ReaperOfVeriod
a02f79a6d1
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.
87 lines
3.2 KiB
Markdown
87 lines
3.2 KiB
Markdown
# 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. |