Return to BSD News archive
Xref: sserve comp.os.os2.programmer:13321 comp.os.linux:53360 comp.os.mach:3186 comp.os.minix:22572 comp.periphs:4155 comp.unix.bsd:12442 comp.unix.pc-clone.32bit:4096 comp.os.386bsd.development:1102
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!howland.reston.ans.net!wupost!csus.edu!netcom.com!jmonroy
From: jmonroy@netcom.com (Jesus Monroy Jr)
Subject: Re: More annoyance on the DMA problem
Message-ID: <jmonroyCBy43E.FLG@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: <jmonroyCBoq14.Kz0@netcom.com>
Date: Wed, 18 Aug 1993 08:11:38 GMT
Lines: 77
As people have obviously found out I am human
I will admit to the error. The Floppy drive works
at 300 rpm, not 300rps. An obvious "blow-it" on my
part.
>> From: junaid@nella30.cc.monash.edu.au (Mr A. Walker)
>> Subject: Re: More annoyance on the DMA problem
>>
>> 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?
>>
All BIOSes for the PC report errors to the FDC, and even as
I have not found the code to verify that the BIOS retries,
MS-DOS does. Most OSes retry on any error. If you program
at the IBM BIOS level, most (if not all) references say to
try at least 3 times before giving up on a transfer.
What does this say?
That some type of problem exist, what it is - is not certain.
Maybe a slightly bad disk, who knows.
>> 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).
>>
Sorry, this does not "jive" with my information.
The timer is hard wired. That is, in-hardware is where
the refreshes are done, via the 8254 and the DMA controller.
Also, I reference a book with the page number.
TRUE, some motherboards may have a transparent solution,
but this does not follow my documentation for IBM PC AT.
>> Lets face it, the architecture works (except for some CT
>> chipsets that have buggy 16 bit DMA, which doesnt concern the FDC).
>>
INTEL admitted to no DMA problems today when I spoken
to them. However, I am calling again and will ask
them if they know anything more.
>> In general, hardware is the natural scape-goat to blame for
>> software bugs.
>>
If it is a software bug then I have yet to find an obvious
placement.
==========================================================================
>> From: bill@bilver.uucp (Bill Vermillion)
>>
>> In article <junaid.745467838@nella30.cc.monash.edu.au> junaid@nella30.cc.monash.edu.au (Mr A. Walker) writes:
>>
>> :: [deleted stuff] ::
>>
>> No need to try to work backward. These are standard hardware specs.
>>
Ok thanks for the correction and Infom on the 8" SD.
___________________________________________________________________________
Jesus Monroy Jr jmonroy@netcom.com
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________