|Re: [hatari-devel] Debugger memdump command + MMU address translation?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 24/02/2023 à 16:55, Markus Fröschle a écrit :
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
- '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).