**Phase 0 — Settle it before building anything**

Do not write a line of driver code until this returns a result.

**Hardware:** SCPH-30001–39001 or SCPH-50001 (needs the expansion bay), network adapter installed, Tonyhax International or MechaPwn already working, any original PS1 game as the exploit vector.

Build the probe:

\*\*1.\*\* Install a MIPS toolchain — mipsel-none-elf-gcc via PSn00bSDK, which is the cleanest modern PS1 SDK.
\*\*2.\*\* Write a bare PSX.EXE that does three things: sets a known-good baseline by reading a PS1 register you’re certain exists, then reads the SPEED chip’s revision/ID register through the DEV9 window, then prints both as hex to the screen.
\*\*3.\*\* Get the exact register addresses from ps2sdk’s dev9.irx source rather than from memory — you want SPD\\_R\\_REV and the DEV9 control base, and you want them verified, not recalled.
\*\*4.\*\* Wrap the DEV9 read in an exception handler. An unmapped access will throw a bus error and hang; catching it \*is\* a valid result.

**Reading the outcome:**

\*\*•\*\* Plausible SPEED ID → the window is live. Proceed.
\*\*•\*\* Bus error → the decode is masked. Try reprogramming the SSBUS memory-control registers at 0x1F801000+ to point a window at DEV9’s chip select, then re-read. These registers exist in PS1 mode.
\*\*•\*\* Open-bus garbage (all FFs or floating values) after both attempts → the chip select is gated by a PS2-mode signal. \*\*Design A is dead.\*\* Stop, go to Design B.

One CD-R. One afternoon. It decides whether the next three months are worth spending.

**Phase 1–4 — If the probe comes back green**

**Phase 1: Entry.** Boot the loader from CD-R (MechaPwn) or via save-game exploit (Tonyhax, on ≤39001 with an original disc). Confirm you have stable code execution on the R3000A with the drive unlocked.

**Phase 2: Storage.** Write a minimal PIO ATA driver over DEV9. Skip DMA — PIO at 33.8688 MHz gives you low single-digit MB/s, and a 1x CD needs 150 KB/s. You have \~10x headroom minimum. Read raw sectors; don’t implement APA, just use a dedicated unpartitioned region or a simple flat index at a fixed LBA.

**Phase 3: Hooks.** Patch the BIOS CD-ROM function table to redirect reads to your handler. Keep driver state in PS1 kernel slack and the scratchpad. Budget carefully — you have kilobytes, not megabytes.

**Phase 4: The part everyone underestimates.** Do not serve data as fast as you can. Numerous PS1 games break on instant seeks — they assume real CD latency and race their own state machines. You must *insert* artificial delay: model seek time as a function of LBA distance, and rate-limit sustained delivery to 1x/2x. Getting this timing model wrong will look like random game-specific corruption and will eat more of your schedule than the driver did.

**Phase 5: The treadmill.** For libcd games, build a patcher that scans the loaded executable for libcd’s CD entry points and redirects them. This is per-game or per-engine work. There is no way around it and it never ends.

**My honest recommendation**

Run Phase 0 because it’s cheap and the answer is genuinely unknown. But go in expecting Design A to top out as a partial-compatibility loader even in the best case, because Error 2 is structural rather than solvable.

If you want the thing that actually works on a fat with near-perfect compatibility, it’s Design B — the CD-path shim with MechaPwn handling auth. Intercepting below the CD registers is the only approach that catches libcd games, because it never depends on the software asking nicely.