|Re: [hatari-devel] New WinUAE core issue with Bad Mood?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 6 Dec 2014 at 0:38, Nicolas Pomarède wrote:
> Le 04/12/2014 20:05, Eero Tamminen a écrit :
> > Some additional issues I noticed:
> > - EmuTOS 512k doesn't boot up in TT or Falcon mode, it just endlessly
> > bus errors.
> regarding emutos, I think the problem is that if the cpu is 68030, then
> emutos expects the MMU to be available. I also get crashes if I don't
> select MMU when 68030 is selected.
> - 68020 without MMU -> emutos 0.93 OK
> - 68030 with MMU -> emutos 0.93 OK
> - 68030 without MMU -> emutos crashes
You're correct, the latest version of EmuTOS expects that a real 68030 will
have the PMMU available. It sets up the PMMU tables just like TOS 3.06.
However, during startup, if the processor appears to be a 68030 but PMOVE from
TC gets an exception, EmuTOS will assume it's running on a 68ec030 which it
doesn't expect to have a PMMU.
> Can you try it too ?
> In all accuracy, a real 68030 has a MMU, so it's "normal" that emutos
> crashes if it finds a 68030 but the MMU instructions are disabled.
> But the winuae's cpu core also has a "fake mmu" mode : it behaves as if
> all mmu's registers/instructions were present (so no illegal or line-f
> exceptions), but it doesn't do any translation job.
> This could be a solution if people just want a 68030 but not the MMU's
> translation overhead : enable fake mmu instead of completely disabling
> mmu (but of course, if emutos really set some particular MMU's tables,
> then you might get crashes later anyway).
In this case, I think it would be best to give an illegal instruction on
PMMU-related opcodes (see above).