Working                                            X3T10
Document                                                  1120



                                                    Revision 1p
                                             September 19, 1995




Information Technology -
AT Attachment Packet Interface
(ATAPI)


This is an internal working document of X3T10, a Technical
Committee of Accredited Standards Committee X3. As such, this is
not a completed standard and has not been approved. The contents
may be modified by the X3T10 Technical Committee. The contents
are actively being modified by X3T10. This document is made
available for review and comment only.

Permission is granted to members of X3, its technical committees,
and their associated task groups to reproduce this document for
the purposes of X3 standardization activities without further
permission, provided this notice is included. All other rights
are reserved. Any commercial or for-profit replication or
republication is prohibited.






ASC X3T10 Technical Editor:
                                   Thomas D. Hanan
                                   Western Digital Corporation
                                   8105 Irvine Center  Drive
                                   Irvine, Ca   92718
                                   USA
                                   
                                   Tel:     714 932-7472
                                   Fax:    714 932-7312
                                   Email: hanan_t@a1.wdc.com
                                   
                                   



                                                 Reference number
                                             ISO/IEC ***** : 199x
                                               ANSI X3.*** - 199x
                 Printed December, 3, 1995 9:53AM
                                                                 
Other Points of Contact:

X3T10 Chair                             X3T10 Vice-Chair
John B. Lohmeyer                        Lawrence J. Lamers
Symbios Logic,Inc.                      Adaptec, Inc.
1635 Aeroplaza Drive                         691 S. Milpitas
Blvd.
Colorado Springs, CO 80916                   Milpitas, CA 95035
Tel: 719-573-3362                       Tel: 408-957-7817
Fax: 719-573-3037                       Fax: 408-957-7193
Email: john.lohmeyer@hmpd.com                     Email:
ljlamers@aol.com

X3 Secretariat
Lynn Barra
Administrator Standards Processing
X3 Secretariat
1250 Eye Street, NW  Suite 200
Washington, DC 20005
Tel: 202-626-5738                       Email:
LBARRA@ITIC.NW.DC.US
Fax: 202-638-4922

ATA Reflector
Internet address for subscription to the ATA reflector:
majordomo@dt.wdc.com
Send email to above account and include in BODY of text, on a
line by itself the following:
     "subscribe ata [your email address]"
Internet address for distribution via ATA reflector:
ata@dt.wdc.com

ATA Anonymous FTP Site
fission.dt.wdc.com
ATAPI directory is:  "/pub/ata"

X3T10 Bulletin Board
719-574-0424

Document Distribution
Global Engineering
15 Inverness Way East
Englewood, CO   80112-5704
Tel: 303-792-2181 or  800-854-7179
Fax: 303-792-2192


                            ABSTRACT

The standard for AT Attachment Interface with Extensions (ATA-2)
has been completed, but as the popularity of the interface has
increased, its application area has grown outside the originally
intended purpose. This draft proposed standard is based upon the
AT Attachment Interface with Extensions (ATA-3). This document
is a stand alone document, separate from that document.  The AT
Attachment Packet Interface (ATAPI) standard is intended to
broaden the ATA scope and application area and take advantage of
the huge installed BIOS (Basic Input/Output System) base, and
software.

This standard defines a SCSI Like packet interface protocol for
use with the ATA protocol defined in ATA-3.

The ATAPI standard shall maintain a high degree of
compatibility with the AT Attachment with Extensions (ATA-3)
while providing documentation for new capabilities.  This
standard is not intended to require changes to presently
installed devices or existing software. It is intended that this
standard would be used to provide additional capabilities.

The proposed ATAPI standard involves evolutionary expansion of
the draft AT Attachment with Extensions standard to provide
additional capabilities. The nature of the proposed project is
to enable the attachment of devices other than disk drives to the
physical AT Attachment interface as defined in the ATA-3
standard. This insures that current investments in AT
Attachment are provided with more stability in the face of
technological developments. It is likely that any isolated
negative impacts would occur in any case through non-standard
evolution or revolution.




                        PATENT STATEMENT

CAUTION: The developers of this standard have requested that
holders of patents that may be required for the implementation of
the standard, disclose such patents to the publisher. However,
neither the developers nor the publisher have undertaken a patent
search in order to identify which, if any, patents may apply to
this standard.

As of the date of publication of this standard and following
calls for the identification of patents that may be required for
the implementation of the standard, no such claims have been
made.


                         Change History
                                
Rev 0.2 -> Rev 0.3, Aug 20, 1995
1.   Remove bottom 4 Bullet Items from Section 3.5.1
2.   Remove section 3.5.2.1
3.   Remove bottom 2 bullets from section 4.6
4.   Change Bit 0 of Status registers from ERROR to CHECK.
5.   Move BIOS & ATAPI Driver Compatibility section to Annex A
6.   Add ATAPI device should wait until SRST is cleared by the
     host before completing their SRST sequence. to Annex A 6.2.1
     SRST Initialization Sequence
7.   Change Draft Standard to Standard
8.   Remove Proposal
9.   Remove last Two Lines of last paragraph of ABSTRACT.
10.  Change 0xnn to 0nnh for Hex.
11.  Remove DASP & PDIAG sequence from SRST in ATAPI
     Implementation of ATA SRST.



Rev 0.3 -> Rev 1, Sep 19, 1995
1.   Global search and replacement of Will, May and Could.
2.   Global search and replacement of SERVICE with DSC.
3.   Global search and replacement of CoD with C/D-.
4.   Global search and replacement of EXECUTE DIAGNOSTICS with
     EXECUTE DRIVE DIAGNOSTICS.
5.   Capitalize Commands.
6.   Replace section 2.2 Signal Conventions with ATA-3 text.
7.   Move Abbreviations to their own section.
8.   Move section 3.5.2 Redundant Command Functionality to
     Informative Annex.
9.   Clean up DRQ & BSY sequencing.
10.  Delete 2nd paragraph of section 4.10.1 Release.
11.  Move Note to bottom of figure 4.
12.  Remove item 11 from section 4.11.
13.  Add SERVICE to header in section 5.7.
14.  Change note 1 in table 9 from superscript to (1) and make
     note part of table graphics.
15.  Remove note from description of bit 4 in table 10.
16.  Change Sense Key to ATAPI Sense Key in table 11.
17.  See change bars and revision 0.3 for additional changes.


Table of Contents

1. SCOPE                                                        1

2. CONVENTIONS                                                  3
     2.1 DOCUMENT CONVENTIONS                                   3
     2.2 SIGNAL CONVENTIONS                                     3
     2.3 DEFINITIONS                                            3
          2.3.1 ATA (AT ATTACHMENT)                             3
          2.3.2 CHS (CYLINDER-HEAD-SECTOR)                      3
          2.3.3 COMMAND PACKET (CP)                             3
          2.3.4 DATA BLOCK                                      3
          2.3.5 DMA (DIRECT MEMORY ACCESS)                      3
          2.3.6 FIELD                                           3
          2.3.7 INVALID                                         4
          2.3.8 LBA (LOGICAL BLOCK ADDRESS)                     4
          2.3.9 LOGICAL BLOCK                                   4
          2.3.10 LUN                                            4
          2.3.11 MANDATORY                                      4
          2.3.12 ONE                                            4
          2.3.13 OPTIONAL                                       4
          2.3.14 PAGE                                           4
          2.3.15 PIO (PROGRAMMED INPUT/OUTPUT)                  4
          2.3.16 SAM                                            4
          2.3.17 RESERVED                                       4
          2.3.18 STATUS                                         4
          2.3.19 VS (VENDOR SPECIFIC)                           4
          2.3.20 ZERO                                           5
     2.4 SYMBOLS AND ABBREVIATIONS                              5

3. ATAPI OVERVIEW                                               6
     3.1 ATA SIGNAL UTILIZATION                                 6
     3.2 ATA COMMAND UTILIZATION                                6
     3.3 ATA COMPATIBILITY                                      6
     3.4 PACKET TYPES                                           7
     3.5 HOW SCSI IS USED BY ATAPI                              9
          3.5.1 DIFFERENCES FROM THE SCSI STANDARD              9
          3.5.2 REDUNDANT COMMAND FUNCTIONALITY (TASK FILE VS.
          PACKET)                                              10
               3.5.2.1 ATAPI IDENTIFY DRIVE VS. INQUIRY        10
               3.5.2.2 INITIALIZE DRIVE PARAMETERS AND SET
               FEATURES VS. MODE SENSE AND MODE SELECT         10

4. ATAPI PROTOCOL                                              10
     4.1 INITIALIZATION                                        10
     4.2 PACKET COMMAND                                        10
     4.3 STATUS REGISTER UTILIZATION FOR PACKET COMMANDS       11
     4.4 BYTE COUNT REGISTER (CYLINDER LOW/HIGH) USAGE FOR PACKET
     COMMANDS                                                  11
     4.5 SECTOR COUNT (ATAPI INTERRUPT REASON) REGISTER USAGE
     FOR PACKET COMMANDS                                       12
     4.6 IMMEDIATE COMMAND OPERATION                           13
     4.7 FLOW OF PACKET COMMAND, PIO DATA IN TO HOST           14
     4.8 FLOW OF PACKET COMMAND WITH PIO DATA OUT FROM THE HOST16
     4.9 FLOW OF NON-OVERLAP DMA DATA COMMANDS                 18
     4.10 OVERLAPPED COMMAND OPERATION                         20
          4.10.1 RELEASE                                       21
          4.10.2 USING THE DSC COMMAND (A2H)                   22
          4.10.3 LEGAL TRANSITIONS                             23
          4.10.4 ATAPI OVERLAP WITH ONLY ONE ATAPI PERIPHERAL  25
          4.10.5 TASK FILE OWNERSHIP                           27
          4.10.6 ERROR HANDLING WITH OVERLAPPED COMMANDS       27
     4.11 FLOW OF OVERLAPPED COMMANDS WITH DATA TRANSFER FROM
     HOST TO DEVICE                                            28
     4.12 FLOW OF OVERLAPPED COMMANDS WITH DATA TRANSFER FROM
     DEVICE TO HOST                                            31
     4.13 FLOW OF NON-DATA COMMANDS                            35
     4.14 TIMING OF NON-OVERLAP PACKET COMMAND                 36
     4.15 TIMING OF NON-OVERLAP DATA AND STATUS TRANSFER       37
     4.16 CONTROL SIGNAL TIMING REQUIREMENTS AND RELATIONSHIPS 38

5. ATAPI TRANSPORT MECHANISM                                   39
     5.1 RESET CONDITIONS                                      39
          5.1.1 POWER ON OR HARDWARE RESET                     39
     5.2 ATAPI SOFT RESET COMMAND AND PROTOCOL                 39
     5.3 ATAPI IMPLEMENTATION OF ATA SRST                      41
     5.4 PHYSICAL CONNECTION                                   42
     5.5 SINGLE DEVICE CONFIGURATIONS                          42
     5.6 REGISTER MAPPING                                      43
     5.7 ATAPI REGISTER MAP (PACKET COMMAND)                   43

6. ANNEX A - BIOS AND ATAPI DRIVER COMPATIBILITY               49
     6.1 RESET MASTER/SLAVE DIAGNOSTICS SEQUENCE               49
     6.2 SRST INITIALIZATION SEQUENCE                          49
     6.3 SPECIAL HANDLING OF ATA READ AND IDENTIFY DRIVE
     COMMANDS                                                  49
     6.4 ATAPI AWARE BIOS AND DRIVER CONSIDERATIONS            50
     6.5 DEFAULT TIMING                                        50
     
List of Figures
FIGURE 1 - PACKET COMAND WITH PIO DATA IN TO HOST              15
FIGURE 2 - PACKET COMMAND WITH PIO DATA OUT FROM HOST          17
FIGURE 3 - PACKET COMMAND WITH DMA DATA                        19
FIGURE 4 - STATE DIAGRAM, OVERLAPPED OPERATION, LEGAL
           TRANSACTIONS                                        24
FIGURE 5 - ATAPI OVERLAP COMMAND SEQUENCE                  ERROR!
FIGURE 6 - ATAPI OVERLAP, ONE ATA DEVICE AND ONE ATAPI DEVICE  26
FIGURE 7 - PACKET COMMAND WITH PIO DATA IN FROM HOST           30
FIGURE 8 - PACKET COMMAND WITH PIO DATA IN TO HOST             33
FIGURE 9 - TIMING OF COMMAND PACKET TRANSFER                   35
FIGURE 10 - TIMING OF DATA AND STATUS TRANSFER                 36
FIGURE 11 - ATA SRST SEQUENCE                              ERROR!

List of Tables
1 GENERIC COMMAND AND STATUS USAGE FOR ATAPI DEVICES            7
2 BYTE COUNT REGISTER USAGE                                    12
3 REGISTERS AFTER THE SERVICE COMMAND                          22
4 LEGAL OVERLAP TRANSACTIONS                                   23
5 REGISTERS CONTROLLED BY BSY & DRQ                            27
6 PREFERRED DRIVE CONNECTION                                   42
7 SHADOW REGISTERS                                             42
8 SHADOWING FOR SINGLE DRIVE CONFIGURATIONS                    43
9 I/O PORT FUNCTIONS/SELECTION ADDRESS (COMPATIBILITY MODEL)   44
10 ATAPI STATUS REGISTER (ATA STATUS REGISTER)                 45
11 ATAPI ERROR REGISTER (ATA ERROR REGISTER)                   45
12 ATAPI FEATURE REGISTER (ATA FEATURE REGISTER)               46
13 ATAPI BYTE COUNT REGISTER (ATA CYLINDER HIGH/LOW REGISTER)  46
14 ATAPI INTERRUPT REASON REGISTER (ATA SECTOR COUNT REGISTER) 47
15 ATAPI DRIVE SELECT REGISTER (ATA DRIVE / HEAD SELECT
   REGISTER)                                                   47
16 ATAPI DEVICE CONTROL REGISTER (ATA DEVICE CONTROL REGISTER) 48


1.   Scope
This document is intended to be used with the ATA-3 document. Its
purpose is to describe the operation of the ATA Packet Interface
Transport Mechanism (ATAPI-TM) and ATA Packet Interface Transport
Protocol (ATAPI-TP). It indicates areas within the ATA document
which are modified for operation of Packet Interface Protocols n
the ATA environment. Both mandatory and optional specifications
are presented.
In the event of a conflict between the ATA-3 document and
this document, the interpretation of this document shall prevail
only if this document acknowledges that a conflict exists between
the documents.
This document provides a description for the ATAPI Transport
Protocol (ATAPI-TP) and ATAPI Transport Mechanism (ATAPI-TM).
Command sets for specific devices such as CD-ROM and Tape are
defined in separate documents referencing this standard.


Interconnects


                                





                    Intentionally Left Blank

2.   Conventions


2.1n  Document Conventions
Certain words and terms used in this document have specific
meaning beyond the normal English meaning. These words and terms
are defined either in this section or in the text where they
first appear. Names of signals, commands, statuses, and sense
keys are in all uppercase (e.g. ATAPI IDENTIFY DEVICE). Lower
case is used for words having the normal English meaning.
Fields containing only one bit are usually referred to as the
<name> bit instead of the <name> field. Numbers that are not
immediately followed by a lower case b or h are decimal (nnh for
Hexadecimal, where nn refers to two hexadecimal digits 0-9, A-F.)


2.2  Signal Conventions

Signal names are shown in all upper case letters.

All signals are either high active or low active signals. A dash
character (-) at the end of a signal name indicates it is a low
active signal. A low active signal is true when it is below ViL,
and is false when it is above ViH. No dash at the end of a
signal name indicates it is a high active signal. A high active
signal is true when it is above ViH, and is false when it is
below ViL.

Asserted means that the signal is driven by an active circuit to
its true state.

Negated means that the signal is driven by an active circuit to
its false state.

Released means that the signal is not actively driven to any
state. Some signals have bias circuitry that pull the signal to
either a true state or false state when no signal driver is
actively asserting or negating the signal. These cases are noted
under the description of the signal, and their released state is
stated.

Control signals that may be used for two mutually exclusive
functions are identified with their two names separated by a
colon e.g. SPSYNC:CSEL can be used for either the Spindle Sync
(SPSYNC) or the Cable Select (CSEL) functions.



2.3  Definitions

2.3.1     Command Packet (CP)
Command Packet is the structure used to communicate commands
from a host computer to an ATAPI device.

2.3.2     Data Block
This term describes a data transfer, and is typically a single
sector, except when declared otherwise by use of the Set Multiple
command.

2.3.3     DMA (Direct Memory Access)
DMA is a means of data transfer between peripheral and host
memory without processor intervention.

2.3.4     Field
A field is a group of one or more contiguous bits.

2.3.5     Ignore
Information in this field or bit shall not be used by the
receiving device.


2.3.6     Invalid
Invalid refers to an illegal (reserved) or unsupported field or
code value.

2.3.7     Logical Block
A Logical Block is a unit of data supplied or requested by a host
computer.

2.3.8     Mandatory
Mandatory indicates that a referenced item is required to claim
compliance with this standard.

2.3.9     One
One represents a true signal value or a true condition of a
variable.

2.3.10    Optional
Optional describes features which are not required by the
standard. However, if any feature defined by the standard is
implemented, it shall be done in the same way as defined by the
standard. Describing a feature as optional in the text is done to
assist the reader. If there is a conflict between text and tables
on a feature described as optional, the table shall be accepted
as being correct.

2.3.11    Page
Several commands use regular parameter structures that are
referred to as pages. These pages are identified with a value
known as a page code.

2.3.12    Shall
Describes a mandatory requirement of the standard.

2.3.12    Should
Describes a recommendation within the standard..

2.3.13    Reserved
Reserved bits, fields, bytes, and code values are set aside for
future standardization. Their use and interpretation may be
specified by future extensions to this or other standards. A
reserved bit, field, or byte shall be set to zero, or in
accordance with a future extension to this standard.  The
recipient shall not check reserved fields.

2.3.14    Status
Status is one byte of information sent from the ATAPI device to
the host computer upon completion of each command.

2.3.15    Vendor Specific - VS
The term, VS, is used to describe bits, bytes, fields, code
values and features which are not described in this standard, and
may be used in a way that varies among vendors.

2.3.15    Zero
Zero is a false signal value or a false condition of a variable.


2.4  Symbols and Abbreviations

2.4.1     ATA (AT Attachment)
ATA defines a compatible register set and a 40-pin connector and
its associated signals.

2.4.2     AWG
American Wire Gauge

2.4.3     CHS (Cylinder-Head-Sector)
This is an ATA term defining the address translation  of the
drive as being by physical address. This form of addressing is
not used by ATAPI Devices.

2.4.4     LBA (Logical Block Address)
The LBA defines the address translation of the drive by the
linear mapping of sectors from 0 to n.

2.4.5     LSB
Least significant bit

2.4.6     LUN
Logical Unit Number.

2.4.7     MSB
Most significant bit

2.4.8     PIO (Programmed Input/Output)
PIO is a means of data transfer that requires the use of the host
processor.

2.4.9     SAM
SCSI Architectural Model. X3T10/994D

2.4.10
AWG   American Wire Gauge
LSB   Least significant bit
LUN   Logical unit number
MSB   Most significant bit

3.   ATAPI Overview
The purpose of the ATAPI is to provide a more extensible and
general purpose interface than the ATA Task file.
Although a device attached to the ATAPI Interface utilizes
the ATA Host Hardware and Task File, the logical interface
differs  slightly  and needs to  support  additional
capabilities. The Mass Storage devices connected to the ATA make
use of eight registers (Task File) that contain the command and
all parameters needed for operation. However, eight registers is
not enough to pass all the needed information for commanding
other peripheral types. To remedy this, the ATAPI Device receives
its commands through the use of an ATAPI PACKET command,
in addition to the normal ATA protocol. The ATAPI PACKET command
complements the existing ATA commands. The ATAPI Device shall
support all of the ATA specified protocol, including the Reset
Master/Slave Diagnostic Sequence, Diagnostic Command, and Command
Abort for unsupported Commands. The ATAPI Device shall also
support both the Master and Slave modes of operation.


3.1  ATA Signal Utilization
ATAPI Devices utilize the signals and timing definition from
the ATA-3 Standard.

3.2  ATA Command Utilization
The ATA Task File concept does not contain enough bytes to
support some of the command structures of non-disk peripherals,
so a new command called Packet Command has been added to allow
a Packet to be sent to the Device. The Packet data  be
transferred by writing multiple times to the Data Register. No
random access to the register file in the Peripheral can be done.
This technique reduces the number of register addresses needed,
but not the actual space needed. Although all the commands for
the ATAPI Device could be sent via this packet protocol, some of
the existing ATA commands and the full ATA command protocol
are necessary for the existing drivers to operate correctly.
The ATAPI Devices therefore support some existing ATA commands
in addition to the new ATAPI PACKET command, so that there are
minimal changes to the drivers. This minimal set of ATA commands
is different than the minimum as defined in the ATA standard,
but should be sufficient for normal operation.

3.3  ATA Compatibility
There are several backward compatibility issues with the ATA
commands, and therefore the ATAPI Devices respond to the
existing ATA Reset Master/Slave Diagnostic Sequence, but not the
Identify Drive or Read commands. This allows the BIOS and
older drivers to ignore the Device and not confuse data with
normal ATA Drive format data. All unsupported ATA commands shall
be Aborted, and not executed. As with aborted commands in ATA, an
interrupt is generated to signal the completion with an
aborted error status.

3.4 Packet Types
To allow for generic packet transfer and the connection of SCSI
like peripherals, there shall exist a minimum set of information
that is exchanged. This information shall generically support the
following:
  -    Command Packet (Always padded to number of bytes identified
       in byte 0 of the identify drive data.
       00 = 12 bytes, 01 = 16 bytes)
  -    Command Parameter Data (e.g. Write Data etc.)
  -    Command Response Data (e.g. Read Data etc.)
  -    Status. The Status will be presented using the ATAPI Status
       Register (redefinition of the ATA Status Register).



Table 1 - Generic Command and Status Usage for ATAPI Devices

    Command     Used Code         Error Register           Status Register
                          BBK UNC IDNF ABRT TK0NF AMNF DRDY DWF DSC CORR CHECK

 ACKNOWLEDGE     N    DBh               V                                  V
 MEDIA CHANGE
 BOOT - POST-    N    DCh               V                                  V
 BOOT
 BOOT - PRE-     N    DDh               V                                  V
 BOOT
 CHECK POWER     M    E5h               V               V    V   V         V
 MODE
 DOOR LOCK       O    DEh               V     V         V        *         V
 DOOR UNLOCK     O    DFh               V               V                  V
 MEDIA EJECT     N    EDh               V               V        V         V
 EXECUTE DRIVE   M    90h       Special Drive                              V
 DIAGNOSTICS                  Diagnostic Errors
 FORMAT TRACK    O1   50h           V   V           V   V    V             V
 IDENTIFY DRIVE  N    ECh               V                                  V
 IDLE            O    E3h               V           V   V    V             V
 IDLE IMMEDIATE  M    E1h               V           V   V    V             V
 INITIALIZE      N2   91h               V                                  V
 DRIVE PARMS
 NOP             M    00h               V           V                      V
 ATAPI PACKET    M    A0h      Contains Packet               V             V
                               Command Status
 ATAPI IDENTIFY  M    A1h               V               V    V   V         V
 DEVICE
 ATAPI SOFT      M    08h
 RESET
 SERVICE         O    A2h               V               V                  V
 READ BUFFER     N    E4h               V                                  V
 READ DMA        N    C8h               V                                  V
 (W/RETRY)
 READ DMA        N    C9h               V                                  V
 (WO/RETRY)
 READ LONG       N2   22h               V                                  V
 (W/RETRY)
 READ LONG       N2   23h               V                                  V
 (WO/RETRY)
 READ MULTIPLE   N    C4h               V                                  V
 READ SECTOR(S)  N2   20h               V                                  V
 (W/RETRY)
 READ SECTOR(S)  N2   21h               V                                  V
 (WO/RETRY)
 READ VERIFY     N2   40h               V                                  V
 SECTOR(S)
 (W/RETRY)
 READ VERIFY     N2   41h               V                                  V
 SECTOR(S)
 (WO/RETRY)
 RECALIBRATE     O1   1xh               V     V         V    V   V         V
 SEEK            N    7xh               V                                  V
 SET FEATURES    M    EFh               V           V   V    V             V
 SET MULTIPLE    N    C6h               V           V   V    V             V
 MODE
 SLEEP           M    E6h               V           V   V    V             V
 STANDBY         O    E2h               V           V   V    V             V
 STANDBY         M    E0h               V           V   V    V             V
 IMMEDIATE
 WRITE BUFFER    N    E8h               V                                  V
 WRITE DMA       N    CAh               V                                  V
 (W/RETRY)
 WRITE DMA       N    CBh               V                                  V
 (WO/RETRY)
 WRITE LONG      N2   32h               V                                  V
 (W/RETRY)
 WRITE LONG      N2   33h               V                                  V
 (WO/RETRY)
 WRITE MULTIPLE  N    C5h               V                                  V
 WRITE SAME      N    E9h               V                                  V
 WRITE           N2   30h               V                                  V
 SECTOR(S)
 (W/RETRY)
 WRITE           N2   31h               V                                  V
 SECTOR(S)
 (WO/RETRY)
 WRITE VERIFY    N    3Ch               V                                  V
 INVALID                                V           V   V    V             V
 COMMAND CODE

V = Valid on this command
M = Mandatory and shall be supported by ATAPI Devices, as
specified by the ATA Standard
O = Optional for use by an ATAPI Device
N = Not supported by ATAPI Devices (shall be Aborted by the ATAPI Device)

Dark Shading = New ATAPI Commands
Light Shading = existing ATA Commands
Shaded = Commands are utilized by the ATAPI Devices

1.  Although this command is Optional for ATAPI, the ATA
Standard specifies it as Mandatory.
2.  This command is specified as Mandatory for ATA, but shall
NOT be supported by ATAPI Devices.

3.5 How SCSI is Used by ATAPI
Although an ATAPI Device utilizes many of the actual packet
definitions from the SCSI standard, it does NOT use most other
features of the normal SCSI Protocol. Thus there are no Phases,
no Messages, no multiple host support and no SCSI Hardware.

3.5.1 Differences from the SCSI Standard
Some of the major differences from the SCSI Standard:
  -  Status uses the ATAPI description, rather than a Data
     Byte passed at the end of the command.
  -  The ATAPI Device is the slave during operation rather than
     having the master view of a SCSI Peripheral.
  -  No messages are supported.

An ATAPI Device makes use of many of the Standard SCSI Command
Block definitions and Commands, but some of the commands that
would normally be supported by a SCSI Device are not supported for
various reasons. These commands are:
  -  Reserve and release; as there is only one Host allowed, this
     is not needed.
  -  Send and receive diagnostics; the ATA EXECUTE DRIVE DIAGS
     command replaces these commands.
  -  Change definitions; as there is no SCSI, this command  is
     nonsensical.
  -  Copy  /  Copy  and  Verify;  no  device  to  device  data
     transfers so this command can't be implemented.
  -  Compare; no shared bus, so this command can't be implemented.


4.   ATAPI Protocol

The ATAPI Device is commanded by two methods, the original ATA
Commands utilizing the Task File and the new Packet Command
method. For both methods, the devices using this interface shall
be programmed by the host computer to perform commands and return
status to the host at command completion. When more than one
Device is daisy chained on the interface, commands are written in
parallel to all peripherals, and for ATA commands except the
Execute Drive Diagnostics command, only the selected Device (DRV
bit in the Drive/Head ATA Register) executes the command. On an
Execute Drive Diagnostics command addressed to Device 0, both
devices shall execute the command, and Device 1 shall post its
status to Device 0 via PDIAG-.
The Protocol for ATAPI centers around the usage of a new ATA
Command called Packet Command. All the normal ATA rules and
protocol are used to issue the Packet Command, but once the
command has been issued, a new set of rules applies:
1. The interpretation of the DRQ bit in the Status Register shall
   be used along with the Interrupt Reason Registers to determine
   the actual Interrupt Type.
2. The actual command for the Device to execute is sent as a
   packet via the data register, and not the Task File.
3. Command arguments are supplied by the Command Packet as well
   as from the Task File.
4. A Byte Count is used to determine the amount of data the Host
   shall transfer at each DRQ Interrupt.
5. The ATAPI Features Register is used to indicate when DMA
   is used rather than by using different opcodes.
6. The final status is presented to the Host as a new interrupt
   after the last data has been transferred, rather than along
   with the last block of data.

These new rules (protocol) only apply from after the issuance of
the Packet Command, until the Completion Status has been read by
the Host. After the Completion Status has been read, the Task
File Register definitions and Protocol revert to the standard ATA
definition.


4.1  Initialization
The ATAPI Device responds just as defined in the ATA Standard.
The DASP and PDIAG signals are utilized following any reset
condition, except the ATAPI RESET command.


4.2  PACKET Command
The Packet Command is issued exactly as normal ATA commands, by
initializing the Task File Registers, setting the Drive Selection
Bit and writing the Command byte into the Command Register. With
normal ATA commands a DRQ (Optional Interrupt) would be generated
to indicate that the data for the command could be transferred
to/from the Device. With the Packet Command, the first DRQ
indicates that the Command Packet Data shall be written to the
Device. Once the Command Packet has been sent, the command
proceeds as a normal ATA command would. The Command Packet bytes
shall always be transferred via PIO and never using DMA.
ATA Packet Commands can be issued regardless of the state of the
DRDY Status Bit.
If while polling BSY the device remains in a state where it
cannot accept a command for more than 5 seconds, the Host shall
time out and reset the device.

4.3
Status Register Utilization for Packet Commands

D7     D6      D5     D4     D3      D2     D1     D0       
BSY    DRDY    DMA    DSC    DRQ     CORR   Reser- CHECK   Read
              READY                          ved


4.4  Byte Count Register (Cylinder Low/High) Usage for Packet
Commands

D7     D6     D5      D4     D3      D2     D1     D0       
                    Byte Count (Bits 0-7)                  R/W
                    Byte Count (Bits 8-15)                 R/W

This register is used to control the number of bytes the Host
shall transfer at each DRQ. It is only used for the command
parameter data being transferred via PIO and never for DMA or
Command Packet bytes.
Since the length of data that is actually transferred to and from
an ATAPI Device using PIO is controlled by the Host, and since
the ATAPI Device needs to be able to control the number of bytes
transferred, an additional capability was needed. By using the
Byte Count Register, a capability to transfer a variable number
of bytes has been created. In ATAPI the Device indicates to the
Host the number of bytes that shall be transferred on each DRQ
Interrupt. Before transferring data, the Host shall read the 16-
bit Byte Count Register, and comply with the length requested.
Both the ATAPI Device and the Host have their own byte
counts and transfer until those counts go to zero. For some
commands, such as Mode Sense, the Host does not know the amount
of data that be transferred, and shall rely on the Byte
Count supplied by the Device to transfer the correct amount of
data.
A further capability of the Byte Count Register is for the Host
to signal to the ATAPI Device the maximum amount of data it can
take in a single PIO DRQ or DMA DMARQ packet and/or the preferred
packet size. For all commands that require data be transferred to
the host, the Host shall set the Byte Count Register to the
desired length before issuing the Packet Command. This length
shall be used by the ATAPI Device as the maximum size for each
PIO or DMA data packet. The Device can choose to transfer packets
smaller than those set by the host in the Byte Count Register.
For all commands that can transfer all the data in one DRQ
Interrupt, the Byte Count shall contain the total data length.
When a Read command is being processed, the ATAPI Device may wish
to send all the data that is available in its buffers on just one
DRQ Interrupt, with the limitation that only 65535 bytes may be
transferred at one time.

Table 2 - Byte Count Register Usage

    Operation       Usage (PIO)          Usage (Non-Overlapped DMA)
     
 Send Command       Is used as a         Command Packet is
 Packet             parameter to the     always sent via
                    Packet Command and   Programmed I/O and not
                    is not used to       DMA.
                    control the Packet
                    transfer.
 Parameters to the  As a parameter to    The Device can ignore
 Packet Command     any Packet Command   the byte count, as the
 (Task File         that transfer        actual transfers are
 Contents)          parameter data, the  controlled via the
                    Byte Count is used   ATAPI Device and not
                    by the Host to       the Host.
                    communicate the
                    maximum / preferred
                    amount of data to be
                    transferred on each
                    DRQ.
 Parameter Data     At each DRQ the      The ATAPI Device can
 from the Device    count contains the   request data
 to the Host (e.g.  number of bytes that transfer whenever it
 data from a Read,  the Host shall       wishes, and as such
 or Inquiry         transfer from the    the Byte Count shall
 command)           Device.              not be used.
 Parameter Data     At each DRQ the      The ATAPI Device can
 from the Host to   count contains the   transfer data whenever
 the Device (e.g.   number of bytes that it wishes, and as such
 data for a Write,  the Host shall       the Byte Count shall
 or Mode Select     transfer to the      not be used.
 command)           Device.

If the Device requests more data be transferred than required by
the command protocol, the Host shall pad when sending data to the
Device, extra data when reading data from the Device.
The only permissible time for an actual Odd Byte Count value be
on the Last DRQ, Intermediate DRQs shall contain even byte counts.
The peripheral is not responsible for padding the data. Only the
specific amount of data specified by the host byte count shall be
transferred.


4.5 Sector Count (ATAPI Interrupt Reason) Register Usage for
Packet Commands

D7     D6     D5     D4     D3     D2      D1     D0       
           Reserved                RELEASE IO     C/D-      Read

The Interrupt Reason Register contains an expanded definition of
the ATA DRQ Status. When the DRQ is presented in the ATAPI Status
Register for an ATAPI Packet Command, then the contents of this
register indicate if Packet Command or User Data shall be
transferred and, if so, the direction of the transfer.

4.6  Immediate Command Operation
Immediate ATAPI PACKET commands return Completion Status immediately,
with the actual execution of the command continuing. When the actual
completion of the seek operation of immediate ATAPI PACKET
commands has occurred, the Device shall set the DSC bit in the
Status Register.
- Immediate  ATAPI PACKET commands that report completion
  before  the  actual completion (e.g., CD-ROM Seek, Play  Audio,
  etc.) shall respond by queuing the new command.
- New ATAPI PACKET commands received while a
  previous packet command is still executing shall cause both
  commands to be aborted with an error, Check Condition.
- If an Immediate ATAPI PACKET  command is executing when
  the device is issued an SRST the DSC bit shall not be cleared
  with the rest of the status register. Instead the functionality
  of the DSC bit shall be maintained.

4.7 Flow of Packet Command, PIO Data In to Host
This class of packet commands includes commands such as Inquiry,
Read etc. Execution includes the transfer of some unknown number
of data bytes from the Device to the host.
1.  The host Polls for BSY=0, DRQ=0 then initializes the task file
    by writing the required parameters to the Features, Byte
    Count, and Drive/Head registers.
2.  The host writes the Packet Command code (A0h) to the Command
    Register.
3.  The Device sets BSY, before the next system read of the status
    register, and prepares for Command Packet transfer.
4.  When the Device is ready to accept the Command Packet, the
    Device sets C/D- and clears IO, BSY prior to asserting DRQ.
    Some Devices assert INTRQ following the assertion of DRQ.
5.  After detecting DRQ, the host writes the 12 bytes (6 words) of
    Command to the Data Register.
6.  The Device(1) clears DRQ (when the 12th byte is written), (2)
    sets BSY, (3) reads Features and Byte Count requested by the
    host system, (4) prepares for data transfer.
7.  When data is available, the Device:(1) places the byte count
    of  the data available into the Cylinder High and  Low
    Registers, (2) sets IO and clears C/D-, (3) sets DRQ and
    clears BSY, (4) sets INTRQ.
8.  After detecting INTRQ, the host reads the DRQ bit in the
    Status Register to determine how it shall proceed with the
    command. If DRQ=0 then the device has terminated the command.
    If DRQ=1 then the host shall read the data (number of bytes
    specified in the Cylinder High/Low Registers) via the Data
    Register. In response to the Status Register being read, the
    Device negates INTRQ for both cases.
9.  The Device clears DRQ. If transfer of more data is required,
    the Device sets BSY before clearing DRQ and the above
    sequence is repeated from step 7.
10. When the Device is ready to present the status, the Device
    places the completion status into the Status Register, sets
    C/D-, IO, DRDY, DRQ  and clears BSY, prior  to
    asserting INTRQ.
11. After detecting INTRQ, DRQ cleared and BSY cleared,
    the host reads the Status Register and if necessary, the Error
    Register for the command completion status.

The DRQ signal is used by the device to indicate when it is ready
to transfer data, and is cleared after (during) the last byte of
data to be transferred. This applies for both Command Packet as
well as normal read/write data.


Figure 1 - Packet Comand with PIO Data In to Host

4.8 Flow of Packet Command with PIO Data Out from the Host
This class includes commands such as Mode Select, Write etc.
Execution includes the transfer of some known number of data
bytes from the Host to the Device.
1.  The host Polls for BSY=0, DRQ=0 then initializes the task file
    by writing the required parameters to the Features, Byte
    Count, and Drive/Head registers.
2.  The host writes the Packet Command code (A0h) to the Command
    Register.
3.  The Device sets BSY, before the next system read of the status
    register, and prepares for Command Packet transfer.
4.  When the Device is ready to accept the Command Packet, the
    Device sets C/D- and clears IO, BSY prior to asserting DRQ.
    Some Devices will assert INTRQ following the assertion of DRQ.
    DRQ may be set before or after BSY has been de-asserted;
    however, DRQ is will not be visible to the host until BSY=0.
5.  After detecting DRQ, the host writes the 12 bytes (6 words) of
    Command to the Data Register.
6.  The Device(1) clears DRQ (when the 12th byte is written), (2)
    sets BSY, (3) reads Features and Byte Count requested by the
    host system, (4) prepares for data transfer.
7.  When ready to transfer data, the Device:(1) sets the byte
    count (Cylinder High and Low Registers) to the amount of data
    that the Device wishes to be sent, (2) clears IO and C/D-,
    (3) sets DRQ and clears BSY, (4) sets INTRQ. The Byte Count
    would normally be set to the number of bytes requested by the
    contents of the register at the receipt of the command, but
    may be any amount that the Device can accommodate in its
    buffers at this time.
8.  After detecting INTRQ, the host reads the DRQ bit in the
    Status Register to determine how it shall proceed with the
    command. If DRQ=0 then the device has terminated the command.
    If DRQ=1 then the host shall write the data (number of bytes
    specified in the Cylinder High/Low Registers) via the Data
    Register. In response to the Status Register being read, the
    Device negates INTRQ for both cases.
9.  The Device clears DRQ. If transfer of more data is required,
    the Device sets BSY before clearing DRQ and the above sequence
    is repeated from step 7.
10. When the Device is ready to present the status, the Device
    places the completion status into the Status Register, sets
    C/D-, IO, DRDY, DRQ and clears BSY, prior to asserting INTRQ.
11. After detecting INTRQ, DRQ cleared and BSY cleared, the host
    reads the Status Register and if necessary, the Error Register
    for the command completion status. The Device clears DRQ and
    sets BSY. If transfer of more data is required, the above
    sequence is repeated from step 7.
10. When the Device is ready to present the status, the Device
    places the completion status into the Status Register, sets
    C/D-, IO, DRDY and clears BSY, DRQ, prior to asserting INTRQ.
11. After detecting INTRQ & DRQ=0 the host reads the Status
    Register and if necessary, the Error Register for the command
    completion status.

The DRQ signal is used by the device to indicate when it is ready
to transfer data, and is cleared after (during) the last byte of
data to be transferred. This applies for both Command Packet as
well as normal read/write data.






Figure 2 - Packet Command with PIO Data Out from Host

4.9 Flow of Non-Overlap DMA Data Commands
This  class includes commands such as Read, Write etc.  Execution
includes the transfer of some unknown number of data bytes.
1. The  host Polls for BSY=0, DRQ=0 then initializes the task file
   by  writing  the  required parameters  to  the  Features,  Byte
   Count,   and   Drive/Head  registers.  The   host   must   also
   initializes  the  DMA  engine which will services  the  Devices
   requests.
2. The  host  writes the Packet Command code (A0h) to the  Command
   Register.
3. The Device sets BSY and prepares for Command Packet transfer.
4. When  the  Device  is ready to accept the Command  Packet,  the
   Device sets C/D- and clears IO, BSY prior to asserting  DRQ.
   Some Devices will assert INTRQ following the assertion of DRQ.
5. After detecting DRQ, the host writes the 12 bytes (6 words)  of
   Command to the Data Register.
6. The  Device(1) clears DRQ (when the 12th byte is written),  (2)
   sets  BSY, (3) reads Features and Byte Count requested  by  the
   host system, (4) prepares for data transfer.
7. When   ready  to  transfer  data,  the  Device  transfers   via
   DMARQ/DMACK any amount that the Device can accommodate  or  has
   in  its buffers at this time. This continues until all the data
   has been transferred.
8. When  the  Device  is ready to present the status,  the  Device
   places  the  completion status into the Status  Register,  sets
   C/D-, IO, DRDY, DRQ  and clears BSY, prior to asserting INTRQ.
9. After  detecting INTRQ, DRQ cleared and BSY cleared,  the  host
   reads  the Status Register and if necessary, the Error Register
   for the command completion status.



Figure 3 - Packet Command with DMA Data


4.10 Overlapped Command Operation
ATAPI  devices  reporting  support for  Overlapped  commands  are
capable of improving system performance by releasing the ATA  bus
to  another  device before completing a command in progress.  The
host system can enable this feature by setting the OVERLAP bit in
the  Feature Register when it issues an ATAPI Packet command. The
device  uses  the  RELEASE  bit in  the  ATAPI  Interrupt  Reason
register  to  notify the host that it has released  the  ATA  bus
before it has completed the command in progress.
- Releasing the ATA bus to another device is at the discretion
  of  the device processing an Overlapped command. Devices should
  only  Release the ATA Bus, before a command has completed, when
  the host willdoes  not need to service an Interrupt or DRQ from
  the device for more than the time specified in words 71 and 72 of
  the devices identify drive data. This is typically the cases for
  seeks on mechanically slower devices such as CD-ROM and Tape.
- When the host detects a Release from a device to which it
  has  sent an overlapped command, the DRV bit may be changed  to
  select another device and issue a command.
- Changing the DRV bit while BSY or DRQ are set may cause the
  currently selected device to abort any command in progress.
- The  normal  protocol for Non-Overlapped commands  requires
  that  the  command complete before the host can select  another
  device. This means that the host willis  not be able to  access
  the  Overlapped  device again until the non  overlapped  device
  completes any command the host may issue to it.
- To ensure fairness between slower Overlapped and faster Non-
  Overlapped devices sharing the same ATA channel, can be achieved
  by the host should polling the slower Overlapped device's
  DSCSERVICE bit before issuing each new command to the faster non-
  Overlapped device.
- When the host detects that the DSCSERVICE bit in the ATAPI
  STATUS Register is set, a Service (A2h) command shall be issued
  before any task file registers besides ATAPI STATUS are valid.
- Once  the  Service (A2h) command has successfully completed
  the host may service the device's interrupt as if the device were
  the only device on the ATA Bus.
- Slower Overlapped devices may release control of the ATA bus
  several times while processing an overlapped command.
- When  DMA data is to be transferred, the protocol  sequence
  used for PIO iswill be followed. When data is to be transferred a
  Service Interrupt shall be generated. No data shall  be
  transferred until the Service (A2h) command has been received by
  the Device.
- The number of bytes that shall be transferred is
  specified in the BYTE COUNT Register after the Service (A2h)
  command has been processed. After the specified number of bytes
  is transferred the ATA bus shall either be released or held busy
  until data or status are available.
- At the completion of data transfer, if the Device shall
  Release the ATA Bus, BSY shall be cleared in less than 5ms.

4.10.1 Release
One  of  the  capabilities that is the foundation for  Overlapped
operation is Release. There are three different forms of  release
used in this specification, after the receipt of a Command, after
transferring  some  data  and after the receipt  of  the  Service
Command.
This  standard  allows  the  device to  implement  these  release
operations either in the Firmware or in Hardware. Each  of  these
release  points has its own complexities. For example before  the
Task  File  Registers  can be released after  the  receipt  of  a
command,  the  Command and parameter information must  be  saved.
Once  the  release  is performed the contents of  the  Task  File
Registers  can  no  longer  be  used  by  the  Device.   Although
automatically saving the task file when DRV is changed would seem
a  simple  solution, it requires unnecessary changes to  existing
ATAPI device VLSI. which prevent F/W versions of a protocol  from
being implemented before automating the protocol for speed.
The  device shall consistently unload the information in the Task
File  Registers. Although holding the BSY longer  in  some  cases
would  most  likely  be  acceptable  from  a  system  performance
standpoint,  forcing the driver to poll for  varying  lengths  of
time  is not. This specification forces the device to report  the
typical  length of time that the device will requires  to  unload
and  then Release the Task File Registers. Further to reduce  the
length  of  time  that  the Driver would have  to  poll  for  the
release,   this   standard  defines  an  Interrupt   on   Release
Capability.
The Interrupt on Release capability is enabled by the Host Driver
using a SET FEATURES Command. To assist the Driver in determining
if  the  Interrupt should be enabled the IDENTIFY  DRIVE  Command
returns  the length in microseconds that the device will uses  to
Release  for both an Overlapped Command and the Service  Command.
The  Driver  can  then  make  its  own  decision  to  enable  the
interrupt.  Thus if the Device reports 1000 ms, the Driver  could
decide  that  it  wants  to  poll and not  enable  the  interrupt
(Unlikely).
The  Release  after the transfer of data shall  be  performed  by
hardware for all data transfer operations and as such there is no
Interrupt generated after the release when transferring data.
The  Release after the Service Command shall only occur after the
parameters  for  the  Interrupt are loaded  into  the  Task  File
Registers.  Thus for a hardware implementation of  this  Release,
there  should  exist  a  separate set of  information  for  these
parameters  e.g. Byte Count, Interrupt Reason, Status.  Note,  in
the  future,  acceleration of the Service Command  willis  become
very  important  to  the  overall system performance  when  using
overlap.  It  is  highly recommended that the  time  required  to
perform the Release after the SELECTION Command is less than 5ms.

4.10.2 Using the Service Command (A2h)
The  Arbitration of the Task File Registers is performed by logic
outside  of  the  Devices attached to the ATA  Cable.  The  basic
premise  is  that the Device releases the use of  the  Task  File
Registers  when it is processing the command and no longer  needs
the  registers. This of course makes it difficult  to  place  the
arguments  for the Interrupt into the registers as the device  no
longer  owns  them. The Service command allows the host  to  give
control of the task file registers back to the device so that the
correct  parameters  can  be placed into them.  These  parameters
include the Byte Count, and Interrupt Reason.
When  an  overlapped command requests service the Host Driver  is
responsible for determining which device should be serviced,  and
then issuing the Service Command. This causes the device to place
information  on  the reason for the service into  the  Task  File
registers.

Table 3 - Registers after the Service Command

Addresses  Register          Contents

  1F0      Data              
  1F1      Error Register    If the Status indicates an
                             Error then this is Valid
  1F1      Reserved for ATA  Reserved and not used by this
           Tag               Specification.
  1F2      Interrupt Reason  Contains IO and C/D-
  1F3      Tag for Command   Reserved for future use as Tag
                             for the command requiring
                             Service
  1F4      ATAPI Byte Count  Number of bytes that need to
           LSB               be transferred, both for PIO
                             or for DMA
  1F5      ATAPI Byte Count
           MSB
  1F6      Drive Select      Same before and after Service
  1F7      Status            DRQ along with IO, C/D- and
                             Release determine the reason
                             for the Service Request
  3F0      Floppy A Status   Unused
  3F1      Floppy B Status   Unused
  3F2      Unused            Unused
  3F3      Floppy ID / Tape  Unused
           Control
  3F4      Floppy            Unused
           Controller Status
  3F5      Floppy Data       Unused
           Register
  3F6      Alternate Status  Same as Status register
  3F7      Change / Drive    Same before and after
           Address           Service
                                
4.10.3 Legal Transitions

Table 4 - Legal Overlap Transactions

State From      State To  Reason      Sequence          Notes

Idle            Cmd       Host Issues BSY=1,       
                Packet    A0h         C/D-=1, IO=0,
                                      DRQ=1, BSY=0

Cmd Packet      Release   Command ok, BSY=1, DRQ=0,     The time
                          but no data RELEASE=1,        required by
                          is ready to C/D-=0, IO=0,     the Device to
                          be          BSY=0, INTRQ=1    perform the
                          transferred if Interrupt on   Release is
                                      Release After     specified in
                                      Command Packet    Word 71 of the
                                      is enabled        Identify Drive
                                                        Data

Cmd Packet      Data      Command ok  BSY=1, DRQ=0,     The assertion
                Transfer  and Data is C/D-=0, IO=1/0,   of DRQ shall
                          ready to be RELEASE=0,        occur within
                          Sent/       DRQ=1, BSY=0,     the time
                          Received    INTRQ=1           specified in
                                                        word 71 of the
                                                        Identify Drive
                                                        Data

Data Transfer   Release   # of bytes  RELEASE=1, DRQ=0  The Release
                          specified   (BSY stays=0,     shall occur
                          by the Byte C/D- & IO stay    within 5ms
                          Count       the same)         after
                          Register                      transferring
                          has been                      the last word
                          transferred                   of data

Data Transfer   Data      # of bytes  BSY=1, DRQ=0,     The assertion
                Transfer  specified   Byte Count = new  of DRQ shall
                          by the Byte count (C/D- & IO  occur within
                          Count       stay the same),   5ms after
                          Register    DRQ=1, BSY=0,     transferring
                          has been    INTRQ=1           the last word
                          transferred                   of data from
                                                        the previous
                                                        data transfer

Release         Service   Data or     DSCSERVICE=1,     Requests that
                          Status is   DMA READY=0/1,    the Host
                          ready for   INTRQ=1           Arbitrate and
                          the Host                      Issue the
                                                        Service
                                                        Command.

Service         Data      Service     BSY=1, IO=1/0,    
                Transfer  Command     C/D-=0, Byte
                          issued and  Count=x, DRQ or
                          Data can be DMARQ=1 (DMA
                          transferred READY stays the
                                      same), BSY=0,
                                      INTRQ=1 if
                                      Interrupt on
                                      Service
                                      Completion is
                                      enabled

Service         Status    Service     BSY=1, IO=1,      This is not a
                          Command     C/D-=1,           recommended
                          issued and  RELEASE=0,        transition.
                          Status is   DRQ=0, BSY=0,     After
                          available   INTRQ=1 if        transferring
                                      Interrupt on      the data the
                                      Service           device should
                                      Completion is     set BSY until
                                      enabled           the status is
                                                        available

Data Transfer   Status    # of bytes  BSY=1,            BSY shall be
                          specified   RELEASE=0, DRQ    set within 5ms
                          by the Byte or DMARQ=0,       after
                          Count       C/D-=1, IO=1,      transferring
                          Register    BSY=0, INTRQ=1    the last word
                          has been                      of data if
                          transferred                   status willis
                                                        not be
                                                        available
                                                        within the 5ms
                                                        window
                                
                                



Figure 4   -  State Diagram, Overlapped Operation, Legal Transactions
Note: Release to Service path is optional and NOT recomended.

4.10.4 ATAPI Overlap with only one ATAPI Peripheral
-      ATAPI  Drive  Releases  the  Task  File  Ownership   after
       acceptance of an ATAPI command.
-      Overlap  Mode  is  enabled on each command  via  the  ATAPI
       Features Register.
-      Overlapped  Commands are issued to an  ATA  (Legacy)  Drive
       while an ATAPI Command is still processing.
-      Interrupts are generated from the selected device only. Thus
       the Driver must always select the Overlap capable device  when
       there is no active command to a Legacy Device.
-      Device uses Interrupt & DSCSERVICE Status to gain Host's
       attention. DSCSERVICE Status set when any service is needed.
-      Driver uses the A2h (Service) Command to give control of the
       Task File Registers back to the Device after an Interrupt and
       Sensing the DSCSERVICE status bit.
-      The Interrupt Reason RELEASE Status bit is used to indicate
       a Release Interrupt.





Figure 5 - ATAPI Overlap Command Sequence


Figure 6 - ATAPI Overlap, One ATA Device and One ATAPI Device

4.10.5 Task File ownership
When BSY or DRQ is set, the Task File Registers are owned by  the
Device,  otherwise the Registers are owned by the Host. When  the
Device  does  not own the Registers, it shall not write  to  into
them.  Table  5 - Registers Controlled by BSY & DRQ on page 27
shows which of the ATA Registers are considered part of the Owned
Task File Registers. Logic conventions are:  A = signal asserted,
N = signal negated, x = does not matter which it is.

               Dark Gray are registers where ownership is
               controlled by BSY & DRQ.
               Light Gray are Registers that are not defined for
               use by ATA.


Table 5 - Registers Controlled by BSY & DRQ

         Addresses                          Functions
 CS1FX   CS3FX   DA2  DA1  DA0    Read (DIOR-)    Write (DIOW-)
 
   A       N      0    0    0                 Data
   A       N      0    0    1    Error Register     Features
   A       N      0    1    0   ATAPI Interface Reason / Sector
                                             Count
   A       N      0    1    1            Sector Number
   A       N      1    0    0   ATAPI Byte Count LSB / Cylinder
                                              Low
   A       N      1    0    1   ATAPI Byte Count MSB / Cylinder
                                              High
   A       N      1    1    0             Drive Select
   A       N      1    1    1        Status          Command
   N       A      0    0    0   Floppy A Status      Unused
   N       A      0    0    1   Floppy B Status      Unused
   N       A      0    1    0        Unused      Floppy Digital
                                                     Output
   N       A      0    1    1   Floppy ID / Tape    RESERVED
                                    Control
   N       A      1    0    0        Floppy         RESERVED
                                   Controller
                                     Status
   N       A      1    0    1         Floppy Data Register
   N       A      1    1    0   Alternate Status Device Control
   N       A      1    1    1    Change / Drive      Unused
                                    Address



4.10.6    Error Handling with Overlapped Commands
An  issue can arise because overlapped commands are enabled on  a
Command by Command basis. If an overlapped command is in progress
and  a  non-overlapped command is then received, the Device  must
aborts   without status on any outstanding overlapped  or  queued
command(s).
In  overlapped  operation  there iswill be  intermediate  command
status,  as  well  as  the final command completion  status.  The
intermediate  status is supplied to indicate if the  command  was
accepted. If the command is not accepted, then there wilis  l  be
no further status supplied. The intermediate status is the status
at  the  point  that the device releases the Task File  registers
back  to  the  host,  prior to executing the command.  Thus  this
status can only relate to the validity of the command and not any
command execution.
4.11 Flow of Overlapped Commands with Data Transfer From Host to
     Device
This  class  of commands includes commands such as  Mode  Select,
Write etc. Execution includes the transfer of some unknown number
of data bytes from the Host to the Device.
1.  The  host Polls for BSY=0, DRQ=0 then initializes the task file
    by  writing  the  required parameters  to  the  Features,  Byte
    Count,  and Drive/Head registers. The OVERLAP bit in the  ATAPI
    FEATURES Register mustshall  be set (1).
2.  The  host  writes the Packet Command code (A0h) to the  Command
    Register.
3.  The  Device sets BSY, before the next system read of the status
    register, and prepares for Command Packet transfer.
4.  When  the  Device  is ready to accept the Command  Packet,  the
    Device  sets  C/D- and clears RELEASE,  IO,  BSY  prior  to
    asserting  DRQ.  Some Devices will assert INTRQ  following  the
    assertion of DRQ.
5.  After detecting DRQ, the host writes the 12 bytes (6 words)  of
    Command to the Data Register.
6.  The  Device(1)  clears DRQ (when the 6th word is written),  (2)
    sets  BSY, (3) reads Features and Byte Count requested  by  the
    host system, (4) prepares for either Release of the ATA Bus  or
    Data Transfer.
7.  If  the Device has NOT been previously commanded to generate an
    interrupt  after accepting the Packet Command Data, the  Device
    may  optionally  not  release the ATA Bus.  In  this  case  the
    device  must  moves directly from accepting the Command  Packet
    Data  to  Data Transfer (Step 12. below) with DRQ=1,  C/D-=0
    and IO = 0. This must also be done within the time reported  by
    the  Identify Drive Data Command Data. If the Device  has  been
    commanded to generate an interrupt after processing the  Packet
    Command, the Device shall always release the ATA Bus.
8.  The  Device  (1)  sets  the RELEASE bit  in  the  ATAPI  STATUS
    Register, (2) clears IO, C/D-, DRQ, (3) clears BSY.  If  the
    Device  has been previously commanded to generate an  interrupt
    when  releasing  the ATA Bus after receiving a Packet  Command,
    the Device shall set INTRQ (1).
9.  Released State.
    At this point the Host is free to select the other Device and
    Issue Commands.
    When the Host is Not issuing new commands to the Non
    Overlapped Device it  should select the Overlap Device
    allowing it to interrupt. To promote fairness for overlapping
    devices which release the ATA bus, the host should select the
    overlapped device between each command issued to the non
    overlapped device.
10. When the Device is ready to accept data, the Device (1) sets
    the  DSCSERVICE Bit in the ATAPI STATUS Register, (2) sets DRQ,
    (3) sets INTRQ.
11. After detecting INTRQ, the Host shall read the ATAPI STATUS
    Register  to  determine if the selected  device  is  requesting
    service.  If there is an overlapped command active on the  non-
    selected  device, the Host shall change the DRV  Bit  and  read
    the  ATAPI  STATUS  Register to determine if  service  is  also
    needed  on  the  non-selected Device. When the  state  of  both
    Device's  SERVICE bits are known the Host shall select  one  of
    the  Devices, that is requesting service, and issue the Service
    (A2h)  Command.  The Host shall employ some fairness  technique
    in choosing which Device will be serviced.
12. When  the Device receives the SERVICE Command or if  moving
    directly from Packet Command Data to Data Transfer, the  Device
    (1)  places  the  byte  count of the data  available  into  the
    Cylinder  High  and  Low  Registers, (2)  clears  SERVICE,  (3)
    clears  IO  and C/D-, (4) sets DRQ and clears  BSY.  If  the
    Device  has been previously commanded to generate an  interrupt
    when done processing the SERVICE Command, the Device shall  set
    INTRQ (1).
13. After detecting INTRQ or that BSY has been cleared, the host
    reads  the DRQ bit in the Status Register to determine  how  it
    will  proceeds with the command. If DRQ= 0 then the device  has
    either  released  the  ATA Bus or terminated  the  command.  If
    DRQ=1  then  the  host shall write the data  (number  of  bytes
    specified  in  the Cylinder High/ Low Registers) via  the  Data
    Register.  In response to the Status Register being  read,  the
    Device negates INTRQ for both cases.
14. If no more data is to be transferred, proceed to step 17.
15. The  Device  (1) leaves BSY cleared, (2)  clears  DRQ.  The
    RELEASE  Bit shall have been set at the beginning of  the  last
    data  transfer.  The IO and C/D- bits shall  remain  in  the
    same  state  as  for a normal data transfer, this distinguishes
    the Release from a Status state.
16. The above sequence is repeated from step 9.
17. The Device clears DRQ and sets BSY.
18. The  Device  places the completion status into  the  Status
    Register,  sets  C/D-, IO, DRDY, clears  RELEASE,  BSY,  and
    DRQ, prior to asserting INTRQ.
19. After  detecting INTRQ & DRQ=0, the host reads  the  Status
    Register  and if necessary, the Error Register for the  command
    completion status. If the Host detects that the RELEASE Bit  or
    that  both  IO  and C/D- are not set this is  not  a  status
    state but a release state and should proceed accordingly.


Figure 7 - Packet Command with PIO Data In from Host

4.12 Flow of Overlapped Commands with Data Transfer From Device to
Host
This class includes commands such as Inquiry, Read etc. Execution
includes  the transfer of some unknown number of data bytes  from
the Device to the host.
1.  The  host Polls for BSY=0, DRQ=0 then initializes the task file
    by  writing  the  required parameters  to  the  Features,  Byte
    Count,  and Drive/Head registers. The OVERLAP bit in the  ATAPI
    FEATURES Register shallmust be set (1).
2.  The  host  writes the Packet Command code (A0h) to the  Command
    Register.
3.  The  Device sets BSY, before the next system read of the status
    register, and prepares for Command Packet transfer.
4.  When  the  Device  is ready to accept the Command  Packet,  the
    Device  sets  C/D-  and clears RELEASE,  IO,  BSY  prior  to
    asserting  DRQ.  Some Devices will assert INTRQ  following  the
    assertion of DRQ.
5.  After detecting DRQ, the host writes the 12 bytes (6 words)  of
    Command to the Data Register.
6.  The  Device(1)  clears DRQ (when the 6th word is written),  (2)
    sets  BSY, (3) reads Features and Byte Count requested  by  the
    host system, (4) prepares for either Release of the ATA Bus  or
    Data Transfer.
7.  If  the Device has NOT been previously commanded to generate an
    interrupt  after accepting the Packet Command Data, the  Device
    may  optionally  not  release the ATA Bus.  In  this  case  the
    device  shall  move directly from accepting the Command  Packet
    Data  to  Data Transfer (Step 12. below) with DRQ=1,  C/D-=0
    and  IO  =  0.  This  shallmust also be done  within  the  time
    reported  by  the  Identify Drive Data  Command  Data.  If  the
    Device  has  been  commanded  to generate  an  interrupt  after
    processing the Packet Command, the Device shall always  release
    the ATA Bus.
8.  The  Device  (1)  sets  the RELEASE bit  in  the  ATAPI  STATUS
    Register, (2) clears IO, C/D-, DRQ, (3) clears BSY.  If  the
    Device  has been previously commanded to generate an  interrupt
    when  releasing  the ATA Bus after receiving a Packet  Command,
    the Device shall set INTRQ (1).
9.  Released State.
    At  this point the Host is free to select the other Device  and
    Issue  Commands. When the Host is Not using the Non  Overlapped
    Device it selects the Overlap Device allowing it to interrupt.
10. When the Device is ready to accept data, the Device (1) sets
    the  DSCSERVICE Bit in the ATAPI STATUS Register, (2) sets DRQ,
    (3) sets INTRQ.
11. After detecting INTRQ, the Host shall read the ATAPI STATUS
    Register  to  determine if the selected  device  is  requesting
    service.  If there is an overlapped command active on the  non-
    selected  device, the Host shall change the DRV  Bit  and  read
    the  ATAPI  STATUS  Register to determine if  service  is  also
    needed  on  the  non-selected Device. When the  state  of  both
    Device's  DSCSERVICE bits are known the Host shall  select  one
    of  the  Devices,  that is requesting service,  and  issue  the
    Service  (A2h)  Command. The Host shall  employ  some  fairness
    technique in choosing which Device will isbe serviced.
12. When  the Device receives the Service Command or if  moving
    directly from Packet Command Data to Data Transfer, the  Device
    (1)  places  the  byte  count of the data  available  into  the
    Cylinder  High  and Low Registers, (2) clears  DSCSERVICE,  (3)
    clears  IO  and C/D-, (4) sets DRQ and clears  BSY.  If  the
    Device  has been previously commanded to generate an  interrupt
    when done processing the Service Command, the Device shall  set
    INTRQ (1).
13. After detecting INTRQ or that BSY has been cleared, the host
    reads  the DRQ bit in the Status Register to determine  how  it
    will  proceeds with the command. If DRQ= 0 then the device  has
    either  released  the  ATA Bus or terminated  the  command.  If
    DRQ=1  then  the  host  shall read the data  (number  of  bytes
    specified  in  the Cylinder High/ Low Registers) via  the  Data
    Register.  In response to the Status Register being  read,  the
    Device negates INTRQ for both cases.
14. If no more data is to be transferred, proceed to step 17.
15. The  Device  (1) leaves BSY cleared, (2)  clears  DRQ.  The
    RELEASE  Bit shall have been set at the beginning of  the  last
    data  transfer.  The IO and C/D- bits shall  remain  in  the
    same  state  as  for a normal data transfer, this distinguishes
    the Release from a Status state.
16. The above sequence is repeated from step 9.
17. The Device clears DRQ and sets BSY.
18. The  Device  places the completion status into  the  Status
    Register,  sets  C/D-, IO, DRDY, clears  RELEASE,  BSY,  and
    DRQ, prior to asserting INTRQ.
19. After  detecting INTRQ & DRQ=0, the host reads  the  Status
    Register  and if necessary, the Error Register for the  command
    completion status. If the Host detects that the RELEASE Bit  or
    that  both  IO  and C/D- are not set this is  not  a  status
    state but a release state and should proceed accordingly.

The DRQ signal is used by the device to indicate when it is ready
to  transfer data, and is cleared after (during) the last byte of
data  to be transferred. This applies for both Command Packet  as
well as normal read/write data.
The RELEASE Bit is used to signal that the Drive has released the
ATA Bus. The RELEASE Bit shall be qualified by the host with both
BSY  and DRQ cleared. If either BSY or DRQ is set, then the value
in the RELEASE bit is undefined.





Figure 8 - Packet Command with PIO Data In to Host



4.13  Flow of Non-data Commands
This  class  includes commands such as Seek,  etc.  Execution  of
these commands involves no data transfer.
1. The  host Polls for BSY=0, DRQ=0 then initializes the task file
   by  writing  the  required parameters  to  the  Features,  Byte
   Count, and Drive/Head registers.
2. The  host  writes the Packet Command code (A0h) to the  Command
   Register.
3. The Device sets BSY and prepares for Command Packet transfer.
4. When  the  Device  is ready to accept the Command  Packet,  the
   Device sets C/D- and clears IO, BSY prior to asserting  DRQ.
   Some Devices will assert INTRQ following the assertion of DRQ.
5. After detecting DRQ, the host writes the 12 bytes (6 words)  of
   Command to the Data Register.
6. The Device sets BSY and executes the command.
7. When  the  Device  is ready to present the status,  the  Device
   places  the  completion status into the  Status  Register,  and
   sets  IO, C/D-, DRDY and clears BSY, DRQ, prior to asserting
   INTRQ.
8. After  detecting INTRQ, the host reads the Status Resister for
   the command completion status.

4.14 Timing of Non-Overlap Packet Command

  
  
  
  Figure 9 - Timing of Command Packet Transfer
  
4.15 Timing of Non-Overlap Data and Status Transfer


  
  
  
  Figure 10 - Timing of Data and Status Transfer

4.16 Control Signal Timing Requirements and Relationships
The  order  that the signals change shall adhere to the following
conditions:
1. Upon  receiving the A0h ATAPI Packet Command the  Device  shall
   have  BSY  asserted until the next host access  of  the  Status
   Register  where  the  device can guarantee that  C/D-=1  and
   IO=0.
2. The  Device shall not assert DRQ until C/D- and IO are valid
   for  the  command  or  data packet to be  transferred  and  the
   device is ready to perform that transfer.
3. DRQ may be set before or after BSY has been deasserted.
4. The  Device  shall  clear BSY and set DRQ within  the  time-out
   specified by the CMD DRQ Type.
5. Devices  reporting CMD DRQ Type Accelerated  shall  de-assert
   DRQ  within  5us of the last word transferred for a command  or
   data packet.
6. Devices  reporting  a  CMD  DRQ Type other  than  Accelerated
   shall  de-assert  DRQ,  before asserting INTRQ,  following  the
   last word transferred for a command or data packet.

Implementer's Note:  Early ATAPI Devices reporting CMD DRQ  Types
other  than Accelerated may not be able to de-assert DRQ before
the  next  INTRQ. Host systems should therefore  wait  until  the
device asserts INTRQ before testing DRQ following the transfer of
the last data word in a command or data packet.



5.   ATAPI Transport Mechanism
The  Transport  Mechanism provides for the  hardware  support  to
connect the host computer to the Peripheral.


5.1  Reset Conditions
There  are three types of Reset Condition to which ATAPI  Devices
shall respond:
  -  Power  On Reset or Hardware Reset: the Device executes  a
     series  of electrical circuitry diagnostics and sets default
     values,  as  well  as executing the Master Slave  Diagnostic
     Protocol.
  -  ATAPI Soft Reset: ATAPI Devices shall reset the interface
     circuitry according to the Set Features requirement upon receipt
     of the ATAPI Soft Reset Command.
  -  ATA SRST: ATAPI Devices shall provide the normal ATA PDIAG/
     DASP  sequence and initialize the task file with  the  ATAPI
     signature upon detection of SRST. No actual reset of the ATAPI
     device will occur, no commands that may be active arewill be
     aborted or stopped.
The  Reset  Conditions above are listed in order  of  precedence.
That  is,  Power On or Hardware Reset shall take precedence  over
ATAPI  Soft  Reset, which shall take precedence  over  ATA  SRST,
which shall take precedence over all other conditions.

5.1.1     Power On or Hardware Reset
Each ATAPI Device, as it is powered on, shall perform appropriate
internal reset operations, and internal test operations.
ATAPI Devices upon detection of reset, shall:
1. Clear all Commands and I/O operations in progress.
2. Return to Devices default configuration.
3. Perform the DASP / PDIAG sequence.
4. Return  any  ATAPI Device operating modes to their  appropriate
   initial  conditions, similar to those conditions that would  be
   found  after  a  normal power-on reset. MODE SELECT  conditions
   shall  be  restored to their last saved values if saved  values
   have  been  established. MODE SELECT conditions  for  which  no
   values  have  been  saved shall be returned  to  their  default
   values.
5. Initialize  the Task File Registers as follows: Status  =  00h,
   Error  = 01h, Sector Count = 01h, Sector Number = 01h, Cylinder
   Low  =  14h, Cylinder High =EBh and Drive/Head = 00h.  A  value
   other  than  00 in the status register prior to the receipt  of
   the  first  ATAPI Command Packet from the host  may  cause  the
   ATAPI  Device to be incorrectly identified by the  host  as  an
   ATA  compatible  disk  drive. BSY =  0,  following  any  Reset,
   indicates  to the Host that the registers within the Task  File
   have been initialized.


5.2  ATAPI Soft Reset Command and Protocol
ATA  specifies a mandatory software reset capability  because  it
provides  a  recovery mechanism from a class of errors/problems
that  are recoverable in no other way. The current DEVICE drivers
invoke  this  feature  at  some point  in  their  error  recovery
procedures today.
The  ATA  software reset mechanism, SRST, (bit 2  in  the  Device
Control  Register)  cannot  be used for  ATAPI  Devices,  because
resets  issued by the ATAPI driver would also reset any  attached
hard disk and vice versa.
For  a software reset to be useful, it shallmust be able to bring
the  drive's  microprocessor back from a busy or hung  condition,
allowing  issuance of a diagnostic or some other  command.  Since
the  microprocessor  is the destination of the  reset,  we  can't
depend  on  it as part of the reset path. Therefore,  ATAPI  Soft
Reset  shall  be  detected/decoded by  the  interface  controller
circuitry and be routed back to the microprocessor as a  hardware
signal.
Upon detection of the ATAPI Reset command, shall:
1. Set  BSY. When the reset sequence in the Device is complete the
   BSY  bit usy status willis be cleared. This iswill be the  only
   status returned to the host by the ATAPI Soft Reset command.
2. Initialize the task file with the same information as  after  a
   Power  On  Reset.  See  section 5.1.1 Power On or Hardware Reset
   on  page 39 for a description of the initialization sequence,
   with the exception of the DRV bit which shall remain unchanged.

5.3 ATAPI Implementation of ATA SRST
The  ATA  software reset mechanism, SRST, (bit 2  in  the  Device
Control  Register)  cannot  be used for  ATAPI  Devices,  because
resets  issued by the ATAPI driver would also reset any  attached
hard  disk and vice versa. To solve this ATAPI defines  an  ATAPI
Soft  Reset  command using a reserved ATA opcode which  could  be
decoded by the interface controller hardware.
To maintain Master / Slave compatibility with ATA disk drives and
prevent detection of ATAPI Devices by non ATAPI-aware BIOS, ATAPI
Devices  shall  implement the following upon receipt  of  an  ATA
SRST:
1. Follow  the  SRST Sequence defined in Error! Reference  source
   not  found. on page Error! Bookmark not defined., and not  the
   sequences shown in the ATA Specification.
2. Initialize  the  task file with Status = 00h or  10h,  Error  =
   01h,  Sector Count = 01h, Sector Number = 01h, Cylinder  Low  =
   14h, Cylinder High =EBh and Drive/Head = 00h
3. The  functionality of the DRDY and DSC bits shall  be  restored
   on the first command following an SRST.
4. Continue executing commands or play operations.
5. Leave Mode settings or Set Feature settings unchanged.
6. If  a  selected ATAPI Device detects SRST while its own DRQ  or
   BSY is set (1), then the command in progress shall be stopped.



5.4 Physical Connection
The  ATAPI  Devices  are selected by the  Address  field  in  the
DeviceSelect  Register. When the ATAPI Device is  attached  along
with  an ATA Mass Storage Device, the ATAPI Device should be  set
as Device 1 and respond as a Slave.

Table 6 - Preferred Device Connection

     Primary Cable           Secondary Cable            
  Drive 0     Drive 1      Drive 0     Drive 1   Notes

    ATA                                          Normal, no
                                                 ATAPI
    ATA                     ATAPI                Disk and ATAPI
                                                 for enhanced
                                                 IDE system
    ATA        ATAPI                             Legacy IDE
                                                 System with
                                                 only one cable
    ATA                     ATAPI       ATAPI    Enhanced IDE
                                                 with CD-ROM
                                                 and a tape



5.5  Single Device Configurations
There  can be either one or two drives attached to the ATA Cable,
and  thus four configurations are possible. Even though there are
four possible configurations, only three of them are recommended.
An   ATAPI   Peripheral  shall  detect  each   of   these   three
configurations  and  respond according  to  Table 7 -  Shadow
Registers on page 42.
There  are  configurations where there may be only one Master  or
Slave  present  on the cable. In this case there  is  will  be  a
Shadowing  of  the registers for the non-existent  device.  The
following table shows the actions to take.

          Table 7 - Shadow Registers

Jumper ->  DRV Bit  Configuration  Action

 Master       0     Don't Care     Drive Bus
              1     Slave          Float Bus
                    Present
              1     Slave Not      Shadow
                    Present
 Slave        0     Master         Float Bus
                    Present
              0     Master Not     This is not a
                    Present        recommended
                                   configuration.
                                   Float Bus
              1     Don't Care     Drive Bus
 CSEL=M               Same as Master DRV=0
                      Same as Master DRV=1
 CSEL=S               Same as Master DRV=0
                      Same as Master DRV=1

		      
  Table 8 - Shadowing for Single Device Configurations

       Drive 0         Drive 1 (Non-existent Slave) Use of
Register Description              the Register

                  Control Block Registers

Alternate ATAPI       This may be either be a complete
Status                duplicate of the Device 0 Status
                      (Shadowed) or Some of the bits are
                      explicitly for Device 1 (e.g. CHECK)
Device Control        Writing to this register writes to
                      Device 0's Device Control Register

                  Command Block Register
		  
Data                  Should not be used for the non-
                      existent slave
ATAPI Error Register  This may be either be a complete
                      duplicate of the Device 0 ATAPI Error
                      Register or the Register is
                      explicitly for Device 1 (Not
                      Shadowed)
ATAPI Features        Writing to this register writes to
                      Device 0's ATAPI Features Register
ATAPI Interrupt       
Reason Register
ATAPI Byte Count      These are an exact duplicate of
Register (bits 0-7)   Device 0's register. Implementer's
                      Note: As the Signature is placed in
                      these Registers, both Device 0, and
                      the non-existent Device 1   will have
                      an ATAPI Signature after a reset
                      condition. To detect that Device 1
                      does not exist will requires a
                      command be issued to Device 1 and
                      detecting the Abort.
ATAPI Byte Count      
Register (bits 8-15)
Device Select         Writing to this register writes to
                      Device 0's Device Select Register
ATAPI Status          This may be either be a complete
                      duplicate of the Device 0 Status
                      (Shadowed) or Some of the bits are
                      explicitly for Device 1 (e.g. CHECK)
ATA Command           Commands to Device 1 are will be
                      aborted. Implementer's Note: The
                      Error bit will isneed to be set to
                      abort a command to Device 1, if the
                      Status and Alternate Status Registers
                      are complete shadows of Device 0's
                      Register, changing the DRV bit and
                      reading the Status Register will also
                      show an error condition that does not
                      exist. It is recommended that the
                      ERROR bit not be shadowed, but a
                      separate bit for the non-existent
                      drive 1.
                                
Implementer's  Note:  Device 0 (Master) is able to  determine  if
Device  1  (Slave)  is present, but Device 1 can't  determine  if
Device  0  is present. Device 1 will sees the Slave drive  assert
the    DASP   signal   during   the   Reset   procedure,    which
indicatingindicates that the Slave is present.

5.6  Register Mapping
Communication  to  or from the Devices is through  I/O  Registers
that  route  the  input  or  output data  to  or  from  registers
(selected)  by  a code on signals from the host (CS1FX-,  CS3FX-,
DA2, DA1, DA0, DIOR- and DIOW-).


5.7  ATAPI Register Map  ( PACKETp (Packet / SERVICE Commands )
Logic conventions are:   A = signal asserted, N = signal negated,
x = does not matter which it is.

Table 9 - I/O Port Functions/Selection Address (Compatibility Model)

         Addresses                        Functions

 CS1FX   CS3FX  DA2 DA1  DA0    Read (DIOR-)     Write (DIOW-)

                                   Control Block Registers

   N       A     0   0    0    Floppy A Status       Unused
   N       A     0   0    1    Floppy B Status       Unused
   N       A     0   1    0        Unused        Floppy Digital
                                                     Output
   N       A     0   1    1   Floppy ID / Tape      RESERVED
                                   Control
   N       A     1   0    0   Floppy Controller     RESERVED
                                   Status
   N       A     1   0    1         Floppy Data Register
   N       A     1   1    0   Alternate ATAPI    Device Control
                                   Status
   N       A     1   1    1      Note(1)            Not Used

                                   Control Block Registers

   A       N     0   0    0                  Data
   A       N     0   0    1      ATAPI Error     ATAPI Features
                                  Register
   A       N     0   1    0    ATAPI Interrupt       Unused
                               Reason Register
   A       N     0   1    1       Reserved for SAM TAG Byte
   A       N     1   0    0   ATAPI Byte Count Register (bits 0-7)
   A       N     1   0    1   ATAPI Byte Count Register (bits 8-15)
   A       N     1   1    0             Device Select
   A       N     1   1    1   ATAPI Status      ATA Command

(1) This register is obsolete. It is recommended that a device not
respond to a read of this address. If a device does not respond,
it shall not drive the DDF signal.

1.This register is obsolete. It is recommended that a device  not
  respond  to  a  read  of this address. If  a  device  does  not
  respond, it shall not drive the DDF signal.


With  the exception of the Data Register, all the ATAPI registers
are  referenced  using  Byte (8 Bit) Read and  Writes.  The  Data
Register is ALWAYS referenced as a 16 bit word.

Table 10 - ATAPI Status Register (ATA Status Register)

D7     D6     D5      D4      D3     D2      D1     D0       
BSY    DRDY   DMA     DSCSER- DRQ    CORR    Reser- CHECK   Read
              READY   VICE                   ved

DRDY,  DSC, CORR and CHECK shall only be valid at the end of  the
completion of the command.

Bit 7 BSY           Busy is set whenever the drive has access
                    to the Command Block.
Bit 6 DRDY          Indicates that the drive is capable of
                    responding to an ATA command.
Bit 5 DMA READY     This bit indicates that the device is
                    ready to start a DMA data transfer. It is
                    used to communicate to the overlap capable
                    PCI DMA logic that this service interrupt
                    is going to transfer data via DMA. Note
                    that this bit is used for Device Fault
                    (DF) when Overlap operation is not enabled.
Bit 4 DSCSERVICE    This bit signals that the device is
                    requesting service or interrupt. It is set
                    when the interrupt is requested and does
                    not clear until the Service (A2h) command
                    is issued. Note that this bit is used for
                    the DSC function when the overlap function
                    is not enabled.
Bit 3 DRQ           Data Request - Indicates that the device
                    is ready to transfer a word or byte of
                    data between the host and the drive. The
                    information in the ATAPI Interrupt Reason
                    is alsowill also be valid during a Packet
                    Command when the DRQ is set.
Bit 2 CORR          Indicates if a Correctable Error occurred.
Bit 0 CHECK         Indicates that an error occurred during
                    execution of the previous command. The
                    bits in the Error Register contains the
                    Sense Key and Code.



Table 11 - ATAPI Error Register (ATA Error Register)

D7     D6     D5      D4     D3      D2     D1     D0       
    ATAPI Sense Key          MCR     ABRT   EOM    ILI     Read

Bits   ATAPI  Sense The ATAPI sense key areis defined in Annex
7-4    Key          C??.
Bit 3  MCR          Media Change Requested, is used and defined
                    as in the ATA Standard.
Bit 2  ABRT         Aborted Command, is used and defined as in
                    the ATA Standard.
Bit 1  EOM          End Of Media Detected.
Bit 0  ILI          Illegal Length Indication.

Table 12 - ATAPI Feature Register (ATA Feature Register)

D7     D6     D5      D4     D3      D2     D1      D0       
                Reserved                    OVERLAP DMA    Write
                                
Bit 7- Reserved     Reserved for future enhancement.
2
Bit 0  DMA          Any   data   for  the  Command   iswill   be
       (Optional)   transferred via the DMA interface. Note this
                    does not apply for the Command Packet.
Bit 1  OVERLAP      The  device  may release the ATA bus  before
       (Optional)   this  command has completed. Release of  the
                    ATA bus is at the discretion of the device.


Table 13 - ATAPI Byte Count Register (ATA Cylinder High/Low
Register)

D7      D6     D5      D4     D3     D2      D1     D0      
                Byte Count (Bits 0-7)                      R/W
                Byte Count (Bits 8-15)                     R/W

The Byte Count is used for PIO only. The count shall be set prior
to  the  issuance of the Packet Command. The count  contains  the
total transfer size for commands that transfer only one group  of
data  (e.g.  Mode  Sense  / Select, Inquiry)  For  commands  that
require  multiple DRQ Interrupts (e.g. Read, or Write) the  count
is  set  to  the desired transfer size. When any data  is  to  be
transferred,  the ATAPI Device will sets the Byte  Count  to  the
amount  of  data that the Host shall transfer and then issue  the
DRQ Interrupt. The contents of this register shall not change
during the DRQ.

Table 14 - ATAPI Interrupt Reason Register (ATA Sector Count
Register)

D7     D6     D5      D4     D3      D2      D1     D0       
           Reserved                  RELEASE IO     C/D-   Read

Bit 0  C/D-         Command or Data. When this bit is zero  then
                    the  information being transferred  is  user
                    data, when one then the data is Command.
Bit 1  IO           Direction for the Information transfer,
                    where in to the Host is indicated by a
                    value of one and out to the device is zero.

                    IO   DRQ  C/D-
                    0    1    1    Command - Ready to Accept
                                   Command Packet Bytes
                    1    1    1    Message (Future) - Ready to
                                   Send Message data to Host
                    1    1    0    Data To Host- Send command
                                   parameter data (e.g. Read
                                   Data) to the host
                    0    1    0    Data From Host - Receive
                                   command parameter data (e.g.
                                   Write Data) from the host
                    1    0    1    Status - Register contains
                                   Completion Status
Bit 2  RELEASE      Release indicates that the device has
                    released the ATA bus before completing the
                    command in progress.

Table 15  - ATAPI Device Select Register (ATA Drive / Head
Select Register)

D7     D6     D5      D4     D3      D2     D1     D0       
1      Reser- 1       DRV      Reserved for SAM LUN       R/W
       ved

Bit 4  DRV          This bit selects either Device 0 (DRV=0) or
                    1 (DRV=1).

Table 16 - ATAPI Device Control Register (ATA Device Control
Register)

D7     D6     D5      D4     D3      D2     D1     D0       
        Reserved             1       SRST   nIEM   0     Write

Bit 2  SRST          This  bit is the Software Reset. The  ATAPI
                     Device shall follow the reset sequence  for
                     SRST  defined  in 6.3 ATAPI Implementation
                     of  ATA  SRST on page 59. There is also  a
                     new  reset  capability  for  ATAPI  Devices
                     utilizing  a RESET COMMAND (see  5.2
                     ATAPI  Soft Reset Command and Protocol on   page
                     39).
Bit 1  nIEN          This bit enables/disables the interrupt  to
                     the  host.  When nIEN=0 and the  device  is
                     selected, INTRQ shall be enabled through  a
                     tri-state  buffer.  When  nIEN=1   or   the
                     device  is  not selected, the INTRQ  signal
                     shall be in a high impedance state

6. Annex A - BIOS and ATAPI Driver Compatibility
This  section discusses the ATA features and functions that shall
be  provided by the ATA Device to allow the BIOS and driver to be
content.


6.1  Reset Master/Slave Diagnostics Sequence
A  Reset  Master/Slave Diagnostics Sequence with  a  Good  Status
shall  be  provided or the BIOS shall not continue. When  the
ATAPI  device is the slave device, and it does not respond  after
the  Reset  or  Diagnostic Commands, the Master Device  shall
return  an Error Condition to the Host Computer and all shall
die.


6.2  SRST Initialization Sequence
The  SRST  bit in the ATAPI Device Control Register  (See  Table
16  -  ATAPI  Device  Control Register  (ATA  Device  Control
Register) on page 48) shall NOT be used by the ATAPI  Driver.
Instead the ATAPI Device Driver shall  reset  the ATAPI  Device
utilizing  the  ATAPI  Soft  Reset  command   (see 5.2 ATAPI Soft
Reset Command and Protocol on page 39). Resetting the ATAPI Device
using the ATA SRST would also reset any ATA hard drive attached,
and if there are separate Drivers  for  an  IDE and an ATAPI device,
each driver  would be resetting the others peripheral without the
other  driver  being aware  of  the  reset. ATAPI device should
wait until SRST is cleared by the host before completing their SRST
sequence. After  Receipt of an ATAPI Packet Command there are
several differences from the ATA Specification:
A  value  other  than  00h in the status register  prior  to  the
receipt of the first ATAPI Command Packet from the host may cause
ATAPI Devices to be incorrectly identified by pre-ATAPI host BIOS
as an ATA-compatible disk drive.
Initializing  the task file upon receipt of an SRST  should  work
since only immediate commands shall be executing when an  ATA
disk  driver  issues  an SRST. To prevent interruption  of  ATAPI
immediate  commands  which  have  not  finished  executing,   the
function  of  the  DSC  bit  (i.e.  command  complete)  shall  be
maintained.  On  a warm boot the BIOS and/or drivers  may  see  a
status  of  00h  or 10h, depending on whether  or  not  an  ATAPI
immediate command completed at the same time the system performed
the WARM BOOT.
The  signature  placed in the task file following an  SRST  shall
remain  until the ATAPI device receives its first ATAPI  command,
i.e.,  the  ATAPI device shall look NOT READY (DRDY=0).  This
shall  not  affect the ATAPI device drivers ability  to  send
ATAPI  commands to the ATAPI device since it is not  required  to
wait  for  DRDY=1.  However, it shall prevent  ATA-compatible
drivers, such as those performing power management, from  sending
commands  to an ATAPI device until the ATAPI device has  received
its  first  ATAPI command: ATAPI Packet Command,  ATAPI  Identify
Device, ATAPI Soft Reset.
ATAPI  drivers  wishing  to  use ATA  power  management  commands
shallmust  poll  DRDY and, if it is not set, they shallmust  also
look  at the Cylinder registers for the ATAPI signature.  If  the
signature is present, the ATAPI driver shallmust issue the  ATAPI
device an ATAPI command, re-enabling DRDY, before it can issue an
ATA Power management command. Operating systems wishing to use  a
common  ATA power management driver shallmust also be changed  to
perform  this detection and recovery sequence, if they intend  to
power-manage ATAPI devices.


6.3  Special Handling of ATA Read and Identify Drive Commands
ATAPI drivers shall not issue SRST since it may corrupt the state
of  ATA IDE drives sharing the same cable. Instead, ATAPI drivers
shall  use  the ATAPI Soft RESET command to initialize  an  ATAPI
device. Note that ATAPI commands shall not be issued to a  device
which  has  not  already been identified as an ATAPI  device.  In
order to provide ATAPI drivers with the ability to force a device
to  initialize its ATAPI signature (Cylinder High = EBh, Cylinder
Low = 14h) without issuing an SRST, ATAPI devices shall abort the
ATA Read and Identify Drive commands and initialize the task file
with the ATAPI signature before clearing BSY.


6.4  ATAPI aware BIOS and Driver Considerations
Pre-ATAPI  BIOS shall not detect or configure ATAPI  devices.
Some of these BIOS are capable of configuring ATA hard disks  for
ATA  Mode  3 IOCHRDY operation. This places a special  burden  on
ATAPI  drivers  to  detect the presence of any  ATA  disk  drives
sharing the same port address and configure the ATAPI device  for
a compatible mode of operation.
Note  that  a  special  IDE port configuration  driver  must  be,
provided  by the IDE card manufacturer, is necessary to configure
the  cards proprietary IDE configuration control registers. These
proprietary  IDE card drivers should be loaded before  the  ATAPI
driver.
During  ATAPI  device detection, ATAPI device drivers  or  ATAPI-
aware  BIOS should verify that Status=00h (Not BSY, Not RDY)  and
that the ATAPI signature Cylinder High = EBh, Cylinder Low =  14h
are  present. If an ATAPI device is detected, then issue an ATAPI
Identify Command to complete the ATAPI detection protocol and re-
enable  the task file (DRDY=1). If the device is ready to  accept
an ATA command, but no ATAPI signature is detected, then issue an
ATA  Read  or Identify Drive command to the device to  force  the
ATAPI device to initialize its signature. Then wait for BSY=0 and
re-verify the presence of the ATAPI signature. If there is  still
no ATAPI signature present, do not configure the device.
ATAPI-aware  BIOS  and drivers should give special  attention  to
managing  configurations where ATAPI drivers share  an  IDE  port
address  (Cable) with ATA IDE drives and their drivers.  ATA  IDE
drivers  frequently issue SRSTs to manage errors thereby  causing
ATAPI devices to clear DRDY as part of their SRST ATAPI signature
initialization sequence. If the ATAPI driver already  knows  that
the  device  it wishes to issue an ATAPI command to is  an  ATAPI
device, then it need not take special action since issuing any of
the ATAPI commands which do not require DRDY=1, shall restore
the  ATAPI device's ability to accept ATA commands. If,  however,
the  ATAPI  driver  wishes to issue an ATA command  to  an  ATAPI
device  which  has received an SRST from an ATA  IDE  driver,  it
should issue the ATAPI device an ATAPI Soft Reset to restore  the
ATAPI device's ability to accept ATA commands.
Note  that  Newer  BIOS  detect the presence  of  a  Device (see
3.3  ATA Compatibility on  page 6) by using the IDENTIFY DRIVE
command, but older BIOS use configuration information from outside
the IDE/ATA interface. It  has also been discovered that very old
BIOS may issue an  ATA READ  command  to  detect  the presence  of
an  ATA  IDE  drive.
Therefore,  the  ATA READ and IDENTIFY DRIVE  commands  shall  be
aborted  by ATAPI Devices. It has also been discovered that  some
BIOS look at the status register to detect the presence of an ATA
drive.
Implementer's  Note:   Implementers of ATAPI  drivers  which  are
intended  to  share a single cable with a disk  and  disk  driver
should  ensure that the device has completed any issued  commands
prior to changing the DRV bit.


6.5  Default Timing
ATAPI  devices  compatible with this specification shall  support
ATA  mode 3 timing without requiring the host system to configure
the  ATAPI device using any set features commands. ATAPI  devices
must therefore either be fast enough to always supply data at the
maximum  rate  allowed  by Mode 3 or the  ATAPI  device  must  be
shipped with IORDY enabled.
ATAPI   devices   shall   revert  to  their   default   interface
configuration on a Power On Reset or a Hardware Reset.
Implementer's Note:  A Non-Overlapped low-speed drive, Mode  0-2,
may  affect  system performance when sharing the same cable  with
hard  disk  drives  capable of mode 3  or  faster  data  transfer
timing.


6.6  Special Considerations for ATAPI

6.6.1     Redundant Command Functionality (Task File vs. Packet)
The  SCSI  Standard  has  provided some  commands  that  the  ATA
Standard  also  provides. It is the intent of  this  standard  to
allow  all the functionality to exist, by utilizing only  Command
Packets.  This allows existing SCSI like drivers to  continue  to
issue packets for all operation, and have some lower level driver
convert  them  to  the  ATAPI protocol. Unfortunately  there  are
existing  low  level drivers that would like to continue  to  use
some non data transfer ATA Task File commands.

6.6.1.1   ATAPI Identify Drive vs. Inquiry
The  ATAPI  IDENTIFY DRIVE command has information that  the  low
level   drivers   use   to   perform   ATA   interface   hardware
configuration.  Information  in the  Identify  Drive  data  shall
continue to look exactly as the ATA Identify Drive data does  for
compatibility reasons. As the information in the Inquiry  Command
cannot  be  returned  by the ATAPI Identify  Drive  Command,  the
Inquiry  Command  shall  be supported for  use  by  higher  level
drivers.

6.6.1.2   Initialize Drive Parameters and Set Features vs. Mode
Sense and Mode Select
The INITIALIZE DRIVE PARAMETERS command does not contain a method
to  provide non ATA device configuration information,  and  shall
not  be  used; instead, the Mode Select and Mode Sense  from  the
SCSI  standard shall be supported. The combination of Mode Select
and Set Features commands contain all the necessary functionality
and is most compatible with the existing BIOSes and OS Drivers.
