Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!accuvax.nwu.edu!tank!eecae!netnews.upenn.edu!dsl.cis.upenn.edu!david
From: david@dsl.cis.upenn.edu (David P. Feldman)
Newsgroups: comp.sys.ibm.pc
Subject: Re: AT Bus Mastership Control: How does it work?
Keywords: AT, Bus, Master, Handshaking
Message-ID: <16169@netnews.upenn.edu>
Date: 31 Oct 89 07:25:46 GMT
References: <226@cfa.HARVARD.EDU>
Sender: news@netnews.upenn.edu
Reply-To: david@dsl.cis.upenn.edu (David P. Feldman)
Distribution: na
Organization: University of Pennsylvania
Lines: 47

I am basing my statements on documentation provided by IBM including the
TechRef signal descriptions and schematics.  The poster was correct about how
to achieve mastership.  That is, assert DREQ, wait for DACK, and then assert
MASTER.

Now, looking at the TechRef Schematics, master degates the DMA external
address latches (see sheet 13) by forcing AEN1 and AEN2 to disassert.  On sheet
6, the DMA AEN signal is derived from a PAL, and I assume the equation is
simply !AEN1 * !AEN2, in which case DMA AEN is disasserted by MASTER.  If so,
the tranceivers on sheet 5 will send the system address TO the DMA controllers,
so the system address will not be affected by the DMA chips.  Also, on sheet
4, MASTER is seen to disable the drive for the upper 7 address bits (by
setting transceiver direction).  The rest of the address drivers are disabled
by HLDA from the CPU.

Thus, MASTER should give you a clean address bus if asserted after the DMA
controller gains control.  It is essentail for the DMA controller to gain
access first so that a) the CPU can stop cleanly b) all bus signals can be
tristated.  As explained above, MASTER should isolate the addressing of the DMA
controllers.  Since the hardware is not set up for the DMA controllers to
access the system data bus (as in mem to mem cycles), this should be all that
is necessary.

Now, the DMA controller that asserted DACK must continue to hold off the CPU,
because I can't see where MASTER asserts CPU HRQ.  As I said above, the lower
address byte is still sent TO the DMA controller by chip U48 (a 245).  So,
this implies that the DMA controller better not send any addresses while
the master is.  I am not sure how this is managed.

Hope this helps.  Oh, wait a minute, hold on.  Cascade mode!!!  Listen to this!
"Since the cascade channel of the initial 8237 is used only for prioritizing
the additional device, it does not output any address or control signals of
its own.  These could conflict with the outputs of the active channel in the
added device.  The 8237 will respond to DREQ and DACK but all other outputs
except HRQ will be disabled.  The ready input is ignored."  So, program the DMA
channel in cascade mode.  Then your master device will look like a cascaded
DMA controller.  You assert DREQ, the DMA controller sees as cascaded access,
asserts HRQ, eventually gets HLDA from the CPU, and sends out a DACK.  As
long as DREQ is asserted, the CPU will get the HRQ.

Anybody actually done this?  I am just figuring.

_   /|					Dave Feldman
\'o.O'					david@dsl.cis.upenn.edu
=(___)=		Ok, cough!
   U					DSL - land of wonder and enchantment
ACK! PHHT!