The VT320 came with an LK201 keyboard, although it works quite happily with an LK401, which comes with the newer VT420. I haven't had much luck deciphering the initial conversation that takes place between the VT320 and an LK201 just by running the VT320 firmware on my emulator. All I know so far is that the terminal expects to see four bytes when the keyboard powers up. (That last sentence sounds odd, because the keyboard obviously powers up at the same time as the terminal. What I mean is that the keyboard has its own microcontroller, a Motorola MC68HC05 and it does some of its own tests before talking to the terminal).
Dan McMahill has produced a great document which explains the LK201 Keyboard Interface. That helped explain what the first four bytes should be, as well as explaining the characteristics of the serial link between the terminal and the keyboard.
I've now hacked into the keyboard wire and tapped off the data connections into a 25-way D-type connector, so I can watch the initial conversation on my shiny ARC Protocol Analyser. The conversation below is between a VT320 with Rev 1.2 firmware and an LK201 with Rev D01 firmware. I don't have any timing information for this, so it is occasionally unclear which byte came first when one from each end is shown vertically aligned. I believe that where two bytes are vertically aligned, the keyboard one was sent first. That makes more sense, though I haven't proved it.
All bytes are shown in hex. VT = terminal, KB = keyboard. VT 55 11 8F 13 82 11 8F 13 83 11 8F 13 84 11 8F 13 85 11 8F 13 84 KB 01 00 00 00 B6 BA VT 11 8F 13 85 11 8F 13 84 11 8F 13 85 11 8F 13 88 11 8F 13 89 11 8F 13 90 KB VT FD 0A 80 12 81 1A 80 3A 81 42 81 4A 82 5A 82 62 82 6A 82 72 82 KB 01 00 00 00 BA BA BA BA BA BA BA BA BA VT A2 78 64 9E 7A 64 9E 7C 64 9E 99 E3 11 8F 13 80 11 8E 13 81 FD KB BA BA 01 00 00 VT 0A 80 12 81 1A 80 3A 81 42 81 4A 82 5A 82 62 82 6A 82 72 82 A2 78 64 KB 00 BA BA BA BA BA BA BA BA BA BA BA VT 9E 7A 64 9E 7C 64 9E 99 E3 11 8F 13 80 A7 11 8E 13 81 11 8F 13 80 KB
All of the above conversation takes place during the terminal's POST (Power-on Self Test) before a single key has been pressed! However, it is repetitive and I've decoded it with the help of Dan's document and correspondence with him.
When the VT sends 13 or 11 followed by one byte,
it is turning one or
more of the keyboard LEDs on or off, respectively. Having disregarded these,
the next biggest chunk of commands and responses are to do with setting up
the modes of certain keyboard divisions, ie. whether the keyboard should
report key up and/or key down transitions and whether auto-repeat is enabled.
div mm rr
0A 80 -> 0 0001 01 0 100000 00 Set keyboard division 1 (letter keys)
to autodown mode and use autorepeat
register 0.
12 81 -> 0 0010 01 0 100000 01 Div 2 (numeric keypad), autodown, reg 1
1A 80 -> 0 0011 01 0 100000 00 Div 3 (Delete key), autodown, reg 0
3A 81 -> 0 0111 01 0 100000 00 Div 7 (left/right arrows), autodown, reg 0
42 81 -> 0 1000 01 0 100000 01 Div 8 (up/down arrows), autodown, reg 1
4A 82 -> 0 1001 01 0 100000 10 Div 9 (E1-E6), autodown, reg 2
5A 82 -> 0 1011 01 0 100000 10 Div 11 (F6-F10), autodown, reg 2
62 82 -> 0 1100 01 0 100000 10 Div 12 (F11-F14), autodown, reg 2
6A 82 -> 0 1101 01 0 100000 10 Div 13 (Help,Do), autodown, reg 2
72 82 -> 0 1110 01 0 100000 10 Div 14 (F17-F20), autodown, reg 2
A2 -> 1 0100 01 0 Div 4 (Tab key), autodown, default repeat
The keyboard responds with BA to acknowledge these commands.
The autorepeat rate in the four available registers is programmed by the
next group of commands, which each have three bytes.
rr timeout rate
78 64 9E -> 01111 00 0 0 1100100 1 0011110
7A 64 9E -> 01111 01 0 0 1100100 1 0011110
7C 64 9E -> 01111 10 0 0 1100100 1 0011110
Autorepeat registers 0, 1 and 2 are programmed to the same settings: timeout of 500ms before starting to repeat (100 * 5ms) and 30 repeats per second.
I recorded the following conversation of the startup sequence while holding
down the left shift key. The keyboard changes its POST results string from
01 00 00 00 to one that incorporates the keycode of the key that
is held down, in this case, 01 00 3D AE. When the terminal sees this,
it resets the terminal several times in the hope that the key will be lifted.
If it isn't lifted, the terminal still performs the full setup on the keyboard,
but will repeat the setup when the keyboard reports that everything is OK again.
All bytes are shown in hex. VT = terminal, KB = keyboard. VT 55 11 8F 13 82 11 8F 13 83 11 8F 13 84 11 8F 13 85 11 8F 13 84 KB 01 00 3D AE VT 11 8F 13 85 11 8F 13 84 11 8F 13 85 11 8F 13 88 11 8F 13 89 11 8F 13 90 KB VT FD FD FD 0A 80 12 81 1A 80 3A 81 42 81 4A 82 KB 01 00 3D AE 01 00 3D AE 01 00 3D AE VT 5A 82 62 82 6A 82 72 82 A2 78 64 9E 7A 64 9E 7C 64 9E 99 E3 11 8F 13 80 KB VT 11 8E 13 81 FD 0A 80 12 81 1A 80 3A 81 42 81 4A 82 5A 82 62 82 KB VT 6A 82 72 82 A2 78 64 9E 7A 64 9E 7C 64 9E 99 E3 11 8F 13 80 0A 80 12 81 KB VT 1A 80 3A 81 42 81 4A 82 5A 82 62 82 6A 82 72 82 A2 78 64 9E 7A 64 9E 7C KB VT 64 9E 99 E3 11 8F 13 80 11 8E 13 81 11 8F 13 80 KB
While typing this in I notice that I've not recorded the keyboard's
acknowledgement of mode changes (the single byte BA) but you
can mentally insert them in the same positions as the first conversation.
When the stuck key is released, the keyboard immediately sends the POST results to report everything is OK and the terminal reciprocates by performing the autorepeat setups.
All bytes are shown in hex. VT = terminal, KB = keyboard. VT 0A 80 12 81 1A 80 3A 81 42 81 4A 82 5A 82 62 82 6A 82 72 82 A2 KB 01 00 00 00 BA BA BA BA BA BA BA BA BA VT 78 64 9E 7A 64 9E 7C 64 9E 99 E3 11 8F 13 80 KB BA BA