Boss Rally / Top Gear Rally: byte-exact decompilation

<p> <img src="docs/brally/img/native-brally.png" width="49%" alt="Boss Rally racing along the Coastline sea wall, chasing a rival car, in the native 64-bit build on macOS"> <img src="docs/tgrally/img/native-tgrally.png" width="49%" alt="Top Gear Rally racing out of the Coastline town in the chase view, in the native build on macOS"> </p>

Left: Boss Rally's Coastline in the native 64-bit build (Native ports), the decompiled PC source compiled for Apple Silicon and drawn through Metal. Right: Top Gear Rally's Coastline in the native N64 build (ports/tgrally), the decompiled ROM source compiled for Apple Silicon, with the RCP's display lists drawn through Metal.

Top Gear Rally is fully byte-exact and documented. As of October 7, 2026, every one of the N64 game's 572 functions compiles under SGI's IDO 5.3 to the very bytes of the retail ROM, each transcribed by hand. Every function is named and carries a comment saying what it does, and every area of the source has a README listing its files and functions (src/tgrally/). The 1997 cartridge now exists as readable C that rebuilds it exactly.

Play it: download Rally Builder for macOS, Windows or Linux from Releases. It builds a native copy of any of the three games (Boss Rally, Top Gear Rally or Top Gear Rally Remastered, below) from your own BIN/CUE or ROM, checked by MD5; no game data ships with it (builder/).

Maintainer: Jeffrey Wilbur, Strut B, LLC
Contact: retro@strutb.com

License, and no claim to the games

I claim no ownership whatsoever of the decompiled source code. Boss Rally and Top Gear Rally, their code and their assets belong to their rights holders. The C in this repository is a reconstruction of their work, recovered by hand so that it compiles back to the original bytes. It is not mine to own, license or give away, and nothing here says otherwise. No game data ships in this repository: every build starts from your own copy of the game.

This project exists for preservation and for love of these games, so that the rally games Boss Game Studios made in the late 1990s can still be read, studied, built and played long after the cartridges, discs and hardware they shipped on are gone.

The work that is my own (the tools, the native ports' platform code, the Remastered renderer and Rally Builder) is dedicated to the public domain under CC0 1.0 Universal. Anyone may use it for any purpose, with no permission or credit needed.

Why CC0. A preservation project should claim as little as possible. CC0 asserts nothing over the reconstructed games, and it gives everything that is mine to the public domain, with a fallback licence for countries where copyright cannot be waived outright. That fallback is why CC0 was chosen over the Unlicense, which has the same intent but no fallback. Files written by others keep their own terms: tools/brally/c2read/ is under the MIT licence in its LICENSE.byte-tactics.

The Decompilation Standard

The purpose of a decompilation, as opposed to a recompilation, is preservation: recovering the game itself, as written, in a form that outlives the original hardware and media. Playability and portability are welcome side effects, not the direct goal. With a bit-exact decompilation, every function, built with the original compiler, must reproduce the original machine code byte for byte. A bit-exact match is 100% reliability that the source is accurate to the original, ensuring preservation for future generations.

Project Purpose

A bit-exact decompilation of Boss Rally (PC, 1999), held to the MAME standard: the C source is the single source of truth and must compile to byte-identical output under the original compiler (MSVC 5.0), while the same source also cross-compiles to modern platforms. One tree, two build targets (the SM64 model). Progress is measured only in per-function byte-identical equivalence; playability is a consequence, never a reason to reorder matching. Do keep the port buildable.

Game background

Boss Game Studios built Top Gear Rally for the N64 (1997), then shipped Boss Rally for Windows (1999) on the same engine. The PC build still emits N64 F3DEX display lists, ships N64-format textures and big-endian geometry off the disc, and carries the ROM's diagnostic strings. The PC game ships two renderer DLLs over one shared core: BRGlide.dll (3dfx Glide: the mature target and the reference for all matching) and BRD3D.dll (Direct3D: statically links Microsoft's CRT, so it's reference-only, out of scope).

Two games, two decompilations

It's tempting to assume the N64 game is the PC game compiled for another machine. It isn't. When the PC source is compiled for the N64 and compared against the ROM, only about a fifth of the ROM's code has a clear match. At most around half could turn out to share code with the PC game.

• Boss Rally is the bigger game. It has roughly twice as many game functions as Top Gear Rally. It's a later game built on the same engine, not a straight port.
• Shared code still changed. Where a function exists in both games, the two usually differ by a few percent of their instructions. Two years of edits sit between the 1997 and 1999 releases, so PC source is a strong starting point for an N64 function, not a finished answer.
• Much of the ROM has no PC counterpart. Around 40% is N64-only code: graphics and audio drivers, the front end and other console-specific systems. It has to be decompiled from scratch. Another sixth is Nintendo's system library and a compression library, which are linked in rather than decompiled.

So the N64 game gets its own decompilation, kept apart from the PC tree (see Top Gear Rally (N64) decompilation). The two still help each other. The N64 compiler records operand order that the PC compiler throws away. A matched function on either side is a head start on its twin.

Current Status

Both decompilations count two milestones: M1, functions certified to behave exactly like the original (T3) plus byte-exact ones (T4), and M2, byte-exact functions only. The blocks below are snapshots; regenerate the bars and both treemaps in one step with python3 tools/brally/progressbar.py: do not hand-edit them.

Boss Rally (PC)

<!-- PROGRESS:BEGIN: generated by tools/brally/progressbar.py; do not edit by hand -->

Snapshot 2026-10-28.

M1  Contract-valid: compiles & ports (T3 + T4)
    ████████████████████████████████████████  100.0%   450,489 / 450,649 B   1,495 / 1,495 fns
M2  Byte-exact (T4)
    ███████████████████████████████░░░░░░░░░  78.6%   354,110 / 450,649 B   1,405 / 1,495 fns

Area	M1: contract-valid	M2: byte-exact
BossRally.exe	████████████████████ 100%: 35/35 fns, 2,482 B	████████████████████ 100%: 35/35 fns, 2,482 B
BRally.exe	████████████████████ 100%: 28/28 fns, 2,860 B	████████████████████ 100%: 28/28 fns, 2,860 B
SetVideo.exe	████████████████████ 100%: 42/42 fns, 7,251 B	████████████████████ 100%: 42/42 fns, 7,251 B
BRGlide.dll	████████████████████ 100.0%: 450,489 B, 1,495 fns	████████████████░░░░ 78.6%: 354,110 B, 1,405 fns

<!-- PROGRESS:END -->

Every box is one function, sized by its bytes in .text and grouped by module: green = byte-exact (T4, M2), blue = contract-valid but not yet byte-exact (T3), amber = still diffing (T2), gray = not started (T1), purple = linker/CRT (fenced). Green + blue is the M1 corpus. Regenerate: python3 tools/brally/progressmap.py --svg docs/brally/progress-map.svg.

Top Gear Rally (N64)

Complete. All 572 functions are byte-exact (M2 100%), and every one is named and documented in its source.

<!-- N64-PROGRESS:BEGIN: generated by tools/brally/progressbar.py; do not edit by hand -->

Snapshot 2026-10-28.

M1  Contract-valid (T3 + T4)
    ████████████████████████████████████████  100.0%   379,932 / 379,932 B   572 / 572 fns
M2  Byte-exact (T4)
    ████████████████████████████████████████  100.0%   379,932 / 379,932 B   572 / 572 fns

<!-- N64-PROGRESS:END -->

Top Gear Rally (Europe)

The Europe cartridge (PAL, EEPROM saving, faster computer cars on Desert and Jungle) is a sub-variant of the same source, held to the same standard: every function byte-exact against the Europe ROM (docs/tgrally/REGIONS.md).

<!-- N64-EUR-PROGRESS:BEGIN: generated by tools/brally/progressbar.py --regions; do not edit by hand -->

Snapshot 2026-10-28. Europe: 582 of 582 game functions byte-exact (100.0%), 0 left.

M2  Byte-exact (T4)
    ████████████████████████████████████████  100.0%   385,308 / 385,308 B   582 / 582 fns

<!-- N64-EUR-PROGRESS:END -->

Top Gear Rally (Japan)

The Japan cartridge (its own title logo, three replaced cars, real-livery decals, Japanese text through a Japan-only %j escape, renamed terms) is a sub-variant of the same source, held to the same standard: every function byte-exact against the Japan ROM (docs/tgrally/REGIONS.md).

<!-- N64-JPN-PROGRESS:BEGIN: generated by tools/brally/progressbar.py --regions; do not edit by hand -->

Snapshot 2026-10-28. Japan: 585 of 585 game functions byte-exact (100.0%), 0 left.

M2  Byte-exact (T4)
    ████████████████████████████████████████  100.0%   383,948 / 383,948 B   585 / 585 fns

<!-- N64-JPN-PROGRESS:END -->

Same map as the PC lane, over the ROM: one box per function, sized by its bytes and coloured by tier (green = byte-exact, blue = contract-valid, amber = in progress, gray = not started). Regenerate: python3 tools/tgrally/n64map.py --svg docs/tgrally/progress-map.svg.

More

• docs/brally/cheats.md: the six hidden cheat codes the decompilation found in the PC game.
• docs/brally/port/splitscreen.md: the PC game's complete but unreachable two-player split-screen renderer.

Boss Rally (PC) decompilation

Both milestones are measured in bytes of the game's own functions in BRGlide.dll: the hand-written target (in-scope EXE game code is separately complete). The rest of the DLL's code section is itemised below.

<!-- PROGRESS-DETAIL:BEGIN: generated by tools/brally/progressbar.py; do not edit by hand -->

What the bars measure. Both bars count the game's own functions in BRGlide.dll: the code that has to be written by hand. M1 has complete. M2 trails it by 90 functions (96,379 B) that are certified to behave exactly like the original but do not yet compile to identical bytes.

The rest of the DLL. Its code section is 480,853 B; the bars leave out 30,204 B of it, all of which the finished DLL still contains but none of which is hand-written:

Bytes	What it is	Where it comes from
20,151	padding and jump tables between functions	emitted by the compiler with the functions
7,975	import stubs and C++ exception-handling glue	generated by the compiler and linker
2,078	2 functions the retail game never runs	written, but left out of the count (config/brally/excluded.csv)

By binary: the three EXEs are complete at both milestones (their game code is fully byte-exact; the static CRT filling out each image is reproduced by linking, not decompiled, and is out of scope). All remaining work is in BRGlide.dll.

<!-- PROGRESS-DETAIL:END -->

Query the tree. Do not trust a number in this file.

.venv/bin/python tools/brally/refcheck.py     # corpus must be Glide-keyed
.venv/bin/python tools/brally/total.py        # byte-exact functions and bytes, all lanes
.venv/bin/python tools/brally/tiers.py        # T1/T2/T3/T4 of the C target (bytes, not just fns)
.venv/bin/python tools/brally/image_build.py  # M2 gate: assembled DLL vs original; must be 0 differing bytes AND 0 refslot findings
.venv/bin/python tools/brally/image_build_t3.py  # M1 gate: T3+T4 all compile & place; only T3 bodies differ
.venv/bin/python tools/brally/brbox_diff.py --all  # M1 behaviour gate: T3 image vs original, every script, every frame
.venv/bin/python tools/brally/fileaudit.py    # WHAT IT DOES, filing, T3 tags

image_build.py is the Milestone-2 (byte-exact) gate; image_build_t3.py is the Milestone-1 (contract-valid) one: it compiles every T3-certified function as well and proves the whole corpus builds and places, emitting BRGlide.T3.dll. Its T3 bodies differ in bytes by design, but it is a working drop-in: it runs the retail game (tested in a Win98 VM under 86Box) and behaves identically to the original on every scripted session (below).

T1 = draft only; T2 = in the tree, not done; T3 = certified complete, not byte-exact (tools/brally/t3.py --qualify); T4 = bytes diff clean.

How T3 is verified

"Not byte-exact" must still mean "does exactly what the original does". Two oracles run the original game headless (tools/brally/brbox.py: the retail BRGlide.dll under Unicorn, driven by input scripts in tools/brally/brbox_scripts/: boot, menus, quick race to the finish, time attack and saves, championship and season save/load, options and video modes, cheats and credits, a force-feedback wheel, CD music, and two-machine DirectPlay races with join and dropout):

• A5: per function (tools/brally/t3live.py, ledger config/brally/t3_live.csv): at real calls in the running game, the original body and the T3 body run from the identical captured state; memory, imports, registers, x87 state and live return values must agree. Unreached functions are UNCOVERED, never passed.
• A7: whole image (tools/brally/brbox_diff.py --all, ledger config/brally/whole_image.csv): the assembled BRGlide.T3.dll and the original run every script side by side and must agree on every frame: every Glide call and its arguments, the whole data area, and every network packet (both machines of a network session run the image under test). Currently 26/26 scripts identical.

A7 exists because A5 alone was not enough: the whole-image run found some 25 real transcription bugs (inverted branches, swapped or wrong arguments, off-by-one indexing, x87 rounding points, and image-builder relocation errors) in functions A5 had certified. t3.py --qualify requires both, and A7 is never superseded. Bytes the original itself reads without ever writing (stale stack) are listed with their evidence in config/brally/ub_scrub.csv and neutralised on both sides. Function counts overstate progress: remaining functions are several times larger than matched ones. Quote bytes with their denominator (the hand-written target shown in the bars, or BRGlide .text at 480,853 B: say which).

In-scope EXE game code (BRally.exe, BossRally.exe, SetVideo.exe) is complete; what remains in those images is statically-linked CRT, reproduced by linking. C++ EH functions are a separate lane (tools/brally/cpp_sweep.py).

A byte-exact session picks targets with python3 tools/brally/t4lane.py --claim (Pool B). Procedure: docs/brally/MATCHING.md.

The image gate (tools/brally/image_build.py) is the deliverable check a per-function diff cannot perform: it lays every claim at the address it claims, refuses overlaps, fills unmatched ranges from the original, and diffs the image.

Keeping it that way

A function is not done until it says what it does and lives in its module. tools/brally/precommit_rule6.py refuses a commit that adds an @implements without a WHAT IT DOES: comment, creates a sliceN_MM.c, or adds a new VA to an existing address batch. tools/brally/fileaudit.py is a ratchet across all three lanes (undescribed 0, batches 58, stranded 11) and fails on a bad @t3 tag. Moving byte-exact code can change its codegen: after a refile, sweep both files and keep the move only if nothing regressed.

Architecture

Every top-level folder is split by game (brally, tgrally); ports/ is derived platform code, not byte-matched.

src/brally/                  the Boss Rally decomp: core/ (game logic), exe/ (the
                             three Win9x executables), include/ (byte-matched)
src/tgrally/                 the Top Gear Rally decomp (IDO 5.3, MIPS)
config/{brally,tgrally}/     function maps, globals, ledgers, worklists
tools/brally/                matching pipeline, oracles, generators
tools/tgrally/               the N64 lane's tools; the soundtrack tools
tools/common/                git hooks, provenance check
tools/toolchains/            MSVC 5.0, Wine, IDO 5.3 (staged by setup.sh)
docs/{brally,tgrally}/       procedure, rules, and everything the work learned
ports/brally/                the native 64-bit port: a retyped fork of the core
                             plus a cross-platform layer (macOS, Windows, Linux)
ports/tgrally/               the native Top Gear Rally port
ports/common/                Remastered assets (recipes tracked, binaries not)
reference/                   the original disc, ROM, compilers and corpora (not tracked)
build/                       everything generated, per game and platform:
                             build/brally/{win32,null-soft,macos-metal,...},
                             build/tgrally/{n64,null-null,macos-metal,...}

@implements <addr> is a hard claim: MSVC 5.0 emits those original bytes. The engine is dispatch-driven: only ~13% is reachable by following call from the entry point, so functions are taken leaves-first.

Further reading: docs/brally/ARCHITECTURE.md, docs/brally/MATCHING.md, docs/brally/VC5-IDIOMS.md, ports/README.md.

Building & Setup

• ./setup.sh: stages the matching build entirely inside the repo (nothing installed on the host). Downloads a pinned Wine build, copies MSVC 5.0 and its C runtime source out of a VC++ 5.0 disc image, and extracts the game binaries and original function bytes from the retail disc. Needs (you supply; none tracked in git): reference/msvc/VCPP-5.00.iso, the Boss Rally disc (reference/brally/BossRally.BIN + .cue), optionally the Top Gear Rally ROM, plus Rosetta 2 on Apple Silicon.

• sh tools/brally/build_match.sh: compiles with the original compiler and diffs; each function reports MATCH or DIFF with the first divergence. tools/brally/pe_patch.py patches matches back into the DLL for drop-in testing.

• The playable builds are the Boss Rally native port (macOS, Windows, Linux, headless; its scenario suite is ports/brally/tools/suite.sh) and Top Gear Rally Remastered (ports/remastered), which runs it behind Top Gear Rally's menus on macOS, Windows, Linux and the iPhone.

Reference data (you supply; none tracked in git)

These are the exact dumps the match counts were produced against: setup.sh checks the MD5s and warns if a different image is in reference/. Without them the tree still builds and the suites that need retail data skip with a reason, but the matching pipeline cannot run and no byte-exact claim can be verified.

reference/msvc/VCPP-5.00.iso                  Visual C++ 5.0 disc image
reference/brally/BossRally.BIN                retail PC disc
    MD5  31c64f9b1e09788c2dfc384b44af8f6c     616,572,096 bytes (MODE1/2352)
reference/brally/BossRally.cue                cue sheet (data + 12 audio tracks)
    MD5  a48a4a5860558177c3041afee57e03c9     622 bytes

Rosetta 2 is required on Apple Silicon (the Wine build is x86_64). setup.sh pulls BRD3D.dll, BRGlide.dll and the other game binaries out of the BIN into reference/brally/orig/: do not copy them by hand. Assets are extracted from the same images and never committed or redistributed; without them the tree still builds and the suites that need retail data skip with a reason.

Top Gear Rally (N64) decompilation

A second, separate decompilation lives in src/tgrally/ (tools in tools/tgrally/, ledgers in config/tgrally/): Top Gear Rally (N64, 1997), matched byte for byte against the retail ROM under SGI's IDO 5.3 compiler. It keeps its own sources, headers, symbols and tools, so nothing in it touches the PC work. It follows the same T1-T4 tiers and the same two milestones. M1 counts functions certified as behaving exactly like the original (T3) plus byte-exact ones (T4). M2 counts byte-exact functions only.

The denominator is the ROM's game-code functions. Nintendo's system library and the compression library are fenced out as each of their functions is identified, the way the PC lane excludes Microsoft's C runtime, so the count shrinks as more library code is recognised.

.venv/bin/python tools/tgrally/n64tiers.py     # tiers and milestones, rebuilt fresh
.venv/bin/python tools/tgrally/n64build.py     # compile src/tgrally and grade every function
tools/tgrally/n64ghidra.sh                     # machine drafts (T1) for every ROM function

A byte-exact grade is strict: every instruction must match, and every address a function uses must point where the ROM's does. Strings, float constants and jump tables are checked by their contents in the ROM.

How N64 T3 is verified

The same two oracles as the PC lane, over the original ROM: tools/tgrally/n64box.py runs the retail cartridge headless under Unicorn (MIPS), with the operating system, the controllers, a Controller Pak and a Rumble Pak modelled and everything else executed for real. A5 (tools/tgrally/n64t3.py, ledger config/tgrally/t3_live.csv) replays each T3 body against the original at real calls; A7 (n64t3.py --image, ledger config/tgrally/whole_image.csv) runs the whole image with every T3 body placed and must agree on every frame: every display list and audio task, and the game's RAM.

Both are only as good as the play they see, so the 60 input scripts in tools/tgrally/n64box_scripts/ cover the game broadly: all ten tracks (mirrors included) across all five weathers, all 13 cars and every setup option, one and two players, arcade, time attack, practice and championship (one race driven all three laps to the flag, through the instant replay and results), the camera views, all five controller layouts, the cheat codes, the credits demos, the paint shop and the Controller and Rumble Paks. Most are written by tools/tgrally/n64drive.py, which plays the ROM toward a plan: menu rows, cheats, cars, then a race on the computer drivers' own racing line, and records the pad as a script that replays identically. tools/tgrally/n64probe.py --cover reports which functions the scripts reach: 373 of the 439 byte-exact functions, and every T3.

.venv/bin/python tools/tgrally/n64probe.py SCRIPT       # what a script does: screens, rows, race setup
.venv/bin/python tools/tgrally/n64probe.py --cover      # functions the suite reaches, by tier
.venv/bin/python tools/tgrally/n64drive.py list         # the generated plans
.venv/bin/python tools/tgrally/n64drive.py verify --all # every generated script replays its recording

Reference ROM (you supply; not tracked in git)

reference/tgrally/Top Gear Rally (USA).z64    Top Gear Rally ROM (optional; the Mac app needs it)
    MD5  6f7030284b6bc84a49e07da864526b52     8,388,608 bytes (big-endian, NGRE)

setup.sh treats it as optional because the PC decompilation does not need it; the N64 decompilation is graded against it, and the Mac app reads its music modules for the N64 soundtrack.

Native ports

The decompiled source isn't just for study. It also builds three games that run natively on modern computers, with no emulator:

Game	What it is	Runs on
Boss Rally	The 1999 PC game, as it shipped. 4:3 picture, the original music and menus.	macOS, Windows, Linux
Top Gear Rally	The 1997 N64 game, as it shipped.	macOS, Windows, Linux
Top Gear Rally Remastered	The best of both: Top Gear Rally's menus, with Boss Rally's engine driving the races. Adds widescreen, a choice of PC or N64 music, an FPS counter, a choice of either game's menus, two-player split screen and each player's controls.	macOS, Windows, iPhone and iPad

The first two are faithful ports: they play just like the originals. They add only what a computer needs: full screen (Control-Command-F on a Mac, Alt+Enter on Windows and Linux) and, in Top Gear Rally, Options > Keys and Pad for the keyboard and gamepad, and Exit Game. Remastered is where the improvements live.

They run on macOS 12 or later (Apple silicon and Intel), Windows 10 or later (64-bit, with a Vulkan driver or OpenGL 3.3), x86-64 Linux with glibc 2.31 or later (the same drivers; new in 0.99, not yet run on a real Linux machine) and, for Remastered, iOS 16 or later.

Building a game with Rally Builder

No game data ships with this project, so you need your own copy of the game. Rally Builder turns that copy into a game you can play.

1. Download Rally Builder for macOS, Windows or Linux from Releases and open it.

2. Pick a game: Boss Rally, Top Gear Rally or Remastered.

3. On a Mac with Remastered, pick the Mac or an iPhone.

4. Point it at your copy of the game:

   • Boss Rally: the retail CD, as a BIN/CUE.
   • Top Gear Rally: the Top Gear Rally (USA) ROM.
   • Remastered: both.

   The builder checks each file's MD5 and builds only from a correct copy.

5. Pick a folder and press build. You get the app (or an iPhone .ipa, or a Windows or Linux folder) ready to play. Your original files are no longer needed.

Building from source

For developers: the commands to build, package and test each port are in ports/README.md, and the builder itself is in builder/README.md. Each port's design is in ports/brally/PORTABLE-CORE.md, ports/tgrally/PORT.md and ports/remastered/README.md.