Building ROM Images

A final set of tools, headers, and libraries are available to pack your database and code into final ROM images for the Nintendo 64. The Nintendo 64 development environment heavily leverages the C compiler and preprocessor tools to process symbolic data into binary objects. A ROM packing tool, makerom(1P) packs these objects into a single monolithic ROM image according to a specification of where these objects go.

C Compiler Suite
Currently, the Nintendo 64 development environment has only been verified with the IRIX 5.3 MIPS C-compiler suite. The interfaces provided do not rely on proprietary features of this compiler; however backend tools such as makerom may rely on specifics of the MIPS symbol table format. It is required that all modules be compiled or assembled with the -non_shared and -G 0 compilation flags; neither position independent code or a global data area is supported. Since the MIPS R4300 supports the MIPS II instruction set, the -mips2 flag is also recommended, as are optimization flags (-O and -O3).

ROM Image Packer
The ROM image packer (makerom) takes as input relocatable objects created by the compiler, and performs the final relocations of code symbols. To perform these relocations, it invokes a next generation link editor that allows objects to be linked at arbitrary addresses specified by the developer. After these relocations, makerom extracts the code and initialized data portions of the resulting binary and packs them onto a ROM image. The makerom tool can also copy raw data files to the ROM as desired.

Note: When building a ROM image for the console (as opposed to the development system), be sure to:

- link with libultra.a and not libultra_d.a

- remove all calls to printf and its variations from your application

- remove any functions specific to the development board (such as command line parsing or logging) from your application

Headers and Libraries
Although the Nintendo 64 API includes interfaces for a wide variety of areas, the interfaces are made available by including a single header file, /usr/include/ultra64.h, and by linking with a single library, /usr/lib/libultra.a (or /usr/lib/libultra_d.a).The library routines are broken into their finest level of granularity, so applications “pay as they go," only including routines they actually use.

Note: There are two versions of the Nintendo 64 library: a debug version (/usr/lib/libultra_d.a) and a non-debug version (/usr/lib/libultra.a). The debug version of the library provides additional run time checks at the expense of some space on the ROM and DRAM, as well as some performance. The kinds of checks performed include argument checking (especially hard to find alignment problems), improper use of interfaces, audio resource problems, etc. It is recommended that the debug library be used in initial development, and then replaced by the non-debug library later in the development cycle.

In case of error, the game loading program gload(1P) will interpret and display the errors on the host.

Copyright © 1999 Nintendo of America Inc. All Rights Reserved Nintendo and N64 are registered trademarks of Nintendo Last Updated January, 1999