|Re: [hatari-devel] New WinUAE core issue with Bad Mood?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 8 Dec 2014 at 11:28, Nicolas Pomarède wrote:
> then I think there's an error in EmuTOS PMMU boot's sequence, because we
> have this code :
> $e00088 : 21fc 00e0 00b2 002c move.l #$e000b2,$002c.w
> $e00090 : f039 0800 00e0 013e pmove $e0013e,tt0
> $e00098 : f039 0c00 00e0 013e pmove $e0013e,tt1
> $e000a0 : 21fc 00e0 00d0 002c move.l #$e000d0,$002c.w
> $e000a8 : f039 4000 00e0 013e pmove $e0013e,tc
> So, emutos first write to tt0/tt1, then it writes to tc ; the 2 moves to
> TTx are not made after a full 68030 was detected.
> It seems to be the opposite of what you describe ? Before reaching
> e00088, I don't see 68030 only instructions.
Sorry for my previous confusing comments - I assumed that the problem was
occurring in the detect_cpu code. I'd forgotten that a minimal amount of CPU
detection was done earlier as part of reset handling. The code you're looking
at is part of the code to disable the PMMU during a reset (necessary if the
reset is a software reset).
Here's the relevant part of the commented source FYI. Please excuse the macros
for the instructions; they exist so that we can assemble the whole module as
move.l #not_68030,0x2c // PMOVE is lineF on non-68030 systems
PMOVE_TO_TTR0(zero) // first initialise the TTRs (ACRs on a 68ec030)
move.l #mmu_done,0x2c // since PMOVE_TO_TC doesn't exist on a 68ec030,
PMOVE_TO_TC(zero) // we're done if we get a lineF exception ....
move.l #mmu_done,0x10 // if a MOVEC causes an exception, we're done
MOVEC_D0_ITT0 // first initialise the TTRs (ACRs on a 68ec040)
MOVEC_D0_TC // disable translate on 68040-60 (will error out
// on a 68ec040)
As you can see, we assume it's a 68030/68ec030 and try to clear the TTRs/ACRs.
If that doesn't work, we try the 68040/68060 initialisation. Otherwise it's a
68030/68ec030 and we try to clear the TC. Whether or not that works, we're
done 68030/68ec030 PMMU initialisation.
Hope that clears things up,