Re: [hatari-devel] AUTO folder not executed anymore (commit #ba51a1e2) |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Le 20/06/2024 à 22:42, Uwe Seimet a écrit :
Sure, please see the attachment.
Le 20/06/2024 à 22:32, Uwe Seimet a écrit :
Please see the attached configuration file for my complete setup.
and could you also run "hatari --trace scu" and send the traces in that
case ? (this should give 10-20 lines at max)
that's what I thought ; your logs :
Checking: /opt/atari/tos306de.sym
scu read gpr1 ff8e09=0x0 pc=e00086
scu read gpr1 ff8e09=0x0 pc=e000f4
this is not "normal". GPR1 bit0=1 is used by TOS to save the fact that
it did a TT RAM test in a previous boot and it should not do it again
(if the magic value for TT RAM is valid too). So 0x0 means that a TT RAM
test will be made.
in my case I have
Checking: /home/npomarede/Emul/ST/tos/tos306de.sym
scu read gpr1 ff8e09=0x1 pc=e00086
scu read gpr1 ff8e09=0x1 pc=e000f4
and in scu_vme.c we have :
void SCU_Reset ( bool bCold )
{
if ( !SCU.Enabled )
return;
....
/* GPR1 and GPR2 are cleared only on cold boot, they keep their
content on warm boot */
if ( bCold )
{
SCU.GPR1 = 0x00;
SCU.GPR2 = 0x00;
}
/* TODO: ...but TOS v2 / v3 crash on MegaSTE / TT
* unless gen reg 1 has this value, why?
*/
SCU.GPR1 = 0x01;
....
}
So, SCU.GPR1 should be set to 0x01 in all cases, cold or warm boot.
just to be sure, do you have the same code in your version of scu_vme.c ?
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.
Nicolas