Return to BSD News archive
Xref: sserve comp.os.386bsd.development:1721 comp.sys.ibm.pc.hardware.chips:1930 comp.periphs:4947 Path: sserve!newshost.anu.edu.au!munnari.oz.au!bunyip.cc.uq.oz.au!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!pipex!sunic!ugle.unit.no!ugle.unit.no!jarle From: jarle@drue.idt.unit.no (Jarle Greipsland) Newsgroups: comp.os.386bsd.development,comp.sys.ibm.pc.hardware.chips,comp.periphs Subject: Re: The DMA problem again! Date: 25 Jan 94 00:51:38 Organization: Free Hardware Foundation, UnLtd. Lines: 101 Message-ID: <JARLE.94Jan25005138@drue.idt.unit.no> References: <jmonroyCJxHBH.2x0@netcom.com> <1994Jan22.120513.8484@cc.usu.edu> <jmonroyCK4tFo.3Jx@netcom.com> NNTP-Posting-Host: drue.idt.unit.no In-reply-to: jmonroy@netcom.com's message of Mon, 24 Jan 1994 11:33:24 GMT Oh boy, doesn't anyone else find this thread tiresome? Now it gets worse! Well, since you seem to insist, let's read some schematics then, shall we?. Just to make sure we are reading the same book, will everybody check that they're holding a copy of the IBM Technical Reference Personal Computer AT, not an XT tech ref. (My copy is dated March 1984, first edition) Starting on page 21, a nice page if I may say so, we see that there is a signal on the right called -refresh. This signal goes to the expansion connectors, pin B19, on page 20. Good, that means it's the signal we're looking for. It also goes to the DRAM addressing circuitry on page 8, the DMA page address register on page 15 and some sequencing stuff on page 12. Looks good. How is it generated then? (Back to page 21 for those of you paying attention.) Right, it's active (low) when 3 other signals are true. These are the HLDA (hold acknowledge, directly from the CPU via a '244 buffer), the HRQ (hold request, through a gate to avoid holds during interrupt acknowledge cycles, and directly to the CPU) and a third signal, let's call it "S". It's coming from a D-type flip-flop in about the center of the page. It's also connected in some way to the 2 FFs in the upper left corner. These 2 FFs again seem to be clocked by a signal called OUT1. (from page 16, funny - printed upside-down, bad quality control IBM!). Now, my my, what a surprise, one of the outputs of the 8254 (timer chip) is called OUT1! I can't say for sure (without reading the BIOS source of course:-), but my guess is that this output is used for some purpose..... What happens when OUT1 goes high? (Hm, back to page 21) The first FF obviously goes to 1 (ignoring that a delayed version of -refresh will reset the FF in a bit). Now the second FF synchronizes the signal to the DMA clk frequency (SYSCLK / 2, from page 3). Let's follow the true (not negated) version of the signal, called REF_REQ. This signal is again synched to SYSCLK by another FF, and comes out as our signal "S". Okay, we will study this little piece of circuitry a bit more in detail. The signals coming into it are (ignoring the nice "homemade" S/R FF INTA stuff): OUT1 - from the timer -DMACLK - SYSCLK / 2 + \phi (don't remember the phase relationships precisely) LHRQ1 - latched version of the HRQ1 signal coming from the DMA controllers HLDA - buffered CPU HLDA SYSCLK - system clock (what else should it be?) Signals out are: CPU HRQ - hold request to CPU -Refresh - the much abated refresh signal HLDA1 - hold acknowledge back to the DMA controllers How does it work then? Example 1: No DMA activity, i.e. LHRQ1 and HLDA are low OUT1 -> 1 (timer times out) REF_REQ -> 1 with rising -dmaclk, CPU_HRQ -> 1 combinatorically "S" -> 1 with rising sysclk [ cpu responds with HLDA -> 1 ] all inputs on the NAND gate (U98) is now high and the output, -refresh, will go low. Refresh time. -refresh will then stay low for 4-5 sysclk cycles (if nothing pulls the IOCHRDY- line). (Why is an exercise for the readers.) Then the upper two FFs are cleared, and "S" will be cleared. Example 2: There is DMA activity, i.e. LHRQ1, CPU_HRQ and HOLDA are all high. OUT1 -> 1 (timer times out) REF_REQ -> 1 with rising -dmaclk (CPU_HRQ is already high) ** but ** "S" doesn't get set because the second FF in U90 contains a '1' from LHRQ1 and keeps the first FF in U90 from being set while LHRQ1 is set. The refresh is blocked until the DMA controllers release LHRQ1. Then we get: LHRQ1 -> 0, CPU_HRQ and HLDA *stay* high. "S" -> 1 with rising sysclk all inputs on the NAND gate (U98) is now high and the output, -refresh, will go low. Refresh time. Continue as above. Example 3: Let's introduce some DMA activity in the middle of the refresh cycle. OUT1 -> 1 (timer times out) REF_REQ -> 1 with rising -dmaclk, CPU_HRQ -> 1 combinatorically "S" -> 1 with rising sysclk [ cpu responds with HLDA -> 1 ] all inputs on the NAND gate (U98) is now high and the output, -refresh, will go low. Refresh time. LHRQ1 -> 1 (DMA wants access) Now, in order for HLDA1 (to the DMA controllers) to go high the output of the second FF in U90 must be '1', but this output is kept '0' by the first FF for the duration of the refresh cycle. When the refresh cycle is finished the first FF will contain a '0' and the second FF is free to track LHRQ1 again. What does all this mean then? For one, the DMA channels are not used for refreshing! (Do you read me Mr. Monroy?) The refresh cycles are controlled by the system timer. Second the refresh cycles can *not* preempt an ongoing DMA cycle. It can, however, delay a DMA request for at most 5 sysclk cycles (which @ 8Mhz should be approximately 625 ns), which in itself is not enough to disrupt FDC DMA transfers. End of IBM AT discussion. So, back to your drivers & theories Mr Monroy.... -jarle ---- "Memory is like an orgasm. It's a lot better if you don't have to fake it." -- Seymour Cray commenting on virtual memory