thejayman77
ec82764bef
RTL (GS rasterizer, EE core stub, platform bridge, LPDDR4B path), sim regression (272 TBs), docs, and tooling. Copyrighted PS2 content (BIOS, game code, GS dumps, and all dump-derived textures/traces) is excluded via .gitignore and stays local. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
85 lines
3.9 KiB
Markdown
85 lines
3.9 KiB
Markdown
# Architecture Studies and Community Signal
|
|
|
|
Context sources that complement Codex's register-level material. These are for
|
|
orientation and feasibility reasoning rather than implementation detail.
|
|
|
|
## High-level architecture
|
|
|
|
### Rodrigo Copetti — "PlayStation 2 Architecture: A Practical Analysis"
|
|
|
|
- URL: https://www.copetti.org/writings/consoles/playstation-2/
|
|
- One of the clearest pedagogical writeups of the PS2 as a system. Covers the
|
|
EE, VU complex, GS, IOP, and data paths with diagrams.
|
|
- Good onboarding reading for anyone joining the project cold. Not a spec.
|
|
|
|
### psdevwiki — PS2 section
|
|
|
|
- URL: https://www.psdevwiki.com/ps2/
|
|
- Community-maintained counterpart to `ps2tek`. Strong on IOP modules, SPU2,
|
|
peripheral protocols, and regional/hardware revision differences.
|
|
- Useful cross-check: when `ps2tek` and `psdevwiki` agree, treat as settled.
|
|
When they disagree, flag for verification against Sony manuals or emulator
|
|
behavior.
|
|
|
|
### Wikipedia — PS2 technical specifications / Emotion Engine
|
|
|
|
- URLs:
|
|
- https://en.wikipedia.org/wiki/PlayStation_2_technical_specifications
|
|
- https://en.wikipedia.org/wiki/Emotion_Engine
|
|
- Orientation only. Not suitable as an implementation source.
|
|
|
|
## Academic / feasibility
|
|
|
|
### VPU Thesis — "A Study on the Feasibility of ... VU [on FPGA]"
|
|
|
|
- URL: https://gamehacking.org/faqs/VPUThesis.pdf
|
|
- Academic study specifically looking at implementing the PS2 Vector Unit on
|
|
FPGA. Directly relevant to Codex workstream 4 (VU/VIF).
|
|
- Worth reading carefully before any VU design decisions — likely surfaces
|
|
pitfalls that would otherwise be discovered the hard way in simulation.
|
|
|
|
## Community consensus (why nobody has done this)
|
|
|
|
These threads are not technical references, but they capture the current
|
|
community baseline of what has been tried, what was abandoned, and why. Useful
|
|
for setting expectations with stakeholders.
|
|
|
|
- MiSTer Forum — "Advanced cores for MiSTer future FPGA hardware":
|
|
https://misterfpga.org/viewtopic.php?t=4884
|
|
- MiSTer Forum — "What Do You Think Will Happen Once MiSTer Reaches Its Limits?":
|
|
https://misterfpga.org/viewtopic.php?t=2512
|
|
- Time Extension — MiSTer Pi and next-gen FPGA gaming:
|
|
https://www.timeextension.com/news/2025/03/the-next-generation-of-fpga-gaming-could-be-just-around-the-corner-thanks-to-mister-pi
|
|
|
|
Distilled consensus (as of 2026-04):
|
|
|
|
- No PS2 FPGA core exists, anywhere, open or closed.
|
|
- Mainstream view is that PS2 exceeds MiSTer-class FPGA fabric (DE10-Nano
|
|
Cyclone V): the EE+VU+GS combination is the wall, and Dreamcast is already
|
|
considered near the ceiling.
|
|
- The only publicly-discussed PS2-via-FPGA effort has been a *hybrid*: a PCIe
|
|
FPGA card offloading specific hot blocks (128-bit math, possibly GS-adjacent
|
|
work) to a host CPU running an emulator. Not a self-contained core.
|
|
- Cost estimate for an FPGA that could plausibly fit full PS2 at useful
|
|
timing: "$1000+ for the chip alone" in forum discussions.
|
|
|
|
## Implication for retroDE_ps2
|
|
|
|
The feasibility picture is not an argument against the project — it is a
|
|
framing argument for the plan. Realistic posture options:
|
|
|
|
1. **Hybrid architecture** (host CPU + FPGA co-processing). Matches the only
|
|
known active PS2-via-FPGA effort. Changes the retroDE shell contract.
|
|
2. **Subset / staged core** (e.g. EE + IOP + minimal GS, software-rendered
|
|
framebuffer first). Closer to homebrew/demo compatibility than full-title
|
|
compatibility. Lets bring-up progress without waiting for the full GIF/GS
|
|
problem.
|
|
3. **Future-hardware target**. Design against a more capable FPGA than the
|
|
current retroDE platform. Decouples the project from today's fabric
|
|
constraints at the cost of harder validation.
|
|
4. **Full native on current hardware**. Widely considered infeasible; would
|
|
require pushing past what any open console-FPGA project has achieved.
|
|
|
|
Worth settling which of these retroDE_ps2 is aiming at before Phase 0 locks
|
|
memory/firmware/host decisions.
|