Try disabling the SATA ports in the BIOS or setting them to Legacy/IDE mode. Also consider trying an actual hard drive, the SD to IDE adapters may not have good compatibility with all chipsets.

onethirdxcubed wrote on 2025-10-03, 01:25:

Try disabling the SATA ports in the BIOS or setting them to Legacy/IDE mode. Also consider trying an actual hard drive, the SD to IDE adapters may not have good compatibility with all chipsets.

Agreed, i865's SATA ports work fine in legacy mode (Compatible Mode), tested on ASUS P4P800-VM(i865G)/120GB SATA SSD/Win98SE.

For testing I completely disabled SATA, but it still gets stuck as before once I enable DMA Transfer (with the drive in widows set either way).

Generally:
Drive set to Normal | BIOS set to DMA Disable -> Runs normally / Stutter of curstor when crystalDisk benchmark is running. Benchmark scores of 5.5 MB/s
Drive set to DMA | BIOS set to DMA Disable -> Stutter on Boot, Stutter when starting crystalDisk benchmark, but NO stutter during benchmark. Benchmark scores of 25.6 MB/s
Drive set to Normal | BIOS set to DMA Enable -> Hangs
Drive set to DMA| BIOS set to DMA Enable -> Hangs

Solved the issue:
Apparently it makes a difference which IDE Port you use. IDE2 does not work in combination with DMA. Or maybe it always checks IDE1 first and if that is not ok (no drive connected), it just hangs.
If the drive is connected to IDE Port 1, it is identified every single time, whether it is set to DMA or not. (seems like it was automatically disabled once during testing. If DNA is activated in BIOS but not on the drive it stuttered though, basically reverse to what happened before). Now in that instance it also doesnt matter if SATA is set to auto.

I am still going to test whether my other drives are affected now in any way and if this is "stable" or if it automatially disables itself again after reboots and so on. But this seemed to be the main issue.

More than likely the port configuration in the registry has the max speed value capped at PIO4, because it had a burp with reads at some point.

This is a little known behavior that I would think would be more well known, given its prevalence, but win9x has a coded behavior to detect if the IDE controller misbehaves at higher speeds, and then automatically downthrottle until it becomes stable, and then sits like a mother hen on that detected speed, even if this is in error for some reason, or the cause is later fixed (like moving to 80 conductor cable with real IDE, etc.)

https://learn.microsoft.com/en-us/answers/que … uck-in-pio-mode

Related issue that affects the whole system is the 'noide' and 'badide' flags in the registry, if present. Since at least the master port remains able to do DMA, that suggests its the checksum test that has triggered, and flagged the channel as being unreliable for DMA, for whatever reason.

In addition to the "Number of failed reads" stored in the keys cited by the article, there is also a key in there that sets the speed directly,

What a great thread!