# Disc layout

Target: `SCUS_972.68` v1.01 (USA Black Label, NTSC 60 Hz).

All integers are little-endian. Sector size is `0x800` (2048) bytes throughout;
everything on the disc is sector-aligned.

## Root directory

Observed by enumerating the ISO 9660 filesystem:

```text
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     IOP modules
Z6TAIL.DUP           0     ISO 9660 padding
G/...                    96 asset containers (see global-wad.md)
```

`RC2.HDR` being present as a real file is convenient. R&C1's equivalent is not a
named file and sits at sector 1500.

## ISO 9660 usage

The filesystem is load-bearing for this game, unlike R&C1 whose filesystem is
nearly vestigial. Everything the engine needs is either a file here or a sector
range declared by a container header.

**Consequence for the extractor:** `G/*` can be enumerated by walking the
directory. There is no need to parse a table of contents to find the assets.

### Details that will bite

- **Directory records store each 32-bit field twice**, little-endian then
  big-endian. Reading 4 bytes where the record has 8 shifts every subsequent
  field and yields an empty or nonsense listing with no error.
- **The `CD001` signature is at sector offset `0x0001`**, not `0x8001`. The
  latter is its absolute file offset and lies outside a 2048-byte sector, so a
  bounds-checked read there fails rather than returning empty bytes.
- **The directory flag is at record offset 25**, bit 1. Do not rely on the
  identifier's trailing `/`: not every writer sets it, and the flag is
  authoritative. Getting this wrong writes a subdirectory's *contents* to a file
  named after the directory.
- Records never span a logical block; a zero record length means "advance to the
  next block".

## Table of contents (`RC2.HDR`)

The game also maintains a table of contents, and a second copy lives at sector
**1001** (`SYSTEM.CNF` sits at sector 1000 on this disc). The ToC begins with a
chain of global container headers, each `{header_size, sector}`, running from
offset 0 until the level records begin.

Verified on this disc:

```text
offset 0x0000  header_size 0x0328  sector 2610      MPEG
offset 0x0328  header_size 0x0040  sector 1216608   MISC
offset 0x0368  header_size 0x1870  sector 1223855   HUD
offset 0x1bd8  header_size 0x0a48  sector 1242375   BONUS
offset 0x2620  header_size 0x1800  sector 1257884   AUDIO
offset 0x3e20  header_size 0x0ba8  sector 1275113   SPACE
offset 0x49c8  header_size 0x0170  sector 1280474   SCENE
offset 0x4b38  header_size 0x03c8  sector 1282655   GADGET
offset 0x4f00  header_size 0x00f8  sector 1285084   ARMOR
```

The nine header sizes match the container table in
[`global-wad.md`](global-wad.md) exactly, which cross-confirms both readings.

### Level records

Level records follow the globals on a **`0x2000`-byte stride**, each beginning
with `{header_size, sector}` where the sector is an **absolute** disc sector:

```text
+0x00000  LEVEL  0x0060  sector 1286296
+0x02000  SCENE  0x137c  sector 1296509
+0x04000  AUDIO  0x1018  sector 1309652
+0x06000  <zero>
...
```

Levels appear as `LEVEL`/`SCENE`/`AUDIO` triples separated by gaps, and every
level's sector cross-checks against the `G/LEVEL<n>.WAD` entry found by walking
the filesystem. That agreement between two independent routes is what confirms
the layout; a single route agreeing with itself proves nothing.

**Not yet implemented.** The extractor does not read the ToC. It enumerates the
filesystem instead, which is sufficient and simpler. The ToC becomes necessary
when the game needs to resolve a sector at runtime, or when per-level overlay
loading has to be understood (Phase 3).

## Boot executable

`SCUS_972.68`, 2,618,684 bytes, SHA-1
`bacda860cbd6723142e86db56f197e47e728970f`.

ELF32, little-endian, MIPS (EM_MIPS = 8), entry point `0x00131AE8`, `$gp`
`0x001AEFF0`. The entry point independently matches the value recorded by the
`rac2-gc-decomp` community reference, which cross-confirms the disc
identification.

## Provenance

Container layout knowledge was guided by the Wrench project's format
descriptions (<https://github.com/chaoticgd/wrench>, GPLv3). **No Wrench code is
copied** — see `PROVENANCE.md`. Structures here are written from the
specification and verified against this disc.