After browsing through the entire section of NES Win utilities, I haven't found what I'm looking for.

The problem I'm having is with the refresh rate of a NES rom. I was wondering if there was a tool that could force NTSC on a PAL rom? 

Similar to what the SNEStool utility can do for SNES games.

*ahem*


That's been around for a while, you know.

This bit has been a standard for at least 5 years, and so far it would appear as though that nothing's been done to correct the roms that need to be corrected. That's laziness on everybody's part.

Laziness on the emu author's part then. They willfully ignore it.

You're arguing for the sake of arguing. I can recall many a rant by you about the "DISKDUDE!" BS that shouldn't even be there in the first place.

It might help if we even knew what game he was talking about.

Not useless, just largely unused.

I don't believe such a thing does or can exist for the NES. Though it won't be the first time I am wrong. :angel:

Yeah, would it be hard to specifically check for DISKDUDE!, ASTER, pyr0 or other common header garbage, before checking for valid header data?

And therein lies the problem.

Nobody fixes their corrupted ROMs because they work fine in emulators, and no emulator author is willing to suffer a loss in popularity by being "the emu that can't run half the games out there."

The ROM users / sites are clueless. The only way to force them to change is for the emu authors to take action. If all emu authors would work together and remove all of this legacy cruft (DISKDUDE!, iNES1, SNES copier headers, 300 file extensions, Genesis interleaving, etc etc), we could make real progress. But we all know that's never going to happen. We can't pull it off in the SNES scene with all of four active emulators. How the hell could we expect that from the NES scene with at least 100 active emulators?

And I'm no better myself. I still have copier header detection. But I have tried very hard to get other emulators to remove this along with me. I couldn't convince a single person. Ideally, we'd just display deprecation messages and offer to fix the ROMs. After a year, remove the mechanism entirely.

But yeah, we bring the problem on ourselves through our competitive nature.


I agree completely. Lenophis advocates emulators to treat a bit that's not set correctly for and will break hundreds of titles. It's a nice ideal, and should have been done initially. But now, in the best case, this would get the iNES1 headers slightly updated. In the worst case, it's suicide for the one emulator daring enough to try it. And you'd still be left with a worthless header format that doesn't adequately represent the hardware (PRG/CHR RAM/ROM mirroring/size info, mapper subtype properties, etc etc); forcing you to use a database anyway.

Fixing that bit will just cause lots of temporary problems for people with no real long-term improvement. If we're going to fix the NTSC/PAL issue, we should take the opportunity to ditch iNES all together. And no, UNIF is not the answer there. XML is much nicer, but talk about using a sledgehammer on a nail ...

 The first thought that comes to mind is why not create a new header format that's distinguishable from the current iNES header format (.i.e longer header and a new/specific identification string). Not changing the rom layout, but the just the header itself and it wouldn't conflict with the older iNES header format. Then the next thought was if I had thought of it, I'm sure as hell positive that someone else has thought of this already. So what was the reasoning/conclusion behind not creating a new header format?

 Ah, I see.