You can simply run the interrupts into a Z80 PIO. That gives you bit level masking and interrupt control as well as telling you what interrupts are present with a single IN. See "mode 3" and the interrupt control word - you can mask/unmask each line individually. If you have 8 lines used for that I think you've still got enough to add a bitbang SD card (even in QSPI mode) or a printer port as well ;-)

You can use a Z80 and 8259 together but you have to add a lot of glue or use the 8259 in poll mode (so you get an interrupt and then read the PIC to find out what is going on), as it can't cope with the Z80 interrupt pattern. There's a modern S100 card that does it here:

http://www.s100computers.com/My%20System%20Pages/PIC&RTC %20Board/My%20PIC%20Board.htm

One other thing I was looking at was your banking model. You are going to need to disable interrupts around your ROM/RAM switching so you don't get an IRQ mid switch when there is nothing mapped low.

Alan

You can simply run the interrupts into a Z80 PIO. That gives you bit level masking and interrupt control as well as telling you what interrupts are present with a single IN. See "mode 3" and the interrupt control word - you can mask/unmask each line individually. If you have 8 lines used for that I think you've still got enough to add a bitbang SD card (even in QSPI mode) or a printer port as well ;-)

You can use a Z80 and 8259 together but you have to add a lot of glue or use the 8259 in poll mode (so you get an interrupt and then read the PIC to find out what is going on), as it can't cope with the Z80 interrupt pattern. There's a modern S100 card that does it here:

http://www.s100computers.com/My%20System%20Pages/PIC&RTC %20Board/My%20PIC%20Board.htm

One other thing I was looking at was your banking model. You are going to need to disable interrupts around your ROM/RAM switching so you don't get an IRQ mid switch when there is nothing mapped low.

Alan

Interesting. I want to check my understanding of this approach. The Z80 PIO would be the one and only driver of the /INT signal into the Z80, right? So, no IEI or IEO chain, right? Additionally, the Z80 PIO could invoke a Z80 mode 2 interrupt, right? The PIO interrupt handler would then use the PIO channel bits to determine what is causing the actual interrupt, right?

I think the simplest solution is to just have a hardware IM2 vector generator and there's no need for any software except for the vector table and interrupt handlers. There's also no need for IEI / IEO chains and their associated delays.



The '148 generates the INT* signal and during the response the M1* sugnal latches the highest priority interrupt since it occurs before IORQ*. The actual vector is placed on the data bus during the interrupt acknowledge read.

INT7* is the highest priority and if there is any chance of spurious interrupt signals then the INT0* handler needs to verify it's processing a real interrupt. Just to be safe, even if various INT inputs are not used, their vector should probably point to an EI / RETI sequence.

I think the simplest solution is to just have a hardware IM2 vector generator and there's no need for any software except for the vector table and interrupt handlers. There's also no need for IEI / IEO chains and their associated delays.



The '148 generates the INT* signal and during the response the M1* sugnal latches the highest priority interrupt since it occurs before IORQ*. The actual vector is placed on the data bus during the interrupt acknowledge read.

INT7* is the highest priority and if there is any chance of spurious interrupt signals then the INT0* handler needs to verify it's processing a real interrupt. Just to be safe, even if various INT inputs are not used, their vector should probably point to an EI / RETI sequence.

Of the solutions offered so far, I think this is the most elegant. Very nice. [...]

Thanks, Andrew Lynch

I think the simplest solution is to just have a hardware IM2 vector generator and there's no need for any software except for the vector table and interrupt handlers. There's also no need for IEI / IEO chains and their associated delays.



The '148 generates the INT* signal and during the response the M1* sugnal latches the highest priority interrupt since it occurs before IORQ*. The actual vector is placed on the data bus during the interrupt acknowledge read.

INT7* is the highest priority and if there is any chance of spurious interrupt signals then the INT0* handler needs to verify it's processing a real interrupt. Just to be safe, even if various INT inputs are not used, their vector should probably point to an EI / RETI sequence.

My real question would be why D3 remains low versus the expected high from S2. Some thoughts:
- Possibly a bad '373 chip
- Another circuit driving D3 plus ? during /M1 or /IORQ. Note that all I/O in the system must be qualified by /IORQ AND NOT /M1.

It's also kind of weird to me that S1 is following D1. S1 should be based on the interrupt request inputs to the '148 and I would not expect to see that kind of cyclic change.

I find my oscilloscope can be handy when looking at this kind of thing. If there's signal contention it should be pretty obvious as a midrange value between high and low and possibly as spikes on the supply rail.