|Re: [hatari-devel] Many changes to MFP - Part 2|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel 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
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
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.