Any emulators able to pause on completon of loading?

[8BitSC]

Do any emulators support a function where on completing a load from tape, tap, tzx, etc. They can PAUSE emulation?

I'm trying to make .z80 images which I can then convert to MDR images using Tom Dalby's Z80onMDR to include the game's loading screen.

Trying in Fuse to pause the emulator at the exact moment the game finishes loading and quick enough to keep the game's loading screen on-screen, (so it becomes part of the z80 snapshot) is becoming a game of reaction-timing.

Having the ability to load, then freeze on completion; allowing the resulting file to be at the loading screen in a (kind of) "press any key to continue/PAUSE 0" state would ease the process of exporting to a z80 snapshot in a neat way, allowing the file to be converted to MDR while keeping the loading screen and every note of any intro-screen music, rather than it missing the first notes, dependant on how quick (or slow) my reactions are.

[equinox]

Do any emulators support a function where on completing a load from tape, tap, tzx, etc. They can PAUSE emulation?

Well, saving a picture out of Art Studio 128 in Spectaculator mysteriously freezes everything until you pause and unpause the emulator. (The tape-handling trap seems to have a bug there.)

In reality: I doubt it. Never heard of such a feature — and it might not work well with custom (non-ROM) loader routines. But it would be great for RZX recordings too, where you want to start from "point zero", and (as you say) not miss any music. You might be able to achieve this using some kind of breakpoint or watchpoint feature in the debugger: you know, pause when register A contains value B, or memory location X is non-zero... I think some emulators support that...? But you would need some pretty technical knowledge about tape loading.

Let us nag emulator authors for this feature. (Also, how come every game console emulator has some kind of Lua scripting system, but the computer ones don't? Is it because we don't have a speedrunning community?).

Quoting reduced by admin

[Seven.FFF]

The usual way is to figure out what the entry point address is, abs put a breakpoint there.

Snapshots do have a single well-defined entry point, but tape/disk/microdrive programs are not like that. There’s usually a bunch of blocks that are loaded one after the other, often with code running in between. Some of that code can even be custom loader code. So figuring out what the “final” entry point is can be more of an abstract or conceptual exercise than a mechanical one than an emulator can just guess for you, But once you’ve done that, you can put a breakpoint there, and create a snapshot.

For a non-custom loader it’s often the final USR nnnnn in the BASIC loader. For custom loaders you have to analyze it step by step, because you can’t even see the next piece of custom liadet code until the previous piece has finished loading. It’s all just code, so you have to assign it some meaning, just the the emulator would have to do if it guessed for you.

[8BitSC]

Maybe a rewind feature in the emulator which would allow us to step back to the exact point the tape finished loading, so we could make the ideal snapshot?

[equinox]

Maybe a rewind feature in the emulator which would allow us to step back to the exact point the tape finished loading, so we could make the ideal snapshot?

To my limited understanding: as soon as you have "rewind", you make things infinitely more difficult, because now you have to remember everything that happened in between. When you "replay" stuff in an emulator, you are not doing one of those flipbooks where you move your thumb and go through lots of entire pages. You are only executing the changes from the initial point. (It is easy to save a file, but not to un-save it. Easy to draw a shape on screen, but not to un-draw it.) The arrow of time!

I guess this is why RZX playback doesn't give you a nice draggable seek bar like a YouTube video. But even video has these problems, because (again) it isn't a huge collection of entire 100% screen frames, but a number of intermediate "keyframes" and then some smaller changes to those.

[jpnz]

For ROM based loaders a break point at 0x0555 is a good spot

The break point triggers on completion of loading either a header or code, so loading something like Manic Miner would trigger 6 times

Ideally take your snapshot while the 6th trigger is in place

Restarting execution would then traverse it's way out of the ROM code, and at some point return to BASIC - presumably with the last statement, or line, being a USR call to start the game - 33792 IIRC

[Lethargeek]

i use SPiN to make "ideal" snapshots. When it begins the loading of the last block, enter the debugger then keep clicking "exit function" button until it resumes the loading, then it breaks at the next RET when finished. Then i trace until the PC points into the RAM (and for 48K snapshots at the point when two bytes below SP were read recently or are about to be corrupted).

[Pegaz]

Do any emulators support a function where on completing a load from tape, tap, tzx, etc. They can PAUSE emulation?

Yes, SpecEmu can do this.
Start loading process, then press ESC to go into debugger and choose Debug/Run Until/Tape Event/Tape Stops.

Quoting reduced by admin

[TomD]

I highly recommend you use @SkoolKid's SkoolKit for this with the new --sim-load functionality (viewtopic.php?f=6&t=8927).

Most of the recipes will create you a perfect Z80 snapshot which keeps the loading screen in tact (I haven't tried them all) as it creates the snapshot as soon as loading stops by monitoring for the tape stop and/or a specific memory address access.

TomD

[SkoolKid]

I highly recommend you use @SkoolKid's SkoolKit for this with the new --sim-load functionality (viewtopic.php?f=6&t=8927).

If I'm allowed, I'd also recommend @SkoolKid's tap2sna.py (included in SkoolKit).

By default, it stops when the tape ends, which means for most tapes it "just works". Where it doesn't just work, you can try a recipe from the t2sfiles repository. And if that still doesn't work, post here and we'll see what we can do.

[8BitSC]

@SkoolKid Thank you for pointing out these Python tools. I'm having fun now, converting downloaded TZX files to Z80 then MDR files and testing in Fuse, then on a real 48K Speccy.

Oddly, the first example in the documentation, Pyjamarama works under emulation in Fuse but crashes, NEW-ing, RANDOMISE USR 0 style on a real 48K Spectrum.

Others I've tested up to now, work just fine in Fuse AND on a real Issue 3 48K Speccy.

This leaves me wondering though, how the process could create an image which will work in an emulator but crashes on real hardware?

[TomD]

This leaves me wondering though, how the process could create an image which will work in an emulator but crashes on real hardware?

Does the MDR work in an emulator? If not it is likely due to the MDR conversion of a Z80 snapshot. My utility has to build the full memory of the Spectrum while also running on the Spectrum in the same memory. It uses a few tricks to do this and compatibility is very close to 100% but some snapshots do not work. First thing to do is to try a a different TZX or even a TAP version.

If still no joy then if you are using v3.0 of the full version of Z80toMDR there are some options to change how the MDR works. First try the option -c t. If that doesn't work also try -sos 191. You can play with these options but both do cause some screen corruption. If still no joy or you don't want screen corruption then the final option is to change how SkoolKit creates the Z80.

Often the reason the MDR conversion doesn't work are little routines run after loading. Using SkoolKit you can change the memory location when the snapshot is created to happen after this routine. This is a little more advance and requires a little knowledge of machine code but it does usually work.

TomD

[SkoolKid]

This leaves me wondering though, how the process could create an image which will work in an emulator but crashes on real hardware?

That is weird, and I have no idea. What happens if, in the case of Pyjamarama in particular, you let tap2sna.py do all the RAM-descrambling before saving the snapshot? For example:

Code: Select all

tap2sna.py --start 0x8200 https://worldofspectrum.org/pub/sinclair/games/p/PyjamaramaV1.tzx.zip

[8BitSC]

What happens if, in the case of Pyjamarama in particular, you let tap2sna.py do all the RAM-descrambling before saving the snapshot? For example:

Code: Select all

tap2sna.py --start 0x8200 https://worldofspectrum.org/pub/sinclair/games/p/PyjamaramaV1.tzx.zip

I can confirm this script produces an image which works just fine on real hardware.

The image converted to a Z80 without issue, then converted to MDR without errors. Once copied to OqtaDrive it loaded, complete with a loading screen into a pristine image.

How does this differ from the t2s conversion approach?

[8BitSC]

Does the MDR work in an emulator?

Yes. The Z80 file resulting for skoolkid's t2s recipe (not the code snippet he presented a short while ago in this thread), converted to an MDR using your fab Z80onMDR app, loads into Fuse and runs just fine but crashes back to a USR 0 boot-screen on a real issue 3 48K Speccy.

[SkoolKid]

How does this differ from the t2s conversion approach?

The only difference is the point at which the snapshot is taken: when PC=32819 for the pyjamarama.t2s file, and when PC=33280 (0x8200, after the game has finished its post-LOAD RAM-descramble) for the tap2sna.py command I suggested.

So it looks like the MDR conversion messes with Pyjamarama's RAM-descrambling routine somehow. Over to @TomD for why that might be.

[TomD]

So it looks like the MDR conversion messes with Pyjamarama's RAM-descrambling routine somehow. Over to @TomD for why that might be.

Without disassembling Pyjamarama my best guess would be how the RAM-descrambling routine uses the stack. My routine uses a "safe" area below the stack to facilitate the in-place decompression of the Z80. This area is usually a good place to put this code as it is not often used for storage, however, this isn't always the case. I've added options to the utility to move these routines to the screen area but this isn't as good as it causes screen corruption, also some games use the screen hiding code in blacked out areas etc... The best option is often just take the snapshot a little later after loading like you've done for Pyjamarama.

TomD

[SkoolKid]

The first thing Pyjamarama does at 32819 (the start address in the t2s file) is this RAM check, which I'm guessing is what fails on a real Spectrum:

Code: Select all

32819 LD HL,33280
32822 LD BC,31405
32825 CALL 32831  ; Check RAM.
32828 JP 64663
32831 LD A,0
32833 ADD A,(HL)
32834 LD E,A
32835 INC HL
32836 DEC BC
32837 LD A,B
32838 OR C
32839 LD A,E
32840 JR NZ,32833
32842 CP (HL)     ; RAM check successful?
32843 RET Z       ; Return if so.
32844 JP 0        ; Otherwise reset.

It would be interesting to know whether the snapshot works on a real Spectrum if it's taken when PC=64663 (immediately after a successful RAM check):

Code: Select all

tap2sna.py --start 64663 https://worldofspectrum.org/pub/sinclair/games/p/PyjamaramaV1.tzx.zip

[ParadigmShifter]

Wouldn't it be easier to just turn the RET Z into a RET to bypass the check then?

[SkoolKid]

Wouldn't it be easier to just turn the RET Z into a RET to bypass the check then?

Not really, but if you wanted to, you could:

Code: Select all

tap2sna.py --start 32819 --ram poke=32843,201 https://worldofspectrum.org/pub/sinclair/games/p/PyjamaramaV1.tzx.zip

[8BitSC]

It would be interesting to know whether the snapshot works on a real Spectrum if it's taken when PC=64663 (immediately after a successful RAM check):

Code: Select all

tap2sna.py --start 64663 https://worldofspectrum.org/pub/sinclair/games/p/PyjamaramaV1.tzx.zip

@SkoolKid I CAN confirm this also works on real harware.

I tested as far as allowing the game to load from a Microdrive image coversion after using @TomD's Z80onMDR program (complete with loading screen and its "Popcorn" intro tune), I press a key and as expected, it takes me to the keyboard select screen from where I can start the game.

[8BitSC]

Not really, but if you wanted to, you could:

Code: Select all

tap2sna.py --start 32819 --ram poke=32843,201 https://worldofspectrum.org/pub/sinclair/games/p/PyjamaramaV1.tzx.zip

Just for confirmation, this also works on real hardware.

[TomD]

The first thing Pyjamarama does at 32819 (the start address in the t2s file) is this RAM check, which I'm guessing is what fails on a real Spectrum:

Makes sense, a simple RAM check would fail as a few bytes in the stack would differ to the original. Good to see taking the snapshot just after works great. Not sure how many games do this type of tamper/copy protection check, maybe something to add to the General Info section of the Spectrum Computing entry.

Code: Select all

Copy Protection: RAM check on load

TomD

[jpnz]

Just a thought... activating the IF1 will bump out the system variables by 58 bytes

Loading a file from the microdrive will also consume some further 595 bytes

Once the file is loaded, those 595 bytes should be released

But those extra system variables will still persist

Maybe consider collapsing the system variables prior to kicking off the decompression?

[TomD]

Routine decompresses all the memory, including the system VAR area so this is already utilised. The stack is literally just for the last bit which is used to set the final registers and launch the game. The following diagram shows how it works:



You can already tell the utility to use the printer buffer area or screen and one of these will probably work fine for Pyjamarama as the RAM check doesn't check everything.

In my testing (and others) the stack is the most compatible area to use outside of the screen. Screen is the best and what a lot of these tools use, but it causes corruption so can look a mess especially if the corruption is not on a loading screen but an in-game one. Stack doesn't always work as you can see from Pyjamarama but there are plenty of options, just needs a little bit more work.

TomD