Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
86 changes: 86 additions & 0 deletions bios/SCPH5552.toml
Original file line number Diff line number Diff line change
@@ -0,0 +1,86 @@
# bios/SCPH5552.toml — BIOS build profile for the retail Sony SCPH-5502/5552
# (Europe) v3.0 01/06/97 image ("System ROM Version 3.0 01/06/97 E",
# SHA-256 1faaa18fa820a0225e488d9f086296b8e6c46df739666093987ff7d8fd352c09).
#
# Derived from bios/SCPH1001.toml. ROM 0x0000-0x17FFF (boot + Kernel Part 1/2)
# is byte-identical to the US SCPH-1001 v2.2 image, so every kernel anchor
# below (copy windows, install slot, deliver_event_ret, shell entry) carries
# over unchanged. The shell (ROM 0x18000+) DIFFERS from the US image; this
# profile therefore has no shell seeds (recompiler/seeds/
# phase2_ghidra_seeds_SCPH5552.json = the SCPH1001 corpus filtered through
# tools/filter_bios_seeds.py, kernel region only) and the shell window runs
# through the dirty-RAM interpreter (build with -DPSX_SHELLWIN_INTERP=ON) until
# an EU-shell seed corpus exists.
#
# The .BIN image itself stays untracked (bios/* gitignore rule) — profiles are
# the only tracked contents of this directory.

[program]
name = "Sony SCPH-5552 BIOS (Europe, v3.0 01/06/97)"
id = "SCPH-5552"
rom = "bios/SCPH5552.BIN"
load_address = "0xBFC00000"
entry_pc = "0xBFC00000"
text_size = "0x80000"

[recompiler]
seeds = "recompiler/seeds/phase2_ghidra_seeds_SCPH5552.json"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: When the packaged CLI selects a SCPH5552 BIOS, it loads the legacy root profile instead of this profile and cannot resolve that profile's SCPH5552 seed path. Update packaging to copy bios/SCPH5552.toml and include the referenced seed.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At bios/SCPH5552.toml, line 27:

<comment>When the packaged CLI selects a SCPH5552 BIOS, it loads the legacy root profile instead of this profile and cannot resolve that profile's SCPH5552 seed path. Update packaging to copy `bios/SCPH5552.toml` and include the referenced seed.</comment>

<file context>
@@ -0,0 +1,86 @@
+text_size    = "0x80000"
+
+[recompiler]
+seeds    = "recompiler/seeds/phase2_ghidra_seeds_SCPH5552.json"
+out_dir  = "generated"
+out_stem = "SCPH5552"
</file context>

out_dir = "generated"
out_stem = "SCPH5552"
strict = true

# The BIOS's boot-time bulk copies of CODE out of ROM into RAM. Single source
# of truth for every relocation window in the recompiler AND in the C it
# emits (the generated dispatch's normalize(), the kernel-bless guard, the
# game/shell-overlap tests). Each entry is a CLAIM that the copy is
# byte-verbatim; the runtime's kernel-bless memcmp enforces it for the
# bless window. All bounds are [lo, hi) with hi EXCLUSIVE.
#
# dispatch_key = "ram": functions in the window are keyed by RAM address
# (normalize folds ROM -> RAM).
# dispatch_key = "rom": functions keep their ROM key (normalize folds the
# RAM alias back to ROM).
[recompiler.address_model]
normalize_mask = "0x1FFFFFFF"

[[recompiler.address_model.copy]]
name = "Kernel Part 2"
rom_lo = "0x1FC10000"
rom_hi = "0x1FC18000"
ram_lo = "0x00000500"
runtime_base = "0x00000500" # KUSEG — the kernel executes uncached-region code cached at 0x500
dispatch_key = "ram"
kernel_bless = true

[[recompiler.address_model.copy]]
name = "Shell"
rom_lo = "0x1FC18000"
rom_hi = "0x1FC43000"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1: When the EU shell reaches code above RAM 0x5B000 with PSX_SHELLWIN_INTERP, the runtime cannot execute the copied bytes through the interpreter. Extend the runtime dirty range and this address-model window together, or prove that the upper copied region is unreachable before shipping this profile.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At bios/SCPH5552.toml, line 58:

<comment>When the EU shell reaches code above RAM `0x5B000` with `PSX_SHELLWIN_INTERP`, the runtime cannot execute the copied bytes through the interpreter. Extend the runtime dirty range and this address-model window together, or prove that the upper copied region is unreachable before shipping this profile.</comment>

<file context>
@@ -0,0 +1,86 @@
+[[recompiler.address_model.copy]]
+name         = "Shell"
+rom_lo       = "0x1FC18000"
+rom_hi       = "0x1FC43000"
+ram_lo       = "0x00030000"
+runtime_base = "0x80030000"     # KSEG0 — LoadRunShell jumps to 0x80030000
</file context>

ram_lo = "0x00030000"
runtime_base = "0x80030000" # KSEG0 — LoadRunShell jumps to 0x80030000
dispatch_key = "rom"
kernel_bless = false
# NOTE (do not "fix" without evidence): runtime/src/bios_hle.c documents the
# actual LoadRunShell copy as 0x67FF0 bytes (ROM 0xBFC18000 -> RAM 0x30000..
# 0x97FF0). Every pre-profile window constant covered only 0x2B000 of that,
# and dirty_ram_interp.c tracks live RAM in [0x5B000,0x8F000) as an open
# class-B bug. Widening this window is a REAL BEHAVIOR CHANGE requiring its
# own evidence-backed commit — it is not a parameterization cleanup.

# Kernel-RAM PCs the BIOS overwrites with 4-instruction dispatch stubs at
# runtime (CLAUDE.md rule 18; docs/dynamic_handler_install.md). The emitter
# plants a dirty-check hook at these PCs so the installed stub executes.
[[recompiler.install_slots]]
ram_addr = "0x00000CF0" # SIO data-byte handler dispatch slot

# Per-image anchors couriered into the generated C (psx_bios_image) for the
# runtime HLE tier. Values are FACTS about this image, not tunables: the
# shell entry is where LoadRunShell (ROM 0xBFC06FF0) jumps after its copy;
# deliver_event_ret is the instruction after the kernel DeliverEvent loop's
# `jalr v0` (kernel RAM 0x1718), the $ra a delivered event callback returns
# through. Omit a key on a BIOS that has no such anchor — the runtime then
# treats that HLE feature as structurally unavailable instead of firing on a
# wrong address.
[recompiler.runtime_exports]
shell_entry_phys = "0x00030000"
deliver_event_ret = "0x80001720"