BlinkenBone physical panels

Details

Written by: Administrator

Parent Category: Projects

Category: BlinkenBone physical panels

Oscar Vermeulen made a cute PDP-8/I replica. People love it, the web is full of images and stories.

Offical web presence is here: http://obsolescence.wix.com/obsolescence#!pidp-8/cbie

It's called "PiDP8" because a RaspberryPi is build in.

See it here together with a REAL PDP-8/I and a monitor with the Java panel simulation:

Choose your '8/I ! (click to enlarge)

Use the PiDP8 with REALCONS SimH

On GitHub there is a "rpi" distribution. This contains all binaries to run on the RaspberryPi, among others the special BlinkenLight API server for the PiDP8.

Quick start:

1. Make an network connection to the RPi,
2. copy the panelsim_rpi.tgz over,
3. login with ssh and unzip with "tar xzf panelsim_rpi.tgz". It will need 1.3 GB, since all simulated machines with their disk images are installed !
4. execute ./pidp8.sh

Then ADVENTURE is started on OS/8, the lights on the PiDP8 begin to blink. Now SimH can be operated over the PiDP8 replica switches.

If you execute ./pdp8i.sh instead of ./pidp8.sh, you start the Java panel simulation. You need to connect a monitor on the HDMI port then.

Tired of ADVENT?

Everything written for the simulated PDP8 Java panel applies to the PiDP8. See here how to build and toggle-in own assembler programs.

Why a 2nd SimH implementation for the PiDP8 ?

Why not ?

The PiDP8 comes ready-to-use with a modified SimH, so connecting to BlinkenBone is really not necessary.  But I liked to play with it! As test case for later projects I made an Blinkenlight API server for the PiDP8, so it's now part of the BlinkenBone world.

You can easily switch from the Java PDP-8/I simulation to the PiDP8 as front end, without leaving the BlinkenBone environment.

If you connected on your desktop to the Java panel with

sim> set realcons host=localhost panel=PDP8I connect

then switch to the Rpi (after starting rpcbind and the server there!) with:

sim> set realcons host=raspberrypi panel=PiDP8 connect

The PiDP8 server contains a anti-flicker low-pass and simulates slow lightbulb with the LEDs.

That "Deposit" switch again

As on all DEC panels, the "Deposit" switch has a reverse polarity, to prevent accidental memory change.

For the PiDP8 replica only bi-stable switches could be found (and that was hard enough!), so the mechanical "Off" position must be set by hand.

Compare with the physical PDP-8/I panel:

The default SimH of Oscar doesn't implement the Deposit as inverted. So Oscar's SimH and my PiDP8 server behave different here.

Details

Written by: Administrator

Parent Category: Projects

Category: BlinkenBone physical panels

My PDP-10 KI10 panel lay around for almost 1 1/2 years, until it was shown on the VCB 2014 in Berlin.

It kept me busy over half a year. The story describing this adventure is found here.

Meanwhile there's an article on HACK A DAY about it.

Details

Written by: Administrator

Parent Category: Projects

Category: BlinkenBone physical panels

"blinkenlightd" is a background service ("daemon") written for the BeagleBone. It publishes the attached console panels to Blinkenlight API clients. It normally does not talk to users, but communicates over these other interfaces:

• It provides a BlinkenLight API server interface for clients, see the "Blinkenlight API" page.
• It converts the digital signals connected to the BlinkenBoards to usable "control values". The information how to do this is read from a configuration file.
• It uses the file interface "/dev/blinkenbus" to control the BlinkenBoards.

Connecting panels to BlinkenBoards

If you connected the wires from a vintage panel to the I/O chips on the BlinkenBoard, you typically

• solder some kind of connectors onto the patch field
• and route wires from the connectors to the terminals of the input or output register chips.

It doesn't always looks nice, if a programmer tries to solder:

The assignment between console panel functions and I/O register bit positions must be evaluated by software then.

Problem: decoding/encoding bit patterns into control values

Translating raw digital I/O signals to useful application data involves lot of bit masking and bit shifting. This is usually done in program code which is specialized for the hardware in use.

Example 1:

The 11/40 console panel has a 18 bit switch row for data entry, it is labled "SR" by DEC (for "Switch Register). Let's say the wires coming from SR are connected to the BlinkenBoard with address 1 as follows:

 To get the 18 bit data value for the Blinkenlight API control object, you would use C code like this:

SR_value = get_board_register_data(1, 0)
    | ( get_board_register_data(1, 1) << 8)
    | ( get_board_register_data(1, 2) << 16) ;

Example 2:

The LED "VIRTUAL" is connected to bit 6 of output register 2 on board #1.

To set the LED, this code would be necessary:

tmpval = cached_OUT2_value ;
if (led_virtual) 
    tmpval |= 0x40 ; // set bit 6
else
    tmpval &= ~0x40 ; // clear bit 6
set_board_register_data(1, 2, tmpval ) ;
cached_OUT2_value = tmpval ;

 So for each connection schema, specialized decoding logic must be programmed.

Solution: generic logic and a configuration file

The program code of blinkenlightd does not contain any special code for a certain console panel.
Instead actual wiring is read from a configuration file. If wires are changed on the patch field of a BlinkenBoard, only the configuration file must be changed accordingly.

Bit masking and shifting is done by fixed generic logic in blinkenlightd.

This diagram illustrates how raw digital I/O data from the panel is mapped to proper "control" values:

(click image to enlarge)

The configuration file is also a good documentation about what you've done on the patch field!

The name of the configuration file is normally "/etc/blinkenlightd.conf", since it is the setup file for a Linux service.

In the attachement you find two files:

• the grammar of the configuration files (I used the wunderful "ANTLR" parser generator).
• the full configuration file for the PDP-11/40 panel.

FULL configuration file entry for Example 1:

 control =
        {
                // 18 switches, for data and address input
                name = "SR",  // "Switch register"
                type = SWITCH,
                encoding = BINARY,
                blinkenbus_wiring =
                {
                        // 18 wires, connected to board 1, input register chips 0, 1 and 2
                        register_wiring =
                        {
                                value_bit_offset = 0, // define bits 0..7 of value
                                board = 0x01,
                                register = IN0,
                                bits = 0..7, // lsb on register = lsb in value!
                                levels = active_high // is default
                        }, //
                        register_wiring =
                        {
                                value_bit_offset = 8, // define bits 8..15 of value
                                board = 0x01,
                                register = IN1,
                                bits = 0..7  // lsb on register = lsb in value!
                        }, //
                        register_wiring =
                        {
                                value_bit_offset = 16, // define bits 16..17 of value
                                board = 0x01,
                                register = IN2,
                                bits = 0..1// only 2 lsb bits  for addr 16 & 17
                        }
                }
        },

FULL configuration file entry FOR EXAMPLE 2:

 control =
        {
                name = "VIRTUAL",
                type = LAMP,
                encoding = BINARY,
                blinkenbus_wiring =
                {
                        register_wiring =
                        {
                                value_bit_offset = 0,
                                board = 0x01,
                                register = OUT2,
                                bits = 6
                        }
                }
        }      

*  *  *  *  *

Normally blinkenlightd runs without user interaction. But it has two interactive modes:

Using blinkenlightd to test the configuration file

blinkenlightd can check the configuration file for logical errors. Call it with these options:

 blinkenlightd -c configuration_file_name -t

Using blinkenlightd to simulate the console panel defined in the configuration file

This is tricky. If you call blinkenlightd like this

 blinkenlightd -c configuration_file_name -s

it goes into interactive simulation mode.

It does not access the real console panel over "/dev/blinkenbus" anymore, instead it shows a crude text simulation of the panel described in the configuration file:

The function is simple:

• A list of the output controls and input controls with their current values is shown.
• If a client sets an output control value over Blinkenlight API, the display is updated.
• The value of an input control (a simulated switch) can be set by the user. A Blinkenlight API client gets the new input value on the next call to blinkenlightd.

In simulation mode, blinkenlight does not access any hardware over /dev/blinkenbus. So it can run on any platform, it is not bound to the BeagleBone.

If you like to impress people on an exhibition, you must write an graphical console panel simulator. But blinkenlightd in simulation mode is a valuable tool to develop or debug machine simulation clients without access to a physical BeagleBone/BlinkenBus/BlinkenBoard/panel installation.

blinkenlight_panel_config.g -- ANTLR grammar definition for blinkenlightd configuration file

pdp11-40.conf -- blinkenlightd config file for PDP-11/40 panel

Details

Written by: Administrator

Parent Category: Projects

Category: BlinkenBone physical panels

The Linux file interface for BlinkenBoards: /dev/blinkenbus

BlinkenBus address space.

Over BlinkenBus up to 32 BlinkenBoards can be connected, each occupying an address space of 16 bytes. In the board address space, 11 output registers and 5 input registers are located on overlapping addresses, byte address 15 gives access to the read/write board control register (see "BlinkenBus specification" attachement on the hardware page). The absolute 9-bit address of a certain register chip is given by the formula:

<absolute addr> := 16 * <board_address> + <register_address_on_board>

Over these registers you can read and write raw digital I/O data from the connected blinkenlight panel.

Accessing the BlinkenBus address space as a file

User applications can access I/O registers on the BlinkenBus very easy over a file interface.

The 512 register addresses are arranged as a file of 512 bytes. Reading certain positions in the file accesses the input registers, writing sets the output registers. This file is a simple character device file node, named "/dev/blinkenbus".

The translation between BlinkenBus signal patterns and the device file is done by a Linux kernel mode driver. On access to "bytes in the file" he creates the BlinkenBus signals patterns by toggeling with GPIO (general purpose IO) pins of the ARM cpu.

Example "read":

To get the signals on input register 4 on a board with address switched to hex 0xb (decimal 11), global address 11*16+4 =>180 must be read. This is done by opening "/dev/blinkenbus", moving the read pointer to byte 180, and reading it.

In a C program you would use these Linux system calls:

fbb = open("/dev/blinkenbus", O_RDWR | O_SYNC) ;
lseek(fbb, 180, SEEK_SET) ; 
read(fbb, &your_byte_buffer, 1) ;

You can even do this from the shell prompt with the user command "dd", which is used for block read/write on files:

$ dd if=/dev/blinkenbus bs=1 seek=180 count=1 of=your_file 

The byte value of register 4 on board 11 is written to the file named "your_file". Don't let the output go to terminal screen ... or prepare for some strange characters appearing.

Speed

A Linux system calls like "read()" is much slower than an access cycle to the BlinkenBus in the driver.

Tests indicate that BeagleBone can perform about 10.000 system calls per second. Even unoptimized driver code generate 250.000 BlinkenBus access cycles per second.  So it's good practice to bundle read or write accesses to BlinkenBus registers into few block read/write transactions whenever possible.

Protection against hardware changes

There is one big benefits to have "/dev/blinkenbus" as interface: The underlying hardware (BlinkenBus, BlinkenBoards) can be modified or replaced by something totally different without impact to the overall system.

For example, there may be needs to change BlinkenBus from parallel to SPI or I2C or CAN bus. Or the BeagleBone itself is replaced by some other embedded Linux  hardware with an incompatible GPIO system.

In any case, as long as the driver for the new hardware implements "/dev/blinkenbus" as defined, no application needs to be changed.

Who else needs this?

Well, accessing device data over pseudo files is the BIG standard under Linux: "Everything is a file"

You can open the file and access BlinkenBoard I/O from any programming environment, including

• the hot web app builder Cloud9 for node.js and bonescript
• script languages like Python
• Java
• classic C/C++

And you are not limited to Blinkenlight applications.

If you need massive digital I/O for the BeagleBone, think about using BlinkenBoards!