Root-caused on Tomba 1: overlay_autocompile_cmd's bare 'python' resolved
through PATH to the devkitPro MSYS2/Cygwin python (usr/bin precedes the
Windows install), which segfaults (exit 0x0B00, signal 11) under the
kill-on-close job spawn BEFORE writing a byte — so every compile failed
with '(no output captured)' and nothing pointed at the cause; the title
silently ran interpreted.
At configure time, resolve the command's first token exactly as
cmd.exe /C will (SearchPathA with .exe), print the binding once, and
warn loudly when msys-2.0.dll/cygwin1.dll sits beside the resolved
interpreter, recommending the Windows launcher form 'py -3 ...'.
Also fail loudly up front when the token doesn't resolve at all.
Doc'd in ASYNC_OVERLAY_COMPILE.md. Title game.toml fixes (python ->
py -3) ship separately in each game repo.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Salvaged from PR #13 (feat/launcher-stb-revamp, commit 2ba52e97) by
NyperYuhgard. Master fatal-halts on any DMA start for channel 5; this
moves words to/from RAM directly (device side unemulated: RAM-to-device
reads-and-discards, device-to-RAM zero-fills) and completes the
transfer with the normal IRQ path.
Note: zero-filling from an unemulated expansion device is weaker than
the fail-closed psx_fatal_halt default the other channels follow; kept
as submitted because the contributor exercised it on a real title.
Trimmed from the original hunk: unused DMA_PIO_CYCLES_PER_WORD macro
and mdec_finish_async_{in,out}_transfer wrappers nothing references.
Co-Authored-By: NyperYuhgard <noreply@github.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Salvaged from PR #13 (feat/launcher-stb-revamp, commit 9fd2876c) by
NyperYuhgard. Adds to the dirty-RAM interpreter:
- LoadAddressError/StoreAddressError delivery for misaligned LH/LW/LHU/
SH/SW and misaligned JR/JALR targets, via a new interp_exception()
that performs the architectural COP0 sequence (BadVAddr, Cause ExcCode,
SR mode-stack push, EPC, BEV-selected vector).
- COP0 Cause write protection on MTC0/CTC0.
- CFC0/CTC0 aliases (identical to MFC0/MTC0 on R3000A).
Two deviations from the original:
- The original masked Cause writes to bits [15:10] (backwards vs
hardware); corrected to the writable software-interrupt bits [9:8]
per psx-spx / PCSX-Redux, which also un-deadens the psxTestSWInts
recheck below it.
- The original's post-RFE immediate psx_check_interrupts recheck is
dropped: master already delivers post-RFE interrupts through
psx_rfe_mark_escape() and re-checking inside the handler window is
the documented dbg-build boot-wedge livelock.
Co-Authored-By: NyperYuhgard <noreply@github.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
copy_directory merges, so a mod package deleted from source survived in the
build output indefinitely -- it kept showing on the Mods page and inflated
the release packagers' catalog assertions (Tomba 2 found 7 manifests where 5
exist). Remove the staged tree first; this runs before the game's own
POST_BUILD copy, so game and framework catalogs both land on a clean slate.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Loading acceleration is a property of the emulated hardware, not of any
particular disc, so having each title carry its own copy of the same two
manifests and plugins was duplication waiting to drift.
- target game_id "*" now matches every game. An empty target list still
matches nothing, so a malformed manifest fails loudly as before.
- mods/builtin/packages ships psx.enhancement.fast-loading and
psx.enhancement.cd-speed: independent host-pacing and CD-timing mods,
each a free integer multiplier (1..1024) plus a tickbox that uses
disabled_by to grey out the field it overrides.
- runtime/src/mod_builtin_speed.c registers both activation plugins.
- runtime.cmake stages mods/builtin into every game's output beside its own
catalog, before the game's own copy, so a title can still override an id.
Titles adopting these should delete their per-game copies; keeping both
would show two of each mod.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Players asked for CD speeds beyond the curated 2x/4x list and for the two
loading accelerators to stop being one control (GH TombaRecomp#5: a
speedrunner wants shorter loads but NOT the host speed-up, which runs past
the loading screen and breaks a skip).
Three changes, all general:
- psx_mod_set_disc_speed accepted only divisor 2 or 4. That was policy,
not safety: cdrom.c divides the sector delay and floors the result at
CDROM_MIN_DELAY, and apply_speed leaves XA streaming at authentic
timing, so no positive divisor can produce a zero-delay storm or
pitch-shift FMV audio. Accept 1..PSX_MOD_DISC_SPEED_MAX and let the
mod's description carry the risk warning.
- psx_mod_set_load_acceleration accepted 2..16. Host pacing cannot desync
the guest at all (every frame, CD deadline, interrupt and callback still
happens), so the ceiling was arbitrary. Accept 1..PSX_MOD_LOAD_ACCEL_MAX,
with 1 meaning authentic and 0 still meaning uncapped.
- New option key disabled_by: an option names a BOOLEAN sibling that
overrides it, so "tick Instant and the speed box stops mattering" needs
no second widget type. The parser rejects a dangling, self-referential
or non-boolean reference rather than leaving a control silently always
enabled, and the provider resolves the link against the live selection
so the launcher and the plugins can never disagree about whether a
control counts.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
SDL_main.h is a single-header implementation in SDL3. Include it only from the translation unit that owns main so MinGW emits one WinMain instead of one per SDL-using source.
Extract the useful diagnostic from PR #13 into an opt-in, title-agnostic boot
write-range trace with TCP-queryable context.
Co-authored-by: NyperYuhgard <93950153+NyperYuhgard@users.noreply.github.com>
This fix is due to games like Tekken 1, which contains multiple discs (multiple .bin files). The problem was that the current code caused the music to repeat several times without counting each second and never allowed the music to continue, both in menus and during gameplay, and also when we paused the game, this repetition continued and did not stop...
(I would appreciate it if you could review and analyze the code. My intention is to keep it updated and improve it over time.)
This is my current possible fix:
`cdda_playing` -> "Is the music already playing?" If the game sends a "Play" command, but the music is paused, we allow the command to pass normally so that the music starts.
`requested_track == 0` -> "Does the game want to play the same track?" When Tekken 1 enters "spam" mode, it sends the pure "Play" command (0x03), without specifying a new track (which in the engine code translates to `requested_track = 0`). If you request track 4, we will allow the command to pass. Since it asks for "0", we know it's just redundancy for a song that's already playing.
`iso_handle` -> "Is there a CD inserted?" This ensures the engine doesn't try to check for phantom tracks and won't crash if there's no .cue file loaded. `iso_track_count(iso_handle) > 1` -> "Does the CD have audio tracks?" The PlayStation game format dictates that Track 1 always contains the game data. If the CD has more than one track, it means it has audio tracks (CDDA).
The manifest schema already carries typed, validated, launcher-rendered,
persisted options ([[option]] boolean/choice/integer), and the launcher
provider already reads them. A trusted activation plugin could not: the
callback takes no arguments, so a plugin was only ever an on/off switch.
That forced a parameterised feature to be modelled as one feature per
value, and `constraint` only expresses ordered_integer WITHIN a feature, so
those pseudo-features could not even be made mutually exclusive. A game
wanting "Widescreen: 16:9 / 21:9" or "Interpolation: 90/120/144/165/240"
had no way to express it as one entry.
psx_mod_option_value(package, feature, option, out, out_size) closes the
gap against the value the player actually committed. It returns 0 with an
empty string when the plan is not committed or the ids do not resolve, so a
caller applies its own default rather than reading "" as a selection. Ids
are explicit because registration is by plugin id alone and the callback
carries no package/feature context.
Also in this commit, from the same investigation:
* Sustained overlay-autocompile failure is now LOUD. After 3 consecutive
failed runs the runtime prints once to stdout: what failed, the exit
code, that overlays are staying interpreted and frame times will be far
worse than the build is capable of, what to check, and the compiler's own
output tail. Previously the only trace was a `fails` counter reachable
over TCP, so a wholly-interpreted title presented as "why is this slow"
rather than as a message. Threshold is 3, not 1, because isolated
failures (a shard racing a capture rewrite, a transient lock) are
ordinary and self-heal. Measured cost of the silent case on Tomba!:
p50 frame period 105ms, vs 3.1ms once shards existed.
* The autocompile child's working directory is printed at startup beside
cache and captures. Every relative path in overlay_autocompile_cmd
resolves against it and it comes from game.toml's detected project root,
so a game.toml staged outside the real root silently repoints the entire
compile command with no other symptom.
* A build tree whose cache still carries recomp-ui's OFF for
RECOMP_UI_ENABLE_MODS now says so at configure time. 610234a's seed only
fires on a fresh cache, and a stale OFF is indistinguishable from a
deliberate one, so such trees kept producing Mods-less builds across
reconfigures - the same "reads as a stale build" failure one level up,
and invisible. The explicit-OFF contract is deliberate so this does not
override it; it makes the state audible.
Runtime ctest 16/16. Warning verified to fire on a tree configured with
-DRECOMP_UI_ENABLE_MODS=OFF and to stay silent on a fresh configure.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`bios_hle` (default on) is the player-facing "skip the BIOS and go
straight to the game" flag, and it did nothing under the bundled
OpenBIOS: choosing OpenBIOS sat the player in the boot animation while
the identical build on retail SCPH-1001 went straight to the game.
Root cause was ordering, not policy. The tier has two axes with
different per-image requirements:
* boot-skip needs only `shell_entry_phys`, works under pure LLE
(nothing is synthesized — the shell call just returns
immediately), so any image exporting it can skip
* kernel-call needs `deliver_event_ret`, the kernel's own
DeliverEvent `$ra`, or a delivered callback returns to
the wrong PC
main.cpp correctly refused the call axis on an image without
`deliver_event_ret` by assigning `bios_hle = false` — and then derived
`boot_skip` from that already-mutated flag. OpenBIOS omits
`deliver_event_ret` (B0 semantics unvalidated) but DOES export
`shell_entry_phys`, so an available skip was cancelled by an unrelated
refusal, and one flag meant two things depending on a BIOS detail no
player can see.
Both axes are now decided by one pure, dependency-free function,
`psx_bios_hle_plan()` (runtime/src/bios_hle_plan.c): the boot decision
reads the REQUESTED `bios_hle`, each axis is gated on only the anchor it
needs, and refusals are reported at startup instead of downgrading
silently. `psx_bios_hle_configure()` clamps `boot_skip` to
`shell_entry_phys != 0` as a backstop so the banner and `hle_dump`
cannot overstate what can fire. The main.cpp local is renamed
`bios_hle_requested` and is no longer written back from the plan — the
`session_reboot` path re-enters that block, so folding a refusal into
the request would have made a netplay rematch differ from first launch.
Also in this pass:
* A BIOS profile's `[runtime]` block was parsed into
`BiosConfig::runtime` and read by NOTHING, and bios/OpenBIOS.toml
carried an inert `bios_hle = false` there that read as the reason HLE
was off on OpenBIOS. It was not. `load_bios_config` now REJECTS
`[runtime]` in a BIOS profile: a profile states facts about an image,
never preferences.
* `psx_icache_fastpath_test` had been unbuildable ("redefinition of
`psx_advance_cycles`" — the test's counting stub vs the header's
`static inline`), which blocked every runtime test registered after
it. It now builds with `PSX_OVERLAY_DLL_BUILD=1`, the seam
psx_cycles.h already provides for a TU supplying its own advance.
Tests: new `bios_hle_plan_test` pins the matrix, including a 64-case
sweep asserting the boot decision is independent of
`deliver_event_ret` and the call decision independent of
`shell_entry_phys`. Runtime ctest 15/15, recompiler ctest 30/30.
Validated on Ape Escape (SCUS-94423) built against this framework with
both backends linked, headless, all four cases:
OpenBIOS default bios_boot=skip to game; route=2 fire at vec 0x30000
ra=0xBFC06EA8 (the continuation OpenBIOS.toml
documents); in-game on screen
retail default bios_boot=skip to game; route=2 at vec 0x30000
ra=0xBFC0702C; in-game on screen; differs only in
bios_backend=HLE (LLE fallback)
PSX_BIOS_HLE=0 bios_boot=real intro; ring empty (no hook)
KEEP_INTRO=1 bios_boot=real intro; ring empty
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
recomp-ui f6395d6 (upstream commit 39a6e4e, 'mods: make launcher integration
opt-in') gates the Mods view behind RECOMP_UI_ENABLE_MODS, which defaults OFF.
That is the right default for a cross-console launcher -- a console with no mod
system should not show an empty Mods tab -- but it is the wrong default here.
psxrecomp ships mod packages as a first-class documented feature
(docs/MOD_PACKAGES.md); Tomba! ships three catalogs and Ape Escape two. With
the option off, a title that already shipped a working Mods panel silently
loses it on its next rebuild: the panel is compiled in, the catalog is staged
beside the exe, and the view simply never appears. It reads as a stale build
rather than a missing flag, which is how it was found.
Opt in from the framework rather than in each game's CMakeLists, so every
title inherits it instead of six repos each needing the same line. Set before
including recomp_ui.cmake so its option() honours the value, and only when the
caller has not already decided, so -DRECOMP_UI_ENABLE_MODS=OFF still wins.
Verified on ApeEscapeRecomp: a clean configure with no extra flags now yields
RECOMP_UI_ENABLE_MODS:BOOL=ON and the compile definition on every launcher TU;
configuring with -DRECOMP_UI_ENABLE_MODS=OFF still produces none. runtime.cmake
is not in codegen_hash_sources.cmake, so the overlay cache tag is unaffected.
PSXRECOMP_BIOS_STEMS defaults to "OpenBIOS;SCPH1001", so every game link
required a SCPH1001 backend. That backend is compiled from generated C which is
a derivative of a copyrighted Sony BIOS, so it is gitignored and only exists
after a developer regenerates it from their own dump. A checkout that has only
the bundled MIT OpenBIOS -- the documented default, and what a fresh clone gets
-- configured fine and then failed at link with:
undefined reference to `SCPH1001_psx_bios_backend'
Hit while building Tomba 1, Tomba 2 and MMX6 to validate an unrelated branch;
all three needed -DPSXRECOMP_BIOS_STEMS=OpenBIOS as a workaround.
Filter the stem list to those that actually supply a backend, rather than
flipping the default. Flipping it would silently drop SCPH1001 for developers
who HAVE regenerated it; filtering keeps it fully supported when present and
simply absent when not.
Presence of the files is not a sufficient test. A generated/ tree produced
before the backend-descriptor mechanism existed has both <stem>_full.c and
<stem>_dispatch.c yet defines no descriptor -- exactly the local state that
produced the error above. The check therefore probes for the descriptor symbol
itself, in <stem>_dispatch.c (~1MB, where the emitter puts it) rather than the
multi-megabyte <stem>_full.c, so configure stays fast.
Also report what happened instead of leaving it implicit:
- STATUS line naming the linked backends
- STATUS line naming skipped stems with the regen command to fix them
- FATAL_ERROR, with the OpenBIOS regen command, if no backend resolves at all
(previously an empty registry would have surfaced as a confusing link error)
Verified: with default flags and a stale local SCPH1001 tree, Tomba 2 now
reports "BIOS backends skipped ... SCPH1001" / "BIOS backends linked: OpenBIOS",
links, and boots.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Comment-only. No compiled code changes -- the sole non-comment diff line moves
a trailing comment off the g_mmx6_hostside declaration into a block above it;
the declaration itself is byte-identical.
A survey of the mmx6-named widescreen symbols found the existing comments
misleading in a way that invites a dangerous cleanup, so the findings are
recorded in the source next to the code they describe.
1. "Compatibility entry points for already-generated MMX6 sources" (gpu.h) was
wrong. These are not MMX6 compat shims and are not safe to delete. They are
the widescreen-2D entry points the recompiler emits for ANY title with a
[widescreen.bg2d] block, and live generated code in several non-MMX6 repos
links them today:
cols/startcol/startx/stream_left/stream_right
-> CrashBash, MegaManX5, Tsumu (+ -release)
undercap
-> Ape, CrashBash, MMX4, MMX5, Tsumu, Vigilante8, THPS2
Each forwards to its psx_ws_bg2d_* twin, which is the real implementation.
Only the name is historical. Renaming is not runtime-only: the names come
from code_generator.cpp, which is in codegen_hash_sources.cmake, so it rolls
the overlay cache tag and forces regen + reshard of every title.
2. Host-side reveal (g_mmx6_hostside) is dead in every shipping build, which
the previous "kept inert pending removal" note understated. Nothing sets it
but the mmx6_reveal debug command, PSX_DEBUG_TOOLS is OFF for Release, and
no generated source anywhere references a host-side symbol. Noted that
removing it is the last step decoupling the generic psx_ws_bg2d_* API from
MMX6 -- mmx6_hostside_active() is currently embedded in the ternaries of
psx_ws_bg2d_cols/startcol/startx -- and listed the symbols that go with it.
3. BG buffer relocation is a parked FEATURE behind a load-bearing SYMBOL, a
distinction the old comment did not draw. With g_mmx6_reloc == 0 both hooks
return their argument unchanged, but MegaManX6Recomp/game.toml names the
bufbase/cap instruction sites, so the emitter writes calls into generated
code and psx_ws_mmx6_bg_bufbase is genuinely called by MMX6's generated C.
The supportable cleanup is to gut the bodies to identity and keep the
symbols, not to delete the functions.
Removal of (2) and (3) is deliberately deferred: it touches the renderer and
wants its own session with MMX6 revalidation.
Verified: gcc -fsyntax-only on gpu.c exits clean (an earlier draft embedded
"*/" inside a block comment and broke the parse -- caught before commit);
ctest 29/29 green.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
recompiler/CMakeLists.txt defined both `psxrecomp` (the user-facing CLI,
src/main_cli.cpp) and `PSXRecomp` (a legacy duplicate of psxrecomp-game, built
from the identical PSXRECOMP_GAME_SOURCES list). CMake treats those as distinct
targets, but Windows and macOS filesystems are case-insensitive, so both wrote
the same file and the last one linked won.
The CLI lost. After a clean build, psxrecomp.exe was the game recompiler,
answering `--config <game.toml>` instead of the documented
`build --disc ... --bios ... --output ...`. tools/build_cli.py packages that
binary into psxrecomp-cli-windows-x86_64.zip, and README's first instruction to
a new user is to download and run it, so the primary onboarding path handed
people a program matching no documentation. Invisible on Linux, which is why it
survived.
Remove the legacy target (psxrecomp-game already covers those sources) and add a
configure-time guard so it cannot recur: the guard compares OUTPUT_NAME
case-insensitively across a directory's targets and fails with an actionable
message. A rename alone would not have prevented recurrence.
The PSXRecomp.exe named in README's Release Package section is a different
artifact, the BIOS-only runtime named via OUTPUT_NAME in runtime/runtime.cmake,
and is unaffected.
Verified: clean build now yields psxrecomp.exe (791KB) printing the documented
`build --disc` interface; no case-colliding pair remains; guard confirmed to
fire by temporarily reintroducing a collision.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Matthew Stanley