I'll chime in a little bit late now that you've got it figured out. In troubleshooting it's good to know how things are supposed to work, at least enough to narrow down whether the problem is most likely hardware or software. Based on the symptoms and the fact that you are running on real hardware pretty much eliminates this being a software problem.
In PS2 (and earlier) keyboards, the Typematic rate is controlled by the keyboard hardware. The communication between the keyboard and the computer (the keyboard controller in the computer) is a relatively simple serial communications link that sends small packets of data. The computer (BIOS) sends a packet of data to the keyboard telling it what the Typematic rate should be and the keyboard hardware handles all the details as keys are pressed and released afterward. Eric's DEBUG example talks to the BIOS, and the BIOS in turn talks to the keyboard over the serial communications link. The fact that your keyboard is sending some data indicates that the communications link (including the cable between the keyboard and computer) is probably OK, and so is the keyboard controller in the computer. The problem, as you discovered, is in the keyboard itself. If you're feeling ambitious you can try to open up the keyboard and see if there's anything obvious (like a broken wire or something), but it's probably best just to toss it. A couple of things to note, though. In the packet protocol that is used, there is no way to ask the keyboard what the current Typematic rate is. So, the BIOS needs to keep track of it internally. There is a standard BIOS function to retrieve the current Typematic rate, but a lot of BIOS's don't implement it. When it is implemented, the BIOS needs to keep track of the Typematic rate internally since it can't query the keyboard about it. Another thing to keep in mind is that the (CapsLock, NumLock, and ScrollLock) LEDs in the keyboard are NOT controlled by the keyboard itself but are instead controlled by the computer (BIOS). When you press the CapsLock key, for example, it causes the BIOS to send a packet of data to the keyboard to change the state of the LED. The keyboard just does whatever the computer tells it to do when it comes to lighting the LEDs. Also, it is not possible to tell the keyboard to change the state of just one LED -- you need to send the state of all three LEDs as a single packet of data. And, similar to the Typematic rate, there is no way to query the keyboard about which LEDs are currently turned on so the BIOS also needs to keep track of that internally (but unlike the Typematic rate, there are standard BIOS memory locations where the LED statuses can be found). If you're running inside a Virtual Machine (VM), as Eric noted sometimes the Virtual BIOS doesn't respond to Typematic rate requests. I've never seen that problem with real hardware, though I suppose it's possible. Another thing that can happen inside VMs is that the state of the LEDs on the keyboard doesn't always stay synchronized. For example, the CapsLock state can be On in the Host (usually Windows or Linux) and Off in the Guest (DOS), and the CapsLock LED on the keyboard should (at least theoretically) change to reflect the state of whichever application currently has the focus (the Host or the Guest). I'm not sure that happens correctly all the time. I know I have lots of keyboard problems in my VMs, including the fact that the state of the keyboard LEDs is not always synchronized properly. Lastly, all the above stuff only applies to PS2 and older keyboards and does not apply to USB keyboards. In a sense, USB keyboards are dumber than PS2 keyboards in that all they do is provide information about which key(s) are currently pressed. All the Typematic related stuff and keeping track of when keys are released must all be handled in software since the USB hardware doesn't handle any of that. _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
