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-boun...@classiccmp.org> On Behalf Of Charles Anthony > via cctalk > Sent: 30 October 2019 21:36 > To: Tapley, Mark B. via cctalk <cctalk@classiccmp.org> > Subject: Re: OT(?): Emulation XKCD > > On Wed, Oct 30, 2019 at 2:17 PM Tapley, Mark B. via cctalk < > cctalk@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