This message is from the T13 list server.
> [EMAIL PROTECTED] 02/14/02 04:37PM >>> > If we are talking PIO data transfers > then the device SHALL NOT set DRQ=0 > until after the last word of the DRQ data block has been transferred. Falsely comforting paper theory yes. I can speak less verbosely here if you will let me say a "grey sequence" is one in which the xor of consecutive samples consistently has 1 bit set. The specified BSY:DRQ sequence of x 00 80 08 80 00 is not a grey sequence. In this sense, the paper specification is unreal. By definition, sequences that aren't grey aren't real except where we can all agree on a common grey clock to setup and hold around. I certainly agree the intent of the Ansi standard is to require the grey sequence x 00 80 88 08 88 80 00 and not to allow the alternative grey sequence x 00 80 00 08 00 80 00 in the BSY:DRQ bits. I agree electronic engineers on the device side can and should design device logic to be clocked by DIOR-/DIOW-, in order to reduce the probability of seeing x 80 00 08 to vanishingly small levels. I'm not very clear on why device folk don't avoid x 80 00 08 more effectively. I hear some talk of people new to the field being less than adequately familiar with commonly accepted Good Practice in asynchronous logic design. But I have with my own eyes seen devices report x 80 00 08, I have with my own eyes seen hosts designed to tolerate this, and I have with my own ears heard other Ata/pi people speak of this issue as something that "everyone understands" to be fuzzy. A related pretty paper theory is that INTRQ rising can be delayed indefinitely past BSY falling. This doesn't work with Windows, not if you report that you support their xDA GetMediaStatus Ata op, because then that host becomes the abomination known as a mix of polling and interrupt-driven protocol. > BSY:DRQ ... x00 ... something that "everyone understands" to be fuzzy. Of course I knew to suspect "everyone understands" from day one, by definition. > I am not about to propose or support changes > to the ATA/ATAPI standards > to cover BROKEN DEVICES (or BROKEN HOSTS). Hmmm. In general, I'd say our standard, and this committee, loses credibility every time people implement something else under the same name. Here specifically, I'm ok letting people compete on merit. Hosts that want to work will tolerate a little fuzz in any not-Gray code. Devices that want to work will approximate x 00 80 08 80 00 as close as practical, taking care to favour x 00 80 88 08 88 80 00 over x 00 80 00 08 00 80 00 when necessary. Hosts and devices designed to assign blame, rather than to talk, would work differently. Devices would inject x00, hosts would reject x00. Here I'm not asking for change. Here I'd say the paper standard describes what really happens well enough. I'd say anybody skilled in the art knows what we mean by the technically silly English here. Anybody else will learn, hopefully getting less well paid until after they do. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
