John Tsiombikas nuclear@mutantstargoat.com
18 November 2023
A few years ago, I wrote a tetris game for ANSI-compatible terminals called
termtris. My original
inspiration for termtris, was the original tetris game written by Alexey
Pajitnov on a soviet PDP-11 clone (the Электроника-60), using a VT100-compatible
terminal for input and output. Similar to the original tetris, I used pairs of
square brackets for the tetris blocks ([]).
Here's the original tetris, side by side with my termtris game in monochrome
mode (termtris also supports color, on compatible terminals).
Recently I've been experimenting with custom font loading (or down-line loaded fonts as DEC calls them) on my VT420, and decided to use that feature for graphical tetris blocks in termtris. The initial implementation went smoothly, and I made a short video about it.
Unfortunately the format of soft-fonts for DEC terminals, and to a certain extend the DECDLD command to load them, is different between the VT220, the VT320, and the VT420/VT520 (I'll just refer to the whole series of terminals by the base model, so when I say VT220 I'm really talking about all terminals in the VT200-series of models, and so on for the rest). So, in order to support all of them, termtris needs three sets of font data and code paths, of which I was able to test only one. Predictably, the only version of soft-fonts which was working correctly at this stage, was the one for the VT420.
With the help of avid terminal collector Olafs Bāliņš I verified that on VT220, termtris failed entirely to load the font, while on an HP terminal with VT320-style soft-font support it did something, but looked wrong.
I managed to debug and fix the VT220 issue by discovering that MAME (the coin-op emulator) is also able to emulate some terminals, including the VT240! (I also used mame to add VT52 support and fix a VT100 glitch). Unfortunatly however, MAME's support for the VT320 was incomplete. I managed to improve the VT320 soft-fonts by going back and forth sending Olafs new code to test on his HP terminal, but by the end it still looked wrong, and as I was running out of glaring bugs to fix, I had a suspicion that the HP 700/60 doesn't display the soft-font entirely correctly as a VT320 would. And so not wanting to keep chasing red herrings while remote debugging over email, I decided to stop until I could get a chance to see how it runs on a real VT320.
80s terminals don't grow on trees, but as luck would have it I remembered a friend of mine has two non-functional terminals, a VT220 and a VT320, which he acquired ages ago when a university was throwing them away. He was meaning to troubleshoot and fix them, but apparently never did, and they've been rotting in a closet ever since. So I offered to come pick the VT320 up and try to fix it, hoping to be able to use it to debug the soft-font issue if I did.
When I got the terminal home, the terminal actually started up, but then it displayed a keyboard error message and hang there useless. The keyboard itself, an LK201, lit up all its LEDs in mute protest.
This could be some fault with the terminal's keyboard port, the keyboard itself, or the cable (which I didn't even have, and used a telephone handset cable since it's just a 4-pin RJ10 at both ends). The cable buzzed out just fine on the multimeter in continuity mode, so the next easiest thing to check was to connect the LK401 keyboard of my VT420 to the VT320, and see if that works; it did. Turns out the terminal itself works just fine, it was the keyboard which had issues.
Of course first thing I did was to run termtris, and it worked perfectly. The over-email bug hunt fixed all remaining issues with my VT320 soft-fonts, and it was just the HP terminal which failed to display them correctly at the end.
But I had to figure out what's wrong with the keyboard.
When I got it, the spacebar was stuck down pretty well; it took some effort to dislodge it, and got stuck again when pressing it. The keyboard frame was fouling the spacebar stabilizer somehow, and I had to pull it off and reseat it to make it work properly. Unfortunately that didn't clear the error, nor did hitting it repeatedly help at all.
Incidentally, the spacebar doesn't fit visually with the profile of the rest of the keys. That can't be right... Is this how it's supposed to be, or did someone replace it with the wrong spacebar at some point in this terminal's history?
I disassembled the keyboard for further examination. The board looked and smelled fine (the smell test is a very important part of any troubleshooting effort). I then pulled the key matrix membranes from the controller board, and connected just the controller by itself to the terminal: no error!
Note: in case anyone reads this and attempts the same test, make sure to insert something non-conductive in the connectors to stop the spring fingers from sorting all the lines together.
The error going away with no membranes connected leaves only one place for the issue, the key matrix membranes themselves.
The first obvious issue after a quick inspection, was a break in one of the traces of the membrane, near one of the three connectors to the controller board.
Unfortunately at this point my neurons misfired, and remembering a similar repair I did some time ago to the touchpad connector of my wife's laptop, I attempted to see if I can solder a piece of copper foil onto the broken trace.
Predictably, this resulted in immediate melting and a hole appearing in place of the break, because obviously my wife's touchpad connector was flat-flex PCB, not melty plastic membrane with carbon traces on top. That's why I hate neural networks, you just can't rely on the output not being insane. Thankfully the damage was pretty much localized to the pre-existing gap of the trace, so no harm done other than making the repair a bit more difficult.
The second attempt was much more successful. I jumped the new hole with a piece of wire and glued it onto the traces on either side with blobs of conductive paint.
While fixing the broken membrane trace was obviously necessary to end up with a functional keyboard, I was sure from the start that it would not fix the main issue that prevented the terminal from starting up, because if it works without any key matrix at all, not having a single row or column connected won't stop it from working either.
I've read online that this error can sometimes be caused by a stuck key, so I needed to find if that was indeed the issue with this keyboard, and if so, which key was stuck. At this stage I had already forgotten entirely about the initially stuck spacebar (see discussion of the shortcomings of neural networks above), which after all I had fixed and was no longer stuck pressed down.
To methodically test every key on the keyboard, I decided to solder ribbon cables to the controller PCB at the three connectors of the key matrix, and stick them to a breadboard for easy continuity tests.
Going through the LK201 schematics, I made a list of all the matrix row/column combinations, which key corresponds to each, and which pins on the membrane connectors to probe for each key.
After going through continuity testing of the corresponding rows and columns for each key, I discovered that every key worked perfectly, except one pair of row and column lines, which were always connected without having to press the corresponding key... the spacebar. At least this process also verified that my membrane trace repair worked.
Right, so if the spacebar row and column are always connected, even when the key itself is not pressed (or in fact removed), there's obviously something wrong between the membranes. Maybe that spacebar was stuck pressed for the last decade or more, and the membranes stuck together. So I would have to disassemble further to remove and repair the key matrix membranes, which is easier said than done.
Some people were making the argument recently, that IBM took the idea for the inverted-T arrow keys of the Model-M's layout, from the LK201 keyboard (which was also used with the VT220). I guess IBM wasn't satisfied with borrowing only good ideas from the LK201, because apparently the Model-M construction method of holding together the key stems and the membranes with a forest of plastic rivets was also an LK201 innovation...
Having swore I'm not going to do any more bolt-modding unless absolutely necessary, I tried to find an easy way out. Thankfully a combination of circuimstances made it possible to attempt a fix without breaking all the rivets to completely disassemble the rest of the keyboard:
These factors allowed me to break only the rivets holding the spacebar frame to the matrix, and have a hope of re-attaching it with hot-glue without having to perform a bolt-mod for the n-th time.
When I did remove the spacebar frame, I was able to insert a flat tool between the membranes, which were indeed stuck together, and with some gentle prying I managed to pull them apart once again.
The final reassembly with hot glue seemed to go as planned and the frame was holding solidly to the neighboring plastic frames and the bottom of the membrane covering mat.
After putting the keyboard back together I connected it to the VT320 once more to test, and no error! The terminal started up, all startup tests passed, and getty welcomed me with a 'login:' prompt.
One final minor issue, was that the hot glue was interfering marginally with the spacebar, making it hard to press. So I used an xacto knife to shave a few millimeters off the back side of the keycap, after which it worked perfectly.
To celebrate the occasion, I decided to write this blog post on the VT320. But
for some reason it refuses to remap ~ to ESC, and having to press ctrl-[ all
the time to exit insert mode in vim becomes annoying very quickly. So I wrote it
on the VT420 instead ... close enough; also I prefer the green phosphor.
