Canonical: https://rom-weaver.com/docs/cheat-database # Cheat database reference Supported cheat-code systems, match types, and ROM patch export limits in rom-weaver, with database sources and local storage behavior. ## Table of contents - [Supported systems](<#supported-systems>) - [Delivery classes](<#delivery-classes>) - [Match classes](<#match-classes>) - [Patch export](<#patch-export>) - [Data source](<#data-source>) - [CLI database directory](<#cli-database-directory>) - [Storage and network behavior](<#storage-and-network-behavior>) - [Shard file](<#shard-file>) - [Preserved source fields](<#preserved-source-fields>) - [Weaves](<#weaves>) ## Supported systems | Database system | Rust decoders | | --- | --- | | Nintendo Entertainment System | Game Genie, Pro Action Replay, Pro Action Rocky | | Super Nintendo Entertainment System | Game Genie, Pro Action Replay, Gold Finger | | Sega Genesis / Mega Drive | Game Genie, Pro Action Replay | | Sega 32X | Game Genie, Pro Action Replay | | Sega Master System | Game Genie, Pro Action Replay | | Sega Game Gear | Game Genie, Pro Action Replay | | Game Boy | Game Genie, GameShark | | Game Boy Color | Game Genie, GameShark | | Game Boy Advance | Xploder, GameShark v1/v2, Action Replay v3 | rom-weaver does not offer database systems outside this table. The database stores these explicit code kinds: `game-genie`, `pro-action-replay`, `gold-finger`, `xploder`, `pro-action-rocky`, `game-shark-v1`, `game-shark-v1-raw`, `action-replay-v3`, and `action-replay-v3-raw`. Generic GBA GameShark and Action Replay file names remain `xploder` because the device name does not identify the encryption version. Gold Finger codes can write one to three consecutive SNES ROM bytes. `XX` marks an unused trailing byte. SRAM Gold Finger codes are unsupported. The address is a ROM offset without a 512-byte copier header. The GBA versioned kinds preserve the complete code block. The non-`raw` kinds decrypt their device format before classification. The `raw` kinds accept the corresponding decrypted form. Only writes that resolve to cartridge ROM can be baked. Runtime-memory writes, conditionals, and device operations without a ROM write remain unsupported. ## Delivery classes | Class | Meaning | Output | | --- | --- | --- | | ROM cheat | Every subcode decodes to a cartridge ROM address | Ordered ROM write step | | Unsupported | The code cannot bake into the ROM | Disabled, with a reason | An unsupported row shows its reason and cannot be selected. Reasons include: the code targets runtime memory, some of its linked subcodes target runtime memory, the entry needs a parameter value, or the entry is a structured RetroArch memory entry rather than a native code. ## Match classes | Match | Meaning | | --- | --- | | Exact | A known checksum matched a canonical release record and its cheat set. | | Title | The normalized file name matched, but the ROM checksum did not match. | | Manual | The user selected a game record. | | None | rom-weaver found no automatic game match. | Title and manual matches can target another region or revision. ## Patch export The browser's **Save as patch** action exports one supported ROM cheat. Its automatic format depends on the ROM size: | ROM size | Patch format | | --- | --- | | Less than 16 MiB | IPS | | 16 MiB through 107,374,182 bytes | BPS | | More than 107,374,182 bytes | xdelta | The 107,374,182-byte cutoff is rom-weaver's creation policy, not a limit of the BPS format. BPS create holds the original and the patched ROM in memory together, so the pair can total at most 214,748,364 bytes. Procedure: [Save a ROM cheat as a patch](). ## Data source The shards derive from the `cht/` directories of `libretro/libretro-database` at the same pinned revision as the identify packs. The identify index (`index.json`, `sources.libretro.revision`) records that revision, and the Cheats section shows it. Source [libretro/libretro-database]() License CC-BY-SA-4.0 The generated shards are an adapted database under CC-BY-SA-4.0. rom-weaver's code license does not replace that data license. ShareAlike applies to redistributed adaptations of this database. The distribution includes the full license text and the source revision in the third-party notices. Game titles and release checksums come from the same Libretro DAT files that build the platform's identify pack, so a cheat match and an identify match agree on the ROM. Before packaging, the build removes structured RetroArch entries, empty or placeholder codes (`?`, or `XX` except in Game Genie codes on NES, Genesis, and 32X, where `X` is a code letter), and entries whose every subcode has a known runtime-memory address. Gold Finger `XX` data slots are unused bytes, not parameters. Encrypted and versioned GBA blocks remain intact for the Rust decoder. Mixed entries remain for the ROM-dependent decoder to classify; an entry remains unsupported if any subcode cannot bake. ## CLI database directory The CLI reads the same shards the webapp serves, from a directory on disk. | Path | Contents | | --- | --- | | `nintendo-nintendo-entertainment-system.json.br` | Nintendo Entertainment System shard. | | `nintendo-super-nintendo-entertainment-system.json.br` | Super Nintendo Entertainment System shard. | | `sega-mega-drive-genesis.json.br` | Sega Genesis / Mega Drive shard. | | `sega-master-system-mark-iii.json.br` | Sega Master System shard. | | `sega-game-gear.json.br` | Sega Game Gear shard. | | `sega-32x.json.br` | Sega 32X shard. | | `nintendo-game-boy.json.br` | Game Boy shard. | | `nintendo-game-boy-color.json.br` | Game Boy Color shard. | | `nintendo-game-boy-advance.json.br` | Game Boy Advance shard. | | `manifest.json` | Source name, source revision, source URL, and license. Optional. | There is no shard for PlayStation (`psx`) or SG-1000 (`sg1000`). Those systems decode codes but have no database, so `cheat list` and database lookups for them fail with exit code 1. Each shard may also be a plain `.json`, or carry the `cheats-` prefix the repository's own data directory uses. When several forms are present the CLI reads the `.json.br` copy. The [CLI reference]() lists directory overrides and discovery order. `ROM_WEAVER_DATA_DIR` moves the user data base. `rom-weaver setup` installs `/full-v1/cheats` from the identify archive. Missing-shard errors name the file and installation command. [ROM identify data]() documents how to build the identify packs and cheat shards from their pinned sources. ## Storage and network behavior Each shard is one identify data asset (`assets/identify-cheats-.json`) listed in the identify index with its size and SHA-256. The app loads only the detected or selected platform. A shard belongs to the same pack group as its platform's identify pack. The background warm-up downloads the default group, the Settings page installs optional groups, and the CLI `identify database install-group` installs the same shards natively. An uncached shard is fetched on demand when the Cheats section opens. All nine shards are in the default group. Together they add about 2 MB to the default group download and about 17 MB of decoded JSON to the browser's cache storage. The service worker verifies each shard's SHA-256 before it stores it, and the parsing worker verifies it again before use. A shard that fails either check reports the database as unavailable. A dedicated browser worker parses each shard and restores the fields the file leaves out (see [Shard file](<#shard-file>)). The initial JavaScript bundle does not contain the database. The hosted app requests shards only from its own origin. It makes no runtime request to Libretro. ## Shard file A shard is one JSON document: `schemaVersion` (currently `2`), `system`, `sourceRevision`, and `games`. Each game carries its `id`, `title`, `normalizedTitle`, `regions`, `revisions`, `checksums`, and `cheats`. A shard does not record which Libretro `.cht` file a cheat came from. The file stores each cheat record without the values a reader derives. The CLI and the browser worker restore them the same way: | Record field | Source in the file | | --- | --- | | `system` | the shard's `system` | | `gameId` | the game's `id` | | `sourceRevision` | the shard's `sourceRevision` | | `sourceFile` | always `libretro-database` | | `codeKind` | stored when the Libretro file name names an unambiguous device or version; generic GBA Action Replay and GameShark files retain Xploder compatibility | | `description` | stored when the source record has a `desc` field, else `Cheat ` | | `rawFields.desc`, `rawFields.code` | `description` and `rawCode` | | `rawFields.enable` | stored only when it is not `false` | | `id` | `cheat_` plus the first 24 hex digits of SHA-256 over `system`, `gameId`, `codeKind`, and the raw fields without `enable`, as key-sorted JSON, joined by NUL bytes | Record IDs do not depend on the file layout, so a weave written against an earlier layout still names the same records. ## Preserved source fields Each imported record keeps the original code, every `cheatN_*` value, unknown fields, source index, and source revision. A source record without a `cheatN_enable` line reads as `enable = false`. rom-weaver does not synthesize RetroArch memory handlers. It only decodes the native code fields the source record already carries. ## Weaves A weave's optional top-level `cheats` array records a selection: each entry carries the record `id`, the `source` database and `revision`, the `description`, and a `code` snapshot with its optional `codeKind`. `weave create --cheat` and `patch apply --emit-weave` write the array. Applying the weave resolves each entry by `id` against the database at `--cheat-database`, and falls back to its `code` snapshot when the database is absent. An unresolvable entry fails the apply unless it is marked `optional`. For the field list, see [CLI reference](). For the CLI task, see [Bake cheat codes into a ROM](). For the browser task, see [Use cheats in the browser](). For the baking model, see [ROM cheats]().