[hatari-devel] Regression when restoring desktop.inf

[Nicolas Pomarède]

Le 18/05/2011 21:46, Eero Tamminen a écrit :
> Hi,
>
> On keskiviikko 18 toukokuu 2011, Nicolas Pomarède wrote:
>> Yes, desktop.inf is correctly read in all case for me, because all
>> windows are correctly restored at their right place. The only problem is
>> that the resolution is not restored.
>>
>> I wonder if the tos tests some file attribute/date on desktop.inf to
>> decide the resolution should be restored or not, and this could be the
>> cause of the problem.
>
> If you check the full GEMDOS trace, you see that it isn't doing any file
> attribute/date checks.
>
> The get trace just of the Desktop parsing and its effects, you can set up
> breakpoint&  tracing for it like this:
> ----
> # run debugger commands from fopen.ini when Fopen() is called
> echo "b GemdosOpcode = 0x3D :trace :file fopen.ini">  break.ini
> # trace all kinds of things after that
> echo "--bios-intercept --trace gemdos,xbios,fdc,io_all">  fopen.ini
> # and exit Hatari after 4 VBLs
> echo "setopt --run-vbls 4">>  fopen.ini
> ----
>
> Then just do:
> 	hatari --tos tos162de.img --parse break.ini -d . 2>&1 trace.txt
>
> To get trace of Gemdos&  XBios and IO register reads&  writes that start
> from opening the desktop.inf and ending a bit after resolution would be
> changed.  (FDC shows VBLs which helps in getting suitable --run-vbls value)
>
> I didn't see anything suspicious there.
>
>
> 	- Eero

Instead of doing it this way (trying to understand what the tos 
does/doesn't), I think I will try the "bisect" way from mercurial instead.
I'd really like to understand at what point between 1.4 and now, this 
problem appears for me in Hatari.

Nicolas