There's a 4 MB ROM chip fitted on the motherboard, this stores a great amount of code used to load a shell menu (that the users can interact with) but it also provides system calls to simplify I/O access (which games rely on).
Splash animation after turning on the console.
PS2 logo showing after a valid PS2 game is inserted.
Upon receiving power, both the MIPS R5900 and the IOP will start at address 0xBFC00000 (that's the signature reset vector for all MIPS CPUs). To handle the expected conflicts, however, the respective code stored in that address (pointing to the BIOS ROM) will make each CPU branch at a different location based on its identifier.
In the case of the R5900, the CPU will follow these steps :
- Initialise the hardware.
- Load the Kernel from ROM into RAM. Once loaded, the Kernel will provide a layer of abstraction to applications (mostly games) to interact with the hardware. Additionally, it also exposes a multi-threading API (cooperative and priority-based).
- The Kernel loads
EELOAD, a kernel module which, in turn, bootstrapsOSDSYS. The latter is the program that displays the splash animation and the shell menu.
On the other side, the IOP will be initialising part of its hardware and then load multiple modules, these enable the IOP to access the hardware of this console. Once finished, the IOP will be put in a 'waiting for command' state.
It's worth pointing out that the use of modules allows Sony to release new hardware revisions of the PS2 without changing the IOP (until they did), thereby lowering some production costs in the process.
Interactive shell
The functionality of the PS2 shell is pretty much in pace with the other 6th-generation consoles.
Initial menu. Appears when there's no disc inserted.
Memory Card browser.
Saves browser. It shows up after selecting a memory card.
Save editor, displayed after selecting a save.
System Configuration.
The shell is composed of multiple user interfaces for managing typical operations, like manipulating the save data stored in the memory card or altering the clock. It also provides some advanced options, like changing the current video mode.
Updatability
The BIOS is indeed stored within read-only memory, but that didn't stop Sony from amending it after leaving the factory. You see, behind the scenes, the BIOS left two doors open for future alterations:
- Applications (games and
OSDSYS) can monkey patch the kernel routines at runtime . Both the official SDK and the unofficial 'ps2sdk' made extensive use of this, as Sony's engineers subsequently discovered their Kernel to be riddled with bugs (pun intended). EELOADwill look for an updatedOSDSYSbinary stored in the Memory Card and/or the HDD . Sony relied on this to add a DVD movie player and HDD support, as none of these drivers were bundled in the earlier revisions of this console.- These updates were distributed in installation discs that came with the console or the HDD kit (part of the Final Fantasy XI box set).
- Unlike the Kernel, which has to be backwards compatible with old SDKs, follow-up revisions of the console shipped previous updates in the BIOS ROM.
- To control distribution, binaries must be signed with Data Encryption Standard (DES) , a symmetric encryption system, using keys only known by Sony (in theory). Additionally, the binaries must be stored in a storage device with MagicGate support.
In any case, Sony eventually removed the second method in late PS2 models (with a BIOS version 2.30). I presume Sony wasn't planning any more updates and this just added up to the attack surface.