emit or insert a manifest file

[Europia79]

heya @Alcaro I saw the -m option listed in the help, but I didn't see any documentation for it ?

Like, what are some use-case scenarios ? ...And how would one use this option ?

[Alcaro]

The BPS manifest is an extra file embedded into the patch.

The intended usecase a specification of how the SNES ROM file maps to the SNES address space.

In practice, pretty much nobody uses it. Only a few emulators support custom mappers (bsnes and derivatives, and sd2snes (or whatever it's called now) - and they don't even use the same format), which means every ROM hacker needs to use one of the standard mappers (making bsnes-only romhacks tends to be impopular), which means the manifest is unnecessary. And for those few people who want to make bsnes-only ROMs, the most popular solution is simply including the manifest as a normal file in the zip.

[Europia79]

Sorry, i was reading this...

Checksum information appears at the bottom of the file. The idea is to allow a
patcher to calculate this information as the patch is being produced. The source
checksum verifies that the input file is correct, and the target checksum
verifies that the patch has been applied successfully. Finally, the patch itself
has a checksum. The patch checksum is the checksum of every byte before it. In
other words, it does not include the last four bytes for obvious reasons. This
ensures the patch itself has not been corrupted.

Note that checksums are stored in CRC32 format. The intention of checksums is to
verify against corruption and mistakenly incorrect files. The idea was to keep
the file format simple, so cryptographically secure hashes were not used here.
If security is a grave concern, SHA256 or better hashes can be stored in the
manifest data. Otherwise, beat is not the right file format for such uses.

And I was under the impression that the manifest could attach additional metadata information as it suggests ?

If so, I might want to do this: Just as a simple example, how would I attach Name, MD5 & SHA1 checksums to a "manifest" file ?

My particular use-case: I want to create a pair of scripts that will create & apply tons of patches for an entire console. There are probably a variety of algorithms that I could use to match the patch with the correct parent rom and apply the patch: One way would be to attach extra metadata information about the parent rom and use that information to find the correct file to patch.

Alternatively, I do see that .BPS does store the CRC-32 checksum at the end of the file, however, not all systems (like mine unfortunately) have the crc32 command. And ideally, I would want my script to have as few dependencies as possible for ease of use.

So, we would either have to expose the flips crc32 function via CLI or I would simply have to use a brute force technique where I try to apply the patch to every single ROM and then check to see if the romhack file was created in order to detect success ? ...It sounds really bad, but with my naming scheme, I could at least save the last successful Parent ROM for the next patch in the loop. So, for example, I have 337 Super Mario World romhacks, but the script only has to find the Parent ROM once: For the 1st SMW romhack. Then, for the remaining 336 SMW romhacks, it will already know the correct ROM to patch ?

Whereas, I'm thinking that I could possibly use the manifest to attach metadata about the Parent ROM to make the algorithm even faster ? ...Like, maybe store the No-intro & GoodSNES name(s) and see if they exist ? ...If not, create a Map for the users romset and Map the MD5 to the filename. Then just use the MD5 from the manifest to lookup the correct filename ?

[Alcaro]

The manifest is just an arbitrary byte stream, you can put whatever you want there.

However, there is no specification for how you can attach Name, MD5 & SHA1 checksums to a manifest file, so no matter how you format your checksums, no BPS-related tool I'm aware of will treat the manifest as anything more than an attached byte stream.

For this usecase, Floating IPS in GUI mode has a feature to remember used input ROMs and automatically pick the correct one, but command line mode does not. I've considered adding it, but I'm lazy.

Using the manifest to identify the ROM is a funny idea, but since it won't be compatible with any patch you didn't create yourself, I wouldn't recommend it. Better use the crc32 that already exists in the patch.

If you don't want to hardcode a mapping of checksum -> ROM name in your tool (it's doable, the No-Intro sets are finite size), you can instead chain together a crc32 calculator from other tools, for example cat supermarioworld.sfc | gzip -1 -c | tail -c8 | hexdump -n4 -e '"%.8x"'.

Or if you rewrite your tool to Python instead of sh, you have a crc32 function in the standard library (zlib or binascii modules).