quick question about interrupts

[ervin]

Hi everyone.

One thing I've never really explored in much depth is how to use interrupts on the cpc.

I'm wondering - is there a way to know which interrupt is about to happen, without keeping a counter?
Missing an interrupt (due to the previous interrupt code taking a bit too long, or if interrupts are briefly disabled) will cause the counter method to fail, I would think.

[McArti0]

B8BF is native firmware counter 6,5,4,3,2,1 used to scan keyboard. When you wait for vsyn and set B8BF to 1 , next interrupt will be setting 1 to 6 and scan keyboard.

[andycadley]

More generally, no there is no way of knowing which interrupt it was. The hardware just generates an interrupt periodically and doesn't really care about how many have occurred so far.

I'd assume the firmware checks for frame flyback and uses that to figure out when to reset its counter, but I've never looked into it that deeply.

For the most part it's not likely to be an issue unless you're disabling interrupts for extended periods of time (say because you're using the stack to clear RAM or something). Or you're doing most of your work inside an interrupt handler. It's probably one of those things only worth worrying about when it becomes an actual issue, as refactoring the design can usually eliminate the issue.

[McArti0]

Of course this counter is desynchronized with vsync and when you use DI  for too long or disk routines. Then you need to re-synchronize. wait for Vsync and set the counter. This is also a way to force the interrupt to be used for keyboard scanning and tick clock 300Hz

[ervin]

Thanks all, that's very useful info.

The only reason I want to be able to have interrupts active is to, at some point, have interrupt-driven music. I guess I could have a variable (hasMusicPlayed or something like that), which is reset on vsync, and then any interrupt afterwards checks it, plays music if the variable is 0, and then sets the variable to 1, so that music isn't played again until after the next vsync.

This is just initial thoughts on the idea, so I might be barking up the wrong tree!

[andycadley]

If you're in a position you can reset a variable on every frame, you might just as well call the music player directly at that point instead. There's nothing special about "interrupt driven" music, other than it's designed to be called periodically.

[ervin]

Yes I guess you're right.
I'll still experiment with interrupt-driven music, just out of curiosity.