Headers have long been seen as contrary to the goal of preservation, as it adds data to the ROM file that isn't on the original ROM. (I use header to refer to external headers, not internal headers, which are part of the ROM and should be preserved.) In many cases this is true; we have no purpose in preserving this data. No-Intro has therefore taken the position of removing headers on NES ROMs. I have recently begun to start thinking of this as a mistake (based on my limited knowledge of how NES cartridges work), so I want to document and discuss how to best store NES ROMs. Although I defend the use of headers, I am not defending a particular header format.Jul 02, 2017 Here's the complete No-Intro Game Boy ROM collection. Visit my page at archive.org. Download No Intro Rom Sets. By Arcade Punk January 22, 2017. Atari – 5200.zip Atari – 7800.zip. Nintendo – Game Boy Advance.zip Nintendo – Game Boy Color.zip.
First, there are three tenets of No-Intro that, as I understand them, are relevant to this.
Gameboy Advance Rom Set No Intro Creator
1. One cartridge, one ROM file. We do not split ROMs.
2. The ROM file should be sufficient to describe everything about the cartridge's data. One should not have to rely on external data about the particular cartridge to understand or reconstruct the ROM data as it is read by the console. Similarly, if two cartridges correspond to the same ROM file, then their data as it is read by the console must be identical.
3. Extraneous data not on the cartridge that's not necessary for the preservation of the cartridge's data should not be included in the ROM file.
Gameboy Advance Rom Set No Intro Creator
With that said, I'll now consider several proposed formats for NES ROMs.
Split PRG and CHR ROMs: This is a blatant violation of tenet 1.
Concatenated PRG and CHR ROMs: This is what we have now. The problem is that it violates tenet 2. The size of the PRG and CHR ROMs is lost when they are concatenated; the way the data is organized on the cartridge is, which is essential to understanding the data, is lost. People have suggested that if headerless ROMs were to be used by an emulator, an external database would have to be used, containing the information that would otherwise be in the header. But all the data necessary to describe the data n the cartridge should be self-contained in the ROM file. This is like preserving books by stripping them of their cover and table of contents; now you just have a bunch of loose pages.
Split PRG and CHR ROMs together in an archive (such as a renamed ZIP or tarball file): This solves tenet 1 and 2, but tenet 3 is violated. If a header is bad, then this is even worse because now there is much more than 16 bytes of metadata and headers as part of the ZIP or tarball format (and, of course, none of this is part of the original data). Furthermore, these files can produce different hashes even with the same ROM files (a ZIP file can have different compression algorithms and a tarball can have different date modified parameters). We could fix this with a standard that specifies what compression algorithms, date modified parameters, etc. are to be used, but then the convenient appeal of using a renamed ZIP or tarball file is lost.
Concatenated PRG and CHR ROMs with a header: This certainly satisfies tenet 1 and 2, but does it satisfy 3? I argue that it does, because the NES headers contain essential data that should be preserved, unlike the external headers on, for example, SNES ROMs. We shouldn't do away with headers just because the data is not part of the ROM itself, but is rather a representation of how the data is organized on the cartridge.
Any way of organizing the data into a single file will surely be arbitrary. Although such arbitrariness can be standardized (e.g., iNES and NES 2.0), we have no reason to preserve this arbitrariness. So how can I reconcile this with my support for headered ROMs? Although I think headered ROMs are a good way to store the data, I do not think the headered file is what should be datted. My solution is for the DAT to store the hash of both the PRG and CHR. Then, one may store these however one likes, and the DAT would only verify that the PRG and CHR files have the correct hash, regardless of how one chooses to store them.