Return to BSD News archive
Xref: sserve comp.os.os2.programmer:13313 comp.os.linux:53138 comp.os.mach:3174 comp.os.minix:22561 comp.periphs:4123 comp.unix.bsd:12421 comp.unix.pc-clone.32bit:4071 comp.os.386bsd.development:1071 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!bruce.cs.monash.edu.au!monu6!nella30.cc.monash.edu.au!junaid From: junaid@nella30.cc.monash.edu.au (Mr A. Walker) Subject: Re: More annoyance on the DMA problem Message-ID: <junaid.745467838@nella30.cc.monash.edu.au> Sender: news@monu6.cc.monash.edu.au (Usenet system) Organization: Monash University, Melb., Australia. References: <jmonroyCBoq14.Kz0@netcom.com> <jmonroyCBp5Ks.CM3@netcom.com> Date: Mon, 16 Aug 1993 02:23:58 GMT Lines: 64 jmonroy@netcom.com (Jesus Monroy Jr) writes: > >>> From: rooij@bashful.isp.cft.philips.nl (Guido van Rooij) >>> Subject: Re: More annoyance on the DMA problem >>> Organization: Philips Communications & Processing Services, Eindhoven >>> Date: Fri, 13 Aug 1993 09:39:00 GMT >>> >>> jmonroy@netcom.com (Jesus Monroy Jr) writes: >>> >>> > >>> > The new FDC driver is reading a 1.44 meg diskette in >>> > about 1 minute 30 seconds. There are 2880 sectors on >>> > a diskette of this size. 2880 divided by 90 seconds >>> > is 302 sectors per second. 66,287 divided by 302 >>> is it? 2880/90=32 >>> > Correct. The ultimate in miscalculations on my part. > I have errored. I am human. > > At times I must communicate with non-humans, > this may not include yourself. As I have no evidence of this. > > Again, I have errored. > > OK...32 sectors per second. > > 66,287 / 32 = 2071 refreshes per sector transfer. > > 1 / 32 = 0.03125 second per sector transfer > > Gee! Thanks for the correction. > > This makes the new index 5. The numbers match exactly. > > MY POINT IS THE LOWER HARMONIC OF THE DMA REFRESH > COLLIDES WITH THE FDC TRANSFER. > > >___________________________________________________________________________ >Jesus Monroy Jr jmonroy@netcom.com >/386BSD/device-drivers /fd /qic /clock /documentation >___________________________________________________________________________ I always thought that 3.5 drives rotate at 250rpm= 5 rev/s. There are 18 sectors/track. ie 90 sectors/sec . therefore the transfer rate is 512*90 = 50KBytes/s (aprox.). Negligable as far as DMA latency goes. I see no conflict in the refresh DMA(ch0, highest priority) leading to 'byte' robbing of the FDC DMA, even with no buffering on the FDC. Ie 2 Competing DMA channels * 1uS/transfer << 1/50KBytes/s. How else can a IBM PC(4.77MHz) work with a FDC? As stated, DMA on post-IBM AT class machines doesnt exist, the memory controller subsystem does it transperantly. Get a refresh tweaking program or disable the refresh channel on the 8254 and your computer wont crash. Test the CPU landmark speed, you'll see no difference (try it, i havent, should be interesting). Lets face it, the architecture works (except for some CT chipsets that have buggy 16 bit DMA, which doesnt concern the FDC). In general, hardware is the natural scape-goat to blame for software bugs. Even if there was a problem, i wouldnt change the DMA setup given all the near-8237 chipset clones floating out there, just to much incompatibility to risk anything that isnt cosher IBM BIOS.