ATAPI PACKET Commands: Follow the Device's Data-Phase Contract
Trace an ATAPI PACKET request from device identification through CDB transfer, interrupt-reason checks, bounded data phases, and status recovery.
ATAPI extended the ATA transport so a device could receive SCSI-style command descriptor blocks over an ATA channel. A CD-ROM driver can therefore issue commands such as inquiry, capacity, read, and request sense without pretending that an optical device is a conventional ATA hard disk. The transport still has ATA task-file state, but the device’s command payload and data-phase behavior are packet-oriented.
The key distinction is between the ATA PACKET command and the command descriptor block (CDB) sent after the device accepts that command. Sending the first command does not mean the CDB has been accepted, and sending the CDB does not mean all requested data has arrived. The host must track the protocol’s phases, verify interrupt-reason/status fields, and honor the byte count reported for each data phase.
This low-level interface belongs in a device driver or a controlled diagnostic. For ordinary DOS CD-ROM access, use a compatible host adapter driver, CD-ROM device driver, and MSCDEX-compatible redirector. Direct port access from an application can conflict with those layers and bypass filesystem and cache ownership.
Identify a packet device before issuing a packet
Do not assume that every device attached to an ATA channel is ATAPI. Use the applicable ATA identify command and inspect the device signature and identify data as defined by the command-set standard. IDENTIFY PACKET DEVICE is used for devices implementing the packet feature set. The device’s identify data includes its supported packet length and capabilities; code must not assume a packet size that the target did not advertise.
Select the correct device, wait for a non-busy state using a bounded deadline, and prepare the task-file registers required by the device and command. The host then issues ATA command A0h (PACKET). The device may signal that it is ready to receive the packet using status and interrupt-reason information. Check the interface’s command/data and input/output indicators rather than assuming every interrupt means “data is ready.”
For a traditional 12-byte packet device, the host transfers six 16-bit words for the CDB. Some devices support a 16-byte packet. The length is part of the device contract, not a constant to copy into every driver. Build each CDB according to the SCSI command definition, zero reserved fields where required, and validate allocation lengths against the destination buffer before submission.
Separate the command phase from data phases
The request progresses through distinct states: command acceptance, packet-out transfer, optional data-in or data-out phases, and final status. The interrupt-reason register identifies whether the current phase is command or data and, for data, the transfer direction. During a data phase, the byte count is reported through the task-file count registers according to the ATAPI transport rules. Transfer exactly that amount, then wait for the next phase or completion.
issue PACKET command (A0h)
wait for not-busy packet request; validate interrupt reason
transfer exactly the advertised number of CDB bytes to the device
while a data phase is reported:
read phase direction and byte count
validate count <= remaining command buffer
transfer exactly count bytes in the indicated direction
wait for the next phase with a deadline
read final status and error details
The pseudocode intentionally omits task-file register setup and transport timing, which vary with controller and device. A production driver must follow the specific ATA/ATAPI standard revision, handle odd byte counts if the transport can report them, and make sure a word transfer does not overrun the supplied buffer. Do not round a byte count upward and blindly copy the extra byte into application memory.
BSY, DRQ, ERR, and interrupt reason must be interpreted together. If BSY is set, the other status fields may not describe the stable next phase. A request for host-to-device data differs from device-to-host data. A final status phase is not a data phase even if stale count registers still contain an earlier value. Clear any pending host-side state between commands and capture the final status and error register before resetting or retrying.
SCSI sense and retry policy
ATAPI transports SCSI command semantics; it does not eliminate them. A completed host transfer can end with a SCSI check condition. The driver must retrieve and decode sense data using the command and response format supported by the device, preserving the sense key and additional sense code/qualifier. “No media,” “unit attention,” “not ready,” and “illegal request” require different user messages and retry decisions.
Do not retry every failed command identically. A read may be retried after a transient unit-attention condition once the device has settled; a command with invalid fields will fail again until the CDB is corrected. A write-like optical command can alter media and should not be automatically repeated after an ambiguous timeout. Preserve the requested LBA, allocation length, CDB, phase sequence, and sense bytes in the diagnostic record.
Data buffers must remain valid until the device has completed the request. If the driver uses DMA for a later transport path, use the controller’s documented DMA mapping and alignment rules; do not assume a DOS buffer is physically contiguous or accessible to a bus master. For PIO, still validate segment boundaries and all byte-count arithmetic.
ATAPI is not a DOS drive letter
ATAPI discovery proves only that a packet device responded through the controller path. A DOS CD-ROM setup usually has several separate layers: an ATA/ATAPI host interface, a device driver that registers a DOS character/block-facing interface, and a redirector such as MSCDEX that provides drive-letter access. A BIOS may support booting from an optical disc without providing DOS runtime access to it.
Do not conflate the ATAPI CDB with an ASPI SRB. ATAPI is a command transport over an ATA channel; ASPI is a manager API that accepts an SRB and can route a SCSI CDB through a supported host-adapter manager. A particular adapter driver may implement both paths, but the interfaces have different discovery, buffer, status, and completion contracts. A BIOS boot service can read a bootable optical sector without offering a runtime packet interface to a DOS application.
For read-only media commands, validate allocation length before requesting data. Inquiry, capacity, and sense responses have defined formats, but a device can return fewer bytes than the allocation length. Keep bytes transferred separate from bytes requested, parse only complete fields, and preserve the raw response. If the device reports an unexpected phase byte count, stop and capture it rather than shifting the remainder into the next structure.
For large transfers, process each device-reported phase without assuming one interrupt corresponds to one sector or one application buffer. Keep host buffer length, CDB allocation length, and device-reported phase length as three distinct values. Never reuse the request buffer while the device still owns the operation.
This separation helps isolate failures. If IDENTIFY PACKET DEVICE fails, investigate controller ownership, device selection, cable, power, or emulation. If identify succeeds but a read packet fails, inspect CDB, phase direction, byte count, timeout, and sense data. If the low-level driver reports the disc but no drive letter appears, verify its load result and redirector configuration rather than changing the ATA protocol.
Bounded operation and test plan
Every wait for BSY to clear, DRQ to assert, a packet phase, and final completion needs a deadline. Use a timer that progresses in the environment; do not use an uncalibrated CPU loop. On timeout, preserve the state reached, mark the request outcome ambiguous where data may have moved, and use the standard reset/recovery path only after preventing a competing driver from using the channel.
Test an absent device, unsupported packet length, no-media condition, successful inquiry, successful read of a known sector, invalid CDB, check condition with sense data, short or unexpected transfer count, and timeout at each phase. Run against a read-only image or sacrificial emulator device. Verify the request never writes beyond the buffer, never loops without a deadline, and does not claim a DOS drive letter merely because the transport detected hardware.
For each accepted packet length, test both a short response and the maximum response your implementation permits. Verify the complete final status phase is drained before another CDB is submitted. Record packet bytes, task-file status, interrupt reason, reported byte count, and final sense data in a bounded trace buffer. A deterministic emulator image permits byte-for-byte comparison of returned logical blocks with a known source.
The reliable ATAPI driver is a protocol state machine layered on ATA task-file access and SCSI command semantics. The packet command starts the exchange; it does not finish it. Validate each phase, move only the advertised bytes, interpret sense, and keep DOS’s runtime driver and redirector responsibilities separate.
Related:
- ASPI on DOS: From the SCSI Manager Entry Point to a Completed Request
- How to Set Up CD-ROM Access on FreeDOS with MSCDEX
Sources: