English Amiga Board - View Single Post

jotd · 18 March 2017, 21:43

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.

18 March 2017, 21:43	#21
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,162	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.