Well you do not have busmastering from DOS (as with PIIX driver in 9x) so HD will perform slower but 10x slower seems a bit off. What do you mean by "hitching" ?
What is being loaded thru config.sys and autoexec.bat in DOS mode ?

Hitching maybe is just a word used locally, something between a stutter and a long pause enough to be a nuisance basically without being unusable.

Config.sys

1DEVICEHIGH=C:\DOS\VIDECDD.SYS /D:OPTICAL
2DEVICE=C:\WINDOWS\HIMEM.SYS /TESTMEM:OFF
3DEVICE=C:\WINDOWS\EMM386.EXE RAM

Autoexec.bat

1LH C:\WINDOWS\COMMAND\MSCDEX.EXE /D:OPTICAL
2LH C:\DOS\CTMOUSE EXE /R2
3C:\PROGRA~1\YAMAHA\YAMAHA~1\SETUPSA.EXE /S

Hopefully I typed those in right, I suck at typing on mobile haha

Ahh I see two things. Why EMS ? aka EMM386.exe RAM and why CTmouse ?
I use the NOEMS with EMM386 because I do not need any EMS ram on a Win9x machine. And you did not specify a window for the EMS http://info.wsisiz.edu.pl/~bse26236/batutil/help/EMM386S.HTM
Also CTmouse driver is known for issues. What exact mouse are you using ? If Logitech or Microsoft use their drivers...if generic then use MS mouse 9.x.
updated...

I REM'd the mouse out of autoexec and set EMM386 to NOEMS. Seems to be about the same. Part of me wonders if the 166MMX is just running ahead of what the disk can provide since it's missing that busmastering in DOS and that's what's causing the hitching. I should probably get off this 30 yr old spinning rust anyway and sling a CF adapter in there instead.

Or just run Smart Drive, the disk cache.
Yes, it's a memory hog, normally, but there are workarounds.
Tools like Helix Multimedia Cloaking can run mouse driver, mscdex and smartdrv.exe past the 1MB boundary.
All that without requiring UMBs or EMS.

Make sure that disk caching like smartdrive runs when booting in dos, the performance hit without is more noticeable with a mechanical hard disk.

What file format did you use? I recommend fat 16

fat 32 may be problematic

I heard that there are similar problems with duke3d when not using fat 16

DeathRabbit679 wrote on 2023-11-24, 03:19:

On my win95 rig, whenever I boot into dos mode, it seems like my load times shoot through the roof. Dn3d and hexen are particularly bad offenders being about 10x longer to load with the former even displaying some hitching that isn't present when I run the game under windows. The disk also audibly just sounds like it's getting hit a lot harder under dos. Is this a common problem? I couldn't find anyone talking about it but this is also one of those things that's kinda hard to google.

It's a pentium mmx166 abit ab-tx5 mobi with 64 mb if ram if it matters.

As other mentioned, adding a disk caching utility such SMARTDRV (included with Windows) would help tremendously. I would do the following for CONFIG.SYS:

1BUFFERS=10
2STACKS=9,256
3DEVICE=C:\WINDOWS\HIMEM.SYS /TESTMEM:OFF
4DEVICE=C:\WINDOWS\EMM386.EXE RAM AUTO NOEMS
5DEVICEHIGH=C:\DOS\VIDECDD.SYS /D:MSCD0001

And AUTOEXEC.BAT:

1C:\PROGRA~1\YAMAHA\YAMAHA~1\SETUPSA.EXE /S
2LH C:\WINDOWS\COMMAND\MSCDEX.EXE /D:MSCD0001
3SMARTDRV /X 8192 16 /B:8192 /E:32768
4C:\DOS\CTMOUSE EXE /R2

CTMOUSE and SMARTDRV doesn't need LH, both will be loaded automatically high by default if UMB is available.

Also, if possible, I recommend replacing CTMOUSE as well. Has compatibility issues with certain DOS software.

dragonkn wrote on 2023-11-24, 09:38:

What file format did you use? I recommend fat 16

fat 32 may be problematic

I heard that there are similar problems with duke3d when not using fat 16

At this point, one could be running MS-DOS 6.22. 😉

Thanks for all the replies, I'm afk with holidays and all, but smartdrv looks promising, thanks for all the tips!!!

Those games should in general be faster in dos than Win95 on a P166mmx. It was normal back then quit to dos and run them, to get a speedup.
Run Speedsys from phils benchmarks and look at the Hard drive speed results. The only thing I can think is you may be stuck in PIO mode 0 or 1, instead of 4 in the bios.

Riikcakirds wrote on 2023-11-24, 22:29:

The only thing I can think is you may be stuck in PIO mode 0 or 1, instead of 4 in the bios.

Hi there, please be careful with PIO mode 4.
It had a bad reputation for being unreliable.
Using PIO mode 3 might be safer, thus, depending on the hardware.

Also, enabling IDE block mode and 32-Bit transfer in CMOS Setup might improve performance.

Jo22 wrote on 2023-11-24, 22:40:

Hi there, please be careful with PIO mode 4. It had a bad reputation for being unreliable. Using PIO mode 3 might be safer, thus […]
Show full quote

Riikcakirds wrote on 2023-11-24, 22:29:

The only thing I can think is you may be stuck in PIO mode 0 or 1, instead of 4 in the bios.

Hi there, please be careful with PIO mode 4.
It had a bad reputation for being unreliable.
Using PIO mode 3 might be safer, thus, depending on the hardware.

Also, enabling IDE block mode and 32-Bit transfer in CMOS Setup might improve performance.

I've never had any problems with it myself, it's still very slow, around 5-7mb even though it's suppose to support 16MB/s. I don't think I've ever seen a PIO4 mode reach more than 8MB/s, even with an SSD attached .

Oddly enough my motherboard MSI-5120 (intel 430fx chipset) actually has a setting for PIO5 in the AMI bios.It also has an option to enable IDE-Bus Mastering MW-DMA2. This gives 15-16mb/s in realmode DOS without any drivers needed.

Riikcakirds wrote on 2023-11-24, 22:59:

I've never had any problems with it myself, it's still very slow, around 5-7mb even though it's suppose to support 16MB/s. I don't think I've ever seen a PIO4 mode reach more than 8MB/s, even with an SSD attached .

I've never had an issue with PIO 4, either, but some people had warned about it.
That was 20 years ago, of course.
But the information might be good for troubleshooting, though.

Riikcakirds wrote on 2023-11-24, 22:59:

Oddly enough my motherboard MSI-5120 (intel 430fx chipset) actually has a setting for PIO5 in the AMI bios.It also has an option to enable IDE-Bus Mastering MW-DMA2. This gives 15-16mb/s in realmode DOS without any drivers needed.

Thank you for the information. 🙂👍
Speaking of drivers, didn't FreeDOS have some UDMA drivers? 🤔
I've read about them before, but didn't own compatible hardware. 🤷‍♂️

Yes, and I think they were developed by J.R. Ellis, who released them in his own website as XHDD.SYS. You can still download them here, latest version is from last here:
http://optimizr.no-ip.org/dos/drivers.html

For my DOS systems they work really well, they are both IDE driver and disk cache and take way less memory then Smartdrive. If you want to combine it with caching your cd-rom drive he also has a dvd/cd-rom driver that also takes little memory called XDVD2.SYS.

I have tried XHDD's disk caching on my own computer, and it was faster than any other utility but without EMM it caused triple fault when attempting to run some real-mode DOS games (Jazz Jackrabbit and Xatax so far). Currently using it with /B command line switch to simply enable UDMA which doesn't cause that problem.

digistorm wrote on 2023-11-25, 09:02:

Yes, and I think they were developed by J.R. Ellis, who released them in his own website as XHDD.SYS. You can still download them here, latest version is from last here:
http://optimizr.no-ip.org/dos/drivers.html

For my DOS systems they work really well, they are both IDE driver and disk cache and take way less memory then Smartdrive. If you want to combine it with caching your cd-rom drive he also has a dvd/cd-rom driver that also takes little memory called XDVD2.SYS.

Any chance you could post some with and without speedsys benchmarks ?

Yes… these are the results of my CF card with and without XHDD.SYS. The IDE controller is the onboard controller of the AMD 750 chipset, the card is a Transcend Industrial CF card.
Without XHDD.SYS (just BIOS routines):

With XHDD.SYS loaded:

I used the following CONFIG.SYS line:
XHDD.SYS /S96 /H /O

Jazz Jackrabbit runs file without EMM386.EXE by the way. But I do use it with the XMGR.SYS memory manager (with the /R option) and with UMBPCI.SYS to load everything high. I don't remember if HIMEM.SYS caused trouble because XHDD.SYS uses XMS memory for its cache and it cooperates best with XMGR.SYS (from the same author).

digistorm wrote on 2023-11-27, 09:11:

Jazz Jackrabbit runs file without EMM386.EXE by the way. But I do use it with the XMGR.SYS memory manager (with the /R option) and with UMBPCI.SYS to load everything high. I don't remember if HIMEM.SYS caused trouble because XHDD.SYS uses XMS memory for its cache and it cooperates best with XMGR.SYS (from the same author).

I was also thinking that there could be some incompatibility with HIMEM.SYS. Did further testing with XHDD.SYS's disk caching enabled and finally got it running fine without any EMM.

With HIMEM.SYS, more than 14 MB of cache size is troublesome. With XMGR.SYS, it does indeed cooperate very well, the /R command line switch (with the appropriate amount of reserved memory) allowed me to use 25 MB of cache size without problems.

digistorm wrote on 2023-11-27, 09:11:

Yes… these are the results of my CF card with and without XHDD.SYS. The IDE controller is the onboard controller of the AMD 750 […]
Show full quote

Yes… these are the results of my CF card with and without XHDD.SYS. The IDE controller is the onboard controller of the AMD 750 chipset, the card is a Transcend Industrial CF card.
[....]
I used the following CONFIG.SYS line:
XHDD.SYS /S96 /H /O

Thanks for sharing that. It's interesting to me.

Since you have an AMD750 north bridge, you probably have the AMD-756 peripheral bus controller.

1) 8.3MB/s suggests you are getting something close to PIO 3 throughput without the driver
2) With the driver, the buffered read speed is suspect. That controller only supports up to UDMA4, so 106MB/s is too high. Perhaps the built in disk cache is confusing speedsys.
3) I think 40MB/s linear read speed would match up pretty well with what you can hope to see with UDMA4. My experience is that the best CF's max out at about 30-35MB/s, but there's a lot of different CF's in the wild, so maybe out have an outstanding device.
2) Event though UDMA has a shorter cycle time, you are getting higher latency with the driver, which suggests that the driver does some setup overhead before each I/O call.