[Simh] Simulator development: Advice on system timing

[Armistead, Jason]

If you need accurate device timing, then perhaps something like the core of MAME/MESS is a better choice than SIMH.  All those retro arcade machine games in MAME depend on counting cycles in order to give realistic game behavior for the human who is playing them.  If they ran twice as fast, they'd be unplayable (or at least, very challenging), so everything is carefully handled to ensure it runs smoothly at a realistic rate.

Maybe not the answer you're looking for, but it is one alternative.

-----Original Message-----
From: Simh [mailto:simh-bounces at trailing-edge.com] On Behalf Of Paul Koning
Sent: Thursday, 26 October 2017 2:16 PM
To: Seth Morabito
Cc: simh at trailing-edge.com
Subject: Re: [Simh] Simulator development: Advice on system timing


> On Oct 26, 2017, at 1:55 PM, Seth Morabito <web at loomcom.com> wrote:
> 
> Hello all, and especially those who have written or are writing 
> simulators,
> 
> I'm battling system timing in the 3B2/400 emulator I'm working on. As 
> with any system, particular activities such as disk seeks, reads, and 
> writes must be completed within certain margins -- if they happen too 
> early or too late, an interrupt will be missed. But the "fudge 
> factor", so to speak, seems pretty tight on the 3B2, possibly because 
> it runs at a system clock frequency of 10MHz.

In most systems, odd things can happen if interrupts happen too soon.  If an I/O completes essentially instantaneously, then software that relies on being able to start I/O, then do some more stuff, and count on that completing before the interrupt -- even though interrupts are enabled -- will break.

The correct description for such software is "defective" though there certainly is quite a lot of it in the wild.

For this reason, simulators need to delay interrupts by some number of instruction times, and SIMH makes that easy.  But it doesn't normally matter that the timing is not exact, all that's needed in most cases that the interrupt is held off long enough to work around the sort of poorly written code I mentioned.  So if you base your delays on average instruction times and average I/O latency, you'll normally be fine.  In the 3B2 case, with 10 MHz clock and an average of 8 cycles per instruction, that's 1.25 MIPS.  A disk I/O might take 20 ms (1/2 rotation at 3600 RPM), so that would be 25,000 instruction times.  Quite likely you could crank that number way down and have the code still run.

If you want to have realistic timing, that's a different matter.  You'd find yourself tracking the cylinder position and charging for seek timing.  The DECtape emulation does that, and it matters because some operating systems (TOPS-10, VMS) do tape position prediction based on elapsed time.  But that's an unusual case.

	paul


_______________________________________________
Simh mailing list
Simh at trailing-edge.com
https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.trailing-2Dedge.com_mailman_listinfo_simh&d=DwIGaQ&c=ilBQI1lupc9Y65XwNblLtw&r=CeQuuq99aEH_1RE1yGnGXY4AbMg6_1cjkYeJjaT-sd4&m=28teaDEfpeRsG91nozxabV4mdFUU29mk-Z8uKnyQzU8&s=eipMJsFHOejQwt_QvM2i4SQzThEadhwDwVzO6zm-M7s&e=