Re: [hatari-devel] Debugger memdump command + MMU address translation?

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 24/02/2023 à 16:55, Markus Fröschle a écrit :
> Hi all,
>
> I'm currently trying to debug Hatari's inability to boot Atari SYSV4
> and ran into the following:
>
> Is Hatari's memdump command supposed to be able to deal with MMU
> address translation (030 emulation)?
>
> ASV seems to set it's system stack at virtual addresses far outside
> physical system memory:
>
> > r
>    D0 00000000   D1 00057A80   D2 002F1000   D3 0010E000
>    D4 0000010E   D5 04000000   D6 000109BE   D7 0000010E
>    A0 002A0604   A1 0006AF04   A2 000ABC9C   A3 000ABCA0
>    A4 0010B2EC   A5 001CB400   A6 4E001FB0   A7 4E001F90
>
> When attempting to dump stack contents
>
> > m "a7"
> - 'a7' -> $4e001f90
> 4E001F90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ................
> 4E001FA0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ................
>
> I only get a dump of zeros (what seems to be the error return value
> from STMemory_Read()) although emulation in general (like bsrs and
> rets) seem to work fine with stack read/write.
>
> Is this a bug or just a missing feature?

Hi

debugger uses some slightly different read access functions, mainly 
because under Atari RAM below 0X800 can only be read in supervisor mode. 
Depending on the context when you enter debugger, you might be in user 
mode S=0 and if you try to read memory below 0x800 this will trigger a 
bus error from inside the debugger :(

so the debugger doesn't use the same access functions as when the cpu 
emulation is really running, and this can be broken/missing when using MMU.

I would need to check the code to be sure, but it's quite likely (you 
can check manually if it's broken/mising by reading the MMU tables and 
doing the translation yourself and see if this makes A7 points to a more 
"consistent" part of the memory).

Nicolas