7

In the Apple II, DMA and IRQ priority is determined by a daisy-chain system, in which a card may only assert an IRQ or perform DMA when all higher-priority cards allow it.

I understand the importance of “following the rules” with DMA and not doing DMA out of turn, since there can only be one bus master at a time. But what are the negative consequences of asserting an IRQ at the same time as another card? I have seen some cards with participate in the IRQ daisy chain and others which assert IRQ but which ignore the priority daisy chain. What additional considerations must be made when designing a card which asserts IRQ regardless of the IRQ daisy chain input?

  • It's a guess, but perhaps the design of the typical IRQ handler for the Apple was to invoke the service routines in priority order and stop as soon as the one card causing the IRQ was serviced. – Brian H Dec 13 '19 at 18:33
3

But what are the negative consequences of asserting an IRQ at the same time as another card?

Overhead and delay during the interrupt handling, but more important potential mixed up priorities.

Priority

After all, the 6502 provides only a single interrupt. If multiple cards issue interrupts at the same time, the handlers will be called in the sequence they hooked the vector. When called a handler has to check if it's its own card the interrupt is about - by whatever means. If not, the chain is continued. This means priority is handled in reverse sequence of handlers installed - read, the last one installed gets the highest priority.

Possible Ways to Screw Up Priority

  1. When drivers are installed as part of initialization - like when searched by the Autostart Monitor, or some OS - they are usually installed top down, so from slot 7 down to slot 1 - which is the native priority on an Apple II. Due this sequence, lower slot number drivers will get higher priority - which is at least unexpected.

  2. When drivers are installed after OS setup by some script or software, they come up in random order, resulting in random priority.

Both can be avoided when cards obey the hardware protocol as now priority is always fixed and following the same scheme which fis well the basic philosophy of geographic addressing/handling of the whole Apple II.

Interwoven Interrupts

A good interrupt handling considers two factors

  1. Concurrent should be served in sequence of priority
  2. Lower priorized interrupts should give way as soon as possible if a higher one occures.

While the first can as well be handled in software, the second needs cooperation of software and hardware. Usually an interrupt can be sliced into 4 pahses:

  1. Interrupt recognition

    -> Checking if the interrupt is about (one of) the handlers devices

  2. Data acquisition

    -> All acivity that has to be done uninterrupted

  3. Interrupt acknowledge/clearing

    -> Clearing the interrupt source

  4. Housekeeping

    Whatever is needed to transport data and setup everything for the next interrupt round.

  5. Getting ready for the next (own) interrupt

    -> Whatever else needs to be done, but can happen without blocking other interrupts.

Usually phase 3 ends with a CLIinstruction allowing other interrupts to happen. From this point on any other interrupt may occur, no matter if of higher or lower priority - as the CPU itself has no knowledge about priority. While this is in general a good idea, it might lead to a situation where lower priorized interrupts hit and get the full time to finish - including housekeeping, before a higher can have his part done.

With simple handlers/interrupts, this may work fine, but more often than not it leads to most housekeeping done during phase 2, and doing the CLI only at the end of phase 5. As a result the the system will become a bit less responsive.

But if the hardware obeys not only the interrupt protocol (enabling priority), but active controls the interrupt protocol, over all responsiveness may/will improve.

What additional considerations must be made when designing a card which asserts IRQ regardless of the IRQ daisy chain input?

The Hardware should for one obey the priority chain, so only issue an interrupt if no higher priority one is active and pulling the chain if it got one, but as well make releasing the chain again a separate step.

This leaves it up to the software (interrupt handler) to act as cooperative as possible:

  • Check for prior handler when installing
  • Mark down that address
  • Check if the interrupt is really from your source.
    • If not, jump to any prior driver - if none, return (*1)
  • Handle whatever of that interrupt processing must be done without any time delay. Usually this isn't much - if any at all.
  • Up until here the handler is protected against any interrupt
  • Release the interrupts (CLI), but keep the chain pulled.
    • From this point on higher priorized interrupts as well as any interrupt not following the protocol can happen.
  • Continue with whatever has to be done.
  • Release the chain
    • From this point on any lower priorized interrupt (that follows the protocol) may happen as well.
    • The handler is still protected against his own interrupts
  • Reinitialize your hardware to be able to issue new interrupts
    • Now everyone, including your own hardware can interrupt again (*2).
  • RTI

Sounds complicated, but isn't and easy to implement.


*1 - In general this is done by having the jump always point to an RTS and patching it when a prior driver existed.

*2 - It might be a good idea to disable interrupts right before doing so - to be released by RTI - to avoid interrupt stacking under high load/overload.

| improve this answer | |
  • 2
    Amazingly thorough answer. You have clarified the matter completely. Only a tiny bit of Apple II hardware and software is being made today, but I think the quality of your answer will guide us to make better hardware and software which uses interrupts. – Zane Kaminski Dec 13 '19 at 22:53
  • 1
    @ZaneKaminski There is much more about interrupts. Above just focuses on the direct hardware side. Interrupt handlers, especially when they are supposed to work with ProDOS do need a bit more TLC. For an old time Apple II nerd, like me, it would be interesting to see what hardware you're working on. – Raffzahn Dec 13 '19 at 22:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.