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

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

penguin wrote: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.

penguin wrote: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.

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

You do not have the required permissions to view the files attached to this post.

mlynn1974 wrote: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.

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?

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.

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

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

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.