A JSON database mapping Atari VCS (2600) ROM files to metadata, built for emulator developers. Given the bytes of a ROM file, the database tells you what it is, how to load it, and how well the dump is attested.
This is a metadata database. It contains no ROMs, and it never will. Please don't open issues asking where to find ROMs — your nearest search engine handles that question far better than we can.
One record per file, not per game — the same shape as No-Intro or TOSEC DATs. Three padding variants of Combat are three records. Every field is a fact about the bytes, the hardware, the physical cartridge, or the provenance of the dump; nothing points outward to external services, so the data doesn't rot.
The key fields:
| Field | Meaning |
|---|---|
sha1 |
The identity of the file. Unique per record; use it to join against No-Intro, TOSEC, MAME, and other preservation databases. |
md5, crc32, sha256 |
Additional hashes. MD5 is the join key for Stella's properties database; CRC32 matches classic DAT files. |
cartType |
How to load this file — values match Stella's Cartridge.Type (2K, 4K, F8, E0, DPC, …). |
tvFormat |
Color encoding and frame timing (NTSC, PAL, SECAM, NTSC50, PAL60, SECAM60). |
title, publisher, year, partNumber |
Release facts about the cartridge. |
verification |
How well the dump is attested: silicon > pcb > consensus > inferred > unverified, with provenance in verificationNote. |
size, layout, offset, length, fillByte |
The file's internal structure: exact, mirrored (a repeated unit), or padded (content plus fill). |
derivedFrom, derivation |
A mechanically verifiable link from a transformed file (trimmed/mirrored/padded) to the authoritative dump it was derived from. |
alternateReleases |
Other commercial releases of the identical bytes under a different label (e.g. Atari and Sears branding). |
notes |
The escape hatch for everything else. |
Two design points that surprise people:
- The database is authoritative, not advisory. There is no
AUTOcart type. If a file's SHA-1 is in here, itscartTypeis correct and heuristic detection can be skipped entirely. cartTypedescribes loading the file, not the silicon. A 2K program mirrored into a 4K file hascartType: "4K"— a plain 4K handler loads that file correctly. The mirroring is still recorded, inlayout.
size has no power-of-two constraint — Pitfall II is 10,495 bytes.
Anything that infers cart type from file size alone is wrong.
db.jsonis the database;metadata.schema.json(JSON Schema, draft 2020-12) describes and validates it.- Load the JSON, build whatever hash index you need in memory at load time. Deliberately, no prebuilt index files are shipped — indexes go stale silently; regenerating at load cannot.
- Look up files by
sha1(ormd5/crc32as a prefilter). On a hit, trust the record. On a miss, fall back to your own heuristics — a missing entry is always preferred over a wrong one.
Entries were assembled and cross-checked from, in various combinations:
- No-Intro DAT files and database exports
- Stella's properties database and
cartridge detection logic (the reference for
cartTypevalues) - MAME's a2600 software list
- BizHawk's game database
- TOSEC catalogs
- ROM Hunter's VCS collection catalogs and the Good2600 naming project
- Community knowledge from the Atari homebrew and preservation scenes, plus direct author attestation for some homebrew entries
Where sources disagreed, neither side was trusted blindly: conflicts were flagged and resolved by evidence, and unresolved doubts are noted in the records themselves.
Corrections, updates, and pull requests are welcome — especially hardware-verified cart types, dump provenance, part numbers, and release facts. A claim is easiest to accept when it comes with evidence: what the fix is, and how you know.
Commit messages follow Conventional Commits
(fix:, feat:, docs:, …). Leave out the body and footers whenever
the description alone is enough.
This work is released into the public domain under the Unlicense. Use it for anything.