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
___________________________________________________________________________