ZXR 0.1c (updated)

[shoggoth]

Hi people,

New ZX Spectrum emulator below (updated 2018-09-23):
https://www.dropbox.com/s/j3n1cewmkb6ic ... c.zip?dl=1

It's aimed at Falcon/TT or higher, and probably needs fastram and a 32MHz CPU for most stuff. If you're only playing Manic Miner, you could probably do so on a plain Falcon, with some slowdown.

Now tested successfully on EmuTOS, TOS404 and TOS306. The latter has also been tested successfully with STFA for beeper sound emulation.

If you decide to try it, I'd be happy to know how it works for you!

[penguin]

Just tried it out with Hatari Falcon emulation/14 MB ST/64 MB TT ram. The TAP dumps of Jet Set Willy and Skool Daze didn't work (black screen), while the SNA of a text adventure did start up but didn't recognise any keys. It's not using the original Spectrum font, I assume? Manic Miner (https://www.yoyogames.com/blog/421/bina ... ner-part-1) freezed on the title screen.

It's a pitty though that no 128k emulation is planned. The three Speccy emulators for the Atari only support the 48k model.

So I wonder - is this a personal coding challenge for yourself? Zx_Sp already does a fine job emulating the Spectrum, it has a more user friendly UI and high compatibility with classic games.

Another suggestion: Get a website to host this emulator. It will get buried quickly if it only appears in a single forum post...

[CiH]

I'm not at home but will try this next week.

Is this using a new z80 core, as mentioned in the past? If so, can this be repurposed for other z80 based emulators, eg. Amstrad CPC, MSX and even an up to date ZX81?

[ctirad]

Is this emulator a new one or some port?

[shoggoth]

Just tried it out with Hatari Falcon emulation/14 MB ST/64 MB TT ram. The TAP dumps of Jet Set Willy and Skool Daze didn't work (black screen), while the SNA of a text adventure did start up but didn't recognise any keys. It's not using the original Spectrum font, I assume? Manic Miner (https://www.yoyogames.com/blog/421/bina ... ner-part-1) freezed on the title screen.

I just loaded Manic Miner (TAP), Jet Set Willy (Z80) and Skool Daze (TAP) from World of Spectrum w.o. problems, so I guess I need more info. (remember to type LOAD "" when loading .TAPs).

Anyway this is a very very early release (hence 1.0a), so TAP-emulation is very very rudimentary at this point. Lot's of TAPs won't work, but in many cases the equivalent Z80/SNA/SLT often do (though some games won't work anyway due to bugs in the core).

[shoggoth]

If so, can this be repurposed for other z80 based emulators, eg. Amstrad CPC, MSX and even an up to date ZX81?

In some cases, yes. It doesn't support paging however.

[shoggoth]

Is this emulator a new one or some port?

It's new

[penguin]

Just tried it out with Hatari Falcon emulation/14 MB ST/64 MB TT ram. The TAP dumps of Jet Set Willy and Skool Daze didn't work (black screen), while the SNA of a text adventure did start up but didn't recognise any keys. It's not using the original Spectrum font, I assume? Manic Miner (https://www.yoyogames.com/blog/421/bina ... ner-part-1) freezed on the title screen.

I just loaded Manic Miner (TAP), Jet Set Willy (Z80) and Skool Daze (TAP) from World of Spectrum w.o. problems, so I guess I need more info. (remember to type LOAD "" when loading .TAPs).

Strange... Basic won't show up for me at all (black screen). But this was just a quick test anyway, will have to take a closer look soon. I will get back to you with more info after I've spend some time with the emulator.

[shoggoth]

Strange... Basic won't show up for me at all (black screen). But this was just a quick test anyway, will have to take a closer look soon. I will get back to you with more info after I've spend some time with the emulator.

It's currently that not well tested on real machines (just Hatari + EmuTOS), so there may be some funny bugs to sort out.

[CiH]

CiH wrote:
If so, can this be repurposed for other z80 based emulators, eg. Amstrad CPC, MSX and even an up to date ZX81?

In some cases, yes. It doesn't support paging however.

So lack of paging rules out 128k systems I guess?

[shoggoth]

CiH wrote:
If so, can this be repurposed for other z80 based emulators, eg. Amstrad CPC, MSX and even an up to date ZX81?

In some cases, yes. It doesn't support paging however.

So lack of paging rules out 128k systems I guess?

Maybe not forever, but it's probably on the bottom of the list.

[CiH]

I've done a little bit of random and unscientific testing.

Nothing as yet on real hardware. Screengrabs are below. You will note that I've made up a fantasy TT running EmuTOS.

Any mention of a real (Falcon 4.04) TOS will get as far as the title screen and then it hangs. no keys work and Hatari as a whole has to be reset. EmuTOS and the keys work, including the screen rendering and exit keys.

Atic Atack and Alien 8 were reasonably quick, Jet Set Willy slower, and Jetpac was playable.

atick.jpg

jetset.jpg

jetpak.jpg

littledemo.jpg

[mlynn1974]

Very nice! I'll need to try that on Hatari.
A few years ago did you convert James McKay's X128 V0.5 to the Falcon?
https://x128.speccy.cz/x128wip/x128wip.htm

"It was shown for the first time at the Nordic Atari Show. It's a bit slow and needs a fast machine, but future versions should have much faster screen rendering."

I think 128k emulation would be great. It would be very interesting to hear 128k sound from a Falcon.

[shoggoth]

Very nice! I'll need to try that on Hatari.
A few years ago did you convert James McKay's X128 V0.5 to the Falcon?

Yes, that was me. IIRC x128 works really well on a 060 class machine, and it runs nicely in a window on FreeMiNT/XaAES. Not everyone has a 060 machine though, hence ZXR was born. System requirements are still "high", but it should work well on a TT with fastram (remains to be seen though, since I'm a bit stuck in emu-land atm).

I think 128k emulation would be great. It would be very interesting to hear 128k sound from a Falcon.

ZXR emulates the AY, since that's actually supported by some games:
http://zxspectrum48.i-demo.pl/48K_AY_games.html

EDIT: Just tried Silkworm, and indeed it has 128k sound

[ctirad]

Do you think about implementing a GEM output mode some day?

EDIT: BTW, do you use YM for sound, or you have an AY software emulation?

[shoggoth]

Do you think about implementing a GEM output mode some day?

EDIT: BTW, do you use YM for sound, or you have an AY software emulation?

I use the YM for sound since it’s 1:1 compatible. This implementation does not support sampled sound on the ”AY” however (hence I added Covox support instead).

For GEM usage, it’s better to use x128 + a faster machine, I think. It’s not complicated to add it, but it doesn’t make sense since the aim is to work well on ”slower” machines.

[shoggoth]

Updated (see initial post). It's only a minor update, and I haven't looked at any TOS4 issues yet (sorry!).

Changes:
- tape auto load support (no need to type LOAD "" to start loading)

EDIT: Tried it on TOS 4.04, and it works for me (tried Manic Miner and Zynaps; Manic Miner seems to run at ok-ish speed on a stock Falcon if you turn off the music (press K during the game)).

[shoggoth]

Updated, again. It seems I didn't configure the sound matrix properly, perhaps this version works better (mainly affects beeper sound emulation on Falcon).

[Eero Tamminen]

I tried some ZX program with this in Hatari emulator and it worked pretty well, so I tried profiling it a bit.

Just having EmuTOS symbols looks a bit too boring:

Code: Select all

Visits/calls:
  47.78%      265389   _xbiostrap
  47.78%      265389   _buffptr
   1.09%        6053   _int_timerc

Executed instructions:
  86.72%    97701128   PROGRAM_TEXT
   7.77%     8757837   _xbiostrap
   5.18%     5838558   _buffptr

Used cycles:
  86.58%   840747965   PROGRAM_TEXT
   8.25%    80103067   _xbiostrap
   4.72%    45837940   _buffptr

Instruction cache misses:
  88.35%    22177357   PROGRAM_TEXT
   7.54%     1893365   _xbiostrap
   2.94%      738047   _buffptr

Data cache hits:
  80.15%    27172634   PROGRAM_TEXT
  17.97%     6092250   _xbiostrap
   1.57%      531022   _buffptr

-> Maybe you could you include debug symbols to the TTP binary, so that I can get better profiles?

ZXR querying the playback pointer with Buffptr() XBios call seems somewhat expensive, at least with TT/EmuTOS:

• With TOS v3.06, ZXR doesn't do any XBios calls and TOS takes 0.5% of all cycles
• With TOS v4.04, ZXR does Buffptr() calls and TOS takes 4% of all cycles
• With EmuTOS, ZXR also does Buffptr(). On Falcon, it takes 3%, but on TT it takes 13% of all cycles! 8% goes to XBios trap handling and 5% of the cycles goes to the XBios function itself

-> Is ZXR calling Buffptr() a lot more with TT / EmuTOS, than with any other machine / TOS combination?

(All the executed program code outside of TOS seems to be in TT-RAM, but I think Hatari still accounts same amount of cycles for TT-RAM as for things running from the normal RAM, i.e. in reality the TOS portion impact is probably even slightly higher.)

Could you recommend some particular (e.g. *.z80) image which seems particularly slow with ZXR, but otherwise works fine, for profiling?

[shoggoth]

Nice New binary (identical to the other one, except for symbols):
https://www.dropbox.com/s/4hsfkxcohlls2 ... d.zip?dl=1

About XBIOS sound; I poll Buffptr() to synchronize CPU and beeper emulation. The idea is that the faster the machine, the more time is spent in Buffptr(). On a slow machine (Falcon @ 16MHz), things become a bit funny since frames are missing, and hence I attempt to sync on the next frame instead. Improvement is needed.

[Eero Tamminen]

Thanks!

I did a small profile of a game idling, reviewed the save profile assembly to see whether all RTS & RTE instructions (i.e. ends of subroutines) are followed by a symbol name for the code in next subroutine. At least code following sys_main() is missing one such symbol name.

Here's the result of that TT/EmuTOS profile (generated callgraphs are attached):

Code: Select all

Visits/calls:
  27.72%     5917971   cmd_xx
  27.71%     5917253   xx_im0
   3.62%      773570   nxtjmp
   3.57%      763314   xx44
   2.62%      559091   xx24
   2.14%      456882   xx113
   1.92%      410569   xx40
   1.75%      373890   cpir1
   1.69%      361908   ldir1
   1.55%      330708   xx26
   1.51%      321342   xx161
   1.47%      314320   xx28
   1.11%      238033   cmd_XY
   1.10%      234918   xx126
   1.04%      222465   cmd_IX

Executed instructions:
  19.56%    17754209   cmd_xx
  14.71%    13354112   loop8
  13.04%    11835045   xx_im0
   7.39%     6710748   _xbiostrap
   5.05%     4580310   xx44
   4.93%     4473832   _buffptr
   2.53%     2295018   cpir1
   2.46%     2236568   xx24
   2.08%     1886388   xx28
   2.01%     1827712   xx113
   1.59%     1447530   _sys_main
   1.46%     1322916   xx26
   1.12%     1017111   xx40
   1.06%      964088   xx161
   1.04%      939812   xx126

Used cycles:
  24.92%   194939933   xx_im0
  17.70%   138501136   loop8
  10.52%    82276625   cmd_xx
   7.85%    61390161   _xbiostrap
   4.49%    35128272   _buffptr
   3.36%    26250372   xx44
   2.25%    17617400   xx28
   1.62%    12691594   xx161
   1.60%    12525483   _sys_main
   1.56%    12200190   cmd_CB
   1.47%    11488893   xx113
   1.38%    10815638   cmd_XY
   1.15%     8966718   cpir1
   1.10%     8607059   xx230
   1.07%     8378530   xx40
   1.03%     8035183   xx26

Instruction cache misses:
  51.58%    10449813   loop8
  17.80%     3605506   xx_im0
   7.17%     1451845   _xbiostrap
   5.36%     1085764   _sys_main
   3.11%      630050   xx28
   2.79%      566014   _buffptr
   1.25%      253142   cmd_CB
   1.16%      235005   xx40
   1.04%      211258   cmd_XY

Data cache hits:
  27.16%     7400745   loop8
  17.68%     4816412   cmd_xx
  17.13%     4667675   _xbiostrap
  10.22%     2784810   xx_im0
   2.56%      698503   xx113
   2.04%      557100   xx24
   1.86%      506536   xx26
   1.52%      413441   xx44
   1.50%      408421   _sys_main
   1.49%      406898   _buffptr
   1.24%      338298   cpir1
   1.17%      318569   xx54
   1.15%      313194   xx28
   1.12%      305744   ldir1

Here are some instructions on how you can do profiling too.

First enable profiling in Hatari debugger:

Code: Select all

profile on

Then at the start of the place you want to profile, drop into debugger and continue, to reset profiling stats.

And at the end of the part you want to profile, invoke debugger again, and save the profiling data:

Code: Select all

profile save profile.txt

Get symbols for the program:

Code: Select all

gst2ascii -l -a -o zxrectum.ttp > zxrectum.sym

List most expensive functions and create callgraphs:

Code: Select all

hatari_profile.py -a etos512k.sym -r zxrectum.sym -s -t -p -g --ignore-to _timer_new,nxtjmp,ikbd_endit  profile.txt

(Above will use both EmuTOS & ZXR symbols, and it ignores program flow changes to few addresses to make the graphs more readable.)

gst2ascii & hatari_profile.py are part of Hatari:
https://hg.tuxfamily.org/mercurialroot/ ... s/debugger

To view the callgraphs, you could use "dotty" from GraphViz, but I (much) prefer XDot:

Code: Select all

apt install xdot

Then to view callgraph of instruction usage:

Code: Select all

xdot profile-1.dot

And view CPU cycle usage:

Code: Select all

xdot profile-2.dot

[shoggoth]

Thanks for the instructions Eero! I've always wanted to do profiling but never learned the procedure (actually I use a logic analyser for profiling at work, since I never figure out how to use the proper tools).

All the top entries are inside the CPU core. cmd_xx is a dispatcher for a range of multi-byte opcodes, and I could most likely optimise it a bit

[Eero Tamminen]

Ok. Looking at the (attached) profile assembly, "xx_im0" (which takes more cycles than "cmd_xx") is actually latter part of the "cmd_xx" subroutine, so looking at the whole indeed makes sense.

Btw. Have you looked at the callgraphs yet? Do e.g. calls to "cmd_xx" look sensible, or does it get called more through some route than expected?

Also, "loop8" causes half of the instruction cache misses in the whole profile. Would it be possible to split that large loop into smaller loops that would fit within i-cache?

Note that profiler can be used to validate optimizations too. Just set breakpoints before and after the part you want to profile. Once code hits the latter breakpoint, debugger shows how many instructions and cycles were spent between the debugger invocations.

And if things actually took longer than before optimizations, you have the profile & annotated disassembly ("profile save profile.txt") where you can check in details what went wrong... Often I just check the instruction count stats in the disassembly to see typical flow within the code.

[Eero Tamminen]

Tested few 48k TAP files from World of Spectrum with Hatari TT/EmuTOS combo.

While others worked fine, Cybernoid came up just with a black screen: http://www.worldofspectrum.org/infoseek ... id=0001196

[sashapont]

Can you port it for FireBee?