Re: [hatari-devel] TT problems with MMU (was: 4MB TT with WinUAE) |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 02/14/2016 01:56 AM, Eero Tamminen wrote:
On 02/13/2016 06:02 PM, Nicolas Pomarède wrote:
Le 13/02/2016 13:56, Eero Tamminen a écrit :
On 02/09/2016 01:08 AM, Nicolas Pomarède wrote:
Le 08/02/2016 23:52, Eero Tamminen a écrit :
PS. Starting TOS v3 with 4 MB bombs regardless of CPU core version.
If I enable some TT-RAM in addition of 4MB ST-RAM, it boots fine.
this is what I get with TT / TOS 3 :
- if 24 bit addressing is checked, the prefetch and CE mode will give
2 bombs at boot, with or without MMU
This doesn't bomb anymore.
- if 24 bit adressing is not checked, the prefetch and CE mode will
work if MMU is not used.
Verified.
If MMU is used prefetch mode will still work,
For me, TT boots, but screen stays black until TOS gets to GEM desktop.
It's black only with 32-bit mode, in 24-bit mode
everything is visible during boot.
And indeed, only in 32-bit mode (with MMU),
I see this:
-------------------------------------------
Illegal wput at ffff8240=00000fff PC=e000e4
Illegal wput at ffff8242=00000f00 PC=e000e4
Illegal wput at ffff8244=000000f0 PC=e000e4
Illegal wput at ffff8246=00000ff0 PC=e000e4
Illegal wput at ffff8248=0000000f PC=e000e4
Illegal wput at ffff824a=00000f0f PC=e000e4
Illegal wput at ffff824c=000000ff PC=e000e4
Illegal wput at ffff824e=00000555 PC=e000e4
Illegal wput at ffff8250=00000333 PC=e000e4
Illegal wput at ffff8252=00000f33 PC=e000e4
Illegal wput at ffff8254=000003f3 PC=e000e4
Illegal wput at ffff8256=00000ff3 PC=e000e4
Illegal wput at ffff8258=0000033f PC=e000e4
Illegal wput at ffff825a=00000f3f PC=e000e4
Illegal wput at ffff825c=000003ff PC=e000e4
Illegal wput at ffff825e=00000000 PC=e000e4
-------------------------------------------
I.e. ST palette register writes don't go through
before MMU is enabled at boot.
Can you see the same?
I assume the TT palette register writes that happen
after enabling MMU, but before TOS memory checks,
have zero values because ST palette entries were
still all zeroes.
(EmuTOS writes ST palette once and corresponding
TT palette registers twice at boot, but these
3 palette settings before first screen output
all happen after MMU has been enabled.)
but CE mode will give the infinite loop you saw.
Yes.
In TT mode, 24 bit addressing should not be used; the TT had a 32 bit
68030, so limiting it to 24 bit can have unexpected effects (we can try
to make it work in 24 bit mode with a few hacks (mirroring IO registers
to their 32 bit equivalent) but that would not be a real HW case).
But currently Hatari defaults to 24-bit addressing, even with TT...
In the end, the non working mode is 32 bit adressing + CE + MMU, I will
have a look at this, some IO regs might be wrongly mapped.
Prefetch mode has also something funny in my case.
- Eero