Files

T

ReaperOfVeriod a02f79a6d1 Initialise native Rust port of Ratchet & Clank: Going Commando

Sets up the foundation for reimplementing the PS2 game in Rust rather than
emulating it. Nothing is implemented yet; this is the scaffold, the verified
target and the working agreements that keep a long project coherent.

Target disc, verified against a real image:

  SCUS_972.68 v1.01, USA Black Label, NTSC 60 Hz
  boot ELF 2,618,684 bytes, SHA-1 bacda860...d098a77, entry 0x00131AE8

The entry point independently matches the value recorded by the rac2-gc-decomp
community reference, which cross-confirms the identification. This is the exact
build the upstream research pins; Greatest Hits v2.00 is a different binary and
is not the target. NTSC matters beyond label compatibility: PAL discs run 50 Hz,
which would make chargeboots and other speed-sensitive movement run at 5/6
speed. Verifying the disc before writing movement code avoids discovering that
in Phase 5.

Contents:

- Five-crate workspace (formats, extract, game, video, engine) on Bevy 0.19.1,
  matching the version ReRAC uses so its Graphics Synthesizer and VU work stays
  portable. `cargo check --workspace` is clean.

- tools/identify-disc.py, which reproduces the identification against any
  disc image and distinguishes a truncated dump from a non-PS2 image.

- .githooks/pre-commit, refusing game data from entering git history: disc
  image extensions, asset directories, container signatures at offset 0, and
  files over 50 MiB. Verified against seven cases including a disc image
  renamed to look like source. Now that this pushes to a remote, this matters
  more than it would have locally.

- AGENTS.md, the operating agreements: no game data ever, reproduce the PS2
  float model rather than approximating it, bound every read, verify against
  the real disc.

- PROVENANCE.md, recording that this follows ReRAC (ISC) and learns from
  rac2-gc-decomp (MIT). Wrench is used as a written specification only and no
  GPLv3 code is copied, since that would relicense everything derived from it.
  RAC2Decomp is explicitly not used: its provenance is disputed in the upstream
  community reference, and it targets the wrong region.

- docs/roadmap.md, phased so the riskiest unknowns are retired early. The two
  that matter: overlay relocation transfers from ReRAC and makes 27 level
  overlays tractable, while VU1 microcode is binary and is the hardest single
  item. Phase 5 is a deliberately scoped Veldin vertical slice as the go/no-go.

2026-10-09 15:42:10 +02:00

3.2 KiB

Raw Permalink Blame History

Disc identification — VERIFIED 2026-10-09

Your disc was identified while initialising this repository. It is the best case target: the exact build that OpenRAC/rac2-gc-decomp pins.

Result

Field	Value
Title	Ratchet & Clank: Going Commando
Serial	`SCUS_972.68`
Version	1.01 (Black Label)
Video mode	NTSC (60 Hz)
Region	USA
ISO 9660 volume	`RATCHETANDCLANK2`
Image size	3,828,350,976 bytes
Publisher / Preparer	SONY / INSOMNIAC

Boot executable (`SCUS_972.68`)

Property	Value
Size	2,618,684 bytes
SHA-1	`bacda860cbd6723142e86db56f197e47e728970f`
CRC-32	`262705496`
Format	ELF32, little-endian, MIPS (EM_MIPS = 8)
Entry point	`0x00131AE8`

The entry point 0x00131AE8 matches the value independently recorded by the rac2-gc-decomp community reference for this target, which cross-confirms the identification.

Why this matters

VER = 1.01 + VMODE = NTSC is exactly what we want.

v1.01 is the pinned target. rac2-gc-decomp states plainly that Greatest Hits v2.00 is a different target — do not point a build at it. You have the Black Label original.
NTSC means 60 Hz. This is the detail that decides the movement constants. PAL discs report VMODE = PAL and run the game at 50 Hz, which makes the chargeboots and other speed-sensitive movement run at 5/6 of their intended speed. Building against NTSC timing constants is correct for this disc.

There is no ambiguity to resolve, so no disc-conversion work is required.

Not used for identification

Redump's catalogue records the first track hash for this disc as f2cfaf0eb12b3c0d8fd6db7aa49ce032e8a6020b (CRC-32 3828350976). The values computed above are the boot executable's hash, which is a different thing: a single file rather than a track. Both are stable identifiers, but they must not be compared against each other. We identify by serial + VER + VMODE + boot-ELF SHA-1, which is unambiguous.

Disc layout (observed)

R&C2 lists its assets in the ISO 9660 filesystem, unlike R&C1. Confirmed entries at the disc root:

SYSTEM.CNF        60 bytes
RC2.HDR        408,444     <- the table of contents, as a named file
SCUS_972.68  2,618,684     <- the boot ELF
IOPRP255.IMG   264,449
Z6TAIL.DUP           0
G/...                    <- global WADs (LEVEL*, AUDIO*, SCENE*, MPEG*, HUD, …)

RC2.HDR being present as a real file is convenient: the extractor can read the table of contents directly instead of hunting for it at a fixed sector as with R&C1. The G/ WADs are listed in the filesystem, so enumeration works too.

Observation on MPEG WADs

The three MPEG WADs are large — roughly 1.0 GB, 1.3 GB and 115 MB. That is a substantial fraction of the 3.8 GB disc and will matter for the video phase (R&C2 uses IPU/FMV streams, notably the title screen). Worth factoring into the plan: video is a large data problem before it is a decoding problem.

Reproducing this check

tools/identify-disc.py performs the same identification against any R&C2 disc image and prints the table above. It reads only the ISO 9660 structures, SYSTEM.CNF and the boot ELF (a few MB of seeks), so it runs in well under a second on a local image.

3.2 KiB Raw Permalink Blame History