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

[ Thread Index | Date Index | More 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.

example :
 - 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 MFP_Pending_Time_Min.

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.


Mail converted by MHonArc 2.6.19+