The pinout of the DE-9 is given in the user manual.
The keyboard on the D411/D461 terminal has a very similar layout. The connector is round but the pin names are the same, so it may be that the signals are the same.
An outline of the protocol is in the patent.
- The keyboard provides clock for bit-serial data in both directions.
- The terminal uses a RESET pulse to (re)start the protocol with the keyboard identifying itself.
- The keyboard triggers the IRQ line when key state changes but also periodically to give the terminal a chance.
- The terminal sends LED and buzzer state in its data to the keyboard.
- The terminal detects a lack of periodic IRQ and starts the RESET sequence until the keyboard is plugged back in.
Some experimentation was required to determine the specifics of how this was implemented.
- The initial state just from the keyboard / its pullups is RESET high, SI low, SO high, SCLK low, KBIRQ low.
- RESET is pulled down briefly and SI, SCLK, and KBIRQ go high, which are their idle states.
- SCLK then clocks 8 bits over SI for an identity of 3 for what seems like the normal American layout.
- SCLK then periodically -- about every 70ms -- clocks 7F out for no key.
- KBIRQ then goes low to signal the terminal to pick the shifted data up.
- SO should ack this by going low itself.
- SO staying high is a nack / lack of an ack and causes the keyboard byte to be repeated for a while before giving up.
- SCLK then clocks the LED and buzzer states in.
- SO should end low and then go idle high again.
- When there is a key change, 7F is replaced by its code.
- 01 standby
- 02 ALPHA LOCK
- 04 ON LINE
- 08 buzzer off
- 10 F19
- 80 F20
The default state of the keyboard after reset and before a new setting is loaded is all LEDs lit and the buzzer on. Which I guess makes for a kind of self-test, although it does make the debugging process rather louder than it might otherwise be.
Standby may not actually be a thing. The effect I see is that if the last bit into the keyboard is high, KBIRQ shuts down to low and nothing more happens until a new RESET. So I am guessing an explicit shutdown mode, though it could just be a way of detecting the lack of a terminal (but still getting power?). Anyway, I keep it low.
The key codes represent changes in key state: the same code is repeated when the key is released. This is not as good as having distinguishable break codes and results in stuck keys from time to time, but isn't so bad with an explicit reset that gets things in sync.
As far as I can tell, there is full n-key rollover.
A handful of keys on this particular keyboard are not registering. I may need to try to squirt some contact cleaner in or disassemble them; I'd appreciate advice from anyone who has done that. The key codes do not correspond directly to the matrix, so they can't be inferred from that. I imagine that these codes are compatible with some earlier keyboard using the same protocol. The patent mentions a more complicated sensing system than these switches require.
Alternatively, if someone else has an intact keyboard, or if either of the MCUs removed from the earlier conversions was saved by snacksthecat or OldIsNew and is readable -- or I can borrow it to read -- we should be able to fill in the gaps.