This message is from the T13 list server.

Here is another DMA example for Pat...

I know I posted something similar before.

Assume fast Ultra DMA where the receiver gets 4 bytes more each time
the receiver signals stop to the sender. Assume a device with a
(strange) data block size of 501 bytes. Assume a command transfers 3
of these data blocks. That makes to total data transfer size 1503
bytes plus 1 pad byte for a total of 1504 bytes.

Now assume the entire data transfer is done in 4 DMA data bursts as
follows:

1st DMA data burst: Sender sends 400 bytes, receiver signals stop,
receiver gets 4 more bytes.

  -- 404 bytes have been transferred.

2nd DMA data burst: Sender sends 400 bytes, receiver signals stop,
receiver gets 4 more bytes.

  -- another 404 bytes, total of 808 bytes have been transferred.

3rd DMA data burst: Sender sends 400 bytes, receiver signals stop,
receiver get 4 more bytes.
 
  -- another 404 bytes, total of 1212 bytes have been transferred.

4th DMA data burst: Sender sends last 292 bytes. The last byte is a
pad byte.

  -- done, 1504 bytes transferred, the last byte was a pad byte.

The entire data transfer stream for this command has an odd number of
bytes so there is a single pad byte at the end. (If this command had
been executed in PIO mode then the same would be true, there would be
only one pad byte at the end of the last PIO DRQ data block.) There
are no extra/residual bytes at the end of each DMA data burst. There
is no pad byte at the end of each of the 501 byte data blocks. TO
repeat, there is only one pad byte at the end of the last DMA data
burst. All bytes transferred are data bytes, none are extra, none can
be ignored (except the single pad byte at the end).

I have not read your "white paper" yet but I'll bet you have made
some incorrect assumptions about how ATA/ATAPI data transfers are
executed? But now, like many people, I really must ignore this for
awhile so I can get my taxes done, but I'll get back to my email by
Monday. However, I look forward to reading your comments and/or
questions.



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



Reply via email to