Re: [hatari-devel] AUTO folder not executed anymore (commit #ba51a1e2)

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 20/06/2024 à 23:12, Nicolas Pomarède a écrit :
> Le 20/06/2024 à 23:03, Nicolas Pomarède a écrit :
> > Also if SCU.Enabled is false, this could give your result. But 
> > SCU.Enabled is set to true in ioMem.c line 345 :
> >
> >          if (Config_IsMachineTT() || Config_IsMachineMegaSTE())
> >                  SCU_SetEnabled ( true );
> >          else
> >                  SCU_SetEnabled ( false );
> >
> >
> > This is really strange. It could be some sources or .o files not up to 
> > date, but you said you did a "make clean"
> >
> > Let's see if other people have the same issue, for now I don't see 
> > what's wrong.
>
> I can reproduce it :
>
> hatari --machine tt --tos ~/Emul/ST/steem/tos/tos306de.img
>
> -> SCU.GPR1 is 0 on boot instead of 1
>
> hatari --tos ~/Emul/ST/steem/tos/tos306de.img
>
> -> this will ask for switching to TT mode and then GPR1 is 1 on boot
>
> there's sthg wrong here. Both cases should boot in TT mode, giving 
> "--machine tt" (or in the config file) should not majke such a difference.

Hi

fix applied ; the way Hatari calls Reset() before IoMem_Init() is not 
the correct order and it could produce this wrong behaviour where SCU 
was not enabled at the time of the reset depending on the default 
machine type in your config file.

SCU_Reset() will now check MachineType directly, which fixes the problem 
(refactoring the startup order remains on the todo list for later)

Nicolas