OSDev.org

Hi,
I'm writing a bootloader for windows. In order to perform i/o with the HDD in real mode code, SATA AHCI is not an easy option, so I'm relying on IDE emulation modes. ATA commands works fine and for R/W i'm using BIOS int 13h.
In this Q965 chipset mobo I can set the emulation mode to "Compatible" or "Enhanced". I believe it shouldn't make any difference in how my code works, but I'm having some weird behavior. Works perfectly in virtual machines and other chipsets (tested in motherboards equipped with Q57 and Q77) and in "Compatible" mode in this Q965 (actually tested in 2 distinct machines with the same motherboard). When set to "Enhanced", a specific int13h read routine call returns with no error codes, but writes everything zeroed in the buffer.
It stops behaving like this if i disconnect the CD Drive (or disable it in cmos setup). Could it be a bad implementation of IDE emulation? Anything known to this chipset?

In the same bootloader, when loaded to a Q67 machine, the situations is inverse. "Enhanced" mode works just fine (ATA port i/o and int13h read/write). But in "Compatible" mode, port i/o with the emulated controllers returns FFh in every register.

Hi,

brktNTC wrote:ATA commands works fine and for R/W i'm using BIOS int 13h.

I find that sentence relatively horrifying all by itself.

Either the BIOS has ownership of the device (and your software shouldn't touch it directly), or your software has ownership of the device (and BIOS shouldn't be allowed to touch it); or you end up with tangled mess of nightmares where BIOS and your software take turns in ruining the state of the device for each other.


Cheers,

Brendan

I don't know anything about the chipset you mention, but as Brendan said, you shouldn't access hardware yourself at the same the BIOS accesses the hardware. Either you write an IDE/SATA driver and use only that, or use only the BIOS without ever touching the device's registers.

For some real hardware, it wouldn't even be possible to use the BIOS for SATA after your SATA driver has loaded at all, because some SATA controllers (AHCI) implement a "handoff" register which takes the ownership from the BIOS, and basically tells the controller that your driver owns it and not the BIOS. The AHCI spec has more information on this, if you're interested.