Initial commit: retroDE_ps2 — first-of-its-kind PS2 GS FPGA core (DE25-Nano / Agilex 5)
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>
This commit is contained in:
@@ -0,0 +1,158 @@
|
||||
# PS2 Hardware Overview
|
||||
|
||||
This file is the quick architectural map for planning. The intent is to answer
|
||||
"what major machines exist inside the PS2, how do they talk, and what has to
|
||||
be present before software can do anything useful?"
|
||||
|
||||
## Big Picture
|
||||
|
||||
At a high level, the PS2 is not "CPU + GPU + RAM" in the simple console sense.
|
||||
It is closer to a small multiprocessor system with a graphics subsystem tightly
|
||||
coupled to DMA and vector processing:
|
||||
|
||||
- EE / R5900: main CPU.
|
||||
- COP0, COP1, and MMI behavior: system control, floating point, multimedia
|
||||
instructions.
|
||||
- VU0 and VU1: vector processors with local code/data memories.
|
||||
- VIF0 and VIF1: vector data upload / unpack / microprogram path.
|
||||
- DMAC: central movement engine for many peripherals.
|
||||
- GIF: packet formatter / path arbiter into the GS.
|
||||
- GS: fixed-function graphics processor with its own VRAM.
|
||||
- IPU: MPEG video decode block.
|
||||
- IOP: separate MIPS-based I/O CPU with its own RAM and peripherals.
|
||||
- SPU2: audio DSP / RAM / DMA complex.
|
||||
- SIF: EE<->IOP communication path.
|
||||
- CDVD, SIO2, DEV9, USB, FireWire, memory cards, controllers: IOP-side
|
||||
peripherals.
|
||||
- BIOS ROM: shared system firmware image visible to both EE and IOP.
|
||||
|
||||
The organizing lesson is that a PS2 bring-up is fundamentally a fabric problem
|
||||
as much as a CPU problem. Data movement and coprocessor interaction are central.
|
||||
|
||||
## Memory Map
|
||||
|
||||
The most useful condensed map from a core-planning standpoint is the one in
|
||||
`ps2tek`.
|
||||
|
||||
### EE virtual/physical view
|
||||
|
||||
- `0x00000000 -> 0x00000000`: 32 MiB main RAM.
|
||||
- `0x20000000 -> 0x00000000`: uncached mirror of main RAM.
|
||||
- `0x30100000 -> 0x00100000`: accelerated uncached RAM window.
|
||||
- `0x10000000`: EE I/O registers.
|
||||
- `0x11000000`: VU memories.
|
||||
- `0x12000000`: GS privileged registers.
|
||||
- `0x1C000000`: 2 MiB IOP RAM.
|
||||
- `0x1FC00000`: 4 MiB BIOS.
|
||||
- `0x70000000`: 16 KiB scratchpad RAM, virtual-only.
|
||||
|
||||
### IOP physical view
|
||||
|
||||
- `0x00000000`: 2 MiB IOP RAM.
|
||||
- `0x1D000000`: SIF registers.
|
||||
- `0x1F800000`: I/O register block.
|
||||
- `0x1F900000`: SPU2 registers.
|
||||
- `0x1FC00000`: shared BIOS ROM.
|
||||
|
||||
### Additional memories
|
||||
|
||||
- 4 MiB GS VRAM.
|
||||
- 2 MiB SPU2 work RAM.
|
||||
- 8 MiB memory card capacity per card.
|
||||
|
||||
## Important register clusters
|
||||
|
||||
These are the blocks that look most relevant for staged hardware bring-up:
|
||||
|
||||
- EE timers: `0x100000xx` through `0x100018xx`.
|
||||
- IPU registers/FIFOs: `0x10002000`, `0x10007000`, `0x10007010`.
|
||||
- GIF registers/FIFO: `0x10003000` block and `0x10006000`.
|
||||
- EE DMAC channels:
|
||||
- VIF0 ch0
|
||||
- VIF1 ch1
|
||||
- GIF ch2
|
||||
- IPU_FROM ch3
|
||||
- IPU_TO ch4
|
||||
- SIF0 ch5
|
||||
- SIF1 ch6
|
||||
- SIF2 ch7
|
||||
- SPR_FROM ch8
|
||||
- SPR_TO ch9
|
||||
- INTC: `0x1000F000` / `0x1000F010`.
|
||||
- SIF registers: `0x1000F200` block on EE, `0x1D000000` block on IOP.
|
||||
- GS privileged registers: `0x12000000` block, including `PMODE`,
|
||||
`DISPLAY1/2`, `DISPFB1/2`, `BGCOLOR`, `GS_CSR`, `GS_IMR`.
|
||||
- IOP DMA channels include CDVD, SPU2, DEV9, SIF0/1, and SIO2.
|
||||
|
||||
## Boot and Firmware Flow
|
||||
|
||||
The BIOS is not just a ROM blob we fetch instructions from. It also contains an
|
||||
IOP bootstrap path and module-loading logic that matters for system bring-up.
|
||||
|
||||
Key points from `ps2tek`:
|
||||
|
||||
- The EE starts from BIOS space.
|
||||
- The BIOS contains `IOPBOOT`, which is responsible for finding and parsing
|
||||
`IOPBTCONF`.
|
||||
- `IOPBTCONF` is the module list for IOP startup. It includes core IOP modules
|
||||
such as `SYSMEM`, `LOADCORE`, interrupt handling, DMA management, timer
|
||||
management, and more.
|
||||
- The first loaded IOP module is `SYSMEM`, which sets up IOP-side memory
|
||||
allocation.
|
||||
|
||||
What that means for planning:
|
||||
|
||||
- "BIOS fetches correctly" is only the first step.
|
||||
- A useful early bring-up target is likely "EE reaches BIOS code and the IOP
|
||||
bootstrap flow begins in a recognizable way."
|
||||
- If the eventual project uses a real dumped BIOS, boot behavior will stress
|
||||
more than just the EE core. It will quickly exercise memory mapping, DMA,
|
||||
SIF, and IOP startup assumptions.
|
||||
|
||||
## Graphics Path Summary
|
||||
|
||||
A simplified practical view of the graphics data path:
|
||||
|
||||
1. EE code prepares packets.
|
||||
2. DMAC moves packet data, often to GIF.
|
||||
3. GIF arbitrates PATHs and reformats command/data traffic.
|
||||
4. GS consumes packets, updates VRAM, and drives the PCRTC/display path.
|
||||
|
||||
The DobieStation "From Bits to Pixels" article is especially useful here: it
|
||||
frames the first visible output as a memory-map plus DMAC plus GIF plus GS
|
||||
problem, not merely a CPU problem.
|
||||
|
||||
## Audio / Peripheral Side Summary
|
||||
|
||||
The IOP side owns much of what makes the console feel complete:
|
||||
|
||||
- controller and memory card traffic via SIO2 and BIOS/IOP modules,
|
||||
- SPU2 audio and SPU2 DMA,
|
||||
- CD/DVD access,
|
||||
- DEV9 expansion functions such as HDD/network in supported setups,
|
||||
- USB / FireWire blocks.
|
||||
|
||||
This matters because a core can "boot code" long before it can convincingly
|
||||
behave like a PS2.
|
||||
|
||||
## Planning Implications
|
||||
|
||||
From an FPGA-port perspective, the PS2 naturally breaks into these bring-up
|
||||
layers:
|
||||
|
||||
1. Address map, RAM/ROM visibility, reset, and exception vectors.
|
||||
2. EE execution plus enough COP0 behavior for BIOS progress.
|
||||
3. DMAC, GIF, GS privileged register access, and some display proof-of-life.
|
||||
4. IOP boot path and SIF interaction.
|
||||
5. VIF/VU behavior sufficient for real software.
|
||||
6. SPU2, SIO2, CDVD, DEV9, and the broader "console completeness" layer.
|
||||
|
||||
That layering is a big reason this project feels closer to `ao486` than to
|
||||
`nes` or `gb`. The challenge is not one datapath; it is many cooperating
|
||||
subsystems with firmware-visible contracts.
|
||||
|
||||
## Source Pointers
|
||||
|
||||
- `ps2tek`: https://psi-rockin.github.io/ps2tek/index.html
|
||||
- DobieStation wiki, "Making a PS2 Emulator: From Bits to Pixels":
|
||||
https://github.com/PSI-Rockin/DobieStation/wiki/Making-a-PS2-Emulator%3A-From-Bits-to-Pixels
|
||||
Reference in New Issue
Block a user