Q7Microprocessors

Vectored Interrupts

A vectored interrupt is one in which, upon recognizing the interrupt request, the processor automatically transfers program control to a specific, predetermined memory address that is fixed by the processor's own hardware design for that particular interrupt input, without requiring the interrupting device to supply any additional address information over the data bus. In the 8085, the three interrupt inputs RST 7.5, RST 6.5, and RST 5.5, along with the non-maskable TRAP input, are all vectored interrupts, each hardwired to transfer control to its own specific fixed address when the interrupt is recognized and accepted: RST 5.5 vectors to address 002CH, RST 6.5 vectors to 0034H, RST 7.5 vectors to 003CH, and TRAP vectors to 0024H. Because each of these interrupt sources has its own dedicated vector address spaced eight bytes apart in the low memory area, a full interrupt service routine typically cannot fit directly at the vector address itself (since only 8 bytes are available before the next vector location begins) — the common practice is therefore to place just a single unconditional jump instruction (JMP) at each vector address, which then transfers control onward to the actual, full-length interrupt service routine located elsewhere in memory. Because vectored interrupts require no external hardware to supply an interrupt response (the processor itself already knows exactly where to jump for each of these specific interrupt inputs), they offer a fast, simple interrupt response mechanism requiring minimal additional interfacing hardware, at the cost of the associated interrupt handling being restricted specifically to whichever few, dedicated interrupt input pins the processor physically provides (in the 8085's case, three maskable vectored interrupts plus the non-maskable TRAP).

Non-Vectored Interrupts

A non-vectored interrupt, by contrast, has no processor-fixed service-routine address of its own; instead, when the processor recognizes and accepts the interrupt request, it activates an interrupt-acknowledge signal (INTA-bar in the 8085) directed at the external interrupting device, and it is then the responsibility of the external interrupting device's own hardware to supply an appropriate instruction opcode (or, in more elaborate multi-byte schemes, a full CALL instruction with its own target address) onto the data bus during this interrupt-acknowledge cycle, which the processor then executes exactly as if it had been fetched from ordinary program memory. In the 8085, the INTR pin implements this non-vectored interrupt scheme: upon accepting an INTR request, the 8085 issues INTA-bar, and the external interrupting device (via appropriately designed external hardware, commonly built around an 8259 Programmable Interrupt Controller in more elaborate multi-source systems) responds by placing a suitable RST instruction opcode (most simply, though in principle any single-byte, or via extended multi-INTA-cycle protocols even multi-byte, instruction could be supplied) onto the bus, which the 8085 then executes, transferring control to whatever address that supplied instruction specifies — since this target address is determined entirely by the external device's hardware response rather than by any fixed processor vector, a non-vectored interrupt scheme offers considerably greater flexibility in how many distinct interrupt sources can be accommodated and how their servicing addresses are assigned (particularly when combined with an external interrupt controller chip capable of prioritizing and individually vectoring numerous distinct interrupt request lines), at the cost of requiring additional external interfacing hardware to correctly generate the appropriate bus response during each interrupt-acknowledge cycle.

Practical Significance and Comparison

The essential distinguishing factor between vectored and non-vectored interrupts is therefore where the responsibility for determining the interrupt service routine's address lies: internally, fixed within the processor's own hardware for a vectored interrupt (fast and simple, but limited to a small, fixed number of dedicated interrupt inputs), versus externally, supplied by the interrupting device's own hardware for a non-vectored interrupt (more flexible and expandable to many interrupt sources via external controller chips, but requiring additional interfacing complexity). Modern practical 8085-based systems requiring more interrupt sources than the four dedicated vectored inputs (TRAP, RST7.5, RST6.5, RST5.5) provide typically expand their interrupt-handling capability precisely by using the INTR non-vectored interrupt input together with an external Programmable Interrupt Controller (such as the 8259, covered elsewhere in this paper), which can itself manage up to eight (or more, via cascading multiple 8259 devices) individually prioritized and vectored interrupt request lines, effectively converting what is, from the 8085's own perspective, a single non-vectored interrupt input into a much richer, externally-managed vectored interrupt system for the overall application.

Comparison of Vector Addresses

• TRAP: vector address 0024H — non-maskable, edge-and-level sensitive, highest priority.
• RST 7.5: vector address 003CH — maskable, rising-edge sensitive (internally latched), second priority.
• RST 6.5: vector address 0034H — maskable, level sensitive, third priority.
• RST 5.5: vector address 002CH — maskable, level sensitive, fourth priority.
• INTR: no fixed vector address of its own (non-vectored) — maskable, level sensitive, lowest priority among the hardware interrupts; the actual service address is supplied externally by the interrupting device during the interrupt-acknowledge cycle.

It is worth noting that the four fixed vector addresses (0024H, 002CH, 0034H, 003CH) are each spaced exactly 8 bytes apart, which is why, as noted above, an unconditional jump instruction (occupying 3 bytes) is typically placed at each vector location to redirect execution to a full-length service routine elsewhere, since 8 bytes is rarely sufficient to hold a complete, non-trivial interrupt handler directly.

Interrupt Response Timing and Latency

The total time elapsed between an interrupt request becoming active and the corresponding service routine actually beginning execution — the interrupt latency — depends on several factors specific to the 8085's interrupt-handling mechanism. First, the processor only samples its interrupt input lines during the last T-state of the currently executing instruction, meaning an interrupt request occurring midway through a long instruction (such as a multi-machine-cycle CALL or SHLD) must wait until that instruction completes before being recognized, so worst-case latency is bounded by the execution time of the longest instruction in the 8085's instruction set. Second, for a vectored interrupt (TRAP, RST 7.5/6.5/5.5), once recognized, the processor automatically performs an internal operation equivalent to a CALL instruction to the fixed vector address, saving the current program counter on the stack and transferring control — this internal vectoring itself consumes additional T-states (comparable to the machine cycles of a CALL instruction) before the first instruction of the service routine begins executing. Third, for the non-vectored INTR input, additional latency is introduced by the interrupt-acknowledge handshake itself, during which the external interrupting device's hardware must respond with the appropriate instruction opcode on the data bus, a process that can take longer than the fixed internal vectoring of a dedicated RST-type interrupt, particularly if the external hardware itself introduces propagation delay in decoding which of several possible interrupt sources is requesting service. This overall latency consideration is important in real-time or timing-critical embedded applications, where the maximum acceptable delay between an external event and the processor's response to it must be verified against the worst-case interrupt latency achievable with the chosen interrupt scheme.