Disc layout and boot chain

These pages consolidate everything established about the game’s boot chain. Facts are marked confirmed (verified against disassembly, working reference code, or an actual boot log) or inferred (strongly implied, not independently verified).

Two independent boot logs — USA (proto) SLUS-21262 and Japan SLPM-65800, captured via PCSX2 — are used throughout as ground truth alongside the static disassembly of USA (proto) SLUS-21262. Manual verification on dumped ISO level files was also used to confirm the boot sequence.

• The two release builds share the same main code, but not the same bytes confirmed. All three files are distinct:

  Build	Size	SHA-256
  Debug (proto)	581,552	161bc2e5e7c49fdde4f9d5199a43f238c5d88703d909f1f0362f1f2b8e74ea99
  USA release	518,576	98a2dcb45c44915c666639fa7946224d2a0d0da4eb12630e2283693ac68f5440
  Japanese release	518,576	213adf37b41b475aaeae4d2e59eb1e716bc7070ae04d3ec5a79432fd017e3143

  The two retail files are the same size and differ in 8.6% of their bytes — but those differences are spread across 23,886 runs averaging under two words each, which is what embedded addresses and data look like, not different code. Function-for-function the two are the same: all 1,209 functions confirmed inside the main ELF sit at the same address and the same size in both, and a function is only confirmed when its body matches after J/JAL targets and MIPS immediates are normalised.

  So “the release builds have the same main” is true of the code and false of the file. The prototype’s differs in both.

• The overlays are where the builds actually diverge. In step0_00, only 1,092 of 2,515 shared symbols sit at the same address across the two retail builds — which is why the RMF and EVD pages carry separate ENG and JPN addresses throughout.

• All versions’ IOP kernel images are identical.

• All versions’ custom ELFs are identical.

1. Disc layout

confirmed — cross-validated across all builds and the USA-proto / Japan boot logs:

Region	Extent	Contents
ISO9660 root-directory files	Start of disc → end of IOP kernel	system.cnf, main ELF, IOPRP300.IMG kernel v2.2, and dev modules
Padding	End of IOP kernel → start of the custom IOP ELFs	~900 MB
Custom ELFs	0x10000 bytes, immediately before the TOC	An unknown custom packed EE ELF section (§6.2)
File table (TOC)	0xD800 bytes, resolved to sector 494979 in both regions	Scrambled 3-plane TOC (§7)
Filesystem	End of file table → end of disc	Remaining game data, including game-specific IOP modules, resolved via the TOC

main’s sector varies by region (USA-proto: 274, Japan: 270), and so does its size (0x8D900 vs 0x7E300) and the disc’s total sector count (2,242,608 vs 2,239,296) — yet the TOC resolves to the identical absolute sector (494979) in all builds.

2. ISO9660 root directory placement

confirmed — the root directory entries are in this order: ., .., dev9, IOPRP300.IMG (kernel image), the remaining dev modules, system.cnf, and main. main is always the last entry in the ISO9660 root directory, but it is not the last physical entry; the last physical entry is the kernel image.

3. Boot chain: two executions of main

confirmed. Read the descriptor volume (LBA 16) for the LBA and size of the root directory. Read the root directory and locate system.cnf. Read system.cnf and locate main. main (entry point 0x00100008 in all builds) executes twice, across two separate EE resets:

Simplified hard-reset boot
  -> IOP Kernel 0.9.1 (BIOS default) loads
  -> main ELF loads and executes (1st time)
       -> triggers sceSifRebootIop (loads the custom kernel image)
       -> triggers an EE-side reboot request
  -> "Update rebooting.." / EE/iR5900 Recompiler Reset
  -> main ELF loads and executes AGAIN (2nd time, same entry point)
       -> now running under the custom IOP Kernel 2.2
       -> proceeds into CBios / MakeFileSystem / sound / TOC read

The single main symbol seen in static disassembly corresponds to two logical phases sharing one entry point — an early phase whose job is to kick off the IOP kernel reboot, and a later phase (after that reboot completes) that performs the actual game bring-up starting with the filesystem.

Not yet isolated: the exact branch or flag distinguishing “first pass, about to reboot IOP” from “second pass, IOP kernel already upgraded.” The flag byte at storage+0xD99B (§4.5) is a candidate worth re-examining specifically for this, since a storage struct freshly constructed after an EE reset would plausibly read differently than one still holding pre-reboot state.

confirmed — all builds of the game share the exact same custom kernel image content.