Retool Shapes No-Intro and Redump DATs Into Clean, Custom ROM Sets

There is a specific, familiar frustration that arrives the moment you try to load a complete No-Intro or Redump DAT into your ROM manager: the entry count. A single platform catalog will list every regional press, every revision letter, every prototype, demo, and alternate-language variant that has ever been documented. That comprehensiveness is the point. These catalogs exist to preserve the full record of what was released, and they do it with rigorous, checksum-verified accuracy. For a long-term archive, that's exactly what you want. For a 512 GB microSD card going into a Steam Deck, it's a problem.

This is where Retool enters the workflow. Built by the developer known as unexpectedpanda and available at github.com/unexpectedpanda/retool, Retool is a cross-platform filter utility that sits between the canonical DAT and your ROM manager. It does not touch your ROM files directly. Instead, it takes the full No-Intro or Redump DAT as input and outputs a trimmed, customized DAT based on the rules you define: preferred regions, language priorities, revision handling, and exclusion lists for categories you don't want. Feed that trimmed DAT into RomVault, ClrMamePro, or IGI-R, and your manager will only build, verify, or import the variants you've actually chosen. The original catalog stays intact. Your playable set stays compact.

Why canonical DATs grow so large

No-Intro and Redump are not trying to give you a convenient game library. They are trying to document every known dump of every known release. For a game like Super Mario Bros., that means the US cartridge, the European cartridge, the Japanese cartridge, rev 1 of the US cart, rev 2, a later re-release with a different board revision, and so on. On a disc-based system cataloged by Redump, a single title can have region-specific pressings across six or more territories, each one a separate entry with its own checksum. Multiply that across a full platform catalog and a "complete" set becomes less a game library and more a research database.

For preservation, that's correct behavior. For players, it creates noise: scrolling past four versions of the same game in a frontend, managing storage that inflates to multiples of what any one person could actually play, and navigating ROM managers that have to reconcile hundreds of extra entries. Retool's central promise is that you can have the clean provenance of a DAT-managed set without carrying all that weight onto a device with real storage constraints.

Setting up Retool

Retool runs on Windows, macOS, and Linux. If you're pulling from the project's releases page you can grab a prebuilt binary for your OS; if you prefer to run from source, Python 3.10 or later is the only dependency. Either way, the setup is straightforward.

Before launching Retool, download the latest DAT files for your target platform from No-Intro or Redump directly. Archive these originals in a dedicated folder and do not alter them. They are your provenance anchor: everything Retool produces is traceable back to them.

Building a preference profile

The core of a Retool session is the preference profile. This is where you translate your personal collecting philosophy into machine-readable rules:

• Region priority: Set the order in which Retool selects a title's preferred release. A typical handheld player might set USA first, Europe second, Japan third, and let Retool work down the list if a preferred region's release isn't in the collection.

• Language priority: If a game has no USA release but has an English-language European variant, language priority rules ensure Retool picks that over a Japanese-only press.

• 1G1R policy: This is the big one. One Game, One ROM means Retool keeps a single representative entry per title, dropping all the regional clones once the parent has been selected. On a platform like the Game Boy Advance, where No-Intro can catalog several hundred entries across regions and revisions for a library of around 1,000 unique games, enabling 1G1R and preferring USA releases can reduce the working entry count by more than half, depending on how broadly the platform was released internationally.

• Revision handling: Within the preferred region, Retool can be told to keep only the latest revision of each title rather than every incremental update. Rev A, Rev B, and the original press collapse into a single entry.

Adding exclusions

Region and revision filtering handles the bulk of the reduction, but exclusion rules sharpen the output further. Retool supports regular expression-based exclusion, so you can strip out entries with tags like "Demo," "Beta," "Sample," "Prototype," "Hack," "Translation," or "Trainer" in the title. For a console-focused frontend this matters: demo discs and review builds inflate the entry count without adding to the playable library, and they can surface awkwardly in a metadata-matched frontend that isn't expecting them.

Applications and non-game software that appear in No-Intro catalogs for certain platforms can also be excluded here, keeping the output focused purely on playable titles.

Running Retool and importing the result

Once the profile is saved, running Retool against the source DAT produces a new, sanitized DAT file. This output is what you load into your ROM manager. In RomVault or ClrMamePro, replace the canonical DAT with the Retool-generated one and run the manager's verify or rebuild routine as normal. Because the trimmed DAT carries the same checksum data for the titles it includes, every ROM it matches is still fully verifiable against the original No-Intro or Redump standards. Nothing has been renamed by hand. Nothing has been guessed at. The provenance chain is clean.

Export and save your Retool profile alongside the original DAT. That combination, original DAT plus the profile used to trim it, is all a future researcher (or your future self) needs to reproduce exactly how the trimmed set was built and verify its relationship to the canonical catalog.

The Steam Deck scenario, spelled out

A 512 GB microSD is a realistic budget for a Steam Deck or Anbernic handheld player wanting broad multi-platform coverage. A full Redump set for a single sixth-generation disc-based console can run deep into that budget on its own, even before accounting for the other systems you want on the same card. Running Retool with USA-first region priority, latest-revision-only, and demos/betas excluded can pare a disc-based catalog down dramatically by eliminating redundant regional pressings that no single frontend session will ever surface. The files you're not storing are checksummed, documented, and recoverable later from an archive partner or a trusted mirror; they're not gone, just not on your device.

This is the argument Retool makes implicitly: that a well-configured DAT filter is not a lossy operation. It's a curatorial one. You know exactly what you kept and why.

Preservation discipline alongside convenience

Retool's own documentation is clear on this point: trimming for playability is entirely appropriate for personal use, but archival and institutional projects should maintain full canonical No-Intro and Redump outputs alongside any trimmed versions. If you're running a mirror, seeding a set, or contributing to a preservation effort, include the original DAT files and a changelog so downstream users can verify provenance. Checksums are non-negotiable in this workflow. The whole point of DAT-based management is that nothing is taken on faith.

Extending the workflow

For MiSTer FPGA users, Retool-generated DATs pair naturally with MiSTer Organize to produce a validated, core-friendly layout. Batocera and RetroPie setups benefit similarly: a trimmed DAT matched against platform-specific DAT packs produces a frontend-ready library without manual sorting. For longer-term archival work, the recommended posture is a two-tier setup: Retool-trimmed sets on devices, full Redump and No-Intro mirrors stored offline or with a trusted archival partner.

The Retool GitHub repository houses documentation, sample profiles, and the project's clone lists and metadata files in a companion repository. Clone lists are JSON files that define relationships between titles Retool wouldn't automatically connect through naming conventions alone, which is what gives Retool's 1G1R logic its precision advantage over the built-in parent/clone handling in most ROM managers. Whether you're curating a single platform or a multi-system cabinet, the DAT-in, DAT-out model means you can rebuild, re-filter, or re-verify any set at any time, with a transparent audit trail back to the source.