BlinkenBone as approach for SimH device visualisation

The REALCONS extension to SimH is part of the "BlinkenBone" project.

Now there are plans to use it as an generic "SimH device visualisation framework". To support the coders of SimH, the concepts behind REALCONS are explained here.

SimH Source code is available on GitHub.

In fact, this is just another article about the BlinkenBone architecture, but here the focus is on SimH.

• For "BlinkenBone", SimH is just one of many applications to drive a Blinkenlight panel.
• But for SimH, a "BlinkenBone" hardware is just one way to visualize the simulated computer. SimH users will mostly drive visual simulations of devices, not physical Blinkenlight panels.

As usual, such an abstract document is incomprehensible unless you hold an actual demo application against it. So you might try the PDP-11/40 simulation again.

Dreaming of a visual extension on SimH

 A visual extension on SimH would have these features:

• paint a clickable, animated picture of a whole computer system with many devices.
• while the devices are operating, their visual representation is updated accordingly (lamps blink, tape reels spin,switches flip).
• the simulated computer can be operated with the mouse (switches can be toggled, disks and tapes can be mounted on devices by drag&drop). 
• even an acoustical simulation could be added: you might hear the sound of rotating fans, printers, moving tape ....
• the visual representation of the computer is dynamically controlled by SimHs configuration.
  Only those device are shown, which are actually enabled.
• Visual operations and classic SimH command line input should coexist. The command line should echo the visual actions also in text form: For example, dragging a tape picture onto a tape drive could result in the echo of "attach ...." command to the SimH command line.

REALCONS was designed to implement all this.

However, in the current code, REALCONS implements only the CPU device for PDP-11/40.

Inside REALCONS

The REALCONS extensions consists of several software modules. When you try understand the code, the following function diagram may help. (Again: only the CPU device is implemented at the moment).

(Click on the image for the updated PDF)

Overview, concepts

• Talk is about "panels" and "blinkenlights" in the existing REALCONS code, but the more general term "device graphical user interface" ("device GUI") is used on this page instead. Or should we speak simply of a "SimH GUI" ?
• a "device GUI" don't need to be a blinkenlight panel, it can be also pictures of other equipment with operable objects (press buttons, change disk packs, tape reels)
• Multiple SimH devices (CPU's, disk drives, tape drives, ...) can each have an own "device GUI" attached.
• the graphical represention of a SimH-computer is an interactive picture with lot of interactive "device GUIs". For example,
  - you can click on buttons on the console panel with the mouse, to EXAM/DEPOSIT.
  - lights are updated according to CPU states.
  - You could drag&drop disk and tape media symbols onto pictures of disk and tape drives to "mount" them.
• "device GUIs" consist of two parts: "device GUI logic" and "device GUI graphics"
  "device GUI logic" are state variables and additional logic inside SimH ("REALCONS" here).
  (Example for a PDP-11 panel: state of address register, logic for auto address incremment on multiple EXAM/DEPOSIT)
  The logic interacts with the actual simulation, and controls the graphics accordingly.
• The "device GUI graphic" (interactive pictures on the screen) can not be done with SimH. SimH is a portable C program without any platform independent graphic library. So the "device GUI graphic" is a separate application. For BlinkenBone, it is the Java PDP-11/40 panel simulator.
• The "device GUI graphic" application must also be platform independent, as SimH itself.
  (At least it should run on MS-Windows / MacOS / Linuxes, mobile devices). Java Swing seems a good aproach.
  Java is also good for mobile Android platforms (but there they don't use Swing).

deviceGUI logic inside SimH

•  "device GUI logics" are compiled into SimH. They are own processes, running with different and much slower speed then the attached simulated devices.
• the "device GUI logic" serves also as a decoupling buffer between the actual simulation and the visualization.
  NEVER let a state change in the simulated device directly perform some visualization, the impact on run time behaviour would be catastrophic.
  (Example: the DATA LEDs on a PDP-11 blinkenlight panel are NOT updated directly in the CPU simulation loop.) So the speed impact on existing SimH device code in the simulation loop is minimal: Just update some states in the device GUI logic and notify some device events.

Network connection between deviceGUI logic and deviceGUI graphic

• Both "device GUI logic" and "device GUI graphic" share a synchronized copy of the same data structure.
• This data represents the graphical user components, which can be operated by the user with his mouse, and can be updated according to simulation state by SimH.
• The data structure, together with server-side procedures and the network layer form the "Blinkenlight API"
• The connection between "device GUI logic" and "device GUI graphic" must cross
  - a technological gap (C <=> Java)
  - and perhaps physical gaps (if the "device GUI graphic" is not a Java program, but a physical device, as in "BlinkenBone").
  So a network based "client-server" approach is implemented:
  1. The "client" is "device GUI logic". It actively sets display states, and polls user interactions.
  2. The "server" is the "device GUI graphic" application. It processes commands triggered by SimH. It runs parallel to SimH, but never issues any commincation to SimH on its own.
  3. As network layer between "device GUI logic" and "device GUI graphic", Suns "ONC RPC" over TCP/IP is used.
  4. The set of shared data structures and executable server functions is called "Blinkenlight API", (should be renamed to "device GUI API").

"ONC RPC" was choosen instead of raw socket communication, because it has some advantages:

• Shared data and procedures are well defined in a XDR file.
• code for server and client can be generated with the tool "rpcgen"
• Marshalling (conversion between endianess of different processor types) is handled transparently.
• Integrity of request/response transactions is checked.
• Since it's a 1990 technology and based an raw C, it is very fast. This is important if going to small micro-Linux platforms (yes, Raspberry...).
• Since Sun implemented the NFS (network file system) with ONC RPC, you can rely on speed, stability and future support.

In short, RPC gives you all for free what you would have to code on your own if using raw sockets.

The visual GUI (deviceGUI graphics)

• a "device GUI graphic" application can (and should!) implement a graphical representation of a whole machine with all supported devices. So one "device GUI graphic" application publishes many "device GUI graphics" over the client-server API. For each SimH device (CPU, disk, tape,...), the attached "device GUI logic" interacts with the corresponding graphics individually. On startup, SimH should tell the "device GUI graphic" application, which devices to display.
  So, an "attach RL0 <file>" would result in appearance of an RL02 disk front in the picture of a 19" DEC rack.
  If the "RL drive is detached, the picture of an empty rack panel should be painted instead.
• a "device GUI graphic" server can be made with different technologies, as long as he implements the "Blinkenlight API".
• for SimH device visualisation, the "device GUI graphic" server is a Java Swing application. It can be written with the "WindowBuilder" designer.
• for "BlinkenBone", the "device GUI graphic" server is a BeagleBone micro-Linux device running a specialized RPC daemon.
• a "device GUI graphic" server implementation can also be a wrapper to an existing hardware blinkenlight project.
  For example, pdp11.nl (Henk Gojen) has written a serial interface to an 6809 based Blinkenlight panels controllers. If his serial interface logic is transformed into a "device GUI graphic" server, his work would not be lost.

Extended "controls"

At the moment, a Blinkenlight API "control" (as part of the shared data structure) is defined as "interface element for users" (primary lights or switches).
The visualisation of a control is meant to be a list of picture, were depending on the control value only one picture at a time is shown.

In the future, a "control" should be interpreted much boader as "some part of a computer, whose appearance is controlled by SimH".
The visualisation of a control can also be a movie (visually emebedded into the pictore of the whol computer system) or a sound beeing played.

Examples for some extended "control" are:

• a whole computer rack.
  Turning it "ON" (set value=1) would not result in any changed visual apperance, but in the sound of rotating fans's beeing played.
•  the activity of a printer.
  Set value = 64bit <01> pattern could result in generation of a synthetic sound, with the 0/1 pattern controlling the noise of letter hammers (depending on the text line printed).
• the activity status of a tape drive. Setting...
  value = 0 would result in the static display of an empty tape drive
  value = 1 would result in the static display of stopped tape reels mounted with a a tape
  value = 2 would result in playing the video of slow forward rotating reels.
  value = 3 would result in a showing "fast forward".
  value = 4 would result in showing a "fast backward" movie, and so on.

Extending the meaning of a "control" would not cause an programming effort in the "Blinkenlight API" layer, it is just a mental thing.

Extending REALCONS: what needs to be done

 When REALCONS is used integraded in SimH as generic device visualisation extension, the following changes should be made:

• Change the names scheme: Example: "REALCONS" -> "VISUALIZATION" ,"panel" -> "device GUI",  visualisation", "Blinkenlight API" -> "Device GUI API".

• the procedure, which queries user input into the SimH console should use multiple threads to get input in parallel from three sources:
  1. getline()
  2. command string from REALCONS
  3. console telnet
  At the moment, "getline()" is disabled, because it is blocking program flow, so REALCONS could not scan for input.. Instead some rudimentary own "gets()" is used.
  
  
• The device data structure in SimH should be extened by a handle to the attached "device GUI logic". At the moment, the (single) CPU device GUI logic is a global variable.

•  optionally replace the Client-Server Transport layer (now ONC/RPC over TCP/IP) by something other (some interprocess communication?)
  While RPC is working fine between C and Java, it could be difficult to port to mobile platforms (Android) without "root" privileges.

•  the client (SimH) should tell the server, which supported panels to display. THis is necessary to adapt the visualisation of a whole computer system to the SimH configuration.
  This additional API procedure is easy to implement.

• some "device GUI controls" should have not a numeric, but an String value (examples: a tape file name, which is "inserted" into the tape drive. Or the name of a sound to play.) This is also easy to implement.