Now that I think about it, there's merely so much you can do about badly coded software.

How about a more analog solution?
Is it possible to physically reduce the memory on the RAM modules?
Like, using a hot air station to carefully get rid of some chips?

Or, is it possible to disable some modules by cutting their power pin?
So they could still reside in the slot, but have no power?

A good old electro-mechanical relay (miniature, maybe DIL version) could do that, remote controlled over a cable by a battery and a switch.

Edit: The idea was that the RAM module(s) could be enabled/disabled via switch on a front panel.
That way, the PC could be physically limited in memory for the sake of compatibility.
The same could be done to the motherboard's slot, which would look more elegant.
But on the other hand, if something goes wrong.. Modding a single RAM module is safer.

The idea came to mind because my generation (or my previous one) did such mods in the 486 days.

We added switches to toggle IDE HDDs between master/slave, added reset buttons, wired the PC speaker output to an external cable (not the best idea maybe, since the system timer could be damaged).
Or we wired 3 floppy drives and a awitch to a two floppy cable et cetera pp.

Here's the IDE example (mod done by someone in 2006): http://www.stefanv.com/electronics/ide_dual_boot.html

Of course, such a hacky hardware modification needs more courage, time and dedication than tinkering with software alone.

Some old toggle switches sticking out of the front side
may also not be very cool looking in your glossy piano black PC case. ;)

But to the software, it's a more compatible solution in the end.
No software solution beats a physical RAM reduction.

I recommend against enabling the Memory Hole option in the BIOS setting, I had issues with it where it didn't return to the DOS prompt after attempting to exit DOOM.

Jo22 wrote on 2023-02-09, 10:57:

Now that I think about it, there's merely so much you can do about badly coded software.

How about a more analog solution? [unnecessary hardware modding ensues]

How about just investing five-ish bucks into some properly sized modules to install instead?

I created this thread and I spent tens of hours with it.

Read my first post and then there are two solutions:
HimemX from Github
or
R.Loew LIMITMEM.sys

Please do not SPAM this with your brainfart and create your own thread. If you need, you can put 64MB of RAM and you won't encounter this issue.

For others, last post with finished investigation was here: Re: Limit DOS RAM memory (XMSDSK / HimemX / JemmEx), DOS RAM size limit

Gmlb256 wrote on 2023-02-09, 13:42:

I recommend against enabling the Memory Hole option in the BIOS setting, I had issues with it where it didn't return to the DOS prompt after attempting to exit DOOM.

I did not have that experience, tested on two machines. I think one machine even did not need the memory hole. Anyway, you are free to use the second solution. Everyone needs to test it themselves first. The two solutions, both of them do work.

I've seen software behave badly with certain otherwise harmless BIOS settings on some motherboards. Some of the software of this era just has weird bugs that cause DOS to behave badly.

Tried the R.Loew LIMITMEM.sys, however that one doesnt work together with ctmouse. So would require a different mouse driver, which might be an easier solution but still

Hello guys. I have an Apollo Pro 133 chipset Board from MSI MS-6153 with 256Mb RAM, and I am using Phil Computer Lab Dos Start for entering in DOS mode.
Using R.Loew LIMITMEM.sys I cant go lower than 65Mb of XMS, but in config.sys I have the DEVICE=C:\LIMITMEM\LIMITMEM.sys 16
Using BURNMEM
DEVICE=C:\BURNMEM\BURNMEM.SYS 01000000 It displays the 9x string but in the next line it shows "Error"
What I am doing wrong that I cant get only 16Mb of RAM?
Many thanks!

---small edit ----
Tried the Memory HOLE thing in BIOS and the only thing that works is limitmem.sys if DEVICE=C:\LIMITMEM\LIMITMEM.sys 16 .... using DEVICE=C:\LIMITMEM\LIMITMEM.sys 8 will show all the RAM

If you're using EMM386, try adding 16384 to that line and see if it helps.

Since R.Loew's LIMITMEM doesn't work with FreeDOS, is there any other solution to limit the memory to 32 or 64Kb ?
I'm using SBEMU and I must have jemmex as mem manager, so I can't use HIMEM.SYS.
Currently, FreeDOS reports all 2Gb of free memory on my PC, which prevents some games from running properly.

retrofan011 wrote on 2023-06-12, 15:39:

Since R.Loew's LIMITMEM doesn't work with FreeDOS, is there any other solution to limit the memory to 32 or 64Kb ?
I'm using SBEMU and I must have jemmex as mem manager, so I can't use HIMEM.SYS.
Currently, FreeDOS reports all 2Gb of free memory on my PC, which prevents some games from running properly.

JemmEx accepts MAXEXT parameter to set maximum amount of XMS. E.g. /MAXEXT=65535 sets 64MB XMS

Here are some relevant discussions on GitHub:

https://github.com/FDOS/kernel/issues/89

https://github.com/FDOS/kernel/issues/91

https://github.com/Baron-von-Riedesel/HimemX/issues/3

These reports have to do with LIMITMEM not working with FreeDOS, being unable to workaround it with EMM386 (in my case), and reporting and resolving a bug in HimemX for /MAX.

Kahenraz wrote on 2023-06-13, 00:54:

Here are some relevant discussions on GitHub: […]
Show full quote

Here are some relevant discussions on GitHub:

https://github.com/FDOS/kernel/issues/89

https://github.com/FDOS/kernel/issues/91

https://github.com/Baron-von-Riedesel/HimemX/issues/3

These reports have to do with LIMITMEM not working with FreeDOS, being unable to workaround it with EMM386 (in my case), and reporting and resolving a bug in HimemX for /MAX.

Different programs check memory availability differently:
1. Some check only available memory, so tricks to burn excessive RAM (like a RAMDisk) rather than limiting reported maximum memory will work. Win9x itself is such an example.
2. Others check only reported maximum memory size. In this case, tricks to burn excessive RAM will NOT work at all, and RAM limiting tricks may or may not work depending on how the program in question obtains the information about system memory configuration. What worked against one program may not work against another.

If Win3.x's HIMEM.SYS does not misbehave on too new systems then it's the best driver for the job to limit both the available and reported maximum memory size, as it implements a lower XMS standard (2.0) whose limit (up to 64MB) is never going to be a problem for most of the DOS programs of that period, bypassing the need to limit RAM entirely... unless you're dealing with a program that's so old that it expects even less (like <16MB or even worse).

I haven't thoroughly tested the compatibility of Win3.x's HIMEM.SYS with other TSRs as I don't have that many use cases for limiting available/max RAM, but if Win3.x's HIMEM.SYS is compatible enough then there's little need to reinvent the wheel on newer XMS managers.

That's very interesting. I hadn't ever thought about using an older HIMEM.SYS that already had a 64MB limit. That seems perfectly reasonable for DOS. When is more than 64MB ever needed in a pure DOS environment?

The only use case I can think of is higher end "workstation" kinds of environment that might utilize FreeDOS, but then it's no longer a vintage use case. The only other use case I can think of is virtual disks and mounting ISOs into memory, which is not undesirable, but has limited use because there won't be any redbook audio anyways.

Kahenraz wrote on 2023-06-13, 03:54:

That's very interesting. I hadn't ever thought about using an older HIMEM.SYS that already had a 64MB limit. That seems perfectly reasonable for DOS. When is more than 64MB ever needed in a pure DOS environment?

The only use case I can think of is higher end "workstation" kinds of environment that might utilize FreeDOS, but then it's no longer a vintage use case. The only other use case I can think of is virtual disks and mounting ISOs into memory, which is not undesirable, but has limited use because there won't be any redbook audio anyways.

Old HIMEM.SYS had that 64MB limit because it predated XMS 3.0. I'm just not 100% sure if those older HIMEM.SYS versions are friendly with present-day kernels as well as TSRs.

AFAIK no DOS software ever needed that much RAM. My first PC (Pentium 100) had 8MB, later 16MB of RAM and it was more than enough for DOS, as well as Windows 3.x. It was only barely enough to run Windows 95 reasonably fast, however.

I'm also interested in the possibility to use virtual CD drives in DOS. I know about the other parts in the SHSUCD suite that provided the functionality, though redbook audio is still unfortunately not possible. Nowadays to play redbook audio in analog (which DOS expects) you definitely need an IDE optical drive, as SATA optical drives no longer offer the analog header for CD audio between the drive and sound card.

NOTE: In case of newer motherboards, if the board doesn't have IDE ports you can always connect an IDE optical drive to a SATA port with a good-quality IDE-SATA adapter, and it'll work, while you retain the ability to connect an analog CD cable from the drive to your sound card.

at 2008, i begin make LIMEM - little patches for XMGR (another opensource HIMEM, with some redudance features) with user-selectable XMS limitation in 1,2,4...4096 MiB range (by two power). i do it for bypass win98 512 MiB problem (win3.x also have likely problems).
after this, i lost my sources... and create new version LIMEM in 2014. i also want make this dynamic-loadable from command line, as XMSMMGR, but it is not implemented at now...

USAGE:

device=LIMEM.EXE /LX,

where X - any symbol from A,B,C-N range, matched to 0,1,2-12 power, then "total available" XMS size will set to 1,2,4 ... 2^X MiB.
driver also have default limit, for example, 128 MiB, which used, if driver loads as regular HIMEM.SYS without /L switch. it was maked for win98 Safe Mode.
unfortunatelly, there is no fresh XMGR sources in public, so i can't update LIMEM, but old version work good for me and little group friends.

if you interested, i can attach LIMEM here.

=====

ok, binary attached.

MERCURY127 wrote on 2023-06-13, 09:24:

if you interested, i can attach LIMEM here.

Yes, very interested, please post. More programs of this type are always welcomed, and I like that yours will limit XMS based upon a power of 2 factor. That's a good way of doing it.

zyzzle wrote on 2023-06-14, 02:49:

Yes, very interested, please post

ok, previously post updated.

MERCURY127 wrote on 2023-06-14, 06:54:

zyzzle wrote on 2023-06-14, 02:49:

Yes, very interested, please post

ok, previously post updated.

Thank you, very interesting.
TBH, in the end I decided to go back to DOS7.1/Win98 option for my sbemu configuration, primarily for game compatibility.
From FreeDOS I used only a couple of commands: FDISK, FDAPM, FORMAT and DOSLFN, as better alternatives and for now this is very good combo.