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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 30/03/2019 à 18:21, Eero Tamminen a écrit :
> Hi,
>
> On 3/30/19 5:41 PM, Nicolas Pomarède wrote:
> > Le 30/03/2019 à 16:10, Eero Tamminen a écrit :
> > > > I will have a look ; which cpu were you using?
> > >
> > > What one gets with "--machine falcon" i.e. 030.
> >
> > As you talked about TT ram, I tested with TT mode, not falcon mode, 
> > and it seems to work. Can you check if it works in TT mode (unless the 
> > program you want to run really require falcon HW ?)
> > As the Falcon was really supposed to be 24 biy only and TT RAM in 
> > falcon mode is a "hack", it's possible the mask is not correctly set.
>
> I can't reproduce it with TOS, when running an Atari application that
> is loaded to TT-RAM by TOS.
>
> => it's not a regression
>
> It happens when Linux runs in TT-RAM, regardless of whether it's loaded
> to TT-RAM by the new lilo.c code, or by an Atari application under TOS.
>
> When Linux in TT-RAM oopses, its own backtrace shows addresses that are
> in ST-RAM, although that code is actually in TT-RAM.
>
> Maybe this issue is related to how Linux sets up MMU?

yes it could be possible that linux install its own mmu table to handle 
page swapping. One would need to look at the source code to check this 
(which I don't have time at the moment).
It's quite possible that the "24 bit PC" you see will be in fact 
translated to a physical 32 bit address when the cpu core runs the whole 
MMU emulation.
M68000_GetPC and other command showing regs values will in fact display 
logical address before translation, not the physical ones.

At least if TOS behaves correctly when using TT RAM and the PC is shown 
untruncated with 32 bits, then it seems the bug is not in Hatari or in 
the cpu core.

Nicolas