I found UMBINFO.COM useful, but it annoyed me being in German, so I translated it to English. Attached for anyone else interested.

How nobody here has mentioned using 4dos as the command shell.
That was the standard back then for gaming because it could use higher memory and if you had the right video card, could even get you past 640kb free base memory (it was very dodgy and not very usable)

either way 4dos was instrumental at getting some of the more demanding games to work

stijnvanbeselaere@gm wrote on 2025-08-12, 18:00:

How nobody here has mentioned using 4dos as the command shell.
That was the standard back then for gaming because it could use higher memory and if you had the right video card, could even get you past 640kb free base memory (it was very dodgy and not very usable)

either way 4dos was instrumental at getting some of the more demanding games to work

I mentioned it on the previous page.

Re: Dos 6 conventional memory tricks

Searched the entire thread, and then overlooked the one post that has it.. sorry bout that!

stijnvanbeselaere@gm wrote on 2025-09-03, 08:22:

Searched the entire thread, and then overlooked the one post that has it.. sorry bout that!

No worries. Everyone has an off day.

And we get more of those when we get older 😀

I can't recall if anyone here has mentioned it yet, too lazy atm to look/read through it all, but...

FYI.
When using the SHELL command in config.sys to enlarge the environment size, ie ... /E:1536

It comes in handy to load TSRs using INSTALL= or INSTALLHIGH= from config.sys since then they'll still use the small, on boot, environment size and not the enlarged size which will get used when loading TSRs from command line or from AUTOEXEC.BAT.

DivByZero wrote on 2025-05-18, 21:50:

I found UMBINFO.COM useful, but it annoyed me being in German, so I translated it to English. Attached for anyone else interested.

Thank you! I did same in reverse for use!umbs.sys, by the way, because the English annoyed me.
It didn't fit an otherwise entirely German installation of MS-DOS 6.2.

I really should do a proper post here one day on my setup, but I got a config working on my physical 486 where I boot in real mode, and from that single config, I get every game working, all the known problematic ones, by using launch scripts per game that load things as needed, then unload on close to return to stock. I dynamically load/unload jemm to pull in EMS support for things that need it, and return to real mode afterwards. I unload mscdex when games don't need cd support, and load it back in after. I push out memory heavy gravis drivers and the like to free up to 620kb of conventional memory as needed, all of which can be undone when games close. Since I'm running in real mode, I can use at-slow for speed throttling for 286 games and the like. There are some tricks in there, like deliberately eating 2kb of memory during startup, then freeing it, to create a small hole that swallows environment block buffers, to stop memory fragmentation when trying to unload drivers within a batch script before loading a game, but it's all pretty straightforward. Pretty sure nobody has done it before, since unloading jemm for ems support never worked on a 486 until I debugged it with the creator earlier this year. I use it on a machine that runs launchbox for dos, so my kids can just boot, pick any game from the list, and play. No rebooting or having to know which memory config to select at startup. It is possible to "have it all", just takes a bit of setup work.

I tend to remove all the FCBS, last drive entries and the others as I never ran into any issues not having them and it frees up even more memory - I let Memmaker do it's thing and modify from there with lots of testing.
Also built my own DOS Menu system when I was a teen way back, with different booting options and at the end of the Autoexec calls, instead of dropping to a command prompt, some entries would call a "reboot.com" file and trigger a soft reset of the system. banged my head learning the menu syntax from the MS-Dos help file.. hundreds of reboots and attempts to figure it out 🤣 no internet for me at the time

stijnvanbeselaere@gm wrote on 2025-08-12, 18:00:

How nobody here has mentioned using 4dos as the command shell.
That was the standard back then for gaming because it could use higher memory and if you had the right video card, could even get you past 640kb free base memory (it was very dodgy and not very usable)

either way 4dos was instrumental at getting some of the more demanding games to work

You can do that without 4dos. For example, if you movexbda and then load jemm386/ex I=A000-B7FF, then MS-DOS will see 736KB of conventional memory. However, as you say, it's very dodgy to do this because if you run any program that actually used video modes that needed that memory, the results aren't pretty. More advanced methods did cloaking tricks that could avoid some of the dodginess (but not all given the craziness of DOS programs).

There were certainly text-mode apps needing a ton of conventional memory that could use this safely and headless setups could also use this.

DivByZero wrote on 2025-09-04, 13:05:

I really should do a proper post here one day on my setup, but I got a config working on my physical 486 where I boot in real mode, and from that single config, I get every game working, all the known problematic ones, by using launch scripts per game that load things as needed, then unload on close to return to stock. I dynamically load/unload jemm to pull in EMS support for things that need it, and return to real mode afterwards. I unload mscdex when games don't need cd support, and load it back in after. I push out memory heavy gravis drivers and the like to free up to 620kb of conventional memory as needed, all of which can be undone when games close. Since I'm running in real mode, I can use at-slow for speed throttling for 286 games and the like. There are some tricks in there, like deliberately eating 2kb of memory during startup, then freeing it, to create a small hole that swallows environment block buffers, to stop memory fragmentation when trying to unload drivers within a batch script before loading a game, but it's all pretty straightforward. Pretty sure nobody has done it before, since unloading jemm for ems support never worked on a 486 until I debugged it with the creator earlier this year. I use it on a machine that runs launchbox for dos, so my kids can just boot, pick any game from the list, and play. No rebooting or having to know which memory config to select at startup. It is possible to "have it all", just takes a bit of setup work.

You're my hero! I only recently decided to play around to see if it's possible to not ever have to reboot between games while still having as many useful drivers for games loaded. JEMM386's ability to load and enable EMS, then cleanly unload afterwards ended up being the solution.

My goal was to be able to run Lemmings 2, Ultima 7, Wing Commander 2, and Zone66 in any order, unlimited times without needing to reboot and needed JEMM386 to do it.

chronoreverse wrote on 2025-12-09, 18:11:

DivByZero wrote on 2025-09-04, 13:05:

I really should do a proper post here one day on my setup, but I got a config working on my physical 486 where I boot in real mode, and from that single config, I get every game working, all the known problematic ones, by using launch scripts per game that load things as needed, then unload on close to return to stock. I dynamically load/unload jemm to pull in EMS support for things that need it, and return to real mode afterwards. I unload mscdex when games don't need cd support, and load it back in after. I push out memory heavy gravis drivers and the like to free up to 620kb of conventional memory as needed, all of which can be undone when games close. Since I'm running in real mode, I can use at-slow for speed throttling for 286 games and the like. There are some tricks in there, like deliberately eating 2kb of memory during startup, then freeing it, to create a small hole that swallows environment block buffers, to stop memory fragmentation when trying to unload drivers within a batch script before loading a game, but it's all pretty straightforward. Pretty sure nobody has done it before, since unloading jemm for ems support never worked on a 486 until I debugged it with the creator earlier this year. I use it on a machine that runs launchbox for dos, so my kids can just boot, pick any game from the list, and play. No rebooting or having to know which memory config to select at startup. It is possible to "have it all", just takes a bit of setup work.

You're my hero! I only recently decided to play around to see if it's possible to not ever have to reboot between games while still having as many useful drivers for games loaded. JEMM386's ability to load and enable EMS, then cleanly unload afterwards ended up being the solution.

My goal was to be able to run Lemmings 2, Ultima 7, Wing Commander 2, and Zone66 in any order, unlimited times without needing to reboot and needed JEMM386 to do it.

Glad I could help! Like I said, I really should do a proper write-up on it some day, but it's good you were able to figure it out. Unloading JEMM386 really was the missing piece. Once that was fixed and worked reliably for loading/unloading EMS support, everything else was there. The author of JEMM386 deserves the real credit for making that possible at all, that's the real secret sauce, and what was missing back in the day. For my case, I have to dynamically juggle some drivers too in order to free up enough conventional memory for certain games (MSCDEX and the Gravis Ultrasound drivers are the two main culprits), but there are multiple tools out there to allow you do to that, you just need to make sure you consistently unload drivers in the reverse order of loading, which if you're doing launch scripts and you define the "rules" clearly, you can make work. I still have my dos boot menu allowing me to pick from various configs, but unless I'm doing something unusual/specialized, it's just straight into real mode these days and I run everything from there.

DivByZero wrote on Yesterday, 00:16:

For my case, I have to dynamically juggle some drivers too in order to free up enough conventional memory for certain games (MSCDEX and the Gravis Ultrasound drivers are the two main culprits)

Have you tried SHSUCDX? I didn't see you mentioning it when I Ctrl+F'd through the thread and it was part of my DOS machine's stack of drivers for freeing up a bunch of conventional memory while simultaneously getting better functionality before the machine wound up in pieces again on my metaphorical garage floor.

(In SHSUCDX's case, that "better functionality" part is that it supports DVD-sized ISO9660 filesystems too and, aside from two CDs with noncompliant logical sector sizes that Linux won't read either, I haven't had a problem with it yet.)

ssokolow wrote on Yesterday, 03:27:

DivByZero wrote on Yesterday, 00:16:

For my case, I have to dynamically juggle some drivers too in order to free up enough conventional memory for certain games (MSCDEX and the Gravis Ultrasound drivers are the two main culprits)

Have you tried SHSUCDX? I didn't see you mentioning it when I Ctrl+F'd through the thread and it was part of my DOS machine's stack of drivers for freeing up a bunch of conventional memory while simultaneously getting better functionality before the machine wound up in pieces again on my metaphorical garage floor.

(In SHSUCDX's case, that "better functionality" part is that it supports DVD-sized ISO9660 filesystems too and, aside from two CDs with noncompliant logical sector sizes that Linux won't read either, I haven't had a problem with it yet.)

I tried it briefly, but I read plenty of claims of compatibility problems which turned me off it. I found though I simply didn't need it. I didn't find a single game that actually needed CD support, where I couldn't get enough conventional memory under real mode to run it just fine. It's really mscdex and ultramid for the Gravis Ultrasound which are the two problems I encountered. Unload them when you don't need them, and there's no issue. You can do this dynamically. The smallest memory footprint driver is no driver at all.

If I get a chance, I'll power on the 486 sometime later and provide some numbers on my setup.