gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > Multiple interrupts

#13422 - poslundc - Sat Dec 13, 2003 2:14 am

I'm looking at combining my graphics engine with my music engine, and it has me a little bit nervous. Basically because both rely heavily on interrupts, and I'm concerned about collisions occuring between the two. Here's the skinny on it:

- Graphics engine has a HBlank ISR that pretty much has to run and cannot afford to be pre-empted with the short length of time that HBlank lasts.

- Music engine relies on a timer that interrupts at a frequency of 4096 Hz.

My ideal situation would be to have both interrupts enabled, and if the music interrupt is activated during the HBlank ISR then it would be blocked until the HBlank ISR completed (and if the HBlank ISR was activated during the music ISR, then it would interrupt it).

I suppose I can at least change my HBlank ISR so that the first thing it does is set REG_IME to zero, and then just before returning sets REG_IME to 1. The problem with this, though, is that if I understand correctly then it won't simply block my music interrupt, it'll ignore it entirely, and some samples will go missing as a result. I'm guessing that over the VDraw period this could accumulate to become quite a nuisance.

Are there any suggestions as to how I should be dealing with this?

Thanks,

Dan.

#13427 - torne - Sat Dec 13, 2003 5:05 am

DKA 5 has a prioritised multiple interrupt handler.

#13429 - poslundc - Sat Dec 13, 2003 6:21 am

Forgive me for being naive, but I've just been using a pre-compiled Mac OS X version of DKA, and don't know an awful lot about upgrading it.

I know in the version that I have, interrupts are handled by crt0.S. In order to get this improved functionality, do I just need to get the more recent version of crt0.S? If so, which of the packages on the website contains it? Or is the only way to get this improved functionality by recompiling the whole darned thing?

Does the new DKA ISR handle the priorities in the way I was describing? I'm not shy about coding an interrupt handler (I was planning on going in and messing with the one in crt0.S eventually anyway), it's just that I don't really know how to block (ie. detain) lower-priority interrupts without skipping them entirely.

Thanks,

Dan.

#13434 - gb_feedback - Sat Dec 13, 2003 12:31 pm

Quote:
Music engine relies on a timer that interrupts at a frequency of 4096 Hz.
I suppose this means that your dma is using the interrupt to request 4 bytes at a time? I know it won't be a welcome suggestion, but wouldn't it be better to do the dma from a couple of buffers long enough for one frame, and not use interrupts at all. I tried it once using interrupts, but it was all too time critical and kept locking up on me. Doing all the work during vblank fixed everything.

If I've misunderstood what you're doing - ignore this.
_________________
http://www.bookreader.co.uk/

#13436 - torne - Sat Dec 13, 2003 12:39 pm

poslundc wrote:
I know in the version that I have, interrupts are handled by crt0.S. In order to get this improved functionality, do I just need to get the more recent version of crt0.S? If so, which of the packages on the website contains it? Or is the only way to get this improved functionality by recompiling the whole darned thing?


You should just be able to replace the crt* files and the link script.

Quote:
Does the new DKA ISR handle the priorities in the way I was describing? I'm not shy about coding an interrupt handler (I was planning on going in and messing with the one in crt0.S eventually anyway), it's just that I don't really know how to block (ie. detain) lower-priority interrupts without skipping them entirely.


Just read the DKA code, then, and write your own. Basically, all you need to do is to write to the IE register to disable all interrupts of lower priority than the one you are currently processing (they will still be generated, and will thus be handled when you turn them back on), then reenable interrupts by flipping the I bit of the CPSR. It's slightly fiddly to get it all done in the correct order so as not to cause any races; the No$ documentation has some details.

#13441 - poslundc - Sat Dec 13, 2003 3:51 pm

gb_feedback wrote:
Quote:
Music engine relies on a timer that interrupts at a frequency of 4096 Hz.
I suppose this means that your dma is using the interrupt to request 4 bytes at a time? I know it won't be a welcome suggestion, but wouldn't it be better to do the dma from a couple of buffers long enough for one frame, and not use interrupts at all. I tried it once using interrupts, but it was all too time critical and kept locking up on me. Doing all the work during vblank fixed everything.


I've experimented with buffered systems and they work okay... the thing is that the latest mixer I wrote processes exactly four samples in its loop. So I figured at the cost of having two DMAs running (which means halting the CPU, running DMA1, running DMA2, and then restarting the CPU) every frame I might as well just have an interrupt do it and not have to worry about keeping track of and switching up the DMAs (in a double-buffered system).

It's actually worked pretty well... but now I'm thinking of scaling it down to a simpler half-panning system that uses scaling instead of clipping, so I may go back to using a buffer, who knows. :P

Dan.

#13442 - poslundc - Sat Dec 13, 2003 4:03 pm

torne wrote:
Just read the DKA code, then, and write your own. Basically, all you need to do is to write to the IE register to disable all interrupts of lower priority than the one you are currently processing (they will still be generated, and will thus be handled when you turn them back on)


Is that so? It'll be easy to code, then. I was under the impression, though, that if you didn't have the bits flipped on in REG_IE that the interrupts wouldn't be generated. This is the lynchpin to the operation, since if the interrupts are skipped instead of just held up then my system won't work.

So if, for example, I were to enable VBlank interrupts in REG_DISPSTAT but not in REG_IE, then suddenly at some point in my program turn VBlank interrupts on in REG_IE, would I immediately have a VBlank interrupt regardless of whether I was in VBlank or not because of an initial interrupt trigger many VBlank cycles ago that was detained instead of skipped?

Thanks,

Dan.

#13454 - torne - Sat Dec 13, 2003 7:37 pm

poslundc wrote:
So if, for example, I were to enable VBlank interrupts in REG_DISPSTAT but not in REG_IE, then suddenly at some point in my program turn VBlank interrupts on in REG_IE, would I immediately have a VBlank interrupt regardless of whether I was in VBlank or not because of an initial interrupt trigger many VBlank cycles ago that was detained instead of skipped?


Yes, you would. That's exactly how it works. The actual enabling/disabling of the *event* is handled in some event-specific way (for h/vblank it's in DISPCNT, for timers it's whether the timer is running..etc). REG_IE only affects whether the events actually interrupt the CPU; they happen regardless.

#13457 - gb_feedback - Sat Dec 13, 2003 8:01 pm

Quote:
I've experimented with buffered systems and they work okay... the thing is that the latest mixer I wrote processes exactly four samples in its loop. So I figured at the cost of having two DMAs running (which means halting the CPU, running DMA1, running DMA2, and then restarting the CPU) every frame I might as well just have an interrupt do it and not have to worry about keeping track of and switching up the DMAs (in a double-buffered system).
When I tried something similar the killer was that the amount of processing varied quite a lot depending on the state of each channel. So sometimes the interrupt timing was critical. Spread over a whole frame the average processing load was never critical.
Also the actual interrupt overhead (times many interrupts per frame) added significantly to the actual mixer processing.

Hell - just knocked over my drink all over the mouse!
_________________
http://www.bookreader.co.uk/