This message is from the T13 list server.
Hale a detailed list of your concerns about PATA would be appreciated since I'm editing it now. Since PATA will stand alone in ATA-8 (as the documents are 3 seperate standards) this is your chance to have me correct what you view as wrong. ::>-----Original Message----- ::>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On ::>Behalf Of Hale Landis ::>Sent: Friday, June 24, 2005 10:42 AM ::>To: [email protected] ::>Subject: Re: [t13] PATA Corrections, Clarifications, or Errors ::> ::>This message is from the T13 list server. ::> ::> ::>David F. wrote: ::>> My main concern is the issue of protocol related items ::>being spread out in ::>> various places instead of in the protocol section and it ::>being missed by ::>> device makers/firmware developers. One example is how a ::>device is to set ::>> the various bits in the various registers such as BSY / ::>DRQ in relation to ::>> data packets (the protocol is documented with the ::>registers instead of the ::>> protocol section). ::> ::>Looking at ATA/ATAPI-6 (the last valid description of PATA) and ::>ATA/ATAPI-7 (not a valid description of PATA or SATA), I ::>don't see the ::>problem David F. talks about. Yes, there are problems in the ::>text that ::>goes with the state diagrams but I think it is very clear ::>when and how ::>the various registers, especially the BSY and DRQ bits are ::>used. Yes, ::>some information about the BSY and DRQ bits duplicated (I ::>would call it ::>"summarized") in the description of the Status register. But ::>I see no ::>real problem here. ::> ::>The problems I do see are: ::> ::>a) If you carefully read the text that goes with the state ::>diagrams you ::>will find things that are not correct, such as "when BSY=1 ::>and DRQ=0, ::>..." which is wrong because when BSY=1, DRQ has no meaning. ::> ::>b) I only use ATA/ATAPI-6 for PATA and I strongly recommend ::>to anyone ::>that asks about PATA to use ATA/ATAPI-6. Why? First it is ::>only PATA and ::>it is all in one document. Second, things were changed in ::>ATA/ATAPI-7, ::>apparently because SATA was merged in, and some of these ::>changes apply ::>only to SATA but that is not clear in the document - it is easy for ::>someone to think one of the changed things applies to both ::>PATA and SATA ::>when if it applied to PATA it would not be correct. [I'll ::>repeat myself: ::>ATA/ATAPI-7 should have never been published, ATA8 (whatever ::>that is) ::>should not contain any PATA information. SATA is ATA in ::>marketing hype ::>only. PATA and SATA might share some of the same command ::>codes, just as ::>SCSI-1 shares command codes with iSCSI, but SATA is not ATA.] ::> ::>c) While some SATA host controller vendors attempted to ::>emulate the PATA ::>host controller programming interface, I have not seen a single ::>controller yet that does it correctly. I think this is what ::>got David ::>F.'s attention originally. This is odd because over the ::>years lots of ::>people have built devices/bridges/controllers that do emulate PATA ::>correctly based on the ATA/ATAPI-4, -5 and -6. What happened ::>with SATA? ::>Resolve this problem by admitting that SATA is not ATA. Leave PATA ::>alone. Let SATA move forward on its own. Stop corrupting the ::>description ::>of PATA with things from SATA. ::> ::>Hale ::> ::>-- ::> ::>++ Hale Landis ++ www.ata-atapi.com ++ ::> ::>
