Over a decade ago I picked up some interesting-lookign input devices at a local surplus shop.
The IBM Lighted Programmable Function Keyboard has 32 unlabeled buttons, each with its own green indicator LED like a ‘80s-era Monome.
The 6094 010 Dials peripheral was even more interesting, with eight continuously-turning knobs with a clever design that could be spin quickly or fine tuned.
These were originally made for RS/600 series CAD workstations.
After realizing how cool these were, I collected all the ones they had. for about $3 each. A look at eBay finds asking prices about $100-200 apiece.
More buttons and knobs than I could even think what to do with!
Just needed to reverse the serial protocol… and find enough serial ports. Never managed to happen what with needing to graduate from school and all.
Get all devices running at once. Write a server program thattaks to them and them exposes to the network as OSC controls. Use them to blink lights and twiddle noises.
- The LPFKs and knob boxes. Six of one and seven of the other.
- Four InsideOut Networks EdgePort/4 USB to serial adapters (each having four ports)
- one Raspberry Pi
- one USB hub with enough juice in the charge ports to power the Raspberry Pi autophagically.
The peripherals have a single mini-DIN-8 connector. Here’s what IBM documentation has to say about this mini-DIN 8 connector:
(from this document on page 156)
However, this document seems to treat the LPFK and knobs as having the same interface as the tablets, and a pinout listed later in the same dicument disagreed about which pins were to power the tablet.
So I took apart the device and looked at the PC board. I found that the power and power return were routed to pins 3 and both grounds connected to pins 1 and 2. So the first diagram is correct. And the “selective reset” appears to be unused — only
Vcc, the two grounds,
Rx were connected to anything for either the LPFK or the knobs.
Here’s I wired the cables for these: a converter from DE-9 to this port:
Note that the cable carries both power and signal. I got a bix boxy kind of DE9 connector so I injected power by this somewhat horrifying method:
Yes, it’s not really a great to use a TS connector to provide power. But it is literally the smallest jack I could find.
Power came from a a 5V USB power supply the form of phone chargers via a series of horrible splitter cables.
Note that the diameter of the plug hole on the devices is a little smaller than the common mini-DIN shroud, so these are held together with hod glue and heat shrink on the DIN end end.
Then I realized that I would be in for massive headaches if I didn’t have a test rig for the wires, so I got some mating connectors:
Despite making the careful wiring diagram above, I had about a 40% rate of something being wrong with a cable on the first try. A short, a bad solder joint, a swapped pair of colors, and a fun one was getting the DIN connector rotated by one step.
Eventually, though I had as many cables as I had devices.
(serial.jpg)[Wow Such connection Very RS-232 So serial Wow]
The Linux driver for the EdgePort automatically detected on Raspbian, which came with the requisite kernel module, which was a blessing. No OS X drivers for the EdgePorts. However, Debian sees fit to not distribute the firmware files needed by the Edgeport, because they are the masters of GPL rules lawyering1. Strangely, the firmware is not even included in the
non-free/firmware-linux-non-free package. As a result you see startup messages like:
To fix this, you need to get the firmware files. I grabbed them from Ubuntu (note that Ubuntu distro itself doesn’t support the Pi):
1 2 3 4 5
Whee, looks like that worked. The fast blinking red lights in the Edgeports became slow blinking green lights.
Talking to the thing
Apparently the LPFK protocol is supposed to be simple. Let’s find a terminal emulator that works in hexdump mode.
minicom will output in hex, but
cutecom will do both input and output in hex. Okay.
Now, the docs from IBM say 9600/8N1, but monkey typing doesn’t produce any response, and monkey button pushing doesn’t produce any activity.
The knob boxes are going to be more of a challenge, if I recall.
(apparently Digi used some GPL code in producing the firmware, so in Debian’s view Digi is not allowed to distribute the firmware without making their source available, therefore Debian won’t distribute the file that Digi has contributed to the Linux kernel.)↩