VT72 keyboard

Making a DEC LK05-A keyboard — Micro Switch 112SD12-1, Hall effect, 112 keys and 12 lamps, built late 1976 for a VT72 newsroom terminal — work on a modern computer. This one is the German QWERTZ variant, with the sixteen composition keys above the top row still carrying their typesetting commands ($ZS44A, $QB, $G4,5.10) on the front faces.

The keyboard turns out to send negative-true ASCII — invert the byte and a8 b4 c0 be read back as W K ? A — with an active-high strobe about 40 µs wide. Some keys send a different code on release. No code table survives, so the job is to build one.

What is here

interface.html	What the DEC print set says about the connector, the signals, the lamps and the software. Read this first. Also published at https://claude.ai/code/artifact/dcfda550-11ed-4c28-91d5-c8a94f0799de
WIRING.md	The pin map, in prose
SWITCHES.md	How to test a Hall key switch, cheapest test first
wiring-guide.html	The same wiring, one step at a time, drawn from underneath, for either board
serve.sh	Puts both pages on the network for a tablet at the bench
firmware/	RP2040 firmware: a nine-channel transition recorder with twelve lamp outputs
tools/	Host tool: probe the signals, record the key codes, find the lamps
data/	What the tools write: config.json, keymap.json, leds.json

The rig

The firmware assumes nothing about the keyboard's timing. It records every change on the nine input lines with the time it happened and streams the changes as text; strobe polarity, pulse width, and the code a key produces are all worked out on the host. That way the rig can be pointed at a keyboard whose timing diagram nobody has.

cd firmware
cmake -S . -B build -G Ninja
ninja -C build

Requires pico-sdk at ~/Development/privat/pico-sdk. Add -DPICOTOOL_FORCE_FETCH_FROM_GIT=1 to the cmake line if the picotool on PATH is older than the SDK wants. Flash build/vt72_probe.uf2.

The rig runs on an official Pico or on a USB-C RP2040 clone whose header runs GP0–GP17 down one side and GP18–GP25 plus the analogue inputs up the other. The pin map is laid out for the clone at the bench — data on GP10–GP17 facing the card edge contact for contact, strobe on GP9, lamps on GP0–GP8 and GP26–GP28 — and every one of those pins exists on both boards, so the same binary serves either. What differs is where they sit, which the wiring aid switches with its Board button.

Bringing it up

pip install pyserial                 # optional; the tool falls back to the raw tty

python3 tools/vt72.py probe          # press keys, watch what the signals do
python3 tools/vt72.py leds           # which drive line lights which lamp
python3 tools/vt72.py leds --anim 2  # leave a sweep running
python3 tools/vt72.py leds --low     # try the other lamp polarity
python3 tools/vt72.py scan           # walk the keyboard, record every code
python3 tools/vt72.py monitor        # decode presses against what was recorded
python3 tools/vt72.py raw            # the transition stream, unprocessed
python3 tools/test_vt72.py           # smoke tests against a synthetic keyboard

probe reports the resting level of all nine lines, picks out the line that pulses once per keypress, states its polarity and pulse width, and writes data/config.json. Everything after that reads its polarity from there.

scan walks tools/layout.py one key at a time: press, release, Enter. It records the make code and the break code where there is one, saves after every key, and at the end reports duplicate codes and any key whose make/break behaviour disagrees with the print set — which lists exactly seventeen keys that should send both, and the tool knows which.

The layout table is transcribed from a photograph of worn 1976 keycaps and is a starting point: 115 switch positions where DEC counted 112 keys. Correct it and scan follows the change.

When a key gives nothing

scan separates three outcomes, and they mean different things.

Silent, as a modifier should be. SHIFT, CTRL and CAPS LOCK are folded into the code that follows, so they send nothing of their own. A ? arriving from the ß key is the shift working.

Data moved, no strobe. The encoder put a code on the lines and held the strobe back. Micro Switch suppress the strobe when more than one key is down, so this is what a second key looks like — either a real one still held, or a sensor that has drifted far enough to read as pressed at rest. Watch the resting lines with raw and nothing touched: a line that changes on its own names the culprit.

Nothing on any line. The sensor never registered. Record every one of these, then look at where they sit:

• Scattered across the board — individual Hall sensors, the usual failure in a fifty-year-old SD-series keyboard. Also worth ruling out a sticky plunger that no longer travels far enough. SWITCHES.md has the bench tests, starting with the ones that need no instruments.
• Clustered in a row or column — a scan line, not the switches. The PCB carries a silkscreened node number beside every switch (75, 77, 137, 139, 96 … visible under the missing keycaps); if the dead keys share one, the fault is a broken trace or a dead driver, and one repair fixes all of them.

Two checks that cost nothing: P in the firmware switches the input pulls, so a data line that follows the pull is floating rather than driven; and the lamps, once lit, prove the connector's other twelve lines are sound.

Still open

• The function pad codes, which fall outside the printable range, and the seventeen keys the print set says send make and break
• Which keys are dead, and whether they cluster
• Whether the encoder still works at all. If no code ever appears, the suspect is the unmarked 28-pin ceramic MOS device, which is unobtainable; the fallback is abandoning the encoder and reading the Hall sensors off the numbered pads on the PCB.

Sources

DEC VT72 field maintenance print sets MP00610 and MP00615, the second of which carries engineering specification M8656-0-8 with the connector pinning. Micro Switch SD series at Telcontar's keyboard knowledgebase, which lists a 112SD12-2 with no attribution — this 112SD12-1 is a DEC LK05-A.