Alternative ROM Packaging and Format

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Alternative ROM Packaging and Format
by Great Hierophant on 2005-06-02 (#2218)
I was looking into how MAME packages its roms today, and I was struck of the appropriateness of it. They are zipped to improve space and separate dumps are kept separate. This is useful for burning and hacking ROMs. Also, it could be useful in terms of establishing a new and better ROM format than iNES. The mapper would be designated by an empty file simply entitled something like NROM.

For a game like Super Mario Bros., I envision the following:

File Name:Super Mario Bros. (U).zip
File Contents:
Super Mario Bros. (U).prg 32768 bytes
Super Mario Bros. (U).chr 8192 bytes
NROM V 0 bytes


There is a space between the board name and an H or a V, which designates the mirroring used. It is only used on those boards that use mirroring to any real effect (shown by an asterisk.)

Thus we have the boards

NROM * 32K PRG, 8K CHR-ROM

MMC1
SLROM 256K PRG, 128K CHR-ROM
SGROM 256K PRG, 8K CHR-RAM
SJROM 256K PRG, 8K CHR-RAM, 8K W-RAM
SKROM 256 PRG, 128K CHR-ROM, 8K W-RAM (battery backed)
SNROM 256K PRG, 8K CHR-RAM, 8K W-RAM (battery backed)
SOROM 256K PRG, 8K CHR-RAM, 16K W-RAM (8K battery backed)
SUROM 512K PRG, 8K CHR-RAM, 8K W-RAM (battery backed)

MMC2
PNROM 128K PRG, 128K CHR-ROM

MMC3
TLROM 512K PRG, 256K CHR-ROM
TGROM 512K PRG, 8K CHR-RAM
TKROM 512K PRG, 256K CHR-ROM, 8K W-RAM (battery backed)
TSROM 512K PRG, 256K CHR-ROM, 8K W-RAM
TLSROM 512K PRG, 128K CHR-ROM
TQROM 512K PRG, 128K CHR-ROM, 8K CHR-RAM
TVROM 512K PRG, 256K CHR-ROM, 4K V-RAM

MMC5
EKROM 512K PRG, 512K CHR-ROM, 8K W-RAM (battery backed)
ELROM 512K PRG, 512K CHR-ROM
ETROM 512K PRG, 512K CHR-ROM, 16K W-RAM (8K battery backed)
EWROM 512K PRG, 512K CHR-ROM, 32K W-RAM (battery backed)

MMC6
HKROM 512K PRG, 256K CHR-ROM

LS161
AOROM 256K PRG, 8K CHR-RAM
BNROM * 128K PRG, 8K CHR-RAM
CNROM * 32K PRG, 32K CHR-ROM
CPROM * 32K PRG, 16K CHR-RAM
GNROM * 128K PRG, 32K CHR-ROM
UOROM * 256K PRG, 8K CHR-RAM

FME-7
JSROM 512K PRG, 256K CHR-ROM

MMC1+4040
EVENT 256K PRG, 8K CHR-RAM, 8K W-RAM

MMC3+161
QJ 512K PRG, 256K CHR-ROM

MIMIC-1
80004 * 128K PRG, 64K CHR-ROM, 2K V-RAM
80030 * 128K PRG, 64K CHR-ROM

RAMBO-1
80032 128K PRG, 128K CHR-ROM

BF9093
BIC-43 * 256K PRG, 8K CHR-RAM

BF9096
BIC-48 * 256K PRG, 8K CHR-RAM

BF9097
BIC-62 128K PRG, 8K CHR-RAM

LS377
BC6 * 128K PRG, 128K CHR ROM
50282 * 128K PRG, 128K CHR ROM

LS138+LS175
NINA-06 * 64K PRG, 64K CHR-ROM

Impossible Mission II
NINA-001 * 64K PRG, 64K CHR-ROM, 8K W-RAM

Maxi-15
D-1012 1MB PRG, 1MB CHR-ROM

Caltron 6-in-1
?

Cheetah Men II + Action 52
?

Super Mario Bros./Tetris/Nintendo World Cup
?

After Burner
80042 ?

The benefits of this system are many. First, we will have more accurate emulation by ridding ourselves of the hated iNES mapper. Second, we can concentrate on emulating unique board hardware rather than emulating every single board variation, for many games come on more than one. Third, with the possibility of new CopyNESs, we can redump many boards that may have been hacked to use another mapper. Fourth, PRG and CHR are separated foreasy hacking and dumping. By peeking into the archive we can discover the size of the ROMs we will need. Fifth, we can keep game saves separate from our ROMs. Sixth, the system is flexible enough to add Famicom mappers. Seventh, the system will help people identify donor boards. Eighth, the system will eliminate the need for headers. The only possible way the ROM could go wrong is if the mirroring is set wrong. Ninth, these boards designate the maximum ROM sizes that the hardware can handle, tying them to reality.

by ReaperSMS on 2005-06-02 (#2220)
I see little advantage of this over UNIF. MAME's approach is not a terribly great idea, as they identify roms by hardcoding the checksums into the binary.

by Quietust on 2005-06-02 (#2221)
This looks like little more than a zipped Pasofami format, except using UNIF-style board names. Personally, I'm against it, since it would require implementing ZIP support in order to even load them, and it does not provide any advantage whatsoever over UNIF (in fact, it would be arguably worse, since zipped UNIF would compress better anyways).

by Zepper on 2005-06-02 (#2222)
This topic back to business??? :| Go figure...

by Great Hierophant on 2005-06-02 (#2227)
Quote:
I see little advantage of this over UNIF. MAME's approach is not a terribly great idea, as they identify roms by hardcoding the checksums into the binary.


That is because MAME emulates individual arcade games, not systems. I only like MAME's grouping of a game's ROMs, not its methods of detection. A NES emulator should be able to run NES code, what I propose will not change that.

Quote:
This looks like little more than a zipped Pasofami format, except using UNIF-style board names. Personally, I'm against it, since it would require implementing ZIP support in order to even load them, and it does not provide any advantage whatsoever over UNIF (in fact, it would be arguably worse, since zipped UNIF would compress better anyways).


It is essentially a zipped Pasofami format, shorn of its iNES generalizations and properly organized into ROM sets. Yes, it will require implementing ZIP support, but the alternative is to have a bunch of text files for the sole purpose of identifying the PCB type. Many good emulators have ZIP support already. Extra files take up unnecessary hard drivr allocation units. However, separating the ROM and eliminating the headers keeps the ROMs pure and makes them easier to work with.

UNIF is unnecessarily complex and turns the resulting ROM into something almost unworkable. It stores far too much unnecessary and redundant information in its "chunks." It also eliminates padding bytes at the end of ROM banks (to make it into a power of 2), which requires the user to put them back in when he wants to burn something.

I don't advocate splitting up multiple PRG or CHR ROMs, as that would generally be going too far and its far for games to have more than one of each. Of all the licensed and unlicensed NES games I only know of two that use two PRG (NWC 1990) or CHR (Afterburner).

by Guest on 2005-06-05 (#2260)
Great Hierophant wrote:
Of all the licensed and unlicensed NES games I only know of two that use two PRG (NWC 1990) or CHR (Afterburner).


And that Contra/xx-in-1 multicart too.