-
Notifications
You must be signed in to change notification settings - Fork 0
FAQ
No. It is a static recompiler and compatibility runtime: offline tools translate a user-supplied PSP ELF/PRX into C, then a native host executable runs the generated code with runtime/HLE services. It is title-focused and does not claim general-purpose PSP emulation.
No. The public repository and Wiki exclude the game, firmware modules, decrypted retail inputs, proprietary assets, keys, generated retail-title output, and private traces. Use only files from your own lawful copy locally.
Not as a current promise. The implementation and build orchestration are focused on the HST target; PORTING.md describes the current limits of generality.
480x272 is the PSP guest framebuffer size. The current SDL path starts a resizable 960x544 host window, which is 2x-style presentation rather than native PSP window sizing. A user-selectable 480x272/1x host mode is not implemented yet; internal render scale, host-window size, and final filtering are separate concepts.
Windows 11 x64 is the first-class development and validation host. Linux and macOS are long-term portability goals, not current end-to-end support claims.
Generated C is a reviewable, portable boundary between PSP instruction translation and the native compiler/runtime. It also makes generated-source freshness and ABI agreement explicit. It is not a claim that C is the PSP's native execution model.
A runtime or reference implementation can agree with itself. Hardware probes provide an external behavioral authority for bounded questions. Transport qualification and evidence provenance are part of the result.
PPSSPP is useful for developing probes, comparing implementations, and validating the measurement chain. It is not substituted for a real PSP hardware acceptance result.
Yes, through the public replication and experiment workflow. Use source-owned probes, record model/firmware and transport facts, separate observation from inference, and submit only redacted/public-safe artifacts. Start with Hardware Research and the research runbook.
General findings and registries belong on recomp.jaycast.net, not as large duplicated articles in this Wiki. Concrete implementation changes remain in GitHub Issues and pull requests.
HLE coverage is an evidence-driven compatibility surface. An unknown or unregistered operation should stay visible until its behavior is implemented or deliberately classified; returning success merely to unblock a route would hide the gap.
They are not public-source inputs. Keeping them local lets the generic tooling, tests, and runtime remain reviewable without redistributing copyrighted game material.
It is an interior or alternate entry that re-enters an existing function with live state, rather than a normal callable function start. Treating every reached address as a fresh function can corrupt ownership and stack assumptions; see Static Recompiler.
It means a source tree, fixture, report, or Wiki page can be shared without private inputs, restricted game material, secrets, local identifiers, or unsupported legal/provenance claims. When uncertain, keep it private and ask for review.
Home ยท Current Status ยท Getting Started ยท Research site ยท Public repository
Public-source project manual. Users supply their own lawful inputs; no proprietary game content is distributed.
- ๐ Home
- ๐ Current Status
- ๐ Getting Started
โถ๏ธ Build and Run- ๐งญ Repository Tour
- ๐๏ธ Architecture
- ๐ Static Recompiler
- ๐งฉ Runtime and HLE
- ๐ผ๏ธ Graphics and Display
- ๐ Audio and Media
- ๐งช Verification and Testing
- ๐ฉบ Debugging
- ๐ฎ Hardware Research
- ๐ง Development Workflow
- ๐ค Contributing
- ๐ Publication and Provenance
- ๐ Research and Documentation
- โ FAQ
- ๐ Research Home
- ๐๏ธ Knowledge Base
- ๐ Evidence Standard
- ๐ฌ Hardware Replication