Creates a ROM Game Pak image and associated ELF object files
makerom [-D name[=def]] [-I dir] [-U name] [-d] [-m] [-o]
[-b bootstrap filename] [-h header filename]
[-s romsize] [-f filldata]
[-p pif2 bootstrap filename] [-r romfile] specfile
makerom creates a ROM image suitable for downloading into the Game Pak ROM by the gload tool. makerom takes as input the specification file (specfile) that describes the organization of object and raw data files into segments. Then makerom invokes a link editor to resolve all undefined references, perform relocations, and create ELF object files for the Nintendo 64 debugger, gvd.
The makerom tool forcefully loads the first 8K bytes with the default bootstrap, pif bootstrap, and header files, unless you override these built-in defaults with command line options.
Command line options recognized by makerom are the following.
The makerom tool searches in three places for the bootstrap, pif bootstrap, and ROM header files in this order: First, $(ROOT)/<filename>, next $(WORKAREA)/<filename>, and last /<filename>. The ROOT and WORKAREA shell environment variables are used internally by SGI machine. The makerom tool's use of these variables allow our internal developers to use sw modules created within their personal development source directories, even if the same modules are installed on the development system upon which they are running their new code. If these variables are not set, you must supply the full pathname for these files to overwrite the existing default structure in makerom.
The spec file is preprocessed with the C language preprocessor (cpp) so that header files may be used for consistency with source and #defines may be used for clarity. Following describes the syntax of the specification file.
<specFile> :<segmentList> <waveList>
<segmentList> :<segment>
|<segmentList> <segment>
<segment> :beginseg <segStmtList> endseg
<segStmtList> :<segStatement>
|<segStmtList> <segStatement>
<segStatement> :name <segmentName>
|address <constant>
|after <segmentName>
|after max[<segmentName>,<segmentName>]
|after min[<segmentName>,<segmentName>]
|include <filename>
|maxsize <constant>
|align <constant>
|flags <flagList>
|number <constant>
|entry <symbol>
|stack <stackValue>
<flagList> :<flag>
|<flagList> <flag>
<flag> :BOOT
|OBJECT
|RAW
<stackValue> :<constant>
|<symbol>
|<symbol> + <constant>
<waveList> :<wave>
|<waveList> <wave>
<wave> :beginwave <waveStmtList> endwave
<waveStmtList> :<waveStatement>
|<waveStmtList> <waveStatement>
<waveStatement> :name <waveName>
|include <segmentName>
The "name" statement when used in the segment definition provides makerom with a string that it associates with the segment. It uses this for two reasons: to associate the segment with "waves" described below and to create some predefined symbols that may be referenced by code segments. These symbols should be declared as an "extern" to avoid their interpretation as gp-relative data. The symbols, and their meaning are as follow.
The "flags" statement provides some specific information about the segment. Segments flagged as "object" are composed of nonshared ELF relocatables. The type "raw" consists of uninterpreted data. The segment flagged as the "boot" segment is of special significance. It must be the first segment in the specification file, and it is linked at a fixed address. The "entry" statement gives the symbol that will be jumped to immediately after the rom image is loaded by gload. The "stack" segment specifies the beginning stack address of the boot code. It may either be a constant virtual address, or optionally, a program segment symbol name plus an offset. The later form is often useful since stacks grow backwards (towards smaller addresses) as procedures are invoked.
The "address", "number", and "after" statements are ways of indicating the beginning virtual address of an OBJECT segment. The "address" statements are primarily intended for segments that will be executed by the CPU, whereas segments numbered by the "number" segment are primarily intended to be accessed by the RSP. The "after" keyword can place a segment directly after the address range of another segment; this can be useful for preventing fragments in the address space while easily accommodating changes in segment sizes.
Each of one or more "include" statements of a segment definition specifies files that comprise the segment. If the segment has been flagged with "object", the specified file should be a nonshared ELF relocatable. Any types of files can be specified for "raw".
The "maxsize" statement can be used to specify the maximum size of a segment in bytes.
The "align" statement can be used to align a segment to a given number of bytes. By default, segments are aligned to 16 byte (128 bits) boundaries.
It is necessary to define multiple "waves" statements for specification files. Each wave definition results in a different ELF object file being created. Multiple waves may be used as desired to controll totally different scenes or perhaps appropriate when different address spaces are necessary due to the memory layouts.
The "name" statement of a wave definition will be used as the file name of the resulting ELF object file that corresponds to the wave. The defined segment specified by "include"' statement in the wave definition is included in the wave. The inclusion of the a segment into a wave makes its symbols available to all other segments of the wave.
The following spec file describes an application with two segments: a boot program segment and a static data segment. A single ELF object file named "rotate" is created.
beginseg
name "program"
flags BOOT OBJECT
entry mainproc
stack mainThreadStack + 0x1000
include "rotate.o"
endseg
beginseg
name "static"
flags OBJECT
number 1
include "square.o"
endseg
beginwave
name "rotate"
include "program"
include "static"
endwave
1999/01/21 Removed -C option, and added -B 0 option
1999/04/30 Changed Format