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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Hello

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.

Nicolas