On Fri, 2 May 2003, matthew conte wrote:

> there's no need to handle game pak interrupt at highest priority. only one
> interrupt is handled per entry to the main ISR (for most usual setups), so
> giving the lowest priority is fine.

I think I see what you mean. If you have multiple interrupts enabled like
how Nintendo has demonstrated, then a "lower priority" interrupt will
still preempt a higher priority one. The order that you check the IF
flags doesn't mean anything if any interrupt which happens preempts the
one you are currently processing.

It is like a store where any customer who comes to the counter will get
immediately served. It would be pretty annoying to a customer with a lot
of stuff to buy, but really convenient for those people with just a couple
of things. The problem is that if the person with just a couple of things
was being served, he would have to wait if the big customer came up behind
him him (but this is less likely because the small customer is so fast).

I guess interrupts that do not need to be preempted can set IME to 0. It
will be restored by the main ISR.

Hmm, how does the multiple interrupt process keep from processing the same
interrupt twice? If an interrupt high on the list was being processed,
and then an IRQ lower on the list occured, isn't there a situation where
the IF bit for the higher IRQ has not been cleared yet? In that case
wouldn't the ISR confuse which interrupt had occured?

I guess a true priority system would return from the ISR without clearing
the IF flag and handling the interrupt if the interrupt was lower
priority. I assume that if you return from your ISR without writing the
bits of the IRQs you handled to IF, that the IRQ will be immediately
reasserted.

In a single interrupt system, the order has meaning because the IRQs which
occur while you were processing the current IRQ will be waiting. When it
cames back into the ISR, the one highest on the list will get processed
first. I assume the IME simply keeps IRQs from being asserted, but that
if they are enabled in every other whay they still set IF and will be
asserted when IME is set to 1.

I dunno, the more I think about it, the more confused I get. Nintendo's
sample code seems to work just fine for the most part, so I must assume
that any questions I ask have satifactory answers.

I am concerned about how the multiple IRQ ISR knows if it is already
processing an interrupt in another context. Is the IE bit reset until
you reset the equivalent IF bit? If so, then that would explain the IF&IE
instruction and explain how it knows to only process new interrupts.

Is this explained in detail anywhere?

> but if you disable all interrupts, you'll never get the game pak interrupt
> if someone inserts the cart again. ;)

I guess if you are looking to allow reinsertion you should push the IE
onto the stack, clear it except bit 13, and then wait.

I was thinking in context of what a simple cart interrupt handler for
devkitadv might do. I would probably just reset IME and be done with in
that case. Anything more complicated would be up to the programmer to
override.



> regards,
> matthew.