Just noticed that Commander Keen 4/5 can utilize UMBs 😀

Does the loadhigh work fine for other TSRs? When disabling
ems you get one additional 64kb upper memory block which
should be enough for most things.

wd

Are UMBs abstract enough that you could provide an effectively unlimited number of them, or are they still tied too strongly to real memory addresses?

UMBs are conceptual identical to normal DOS memory allocations, except they cannot be resized and a different function is called. Unlike EMS, they are not virtual addresses which can be swapped out. So no, that can't be done.

I wonder how much upper memory can we get in dosbox. I have experimented a bit and with such a line in config.sys
device=c:\dos\emm386.exe noems verbose i=a000-b7ff i=b900-c7ff i=c900-cbff i=cd00-ffff
I get a really nice result - look at the picture (although i know it doesn't really work)

So my question is what occupies different parts of upper memory in dosbox. And which parts are free for us to use 😀

Well UMBs can be resized, but this is not done anywhere
i know of.

Generally it works like this: something provides upper
memory areas through the XMS-interface, namely EMM386
is doing this. The areas are (parts of) segments that
are unused with the current computer configuration,
like some ROM when not occupied by some PC card.

EMM386 can do this quite easily because it uses the
v86-mode and thus has a paging system running in the
background.

Now either some game (Der Clou, Keen) can request some
space in the UMB, or DOS does this if you specify DOS=UMB
(but it'll allocate all of it under real DOS, so apps
can't use it any more). DOS can link the upper memory
blocks into its MCB chain, so they can be allocated
through the normal DOS_ALLOCMEM (ah=0x48) and freed
and resized.

This was my first implementation, but it requires
the behaviour to be switchable (like umb=dosonly
or umb=app), so i turned it upside down. Now the
first thing done is to link the UMBs into the MCB
chain, and requests through the XMS-interface will
allocate a standard memory block in the upper memory.
This way all UMBs are accessible by both methods
all of the time, and only umb=false/true is needed
(if at all).

At the moment dosbox can use two upper memory areas,
one is from about 0xca00:0 to 0xd000:0-1 (above the
callbacks, free all the time) and the other from
0xe000:0-0xf000:0-1 (that is the page frame, so it
is only available when ems=false as unused then).

And adding video memory isn't recommended (besides
0xb000 monochrome when unused, but this'll create
too much problems anyways).

Hope this clarifies it a bit (and isn't too wrong...)

run msd to see what is rom in dosbox.

Can a UMB be resized? What is the XMS function call for that? My manual lists only 10h = alloc, 11h = free.

If it is linked to the standard MCB chain, I can see how, but I've never seen that happen...

I think 12=realloc does something like that.