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

[ Thread Index | Date Index | More Archives ]

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:

   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?


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


Mail converted by MHonArc 2.6.19+