Vintage PC pages
Home -> Vintage PCs -> IBM 1390876 Keyboard

The IBM 1390876 Keyboard

Note: You need a browser capable of displaying SVG images to see the keyboard layouts.

The IBM 1390876 is a 122-key keyboard, originally intended for use with an IBM 3197 terminal. It is possible, with a little ingenuity, to connect it to and use it on a PC (under DOS and Linux, if not Windows).

The keyboard has a 5-pin DIN plug that uses the 240-degree spacing. From another site, I was able to get a pinout:

A normal AT keyboard uses the 180-degree spacing and this pinout:

It would, therefore, be possible to construct a simple adaptor. I was able to use an alternative method: swap the keyboard lead with one from a real IBM AT keyboard. Inside both types of keyboard, the lead connects to a 3x2 Berg connector with the same pinout, so I could simply swap the leads over.

LEDs

There are no LEDs, and no obvious connector for an LED panel. The keyboard controller accepts commands to set them, though.

Identity

When sent an identify command (0xF2), the keyboard returns the byte sequence 0xBF 0xBF. However, this can be changed. On the keyboard PCB is a 12-pin header, marked as 6 pairs of pins (B2-B7). These correspond to bits 5-0 of the second byte of the keyboard ID. Shorting a pair of pins sets that bit to zero. So placing a jumper on the B2 pair will change the keyboard ID to 0xBF 0x9F.

Adjacent to this header is a space on the circuit board for an identical header, marked as pins A2-A7. Presumably these would have the same effect on the first byte of the keyboard ID.

Scancodes

The keys on the 1390876 are laid out like this:

When in use, the keyboard always uses Scancode set 3. It rejects requests to change the scancode set. The scancodes it returns are:

Notes:

These are then translated by the PC's keyboard controller to:

meaning that, on a PC, the keyboard behaves like an 84-key AT keyboard:

Commands

The keyboard accepts the following commands. Most of them behave as documented for the 102-key PS/2 keyboard, but there are a couple of exceptions:

CommandDescription
ED xx Set LEDs. Despite the keyboard not having any LEDs, it will accept this command and check that the parameter is in the correct range (0-7).
EEDiagnostic echo.
F2Read keyboard ID (usually BF BF).
F3 xxSet repeat rate and delay.
F4Enable keyboard (clear errors).
F5Disable keyboard.
F6Set defaults.
F7Set all keys to repeat. No keys will send break codes.
F8Set all keys to give make/break codes. No keys will repeat.
F9Set all keys to give make codes only. No keys will repeat or send break codes.
FABehaves as FB. On a 102-key PS/2 keyboard, would set all keys to repeat and to give make/break codes.
FBSet specified key(s) to repeat. They will not send break codes. Followed by a list of scancodes, which should be terminated by F4.
FCSet specified key(s) to give make/break codes. They will not repeat. Followed by a list of scancodes, which should be terminated by F4.
FDSet specified key(s) to give make codes only. They will not repeat or send break codes. Followed by a list of scancodes, which should be terminated by F4.
FEResend last scancode.
FFReset. The keyboard will respond with AA (as for the 102-key keyboard) followed by the 2-byte keyboard ID.

The F0 command (set / get scancode set) is not supported.

Under Linux

[TAR]1390976.tar.gz contains a script and keymap which, combined, make the keyboard rather more usable in the Linux console. Among other things, it makes the arrow keys work, moves the function keys from the left to the top, and makes the symbols produced match the keytops where possible.

Under Windows 2000

If the keyboard is connected directly to a Windows 2000 computer, it does not work. Windows, during initialisation, resets the keyboard, and then gets flummoxed by the extra bytes which result. It is possible to trick the keyboard into working by using a KVM switch: switch away from the computer when Windows starts to load, and switch back when Windows has loaded completely.

[REG]1390876.reg remaps the cursor keys, function keys, and various other keys so that they produce the scancodes that Windows expects for their keycaps.

If you have a copy of the Windows 2000 DDK, it's possible to build a patched version of the keyboard driver that doesn't try to do the reset. Apply this patch:

[DIFF] pnpi8042.diff

to the i8042 driver (in ...\src\input\), rebuild it, and replace \winnt\system32\drivers\i8042prt.sys with what you just built (you may have to disable Windows File Protection or do the copy from an alternative OS. I'm told that booting in Safe Mode also allows you to make the substitution).

When using the custom driver, the keyboard's hardware key repeat is disabled. If you turn on the FilterKeys functionality as described here, Windows will simulate key repeat in software.

Although this section describes Windows 2000, it probably applies to other NT-based Windows systems such as Windows NT, XP and Vista. The supplied registry file requires Windows 2000 or later, and I haven't tested the patch on later or earlier versions of the DDK.

A Theory

This is my guess at how the three scancode sets came to be:

Just a theory, nothing more.


John Elliott 19 January 2010.