BIOS, boot & software interrupts

Before a cartridge game can run, the console needs a starting machine state and a route into the game’s program. The original GBA contains a small BIOS ROM that participates in startup and provides services games can call later. GBAx must reproduce those observable behaviours as part of the console model.

The BIOS is distinct from the cartridge ROM and from a normal game save. Changing a BIOS setting can affect boot and service behaviour, but it does not turn one game revision into another or replace missing save data.

What the BIOS contributes

The GBA BIOS occupies a 16 KiB region at the low end of the address map. Its responsibilities include startup behaviour and services that games can invoke through software interrupts. These services cover operations such as memory copying, arithmetic helpers and decompression.

A game can therefore rely on code outside its own cartridge image. If it asks for a BIOS service, the emulator needs to provide the expected result and relevant side effects. Simply loading the cartridge bytes and ignoring that service call would leave part of the game’s execution undefined.

Real BIOS execution and replacement behaviour

The reviewed core supports loading an external BIOS and also contains a built-in replacement implementation. These are two ways of supplying the environment expected by the game. They should not be described as identical internal execution paths.

With an external BIOS loaded, the core can execute its instructions through the ARM machinery. With replacement service handling, the emulator implements the operation in its own code. The GBA source contains GBASwi16 and GBASwi32 service entry points and supporting routines. The selected configuration determines the relevant path.

Replacement behaviour can be efficient and convenient, but compatibility depends on more than returning a plausible output buffer. Register effects, memory access behaviour and timing can matter to software. That is why BIOS configuration belongs in a reproducible bug report.

Follow a software interrupt

A game uses a software-interrupt instruction to request a service. The instruction is decoded by the CPU implementation, which calls the configured service/exception handling path. That path identifies the operation and either performs the required handling or transfers execution through the appropriate BIOS machinery.

1. Game requestThe program supplies arguments and executes a software interrupt.
2. DispatchThe core identifies the requested service and selected BIOS path.
3. OperationMemory, registers and emulated time change as required.
4. ReturnThe game resumes and observes the result.

For a decompression service, for example, the game supplies a source containing encoded data and a destination address. The operation expands that data into the destination using the expected format and access rules. The destination may be working memory or a graphics-related region with particular write constraints.

A memory-copy service illustrates the same point on a smaller scale. Transfer width, alignment, fill-versus-copy behaviour and the amount of data moved all affect the result. Implementing “copy some bytes” without those rules can produce corrupted data even though the service name sounds straightforward.

Skipping the boot sequence still requires a valid state

A frontend can offer a way to skip the visible startup sequence. Doing that does not mean starting the cartridge with every register and device left at zero. The game expects a coherent handoff state: CPU mode, stack/register values and hardware status must match what the chosen boot path promises.

The reviewed GBA code includes an explicit GBASkipBIOS path. It adjusts state and the instruction stream rather than treating startup as a cosmetic video that can simply be removed. When diagnosing a boot-only failure, compare the relevant settings and keep the rest of the setup unchanged.

BIOS memory has special access rules

The BIOS address region does not behave like ordinary RAM that any instruction can freely read and write. The GBA memory implementation tracks special BIOS-read behaviour and the current execution context. This is another reason a flat array of memory cannot fully represent the machine.

Games that exercise unusual access patterns can expose differences between a replacement implementation and another BIOS configuration. A successful title screen is useful evidence, but it is not a test of every service and protected-read case.

BIOS configuration and save states

The state format in this core records a BIOS checksum alongside other identifying information. During state loading, the implementation checks relevant compatibility conditions and can warn about a BIOS difference. A snapshot taken while executing BIOS code is particularly sensitive to restoring into a different BIOS environment.

If you change the BIOS configuration or emulator version, keep a normal in-game save and a copy of the previous setup. Test a fresh launch before relying on an old state. This makes it easier to distinguish a startup problem from a state-compatibility problem.

Practical use in GBAx

The desktop release packages do not supply Nintendo BIOS files. The built-in implementation allows the core to provide BIOS behaviour without adding one to the package. If you configure an external file, use the emulator settings appropriate to your installed build and record that choice when comparing results.

For the instruction path involved in a software interrupt, read CPU: ARM & Thumb execution. For the memory rules involved in BIOS services and protected reads, continue with Memory & the system bus.