Pretty Soldier Sailor Moon S

Disc Archaeology

Findings from a byte-level analysis of the Japanese retail disc image (597,999,616 bytes / 291,840 blocks).

A complete debug menu ships on the disc

The disc root contains gmdebug — an 83,104-byte standalone debug program, pressed onto every retail copy. Its menu strings describe a full development tool:

• Modes: BATTLE / DEBUG BATTLE / TITLE / DATA BASE / DEBANIM-1 / DEBANIM-2 (animation viewers) / GAME / STAFF ROLL / SUPER ENDING / EXIT
• Per-player cheats: MUTEKI (invincibility), TIME INFINITY, handicap, speed and color overrides
• Live memory readouts: SYS_FREE / VRAM_FREE / DRAM_FREE NOW=%06d
• Full character and stage select lists (see below)

The main executable (launchme) contains the strings TaskDebug and gmdebug, indicating it can spawn the debug program directly. A leftover development-kit string sits alongside: "Cannot communicate with Mac" — the tether check for 3DO's Macintosh-based debugging link.

The debug menu preserves earlier stage names

The debug stage list reads: GAME CENTER, SCHOOL, JINJYA, PARK, TAIIKUKAN, CERKIT, YACHT, DOOR, NEO CRYSTAL, CRYSTAL PALACE. Position 7, "YACHT", corresponds to the shipped file 06_Pool.pak — the pool stage apparently began life as a yacht/harbour setting and kept its old name in the debug tool. "CERKIT" (circuit) is a romanization slip that also survives in the shipping filename 05_Cerkit.pak.

NUPTUNE

Sailor Neptune is spelled "NUPTUNE" throughout — in the debug menu's character roster and in the shipped animation archives (Nuptune1P_0.pak, Nuptune2P_1.pak, etc.). The misspelling was evidently entrenched in the project's asset pipeline.

A Japanese-named folder in the filesystem

The directory /data/SE35ウラヌス ("SE35 Uranus", in raw Shift-JIS katakana) sits in the Opera filesystem alongside its ASCII siblings — a working folder holding four Uranus voice samples (Uranus11.ADPCM–Uranus14.ADPCM) whose name was never romanized before mastering. Opera filesystems are meant to carry ASCII names; on non-Japanese systems this entry renders as garbage bytes.

Superseded assets pressed to disc

The team's backup convention — appending (org) — shipped along with the game:

• 08_NeoCrystal.pak(org1) through (org5) — five successive revisions of the Neo Crystal stage alongside the final, a complete iteration history of one arena.
• 03_Kouen.pak(org), 07_Door.pak(org), SE60.PAK(org) — older versions of a stage, a door arena and a sound bank.
• The staff-roll font files are named Stuff.Font.OBJ and StuffRoll.data — "Staff Roll" misspelled as "Stuff Roll" — and the font ships with both compiled (.OBJ) and source (Moon.Font.SRC) forms.

Multi-program architecture

Beyond launchme, the disc carries several cooperating ARM programs: sub (161,024 bytes), and the parenthetically-named movie players MovieDemo(Main) and MovieDemo(Sub) (identical 71,872-byte sizes). A launch command survives in the executable: MovieDemo(Main) MoonOp.Film 18 12 5fff. There are no text credits on the disc — the staff roll is pre-rendered graphics (StaffRoll.pak/StaffRoll2.pak).

Filesystem notes

The redundant directory copies ("avatars") of /System/Drivers, Folios, Programs and Scripts, plus rom_tags, disagree between copies — stale older generations from multi-pass mastering, pressed into every disc. The root directory copies verify hash-identical, so this is a mastering artifact, not dump damage.

Unallocated space

63,351 blocks (~124 MB, 22% of the disc) belong to no file. Every byte was checked: 100% standard iamaduck mastering filler, nothing hidden inside.