Re: [hatari-devel] Bugs with memory snapshot saving from SDL GUI

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi,

On 15.9.2022 14.34, Chris Jenkins wrote:
I'm not easily able to try to reproduce this issue myself because I'm
using
a Mac but I might try getting Hatari working on my Raspberry Pi if I get
the chance and see if any of this stuff happens there.

According to sources, Mac GUI is also using the non-immediate memory
capture function, so it should also be suffering of the too-late
overwrite question.


Confirmed. I experimented with changing the Mac UI code code such that it
does_not_ call GuiOsx_Resume() after calling MemorySnapShot_Capture.
Nothing happens until you manually un-pause emulation, after which point
the "File '%s' exists, overwrite?" dialog is shown and then the snapshot is
saved if I accept it.

One question that I have: is there any reason why we can't just use the
immediate memory capture function in all cases? If the emulation is paused
when we call it then would that work? The Mac UI makes basically this
sequence of calls at present:

GuiOsx_Pause(true)
MemorySnapShot_Capture(...)
GuiOsx_Resume()

I'm not sure what consequences there would be if we just called the
immediate memory capture function there. I'll try it when I have time.

This seems to have been a change done by Nicolas for Hatari v2.2, with following message:
----------------------------------
Improve reliability of saving/restoring memory snapshot
Saving/restoring was previously called directly from the UI, which could lead
    to some inconsistencies when restoring some games/demos.
Saving/restoring is now postponed to the end of the current instruction emulation loop,
    which ensures stable behavior.
----------------------------------

Based on that description, everything should be doing a delayed save/restore, including debugger...


	- Eero



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/