You're using the AT version of XT-IDE BIOS ?

Yes, I'm using the latest official AT version(https://storage.googleapis.com/google-code-ar … 2.0.0_beta3.zip, file ide_at.bin. It has a copy of the XT configuration(loaded from the XT ROM(which works), then flashed the AT ROM(By booting using the working XT ROM on the AT emulation(80286), then loading the ide_at.bin file in the xtidexfg application, loading the settings from the XT ROM(which is used to boot), then flashing the new ROM with settings back to the emulated flash ROM(8KB AT28C64B chip, which is the default). Just don't forget to set the protection to disable to make it flash properly(otherwise it will fail).

grab the latest bios from here: http://www.xtideuniversalbios.org/binaries/ , maybe it helps

One strange thing is currently occurring: it does detect the secondary controller(at base ports 0x170/0x376) which are emulated ATAPI-4 CD-ROM drives, but doesn't detect the primary controller(at 0x1F0/0x3F6) which handles the hard drives. It's giving me Base(cmd block) address 0x170 and Control block address 0x370. I'm using the addresses from the osdev wiki(http://wiki.osdev.org/PCI_IDE_Controller). That is what it's giving me when I choose "Auto configure" to make it autodetect the hardware.

Just found a little problem with the ATA/ATAPI status register: entering a new command phase(e.g. no command is running, controller is waiting for a new command to be specified without any pending error handling) will now cause:
- Busy bit to become 0.
- Drive ready bit becoming zero after drive select, 1 when finished selecting.
- Drive write bit fault to become 0.
- Data request ready bit to become 0(the device isn't waiting for data to be read/written from the data port).

This causes it to find both the hard disk(Primary master/slave) and CD-ROM(Secondary master/slave), although it ends up with a not found message when trying to boot the hard disk(saying boot sector not found)?
Edit: The XT version works without problems. Now checking the AT version(used on the Compaq Deskpro 386 emulation as well).
Edit: The AT and Compaq emulation now gives me a "Boot sector not found" message and proceeds to boot the floppy disk(which hangs the emulation).

I've found a few little problems with the EEPROM emulation I am using (Atmel AT28C64B 64K flash ROM emulation requiring a ROM of at least 5462 bytes to make the SDP commands work, otherwise it acts like a simple ROM instead of a flash ROM(effectively never being able to finish the SDP command, because not enough bytes can be addressed)). Besides writes to the flash chip's reserved addresses(addresses 1555h and 0AAAh) ignoring writes when entering (part of) a SDP enable/disable sequence, it was also enabling SDP directly after receiving the command completely, instead of waiting 10ms after the last byte written(as far as I understand from the manual) to enable the SDP. It's now properly enabling a timeout when the enable SDP command is written(starting the timeout) or writing data to the flash ROM(which resets the counter(that's counting downwards) to 10ms). Once the counter times out(becomes 0 or lower), it will enable the SDP. The only difference with a real chip being that it doesn't enforce a 64-byte limit after the enable SDP command is issued(probably because of internal buffers inside the chip being full).

After testing it with the newest data protection handling(SDP commands according to the manual), it crashes, because byte 0xAAA contains 0x55, failing the BIOS checksum? Don't the writes to the EEPROM get written normally(the documentation from Atmel doesn't say anything about it)? The 0xAAA address should just write normally, due to write protection being off? But instead it's written with value 0x55(instead of the correctly flashed value that was written previously)?

I've just modified the emulation to apply the flash writes correctly. Now it works both in the way the documentation says, as well as working with the XT-IDE configurator. The ROMs end up intact(without any missing data at address 0xAAA/0x1555. The AT BIOS gets a lot of zeroed out data appended, though(to the ide_at.bin file). Without making modifications to the settings(which still detect 2 drives instead of the valid 1 drive installed(it also takes the CD-ROM drives as harddisks?)), the flash memory now gets updated correctly.

It now properly flashes the BIOS(although I still need to manually adjust it to use only the first controller(it's still detecting the CD-ROM drives as harddisks)). Now it ends up at some infinite loop, waiting for an IRQ0 tick count to be set, which doesn't update it seems?

I've managed to get the XT-IDE BIOS AT version to properly load the boot sectory, but after that it looks like some rogue reads

XT(correctly booting):
CHS-based addressing when bit 30 is set(starts with A most of the time).

XT:
A00000001=0
A10000001=3F
A80000031=228
A90000012=248
A90000013=249
A90000014=24A
248
276
40
110c8
110eb
44
0
3f
40

AT(terminating with disk not bootable error):
AT:
0
1
3f
40
20028
20029

Or could that be a CHS vs LBA addressing problem?

The Compaq BIOS now completely refuses to boot. It seems to be waiting for some interrupt, waiting for bit 7 at 0040:00A0 to set?

Looking at some documentation, it looks like it's waiting for an interrupt from the RTC?

http://stanislavs.org/helppc/bios_data_area.html says:

140:A0	byte	RTC wait function flag
2
3		|7|6|5|4|3|2|1|0| INT 15,86 RTC wait function flag
4		 | | | | | | | `--- 1= wait pending
5		 | `-------------- not used
6		 `--------------- 1=INT 15,86 wait time elapsed

It's simply looping until the bit is set.

After looking at the BIOS i/o, it doesn't seem to ever set the register A of the CMOS to any value other than 0? That effectively disables all interrupts(since it doesn't count)? I've curcumvented this by loading a value of (2<<4)|6 when initializing the RAM(when not saved already). Thus it's automatically running on the Compaq. I've also implemented a proper status D register(which sets it's byte, after it's read, to 0x80, 0x00 is only read when read for the first time(CMOS is cleared or initiliazed)).

Looking at the disassembly of the BIOS ROM on the pcjs project, it looks like the BIOS never ever sets the 0xA register, except when reading it to check for bit 7 to be set?

After a bit of tinkering with the hard disk commands(in particular, fixing the Set multiple mode command and drive parameters that are based on it). It now properly starts to boot MS-DOS, ending up reading IO.SYS(3 sectors afaik), then crashing with an #UD(which loops infinitely to the faulting instruction) at 0070:0200.

Edit: Looking at what it's reading, I see it reading up until the first sector of IO.SYS, but instead of the next sectors(which are correctly addressed in the hard disk), it reads a buffer filled with set bits as the second sector of IO.SYS, while the third sector contains garbage as well. So something is wrong with the disk image itself(the basic emulation works without problems).

Edit: Restoring an old backup of the hard disk image, with the information intact, makes it properly boot again.