The other day I tried running NSNIPES, a multiplayer networked game that came with old versions of NetWare. The game worked fine, but I couldn’t get out of it. Esc did nothing, any “usual” combinations like Alt+X, Alt+Q or similar had no effect. So I found the game documentation (because of course it was documented in NetWare reference manuals just like any other program shipped with NetWare), and learned that to quit the game, one has to press Ctrl+Break.
Only pressing Ctrl+Break elicited no reaction from NSNIPES. But then I noticed that pressing Ctrl+Scroll Lock did. So… why is that?
There are really two mostly separate questions. Why does NSNIPES treat Ctrl+Scroll Lock as if it were Ctrl+Break, and why does actual Ctrl+Break not work, or only works very intermittently? Let’s answer that one at a time…
Finding the answer to the first question is pretty easy. The original PC had a Scroll Lock key (scan code 70 decimal or 46 hex). When pressed together with the Ctrl key, the Scroll Lock key functioned as a Break key because that’s how the PC BIOS treated it.
The Enhanced 101/102-key keyboards added a separate Pause key; the key is special and when pressed together with Ctrl, it produces a sequence simulating the press and release of a key with scan code 46h but prefixed with E0h. When the key is released, no further scan codes are generated. The Pause/Break key is the only key on a standard keyboard which behaves in this manner.
The 1986 PC/AT BIOS and later systems only trigger Ctrl+Break functionality when the E0h prefix is seen. Older BIOSes ignore the E0h prefix and trigger Ctrl+Break in response to both Ctrl+Break and Ctrl+Scroll Lock.
OK, so that probably explains why NSNIPES reacts to Ctrl+Scroll Lock, but not why it misses Ctrl+Break. Or at least misses Ctrl+Break most of the time.
As it turns out, NSNIPES has its own keyboard interrupt handler (IRQ 1) and completely bypasses the system BIOS. The strategy NSNIPES uses is not unreasonable: The program keeps an array reflecting the state of all keys indexed by their scan code, which is updated by the interrupt handler and periodically checked by the main routine.
The problem is apparently that the main routine does not run in a tight loop and “only” checks the keyboard state several times a second. If the user pressed and released a key really quickly, NSNIPES might miss it. That does not happen in practice because human fingers aren’t that fast.
But microcontrollers simulating human fingers are. Remember the Ctrl+Break key behavior which simulates both a press and a release when it is pressed? This poses no problem to the system BIOS which keeps track of the current modifier key state and processes each scan code as it comes in.
But NSNIPES is different. The simulated key press/release sent by Ctrl+Break on an Enhanced keyboard is fast (somewhere in the range of several milliseconds), much faster than a human. If the NSNIPES game loop does not happen to check the keyboard state in the brief instant between receiving the 46h scan code indicating a key press and the C6h scan code indicating a key release, it will completely miss the key.
And of course the reason why Ctrl+Scroll Lock actually works in NSNIPES is because it behaves like other keys, meaning that it does not send the key release scan code until after the user actually physically releases the key. Hence NSNIPES has enough time to see it pressed. And because NSNIPES is old, it has no special logic for Enhanced keyboards; as far as it is concerned, Ctrl+Scroll Lock is Ctrl+Break.
The joys of backward compatibility.
Makes me wonder if maybe back then there were TSR tools to try make 101+ keyboards compatbile with old games.
Avenu 1: “The original IBM-PC keyboards (using the old XT interface) used “scan code set 1”. The new AT keyboards generated different scan codes, or “scan code set 2”. This change would have created compatibility problems for software that was expecting different scan codes from the keyboard. To avoid the compatibility problem, the keyboard controller supports a translation mode. If translation is enabled the controller will translate “scan code set 2” into “scan code set 1″.”
That said, i remember some old keyboards even had a DIP-switch for XT mode or AT mode.
If there was a standard way to re-enable this mode on any AT-compatible, then this should’ve solved it the most generic way.
2. This would be tricky, but i8042 was a computer in itself. Again, not sure about standard (compatible with any AT clone) ways, but at least Compaq 386 manuals felt like hinting that one could even re-program that i8042 completely and at least one could modify the values in it’s I/O ports. If so, then suvh a hypothetical TSR would, like Windows itself, move the hardware interrupts table to unused high indexes, then use their own handlers to simulate needed inpurs on i8042 ports and call the Int 09h programatically.
http://www.techhelpmanual.com/96-irqs__hardware_interrupts.html
https://wiki.osdev.org/%228042%22_PS/2_Controller#Hot_Plug_PS.2F2_Devices
The 8042 is programmable, but not end user programmable. Typical keyboard controllers were either ‘OTP’ (One Time Programmable) or manufactured with a code ROM. Only development chips were usually actually programmable.
The DIP switch on switchable AT/XT keyboard changed the scan codes, possibly more. There is some evidence that IBM PC/AT machines could support XT keyboards, but this was not used in practice. Possibly because the set of keys was slightly different, possibly because XT keyboards had no LEDs. Technically it would have been possible to use a XT keyboard and not translate the scan codes, but perhaps IBM felt that keyboards were confusing enough already and there did not need to be yet another possible configuration.
I’ve never come across a 286 or newer that would work with an actual PC/XT keyboard.
The switch not only changes scan codes and whatnot but also changes the protocol, so you need a PC/XT computer for the XT switch position to work and a AT/286+ computer for the AT switch position to work.
Btw it was probably super uncommon but I’m 99% percent sure that the keyboard controller on the main board on a Compaq 386 SX 16 I scrapped perhaps 25 years ago was actually reprogrammable. (I assume that it would be an 8742 as intel usually has a 7 in the model numbers of reprogrammable microcontrollers). I’m also pretty sure I was able to do something with it using my Data-I/O Unisite universal programmer, but I can’t remember if I “only” was able to identify the chip or possibly even read out the program of it. I should have that chip somewhere but the Unisite is unfortunately broken and I doubt that my Hi-Lo systems ALL-03 would be able to read that chip.