31 Oct
2019
31 Oct
'19
1:26 p.m.
In my MU5 emulator I have attempted to do all I/O at the speed it would have been done in
the real hardware. Not because I think the OS might be sensitive to it (I don't know
as I don't have any OS running on it), but simply because if/when ever it runs an OS I
want the experience to be as close as possible to what it was originally. I even slow down
the console output to actual Teletype Model 33 speed. I will add options to run at host
machine speed at some point though.
Regards
Rob
-----Original Message-----
From: cctalk <cctalk-bounces at classiccmp.org> On Behalf Of Charles Anthony
via cctalk
Sent: 30 October 2019 21:36
To: Tapley, Mark B. via cctalk <cctalk at classiccmp.org>
Subject: Re: OT(?): Emulation XKCD
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.
The XKCD is dead on for me. I have had that conversation.
-- Charles