A new patching-fileformat

During my "quest" on patching VS/other-NES Games I've discovered that a hex-Editor is a good thing to have, but it can also be a huge drawback. During patch-development there's a lot of copy+paste compiled code in the hex-editor and manually adjusting a few bytes here and there. It could get extremly time consuming and you can easily screw things up by adjusting the wrong bytes by mistake etc. Sometimes I think I spent more time with the hex-editor instead of the assembler-patch code..

So I've invented a new patch-fileformat (for internal use at the moment, but perhaps others are interested)? The idea is to have a text-file containing all modifications in
cleartext, which is then parsed, and applied to the source-ROM.
This way, you can enter your modifications in this file and just run the parser (a .NET console application at the moment), and the patch gets applied in a second or so. If you screw things up, you can easily comment out your stuff and run the parser again, no need to hex-edit the file.
The parser uses this syntax:
c:\patch.exe <patch file> <Source ROM> <Destination ROM>
The original ROM is never touched, you always gets a new file.

Here's an extract how a patchfile could look like for my latest hack "VS Castlevania".


Currently, the parser only supports these two instructions ("poke" and "incbin") but more can (and probably will) be added.
Another advantage is documentation. It's alot easier to read later, what kind of modifications that has been done etc.

The fileformat is perhaps best suited during development. IPS-files are obviously alot smaller and probably better to distribute.

What do you think? Usefull or not?

I guess this is OK for when you're doing a few modifications, but those extensive hacks where a lot of data is shifted around would result in insanely large patch files.

Yes, but when there's alot of data to be patched (lots of new code etc.), it can be included with the "incbin" directive instead of using lots of "poke's". See my example.

Then the main drawback is that it requires multiple files for a patch...

Extensive hacks often move data from one address to another in a ROM. If this were handled with incbin, that would result in including a lot of copyrighted data in incbin'd files.

I'd recommend extending two operations and adding one:

Yes, as I state the format isn't very practial for distribution, but for developing-purposes only.

Distribution could be done by zipping up all the files that make up the patch and having the filenames be relative to the root of the zipfile instead of relative to the current working directory. That's how Java (jar), Winamp (wsz), StepMania (smzip) and Android (apk) handle extension packages.

In any case, I like this proposal. Once all the syntax gets ironed out, I might try my hand at making a Python version of the patching tool so that people who can't install the .NET Framework or the Mono runtime for whatever reason can still use patches built with this tool.

Sounds like to me this i just a personal tool...why not just use it as such? I don't find it very useful in any sense, myself. Usually when you separate blobs of data, and how they work...might as well make a PC editor and call it done for said game.

Please don't call the patcher patch.exe. This conflicts with both the UNIX utility called patch, as well as the Cygwin version (patch.exe). Pick something unique please.

Yes, avoid feature-creep, or you'll just end up with yet another patcher.

I sometimes use a simple patching tool that accepts the offset in a file, the new byte(s) to overwrite with, and optionally the old bytes so it can verify that you're patching what you expected to be patching.

If anyone's interested.. I've continued to develop this (yet unreleased) fileformat since I've discovered IPS has it's issues (people's patching the wrong files, that's why I've implemented the MATCH_CRC32 function..)
It pretty much fulfills all my needs ("good enough") at the moment so I'm probably going to switch to this fileformat instead of IPS in the future..

Well if you do, two thing will happen:

Nobody will use it.

People will get it from a 3rd party as an IPS, which may not be up to date.

And yeah, but you could do better than just a CRC match. When patching a ROM, test for a header, and then if so remove it and then patch if correct. Only bad thing is there's a few diferent formats of ROMS so it'd take a while to do it right...or, you could just keep the header changes and ROM changes different, and just offset the ROM data space.

It also needs a way to specify the CRC of the final patched file, to be sure everything was applied correctly.