IR PC keyboards: IBM and Quadram

[MMcM]

For a short period in the early-80's, some home PCs had infrared wireless keyboards, to try to make them more flexible in non-office setups, I guess.

The best known of these is the notorious IBM PCjr, with keyboards made by Advanced Input Devices, first with chiclet keys and then with more normal, slightly less worse, stepped keys. Inside, these AID boards were pretty much the same, with conductive rubber domes making contact onto the PCB.

IBM-PCjr-top.jpg (1.31 MiB) Viewed 3717 times

IBM-PCjr-bottom.jpg (1.13 MiB) Viewed 3717 times

The real key version is also a little interesting in that, in lieu of stabilizers, the space bar and big-ass Enter key are cantilevered. This seems to have also been done on some other AID keyboards, such as this one.

Another wireless keyboard was for the DataVue 25 from Quadram.

DataVue-25-case.jpg (384.59 KiB) Viewed 3717 times

I found one of these to see what could be done by way of an IR converter.

The layout is a bit crowded. But it has Omron switches, so it isn't impossible to type on.

DataVue-25-top.jpg (1.87 MiB) Viewed 3717 times

DataVue-25-bottom.jpg (1.24 MiB) Viewed 3717 times

Like the PCjr, it is powered by 4 AA batteries. There is a provision for a wired connection by a DIN-3 connector, but it is not capable of supplying power. And to start I am concentrating on the wireless protocol. Unlike the PCjr, which just ate the cost of keeping the keyboard in standby mode all the time, the DataVue has a mercury(!) reed switch, angled in such a way that it is on most of the time, until the keyboard is locked vertically into the case. That's it in the lower-right of the photo.

I started by connecting the scope to the NPN transistor that drives the IR LEDs and hitting some keys.

DataVue-IR-A.png (19.73 KiB) Viewed 3717 times

DataVue-IR-A-up.png (19.23 KiB) Viewed 3717 times

DataVue-IR-B.png (20.14 KiB) Viewed 3717 times

The on pulses are always the same width and there seem to be three widths for the off interval, suggesting maybe some kind of Manchester encoding. Which is interesting, of course, because that's the encoding used by the PCjr.

Looking more closely at the pulses, they are 40kHz square waves.

DataVue-IR-pulse.png (24.97 KiB) Viewed 3717 times

The on period is three (or two and a half, if you prefer) cycles.

Again, this sure looks like the same protocol as the PCjr, as seen in the Technical Reference. So I decided to get one of those for cheap (no one wants them because they are awful) to be able to compare.

How to detect the IR signal? Most IR receivers today use a single-component digital receiver, which consists of an amplifier and band-pass filter. The most common of these are 38kHz, but Vishay also makes them in 40kHz. Also, the common ones are designed for medium-length pulses. There is a short-pulse version, but it still takes 6 cycles to stabilize. So, that's not going to work.

The circuit in the original Infra-Red Receiver Board has an NEC IR pre-amp and a one-shot. Those pre-amp chips can be found on eBay, but the receiver also needs a bunch of passives like an inductor.

So I built something simpler with what was lying around, using an op-amp as a voltage comparator and including a trim-pot to somewhat adjust the sensitivity.

DataVue-IR-converter.jpg (477.55 KiB) Viewed 3717 times

It won't be very good in an environment with much light noise. Specifically, it seems to be okay for around 6 inches when the room isn't too sunny. Honestly, I'm not sure the original was much more reliable than that.

Here is the voltage drop over the photodiode and the resulting compared signal.

DataVue-IR-A-recv.png (22.28 KiB) Viewed 3717 times

In the meantime, the PCjr keyboard showed up here, and, yes, it's more or less identical, except maybe for a lack of a "warm-up" pulse before the key press.

IBM-PCjr-IR-A-recv.png (23.13 KiB) Viewed 3717 times

So, assuming that it really would be the same, I whipped up a sigrok decoder based on that specification.

DataVue-IR-A-logic.png (36 KiB) Viewed 3717 times

It's not all that surprising that the scan codes are the same, since they are just the XT ones.

But how is the lower level encoding the same? Did it originate with IBM, or AID, or Quadram, or some earlier system? Was it licensed or just "borrowed?"

[raoulduke-esq]

Fantastic work! I’m looking forward to the day I can torture myself by using a PCjr board with a modern computer. This is really exciting! Being able to use every board in the collection is a goal.

[John Doe]

Glad realising I lost the auction to whom and this beauty went to a more propriate guy.

Excellent adapting job like always.

ps: Probably it's time to get analyser, adapting with parsing protocol looks so funny.

[MMcM]

For comparison, here is the wired protocol from a PCjr's RJ port. The encoding is the same, with 0 and 1 half-bits being distinguished straightforwardly as low and high (rather than 1 containing an IR pulse).

PCjr-RJ-A-logic.png (37.92 KiB) Viewed 3554 times

The same converter firmware can handle both encodings with separate GPIOs. And both keyboards, although it's probably best to pick the right layout so as not to lose Alt when there are real keys with `~\|.

It's hard to overstate how horrible the chiclet keyboard is to type on.

[raoulduke-esq]

Greetings Comrade!

I saw this pinout in the documentation:

Screen Shot 2021-08-10 at 9.38.15 PM.png (400.53 KiB) Viewed 3380 times

2: DATA
3: GND
5: VCC

I saw in the firmware it was:
2: DATA
5: VCC
6: GND

Any suggestions for how I should wire my converter? Maybe 3 and 6 both to GND?

[raoulduke-esq]

Made my own cable by ordering some 6P6C tips and using a beige 4P4C cable I had lying around. Stripped one end of the cable and fed it carefully into the 6P connector into slots 2-3 5-6. I took a 4P4C socket and added that to my usual project box Pro Micro setup and and ran 3 and 6 both to ground, jumped D0 to ground, and it works perfectly. I'm using this badass keyboard right now and it's by far the best keyboard I've ever used.

Ok, so not quite perfectly. It cuts out periodically and I need to stop typing and wait like 5 seconds before keystrokes are registered again. If I keep typing when it stops then it doesn't start again. Waiting is the only solution once it decides to stop furnishing keystrokes. Tried going back and adding an external pull-up resistor between VCC and Data to see if that would help but I'm still getting the dump/freakout. I haven't identified any specific behavior that leads to the stop unless it's just fast typing. It hasn't done it for like the last 20 mins... no idea.

Other than that, it's by far the best keyboard I've ever used. This is seriously about to be my daily driver.

[MMcM]

An NEC product in this space is the PC-6601SR, aka Mr. PC. The keyboard can use infrared or a coiled cable, switching modes depending on whether it is plugged in.

NEC-6601SR-case.jpg (338.27 KiB) Viewed 2500 times

Someone has completely documented how this PC works, including schematics, keyboard scan codes, and keyboard protocol timing. About the only confusing thing is the pin numbering of the RJ 4P4C used for wired communication: the pin numbering of the CNx01 part on the PCBs does not match standard RJ and the cable is crossover, so the two sides are additionally mirrored.

Guessing that the PC has +5VDC on one of the 4 pins to power the keyboard would be half right. There is a 5V signal, but is used to pull up the T1 pin on the 8049 so that it knows that the cable is plugged in (IBM had a complicated switch built into the jack for this). The keyboard always runs off 4 AA batteries, even when connected like this. In order for the PC to similarly detect the keyboard, another of the lines is connected to ground inside the keyboard. The remaining two are the signal ground and data.

The pulse distance encoding of the key event bits is identical for wired and wireless, except that the wired pulses are shorter. The IR signal has a 38kHz carrier. The pulse widths are a sufficient number of cycles that readily available remote control sensors like TSOP38238 or VS1838B have no problem. The converter then has two active low data lines and a binary sense line to tell it which to use.

NEC-6601SR-converter.jpg (704.66 KiB) Viewed 2500 times

Each packet has 24 bits, the second 12 being the bitwise complement of the first 12. Which means that packets are always the same duration (same total number of 1s and of 0s). The 12 bits are 3 bits of control, 8 bits of scan code, and a parity bit. All of which error checking, together with an extra long header pulse at the start, means that garbage USB keyboard input is pretty unlikely even when decoding fails.

The basic form of a scan code is an ASCII character. For the most part there are no key up events. Shift and Ctrl are applied by the keyboard, so that A is 61, shift-A is 41, and ctrl-A is 01. But Caps Lock is not: it is just another key press. Many of the command keys send ASCII control characters, so that RETURN is indistinguishable from Ctrl-M or CLR from Ctrl-L. But within those constraints a minimal converter is possible.

7 of the keys, STOP, SHIFT, SPACE, and the 4 arrow keys, are meant to be used for gaming and send their current state as a bitmask using one of the control prefixes. That means that if one needs an extra USB shift key, such as for CMD, those are the only ones available. STOP doesn't match anything in particular on a modern system, but is awkwardly placed. Else one could give up the arrow keys (or bring them back in layers).

Another control prefix is used for GRAPH key variants. But only 36 of the keys have them. Which makes it somewhat unsatisfactory to bind to ALT, say. You get Graph-B and Graph-E, but not Graph-A or Graph-Q. I bound it to a layer shift so that the keymap at least documents which are actually available.

When the テレビ locking switch is depressed, only 20 keys send commands with a different control prefix. Presumably these were actually recognized by some televisions. This also helps explain the command structure, if you think of the control bits as a device address and the scan code as a device command. I bound this to a layer shift and put some media key bindings on those codes.

The 電源 key needs to be held for a few seconds to do anything. Then it sends a unique control prefix with the only code used for it. I find it convenient to bind this to QMK RESET. Then one can use an AVR board without a reset switch and only have to tweezer jumper it the first time while developing / refining the keymap. I in fact used an A-Star Micro, because it has two LEDs, one for wired vs. wireless mode and the other for character receipt in progress, which is useful when unsure about IR.