Return to BSD News archive
Xref: sserve comp.os.os2.programmer:13310 comp.os.linux:53062 comp.os.mach:3170 comp.os.minix:22556 comp.periphs:4116 comp.unix.bsd:12418 comp.unix.pc-clone.32bit:4064 comp.os.386bsd.development:1062 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!wupost!csus.edu!netcom.com!jivko From: jivko@netcom.com (Jivko Koltchev) Subject: Re: More on the DMA timing problem Message-ID: <jivkoCBs3uJ.9tz@netcom.com> Organization: Netcom Online Communications Services (408-241-9760 login: guest) References: <jmonroyCBKrE9.76n@netcom.com> <jmonroyCBopts.KM8@netcom.com> Date: Sun, 15 Aug 1993 02:20:42 GMT Lines: 52 In article <jmonroyCBopts.KM8@netcom.com> jmonroy@netcom.com (Jesus Monroy Jr) writes: >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 That is correct. You do not need to read any single bite to refresh the entire D-RAM. All you need to do is to sellct a row of bits by strobing only part of the address lines. It might be helpful to open a data-book of any D-RAM mfgr and read the description of the first D-RAM chip you see there. > 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 >___________________________________________________________________________ > -- Regards. Jivko ============================================================================= E-mail: jivko@netcom.com | Tel:(408)980-3625 | Fax:(408)377-0714 =============================================================================