Why are you not using any drive cache?
MS-DOS brought SmartDRV and FreeDOS has LBACACHE

On MS-DOS 6.22 which uses FAT16a, you should not be using 16 GB partitions (2 GB should be the maximum)!

And honestly, FreeDOS while commendable as a project, with lots of positive things coming from it, IMHO is neither a fast or efficient DOS distribution. It just works.

I would suggest you give a try IBM PC-DOS 7.1 which is available free for home use, or OpenDOS 7.01 which is also free for non commercial purposes.
There are also other DOS distribution that are less known, but certainly do have some bright spots to learn about. Depends on your time, will and needs.

igully wrote on 2026-02-07, 13:31:

Why are you not using any drive cache? MS-DOS brought SmartDRV and FreeDOS has LBACACHE […]
Show full quote

Why are you not using any drive cache?
MS-DOS brought SmartDRV and FreeDOS has LBACACHE

On MS-DOS 6.22 which uses FAT16a, you should not be using 16 GB partitions (2 GB should be the maximum)!

And honestly, FreeDOS while commendable as a project, with lots of positive things coming from it, IMHO is neither a fast or efficient DOS distribution. It just works.

I would suggest you give a try IBM PC-DOS 7.1 which is available free for home use, or OpenDOS 7.01 which is also free for non commercial purposes.
There are also other DOS distribution that are less known, but certainly do have some bright spots to learn about. Depends on your time, will and needs.

1) SmartDrv offers no gain on flash storage. It's generally recommended not to use it, it just takes up memory and performance is the same. I have confirmed what these forums already say about it elsewhere.

2) I have been using MS-DOS 7.1 from Win98SE since it supports FAT32

I can have a look at PC-DOS and OpenDOS, just not very familiar with those. I am not seeing any regressions when benchmarking FreeDOS vs MS-DOS aside from disk access, that is why I was asking if this is known and if there are things I should be doing. I'll look more deeply into LBACache to determine if it is an analog for SmartDrv or if it has it's own features that make more sense on flash storage.

1) SmartDrv offers no gain on flash storage.

Depends, I would say.. CF cards, for example, have a little buffer of 1 KB and aren't exactly quick at writing or if multiple read/write request happen.

They tend to cause stutter on multitasking OSes such as Windows 98, too, I think.
Enabling DMA helps a bit to hide the symptoms, though.
Only works if the CF adapter has DMA lines, also.
Enabling DMA on unsupported hardware causes Windows 98 to hang on boot.

It's generally recommended not to use it, it just takes up memory and performance is the same.

What comes to mind, there's a SmartDrive alternative in Helix Multimedia Cloaking which takes up little RAM.
I've taken a screenshot here: Re: Can I skip Smartdrive?

The advantage of having SmartDrive or a similar cache loaded is most noticeable if multiple files are loaded from disk, I think.
Some games do load their game data during gameplay and can benefit from a cache.

Another advantage is that data held in RAM doesn't need to travel over ISA bus every time.
That frees more bandwidth for ISA graphics cards or soundcards, maybe.

Another aspect of SmartDrive is that it hold the directory information of the FAT in RAM.
That speeds up DIR command, for example. Or opening files.
The ancient FASTOPEN command does same thing, basically. It's a mini cache.

Jo22 wrote on 2026-02-07, 21:33:

Depends, I would say.. CF cards, for example, have a little buffer of 1 KB and aren't exactly quick at writing or if multiple re […]
Show full quote

1) SmartDrv offers no gain on flash storage.

Depends, I would say.. CF cards, for example, have a little buffer of 1 KB and aren't exactly quick at writing or if multiple read/write request happen.

They tend to cause stutter on multitasking OSes such as Windows 98, too, I think.
Enabling DMA helps a bit to hide the symptoms, though.
Only works if the CF adapter has DMA lines, also.
Enabling DMA on unsupported hardware causes Windows 98 to hang on boot.

It's generally recommended not to use it, it just takes up memory and performance is the same.

What comes to mind, there's a SmartDrive alternative in Helix Multimedia Cloaking which takes up little RAM.
I've taken a screenshot here: Re: Can I skip Smartdrive?

The advantage of having SmartDrive or a similar cache loaded is most noticeable if multiple files are loaded from disk, I think.
Some games do load their game data during gameplay and can benefit from a cache.

Another advantage is that data held in RAM doesn't need to travel over ISA bus every time.
That frees more bandwidth for ISA graphics cards or soundcards, maybe.

Another aspect of SmartDrive is that it hold the directory information of the FAT in RAM.
That speeds up DIR command, for example. Or opening files.
The ancient FASTOPEN command does same thing, basically. It's a mini cache.

I appreciate the feedback, but my main question is why disk performance on FreeDOS is about half of disk performance on MS-DOS 6.22 or 7.1 with the same configurations. I do not experience any of the issues listed above, Win98 loads without any problem, no stuttering, hangs etc. I bought what seems to be a quality CF adapter that carries all lines through, and a decent card as well. But even if I had not, my point is that one MS DOS performance is double what it is on FreeDOS and I'd like to know why.

Any thoughts on that?

^You're welcome. ^^

Any thoughts on that?

I'm afraid I don't know enough to make a proper statement.
My best guess though is that FreeDOS was written the clean way and using C language,
while MS-DOS used quite some assembler code and a few tricks here and there (MS has used C for OSes, too).

Then there are different 8086 memory models: tiny, small, medium, compact, large etc.
Could be that FreeDOS had used a slower model for some reasons.
https://en.wikipedia.org/wiki/X86_memory_models

But that's just a wild guess.
Maybe comparing the source code of both OSes provides some clues about what's really going on?
I'm not that familiar with DOS 7.x, I have to admit. 😅

There's lot of info here but not enough to make final conclusions. It would help if you told us how do you make your speed tests so forum users could replicate it and share their experience. Then I would take a look at difference in config.sys and fdconfig.sys. I don't use clean FreeDOS install but my wild guess it's trying to use long names. Also you didn't state what environment do you use. Is it the same partition for all or is it FAT16 for one OS and FAT32 for the other.

I don't think FreeDOS is any slower but I never made any performance tests versus other DOSes.

I would assume that it’s something trivial such as MS-DOS combining two read requests into one, potentially due to luck/circumstances rather than design.

eM-!3 wrote on 2026-02-10, 06:54:

There's lot of info here but not enough to make final conclusions. It would help if you told us how do you make your speed tests so forum users could replicate it and share their experience. Then I would take a look at difference in config.sys and fdconfig.sys. I don't use clean FreeDOS install but my wild guess it's trying to use long names. Also you didn't state what environment do you use. Is it the same partition for all or is it FAT16 for one OS and FAT32 for the other.

I don't think FreeDOS is any slower but I never made any performance tests versus other DOSes.

System -

Compaq Presario 425 w/AMD 5x86 133Mhz, 20MB FPM RAM, SB AWE64, 3Com 3c509 w/XTIDE boot ROM, Gotek with FlashFloppy installed & IDE->CF adapter with all pins connected and 64GB Sandisk Ultra card.

Operating systems installed into primary 16GB partition formatted FAT32 (I've done a clean install of each) -

- MS-DOS 7.1

1DEVICE=C:\DOS\HIMEM.SYS /SHADOWRAM:ON  /TESTMEM:OFF
2DOS=HIGH,UMB
3DEVICEHIGH=C:\DOS\EMM386.EXE RAM HIGHSCAN I=B000-B7FF ROM=D000-D3FF
4BUFFERS=20,0
5FILES=40
6LASTDRIVE=Z
7FCBS=16,8
8SHELL=C:\DOS\COMMAND.COM /C LH C:\DOS\COMMAND.COM /E:1536 /P
9STACKS=9,256
10
11DEVICE=C:\DOS\SETVER.EXE

- FreeDOS 1.4

1DEVICE=C:\FREEDOS\BIN\HIMEMX.EXE
2DEVICE=C:\FREEDOS\BIN\JEMM386.EXE RAM X=TEST I=B000-B7FF S=D000-D3FF
3DOS=HIGH,UMB
4DOSDATA=UMB
5SET DOSDIR=C:\FREEDOS
6COUNTRY=001,858,C:\FREEDOS\BIN\COUNTRY.SYS
7LASTDRIVE=Z
8BUFFERS=20,0
9FILESHIGH=40
10FCBS=16,8
11STACKS=9,256
12SHELLHIGH=C:\FREEDOS\BIN\COMMAND.COM C:\FREEDOS\BIN /E:1024 /P=C:\FDAUTO.BAT

- Windows 98SE (no special config.sys)

Disk performance test results using disktest.exe

MS-DOS 7.1: ~4MB/sec read/write
FreeDOS 1.4: ~450kb/sec read/write (using JEMMX)
FreeDOS 1.4: ~2MB/sec read/write (if I substitute himem.sys/emm386.exe with the MS-DOS parameters)
Windows 98SE: ~12MB/sec read/write (this is near the theoretical maximum of PIO-4 after overhead, especially when factoring in the 486 CPU)

I have no idea how good of a test disktest is, but the performance gains are real, using FreeDOS for instance with JemmX trying to play Master of Orion 2 it stutters even in menu screens, lots of audio crackling. Loading EMM386 instead of JEMMX makes it playable, and using MS-DOS it's buttery smooth.

I feel like FreeDOS is not doing something by default that MS-DOS does, and also that it does not have a ROM shadow function in it's memory manager like EMM386 does, but I was hoping someone here had more experience with it and could tell me if there is a way to do this or if it's just a limitation of FreeDOS.

reflexve wrote on 2026-02-10, 22:57:

I feel like FreeDOS is not doing something by default that MS-DOS does, and also that it does not have a ROM shadow function in it's memory manager like EMM386 does, but I was hoping someone here had more experience with it and could tell me if there is a way to do this or if it's just a limitation of FreeDOS.

You're correct about the missing ROM shadow function in Jemm ( I'm the maintainer so I should know ).
One can "easily" add such a feature by writing a so-called JLM - actually, Jemm does already implement shadowing region ff000h-fffffh, but this is to catch reboot actions, not to speed-up disk access.

What's probably more convenient if you aren't a programmer is to install a "multiple sector" HDD DOS driver. Accessing IDE drives with so-called multiple-sector commands was one of the first improvements in the pre-DMA and pre-LBA times of IDE. If your HDD supports this feature, speed may increase noticeable.

Attached is such a driver - it intercepts BIOS int 13h, functions 02/03 ( read/write) if the HDD supports multiple sector access. But better try it in an emulator first ( I used 86Box ), there's absolutely no guarantee that it works. Also, it knows CHS access only, so it's restricted to 8 GB.

1. I don't use XTIDE on my real PC but I have a 32GB CF card with FAT32 partition for DOS.
2. I didn't saw any significant difference in results between MS-DOS and FreeDOS using "disktest.exe size=64M". With EMM386 2.26 (which was removed from latest FreeDOS) or JEMMEX it was a little bit slower. But nothing like 5x or 10x slower.
3. I use XHDD.SYS driver. It results in slightly better performance on my setup but nothing important. I might even reconsider the point of using it at all.

Baron von Riedesel wrote on 2026-02-11, 08:22:

You're correct about the missing ROM shadow function in Jemm ( I'm the maintainer so I should know ). One can "easily" add such […]
Show full quote

reflexve wrote on 2026-02-10, 22:57:

I feel like FreeDOS is not doing something by default that MS-DOS does, and also that it does not have a ROM shadow function in it's memory manager like EMM386 does, but I was hoping someone here had more experience with it and could tell me if there is a way to do this or if it's just a limitation of FreeDOS.

You're correct about the missing ROM shadow function in Jemm ( I'm the maintainer so I should know ).
One can "easily" add such a feature by writing a so-called JLM - actually, Jemm does already implement shadowing region ff000h-fffffh, but this is to catch reboot actions, not to speed-up disk access.

What's probably more convenient if you aren't a programmer is to install a "multiple sector" HDD DOS driver. Accessing IDE drives with so-called multiple-sector commands was one of the first improvements in the pre-DMA and pre-LBA times of IDE. If your HDD supports this feature, speed may increase noticeable.

Attached is such a driver - it intercepts BIOS int 13h, functions 02/03 ( read/write) if the HDD supports multiple sector access. But better try it in an emulator first ( I used 86Box ), there's absolutely no guarantee that it works. Also, it knows CHS access only, so it's restricted to 8 GB.

Thank you very much for this comprehensive reply! It is really appreciated. I will try that driver when I have some time and see if it changes things much. Is there any plan to implement ROM shadowing for older systems that don't have that feature in the BIOS, either in JEMM or via an additional tool? If not I understand, you don't work for us!

Thanks again for the clarity and tool!

It sounds like this is something that JLOAD is for.

JEMM is a modular manager with an interface to extend its function.

I just question how to solve the 'cart in front of horse' problem.

To do as Baron suggests, the loaded module would need to allocate XMS memory from the XMM *which might not be JEMMX and co* (or at least get the XMM to stop managing and reporting it), tell JEMM/JEMMX to copy the contents of ROM to that memory for specified addresses, remap the XMS memory to the designated regions, then make the ram read only.

The issue of getting the XMM to cooperate with this is 'the cart', where 'the horse' is this module we are poking at JEMM.

With JEMMEX exclusively, or its siblings, this is not a big deal, but maybe poses a big issue if using some other XMM.

I'm with you in suggesting it should be part of JEMM directly.