4

I'm attempting to build an interface for a 1985 IBM typewriter keyboard. This is interesting because it's bidirectional --- the keyboard has a screen on it. I was expecting some variation of XT or AT protocol, but it's really not.

There appear to be two wires which are used; one is clearly a reset line and is of no further interest; and the other is used for all data transmissions. There is no clock wire.

enter image description here

So far I've observed:

  • data transmission is in short packets, probably bytes. One is pictured above. Each one is prefixed with a much higher frequency prologue sequence. I've observed at least two kinds. (Keyboard→machine and machine→keyboard?)

  • looking at it on the scope, the leading edges are very sloppy, but trailing edges are sharp. If I assume that only the trailing edges are the ones of significance, but the sequence pictured only has five, which isn't enough for a simple time-between-trailing-edges protocol.

  • the pulse width is very approximately 100us, meaning the protocol runs at 100kHz-ish, which seems reasonable. The short pulses are about 20us from trailing edge to trailing edge.

  • (new) Taking a logic analyser trace without the keyboard attached shows that the base station is sending the initial high-frequency sequence and then waiting for a response. This suggests that the protocol is polled and controlled from the master end.

  • (new) In the trace below, there are four timings: high intervals can be 45us or 67us. Low intervals can be 54us or 44us. This doesn't add up neatly to simple async mark/space bits.

  • (new) There's no high-level timing structure I can see --- i.e. no sequences which look like packets or frames. The only communication is a constant stream of sequences like the one below. (newer) This actually turns out to be wrong. There are some multi-packet sequences, mostly in startup and initialisation; I was just looking in the wrong place. I'm not sure they help to identify what this is, however.

I wasn't expecting anything quite this... odd. It's certainly not any of the one-wire protocols I've encountered before. I've double checked that there isn't a clock wire hidden away anywhere. Any ideas?

(As an aside, none of the ICs on the keyboard are identifiable! Mysteriously so, in fact. There's a chip with the TI logo with a number starting with SH, which is not Texas Instruments' IC prefix (SN)? Likewise, a National Semiconductor chip with an NK code (should be DM/LM/MM)... even the MCU just says it's an Intel 'PI M A'. Picture attached.)

enter image description here

David Given
  • 1,173
  • 1
  • 8
  • 15
  • 1
    Very interesting! Would you share a picture of the board and device anyways? And maybe the scope traces for some specific ASCII chars (for instance space, zero, 9, @, a, e, z)? – datenheim Jan 25 '23 at 21:43
  • I've uploaded a picture. Sadly I can't produce traces on demand --- there's constant traffic no matter if I'm pressing any keys or not. Polling, maybe? – David Given Jan 25 '23 at 22:12
  • Also, one really interesting thing I've just noticed... the top numbers on the two chips on the left are 4767634 and 4767635; but one's Motorola and the other's TI! I always thought that was the batch number. I wonder if IBM had all of these made specially with non-standard markings. – David Given Jan 25 '23 at 22:13
  • How sure are you that the data transfer is bidirectional? For example, an input device with a screen could use it for local feedback, and data exchange with the larger system could still be unidirectional. Of course being bidirectional is possible, I just don't believe having a screen is proof unless data from the larger system actually ends up on the screen. – Ben Voigt Jan 25 '23 at 22:22
  • @DavidGiven The IC marked 4767635 looks like it's from National Semiconductor, not TI. Compare the logo to [this image](https://en.wikipedia.org/wiki/File:National_Semiconductor_8250A.JPG). – Velvel Jan 25 '23 at 22:27
  • @Velvel Sorry, yeah, typo. I was spending to much time looking at the other end of the board. – David Given Jan 25 '23 at 23:54
  • @BenVoigt Quite sure. The machine's main software runs on the base unit, which is a 64kB 8086 running programs off cartridge. It will display messages stored on the cartridge. – David Given Jan 25 '23 at 23:56
  • @DavidGiven IF the keypresses are transmitted over that line, there MUST be some change depending on the keypresses, even if it may look very subtle. I hope you have a digital scope - else you won't have a chance to de-mystify it. By the way - do you only want to know - or have you an idea of re-using the keyboard or so? – datenheim Jan 26 '23 at 19:05
  • @datenheim (Sorry, been away.) That's true, but currently I don't have any way of distinguishing the keypress packets from anything else. There's constant traffic and the packets constantly vary. I was hoping to see a Tx and an Rx line which would let me distinguish the two types of packets but with only one data line it's much harder. I've added some more data to the question, BTW. – David Given Feb 01 '23 at 21:57
  • The presented trace is from the logic analyzer? Sadly without a time axis. You described sloppy and sharp edges - please show a scope image too. Lastly I think we need a couple of traces to put over each other to see a pattern. Couldn't you trigger the scope directly with a keypress to catch what it triggers? – datenheim Feb 01 '23 at 22:57
  • @datenheim I'm not actually looking for help reverse engineering this --- I can do that myself, and this isn't a useful venue for that! What I want is someone who can instantly recognise this as a known protocol so that I don't have to identify it. – David Given Feb 02 '23 at 22:25
  • @DavidGiven - Hi, Thanks for coming back with an answer to your question. In order to effectively mark the topic as solved, please consider "[áccepting](https://meta.stackexchange.com/q/5234)" your choice of the best answer (i.e. click the "tick mark" next to an answer - [your answer](/help/self-answer) or another one - to turn the relevant tick mark green). This shows that you don't need more help and future readers can quickly see there was a confirmed answer. Thanks. – SamGibson Feb 05 '23 at 23:32

2 Answers2

3

Figured it out, thanks to some help from someone on Reddit --- it turns out that I was dramatically overthinking things!

It's just a simple UART connection, at about 190kbaud. It's either 8n1 with some undetermined parity bit or 9n1. It's strictly master-slave; the master (the base station) sends a byte and then the slave (the keyboard) responds with another byte, rinse and repeat. Those 'fast pulses' are actually the command byte sent by the master. The things which I thought were bits are 0x000 and 0x100, depending on the length. The sequence above is the base station querying the keyboard for status and the keyboard replying with 0x100. The only difficult part is determining the baud rate, as low bits tend to be about 5.75us long, but high bits are 5us --- maybe it's bitbanged?

And that's all there is to it. The higher-level protocol is more complex but I'm making progress. I suppose the moral is that things are frequently more boring than they seem!

David Given
  • 1,173
  • 1
  • 8
  • 15
2

Maybe something like SDLC (or some variant) implemented with open-collector outputs for half-duplex over a single wire.

There were some MCS51 MCUs of that era made with on-chip SLDC controllers. The chip arrangement is suggestive of that kind of architecture, perhaps with external OTP EPROM as the TI chip.

Spehro Pefhany
  • 376,485
  • 21
  • 320
  • 842
  • Isn't SDLC a synchronous interface, Synchronous Data Link Control, which requires an accompanying clock? So two wires/signals? – SteveSh Jan 26 '23 at 00:57
  • @SteveSh You'd think so from current usage of the term synchronous, but synchronous here refers to time-based signals. It's used with modems, so no clock. – Spehro Pefhany Jan 26 '23 at 01:28
  • Tentatively, I'd have to say it doesn't look like SDLC. There doesn't seem to be high-level framing and the start sequence is completely unlike the traces I've found for SDLC. – David Given Feb 01 '23 at 22:14