It is currently Tue Oct 16, 2018 1:35 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 13 posts ] 
Author Message
PostPosted: Mon Apr 08, 2013 3:57 am 
Offline
User avatar

Joined: Sun Mar 19, 2006 3:06 am
Posts: 585
Location: Gothenburg/Sweden
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:
;**** 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?

_________________
http://nes.goondocks.se/


Top
 Profile  
 
PostPosted: Mon Apr 08, 2013 5:39 am 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10892
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Mon Apr 08, 2013 7:21 am 
Offline
User avatar

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

_________________
http://nes.goondocks.se/


Top
 Profile  
 
PostPosted: Mon Apr 08, 2013 8:12 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7546
Location: Chexbres, VD, Switzerland
Then the main drawback is that it requires multiple files for a patch...


Top
 Profile  
 
PostPosted: Mon Apr 08, 2013 8:22 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20659
Location: NE Indiana, USA (NTSC)
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:
; 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


Top
 Profile  
 
PostPosted: Mon Apr 08, 2013 8:24 am 
Offline
User avatar

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

_________________
http://nes.goondocks.se/


Top
 Profile  
 
PostPosted: Mon Apr 08, 2013 8:31 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20659
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Mon Apr 08, 2013 9:41 am 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2263
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.


Top
 Profile  
 
PostPosted: Mon Apr 08, 2013 10:00 am 
Online
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3629
Location: Mountain View, CA
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.


Top
 Profile  
 
PostPosted: Mon Apr 08, 2013 10:37 am 
Offline
User avatar

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


Top
 Profile  
 
PostPosted: Wed Jun 12, 2013 12:58 pm 
Offline
User avatar

Joined: Sun Mar 19, 2006 3:06 am
Posts: 585
Location: Gothenburg/Sweden
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:
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

_________________
http://nes.goondocks.se/


Top
 Profile  
 
PostPosted: Wed Jun 12, 2013 1:39 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2263
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.


Top
 Profile  
 
PostPosted: Wed Jun 12, 2013 4:24 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
It also needs a way to specify the CRC of the final patched file, to be sure everything was applied correctly.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group