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

[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)

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

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

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).