The Flame GPU — Initial Design Part 3: Initializing the GPU

Now that we have a basic design for the Flame GPU and display mode 0, we need to write some assembly code to initialize the virtual GPU. We will start by adding a GPU initialization routine called flame_Init to the startup code we wrote for the boot firmware for the Ember Fantasy Console.

This new function doesn’t take any parameters; it just sets various memory-mapped hardware registers in the GPU to default settings to enable Mode 0, which is a simple tiled display mode, using a single playfield tilemap with a one-byte tile index at each memory location, a single tilesheet, and a two-color palette. This mode is ideal for implementing a text mode for testing and simple debugging of the Ember virtual console. Using this mode, we can implement a basic monitor application, or a command-line tool, similar to WozMon, or any other early console terminal on a Commodore 64 or other early personal computer.

flame_Init

We first load the r9 register with a pointer to the starting address of the memory-mapped GPU control registers. In a C or C++ application, this is the equivalent of a pointer to a struct. We will then use this pointer, adding various offsets, when we want to access the values in the struct. Check out the figure below (and this post) for details on the GPU Control Registers.

Next, we push the lr, or link register, to the stack. This is a common operation for any Ember function that will call other functions, as we will need to set it back to the return address of the calling function when we are done.

Before we start initializing the GPU hardware, we must ensure it is fully powered up and ready. At this point in the system's initialization, we can assume that power has been recently applied, so the chips on the board may still be in a reset state. We need to wait here in a loop until the GPU reports that it is ready, as indicated by the GPU_Status register.

Once the GPU is ready, we will call a series of functions which will perform the initialization, starting with __flame_DisableDisplay. Since we have just booted the machine, the GPU display output should already be disabled. However, it is best to confirm this, as changing some hardware registers below while the display is active could cause a system crash.

Next, we call __flame_SetMode, passing zero as the mode parameter for default Mode 0, then call __flame_SetDisplay to set the display resolution to a valid default such as 1024x768. Ultimately, an application can set it to whatever it needs, but the system can set a standard default that it expects any monitor to be able to handle. Finally, we call __flame_EnableDisplay to begin drawing frames, then return using the ret instruction, which will pop the link register off the stack and jump back to the system initialization routine.

At this point, the GPU will begin drawing frames using the data in the Playfield 0 tilemap in VRAM, which we have set to 0s, resulting in a solid color background on a blank display. The GPU is now ready to display a splash screen, render text, or whatever is needed.

SysCall and Parameter Passing

A quick note on parameter passing. As part of the Ember ABI (Application Binary Interface), there are three recommended calling conventions: StdCall, TrapCall, and SysCall. StdCall is the primary user-facing standard used for application libraries and games. TrapCall is used when calling TRAP system calls from user mode. Lastly, SysCall is a loosely defined standard used internally by system code and libraries to facilitate faster, yet more modular code for system drivers and handlers. We will cover the first two in more detail in the future, but for the GPU driver, we are using the SysCall standard.

Continue reading the entire article here...