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