nesdev.org

Sorry to sound extremely sarcastic, but just to say I'm laughing loud at you guys doing a 8-page hot flamed debate on a yet another useless proposal for iNES remplacement that nobody will ever use. MWAHAHAHAHAHA. (don't tell me that wasn't constructive I know that, I just couldn't resist) And yet, ...

No. Nor does it handle expanding the PRG and moving the CHR to compensate. A new binary diff format is needed; I'd recommend a zipped collection of IPS files or (better yet) bsdiff files. In this instance, patch conversion would be far easier than the SNES because headers on ".nes" files ...

Nor would they be for extra files in folders. I'm not saying it's the sure-proof method here. There is too much inertia in getting the OS to treat a folder like a file. You responded before I could edit, but I was going to give ease of future validation as the reason tools control distributors and ...

The advantage of containers is for distribution, which can be handled better. That's the biggest reason I dislike using folders as containers. But you know, ".fc" folders are an easy thing to support without having to be distributed as its own set. Because tools like WinRAR can "extr...

If we "had it to do all over again" we would use iNES 2.0, Umm, no. Ever heard the term "hindsight is 20/20"? There is a fundamental risk with rom-side mapping. You know it now and it should have been known then. but possibly with a larger header that would also include things l...

The troubleshooter that I mentioned would start to explain the difference. Imagine, if you will, a short video of a good dump of Super Mario Bros. with the wrong mirroring. Take time to read a doc that links to a video to watch about ines headers? Aw jeez. iNES doesn't need to exist solely to be a ...

You are so not getting this. I am saying Nestopia only goes half way, but if iNES really was this huge problem it could use a full header database. But that's inconsiderate to those who want to work with and store this data in its native form without specialty tools. It's also not an archival forma...

So you believe the average person can be expected to know: (a) the difference between a header problem and not an emulation bug No, I expect the EMULATOR to do this. Completely independent from the average person. Just as you expect the emulator to do the work. You are so not getting this. The Nest...

You want the emulator to do a checksum and look up mapping information in a database. How is that any different from an emulator doing a checksum and looking up a header in a database? If bad headers are the problem, then an emulator can just always ignore them and use its own. Doesn't Nestopia (am...

Listing those 50 games would go a long way to promoting this idea. Looking at the iNES 2.0 discussions there are far fewer than that in the licensed set which need to be handled. That's not the only issue. Missing or incorrect headers are the larger issue. Think about how many new dumps have been r...

Because 1.0 takes care of 99.99% of games. More like 98%, but 2% is 50 games, including Final Fantasy I+II (J), which is not exactly obscure. And as far as I know, no-intro does not concern themselves with mapping, only rom integrity, so it will have more and better dumps, but the mapping will be a...

An auditing tool could use a database like yours to split, hash, and rewrite the header on each ROM in a collection. It's still a frankenfile and it's still part of a failed mapping delivery concept. 100% of users and 95% of emulators use only 1.0 files even after a better revision was issued years...

I only made a splitter and there's alot more on the web >.>....needs fixed up though. And what will the files spaced out have that iNES can't? This offers no advantage as far as I'm concerned. Instant access to the chr and prg files, sizes, and checksums without needing to find some assfuck special...

What's wrong with the 20 byte header? This question still hasn't been answered! :P It was answered before anyone even responded. I laid it out cold that rom-side mapping is fundamentally flawed in that it can't effectuate inevitable revisions. "Just get every rom supplier to update to iNES 2.0...

I'm pretty sure Nestopia does. Nestopia's database feature requires roms be in headered frankenfile format. There was never any effort made to make virgin data playable like every other system, only to override the mapping information in the header. That you have to look at the mapper or the databa...