Thorbjørn Ravn Andersen <
thorbjoern@gmail.com> wrote:
I have been doing some disassembly work on my Macbook with RunCPM as
the CP/M emulator (it works with files, not disk images) and it works
fine. What took 5 minutes in the old days, now executes in fraction of
a second. Life is great. Looking at putting it in Github Actions too.
Now my question is whether this is the fastest this can be run to save
cycles on Github Actions, in other words, am I using the fastest Z80
emulator available, and found it very hard to locate any recent
comparison, so I thought I'd ask here :)
Is there a recent benchmark of Z80 emulators?
(I think the "save cycles" above explains why this isn't entirely
pointless... though it is still fairly pointless.)
Of the ones I ended up testing a year or two ago, the fastest was
actually the old yaze 1.10. This was as tested on a Raspberry Pi 3
underclocked to Pi 2 speed (so not exactly the fastest computer),
though I was purely measuring how fast "zexdoc" would run (which takes
hours on most real Z80s) - not necessarily a good benchmark. I was
primarily checking how well the Z80 emulations were working, I just
happened to time the runs too.
The run times I got, in seconds:
100 yaze 1.10 (modified to get it compiling again)
130 zxcc 0.5.7
132 yaze-ag 2.40.5
267 RunCPM 4.4
389 nc100em 1.2 compiled with no speed limiter
463 z80pack 1.3.7 (modified to avoid opcode trap exits)
10346 nc100em 1.2, speed-limited NC100 emulation at 4.606MHz
The 10346 figure should be realtime for a Z80 of that speed. [1] I
also got a similar time on a real NC200.
I think the times suggest these effective Z80 speeds, in MHz:
476 yaze
366 zxcc
361 yaze-ag
178 RunCPM
122 nc100em, no speed limiter
103 z80pack
I should probably redo these tests somewhen as I'm not certain of the
compiler flags used in each case, though I believe they were mostly
just using gcc with -O3. Hopefully they give a general idea at least.
Anyway, RunCPM seems like a decent enough emulator with some handy
features, whether it happens to be the fastest or not.
-Rus.
[1] More or less. It isn't a perfect comparison figure, as zexdoc
mostly leaves interrupts enabled and an NC100 running ZCN has a 100Hz keyboard-scan interrupt slowing down user program execution more than
on "real" CP/M machines, I suspect. It should only be about a 3%
slowdown in this case, so I've ignored it. Also, I should note that
zexdoc may actually overwrite some of ZCN as I think it writes to some
high memory without checking the TPA size - so it's not generally
something I'd recommend running like this. :-)
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)