Re: [hatari-devel] Many changes to MFP - Part 2

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Hello

after refactoring the MFP's interrupt handling with the CPU, I just 
added another required behaviour : the ability to update the MFP's state 
while an ongoing MFP exception is already going on.

Basically, when the MFP raises an interrupt/exception with the 68000 by 
changing IPL, the 68000 will fetch the vector number associated with the 
MFP interrupt 12 cycles after the start of the exception, during an IACK 
phase.

This means that during this small timeframe of 12 cycles, a new 
interrupt could happen in the MFP (setting twice the same pending bit, 
or setting the pending bit for a higher priority interrupt).

So, the vector number used by the 68000 to process the exception (and 
the corresponding handler) must be updated after 12 cycles, it can 
change from its initial value that triggered the exception.

This is a very rare case, but some programs rely on this to work 
(sometimes due to bad design in the program itself) and it should be 
emulated correctly.

This will fix for instance :
 - Anomaly Demo Main Menu : samples on timer C could prevent timer B 
from starting at the expected cycles. But as timer B happens during 
those 12 cycles, it should be processed first.

 - The Final Conflict : this games play a sample music in the intro. 
The replay code is quite buggy and only works by luck, because pending 
bit is sometimes set twice before IACK, which skips one MFP's exception 
and allows the VBL's interrupt to start.

I changed win-uae cpu too to use this, please check that nothing is broken.

PS : some warnings appear during compilation, that's debug code that 
will be removed soon if no immediate regression is seen.


Nicolas