Just get ips win and make an ips file to put in the patch folder,from original and hacked rom.Then if you wish, you enable auto-patching, or load original then ips from launcher.

It will apply to current rom, this is another way of doing it

I think it won't help with several cases. Try to load Dragon Scroll (J) with lasted Nestopia 1.40 or 1.41 (not mine), and then apply ips patch. You'll see an error - unsupported or malfromed mapper. That's because game has new CRC value, and without database entry this game won't run. (the same result will be when you disable internal database and try only open Dragon Scroll).

There are two things to make this better without adding new entries for hacked roms:
- enhance somehow auto-recognizing mapper type (you are able to load Dragon Scroll without database in my last release, but it's almost impossible to make it perfect)
- or force to keep old CRC and SHA-1 (original) value before loading ips patch (that sounds good for me). btw. there's checkbox "bypass CRC validation" - what is doing, is this work?

anyway good to hear all your improvements! I hope your release will be free of mentioned above fatal error - bugs (like in 1.41 that makes system unresponsive on fullscreen, forcing to reboot)

The second best option as I see it is to separate the database of verified good dumps into a separate executable that takes a hash of the PRG and CHR and returns a correct 16-byte iNES or NES 2.0 header. This would allow permanently fixing the header in the ROM file before applying IPS, and it'd allow behavior similar to your "force to keep old": load ROM, get fixed header, load IPS.

The best option would involve a BitTorrent-style hash list that recognizes inexact matches in order to recognize that a ROM has been partly patched. Again, this would be best as a separate executable so that other tools can make use of it.

Try to load Dragon Scroll (J) with lasted Nestopia 1.40 or 1.41 (not mine), and then apply ips patch. You'll see an error - unsupported or malfromed mapper. That's because game has new CRC value, and without database entry this game won't run. (the same result will be when you disable internal database and try only open Dragon Scroll).

Ok, I have learnt a lot,
1. To load a patched rom of dragon scroll you need a database entry.
2. To load the ips patch that makes that patched rom you do not need an entry at all.
But, the ips patch needs the same header / mapper info as the original.

I traced through the v-related circuitry in Visual 2C02 to figure out what goes on in this glitch. The short version is that reading or writing $2007 during rendering triggers a Y increment and a coarse X increment. Here's the explanation:

v is split up into multiple sections (X scroll, Y scroll, horizontal nametable bit, vertical nametable bit, and fine Y scroll), each with a configurable carry in that determines the "next" value for the section. When not rendering, the carries are set up to perform linear increments of v by either 1 or 32. When rendering, they are set up to perform the operations described in The skinny on NES scrolling.

The crux is that reading or writing $2007 triggers the "load next value" signal for all the bits of v (it triggers both of the "load next hscroll value" and "load next vscroll value" signals), and it expects the carries to be set up for a linear increment. During rendering, this instead has the effect of loading both the next Y value and the next coarse X value.

I also updated the "$2007 reads and writes" bullet in The skinny on NES scrolling.

Thanks. This does kinda fall in the OCD category though (I only know of one game that cares, and the previously guessed behavior was likely sufficient there), but it's not very hard to get right at least.

As far as I can tell, MMC3C and MMC3B S (with S in the same font as the logo of Sharp Electronics) have the new behavior (0 = IRQ every line), and MMC3A and MMC3B (no S) have the old behavior (0 = disable).

Can't remember whether this was mentioned before, but Legend of Zelda does two "inexplicable" $2007 reads in it's vertical scrolling routine (used when screen is scrolling upwards/downwards) at $8566, with rendering enabled. Notably they also didn't know about the $2005/$2006 trick so they only used $2006 when scrolling vertically, making the vertical screen transition slightly choppier than the horizontal one.

Sorry for resurrecting an old thread. But the shaking issue is there on Nintendo's emulator that is used in their games in eShop on 3DS. If you do an inject of this game into that emulator the screen shakes. Unfortunately I cant use another emulator so I need to fix the game itself. I saw that there is an ips patch posted on page 2. is that still the best solution for this?

Who is online

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