Most switches on my board are 4A3S (scan type, in contrast to snuci's above
which uses pulse type 4A3B). The exceptions are the Caps lock, which is 5A3S (it
physically stays down until you press it again to release it) and the bigger
keys with a passive support "switch", these use 4A1S instead, which has less
spring resistance.

Here is the board, there are many more better photos of the similar boards in
the threads linked to above (the cable is hardly original, I think the wiring
matches a bidirectional IBM PC parallel port): Spoiler: I was happy to find that
the PCB is single sided, so it is easy to read, and I made a diagram of the
whole thing (there may be errors, of course, and also it is a bit messy as I
just drew it as I went along "reading" the PCB and I haven't cleaned it up
afterwards). Here it is, minus the switch matrix: Spoiler: Quick summary of the
schematics: the controller is an 8048 and it buffers its output with a pair of
74368 hex inverting buffers (three of those gates are also used as an
oscillator). Then a 74154 demultiplexer is used to scan the switches (I used the
labels "IN" and "OUT" from the viewpoint of the switches, so the demultiplexer
outputs going to the keyboard matrix are labelled "SW_IN"). The switch outputs
SW_OUT are connected directly to the "DB" port of the 8048 (with 3 exceptions,
see below). I'm guessing the funny resistors R8-R11 are spare inputs (require
desoldering of some wire jumpers).

First I wanted to see what I can get from the existing interface through the
keyboard's 25-pins connector (it's 26 pins in my diagram, but the 26th pin
doesn't exist physically). It is a parallell port with strobe. The strobe (pin
10) goes low when a key is pressed, and then an 8 bit code can be read (pins
19-25 plus 13). The code is the ASCII code for keys were this makes sense. Key
release is not signalled in any way. SHIFT/CTL keys cannot be read directly, but
SHIFT+key and CTL+key (and CAPS+key) produce codes pretty much as one would
expect.

In addition, there are 4 special output lines (pins 8,9,11,12 on the connector).
Each goes low when RPT, END-OF-MESSAGE, BREAK or the BLANK key is pressed. They
stay low for the duration of the key press and go high only when the key is
released. So the state of these four keys is fully available and independent of
everything else.

In fact, the keys RPT, END-OF-MESSAGE and BREAK are not connected to the 8048 at
all, but have their inputs hardwired to ground (=active) and the output directly
wired to the connector. (In particular, the RPT key is not handled by the
controller, it does not cause keys to repeat.) Although the BLANK key in
practice behaves the same way, it is different in hardware: it is scanned by the
8048 just like all the other keys, and it is the 8048 that drives the
corresponding line in the connector.

One could make a reasonable USB interface connecting only to the output port as
it is, perhaps using the special keys RPT, END-OF-MESSAGE, BREAK and BLANK as
modifiers. Somewhat better control of the keyboard's state is of course
desirable, but I also wanted to keep the board as untouched as possible. I ended
up to piggy back on the controller: I connected an Arduino Uno (for testing,
eventually to be replaced by a Tweeny) and let the original controller do its
thing with me spying: Spoiler: This works. I listen to the four SW_IN lines
(pins 21-24 on the 8048) and wait for the transition from 0 to 15=1111b (the
8048 scans downwards). Then I record the SW_OUT lines (pins 27--34 on the 8048),
wait for SW_IN=14, record the SW_OUT lines etc. I also timed the 8048: it holds
SW_IN fixed for roughly 150µs, except for the value 15=1111b, which is held only
for around 70µs. This is possibly because only the SHIFT and CTL keys are
connected to the SW_IN=15 line, so I can imagine that the 8048 code handling
this line is different from the rest (incidentally, the SW_IN=15 line together
with SW_OUT4, SW_OUT5, SW_OUT7 are also exposed through a 4-pole edge connector
labelled "TP", I guess for extending the keyboard with up to 3 external
switches). I also need to monitor the END-OF-MESSAGE, RPT and BREAK keys through
the 25-pins connector. In this way I can read the entire keyboard state without
interfering with the keyboard's original function, and it could still be
connected to a VIP terminal. I think I am done at this point as it now is
straight forward to make a USB interface; I just have to wait for my Teensy to
arrive in the mail.

Unfortunately, two of the keys turned out to be dead. One 4A3S (the "6&") and
one 4A1S (the ERASE). Bummer. I'll desolder them to confirm that they are indeed
dead, but as they sit in the middle of the kbd matrix and all other keys work, I
am not optimistic. I'll probably have to swap them with two keys I can live
without.