ID Strategy - cressie176/Load64 GitHub Wiki

There is no authoritative, centralised database for Commodore 64 games. The major community sites — MobyGames, Lemon64, GameBase64, CSDb — each maintain their own catalogues independently, with no shared identifiers between them. The same game may appear under different titles across databases, use different spellings, or be absent from some entirely.

Even within a single database, game identity is ambiguous:

• Identical titles, different games: Many titles were reused. "Jet" on one label is a different product from "Jet" on another.
• Variants of the same game: A single title may exist as an original release, a cracked version, a trained version with cheats, a cartridge port, a tape release, a disk release, a compilation appearance, and regional variants with different language or copyright screens. These are meaningfully different artefacts.
• No stable cross-site ID: A game's identifier on MobyGames has no relationship to its identifier on Lemon64 or GameBase64. Linking them requires manual curation.

Because of this fragmentation, no metadata source can reliably be used as the primary key for a game. The only thing that uniquely and unambiguously identifies a specific game artefact is the ROM itself. LoadC64 therefore builds identity upward from the ROM content, using cryptographic hashes as its foundation.

LoadC64 separates game identity into four layers.

ROM files
   │  sha-256 each file
   ▼
ROM Hash              one per ROM file
   │  sort + concatenate + sha-256
   ▼
ROMSet ID (rsid)      one per ROM collection
   │  catalogue lookup
   ▼
LoadC64 Global ID     one per abstract game in the LoadC64 Catalogue

LoadC64 Local ID      one per library entry, allocated on import

Each ROM file is hashed individually using SHA-256. Identity is derived entirely from file content. A multi-disk game produces one ROM Hash per file.

A ROMSet is the exact collection of ROM files required to run a game. The rsid is a deterministic identifier derived from that collection.

1. Compute sha256 for each ROM file → [hash_1, hash_2, ...]
2. Sort the hashes lexicographically
3. Concatenate the sorted hashes (no separator)
4. Compute sha256 of the result → rsid

Sorting before hashing ensures the result is stable regardless of import order. Two users who import the same disks in different order produce the same rsid.

The LoadC64 Global ID is a permanent, globally unique identifier for an abstract game in the LoadC64 Catalogue. It is assigned and curated by the LoadC64 Catalogue — not generated locally.

When a game is imported, LoadC64 looks up the rsid in the LoadC64 Catalogue. If the ROMSet is recognised, the corresponding LoadC64 Global ID is returned. If the rsid is not recognised, the game remains local-only with no LoadC64 Global ID.

Because the LoadC64 Global ID represents the abstract game rather than a specific ROM variant, many ROMSets may map to the same LoadC64 Global ID:

rsid for NTSC release   ─┐
rsid for PAL release    ─┼──►  LoadC64 Global ID
rsid for trained crack  ─┘

An rsid maps to at most one LoadC64 Global ID.

The LoadC64 Catalogue associates each LoadC64 Global ID with identifiers from third-party catalogues (GameBase64, MobyGames, CSDb, TOSEC). These are used to facilitate importing metadata and media. Third-party catalogue IDs are optional — not every game will have an entry in every catalogue.

The rsid is a 64-character hex string — precise and stable, but unwieldy for day-to-day use. The LoadC64 Local ID is a positive integer allocated on import, incrementing with each new game added to the library. It has no meaning outside the local system.

Game folders are named by combining the slug (derived from sort_title) with the first 8 characters of the rsid, separated by --:

<slug>--<short-rsid>/

For example:

last-ninja-the-1987--a3f9c2d1/

The short rsid provides sufficient uniqueness for a personal library while remaining readable. It is content-derived, so it is stable across systems for the same ROM collection.

The folder path (relative to the games directory) is stored in the database. LoadC64 uses this stored path to locate game assets. The folder name itself has no special meaning to LoadC64 after import — it is not parsed or validated at runtime.