I appreciate it. I just wish you could have made this discovery 25 years ago to spare me the headaches.

Very interesting. 😄
Could you explain in detail (step by step) how you did it?
Sorry but I don't have much experience with VIA chipset motherboards. Thank you for your time 😉

Sure, I would like to prepare a more comprehensive howto, hopefully I can post it later today. Just wondering, is this a known issue or not. On many occasions I've tried to google this problem out, but in the best case was left with advice to try out different drivers... Well, turns out it was a driver issue after all. 😀

Anyhow, basically you just right click on the primary/secondary controller, open Driver tab, verify if it's microsoft driver. If it is, then select update driver, say that you would pick the driver from the list, point to the extracted via 4in1 package, select VIAVSD.INF file in the WIN9X sub-directory of the archive and then select "Bus Master IDE controller". Might have to tell it to show all drivers, not just compatible ones. After reboot check again the driver tab (should say it is a VIA driver) and the DMA checkbox on the hard drive.

And yeah, it kind of sucks to find this stuff out after so many years! Still, better late than never I guess...

Hi,
I do not want to be a party killer, but I have just checked this on my Win98SE/VIA KT133a PC. It's worth mentioning that I did not have DMA enabling problems even with the original config, just a little high CPU usage/low transfer speed during disk operations.
The starting situation was the same, both the primary and secondary disk controllers used MS drivers, only the Master had explicit VIA driver provider. And the names of the controllers were Primary IDE controller (dual fifo) and Secondary IDE controller (dual fifo) respectively.

After forcing the VIA driver on both controllers they really changed the name and driver vendor. The controllers became Primary Bus Master IDE controller (dual fifo) and Secondary Bus Master IDE controller (dual fifo) respectively and the driver Provider became Via Technologies, Inc. instead of Microsoft.

But the important thing is that the used drivers remained the same. Both the old Microsoft and the new VIA controller drivers really use the exact same 2 Microsoft driver files. Namely ESDI_506.pdr and IOS.vxd. And in my case nothing has changed in terms of performance/behavior when tested with disk benchmarks and games.
Looking at VIAVSD.INF has revealed that the setup inf file really does not contain any separate driver for the controllers, only the VIA BUS Master PCI IDE Controller has a real VIA driver that was already installed originally (vatapi.vxd). So on my side these changes seem to be only cosmetic.
I do not say that for others these changes cannot do miracles, but maybe ones who have only some performance problems like me should be careful about too high expectations.
Bye.

content of my VIAVSD.INF:

Very interesting! Indeed the actual driver files remain Microsoft ESDI_506.pdr and IOS.vxd just as in your case, so indeed this seems to be cosmetic change. As it is not my intention to offer snake oils, I have tried to reproduce the effect once again, thus reinstalled fresh Windows 98SE.

The Chipset I am using right now is VIA KLE133 and I'm working with VIA 4 in 1 driver version 4.35 package. I am using a Samsung EVO 850 250GB Sata SSD drive connected via cheap Gembird IDE to Sata bi-directional adapter like This One

Right after the installation, without any driver updates, I've noticed that Primary IDE controler has stock ESDI_506.pdr version 4.10.2222 and IOS.vxd also 4.10.2222.

I have proceeded to install the 4 in 1 driver pack and after installation ESDI_506.pdr file remained version 4.10.2222, but IOS.vxd was upgraded to version 4.10.225. And now I've tried to enable DMA mode for an SSD drive and, to my demise, it worked out fine indeed! That has literally NEVER EVER happened to me before! Very very strange. So I've took a disk speed benchmark and it seemed to perform really well!

Then I have proceeded to manually update Primary and Secondary IDE drivers as described in the original post. Then ran the disk test again. And it does seem to have a slight effect on disk performance somehow, but overall it looks to be a slightly negative one now...

So ain't this a bombshell, eh? Now I'm really confused. I have not touched the BIOS settings or the rest of the system hardware, yet I have really never been able to get DMA mode to work with any SSD drive ever until messing with this yesterday. I'll definitely keep an eye on this stuff when I'll have different board to play with. Until then this would remain one of the things to try when dealing with DMA mode issues on VIA Chipsets, I suppose it may or may not help.

This is just a little guide for those who would like to experiment.

It is all very simple really. If DMA mode is working fine for you, then, I suppose, there is no benefit in doing this. However, If, after installing VIA 4 in 1 Chipset driver pack, there is trouble enabling DMA mode, or the disk performance is still sub-optimal, it may be worth to try this.

NOTE: I was unable to revert this, for some reason, Microsoft's driver cease to exit in the driver list!

Basically one need to go to the Device Manager and find Primary IDE Controller (dual fifo) device.:

1. Right click on it and select properties
Select Driver tab and click on Update Driver button:

2. Choose to Display a list of all drivers:

3. Find VIA Technologies, Inc in the manufacturers list and select Primary Bus Master IDE Controller (dual fifo) and click next.

4. If asked for viadsk.cat file, point installer to the location of your extracted VIA 4 in 1 Chipset driver pack, select WIN9X subdirectory

Windows will ask for reboot, decline, repeat the same steps for Secondary controller, then reboot and test. Hopefully this will help to enable DMA mode, or at least it should not do any harm.

totoro wrote on 2022-09-28, 15:01:

So ain't this a bombshell, eh? Now I'm really confused. I have not touched the BIOS settings

Most BIOS settings shouldn't matter in Windows as Windows drivers don't use BIOS to access hard drives. That also goes for any drives configured in BIOS. That is only necessary to be able to boot.

VIA is infamous for poor performance and instability. It only managed to fix its image late in the Athlon XP era before fading into obscurity. Always use Intel, Sis or ALi chipset whenever possible except for Athlon XP / 64.

AlexZ wrote on 2022-09-28, 18:21:

VIA is infamous for poor performance and instability.

You don't say... I've just found another motherboard, this time featuring VIA Apollo Pro 133T Chipset, for which Via 4 in 1 driver version 4.43 generally is more appropriate, and to no surprise, the DMA just does not work. Same classic issue, I check the Chekcbox, reboot and... no DMA.

I've tried this trick with manual driver update and... it did not work this time. So, I have tried older driver, the same I was using previously, version 4.35, then the trick worked, however, the actual performance is dismal... It seems that only disk cache is working at the proper speed, but the disk itself performs worse than when using PIO mode.

Noticed that after using driver version 4.43 Primary IDE Controller has Microsoft ESDI_506.pdr version 4.10.2230 and IOS.vxd is 4.10.2225

Tried to use a better ide -> m.2 sata adapter, which features 80 conductor cable and all. But no go.

On some VIA chipsets like the KT133A it helps to use a SATA to IDE adapter which is based on a Marvell chip. They are more expensive but tend to work more reliably in such cases, compared to the adapters based on a JMicron chip.

Phil recently made a video on one of those Marvell based adapters.

Joseph_Joestar wrote on 2022-09-28, 19:13:

On some VIA chipsets like the KT133A it helps to use a SATA to IDE adapter which is based on a Marvell chip. They are more expensive but tend to work more reliably in such cases, compared to the adapters based on a JMicron chip.

Phil recently made a video on one of those Marvell based adapters.

I concur. There were several threads on this. Here are some of them .

EDIT: Especially this [SOLVED] SSD on TUV4X...impossible [IDE2SAT2 Startech adapter or nothing]

Windows 98 SE on SSD 128 GB
Re: Master/Slave option for modern storage
Re: Planning to install SSD in my Windows 98 machine. Help, advice, suggestions, etc.?
Re: Gigabyte 6bxc with PCI SATA HBA

Thanks! I'll sure read through them. Meanwhile, another crazy discovery.

I have two different ssd's with two different adapters. EVO+Gembird and m.2 one. Now on this setup, the m.2 adapter does not use the DMA, but performance is OK-ish (feels like PIO4 or simmilar). I seem to be able to use EVO+Gembird in DMA mode. I have identical Windows 98 installed on both.

And here is the strange thing, if I boot from the EVO in primary channel, then DMA is enabled and performance is beyond dismal. If I switch them (EVO goes to secondary IDE, and M.2 to primary), then boot from M.2 and then EVO also use the DMA mode, but now performance is Excellent! It's very snappy, it saturates whole udma bandwith nicely and pushes well over 60MB/sec while testing. Basically it works as it should. Really funny.

So, now I disconnect the M.2 SSD from the system, and leave EVO connected to the secondary IDE port, boot from it and the performance is still Excellent! It's really fast and proper. And then if I return it to the primary channel, then it's dismal again. Really, what chore 👎

I gave up on the 686B's IDE controllers decades ago. Thanks for adding to my list of reasons 😉

Also, ESDI506.PDR has its share of quirks, even on Intel platforms. Did VIA ever release a Windows 9x IDE driver implemention not based on ESDI506.PDR in whole or in part ?

EDIT: Looks like they might have. See https://www.techspot.com/drivers/driver/file/ … formation/1158/

totoro wrote on 2022-09-28, 19:56:

Thanks! I'll sure read through them. Meanwhile, another crazy discovery. […]
Show full quote

Thanks! I'll sure read through them. Meanwhile, another crazy discovery.

I have two different ssd's with two different adapters. EVO+Gembird and m.2 one. Now on this setup, the m.2 adapter does not use the DMA, but performance is OK-ish (feels like PIO4 or simmilar). I seem to be able to use EVO+Gembird in DMA mode. I have identical Windows 98 installed on both.

And here is the strange thing, if I boot from the EVO in primary channel, then DMA is enabled and performance is beyond dismal. If I switch them (EVO goes to secondary IDE, and M.2 to primary), then boot from M.2 and then EVO also use the DMA mode, but now performance is Excellent! It's very snappy, it saturates whole udma bandwith nicely and pushes well over 60MB/sec while testing. Basically it works as it should. Really funny.

So, now I disconnect the M.2 SSD from the system, and leave EVO connected to the secondary IDE port, boot from it and the performance is still Excellent! It's really fast and proper. And then if I return it to the primary channel, then it's dismal again. Really, what chore 👎

I have read all the updates and anyway thank you for opening this thread: it's nice to keep learning new things about the old hardware / software even after all these years 😄

Well, at least it was fun 😃 I still have some VIA boards laying around, but I'll be back to using boards with Intel Chipsets now. At least until I can get my hands on some decent adapter with a Marvel chip. It would be interesting to try all those VIA boards again then.