VOGONS

Common searches


First post, by LSS10999

User metadata
Rank Member
Rank
Member

I'm currently running FreeDOS 1.3-rc3 on a legacy-focused system. While I can easily attain more than 600KB of conventional memory, I noticed some TSRs that I'm using don't load high even when there appear to be plenty of upper memory for it to be resident there.

A good example would be DOSLFN. The table file I use results in around 12KB of conventional memory used, but it refuses to load high even when I still have a lot more UMB (with largest contiguous upper memory block be like at least 20-30KB). Changing the TSR loading order (according to that thread), that I would load DOSLFN as early as possible, helped getting it loaded high, but at the same time, SHSUCDX ended up loading low, so in overall I get 6KB more of conventional memory. I don't know if this would cause any side effects, especially I'm not really sure if there are any serious differences between loading DOSLFN before or after SHSUCDX.

Is there a good way to inspect how much memory a TSR uses while loading? It seems some TSRs might use more memory during its process which may lead to it thinking it should be loaded low when the system's largest contiguous upper memory block is below a certain threshold...

Reply 1 of 5, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 2 of 5, by LSS10999

User metadata
Rank Member
Rank
Member
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...

Last edited by LSS10999 on 2021-03-22, 15:37. Edited 1 time in total.

Reply 3 of 5, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 4 of 5, by LSS10999

User metadata
Rank Member
Rank
Member
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.