This message is from the T13 list server.

Well, I would say its a bad thing to put in the spec that the host should
expect DRQ=0 when BSY=1 if this is not true. This seems to imply that if you
get DRQ=1 and BSY=1 then its some kind of error (whereas its might just a
transitory state). I was thinking that the device specs should be
conservative in what bit it sets(ie: when device set BSY=1, device set
DRQ=0) and the host spec liberal in what bits it uses (ie: when BSY=1 , dont
care about DRQ).

Am I the only to find those kind of errors/imprecisions in ATA/ATAPI or is
this just that everybody else just doesnt really care about the exact
wording of the specs as long as they know who its intended to work?

I found another strange wording a few pages further. In the Device PACKET
DMA command state diagram descriptions, there is for DPD2:DPD4 : "When the
device is ready to transfer DMA data for a command and nIEN is set to
one,...", but I dont think it matters what nIEN is here.

I am surprised nobody ever noticed that. Has anybody ever tried to implement
an host driver, or a device (or a device emulator) just following the
ATA/ATAPI 6 or 7 specs ?
But I guess this is kind of a stupid thing to do (compared to implementing
something that works in the real world.)

-- Fabrice


-----Original Message-----
From: Pat LaVarre [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 11, 2004 3:34 PM
To: [EMAIL PROTECTED]
Subject: RE: [t13] PACKET protocol. Host state diagram.


This message is from the T13 list server.


> > In a host's sample of x3F6 Alternate Status, or of x1F7 Status, seeing
> > BSY=1 makes DRQ indeterminate.
> 
> Make sense... Actually the diagram shows only BSY=1 for the HP2:HP2
> transition. The text however, states "When BSY is set to one, and DRQ is
> cleared to zero,

Ugh.

This English is wrong.

When BSY is set to one, DRQ is unknowable.

However, I agree we probably want the host to behave as if DRQ == 0
whenever BSY == 1.  I know myself I have often written code like:

xx = i(0x3F6);
if ((xx & 0x80) != 0) xx &= 0x80;

Supposedly unnecessary code like this spends code space and run time to
force these indeterminate bits to appear determinate, so that by
construction the people writing the code of the layer above cannot make
the error of branching on these indeterminate bits.

Pat LaVarre

Reply via email to