[Coco] Interrupt Confusion

[Arthur Flexser]

On Sun, 11 Jan 2004, Brad Grier wrote:

> I'm having having a problem with two games in Mocha that appear to be 
> interrupt related - just when I thought I had all that ironed out!
> 
> Here's my understanding of how things should work with regard to the 
> 60ms IRQ. Please let me know if I'm wrong.
> 
> bit 0 of 0xff03 must be set to 1 to enable the interrupt
> bit 4 of the CC (IRQ Interrupt mask) must be set to zero for the cpu to 
> process the interrupt.
> 
> When an interrupt occurs, bit 7 of 0xff03 is turned on - another 
> interrupt cannot occur until a read of 0xff02 which clears bit 7 of 0xff03.
> 

This doesn't quite correspond with how I understood it to work, which may
or may not be entirely right.  The interrupts occur regardless, if bit 0
of $FF03 is set.  But effectively, this doesn't matter;  if you don't
clear bit 7 with a read of $FF02, this bit just stays set.  If interrupt
processing is enabled in the processor, as soon as the interrupt service
routine returns, it immediately gets called again since the processor
"sees" the flag as still set.  So, effectively, you never escape from
interrupt servicing and your program crashes.  This is why it is customary
to embed a read of $FF02 within the IRQ service routine just before it
returns. A simple demonstration of this is to enable the HS IRQ from Basic
with a poke to $FF01 that sets bit 0.  Basic will crash, because its HS
IRQ servicing returns without clearing the flag (by reading from $FF00)
first.  But if you patch it so that the flag does get cleared, Basic keeps
on going, albeit at a snail's pace.

> First question: if the CC register's IRQ mask is on, does an interrupt 
> still fire (even though it's not processed by the CPU) causing bit 7 of 
> 0xff03 to be set? In other words, do 'unprocessed' interrupts continue 
> to fire if the CC register's IRQ flag is on?

Yes, they do.  Some "wait for interrupt" routines, ones that don't rely on
the SYNC instruction, instead just loop until that bit 7 flag pops up,
which it will regardless of whether interrupts are enabled in the CC. In
fact, strange things can happen if you execute such a loop with interrupts
enabled in the processor, when the behavior of the software depends on
exactly where you are in the loop when the IRQ service routine, which has
cleared the flag, returns.  I remember tracking down a weird ADOS
incompatibility due to this, where animation would freeze up after a few
seconds under Ext. ADOS-3 and yet would work fine under RSDOS, due solely
to some extra stuff in the ADOS IRQ service routine that threw off some
fortuitious timing that enabled the program to work okay under RSDOS.  
Replacing the loop with a SYNC cured it.  (Problem was that whenever the
loop checked for bit 7 being set, it never was under ADOS because the
service routine had just cleared it.)  Maybe something odd like this is
causing your present headaches.

Art