This message is from the T13 list server.
> if you include the DRQ bit in the mix (sff8020),
> you get a bigger picture of the current bus phase.
> How is this confusing?
> Or not useful?
Incomplete pictures are often misleading.
BSY:DRQ:ERR:C/D:I/O can occur in thirty-two combinations, and people disagree over how
to handle the conditions that should not occur.
Me, I'd say the complete picture is as follows. Mind you, I hear people say some
hosts have to trade away a little integrity in return for more interoperability ... in
particular, that some hosts have to resample x3F6 AlternateStatus if BSY = DRQ = 0
unexpectedly, just because the normal x 80 08 80 00 sequence there is not a Gray code.
> thirty-two combinations
We can speak of these combinations concisely in hex if
first we quote (x3F6 AlternateStatus & (x80 BSY | x08 DRQ | x01 ERR)) and
then we quote (x1F2 SectorCount aka InterruptReasons & (x02 IO | x01 CD).
x 8X XX: BSY set: wait (or timeout)
x 09 XX: DRQ set with ERR: fuzzy, do what you like, tell us how it goes. Me, I've
been trying x09 = x08 without having hurt yet.
x 08 03: not intelligible, so freak
x 08 02: DRQ Data In, count if too little data requested, freak if direction is wrong
or after too much data requested
x 08 01: DRQ Command Out, required when expected, else freak
x 08 00: DRQ Data Out, count if too little data requested, freak if direction is wrong
or after too much data requested
x 01 03: Status In, failed
x 01 XX, XX != x03: freak because device refused to move status in
x 00 03: Status In, passed
x 00 XX, XX != x03: freak because device refused to move status in
> Me, I'd say as follows,
I'm not clear how closely this idiosyncratic summary of how Atapi Pio works matches
which printed Sff/Ansi texts.
Pat LaVarre
>>> Mark Payne <[EMAIL PROTECTED]> 02/12/02 11:48AM >>>
This message is from the T13 list server.
I agree with Curtis ... and if you include the DRQ bit in the mix (sff8020),
you get a bigger picture of the current bus phase. How is this confusing?
Or not usefule?
IO DRQ CoD What it means
-- --- ---
-----------------------------------------------------
0 1 1 Command - Ready to Accept Command Packet Bytes
1 1 1 Message (Future) - Ready to Send Message data to
Host
1 1 0 Data To Host- Send command parameter data (e.g. Read
Data) to the host
0 1 0 Data From Host - Receive command parameter data
(e.g.
Write Data) from the host
1 0 1 Status - Register contains Completion Status
Regards,
Mark
-----Original Message-----
From: Curtis Stevens [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 12, 2002 10:35 AM
To: [EMAIL PROTECTED]
Subject: RE: [t13] doing a big favor
Hale
The way IO and CD get used really depends on the design of the host.
Since there is no CRC or Checksum on the command you send to the drive,
there is no real way to validate that the right hing is happening. IO and
CD give you at least some confirmation that the right thing is happening.
Further, if the host side is designed with independent state-machines to
read data and to send commands the IO and CD bits become very important. I
am aware of some firmware that works this way... The firmware is not broken
because IO and CD are well defined in the specification as to how they
operate during data transfers.
-----------------------
Curtis E. Stevens
Pacific Digital Corp.
2052 Alton Parkway
Irvine, CA 92606
Subscribe/Unsubscribe instructions can be found at www.t13.org.
Subscribe/Unsubscribe instructions can be found at www.t13.org.
