I have two suggestions for you: 1. Try adding "i=b000-b7ff" to EMM386's command line. It should do nothing to your setup, as everything you have already fits in UMBs, but would give you more memory with which to play. That section is for the monochrome video buffer but is highly unlikely to be used. 2. Try Googling "QEMM." It will give you more base memory. BTW, the values in parentheses are just the same values as without, just measured in k instead of bytes. Does this help?

Are there any games that need more than 604KB? 612KB should make all games work IMO. If a game is crashing on you, it's most probably something else.. an incompatibility most probably, which is why I prefer to stick to original DOS drivers (HIMEM, EMM386, an old CDROM driver, MSCDEX, GMOUSE or MS MOUSE). I use those and also get 612KB free conventional, and everything loads fine (games, Windows 3.1, etc).

626,608 bytes will round to 612KB when divided by 1024. A kilobyte has 1024 bytes in it, not 1000. No issues here.

Ah ok i see.
Well Elder Scrolls Arena crash's with Insufficient Base Memory. But ok its a buggy game..
Add EMM386 parameters dont change anything. I also tryed QEMM but it gives me a reboot when i try to install

Try these:

DEVICE=C:\DOS\EMM386.EXE RAM I=B400-B7FF (or B000-B7FF as Harry Potter suggested)
FILESHIGH=20
BUFFERSHIGH=16
LASTDRIVEHIGH=G
FCBSHIGH=4,0

Also stacks might be loading into the base memory. Try adding this:

STACKSHIGH=9,256

You can also run MEM/D/P to get a detailed view of what's loaded, and where.

However, as wbahnassi mentioned, 612 KB should be enough for Arena. Something else might be going on.

EDIT:

Also, if the game doesn't require EMS memory, you can add NOEMS to EMM386. That'd free up 4 UMBs (64 KB).

You may try to move the environment vatiables to the END of autoexec.bat; at least below the TSRs loaded (but that just will free some space in UMBs).

While QEMM is being installed, it will reboot several times to determine your current setup then a couple more times to check its results. BTW: eddman, thank you for quoting me. 😀

eddman wrote on 2023-12-29, 14:09:

Try these: […]
Show full quote

Try these:

DEVICE=C:\DOS\EMM386.EXE RAM I=B400-B7FF (or B000-B7FF as Harry Potter suggested)
FILESHIGH=20
BUFFERSHIGH=16
LASTDRIVEHIGH=G
FCBSHIGH=4,0

Also stacks might be loading into the base memory. Try adding this:

STACKSHIGH=9,256

You can also run MEM/D/P to get a detailed view of what's loaded, and where.

However, as wbahnassi mentioned, 612 KB should be enough for Arena. Something else might be going on.

He isn't running FreeDOS. He's running MS-DOS.

Disruptor wrote on 2023-12-29, 14:22:

He isn't running FreeDOS. He's running MS-DOS.

I'm not using FreeDOS; never have, I think.

Which of those don't work in DOS 6.x? I'm using DOS 7 of Windows 98 and they work there at least.

EDIT:

Ok, apparently HIGH doesn't work for those on Pre-7 DOS.

Somehow your BIOS seems to steal 5KB (conventional is only 635K instead of 640K). Otherwise it is as good as it gets. I use ndos as a COMMAND.COM replacement (which is Norton’s version of 4DOS), which buys me another 3KB, but really anything beyond 610K is not worth fiddling.

Ringding wrote on 2023-12-29, 14:33:

Somehow your BIOS seems to steal 5KB (conventional is only 635K instead of 640K). Otherwise it is as good as it gets. I use ndos as a COMMAND.COM replacement (which is Norton’s version of 4DOS), which buys me another 3KB, but really anything beyond 610K is not worth fiddling.

hmm maybe video shadow enable use the 5kb, have to check.

5kB sounds like EzDrive overlay... If that is it, then XT-IDE would only steal 1kB. 😉 And if you find an updated BIOS, you may not need any drive overlay at all.

Depending on what machine you have, you might be able to use UMBPCI. With that you can get rid of himem being in conv. memory and don't need emm386 for enabling UMB. (You still need emm386 for EMS memory, if you want it, but you can load it high with UMBPCI)

JEMM and QEMM can do some dark magic, too. I've seen some almost silly numbers with them. But compatibility may not be the best exactly because of that.

Disruptor wrote on 2023-12-29, 14:11:

You may try to move the environment vatiables to the END of autoexec.bat; at least below the TSRs loaded (but that just will free some space in UMBs).

What's the explanation for this?

eddman wrote on 2023-12-29, 14:31:

I'm not using FreeDOS; never have, I think. […]
Show full quote

Disruptor wrote on 2023-12-29, 14:22:

He isn't running FreeDOS. He's running MS-DOS.

I'm not using FreeDOS; never have, I think.

Which of those don't work in DOS 6.x? I'm using DOS 7 of Windows 98 and they work there at least.

EDIT:

Ok, apparently HIGH doesn't work for those on Pre-7 DOS.

Some of these HIGH variants for commands work with MS-DOS 7.0 (and newer) and Caldera's DR-DOS 7.02 (and newer), but I don't remember which one works for which version of DOS. If I recall correctly all of them have to work fine in FreeDOS.

analog_programmer wrote on 2023-12-29, 16:33:

Some of these HIGH variants for commands work with MS-DOS 7.0 (and newer) and Caldera's DR-DOS 7.02 (and newer), but I don't remember which one works for which version of DOS. If I recall correctly all of them have to work fine in FreeDOS.

They are listed here: https://en.wikipedia.org/wiki/CONFIG.SYS

You can load the TSRs, which are normally loaded from AUTOEXEC.BAT, from within CONFIG.SYS using the INSTALL=/INSTALLHIGH= command. (I do find it funny that I hardly ever see people do this)
This will save you some bytes due to the environment size being minimal at this point.
After CONFIG.SYS processing has finished, the environment size is?/ can be expanded by using the SHELL=/SHELLHIGH= command from CONFIG.SYS with the added /E:<size> parameter.
Any TSR being loaded from AUTOEXEC.BAT will use and thus add this larger environment size to its memory usage.

weedeewee wrote on 2023-12-29, 16:58:

You can load the TSRs, which are normally loaded from AUTOEXEC.BAT, from within CONFIG.SYS using the INSTALL=/INSTALLHIGH= comma […]
Show full quote

You can load the TSRs, which are normally loaded from AUTOEXEC.BAT, from within CONFIG.SYS using the INSTALL=/INSTALLHIGH= command. (I do find it funny that I hardly ever see people do this)
This will save you some bytes due to the environment size being minimal at this point.
After CONFIG.SYS processing has finished, the environment size is?/ can be expanded by using the SHELL=/SHELLHIGH= command from CONFIG.SYS with the added /E:<size> parameter.
Any TSR being loaded from AUTOEXEC.BAT will use and thus add this larger environment size to its memory usage.

OK, maybe this also explains what I asked for the environment variables place in AUTOEXEC.BAT file. So, is it a good idea to move everything except common env. variables from AUTOEXEC.BAT into CONFIG.SYS if not using menu items options and (just for example) SHELL/SHELLHIGH=COMMAND.COM /E:4096 at last row in CONFIG.SYS?

analog_programmer wrote on 2023-12-29, 17:16:

weedeewee wrote on 2023-12-29, 16:58:

You can load the TSRs, which are normally loaded from AUTOEXEC.BAT, from within CONFIG.SYS using the INSTALL=/INSTALLHIGH= comma […]
Show full quote

You can load the TSRs, which are normally loaded from AUTOEXEC.BAT, from within CONFIG.SYS using the INSTALL=/INSTALLHIGH= command. (I do find it funny that I hardly ever see people do this)
This will save you some bytes due to the environment size being minimal at this point.
After CONFIG.SYS processing has finished, the environment size is?/ can be expanded by using the SHELL=/SHELLHIGH= command from CONFIG.SYS with the added /E:<size> parameter.
Any TSR being loaded from AUTOEXEC.BAT will use and thus add this larger environment size to its memory usage.

OK, maybe this also explains what I asked for the environment variables place in AUTOEXEC.BAT file. So, is it a good idea to move everything except common env. variables from AUTOEXEC.BAT into CONFIG.SYS if not using menu items options and (just for example) SHELL/SHELLHIGH=COMMAND.COM /E:4096 at last row in CONFIG.SYS?

It's been a long time since I played around with it, so i'm not 100% certain about it.
I think setting the environment size to 4k like in your example would make any TSR use ~4K more memory when loaded from dos or command prompt.

Is this wrong then, or I'm not understanding it correctly?

In the past, INSTALL may have saved you a little bit of memory because it does not create an environment when it loads a program. With DOS 6.0 an environment is created, so the extra memory is no longer gained by using the INSTALL command (memory-resident programs can still be loaded from the AUTOEXEC.BAT file).

https://home.csulb.edu/~murdock/install.html

eddman wrote on 2023-12-29, 18:20:

Is this wrong then, or I'm not understanding it correctly?

In the past, INSTALL may have saved you a little bit of memory because it does not create an environment when it loads a program. With DOS 6.0 an environment is created, so the extra memory is no longer gained by using the INSTALL command (memory-resident programs can still be loaded from the AUTOEXEC.BAT file).

https://home.csulb.edu/~murdock/install.html

Best way to figure out if it's wrong/incomplete/correct would be to test it and post the results of the experiments 😉

weedeewee wrote on 2023-12-29, 18:06:

analog_programmer wrote on 2023-12-29, 17:16:

weedeewee wrote on 2023-12-29, 16:58:

You can load the TSRs, which are normally loaded from AUTOEXEC.BAT, from within CONFIG.SYS using the INSTALL=/INSTALLHIGH= comma […]
Show full quote

You can load the TSRs, which are normally loaded from AUTOEXEC.BAT, from within CONFIG.SYS using the INSTALL=/INSTALLHIGH= command. (I do find it funny that I hardly ever see people do this)
This will save you some bytes due to the environment size being minimal at this point.
After CONFIG.SYS processing has finished, the environment size is?/ can be expanded by using the SHELL=/SHELLHIGH= command from CONFIG.SYS with the added /E:<size> parameter.
Any TSR being loaded from AUTOEXEC.BAT will use and thus add this larger environment size to its memory usage.

OK, maybe this also explains what I asked for the environment variables place in AUTOEXEC.BAT file. So, is it a good idea to move everything except common env. variables from AUTOEXEC.BAT into CONFIG.SYS if not using menu items options and (just for example) SHELL/SHELLHIGH=COMMAND.COM /E:4096 at last row in CONFIG.SYS?

It's been a long time since I played around with it, so i'm not 100% certain about it.
I think setting the environment size to 4k like in your example would make any TSR use ~4K more memory when loaded from dos or command prompt.

4 KB space for env. variables is just random value for my command-line example, but I'm interested in the other part of the question: Will it be better, if all device drivers and TSRs are moved in CONFIG.SYS before all the standard DOS variables (at the bottom lines of the very same configuration file) with SHELL(HIGH) at the last place as AUTOEXEC.BAT will contain only common variables as for soundcards settings or similar (some "drivers" for these are not real drivers/TRSs, but registers initializing executables)? Or what's the optimal structure for DOS configuration files?

eddman wrote on 2023-12-29, 18:20:

Is this wrong then, or I'm not understanding it correctly?

In the past, INSTALL may have saved you a little bit of memory because it does not create an environment when it loads a program. With DOS 6.0 an environment is created, so the extra memory is no longer gained by using the INSTALL command (memory-resident programs can still be loaded from the AUTOEXEC.BAT file).

https://home.csulb.edu/~murdock/install.html

If this is true, it makes non-sense from all the DOS 6.22+ variable space INSTALL(HIGH) savings and arrangements in CONFIG.SYS and AUTOEXEC.BAT files. I have to try how it will exactly work in MS-DOS 7.10.