This message is from the T13 list server.
> From: Hale Landis [[EMAIL PROTECTED]]
> Sent: Thu 1/16/2003 10:33 AM
> ... for the last time?
I don't think our English is yet precise and
unambiguous enough to retire this issue in the
confident belief we understand each other.
I'm talking about something real. When you deny it
exists, you just sound silly ... so we must not mean
the same thing by the same words.
I am pleased to see you raise the claim: "In reality
the BC is always an even number". Since that claim
is plainly false when quoted out of context, I imagine
we are progressing.
> * Part 1: The Physical Interface and Command Protocol
>
> The ATA/ATAPI interface is 16-bits wide during data
> transfer. That means only an even number of bytes
> can be transferred. This rule applies to both PIO
> and DMA transfers.
I think the first ambiguity creeps in here.
When you say "transfer" you could mean "copy" from
memory to memory. If you do, then you misspoke. If
instead you mean "clock across the bus" then you're
merely restating a well-known truth: in Ata/pi, data
bursts clock pairs of bytes across a 16 bit bus, no
matter Pio/SwDma/MwDma/UDma.
> For ATAPI data transfer commands...
>
> 1) On write commands the host side must always
> prepare an even number of bytes to transmit to the
> device.
Yes, though not necessarily contiguous in memory.
> This means that if an OS application really wants
> to send an odd number of bytes the OS device driver
> must add a pad byte.
One or more pad bytes, yes.
> The OS driver must do this without violating any
> memory access requirements the OS may have imposed
> on the application program
Yes, the OS driver owns that job.
> and without accesing memory beyond the
> application's data buffer.
I find this English difficult also.
OS drivers differ in how deeply they trust the app.
The less trust, the better they work. The least
trust is to access only the same memory that was
accessed by legacy drivers when the app was developed.
Designing an OS driver to access all the memory the
app claimed could be accessed is a good way to go
find broken apps: not a useful way to spend time.
> The only way the device knows it is receiving an
> odd number of bytes is by looking at the SCSI CDB
> data.
Agreed, Ata/pi gives the host no way of disclosing
precisely how many bytes it wishes to copy In or Out,
so the device has to guess. Often nothing but the
Cdb goes into that guess, but not always.
> 2) On read commands the host side must always
> accept an even number of bytes from the device.
I find this English difficult also. What do we mean
by "accept".
> This means that if an OS application really wants
> to receive an odd number of bytes the OS device
> driver must discard the pad byte.
Same ambiguity as when copying data Out: one or more, yes.
> The OS driver must do this without violating any
> memory access requirements the OS may have imposed
> on the application program and without accessing
> memory beyond the application's data buffer.
Same ambiguities as when copying data Out.
> The only way the device knows it should send an odd
> number of bytes is by looking at the CDB data.
Same ambiguities as when copying data Out.
> But the most important cnncept is this: In PIO
> mode, just like in DMA mode, only an even number of
> bytes are transferred on the ATA/ATAPI interface.
Same "copy" vs. "clock" ambiguity as above.
> This means that at the lowest level of the host OS
> device driver stack, the host software is
> restricted to host hardware that transfers only two
> bytes at a time.
Same "copy" vs. "clock" ambiguity as above.
Furthermore, in Atapi Pio with an x86 host, we can
discard bytes copied to registers, without ever
dirtying extra memory.
> Nowever now we run into one of the strange things
> about ATAPI: the Byte Count (BC). The BC really
> isn't a "byte count" - it is a "word" count (a word
> being two bytes in the long standing x86 tradition).
> In reality the BC is always an even number.
The x1F5:1F4 Cylinder = ByteCount value from the
device is a number between x0001 and xFFFE, SFF
consciously did not require it to be even, T13
followed faithfully.
> In reality the BC is always an even number. This
> is because before transferring a PIO data block
> the host must perform the following computation:
> numberWords = ( BC + 1 ) / 2
In the de facto Win 95 B standard, this calculation
was incorrect:
numberWords = ( BC ) / 2
> That is, the host must convert the BC into a word
> count every time (no exceptions):
I don't know what "no exceptions" means here, sorry.
> That is, the host must convert the BC into a word
> count every time (no exceptions):
>
> BC=1 and BC=2 is word count 1
> BC=3 and BC=4 is word count 2
> ...
> BC=59 and BC=60 is word count 30
> ...
> BC=65533 and BC=65534 is word count 32767
Yes, though working in decimal makes this hard for me
to see at a glance.
> and finaly the strange one
> BC=65535 is the same as BC=65534 or word count 32767
I haven't followed the de jure and de facto standards
closely here, the devices of my experience never
used large BC.
In the Byte Count Limit written to x1F5:1F4 rather
than read from x1F5:1F4, I think I do remember I did
see Microsoft use xFFFF to mean xFFFE, before the de
jure standard got around to blessing that creative
choice.
> So why is this value a byte count and not a word
> count (as it should be)? My answer is because the
> ATAPI protocol was defined by a "secret society".
If by "secret society" we mean SFF, then that secret
society excluded me. I didn't create an Atapi device
until after Win 95 B shipped.
> Perhaps if the development of ATAPI was more open
> to public comment we would not still be having
> problems with the meaning of BC and how to handle
> odd BC values and how to handle BC=0 values.
Probably not. T13 Atapi UDma was developed more
publically than Sff Atapi, developed broken, and yet
noone spoke at the time. To this day, none of my
employer's, may they ever remain anonymous, have
shipped a device that needs the speed of Atapi UDma.
> BC is really a "word count" and that makes PIO and
> DMA transfers entirely equivalent - a data transfer
> command will transfer the same number of words in
> PIO as it does in DMA.
Same "copy" vs. "clock" ambiguity as above.
> Something to think about for the future: What if
> the ATA/ATAPI interface could do 32-bit wide or
> 64-bit wide data transfers? This would be no
> problem for traditional ATA commands but for ATAPI
> it would add more pad bytes to some data transfers.
> BC would still be an even value: 4 or 8.
This happens now, ever more with increasing burst
rate, whenever the host & the device have failed to
agree perfectly in advance out of band over how many
bytes a Cdb means to copy in context.
> Bottom line: BC is really always an even value at
> the physical interface and command protocol level.
Presumably, this is not crazy, only I must somehow
misunderstand.
> * Part 2 - CDBs with odd data transfer
Agreed, that's a good place to go next.
In a bus trace, the only distinction between
-x "12 0 0 0 05 0" -i 5
-x "12 0 0 0 06 0" -i 6
is that the x1F5:1F4 ByteCount is odd.
It is the odd number x0005 rather than the even
number x0006.
Pat LaVarre
