English Amiga Board - View Single Post

jotd · 19 March 2017, 16:50

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)

19 March 2017, 16:50	#24
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,303	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)