10 Jan
2001
10 Jan
'01
5:34 p.m.
At 09:46 PM 1/8/01 -0500, you wrote:
-----Original Message-----
From: Jim Battle <frustum(a)pacbell.net>
You are absolutely on the mark -- the test program that exposed this
did read the key code before clearing the flag.
For instance, the first version of the emulator
would convert each
windows keystroke into an emulated "strobe" of a keystroke register.
But then my first user noted a discrepancy in a program he tried.
... Thus, one keystroke can appear twice
in these circumstances.
... It could be if someone was reading keystokes on the
fly
something bad can occur but not reading the key pressed status first is
bad programming. ...
I guess we should distinguish between how many keys of buffering
it has vs rollover. The Sol keyboard can latch only one keystroke.
However, there is a small RAM on the keyboard that maintains
per-key state. You can press each key and not release it until
all other keys are pressed and each will emit a single keystroke.
I was using a bit of hyperbole by saying infinite rollover.
Things get really weird when the REPEAT key is held down. It
inhibits scanning for new keys and simply repeats the most recent
key over and over. But if you release that most recent key, then
the next one it reports depends not on the order it was pressed,
but the order the keyboard circuit scans the keyboard. I went
through the circuit in detail in order to emulate it, but decided against
doing a full-out emulation since it didn't matter, it wouldn't be trivial,
and it wouldn't really be noticed.
A perfect emulation isn't possible for other reasons anyway.
On the Sol keyboard, "@" is an unshifted key. CTRL-@
produced a 0x00 code. On the PC keyboard (mine, anyway),
@ is above the 2. So the emulator specificially looks for
SHIFT-CTRL-2 and emits 0x00 in that case. So far, so good.
But on the Sol, CTRL-2 and SHIFT-CTRL-2 both produce 0x02.
I can't have both.
-----
Jim Battle == frustum(a)pacbell.net
Now for an example of behavior I'm not going
to bother with.
The Sol keyboard has infinite key rollover.
...
No it didn't. The encoder may have had Nkey rollover but it was anything
but
infinite. There was at best one byte of buffereing. If you read the
buffer fast
enough you can stay mostly ahead of it but most software of the time
didn't
buffer what it got so the last key read was it.