IBM Terminal F: Controller ROM

[JohnElliott]

I've managed to desolder the controller from an IBM 6110344 terminal model F, and read its internal ROM. The contents probably won't be very interesting unless you either:

a) have a few spare 8048 / 8748s lying around to make a modified controller image, or
b) are interested in how capacitative keyboards work.

PM me if you want a copy of the ROM image. I've identified two areas where changes could improve PC compatibility (completely untested):

• From 0101h to 0120h is the bitmap of which keys repeat and which generate break codes. If all the bytes were set to 55h then all keys should send break codes.
• 015Ch: Replacing A4h with 00h should stop the keyboard sending its ID on reset.

I suppose if the controller were replaced with one that had a larger ROM (say an 8049 or an 8050) it might be possible to add scancode translation (currently, scancodes are tied to the keyboard matrix) or even turn the board into a full terminal emulation board supporting all three scancode sets and LEDs. I will happily leave both as an exercise for the interested reader :smile:

[microsoft windows]

Kishy would be very interested in this.  You should  send him a  message  or something  about it.  He's done  a  lot with the IBM terminal keyboards.

[JohnElliott]

I don't code but like learning about capacitive switches.  Anything interesting in the code?

Depends on your definition of 'interesting'. It reads the keys in groups of 8, storing their up/down status in a byte. Then it compares that byte to what it was last time the row was scanned, and if there are differences it gets on to sending scancodes. (It rereads the key group twice, presumably for purposes of debouncing, but I'm not exactly sure what it's up to there). Its buffer appears to be able to hold three scancodes at most, so if you pressed four keys in the same group simultaneously [eg: ZSAW] I think it might miss one.

Another thing, which may or may not be interesting, is that the key matrix has 128 positions, and the keyboard has 127 keys. The extra key position is (roughly) where Right-Windows ought to be -- you can see a sort of vestigial connection on the PCB there. Part of the self-test is to read that key, and if it registers as 'down' report an error.

Anyone studying the code would probably find it helpful to read it in conjunction with the KBDBabel schematic of the 84-key AT keyboard, which appears to have an identical controller. It does make me wonder what would happen if you did a controller swap.

One thing I forgot to mention when talking of patching the controller ROM: You have to make sure the 8-bit checksum is 0, because the self-test checks that. I think the byte at 0100h is used for this purpose.

[ch_123]

The AT most definitely has the same controller. As I posted elsewhere, plugging the AT into a system that uses Scancode Set 3 causes the AT to behave like a terminal board in regards to layout.

[JohnElliott]

It does make me wonder what would happen if you did a controller swap.

Curiosity got the better of me. I desoldered the microcontroller from my 6450225 (84-key AT), and plugged it into the 6110344 (which means I now also have a suitable microcontroller ROM image for the 6450225; again, PM me if you want a copy). I haven't fully reassembled the 6110344, but tests on the bare PCB are encouraging. It does appear to pick up all the extra keys when I bridge them with my fingers.

Possibly related: In both ROMs at 0300h is a table which I think governs key sensitivity. In the 6450225 ROM, all the keys that aren't present on the board have a value of 7, while keys that do exist have values of 1-4. I suspect that best results would be obtained by making a custom ROM that used the 6450225 code and the 6110344 table.

[JohnElliott]

I've been experimenting, on and off over the last few weeks, with custom firmware for the 122-key terminal Model F (6110344). I've now got a 1k ROM image that seems quite promising.

Upsides:

• It works on Windows 2000 without a driver swap.
• It allows any key to return any 1-byte scancode so (for example) I can move the function keys to the top and have two Escape keys, one on the left and one on the right. This also means I can stop keys sending codes where the key-up is swallowed by Windows.
• It supports the LED panel from the 84-key AT keyboard, if you happen to have one of those spare.
• All keys send key-up and key-down codes and repeat, so it ought to work through a USB converter.

Downsides:

• It's heavily based on IBM's copyrighted code, so I can't distribute it (but see below).
• It doesn't support E0 prefixes, so the cursor keys and the six keys above them will still need remapping at the host end to be useful.
• Installing it is not for the fainthearted: You need an EPROM programmer that supports 8748s, and you need to desolder the keyboard's original microcontroller to replace it.

I've also come up with a 2k ROM image that should turn the Terminal F into a full terminal-emulation board with support for all three scancode sets and E0 prefixes. But my Willem EPROM programmer can't program 8749s (it barely manages 8748s) so I haven't been able to test it at all.

To get round the problem of distributing IBM's copyrighted code, I've written a Java program that, given images of the original IBM ROMs, will create the new 1k and 2k firmware images and allow you to customise the key translation tables. Let me know if you want a copy.

Oh, before you ask: The only hardware I can do this with is the Terminal Model F and the 84-key AT Model F. Not the 83-key XT Model F, and not any kind of Model M.

[Hak Foo]

Proposal:  Can a replacement for the controller be had cheaply?

If so, you might be able to do a "piggyback" install-- new chip on old chip, and cut just the power lead of the old chip so it doesn't power up.  It's potentially less difficult to install.

[JohnElliott]

Proposal:  Can a replacement for the controller be had cheaply?

If so, you might be able to do a "piggyback" install-- new chip on old chip, and cut just the power lead of the old chip so it doesn't power up.  It's potentially less difficult to install.

If you needed a replacement for the original microcontroller, you'd have to burn another 8748 with the original firmware, I think, unless Unicomp happen to have a supply of spare Model F microcontrollers somewhere. 8748s seem to cost $10-$20 each on eBay.

While piggybacking may be easier if you're doing a permanent replacement, the advantage of properly desoldering the microcontroller and fitting a socket is that it then becomes much easier to swap the thing in and out in the future -- for example, if you wanted to change the 8748 for one with different key mappings.

[What is X?]

Wouldn't it be better to upload it somewhere rather than ask for PMs? What if someone wants the code in a year and you're not here or something? Just a suggestion.

[JohnElliott]

Wouldn't it be better to upload it somewhere rather than ask for PMs? What if someone wants the code in a year and you're not here or something? Just a suggestion.

A fair point; I'd wanted to wait until I'd written better instructions, but it might as well go up now. The Java app is here. That's on my personal website, though, so if I do go under a bus it won't outlast me by more than a few months at most.