deskthority

Attached is the LMI Lambda keyboard's 8748 software, the LMI equivalent to CADR's "ukbd". This only matters to you if you have a LMI keyboard with its "brad board". If you have such a keyboard and your 8748 has bit-rotted, this will revive it. (The image is also being sent to bitsavers and such)

This was extracted from and compared between two separate working keyboards. I tested it by fully erasing and reprogramming an 8748, installing it into a keyboard, and plugging that directly into lambdadelta using an arduino as a level converter / UART. It works. I also documented the "unknown" double-bucky boot chord bytes while I was at it, so I have a complete map of the protocol now.

If you have a LMI keyboard that does not have the brad board, this may still be helpful. If you are in this situation, let me know. The brad board doesn't do much to the serial bits, it only inverts the serial polarity unless the 8748 is in reset. Most of the board is the speaker driver and 5V regulator.

I am still testing to confirm if the difference between LMI and CADR keyboards really is just the firmware; I will tell people later when a determination is made.

I wrote that firmware. I think in 1983. It might say at address 1300 (octal).

BTW, the "Brad" of the "Brad Board" was Brad Miller.

The original CADR keyboard wasn't serial. The interface used a 24 bit (IIRC) shift register that was clocked by the host.

The LMI Lambda had a serial port on the SDU board (designed by the NU machine project at what I think was then Western Digital). That's what the keyboard had to connect to.

My goal was to be able to communicate everything the CADR keyboard could since there was CADR software that made use of key transitions and distinguished between left and right bucky keys.

Given the cycle time of the 8748, the best I could send at was 1200 baud. I couldn't hit that accurately enough so I had to add I think one extra stop bit to force the SDU's UART to resynchronize.

I think I'm remembering this all correctly. I don't have any of the files at hand.

Two bytes were sent for each key transition.

The high bit of the first byte was 0. The other 7 bits were the key number. This was something arbitrary governed by how the traces on the printed circuit board were layed out.

The high bit of the second byte was 1. Of the other bits, one indicated whether a down or up key transition was being sent. For each pair of named bucky keys (e.g. "meta") there was a bit to indicate if either of those keys was down. This was a precaution in case a byte got lost.

Typing something like control meta f would send two bytes for the down transition of the control key, two for the meta key and two for the "f", and then another 6 bytes for the corresponding up transitions.

The reboot gestures required that both control and both meta keys be held down while hitting either rubout (cold boot) or return (warm boot). This was a precaution to guard against accidental booting.

An interesting note: when Texas Instruments was building their Lisp Machine (they licensed the Lambda from LMI and made custom ICs), their keyboard had the bug that if you hit both control and meta keys, the keyboard would get stuck in a mode where the next thing it would send would be a reboot. If I recall, you could avoid this fate by unplugging the keyboard and plugging it back in again.

I believe that the actual keyboards from MicroSwitch were the same for both the CADR and Lambda. These keyboards had the best feel of any keyboard I've ever used. I wish I had one.

I hope I remembered this all correctly and that it might be useful to someone.