ROM Setup

ROM Setup

Sightline ships no game assets and no ROM. Level data, models and textures are read out of your own ROM at run time; nothing ROM-derived is committed or distributed.

The supported dump

The native build and the matching build target the NTSC-U cartridge:

Region	USA / North America (ge007.u.z64)
Format	plain, uncompressed, big-endian .z64
Size	12 582 912 bytes (12 MiB)
SHA-1	ABE01E4AEB033B6C0836819F549C791B26CFDE83

The matching build also targets the JP and PAL dumps upstream supports; the native Windows launcher is documented against the US dump.

Where to put it

Either of these works. Both are ignored by Git, and the ROM must never be committed.

1. Copy the file to baserom.u.z64 in the repository root, or
2. leave it where it is and point SL_ROM at its full path:

$env:SL_ROM = "D:\Games\GoldenEye\baserom.u.z64"

play.ps1, test.ps1 and setup.ps1 all read SL_ROM first and fall back to baserom.u.z64. No rename is needed when you use SL_ROM.

If your dump came as an archive

If you have something like 007 - GoldenEye (USA).zip:

• Extract it first (right-click → Extract All, or Expand-Archive). Sightline does not read archives.
• The extracted file is typically 007 - GoldenEye (USA).z64. Copy it to <repo>\baserom.u.z64, or set SL_ROM to its full path.
• Windows Explorer hides known extensions by default, so a rename can silently produce baserom.u.z64.z64. Check with Get-ChildItem or dir in PowerShell, which shows the real name.

Byte-swapped dumps

If the extracted file is .n64 or .v64, it is byte-swapped. Convert it to a big-endian .z64 with a ROM tool (or re-dump) before use. Since v0.2.0 the game refuses a swapped file at start-up, before it boots, with the reason on the console ("the file does not start with the big-endian .z64 magic"). The header magic tells the formats apart:

Magic	Meaning
80 37 12 40	.z64, big-endian — correct
37 80 40 12	.v64, 16-bit byte-swapped
40 12 37 80	.n64, 32-bit word-swapped

Self-check in PowerShell

At start-up the game checks the size, the .z64 magic and a checksum of the audio microcode segment it reads out of the ROM; it does not hash the whole file. To confirm you have exactly the supported dump, check it yourself:

(Get-Item .\baserom.u.z64).Length                    # 12582912
(Get-FileHash .\baserom.u.z64 -Algorithm SHA1).Hash  # ABE01E4AEB033B6C0836819F549C791B26CFDE83

Size and hash must both match. A wrong hash with the right size usually means a byte-swapped or modified dump; a wrong size usually means an archive, a different region, or a file with a header added.

Optional inputs for COMMUNITY HD and XBLA

The ROM is the game. The COMMUNITY HD and XBLA presentations (Running the Game → Presentation) only replace artwork, and each comes from a different file. None of them is the ROM, and none of them is a substitute for it.

Input	Needed for	Identity
GoldenEye 007 (USA) N64 ROM — required	the game itself, and several preparation steps	the dump above
Community HD release — optional	the COMMUNITY HD texture pack	the GoldenEye 007 HD project's pinned release, downloaded on your machine from its maintainers by Get-Textures.cmd (release package) or prepare-textures.ps1 (source checkout), and checked against the size and SHA-256 in community-source.json
XBLA source archive — optional	the XBLA texture pack and world assets	user-supplied; Sightline does not provide, locate or download it

One XBLA archive is known to work with the current preparation tools:

file	GoldenEye_007_XBLA.7z
size	242343042 bytes
SHA-256	dfb7b35afd9767f671469e00cf34bb454b6acc3c2ddf93d4953bc056611f6eb2
SHA-1	1522e3d4f36d56f4d089f9c2fdebfb73b5ef2c9b

These are checksums of that archive file as a whole — not of anything inside it, and not of the N64 ROM. Renaming the file does not change them (a copy renamed to texsources\xbla-source.7z still matches); repacking the same content produces a different archive with different hashes, which may still work, because the tools read the archive's own index. A matching hash identifies the tested archive; it says nothing about where a copy came from. The preparation steps are in docs/xbla-setup.md.

What make verify-rom checks

The matching build's Makefile (Linux) has a stricter gate, and make matching runs it first and refuses to build on failure:

make verify-rom

It tests size, then the header magic, then the region byte at offset 0x3E (E = USA, P = Europe, J = Japan), then the SHA-1, and names the actual cause — so a byte-swapped dump is reported as byte-swapped rather than as a bare hash mismatch. Expected output for the US ROM:

size    12582912 bytes (12 MiB)
magic   0x80371240        (z64, big-endian)
region  country code 'E'  (USA / North America)
sha1    abe01e4aeb033b6c0836819f549c791b26cfde83

See docs/toolchain.md for the full description.

Related

• Getting Started
• Troubleshooting — the "no ROM at …" message and the hidden-extension trap