|Re: [hatari-devel] Many changes to MFP - Part 3|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
an other batch of changes for MFP interrupts. Hopefully, this should be
the last one.
In some rare cases (depending on the number of cycles of the CPU
instruction), several MFP interrupts can go to the pending state, but
not necessarily at the same time during this CPU instruction.
This means that when the CPU instruction is completely processed, we
should not choose the highest priority MFP interrupt among all those
pending interrupts, but we should process only the interrupts that
chronologically happen first during this CPU instruction.
- consider a movem that take 80 cycles.
- timer C expires at sub cycle 10 during the movem
- timer B expires at sub cycle 40 during the movem
The CPU should not start an exception for timer B (which is the highest
priority one) by looking at all the pending interrupts at the end of the
movem, but instead it should start and exception for timer C.
This required some changes to when we call MFP_UpdateIRQ() (as it should
be called only once after a CPU instruction, not after each MFP input
signal) and to keep track of the most ancien pending event using
This fixes a crash with Fuzion CD Menus 77, 78 and 84 when using STF
mode and digidrums are played using timer C while the main demo uses a
lot of movem. Eventually, the timer B count was shifted by 1, which
resulted in bottom border not being removed and a crash in the demo.