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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 15/09/2022 à 20:23, Eero Tamminen a écrit :
> 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...

Hi

I don't remember all the details from this change, but basically key 
shortcuts are processed in the VBL handler, so if you create the 
snapshot while handling the F12 key for example during the VBL, then you 
will be in a in-between state where some internal HW variables will 
refer to current VBL and other to the next VBL (IIRC this was visible in 
the B.I.G demo by TEX).

So, snapshot saving demand is stored during the VBL, but it is 
effectively executed only after the end of the current instruction, 
because we're then in a "stable" state..

When entering the debugger using shortcut key, a similar change could be 
made to call DebugUI also at the end  of the current instruction.

But in case it's a breakpoint when monitoring read/write access to a 
specific memory address (which is not yet supported in Hatari), you 
should call debugUI immediately, not at the end of the current 
instruction, because the context would not be the correct one.


Nicolas