Re: [hatari-devel] Hatari freeze on XaAES quit with 030 MMU + FPU + cache emulation

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 26/07/2022 à 11:11, Nicolas Pomarède a écrit :
> Le 25/07/2022 à 23:52, Eero Tamminen a écrit :
> > With above 2 lines changed (or just the first one), EmuTOS v1.1.1 does 
> > not even boot.
> >
> >
> > => That validation code in Hatari seems broken, as instead of 
> > validating emulation, it changes how things are emulated.
>
> Hi
>
> the first line "VALIDATE_68030_DATACACHE" is directly from WinUAE's cpu, 
> maybe it has not been updated recently and has some problem with current 
> version of the cpu core ; I will try to have a look.
>
> Can you try with only the second line "WINUAE_FOR_HATARI_DEBUG_CACHE" ? 
> It's a much simpler function that I added some time ago and it should work.

Hi

this is fixed ; the problem was that these debug functions are doing 
get_long/get_word/get_byte and in the case of Atari machines this 
requires to be in supervisor mode when accessing RAM 0-$7FF, which was 
not always the case depending on the state of the running program 
accessing the cache, hence the bus error / crash.

I added a special BUS_MODE_DEBUGGER to bypass this supervisor check, 
this way debugger/logging functions can now safely access all the memory 
(and must restore the correct BusMode after)

Can you try again to enable the 2 define's to see if any cache mismatch 
is reported ?

Nicolas