|Re: [hatari-devel] Truncated PC address value with code running in TT-RAM?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 3/30/19 8:06 PM, Toni Wilen wrote:
Maybe not in the CPU core, but apparently in the disassembler, using the
functions that use physical addresses to fetch opcodes. When the MMU is
active, you need to translate them first (it is not just adding the memory
bank offset, you really have to go through the MMU table).
I'm not sure how Hatari handles this currently, but in Aranym there are
functions like phys_get_long(), mmu_get_long() etc. for this purpose.
These aren't suitable because they act like emulated memory reads
i.e. impact cache etc.
I thought that maybe I could use mmu_translate(), but even that seems
to be changing internal MMU emulation state.
WinUAE has mmu <fc> debugger option to select which fc value to use when
translating addresses in debugger. Default is no translation.
Thanks! How I should use it?
Is there a function that should be called or variable to be set when
entering and exiting the debugger (which in many cases can happen for
Almost all of the debugger functionality needs just correct physical
memory address for the program counter.