Speaking of master/slave handshaking...
jesup at cbmvax.cbm.commodore.com
Tue Jan 4 11:47:07 PST 1994
>One of the problems with ATA-1 is the unclear way that
>master/slave handshaking is described and how the results of this
>activity affect following operations. This is really unfortunate
>since there are more pages of the ATA-1 document devoted to this
>topic than to any other part of the ATA interface.
Hmmm, from your description, it looks like I was still interpreting
it incorrectly. Probably the fact that I'm coming at the problem from a
non-clone point of view is part of the problem. There are a lot of
assumptions in the current spec about what you're familar with.
>Note that DRDY is a DRIVE status bit, not a controller status
>bit, and just because the controller is "not busy" does not imply
>anything about the "ready" status of a drive.
Something that should have been in red flashing ink in the status
>Drive 0 sets BSY=1, does the master/slave handshake, which could
>take up to 31 seconds, and then drive 0 may set BSY=0. Then
>drive 0 can complete spinup, etc, and set DRDY=1. The ATA has no
>specification for when DRDY=1 should happen. Please note that
>there is NO reference to the DRDY bit of the Status register in
>Annex A or B. What is in Annex A and B is the statement
> "Drive 0 clears BSY when ready to accept commands (within 31
>I think a lot of people read this sentence as if it said
> "Drive 0 clears BSY and sets DRDY when ready to accept
> commands (within 31 seconds)."
>If people do interpret this sentence in this way, they are wrong.
Like me. The problem is that there's almost no description of
what BSY and DRDY _are_. Most of the understanding of the signals comes from
inference from the diagrams. For quite a while while developing the driver
I thought that !BSY and !DRDY was an incorrect condition, until I read the
index in detail.
>Also note the sentence marked by "->". I would bet that a lot of
>people fail to "see" this sentence when they read Annex A!
I didn't. What I did see was:
A.1.2.1 Drive 1
- Drive 1 clears BSY when ready to accept commands.
- Drive 1 asserts PDIAG- to indicate that it is ready to accept commands
(within 30 seconds from RESET-).
A.1.2.2 Drive 0
- Drive 0 waits up to 31 seconds for Drive 1 to assert PDIAG-. If PDIAG- is not
asserted, Drive 0 sets Bit 7=1 in the Error Register.
- Drive 0 clears BSY when ready to accept commands (within 31 seconds).
I read "ready to accept commands" as being the same as "sets DRDY".
>--- And now, one final comment ---
>If I could change the way host software is designed, I would do
>the following (and I would definitely do this in a notebook
>computer if there was no possibility that a second drive could be
>added to the computer's ATA host adapter):
>Support only one drive per ATA host adapter with that drive
>configured as slave (drive 1). This would be great... No
>master/slave handshaking to worry about... No multi-vendor
>compatibility problems... No problems with a Drive 0 that
>"hangs" waiting for a Drive 1 to do something... No problems
>with a Drive 0 that thinks there is no Drive 1 when there really
>is a Drive 1... No problems with a Drive 0 that thinks there is
>a Drive 1 when there really is no Drive 1...
>Ahhh... Life would be wonderful! But then there is nothing more
>difficult in the entire universe than getting software people to
>change the way they do things.
My biggest beefs with the whole ATA spec are that:
a) It's tricky to determine if there's drive attached. (We had to add
pullups to DRDY and BSY, and use a status of DRDY|BSY to indicate that
no drives are attached at all.)
b) Since there's no difference between no slave drive (status = 0x00) and a
slave drive that has asserted PDIAG but has not asserted DRDY (status =
0x00) there's no way to determine if a slave drive is attached.
c) There's no bloody "I'm generating the interrupt" bit (we have to add
hardware around the interface to create such a bit in order to use ATA
drives in a shared interrupt environment).
d) Commands and bits that are mentioned but their use is never defined (the
removable media support, for example).
e) The lack of interoperability between manufacturers.
f) Lack of testing to the spec (all the drives that fail on 256 sector
transfers, for example).
(The last few are problems with the manufacturers, not with the spec.)
Not all our machines have any battery-backed ram. How long should
they wait to see if there's a drive 1? Even for those that do have battery-
backed ram, we always prefer to automatically configure - adding/removing
drives should be simple (see current Apple ads for an example, admittedly
I always knew there was a reason I disliked ad-hoc standards...
Even if they get made into "real" standards, they still retain all sorts
of funny limitations and quirks to make ones life miserable, especially if you
try to use them outside their original application.
Oh well. Thanks for the clarification, Hale. Please tell Will
Paduano (sp?), Dick Edwards, etc that I'm sorry I was wrong on this one
(though perhaps it helped point out how easy it was to misread the spec -
they agreed with me when I said the spec required drive 1 to be ready before
GNU Emacs is a LISP operating system disguised as a word processor.
- Doug Mohney, in comp.arch
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
jesup at cbmvax.commodore.com or rutgers!cbmvax!jesup BIX: rjesup
Disclaimer: Nothing I say is anything other than my personal opinion.
More information about the T10