Re: [hatari-devel] Hatari freezing when running FIX24.PRG

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 09/10/2018 à 13:57, Nicolas Pomarède a écrit :
> Le 09/10/2018 à 12:54, Uwe Seimet a écrit :
> > Hi,
> >
> > > thanks for this program, but unfortunately I can't reproduce any crash.
> > >
> > > I copied fix24.prg to my gemdos drive then ran :
> > >
> > > hatari -c ../my_tests/hatari_uwe.cfg  -d /others/ST/D  --machine tt
> > > --tos ~/Emul/ST/tos306fr.img -s 14 --ttram 16 --mmu on --addr24 off
> > > --cpu-exact on --compatible on
> > >
> > > from the desktop I launched fix24.prg which exited cleanly and tos still
> > > work, no crash.
> >
> > How did you ensure that TT-RAM was completely unallocated when starting
> > FIX24? Please see the notes in my previous posting: FIX24 usually has to
> > be run (as first program) from the AUTO folder. Otherwise some TT-RAM may
> > already have been allocated, and then it's too late to disable 32 bit
> > addressing, because running programs are already using it.
> > Please also check the startup message of FIX24, which reports if TT-RAM
> > is already in use.
>
> Ok, I can get the same problem when starting from auto. I will try to 
> debug this as soon as I get a little more spare time.

looking more closely at the tables that fix24.prg generates to ignore 
the upper 8 bits of 32 bit logical addresses, I see something strange 
when I run hatari with 16 MB of TT-RAM : it overrides the entry for 
ROM's region at E00000 and translate it to 01000000.

So obvioulsy, as soon as fix24.prg exits and PC goes back to TOS, 
program will misbehaves as the cpu will try to fetch TOS content from 
physical address 01000000 instead of E00000.

This is the table I see at $700 just before fix24.prg enables MMU in TC 
(no_cook label in FIX24.S) :

00000700: 00 00 00 01 00 10 00 01 00 20 00 01 00 30 00 01
00000710: 00 40 00 01 00 50 00 01 00 60 00 01 00 70 00 01
00000720: 00 80 00 01 00 90 00 01 00 a0 00 01 00 b0 00 01
00000730: 00 c0 00 01 00 d0 00 01 01 00 00 01 00 f0 00 41
00000740: 00 00 07 ca 01 00 00 01 02 00 00 01 03 00 00 01
00000750: 04 00 00 01 05 00 00 01 06 00 00 01 07 00 00 01
00000760: 08 00 00 01 09 00 00 01 0a 00 00 01 0b 00 00 01
00000770: 0c 00 00 01 0d 00 00 01 0e 00 00 01 0f 00 00 01
00000780: 00 00 00 41 01 00 00 41 02 00 00 41 03 00 00 41
00000790: 04 00 00 41 05 00 00 41 06 00 00 41 07 00 00 41

As can be seen, $738 contains 01 00 00 01 instead of 00 e0 00 01.

Am I missing something (my memories about mmu debugging are not 
completely fresh yet :) ) or does fix24.prg requires at least 32 or 64 
MB of TT-RAM for example to not override $738 ?

Nicolas