OT(?): Emulation XKCD

[Rob Jarratt]

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