Z80: Interrupt (IM2) daisy chain for "foreign" peripherals

Question

I'm looking for a way (apart from manually wiring up Fig.15 of The Z80 Family Program Interrupt Structure) to daisy chain "non-Z80-family" devices in an IM2 Z80 system i'm designing.

So far i've come across the "one PIO (using a bit mask) / CTC (using a trigger input) / CIO (not sure how, haven't looked too much at that chip yet, but afaik it's just a PIO/CTC combined) port per device" approach, which, frankly, sounds rather wasteful (in pcb real estate, power, money and code overhead, especially since i'm making a modular system with multiple daughter boards, so each one would need one of those chips).

I've also found US4860200A, but couldn't find any indication that ever was an actual Tektronix product.

I've tried (and failed) to wire up the circuit in GAL22V10, and want to avoid full on CPLD/FPGA/microcontroller solutions.

Essentially what i need is an IC with data bus, IEI, IEO, INT on one side and "HELP", "INTACK" on the other, and implements the logic linked to above. Address decoding and outputting the IM2 interrupt vector i can do myself easily with a binary comparator and a tristateable buffer (or more likely the combination of those in a GAL because i have a bunch of them and they save space&power)

Does anyone know any such thing I might've missed in my research?

for the record, i've asked this on reddit too, where you can see a naive and extremely wrong attempt at the GAL implementation, but we didn't come to any results there, the most helpful reply there was showing me how to do interrupts in IM0 with polling the devices to see which has data, which i already knew

Answer 1

My opinion is that I wouldn't rely too much on Z80 daisy-chained interrupts. It was actually invented to "dissolve" the need for the dedicated interrupt controller IC among the ordinary peripheral chips. Besides that only useful feature, everything else is disadvantage:

1. The need for extra logic inside chips, i.e. decoding RETI instruction and maintaining IEI/IEO chain
2. The need for extra pins dedicated to that interrupt stuff, that is, instead of single /INT output, now ICs have IEI, IEO and /M1 pins. This is probably the most stringent objection given the only standard DIP cases were available at the time.

A funny thing that the Z80 CPU itself knows little of that daisy chaining. IM2 mode could be made useful without any Z80 peripherals. Another (though little) its 'knowledge' is RETI instruction that Z80 executes exactly the same way as RET, except for two opcodes instead of one.

If I need to have a vectored prioritized interrupt system on Z80, I'd consider the following ideas:

1. Do not use vectored prioritized system at all
2. Use another IC from 80ies, that is 8259 interrupt controller, along with IM0 mode in Z80
3. When some kind of programmable logic is made voluntarily available, I'd build my own minimal prioritized interrupt controller. It is as simple as having to priority encode interrupt requests to directly form an interrupt vector (for IM2 mode) or RST n opcode (for IM0 mode).

P.S.: Consider using MAX CPLDs (that is, EPM7032, 7064 and 7128, or EPM3032, 3064, 3128). They are available in PLCC cases (so that you can use PLCC sockets for them), quite powerful in comparison with GALs/PALs, 5v tolerant (only applicable to EPM30xx, as EPM70xx are already 5v-only devices) and considerably easier to program as vhld/verilog languages are higher level ones.

Answer 2

This answer is an attempt at a “middle of the road” solution: not as flexible as a fully decoded IM2 system with 128 interrupt vectors, but certainly practical enough not to require programmable logic.

Routing the IEI/O chain through modules in a general purpose system is not the best idea due to timing constraints and the general Z80-specificity - it’s not quite necessary.

So, if you can do with 7 prioritized interrupt vectors then it can be done differently - still using IM2. The trick is to use a one-of-7 priority encoding for interrupt vector number, eg. 0x00 highest priority then 0x02, 0x06, 0x0E, 0x1E, 0x3E, 0x7E, 0xFE lowest priority. Data bus would have pull ups - they can be gated by VECRQ described below, if you want to decrease general bus loading a bit. Prioritized requester uses an open-collector driver to place their interrupt vector (from jumpers etc) on the data bus in response to a vector request. The wire-or of concurrent vectors automatically provides the highest priority vector to the CPU, should multiple interrupts be pending.

This allows the use of Z80-native peripherals without the chain as well: all they would need is two bus access buffers: open-collector gated by VECRQ | CS & !RD, and open-emitter gated by CS & !RD only.

So let’s see what the logic requirements would be: each non-Z80 peripheral needs an additional 8-bit open-collector driver, input set to the encoded interrupt priority, with its OE:=VECRQ & DEVINT, where VECRQ:=M1 & !IOREQ driven by the motherboard.

Interrupt acknowledgment would be quite peripheral-specific. Some peripherals don’t need it - the handling of the device’s state may clear the interrupt active flag, or it can be cleared via a config register. But if you really need one, then physical INTACK can be generated using any GPIO mechanism or even just a plain 8-bit address comparator gated by !IORQ, and can be pulsed by the interrupt handler, or set by the interrupt handler and cleared on next M1 - just one F/F for that.

Using IRET snooping for acknowledgments takes a bit more logic: the motherboard would provide IACK:=M1 & D[7:0]=IRET. The device then would need two things: 1) comparator that compares D[7:0] with its interrupt vector, with the output, say INTEQ, latched by falling VECRQ. This lets the device know that it won the priority contest. 2) Device INTACK := INTEQ & IACK from motherboard, this would synchronously reset the INTEQ latch as well.

Since interrupt handling highly depends on peripheral type, it makes sense to put the device-specific part of it on the side of the device rather than on the motherboard, and only provide VECRQ and IACK as somewhat general-purpose signals from the motherboard.