This message is from the T13 list server.

On Sun, 14 Apr 2002 09:01:32 -0600, Pat LaVarre wrote:
>This message is from the T13 list server.
>> The host side using PIO
>> has no way to suppress the
>> transfer of the pad byte.
>No.  Hosts vary in quality of implementation.

I was talking only of "standard" x86 systems...  These systems
have no way to suppress the transfer of the pad byte in PIO or
DMA.

>> On the x86 host side for PIO
>> the software has no choice
>> but to use the REP INSW
>> or REP INSD instructions.
>No.

I do not understand your "No" response.  Today's x86 PCI bus ATA
host adapters do not support reading the ATA data register 8-bits
at a time.  Only word or dword accesses are supported.  I have
asked because I wanted to test an 8-bit ATA device (a CF in 8-bit
mode) on a "standard" PC and it can't be done.

But here I must say I do not want to flood the T13 list with a
big discussion of how "double buffering" works or how some OS
device driver stacks can only move data from memory to memory in
2, 4 or 8 byte chunks.  This is not a T10 or T13 problem!

>I hear that x86 REP INSD of Ata/pi data commonly doesn't work:
>the bus trace the device sees doesn't match what appears in
>memory.

I have used my test software with REP INSD/OUTSD on lots of
systems and devices and I have never seen a data compare error
due to a x86 PCI bus host adapter failure.  Yes, there are
limitations on when/how REP INSD/OUTSD can be used but I will not
go into that in this message.

>Why not, how often not, who can fix it, who if anyone should fix
>it ... those are our questions.

I don't think so Pat...  We haven't defined the problem yet.  You
apparently refused to look at by example of a Ultra DMA data
transfer (because it didn't match the real world?).  But I think
it would show you how Ultra DMA works and therefore it would show
you many of the issues you would need to address in any
X-to-ATAPI bridge device, including the fact that there is no
such thing a "residue" data, there is only a single pad byte in
some cases.



*** Hale Landis *** www.ata-atapi.com ***



Reply via email to