11 System Initialization

Game developers do not generally need to understand all the details of initialization. However, this may be of interest to system developers.

Here is a rough outline of the steps taken to initialize the FreeWPC environment:

• On real hardware, the processor's RESET handler is called. On WPC, the reset handler is written in assembly language. It performs a ROM checksum test and a RAM test.
• The program's main function is called (on real hardware, this is called from the RESET handler; in simulation, this is called by the OS like any other executable). main is a platform-dependent function. It can be thought of as the continuation of low-level initialization, except written in C.
• main calls into freewpc_init, where the common initialization begins. This is defined in kernel/init.c.
• All of the hardware-related subsystems are initialized.
• The task scheduler is initialized. This transforms the single thread of execution into a legitimate task.
• Interrupts are enabled. Hardware systems that depend on interrupts are now fully functional. Also, the system clock begins to tick, which allows tasks to sleep and therefore multitasking is fully supported.
• Software subsystems are initialized. The init event is thrown here, so any new subsystems added just need to catch this event to initialize themselves. It is important that modules do not interact with each other during this phase, because the order of init calls is not guaranteed.
• Periodic functions are enabled.
• The system powerup display effect is started.
• The init_ok event is thrown to allow modules to perform a final initialization, which may require interaction with each other. Modules can return FALSE if a factory reset is required. In that case, the system will reboot after performing the factory reset.
• The init_complete event is thrown, to signal that all modules are ready.
• The main task exits, and initialization is complete.