This message is from the T13 list server.

Pat why did you dredge this crap up?

Haven't you got a job or something to do in the daytime?

You've been trolling this nonsensical campaign about bus residue for 
weeks now. Despite numerous patient and well intentioned 
explanations, you refuse to understand or accept certain physical 
realities of the ATA bus and separate them from operating system and 
driver issues. One can only conclude that you've milked it for all 
that it is worth and are looking for some other thing to troll.

Since I'm the one who brought the proposal that Hale wrote about, I 
very obviously disagree with his article. But we've been over and 
over and over it so many times already that I'm going to leave it 
that I disagree with Hale, other host vendors disagree with his 
position, the committee voted and disagreed with Hale's position and 
that's why the change was adopted into ATA-6. That's the last I'm 
going to say about.

Stop feeding the trolls!

At 3:12 PM -0600 4/17/02, Pat LaVarre wrote:
>This message is from the T13 list server.
>
>
>Fom one of the anonymous mass of folk that have been reading the 
>burst on how AtapiPio does or does not support the reporting of bus 
>residue more fully than Dma does ...
>
>... we have a copy of this invitation from Hale Landis, dated May 
>2001, for Atapi folk to pay more attention to correcting the T13 
>standard to represent accurately the realities first described in 
>SFF 8020i, such as a workable DeviceSignature other than floating 
>the bus for a Slave that does not exist.
>
>I think we can all agree Hale has always been very responsive here 
>to the Atapi concerns some of us express.
>
>I trust everyone is happy to have Atapi discussed here.
>
>Enjoy.    Pat LaVarre
>
>
>
>http://www.nikkeibp.asiabiztech.com/nea/200105/peri_129440.html
>
>(May 2001 Issue, Nikkei Electronics Asia)
>
>Interface Connections: ATAPI Device Designers Beware
>
>ANSI NCITS T13, the committee responsible for the ATA and ATA/ATAPI 
>standards, has just completed work on ATA/ATAPI-6, the sixth in the 
>series of ATA and ATA/ATAPI standards. T13 is about to begin work on 
>ATA/ATAPI-7. The early standards, ATA or ATA-1, ATA-2 and ATA-3, 
>were used to describe only ATA hard disk drives. The ATA-1 and ATA-2 
>standards have been withdrawn and are now considered obsolete.
>
>Starting with the fourth standard, ATA/ATAPI-4, ATA became one of 
>the many SCSI physical transport layers. This was achieved by adding 
>the ATAPI command protocol to the existing ATA standards. T13 was 
>given the task of merging the SFF-8020 document with the ATA-3 
>document. SFF-8020, also known as INF-8020, was the first 
>description of the ATAPI interface for CD-ROM drives. A number of 
>items in SFF-8020 that were incorrect or incomplete were corrected 
>by T13 in the process of adding the ATAPI reset and command 
>protocols to the ATA/ATAPI-4 document.
>
>Only the ATAPI protocol information in SFF-8020 was moved into 
>ATA/ATAPI-4. The CD-ROM commands were given to ANSI NCITS T10, the 
>SCSI committee, to merge into the SCSI MMC document.
>
>Device Signature Values
>
>One item of difference between SFF-8020 and ATA/ATAPI-4 was the 
>device signature values presented by device 0 when there was no 
>device 1. The SFF-8020 implementation was different from the 
>traditional ATA implementation. The SFF-8020 required extra hardware 
>in an ATAPI device interface chip.
>
>SFF-8020 specified that when there was no device 1, and when device 
>1 was selected, then device 0 would respond with the value of zero 
>if the host attempted to read any of the device 1 interface 
>registers. This required extra hardware in device 0. ATA devices 
>never had this extra hardware because, when an ATA device 0 is 
>responding for device 1, the host receives the current values in the 
>device 0 register.
>
>When T13 merged SFF-8020 into the ATA/ATAPI-4 document, no-one could 
>explain why this difference existed or what purpose it served. T13 
>did not include this SFF-8020 item in the ATA/ATAPI-4 standard.
>
>The fifth standard, ATA/ATAPI-5, did not change this signature 
>handling, but a number of interesting new things were added, such as 
>more Ultra-DMA modes, known as the Ultra-DMA 66 modes. Also, the old 
>8-bit PIO data transfer method was restored, but only for CF 
>devices. Two other important items could be found in ATA/ATAPI-5: 
>the detailed I/O response tables, and the host and device state 
>diagrams describing all the reset and command protocols.
>
>T13 has just completed the sixth standard, ATA/ATAPI-6, but it must 
>now undergo several review processes before publication as an ANSI 
>standard. One new addition is an Ultra-DMA mode know as Ultra-DMA 
>100. Also, the ATA hard disk logical block address (LBA) has been 
>expanded from 28 bits to 48 bits. The original ATA LBA field of 28 
>bits can address hard disks up to 137 Gbytes, and hard disk drives 
>(HDD) are rapidly approaching that capacity. ATA/ATAPI-6 finally 
>makes the old cylinder head sector (CHS) addressing on ATA hard 
>disks obsolete. CHS addressing was limited to addressing only the 
>first 8 Gbytes of an ATA HDD.
>
>ATAPI device designers should note that the original SFF-8020 device 
>1 signature method has been restored. This means that ATA/ATAPI-6 
>once again requires that extra hardware so that device 0 can present 
>a different signature, a signature with all zero data in the device 
>1 registers, when there is no device 1 present.
>
>It is unfortunate that T13 has added this confusion to the ATA/ATAPI 
>standards. The major reason this sort of thing happens is that few 
>ATAPI device vendors attend the T13 meetings.
>
>Without greater interest in what T13 is doing, and without greater 
>attendance at T13 meetings by the vendors of ATAPI devices, more 
>things like this are possible. Currently the worldwide 
>standardization of ATAPI is in the hands of the hard disk vendors 
>and a few software vendors who are active T13 members.
>
>by Hale Landis
>
>(May 2001 Issue, Nikkei Electronics Asia)


-- 

---------------------
I make stuff go.
---------------------

Larry Barras
Apple Computer Inc.
1 Infinite Loop
MS:  306-2TC
Cupertino, CA  95014
(408) 974-3220

Reply via email to