Advanced SNES ROM Utility

[MysticLord]

I know I've seen *.xdelta patches for snes games, and I vaguely remember something called a *.bdiff (binary diff?), but I could be mistaken. Do we have tools to apply those patch formats? If we don't, is implementing them prohibitively complex (and of course do you want to make the effort)?

[Dom]

O.K., Dom. Will not be there glitches if the ROM Final Fantasy IV - Easy Type (J) is into 8,00 Mo?

Especially expanding LoROM + SlowROM with an origin size of more than 16 Mbit to ExLoROM (48 Mbit or more) is causing some troubles at the moment. Final Fantasy IV - Easy Type (J) is only 8 Mbit, so there might be a good chance for it to work without any glitches. Just try it out and do some testing. Would be nice, if you could share your results. I tried and the only method working is expanding with mirroring. Do you really need more than 32 Mbit for your translation? If so, I would take a closer look at it this weekend 

I know I've seen *.xdelta patches for snes games, and I vaguely remember something called a *.bdiff (binary diff?), but I could be mistaken. Do we have tools to apply those patch formats? If we don't, is implementing them prohibitively complex (and of course do you want to make the effort)?

You're right! I also remember these kind of patches, but I guess they're very rare.

In my tool set, I found a tool called Delta Patcher by SadNES cITy Translations for *.xdelta.
But it seems I've never ran into *.bdiff, though there's a tool called BsPatch.

I managed to get *.bdiff working, but it doesn't seem to have any validation like BPS or UPS. So you easily can mess up your ROM, if you apply the same patch for a second, third or whatever time.

Xdelta is also known as VCDIFF and is a little more complex. But there seems to be a good chance for it, since this is available over NuGet package store 
October 08, 2021, 01:49:25 PM - (Auto Merged - Double Posts are not allowed before 7 days.)
New version submitted!

XDELTA and BDF patches are supported now.

@Brutapode89: You now can try to expand your ROM, should work 

[jeffythedragonslayer]

Hi, I tried using this utility to inspect a ROM I assembled from scratch with WLA to see how badly I had screwed up the metadata, but got this error:

ROMs cannot be smaller than 128kByte (1Mbit) or larger than 16 MByte (128 Mbit).

bsnes and Mesen-SX loaded this rom fine, and snes9x loaded it and said it had a bad checksum and was corrupt.  Is there any reason this tool can't attempt to import tiny ROMs anyway just so I can see what mistakes I made?  If it could tell me which metadata fields were corrupt and which weren't (or which was the first byte of the ROM that was corrupt) that would be super useful.

EDIT:

When I commented out the if condition at SNESROM.cs:70, I was able to import my ROM and see the fields (several of them being "Unknown") but when I clicked "Expand ROM" the tool crashed:

Code Select Expand


System.ArgumentException
  HResult=0x80070057
  Message=Offset and length were out of bounds for the array or count is greater than the number of elements from index to the end of the source collection.
  Source=mscorlib
  StackTrace:
   at System.Buffer.BlockCopy(Array src, Int32 srcOffset, Array dst, Int32 dstOffset, Int32 count)
   at Advanced_SNES_ROM_Utility.Form1.ButtonExpandROM_Click(Object sender, EventArgs e) in E:\Advanced-SNES-ROM-Utility\Advanced_SNES_ROM_Utility\Form1.cs:line 146
   at System.Windows.Forms.Control.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ButtonBase.WndProc(Message& m)
   at System.Windows.Forms.Button.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
   at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
   at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
   at Advanced_SNES_ROM_Utility.Program.Main() in E:\Advanced-SNES-ROM-Utility\Advanced_SNES_ROM_Utility\Program.cs:line 16

[Dom]

Hi Jeff,

there must've been a reason why I did this, but I can't remember it at the moment. I will make some research on this and will edit this post later. But I guess that 1 MBit was the minimum ROM size that was used back in the days for making SNES cartridges.

Your header information should be stored beginning at 0x7FB0 for LoROM or 0xFFB0 for HiROM (without SMC header) and should mostly be well formed, otherwise this tool might have some problems with identifying it. In case the tool isn't able to identiy a header, it takes the LoROM layout as default, because this is the most common one. If the information is scrambled, it shows Unknown.

What you can try is making a new empty file with at least 128 kByte of size an copy the content of your actual ROM into it. If you have problems doing this, you can send me your file, I'll expand it for you and maybe fix some faulty header information.

[Dom]

Update to version 1.0! 

[Special]

Grats on the 1.0, this really is a fantastic tool. I've used it a lot since its inception pretty much just to fix odd checksums here and there after patching hacks/translations, and it's pretty much never failed me. Actually maybe a few oddball hacks that didn't get fixed, IIRC this was one such an example ( https://www.romhacking.net/hacks/7231/ ), but I just assume this one and the other few oddball failed ones are lost causes, heh.

I noticed you added "Remove SRAM Checks" in 1.0, got any examples of this? I tried using it on Ryusui translation ( https://www.romhacking.net/translations/1384/ ) but the SRAM check was still was there on first load..., so maybe its something entirely different?

Now so that you've done Advanced SNES and NES Utilities, what's next? lol

No pressure or anything but you should tackle Sega Genesis next IMO, I think a roll-up of useful utilities on that front would be nice to see and probably much needed, such as Fix CheckSum ( https://www.romhacking.net/utilities/342/ ) for example.

Anyways again, congrats on the release.

[Felipefpl]

I also used this nice tool several times, i hope it'll be advertised on main page.

[Dom]

Grats on the 1.0, this really is a fantastic tool.

Thanks a lot! Hope you also enjoy the new version as much as the previous

Actually maybe a few oddball hacks that didn't get fixed, IIRC this was one such an example ( https://www.romhacking.net/hacks/7231/ ), but I just assume this one and the other few oddball failed ones are lost causes, heh.

I think it's just because the ROM is malformed in its size. It claims to be 8 MBit but is slightly larger. Try to expand the unpatched ROM to 12 MBit without mirroring first, apply the patch, fix internal ROM size, fix checksum and save. The ROM now should be OK.

I noticed you added "Remove SRAM Checks" in 1.0, got any examples of this?

There's a wide variety of code for doing this, which is also different for Hi- and LoROM.

Most of them just write a specific number to a regular SRAM address and try to read this value from a mirrored address range again. If this works, everything is fine. If it fails, there's more SRAM available than the cartridge should have and it locks the game.

SRAM checks shouldn't be a thing in emulators and flashcards anymore, because the exact number of SRAM gets allocated. They just lock the game if there's too much SRAM, like in some copy stations or cheap flashcards. Even if you make a physical copy and add the correct SRAM chip, this locks shouldn't do anything

I tried using it on Ryusui translation ( https://www.romhacking.net/translations/1384/ ) but the SRAM check was still was there on first load..., so maybe its something entirely different?

This is a one time startup check to verify the patch. Just standard patch the ROM first, start it in an emulator, wait till the check is completed and make a save state, if your emulator didn't do this automatically. Then remove SRAM checks, fix checksum and save. There still should be a warning, if you play in PAL, but it doesn't prevent the game from running. When you try to make a physical copy, you should write the save state to your cartridge. Otherwise the startup check will run again.

Now so that you've done Advanced SNES and NES Utilities, what's next? lol

Well, I don't know yet Let's see, time will tell

I also used this nice tool several times, i hope it'll be advertised on main page.

Fortune smiled 

[Special]

Thanks for the replies. The only thing I have else to add, and you might want to consider, is to replace those blurry images of your SNES/NES utility on their respective download pages with less blurry ones.

[Dom]

replace those blurry images of your SNES/NES utility on their respective download pages with less blurry ones.

The pictures I added aren't blurry at all. Just click them and you will notice they're in good resolution RHDN is downsizing them automatically for their needs, what makes them appear blurry in some previews. I don't have any influence on that behaviour

[Felipefpl]

Fortune smiled 

Good, you deserve it.

[Europia79]

hey Dom, does this tool support a Command Line Interface for scripting ?

Also, I just ran into a rare problem where a patch asked for an Interleaved ROM: https://www.romhacking.net/translations/311/

I saw that your tool (ASRU) supports Deinterleaving ROMs, so I was curious if you could add support to convert ROMs to Interleaved format ?  TY !!!

[Dom]

Hey Europia79

does this tool support a Command Line Interface for scripting ?

Unfortunately not yet, but I might put this in the next release. Let's see 

I saw that your tool (ASRU) supports Deinterleaving ROMs, so I was curious if you could add support to convert ROMs to Interleaved format ? 

Because some other people had already asked for this, I will add this feature in near future. But I won't publish a new version just because of this. If you have Visual Studio installed, you can clone yourself the GitHub repository and compile your own version, after this gets committed.

At the moment I'm about to restructure the whole project. I also planned to outsource all copy protection codes into a library or database, so these could be updated without releasing a whole new version every time some of them got added or changed.

My main long time goal is to push this project to .NET 7.0 or 8.0 (or maybe what ever version is up to date at this time) and redesign the GUI in Avalonia or some other platform independent UI framework. So this tool can also be used on Linux or Mac or maybe as a web service. But this is only a glimpse into the distant future, because of job, family and other real life tings 

[Dom]

Ok, I've implemented interleaving for now. So this should work for applying the translation patch you've mentioned 

I figured out that a non headered interleaved ROM is needed for patching, instead of interleaved w/ header 
Please don't forget to deinterleave and fix checksum after patching.

If you can't compile your own version from GitHub (dev-branch), I can PM you a patch for the clean, deinterleaved version of the ROM 

[Dom]

Version 1.1 is out, enjoy 

[Special]

Download doesn't seem to be working.



Quick edit: Guess I should have checked this first, seems downloads are down for everything here site wide, and not just for your program. So I'm assuming that in time, everything will be back to working again, and you won't have to worry about anything... sorry for the needless bump.

[Dom]

While downloads here aren't working, you can get it from GitHub

[Retroplay]

Thank you, Dom.
It's a great tool.

One thing, though.
Remove Region Locks, it's not working 100% all of the time.
An example, Ball Bullet Gun by I'Max,
SNESTool 1.2 can remove lock with "fix for PAL" and the game will run, however, doing so in your tool results in a warning: "This game pack is not designed for your SUPER FAMICOM or Super NES".
No biggie, just thought I'd let you know, just in case you weren't aware of it.
 

[Dom]

Greetings Retroplay

Thank you for sharing your issue.

I took a loot at this and discovered, that this case seems to be an absolute rare occurance.
There are two pattern which can match the same locking code, but do different things to unlock them.

The first one is going to find exactly this:

(AD3F212910C900)(F0)

LDA $213F
AND #$10
CMP #$00
BEQ $xx

and replace it with:

(AD3F212910C900)(EAEA)

LDA $213F
AND #$10
CMP #$00
NOP
NOP

-> This happend with Ball Bullet Gun by I'Max, but doesn't unlock it

Later, there's another, more dnyamic, pattern:

(AF3F210029)(\w{2})(C9)(\w{2})(F0)

which coincidentally can be the same like the first one, but is doing this for unlocking:

(AF3F210029)(\w{2})(C9)(\w{2})(80)

So, the output in your case will be

LDA $213F
AND #$10
CMP #$00
BRA $xx

-> This will unlock Ball Bullet Gun, but is not applied, because the first pattern already took effect.

Although SNESTool is doing the right thing in your case, I guess it won't be able to unlock a lot of other games the correct way 

There's no Tool which will be able to remove 100% of all protections automatically, but at least a majority of it.

Anyway, I'm going to implement a more dnyamic way to configure region unlocking, but this might take some time.

[Oxinar]

Asterix & Obelix does not convert from PAl to NTSC.
With a hex editor I can change the region and the game starts on real hardware (NTSC).
If I go to the offset 7FD9 change it from 02 to 01 and on the offset E707 and
change the 89 to A9 the game starts on a NTSC Super Nintendo, but when started
on real hardware the colors are all corrupted.
Could this be some kind of region lock?