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?

Thanks
/Thorbjørn

No there are no recent benchmarks, pretty much pointless nowadays. All the major emulations run
stuff in a fraction of a second, so this is not an issue. The major differences are in emulation level,
hardware vs BIOS emulation, cycle correct machine or not so, and so on and forth. Most people
decide on the features they need and not on the speed.

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. :-)

I may as well make a quick correction to that footnote...

Russell Marks <zgedneil@spam^H^H^H^Hgmail.com> wrote:

> 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

I suspect this is wrong. There's apparently a Sega Master System port
of zexall that writes to system RAM at e.g. C06Fh, but there's no
obvious evidence of writing to high memory in the same way by the
zexdoc.com I was using (from yaze 1.10, also included with yaze-ag).
Presumably I confused the two, as I do remember reading about a bug
found in the SMS version.

-Rus.