Ideas for a simple, but somewhat extendable computer bus

[allison]

On 11/19/2017 03:43 PM, Eric Smith via cctalk wrote:
> On Sat, Nov 18, 2017 at 10:48 PM, Jim Brain via cctalk <
> cctalk at classiccmp.org> wrote:
>
>> Looking at the schematic for the ECB, I cannot find any description of the
>> signals BAI, BAO, IEI, and IEO.  Can anyone shed some light on the function
>> of these signals?
>>
> Bus Acknowledge In and Out, Interrupt Enable In and Out, used for serial
> arbitration of the bus request and interrupt.  These signals are
> daisy-chained rather than bused.
>
> If a any card is requesting the bus by asserting the bus request, at some
> point the CPU will acknowledge that by asserting its bus acknowledge
> output, which is wired to the BAI signal of the first bus slot. The BAO of
> each slot is wired to the BAI of the next slot.  Since more than one card
> can request the bus, it is necessary for there to be some arbitration
> scheme to determine which card gets the bus grant. In the serial
> arbitration scheme, the highest priority goes to the card that is earliest
> in the daisy chain (closest to the CPU).  If a particular card is NOT
> requesting the bus, it passes the BAI signal on to BAO to make the
> acknowledge available to the next card. If it is requesting the bus, it
> does not pass BAI to BAO, but instead sets BAO inactive, so that no
> lower-priority card will see the bus acknowledge.
>
> Similarly for how the card deals with interrupts, but using the IEI and IEO
> as the daisy chain.
>
> This is a common technique since the 1960s, and for microcomputers was used
> by Intel Multibus in 1975, and by Zilog Z80 family peripherals in 1976.
>
> The drawback is that if there are a lot of cards, there can be a long
> propagation delay of the interrupt acknowledge from the CPU to the last
> card of the bus, particularly if routing the IEI/IEO chain through NMOS Z80
> peripherals. 
That asumes z80 and a default bus master...  What if the CPU  is 6502 or
still other.


> That can cause no device to respond to the interrupt
> acknowledge with a vector by the time the CPU needs it.  This can be solved
> by adding wait states to the interrupt vector read, or by using a parallel
> arbitration scheme instead of serial.
It also assumes and interrupt vector read.  Not al cpus do that or it
can be
very implementation dependent.

Its not a what bus us better its what bus suits the system and matching CPU.

> Parallel arbitration can be done with the same slot pin assignments, but
> instead of busing the request and daisy-chaining the acknowledge, the
> requests are each separately fed into a priority encoder.  The "any" output
> of the encoder goes to the request input of the CPU.  The acknowledge from
> the CPU goes into the enable of a decoder, and the select inputs of the
> decoder come from the priority encoder, so that each slot gets its own
> decoded acknowledge signal to its BAI input.  In this case the backplane
> doesn't connect the BAO output of a slot to anything.   This parallel
> arbitration scheme can be used for bus request and/or interrupt request.
The rest is the specific implementation.  What happens if the CPU is
1802 or something else that does not match the 6500 or 8080z80 models.

Buses and systems are not software abstractions they are hardware
implementation
and often driven by the host CPU as well as over all system needs.  If
this wasn't true
why do so many different buses exist?

Allison

> Eric