BlinkenBone

Details

Written by: Administrator

Parent Category: Projects

Category: BlinkenBone

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.

 

Details

Written by: Administrator

Parent Category: Projects

Category: BlinkenBone

The Blinkenlight API

"Blinkenlight API" is a software interface used by clients and servers to communicate.

Physically the API comes as set of C header and source files to be compiled into client and server programs.

It is designed to operate on Blinkenlight panels in a high level way. No more dealing with network sockets, wires, lamps, switches or bit patterns! Instead a console panel is abstracted as a set of "controls".

Server, Panels & Controls

Over the Blinkenlight API a simple hierarchy of objects is defined:

1. A client can connect to one of many servers (over the network).
   
2. one server controls several panels (over multiple BlinkenBoards on a BlinkenBus)
3. one panel contains many controls.
4. controls are "input controls" (switches, dials, etc.) or "output controls" (lamps, digit displays, etc.). In each case, their current state is given by a single long integer value.

"Controls"?

The term "control" is used here as "element of a graphical user interface", another term is "widget".

Examples for controls on a Windows program (here Firefox) are: menus, buttons, edit fields, drop-down boxes.

 Examples for controls on a blinkenlight console panel are: LED rows, switch banks, rotary knobs.

 You see: many lights and switches are grouped according to their function and treated as one object.

The state of a control is described by a single integer value.

Two examples from the PDP-11/70 console panel above:

• the Data Switches are set to octal 00707720, so this input control has a value of 233424 (decimal).
• the DATA LED row shows the octal pattern 063637, so this output control has a value of 26527 (decimal).

Network layer

A Blinkenlight API client communicates with a Blinkenlight API server through the "Remote Procedure Call" protocoll (RPC). More precisely, the Sun implementation ONCRPC is used. Over RPC, a client can call code (procedures) on a remote server, with parameters and results transmitted transparently over the network.

While ONCRPC is quite old, it's lightwidth yet powerful. In contrast to plain socket communication, it handles type conversion between different architectures, assembly of data spanning multiple network pakets and error management. It is part of every Linux distribution. Also a free implementation for Microsoft Windows exists.

Building a RPC application consists essentially of these steps

1. Define the functions to call. and the data structures to transmit.
2. use the tool "rpcgen" to generated C interface code ("stubs") both for the client and the server application.
3. Complete the client and the server by implementing functionality.
4. Finally on the server, a special "portmapper" service must run.

Code alarm!

Here are parts of the Blinkenlight C-header file for API clients. This should give you an idea how to use it (sorry for those long identifiers!)

// a control is one functional element on the panel. It's state is given by "value".
typedef struct blinkenlight_control_struct {
 char name[MAX_BLINKENLIGHT_NAME_LEN];
  unsigned char is_input; // 0 = out, 1 = in
 u_int64_t value; // 64bit? for instance the LED row of a PDP-10 register is 36 bit!
 ...
} blinkenlight_control_t;

// a blinkenlight panel is a set of controls
typedef struct blinkenlight_panel_struct {
 char name[MAX_BLINKENLIGHT_NAME_LEN];
 unsigned controls_count;
 blinkenlight_control_t controls[MAX_BLINKENLIGHT_PANEL_CONTROLS];
 ...
} blinkenlight_panel_t;

// a list of panels
typedef struct blinkenlight_panel_list_struct {
 unsigned panels_count;
 blinkenlight_panel_t panels[MAX_BLINKENLIGHT_PANELS];
 ...
} blinkenlight_panel_list_t;

typedef struct {
   char *rpc_server_hostname ;
  blinkenlight_panel_list_t *panel_list; // list of all panels published by server
 ...
} blinkenlight_api_client_t ;

// create and destroy a client object.
blinkenlight_api_client_t *blinkenlight_api_client_constructor(void) ;
void blinkenlight_api_client_destructor(blinkenlight_api_client_t *_this) ;

// auxilliary: get last error text
char *blinkenlight_api_client_get_error_text(blinkenlight_api_client_t *_this) ;

// manage connection to server
blinkenlight_api_status_t blinkenlight_api_client_connect(blinkenlight_api_client_t *_this, char *host_servername) ;
blinkenlight_api_status_t blinkenlight_api_client_disconnect(blinkenlight_api_client_t *_this) ;
blinkenlight_api_status_t blinkenlight_api_client_get_serverinfo(blinkenlight_api_client_t *_this, char *buffer, int buffersize) ;

// query panels and their controls from the server
blinkenlight_api_status_t blinkenlight_api_client_get_controls(blinkenlight_api_client_t *_this, blinkenlight_panel_t *blp);
blinkenlight_api_status_t blinkenlight_api_client_get_panels_and_controls(blinkenlight_api_client_t *_this);

// read new values for input controls from server
blinkenlight_api_status_t blinkenlight_api_client_get_inputcontrols_values(blinkenlight_api_client_t *_this, blinkenlight_panel_t *blp);

// write changed values for output controls to the server
blinkenlight_api_status_t blinkenlight_api_client_set_outputcontrols_values(blinkenlight_api_client_t *_this, blinkenlight_panel_t *blp);

You will notice that reading and writing of control values is only possible for all controls of the panel at once (..._set_outputcontrols_values(), ..._get_inputcontrols_values()). This should force the programmer to use few big transactions, not many small ones. There is a high constant overhead for a network transmission independent of its payload. The same is true for system calls to the /dev/blinkenbus file interface: the call is costly, the transmitted data volume is cheap.

Details

Written by: Administrator

Parent Category: Projects

Category: BlinkenBone

Components of BlinkenBone

It was much fun to split the BlinkenBone system into cleanly separated modules, which communicate over meaningful interfaces.
But after that I had to fiddle long with this  "Architectural overview" diagram:

(click image to enlarge)

Perhaps this is overengineered, but I wanted to create the final architecture for any future blinkenlight project.

Well, I hope you can recognize the main components:

• Real physical console panels are connected to I/O boards ("BlinkenBoard").
• many parallel BlinkenBoard are connected to one BeagleBone over a parallel bus ("BlinkenBus")
• The low level interface to all these board is a Linux file device named "/dev/blinkenbus".
• On top of the file interface, the "Blinkenlight API server" provides a high level interface to the panels.
  He abstracts the digital I/O signals into high level objects like "panel" and "control".
• The Blinkenlight API communication model is split into client application programs, and servers providing panel control (a "two-tier" architecture).
• A console panel can also be simulated. The simulation program must also act as server. It can run on any computer and is not bound to the BeagleBone. PAnelsimulations are written in Java Swing, so they are platform independent.
• Test programs, machine simulations (SimH), or some other show programs are all clients to the Blinkenlight API server. They can run on any computer.
  They set lamps and react on switch settings like the real machine behind the console.

Why a client/server model?

The split of application logic into "clients" and "servers" gives an immense degree of freedom for a BlinkenBone installation:

• Flexible interconnection between clients and servers:  For example, a maschine simulation program can easily access different console panels or simulation just by connecting it to a different server. (one client - alternating servers - alternating panels)
• One panel installation can be driven by alternating client program. For example, you could operate a given console panel either with SimH or a Web interface or a "kiosk mode" show program (alternating clients - one BeagleBone - one panel)
• One BlinkenBus can control many I/O boards, so one BeagleBone can control more than one console panel. Then many simulation programs each can access their own panel over the same BeagleBone. (many clients - one BeagleBone - many panels)
• One machine simulation program could even access many BeagleBones in parallel (one client - multiple BeagleBones - many more panels). So the system is expandable beyound imagination.
• If the BeagleBone/BlinkenBus/BlinkenBoard system is replaced by some other hardware in the future, existing client programs need not to be touched.
  (same client programs - changing panel hardware server)
• BeagleBone can act as headless remote controller for console panels, and can be controlled over WLAN.
• Development of client machine simulation applications for consoles can be done under Ubuntu or Windows. So cross compiling/cross debugging is mostly elimanted, software development can be done without physical access to the BeagleBone server.
• All clients can always run on the BeagleBone itself, by communicating to the Blinkenlight API server at "localhost".

MVC

If you're a fan of the "Model-View-Controller" pattern, you can reorder the BlinkenBone architecture as follows:

• the "Model" (business logic and data objects) are provided by the Blinkenlight API server. He has data structures about panels and their controls and allows to manipulate them.
• the "Controller" (user input logic) sits in the Blinkenlight API client (a machine simulation). The simulation program changes the state of the panel according to the user input (switch flipping) and the machine state.
• the "View" is just the physical console panel (or its graphical simulation). This is the front end the user interacts with.

 

Layers

An actual BlinkenBone application can be written as stack of components. For example, the video on the Intro page shows SimH controlling a PDP-11/40 console panel. This is the component setup:

Level	Component	Type	Physical unit
13	SimH PDP-11/40 simulation	software	Notebook
12	"REALCONS" SimH device extension	software	Notebook
11	Blinkenlight API client	software	Notebook
10	Remote procedure call client interface	software	Notebook
9	TCP/IP	interface	cable
8	Remote procedure call server interface	software	BeagleBone
7	Blinkenlight API server	software	BeagleBone
6	BlinkenBus file interface "/dev/blinkenbus"	interface	BeagleBone
5	kblinkenbus driver	software	BeagleBone
4	BlinkenCape	hardware	BeagleBone
3	BlinkenBus	interface	cable
2	BlinkenBoard #1	hardware	Panel assembly
1	PDP-11/40 console panel	hardware	Panel assembly

 

Impressive, isn't it?

 

 

Details

Written by: Administrator

Parent Category: Projects

Category: BlinkenBone

"BlinkenBone?"

Abstract: "BlinkenBone" is a Blinkenlight panel project, first realized first with the Linux single board computer "BeagleBone" . With the BlinkenBone system, you can connect physical or simulated  console panels of historical computers to simulations of these computers.

Yet another Blinkenlight project

If you read this, you surely know what a "Blinkenlight panel" is: the front of a historical computer, equipped with lots of lamps and switches. There are still many of them in vintage computer collections, since if an old computer was scrapped, the panel often was preserved.

But the Blinkenlight panel disconnected from its computer is just a nice picture on the wall. You need to add control electronic and machine logic to it, to let it show it's original behaviour .. read: "blinking"!

Clearly every vintage computer nerd is hooked to these console panels. So for years people connected Blinkenlight panels to microcontrollers or PCs and simulated the computers behind. Project BlinkenBone is no exception so far. But of course I think its better than all other projects! And there are reasons:

Proudly presenting the feature list:

• BlinkenBone is able to control the biggest known Blinkenlight console panel on earth. As far as I know, this is the IBM 360/91 console in the Computer History Museum  (search for "360/91" on their site).
  To drive the 360/91 was one of the #1 development targets, now about  2800 lamps and 1200 switches can be connected to a single BeagleBone!
• to reduce costs and installation overhead, one BeagleBone is able to control several panels. Typically it should drive a whole "Blinkenlight" exhibition room in a computer museum.
• panels are controlled over Ethernet TCP/IP (with WLAN as options). So all kind of remote controlling - including web-interfaces - are business-as-usual ... (just find someone who writes all the software).
• the interface to the Blinkenlight panels is fast enough to show smooth light patterns. This means at least 25 updates per second ... and remember: on a 2300 lamp panel! BeagleBone can transfer 250 kBytes of switch and lamp data per second.
• the interface electronic was designed to sense and drive not just clean 5V TTL signals, but also bare lamps and raw switches. (vintage console panels often were cut off from their computers quite brutally). I/O voltage maybe up to 40V.
• For presentations, the driving electronics including the computer simulation must somehow be integrated into the original console panel. No assumptions about these panels can be made, they come in every shape and sizes. So mechanically the BlinkenBone components are flexible and modular. The simulated computer can run on the BeagleBone itself.
• As controlling software, several options can be run alternatively or in parallel.
  - If SimH simulates a machine, it is used.
  - For other machines, simple "show programs" could do some blinking and switch reactions.
• Controlling software (= the simulated computer) is intended to run primarily on the BeagleBone.
  But for development, it is nice to run this software on a MS-Windows or an dekstop-Linux-PC, and still access the BlinkenBone.
• It is possible to write a software-simulation of a historical console panel and use it instead or parallel to the original one.
  Panel simulations also help while developing control programs or working on SimH: You can develop applications for BlinkenBone without carrying the big precious original console panel around with you.
  (See here for a real and a simulated PPD-11/70 panel sitting side-by-side).

What made BlinkenBone possible

Some factors supported BlinkenBone on its way:

• It benefits from the appearance of cheap powerful embedded Linux computers in 2011: "Raspberry Pi" even reached mainstream news. Prices are very low for ARM based hardware now, Linux with Ethernet and TCP/IP is for free, and every software which can be compiled with the Gnu Compiler "gcc" can be run.
  For a more detailed introduction to the BeagleBone see project "DECbox".
• My computer club CCG has some rare panels in his collection, these always stimulated my phantasy.
• CCG club member Thomas is an electronic engineer and can make every printed circuit board you want.
• And since BlinkenBone is already my 3rd approach on the "blinkenlight" theme, it has a quite mature concept finally.