This message is from the T13 list server.
Don C: Glad to hear you still listening, glad to see you posting a third perspective. Speaking now to that third perspective, yes the Atapi details matter: AtapiDma needs an analogue to what you point out Ata 0.5KiB block read/write already has for both Pio and Dma in its x1F2 SectorCount register: a place where the device and the host can look to see whether they have or have not agreed over how many bytes should move. AtapiPio already has such a place: both the device and the host can sum samples of x1F5:1F4 Cylinder (aka ByteCount) taken at DRQ INTRQ time. That sum tells us, of the data bytes clocked, how many bytes the device agreed to move. AtapiDma needs such a place. I'm suggesting a sample of x1F5:1F4 Cylinder (aka ByteCount) taken at x1F2 SectorCount (aka InterruptReason) = x03 StatusIn time i.e. after all data clocks across the bus. That sample "residue" could say, of the data bytes clocked, of Udma bytes included in the UDma Crc, how many bytes the device did not agree to move. For example, to report the device had agreed to move x91 of the x92 bytes included in a UDma Crc, the residue would be 1 = x92 - x91. A less clearly intuitive example is the extreme of UDma Data Out, where a host can inadvertently overestimate the count of bytes a device agrees to move by 2 * X + 1, where X rises with burst rate. I don't mean to be saying we should give the device new freedom to disregard quietly a host's request to move N bytes. I'm trying to say instead we should let the device report if it moved N bytes or something else, so that the host can know to freak out when the device unexpectedly moved something else. I'm asking for Atapi UDma to count bytes moved as precisely as I know Atapi Pio does ... as precisely as now I see Ata 0.5KiB block read/rite does. Pat LaVarre >>> don clay <[EMAIL PROTECTED]> 01/26/02 10:08 AM >>> This message is from the T13 list server. This thread has been followed for some time. If you are designing an X to ATA-x bridge, the following is true on the ATA side. 1. The device has to be told exactly how many sectors to transfer via the Sector Number register whether it be read or write via either PIO or any DMA. 2. The device will transfer exactly that amount of data unless an error is detected by the device, any kind of reset is issued, or a new command is issued. 3. The device will pause data transfer only between sectors by waiting to post the interrupt and raise DRQ in PIO mode or by de-activating DMAREQ in any DMA mode. I am pretty sure that this is exactly true of an ATAPI device as well, but am not 100% sure all of the details. So if you are designing any X to ATA/ATAPI bridge, your bridge has to be incredibly stupid (meaning that you probably have to be incredibly sharp with your design) or, more likely, your bridge will have to translate commands from the X interface to ATA, buffer data, and handle the specifics of managing each interface. Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
