On Wed, Feb 21, 2018 at 2:11 PM, Chuck Guzis via cctalk <cctalk@classiccmp.org> wrote: > For what it's worth, I differentiate "cycle correct" from "real time".
Agreed. I've been testing Z-80 emulators over the past year because a CP/M game (Scott Adams' Adventures) depends on the R register being refreshed as the cycles tick on because it's used as a cheap source of entropy for the RNG. It doesn't happen to matter if it's 100% cycle exact for the game to work (though a less thorough implementation _does_ affect the RNG) and it doesn't matter at all how many real-world microseconds have elapsed. The issue comes about because some simple Z-80 implementations (including the version of the Altair emulator that came out with SIMH 3.9) didn't bother to implement the R register because in a real Z-80 the primary purpose of it is to generate 7-bit refresh timing for 16K (and some 64K) DRAMs. With no need to refresh emulated RAM, R wasn't ever incremented. A 100% cycle-correct implementation of R is slightly complicated because of the circumstances of which exact part of a complicated cycle sequence do and do not increment R. I made some non-functional code work just by hacking emulators to blindly increment R once for every instruction. Not 100% correct, but correct enough. > Putting it another way, one can maintain a cycle counter in an emulator > whose contents are updated when certain tasks have been accomplished. Yes. The 100% cycle-correct R implementation just has to track the amount to increment R for each specific class of instruction to attain the original behavior. Altair for SIMH has been fixed, and I can say that the Z-80 emulation for the Commodore 128 in VICE has been correct for quite some time (I didn't do a lot of regression testing there - every version I tried, worked.) So, yeah... there is code out there that depends on buried features specific to hardware implementation of cycles - but time-correct emulation is not often required. -ethan
