Return to BSD News archive
Xref: sserve comp.os.os2.programmer:13290 comp.os.linux:52566 comp.os.mach:3155 comp.os.minix:22542 comp.periphs:4085 comp.unix.bsd:12388 comp.unix.pc-clone.32bit:4025 comp.os.386bsd.development:1027 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!agate!doc.ic.ac.uk!uknet!mcsun!sun4nl!relay.philips.nl!philica!adrie From: adrie@ica.philips.nl (Adrie Koolen) Subject: Re: More on the DMA timing problem Message-ID: <1993Aug11.111931.1065@ica.philips.nl> Keywords: DMA FDC timing problem QIC-40/80 Organization: Philips Consumer Electronics, Eindhoven, The Netherlands References: <jmonroyCBKrE9.76n@netcom.com> Date: Wed, 11 Aug 1993 11:19:31 GMT Lines: 17 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. Adrie Koolen (adrie@ica.philips.nl) Philips Consumer Electronics, Eindhoven, the Netherlands