OT(?): Emulation XKCD

[Ray Arachelian]

On 10/30/19 5:35 PM, Charles Anthony via cctalk wrote:
> On Wed, Oct 30, 2019 at 2:17 PM Tapley, Mark B. via cctalk <
> cctalk at classiccmp.org> wrote:
>
>> All,
>> my daughter is well aware of my affinity for old computers and software,
>> and, as usual, she pointed out that there’s an XKCD for that:
>>
>> https://xkcd.com/2221/
>>
>> I found this remarkably accurate.
>>
> For the dps8 emulator, I wrote (for expediency) the I/O code to complete
> immediately. When the CPU executes an I/O instruction, the I/O is completed
> and the interrupt posted before the next instruction is executed. As the
> emulator was (at that point) single threaded, there was no performance
> reason to do otherwise, and delaying interrupt delivery was additional code
> that I didn't want to write and debug. The consensus in the Multics
> community was that this was *probably* OK; the interrupt structure was
> robust and the interrupt handling code well written, and should be able to
> cope. But everytime a runtime failure occured, the question popped up: is
> zero-latency I/O the issue?  I ended up adding code to delay interrupt
> delivery as a run-time configuration option so that that possibility could
> be checked.
>

Hi Charles,

I guess it depends on the OS.

For LisaEm, I found that if I did that, it would cause lots of failures
with disk I/O.

So, in my case I keep track of CPUCYCLES since power on in an int64, and
when an I/O event happens, I setup a timer to trigger an IRQ CPUCYCLES+N
later. N varies by device, and I shave down N as close as possible to
not cause issues.

Like in the XKCD, floppy and hard disk access is now ludicrously fast.

The 68000 has 7 levels of IRQs, masked to filter out which it will
allow. Should the IRQLEVEL mask be higher than the IRQ of a device, but
CPUCYCLES>DEVICETIMER, then it will retry again once the mask goes back
down.

Should two device events happen for the same IRQ, it will only generate
one IRQ, and then it's up to the OS to handle the extra I/O for that
device, just as in real life. This shouldn't happen with things like
disk I/O, thought it can for serial port I/O.

So, it's not quite a time series queue, but, kind of.

For things like repeating timers on VIA6522s, or square wave sound
generation from the VIAs, I found that I can't fully get away with tying
their timing to the wall clock rather than the CPUCYCLES clock, so to
make sounds work properly when the user selects a higher CPU clock, I
temporarily slow down the CPU to the original 5MHz while the sound is
playing, and for a little bit longer after that to account for delay
loops between beeps.

Cheers,

-- Ray.