8 Jan
2001
8 Jan
'01
8:46 p.m.
-----Original Message-----
From: Jim Battle <frustum(a)pacbell.net>
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.
After thinking about it a little bit, we realized that the difference
was
because the real Sol generates an approximately 6 us
strobe when
a key is hit, asynchronously setting a "key ready" flop. If the
processor
polls this register, the flop gets cleared, but if it
polls it before
the
6 us strobe is finished, then reading it doesn't
clear the flop since
the async strobe has priority. Thus, one keystroke can appear twice
in these circumstances.
This is an oddity but remember the 8080 is 2mhz (5us for an INP
insturction)
so this only can occur if the buffer read should occur within 6us of the
status
read. Typically the code is something like this:
keywait: INP status
ani keyflag
JNZ keywait ; back to top may be a JZ
INP keydata
...
The delay from the first input to the second is 10+7+7 (24 cycles or
12uS) if
the J(n)Z is not taken and much more if it is so the race condidtion it
typically
not a problem. 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.
After looking at the drawing It appears the Key ready goes to a JK flop
/K input and is not async as the data (strobe) is loaded on the falling
edge of Phase2 clock. So the behavour observed is unlikely and
the read/clear has precedence. While Phase2 occurs once every
~500ns it is possible to clear and reset making the key buffer hold
what amounts to bounce (read twice). Also the Osc used for the 3uS
clock in the keyboard is a TTL RC thing that likely has a +-25% error
(times two as it's divided by 2) adding to the already long strobe.
In the end it would take a pathological programming case to make
that keyboard behavour show.
One thing I'm planning on adding is intermittent
disk errors -- the
reason
is that I want to eventually rewrite my CP/M BIOS and I
would
rather test it on the emulator. Without failure simulation, then too
much of the BIOS would go untested.
The assumption is the bios has error retry, many early bios did not.
You got an error and the system you give you retry or ignore both usually
fatal if bad data was read.
Some of the early 8251 serial (UART) devices had a timing thing
that could cause the reverse action. Never assume all devices
are infinitely fast compared to the cpu.
Now for an example of behavior I'm not going to
bother with.
The Sol keyboard has infinite key rollover. On my PC, either the
keyboard or the driver stops giving KEYDOWN messages after
about four keys are down. Perhaps there is some way to get that
extra info, but I'm not going to bother. I don't see any reason to
emulate that extra behavior, so it won't go in.
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.
Allison