External EMM doesn't launch without command-line parameters

[JayQ2K]

Describe the bug

So I've been working through some configurations on using other EMM inside DOSBox-X and then checking inside a diagnostics tool how memory mapping worked out. Without command-line parameters, pretty much no EMM (e.g. EMM386, JemmEx, EMSMagic) works properly. Some see no FRAME space (effectively FRAME=NONE) and thus don't work whilst other halt or crash the system immediately or throw the debugger.
JemmEx states that C400-EFFF range is system memory. Only C400-CBFF however is Hi RAM and including this range for usage to an EMM tends to crash the machine. Effectively any outside EMM in DOSBox requires I=CC00-EFFF to function. Seems the DOSBox internal EMM is hardcoded to properly use CC00-EFFF, but by excluding C400-CBFF in the machine you can pretty much put an EMM into auto-detect with the frame ending up at E000 and 80kB (CC00-DFFF) of UMB that can even become 96kB when including F000-F3FF. When choosing to use any outside EMM, these ranges all suddenly became system memory.

I went a little further and also found that when using EMM386 as a DEVICE in config (and thus not DEVICEHIGH) you get Free Conventional limited to 597kB and none of the EMM386 parts loaded into UMB. Adding FRAME=E000 RAM ups that number to 603kB with part of EMM386 now in UMB. Pretty weird though that these parameters are required to get EMM386 loaded into UMB. If you however use DEVICEHIGH with EMM386, you actually need to remove FRAME=E000 RAM (seems to hang if you don't) and you get 608kB conventional, pretty similar to using the internal EMM.

All this had me ending up at taking another look at which EMM are (nowadays) completely freeware as in using GNU GPL as licensing and it seems 386MAX falls in that category. Perhaps https://github.com/sudleyplace/386MAX can help with revamping the EMM code inside DOSBox. On the website https://www.sudleyplace.com/swat/ they have a debugger tool, called 386SWAT that might assist as well.

Steps to reproduce the behaviour

1. Changes to the config file:
   ems = false
device = EMM386.EXE (no command line parameters)

   • Result: crash

2. Changes to the config file:
   ems = false
device = EMM386.EXE I=CC00-EFFF

   • Result: 597kB conventional

3. Changes to the config file:
   ems = false
device = EMM386.EXE I=CC00-EFFF FRAME=E000 RAM

   • Result: 603kB conventional with parts of EMM386 in UMB

4. Changes to the config file:
   ems = false
devicehigh = EMM386.EXE I=CC00-EFFF

   • Result: 608kB conventional with seemingly all of EMM386 in UMB

Expected behavior

No response

What operating system(s) this bug have occurred on?

Windows 11 24H2

What version(s) of DOSBox-X have this bug?

dosbox-x-vsbuild-win32-20250101083049 SDL1

Used configuration

[dos]
ems                   = false

[config]
rem                   = This section is DOS's CONFIG.SYS file, not all CONFIG.SYS options supported
break                 = off
numlock               = 
shell                 = 
dos                   = high, umb
fcbs                  = 0
files                 = 0
country               = 
lastdrive             = a
set path              = Z:\;Z:\SYSTEM;Z:\BIN;Z:\DOS;Z:\4DOS;Z:\DEBUG;Z:\TEXTUTIL
set prompt            = $P$G
set temp              = 
install               = 
installhigh           = 
#device                = JEMM\JEMMEX.EXE I=CC00-EFFF /V
#device                = EMM386.EXE I=CC00-EFFF FRAME=E000 RAM
devicehigh            = EMM386.EXE I=CC00-EFFF

Output log

Additional information

No response

Have you checked that no similar bug report(s) exist?

• I have searched and didn't find any similar bug report.

Code of Conduct & Contributing Guidelines

• I agree to follow the code of conduct and the contributing guidelines.

[joncampbell123]

There is a dosbox.conf option in DOSBox-X to relocate the DOSBox private area to the bottom of conventional memory, if that upper region C000-CFFFh is needed for EMM.

[JayQ2K]

Yeah, I've seen that "private area in umb" option. But moving that region to conventional seems completely going against the idea as it implies your losing conventional memory and some of these DOS applications tend to like big amounts of conventional memory. And also this is then according to description about C800 (and probably through to CBFF) and not the CC00-EFFF segment which in most PC/AT setups is actually free memory

What I found online:
There are three standard BIOSes present in most systems and located pretty much at the same place:
System BIOS: The main system BIOS is located in a 64KB block of memory from F0000h to FFFFFh.
VGA Video BIOS: This is the BIOS that controls your video card. It is normally in the 32KB block from C0000h to C7FFFh.
IDE Hard Disk BIOS: The BIOS that controls your IDE hard disk, if you have IDE in your system (which most do) is located from C8000h to CBFFFh.

To add on the above: F000-F3FF is the monitor area of the System BIOS part and that might be free area. The IDE part is more broadly an option ROM part (meaning it could also represent a random private area), but effectively that C800-CBFF range is in use.

But to get back on point. Outside EMM seemingly receives some faulty feedback on what UMA ranges can be used to create a page frame and UMB automatically without requiring an INCLUDE parameter for that EMM.
But perhaps the 386MAX code can assist with this.

[joncampbell123]

The private area has some DOS state that would normally exist down in conventional memory anyway. DOSBox SVN (and by extension, DOSBox-X) place some of it up in the upper memory area to free up memory, I guess. There are also options to control the minimum free segment of memory and where the MCB starts which if used right can allow a lot of open conventional memory, though it can also cause issues with DOS programs that malfunction if loaded below a certain address.

[JayQ2K]

So the whole move to UMB already happens regardless? That largely means enabling the EMM is just for creating the page frame (usually at E000). Interesting way to go about that. Memory mapping then is something like C400-EFFF is actually seen as reserved (or system) memory and whatever can play nicely in that area will be loaded there?

If the above is the case, then it might still be better to separate that E000-EFFF range and connect it to the ems=true|false option in the config file (false then leaving this as free and true making this into page frame). That way, an external EMM sees that space as available and just uses it for the page frame.

Effectively making C400-DFFF into system memory and E000-EFFF into either system memory if ems=true or as free memory for a page frame if ems=false.

[joncampbell123]

DOSBox SVN defaults to putting it's private area in UMB, DOSBox-X allows you to place that at the bottom of conventional memory if you need that space for any reason, or more likely, a DOS game has sloppy video rendering code that can render past video memory.

However, yeah, I'll see that some region up there is open if ems=false, if that's what it needs.

[JayQ2K]

Does this movement to UMB also relate in some way to when you put in xms=false and running an external XMM (like HimemX or HIMEM) there is no way to get DOS into UMB anymore? It seems that when having a config like this:

[dos]
xms                         = false
ems                         = false

[config]
dos                         = high, umb
device                      = C:\EMM\HIMEMX\HIMEMX.EXE
device                      = C:\EMM\EMM386.EXE I=CC00-EFFF FRAME=E000 RAM

1. According to MEM.EXE DOS is not loaded into HMA
2. You are working with 599kB conventional, suggesting DOS/Private actually is in Conventional

Switching the config .1:

[dos]
xms                         = false
ems                         = true

[config]
dos                         = high, umb
device                      = C:\EMM\HIMEMX\HIMEMX.EXE

1. According to MEM.EXE DOS is not loaded into HMA
2. You are working with 604kB conventional (4kB goes to HimemX here), suggesting DOS/Private is in HMA
3. 64 kB XMS in use and 15M EMS available

Switching the config .2:

[dos]
xms                         = false
ems                         = true

[config]
dos                         = high, umb

1. According to MEM.EXE DOS is not loaded into HMA
2. You are working with 608kB conventional, suggesting DOS/Private is in HMA
3. All XMS is in use (so no free space left) for the 15M EMS

Switching the config .3:

[dos]
xms                         = false
ems                         = emm386

[config]
dos                         = high, umb

1. According to MEM.EXE DOS is not loaded into HMA
2. You are working with 608kB conventional, suggesting DOS/Private is in HMA
3. All extended memory is in use, but no EMS active

Switching the config .4:

[dos]
xms                         = false
ems                         = emm386

[config]
dos                         = high, umb
device                      = C:\EMM\HIMEMX\HIMEMX.EXE

1. According to MEM.EXE DOS is not loaded into HMA
2. You are working with 604kB conventional (4kB goes to HimemX here), suggesting DOS/Private is in HMA
3. 64 kB XMS in use, but no EMS active (WHAAAAT?!?!?!)

Questions:

1. Is xms=false in some way the trigger to actually activate UMA?
2. xms=false should just mean there is not XMS whatsoever. Not it being in use, but simply invisible.
3. xms=false, ems=true and an external XMM I would have expected an error being thrown like regular EMM will do without any XMM active. This definitely concludes the config file is not read from top to bottom in order, but in some parallel way.
4. ems=true seems to just override the whole xms=false option (without another XMM either) to activate the XMS and put it to EMS use. Under normal circumstances, neither XMS nor EMS should be active in this configuration.
5. Switching the config .1 and .4 only differs for ems=true vs ems=emm386, but the result is very different. The outcome of .4 definitely wasn't expected. In this specific case ems=emm386 actually seems to be read BEFORE 'C:\EMM\HIMEMX\HIMEMX.EXE'.