Microcode Overlays; Memory System Implications; Entirely Up To You - Nintendo Ultra64 Programmer's Manual

Revision 1.0

Microcode Overlays

Microcode Overlays
One of the challenges of RSP programming is working within the limited
instruction memory. IMEM is an explicitly managed resource; you are free
to load new code as you see fit.
swap
RSP microcode loading can be divided into two situations: a , initiated
by the host CPU, which loads the entire IMEM while the RSP is halted, and
overlay
an , which loads part of IMEM and is triggered by the currently
executing RSP program. The latter case is the most interesting and is the
subject of this section, covering related architectural issues and explaining
one scheme for microcode overlays in detail.

Memory System Implications

The Rambus memory system is most efficient at large block transfers, so
microcode loading can approach peak memory transfer speeds.
Like all DMA transfers, the source and destination must be 64-bit aligned;
some care must be taken planning microcode overlays to meet this
restriction. The assembler provides several directives to guarantee code
alignment.
Since IMEM is single-ported memory, only one control unit can access it at
a time; if microcode is loaded while a program is currently executing, IMEM
accesses are shared between the DMA engine and the RSP control unit
(which is fetching instructions). This means that dynamic microcode
overlays can only approach 50% of peak DMA transfer rate.

Entirely Up to You

The decision to overlay microcode and the labor to perform the overlay must
be embedded in the RSP program. Overlay techniques involve the RSP
development tools, the RSP software, and possibly even the display list or
other data that the RSP program is designed to interpret.
Choosing when to overlay microcode should be done carefully; although
such DMA transfers are relatively efficient, they are not free.
135