OSDev.org

Lately I've been bothered by some questions regarding ATAPI. I would appreciate it if someone could shed some light on the situation. The ATAPI specification contains 'flows' that specify how to go about reading PIO data from the device and writing data to it. The specific section I'm curious about is section 5.8 (from the ATAPI CD-ROM Specification, page 25). According to the specification, as soon as data is available to the host and it has placed data in the cylinder low and cylinder high registers, it sends an IRQ (they call it 'INTRQ'). My question is actually if this only counts for actual PIO data reads (so reading data from sectors), or does it also count for commands such as 'Read Capacity', 'Start/Stop', etc. The other commands also involve sending a packet string and 'receiving data', but usually of a smaller size (for Read Capacity, that would be 8 bytes according to the spec). So do we wait for an IRQ there too? The spec seems a little vague about this situation.

I would also appreciate it if anyone could point out things that may behave strangely or I need to look out for. The reason is that I've had a working ATA/ATAPI implementation for quite some time now... except for that it only seems to work in the emulator. At first I could read anything from ATAPI devices (even finding the name of the device failed), but I seem to have reached a point where only the capacity of the device is wrong (but the sector size in 8-byte packet from Read Capacity is correct) and my ATAPI read commands seem to constantly get aborted (DRQ = 0 after receiving IRQ, it should be set to 1 according to the spec to indicate I may continue reading data).

EDIT: I also found in the ATAPI specification that some devices may need to read media for a command to be successfully executed. Does this imply that the ATAPI device itself will read the media and I only have to wait a bit longer before timing out to allow the drive to spin up, or does it mean that I explicitely have to start the motor or read from the device?

Thanks in advance,
Creature

I haven't implemented ATAPI on real hardware yet, so I don't have input on your questions for you. All I could talk about is how things "should" work.
But I'd like to ask two things: 1) what emulator are you using? 2) I am extremely interested in the concept of things that work/fail in emulators and fail/work on real hardware -- so if you end up finding the answer yourself, could you please let me know?

bewing wrote:I haven't implemented ATAPI on real hardware yet, so I don't have input on your questions for you. All I could talk about is how things "should" work.
But I'd like to ask two things: 1) what emulator are you using? 2) I am extremely interested in the concept of things that work/fail in emulators and fail/work on real hardware -- so if you end up finding the answer yourself, could you please let me know?

1) Well, I've tried Bochs, QEMU and VirtualBox as emulators and of course real hardware.

2) Bochs was the one that wasn't feeding me the proper Cylinder Low and Cylinder High values. A wiki code example in the ATAPI section just uses these 2 bytes to determine the type (instead of first checking if an error is returned). On real hardware, I noticed that the ATAPI device of my computer wasn't aborting the command, it simply continued, causing my OS to recognize it as PATA. When removing the check for abortion and simply using the Cylinder Low and High values, it also didn't work yet because the values were random (I didn't recognize them, they weren't PATA, SATA, PATAPI or SATAPI). On Bochs, this caused my OS to only recognize an ATAPI device (so the PATA device apparently didn't send the right cylinder values). QEMU doesn't complain at all (both the PATA and (P)ATAPI device were recognized). I'm not really sure what VirtualBox did, but I believe the response was the same as Bochs (no PATA device found).

After this, I tried 'flushing' values by writing zeroes to the sector count, sector number, cylinder low and cylinder high values just before executing 0xEC, and voila, the proper cylinder values were sent by the hardware. Bochs, QEMU, VirtualBox and real hardware all sent me the correct Cylinder Low and High values. I've also discovered that software resetting both ATA adapters (so before executing 0xEC and selecting one of the two buses on the adapter) instead of 'flushing' the values makes Bochs respond correctly (PATA and PATAPI are detected), but it completely fails on real hardware ((P)ATAPI device is detected as PATA and the PATA hard drive is not detected at all).

These are mostly my conclusions up until now. It could be possible that my code is just wrong or I've forgotten something, but I've tried to use the wiki ATA PIO Mode article as reference for detecting ATA devices and the ATAPI specification for reading. I've also checked out other OS', but I couldn't see anything horribly wrong with my code while glancing through their code.

I suspect that 'flushing' may be the correct approach, then. Don't forget, *I* am the one who wrote the ATAPI article on the wiki (because it needed to be written) -- but as I said, I've never written any ATAPI code yet. So don't trust that wiki article too much.
I also wrote the ATA PIO mode article, but that one was extensively compared with real hardware and emulators to ensure very high accuracy -- except on the part about ATAPI doing an "abort" error on an identify command, of course.