Every MvC1 Secret Character Code, Down to the Byte

Many compiled binaries carry hidden features, debug modes and undocumented functionality left behind by developers. MvC1's CPS-2 ROM carries six secret characters behind directional input codes, plus one unused ID -- 0x2E -- with real code references behind it. This post is the catalog: what the codes are, how they encode, and what every character ID number means.

The Six Shipped Codes

All codes are directional-only, entered on the character select screen, and all six start from Zangief's portrait. Direction encoding: Up 0x08, Down 0x02, Left 0x04, Right 0x06.

Two things in that table are easy to skim past. Roll is not a palette swap -- she is a unique character who happens to be code-locked, which is why her ID sits inside the normal 0x02-0x22 band rather than the secret band. And Orange Hulk has no armor: it is a color change only, with no armor animations behind it, despite what the palette implies.

The Proposed Seventh: ID 0x2E

The Armored Spider-Man code was designed, not found. It deliberately breaks two conventions: it starts on Spider-Man's portrait rather than Zangief's, and it is much shorter than anything shipped.

Sequence (10 inputs): Down, Down, Left, Left, Up, Up, Right, Right, Down, Down Byte pattern: 02 02 04 04 08 08 06 06 02 02

The design rationale was a "box" shape that is easy to remember, thematically anchored on the base character's own portrait, and pattern-unique against all six shipped codes. Plotting every code's length makes the choice explicit -- the shipped codes cluster at 14-17 inputs:

The evidence that made 0x2E worth designing a code for -- 85 real code references and four disabled load points -- is documented in full here. That plan was later retired: the slot went to Dark Sakura, first on a donor chassis and now as a native port.

Character ID Table

IDs are even numbers. The normal roster occupies 0x02-0x22; secret variants occupy 0x24-0x2E, one step of +0x18 or +0x20 above their base.

How the Detector Works

The code checker is a single accumulate-or-reset loop over a circular buffer of recent directional inputs, guarded by two conditions: the cursor must be on the correct starting cell, and inputs expire after roughly 60 frames (one second) of inactivity.

stateDiagram-v2
  [*] --> Idle
  Idle --> Buffering: directional input
  Buffering --> Buffering: append byte to circular buffer
  Buffering --> Match: buffer equals a secret pattern and cursor on start cell
  Buffering --> Idle: wrong input or 60 frame timeout
  Match --> Activated: set secret id, load palette, play confirm
  Activated --> [*]

Two things about that diagram are honest limits rather than findings. The input buffer's address was never located -- it stayed TBD through the whole project, because the interrupt-hook approach that eventually shipped sidestepped the detector entirely rather than extending it. And the "load palette, play confirm" step is inferred from behavior, not read out of disassembly.

The Three Scanners

The live scanners run as autoboot scripts against the emulator, so a single command boots the game, attaches the probe, and dumps a table -- no manual debugger stepping.

The forced-ID probe is the cheapest experiment in the set: write the ID the engine has no row for, then watch what it reads instead.

References

• Code Discovery: Community findings, MAME debugger traces
• Character IDs: PalMod source, ROM analysis
• Input System: CPS-2 hardware documentation