ZapFC Headerless Format - 模擬器

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.

--