The Nintendo 64 operating-system SDK shipped small source projects that taught developers how to draw a first frame, schedule audio and graphics, use controllers and storage, and measure the hardware. The examples changed across releases: new peripherals gained samples, some older projects moved to a separate directory, and familiar folder names often held revised files ^{1 2}.

Two development archives preserve earlier working copies. The Oman archive has samples in both APPS and usr/src/PR. A Project Reality (PR) tree beside the Turok: Dinosaur Hunter source holds many of the same projects. Their shared 2.0G release notes identify an early SDK base, but neither tree is an untouched distribution ³. This guide compares those copies with the supplied 2.0H, 2.0I, 2.0J, and 2.0L packages.

The wider libraries and development tools are covered in the SDK overview:

---

Key terms

The SDK uses these abbreviations throughout its source and notes:

• RSP - Reality Signal Processor, which runs graphics and audio microcode.
• RDP - Reality Display Processor, which rasterizes graphics commands.
• RCP - Reality Coprocessor, which includes the RSP and RDP.
• LOD - Level of detail, selecting a model or texture representation for its screen size or distance.

---

Where are the SDK demos?

The dated evidence and sample coverage place the development copies beside four packaged releases. Dates refer to bundled notes or readmes, not necessarily to when every file was created. Folder counts include the shared Texture asset directory; Oman’s APPS count covers same-named inventory folders, while its other locations are listed separately ^{4 5 3 6 7 8}:

Copy	Dated evidence	Inventory coverage	Character of the copy
Oman	2.0G base, 30 September 1996	28 APPS folders; 5 in usr/src/PR; Tron in NTRON.SKIP	Developer archive with more than one sample tree
Turok	2.0G base, 30 September 1996	38 inventory folders	PR working tree with retained build output
OS-PC 2.0H	PC readme dated 19 March 1997	40 direct folders	Earlier PC source layout, including 64DD examples
OS-Library IRIX 2.0I	Notes dated 15 December 1997	44 main folders	Reorganized demos tree
OS-PC-SGI 2.0J	Notes dated 1 February 1999	43 main + 5 older folders	More peripheral examples; older projects retained separately
OS-PC 2.0L	Notes dated 3 July 2000	44 main + 7 older folders	Flash, S2DEX2, and profiling examples

The supplied disc photographs show two editions from the later part of this sequence. The gold label identifies the IRIX 2.0I release. The teal disc is labelled OS/SGI 2.0L, while the 2.0L inventory below was checked against a separate OS-PC 2.0L package ^{9 2 10}.

The 2.0G attribution for Oman and Turok comes from byte-identical release notes in the two archives. It identifies a base version, not the age or revision of every project. Turok’s PR tree also contains Iguana’s tengine and compiled demo output. Those files show a working development tree; a sample’s presence beside the game does not establish that it was compiled into Turok ^{1 3}.

How did the collection change?

The 2.0H PC package still places projects directly in USR/SRC/PR. Its notes describe nnsample1 as a scheduler example and nnsample2 as an F3DEX and LOD example. The package also has a Rumble Pak test, a 64DD font sample, and a disk variant of tile_rect3d ⁶.

The 2.0I IRIX release groups the examples under usr/src/PR/demos. Its notes identify gs2dex, eeptest, and sramtest as new samples. It also includes cptest, greset, print, and spin, projects familiar from the earlier working trees ^{9 11}.

greset helps explain why a dash in one release need not mean the lesson disappeared. Oman, Turok, and IRIX 2.0I have byte-identical source that opens IRIX’s /dev/mmem and writes the SGI board’s reset-control register. The 2.0H PC archive documents greset but has no program files for it; its PC readme instead shows a Partner-N64PC reset command. The platform difference is a plausible reason for the omission, although the installer does not say why ¹².

By 2.0J, examples for 64DD, the Transfer Pak, and voice recognition appear in the inspected PC collection. gtdemo, host_test, hostio, simple, and turbomonkey sit in demos_old rather than the main folder; they remain available. In 2.0L, nnsample1 and nnsample2 join them there, while flash, spritemonkeyEX, and threadmonkey appear in the main set. The last three cover Flash ROM testing, S2DEX2 sprites, and thread profiling ^{13 2 14}.

These are source distributions, with assets and build files alongside the C code. Some projects need the shared Texture directory. The 2.0L guide names eight that depend on it, including mipmap and spgame ².

---

Official demo inventory

The table shows which inspected copies contain each sample. Yes means a same-named folder is present; Oman’s Yes (/PR) locates a project in its separate usr/src/PR tree, and Yes (NTRON.SKIP) identifies its Tron source under that name. Old means a later PC release places the project in demos_old. A dash means the project was not found in the compared locations; it does not rule out related code elsewhere. The descriptions summarize the supplied guides and source. Texture is shared data, not an application ^{1 13 2 9 5 6 7 8}:

Folder	What it demonstrates	Oman	Turok	2.0H	2.0I	2.0J	2.0L
autofill	Triangle fill-rate measurement	Yes	Yes	Yes	Yes	Yes	Yes
blockmonkey	Display-list and rendering performance	Yes (/PR)	Yes	Yes	Yes	Yes	Yes
bumpmap	Bump mapping	Yes	Yes	Yes	Yes	Yes	Yes
chrome	Reflection mapping	Yes (/PR)	Yes	Yes	Yes	Yes	Yes
ci8fb	8-bit color-index frame-buffer rendering	Yes (/PR)	Yes	Yes	Yes	Yes	Yes
cptest	Small C++ application and runtime support	Yes (/PR)	Yes	-	Yes	-	-
ddspgame	64DD commands and error handling	-	-	-	-	Yes	Yes
detail	Multitiling, detail textures, and mipmaps	Yes	Yes	Yes	Yes	Yes	Yes
eeptest	4 Kbit and 16 Kbit EEPROM tests	-	-	-	Yes	Yes	Yes
fault	CPU fault-event handling	Yes (/PR)	Yes	Yes	Yes	Yes	Yes
flash	1 Mbit Flash ROM tests	-	-	-	-	-	Yes
font	64DD mask-ROM font data access	-	-	Yes	-	-	-
fogworld	Fog and volume culling	Yes	Yes	Yes	Yes	Yes	Yes
gbpak	Transfer Pak access to a Game Boy cartridge	-	-	-	-	Yes	Yes
ginv	CPU, RCP, and memory inventory	Yes	Yes	Yes	Yes	Yes	Yes
gl	Partner-N64 game loader	-	-	-	-	Yes	Yes
greset	Host-side development-board reset utility	Yes	Yes	-	Yes	-	-
ground	Clipping a large ground plane	Yes	Yes	Yes	Yes	Yes	Yes
gs2dex	S2DEX sprite microcode	-	-	-	Yes	Yes	Yes
gtdemo	Animated characters and turbo graphics tasks	Yes	Yes	Yes	Yes	Old	Old
host_test	Host-to-target data transfer using osReadHost and osWriteHost	-	-	Yes	-	Old	Old
hostio	Indy-to-target data exchange	Yes	Yes	Yes	Yes	Old	Old
lights	Specular lighting and simulated shadows	Yes	Yes	Yes	Yes	Yes	Yes
mipmap	Texture filtering and mipmap comparison	Yes	Yes	Yes	Yes	Yes	Yes
morphcube	CPU vertex morphing alongside graphics tasks	Yes	Yes	Yes	Yes	Yes	Yes
morphfaces	Two-dimensional image morphing and blending	Yes	Yes	Yes	Yes	Yes	Yes
motortest	Rumble Pak control	-	-	Yes	Yes	Yes	Yes
nnsample1	Nintendo scheduler and graphics tasks	-	-	Yes	Yes	Yes	Old
nnsample2	F3DEX 1.21 LOD and microcode loading	-	-	Yes	Yes	Yes	Old
nosPak	Controller Pak menu with Nintendo font data	Yes	Yes	Yes	Yes	Yes	Yes
onetri	Single-polygon rendering	Yes	Yes	Yes	Yes	Yes	Yes
onetri-fpal	Full-screen PAL version of onetri	-	-	-	-	Yes	Yes
overlay	Reusing RAM with code and data overlays	Yes	Yes	Yes	Yes	Yes	Yes
pfs	Controller Pak file-system operations	Yes	Yes	Yes	Yes	Yes	Yes
playseq	Audio sequence player	Yes	Yes	Yes	Yes	Yes	Yes
playseq.naudio	Sequence player using n_audio	-	-	-	-	Yes	Yes
polyline	Switching polygon and line microcode	Yes	Yes	Yes	Yes	Yes	Yes
print	osSyncPrintf performance with and without osInitRdb	Yes	Yes	-	Yes	-	-
reboot	Starting a disk program from a Game Pak	-	-	-	-	Yes	Yes
simple	Graphics, audio, input, and task scheduling	Yes	Yes	Yes	Yes	Old	Old
soundmonkey	Sequence and sound players with voice limits	Yes	Yes	Yes	Yes	Yes	Yes
spgame	Foreground and background sprites	Yes	Yes	Yes	Yes	Yes	Yes
spin	Interactive RCP and RDP graphics controls	Yes	Yes	-	Yes	-	-
spritemonkey	Sprite2D microcode	Yes	Yes	Yes	Yes	Yes	Yes
spritemonkeyEX	S2DEX2 sprite microcode	-	-	-	-	-	Yes
sramtest	256 Kbit SRAM tests	-	-	-	Yes	Yes	Yes
terrain	Controller-driven terrain editor	Yes	Yes	Yes	Yes	Yes	Yes
texlight	Diffuse and specular lighting on textured objects	Yes	Yes	Yes	Yes	Yes	Yes
threadmonkey	Thread profiler	-	-	-	-	-	Yes
tile_rect2d	Tiled texture rectangles	-	Yes	Yes	Yes	Yes	Yes
tile_rect3d	Seamless tiled triangles	-	Yes	Yes	Yes	Yes	Yes
tile_rect3d.disk	64DD version of tile_rect3d	-	-	Yes	-	-	-
topgun	Geometry converted from a MultiGen .flt model	-	Yes	Yes	Yes	Yes	Yes
tron	Transparent walls and an RDP hang workaround	Yes (NTRON.SKIP)	Yes	Yes	Yes	Yes	Yes
turbomonkey	Turbo graphics microcode performance	-	Yes	Yes	Yes	Old	Old
voice	Japanese-language speech-recognition sample	-	-	-	-	Yes	Yes
Texture	Shared textures for other demos; not an app	Yes	Yes	Yes	Yes	Yes	Yes

Oman has five projects only in its usr/src/PR tree: blockmonkey, chrome, ci8fb, cptest, and fault. Its APPS/NTRON.SKIP folder is a Tron project: the Makefile sets APP = tron and builds TRON.C. A search across the extracted Oman tree found references to tile_rect2d, topgun, and turbomonkey, but no demo source for those three ^{7 8}.

---

How closely do Oman and Turok match?

The inventory contains 33 demo projects present in both archives, counting Oman’s alternate PR and NTRON.SKIP paths but excluding the shared Texture asset folder. Only overlay, polyline, and print are byte-identical as complete folders. In seven more projects, every Oman file matches a Turok file at the same relative path, but Turok has additional files. Across all 33 projects, 29 have at least one exact file match ¹⁵.

The Oman archive viewer shows the wider directory tree, including the SDK examples and hardware verification programs:

The seven projects with extra Turok files are ginv, greset, gtdemo, hostio, onetri, simple, and soundmonkey. Their 106 extra files are mostly object files, ROM images, executables, dependency files, and build maps. GTDEMO also retains generated walktable and punchtable tools and headers. These build products explain why a folder can contain the same source as Oman without being identical as a whole ¹⁵.

Other matches are partial. Oman’s chrome shares four texture files with Turok, while its nine corresponding source and build files differ. mipmap matches on 53 of 54 Oman files. Release labels matter too: onetri has the same 11 relative file paths in the 2.0J and 2.0L packages, but only one file is byte-identical across those two versions ^{16 13 2 7}.

The Turok source analysis explains the game engine and build environment surrounding its copy of the PR samples:

---

What do the demos teach?

The collection starts with the structure of a running frame, then moves into rendering, host communication, audio, and peripherals. The source is useful even when a sample’s on-screen result is simple.

A first frame, memory overlays, and scheduling

ONETRI draws spinning triangles. Beyond the geometry, it sets up threads, message queues, graphics output, and a ROM spec file. OVERLAY extends that pattern by placing alternative code and data segments in the same RAM space at different times. Together they show the basic program structure and one way to reuse limited memory ¹⁷.

SIMPLE joins graphics, controller input, music, and sound effects. It gives audio work higher scheduling priority because a missed audio deadline is audible, while graphics can repeat a frame. nnsample1 later provides a different scheduler implementation for developers studying how to coordinate graphics tasks ^{18 14}.

---

Texture filtering, graphics tasks, and measurement

MIPMAP compares point filtering, bilinear filtering, generated mip levels, and prepared mip levels in four views. Its controller menu changes the texture and scale so the difference becomes visible ¹⁹. The brick images below are two original SGI-format inputs from Oman, converted losslessly for the article. They are textures, not screenshots from a running console:

GTDEMO combines animated characters, a punch action, and turbo graphics tasks. It exposes timing bars for CPU and RCP work. AUTOFILL narrows the question to triangle fill rate: it varies triangle shape and count, then records timing data for plotting. The pair shows how SDK examples could teach both visible effects and measurement methods ^{20 21}.

Other rows isolate one rendering choice: chrome uses reflection mapping, fogworld combines fog with volume culling, and tile_rect3d tiles large surfaces without visible seams ^{1 6}.

---

Sprites and audio

SPGAME builds a scene from a background, moving ball sprites, and sprite-rendered text. Its build file converts the source images with mksprite; the program draws seven ball objects ²². The two images below are source assets, not captured frames:

The sample family also tracks graphics microcode changes. spritemonkey demonstrates Sprite2D, gs2dex covers S2DEX, and 2.0L’s spritemonkeyEX uses S2DEX2. For audio, playseq demonstrates sequence playback while soundmonkey exercises sequence and sound players with voice limits ^{2 9}.

---

Host tools, controllers, and storage

TERRAIN lets a developer edit hills with the N64 controller and save generated terrain data back to an SGI Indy. Its README distinguishes launching the host-side editor from loading only the ROM. HOSTIO is a smaller host-to-target communication example ^{23 1}.

Other projects test the edges of the system: pfs exercises Controller Pak files, motortest controls the Rumble Pak, and eeptest, sramtest, and flash test different save-memory devices. print measures osSyncPrintf with and without osInitRdb, making a host debug facility into a timing experiment ^{2 9}.

---

Beyond the OS demo collection

The N64 Developers Toolkit 5.2 disc is labelled August 2000. Its later examples are organized separately: NuSystem/sample includes projects such as nuoverlay and nulod; other packages contain HVQ video and sound-tool samples. These complement the operating-system demos rather than replacing the collection above ^{24 25}.

The Oman archive viewer indexes its wider APPS tree, including hardware tests outside this catalog. The Turok source analysis explains the adjacent game engine and build environment.

---

References