This message is from the T13 list server.
Don, Any BIOS back then (e.g. 1990) would not recognize any drive over 512 MB at all for one thing. Over the years we've had to address a LOT of issues with BIOS implementations (actually the intersection of the PC interface to the BIOS code and the BIOS code interface to the HDD). Jim -----Original Message----- From: don clay [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 21, 2002 7:41 AM To: ata reflector Subject: Re: RE: [t13] Re: ^ 18 R/W Long commands This message is from the T13 list server. The seek command also was issued by older BIOSes and if it receives an aborted command the system won't boot. That would prevent people with older systems from being able to replace their hard drive. You'll need to enumerate the "lot more problems" that they would encounter if they put a newer drive into an older system. I agree that Master/Slave detection won't work. The foresightedness of the ATA committee made sure that wouldn't work prior to 1990. 3/20/02 6:55:50 PM, "McGrath, Jim" <[EMAIL PROTECTED]> wrote: >This message is from the T13 list server. > > > >Don, > >Ah, the SEEK command. SEEK was NEVER used in ATA for READ/WRITE - from day >1 (i.e. ATA-1) we had the READ/WRITE commands. SEEK is actually a holdover >from pre ATA days - namely the old WD1003 controller using drives attached >via the ST406/512 interface. That operated by having the controller >instruct the drive to SEEK to a cylinder, and then just turning on/of the >read/write electronics (which were on the controller, not in the drive) at >the right point in time. > >Seagate was the biggest producer of these drives. The largest MFM/RLL drive >they ever produced was the ST1106R, a 128 MB drive. After that the desktop >transitioned to embedded controllers. I don't know of many people even >using that drive today, and if they wanted to upgrade to a new ATA drive >they would encounter a lot more problems than the potential lack of a SEEK >command. > >BTW there was lots of capabilities that were initially carried over from >ST506/412 that we lost over the years. I have not heard anyone argue to >bring back the RECALIBRATE command for instance. > >Later people started using SEEK as a poor man's attempt to overlap commands >(since SEEK actually completes immediately, allowing the ATA bus to be freed >for use by a second drive while the first is still seeking). But this was >recognized by everyone as being inadequate, and so the overlapped command >capability was introduced - first in ATAPI, then merged into ATA in ATA-4. >After more than 5 years of using overlapped command and command queuing, its >time to obsolete SEEK (in my opinion) in favor of the 5 year "new" overlap >command capability that was designed to obsolete it. > >Jim > > >-----Original Message----- >From: don clay [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, March 20, 2002 2:28 PM >To: ata reflector >Subject: Re: [t13] Re: ^ 18 R/W Long commands > > >This message is from the T13 list server. > > >In a previous email on this thread, i described how it is possible to make >R/W >long capable of completely testing ECC. The ways to provide access for >testing >are only limited by one's imagination and that includes on the interface. >Cheap >to do as well. > >Anybody who's going to buy a godzillion drives from a company has a few >rights >to verify that what they're buying works without a "mistrust" guilt trip >being laid >on them. > >Of course, most OEM's would rather have the drive manufacturer's test the >drives for them, but often times they provide the software which, in some >cases, >uses R/W Long. > >But the big picture point is that these commands should not be obsoleted >without a public forum on this reflector prior to their elimination. >Furthermore, >unless there is a valid reason (and I haven't heard one yet on this >reflector) to >eliminate them, they should never be eliminated, obsoleted, or otherwise >disposed or dropped. > >That brings to mind the seek command. It seems to me that if the seek >command is eliminated, that people with old machines without Windows will >not >be able to replace their hard drive. There is a reason not to obsolete the >seek >command. > >3/20/02 2:48:22 PM, "Hale Landis" <[EMAIL PROTECTED]> wrote: > >>This message is from the T13 list server. >> >> >>On Wed, 20 Mar 2002 09:56:59 -0800, Thomas Colligan wrote: >>>This message is from the T13 list server. >>>So why the two positions? >> >>With respect to R/W Long there are two positions: a) the old R/W Long >>commands are inadequate to test a modern drive's ECC -and- b) due to >>a lot of "mistrust" many disk drive customers feel a need to perform >>this testing. OK, if a disk drive manufacturer wants this business >>then that manufacturer will implement a set of vendor specific >>commands to test the ECC of their drive (or even specific model of >>drive). Those vendor specific commands might even "look like" the old >>R/W Long commands. But in general we have progressed past the days >>when commands like those intended to test MFM disk controllers are >>adequate. And testing the ECC on modern drive model A may be very >>different than testing the ECC on modern drive model B. >> >>>Everyone, happy except for drive suppliers because they would have to do >as >>>their customers ask. What a novel Idea? >> >>But when customer ask for things that make no sense what should T13 >>do? The answer is T13 will wait for someone to bring in a proposal >>that makes sense. I don't recall a single proposal in the last 4 >>years to define a new and better way to do ECC testing from a host. >> >>>As Harlan stated it is getting harder and harder to test today's ATA hard >>>drives for a number of reasons. I expect HDD supplier factories are under >>>the same constraints. How do you completely test a 120GB in the time >>>required by upper management, and state that the drive is good. We should >>>be adding new test technologies that allow for a quicker analysis of drive >>>issues. As the capacity of today's HDD increase the more difficult it will >>>be for all of us. >> >>What do you want to test? Many drives have all their hardware logic >>and firmware inside a single chip. There isn't much that can be >>tested externally with any real confidence. Only the drive can test >>itself internally and report the result (isn't that what SMART is all >>about?). But I hope everyone knows that a modern disk drive runs a >>multitasking "OS" with anything from four to eight tasks, each >>responsible for some part of the disk drive's operation. How are you >>going to test that? But I'll ask again... What parts of a disk drive >>do you want to test (and why)? Lets see the proposal(s). >> >> >> >>*** Hale Landis *** www.ata-atapi.com *** >> >> >> >> > > >
