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

[ Thread Index | Date Index | More Archives ]


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.


Mail converted by MHonArc 2.6.19+