This message is from the T13 list server.

Hale L:
 
For the ignorant (lazy?) like me, can you easily/quickly confirm/deny in English ...
 
Technically the published protocol requires a UDma receiver to tolerate a sender that 
sends a CRC for every two-byte "word" it sends.
 
And the published protocol requires a UDma sender to tolerate a receiver that asks for 
a CRC with every two-byte "word" it receives, except that the sender has some freedom, 
rising with burst rate, to send some extra "word"s included in the CRC before the CRC.
 
(In my stunning ignorance, these statements could be wrong-headed in a large number of 
shocking ways, but maybe this is a more clear statement of what I meant to ask.)
 
(Might be nice if I knew what STOP meant.  I might know more if we hadn't chosen to 
rename the pins every so often.  That history has meant that the bus traces I see in 
passing use any of a number of different names to discuss each pin & bit & byte.)
 
Pat LaVarre
 
 
-----Original Message----- 
From: Hale Landis [mailto:[EMAIL PROTECTED]] 
Sent: Fri 5/24/2002 2:07 PM 
To: [EMAIL PROTECTED] 
Cc: 
Subject: RE: [t13] DMA terminate



        This message is from the T13 list server.
        
        
        On Fri, 24 May 2002 13:39:43 -0600, Pat LaVarre wrote:
        >This message is from the T13 list server.
        >But I too would like to understand where/how the T13
        >spec requires a drive to tolerate an indefinite number
        >of arbitrarily placed STOP's.
        
        For a Read/Write DMA command the entire DMA data transfer, be it one
        DMA burst or hundreds of DMA bursts, it is all in state DDMA1.
        
        For a PACKET DMA command the entire DMA data transfer, be it one DMA
        burst or hundreds of DMA bursts, it is all in state DPD4. !!! !!! !!!
        WARNING WARNING WARNING !!! !! !!! Make sure you are looking at the
        corrected "Device PACKET DMA command state diagram". This state
        diagram was corrected in the ATA/ATAPI-5 Errata and should be correct
        in ATA/ATAPI-6.
        
        
        
        *** Hale Landis *** www.ata-atapi.com ***
        
        
        
        

Reply via email to