Re: [hatari-devel] Suspected Hatari 2.3.0 regression (prefetch?)

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 12/16/20 2:41 PM, Christian Zietz wrote:
> Roger Burrows schrieb:
> >      movem.l  (a0)+,d1-d7/a2-a6         ; copy 48 bytes ***
> >      movem.l  d1-d7/a2-a6,$1d0(a1)
> >
> > The crash occurs in the second (and last) time through the loop, at the
> > instruction marked with *** above.  After that instruction, a0 will 
> > point to
> > $ff9c00 (although that address has not been read, at least from a 
> > programming
> > POV).  The error msg from Hatari is "Bus Error reading at address 
> > $ffff9c00".
>
> I know that the 68000 in fact does an extra memory access for MOVEM.x
> (Ax)+,... that can cause an unexpected bus error. I'm unsure, however,
> if newer 68k CPUs exhibit this side effect, too. To me, the fact that
> DELMPAINT runs on a real Falcon without crashing indicates that this
> extra access does not happen on a real 68030.

When running Delmpaint with cache and prefetch
emulation disabled (--cpu-exact off --compatible
off), it still crashes to:
WARN : Bus Error reading at address $ffff9c00, PC=$35ec8 addr_e3=35ec8 
op_e3=4cd8

(Enabling 32-bit addressing didn't change anything
either.)

However, extending the readable area by *single*
byte allows Delmpaint to start fully:
-----------------------------------------
--- a/src/ioMemTabFalcon.c
+++ b/src/ioMemTabFalcon.c
@@ -410,7 +410,7 @@ const INTERCEPT_ACCESS_FUNC IoMemTable_Falcon[] =
        { 0xff9220, SIZE_WORD, IoMem_VoidRead, 
IoMem_WriteWithoutInterception },          /* Lightpen X position */
        { 0xff9222, SIZE_WORD, IoMem_VoidRead, 
IoMem_WriteWithoutInterception },          /* Lightpen Y position */

-       { 0xff9800, 0x400, IoMem_ReadWithoutInterception, 
VIDEL_FalconColorRegsWrite },   /* Falcon Videl palette */
+       { 0xff9800, 0x401, IoMem_ReadWithoutInterception, 
VIDEL_FalconColorRegsWrite },   /* Falcon Videl palette */

        { 0xffc020, SIZE_BYTE, IoMemTabFalc_Compatible_ReadByte, 
IoMemTabFalc_Compatible_WriteByte },
        { 0xffc021, SIZE_BYTE, IoMemTabFalc_Compatible_ReadByte, 
IoMemTabFalc_Compatible_WriteByte },
-----------------------------------------


Because there aren't more programs requiring
MMU with Hatari v2.3, I suspect this issue to
be specific just to certain instructions or
addressing modes.

I think otherwise there would be much more
programs that won't work without enabling
MMU emulation...


	- Eero

PS. In some cases enabling MMU slows down
the emulated program hugely.  Is this expected?