VOGONS


DMA Mode check does not stick in Windows 98SE?

Topic actions

First post, by appiah4

User metadata
Rank l33t++
Rank
l33t++

I remember this being an issue and being resolvable, but I can't remember why it happens or how to fix it.

I'm getting this problem with my current Windows 98SE install on a ZIDA 5STX 430TX motherboard. I click DMA mode for the hard drive, reboot - and the tick is gone..

What is the fix here?

Reply 1 of 63, by Anonymous Coward

User metadata
Rank l33t
Rank
l33t

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?

"Will the highways on the internets become more few?" -Gee Dubya
V'Ger XT|Upgraded AT|Ultimate 386|Super VL/EISA 486|SMP VL/EISA Pentium

Reply 4 of 63, by appiah4

User metadata
Rank l33t++
Rank
l33t++
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.

Reply 5 of 63, by auron

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 6 of 63, by bloodem

User metadata
Rank Oldbie
Rank
Oldbie

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. 😀

1 x PLCC-68 / 2 x PGA132 / 5 x Skt 3 / 9 x Skt 7 / 12 x SS7 / 1 x Skt 8 / 14 x Slot 1 / 5 x Slot A
5 x Skt 370 / 8 x Skt A / 2 x Skt 478 / 2 x Skt 754 / 3 x Skt 939 / 7 x LGA775 / 1 x LGA1155
Current PC: Ryzen 7 9800X3D
Backup PC: Ryzen 7 5800X3D

Reply 7 of 63, by _UV_

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 8 of 63, by bloodem

User metadata
Rank Oldbie
Rank
Oldbie

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.

1 x PLCC-68 / 2 x PGA132 / 5 x Skt 3 / 9 x Skt 7 / 12 x SS7 / 1 x Skt 8 / 14 x Slot 1 / 5 x Slot A
5 x Skt 370 / 8 x Skt A / 2 x Skt 478 / 2 x Skt 754 / 3 x Skt 939 / 7 x LGA775 / 1 x LGA1155
Current PC: Ryzen 7 9800X3D
Backup PC: Ryzen 7 5800X3D

Reply 9 of 63, by auron

User metadata
Rank Oldbie
Rank
Oldbie
_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.

Reply 10 of 63, by bloodem

User metadata
Rank Oldbie
Rank
Oldbie
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.

1 x PLCC-68 / 2 x PGA132 / 5 x Skt 3 / 9 x Skt 7 / 12 x SS7 / 1 x Skt 8 / 14 x Slot 1 / 5 x Slot A
5 x Skt 370 / 8 x Skt A / 2 x Skt 478 / 2 x Skt 754 / 3 x Skt 939 / 7 x LGA775 / 1 x LGA1155
Current PC: Ryzen 7 9800X3D
Backup PC: Ryzen 7 5800X3D

Reply 11 of 63, by ux-3

User metadata
Rank Oldbie
Rank
Oldbie
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!

Retro PC warning: The things you own end up owning you.

Reply 12 of 63, by Chkcpu

User metadata
Rank Member
Rank
Member

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

CPU Identification utility
The Unofficial K6-2+ / K6-III+ page

Reply 13 of 63, by auron

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 14 of 63, by rasz_pl

User metadata
Rank l33t
Rank
l33t

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

https://github.com/raszpl/FIC-486-GAC-2-Cache-Module for AT&T Globalyst
https://github.com/raszpl/386RC-16 memory board
https://github.com/raszpl/440BX Reference Design adapted to Kicad
https://github.com/raszpl/Zenith_ZBIOS MFM-300 Monitor

Reply 16 of 63, by Chkcpu

User metadata
Rank Member
Rank
Member
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

CPU Identification utility
The Unofficial K6-2+ / K6-III+ page

Reply 17 of 63, by ux-3

User metadata
Rank Oldbie
Rank
Oldbie

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?

Last edited by ux-3 on 2024-06-23, 19:03. Edited 1 time in total.

Retro PC warning: The things you own end up owning you.

Reply 18 of 63, by Chkcpu

User metadata
Rank Member
Rank
Member
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

CPU Identification utility
The Unofficial K6-2+ / K6-III+ page

Reply 19 of 63, by ux-3

User metadata
Rank Oldbie
Rank
Oldbie

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.

Retro PC warning: The things you own end up owning you.