[hatari-devel] Latest Hatari HG version gets stuck sometimes
npomarede at corp.free.fr
npomarede at corp.free.fr
Thu Jul 9 01:05:33 CEST 2009
On Thu, 9 Jul 2009, Thomas Huth wrote:
> On Wed, 8 Jul 2009 23:32:19 +0200
> Thomas Huth <huth at users.berlios.de> wrote:
>
>> On Wed, 8 Jul 2009 21:06:15 +0300
>> Eero Tamminen <eerot at users.berlios.de> wrote:
>>
>>> Saving memory state from a freshly booted & idle GEM and then
>>> restoring it with the --memstate option is 100% sure way to trigger
>>> the issue for me.
>>
>> OK, I can reproduce the problem this way. However, I currently don't
>> have a clue how to fix it...
>
> Phew, just found and fixed this bug. The problem was introduced with
> changeset f3051bd6f969 where the place of the call to
> Video_StartInterrupts() was changed in the VBL function.
> After the change, the VBL function basically looked like this:
>
> void Video_InterruptHandler_VBL ( void )
> {
> Int_AcknowledgeInterrupt();
> ...
> ShortCut_ActKey();
> ...
> Video_StartInterrupts(PendingCyclesOver);
> }
>
> AcknowledgeInterrupt() disabled the VBL Int in int.c.
> ShortCut_ActKey() is where we load & save memory snapshots.
> Video_StartInterrupts() enables the VBL Int in int.c again.
>
> So with that order the VBL Int was disabled in the memory snapshots.
> As long as you used F12 or AltGr+l for loading memory snapshots,
> this did not matter since StartInterrupts() re-launched the VBL.
> But as soon as you used the --memstate option, the VBL was never
> started again.
>
> I've fixed the problem now by moving ShortCut_ActKey down, after the
> Video_StartInterrupts() function call (like it was before the change).
>
> Note that this fix only works for new memory snapshots, since the
> disabled VBL is stored in the file of faulty snapshots.
>
> Thomas
Well done, I didn't pay attention to the fact that snapshot was saved in
the vbl and order mattered in that case.
Nicolas
More information about the hatari-devel
mailing list