neither of those configsys entries seem right to me with the loadhigh after /c
I can't recall if dos 6.x already had shellhigh or similar.

moving, deleting or renaming both DBLBUFF.SYS and IFSHLP.SYS should stop them from loading and taking up memory, though ifshlp.sys could be required for windows to operate properly.
They might have some sort of config entry in msdos.sys. You'll have to google for that or maybe someone else still remembers.

I just realized I could check what's being loaded where exactly with MEM/D. Turns out the AUTO mode also loads LASTDRIVE, STACKS and FCBS into upper memory.

I was loading LASTDRIVE without HIGH, and the default for STACKS and FCBS, with NOAUTO, is to go low. After adding HIGH to those, it now almost matches the AUTO mode's behavior.

There is still one small difference; the "Block device tables", which consumes 464 Bytes.

I've looked around but can't figure out what it is.

On PCDOS you can use the DOSDATA=UMB directive to load those structures into upper memory. Perhaps it works on MSDOS as well?

Didn't QRAM from the late 80s use some utilities to load parts of DOS 3.x high ?
If so, they may still be included in QEMM and could be used with MS-DOS 5/6 (similar kernals). It's just a guess, however.

There is very little reason to use DOS=NOAUTO. Unless you have this weird piece of software (most likely some 'demo') that absolutely cannot stand HIMEM.SYS. You'll just end up having to load stuff HIGH manually, as you discovered.

Do you really need that many buffers? You can also use CTMOUSE, unless you hit incompatibility with some games.

Besides, you have 619KB free - what more do you need?

maxtherabbit wrote on 2023-03-11, 15:10:

On PCDOS you can use the DOSDATA=UMB directive to load those structures into upper memory. Perhaps it works on MSDOS as well?

Just tried it. It doesn't work and throws an "unrecognized command" error.

dr_st wrote on 2023-03-11, 21:28:

There is very little reason to use DOS=NOAUTO. Unless you have this weird piece of software (most likely some 'demo') that absolutely cannot stand HIMEM.SYS. You'll just end up having to load stuff HIGH manually, as you discovered.

As mentioned in my post, I'm using it to prevent DBLBUFF.SYS and IFSHLP.SYS from being loaded. IINM they are not needed under DOS (unless 7.x does utilize them somehow?). I do need HIMEM.SYS.

dr_st wrote on 2023-03-11, 21:28:

Do you really need that many buffers? You can also use CTMOUSE, unless you hit incompatibility with some games.

I was testing different values. It seems higher buffers can really help with alleviating long load times and stuttering in games, as an alternative to loading Smartdrv. It doesn't exactly achieve the same results, but gets close.
MOUSE.COM already fits in upper memory, so CTMOUSE isn't needed that much, but I'll probably switch if I end up loading other things.

dr_st wrote on 2023-03-11, 21:28:

Besides, you have 619KB free - what more do you need?

619 KB is more than enough, and is even available with EMS enabled (the NOEMS switch up there was just for testing to make sure insufficient upper memory wasn't the cause by any chance).
With the missing commands now added and all set to HIGH, I get 623 KB free.

It is mostly academic. I was simply trying to understand the reasons for the differences between AUTO and NOAUTO.

The only thing remaining is this "Block device tables". MEM/D shows that AUTO loads it in upper memory. I'm yet to find out what it is exactly and which command corresponds to t.

It's really only about DBLBUFF.SYS. IFSHLP.SYS is loaded high anyways. I believe DoubleBuffer=0 in MSDOS.SYS is another way to prevent DBLBUFF.SYS from loading. I recall reaching 624KB by disabling it.

The reason I never bothered with DOS=NOAUTO is because I liked having a single config for pure DOS and for Windows. I could just type WIN and load Win98 SE from the command prompt without rebooting. Of course, I would have to reboot to get back into DOS.

However, there is some info that suggests that double-buffering can be handy even for DOS games, if set up right (and SMARTDRV is also required):
https://www.mdgx.com/newtip5.htm#DBLBUFF

You have tons of upper memory free. I would definitely load SMARTDRV anyways.