Megadev memory

Inspect the selected toolchain, linker layouts and existing resource owners before adding a pool or changing a memory mode. Main Work RAM, Sub Program RAM, Word RAM, PCM RAM, Z80 RAM and VDP memory are separate resources. Do not combine their capacities into a shared C heap.

Account for the linked program

Read pools and placement for CPU views, BIOS/stack reservations and linked versus reserved bytes. The standalone Lab's tools/report_layout.py checks its explicit layout.json against actual Megadev symbol files. Adapt reservations to the game; the Lab's large code windows and growth margins are examples, not mandatory overhead.

Count code, constants, BSS, initialized data, startup/access services, stacks and resident pools. An arena array inside BSS is already counted there. Unassigned address space is not automatically an initialized allocator. A stack reservation does not prove its high-water usage.

Choose a lifetime

Read allocation lifetimes for resident, scene and scratch storage, alignment, generation checks and leases. The included ma_* and mv_* functions are project-owned examples, not Megadev allocator APIs.

Use a storage policy that fits the game. A scene arena can reset in bulk once its users finish; stable pools or individual allocations may suit different lifetimes. Refuse an allocation that does not fit without silently resizing buffers or moving live objects. An unload must wait for queued transfers/workers that still reference the backing bytes.

Treat Word RAM as an owned view

Read Word RAM modes before changing MODE, DMNA or RET. In 2M mode one CPU owns all 256 KiB. In 1M mode each owns a different 128 KiB bank; swapping changes what the same linear pointer addresses.