So... this is a rather specific question that I am unsure if others here can answer or not...
This question concerns MSDOS realmode memory management, which is a voodoo topic by today's standards.
I have this really old Fujitsu Lifebook E2010 that I got for free some years ago.
It is a PIII class machine, with 1GB of ram and a 300ish GB HDD in it. It has ATI integrated AGP video, and an ESS Audiodrive based sound chip.
I THOUGHT this would make a decent DOS retrogaming system (Dosbox just doesn't cut it for some titles). But there's some issues.
1) Whoever designed this thing mixed an ALI/ULI northbridge with an ATI southbridge. As such, UMBPCI does not know what to do with it (and performance in XP is... bad.)
2) It has an Option Rom at CC00-CFFF that is a PXE bios, that is totally unnecessary.
3) The PCI chipset wants to hang on to the region between D000-DFFF, for nebulously defined reasons. There is nothing in the adapter space there. I checked.
4) The VGA bios is enormous. It occupies C000-CC00
5) The system bios is also enormous. It occupies E000-EFFF.
So, the memory map looks a bit like this. (VV= Video Bios, OO=Option Rom, BB=System Bios XX=theoretically free area held tightly by PCI chipset RR=Video RAM)
(B000)RRRRRRRRRRRRRRRR(BFFF)
(C000)VVVVVVVVVVVVVVOO(CFFF)
(D000)XXXXXXXXXXXXXXXX(DFFF)
(E000)BBBBBBBBBBBBBBBB(EFFF)
If I include the "monochrome mode video ram area" (B7FF-BFFF), the PXE option ROM area (to forcibly unmap it, since it DOES NOTHING USEFUL!), Use the EMM386 Highscan option and forcibly remap the D000-DFFF area to make the PCI set let it go, I can get something like this (where UU=UMB, PP=Page frame, VV=Video bios, BB=System bios, and RR=video RAM)
At this moment, this is the absolute "BEST" I can squeeze out, and is so far the only way I could fit an EMS page frame in.
(B000)RRRRRRRRRRRRUUUU(BFFF)
(C000)VVVVVVVVVVVVVVUU(CFFF)
(D000)PPPPPPPPPPPPPPPP(DFFF)
(E000)UUBBBBBBBBBBBBBB(EFFF)
The UMB created in the monochrome video RAM area is barely big enough to hold MSCDEX, and too small to hold OAKCDROM.SYS.
EMM386.exe is required, as the MMU has to get involved to forcibly remap the forced include areas, otherwise a pageframe cannot be created, and the option ROM cannot be disabled. It eats a shitton of conventional memory (3kb. Yes, that really is a lot when you only have 640k total.)
The OAKCDROM.SYS is a hog as well, scarfing down 25k!!
There is ~9kb of free UMB, split between 2 ~4k areas (where the option rom was disabled, and at the top of the BIOS area, freed by the highscan option.)
If I switch to JEMM386.EXE from the freedos project, I should be able to claw a bit of conventional memory back (it's smaller than EMM386), switch to SHUSCDX.EXE instead of MSCDEX I should claw back some of the UMBs created in the monochrome RAM area, and if I switch to Acer's Atapi driver, I might be able to get that to fit in the remaining contiguous UMB along with SHUSCDX.
But now the question--
Does JEMM386 support forcible remapping like EMM386 does? Without the forced remapping, I can't get the PCI set to let go of the D000-DFFF needed to place the EMS page frame.