This message is from the T13 list server.
Pat
Some devices clear BSY, but leave DRQ set to allow them to do
whatever at the end of a data transfer. When the device has actually
completed the command internally, then they clear DRQ. ATAPI devices are
the biggest offenders here.
------------------------------------------------
Curtis E. Stevens
20511 Lake Forest Drive #C-214D
Lake Forest, California 92630
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: [EMAIL PROTECTED]
My friends and I were on a beer run and noticed that the cases were
discounted 10%. Since it was a big party, we bought two cases. The cashier
multiplied two times 10% and gave us a 20% discount... and then he voted
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pat
LaVarre
Sent: Monday, November 15, 2004 2:57 PM
To: Gary Laatsch
Cc: [EMAIL PROTECTED]; Thomas Colligan; Hale Landis; Jeff Garzik
Subject: Re: [t13] e04155r0 - DRQ=0 When ERR=1 Feature
This message is from the T13 list server.
[[[Sorry my mailer sent a duplicate of this to GL already.]]]
> Example: is it is virtually impossible to clear DRQ at exactly the
> same time that ERR is set. Hence there will always be some sort of
> overlap where the state is undefined (DRQ -> 0 whiles ERR -> 1). That
> is the window I am concerned about.
Yes, it's difficult to avoid seeing a spurious b11 or b00 in the change
between b01 and b10: that's why Gray codes exist. But to avoid DRQ and
ERR appearing together, we should be asking the device to clear both or
either before clearing BSY. That's something device hardware - though
maybe not device firmware - actually can easily choose to do.
Pat LaVarre
P.S. How exactly ATA and ATAPI device hardware folk arrange for BSY DRQ
to cycle always thru b 00 10 11 01 11 10 00 and make b11 rare and never
spuriously produce a b00 in the middle, I've never entirely understood.
Any ASIC folk want to comment? Seems like double-latching to
synchronise clocks would open a b11 window wide ...
