http://nesdev.parodius.com/bbs/viewtopic.php?t=7494 I've spend the last few months on a format that would make virgin data playable by way of emulator-side mapper database. Nothing will ever become as popular as iNES 1.0 because it was the first to be good enough, which is how all standards are determined in emulation. But unlike iNES 2.0, I think this format actually has a chance to be used by some people. And that's all we need to get the games preserved, correct boards and all. Supplied in the zip file is a prepared database and an explanation of the format, why it was made, and how it works. http://www.zapatabase.com/ZapFC_Format_Guide.zip A full converted library does exist and that's all I'll say about that. This topic actually seems to come up every year or so, the last time by etabeta. But no one seemed to get to the point with why headers are so disliked by some. From the guide: This format allows virgin data to function by way of external database checksum lookup. The main problem with rom-side mapping like headers is its inability to effectuate revisions to the format. When an oversight is discovered to affect certain games, as it was with RAM quantity in iNES 1.0, you're offloading mapper update responsibility to users who won't do it with tools that don't exist. The problem goes deeper than that. Distributed rom files are based on databases like GoodNES or No-Intro, so how they checksum files is a determining factor in whether the rom you download will play properly. GoodNES is 7 years out of date. And if you were to download the latest No-Intro set, you'd find that many of the roms have wrong or missing headers. No-Intro ignores headers in validation, probably because iNES 2.0 files would otherwise go unrecognized. But by doing so, they greenlight files that won't work in emulators. It's a double-edged sword with headers. You can either ensure data integrity or mapping integrity, but never quite both. The ZapFC format places no such burden on users because mapping is 100% emulator-side. As long as the user has his roms in this format, game issues stemming from missing or inaccurate headers are no longer a possibility. It's also a great format for dumpers. We would no longer have to use special tools with offset magic to obtain and compare checksums of just the CHR or PRG sections. I'll also address the "unlicensed" issue since I know it will get brought up. My stance on database inclusion is licensed, released games only. I exclude unlicensed games for the same reason that emulator authors don't bother emulating the endless streams of unlicensed add-ons and clone systems: they are a maintenance nightmare and I don't think we should be making inclusion decisions based on subjective quality appraisals. It's like Project Gutenberg trying to catalog everything from self-published books to the notes you took in math class. We all know that it's not possible to include infinitely creatable material, and licensed games will suffer for it. The database is there if you want to extend it, but that quicksand will sink you like it did Cowering. The solution is to either (a) continue using headered frankenroms for unlicensed games or (b) give option on failed database lookup to add custom db entry with a mapping selector. Then there's something neither iNES nor an internal db can accommodate, which is people who want to make not only their own games, but their own hardware. Since this is pretty niche, and would be a rom-side format prone to revisions, this should be its own format. Though I doubt if anyone truly cares enough to spend months preparing one. As for betas of licensed games, I am more sympathetic and could add them in the future. But betas are one-of-a-kind and nearly impossible to verify. How do we know a beta was unmodified and properly dumped? Anyway, there aren't too many active NES emulators left. Not sure if anyone will support it, let alone see things the way I've come to see them. --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 59.126.232.106