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.
There are no LEDs, and no obvious connector for an LED panel. The keyboard controller accepts commands to set them, though.
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.
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:
- Only shaded keys send key-up sequences (F0 xx)
- Smaller numbers shown in circles are holes in the keyboard with no springs, corresponding to unused positions covered by double-sized keys.
- The unused position under the spacebar does not respond to being poked with a screwdriver, whereas the others do.
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:
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:
|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).|
|F2||Read keyboard ID (usually BF BF).|
|F3 xx||Set repeat rate and delay.|
|F4||Enable keyboard (clear errors).|
|F7||Set all keys to repeat. No keys will send break codes.|
|F8||Set all keys to give make/break codes. No keys will repeat.|
|F9||Set all keys to give make codes only. No keys will repeat or send break codes.|
|FA||Behaves as FB. On a 102-key PS/2 keyboard, would set all keys to repeat and to give make/break codes.|
|FB||Set specified key(s) to repeat. They will not send break codes. Followed by a list of scancodes, which should be terminated by F4.|
|FC||Set specified key(s) to give make/break codes. They will not repeat. Followed by a list of scancodes, which should be terminated by F4.|
|FD||Set 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.|
|FE||Resend last scancode.|
|FF||Reset. 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.
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.
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:
to the i8042 driver
...\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
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.
This is my guess at how the three scancode sets came to be:
- Originally, there was only the IBM PC. This used Set 1.
- When the 3270 PC was created in 1983, its keyboard used Set 3. A plug-in ISA card was used to convert the scancodes received to Set 1.
- When the PC AT was designed, it was decided to make its scancodes compatible with Set 3, so that you could connect either an 84-key keyboard or a 122-key keyboard and not have to bother with the ISA card. The keyboard controller would then translate back to Set 1 for program compatibility.
- Then the 102-key extended keyboard entered the picture. It couldn't use the corresponding codes from Set 3 for its extra keys, because existing computers wouldn't be able to handle them. So Set 2 was created for it, where the extra keys send E0 prefixes.
- But the option to switch to Set 3 was added, so that programs which did support the 122-key keyboard wouldn't need to be changed. This also explains why the function keys are different in Sets 2 and 3; in Set 2, for backward compatibility, they return the scancodes for the 'left' function key block, and in Set 3 they return the scancodes for the 'top' function key block, which is where they now are.
Just a theory, nothing more.
John Elliott 19 January 2010.