retroDE_ps2/references/hardware_overview.md

# 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