Return to BSD News archive
Xref: sserve comp.os.386bsd.development:1731 comp.sys.ibm.pc.hardware.chips:1997 comp.periphs:4960 Newsgroups: comp.os.386bsd.development,comp.sys.ibm.pc.hardware.chips,comp.periphs Path: sserve!newshost.anu.edu.au!munnari.oz.au!bunyip.cc.uq.oz.au!harbinger.cc.monash.edu.au!yeshua.marcam.com!news.kei.com!sol.ctr.columbia.edu!howland.reston.ans.net!agate!apple.com!amd!netcomsv!netcomsv!netcom.com!jmonroy From: jmonroy@netcom.com (Jesus Monroy Jr) Subject: Re: The DMA problem again! Message-ID: <jmonroyCK6n4t.2wG@netcom.com> Followup-To: comp.os.386bsd.development,comp.sys.ibm.pc.hardware.chips,comp.periphs Organization: NETCOM On-line Communication Services (408 241-9760 guest) X-Newsreader: TIN [version 1.2 PL1] References: <jmonroyCJxHBH.2x0@netcom.com> <1994Jan22.120513.8484@cc.usu.edu> <jmonroyCK4tFo.3Jx@netcom.com> <1994Jan24.103126.8590@cc.usu.edu> Date: Tue, 25 Jan 1994 11:12:29 GMT Lines: 52 ivie@cc.usu.edu wrote: : In article <jmonroyCK4tFo.3Jx@netcom.com>, jmonroy@netcom.com (Jesus Monroy Jr) writes: : > ivie@cc.usu.edu wrote: : > : In other words, DMA channel 0 is not involved in refresh. : > : : > From the facts you have previously stated, : > no logic can be derived to state DMA channel 0 is : > not involved in the refresh. : Sorry. Point being that if DMA controller channel 0 were used for refresh, : either the DMA request or the grant would go somewhere involved with refresh; : since it only goes to the connectors and the DMA page registers, it can't : be used to do refresh. : Well, my guess is we are looking at two different charts. (Is this possible?) My charts say that DMA channel 0 goes to sheet 15. You did not mention this. : > This makes two of us... I don't think I've ever : > stated that the FDC can hang the "refresh". : > I am saying the inverse (or is it the converse, anyhow). : > I beleive the DMA RAM refresh signal is interfering : > with the FDC transfer. : Again, sorry. Lost track of what the argument was. : No problem... at least you are recount the tale with some (if not all) correctness. : From sheet 21 of the schematics, it looks like you're right, Jesus. A : DMA request is captured and synchronized to the DMA clock by the flops on : top of the sheet. However, the request then goes to the two flops in the : middle of the sheet; these flops decide who to give the grant to. When : the refresh request is made, the top flop becomes set. This does two : things: it grants the DMA request to the refresh controller and it clears : the grant to the DMA controller. : There's nothing in there to stop the grant from being ripped away from the : DMA controller if a refresh request comes along in the middle of a : DMA transaction. : Yes, this is my information also. But there is a point in the DMA controller logic (now I'm speaking chip internals) that allows the higher priority channels to take over the controller. This is stated in earlier notes... -- Jesus Monroy Jr jmonroy@netcom.com Zebra Research /386BSD/device-drivers /fd /qic /clock /documentation ___________________________________________________________________________