Ardent Tool of Capitalism

Keyboard

Hardware Interface Technical Reference, Keyboard 101- and 102-Key

Model M Keyboard
5576 Keyboard Series (Japanese)

Keyboard Trivia
Keying On A Standard by Bob Smith
Keyboard Scan Codes

PS/2 Keyboard Connector Pinout
Signal Voltages
Keyboard Error Codes
   Scan Code Followed by 301 Error
   Error 305
Running Without a Keyboard
Keyboard Emulator
   Dr. Jim Wayne Bobbitt Style Hack
Microsoft Elite Incompatible
Belkin OmniView SE Incompatible

Location of Keyboard Connector (from Peter)

On PS/2s, the keyboard port is the one closest to the power supply.

PS/2 Keyboard Connector Pinout

Signal Voltages

The keyboard and auxiliary device signals are driven by open-collector drivers pulled to 5Vdc through a pull-up resistor.

Keyboard Errors

Scan Code Followed by 301 Error

This error is from a problem with a specific key, in this case the Left-Alt key, scancode 11. The error list above is correct, but confusing.

301 KB reset or stuck-key failure (XX 301 XX = scan code in hex) would result in "Scan Code" "301" or in this case "11" "301".

If E0 or E1 is displayed, one of the "special keys" is sending the first half of their 2-byte code to the system.

Just try it out on a running system - reboot and hold one key until the system restarts. You will end up in the exact error like described. And find the value before 301 in the scan-code tables.

Physical check

To test, which of the keys is malfunctioning, press any key after the other, beginning left / top row down to the right lower key. Any key must act as normal, make an audible "click" when pressed and also immediately after being released again. The feel while pressing must be exactly and not sticky at all. If one key causes no reaction or appears as already pressed suspect it to be the -or one of the- defective.

Error 305

Error code 305 at power-up means "+5 VDC on keyboard missing". This typically indicates a blown keyboard/auxiliary device fuse.

The repair procedure differs depending on the fuse type, but in all cases it's necessary to first remove the fault that caused the over-current scenario (damaged connector or cable, faulty component inside the input device, etc.).

Some machines use a socketed glass fuse that can be easily replaced. Other systems use a through-hole resistor-like fuse that is soldered in. And finally, some selected systems are equipped with a resettable fuse (polyfuse, PTC). Resettable fuse will automatically return to its normal low-resistance state when you turn the machine off and wait a few seconds before turning it back on (once the original fault was removed!).

Running without a Keyboard

Is there a way to get a 95A to boot without a keyboard attached? I want it to boot to NT4 as a file and printer server with no keyboard, mouse, or monitor attached.

Helmut P. Einfalt wins for the simplest suggestion:
   Change the <Set configuration>--<Bypass System Programs on Error> to <Enable>. This will give you an error code on the front panel if no keyboard is plugged into the machine, but it will skip over that error and continue booting NT.
   I'm not sure what the system does when you try to plug in a keyboard once it's running... but you might test its reaction to that.

Ed. Not sure what systems have "Bypass System Programs on Error" or similar. I do know some systems have a "Network Server Mode" though.

Keyboard Emulator

The Guardian for PS/2 - APKME (thanks for the link, Brian Sammon).

From Jim Shorney:
   I was wondering if anyone could help me with finding an inexpensive (i.e. >$20 or less) source for keyboard/mouse emulators.

Get a cheap keyboard, take the microcontroller circuit board out, whack the cable to 6 inches or so, and reconnect the microcontroller board. Do the same with a cheap mouse. Wrap in tape or put it in a small plastic 'project box' to insulate things.

The extent of my idea was to provide a small widget that will allow a turnkey system to come up and perform its designated task without needing to have a real keyboard connected, or requiring any operator intervention. No provision is provided, or needed, to connect a real keyboard in this scenario.

You might investigate Radio Shack's free cuecat. It has a keyboard passthrough, and although the barcode reader puts out garbage on a model 95, the hardware may prove useful for your need.

Fools Rush in Where Angels Fear to Tread

Is there a way to perform the Dr. Jim Bobbitt method of constructing a emulator that will allow for one to plug in a keyboard, run up the system, do whatever, then unplug the keyboard and walk away?

Holy BAT, Batman!

Tim Clarke scrawled:
   What would the results of plugging a second keyboard into the hacked emulator? Would the real KB run a BAT as soon as it got power?

A keyboard *always* sends in a BAT message after power-up, provided that it can control the clock and data lines to it's satisfaction.

Both the Keyboard and Mouse can be disconnected and reconnected to an IBM PS/2 *after* POST and O/S boot has completed. The (A)BIOS "sees" the BAT message from whichever device and re-establishes current state (as kept in the (A)BIOS data area(s)).

This is effectively what happens when using a manual KVM. The biggest bugaboo is that there mustn't be a mouse message "in-flight" at the exact instant of disconnection as the PS/2 mouse protocol doesn't have the "start bit" in the first byte of the message, allowing resync if a message is partially incomplete and a new BAT message comes in. Also, the way in which the physical contacts are broken can cause problems whereby spurious message bytes are "seen"/sent. This is mainly a problem with the mouse, due to the multi-byte messages without sync-bit and usually causes the mouse to freeze or, worse yet, leap about the place and cause the buttons to operate incorrectly.

The above is the situation with direct physical connection (or via a "dumb" manual switch) *and* with O/Ss which correctly use the (A)BIOS to drive the devices at the physical level. Windows drivers *don't* do this. Nor do Linux ones, it would seem, although I have no direct experience of this. So the above doesn't apply to Win 3.x, Win9x and possibly Win2K and NT.

Impact of Cutting Data and Clock Lines

Don Hills hanging on to the underside of the earth wrote:
   Now, a reading from the Good Book(*)...

Traffic on data and clock lines is asynchronous - no keyboard pressing or mouse moving, no traffic. Both lines are high when no traffic, and are standard TTL type open collector at each end. So you can break and reconnect the clock and data lines without problems. Just maintain power to the keyboard and mouse at all times- a weakness of manual switch-boxes, especially if you switch slowly or an intermediate position is not used or has a powered-down system on it. If you're building a smart switch box, design it to not switch until the clock and data lines have been idle for half a second or so to make sure you don't switch in the middle of a transmission.

(*) The IBM PS/2 Hardware Interface Technical Reference Manual.

Hold That Thought!

Dr. Jim Shorney has the prescription:
   Could a flip-flop or other IC catch the current state of the data/clock and hold it for the new KB? The idea is to keep the system from detecting the loss of data/clock during the insertion of the new KB.

One thought: grab some 4066 CMOS quad analog switch chips and wire them to tri-state one keyboard while the other is switched through, and vice versa.

Keyboard Emulator Hack

(Dr. Jim Wayne Bobbitt style)

Wild Bill clears leather with:
   Well, it wasn't hard. The first thing I needed was a busted keyboard. My dad found one alongside the highway that had blown off of a truck. It was all broken, so I opened it up and pulled the controller board inside...after disconnecting all the connections on the board that went to the keys. I left the keyboard cable attached to the controller. To make it look cleaner, I also desoldered the Num, Caps, and Scroll lock LEDs.

I went to RadioShack and got the casing, as well as a 5 volt blue LED. Forget exactly which one it was--but it is black plastic and the package said something about an RS232 port space.

To mount the keyboard controller inside the casing, I ran a screw through part of the casing and a hole in the controller circuit board.

As for the blue LED, that was easy. The LED is 5 volts and so is the keyboard supply voltage. So I looked at your keyboard page to get the pinouts, tested with a DMM, and when I found where +5V and a ground came in, I simply spliced in the LED's wires. (Ed. upper two wires, white and yellow) Then just put the whole mess into the casing, after making place for the LED and cable to come out of.

Microsoft Elite Incompatible

I bought a Microsoft Elite keyboard, plugged it into the keyboard port, fired up the ole 9577 Lacuna and the screen locks at the IBM screen.

From Peter Wendt:
   Uh... that's normal. System self-protection you know... :-) The Elite keyboard has a different keyboard ID than "normal" keyboards have - and it is intended for "ATX" machines AFAIK and behaves different after a power on.

Most likely the 77 Lacuna keyboard controller gets a bit confused by all of that - and hangs the system. Had that with several Cherry "space saving" keyboards with integrated trackball as well.

Belkin OmniView SE Incompatible

From Tim Clarke:
   Just suffered a severe disappointment with these (F1D104u - UK PSU). They *Do Not* work with PS/2 BIOSes, as PS/2s run the keyboard in Scan Code Set 2. The only "workaround" is to disconnect and reconnect the keyboard from/to the KVM after switching to another port. Similarly, when the keyboard is correctly in Scan Code Set 2 the "hot-key" sequence is not recognised. Lastly, although the mouse does continue to work, the "sensitivity" is set to default after a switch.

Al Savage Responds:
   I'm running two OmniViews: one's a four-port SE (I think it's an F1D104, but it's 300 miles away on my server farm right now, running three 8590s and a clone) and a two-port F1D064 here at home. Both work with 8580s and 8590s routinely with no problem. I use the hot key sequence on the four-port most often (<Ctrl-Alt-LShift-n>), and the button select on the two-port mostly. Both methods work.
   Now, ask me about OS/2, scrollms.exe wheel driver, and the OmniView, and you'll get a different story. W95 works fine with Intellimouse/Logitech wheel mouse, but not OS/2 w/the OmniView.

Tim Clarke salvos back:
   From the claimed O/S compatibility list for the F1D104 and the problems I've experienced (in both DOS and OS/2) I assume that Win xxx, Linux and Netware all use keyboard drivers that reprogram the keyboard to run in the non-default Scan Code Set 1. If your OmniView "hot-key sequence" is as described, it sounds like you have an F1D074 or earlier firmware.