rishooty wrote:

That's why. Phil reported issues with UDVD/XDVD, SHSUCDX, and JEMM386 as being the main culprits of freedos's compatibility issues.

[EDIT] To be fair though, some of the compatibility reports I'm posting are from 2016 or older. XDVD2 and XHDD probably have improved lots since then.

I'm not sure about UDVD/XDVD, but UIDE when used with hard disk caching (now the XHDD part) could trigger system reboots when used with UMBPCI (which is in real mode), for programs that used Borland's 16-bit DPMI runtime (RTM). Tyrian 2000 (namely its setup program) was such example. The system reset doesn't occur when using JEMM386, but on the first 2 runs it'll exit with unhandled exceptions. On the 3rd run the program starts running correctly. What exactly caused this phenomenon is unknown, but it's possible that the first few unhandled exceptions were caused by the CPU registers being in invalid states which got corrected after a few times and allowed the program to start later on.

I do remember seeing suggestions (on BTTR) that by running HX's DPMI runtime before running the problematic programs would fix the issues such as system reboots, but I haven't tested personally. From the look of it, HX appeared to be able to correct misbehaviors of some programs, even on DOSBox.

Not sure if JEMM386 could possibly implement a port trapping capability that are compatible with the proprietary ones present in MS EMM386 (and very likely in QEMM) in the future, as both MS EMM386 and QEMM have problems with handling very large RAM (256MB or above) and can only be considered viable in period-correct builds.

Most of the issues typically don't occur when using first-party MS stuffs (MS-DOS, HIMEM, MS EMM386, SMARTDRV, MSCDEX, etc.), despite they consume much more RAM, regardless of system configurations (at least for SMARTDRV and MSCDEX, even when using with 3rd-party memory managers on a system with very large RAM, since you have to use one of those on such environments).

New DOS drivers implemented certain functionalities differently from the old ones using more optimized and efficient approaches that consume less RAM compared to the original ones, and this might be the cause of breakage with certain programs/runtimes that were made with original drivers (such as MS EMM386, SMARTDRV, MSCDEX) in mind, so patches or workarounds might be needed to get those problematic programs/runtimes working as they should.

LSS10999 wrote:

Not sure if JEMM386 could possibly implement a port trapping capability that are compatible with the proprietary ones present in MS EMM386 (and very likely in QEMM) in the future, as both MS EMM386 and QEMM have problems with handling very large RAM (256MB or above) and can only be considered viable in period-correct builds.

The docs say so, although it would require a different code path from MS EMM386 and QEMM. So, compatible in terms of function if not binary compatible.
*START HERE* SoftMPU 1.91 - Software Intelligent MPU-401 Emulator

Well, it looks like after all my testing and research, Phil honestly has the best setup for compatibility and simplicity. Other than replacing a few disk based utilities and himem, there's pretty much nothing to improve. Even after trying other maxed out setups, they all rely on UMBPCI and newer/smaller utilities to achieve their high conventional memories while still having tons of TSRs loaded.

My list pretty much just ended up being:
FreeDOS CHKDSK
FreeDOS FDISK
FreeDOS FORMAT
HIMEMX overwriting HIMEM
Installing a write combiner like FASTVID after install, if applicable to your cpu

It seems the changes worth making are so small I can't even justify writing a utility or even packaging them. You can just extract the floppy images, overwrite a few files, and you're good. It can also be used in tandem with my 9x slipstreamer and other updates. But all my packs already have updated fdisk and format, and I'm probably gonna add HimemX and FreeDOS chkdsk to them anyway. I'll also update their companion bootdisks.

Thanks for the help everyone!

I've tested Screamer 2, it doesn't run with this configuration:

Config.sys DEVICE=C:\DOS\XMGR.SYS /B DEVICE=C:\DOS\EMM386.EXE NOEMS NOVCPI HIGHSCAN I=B000-B7FF DEVICEHIGH=C:\DOS\DISPLAY.SYS CO […]
Show full quote

Config.sys
DEVICE=C:\DOS\XMGR.SYS /B
DEVICE=C:\DOS\EMM386.EXE NOEMS NOVCPI HIGHSCAN I=B000-B7FF
DEVICEHIGH=C:\DOS\DISPLAY.SYS CON=(EGA,,1)
rem DEVICEHIGH=C:\DOS\XHDD.SYS C+ /N /Q /U
DEVICEHIGH=C:\DOS\XDVD2.SYS /D:OPTICAL

Autoexec.bat
C:\DOS\SHSUCDX.COM /D:OPTICAL

but it does with this one:

Config.sys DEVICE=C:\DOS\XMGR.SYS DEVICEHIGH=C:\DOS\DISPLAY.SYS CON=(EGA,,1) DEVICEHIGH=C:\DOS\XHDD.SYS C+ /N /Q /U DEVICEHIGH=C […]
Show full quote

Config.sys
DEVICE=C:\DOS\XMGR.SYS
DEVICEHIGH=C:\DOS\DISPLAY.SYS CON=(EGA,,1)
DEVICEHIGH=C:\DOS\XHDD.SYS C+ /N /Q /U
DEVICEHIGH=C:\DOS\XDVD2.SYS /D:OPTICAL

The autoexec.bat is the same
Upon further testing the problem is the /B switch on XMGR, taking it off solve the problem.

That's because /B is meant for use with UMBPCI. Good to know XDVD seems to be ok now, but try it with some disc based games. That's also where shsucdx seems to have issues.

I always keep some menu options in my CONFIG.SYS for switching between memory managers.

Usually I have:

• HIMEM only
• HIMEM + EMM386
• HIMEM + EMM386 NOEMS
• JEMMEX

And I keep JEMMEX the default, as it gives me the most free memory, until I have to run the odd game or program that doesn't like it, in which case I'll choose whichever of the other ones works best.

rishooty wrote:

That's because /B is meant for use with UMBPCI. Good to know XDVD seems to be ok now, but try it with some disc based games. That's also where shsucdx seems to have issues.

Any suggestion about what game to try?

Dumb question, where can I find the switches for XHDD.SYS?

Thanks

Edit: SHSUCDX doesn't work with the need for speed, error on reading a file just after typing install:
cdromdirectoryentry - ERROR 2 READING DIRECTORY /frontend\movielow\ea.tgv
fixed with reverting back to mscdex.

Try the games I posted from Phil's video. As for xhdd I believe it's the same as smartdrv. I'm sure you can run it with /? Or -help too.

[EDIT] Redacted unfair claim regarding documentation

rishooty wrote:

Try the games I posted from Phil's video. As for xhdd I believe it's the same as smartdrv. Yeah jack isn't exactly the best at documentation. I'm sure you can run it with /? Or -help too.

Well now we know that at least need for speed doesn't work with SHSUCDX, it's enough to get back to mscdex 🤣
Also SHSUCDX isn't updated since 2013...

gdjacobs wrote:

LSS10999 wrote:

Not sure if JEMM386 could possibly implement a port trapping capability that are compatible with the proprietary ones present in MS EMM386 (and very likely in QEMM) in the future, as both MS EMM386 and QEMM have problems with handling very large RAM (256MB or above) and can only be considered viable in period-correct builds.

The docs say so, although it would require a different code path from MS EMM386 and QEMM. So, compatible in terms of function if not binary compatible.
*START HERE* SoftMPU 1.91 - Software Intelligent MPU-401 Emulator

I saw that, just not sure if existing programs that relied on such functionality would like it. From what I remember, the DOS TSR for Sound Blaster PCI/Live cards also relied on it.

If SoftMPU works well with JEMM's IOTRAP then it's probably usable enough to be considered a replacement.

keenmaster486 wrote:

I always keep some menu options in my CONFIG.SYS for switching between memory managers. […]
Show full quote

I always keep some menu options in my CONFIG.SYS for switching between memory managers.

Usually I have:

• HIMEM only
• HIMEM + EMM386
• HIMEM + EMM386 NOEMS
• JEMMEX

And I keep JEMMEX the default, as it gives me the most free memory, until I have to run the odd game or program that doesn't like it, in which case I'll choose whichever of the other ones works best.

What do you need EMM386 NOEMS for?

Nemo1985 wrote:

rishooty wrote:

Try the games I posted from Phil's video. As for xhdd I believe it's the same as smartdrv. Yeah jack isn't exactly the best at documentation. I'm sure you can run it with /? Or -help too.

Well now we know that at least need for speed doesn't work with SHSUCDX, it's enough to get back to mscdex :lol:
Also SHSUCDX isn't updated since 2013...

Welp, keep trying out cd games. I've already updated my update packs with xmgr and chkdsk, they all test just fine. The next thing I want to do is see if there's anything I can add/improve about Phil's DOS setups.

Namely, we already know that replacing HIMEM has little consequences compared to say, EMM386, so using xmgr would be one improvement. The couple of others I'm thinking of relevant to gaming are:
ZENO174 (speeds up all dos text screen writes and scrolls)
NANSI.SYS (console accelerator driver)
XDVD2 (if Nemo1985 can prove digital audio is no longer an issue)
Maxing out MODE.COM's keyboard response
HYPERKEY for even faster keyboard response
SMARTDRV or XHDD the C: and D: drives
Including XMSDSK in case a game needs memory limits
RECALL for usability's sake
Including LFN tools (the standalone ones that don't require a driver)

rishooty wrote:

Welp, keep trying out cd games. I've already updated my update packs with xmgr and chkdsk, they all test just fine. The next thi […]
Show full quote

Nemo1985 wrote:

rishooty wrote:

Try the games I posted from Phil's video. As for xhdd I believe it's the same as smartdrv. Yeah jack isn't exactly the best at documentation. I'm sure you can run it with /? Or -help too.

Well now we know that at least need for speed doesn't work with SHSUCDX, it's enough to get back to mscdex :lol:
Also SHSUCDX isn't updated since 2013...

Welp, keep trying out cd games. I've already updated my update packs with xmgr and chkdsk, they all test just fine. The next thing I want to do is see if there's anything I can add/improve about Phil's DOS setups.

Namely, we already know that replacing HIMEM has little consequences compared to say, EMM386, so using xmgr would be one improvement. The couple of others I'm thinking of relevant to gaming are:
ZENO174 (speeds up all dos text screen writes and scrolls)
NANSI.SYS (console accelerator driver)
XDVD2 (if Nemo1985 can prove digital audio is no longer an issue)
Maxing out MODE.COM's keyboard response
HYPERKEY for even faster keyboard response
SMARTDRV or XHDD the C: and D: drives
Including XMSDSK in case a game needs memory limits
RECALL for usability's sake
Including LFN tools (the standalone ones that don't require a driver)

Are you using chkdsk with fat32 drives? Because I tried the freedos replacements and they just doesn't work neither dosfsck od chkdsk, I switched back to scandisk from win98.
A tool that I haven't been able to find is a defrag for fat32 that works in dos.

About SHSUCDX, the developer said will try to debug the problem with the need for speed.

I tested Tomb Raider with XDVD2, everything seems fine to me, audio is ok both in game and during the movie after starting new game and the video before Lara's House.

Next I test Fade to black, phil's reported an error with SHSUCDX, if i'm going to have the same issue I will report to the developer.

Nemo1985 wrote:

Are you using chkdsk with fat32 drives? Because I tried the freedos replacements and they just doesn't work neither dosfsck od c […]
Show full quote

Are you using chkdsk with fat32 drives? Because I tried the freedos replacements and they just doesn't work neither dosfsck od chkdsk, I switched back to scandisk from win98.
A tool that I haven't been able to find is a defrag for fat32 that works in dos.

About SHSUCDX, the developer said will try to debug the problem with the need for speed.

I tested Tomb Raider with XDVD2, everything seems fine to me, audio is ok both in game and during the movie after starting new game.

Excellent! Then XDVD2 is now a viable replacement. And XHDD seems fine so long as you don't use umbpci, which is system specific and has issues in itself.

Also thanks for letting me know about chkdsk, I'll remove it from my packs.

Nemo1985 wrote:

A tool that I haven't been able to find is a defrag for fat32 that works in dos.

Try freedos' defrag. Assuming that you're using the win98 dos to have fat32 partitions, you need to run "lock" beforehand.

konc wrote:

Nemo1985 wrote:

A tool that I haven't been able to find is a defrag for fat32 that works in dos.

Try freedos' defrag. Assuming that you're using the win98 dos to have fat32 partitions, you need to run "lock" beforehand.

Thanks for the tip, what do you mean by run "lock"? I tried the defrag but it "I simply refuse to run in windows".

edit: I also tried lock defrag.exe but it says: operation failed, then I tried lock I said yes to confirmation message but again when ran defrag I got the same error message about not running it with windows.

LSS10999 wrote:

I saw that, just not sure if existing programs that relied on such functionality would like it. From what I remember, the DOS TSR for Sound Blaster PCI/Live cards also relied on it.

If SoftMPU works well with JEMM's IOTRAP then it's probably usable enough to be considered a replacement.

SoftMPU would need a new build or code path to use JEMM for port trapping, just as it has for QEMM versus MS EMM386. Binary only TSRs would require patching or maybe some form of layering which may not be possible.

As a side note, if anyone is willing to try Descent 2 with SHSUCDX, XDVD2 and XHDD, I will be grateful, i'm actually playing with PC em because my socket 7 pc is under maintenance, unlucky it has a bug that will not make run the Test Redbook audio.
Thanks in advance.

I did a bunch of testing, and once again confirmed that phil has the best setup, and that the only replacements worth really doing is FreeDOS format, FREEDOS fdisk, and XMGR over himem. I made a pretty feature complete setup with high compatibility, but I noticed that I could never quite get past 560kb even on the non mouse/non cd settings (due to the need for older components to maintain compatibility). It seems the tradeoffs of loading too many TSRs are too great, even if they're useful. Ehh, guess I won't make a dos slipstreamer or pack to accompany it then, most everything is done post install with things that aren't entirely replacements anyway. This thread was still extremely useful though, and allowed me to improve my windows update packs with xmgr to raise their memory limits with no known consequences.

If anything, a separate menu option in addition to phil's existing ones with modern components would make more sense, similar to what keenmaster486 does with JEMMEX. And that's assuming we even need 600kb+ with mouse, keyboard, and high/extended memory. The other problem is there'd be no way to make this generic, the optimal setup is different for every machine. For example UMBPCI doesn't work on every chipset and XDVD/XHDD need special switches for older chipsets.

Sadly I feel you are right.
I'm testing Descent2 with a socket 7 platform and it seems the only way to make the Redbook audio to work is using smartdrive plus mscdex and videccd.
I will do some more tests tomorrow.

Edit: I finally found the culprit, I had to change the sound card to a more common Sound Blaster 16, switching from xdvd2 to vide-cdd the test works fine, the other programs works fine (xhdd and shsucdx).

I've tested fade to black as promised, it works fine with shsucdx, installation and gameplay (with pcem)