Byte-Identical on a CD: What the Saturn MSHvSF Port Actually Is

Why a Console Port Became Interesting

This started as a detour from a stuck problem. While the NYC stage port sat on a load hang, a side question got interesting: MSHvSF had a Sega Saturn port in 1998, famously faithful, running on the 4MB RAM cartridge. If that port's data formats were close to arcade, the Saturn version could be a second source of truth for the RE -- or even a second target.

The character-port work spends weeks locating tables inside an encrypted CPS-2 ROM. If a retail CD carried the same tables in the clear, that changes the economics of everything downstream. So I audited the disc against the arcade ROM, byte by byte. The full writeup is the SATURN_VS_CPS2 gist; here is what it turned out to be.

A Recompile, Not a Rewrite

The Saturn port is a source-level SH-2 recompile with mechanically-converted assets. Not an emulator, not a rewrite-from-scratch: Capcom compiled the game's logic for the Saturn's SH-2 CPUs and ran the arcade's data through deterministic converters. The evidence is unusually clean.

• Character data tables are byte-identical to arcade. Shuma-Gorath's file (MC05) carries his 1,604-byte frame-record table and his 1,216-byte sound map byte-perfect against the CPS-2 ROM. The same tables I spent weeks locating in the arcade ROM for the native-character work exist on a consumer CD, unencrypted, in files named per character.
• Sprites are a deterministic pen-map away from arcade tiles: saturn_pixel = (arcade_pixel + 1) & 15, so arcade's transparent pen 15 wraps to Saturn's 0, all wrapped in a bit-packed codec keyed by 2-bit codes. Proof standard: decoding record #694 produces 30 tiles with 0 of 7,680 pixels differing from the arcade originals under the pen-map.
• PALET.TBL is a 128KB lookup table mapping every CPS-2 12-bit color to Saturn RGB555 -- the whole colorspace conversion is one precomputed LUT on the disc.
• The roster index is arcade_id >> 1 -- the Saturn character list is literally the arcade's id space with the always-even ids compacted. Shuma's arcade id $0A becomes Saturn slot PL05 / MC05.
• The one place byte-identity fully breaks: audio, re-encoded to 4-bit ADPCM with zero byte-level correspondence to the QSound data.

The decode pipeline, exactly

The sprite transform is small enough to be a diagram and mechanical enough to be reversible -- which is the entire reason the reverse-direction plan (below) is even costable.

Boot Chain and the 4MB Cart

The disc boots through a fixed chain -- IP.BIN -> 00LOAD.BIN -> SYS.BIN -> MM.BIN -- and the whole thing refuses to run without the 4MB RAM cartridge: the cart check validates ID byte 0x5C at 0x24FFFFFF before proceeding. Once up, characters and stages stream from CD into the cart, and the SH-2 feeds decompressed tiles to the VDP1 sprite hardware per frame; sprites stay compressed in the cart and are decoded per-tile on the way to VDP1.

The cart's streaming region is five equal slots of 668,448 bytes (0xA3320) starting at 0x02486BC0, slot k at base + k * 0xA3320. That is the memory choreography the shipped roster is tuned against -- and it is essentially full, which becomes the load-bearing constraint on any reverse-direction plan.

For the arcade project this audit was an immediate, practical win: the Saturn disc is a plaintext mirror of data I otherwise dig out of an encrypted ROM. Byte-identical frame tables on a CD mean a second, independent witness for every table the native-character ports depend on.

Going the Other Direction: MvC on a Saturn?

Once you know the asset pipeline is deterministic and the data tables are arcade-identical, the tempting question writes itself: could MvC1 content -- a character, eventually the game -- go to the Saturn port's engine? I costed it properly rather than vibing it; the full plan is the MVC_TO_SATURN_PLAN gist. It's a phased plan with honest effort ranges, and the ranges are wide because they should be.

The verdict I stand behind: Phases 0-2 are demo-feasible and low-risk -- the pen-map and codec are proven reversible, so building the toolchain, swapping an asset, and getting one MvC sprite rendering in Saturn MSHvSF is a bounded project with a great screenshot at the end. Phases 3-4 are research projects, and I label them that way deliberately. Three walls stand between a rendered sprite and a playable character:

1. The animation stream format is undecoded. Frame tables are byte-identical; the runtime stream that sequences them on Saturn is not yet understood.
2. Character logic means hand-authored SH-2. The recompile is Capcom's source through Capcom's compiler; we don't have the source. New character behavior means writing it, per character, in SH-2 assembly against a partially-understood engine.
3. The 4MB cart is saturated. Five slots of 668,448 bytes, already streaming-tight for the shipped roster. MvC's bigger cast and effects don't fit the existing memory choreography without redesigning it.

So the recommendation in the plan is the one this whole series already lives by: CPS-2-native porting is the right road for gameplay work, and the Saturn is a superb data source and a fun bounded demo target -- not the venue for new characters. Knowing precisely why, with hour ranges attached, is worth more than the fantasy.

Open Items

Stated plainly, because the project rule is no false success claims:

• Nothing MvC-related runs on a Saturn today. Phases 0-2 are a plan, not an artifact.
• The animation stream format is undecoded -- frame tables are byte-identical, the sequencer that plays them on Saturn is not yet understood.
• Audio has zero byte-identity with the arcade -- the Saturn's 4-bit ADPCM is a separate encoding, not a witness for the QSound data.