21 Feb
2018
21 Feb
'18
1:23 p.m.
On Wed, Feb 21, 2018 at 2:11 PM, Chuck Guzis via cctalk
<cctalk at 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