deskthority

I finally got to doing something with another of these old boards. The VT100 isn't a particularly nice keyboard; the VT52 had much more personality. I never used a DEC terminal as my daily one. But VT100s were everywhere, so the nostalgia value is still pretty high.

The hardware protocol is also very interesting. It's a 1/4" audio jack with three wires: +12, ground, and signal. The signal is bi-directional serial; both ways on the same wire, sometimes at the same time. This requires some open-collector drivers to compose and analog comparators to decompose.

It's all in the DEC schematics, which have been preserved. I just borrowed the relevant circuit straight — with the exact same resistor values.
The very same borrowing was done by somebody's earlier effort and featured on Hackaday.

But they were concerned to replicate the timing and so their circuit has a 1MHz crystal and a classic 40-pin CMOS UART.

The UARTs used then and inside the AVR are designed to deal with small variations in timing. They take 16 samples and average. So there's a fair amount of wiggle-room. In fact, a complementary effort to build an interface from a modern USB keyboard to a VT100 terminal as an Arduino sketch just set the MCU's UART to 7867 baud, ignoring the clock PWM.

For my converter, I set a couple of the otherwise unused timers to generate 4µs and 8µs PWM. And set the UART's baud rate register to match. Since it all ultimately comes from the same I/O clock, everything should stay in sync.

It ends up looking like this: The signals are:

1. receive
2. transmit
3. clock
4. combined signal

and the serial ones decode just fine.

Zooming in, each serial bit takes 16 clock periods. And PWM has 75% duty-cycle for mark and 25% for space. For now the firmware in my fork.

And the hardware will, as always, need some cleaning up for putting into more permanent form. ETA: Perma-proto version.

Very cool. Interesting background info too. I have a VT100 that I brute forced with a Teensy - it's nice to see approaches that actually keep the boards intact!

The Qume (ITT subsidary) QVT-101 was a low-cost green screen ASCII (dumb) terminal from the mid-80's. It competed against the likes of the ADM-3A in the sub-$500 market. For ANSI (smart) terminals, in particular with VT100 compatibility, there were other higher-end QVT models. I believe these capabilities eventually merged down with the QVT-103.
Even though it could not emulate a VT100, there were a number of things about the keyboard copied from the VT100, sometimes for no obvious (to me) gain. Most apparent is the layout, which other than a smaller Setup key and adding a couple of keys around the arrows, is the same. There are, of course, no LEDs, to keep it cheaper.

It has membrane switches with spring sliders. Somewhat surprisingly, most of the caps are thin double-shot. I believe that further cost cutting in the QVT-102 eliminated these for printed caps.
I doubt that they were ever very good, but a little bit of corrosion on the PCB below the membrane now makes the switches very unreliable. Cleaning would mean removing the slider/spring housings, which are held in by rivets. While it might be possible to remove these without damage, I am not sure it's worth it.

The pinout and basics of the signaling are in kbdbabel. The schematic is in Bitsavers. The schematic for the QVT-102 is also there and they are evidently more or less the same.

There are also some detailed pictures of a disassembled QVT-102. Here again, the physical circuit layout is very similar.
The QVT-102 firmware is also there. Using this, it is possible to confirm the timing and the details of the protocol encoding. For example, here are the most important parts of scanning and transmitting.

• B5 sends a byte; the C3 transmit loop is 7 cycles long. At 6MHz, that gives a width of 17.5µs, or around 57kbps.
• A4 loads the row number from the high nibble of R6 into the 4015 mux.
• CE sets the column number from the low nibble of R6 into P1 and P2.

The connector on the keyboard is a 4P4C RJ jack. The coiled cable that comes with the keyboard is crossover, like on a telephone handset, so the pins need to be reversed.

The signals are GND, +12V, PE, and SIG. Other than the connector type and the chassis ground, this is reminiscent of the VT100, with +12V power required and not just for a regulator, because the bidirectional data line is idle high at around 10-12V.

Although there are no LEDs, terminal to keyboard is needed to control the buzzer.

The circuit for combining the input and output signals is less clever than the DEC one without aiming for simultaneity: an open-collector inverter for pulling down output and a PNP transistor to compare input voltage and drive another inverter. A converter can just borrow this to connect two GPIOs.
Note how the RJ colors are reversed to match with the cable's transposition.

These (inverted) TTL level signals are also compatible with a logic analyzer and a simple Sigrok decoder for the protocol confirms the serial encoding.
The long pulse to grab the bus as the start means that the start bit proper has the same polarity as idle, so it is not possible to use a UART to do this encoding/decoding. It has to be bit-banged.

As noted in the disassembly above, the scan code is just four bits of column and three bits of row right off the schematic.

But note how the schematic calls out that the matrix is VT100 compatible. This is true; compare with the VT100 Technical Manual. Here is where I am not sure what the point is. The scan codes aren't the same, and are, in any case, internal to the keyboard. Is it just that the two kinds of terminals then have the same ghosting behavior, since there are no diodes?

A normal key press consists of two bytes. The first is the scan code, which cannot have the eighth bit set. The second always has 80 set and gives the state of the Shift (10) and Ctrl (20) keys. The low bits of this second byte distinguish initial key press (4) from auto-repeat.

The remaining special cases are 81 at power-on and 82 for Caps Lock press. These do not have a preceding scan code byte.

There are no up transitions. The two shift keys cannot be distinguished. It is not possible to enlist other keys are shifts. So, all in all, implementation of a USB keyboard has to be pretty minimal.

The plus is important: the QVT-101+ is a substantially different keyboard.

• The overall layout is different.
• It has a distinctive row of round function keys.
• There are a few even more distinctive Necco wafer colored action keys.
• The switches are rubber dome.
• The function key actuators are free-floating and held in place over the PCB contacts by the face plate.

The Maintenance Guide is in Bitsavers and the schematic shows that, while it is still 4P4C RJ, it is now +5V and the chassis ground has been replaced by a STROBE input.

The SIGNAL is still bidirectional, but I am not sure what the to keyboard direction does. Figuring that out may require getting the firmware off the controller. Caps Lock and its LED are handled locally by the keyboard, with state reports to the terminal.

A converter is simpler, with no need for additional voltages or level shifting.
As expected with a strobe plus one data line, the communications is synchronous serial. The terminal evidently needs to send the stobe periodically and the keyboard will pull down the signal line when it has something to send.

There are four special keys: Ctrl, two Shifts, and Caps Lock. Regular keys send a unique scan code on key press and nothing on key release.
Every couple seconds, the keyboard sends a two-byte report with the current state of shifts.
These shift keys also send both up and down transitions right away, using more codes with the low nibble zero. And, finally, there is a special code for auto-repeat if a non-shift key is held down.

The ones I have seen:

• 10 Shift up (either one or both)
• 30 Ctrl up or Caps Lock off
• 40 shift state follows: 10 Caps, 20 Ctrl, 40 left Shift, 80 right Shift
• 50 left Shift down
• 70 Ctrl up when Caps Lock on
• 90 right Shift down
• B0 Ctrl down
• C0 auto repeat last key
• D0 both Shift keys down (magic key!)
• F0 Ctrl down when Caps lock on

Since Funct is a regular key, the resultant USB keyboard is pretty minimal.