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.