Backplane for IEO/IEI look ahead support in pipeline ?

[Marten Feldtmann]

Perhaps a modified version of  SC113 ? Allowing 4 cards to be used together with IEO/IEI and two of them for other cards ? Actually the SC113 seems to be the most universal card so far ... if a power supply card (to fit in) would be available it could be the alone solutions for backplane questions ...

[Steve Cousins]

Hi Marten

I have considered making a backplane with an IEO/IEI look ahead circuit, but haven't got beyond thinking about it.

For anyone who has not looked into IEO/IEI look ahead, here's a quick summary of the issue:

In a system with more than one Z80 peripheral chip using mode 2 interrupts, these chips are connected together with an IEO/IEI daisy chain to control interrupt priority. When an interrupt occurs the Z80 generates an interrupt acknowledge cycle, allowing the interrupting device to put an interrupt vector on the data bus. The Z80 allows a limited time for the device to do this. However, it takes time for the IEO/IEI signal to ripple through the interrupt daisy chain. The more devices, the longer it takes. Zilog specify 4 PIOs as the maximum number that resolve in the allowed time. Curiously they don't seem to specify the limit for other chips - unless I've missed it. To link more than 4 devices you need a look ahead circuit to reduce the time taken for the IEO/IEI signal to be processed by all the devices.

The LiNC80 SBC1 has 3 devices (PIO, SIO, CTC) on the SBC. A look ahead circuit is included so the time window is not pretty much all used up by the SBC itself. This leaves time for lots of external expansion.

The RC2014 is entirely modular so you could just ignore the problem until you have more than 4 devices. At that point I see two solutions.

1/ Get a backplane with the look ahead circuit built into it, as Marten is suggesting. 

2/ Add an interrupt manager module and connect each peripheral chip's IEI and IEO to it with flying leads. Not pretty, but functional. The interrupt manager module would include a look ahead circuit and the order of the flying lead connections determine priority. The mechanism would also avoid the need for IEI and IEO signals on the bus.

Mode 2 interrupts are a mixed blessing. The current official bus spec does not support IEI and IEO, and if it did the position of the boards on the backplane would be critical. Perhaps flying leads are not such a bad solution.

I agree SC113 is the most universal of the modular backplane sections so far, but I personally like SC112. When someone (can't remember who) first suggestion a power supply module I was initially not keen. However, I am warming to the idea and may make one at some point.

Steve

[Marten Feldtmann]

I've found this in my Sharp MZ80B Manual. The marked stuff must be placed on each SC113 for four slots ...

[Marten Feldtmann]

In "The Z80 Family Program Interrupt Structure" it is mentioned:

"

The CPU will automatically insert one more wait state (for a total of two) to allow additional
ripple time for this priority determination. Up to four Z80 peripheral devices can be serviced
without added logic.
When designing systems with more than four I/O devices, the USER can either extend
interrupt acknowledge cycle time or reduce priority ripple time.

"

so it seems to be valid for all Z80 devices ...

[Steve Cousins]

Thanks Marten, I didn't have that document in my collection.

Steve

[Marten Feldtmann]

In further parts of that document, it is more discussed - and I have to read that more carefully to understand all those problems ... and I thought, that with that "simple" schematic from the Sharp technical manual the problem can be solved ... but I also have to admit, that I do not understand the additional timing problems mentioned in that book.

Marten

[Marten Feldtmann]

The picture of that Sharp Manual comes actually from the Z80-PIO Technical Manual

Marten

[ZO...@gladucalled.com]

Hi Steve. I posted a few random comments.

I have considered making a backplane with an IEO/IEI look ahead circuit, but haven't got beyond thinking about it.

I never saw the look-ahead circuit before. Very clever. I would be tempted to AND three IEI/O circuits instead of four, just for an added margin. Debugging interrupts is time consuming.

At that point I see two solutions.

1/ Get a backplane with the look ahead circuit built into it, as Marten is suggesting.

I like this option. One would not have to populate the backplane with the chips if not needed.

2/ Add an interrupt manager module and connect each peripheral chip's IEI and IEO to it with flying leads. Not pretty, but functional.

No, not pretty at all.

The mechanism would also avoid the need for IEI and IEO signals on the bus.

Haven't we already added IEI and IEO pins in the new spec? Do we want to take them off the bus?

Mode 2 interrupts are a mixed blessing.

Mode 2 help put Zilog in front of Intel back in the day. Intel never did get a handle on real-time systems. 

The current official bus spec does not support IEI and IEO, and if it did the position of the boards on the backplane would be critical.

Is there a requirement to be able to shuffle boards around?

Perhaps flying leads are not such a bad solution.

This requires some skill to wire-up which runs against the KISS principle.

Live long and prosper.  Cheers.  =Steve.

[Steve Cousins]

Hi SteveM

I tend to agree, look ahead on the backplane is the most attractive solution.

> Haven't we already added IEI and IEO pins in the new spec? Do we want to take them off the bus?

Spencer has suggested a new bus spec which includes IEI and IEO, but it has not been officially confirmed.

No, I think they should be on the bus.

> Is there a requirement to be able to shuffle boards around?

No, but I can see the need to have any mode 2 boards in a sensible order, and with no gaps in the IEI/IEO chain, causing apparent failures and reliability issues. Just look at the problems some have due to jumpers on memory boards. Any such mode 2 requirements complicates the system, but mode 2 interrupts are inevitably more complex than mode 1 interrupts, at least in the hardware side of things.

You are right about the KISS principle. I guess true plug and play would be nice, but I don't see this as realistic on limited 8-bit hardware which aims to be simple and cheap to design and build.

Steve C