sward@cfa.HARVARD.EDU (Steve Ward) (10/31/89)
How does the AT Bus (8/16-bit memory and I/O expansion slots) work with respect to multiple bus masters? In particular, please describe the bus signal protocol in detail. I have found only a couple of sentences on this topic even though I have examined about 12 published MSDOS, PC and AT technical references of various sorts - all claiming to contain technical hardware information. It appears I need some net help on this one. Here is what I have found: The AT Bus supports multiple bus masters through use of normal DMA handshaking (DRQ, -DACK handshaking) and the -Master signal line. This isn't too specific. Here is my own best guess as to what this means: A potential bus master requests the AT bus by asserting DRQx and thus requesting the bus through normal DMA handshaking means. When the bus is available and granted to the requester, the -DACKx signal is asserted and detected by the bus requester, which in turn asserts the -Master signal line then deasserts DRQx. As long as the -Master signal line is asserted the requester maintains bus mastership even though the DMA cycle has quickly come and gone. In my scenario the DMA is used strictly to arbitrate bus access while the -Master signal is used to maintain bus control. For this to work the DMA arbitration logic would not grant DMA bus access (assert any -DACKx) until the -Master signal line was deasserted. Am I close? What is the accurate truth? I am also assuming that address lines and other control and bus signal lines (other than data) will be tri-stated by the motherboard upon the assertion of the -Master signal line, since the bus master would take control of all bus signal lines. Any and all help is appreciated. I'll summarize to the net. Thanks in advance. Steven Ward ward@cfa.harvard.edu .
david@dsl.cis.upenn.edu (David P. Feldman) (10/31/89)
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!
phil@diablo.amd.com (Phil Ngai) (11/10/89)
I heard a rumor of something really interesting with regard to bus
mastering. If your device needs to access "planar memory", you DON'T
get a ready! Have fun!!!
--
Phil Ngai, phil@diablo.amd.com {uunet,decwrl,ucbvax}!amdcad!phil
Come witness the failure of democracy in California!