schlang wrote:

Seems to be related to its memory, 512 are just too much.

And what specifically leads you to that conclusion?

HIMEMX will let you restrict available memory, though I am not sure if it will work with those games specifically. You can also create a RAM drive to consume some of your available RAM.

If the game has trouble with too much free XMS, you could try filling it up with something useful, like UIDE.

If it's complaining about too much total memory, you'll need to "mask" a part of it with HimemX (=JemmEx).

There is a good existing thread on this! Can't remember the name though 😀

Jorpho wrote:

And what specifically leads you to that conclusion?

starting the game with command line parameter "-x 50" reveals a negative system memory value

jwt27 wrote:

If it's complaining about too much total memory, you'll need to "mask" a part of it with HimemX (=JemmEx).

I think this is what I need - how to? I checked the readme http://www.japheth.de/Jemm/README.html already

schlang wrote:

jwt27 wrote:

If it's complaining about too much total memory, you'll need to "mask" a part of it with HimemX (=JemmEx).

I think this is what I need - how to? I checked the readme http://www.japheth.de/Jemm/README.html already

Check again 😉

1 MAXEXT=l      limit extended memory controlled by XMM to <l> kB.
2 X2MAX=m       limit for free extended memory in kB reported by XMS V2 
3               (default 65535). It is reported that some old applications
4               need a value of <m>=32767.

But If I were you I'd try UIDE first, having a large disk cache provides a serious speed boost. Here is an example:

1        REM /D: = CD device driver
2        REM /H  = Load to HMA
3        REM /F  = Use large (fast) cache blocks
4        REM /Sn = n MB cache
5        REM /Rn = Use memory above n MB
6 1?DEVICEHIGH=C:\DOS\BIN\UIDE.SYS  /D:FDCD0001 /H /F /S128 /R63

jwt27 wrote:

But If I were you I'd try UIDE first, having a large disk cache provides a serious speed boost. Here is an example: […]
Show full quote

But If I were you I'd try UIDE first, having a large disk cache provides a serious speed boost. Here is an example:

Copy code to clipboard

1        REM /D: = CD device driver
2        REM /H  = Load to HMA
3        REM /F  = Use large (fast) cache blocks
4        REM /Sn = n MB cache
5        REM /Rn = Use memory above n MB
6 1?DEVICEHIGH=C:\DOS\BIN\UIDE.SYS  /D:FDCD0001 /H /F /S128 /R63

works! excellent thx guys 😀

I loved using extra RAM for a huge cache. Pure cache hits were a serious turbo boost.

I find it ironic how games back then used to always be demanding more memory in order to run but then when you gave it to them they still wouldn't run because you gave them too much. 🤣

sliderider wrote:

I find it ironic how games back then used to always be demanding more memory in order to run but then when you gave it to them they still wouldn't run because you gave them too much. 🤣

I remember when we maxed out our 486dx66 with 32mb "just because". It was a total waste since it ran fine on 16mb.

Now fast forward and imagine the same programs trying to deal with 256mb of memory. 😵 They just didn't expect something like that.

I wonder how much the whole finackyness of memory changed after the first 1mb? Is it basically the same all the way up to 4gb?

from a programatically point of view you can easily explain such things e.g. chosing the wrong datatype.
no one would expect that their games are still being played after 20 years 😀

What really interesting is that sometimes you DO need to physically reduce RAM size. (Because the game checks/adds up all you have in the system) Fortunately, EATXMS and similar utilities work in more than 90% of all cases. The above discussed RAM drives are more useful, of course. I also recall lighter issues when only the size of EMS is checked - here, you only have to restrict available EMS in the EMM386 command line.
Another funny thing is when games/apps check if the system has free base memory in a certain range (say, like between 590kb and 630kb). When you install a memory manager like QEMM and choose to beef up the conventional memory range (merge with UMBs?) to about 700Kb, these games/apps will bail out instantly 😵

schlang wrote:

from a programatically point of view you can easily explain such things e.g. chosing the wrong datatype.
no one would expect that their games are still being played after 20 years 😀

Ah yes, quite true!

Jolaes76 wrote:

What really interesting is that sometimes you DO need to physically reduce RAM size. (Because the game checks/adds up all you have in the system) Fortunately, EATXMS and similar utilities work in more than 90% of all cases. The above discussed RAM drives are more useful, of course. I also recall lighter issues when only the size of EMS is checked - here, you only have to restrict available EMS in the EMM386 command line.
Another funny thing is when games/apps check if the system has free base memory in a certain range (say, like between 590kb and 630kb). When you install a memory manager like QEMM and choose to beef up the conventional memory range (merge with UMBs?) to about 700Kb, these games/apps will bail out instantly 😵

QEMM always had some funky issues. It was really good prior to the advent of himem and emm386 in dos 6. Then you could achieve virtually the same thing using native DOS stuff. Although that merging feature of QEMM was way cool. 😎

There is a reason I got 16MB SDRAM for my Super Socket 7 Time-machine system 😀

Well, my DOS PC use the MSDOS 6.22 himem.sys. It have 64 MB limit.

EMS/XMS was not the problem here.
UIDE is indeed quite cool and solves two issues at once

this has been discussed in depth in another thread, my solution for my ss7/128MB machine is xmsdsk/emsdsk , they are ramdisks that you can load/unload and they consume successfully the extra ram that causes trouble.
The /t switch they have is also valuable since it forces them to load above the first 16MB of ram, leaving it free for even more troublesome games. It can be easily used in batch files without limitations.
Find it attached, it solved my problems just fine.

schlang wrote:

EMS/XMS was not the problem here.
UIDE is indeed quite cool and solves two issues at once

Plus you'll get a "free" CD-ROM driver with it (costs only a few bytes) 😀

Gamecollector wrote:

Well, my DOS PC use the MSDOS 6.22 himem.sys. It have 64 MB limit.

I use the one from win98se and am able to get a lot higher than that.

Come to think of it though, we had 128MB in our old Cyrix system and it ran win3.1. And I know himem saw all 128MB. 😕