Overlays
In computer science, overlaying is the process transferring a block of code into ram, which allows a program to be larger than the system's available ram. As such, overlays are a block of code can be loaded dynamically into memory.
Contents
Overlay Tables
Format
Overlay files have a single header defining their properties, which is pointed to by the last word of the file. The overlay structure is similar to the elf file structure, in the sense that there are the following parts:
| Text block | mips r4000 machine code | |
|---|---|---|
| Data block | Read/Write data (Initialized variables) |
This can also include inline model data, as seen in element arrows and Ganon to name a few. |
| Rodata block | Read-Only Data (Constant variables) |
Usually contains float literals, jump tables, and on the debug versions text used with the n64 debugging print function (0x80002130). |
| BSS block | Uninitialized Data | Uninitialized static and global data is initialized to zero at runtime and is kept within this section. Allocated immediately after the overlay's data |
| Relocation block | Remaps virtual ram to ram |
Locating the header
The last word in an overlay file contains a seek up value that points to the header for the overlay, which in turn points to the start of these blocks.
In ovl_En_Test (0002, Stalfos) for example, the last word in the overlay file is 0x00000640, the file length is 0x58B0 bytes, and the file end in rom is at address 0xC33CD0. Therefore the header is located at...
0x58B0 0xC33CD0 -0x0640 -0x000640 =0x5270 =0xC33690
...within the actor file and rom respectively.
Block Table
Overlays contain a table that map out the location of all 5 blocks within the file. At offset 0x5270 within ovl_En_Test, you'll find the following 5 words which correspond to the overlay's five blocks.
| Text block | 00004EC0 | ( .text) Size in bytes of the text block. Block located at the start of the file. |
|---|---|---|
| Data block | 000001F0 | (.data) Size in bytes of read/write data block following the text block. |
| Rodata block | 000001C0 | (.rodata) Size in bytes of the read-only block following the data block. |
| BSS block | 00000000 | Size in bytes of the BSS block. It's common for actors to not have a BSS block defined |
| Relocation block | 00000187 | Count of one-word long entries of relocation data. Relocation block immediately follows this table. |
Relocation Entry Format
Relocation entries are one word (4 bytes) each and are composed of the following:
- Section ID
- Relocation type
- Offset (section relative)
STOOOOOO
int SectionId; // & C000 0000 int RelocationType; // & 3F00 0000 int Offset; // & 00FF FFFF
S = Section ID
1 = .text 2 = .data 3 = .rodata 4 = .bss
T = MIPS ABI Relocation Type
| Name | Value | Description |
|---|---|---|
| R_MIPS_32 | 2 | 32 bit pointer |
| R_MIPS_26 | 4 | jump target |
| R_MIPS_HI16 | 5 | lui/addiu pair high 16 bits |
| R_MIPS_LO16 | 6 | lui/addiu pair low 16 bits |
There are more relocation types defined by the standard, but these are the only ones Nintendo seems to actualize.
R_MIPS_HI16 and R_MIPS_LO16 are paired by the lui's target register. R_MIPS_HI16 must always come before a R_MIPS_LO16, and it's valid for multiple R_MIPS_LO16s to follow a single R_MIPS-HI16. Lastly, lui/ori pairs (used by more modern compilers like GCC) are NOT properly supported.
O = Offset - relative to start of section s
Example implementation on 47-50
Arithmetic to acquire above values
The example is 0x44001210, and "w" is the relocation word.
w >> 30 = section: 1 (w >> 24) & 0x3F = type: 4 w & 0x00FFFFFF = address: 0x1210 >> is the symbol for a right bitshift operation & in this context works on the bits instead of the truth values the operands produce (in both instances)
Custom Actors
ZZT32 decided to get off his ass one day and write nOVL, a tool which converts MIPS elf binaries to Zelda 64 overlays. Few actors have been (re)written using mips-gcc + nOVL, but there are a few:
- En_Anim [1] - An actor written to load any animation.
- En_AnimVar [2] - A fork of the above actor, uses variables.
- en_vase [3] - The simplest actor in OoT, re-written in C to test nOVL and to document functions.
- En_Bird [4] - The simplest animated actor in OoT, re-written for the same reason as En_Vase.
zovldis is the opposite of nOVL - it takes an overlay and disassembles it to an assembly file, which, combined with a proper makefile, produces an identical actor as the one which was disassembled. This makes hacking existing actors much more convenient. An example of actor modification using this approach is seen here (video)
nOvl Windows executable (i686)
When compiling binaries for use as an overlay, you must add the switch -G 0 to prevent it from putting symbols in the small data section, as $gp relative relocations are obviously unimplemented. When linking a binary into an ELF file that is to be converted to an overlay, you must remember to retain all the relocation information with the flag --emit-relocs.