BPS is the format I point people to when a hack author wants the tool to reject a bad dump instead of pretending the apply worked. The file opens with the four characters BPS1. After that come the source size, the target size, a metadata size, the metadata, then an action stream. Lengths use a variable-length integer, so there is no 16 MiB ceiling the way IPS has. The last twelve bytes are three little-endian CRC32 values: source, target, and the patch file itself. byuu released that layout as public domain.
The actions are not a list of offsets. SourceRead copies the next bytes from the input at the output cursor. TargetRead inserts bytes stored in the patch. SourceCopy and TargetCopy replay an earlier span. The result is a program that rebuilds the output byte by byte. Floating IPS, by Alcaro, is the desktop program most SNES authors use to write these files. Its readme says the BPS files it writes are smaller than those from any other tool it compared, and the same program still writes IPS when an older project needs it.
In the browser module the order of checks is fixed. First the patch CRC is tested. A truncated download fails here with patch checksum mismatch, before any ROM is judged. Next the source CRC is tested. A headered SNES dump, a European revision, or a file someone already patched will fail with source ROM checksum mismatch. After the actions run, the output CRC is tested. Target ROM checksum mismatch means the input bytes were not the file the actions expected, even if the early source check was skipped or the ROM was altered in memory. I keep those three sentences apart because each one points at a different file.
SNES and GBA hacks moved to BPS for that reason, and a lot of N64 projects did too. If your file is .bps, stay on this page and use the patcher on the home page. If the author shipped .ups, the UPS guide explains the reversible XOR layout. If the error text is the secondary decompressor line, you do not have a BPS problem. That line belongs to xdelta.
