Cheat database reference

Supported cheat-code systems, match types, and ROM patch export limits in rom-weaver, with database sources and local storage behavior.

Supported systems

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

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

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:

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.

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 <slug>.json, or carry the cheats-<slug> 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 <identify database directory>/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-<platform slug>.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). 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 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.