BlinkenBone test client

[Neil Higgins]

The BlinkenBone repo contains a test client, which is not included in Oscar's distribution. It is easily created as follows:

Clone the BlinkenBone repository: Make a suitable directory and cd to it. Then -

git clone https://github.com/j-hoppe/BlinkenBone.git

This will take a few minutes. It will create a subdirectory called BlinkenBone containing the entire repo - nearly 800Mb.

cd down to BlinkenBone/projects/07.2_blinkenlight_test

Now type -

(MAKE_TARGET_ARCH=RPI make clean)

(MAKE_TARGET_ARCH=RPI make all)

In a remarkably short time you will find an executable called blinkenlightapitst in a subdirectory called bin-rpi. This is the test client.

cd down to bin-rpi. Then -

./blinkenlightapitst --help

Even with your PiDP-11 running you can do this -
./blinkenlightapitst --ping 1 localhost

To avoid confusion, you should try most of the other commands with only the server running.

To do more, you will need to understand the structure of the PiPD-11 server panel and controls. I was a little disappointed to find that the test client does not provide detailed information about this, because if I understand the code libraries correctly, it could be done (all of the data structures seem to be self-describing). You can, however, get this information by looking at main.c in /opt/pidp11/src/11_pidp_server/pidp11/.

Having got this far, there are still many questions for the motivated reader to unravel about exactly how the PiDP-11 works. Such as:

• exactly how REALCONS interchanges information with simh
• how often REALCONS sends out updates to connected server(s)
• whether updates contain all data or only changes
• the number of REALCONS updates that get rolled up into average intensity values for the PiDP-11 lights (it is clear that Oscar and/or Jorg has come up with th nifty 16-stage intensity modulation scheme to map intensity values onto the LEDS as part of the multiplexing process)
• accordingly, how fast the intensity values are updated, and finally
• the multiplexing speed (panels or rows per second)
  

There might be documentation to answer all of these questions, but - if this is a typical open-source project - probably not.

[Neil Higgins]

(Some of) the above questions are (partly) answered by the following text in /opt/pidp11/src/02.3_simh/4.x+realcons/src/REALCONS/realcons.c:

   Information flow:
   ===================
   - Panel switches produce SimH commands
     Examples : Switch sequence LOADADDR, EXAM produces an "examine <addr>" string.
                Switch HALT produces ^E break char (if machine is running)
                Switch RUN produces "cont"
   - SimH manipulates registers, sets memory, reads memory, runs simulated processor
   - Changes on SimH machien are propagated to Realcons machine state :
     A duplicate machine state, so the console panel logic has something to visualize
   - Panel logic displays machine state with Lamps.
   - Panel is provided with computing time: SimH calls realcons_service()
       in interactive input loop
       and instruction execution loop

   Modularity:
   ===========
   - realcons_* can be used indepently of SimH, only realcons_simh is specific
   - Functions can be separated after Model-View-Controller model:
       1 console panel "model" is the Blinkenlight API data struct of panel and controls
     2 console panel "controller" is the logic which reacts on switches and drice the lights.
       This is implemented in SimH and here, in the realcons_* sources.
     3 console panel "view" is the physical console on the BlinkenBone, or a GUI simulation
       driven by another Blinkenlight API server.
   - no global variables, all data objects are "constructed" and destructed dynamically
   - Programming model is slightly object based.
   - all logic for a specfic console panel is located in an instance of cosnsole contrller in realcons_<machine>.c
   - console instance is constructed late in the "connect" command
   - machine propertys and service function calls have a 2-stage calls hierarchy:
   - base class is "realcons", subclass is "realcons_<machine>

    Scalability
   ============
   One machine may have more than one consoles/panel-
   PDP10: has console, and <n> rack headers.


   SimH CPU, console controller logic, and panel on Blinkenlight server:
   ==============================================================
   - For a complete system, 3 objects must fit together
     1) the CPU SimH simulated (as in "set cpu <type>", type = "11/40", "11/70", ...
     2) the realcons console control logic
       3) the physical panel connectet to BlinkenLight API server.
        The panel name is defined in the configuration file.
   - All console panels have a common interface,
     It is initliazed in realcons_init()
   - on SimH "set cpu <type>", the realcons_machine_type is also set,
       and also the default name for "console_name"
   - "console_name" can be overwritten, togheter with hostname.

[Neil Higgins]

In /opt/pidp11/src/02.3_simh/4.x+realcons/src/REALCONS/realcons.h we find:
    #define REALCONS_DEFAULT_SERVICE_INTERVAL_MSEC  20 // run service 50 time per sec

However in all of Oscar's bootscripts we find:

    set realcons interval=1 <which I assume to be in milliseconds, as per the default value>

This value might not be viable if the server is running on a separate host from the client, depending on network speed, CPU loading, etc.

So it appears that realcons is sending (and probably getting) updates to (and from) the server nominally 1000 times per second.

In /opt/pidp11/src/11_pidp_server/pidp11/gpiopattern.h we find:

    #define GPIOPATTERN_UPDATE_PERIOD_US 50000  // 1/20 sec for screen update
    // in one cycle more than GPIOPATTERN_LED_BRIGHTNESS_LEVELS events from server must be sampled, else loss of resolution

It appears from commented-out lines that a range of values has been tried for this parameter, and 1/20 sec (50 times per second) has been chosen.

In /opt/pidp11/src/11_pidp_server/pidp11/gpio.c it is made clear that multiplexing runs independently of intensity updating. Double buffering is used: The multiplexer outputs from one buffer, while LED intensities are updated in the other buffer, then the buffers are switched. It is still not clear (I cannot find a relevant #define) how quickly the multiplexer runs, however for a 16-phase output pattern and a total of 8 LED and switch rows, the rate should be a minimum of 50 * 16 * 8 = 6400 rows per second (156 uS per row),

 

[Neil Higgins]

I should recant on my previous cynical comment about documentation by pointing out that the BlinkenBone test client does indeed have documentation, here:

http://www.retrocmp.com/projects/blinkenbone/blinkenbone-software/250-blinkenbone-blinkenlightapitest

[Stephen Casner]

I've tried to build the test client on my MacBook but the build process fails badly.  The first error from clang is that the -o option is not allowed when there are multiple output files, but there should be only one.  I think this is caused by the .h files being included on the cc command.  Fixing that leads to a complaint about missing the defintion of strlen in main.c, where I see the #include <string.h> is commented out.  Uncommenting that leads to a whole slew of warnings and errors in rpc_blinkenlight_api_clnt.c.  I threw in the towel at that point.

Anyone else tried building on Mac OS?