Re: [hatari-devel] 68040/060 MMU bug fix

[Andreas Grabher <andreas_g86@xxxxxxxxxx>]

Hello Toni,

thank you for pointing out this fix! This finally does no longer fit my interrupt polling code in run_mmu030 and run_mmu040:

https://sourceforge.net/p/previous/code/HEAD/tree/branches/branch_softfloat/src/cpu/newcpu.c#l6422

So it is time to use the WinUAE method of interrupting. There are questions and suggestions arising that may also be relevant for Hatari:

The interrupt code of WinUAE is quite confusing. Is my understanding of the code correct and all I have to do is set SPCFLAG_INT if the interrupt priority line changes (gets raised or lowered)? I’m only using run_mmu030() and run_mmu040().

Unfortunately there is a little difference in the way interrupts are handled by Previous and WinUAE/Hatari. WinUAE/Hatari does this:

intr = intlev();

if (intr > 0 && (intr > regs.intmask || intr == 7))

do_interrupt(intr);

Previous does this:

intr = intlev ();

if (intr>regs.intmask || (intr==7 && intr>lastintr))

Exception (intr + 24);

lastintr = intr;

This reflects the behaviour of the real CPU and is necessary to correctly handle level 7 interrupts (avoid nested NMIs). Is there a chance this will be fixed in WinUAE?

The complexity of interrupt code in WinUAE is very high due to handling lots of different CPUs and emulation modes. This increases the chance to mess things up unintentionally. There is interrupt code in lots of places using SPCFLAG_INT, SPCFLAG_DOINT, regs.ipl[0], regs,ipl[1], regs.ipl[2], ipl_pin, ipl_pin_p, do_interrupt(), check_interrupt(), ipl_fetch_xxx(), doint(), checkint(), m68k_interrupt_delay, m68k_accurate_ipl … just to name a few.

Is there a chance this will be cleaned up a bit which would also improve performance?

Regards,

Andreas

Am 28.12.2023 um 17:59 schrieb Toni Wilen <twilen@xxxxxxxxxx>:

Hi

Just a note that few hours ago I fixed nasty and normally rare random 68040 MMU emulation bug. If interrupt was pending (and interrupts were enabled) when bus error handler executed RTE (and handler had interrupts disabled by setting imask=7), interrupt's first instruction was "retried" instead of the faulting instruction. Normally not that serious (but can cause problems in some situations) because RTE from interrupt handler would "retry" it  anyway but if both are MOVEM to memory, then interrupt handler's MOVEM used faulted MOVEM's pre-calculated EA.

68060 does not have this MOVEM EA feature but in some situations it can also cause bad results. 68030 is not affected because it does not restart instructions.

(https://github.com/tonioni/WinUAE/commit/0be6d4eaca09acdb838c0c6ea45c57267c8f4cce unfortunately I included some do_specialties() clean ups in same patch, just ignore it)