[hatari-devel] Re: Hatari 040/060 + MMU exception handling regression

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

Git bisect gave this as the Hatari commit breaking
040/060 + MMU exception handling for EmuTOS:
-----------------------------------------------
6476cca9daf6e3ab114d75474f5fb76b1580107c is the first bad commit
commit 6476cca9daf6e3ab114d75474f5fb76b1580107c
Author: Nicolas Pomarede <npomarede@xxxxxxxxxxxx>
Date:   Mon Feb 17 18:11:40 2020 +0100

    Enable the new bus error handler in WinUAE's cpu core and set 
'hardware_bus_error=1' on bus error

diff --git a/src/m68000.c b/src/m68000.c
index 4bf3b3d1..bea402d5 100644
--- a/src/m68000.c
+++ b/src/m68000.c
@@ -651,11 +651,16 @@ void M68000_BusError ( Uint32 addr , int ReadWrite 
, int Size , int AccessType )
                bBusErrorReadWrite = ReadWrite;
                M68000_SetSpecial(SPCFLAG_BUSERROR);            /* The 
exception will be done in newcpu.c */
        }
+#else
+#define WINUAE_HANDLE_BUS_ERROR
+#ifdef WINUAE_HANDLE_BUS_ERROR
+       hardware_bus_error = 1;
 #else
        /* With WinUAE's cpu, on a bus error instruction will be 
correctly aborted before completing, */
        /* so we don't need to check if the opcode already generated a 
bus error or not */
        exception2 ( addr , ReadWrite , Size , AccessType );
 #endif
+#endif
 }

-----------------------------------------------

Grepping for the new variable shows:
-----------------------------------------------
$ git grep -l hardware_bus_error
src/cpu/cpummu030.c
src/cpu/debug.c
src/cpu/gencpu.c
src/cpu/newcpu.c
src/cpu/newcpu.h
src/m68000.c
-----------------------------------------------

I.e. that variable isn't used in the cpummu.c
file where 040 & 060 MMU emulation is.

Nicolas, Toni?


Attached patch is a workaround fixing 512k EmuTOS
boot with 040/060 + MMU.

(EmuTOS calibration loop seems to take quite long
long on 060.)


	- Eero

On 4/2/20 1:48 AM, Eero Tamminen wrote:
> Thanks Christian for the analysis!
>
> I'm cross-posting this to hatari-devel.  Feel free
> to reply to whichever list feels more suitable as I (and most of the 
> others) are on both.
>
> On 4/1/20 10:09 PM, Christian Zietz wrote:
> > Christian Zietz schrieb:
> > > Eero Tamminen schrieb:
> > > > I was wondering whether anybody can think of
> > > > a reason why EmuTOS boot would stop in ide_init(),
> >
> > > I've started to investigate and will continue doing so.
> >
> > There's something seriously wrong with the emulation of exceptions in
> > the failing Hatari configuration, i.e., with 68040 and MMU. EmuTOS does
> > not get *any* bus errors while probing for possible IDE interfaces [1]
> > and, thus, detects four of them. Therefore, it will spend four times the
> > IDE timeout (31 seconds) while waiting for any attached IDE drives to
> > become ready.
>
> I guess this could in theory happen also if MMU is
> configured to map IO area to wrong place, not just
> with broken Hatari 040 MMU emulation?
>
> (Although things working with older Hatari version
> make it unlikely.)
>
>
> > When you wait long enough (= more than two minutes), it gets past
> > ide_init() and through the entire bios_init(). But it crashes with a
> > nonsensical exception, before getting to the Desktop:
> >
> > Panic: Exception number -937
> > sr=ffff pc=ffffffff
> >
> > D0-3: 00000000 00000000 00000000 00000000
> > D4-7: 00000000 00000000 00000000 00000000
> > A0-3: 00000000 00000000 00000000 00000000
> > A4-7: 00000000 00000000 03fb4fc6 fffffff0
> >   USP: 03fb4ff8
> >
> > Also note that the failing Natfeats could point in the direction of
> > exception emulation issues, too, since afaik Natfeats rely on an illegal
> > instruction.
> >
> > I think this is the point where you could start bisecting Hatari (if
> > you're not already doing so), given that older versions of Hatari work
> > with the same configuration.
>
> I haven't done that yet, I'll do it later this week.  It's possible that 
> e.g. one of the WinUAE
> CPU core updates missed some Hatari integration
> bits.

diff --git a/src/m68000.c b/src/m68000.c
index bea402d5..a1045de5 100644
--- a/src/m68000.c
+++ b/src/m68000.c
@@ -654,12 +654,18 @@ void M68000_BusError ( Uint32 addr , int ReadWrite , int Size , int AccessType )
 #else
 #define WINUAE_HANDLE_BUS_ERROR
 #ifdef WINUAE_HANDLE_BUS_ERROR
+	if (changed_prefs.cpu_model <= 68030)
+	{
+	/* FIXME: this is used only in cpummu030.c, not cpummu.c */
 	hardware_bus_error = 1;
-#else
+	}
+	else
+#endif
+	{
 	/* With WinUAE's cpu, on a bus error instruction will be correctly aborted before completing, */
 	/* so we don't need to check if the opcode already generated a bus error or not */
 	exception2 ( addr , ReadWrite , Size , AccessType );
-#endif
+	}
 #endif
 }