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

[Uwe Seimet <Uwe.Seimet@xxxxxxxxx>]

Hi,

Thank you for the fix, the problem is gone.

Best regards

Uwe

> 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
> 
> 
>