A new patching-fileformat

A place where you can keep others updated about your NES-related projects through screenshots, videos or information in general.

Moderator: Moderators

Post Reply
User avatar
oRBIT2002
Posts: 687
Joined: Sun Mar 19, 2006 3:06 am
Location: Gothenburg/Sweden

A new patching-fileformat

Post by oRBIT2002 »

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".

Code: Select all

;**** Remove ROM-check
poke #$ea,$1c038
poke #$ea,$1c039
poke #$ea,$1c03A

;*** NMI-inject
poke #$6c,$1c078
poke #$20,$1c079
poke #$fe,$1c07a

;*** Inject own-code
incbin "castle.bin",$1fe30

etc. etc.

'
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?
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: A new patching-fileformat

Post by tokumaru »

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.
User avatar
oRBIT2002
Posts: 687
Joined: Sun Mar 19, 2006 3:06 am
Location: Gothenburg/Sweden

Re: A new patching-fileformat

Post by oRBIT2002 »

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.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: A new patching-fileformat

Post by Bregalad »

Then the main drawback is that it requires multiple files for a patch...
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: A new patching-fileformat

Post by tepples »

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:

Code: Select all

; Poke value, destination start, destination end
; fills an entire range.
poke #$EA, $1C038, $1C03A

; Copy source start, source end, destination start
; copies from one point to another in the working ROM.
; Useful for copying the fixed bank while expanding ROMs.
copy $1C010, $2000F, $3C010

; Incbin filename, source start, source end, destination start
; copies only a portion of a file.
; In each case, the destination start is the last argument.
incbin "newlevels.bin", $0000, $0FFF, $20010
incbin "newlevels.bin", $1000, $1FFF, $24010
User avatar
oRBIT2002
Posts: 687
Joined: Sun Mar 19, 2006 3:06 am
Location: Gothenburg/Sweden

Re: A new patching-fileformat

Post by oRBIT2002 »

Bregalad wrote:Then the main drawback is that it requires multiple files for a patch...
Yes, as I state the format isn't very practial for distribution, but for developing-purposes only.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: A new patching-fileformat

Post by tepples »

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.
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Re: A new patching-fileformat

Post by 3gengames »

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.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: A new patching-fileformat

Post by koitsu »

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.
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Re: A new patching-fileformat

Post by blargg »

3gengames wrote: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.
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.
User avatar
oRBIT2002
Posts: 687
Joined: Sun Mar 19, 2006 3:06 am
Location: Gothenburg/Sweden

Re: A new patching-fileformat

Post by oRBIT2002 »

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..

Code: Select all

FILL #<Byte>,<Offset>,<Length> - Fill an area with <Byte>
POKE #<Byte>,<Offset> - Change a byte at <Address>
INCBIN "<file>",<Offset> - Loads a binary file and inserts at offset <Address>
INJECT #<Byte>,<Offset>,<Length> - Injects <Byte> <Length> times at offset <Address>, increasing size of data
MATCH_CRC32 $XXXXXXXX	 - Makes sure input file matches CRC32
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Re: A new patching-fileformat

Post by 3gengames »

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.
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Re: A new patching-fileformat

Post by blargg »

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