Curiouser and curiouser

Basic Function

I’ve been delving more into the wire protocol the VT100 keyboard uses to talk to the terminal. As you may recall from my first post in the series, communication is bidirectional, asynchronous serial over a single wire. The protocol uses three reference voltage levels (0, 6, and 12 volts) and makes each end sample its own output to see who’s talking, which is… well, it seems weird to me, but I’m sure they had a good reason. So that leaves the actual signaling. How did they send the clock and data using those levels?

Well, it turns out that they used PWM (pulse width modulation). Each bit sent across the wire is encoded on top of 16 clock cycles. The exact number 16 is dictated by the UARTs the designers chose, the Western Digital TR1865. The TR1865 expects a square wave clock signal, and samples its serial input on the falling edge of the pulse for sixteen clock cycles per bit. The DEC engineers cleverly decided to use PWM to change the duty cycle of the clock wave form between 25% and 75%, and feed the same signal to the clock input and serial input of the UART. The serial data can then be separated from the clock signal with a very simple RC circuit and a comparator.

From the Technical Manual, (pp. 4-37 – 4-38):

The keyboard requires a clock for its operation and is provided with one by the terminal controller side of the interface. To transmit a clock independently of data on the same wire, the terminal side of the interface generates a clock signal within which data is encoded as a pulse width modulation. The terminal circuit produces a 75 percent high pulse width output for the mark state. Data transmission causes the clock output to switch between 75 and 25 percent pulse width (duty cycle). […] The negative transition of each output pulse occurs at the clock interval regardless of the presence of data. This transition is therefore the reference point for the keyboard clock at the receiving end.

[…]

The keyboard recovers the modulated clock signal sent by the terminal but must also separate the data from the clock. […] Data is extracted from the combined clock-data by a simple resistor-capacitor filter on one input to a comparator. The other comparator input is referred to one-half the power supply. Because the duty cycle of incoming data is either 1/4 or 3/4, the capacitor charges to that proportion of the supply voltage over the 16 clock periods of each bit. The comparator switches when the capacitor voltage rises or falls past the reference value.

So, the combination of the duty cycle and line voltage give the complete set of four states, as shown in the following two figures. I am truly amazed.

VT100 Keyboard Protocol States

Keyboard Status

There’s something else I consider odd, too. The keyboard has six status LEDs and a speaker in it. The speaker is used for beeps and keyclicks, the LEDs show various status bits. All this state is controlled by the terminal, not the keyboard. In fact, the keyboard doesn’t even latch the status data outside of the UART. Instead, the status is sent by the terminal to the keyboard every 1.28 ms (!!!!). The UART in the keyboard receives this data, puts it out on the 8-bit parallel UART output, and drives the LEDs and speaker directly through a pair of SN7406 drivers. Think of it as DRAM vs. SRAM, if it helps; the state is constantly being refreshed.

That means that my VT100 to USB translator is going to have to do the same thing. It’s going to be a pretty busy little box.


EDIT: An earlier version of this post said the keyboard status was updated every 7.945 µs. This is incorrect. 7.945 µs is the period of the clock signal, not the keyboard status update refresh.

It’s Harder Than It Looks

I’ve been delving into the internals of the VT100, and it’s an impressive piece of engineering. The terminal itself is a fairly sophisticated computer in its own right, built around an Intel 8085 processor. You might expect the keyboard to be a simple ASCII affair with a 7-bit interface, which was popular at the time, but it’s not. Instead, it’s a serial interface, like the later PC, AT and PS/2 keyboards we’re all familiar with. Unlike the AT or PS/2 keyboards, though, the VT100 keyboard is bi-directional. The terminal manages the state of the LEDs and bell on the keyboard by sending status words to it.

Not too hard, right? It kind of sounds like SPI, no big deal. But wait!

The DEC engineers, bless their hearts, decided that using three wires for serial data (clock, rxd, txd) was wasteful. Why have separate receive and transmit lines when you can combine them?

Still not too hard, right? I mean that sounds a bit like I2C, just have a master/slave deal. But wait!

“Two wires, that’s still wasteful,” said the engineers. Why not combine data and clock onto one transmission line? Oh, and this master/slave business, that’s unnecessary, let’s allow both sides to talk simultaneously. So, that’s what they did. The keyboard is asynchronous, bi-directional, and full duplex over one transmission line.

The VT100 keyboard connector is a 1/4″ TRS (“Tip-Ring-Sleeve”) connector with three physical lines: Ground, +12V, and Data. Both sides can communicate at any time over that data line, there is never any ambiguity. Here’s how the “VT100 Technical Manual” (1982, p. 4-34) describes it:

The terminal sends data and clock to the keyboard; the keyboard sends data only. Transmission is asynchronous, full duplex, serial, 8-bit data with one start bit and one stop bit over a single signal line. Four states can exist on the line, representing the two signal states from each end of the line.

Both signals may coexist on the same wire, originate at opposite ends, and simultaneously communicate provided that sensing resistors are put at each end. The interface works by observing the voltage variations on its input (across the sensing resistor) while biasing the input in the opposite direction with its own output signals so that only input variations can cause enough change to exceed the threshold of detection. […]

If one side of the line is at +12 volts and the other is at ground, then by Ohm’s Law, the center of the two equal resistors will be at V/2 = 6 volts. If both sides are at 0 or 12, the center will be identically at 0 or 12. Thus the signal line can either have no current flow but with the junction of the two resistors at either 0 or 12 volts, or the junction can be at 6 volts with current flow to the left or to the right, thereby representing the four required states.

Wow!

So, this is what I’ve gotten myself into. Luckily, the “VT100 Technical Manual” has exhaustive details about the interface and how it works. Over the next few days I’ll be posting more about it, as well as building a few test circuits to interface that 4-state signal to a 5V device.

RetroChallenge 2013

Egads, is it really July already? It’s time for Summer Retrochallenge 2013!

Actually, I’ve left it right up to the last minute this year. So sorry! I was this close to just giving it a pass, but then a project idea literally figuratively fell into my lap.

Long story short, a couple of weeks ago I bought a VT100 keyboard to complete a keyboard-less VT100 terminal I’ve been trying to get working. The keyboard just arrived at my home, but the rest of the terminal is down at my storage. I’m far too lazy to go get it, especially in this heat. Solution: a way to plug the VT100 keyboard into my Mac and use it without the terminal!

Here is my beautifully artistic sketch of the idea:

fig. 1: A VT100 to USB Converter
fig. 1: A VT100 to USB Converter

The little box will hold a Teensy development board. The VT100 keyboard will plug into the box through a standard 1/4″ TRS jack, and a USB cable will trail out the other side.

It would be nice to supply power directly from USB, but unfortunately the VT100 keyboard is a +12V device so I’ll also need a +12V power brick to feed it, and some logic external to the Teensy to interface to it. But that’s part of the challenge, right?

This should be fun!