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

Am 29.12.2023 um 18:46 schrieb Andreas Grabher <andreas_g86@xxxxxxxxxx>:

Am 29.12.2023 um 16:34 schrieb Toni Wilen <twilen@xxxxxxxxxx>:

>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?

It is done this way because Amiga NMI is not used in Amigas except via external hardware (freezer cartridge or NMI button) and it always sends quick pulse only.
But perhaps it can be made more compatible anyway, I'll need to first check NMI generating HW emulation still works.

(Nested NMI is possible, NMI is edge triggered which means if hardware pulses NMI continuously, you will get lots of stacked NMIs)

I agree that in the case of pulsed (interrupt level going up and down) NMIs multiple exceptions should be generated. But if level 7 stays active it should not be possible to cause another NMI interrupt exception. If I correctly understand your explanations level 7 interrupt never stays active on the Amiga and therefore there are no issues with the current code for your purpose.

>The complexity of interrupt code in WinUAE is very high due to
>handling lots of different CPUs and emulation modes.

If you don't need to care about interrupt delays (=you want fast emulation only and/or CPU is 68030+), you can ignore everything that needs "m68k_interrupt_delay" set. This makes it much simpler.

I see. I only need 68030 and 68040 (both with MMU).

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

Not really because I want to keep everything in same routine (cycle-exact 68000 and fastest possible etc). Not that it would help much because it is only called when needed and the complex stuff only happens in cycle-exact modes.

But I am not sure if "do_specialties()" fits with non-Amiga HW because it has lots of custom chipset stuff included. Maybe trace and interrupt part should be separated to make it a bit more cleaner and less system-specific.

I agree with that idea. It would be very convenient if essential CPU operations would be separated from platform-specific routines. This would improve portability. Maybe there could be some differences in naming so we can easily distinguish between flags that are part of fundamental CPU operation, flags that are used for peripherals and flags that are used for program flow like break and mode change.

Anyway, MMU fix is as simple as: if MMU bus error RTE is executed and CPU is 68060 or mmu_restart is set (68040 restart), do not check interrupts or trace but directly execute next instruction (=which is actually same instruction as previous instruction).

I see. So if I put an „if(!(regs.spcflags&SPCFLAG_MMURESTART)“ around my interrupt polling code it should be fine. The flag will then be unset inside do_specialties() before the next instruction (I want to keep differences as minimal as possbile).