This message is from the T13 list server.
Hello, Michael. >The registers you enumerate (below) are decent for device capabilities >detection, but putting an identification field as part of the ADMA memory >mapped registers would be a more flexible "standard" method for determining >if a controller meets this proposed standard. The id field is used in other >controller types, and would work fine here too. Another method is to >require a new capabilities pointer, but this would only work for ADMA as a >brand new device type unencumbered by the legacy ATA controller features. I don't see why should the new capability ID be introduced when the device subclass itself identifies the ADMA (remember, it has sub-class value 05h, not the legacy 01h, and the programming interface register has the different meaning than that of legacy IDE subclass)? Or are there (or will be) any other ADMA-incompatible devices using this subclass value (Serial ATA controllers maybe)? Even if so, the discrimination can be made basing on the programming interface register... PS: I have the same question about the revision ID--D1510 states that it shall be equal 4xh. The specific values are used to judge whether ADMA engine supports ATAPI devices or not? I suppose some other method should be used to identify this... -- Sergei Shtylyov E-mail: [EMAIL PROTECTED] FidoNet: 2:5020/118.24 Subscribe/Unsubscribe instructions can be found at www.t13.org.
