Ruud Baltissen wrote:
>
> The SRC revealed that the unused port A is read to clear the IRQ caused by
> the ATN line. I can disable IRQ with the instruction SEI. If during the time
> IRQ that is disabled an ATN shows up, the IRQ-input of the 6502 is negated.
> Question: if I enable IRQ again with CLI, will this IRQ still be handled?
>
> AFAIK the answer is "Yes", but I want a conformation please.
>
The IRQ is not "cached" in any way, but if the IRQ line is still active
(i.e. negated) when you do the CLI (as it would be unless you explicitly
cleared the ATN condition by reading port A before the CLI), the IRQ
will be taken of course.
Similarly, if you forget to clear an IRQ condition inside an interrupt
handler by doing whatever is needed to clear it, the interrupt would
immediately occur again when you return from the interrupt handler and
the RTI re-enables the interrupts.
You need to think about the IRQ as a condition and not an event.
Whenever the IRQ line is active and interrupts are enabled, an interrupt
will occur (well, actually this condition is only checked at the
beginning of each instruction, but that's something you usually don't
have to think about).
This logic is what enables sharing of the (open collector) IRQ line. If
two devices pulls IRQ at the same time an interrupt will occur.
Interrupts will be implicitly disabled and your interrupt handler will
be executed. Inside your interrupt handler you will check if device A
caused the interrupt by reading some control register inside device A.
If it did, you will branch off to whatever code you have to service the
interrupt, and part of that would be to tell device A that the interrupt
has been acknowledged and that it should release the IRQ line.
After servicing the interrupt your interrupt handler will do an RTI and
control will be returned to the main execution thread and interrupts
will be re-enabled.
Now, since device B is still holding the IRQ line active (because you
haven't yet told it that its interrupt condition has been acknowledged),
another interrupt will occur immediately. Your interrupt handler will
again check if device A caused the interrupt. Since it didn't this time,
your handler will go on to check device B for an interrupt condition and
branch into the code to handle an interrupt from device B. Again, part
of that code would be to acknowledge the interrupt by telling device B
to release the IRQ line. Thus, when you return with RTI, the IRQ line
would be inactive and no more interrupts will occur (until something
activates the IRQ line again, of course).
--
Christer Palm
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail 2.1.1.