"In trying to limit [PDP-15] console cabling, a time division multiplex communication
scheme was designed to get the signals to the lights and from the switches.
In this scheme, a number of signals were transmitted on the same wires on a timeshared basis,
and the console lamp filaments were used as storage elements.
While this scheme was clever enough to gain the PDP-15's only patent, it was generelly unsatisfactory.
It made the console logic so complex that when it failed, it was harder to fix than the processor."
From Bell, Mudge, McNamara: "Computer Engineering", page 160
Here comes an original PDP-15 console connected to BlinkenBone. This allows to operate a simulated SimH-PDP-15 through the original "blinkenlight" panel.
Isn't it nice? Seems to be a late PDP-15/40 "XVM" model, because it has a BANK MODE switch. A date stamp shows: build in 1970.
* * *
I got this panel donated from a member of my computer club C-C-G. Sadly he deceased before completion of the project.
* * *
The PDP-15 BlinkenBone box assembly consists of two parts: the ancient panel, and behind a separate metal case with simulation and interface electronics. Both are mounted onto a black plate.
The PDP-15 panel is in fact made of two separate units, each with individual power and data cables: "Indicator Board" with lamps, and the "Switch Board".
The orignal flat cables were cut off, I had to solder new ones onto the boards.
Very narrow! It took a while until my circuit tester was silent.
The BlinkenBone electronics consists of
- A "Rittal 1505.510" case, dimensions 50x20x12 cm.
- BeagleBone credit-card sized micro Linux system
- BlinkenCape (adapter board with UARTs)
- BlinkenBoard (parallel I/O)
- auxilliary ATmega micro controller
- two power supplies
"Blinkenbonizing" the physical PDP-15 console panel
Connecting the PDP-15 to BlinkenBone was quite an adventure.
The "normal" PDP-11 panels are just a bunch of LEDs and switches, each having its own wire with TTL signals. To connect to the BlinkenBoard almost nothing has to be done: just sort the wires!
Even the PDP-10 KI10 was not this different. Sure, the lamps are driven with +12 V, and every button had a lamp in it. But all in all only the wire count was challenging.
The PDP-15 is special:
- lamp ("Indicator") Board and Switch Board are totally separated, so in fact two units to connect.
- it has lightbulbs instead of LEDs, which all were soldered in. All must be replaced and they produce heat.
- the electronic is designed to consume -6V, +5V, +10V and +30V ... do you really need 4 power supplies?
- switches and lamps are arranged in a multiplex array: in a circular fashion only one of 3 lamp or switch rows is accessed by software at given time. On a plus side, this reduces the wire count. But signal generation is complicated.
I realized I could not generate all needed voltages with a PC power supply as usual. I had to deal with these voltages:
+10V on the Indicator Board: Luckily, the +10V are only needed to generate +5V for the TTL chips:
DEC routes 10V over a big 10 watt resistor so the TTLs draw power down to almost +5V, fine regulation is made with a small Zener diode.
So no +10V are needed, just bypass the resistor.
-6V on the Switch Board: I tried to generate the -6V from the PC power supplies -12V over an 7906 regulator. Normally -12V on PC power supllies is rated with 300mA, but I found a small TSX 250W part with -12V rated at -800mA.
So no problem? Oh well: When the needed 400mA were drawn the power supply switched off. What about the proposed 800mA? A research indicated that my power supply was the only one on earth with more than 300 mA rating!
Perhaps some China guy scanned a datasheet and the OCR converted a "300" to an "800".
What to do? The schematic for the switch board is a bit strange, but the -6V are just needed to give some switching transistors a slightly negative bias. I wired -6V to GND and bypassed some diodes and resistors, everything is fine now.
+30V: is needed on the Switch Board and on the Indicator Board.
- On the Switch Board it feeds a closed switch with "High" level and is then reduced to TTL level via diodes and resistors. So why all this hazzle ??
- On the Indicator Board the +30V drives the lamps, about 2 amps are needed. I added a 2nd power supply .
Light bulbs: the power supply.
Getting the lamp array operable was quite a journey!
At first I bought a 30V power supply as rated. The lamp voltage is so high because of multiplexing: each lamps is ON only a fraction of time, and must be driven with overvoltage to get their normal light level on average.
+30V is a bit unusal, but I found a sealed power supply offered as replacement for LCD monitors.
Lamp rating and replacement:
Still open question: Are these light bulbs driven with 14V or 24V or what?
I tested the lamps and found some dead and lighting level generally quite different.
So I replaced them all. The light bulbs are "T-13/4 Bi-Pin". In the PDP-15 schematic the type is indicated as "#2335".
You can by a type "2335" from CML still today, it is rated at 14V nominal.
Stupidely I FIRST bought compatibles 14V bulbs from Mouser, THEN checked the original PDP-15 bulbs again: They need in fact 24V instead of 14V! The usual DEC documentation error, change of type rating of years, or heavily aged bulbs?
Anyhow, now I had a bunch of 14V bulbs, and a 30V power supply.
After first shock there was a cheap solution: since the lamps are multiplexed, the software can inject some idle cycles to reduce average power.
Later I changed the power supply to a 15..23 V type, and the mulitplexer introduces no idle cycles anymore.
Lightbulb overvoltage MUX watchdog
Since the lamps are multiplexed, they are only ON 1/3 of time. This is the reason they're driven with overvoltage.
The multiplexing lamp driver runs in the BlinkenBone server on the BeagleBone. Backdraw is: on any software error, or if the Linux decides to kill or stop the task, MUXing stops and a whole row of lamps will quickly burn out.
Also debugging the MUX server logic would be impossibly without destroying my lamps.
(Lamp row: 14V bulbs driven with +30V, about to burn)
To protect against this, I added an ATmega88 micro controller.
He just monitors the MUXing inputs to the Indicator Board, and drives a relay switching the +30V.
If any row signal remains constant too long, lamp power is switched off. Cool.
After having finished the Blinkenlight API server and the multiplexing software, I found the lamps lighting levels still very uneven. Reason was not clear at first, since all bulbs were replaced with fresh ones already.
Cause were the switching transistors on the Indicator Board: there's one transistor per lamp, acting as matrix node, and there are more powerful switchers for a block of every 6 lamps driven by the "row select" signal.
After 40 years the current gain of these has gone quite bad!
I replaced all 12 power switches 2N2219A, and situation became much better. I measured all 2N2219A's: the original 1970 ones had a current amplification hFE of 88..130, generation 2016 has about hFE=250. Then for the 10 darkest bulbs I also replaced the matrix node transistors ... looks quite good now!
The heat is on
The step from LEDs to light bulbs means one thing: HEAT.
The whole panel has about 70 lamps, each dissipating about 1 watt. And the switching transistors add their part too.
After 15 Minutes of run with all lamps on, temperature was so hot I couldn't touch the light guiding board with my hands, and the acryl board began to warp!
First design for the case was a neat closed outfit. I had to rework it to have gaps for venting. Technically a good solution, but now the ugly stuff inside can be seen.
Reduced lamp voltage
And I replaced the 30V power supply by one with adjustable power levels (a universal notebook power supply with 15,19,22,24 V), to have some freedom to experiment with.
At 30V the multiplexer process drove each lamp with 1/6 duty cycle; at 20V the same brightness is achieved with 1/3 duty cycle.
Also the watchdog ATMega had to be reprogrammed.
Now the panel feels not too hot if 60% of the lamps are on for hours. Lamp voltage is 22V, which can be reduced to 19V if things start to smell again.
The reduced lamp voltage level has one further advantage: On system load the Linux scheduler may stop the muxing process for a period.
Muxing stoppes shortly for about 100ms, this caused visible flicker with the +30V (a whole row "flashes up").
With 20V the lamps are not so overloaded and the flicker is much less visible.
And yet another problem: if many lights are ON, they shine backward throught their printed circuit board (PCB) and into the room behind panel and electronic case. LEDs don't do this!
In the original PDP-15, there was only air behind the panel, but my design put a white wall there. This forms a light box which gets very bright inside.
Now also lamps which are OFF get light from behind, contrast between ON and OFF lamps is poor.
Situtation could be improved a bit by painting everything behind the panel to black. I was temped to blacken also the indicator PCB, but it's original and should not be touched.
The power/repeat rate knob
Remember those old radio amplifiers, where Power and Volume were both functions of the same knob?
The PDP-15 is switched ON exactly this way, by operating the rotational "REPEAT_RATE " knob.
The two "POWER ON" signals are connected to GROUND and the green "PS ON" ("Power Supply ON") wire of the PC power supply.
The lamp voltage is controlled by the ATmega watchdog and only powered ON, if the Blinkenlight API server produces proper multiplexing signals.
And the value of the "repeat rate" potentiometer is digitized to an 8bit value range of 0..255 by the ATmega AD converter.
These I/O ports are routed to the outside:
- BeagleBone's Ethernet
- BeagleBone's USB (for a WLAN stick outside the metal cage)
- The 4 RS232 ports from the BlinkenCape
The RS232 can be used for additional terminal session to the BeagleBone's Angstrom Linux.
But much better: SimH 4.x can connect simulated serial ports to physical ones (earlier version could only connect Telnet ports to simulated ports). So several VT-terminals can be connected to the PDP-15 and operated under a multi-user operating system like XVM/RSX.
If the Linux devices for the UARTs are
then SimH connects with a statement like
sim>attach dz Line=1,connect=/dev/ttyS1
sim>attach dz Line=2,connect=/dev/ttyS4
To be of any use, the PDP-15 BlinkenBone box must implement the "Blinkenlight API server interface".
So a C command line program was written, which
- defines the logical "controls" of the PDP-15 panel ("Register lamp field", "Data switches" etc),
- makes the panel accessible over the API interface with Remote Procedure Call (RPC),
- transforms logical switch and lamp values into bit patterns,
- and multiplexes those bitpatterns over the BlinkenBus interface "/dev/blinkenbus" to the BlinkenBoard I/Os.
The server is called "pdp15_blinkenlightd" and runs only on the BeagleBone. It is started automatically on Linux boot.
Since Indicator and Switch Board are controlled independently, I could use different multiplexing frequencies:
- Lamps are multiplexed with 1kHz (do be flicker-free),
- the switches are sampled with just 10 Hz (to supress contact bouncing on some keys).
Running your own panel
Finally, there's a virtual version of this PDP-15 panel! So you can play with it, without the hazzle of mounting your own hardware.
And it's free, you don't have to steal a PDP-15 in the next museum.