One Dreamcast Character Does Not Fit In An Entire Saturn

The claim

Someone told me that getting MvC1 from the Dreamcast onto a Saturn would be straightforward. It's a reasonable-sounding claim — both are Sega consoles, both use Hitachi SH processors, and MvC1 is a 2D fighting game, so there are no polygons to cut down.

All three of those are true. None of them survive contact with the numbers.

What is actually on the disc

The dump is a three-track GD-ROM, 1,188,409,587 bytes. Its bootstrap identifies it plainly:

SEGA SEGAKATANA / SEGA ENTERPRISES     T1202N  V1.000   1999-07-29
title  MARVEL VS.CAPCOM
boot   0.BIN

The high-density track carries 504,150 sectors of 2048 bytes — 1,032 MB of addressable area — holding 334 MB across 328 files. And that data is dominated by one file type:

The .PST files are the per-character data, named by a hex id. Splitting them by size separates the fighters from everything else:

Nineteen is exactly right. MvC1 has 15 main characters plus Roll and Shadow Lady with unique art — 17, which is precisely the contiguous 0C–1C run — and Onslaught's two forms account for the outliers 2D and 2E.

A Dreamcast character is 9.80–13.09 MB, averaging 11.41 MB.

The comparison that ends the discussion

I have the Saturn side measured from the MSHvSF disc, so this is like for like:

The average Dreamcast character is 1.45× the Saturn's entire memory (the largest, 13.09 MB, is 1.66×) — all of it, including the mandatory 4 MB expansion cartridge — and 17.9× the slot a character's art actually gets.

The executable is its own version of the same joke. 0.BIN is 4,930,596 bytes: the Dreamcast game's code alone is 2.35× the Saturn's 2 MB of main work RAM.

"Just compress it harder"

The natural objection is that 11.97 MB must be bloat — Dreamcast had room, so surely the data is stored lazily and would pack down. I tested it rather than assuming:

The Dreamcast data is already compressed. Entropy of 7.01 bits per byte with 2.3% zeros is not a file waiting to be packed — it is a file that has been packed. The 17.9× gap is real data.

And the Saturn end has no give either. This series' own encoder for the MSHvSF sprite codec reaches 1.04× Capcom's own density — the Saturn side is already as tight as the people who shipped it managed. Neither end has anywhere near a 17.9× improvement available.

The hardware gap, for completeness

One detail is worth stating because it is routinely assumed backwards: SH-2 code runs on an SH-4. SH-4 code does not run on an SH-2. Upward compatibility only points one way. 0.BIN uses instructions the SH-2 does not implement, so there is no question of running Dreamcast code on Saturn hardware — it would need recompiling from source that nobody outside Capcom has.

The part that actually matters: it is the wrong direction

Size and hardware make the port hard. This next bit makes it pointless.

Both versions descend from the same CPS-2 arcade original. The Saturn MSHvSF port is a source-level SH-2 recompile whose assets were pushed through deterministic converters — and this series has reverse-engineered those converters and can now run them in both directions, each verified to byte-identity.

Going via the Dreamcast means undoing a transformation that moved the data further from the Saturn's format, to get back to something arcade-shaped, so that you can then apply the arcade→Saturn conversion anyway. It inserts an unsolved reverse-engineering problem — the .PST container and whatever codec lives inside it — in front of a pipeline that already works starting from the arcade ROM.

The arcade ROM is 4 MB with plaintext data tables. The Dreamcast build is 334 MB of already-compressed unknown formats. There is no reading under which the second is the easier starting point.

Why the claim sounds right

Two intuitions, both wrong in an interesting way:

"Both are Sega consoles with SH CPUs." True, and irrelevant. The ISA compatibility runs the wrong way, and the memory gap is 3× on the spec sheet but 15–18× per character in practice, because the Dreamcast build spends its 16 MB rather than economising.

"It's 2D, so it should scale down." Being 2D is exactly what makes it large. There are no polygons to reduce and no level-of-detail to drop — it stores every animation frame at arcade fidelity because it has the memory to. The Saturn's constraint was never geometry. It was always memory, which is why Capcom's own Saturn ports lean on a mandatory 4 MB cartridge and a custom sprite codec.

"But the Dreamcast version was really going to the Saturn"

The follow-up claim: that this build began life as a Saturn project, and would therefore be very similar in structure and cheap to move across.

The historical half isn't something a disc can settle — Capcom's internal plans aren't in the bytes. The structural half is directly testable, because I have the Saturn's formats fully reverse-engineered. Tested five ways:

Nothing. Not one Saturn structure survives anywhere in the shipped build.

The endianness fingerprint settles it

The sharpest test fell out of the earlier finding that the Dreamcast carries arcade tables byte-swapped. Run against both ports, with a control:

The Saturn stores arcade data byte-identical, because the SH-2 is big-endian like the 68000 it came from. The Dreamcast stores the same tables byte-swapped, converted for the little-endian SH-4.

A build that began as a Saturn project would carry big-endian data, and retargeting it would leave big-endian remnants behind. Every carried table in 0.BIN is swapped for little-endian — and the control confirms the test can tell the difference, since the Saturn's own table is found unswapped and not swapped.

What is true, and why it still doesn't help

There is a real sense in which the two ports resemble each other: both are source-level recompiles of the same CPS-2 arcade game, and both carry some arcade tables verbatim. That's shared ancestry — and it's precisely why the arcade ROM is the right source for either of them.

It is not shared structure. Containers, compression, sprite codec, colour conversion and byte order all differ, all the way down. Similar ancestry doesn't make a port cheap; identical formats would, and there aren't any.

And the claim wouldn't help even if the history is true. What a Saturn import needs is the arcade → Saturn conversion — and that already exists in shipped form, in Capcom's own Saturn MSHvSF from 1998, whose converters I've reverse-engineered and can run in both directions. A hypothetical unreleased Saturn MvC1 would at best be a second copy of a pipeline I already have.

So is the Dreamcast disc useless to me?

That's a sharper question than the one I set out to answer, and it deserves a separate answer. "Bad port base" and "useless as a source" are different claims, and the second one turns out to be false — one of the findings actually weakens something I published in the Saturn writeup.

It carries the two tables the Saturn threw away

Scanning 0.BIN for the arcade tables, byte-swapped (SH-4 is little-endian, the arcade 68000 is big-endian):

Put next to the Saturn, the two ports are complementary witnesses — each kept what the other dropped:

This weakens a conclusion I published. The Saturn post concludes that hitboxes and box-shape are re-authored by the Saturn port and therefore "must be authored for any character imported to Saturn." The first half stands — the Saturn genuinely doesn't carry them. The second half was an over-reach. The Dreamcast demonstrates that the arcade hitbox and box-shape tables are directly usable, verbatim, by an SH-family recompile of this same game. Capcom carried them into one SH port and re-authored them for the other; that was a choice, not a necessity.

For an import where I'm writing the character's logic anyway, those tables can be carried rather than authored — provided I write the reader to match. That's a materially smaller job, and it moves two of the three "blocked" rows out of the unknown column.

Palette stays blocked and is the exception: 0% in both ports, because both converted it. Though for an import that path is mechanical anyway — take the arcade palette through the Saturn's own PALET.TBL, the 128KB CPS-2→BGR555 LUT already decoded in the Saturn work.

It is Capcom's own SH implementation of this exact game

0.BIN is 4,930,596 bytes of clean SH code — 97% of sampled words decode — loading at 0x8C010000:

0x8c011000  mov     #1,r3
0x8c011004  mov.l   r3,@r2
0x8c011006  mov.l   0x8c011034,r3
0x8c01100a  jmp     @r3

Phase 3's wall is hand-authoring SH-2 character logic, because nobody outside Capcom has the Saturn source. The Dreamcast supplies Capcom's own SH-family implementation of Marvel vs. Capcom specifically — not a cousin game, the same one. SH-2 and SH-4 share the base instruction set, register conventions and calling structure, so algorithm shapes read across far more directly than translating 68000 would.

That is not source code and it is not a shortcut to a working character. It's a reference for how Capcom expressed this engine's per-character behaviour on an SH CPU — which is exactly what Phase 3 has to reproduce.

Revised summary

So: don't port from it. Do keep it open on the other monitor.