*BSD News Article 19538


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