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.
Code: Select all
00A3 : FE " "  mov a,r6
00A4 : 88 70 " p"  orl bus,#070H
00A6 : D2 AA " "  jb6 L00AA
00A8 : 98 BF " "  anl bus,#0BFH
00AA : B2 AE " "  jb5 L00AE
00AC : 98 DF " "  anl bus,#0DFH
00AE : 92 B2 " "  jb4 L00B2
00B0 : 98 EF " "  anl bus,#0EFH
00B2 : 93 " "  retr
00B3 : 23 01 "# "  mov a,#001H
00B5 : D3 80 " "  xrl a,#080H
00B7 : 35 "5"  dis tcnti
00B8 : 15 " "  dis i
00B9 : 9A 7F " "  anl p2,#07FH
00BB : B9 1F " "  mov r1,#01FH
00BD : E9 BD " "  djnz r1,L00BD
00BF : B9 0A " "  mov r1,#00AH
00C1 : 97 " "  clr c
00C2 : A7 " "  cpl c
00C3 : 00 " "  nop
00C4 : 00 " "  nop
00C5 : 67 "g"  rrc a
00C6 : 3A ":"  outl p2,a
00C7 : E9 C3 " "  djnz r1,L00C3
00C9 : 25 "%"  en tcnti
00CA : 16 07 " "  jtf L0007
00CC : 05 " "  en i
00CD : 93 " "  retr
00CE : 89 FF " "  orl p1,#0FFH
00D0 : 8A FF " "  orl p2,#0FFH
00D2 : FE " "  mov a,r6
00D3 : 53 07 "S "  anl a,#007H
00D5 : E3 " "  movp3 a,@a
00D6 : 2E "."  xch a,r6
00D7 : 72 DD "r "  jb3 L00DD
00D9 : 2E "."  xch a,r6
00DA : 39 "9"  outl p1,a
00DB : 04 E0 " "  jmp L00E0
- 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.
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.