Because for a parallel keyboard you need a key-down strobe. If you just set the strobe on keydown and clear it on key up, you will not correctly perform rollover - If you are unfamilier with the term, rollover describes what often happens when a typist is trucking along at speed - one key is pressed, then another before the first is released, then the first released, and finally the second (and you usually have a third key happning after the second etc.) If you simply assert key-down on a make, and release it on a break, you get: Press A - Write A to port, assert key-down Press B - Write B to port, key-down is still asserted Release A - Release key-down Release B - key-down is already released In this scenario, you only got one keystrobe at the emulated parallel interface, and one of the keys will be lost. A true typist would throw your keyboard out the window. One way to resolve this is to simply "pulse" key-down, and not hold it down while keys are down - this works for most applications, but not for some games and things which actually use the duration of key-down. If you take this approach, you can ignore key-up codes, and simply write the ASCII value to the parallel port on key-down codes, and strobe the key-down signal on the parallel interface - but you still have to queue data from the keyboard because you cannot process the next key until after you have released key-down on the parallel interface. If you prefer to implement a true key-down signal on the parallel interface, you assert key-down on the key-down scancode, and queue anything occuring until the matching key-up scancode - then you process the codes in the queue, which arranges all the keys "in order". Btw, most parallel keyboards have "two key rollover" which means that you can press one more key while one is down, but not two - this ability is inherent in the key scanning matrix - the keyboard scans until it finds a key and stops the scanner, watching only those lines until the key is released - if another key is pressed in the meantime, it will be detected as soon as the scanner resumes - if more than one extra key is pressed, the one detected may not be the next one that was actually pressed (hence "two key" rollover). This type of keyboard also usually output a key-down strobe for as long as the key is held (bascially the same control signal that holds the scanner). I've implemented a number of keyboards this way, and it's actually quite sufficient for most typists. Fancier keyboards feature 'n' key rollover, which means the scanner runs all the time, and keystrokes are queued so that any number of pending keys can be serviced. These typically have only a key strobe output, so that the queue can be emptied to "keep up" with the guy mashing down keys. Yes they do, but they only repeat the key-down code - you need to maintain your own repeat logic if you want to be able to toggle the key-down strobe while keys are held down (just asserting it again won't make it toggle). My usual approach is once I've received key-down, and am waiting for key-up to release the key-down strobe, I queue anything else received, EXCEPT for the matching key-down code - these I ignore and implement my own repeat logic. But there are many possibilities - you could provide a "positive pulse" in the key-down strobe when you receive secondary key-down codes - this would provide parallel repeat at the same rate as the PC keyboard is providing (and you can program that to a certain extent if you like - I personally like the repeat logic in my code where I am not reliant on the variances between "compatible" keyboards. Regards, Dave -- dave06a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Collector of vintage computing equipment: http://www.classiccmp.org/dunfield/index.html

Thats a pretty short strobe --- although it will be perfectly acceptable on many systems - Others will "go away" to process a key strobe, and may miss the next key if the strobe is short (in certain applications yadda yadda ...) [An example of where this occurs badly is in polled CTRL-C processing on some systems - you need to hold CTRL-C until the software notices that you have a key down - normal operation on polled systems does this to a lesser extent, but it helps to have a long strobe if you don't have a true key-down strobe] Most of the parallel keyboards I've worked with use a true "key down" strobe which stays asserted until you let go of the key - so I like to provide that capability. As noted above, thats a shortish strobe, and given that the keyboard clocks the transfer, you don't really have control over how fast the next data can come in other than "they are supposed to do it somewhere near this rate", but yes - with a short strobe you can in most cases get away with this technique. As a simple approach, this will work as long as the timing fits ... and it is an easy way to do it - you actually need to "undo" some of the PC's nice keyboard features to implement more robust emulation... (I had to "undo" the auto-repeat by ignoring multiple-key downs without key-ups in my PC100 emulator when the "auto-repeat" option is turned off). I should point out that auto-repeat and a true key-down indicator are somewhat multually exclusive - If you want the indicator to stay asserted as long as a key is held down, then having it auto-repeat is contrary to that ... this is why many parallel keyboards have a separate "REPEAT" key - this key simply interrupts the key-down indicator at a regular rate while it is held down. Which is fine for many applications - A generalized parallel keyboard emulation should allow for either case, and you will need to handle the things I mentioned (which isn't hard). Regards, Dave -- dave06a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Collector of vintage computing equipment: http://www.classiccmp.org/dunfield/index.html