Well, the 512MB limitation was imposed by the BIOS, not the IDE controller.
The 16-head limitation is caused by the IDE controller, however in CHS mode the sector field is 8 bits and the track field 16 bits.

So in CHS the drive could max out at C/H/S 65536/16/256 but then you would have problems with the INT 13h interface, so drives limit the sectors per track at 63. Finally, tracks are limited to 16384 for large drives for some reason.

I do know from experience that some REALLY OLD ide hard disks only decode 10 bits of the track field, but you'd have to go way back to ancient 50MB and 100MB drives to see that at all.

IDE test program:
- CD-ROM read testing has been thoroughly tested and rewritten to work properly with all CD/DVD-ROM drives available for testing. The CD-ROM read test is now able to function properly in single-sector and multi-sector read modes on all test machines. It involves some rather funky details with the IDE ATAPI PACKET command that are not well documented, to carry out properly. read the source code comments for more details.
- A few bugs and typos were corrected in the hard disk read/write tests, one of which failed to actually use the LBA48 versions of the read/write commands when the menu implied that it did.
- A menu was added to allow for playing with the ATA "write uncorrectable sector" command. I have not yet found an IDE drive that implements the command, so I don't know if it works.
- ATA media lock/unlock/eject commands were added to the menu. But of course, none of the CD/DVD-ROM drives I've tested it on actually implement it. Go figure.

If you have some spare hardware with a hard disk who's contents you don't care about, feel free to test this program on it and let me know if you find any problems. What I've developed so far is now enough test code that I can begin adding IDE emulation to DOSBox.

Basic IDE emulation added. There is code for both ATA (hard disk) and ATAPI (CD-ROM) emulation. The ATA disk emulation does not fully work yet. ATAPI emulation is enough to satisfy MSCDEX.EXE and the OAK CD-ROM driver I have in the VM. For whatever reason, Windows 95 currently ignores the devices (I see it emit IDENTIFY DEVICE and then boot up without further conversation). There is debugging code active, prepare to see your console fill up with "ATAPI command" debug info when using the CD-ROM drive.

How to enable the emulation.

Add to your dosbox.conf:

[ide, primary]
enable=true

[ide, secondary]
enable=true

(and so on for 3rd and 4th controller if you like)

For ease of use I wrote the IDE emulation to tie into DOSBox's INT 13h and MSCDEX.EXE CD-ROM code and through the "imgmount" command. The way it's written now, if you use imgmount to attach hard drives or CD-ROM drives the command will automatically also attach it also to the IDE emulation as ATA and ATAPI device respectively. I added a "-ide" switch that allows you to specify exactly which IDE port to attach it to:

The emulation is enough to permit using OAKCDROM.SYS and MSCDEX.EXE to install Windows 95 straight from the CD-ROM drive. As usual, make sure you don't have S3 VGA enabled. Currently Windows 95 installs correctly, but will fall back on "MS-DOS compatibility mode" to talk to the hard disk using INT 13h and MSCDEX.EXE for CD-ROM access. But it's enough now that you can at least run and install things from CD-ROM in Win95.

The DOSlib source code has been updated to allow you to experiment with some ATAPI CD-ROM commands. The device reset now shows you the IDE registers after reset so you can see for yourself some of the "magic bytes" that ATAPI devices show to identify themselves.

A little hint for everyone else who wants to try this out: The above dosbox.conf [autoexec] section isn't entirely correct. The CD-ROM has to be mounted with a drive letter as first parameter like usual, not with the bus number. At least for me using the win32 build . Otherwise oakcdrom.sys (or any other CD-ROM driver I tried) refuses to find a drive.

mr_bigmouth_502 wrote:I just wonder though, will this work with Win98? I don't actually have a copy of 95. I know that 95 will probably work better, but I'm just wondering.

Have you tried the P***** Bay? Well plenty of people had their copy up the last time I checked. The copies I test from though are actual CD-ROM copies that were legitimately bought back in the day, don't worry

Anyway, I managed to get Windows 98 to boot in DOSBox-X. Unless you have core=dynamic and cputype=486_slow and more than 24MB of RAM in the DOS Box, Windows 98 will crash at random inside DOSBox. Windows 98 SE has the same problem if you have less than 32MB of RAM.

To answer your question, Windows 98/98SE treats my ATA/ATAPI emulation the same way Windows 95 does: CD-ROM emulation works, and (for whatever bizarre reason) IDE hard drives are completely ignored. And where Windows 95 flags the IDE controller as malfunctioning when hard disks are attached, Windows 98SE just flat outright ignores the IDE controller. There are some pretty rude comments in the latest revision of the DOSBox-x source code over these shenanigans, I'll give you fair warning

all these years, i'm curious why win9x choose to works with 28 bits LBA?
on real life, unpatched win9x might having trouble with HDD with more than 2^28 sectors.
MS never release any patch for this matter, probably to force win9x users to migrate to NT5 (one of MS infamous forced obselescene tricks?).

all these years, i'm curious why win9x choose to works with 28 bits LBA?on real life, unpatched win9x might having trouble with HDD with more than 2^28 sectors.MS never release any patch for this matter, probably to force win9x users to migrate to NT5 (one of MS infamous forced obselescene tricks?).

So far the ATA mode is 28 bits. I have the code written to eventually support LBA48, which is why the registers in the IDEDevice base class are 16-bit wide, not 8. Windows 95/98/ME as far as I know don't implement LBA48, Windows 2000 does (with a service pack).

The way DOSBox is written right now, it can't handle hard disk images 2GB or larger (using fseek on 32-bit systems where integers are involved----planning on rewriting that part to remove the limit), so there's not yet any point to adding LBA48.

The problem is that for whatever reason, I see Windows 95 carry out a DEVICE RESET (08h) then an IDENTIFY DEVICE, and then I see no more communication by Windows 95 to the hard disk. Or, if DOSBox's CMOS emulation convinces Windows 95 that there are hard drives, I see Windows 95 do a device reset, then issue a C/H/S read to track=0, head=0, sector=1, and then Window 95 turns around and claims the IDE controller is bad. I have absolutely no idea what malice Windows 95 could ever read from a successful 512-byte read from the boot sector to claim bullshit like that. I have both CHS and LBA READ commands implemented. Since Windows 95 fails to attempt any other commands, those commands are all the only ones implemented so far. In other words, Windows 95 isn't even TRYING to talk to the hard drive directly. All I know so far is that the test IDE program I wrote is able to work with it.

all these years, i'm curious why win9x choose to works with 28 bits LBA?on real life, unpatched win9x might having trouble with HDD with more than 2^28 sectors.MS never release any patch for this matter, probably to force win9x users to migrate to NT5 (one of MS infamous forced obselescene tricks?).

You also have to understand that LBA48 was not standardized until ATA-6 in 2000. Since Windows 98 pre-dates the ATA-6 standard it makes sense they do not support the LBA48 mode. It is possible though to use a third party driver that does support LBA48.

Didn't someone post a link to How To Please WDCTRL a while back? Of course, that's regarding 32-bit disk access in Windows 3.1, but maybe some of the wackiness involved held over to Windows 95. (Maybe a C/H/S read to 0,0,1 immediately following a device reset is supposed to fail or something.)