Enabling UDMA in DOS with BIOS only assist has been hit and miss (mostly miss) for me depending on the motherboard. I use drivers from the following website to enable UDMA in DOS. I have had good luck using xhdd.sys & xhdd1.sys from the package. The drivers support a number IDE chipsets.

http://optimizr.dyndns.org/dos/drivers.html

You're already reaching speeds well above PIO. Programmed Input/Output (PIO) has 5 modes:

• Mode 0: 3.3MB/s
• Mode 1: 5.2 MB/s
• Mode 2: 8.3 MB/s
• Mode 3: 11.1 MB/s
• Mode 4: 16.7 MB/s

UltraDMA picks up where PIO leaves off:

• Mode 0: 16.7 MB/s
• Mode 1: 25 MB/s
• Mode 2: 33.3 MB/s
• Mode 3: 66.7 MB/s
• Mode 4: 100 MB/s
• Mode 5: 133 MB/s
• Mode 6: 167 MB/s

jasa1063 wrote on 2020-12-10, 21:15:

Enabling UDMA in DOS with BIOS only assist has been hit and miss (mostly miss) for me depending on the motherboard. I use drivers from the following website to enable UDMA in DOS. I have had good luck using xhdd.sys & xhdd1.sys from the package. The drivers support a number IDE chipsets.

http://optimizr.dyndns.org/dos/drivers.html

This is the first board I have ever used that has it enabled just via the bios, with no dos device drivers loaded. Even the custom 'MR BIOS' for various boards I have used don't enable udma in DOS. I don't know what exact mode it is using (obviously faster than any PIO mode), or if there is a way to show the current mode in Dos other than benchmarks. Utilities like NSSI just list all the modes the chipset and hard drive can support.
Using this same SSD in a 440BX chipset, it benchmarkr at 5.2MB/s in dos using speedsys, confirmed by timing the copy of a large 560MB file in dos command line. BIOS is selected to use UDMA but as normal it uses PIO mode 3 in dos.

Very interesting. Is there a particular BIOS setting to enable UDMA in DOS? I wonder if other G41/ICH7 board have it.

I have a number of motherboards with a UDMA or ATA selections available in the BIOS and it has an affects DOS performance.

Is that what you guys are talking about?

douglar wrote on 2020-12-11, 23:41:

I have a number of motherboards with a UDMA or ATA selections available in the BIOS and it has an affects DOS performance.

Is that what you guys are talking about?

There are two things required to get a specific transfer executed as UDMA transfer:

1. The chipset must and drive be set to agree on the kind (Ultra DMA) and speed (mode number) of any DMA transfers that are going to happen.
2. The IDE/ATA/ATAPI driver needs to tell the IDE controller the physical address of the data in memory and issue a "READ DMA" or "WRITE DMA" command instead of the classe "READ"/"WRITE" or "READ MULTIPLE"/"WRITE MULTIPLE" commands that are used for PIO modes.

Most BIOSes since 1998 are perfectly able to perform step 1, and often they print the mode that they programmed into the chipset and the drive. Note that programming the chipset for transfer speed depends on the kind of chipset, so it can not be done by a generic driver that doesn't know the (familiy of) chipset that is installed in your computer, so it is very sensible that this initial setup is done by the BIOS.

The second step is what you need the DOS UDMA driver for. The main challenge with DMA is that you need to know the physical address of the data you want to transfer, which can (and will) differ from the logical address if you use a memory manager like EMM386 and you want to transfer data from/to UMBs or the EMS page frame. There is a common API implemented by most memory managers called "VDS" (virtual-mode DMA specification), but it adds a lot of complexity to the quite simple IDE implementation in the BIOS and adds a dependency from the BIOS to the memory manager. It seems BIOS writers were reluctant to implement this part, expecting that you are going to boot Windows 98 anyway, which contains both a memory manager and bus-master (which is the same as (U)DMA in this context) IDE drivers, that also work inside the Windows 98 DOS box (but not the DOS mode / command prompt only boot variant).

I installed some kind of udma driver in dos once and it did make hard drives faster but it also made some software to stop working. I don't remember all the software that stopped working but at least speedsys didn't start so I couldn't benchmark the hard drive in it.

mkarcher wrote on 2020-12-12, 10:21:

The second step is what you need the DOS UDMA driver for. The main challenge with DMA is that you need to know the physical address of the data you want to transfer, which can (and will) differ from the logical address if you use a memory manager like EMM386 and you want to transfer data from/to UMBs or the EMS page frame. There is a common API implemented by most memory managers called "VDS" (virtual-mode DMA specification), but it adds a lot of complexity to the quite simple IDE implementation in the BIOS and adds a dependency from the BIOS to the memory manager. It seems BIOS writers were reluctant to implement this part, expecting that you are going to boot Windows 98 anyway, which contains both a memory manager and bus-master (which is the same as (U)DMA in this context) IDE drivers, that also work inside the Windows 98 DOS box (but not the DOS mode / command prompt only boot variant).

Here's a comparison between two Athlon XP boards pretty close in age with similar CPUs and exact the same mSata SSD attached via PATA using the same SATA/PATA converter.

I booted into windows 98se command prompt (DOs 7.1) with no memory manager or TSR's.

1Speedsys Test          Nvidia MCP2   Via VT8235
2Random access time         0.18 ms      0.18 ms
3Buffered read speed    64,103 KB/s   6,413 KB/s
4Linear read speed      66,650 KB/s   6,421 KB/s
5Min read speed         66,479 KB/s   6,420 KB/s 
6Max read speed         66,767 KB/s   6,423 KB/s
7Linear write speed     73,287 KB/s   6,439 KB/s
8Min write speed        70,473 KB/s   6,439 KB/s 
9Max write speed        73,454 KB/s   6,440 KB/s

Does that suggest that the Nforce II bios does UDMA transfers and the Via bios does not?

douglar wrote on 2020-12-12, 13:58:

Here's a comparison between two Athlon XP boards pretty close in age with similar CPUs and exact the same mSata SSD attached via […]
Show full quote

Here's a comparison between two Athlon XP boards pretty close in age with similar CPUs and exact the same mSata SSD attached via PATA using the same SATA/PATA converter.

I booted into windows 98se command prompt (DOs 7.1) with no memory manager or TSR's.

Copy code to clipboard

1Speedsys Test          Nvidia MCP2   Via VT8235
2Max read speed         66,767 KB/s   6,423 KB/s
3Max write speed        73,454 KB/s   6,440 KB/s

Does that suggest that the Nforce II bios does UDMA transfers and the Via bios does not?

Exactly. You could try the same thing on the Via VT8235 from the Windows 98SE DOS Box, or after installing a DOS driver like UDMA.SYS or XDMA.SYS, and I guess you will get performance close to the Nvidia Board.

In theory, the VT8235 should be able to get around 15MB/s, because that's what you get in the fastest usual non-DMA (that is PIO) mode. But no one is really optimizing PIO transfers anymore. Maybe (just maybe) you might get a boost by a factor of two if you enable "IDE 32-bit mode" in the BIOS setup of the VIA board (assuming you have the option, and it's not already enabled). because on some chipsets, 32-bit mode is twice as fast as 16-bit mode. The 32-bit/16-bit is just about the amount of data that in transferred from the processor to the IDE chip (or the other way around) in one cycle. You always have 16 bit transfers on the IDE cable itself. The south bridge will take care of splitting the transfer.

mkarcher wrote on 2020-12-12, 10:21:

There is a common API implemented by most memory managers called "VDS" (virtual-mode DMA specification), but it adds a lot of complexity to the quite simple IDE implementation in the BIOS and adds a dependency from the BIOS to the memory manager. It seems BIOS writers were reluctant to implement this part, expecting that you are going to boot Windows 98 anyway, which contains both a memory manager and bus-master (which is the same as (U)DMA in this context) IDE drivers, that also work inside the Windows 98 DOS box (but not the DOS mode / command prompt only boot variant).

Hey, I think I read about this in my Windows 3.1 resource kit. It sounded like this was more aimed at SCSI cards, since they used DMA much earlier than IDE did.

jakethompson1 wrote on 2020-12-13, 17:49:

mkarcher wrote on 2020-12-12, 10:21:

There is a common API implemented by most memory managers called "VDS" (virtual-mode DMA specification)

Hey, I think I read about this in my Windows 3.1 resource kit. It sounded like this was more aimed at SCSI cards, since they used DMA much earlier than IDE did.

In fact, it is aimed at every device using busmaster DMA (that is, the device itself generates the address it wants to access). This is in contrast to standard ISA DMA where the device just asks the DMA controller for "the next byte / word on channel #x", and the driver sets up the DMA controller to fetch the date from the right address. All DOS memory managers virtualize the ISA DMA controller (i.e. they notice when a program sets up a DMA transfer acessing an UMB) and programs the DMA controler in a way that matches the activity of the memory manger. DOS memory managers are able to this for standard ISA DMA, because they know how to interpret accesses to the standard ISA DMA controller. They can not understand DMA setup for every busmaster card on the market, as every busmaster card might use its own way of setting up busmaster DMA (and some card even fetch pointers for subsequent transfer using DMA, which makes the whole story even more futile).

You are completely right that the first mass-market card that used busmaster DMA on the PC platform is the Adaptec AHA-1542, which is an SCSI controller. I never saw a non-PCI IDE busmaster card. Also I never heard of MFM/RLL/ESDI controllers using busmastering, even if they used DMA (as they use standard ISA DMA). Another well-known, but much less wide-spread ISA busmaster card is the 3c515 "Corkscrew" ISA 10/100 MBit card. The 3c515 drivers also need to care about VDS if they are supposed to work while EMM386 (or QEMM, or 386|MAX or JEMM or whatever other virtualizing memory manager) is active.

douglar wrote on 2020-12-11, 23:41:

I have a number of motherboards with a UDMA or ATA selections available in the BIOS and it has an affects DOS performance.

Is that what you guys are talking about?

No, on every other motherboard I have used, changing the UDMA settings in the Bios has made no difference.
In real mode dos without using XHDD.sys driver, the speed of any hard drive has been limited to PIO3 or 4, regardless of bios udma setting or using a udma capable HD or SSD.
This board, GA-G41M-ES2L, gives me 164MB/s in speedsys and over 101MB/S when copying 1.2GB file on the dos command line in real mode with no device drivers loaded.
Another Dos benchmark I tried was Disktest.
https://github.com/foone/DiskTest/releases/tag/v2.4

Running this with the size=1100M command gives a write speed of 186MB/s and a read speed of 209MB/s, with a clean dos boot.