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
True, I strobe on keydown, I don't hold the strobe down for more than 1uS.
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.
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.
I still don't understand this. The strobe period is typically 1uS, so
there is no chance a new PS/2 char could arrive before I finish my strobe.
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.
This is how I have implemented my interface. THe PS/2
keyboard standard
is an 'n' key rollover implementation, so I just grab the scan code and
convert to ASCII, strobing it into the parallel latch and then repeating
the process.
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).
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).
When you just strobe on keydown, when the next keydown comes along on
PS/2, I just treat it like a new character.
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.
I would agree you can implement that logic internal
(Since C=Key can
also interfaces a KB matrix to PS/2, I implemented a full n-key rollover
scanner with repeat), I decided against re-implementing something
already in PS/2 KBs.
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