Return to BSD News archive
Xref: sserve comp.os.os2.programmer:13303 comp.os.linux:52895 comp.os.mach:3163 comp.os.minix:22547 comp.periphs:4103 comp.unix.bsd:12404 comp.unix.pc-clone.32bit:4039 comp.os.386bsd.development:1046 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!news.Hawaii.Edu!ames!olivea!decwrl!decwrl!csus.edu!netcom.com!jmonroy From: jmonroy@netcom.com (Jesus Monroy Jr) Subject: Re: More on the DMA timing problem Message-ID: <jmonroyCBopts.KM8@netcom.com> Followup-To: 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 Organization: NETCOM On-line Communication Services (408 241-9760 guest) X-Newsreader: TIN [version 1.1 PL8] References: <jmonroyCBKrE9.76n@netcom.com> Date: Fri, 13 Aug 1993 06:25:04 GMT Lines: 37 mail adrie@ica.philips.nl Re: Subject: Re: More on the DMA timing problem >>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 >> Organization: Philips Consumer Electronics, Eindhoven, The Netherlands >> Date: Wed, 11 Aug 1993 11:19:31 GMT >> >> In article <jmonroyCBKrE9.76n@netcom.com> jmonroy@netcom.com (Jesus Monroy Jr) writes: >> >>> The scenario is possible under some conditions and eminently plausible, but >> >>> the timings involved on PC hardware at low transfer rates mean that it >> >>> will not happen on these machines unless: >> >>> 1) some DMA device is seizing the bus for extended burst mode transfers >> >>> or >> >>> >> > The RAM refresh is a burst mode operation. >> >> 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 (hence CPU can't do anything). The period for this (refresh )is no longer that the time needed to read 64k of memory by the DMA. Although a scheme could be devise where only the address lines get strobe, and this might be enough. I don't know enough about RAM and the refresh to tell you anything more than I've read. Hence, why I am posting these messages to see if someone else has more information. ___________________________________________________________________________ Jesus Monroy Jr jmonroy@netcom.com /386BSD/device-drivers /fd /qic /clock /documentation ___________________________________________________________________________