This message is from the T13 list server.
Larry B: Personally I prefer to keep metadiscussion - talk of what mail is or is not appropriate on a particular reflector - offline, in person to person email. In my experience, metadiscussion grows without bound when posted. I'd like everyone to prove me wrong this time by not replying to this post online, by replying to my post here only person-to-person. > Haven't you got a job or something to do in the daytime? (-: Last I checked, I couldn't go work for Apple without moving away from water I can drink and air I can breathe. :-) I think you're not giving me adequate credit for ignorance. My involvement in Atapi devices was intense in 1996-1998, Atapi hosts was 1998-1999. 2000, 2001, 2002 have seen me only on the periphery of Atapi. I do not know the history re Ansi, Sff, & DeviceSignature. Now that you speak up, I do have a vague impression of having seen you post some eminently sensible remarks - maybe in a document of http://www.t13.org/ ? > Pat why did you dredge this crap up? I didn't. It was forwarded to me, after someone here made the erroneous claim that SFF 8020i is dead. > You've been trolling this nonsensical campaign I'm not intentionally being nonsensical. I'm trying to describe a fix I shipped first in November 2001, in the hopes of getting that fix in place even in situations where I do not control the design of both host & device. I haven't finished talking about residue because I remain caught in the programmer's illusion of having fixed the last bug. At this moment, I think the "on residue - to what can we all agree" thread is making a lot of progress. I feel understood by Jim McGrath & co. already. And we now have written agreement between Jim & Hale. This gives me hopes of being understood myself by Hale & co. real soon now. I carefully interleaved the text to try and make the issue clear. > You've been trolling ... I don't think I know what "troll" means, sorry. I think I've heard it is Internet slang? Here now in Winter/Spring 2002, Hale & Jim have taught me to significantly change how I express myself on this issue. Just try comparing the new: http://members.aol.com/plscsi/cdbcomplete.html to the old: http://members.aol.com/plscsi/ftf.html By the way, if you know of anyone else who has vanity-published or otherwise published anything on residue, I'd love to hear of it & link to it. No offence intended, Pat LaVarre >>> Larry Barras 04/17/02 03:42PM >>> 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) ...
