Marvel vs. Capcom Fills All 4MB. The 68000 Has 16.

The wall

I have expanded CPS-2 graphics to 64MB addressable and audio to 16MB. Program ROM I had written off, for a reason that looked solid: Marvel vs. Capcom uses all of it.

$000000  mvce.03a  512 KB      $200000  mvc.07   512 KB
$080000  mvce.04a  512 KB      $280000  mvc.08   512 KB
$100000  mvc.05a   512 KB      $300000  mvc.09   512 KB
$180000  mvc.06a   512 KB      $380000  mvc.10   512 KB
                                        4.00 MB of 4.00 MB

Eight chips, half a megabyte each, $000000 through $3FFFFF. Nothing spare.

This matters because of what a native character port needs. Importing a fighter from another game means her data has to be resident: animation tree, the code that runs her specials, her hitbox tables. Measured, for one character:

So the port did the only thing it could: instead of importing her data, it redirects. Individual per-character lookups get patched to borrow data that already exists in the ROM. It works — it is why the character runs at all — but it has a defining weakness. Any lookup nobody thought to redirect silently reads another fighter's values, and you discover those by playing. Backwards dash is wrong. The pre-fight walk glitches. Hitboxes are the wrong size. Each one looks like a separate bug and is actually the same bug wearing different clothes.

You cannot finish that list. You can only shorten it.

Reading the map instead of the summary

The platform documentation says CPS-2 supports 4MB of program ROM, and that is true — it is the size of the ROM window. But the 68000 has a 24-bit address bus. Sixteen megabytes. The ROM window is the first quarter of it, and I had never asked what was in the other twelve.

So I stopped reading summaries and enumerated every SekMapMemory call in the emulator core:

$618000-$619FFF   QSound shared RAM
$660000-$663FFF   NVRAM
$708000-$70FFFF   Object RAM
$900000-$92FFFF   Video RAM
$F00000-$F1FFFF   (misc)
$FF0000-$FFFFFF   Work RAM

Plus a handful of registers at $400000 and the CPS-B block at $800000.

Look at the gap. $410000 through $5FFFFF is not mapped to anything. Nearly two megabytes of address space that no CPS-2 game ever used, sitting directly above the ROM window, reachable by the same instructions with no bank switching, no window, no paging.

Four small changes

No banking logic, no mapper, no window register. The whole thing is a flat map:

cps.h — declare the buffer and a ROM type for it. The base and length constants have to live here, not in the .cpp, because they are used near the top of the allocation routine.

cps_mem.cpp — map it for both reads and instruction fetches:

SekMapMemory(CpsRomExp, 0x500000, 0x5FFFFF, MAP_READ);
SekMapMemory(CpsRomExp, 0x500000, 0x5FFFFF, MAP_FETCH);

Mapping MAP_FETCH matters: code placed there executes unencrypted, exactly as the existing $100000+ data ROMs already do. Injected routines behave identically to the ones already living in the ROM's gaps — there is just vastly more room.

cps.cpp — a loader case for the new ROM type.

d_cps2.cpp — one line adding the chip to the romset, marked BRF_OPT so every existing romset still loads unchanged when the file is absent.

The bug that made it look broken

First build: the chip loaded (Loading mvc.exp... (OK)) and the window read back as zeros instead of my $FF fill. The mapping looked wrong.

It was an ordering mistake, and an easy one to make:

Cps2Init():  CpsGetROMs(false) → CpsInit() → CpsGetROMs(true) → CpsRunInit()
                                             ^ roms load here     ^ memory is
                                                                    allocated here

The allocation happens inside CpsRunInit, which runs after the load pass. My buffer was carved from that arena, so the pointer was still NULL when the loader needed it, and the guard I had written (if (bLoad && CpsRomExp)) quietly skipped the load. Giving the buffer its own allocation in the loader fixed it.

Worth noting because the symptom — chip loads fine, memory reads zeros — points at the mapping, which was correct the whole time.

Proving it, not assuming it

The core's debug print does not reach stdout in this build, so its silence proved nothing. Instead I wrote a distinctive signature at each end of the window and read them back through the 68000 from a Lua harness:

$500000 = 9AE7005CADDEEFBE     wrote E79A5C00DEADBEEF
$5FFFF8 = FFC011EE33225544     wrote C0FFEE1122334455

Both present. Byte-swapped, which is not a defect — it is the same ^1 interleave every CPS-2 data ROM uses, and the same idiom the build tools already write with.

Reading both ends matters: the base signature alone would prove the region is mapped, but not that the whole megabyte is addressable. Two signatures prove the extent.

What it changes

One character needs 63,782 bytes. The new window holds that sixteen times over, contiguously.

That is the difference between a port that borrows and a port that imports. The redirect architecture was never a design choice — it was the only thing that fit. With a contiguous megabyte, the animation tree, the special-execution code, the code block and the box tables can all be resident as her data, and the defect list stops being something you discover by playing.

The honest caveats

This is offline-only. Like the 64MB graphics expansion before it, a stock CPS-2 board has no such chip and would not see this region. It is an emulator-core capability, not a hardware discovery, and it costs standard netplay compatibility.

Nothing is imported yet. The space exists and is proven addressable. Writing the importer against it is the next piece of work, and this post claims nothing about it.

1MB is a choice, not a ceiling. $410000-$5FFFFF is closer to 2MB. I mapped one megabyte because it is comfortably more than needed and leaves the boundary well clear of the register block at $400000. Widening it later is a constant.