Re: [hatari-devel] New WinUAE core issue with Bad Mood?

[ Thread Index | Date 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).

Roger




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/