N64 dumps circulate in three interleavings of the same cartridge. A .z64 file is big-endian, the order most modern hack readmes demand. A .v64 file is byte-swapped, the order early Doctor V64 units wrote. A .n64 file is little-endian. The game can be identical and the hash will not be, because the bytes really are in a different order. Converting is a lossless shuffle, and it still produces a new checksum. If a BPS was built on a .z64, feeding it a .v64 fails the source check even though a byte-swap tool would call them the same game.
Super Mario 64 US is the dump I see most often. The SHA-1 I record for that big-endian file is 9bef1128717f958171a4afac3ed78ee2bb4e86ce. The US edition of Usamune uses this Mario 64 base; Smash Remix instead uses Super Smash Bros., and the Mario 64 page repeats the hash so the number is not only here. AKI wrestling hacks are also N64 and were distributed through a Rom Patcher JS page that the author later archived. APS patches exist beside BPS. The N64 APS magic is APS10, which is not the GBA APS1 file.
Some hacks mention the Expansion Pak. That is a console memory requirement for the patched game, not a flag inside the patch format. The browser does not insert an Expansion Pak. Your emulator does, after the file is built. I would rather say that plainly than imply the patcher toggles hardware. Byte order comes first, then the patch, then the emulator setting the readme names.
If the patch extension is .xdelta, use the xdelta guide as well, because a few N64 projects left BPS. If the error is a source checksum, compare the required game, region, revision, and byte order before converting anything. Related pages: Mario 64, Smash Remix, Usamune, AKI, and the BPS format page.
