[Abster]

So the 2 Ls is a British thing.  Duly noted.

[columbo]

I think I fixed everything Abster pointed out minus the glitch at the end of the game.  I used KingMike and RadioShadow's suggestions for how to fix those dialog boxes that were a little screwed up.

From what I can tell those garbage tiles at the end of the game are actually part of the title screen.  It might be an easy fix, but I haven't dived too deep into it since I wasn't the one who did the title screen hack.  I'll do a little more investigating to see if I can fix it without straight up removing the title screen hack. (edit: Doesn't look like any easy fix.  Definitely looks like the title screen hack replaces those sprites.  If you have any ideas let me know. There are some unused katakana sprites, but they aren't loaded into the PPU during the title screen.)

I'm going to update the wiki page with the new patch.   For now though you can use this link:

https://www.mediafire.com/file/0aui7rabdieukkk/Zelda%202%20.33%20%28ENG%29.ips

[DemoniusX]

Sorry to bring up this old thread but no matter what I do,when patching the game the file size goes to zero and won't load and I've tried 5 different v1.1 of Link No Bouken 2! Do I have to modify anything,why won't it patch. Using Lunar IPS to patch this game? Any ideas?

[ShadowOne333]

I think I fixed everything Abster pointed out minus the glitch at the end of the game.  I used KingMike and RadioShadow's suggestions for how to fix those dialog boxes that were a little screwed up.

From what I can tell those garbage tiles at the end of the game are actually part of the title screen.  It might be an easy fix, but I haven't dived too deep into it since I wasn't the one who did the title screen hack.  I'll do a little more investigating to see if I can fix it without straight up removing the title screen hack. (edit: Doesn't look like any easy fix.  Definitely looks like the title screen hack replaces those sprites.  If you have any ideas let me know. There are some unused katakana sprites, but they aren't loaded into the PPU during the title screen.)

I'm going to update the wiki page with the new patch.   For now though you can use this link:

https://www.mediafire.com/file/0aui7rabdieukkk/Zelda%202%20.33%20%28ENG%29.ips

Are the correct sprites loaded at that section of the game?
If so, you might want to play around with the tile arrangement when that screen is visible.
Look for the incorrect sprites in the PPU Viewer, write down their Tile ID, then try to hunt the order in which the incorrect sprites appear in the Hex editor -> Rom viewer.

Then try changing them for the correct sprite Tile ID.
Hopefully that works. Of course, that's if the correct sprites are in the PPU Viewer at the correct moment.

[columbo]

Sorry to bring up this old thread but no matter what I do,when patching the game the file size goes to zero and won't load and I've tried 5 different v1.1 of Link No Bouken 2! Do I have to modify anything,why won't it patch. Using Lunar IPS to patch this game? Any ideas?

Sorry for the delayed response.  I used flips IPS for the latest patch.  I doubled checked to make sure it was still working for me.  flips is the newer version of Lunar IPS.  I think the patches are often smaller than the ones Lunar outputs and maybe that affects the compatibility somewhat.

If enough people have issues with compatibility then I'll definitely investigate to see what I can do about it.

Are the correct sprites loaded at that section of the game?
If so, you might want to play around with the tile arrangement when that screen is visible.
Look for the incorrect sprites in the PPU Viewer, write down their Tile ID, then try to hunt the order in which the incorrect sprites appear in the Hex editor -> Rom viewer.

Then try changing them for the correct sprite Tile ID.
Hopefully that works. Of course, that's if the correct sprites are in the PPU Viewer at the correct moment.

Not sure what to do here.  I haven't checked the ending, but at the beginning of the game when you're in the room with sleeping Zelda the katakana sprites aren't loaded.  The sprites loaded all seem like they go to something.

Perhaps an ASM hack could fix this, but honestly I'm not too worried about those missing sprites.

I'm guessing that a little bit of time went into the title hack so I feel like leaving that in for now out of respect, but another solution would be to just use the Japanese title screen, which does happen to say "The Legend of Zelda 2" above the Japanese text.

edit: Or maybe I could just release a separate patch here on the forums with the Japanese title screen.  If anyone wants that, let me know.

[Psyklax]

flips is the newer version of Lunar IPS.  I think the patches are often smaller than the ones Lunar outputs and maybe that affects the compatibility somewhat.

Sorry if I'm derailing the thread here, but can anyone explain to me the benefit of any patching programs besides Lunar IPS - or patch formats besides IPS? The size of the files is so minuscule that that's clearly not a problem, so what's better about the others? The only thing I know is that BPS files will throw an error if the checksum doesn't match, which is nice, but not that big of a deal.

Given the IPS format is so damn simple - go to this part, put this many bytes in, here are the bytes, lather rinse repeat - I don't see why there's a need to change it. Sure, when you get to something above 16-bit, it might need to be more sophisticated (it supports 24-bit addresses, so I guess any file above 16MB is a problem), but for most of the hacking that goes on here, it seems perfectly satisfactory.

Again, sorry for derailing your thread, I just didn't see the need to clutter the forum up with a new thread on this point.

[mods: feel free to move this to a new thread, or let me know if that would be a better thing to do...]

[KingMike]

Using BPS for an FDS game would be a bad idea, since (depending on the emulator) the save file is written to the ROM, so then the BPS would only match if you had identical save data, which is pretty much impossible.
(some emulators might instead make a copy of the ROM and save to that)

The other reason FDS files could not match up despite being good dumps is that, original disks had the date written stored in the standard Nintendo header part of the disk. We've seen that in more accurate dumps that have been made of FDS games lately.
In common FDS dumps that data is zeroed (though I'm not sure if it is relatable to 3DS ROMs, which as I understand typically have some fingerprinting data wiped out. It's going off topic though but the 3DS header wiping is more understandable though as it was probably made to track individual copies and maybe so Nintendo could ban from their network pirated copies and/or accounts of users who uploaded the ROMs.)

[darkmoon2321]

Sorry if I'm derailing the thread here, but can anyone explain to me the benefit of any patching programs besides Lunar IPS - or patch formats besides IPS? The size of the files is so minuscule that that's clearly not a problem, so what's better about the others? The only thing I know is that BPS files will throw an error if the checksum doesn't match, which is nice, but not that big of a deal.

Given the IPS format is so damn simple - go to this part, put this many bytes in, here are the bytes, lather rinse repeat - I don't see why there's a need to change it. Sure, when you get to something above 16-bit, it might need to be more sophisticated (it supports 24-bit addresses, so I guess any file above 16MB is a problem), but for most of the hacking that goes on here, it seems perfectly satisfactory.

If I need to make an IPS patch, I pretty much only use Lunar IPS.  It's simple and I know it works.  But for larger hacks, typically those that involve expanding the ROM, moving large chunks of data, or editing compressed data, it's better to use a patch format that can handle data insertion.  For instance, if you insert a single byte into a long string, IPS will see every byte after the initial change as being different and will include the data in the patch.  This can lead to your patch containing copyrighted information.  In the case of expanded ROMS, the patch size for an IPS can be as big as the original ROM itself, and will undoubtedly contain copyrighted data.  IPS is more popular however, and the average user can apply a patch without having to go download a new patching tool.  So basically, I use IPS when I can, but for the more complicated projects, I'll use something that can handle data insertion, like BPS or xdelta.

[Psyklax]

Using BPS for an FDS game would be a bad idea, since (depending on the emulator) the save file is written to the ROM, so then the BPS would only match if you had identical save data, which is pretty much impossible.
(some emulators might instead make a copy of the ROM and save to that)

I know that. That was my point of saying I just use IPS. However...

But for larger hacks, typically those that involve expanding the ROM, moving large chunks of data, or editing compressed data, it's better to use a patch format that can handle data insertion.  For instance, if you insert a single byte into a long string, IPS will see every byte after the initial change as being different and will include the data in the patch.  This can lead to your patch containing copyrighted information.

This is exactly the problem I've got with my (as yet unreleased) Knight Lore translation for FDS. I added a few bytes to the file and thus the IPS file is 26KB instead of under 1KB, and obviously includes a large chunk of the disk. I don't want this, so if anyone can recommend an alternative then I'm all ears.

The checksum checking of BPS is a problem for the reason KingMike mentioned - though incidentally my patch deletes the save data, and I hope others making patches will do the same as it's probably appreciated by people who want a nice clean file. How about Xdelta? I've not used it, would it yield a better result in my case? Do you have to manually say where the extra bytes are or can it just figure it out by itself?

[darkmoon2321]

The checksum checking of BPS is a problem for the reason KingMike mentioned - though incidentally my patch deletes the save data, and I hope others making patches will do the same as it's probably appreciated by people who want a nice clean file. How about Xdelta? I've not used it, would it yield a better result in my case? Do you have to manually say where the extra bytes are or can it just figure it out by itself?

I use the utility here as a frontend for xdelta:

https://www.romhacking.net/utilities/704/

You can select whether or not to add a checksum when you create the patch.  As long as you disable the checksum you should be good.  It can figure out where the bytes are by itself.

[Psyklax]

I use the utility here as a frontend for xdelta:

https://www.romhacking.net/utilities/704/

You can select whether or not to add a checksum when you create the patch.  As long as you disable the checksum you should be good.  It can figure out where the bytes are by itself.

Thanks for the tip, I'll give it a shot.

[ToHell]

hello,

i use fceux-2.2.2-win32 and have found a another bug. then princess zelda awake, her sprite ist broken.


https://picload.org/view/dgiprgri/neuebitmap.png.html

[ShadowOne333]

hello,

i use fceux-2.2.2-win32 and have found a another bug. then princess zelda awake, her sprite ist broken.


https://picload.org/view/dgiprgri/neuebitmap.png.html

That one has already been reported iirc:

Finally, some garbage tiles in the game's ending for when Zelda wakes up.

[ToHell]

I apologize for that, but when is a corrected patch expected?

[jackic]

That one has already been reported iirc:

This patch addresses the Zelda graphics corruption in the ending:

https://mega.nz/#!GSA0hSoB!IuXDsnmTKK0Y_6IEPjqlgOIR2wykw88vNVolmDB6t-E

Apply to the ALREADY PATCHED translation 2.33 that is hosted in this very site. I hope it does not broke anything else.

[ToHell]

The face is lost. I load a savestate.

[KingMike]

If you patched the ROM and then loaded a savestate, that might be a problem right there.
Depending on the emulator you use, it might revert the entire contents of the FDS file to what it was at the time of your savestate.
(due to that part of the FDS disk is writable data, emulators might rewrite the whole updated file to disk)

Other emulators might make a copy of the fds file into its save folder and use that copy as its save, while others might make an IPS.
I don't know which way of handling FDS files that particular version of the emulator uses.

[jackic]

The face is lost. I load a savestate.

I am fairly positive that it is NOT supposed to have a face until you use the THUNDER spell. Try that!

[vanfanel]

Hi!

I am trying this patch (applied to a clean ROM, the resulting ROM has the expected CRC32 of 359D3F2B) on the FPGA NES+FDS implementation of the MiSTer project,
and causes the FDS to fail with: "DISK TROUBLE ERR.22"

Unpatched clean FDS file (CRC32 1187FE3D) does work without any trouble, so I think this patch isn't working on real hardware. Am I right?

[Noishe]

First... HAPPY NEW YEAR 2021! Is my first post...

Hi!

I am trying this patch (applied to a clean ROM, the resulting ROM has the expected CRC32 of 359D3F2B) on the FPGA NES+FDS implementation of the MiSTer project,
and causes the FDS to fail with: "DISK TROUBLE ERR.22"

Unpatched clean FDS file (CRC32 1187FE3D) does work without any trouble, so I think this patch isn't working on real hardware. Am I right?

This patch work fine in the real hardware. I'm tested in my Famicom AV and FDSSTICK, and the EVERDRIVE N8 (only problems is the sound) and I'm try write in a disk and working fine in a Famicom Disk System.

I see a new error in this patch. After the intro text, if you don't press START, the game title doesn't display right the second time. If you then press START after that time the game starts with a glich in the Link graphic.

The last month I'm translation this patch in spanish, but I do not know correct this bug.





Is anyone able to fix it?

My patch in spanish:
http://www.romhacking.net/translations/5795/