Save state in WHDLOAD?

[jotd]

HRTMon also has ws/wl commands which use WHDLoad I/O to save to any hard disk, IDE, SCSI, you name it, using the OS through OS swap.

I tried to implement such save state for JST, but there are multiple problems as Sting&Galahad stated.

- saving chipmem: easy
- saving write-only registers: possible, but MMU SNOOP must be enabled, would slow down CPU. Alternative: slave must provide copper/other write registers contents at any time of the game (they can change)
- also: slaves have internal states sometimes (counters, boolean toggles) so slave would have to be dumped in the savestate too.
- another tough part would be: games are patched by jumps to the slave memory area. The slave is allocated in fastmemory, not at the same location everytime. Means that we'd need to AllocAbs the slave when resuming, and it may fail. It's very difficult/impossible to "reapply" the patches done by the slave to fix address change.

So I agree with one of the posts: it's way better to ask slave coders to implement efficient trainers/levelskips, like I recently did with BCKid or D/Generation. Saving state is cheating already. Why not blatantly cheat and everyone can easily benefit from those levelskips without all the constraints of the savestates.

WinUAE savestates are handy, though, for debugging for instance. In that case, it works even if WinUAE doesn't guarantee the hard disk behaviour. Didn't have any problems when I cheated in cannon fodder/cannon fodder 2 and then saved after mission success.

[Ragnarok]

Perhaps it's time to leave aside WHDLOAD for some games...

[Retro1234]

Originally Posted by jotd

HRTMon also has ws/wl commands which use WHDLoad I/O to save to any hard disk, IDE, SCSI, you name it, using the OS through OS swap.

I tried to implement such save state for JST, but there are multiple problems as Sting&Galahad stated.

- saving chipmem: easy
- saving write-only registers: possible, but MMU SNOOP must be enabled, would slow down CPU. Alternative: slave must provide copper/other write registers contents at any time of the game (they can change)
- also: slaves have internal states sometimes (counters, boolean toggles) so slave would have to be dumped in the savestate too.
- another tough part would be: games are patched by jumps to the slave memory area. The slave is allocated in fastmemory, not at the same location everytime. Means that we'd need to AllocAbs the slave when resuming, and it may fail. It's very difficult/impossible to "reapply" the patches done by the slave to fix address change.

So I agree with one of the posts: it's way better to ask slave coders to implement efficient trainers/levelskips, like I recently did with BCKid or D/Generation. Saving state is cheating already. Why not blatantly cheat and everyone can easily benefit from those levelskips without all the constraints of the savestates.

WinUAE savestates are handy, though, for debugging for instance. In that case, it works even if WinUAE doesn't guarantee the hard disk behaviour. Didn't have any problems when I cheated in cannon fodder/cannon fodder 2 and then saved after mission success.

Was there ever ever a version of JST with a savestate beta ?- I think in Lotus 1 you could minimise the game during play

[jotd]

Yes, there were. Worked with a few games: Lotus 1, Desert Strike, I don't remember all of them.
Minimizing was also possible, and did not require state saving.

Oh, in my previous post I forgot the CIA registers, but that's properly doable 99% of the time in a generic way (HRTMon does that, no issue)

What could be possible would be savestate from within a whdload session: if you quit, then you cannot restore, nothing is written to disk. You could only restore state from a single gaming session (which would be still very useful).

So you keep the current memory allocation and you can restore, provided that you log the copper pointers and a few other custom chip stuff.

The difference between JST & WHDload is that WHDload wants to do everything perfectly, or not do it at all.
JST attempted, but could fail

So, if not using MMU to log writes (which consumes CPU power unless you're using WinUAE where the feature is a bit pointless), slaves would have to be adapted to provide a "pre-freeze" and "post-restore" couple of callbacks to restore copper stuff, whatever needed for such or such game.

Of course, WinUAE is very helpful here, because we can get the actual values of every register (hardware banging games often use absolute addresses for their codes, else, it would have to be linked to game memory allocation, but still doable)

[Retro1234]

Ok I think trainers with level skip are a good alternative but out of interest
The Lotus Docs Say "Registered users are able to save/restore the game state.........
How do I do this?

[jotd]

JST is now free, but I'm not sure I left the savestate/minimize in. I can happily provide my old jst.key to unlock all previous versions.

[Retro1234]

Originally Posted by jotd

JST is now free, but I'm not sure I left the savestate/minimize in. I can happily provide my old jst.key to unlock all previous versions.

If its ok id like to have a look and your have to tell me how to use the save state feature

[jotd]

I think you typed "TAB" when games where running (Desert Strike). It's lost in the mist of time for me though...

[Retro1234]

Originally Posted by jotd

I think you typed "TAB" when games where running (Desert Strike). It's lost in the mist of time for me though...

Thanks ill check it out

[TEOL]

A rumored proper system is in the plans for future features. Hopefully they tie load and save to the F keys that are unused in a game and not the used in a game ones.

I can see the feature being a hit provided it does it that way of moving it to a different F key if it's used by something else and provided that the new system works on every game ever made.

Emulated music in WHDLoad CD32 might be important too even if it means having to convert the Waves and mp3s into another format on the fly to one a standard AMIGA supports whilst it's installing which means it would take longer to install but music will be in the game.

Whats more important than getting both of those features out is releasing a new Classic Workbench with that new free version of JSTLoad "which was talked about", WHDLoad 1.8.3 and KGLoad all included Classic Workbench will then have the all in one hard drive games experience and thats exactly what we need from the latest edition.

As for the saves and music in WHDLoad god knows when they will be in Beta it's just that they are in the to do list already so has to happen someday anyway.

At the moment I could live with level skips and cheats to be honest.

[jotd]

@TEOL that's cool because the features you're asking for are far from trivial. The audio thingy is just very difficult. The closest we could do would be - only on a CD32 hardware - to add music on Amiga games which don't have it, by modfiying whdload slaves & adding CD-play feature to CD32load.

Another idea would be to issue a "cd-read" command to the amiga CD-ROM (using WHDLoad) but once again, slaves would need to be modified.

And no MP3, only full CD-music, 1 CD per game (beginning to be very demanding)