I think I remember seeing a few cheap drives that couldn't handle DMA mode (I think one of them was a SamDung). Did you try a different one?

What hard drive are you using...

Make sure it is enabled in bios too

Oetker wrote on 2020-06-11, 12:57:

What hard drive are you using...

A Seagate 7200.10 80GB IDE drive jumpered to 32GB. BIOS detects it as running at UDMA5 at POST.

using the same windows installation across different setups seems to be at least one cause of this. deleting the IDE controller driver in device manager (even if it's listed as working correctly) and letting it reinstall can fix this problem, along with CD drive detection issues.

Sorry for the necro post, but I just stumbled upon this thread, and thought I'd share my two cents (just in case anyone runs into the same issue):
1. This is (usually) not a HDD problem, but a BIOS issue (and it predominantly affects some motherboards with certain BIOS revisions from the socket 7 era).
2. Depending on the motherboard (BIOS), it can be quickly solved by disabling UDMA in the BIOS "Integrated Peripherals" section. After doing that, the DMA check will remain active and it will increase the HDD throughput/decrease CPU usage as it should. However, this will limit the transfer to ~ 16 MB/s.

Another option (when possible) is to limit the UltraDMA mode to 5 or lower. This way you get the best of both worlds. 😀

bloodem that is definitely not a BIOS issue, that is HDDs newer than UDMA33 (most of them) working properly only at their native UDMA 66/100 or PIO. That is true for Seagate and IBM drives.
That's also half of famous W98 shutdown bug. Because of that many people suggest using third party controllers.

examples
https://fcenter.ru/online/hardarticles/hdd/54 … arracuda_ATA_IV (article in russian, it just found first by google, translate it and search for "udma33")
https://forums.gentoo.org/viewtopic-p-4029318 … 410cf7d531ac28b
it's hard to find exact info from the past

Year ago i assembled simple test rig for old videocards using ABIT BX board with Barracuda IV, once i enabled DMA and rebooted windows 2-3 times "something went wrong" and PC startup or any disk related operations being dog slow. I checked HDD and DMA CRC errors field in SMART went from 5-10 to something like 38000.

No, that's not the case. Yes, the issue is clearly related to newer storage devices, but this is not the complete story.
I've just had 2 days ago an Acorp 5TX29 motherboard that refused to work in DMA mode with the initial 1997 BIOS, but worked just fine (with the same HDD) after updating it to the latest version (the new BIOS reverted to UltraDMA mode 2 as fallback).
And this is not a singular issue, I've seen it countless times.
Which is why, for boards (BIOS versions) that don't support this automatic fallback, the methods described in my previous post can be used.

_UV_ wrote on 2021-04-04, 22:45:

bloodem that is definitely not a BIOS issue, that is HDDs newer than UDMA33 (most of them) working properly only at their native UDMA 66/100 or PIO. That is true for Seagate and IBM drives.
That's also half of famous W98 shutdown bug. Because of that many people suggest using third party controllers.

that's an interesting statement, but if it such a general issue backwards compatibility issue on IDE existed, wouldn't it be much more widely known as UDMA66 became a thing in 1998/99 and these drives would have been widely used on UDMA33 connectors? or did nobody bother to tick that DMA checkbox?

moreover i looked up the manual for that ST380021A drive you mentioned and it literally lists UDMA 0-5 modes as supported. and as another example, both drive types from seagate and WD used in the original xbox were UDMA100 drives that were connected with a 40-wire cable... unfortunately i can't find any good info on whether the xbox OS actually used UDMA33 or PIO.

also, it's worth saying that 3rd party IDE controllers aren't necessarily a magic bullet either. i've once made a post about issues with silicon image and promise controllers and i think there's other threads about that as well. all in all i find SCSI actually less troublesome as you'd never even have to think about these issues there, and quality controllers are available for basically nothing... it's a shame that the drives do tend to be louder for whatever reason.

auron wrote on 2021-04-05, 05:57:

that's an interesting statement, but if it such a general issue backwards compatibility issue on IDE existed, wouldn't it be much more widely known as UDMA66 became a thing in 1998/99 and these drives would have been widely used on UDMA33 connectors? or did nobody bother to tick that DMA checkbox?

Yeah, of course this was never the case 😀 There are countless motherboards with Ultra ATA/33 HDD controllers which work just fine with any disk you throw at them, including UDMA7 storage devices.
So, yeah, this recurrent theme that this is a HDD problem is just wrong.

bloodem wrote on 2021-04-04, 08:59:

Sorry for the necro post, but I just stumbled upon this thread, and thought I'd share my two cents (just in case anyone runs into the same issue):
1. This is (usually) not a HDD problem, but a BIOS issue (and it predominantly affects some motherboards with certain BIOS revisions from the socket 7 era).
2. Depending on the motherboard (BIOS), it can be quickly solved by disabling UDMA in the BIOS "Integrated Peripherals" section. After doing that, the DMA check will remain active and it will increase the HDD throughput/decrease CPU usage as it should. However, this will limit the transfer to ~ 16 MB/s.

Works right away!
Many thanks!

Now that this thread has been resurrected, I like to add my views on this Win98 UDMA issue.

Although Win98 plays a roll here to, I fully agree with bloodem that this is a BIOS issue!
Here is the story:

A few years ago, when working on an i430TX board, I noticed that the BIOS summary screen indicated that the drives where running in UDMA 5 or 6 mode.
Because the i430TX chipset supports ATA33, any drive should be indicated as running in UDMA 2 max. (More accurately, it is the PIIX4 southbridge that provides UDMA 2 support.)
I’ve seen this before and always considered this a cosmetic issue and that the BIOS just displayed the capability of the drive and not the actual transfer mode.

However, I found that Windows 98(SE) doesn’t like the BIOS reporting higher UDMA modes on older hardware and refuses to use any DMA mode when set in Device Manager. This results in a fall-back to PIO mode 4 with reduced Harddisk performance.
This behavior comes from the Microsoft Bus Master IDE drivers and when it sees that the BIOS reports a higher UDMA mode than the hardware supports, it rightfully regards the BIOS as buggy and only allows PIO transfers to the IDE drives to protect your data.

I’ve tested this on my i430TX board with an 11/1998 Award BIOS and a clean Win98 install, so I was using the standard Microsoft Bus Master IDE drivers.
Indeed the DMA mode would not stick and the atto disk benchmark measured a poor 9MB/s.

I don’t know if this issue is present in AMI BIOSes, but most Award BIOSes from 03/1999 or later have a fix for this UDMA bug. So this issue is predominantly present in 1998 Award BIOSes for boards with UDMA capable chipsets, be it from Intel, SiS, ALi, or VIA.
If you have this bug on your retro board, you need a 1999 BIOS update or disable UDMA in the BIOS to get at least 14MB/sec from MWDMA mode 2.

When a 03/1999 or later Award BIOS is not available for your board, all is not lost. A guy named Petr Soucek found a way to apply the fix from Award Software to older Award BIOSes as well. I’ve tested this fix on my TX board and now Win98 allowed to select DMA in device manager and after a reboot I got 30MB/s in atto disk benchmark! 😀
An archived copy of his procedure is available at https://web.archive.org/web/20071027171328/ht … a586t2_mod.html
Scroll to the end of the page for the UDMA bugfix.

Now that I have a patch for this UDMA bug, I’m slowly applying it to the patched K6plus BIOSes on my "The Unofficial K6-2+ / K6-III+ page" (see link in my signature below).
At present, the following BIOSes on my page have the Win98 UDMA bug patched:
• Chaintech 5SIM: 08/07/98-SiS-5582-2A5IIC39C-00; with patch J.3
• Shuttle HOT-569: 02/10/99-i430TX,ITE8680-2A59IH2HC-00; with patch J.3
• Shuttle HOT-569A: 01/09/99-i430TX,ITE8680-2A59IH2HC-00; with patch J.3
• DFI 586ITBD: 07/13/98-i430TX-2A59ID4TC-00; with patch J.3
• Elitegroup P5TX-Bpro: 08/10/1998-i430TX-P5TXBproC-00; with patch J.3
• GA-586ATX (Rev 1): 07/20/1998-i430TX-W877-2A59IG0BC-00; with patch J.2
• GA-586T2: 12/23/98-i430TX-8679-2A59IG0HC-00; with patch J.2
• PCChips M577/Amptron PM9900: 03/09/1999-PM9900+ITE866-2A5LEH0AC-00; with patch J.4
• QDI Titanium IB+: 01/07/2000-i430TX-NS309-2A59IQ1IC-00; with patch J.3
• QDI Titanium IIB V2.0: 05/14/1998-i430TX-NS309-2A59IQ1IC-00; with patch J.3
• Tekram P5T30-B4: 07/24/1998-i430TX-2A59ITG9C-00; with patch J.4

Cheers, Jan

nice to have a bit more info on this. if i understand correctly, another workaround should be to use a drive that doesn't exceed the maximum supported UDMA mode of the southbridge? judging by that 03/99 date, the issue was only understood as UDMA66 drives actually started appearing. also, how does 95 OSR2 behave? UDMA chipsets are supported there as well with intel's .inf updates.

by the way, if memory serves correctly, on later chipsets like i815 with native UDMA66 support there was a seperate intel driver that would grey out the DMA checkbox in device manager. maybe the approach was changed because of these sorts of bugs.

Des rom.by (dead server now) 'BIOS Patcher' automatically apply a fix for that by any chance?

Is 'BADIDE' Or 'NOIDE' set in the registry?

Windows sets those when probing the ide controller goes sideways on install, so it wont try turning on certain features, fail, and lose data.

auron wrote on 2024-06-22, 15:58:

nice to have a bit more info on this. if i understand correctly, another workaround should be to use a drive that doesn't exceed the maximum supported UDMA mode of the southbridge? judging by that 03/99 date, the issue was only understood as UDMA66 drives actually started appearing. also, how does 95 OSR2 behave? UDMA chipsets are supported there as well with intel's .inf updates.

by the way, if memory serves correctly, on later chipsets like i815 with native UDMA66 support there was a seperate intel driver that would grey out the DMA checkbox in device manager. maybe the approach was changed because of these sorts of bugs.

Yes, using an ATA33 drive, or limiting an ATA66/100/133 drive to UDMA mode 2 via a tool from the drive manufacturer, would avoid this issue on the buggy BIOS and allow normal UDMA 2 transfers.
Win95 OSR2 may be affected by this issue as well, but I have no data on that.

rasz_pl wrote on 2024-06-22, 17:31:

Does rom.by (dead server now) 'BIOS Patcher' automatically apply a fix for that by any chance?

Yes, the ‘BIOS Patcher’ tool from rom.by has a fix for this UDMA bug.
It is called the “UDMA66/100/133 on UDMA33_only_MB patch:”

wierd_w wrote on 2024-06-22, 19:22:

Is 'BADIDE' Or 'NOIDE' set in the registry?

Windows sets those when probing the ide controller goes sideways on install, so it wont try turning on certain features, fail, and lose data.

I never checked but I don’t think so.
With this issue the drivers are installed normally, only the UDMA mode is not used when DMA is selected in Device Manager.
But I may be wrong. 😉

Edit: wouldn't these register flags be more permanent? On a previous clean Win98 install with the buggy BIOS that wouldn't do DMA, I only had to update the BIOS to get UDMA work normally.

Jan

I have disabled UltraDMA in bios to get DMA in windows for my CF cards.

My bios also offers the three following options which I don't know how to set best for CF cards.
IDE Burst Mode
IDE Data Port Post Write
IDE HDD Block mode

Any idea how to set these to improve performance?

ux-3 wrote on 2024-06-23, 12:20:

I have disabled UltraDMA in bios to get DMA in windows for my CF cards. […]
Show full quote

I have disabled UltraDMA in bios to get DMA in windows for my CF cards.

My bios also offers the three following options which I don't know how to set best for CF cards.
IDE Burst Mode
IDE Data Port Post Write
IDE HDD Block mode

Any idea how to set these to imüprove performance?

IDE Burst Mode and IDE Data Port Post Write are both performance enhancing features of the chipset, so Enabled is faster. However it depends on the combination of chipset and motherboard design, and on the IDE HDD or CF card used, if the Enabled state of these options is stable.
I would start with Enabling the IDE Data Port Post Write and see if that works reliably. Then you can try the IDE Burst Mode option.

The IDE HDD Block Mode is a BIOS function and usually always Enabled.
When Enabled it speeds up hard disk drive access by transferring multiple sectors of data per interrupt instead of using the basic single-sector transfer mode.
Most harddisks support these multi-sectors transfers, but if your CF card doesn’t, the BIOS is smart enough to detect that and use the single-sector mode instead.

I know of only one case where you need to disable IDE HDD Block Mode, and that is when running Windows NT 4.0 before SP2. In this case you can get data corruption when this option is Enabled. Microsoft fixed this issue in NT 4.0 Service Pack 2.

Cheers, Jan

Thanks.
I have already tried a bit but did indeed observe instabilities with the first two options. I timed windows startup but found only deviations in the order of 1s of 18s. I probably leave the last option on and the first two off.