Written by: Administrator
Parent Category: Projects
Category: BlinkenBone software

Simulating machines behind the console panel with SimH

Maybe it is time to remember: All the hazzle about panels and switches and busses and boards and interfaces and servers and clients had only one goal: let the console panel behave like a real computer again.

People like this!

blinkenbone seezauber

(Did you ever run your '11 in a public restaurant?)

In most cases this means: Connect the panel to the SimH simulator. (I suppose you are familiar with SimH, aren't you?)

To have an interface to the blinkenlight console, SimH is extended with a new device named "REALCONS". (The name is a reference to Henk Gojen, who build a very good SimH-to-panel integration years ago.)

The REALCONS extension and the console panel

REALCONS is an independend device inside SimH, only loosely coupled to rest of the simulator. And to be exact: It represents not the connection to a panel, but to a Blinkenlight API server. REALCONS itself uses a Blinkenlight API client to access the server.

The Blinkenlight API server and REALCONS implement different components of the original console panel:

This panel logic is sometimes as simple as

"if processor is running, put the RUN LED ON",

but sometimes quite complex, as in

"The DATA lights show the program status word (PSW) after a single step, current memory data after a EXAM, current switch data after a DEPOSIT, the state of register R0 after a HALT opcode or after a RESET instruction, ..."

REALCONS contains many panel logic modules, since not all panels behave alike ... even not all PDP-11 panels.

And REALCONS asserts that these three different components always match each other:

  1. the simulated SimH processor
  2. the REALCONS panel logic
  3. the panel published by the Blinkenlight API server

In other words: if for example a PDP-11/70 panel logic wants to show the run mode on a RUN LED, the panel must have such a LED!

The REALCONS extension and SimH

REALCONS runs generally in parallel with SimH, as an independent process.

Generally switches and lamps are not coupled together in REALCONS, they are handled as indepentend subdevices. Reacting of lights to switch actions is only done in SimH or the simulated machine.

 

Panel switches (input controls)

Panel lamps (output controls)

SimH command
mode ("sim>")

The switches on a console panel produce SimH commands. Generally, there is no difference between commands typed in by an user and a command triggered by switch setting.

For example on the PDP-11/40:

  • Switch EXAM produces "examine"
  • Switch CONT with HALT active produces "step 1"
  • Switch CONT with HALT inactive produces "run"

Lamps are set for a halted CPU,
or as required for EXAM/DEPOSIT/SINGLE STEP cycles.

Simulation running

Switches are repeatedly polled and their states are saved. The running processor uses the polled states.

For example on the PDP-11/40:

  • the HALT switch is used to stop the simulation, like the Ctrl-E hot key.
  • the DATA switches can be read by the processor over the simulated "Switch Register" at address 177570.

Light states are set according to the processor state.

For minimal speed impact, just a few variables are set by the simulation, the lights itself are updated over network by an slower service process.

What exactly is displayed depends on the simulated processor, even every PDP-11 CPU type has it's own REALCONS logic.

Sometimes the light patterns are well documented, sometimes you can get them from real machines or from video, some time you just have to guess.

For the PDP-11/40 KY11-D console, there was apparently good DEC documentation (see attachement), but a look at this video highlighted also the errors in the documentation!

REALCONS command reference

This is how REALCONS is operated through SimH's command prompt "sim>".

set cputype

Syntax: set cpu <cputype>

This is an standard SimH command with side effects to REALCONS.

It selects the variant of a machine family to simulate, and also selects the intern REALCONS panel logic module to be used.
For example, you can not "connect" a PDP-11/45 panel to a PDP-11/70, even if both processors are similar.
"set cpu 11/70" automatically activates the 11/70 panel logic.

For most CPUs there is no REALCONS panel logic implemented. If there is no real panel logic for a given <cputype>, an error message will appear at the "set realcons connect " command (see below).

The panel name (see below) is also set to the string <cputype>, but can be changed later.

Example:  "set cpu 11/40"

set realcons host

Syntax: set realcons host=<host_name>

Set the network name of a Blinkenlight API server to connect to.
<host_name> is the regular name of the computer in the network, or the numeric IP address.

Examples:
set realcons host=beaglebone
set realcons host=192.168.1.187
set realcons host=localhost
 
The hostname is initialized to "localhost" after start of SimH.

set realcons panel

Syntax: set realcons panel=<panel_name>

A Blinkenlight API server may publish many panels, so you have to choose one before you connect to the server.
For blinkenlightd, this is name of the panel in the configuration file.

The "set cpu <cputype>" command (see above) also sets the panel name to the string <cputype>.

Example:
set realcons panel=11/45-experimental

set realcons INTERVAL

Syntax: set realcons interval=<min interval_time_in_milli_seconds>

Set the minimal update interval of the realcons logic. Ideally, the realcons logic would process data from the simulated CPU every instruction cycle. But the simulated CPU run much much faster than data can be transmitted to the Blinkenlight server, so data processing is throttled down.

You can set here the minimal time between two calls to the realcons logic.

Example:
set realcons interval=10

mean: process and transmit data every 10 milliseconds, 100 times per second.

Shorter values give a smoother display, but higher load on SimH's processor, on the network and on to the Blinkenlight server (BeagleBone or simulated panel).

set realcons connected

After you have set <cputype>, <host_name> and <panel_name>, you can connect to the panel. The RPC subsystem handles network transmissions and is responsible for error management.

These errors may appear:

"Realcons panel controller not set"
or "No controller for panel" : There is no panel logic for the current <cputype> implemented.

"Connect to host failed" : Check the follwoing:

"Panel not published by server": Connection to the Blinkenlight API server was established, but the server does not publish panel <panel_name>. A list of panels on this server is displayed.

"Required input/output control not found": Connection is OK, and the server publishes panel <panel_name>. But the REALCONS panel logic uses a control, which is not part of the panel. So despite it has the right name, the panel provides not all the switches or lamps needed.

set realcons disconnected

Disconnect from a Blinkenlight API server. After that, you can change <cputype>, <host_name> and/or <panel_name>, and reconnect.

show realcons

Syntax:
show realcons host
show realcons panel
show realcons connected
show realcons

Show one of the properies set above, or just display everything about the REALCONS device.

If connected to the Blinkenlight API server, also an info string from the server is displayed. Output looks like this:

REALCONS 11/40, host="beaglebone", host panel="11/40", interval=20msec, connected, nodebug, server info=
Server program name........: /home/root/blinkenlightd
Server command line options: -c /etc/blinkenlightd.conf -b
Server compile time .......: Apr 17 2012 21:51:22

So you can be sure the network connection is working!

set realcons test

This sets REALCONS into self test mode. Normally two things happen:

Output may look like this:

Verify lamp test!
Switch SR        = 417406
Switch LOAD ADRS = 0
Switch EXAM      = 0
Switch CONT      = 0
Switch HALT      = 1
Switch START     = 0
Switch DEPOSIT   = 0

The test is terminated automatically after one second (or so).

Keyword SHORTCUTS

All command keywords can be abbreviated, and options can be grouped.

So while the complete sequence to connect to a remote panel is

set realcons host=beaglebone
set realcons panel=11/40
set realcons connected

it can be abbreviated to

se re h=beaglebone p=11/40 c

 

Installation:

SimH with REALCONS device is currently compiled for Win32, Ubuntu and BeagleBone Angstrom Linux. It compiles as usually into an executable named  pdp11, /pdp11.exe or vax, vax.exe, etc.

Additionally the RPC (remote procedure call) functionality has to be installed.

Under Win32, this means to copy  "oncrpc.dll" in to the same directory as SimH, or into \windows\system32\

Under BeagleBone-Angstrom Linux, "glibc-utils" must be installed:  "opkg install glibc-utils"

realcons_pdp11_40.txt -- Behaviour of the PDP-11/40 KY11-D console panel, as implemented in SimH REALCONS