Published on September 20th, 2026
Lately I've been working on a couple of MSX-DOS2 programs that need more memory than the Z80 can address, and I got tired of solving the same problem from scratch every time. So I sat down and solved it once, properly. The result is a library called MapperHeap, and I'm releasing it today.
The short version: MapperHeap gives your program a general-purpose heap (allocate a block, use it, give it back), with the blocks living in memory mapper RAM instead of in the 64 KB the Z80 can see. All the mapper RAM in the machine is available: the internal mapper, mappers in expanded slots, cartridge mappers, all of them.
Think of the alloc() and free() function calls in the C language, but for MSX assembly, and returning a kidn of pointer that takes into account the mapper slot and segment, in addition to the memory offset.
It works by keeping the CPU's page 2 (8000h–BFFFh) as a window. Each block is named by a 4-byte far pointer (slot, segment, offset) which stays valid for as long as the block does, no matter what the window happens to be showing. When you want to touch a block you hand its far pointer to deref and get back an ordinary 16-bit address you can use like any other. Blocks freed next to each other are merged back together, so the heap doesn't fall to pieces over a long run.
Segments are requested from MSX-DOS2's own allocator rather than taken behind its back, so the library coexists with the RAM disk and with anything else resident, and DOS reclaims everything when your program ends. It needs MSX-DOS2 for that, so it won't work under MSX-DOS1.
I wrote it for my own projects, but it's been stable for a while now and it's documented well enough that somebody else can pick it up without reading the source first. No reason to keep it to myself.