A system used to split the cache memory into groups and place the data currently at a specific address in main memory into the "associated" position in the split-out area of the cache. If the cache is split in two, the system is called "2-way set associative." If the cache is split into a number of areas equal to the number of blocks in the data area, the system is called "full associative." By using a 2-way set associative system, you can change the contents of one cache while keeping the contents of the other cache intact.

A data format that requires data to be aligned to 64-bit boundries in memory (such as 0x00000040, 0x00000080, and so on).

The register that specifies the page position of each bank of RDRAM. The banks of RDRAM are separated into four banks of one megabyte each. When using the framebuffer and the Z-Buffer, you use the active page register to store the buffers in separate memory banks. You should do this for faster execution speed.

Usually called TLB (translation lookaside buffer), this buffer holds the address conversion table containing the virtual to physical address conversion information. You can use it to convert from the virtual to physical addresses at a high rate of speed.

The 8-bit value used for expanding the virtual address when you provide the virtual addressing through the TLB (translation lookaside buffer).

The alignment shows the relationship between the information stored in memory and the memory boundary. The N64 system has a rule that says you must align the memory area to the 16-byte boundary so that it becomes a multiple of a cache line.

Application Programming Interface. The programming interface composed of functions, commands, and tools that the operating system supplies for the application program.

The width-to-height ratio of a television screen.

The mode you can use to avoid the span buffer coherence problem. But this mode seriously reduces the fill-rate.

Block Started by Symbol. The uninitialized data section of a segment. Before using the Bss section, you must clear it to 0.

A sorting method that divides numeric values, which you want to sort, into buckets and then does all sorting in the buckets.

The temporary memory area used to adjust between different system transfer rates when data is transferred from one place to another.

A control program used for controlling the peripheral equipment connected to the computer.

The interface that has common I0 functions (protecting, blocking, and buffering) for various devices. You can operate it without knowing the details about the configuration of device.

The N64 high-priority thread used for device control. After registering the event, event message queue, and message, the device manager controls the execution of I0 operations sequentially from the input command queue.

The buffer that stores the RDP display list.

A readable and writeable register used to gain access to the highest bit of the built-in TLB. It stores the address of the information that caused an exception if a TLB exception occurs.

A readable and writeable register used to gain access to the lowest bit of the built-in TLB. The entry Lo registers hold both the even virtual pages (Lo-0) and the odd virtual pages (Lo-1).

The exception program counter. It holds the virtual address value of the command that directly caused the exception or the virtual address value of the last branch or the jump command.

The exception handler built into the N64 operating system decodes interrupts and other exceptions and maps them to system events. If the system event is one that may be handled by the game itself, a message is sent to an associated event mailbox and the game application is notified. In this way, the game designer can provide an interrupt handler to deal with the exception as required by the game requirements.

Once the cause of an interrupt (or other exception) has been determined, the N64 operating system maps it to one of the following 14 events defined for the N64 system:

• SW1 - System software interrupt 1 asserted
• SW2 - System software interrupt 2 asserted
• CART - Peripherial has generated an interrupt
• COUNTER - Internal counter reached terminal count
• SP - RCP (reality co-processor) SP (signal processor) interrupt; Task Done/Task Yield
• SI - RCP SI (serial interface) interrupt; controller input available
• AI - RCP AI (audio interface) interrupt; audio buffer swap
• VI - RCP VI (video interface) interrupt; vertical retrace
• PI - RCP PI (peripheral interface) interrupt; ROM to RAM DMA done
• DP - RCP DP (display processor) interrupt; RDP processing done
• PRE-NMI - An NMI (nonmaskable interupt) has been requested and will occur in 0.5 seconds
• CPU_BREAK - R4280 CPU has hit a breakpoint
• SP_BREAK - RCP SP (signal processor) interrupt; RCP has hit a breakpoint
• FAULT - R4280 CPU has faulted
• THREAD_STATUS - Thread was created or destroyed

Threads, messages, and events work together to form the core of the N64 operating system. N64 applications run under a small, multithreaded operating system. Often a thread needs to wait for an exception such as an interrupt. Exceptions are trapped by the operating system and turned into events. Threads may register to receive notification of system events by requesting that the operating system send them a message whenever a system event occurs.

A flag that indicates the occurrence or the end of an event.

A system used to split the cache memory into groups and place the data currently at a specific address in main memory into the "associated" position in the split-out area of the cache. If the cache is split in two, the system is called "2-way set associative." If the cache is split into a number of areas equal to the number of blocks in the data area, the system is called "full associative."

The code added by makerom that clears (initializes) the Bss (uninitialized) section, sets the stack pointer, and jumps to the boot entry routine.

The GNU C compiler.

The global data area that can be used by all functions, not just local functions.

To allow the Controller Pak to be shared among different applications, the Controller Pak Library creates a file system which it uses for managing the memory areas. Intuitively, this system can be regarded as a greatly simplified version of the file system used in PC operating systems. In the Controller Pak, files are called game notes or simply notes. Up to 16 game notes can be created in one Controller Pak.

An application reserves a game note for data storage. As a general rule, the application program must verify that a game note has been reserved by the application or that there is adequate space remaining before the player begins a game. If no notes are available for use, a message must be displayed before the game is started, such as "The game cannot be saved. Do you still wish to start the game?" Please make every effort to avoid problems such as display of a "Cannot Save" message after a player registers a top score in a game.

The size of the game note can be set individually for each game, provided a new note does not exceed the number of pages remaining. When the note size is set with the library, the size is rounded up to the nearest 256 bytes regardless of the actual number input. Therefore it is recommended that the size be specified in multiples of 256 bytes. An area can be re-sized after it is reserved, but this operation should be performed in such a way that it does not cause problems for a player.

In general, one application should only use one game note. The Controller Pak Library does support multiple notes per application.

The SGI debugger that operates on the developmental workstation in the host and communicates with the emulator board through the dbgif program.

The area of memory that is dynamically allocated to meet the changing needs of the application.

The lowest priority thread. It does nothing except when the other threads are not operating. The N64 operating system hangs if there is no idle thread.

A method that directly includes the concluded commands in the main routine without using subroutines.

The system in the operating system that hides device-specific details in device drivers through which the operating system transfers data and control to provide a fair and safe access scheme to the devices. It is needed because most of the devices are shared resources. It provides a consistent, uniform, and flexible interface to all devices so that programs can reference devices by name and perform high-level operations without knowing the device configuration.

A typical I/O subsystem is structured in three layers:

• Device-independent system interface that provides a uniform interface to user-level software and common I/O functions (that is, protection, blocking, buffering) that can be performed across different devices.
• Device drivers to perform device-specific operations, such as setting up registers for DMA (direct memory access) and checking device status.
• Interrupt handlers that wake up a device driver after an I/O operation completes.

The N64 RCP has two modes of I/O operations:

• DMA to provide a minimum of 64-bit transfer between the RDRAM and any of the devices
• IO to provide a 32-bit transfer between the CPU and any of the devices

The N64 operates in a real-time environment, so its I/O subsystem is one of the most time-critical areas. In addition, the customized N64 environment contains a well-known set of device interfaces. Therefore, the N64 I/O subsystem is designed for optimal throughput and response, not for portability and generality. This design approach coincides with the main N64 design philosophy, which has always been (and still is) to follow the minimal approach.

The N64 operating system provides an optimized I/O interface layer that directly communicates with the hardware. These interfaces include:

• VI (video interface) routines that communicate with a VI Manager (a system thread). The VI Manager thread receives all vertical retrace interrupts and programs the video hardware. It also receives all counter interrupt messages and implements timer services.
• PI (peripheral interface) routines that communicate with a PI Manager (system thread). It manages access to the Game Pak ROM so that two threads do not attempt to use DMA (direct memory access) from ROM to RAM at the same time.
• AI (audio interface) routines that program the audio hardware to output the desired sample rate and that manage access to the audio data buffer.
• DP (display processor) routines that provide the RDP interface.
• Cont or CI (N64 Controller interface) routines that reset, detect, obtain status, query and read data from the game Controllers connected to the N64 Control Deck.

The N64 I/O subsystem has these layers:

• Device-dependent system interface composed of two layers of function calls -- a high-level abstraction layer and a low-level (raw) I/O layer. The high-level layer provides mutual exclusion on devices that support both DMA and I/O operations, and it uses the lower layer to initiate raw I/O operations. The raw I/O layer is exposed to allow you to construct your own custom I/O software interface or use the low-level layer exclusively if your game requires no protection for accessing devices.
• Device manager for devices shared between two or more threads and to ensure that DMA and I/O operations do not overlap. The device manager is simply a thread that runs at a high priority. The main purpose of this manager is to process all DMA requests to and from a device (that is, ROM devices), thus guaranteeing safe and orderly usage of the device.
  
  Upon start-up, the manager registers an event, its event message queue, and a message with the system. The manager then "listens" to its input command queue for request messages. The manager processes one request of a time from the queue by calling the corresponding low-level device routine to initiate the I/O operation. Then the manager waits for an event sent from the exception handler that signals I/O completion. Once awakened, the manager notifies the calling thread (IO requestor) by simply sending the request message to a pre-registered message queue. Then the manager again listens for new requests. The reason for alternating the listening between these two queues (command and event queues) is that there can be only one outstanding I/O transaction at any given time.
• System-wide exception handler that traps all exceptions and interrupts. This handler is simply an optimized event notifier. That is, upon receiving an event (either a supported exception or interrupt), the handler searches the event table for an associated message queue and message, sends the message to the queue, and simply returns. The handler does not perform any device-specific operations.

These components represent a much trimmed-down version of the typical I/O layers. All overhead associated with device-independent interfaces (that is, naming and buffering) has been removed; protection is implemented only on shared devices.

The low-level (raw) I/O interface is also available, so you can customize device interfaces based on your specific needs. The result is a very lightweight and optimized interface that in most cases allows you direct access to the devices.

The I/O subsystem must ensure that only one process can use a device at any one time, thus excluding other requesting processes and forcing them to wait. In the N64 environment, each device can process only one I/O transaction at any given time. For example, if there is a DMA transfer in progress between ROM and RDRAM, you cannot issue an I/O read from a different ROM location. If such a read is issued, the current DMA transfer will probably fail. Therefore, protection (or mutual exclusion) should be provided for devices that support both DMA operation and I/O read/write. The SI Manager in NuSystem does this for you by ensuring that only the device manager currently registered with the SI Manager can operate.

The effective address of the program command.

A cache that temporarily holds the program commands. It improves the performance of the command call.

A timer that sends a signal at each constant interval.

The core of the operating system. The N64 runs under a small, real-time, preemptive kernel. Unlike many popular real-time kernels, no semaphores or event flags are provided. All synchronization is provided by sending and receiving messages. The N64 kernel is supplied as a set of run-time library functions, so that only those portions that are actually used are included in the game�s run-time image. The N64 kernel is so minimal that it has no official name. The kernel can be considered as being layered into core functionality and higher-level system services.

The N64 operating system simply runs in the kernel mode (kseg0) with cache and direct mapping enabled. In this mode, the virtual address 0x80000000 is mapped directly to physical address 0x0. The translation lookaside buffer (TLB) is not used by the operating system to provide virtual memory support. However, low-level routines are available for game developers to program the TLB directly. Furthermore, a region library is provided to simplify the task of allocating and de-allocating fixed-size memory buffers.

The delay that occurs between the time an address is input to memory and the time when the actual data is fetched.

The abbreviation for logical block address.

To place data from ROM to main memory and from main memory to cache, and associate them.

The process of managing all the available memory. All memory management is left up to the game. That is, the N64 operating system provides no heap or dynamic memory allocation mechanism for the game. Because the game has direct access to the entire memory map, it has total control on how memory is partitioned and used. The operating system simply runs in the kernel mode (kseg0) with cache and direct mapping enabled. In this mode, the virtual address 0x80000000 is mapped directly to physical address 0x0. Translation Lookaside Buffer (TLB) is not used by the operating system to provide virtual memory support. However, low-level routines are available for game developers to program the TLBs directly. Furthermore, a region library is provided to simplify the task of allocating and de-allocating fixed-size memory buffers.

Because games manage memory directly, they must invalidate and flush caches before transferring data between Game Pak ROM (or the RCP) and main memory. The operating system provides functions to do this.

Information sent or received by the system and threads. The N64 operating system is message-based, so messages are extremely important. Unlike many popular real-time kernels, no semaphores or event flags are provided. All synchronization is accomplished by sending and receiving messages. This has deliberately been made very efficient, and the lack of other synchronization primitives should not be a problem. In fact, there are advantages to using only messages. The operating system code itself is smaller and less intrusive on game space than it would be if it had to provide multiple facilities for thread synchronization. Also, because information must frequently be transferred when threads synchronize, you can get more use out of a single operation. Of course, messages are also useful in simply transferring information from one thread to another. In the N64 operating system, messages are also used to transfer information when a system event occurs.

By sending and receiving messages, a high priority thread waiting for a message can yield execution to a lower priority thread. Threads communicate and synchronize their operations by using messages. Multiple threads within an application frequently need to synchronize their execution. For example, thread A cannot continue until thread B has performed some operation. The message-passing functions provide the needed synchronization mechanism.

Threads, messages, and events work together to form the core of the N64 operating system. N64 applications run under a small, multithreaded operating system. Simply put, this means that the R4280 CPU switches between several independent components called threads. Each thread consists of a sequence of instructions, a stack, and (possibly) static data that is used only by the thread. Subdividing an application into threads has several advantages. You can effectively isolate each part of the application to avoid interference. You can divide your application into small, easily-debugged modules. And because each thread can be written independently to perform exactly one function, complexity is reduced.

Threads use messages to communicate with one another. While this could be done using shared global variables, such an approach is often unsafe. One thread must know when it is safe to read data that is being written by another. Message passing makes communication between threads an atomic operation; a message is either available or not available, and the associated data arrives at the receiving thread at one time.

A second, perhaps more important function of messages is to provide synchronization between threads. Often a thread reaches a point in its execution where it cannot continue until another thread has completed some task. In this case, the running thread has no useful work to do, so it should yield the processor until the task is completed. You use messages to provide the mechanism for the thread to wait until that time.

Often a thread needs to wait for an exception such as an interrupt. Exceptions are trapped by the operating system and turned into events. Threads may register to receive notification of system events by requesting that the operating system send them a message whenever a system event occurs.

Software that defines the functionality of the RSP. Nintendo provides a number of different microcodes for different purposes, some for audio and some for graphics. A game may use many different microcodes during the rendering of a single frame.

The abbreviation of millions of instructions per second. It is a unit of measure of processor performance.

Protect a device's I/0 process by excluding other I/O processes.

An N64 interrupt. When the N64 Control Deck's RESET switch is pushed by the game user, the hardware generates an HW2 interrupt to the R4280 CPU. The interrupt is serviced by the OS event handler which sends a message of type OS_EVENT_PRENMI to the message queue associated with that event to announce that the HW2 interrupt (known as the PRE-NMI event) will be followed in 0.5 seconds by a non-maskable interrupt (NMI) to the R4280 CPU (unless the RESET switch is pushed and held for more than 0.5 seconds, in which case the NMI will occur when the switch is released).

After the NMI occurs, the hardware is reinitialized, and:

• The first megabyte of the game in ROM is copied into the first megabyte of RAM following the boot address
• The BSS (Block Started by Symbol) for the boot segment is cleared
• The boot procedure is called.

There are some minor differences between a power on reset and an NMI reset. After a power on reset, the caches are invalidated. After an NMI reset, the caches are flushed and then invalidated. Also, the power on reset configures the RAM, while the NMI reset leaves the RAM alone.

After NMI reset, the contents of memory, except for the 1 megabyte that is copied in, are the same as before the NMI occured. The global variable, osResetType, is set to 0 on a power up reset and to 1 on a NMI.

Processing time that is not directly related to the user program. It is the time used by the operating system to allocate or manage system resources and control processes.

For easy management of the Controller Pak, memory is delimited by 256-byte boundaries and managed in 256-byte units. Each 256 bytes is called a "page" and, beginning with memory area 0x0000 ~ 0x00ff, the pages are named Page 0, Page 1, Page 2, and so on up to Page 127. For a 256K-bit Controller Pak (256K-bit capacity = 32K bytes = 128 pages), 5 pages (Pages 0-4) are reserved by the system for game note management. This reserved area totals 1,280 bytes. Consequently, the number of pages that can actually be used by the game is reduced by 5 pages.

The role of each page used by the system is as follows:

• Page 0 holds the serial number and label
• Pages 1 and 2 are the I-NODE area
• Page 3 and 4 are the game note information area
• Page 5 is the first page of actual game data area

Therefore, the effective number of pages available is 123.

A register to set the page sizes (4K, 16K, 64K, 256K, 1M, 4M, 16M) of each TLB (translation lookaside buffer) entry.

By splitting a program into 256-byte pieces called pages and loading only the required pages, you can use the memory area most effectively.

A technique that speeds up execution by overlapping processes in the CPU. That is, mixed component elements from various processes are piped in to the CPU continuously from the pipeline. No time is wasted.

An operation that removes (pops) a data element from the current stack. The stack is a LIFO (last in first out) structure, so you are popping the data element that was last pushed onto the stack.

When a process that has a higher priority than the executing one is encountered, the current process yields CPU for the higher priority process. The higher-priority process preempts the lower priority process.

A heads-up notification that the N64 reset switch was pressed by the game user and an NMI (non-maskable interrupt) will occur in half a second. When a PRE-NMI occurs, you need to save the currently executing process to prepare for the NMI.
When the N64 Control Deck's reset switch is pressed by the game user, the hardware generates an HW2 interrupt to the R4280 CPU. The interrupt is serviced by the OS event handler which sends a message of type OS_EVENT_PRENMI to the message queue associated with that event to announce that the HW2 interrupt will be followed in 0.5 seconds by a non-maskable interrupt (NMI) to the R4280 CPU (unless the RESET switch is pushed and held for more than 0.5 seconds, in which case the NMI will occur when the switch is released).

When the game receives the OS_EVENT_PRENMI message it should:

• Stop issuing graphics tasks to prevent the RDP from being stopped in a non-restartable state.
• Stop issuing audio tasks to prevent audio pops.
• Stop issuing ROM (PI) DMAs.

A tool that measures performance information such as the number of times a resource was called and the execution time.

The act of storing (pushing) a data element onto the current stack. The stack is a LIFO (last in first out) structure.

Random-access memory. This is memory that can be written to and read from dynamically at any location. The N64 main memory (RAM) has a total of 4 megabytes of RDRAM.

The gload tool loads games for the N64 development system for IRIX. Specifically, it downloads a prepared ROM image into the "Game Pak memory" on the Nintendo 64 emulator board. Nintendo calls this RAMROM memory because it is RAM memory that occupies 16 megabytes of space where a Game Pak's ROM would ordinarily reside on the real N64 Game Pak hardware.

The port that couples the SGI Indy with the N64 emulator board.

Rambus Dynamic RAM. This unique RAM from Rambus, Inc. combines high-speed access with the low cost of dynamic RAM. The N64 main memory has a total of 4 megabytes of RDRAM.

Something used by a thread or a task. For example, the CPU, memory, an I/O device, and the RCP are all resources.

Read-only memory where the game is stored in the N64 Game Pak.

The file that describes the segment configuration of objects or unprocessed data files. It is referred to when the ROM image is created.

The manager (thread) that decides the execution order of several threads or the allocation order of system resources.

The RDRAM address for the segment under the current control of the RSP (reality signal processor). The RSP microcode can control 16 segments. The segment address contains the segment ID and the offset, so the physical address is found by adding the segment offset to the base address, which is found by using the segment ID to serch the segment base register.

A register related to the segment table. It holds the segment base address for a specific segment ID.

A table used for calculating the physical address of a program that is split into segments.

An integer argument used for controlling the synthesis process in a multitasking system. It is similar to an event flag in that it controls the synthesis by using signals (integer flags) to flag the beginning and ending of processes to ensure that no synchronization problems occur.

Temporary memory that has a LIFO (last in first out) structure. You pop the stack to remove a data element and push the stack to add a data element.

The system that manages interrupts and other exceptions. In the N64 operating system when an exception occurs, this handler sends a message to the appropriate message queue after looking up the message queue and message from the corresponding event table.

Threads that control DMA or I/O operations in the same way that device manager threads such as the PI Manager or VI Manager manage devices.

The Basic unit of CPU execution.

All code that runs under the operating system runs in the same address space. That is, the game runs as one process. While it is possible to structure a game application as one monolithic program, it is usually advantageous to subdivide it into smaller, more manageable subprograms called threads. With its own stack, each thread usually does one job, often repetitively. This subdivision leads to simplicity for each thread, so it is easier to debug and easier to minimize interference between threads.

Threads may be created, destroyed, stopped, or blocked (the latter by waiting on a message). Threads run until they have to wait for a resource or an event, at which point they yield the CPU to another thread. Each thread has an assigned priority level that is used to determine which thread gets the CPU at any given time. In response to an external event, a thread may be forced to yield control of the CPU. The operating system preserves the state of the thread for restarting at a later time. Thus, the system can properly be described as preemptive. Threads may even be preempted during system calls when it is safe to do so.

There is no concept of a swap clock or round-robin scheduling as is found in UNIX and other time-sharing systems, so two or more threads that run at the same priority level do not alternate use of the CPU. The thread that has the CPU runs until it yields or is preempted by a higher priority thread in response to an exception.

Threads, messages, and events work together to form the core of the N64 operating system. N64 applications run under a small, multithreaded operating system. Simply put, this means that the R4280 CPU switches between several independent components called threads. Each thread consists of a sequence of instructions, a stack, and (possibly) static data that is used only by the thread. Subdividing an application into threads has several advantages. You can effectively isolate each part of the application to avoid interference. You can divide your application into small, easily-debugged modules. And because each thread can be written independently to perform exactly one function, complexity is reduced.

Threads use messages to communicate with one another. While this could be done using shared global variables, such an approach is often unsafe. One thread must know when it is safe to read data that is being written by another. Message passing makes communication between threads an atomic operation; a message is either available or not available, and the associated data arrives at the receiving thread at one time.

A second, perhaps more important function of messages is to provide synchronization between threads. Often a thread reaches a point in its execution where it cannot continue until another thread has completed some task. In this case, the running thread has no useful work to do, so it should yield the processor until the task is completed. You use messages to provide the mechanism for the thread to wait until that time.

Often a thread needs to wait for an exception such as an interrupt. Exceptions are trapped by the operating system and turned into events. Threads may register to receive notification of system events by requesting that the operating system send them a message whenever a system event occurs.

The operating system provides convenient functions to start and stop both countdown and interval timers. These timers are expressed in CPU count register cycles, which depend on the video clock. That is, a counter tick in a PAL system occurs more frequently than the one in a NTSC system. Developers can also set and get the real time counter value.

The translation lookaside buffer. This buffer holds the address conversion table containing the virtual to physical address conversion information. You can use it to convert from the virtual to physical addresses at a high rate of speed.

The R4280 has variable translation lookaside buffer (TLB) page size capability. This can provide additional, useful functionality such as the "poorman�s two-way set-associative cache," because the data cache is 8K bytes of direct-mapped memory and TLB page size can be set to 4K bytes. This means that the application can roll a 4K-byte cache window through a contiguous chunk of memory without wiping out the other 4K bytes in cache.

The geometric Shape.

The vertical synthesis of scan lines on the TV screen. Specifically, it refers to the time interval when the phosphor gun of the TV is turned off in order to move the gun to the top of the screen. This time interval occurs every 1/60th of a second for NTSC. It is during this time interval that it is safe to write to the frame buffer.

When data writing occurs, this system first writes data to the cache memory and then writes back to main memory as the cache memory overflows. Also, it refers to the cache memory of the system itself.

A rendering technique where the distance from the viewer (Z) for each pixel is stored during rendering and used to determine which objects are displayed. If for instance, a pixel representing the dashboard of a car has already been drawn in a given location on the screen, then by comparing the distance from the viewer to the bumper to that of the dashboard, the program knows that the bumper should not be drawn over the top (in front) of the dashboard. This feature is implemented in the N64 RCP graphics hardware.

Nintendo® Confidential Copyright © 1998 Nintendo of America Inc. All rights reserved Nintendo and N64 are registered trademarks of Nintendo Last Updated March 1998