The original poster now considers this method 'deprecated'Please consider Teensy-based USB converter solutions, posted about here on Geekhack already.
This method will work, but is not preferable.
[H=1]Introduction[/H]
[H=2]History, background and overview[/H]
First, before I scare you off: the procedure is to replace or adapt the plug on the keyboard to AT or PS/2, and then do a couple software things to make it a little more usable. The article is very wordy considering that, but it's better to explain too much than not enough.
In the 1980s (and before), 'dumb terminals' were pretty much the industry accepted way of many users in a given location accessing a computer (a mainframe or midrange system that the terminals connected to). The terminals themselves were simplistic, limited-capability devices that more or less just establish a connection to the host system, display the information from it and allow communication.
In the 1980s, sometime around (shortly before, it appears) the introduction of the PC AT, IBM used the new keyboard protocol they had developed for that system ("AT") in the new terminals they were releasing. They used a similar-looking DIN plug with 5 pins, which appears to have been a standard 6 pin DIN socket with the 6th left unpopulated (this accounts for the unusual spacing and pin thickness, which were standard for a 6 position connector, not the 5 position one). These plugs are not mechanically compatible with XT or AT, but they have +5V, GND and AT-compatible data and clock pins, meaning that with physical adaptation they can be used with relative ease. Compare this with XT which uses the same physical connector as AT, but incompatible signalling...the terminal boards are easier to work with by far.
At some unknown point later in time, IBM migrated from the DIN connector to an 8P4C (8 positions, 4 populated conductors) modular plug (commonly but arguably incorrectly known as RJ45). There may be 4P4C connectors as well. These keyboards maintained the same signalling and are just as 'conversion-friendly' as the DIN connector models.
Seemingly because it was an early implementation of the protocol, there are a couple 'bugs' which are in fact fully supported by the protocol/standard, but not by modern software. These will be addressed in a later section of this article.
The keyboards used for these terminals have included capacitive buckling spring (Model F), membrane buckling spring (Models M/M2) and rubber dome (possibly M2 only?) switching technologies. They have had a variety of physical and logical layouts and many, many part numbers.
[H=2]Does this apply to my keyboard?[/H]
In order to determine if this mod should work with your keyboard, you need to first determine what type of IBM dumb terminal it was designed for use with. The majority you're likely to find are compatible, but it's important to check.
First, use the search engine of your preference to search for your keyboard's part number (for example, "1386887"). Then, look through the result summaries looking for a 4-digit number...in most cases a 4 digit number in a search result for one of these keyboards is the terminal type (for example, 3179, 3192, 3488...etc). What can be particularly helpful is resellers who say, for example, "1386887 IBM KEYBOARD FOR 3179 TERMINAL" or something to that effect.
According to
the kbdbabel project, the following terminals used keyboards suitable for this process:
3151-3153, 3179, 318x, 319x, 34xx
Independent research also includes at least some 329x terminals as well. There may well be others but they aren't known for certain at this time.
[H=2]Alright, my keyboard is compatible. What are those problems you mentioned?[/H]
[*]When a computer with an AT or PS/2 port starts up, it 'asks' the keyboard what its ID is. This is a hexadecimal number. Some computers can be particularly picky about this (IBM at least, possibly others) and may fail POST citing a keyboard error if they dislike the reported ID. Some of the keyboards have jumpers or DIP switches that allow for modification of the ID so this issue can often be resolved when it happens.
[*]Modern Windows (NT-based) do something during keyboard initialization which causes the keyboard to 'hang' or otherwise become nonfunctional. Hot unplugging and replugging after this occurs fixes the problem, but this risks damage to both the keyboard and motherboard. A modified driver exists for XP which corrects this.
[*]By default, the keyboards do not send break codes. Keypresses on a keyboard normally send a 'make code' to indicate the key has been pressed, and a 'break code' to indicate it has been released. Old software is generally tolerant of this, and some modern software can be as well, but occasionally weird behaviour will occur. The keyboards can be instructed to enable break codes, but if they are, there is no hardware-level typematic repeat (ex. press and hold a key, and it repeats). The above-mentioned modified driver corrects the break code issue, but does introduce the lack of repeat issue.
[*]The keys are mapped like an XT or AT-layout keyboard: wacky. You'll want to be able to remap the keys if you want the keyboard to be usable. The article describes a couple ways to do this later on.
[/LIST]
[H=2]Alright, I can deal with all that. What are the risks?[/H]
As with most mods, there are possible risks associated with this process. If you make a mistake, whether it is your own fault or an issue with the clarity of this document or others, it is possible to end up with a damaged keyboard, motherboard or both.
The risks, if you do this all properly, are quite low, so just read carefully and ask questions if you have any and you should be fine. Rushing is generally not recommended. This article mentions that hotplugging can be done to verify if the keyboard is working, but this is not a suggestion or instruction to do so. If you do, do it at your own risk, and understand the risk.
[H=2]What You'll Need[/H]
[*]Basic electronics abilities (cutting and stripping wires, perhaps light soldering, continuity checking)
[*]Multimeter or continuity tester (or some other way to check what pins go to what wires in your replacement cord)
[*]Other tools - to open keyboard, to cut/strip wires, to solder...
[*]Keyboard to be converted (duh)
[*]A USB keyboard (not so duh)...there are times you may have no PS/2 port driver during this, so it's important to have a USB HID keyboard available!
[*]Computer with a PS/2 or AT keyboard port - this will not work on a USB converter
[*]A cord with connector from any PS/2 or AT keyboard
OR just a connector if you plan to hack up the original cord
[*]Software: key remapping abilities
[*]Software: key monitoring abilities
[/list]
[H=1]The Process[/H]
[H=2]Hardware[/H]
[H=3]Jumper Configuration (if so equipped)[/H]
Note: does not apply to all keyboards. Some only have some of the pins, some don't have any.
Open the keyboard. On the controller PCB, you will hopefully find a set of pins corresponding to the following image (lacking jumpers installed, of course). In some cases wires will run from these pins to a bank of DIP switches on the bottom of the case, and in some cases some or all of these pins won't be present.
If the pins are present, set the jumpers like I've shown. If the pins are wired to DIP switches, set the switches in an equivalent manner (or remove the wire header and set jumpers on the pins if you like). If the pins aren't there at all, or some are missing, don't touch them at all.
If you are unable to do this, it may or may not be an issue. If your computer fails POST citing a keyboard error, then this is an issue for you, and you probably can't proceed.
[H=3]New Cable Construction[/H]
This presumes you are swapping the entire cable (easier) instead of just swapping the connector. The connector swap is obviously similar.
[*]What you need to do first is figure out the pinout of your cable. The wire colours aren't really standarized and so may vary from keyboard to keyboard...or worse, the same colours as another keyboard may be used, but mixed up.
Using a multimeter or continuity tester, check each pin of the AT or PS/2 connector against each wire at the other end. Make a table of pin numbers/functions and what wire colour corresponds to each. Refer to the pinout for the AT or PS/2 connector (whichever you are using) to figure out what each pin is.
This and
this, GH Member JohnElliott's pages including AT and terminal pinouts
Another set of pinouts for AT and PS/2[*]Inside the keyboard, there is a 6-position pin header with one pin removed.
PIC HERE. The pinout for this connector is as follows:
NO CONN . . +5VDC
CLOCK . . . DATA
|
BETW/ CLK & DATA: GND
This pinout is looking at the ends of the pins.
Note that in the Model F versions, these pins are in the same arrangement but are added onto the end of the jumper pins. Refer to this image:
Original cable colours on a 1386887:
Clock=Yellow,
Ground=White,
Data=Red,
+5V=BlackWhat you need to do is "find a way to connect the wires of your new cable to those pins." This can be done by snipping the connector from the original cable, or using a few connectors from computer case LEDs, etc.
Useful link about working with this style of connector.
This picture shows how I originally did mine.[*]Install the cable in the keyboard. Before proceeding, please check...then check again...then check AGAIN...that each pin of the AT or PS/2 plug corresponds to the correct pin on the keyboard controller.
[/list]
[H=3]Cable Functionality Test[/H]
It's time to test your keyboard! Shut down your testing computer, plug the keyboard in, and power it up.
First, try to get into your BIOS setup menu. If you require F11 or F12 to do this, it's not possible because the keyboard doesn't have those keys. If you require Delete, try using the numpad period (.) key.
122-key hints: the F keys (F1-F10 at least) are the far left block of the keyboard. Top left is F1, beside it is F2, continuing down to F10 in the lower right. Delete is the key which is normally numpad decimal. The cursor/nav keys are numpad 4, 8, 6, and 2. Esc is what would normally be numlock. Immediately beside that is the actual numlock.
Once you are in the menu (if able to get in), try to navigate around a little. The only arrow keys by default are on the numpad, and if numlock is on, they will not be available until you turn it off.
If the keyboard was able to enter the setup menu to begin with, you've got a working cable swap.
[H=2]Software[/H]
First, let's make sure your operating system is recognizing the keyboard's presence. Boot up the computer with the keyboard connected.
In Linux, MS-DOS & Win9x the keyboard should work without any kind of hotplugging required.
NT-based Windows does something during keyboard initialization which these keyboards dislike. This causes a hot unplug and hot plug to be necessary at the Welcome/login prompt or later.
Note: PS/2 equipment is not designed for and technically does not support hotplugging. Although rare, damage may occur from doing it. The type of damage that could happen could not be repaired if it did. Do this at your own risk.
You may get a small series of system beeps when plugging the keyboard back in - this is normal and expected if it happens. At this point, the alphanumeric block of the keyboard should function (test in notepad) with the possible occasional repeat problem. Note it is functioning kind of like an 84-key AT keyboard (CTRL is caps lock, etc). Your 10 F-keys (on the left) should be working as well.
[H=3]Driver Swap (Win2k/XP)[/H]
Certain modifications, described further up, have been made to the PS/2 port driver (courtesy of member JohnElliott and I believe sethstorm, possibly others) in order to allow somewhat more usable operation of these keyboards in Windows (2000/XP tested). You'll need to either a)
modify your PS/2 port driver yourself with the DIFF file from JohnElliott (
find here the file and how to use it), or b) replace your existing driver with the version found in Software Sources further down the page.
You may find that swapping the driver does not work on Windows newer than XP. Success may be possible using the DIFF file instead...someone get me in the loop about this please.
The working copy is located in
%windir%\System32\drivers and is protected by Windows File Protection. If you replace the file yourself without any preperatory actions, you'll find it automatically replaced again with the original. I recommend
WfpReplace to get around this.
Once the driver is swapped/modified, reboot the computer. Does the keyboard work in Windows without hotplugging? Then the driver has successfully been swapped. If not, retrace your steps and verify the driver is successfully in place and that the keyboard is in Device Manager.
If you feel so inclined you can test your keyboard with
PassMark KeyboardTest. It is available as a fully-featured time-limited trial. I have created a custom layout for the program which can be found
on this page (look for IBM-3179).
Quite simply, press every key on the keyboard. The key that is normally "Home" on a normal-layout keyboard should result in a beep if you have a system speaker. Your results, if the driver swap worked as intended, will look like this:
The sole "yellow" key cannot be tested because it actually acts to Windows like "Alt+PrintScreen", which has no (Windows) scancode (the key actually sends a code, but Windows reads it wrong, or something like that).
Note that the KeyboardTest layout is only accurate with the default mappings.
[H=3]Key Mapping[/H]
Use your preferred software key mapping tool to set up the keyboard how you like.
There really isn't much more to say about this, it's the same as for any other keyboard. Ideally though the software will be able to detect keys by scancode, otherwise you won't be able to specify what key to remap.
For this process (in Windows), I used the free software tool
Key Mapper. This program generates a registry file to semi-permanently map the keys to what you want. Keep in mind this affects all connected keyboards.
If you are familiar with AutoHotkey, it is also very capable and is nice in that it doesn't mess around with the registry. Basically, any tool which remaps by *SCANCODE* will be sufficient.
[H=1]Reference Library[/H]
[H=2]Confirmed Suitable Part Numbers[/H]
This is a list of part numbers (individual keyboards) that have been confirmed to use this protocol and are therefore suitable for conversion.
[*]1386887, Model M. 122 keys, membrane buckling spring. Originally for 3179; has wide-spaced 5 pin DIN plug.
[*]6110668, Model F. 122 keys, capacitive buckling spring. Originally for 3179; has wide-spaced 5 pin DIN plug.
[/LIST]
[H=2]Pinouts[/H]
[H=3]AT[/H]
[H=3]PS/2[/H]
[H=3]Connector Inside the Keyboard[/H]
[H=2]Software Sources[/H]
[*]
Microsoft Windows Driver Development Kit (DDK) - if you want to modify the PS/2 port driver by hand
[*]
KeyMapper - graphical tool for creating Windows registry-based key mappings. Detects the key that you press so knowing the scancode is not required.
[*]
AutoHotkey - powerful key map scripting tool
[*]
PassMark KeyboardTest and
kishy's custom layout file - useful for verifying functionality of your keyboard
[*]
WfpReplace - tool which assists in replacing files protected by WFP (Windows File Protection), including the PS/2 port driver
[*]i8042prt.sys - latest version kishy has is
here (it's not just you, the link sucks. will fix in the future, sorry), but there's a newer one floating around out there...
[/list]