116 Bytes, Once a Frame: Sneaking New Behavior into MvC

Injecting a new runtime behavior into a legacy binary is four separate problems wearing one coat: getting at the code, finding a place to put new code, making the new code reachable, and giving it resources (palettes, tiles, IDs) the original never allocated. This post walks each one for a concrete target -- adding character ID 0x2E to Marvel vs. Capcom 1 by ROM patching alone. No source, no emulator cheats.

Getting at the Code: CPS-2 Encryption

CPS-2 program ROMs are hardware-encrypted; the board (or emulator) decrypts on the fly using a per-game key. You cannot grep an encrypted ROM for an opcode pattern, which rules out the normal first move.

The full round trip, if you are targeting a standard board:

# 1. Extract the ROM set
unzip mvscj.zip -d mvscj_extracted/
 
# 2. Decrypt the program ROM (cps2crypt ships with MAME tools)
./cps2crypt -d mvscj_extracted/mvscj.03 mvscj.03.dec mvsc.key
 
# 3. Patch mvscj.03.dec
 
# 4. Re-encrypt
./cps2crypt -e mvscj.03.dec mvscj.03.mod mvsc.key
 
# 5. Swap it back in
cp mvscj.03.mod mvscj_extracted/mvscj.03

In practice all of this work targeted the Phoenix Edition (mvscud), whose program ROM is already decrypted -- step 2 and step 4 collapse to a file copy. That choice matters later: the assumption that "one ROM has one plaintext" survived this entire phase of the project and was only broken much later, when the native port found that opcode fetches and data reads decrypt differently.

Only program code is encrypted. Palettes, character tables and graphics pointers are plaintext in every build, which is why palette patching worked before any of this was set up.

Finding Somewhere to Put Code

MvC1 uses 1MB of a 4MB program window, and the expansion work had already established free space at $0F1000+. That is where every injected routine in this project lives -- new code in unused address space, reached by redirecting something the game already calls, rather than by growing or moving existing code (which would break the hardcoded jump tables).

The addresses the patcher needs -- the character table at $065CCA (32 bytes/entry), the roster at $AC7A, the stage table at $BB04C, the player structures at $FF3000/$FF3100 with the character ID at +$53, and the full CPS-2 hardware map -- are documented in the binary-forensics post.

Making It Reachable: The Input Sequence Machine

The intended activation path was a directional code, matching the six the game already ships. As a state machine it is a linear chain with a reset edge on every wrong input or timeout: ten states for ten inputs, each advancing only on the expected direction.

Written as an injected routine, it is a buffer comparison guarded by a cursor-position check. Spider-Man's grid position is $0F:

; ============================================
; Armored Spider-Man Selection Code Handler
; Insert into character select input routine
; ============================================
 
ARMORED_CODE_CHECK:
    ; Check if cursor is on Spider-Man (position 0x0F)
    CMP.B   #$0F, D0         ; D0 = current cursor position
    BNE     .skip_armored     ; Not on Spider-Man, skip
 
    ; Check input sequence buffer
    LEA     input_buffer, A0  ; A0 = input history buffer
    LEA     armored_code, A1  ; A1 = expected sequence
    MOVEQ   #9, D1            ; 10 inputs to check (0-9)
 
.check_loop:
    MOVE.B  (A0)+, D2         ; Get buffered input
    CMP.B   (A1)+, D2         ; Compare with expected
    BNE     .skip_armored     ; Mismatch, skip
    DBRA    D1, .check_loop   ; Continue checking
 
    ; Code matched! Select Armored Spider-Man
    MOVE.B  #$2E, D0          ; Set character ID to 0x2E
    MOVE.B  #$01, armored_flag ; Set flag for palette load
    BRA     .select_character
 
.skip_armored:
    ; Continue with normal selection
    RTS
 
; Expected input sequence (Down=2, Left=4, Up=8, Right=6)
armored_code:
    DC.B    $02, $02          ; Down, Down
    DC.B    $04, $04          ; Left, Left
    DC.B    $08, $08          ; Up, Up
    DC.B    $06, $06          ; Right, Right
    DC.B    $02, $02          ; Down, Down

A longer variant was drafted as well -- Down, Down, Left, Left, Up, Up, Right, Right, Down, Left, Up, Right -- on the theory that a 12-input code is harder to trigger by accident. It was never needed, because this routine never shipped: getting it called is where the approach died.

The Resource Problem: Palettes

A palette swap is the cheapest way to give a new ID its own identity, since it reuses the base character's entire sprite bank. CPS-2 palettes are RGB444 big-endian -- 0x0RGB, two bytes per color, 16 colors, 32 bytes per palette -- not the RGB555 that gets assumed. Spider-Man has four of them in mvc.06a (P button, K button, Web P, Web K).

The silver/gunmetal design, all 16 entries with exact RGB444 values, is tabulated in the binary-forensics post. The one implementation note worth repeating here: write all 16, not just the ones you changed. A palette swap is a whole-palette store, and unwritten slots keep whatever the base character had, which produces a half-recolored sprite that looks like a rendering bug rather than a palette bug.

Why None of This Was the Answer

Every piece above assumes the injected code gets executed. It does not. The routine that decides whether a secret box exists for the cursor's current position compares against a hardcoded list of positions -- 1, 6, 11, 12, 13 -- and Spider-Man (15) and Wolverine (5) are not in it. Adding table entries changes nothing, because the code never reaches the tables for those positions.

That left two options:

1. Surgery -- patch the position check inside the 13-state character select machine at $01DFA0, which is coupled to three table formats, cursor navigation and rendering state
2. Bypass -- run new code every frame from outside the state machine entirely

The project took option 2: hooking the CPS-2's Autovector 2 (VBlank) interrupt with 116 bytes at $0F1FA0, which reads the character ID at $FF3053 each frame, detects Wolverine plus a newly-pressed Down, writes Spider-Man's ID, and tail-jumps to the original handler at $054A. It carries a 60-frame safety window so it can only fire on the character select screen, and input edge detection so a held direction fires once. It was prototyped as a MAME Lua script before a single byte was assembled.

The assembly, the safety mechanism, the Lua prototype and the build pipeline are documented in full in the hidden-box post.

The Generalizable Part

The insight worth carrying out of this post is not the hook. It is the trade the hook represents: when the thing you want to modify is tightly coupled, stop modifying it and find a periodic entry point you can own. A frame interrupt is a place where your code runs unconditionally, with the machine in a known state, coupled to nothing. Once that pattern was proven here, it recurred: the donor-chassis Dark Sakura build works by owning the state-machine dispatch layer rather than editing the state machine, which is the same trade at a different altitude.

Where This Left the Project

The techniques survived the target. Every one of them -- injection into free ROM space, dispatch-layer interception, whole-palette stamping, prototype-in-Lua-first -- is load-bearing in the native ports that eventually filled the slot.