Skip to content

mem: don't count reserved memory as used upper memory - #134

Merged
stsp merged 1 commit into
masterfrom
claude/mem-reserved-not-used
Oct 3, 2026
Merged

stsp merged 1 commit into
masterfrom
claude/mem-reserved-not-used

Conversation

@stsp

@stsp stsp commented Oct 3, 2026 •

Copy link
Copy Markdown
Member

Asked for in dosemu2/dosemu2#3017 (comment) ("I think comcom should be fixed instead, as whatever is reserved, should not be used").

Before: upper memory was the fixed region 0xA000-0xDFFF, 256K, and used was that total minus the free blocks of the upper memory chain. Everything in the region the chain does not reach - video memory, option ROMs, a video BIOS that reserves more than its header - was reported as in use, although DOS can neither hand it out nor say who holds it. The reserved row was a fixed 128K for 0xE000-0xFFFF, so a hole below 0xE000 was charged to upper memory and a hole above it to nobody.

After: the upper total is the chain's own blocks, allocated and free, wherever they sit, and whatever is left of the area above 640K is the reserved region. A hole is reserved, not used.

Measured under dosemu2 with FreeDOS MEM.EXE beside our own MEM, which is the comparison dosemu2's test/func_comcom_internal.py makes. With a 32K hole in the chain, which $_umb_b0 = (0) produces:

before after FreeDOS MEM.EXE
Upper 256K 120K 136K 224K 88K 136K 224K 88K 136K
Reserved 128K 128K 0K 160K 160K 0K 160K 160K 0K

With $_umb_a0, $_umb_b0 and $_umb_f0 all off: Upper 144K 88K 56K and Reserved 240K, again the same as MEM.EXE, where before it was Upper 384K 328K 56K.

In the default configuration the two agreed by accident: the 36K the chain skips at 0xB800 happens to equal the free area it reports above 0xE000, and the two errors cancelled. That is why the dosemu2 test passed as it stood; it passes after this change too, unchanged.

How: the MCB walk now sums the upper blocks it counts into umb_total_paras - body plus the header paragraph, link placeholders excluded as before - and umb_total_kb comes from that instead of from the region bounds. reserved_total_kb is the rest of 0xA000-0xFFFF, so the two rows still cover the whole area and the "Total memory" and "Total under 1 MB" lines are unchanged in the default case.

Built with the dj64 toolchain and run against dosemu2's own suite: test/test_comcom.py TestCase32 with this build as COPY_COMMAND_COM, 13 cases pass and 2 skip for a missing TEST_R200.tar. Not run here: TestCase64, because this container's dosemu2 is built without djdev64 support, so only comcom32 boots; the changed file is the same for both.

Upper memory was a fixed 256K region, 0xA000-0xDFFF, with used taken
as that total minus the free blocks found in the chain. Anything in
the region that the upper memory chain does not reach - video memory,
option ROMs, the BIOS - was therefore reported as in use by somebody,
although DOS can neither give it out nor account for it.

Take the upper total from the chain instead, as FreeDOS MEM does: the
blocks themselves, allocated and free, wherever they sit, and the rest
of the area above 640K is the reserved region, whose size is now what
is left over rather than a fixed 128K.

Measured under dosemu2 with the FreeDOS MEM.EXE beside our own, which
is what dosemu2's test/func_comcom_internal.py compares. With a 32K
hole in the chain, which `$_umb_b0 = (0)` makes:

                      before            after      FreeDOS MEM.EXE
  Upper      256K  120K  136K    224K  88K  136K    224K  88K  136K
  Reserved   128K  128K    0K    160K 160K    0K    160K 160K    0K

The two agreed in the default configuration only by accident: the 36K
hole the chain skips at 0xB800 happens to be the size of the free area
it reports above 0xE000, and the two errors cancelled. With the holes
of any other size, the fixed total charged the difference to "used".

Co-Authored-By: Claude <noreply@anthropic.com>
@stsp
stsp merged commit b5ee750 into master Oct 3, 2026
2 checks passed
@stsp
stsp deleted the claude/mem-reserved-not-used branch October 3, 2026 18:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants