That just means that the largest contiguous UMB isn't large enough. 20~30KB isn't very large for TSR whose resident size is 12KB. Many TSRs need significantly more memory for runtime before they shrink their memory footprint upon staying resident. if you could get 64+ free UMB, then perhaps both can be loaded high. On my DOS VM, CTMOUSE, DOSLFN and SHCDX33F are all loaded high. Some TSRs are smart to relocate, ie. they can start in low memory and relocate their resident footprint to UMB.

kjliew wrote on 2021-03-22, 06:03:

That just means that the largest contiguous UMB isn't large enough. 20~30KB isn't very large for TSR whose resident size is 12KB. Many TSRs need significantly more memory for runtime before they shrink their memory footprint upon staying resident. if you could get 64+ free UMB, then perhaps both can be loaded high. On my DOS VM, CTMOUSE, DOSLFN and SHCDX33F are all loaded high. Some TSRs are smart to relocate, ie. they can start in low memory and relocate their resident footprint to UMB.

I know SHSUCDX can be relocated. The thread I referenced said something about loading DOSLFN and other TSRs with larger footprint as early as possible, just that I don't know how early, as some TSRs will certainly require them be loaded in specific orders due to the way they work.

The system is a bit modern and the amount of UMB I can have (without EMS) is limited (about 68KB without including B000-B7FF). I have to load DOSLFN as early as possible to get it loaded high. The UMB is contiguous and large enough as I can even enable EMS, just that I would definitely need to include B000-B7FF to be able to access up to 36KB of upper memory which is barely enough for everything except DOSLFN, but still good enough for attaining more than 600KB of conventional memory in overall.

EDIT: Corrections. It seems if I load DOSLFN earliest in FDAUTO.BAT I can actually succeed in loading DOSLFN high, with either JEMM386 or UMBPCI... so DOSLFN indeed needs a lot of memory during runtime...

The rule of thumb is, if they can relocate, then load them last. If they cannot relocate, then load the one that requires large runtime memory first. Unfortunately, there is no easy way to tell how much runtime memory it really needs, so this is trial and error, or you can base on the actual file size of EXE or COM. I would presume at least 64KiB.

kjliew wrote on 2021-03-22, 08:45:

The rule of thumb is, if they can relocate, then load them last. If they cannot relocate, then load the one that requires large runtime memory first. Unfortunately, there is no easy way to tell how much runtime memory it really needs, so this is trial and error, or you can base on the actual file size of EXE or COM. I would presume at least 64KiB.

You're right about relocating. Loading SHSUCDX directly (relocate high) indeed made a difference compared to loading SHSUCDX via LH with /C argument (stay high).

In my UMBPCI configuration, after managing to get DOSLFN loaded high (by loading it earliest), I can actually put SHSUCDX into UMB as well, if loading it directly. On the other hand, if I load SHSUCDX via LH with /C argument, it would be loaded into low memory, while it can still be loaded high in my JEMM386 configuration (which has more UMB in comparison), implying SHSUCDX needs a lot more memory during runtime than the amount it needs to stay resident.

EDIT: I just noticed that if I am to load DOSLFN earlier than SHSUCDX, I need to add /C+ argument to allow LFN on CD-ROM, according to DOSLFN's readme.

Since you're using JEMM386 anyway, have you considered whether XCDROM32 might meet your needs?