Return to BSD News archive
Xref: sserve comp.os.os2.programmer:13314 comp.os.linux:53162 comp.os.mach:3175 comp.os.minix:22562 comp.periphs:4127 comp.unix.bsd:12424 comp.unix.pc-clone.32bit:4073 comp.os.386bsd.development:1072 Newsgroups: comp.os.os2.programmer,comp.os.linux,comp.os.mach,comp.os.minix,comp.periphs,comp.unix.bsd,comp.unix.pc-clone.32bit,comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!mcsun!sun4nl!relay.philips.nl!philica!adrie From: adrie@ica.philips.nl (Adrie Koolen) Subject: Re: More on the DMA timing problem Message-ID: <1993Aug16.072355.292@ica.philips.nl> Organization: Philips Consumer Electronics, Eindhoven, The Netherlands References: <jmonroyCBKrE9.76n@netcom.com> <jmonroyCBopts.KM8@netcom.com> Date: Mon, 16 Aug 1993 07:23:55 GMT Lines: 38 In article <jmonroyCBopts.KM8@netcom.com> jmonroy@netcom.com (Jesus Monroy Jr) writes: >>> This makes me dig deep into my memory. As far as I can remember, memory >>> refresh on a 808[68] PC was done one cycle at a time, controlled by one >>> timer (which of course was set to some 16us). The DMA channel may have >>> been programmed to operate in burst mode, but each burst would be only >>> one cycle and so wouldn't take the CPU bus too long. >>> > To be completely correct, I should say there is no "burst" mode > for the DMA, but it does take over the BUS The 8237a DMA controller in the PC's (or their clones in more modern PC's) do have a Demand Transfer mode in which the bus is hold and DMA transfer cycles are executed as long as the requesting controller asserts the DMA Request. You could call this "burst" mode DMA. > (hence CPU can't do anything). The CPU can continue operating if it stays off the bus (e.g. executing from processor cache memory) and isn't hindered by the DMA (e.g. bus snooping to keep cache coherency might stop the CPU from executing from the cache). > The period for this (refresh )is no longer that the > time needed to read 64k of memory by the DMA. When using 8 bits wide DMA in Single Transfer mode, each DMA transfer takes about 3 ms. 64 KB then takes 192 ms, which certainly is longer than the refresh period, although most DRAMs will operate with refresh periods of 192 ms (though not guaranteed!). When using Demand Transfer mode and 16 bits wide DMA, transfer speed maxes out at some 5 MB/s, so 64 KB would take some 13 ms. This is still longer than the refresh period (4 or 8 ms, I believe). I actually don't know what the point is of having the refresh period be shorter than the time to transfer 64 KB? Adrie Koolen (adrie@ica.philips.nl) Philips Consumer Electronics, Eindhoven, the Netherlands