BlinkenBone setup - operating SimH
The only purpose of the whole BlinkenBone project is to let console panels behave as if they still were connected to their original machines.
So you have eagerly waited to plug the SimH simulator onto the panel.
To be able to control the panel, a Blinkenlight API client must be incorporated into SimH. This client module appears as a SimH machine device with the name "REALCONS".
Read here all about it!
Folowing are just a few hints ... mostly bugs and inconveniences :-)
Getting SimH with REALCONS extension
Well, contact me!
I forked a special SimH version out of the C sources, version is still 3.8.x.
I'm not putting it online, because its still under development.
I can generate version for BeagleBone ARM7 Linux, for x86 Linux and for MS-Windows.
Selecting the right CPU type
In SimH you set the CPU model of the PDP-11 with
set cpu <type>,
with type = "11/05", "11/70", "11/40", "11/23", and so on.
Normally this setting gets not too much attention:
- if you run one of the DEC operating system disk images, the software will adapt automatically to the cpu type.
- on the other hand DEC hardware diagnostics, which depend on the cpu type, will not run under SimH anyhow.
For the REALCONS extension, the cpu type is a very important setting:
- The console panels for different cpu models have each unique and slightly different behaviour.
- it is also the name of the panel in the Blinkenlight server
- and it selects additional simulation logic in REALCONS itself.
Which panels are supported by the current SimH version?
At the moment, SimH/REALCONS supports 11/40 and 11/70.
There's no way to query it directly, maybe this is a TODO for me.
To support a new cpu type, both REALCONS and the panel must be build for it.
Trimming the update rate
To update the lamps on the panel, and to poll the switch state, there is periodically a data transimssion between SimH and the Blinkenlight API server.
REALCONS updates the panel asynchronically from the SimH simulation loop, you can choose an arbitrary update rate.
You can experiment with
sim>set realcons interval=<update_in_milli_seconds>with <update_in_millisconds> optimally in the range of 100..1. "1" means: 1000 updates per second, "100 means" : 10 updates per seconds.
This is far far more slower than on a real PDP-11: there the display is update with the CPU clock, which is about 1 MHz.
These factors have influence the optimal update rate
- Generally speaken: Set the update rate as high as possible, (= the millisecond value as low as possible). The panel dispaly will look smoother then.
- If you run SimH on the BeagleBone, the update rate is limited by the computing power of the 700MHz ARM cpu: high rate will slow down the rest of the simualtion.
- if you control the panel over network, computing power is not the issue: SimH will run on your multi GHz PC then. But network bandwidth becomes an issue. To update the panel state, only few bytes are transmitted (less then 30 for the 11/70). But packet frequency and packet latency may be overload a slow WLAN connection.
- Sometimes a slower rate may give better display. The panel update rate may have interferences with some software loop times on the simulated PDP-11. Then you can see flickering artifacts.
- And if you plan to make a video: the frame rate of your camera may also cause interferences with the update rate.
I usually have interval times of 2..7 milliseconds. REALCONS defaults to 20 milliseconds.