Can You Max Out a 1998 Arcade Board's Storage?

The Capcom CPS-2 arcade board from 1998 shipped with specific ROM sizes per game. But the hardware itself can address far more. This post documents how we expanded Marvel vs. Capcom 1 to the absolute theoretical limits of the CPS-2 platform -- and built a Python pipeline to do it reproducibly.

Engineering Outcomes (file-level -- see Editor's update above for what is actually addressable):

• GFX ROM files expanded from 32MB to 128MB (96MB of padded space; addressable only via custom core, and only to 64MB)
• Audio ROM files expanded from 8MB to 16MB (8MB padded; addressable only via custom core)
• Program ROM documented at 1MB / 4MB max (3MB headroom for code)
• 148MB total ROM set -- the CPS-2 hardware ceiling
• Automated build pipeline with Python + vasm assembler
• In-game ULTRA SETTINGS verification screen confirms expansion

CPS-2 Theoretical Limits

Before expanding anything, we need to understand what the hardware can actually address.

Full Capacity Table

ROM Layout: Before and After

Original (32MB Graphics)

Expanded (CPS-2 MAX: 128MB GFX + 16MB Audio)

Space Distribution

What Fits in 96MB Free Graphics Space

With 96MB of free graphics space (up from our earlier 32MB), the possibilities are enormous:

With 96MB free, you could theoretically import the entire MSHvSF + XMvSF + COTA rosters combined and still have room left.

How the Expansion Works

GFX ROM Interleaving

CPS-2 graphics use 8 interleaved ROMs. The hardware reads 8 bytes at a time, one from each chip:

Padding Values

Using these padding values ensures zero visual or audio artifacts from the expanded regions.

GFX ROM Sprite Format (What Goes in the Free Space)

The 96MB of free GFX space can hold new sprite data. CPS-2 sprites use a specific format:

Each 16x16 tile uses 4 bitplanes. The 8 GFX ROMs are interleaved -- a single character's sprites are split across all 8 files. To copy Spider-Man's sprite data to the expanded region, we'd:

1. Extract all Spider-Man tiles from the interleaved 8-chip layout
2. Copy them to the free region (starting at offset 4MB in each chip)
3. Modify the tiles to add armor details (thicker outlines, visor, metallic highlights)
4. Update the sprite bank pointer in the character table at $065CCA

Spider-Man's full sprite set (all animation frames) is approximately 1.5-2 MB across all 8 chips. That's less than 2% of the 96MB free space.

CPU Cannot Directly Read GFX ROMs

A critical CPS-2 architectural detail: the 68000 CPU cannot directly address graphics ROM data. The CPU communicates sprite tile numbers and palette indices through:

• Object RAM ($700000-$709FFF): 8-byte entries per sprite (Y pos, tile num, attributes, X pos)
• Palette RAM ($900000-$92FFFF): 192KB, RGB444 format

The GFX ROMs are accessed only by the CPS-2 custom graphics hardware. The CPU tells the hardware "draw tile N with palette P at position X,Y" and the hardware fetches the tile data from GFX ROM directly.

Expansion Pipeline

The Build Script

Our unified Python pipeline handles everything: ROM expansion, code patching, assembly, and packaging.

#!/usr/bin/env python3
"""
Unified CPS-2 ROM expansion + patching pipeline.
Expands ALL ROM types to hardware maximums.
"""
 
import zipfile, os, subprocess, tempfile
 
# CPS-2 Maximum ROM sizes
GFX_ROMS = ['mvc.13m','mvc.14m','mvc.15m','mvc.16m',
            'mvc.17m','mvc.18m','mvc.19m','mvc.20m']
GFX_TARGET = 16 * 1024 * 1024    # 16MB per chip (128MB total)
 
AUDIO_ROMS = ['mvc.11m', 'mvc.12m']
AUDIO_TARGET = 8 * 1024 * 1024   # 8MB per chip (16MB total)
 
 
class ROMPatcher:
    def expand_all_roms(self):
        """Expand every ROM type to CPS-2 theoretical maximum."""
 
        # GFX: 4MB → 16MB per chip (0xFF = transparent)
        for name in GFX_ROMS:
            data = bytearray(self.clean_files[name])
            expanded = bytearray(GFX_TARGET)
            expanded[:len(data)] = data
            for i in range(len(data), GFX_TARGET):
                expanded[i] = 0xFF
            # Plant verification marker in mvc.13m
            if name == 'mvc.13m':
                expanded[0x3FFFFB:0x400000] = b'GOLD\x01'
            self.clean_files[name] = bytes(expanded)
 
        # Audio: 4MB → 8MB per chip (0x00 = silence)
        for name in AUDIO_ROMS:
            data = bytearray(self.clean_files[name])
            expanded = bytearray(AUDIO_TARGET)
            expanded[:len(data)] = data
            # 0x00 is default for bytearray, already silence
            self.clean_files[name] = bytes(expanded)

GOLD Marker Verification

We plant a 5-byte marker (GOLD\x01) at offset 0x3FFFFB in mvc.13m -- the last 5 bytes of the original 4MB region. This lets our in-game diagnostic screen verify the expansion is real:

Offset 0x3FFFFB in mvc.13m:
  Before expansion: FF FF FF FF FF (empty)
  After expansion:  47 4F 4C 44 01 (GOLD\x01)

MAME Compatibility

Expected MAME Output

mvc.13m WRONG LENGTH (expected: 00400000 found: 01000000)
mvc.14m WRONG LENGTH (expected: 00400000 found: 01000000)
...
mvc.11m WRONG LENGTH (expected: 00400000 found: 00800000)
mvc.12m WRONG LENGTH (expected: 00400000 found: 00800000)
WARNING: the machine might not run correctly.

Despite all warnings, the game runs perfectly -- because it never touches the padded region. The original data is untouched in the first 4MB of each chip, and that is all the game can see: MAME loads the extra bytes into the region, but the mvsc mapper AND-masks GFX addressing past 32MB (and QSound past 8MB), so accesses to the "new" space wrap back into the original data. Running clean proves the padding is harmless, not that the space is usable.

In-Game Verification: ULTRA SETTINGS

The build pipeline also injects a custom diagnostic screen into the F2 Test Menu. This "ULTRA SETTINGS" submenu displays real-time verification of the expansion:

  9.ULTRA SETTINGS
 
  PRG TOTAL: 4096KB
  PRG USED:   872KB
  PRG FREE:   152KB
  GFX TOTAL: 0128MB
  GFX USED:   032MB
  GFX FREE:  0096MB
  CPS-2 MAX: 0128MB
  ...

The GFX values are computed dynamically at patch time and embedded into the ROM's diagnostic text. The ULTRA SETTINGS screen also verifies character roster counts, palette integrity, and secret character function addresses.

Character Size Estimates

Content Capacity at 96MB Free (GFX)

Audio Capacity at 8MB Free

Expansion History

Program ROM Expansion Potential

The 68000 CPU on CPS-2 has a 24-bit address bus. The hardware maps program ROM to $000000-$3FFFFF -- a full 4MB window. MvC1 only uses 1MB (two 512KB chips), leaving 3MB of addressable program space unused.

Expanding program ROM is more complex than GFX/Audio because:

1. The MAME driver expects specific file names and sizes
2. New code must be position-aware (68000 absolute addressing)
3. Existing jump tables reference hardcoded addresses

However, our ULTRA SETTINGS handler already demonstrates injecting new code into free ROM space. The technique scales to the full 4MB address space.

Armor System Complexity

During our research, we discovered that character armor in MvC1 has two fundamentally different implementations:

Flag-based armor is a simple byte write. Animation-based armor requires modifying hundreds of animation table entries. This is why "Armored Spider-Man" is best implemented as a flag-based armor variant (like Gold War Machine), not an animation-based one (like Hulk).

Summary

References

• CPS-2 hardware documentation (MAME driver source)
• ROM expansion research and implementation
• MAME compatibility testing across multiple CPS-2 titles
• MvC1 modding community (N41, artfuldodger2468)