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