Chkcpu wrote on 2024-06-23, 17:36:

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.

Most Compact flash devices will report via ATA info commands that they support block transfer mode, but ironically, almost all of them report a max block size = 1. Block transfer mode with max block size = 1 is the same thing as not supporting block mode. So don't expect to see block transfer mode help a CF. I'm still looking for a CF that supports block transfer mode with a max block size > 1. Maybe some of the San Disk Ultras.

This isn't necessarily a big performance disadvantage for CFs vs most physical disks in the faster UDMA modes, because the UDMA modes > 3 give have more bandwidth than legacy spinning platters and 1&2 chip CF flash implementations can use. The extra available bandwidth hides much of the extra CF chatter and lets the CF's pull ahead on buffered and linear read tests. But on slower ATA transfer modes that are bandwidth limited, it's not uncommon to see a physical disk that supports block mode pull head in buffered and linear read tests because it's transferring more efficiently with less back and forth chatter. CF's almost always win on track seeks & random access by such a large degree that they usually "feel" faster in windows even if they fall behind on linear read tests in some cases because of a lack of block transfers > 1.

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 improve performance?

UDMA it is much faster than WDMA and should be the goal if your drive and controller both support it. Use an 80 conductor IDE cable if you can.

The transfer mode that is used by your device is an interplay between the controller, the driver, and the storage devices. In DOS, your BIOS is the default driver. In Win9x, ideally your protected mode driver can pick up from the BIOS and using the power of newer programming, even select a faster mode when possible. But there are certainly cases where that hand off isn't smooth, and the windows driver falls back to a slower mode, or is unable to take over from the BIOS at all and your system goes into the dreaded compatibility mode.

I don't have any magic advice for fixing a UDMA issue other than upgrade your bios, look for a newer Win9x device driver, buy a 3rd party IDE controller, or try a different storage device.

douglar wrote on 2024-06-24, 12:04:

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

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

UDMA it is much faster than WDMA and should be the goal if your drive and controller both support it. Use an 80 conductor IDE cable if you can.

If I set it to UDMA, the system ultimately is slower in win98, as the cpu seems to be busy a lot more.
I can't use an 80 pin cable, as the board has no missing pin to allow the cable to fit. My 80 pin cables all have one pin sealed off. Should I just punch a hole and see if that helps? Should be ok if it was just for orientation.

That is... well.. Seems, bass-ackwards.

The whole point of UDMA mode, was to permit the disk controller to handle getting data into and out of memory, leaving the CPU to do "whatever else", whereas Programmed IO modes, require the CPU's full attention to do ANYTHING with the disk controller, as it has to be the thing getting data into and out of, memory for later use.

As for the missing pin issue-- often, you can fake it, by poking a heated straight pin into the appropriate part of the 80-conductor cable's connector. I have done this many times, without ill effect. It's usually just 1mm of plastic in the connector that you have to get past, and there is nothing behind it. Just be careful not to drive the pin super deep, and into the ribbon behind it.

ux-3 wrote on 2024-06-24, 12:34:

douglar wrote on 2024-06-24, 12:04:

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

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

UDMA it is much faster than WDMA and should be the goal if your drive and controller both support it. Use an 80 conductor IDE cable if you can.

If I set it to UDMA, the system ultimately is slower in win98, as the cpu seems to be busy a lot more.
I can't use an 80 pin cable, as the board has no missing pin to allow the cable to fit. My 80 pin cables all have one pin sealed off. Should I just punch a hole and see if that helps? Should be ok if it was just for orientation.

If your UDMA is slower, it sounds like you are not really using UDMA. You are probably running in ATA-1 or what's worse, single tasking compatibility mode.

What IDE controller are you using? What Win9x driver are you using?

You only need the 80 conductor cable if you are trying to get to UDMA 4 or higher. If you have a pin keyed cable, there's usually just a plastic peg stuck in the jumper block to make the pin key. It can usually get popped out with a needle. If you don't have a viable 80 pin cable, you can also mod your CF adapter by grounding pin 34 like this: Re: UDMA 5 with DOM's & CF's

wierd_w wrote on 2024-06-24, 13:29:

That is... well.. Seems, bass-ackwards.

The whole point of UDMA mode, was to permit the disk controller to handle getting data into and out of memory, leaving the CPU to do "whatever else", whereas Programmed IO modes, require the CPU's full attention to do ANYTHING with the disk controller, as it has to be the thing getting data into and out of, memory for later use.

That is correct, and exactly what happens when the BIOS has the Win98 UDMA bug.

Sorry if I haven’t made the issue clear, but the bug causes Win98 to revert to PIO mode 3 or 4 when UDMA for the drive in question is Enabled or on Auto in the BIOS Setup. The workaround of Disabling UDMA in the BIOS will get you at least Multiword DMA. Although both PIO 4 and MWDMA 2 can theoretically transfer 16.6MB/sec, MWDMA is faster because it has less overhead.

A 80-wire IDE cable won’t help here and, as Douglar correctly pointed out, is only needed for UDMA 4 or faster.
What does help to get UDMA with the buggy BIOS is a separate PCI IDE controller with its own BIOS, a tool to limit the HDD to UDMA 2, or an older ATA33 HDD that can’t do more than UDMA 2 anyway.
And of course a BIOS update is the best solution. 😉

@ux-3, is it the GA-586STX2 board with the latest 1.6 BIOS you are talking about?
If so, I can put this BIOS on my “to be patched” list for the UDMA bugfix and fix the 32GB HDD limit bug as well. However it may take a while, I have several other projects to finish first.

Cheers, Jan

Chkcpu wrote on 2024-06-24, 14:45:

What does help to get UDMA with the buggy BIOS is a separate PCI IDE controller with its own BIOS, a tool to limit the HDD to UDMA 2, or an older ATA33 HDD that can’t do more than UDMA 2 anyway.
And of course a BIOS update is the best solution. 😉

Could XTide Universal Bios or a drive overlay like EZ Drive that replaces the motherboard INT13 handler fix the issue?

douglar wrote on 2024-06-24, 14:51:

Chkcpu wrote on 2024-06-24, 14:45:

What does help to get UDMA with the buggy BIOS is a separate PCI IDE controller with its own BIOS, a tool to limit the HDD to UDMA 2, or an older ATA33 HDD that can’t do more than UDMA 2 anyway.
And of course a BIOS update is the best solution. 😉

Could XTide Universal Bios or a drive overlay like EZ Drive that replaces the motherboard INT13 handler fix the issue?

The problem here is in the Win98(SE) Busmaster IDE driver that refuses to enable UDMA when the BIOS reports a higher UDMA mode than the hardware supports.
The 1998 BIOS already has the Int13h extension support that XTide or EZ-Drive were designed to fix, so using these solutions won’t help here unless they can limit the reported UDMA mode of an ATA66/100/133 drive.

A patched driver could help, but I’ve never seen one for these Socket 7 chipsets where the bug is most prominent.

Jan

Chkcpu wrote on 2024-06-24, 14:45:

What does help to get UDMA with the buggy BIOS is a separate PCI IDE controller with its own BIOS, a tool to limit the HDD to UDMA 2, or an older ATA33 HDD that can’t do more than UDMA 2 anyway.
And of course a BIOS update is the best solution. 😉

I do have several IDE (raid) controllers available. One even offers SATA as well.
I wouldn't know how to limit these CF cards to UDMA 2. However, their speed limit is somewhere near the mentioned 15 MB/s anyway. A speed of x133 is about 20 MB/s. The speed loss with these 133x CF cards is not a tragedy. The faster 30MB/s cards lose about 50% speed. That is not so good.

@ux-3, is it the GA-586STX2 board with the latest 1.6 BIOS you are talking about?

Yes, that is the one.

If so, I can put this BIOS on my “to be patched” list for the UDMA bugfix and fix the 32GB HDD limit bug as well. However it may take a while, I have several other projects to finish first.

Sounds great. But I never patched the bios on this board myself. So I don't really know what writing software I would need for this board.

But now you sparked my interest: I have another SS7 board which I patched back all the way to the first bios version to regain "disable onboard cache". I lost the 128 GB support and probably some other bugfixes for this. I could patch to latest version again, but I need "disable onboard cache" more than the later fixes and CPU updates. Would it be possible to reenable this onboard cache option in the latest bios? The board is from a packard bell PC and as such rather limited in bios options anyway.

Ahh, I see. So we are talking about ESDI_506.PDR yes? ESDI_506.PDR v4.10.2225 isn't able to correctly identify available modes for this motherboard when UDMA is enabled in the BIOS for this motherboard.

My understanding is that ESDI_506.PDR doesn't use INT13 for this, so yes you are right, XUB and EZDrive won't help.

OP could try the unofficial ESDI_506.PDR v4.10.2230 http://www.vogonsdrivers.com/getfile.php?fileid=635

Or try ESDI_506.PDR v4.90.3000 from Windows ME. '<---Edit: Probably a bad idea, cure might be worse than the symptom

Or try the 430TX chipset driver? http://vogonsdrivers.com/getfile.php?fileid=1632

This is needed for the proper functioning of the following features:
- Core PCI and ISAPNP Services
- AGP Support
- IDE/ATA33/ATA66 Storage Support

ux-3 wrote on 2024-06-24, 16:50:

Yes, that is the one. […]
Show full quote

@ux-3, is it the GA-586STX2 board with the latest 1.6 BIOS you are talking about?

Yes, that is the one.

If so, I can put this BIOS on my “to be patched” list for the UDMA bugfix and fix the 32GB HDD limit bug as well. However it may take a while, I have several other projects to finish first.

Sounds great. But I never patched the bios on this board myself. So I don't really know what writing software I would need for this board.

Okay, I will put the GA-586STX2 BIOS on my list.
When ready, I will put a message in your Re: Socket 7 Pentium MMX project on regular ATX board. thread about this board.
For flashing the patched BIOS on your board, you can use either AWDFLASH or UNIFLASH, whichever you like.

But now you sparked my interest: I have another SS7 board which I patched back all the way to the first bios version to regain "disable onboard cache". I lost the 128 GB support and probably some other bugfixes for this. I could patch to latest version again, but I need "disable onboard cache" more than the later fixes and CPU updates. Would it be possible to reenable this onboard cache option in the latest bios? The board is from a packard bell PC and as such rather limited in bios options anyway.

About the Packard Bell PC, does it have the BCM IN530 motherboard? https://theretroweb.com/motherboards/s/bcm-in530 If so, to which BIOS version did you downgrade? 1.15? 1.11J?

Jan

douglar wrote on 2024-06-24, 16:50:

Ahh, I see. So we are talking about ESDI_506.PDR yes? ESDI_506.PDR v4.10.2225 isn't able to correctly identify available mo […]
Show full quote

Ahh, I see. So we are talking about ESDI_506.PDR yes? ESDI_506.PDR v4.10.2225 isn't able to correctly identify available modes for this motherboard when UDMA is enabled in the BIOS for this motherboard.

My understanding is that ESDI_506.PDR doesn't use INT13 for this, so yes you are right, XUB and EZDrive won't help.

OP could try the unofficial ESDI_506.PDR v4.10.2230 http://www.vogonsdrivers.com/getfile.php?fileid=635

Or try ESDI_506.PDR v4.90.3000 from Windows ME. '<---Edit: Probably a bad idea, cure might be worse than the symptom

Or try the 430TX chipset driver? http://vogonsdrivers.com/getfile.php?fileid=1632

This is needed for the proper functioning of the following features:
- Core PCI and ISAPNP Services
- AGP Support
- IDE/ATA33/ATA66 Storage Support

Yes, ESDI_506.PDR as Win98 standard PCI Bus Master IDE Controller driver for Intel’s PIIX, PIIX3, and PIIX4 southbridges is probably involved here.
But what about ux-3’s GA-586STX2 board with SiS5582 chipset? His Win98 installation must have another Busmaster IDE driver and he has exactly the same UDMA issue as on my i430TX board due to the buggy BIOS. And I’ve seen the issue on Ali and VIA chipset boards as well.

One could argue that Microsoft validated all these standard drivers and demanded the same driver behaviour from Intel, Sis, Ali, and VIA.
In any case, the Win98 UDMA bug is not a driver issue but a BIOS bug. I believe that Microsoft put this UDMA mode drive/hardware comparison into the drivers on purpose to avoid corrupting the data on your drive.

I don’t know if Windows Me has the same UDMA issue with a buggy BIOS. Using the Win Me driver in Win98 on a 430TX board would be interesting, but I agree it is probably a bad idea. 😉

Fixing the UDMA bug in an Award BIOS is not that hard, I only have to find the time to do it. 😀

Cheers, Jan

Chkcpu wrote on 2024-06-24, 19:02:

Okay, I will put the GA-586STX2 BIOS on my list.
When ready, I will put a message in your Re: Socket 7 Pentium MMX project on regular ATX board. thread about this board.
For flashing the patched BIOS on your board, you can use either AWDFLASH or UNIFLASH, whichever you like.

Many thanks in advance.

About the Packard Bell PC, does it have the BCM IN530 motherboard? https://theretroweb.com/motherboards/s/bcm-in530 If so, to which BIOS version did you downgrade? 1.15? 1.11J?

Yep, that is the board. Mine is called FR520, but I got the older bios version from that linked site. As the board is useless to me without slowdown, and the manual showed the bios with onboard cache disable option, I went back in time all the way. Only with 1.11J, I had success. That bios is what I am using.

Chkcpu wrote on 2024-06-24, 19:40:

I believe that Microsoft put this UDMA mode drive/hardware comparison into the drivers on purpose to avoid corrupting the data on your drive.

I also tried using adapted 32GB SATA SSDs. I couldn't run windows from them, I would get drive corruption. Before using windows, scandisk reported the drives as OK, after starting windows (never fully loaded), the drive was reporting errors, disagreeing FAT or such. As I had no such issues with CF cards, I just dropped SSDs from the project. The BCM IN530 handles 32GB SSDs OK on 1.11J.

Hello, I have 3 boards with i430TX chipset - (the bug mentioned is true)

ECS P5TX-APRO (I tried all the bios, none of them worked for me - https://theretroweb.com/motherboards/s/ecs-p5tx-apro#bios)
Soyo Sy-5BT (works fine wiht the patched Bios - https://www.wimsbios.com/large-hdd-patched-bi … d=200#gsc.tab=0)
PCChips M572 (I couldn't test it yet, I have to change inflated capacitors first)

Does anyone have the modified bios that correctly identifies in the bios as UDMA 2 for the ECS P5TX-APRO rev 2.0

I offer myself as a betaster, since I have a Bios programmer in case something goes wrong

Thanks for your time

Fix the problem by patching the original bios with Bios Patcher, now my ECS mobo works up to 33mbs UDMA2

Thanks: steve_v

Follow these steps:

http://rom.by/Award/patcher/bp-4_23.rar
http://rom.by/Award/patcher/cbrom.rar
http://rom.by/Award/patcher/lha.rar
http://rom.by/Award/patcher/real_microcodes.rar
An image of your broken, pre October 1998 Award BIOS.
The appropriate tool to flash it.
Some courage.

Extract everything to a directory somewhere.
Run bp-4_23.exe <your_rom_file>
Flash.
Reboot.

sappa3dfx wrote on 2024-06-26, 04:08:

Fix the problem by patching the original bios with Bios Patcher, now my ECS mobo works up to 33mbs UDMA2

That's a nifty tool!

Yes indeed!

I love the ECS board because it is i430TX and in ATX format, it is very rare and the boards fit very well!

Chkcpu wrote on 2024-06-24, 19:40:

Fixing the UDMA bug in an Award BIOS is not that hard, I only have to find the time to do it. 😀

Cheers, Jan

Unfortunately, my BCN IN530 passed away.
I replaced it with a Gigabyte GA-586ATX3 (=rev3),
patched it to latest 4.0 bios.
Is a UDMA2 bios for this board already in existance and where would I have to look for it?
Thanks in advance.

ux-3 wrote on 2024-07-18, 11:46:

Unfortunately, my BCN IN530 passed away. I replaced it with a Gigabyte GA-586ATX3 (=rev3), patched it to latest 4.0 bios. Is a […]
Show full quote

Unfortunately, my BCN IN530 passed away.
I replaced it with a Gigabyte GA-586ATX3 (=rev3),
patched it to latest 4.0 bios.
Is a UDMA2 bios for this board already in existance and where would I have to look for it?
Thanks in advance.

My understanding is that UDMA support is not always included in the BIOS for compatibility reasons.

If you want to get UDMA speeds, you need a driver, both in DOS and in Windows 98

douglar wrote on 2024-07-18, 12:58:

My understanding is that UDMA support is not always included in the BIOS for compatibility reasons.

If you want to get UDMA speeds, you need a driver, both in DOS and in Windows 98

Chkcpu seems to know how to patch bioses so that the bios UDMA option will not report the UDMA speed of the device, but a UDMA speed which is the lesser of "2" and the device UDMA speed. This number is the maximum speed the actual combination of board and device can run at.
Which is apparently needed to run Win98se in DMA mode.
The manufacturer bioses don't manage this.

ux-3 wrote on 2024-07-18, 13:09:

Chkcpu seems to know how to patch bioses so that the bios UDMA option will not report the UDMA speed of the device, but a UDMA s […]
Show full quote

douglar wrote on 2024-07-18, 12:58:

My understanding is that UDMA support is not always included in the BIOS for compatibility reasons.

If you want to get UDMA speeds, you need a driver, both in DOS and in Windows 98

Chkcpu seems to know how to patch bioses so that the bios UDMA option will not report the UDMA speed of the device, but a UDMA speed which is the lesser of "2" and the device UDMA speed. This number is the maximum speed the actual combination of board and device can run at.
Which is apparently needed to run Win98se in DMA mode.
The manufacturer bioses don't manage this.

Maybe I misunderstood what you were asking. Your new board has a PIIX4 southbridge, yes? The IDE controller in that southbridge should support UDMA and it should report that as an available ATA speed. It won't have the DMA mode issue discussed in this thread because it actually has a UDMA controller.