This message is from the T13 list server.
[ BC [EMAIL PROTECTED] ]
> Harlan Andrews
> ... more: proposal to 'fix' ATAPI DMA
> Date: Tuesday - April 16, 2002 12:51 PM
...
> "in the real world", ...
> IgnoreWideResidue ... message is
> usually implemented by the SCSI hosts
> to handle variable record size devices).
Thanks, I didn't know that.
> If you can add COMPLETLY transparent
> messaging to ATAPI then make a proposal.
Yes, can do, have done, copied again here below.
> SCSI creates the IgnoreWideResidue message
> to handle this situation.
Yes.
> ATAPI chose not to implement
> the SCSI Messaging system.
In the now famous words of Jim M on residue ...
"Yes and no."
Yes, as far as I know, AtapiDma has no analogue to the Scsi messaging system.
AtapiPio, however, does have an IgnoreWideResidue message. This message masquerades
as a nonnegotiable T13 _requirement_ of the device: "if the last transfer of a command
has a pad byte, the byte count shall be odd."
That is, this message appears encoded as the lsb of the last x1F5:1F4 ByteCount. Set
that bit to send the message, clear that bit to not send the message.
T13 _requires_ all AtapiPio devices to send this message.
The Microsoft Win98 & WinMe Atapi hosts hear & understand this message. When this
message is sent, they double-buffer as required in order to transfer an odd count of
bytes from the bus into memory.
> This is patently ridiculous.
> It is NOT POSSIBLE for the device
> to transfer exactly 5 data bytes
> across the 16-bit data bus.
Microsoft supports the impossible?
I think perhaps we don't mean the same thing by the English word "transfer". I agree
3 "word"s "clock across the bus". And graciously I agree 3 * 2 = 6. But I see just 5
bytes "copied In to memory".
> If you can add COMPLETY transparent
> messaging to ATAPI then make a proposal.
Have done, now copied here.
The T13 scheme for IgnoreWideResidue did break Microsoft Win95B: that system hung any
time a device did send this message.
I mean to be proposing a less intrusive system for AtapiDma.
To fix this for AtapiDma, I want to take some bits that are now n/a - indeed now are
often not fetched - and give them meaning. I want to flip a heretofore reserved xA1
IdentifyPacketDevice bit to tell us when these bits are not n/a.
The bits I have in mind are the ByteCount at StatusIn time i.e. at BSY DRQ C/D I/O = 0
0 c i time.
I want to put zero there ordinarily, else the count of pad bytes clocked across the
bus i.e. a count as high as X * 2 + 1, where X rises with burst rate, and is 2 for
UDma 33.
Recent posts from Jim M ("[t13] on residue - Jim M when D < H") seem to understand why
my reality includes a need to report residues as high as X * 2, so I have hopes of
making the need for X * 2 + 1 intelligible real soon now.
> please don't require any changes
> from the device suppliers or from the hosts
No change required. A host that wants to copy pad bytes remains free to do so. A
device that wants to neglect to report residue remains free to do so.
> any change would have to be completely
> backwards compatible so as to be transparent.
Whaddyathink? Have we met this gold standard?
Pat LaVarre
On 4/15/02, Pat LaVarre <[EMAIL PROTECTED]> wrote:
>Sorry, when it's Microsoft vs. Ansi, Microsoft wins.
>
>Here, however, we have Ansi's own words requiring a device to tell the
>host to
>copy only 5 bytes and not 6:
>
> Revision 18
> 19 August 1998
> ...
> Ata/Atapi 4 ...
> 8.21 PACKET ... A0h ...
> 8.21.5 Normal outputs ...
> 8.21.5.2 Data transmission ...
> ...
> 5) if the byte count is odd, the last valid byte transferred is
> on DD[7:0] and the data on DD[15:8] is a pad byte of
> undefined vaue;
> 6) if the last transfer of a command has a pad byte, the byte
> count shall be odd.
> ...
> I/O - Shall be cleared to zero if the transfer is to the device.
> Shall be set to one if the transfer is to the host.
>
>Surely the assymetry between this T13 text and the analogous T13 text for
>AtapiDma is plain?
>
>How does it serve anyone's interest here in T13 to have the choice between
>Pio & Dma change the count of bytes copied?
>
Pat,
This is patently ridiculous. It is NOT POSSIBLE for the device to
transfer exactly 5 data bytes across the 16-bit data bus. The device
doesn't know or care what the operating system does with the pad byte.
You are confusing the device layer with the Operating System layer. The
DATA that the device sends across the ATA bus is IDENTICAL between PIO
mode and DMA mode.
SCSI creates the IgnoreWideResidue message to handle this situation.
ATAPI chose not to implement the SCSI Messaging system. However, "in the
real world", very few SCSI devices actually implemented the
IgnoreWideResidue message since SCSI also specifies that data Block
lengths shall be a multiple of 4. The hosts typically don't need the
wide residue message for fixed block size devices. (Although that
message is usually implemented by the SCSI hosts to handle variable
record size devices).
I would only care, however, it some attempt to add a messaging system to
ATAPI broke the existing devices. If you can add COMPLETLY transparent
messaging to ATAPI then make a proposal. But please don't require any
changes from the device suppliers or from the hosts ;-) In otherwords,
any change would have to be completely backwards compatible so as to be
transparent.
...Harlan
