This message is from the T13 list server.
>>> "[EMAIL PROTECTED]".API.EXAPI, > seems to me that a "bridge" device also needs to handle this stuff transparently without requiring ANY change to the host or to the device. Should do? YES YES YES. No can do, not for T13 4Dma, that's the problem. Real life just isn't that sweet. A bridge that doesn't crack the Cdb will Not give you the same results for Pio & Dma. A bridge that does crack the Cdb will Not bridge to different devices with equal transparency. Take your pick. I hear Mac OS X AtapiPio rounds up byte counts though Mac OS 9 AtapiPio did not. I wish somebody would go take a port to Mac OS X of the traditional Cizer tool and try http://members.aol.com/plscsi/20020328/oddwinme.txt and see if you don't see 6 bytes copied In when the device said to copy In 5, for a Cdb like -x 12 0 0 0 05 0. Ouch. > a port to Mac OS X of the traditional Apple Cizer tool I'd try this myself if I could. I don't have the source nor an updated binary. I hear porting Cizer to Mac OS X requires writing a Kext i.e. kernel extension i.e. your own filter driver. I hear nobody's published a Cizer yet like the http://members.aol.com/plscsi/ we have for Apple Mac Open Firmware boot Forth etc. x4402 Pat LaVarre [EMAIL PROTECTED] http://members.aol.com/plscsi/ >>> Pat LaVarre 04/15/02 11:38AM >>> This message is from the T13 list server. I haven't yet seen the intro, but I can reply to the proposal. My proposal (November?) last year was: a) Flip a bit in the op xA1 IdentifyPacketDevice to say you are device that bothers to report the bus residue, even for Dma, not just for Pio. b) Report the bus residue in x1F5:1F4 ByteCount at BSY DRQ C/D I/O = 0 0 c i StatusIn time. Since then I've added c) c) Also report x1F3 SectorNumber = x80 to say the device copied data In. Report x1F3 SectorNumber = x00 to say the device copied data Out. In all the Atapi device silicon I know, this is a firmware change only, no silicon change required. Silicon that automagically reports Good status despite the Atapi Data Fifo being not empty would have to learn to check for that (rare) condition. x4402 Pat LaVarre [EMAIL PROTECTED] http://members.aol.com/plscsi/ >>> "[EMAIL PROTECTED]".API.EXAPI, >>> Harlan Andrews 04/15/02 11:47AM >>> This message is from the T13 list server. I thought PAUSE and TERMINATE (for UDMA) can only happen at WORD boundaries. The UDMA hardware is not confused by odd byte counts.... They don't exist. The UltraDMA hardware already seems to know how to pause and resume properly. That stuff is transparent to the host. It seems to me that a "bridge" device also needs to handle this stuff transparently without requiring ANY change to the host or to the device. ...Harlan On 4/15/02, Hale wrote: >This message is from the T13 list server. > > >Something more to think about when attempting to transfer a BC value >from the device to the host within each DMA data burst... > >The BC values needs to be transmitted at the end of the DMA burst >around the same time the CRC is transmitted. This is because the BC >for the current DMA burst is not known until the end of the DMA >burst. This is because the host or device are able to terminate DMA >bursts at any time (for any reason). For example, the device might >want to transfer a 1000 bytes, the host might stop the transfer after >only 50 bytes. {This is much different that PIO bursts. In PIO the BC >value is the number of bytes the host SHALL transfer for the current >DRQ data block.} For this new DMA BC to be valid the device can not >send it to the host until the end of the DMA burst. And to have the >same effect as the PIO BC this new DMA BC must be sent from the >device to the host for both read and write DMA transfers. > >Comments? > > > >*** Hale Landis *** www.ata-atapi.com *** > > >
