Raster interrupts and memory operations interrogation

Hi!

This is more of a question about raster interrupts than anything else.
I assumed that when an interrupt is triggered, it has priority and the execution of the display list begins immediately, regardless of what the main program is doing.

However, that doesn't seem to be entirely the case.

For example, if I add the following line (to make a memory operation) to the main loop of the RASTR_INT.SRC sample program:

memCpy(0x3000, 0x300F, 160, 0x8F);

or even a simple "poke", it has a significant impact on the interrupt processing, which sometimes appears to be skipped.

On the other hand, using "print", "input", "sprPos", or "sprUpdt" has no effect at all.

Perhaps this is normal, or perhaps it isn't - I honestly don't know!

That's why I'm asking.

If this behavior is expected, it might be worth mentioning in the manual that certain operations are not interrupted in order to service raster interrupts.

 

Yes interrupts are treated immediately (right after the current cpu instruction completes), whatever the processor is currently doing.

However I found a bug !
If an instruction in the main VM thread is modifying the memory page (like poke or memSet potentially do), that can impact the interrupt as well as the display list itself (the cpu address bus can only be at a single place at a time). I've fixed the problem by setting default page at the start of the interrupt and restoring whatever page was used in the main thread at the end of the interrupt. The fix will be available in V0.7.9

Also some other subsystems such as timers, MIDI, mouse and keyboard also generate interrupts and interrupts can be nested, which can cause an interrupt to be interrupted in rare cases.

Thanks for pointing that out!