"Real" emulation...

From: ajp166 <ajp166_at_bellatlantic.net>
Date: Mon Jan 8 20:46:29 2001

-----Original Message-----
From: Jim Battle <frustum_at_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
Received on Mon Jan 08 2001 - 20:46:29 GMT