ROM Patch Formats Explained: IPS, BPS, UPS and xDelta

GAME TRANSLATE · ROM HACKING · PATCHING GUIDE

ROM Patch Formats Explained: IPS, BPS, UPS and xDelta

Why ROM hacks and fan translations are usually distributed as patch files, how the major formats differ, and which one makes sense for different kinds of retro-game projects.

By belfallen · Game Translate · about 11 minutes to read

Download a fan translation and you will usually receive a tiny file ending in .ips, .bps, .ups or .xdelta instead of a complete game.

That file is the patch.

It contains enough information to transform a specific original game file into the modified version created by the ROM hacker or translation team.

This distinction matters for preservation, distribution, troubleshooting and project maintenance. It is also why the exact original ROM matters: if the patch expects one revision and you feed it another, the result may be wrong—or the patcher may refuse to continue.

Why Are ROM Hacks Distributed as Patches?

Imagine an original 4 MB game and a translated 6 MB version.

Most of the data may still be identical: the original program, maps, battle systems, graphics, music and countless other bytes have not changed.

A patch format takes advantage of that.

Instead of distributing the entire modified game, the author distributes only the information needed to reproduce those changes.

This has several practical benefits:

• The download is often much smaller than the complete game.
• The original game data does not need to be bundled with the patch.
• Players can verify that they are starting from the intended revision.
• Project authors can release updated patches as bugs are fixed.

But not all patch formats solve the problem in the same way.

IPS: The Classic ROM Hacking Patch Format

IPS is one of the oldest and simplest patch formats associated with classic ROM hacking.

An IPS file begins with the identifier PATCH. Its records essentially say:

Go to this offset and write these bytes.

The format can also use simple run-length encoding for repeated bytes.

That simplicity is a major reason IPS remained popular for so long. It is easy to implement, easy to apply and supported by a huge number of ROM hacking tools.

The checksum issue is particularly important.

If you apply an IPS patch to the wrong revision of a game, the format itself does not guarantee that the patcher will stop you. The patch may write perfectly valid bytes to perfectly wrong locations.

BPS: Built-In Verification for Modern ROM Patching

BPS stands for Beat Patch System.

Instead of being only a list of raw writes, a BPS patch describes how to construct the target file using several kinds of operations: copying data from the source, inserting new data, and reusing data that has already been written to the target.

The most important difference for ordinary users is easier to understand:

That means a BPS patcher can verify three useful things:

• Is this the original ROM the patch was made for?
• Did the patch reconstruct the expected output?
• Is the patch file itself intact?

If the source ROM is wrong, a proper BPS patcher can reject it instead of silently creating a broken game.

For fan translations, where one Japanese game may have multiple revisions, headers or dumps circulating online, that is a very useful property.

Why BPS is often a good default

For cartridge-based systems, BPS offers a strong balance of compact patches, verification and broad support in modern ROM hacking tools.

It also avoids IPS’s 24-bit offset limitation, making it more comfortable for larger files and projects with substantial ROM expansion.

UPS: XOR-Based Patching with CRC32 Verification

UPS is another patch format created for binary differences between game files.

UPS uses an XOR-based delta representation and stores the input size, output size and three CRC32 values covering the input, output and patch.

Like BPS, this gives the patcher much more information for validation than classic IPS.

The XOR design also means the same difference data can be reversible: software that supports the behavior can use the patch relationship in either direction between the two matching files.

xDelta: General-Purpose Binary Deltas for Larger Files

xDelta is different in spirit from the classic ROM-specific formats.

xdelta3 is a general-purpose binary delta tool that encodes differences using the VCDIFF format. It can reconstruct a new file from an old source file and a delta.

Because it is designed for arbitrary binary files and supports large files, xDelta is commonly encountered in projects involving larger game images, disc-based games and other data where the simplicity of IPS is no longer ideal.

Conceptually, the workflow is still familiar:

The underlying format is more sophisticated, however. VCDIFF divides the delta into windows and encodes operations that add or copy data instead of storing only simple offset writes.

IPS vs BPS vs UPS vs xDelta

FORMAT	HOW IT WORKS	BUILT-IN VALIDATION	BEST FIT	MAIN CATCH
IPS	Offset + replacement data, optional RLE	No source/target checksum	Classic cartridge ROM hacks	Wrong ROM may still be patched; 16 MiB address limit
BPS	Source/target copy and insert operations	CRC32 for source, target and patch	Modern cartridge ROM hacks and translations	Requires a BPS-capable patcher
UPS	XOR-based binary delta	CRC32 for input, output and patch	ROM patches needing validation and size changes	Less commonly chosen than BPS in many current workflows
xDelta	VCDIFF differential encoding	Depends on implementation/options; modern xdelta3 adds strong verification features	Large files and disc images	More complex ecosystem and command-line/tool differences

Why Does the Correct Original ROM Matter?

Two files can have the same game title and still be different at the byte level.

Common causes include:

• Different game revisions
• Different regions
• Headered vs. unheadered dumps
• Bad dumps
• Previous patches
• ROM hacks already applied
• Different disc-image layouts

If even one structural difference shifts the data the patch expects, an offset-based patch can hit the wrong bytes.

This is why patch releases often specify hashes such as:

• CRC32 — short and convenient for identifying common ROM dumps.
• MD5 — older but still frequently seen in preservation and patching documentation.
• SHA-1 or stronger hashes — useful when you want a more robust file identity.

A hash is effectively a fingerprint for the file.

A Real Example: Bakumatsu Kourinden ONI

The completed English translation of Bakumatsu Kourinden ONI is distributed as an IPS patch.

The clean Japanese ROM used by the project has CRC32 1CF3C877. The translation expands the game from 4 MB to 6 MB so there is room for the larger English script, new text system and other translated assets.

That is still comfortably inside IPS’s 16 MiB addressing range.

So why use IPS rather than automatically converting everything to a newer format?

Because patch-format choice is not a competition where the newest format always wins.

• IPS is extremely well supported.
• The project fits within its technical limits.
• The required clean ROM checksum can be documented clearly.
• The output can be verified during the project’s own build and release process.

For this particular release, IPS is simple and sufficient.

What about Super Robot Wars R?

The same release principle applies to Super Robot Wars R on Game Boy Advance: the patch package should identify the exact clean Japanese source expected by the translation and provide enough information for users to verify it before applying anything.

The patch format may differ from project to project, but the rule should not:

Which ROM Patch Format Should You Use?

If you are creating a new project, there is no single answer for every console and every game.

IF YOUR PROJECT…	GOOD STARTING POINT
Is a small or medium classic cartridge ROM and compatibility is your priority	IPS can still be perfectly adequate
Is a modern cartridge-ROM translation and you want source/target verification	BPS is often an excellent default
Already uses a UPS-based toolchain or benefits from its XOR/reversible model	UPS
Uses large binary files or disc images	xDelta is often worth considering

The most important factor is not the filename extension. It is whether the format works reliably with your game’s file size, your build pipeline, your intended audience and your verification strategy.

How Do You Apply a ROM Patch?

The exact program depends on the patch format, but the basic process is almost always the same.

1. Read the patch documentation. Confirm the required game region and revision.
2. Verify the original file. Compare its CRC32, SHA-1 or other published hash.
3. Keep the original file untouched. Patch a copy rather than your only backup.
4. Open the patcher. Select the original game and the patch.
5. Create the patched output.
6. Verify the result if the project publishes an output checksum.
7. Test the game. Boot it in your emulator or on your own compatible hardware setup.

This turns a vague instruction like “use a clean ROM” into something users can actually verify.

What About PPF and Other Patch Formats?

IPS, BPS, UPS and xDelta are not the only binary patch formats.

You may also encounter formats such as PPF, especially around optical-disc games, along with project-specific and platform-specific formats.

The important skill is not memorizing every extension. It is learning to check three things:

• What exact source file does the patch expect?
• Can the patcher verify that source?
• Can you verify the final output?

If you know those answers, most patching problems become much easier to diagnose.

Final Thoughts

Patch formats look like a small technical detail, but they sit at the final boundary between a ROM hacking project and the people trying to use it.

IPS is simple and battle-tested. BPS adds strong built-in verification and a more sophisticated delta model. UPS uses a compact XOR-based approach with CRC32 validation. xDelta brings general-purpose differential compression to much larger files.

For players, the lesson is simple:

For patch authors, the lesson is just as important: make the correct source ROM unambiguous, publish hashes, verify your output, and choose a format that fits the project rather than following fashion.

In the next ROM Hacking article, we will look at the problem from the other side: why translation patches fail because of ROM revisions, headers and checksums—and how to diagnose them.