Re: [hatari-devel] Truncated PC address value with code running in TT-RAM?

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

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
every instruction)?

Almost all of the debugger functionality needs just correct physical
memory address for the program counter.


	- Eero