This message is from the T13 list server.

> ...

We managed to continue this thread some offline.  (: I'm pleased to welcome this 
popular thread back here now:


> We rewrote ...
> to ... never look at IO and CD,
> ... and now this thing works
> with every [device] found ...

Expecting to know what IO will be works only for command blocks made fully standard 
before either the host or the device shipped.  Only then does the command block 
correctly imply IO.

Expecting to know CD will be set for status works only in the absence of asynchronous 
resets that unexpectedly clear BSY & DRQ without setting CD, such as the separately 
regulated power-failed resets of Pcmcia connections.

Expecting to know CD will be set to move the command block out and to move data either 
way only works when the host & the device handshake together perfectly.  For example, 
I've seen host abuse like ignoring IORDY and/or writing 12*2 bytes rather than 12 
bytes of command block and I've seen devices that react to such abuse by asking for 
the command block more than once.


> BSY ... DRQ ... IO ... CD ...

Agreed BSY & DRQ win over IO & CD.

Agreed the host needs to include enough of a state machine to send the command block 
(aka the packet) only once, to move data only in the right direction, to never move 
more than the correct byte count of data.


> I just hate to see
> all these host side engineers
> doing the wrong thing
> and having to redesign their hosts
> when they place more importance
> on IO and CD than on BSY and DRQ.

> BSY and DRQ control
> the command protocol execution

Yes, yes, yes!

And yes, the ALMOST complete redundancy between BSY, DRQ, CD, & IO leads people to 
confuse them.

Rumour tells me the first devices implemented according to the SFF 8070i 
compatible-with-LS-120 specification cleared BSY at random, because otherwise he 
device, built out of commodity Ata hardware, would miss x08 Device Reset.

Rumour tells me some other devices get CD & IO backwards, like the popular quick 
reference card (printed by KnowledgeTek?), especially if they were tested only with 
hosts that ignore CD & IO.



> BSY and DRQ control
> the command protocol execution

Yes, yes, yes!

> BSY and DRQ control
> the command protocol execution
> and not other status bits
> are needed to determine
> where you are in the protocol 

No, no, no!


Pat LaVarre

Subscribe/Unsubscribe instructions can be found at www.t13.org.

Reply via email to