xor is actually more powerful than "replacing data". Replacing data is a one way fixed option. "xor" data allows you to "undo changes". For a romhacker, it's important for bug tracking changes they are making from one version to another. Unfortunately it relies on the order you are patching.


The checksums are there for the average user.. to tell them that they are matching up with the wrong intended file. The patcher itself (not the format) should have an option to ignore this.

Okay, how about a more detailed example?

Assume the following:
File A = { 0x01, 0x02, 0x03, 0x04 }
File B = { 0x11, 0x12, 0x03, 0x04 }
File C = { 0x21, 0x02, 0x23, 0x04 }

We know it's easy to convert A to B, and then B to C, this works in both formats. But dshadoff and co are arguing for stacked patches. They want the option of applying either B's patch or C's patch, or both. UPS can already apply one patch (obviously), but things get tricky when you want to apply both (rather, two or more) patches individually in any arbitrary order.

IPS:
Patch X = A->B = { 0x11, 0x12, --, -- }
Patch Y = A->C = { 0x21, --, 0x23, -- }

Apply patch X and then patch Y to file A = { 0x21, 0x12, 0x23, 0x04 }
Apply patch Y and then patch X to file A = { 0x11, 0x12, 0x23, 0x04 }

UPS:
Patch X = A->B = { 0x01 ^ 0x11, 0x02 ^ 0x12, --, -- } = { 0x10, 0x10, --, -- }
Patch Y = A->C = { 0x01 ^ 0x21, --, 0x03 ^ 0x23, -- } = { 0x20, --, 0x20, -- }

Apply patch X and then patch Y to file A = { 0x31, 0x12, 0x23, 0x04 }
Apply patch Y and then patch X to file A = { 0x31, 0x12, 0x23, 0x04 }

Summary:

As you can see, when you stack patches with either IPS or UPS that do not both modify the exact same byte, things work as expected. But there's a problem both with IPS and UPS when both patches do modify the same byte.

With IPS, the most recently applied patch takes precedence. Sometimes, this will be fine. But there's a good chance this kind of patching will result in errors, especially if you're updating code instead of data structures. Even if this works, you're going to run into a lot of problems. What if user A patches Y then X, and reports a bug -- but you don't see it because you patched with X then Y? Despite applying the same two patches, you end up with two different files! Now what happens when you get crazy as with the SMW patching, where you have a page with ~100 different patches, all of which can be applied in any order whatsoever? See what I'm saying now? IPS wasn't meant to do this kind of thing, either. It's terrible design, plain and simple. And I would stand by that statement even if my patch format was unidirectional.

With UPS, it's even worse. You end up with invalid data on those places. So yes, IPS has an "advantage" that you're less likely to run into problems in this case. And that's the only "advantage" IPS has.

Again, if you really want stuff like this, then you want a specialized patcher dedicated to applying these patches in logical, known good order with more advanced information (eg these patches are incompatible, but this one is innocuous, etc etc.)

Imagine how much more user friendly that would be to have a special program with checkboxes and radioboxes, instead of having someone repeatedly apply random patches on top of each other onto a binary, hoping they get it all right, having no way to know what was previously applied?

As for the development process itself -- using patches for that is just silly. Even xkas works on all platforms in "arch none" mode. Instead of keeping IPS patches with individual modifications, why not keep commented assembly files with file offsets and modifications? You can even pull in data from other files and perform mathematical computations this way.

Now instead of simply repatching six patches instead of seven to the original ROM, you simply uncomment that incsrc line in your main project file and run the assembler again.

dshadoff:

PPF does all you want already. Why criticise a format then that you'll never need to use anyway?

In general:

I'm a bit shocked by some of the general responses. byuu announced this format over a year ago and was open for input from everyone for all this time, making several discussions about it. And now that it's here finally here everybody suddenly remembers a special use that no one else is needing and complains about it not supporting it. Typical for this community, but disappointing nonetheless

Well, not so much "Not Invented Here" syndrome as "Not Invented Anywhere" in most cases (PC Engine, remember ?).

But I'll certainly take a look at xkas.  MagicKit is fine for creating ROMs, but not patching.

Is the xkas source open ?  I'm pretty sure I'd have to make adjustments to the opcode set and potentially the memory management approach to accommodate the Hu6280 processor.

If it's any consolation, UPS has got my vote.

Besides...how else am I gonna deliver a patch for Death Note: The Kira Game?

Okay, I completely rewrote everything (underlying library + user interface), taking previous suggestions in mind, and I fixed the edge cases reported to me that were failing. It might still fail one or two extreme edge cases that will never happen in the real world, but I did my best. And for the love of god, please don't everyone message bomb me this time if a glitch is spotted. One post in this thread is enough. Last time I got private messages here and on the Zboard, an e-mail, and about five separate IMs on it. Kind of overwhelmed me, sorry for getting upset over that to those involved.

http://byuu.org/files/tsukuyomi_v01.zip (binaries for Win2k+ / Linux/GTK+)
http://byuu.org/files/tsukuyomi_v01.tar.bz2 (source)


New initial interface. Look familiar? :P


Nothing special here.


The log output is now much more readable than the tiny little corner window.


A simplified method for patching an existing file directly.


And of course, the old-school patching method. Note the bypass checkbox. The reason it's not on the apply to existing file screen should be obvious. If a patch fails, it's not reversible. Applying a patch that is not reversible to your only copy of a file is retarded, and I will have no part in that. Write your own patcher or hack mine if you want that.

I'm a lot more careful this time around about temporary files being deleted. I buffer the output in memory at the moment so that there's no temporary file spawned until it's time to write data out. If patching fails, no file is ever created. Yes, this means a 64MB target file requires 64MB memory. I really don't think that'll be a problem, but I'll come up with something more complete later.

And yes, the DL v1.02 UPS patch works just fine with this patcher. The patch file and its format is unchanged between versions.


Thank you! :D

So why do you differentiate between "new files" and "existing files"? Wouldn't it be much more convenient to just have the program see if source = traget and then decide what to do or maybe give a warning with a "continue anyway" option?

This somehow reminds me of various linux distri's which have so many tools all to do the same thing but in a different way and now the user is up to deciding which one would work and if so, work best :-/

cYa,

Tauwasser

Oops never mind.