New File Format

[tepples]

- What on earth are those PPU types ? I've never heard of that. Normally, a NES game should work with all PPU revisions, huh ?

True, Nintendo lot check tried each licensed NES game in consoles with all PPU revisions (including one NES with a dying PPU that The Three Stooges helped uncover). But as Marty said, it's a matter of Famicom/NES NTSC PPU, NES PAL PPU, PlayChoice PPU, and especially different Vs. Unisystem PPUs.

- Why CHR-RAM could be battery backed ? I don't see much interest with that. What game could have any use of this ? To save space, a game would write all its save to the CHRRAM ? That make no sense to me, while technically possible.

Because a 16 KiB CHR RAM may be cheaper than an 8 KiB CHR RAM, an 8 KiB PRG RAM, and the extra decoder circuitry.

- Why CHR-RAM/SRAM size could be less than 8kb (exept 0kb) ? I doubt any 128-byte RAM chips are used in any NES game.

How big is the PRG RAM in HKROM carts?

- More info on what exactly "submappers" would look like would be welcome.

Mapper 4.x: T*ROM (MMC3) vs. H*ROM (MMC6).
Mapper 34.x: BNROM vs. NINA.

Something like 3 bits :
000 -> Japan, NTSC
001 -> America, NTSC
010 -> Europe, PAL
011 -> (Australia ?), PAL

Would that be a lockout chip ID? The way the Sega Genesis does it is one bit for screen and one bit for ideographic:

• 60 Hz ideographic: Japan
• 60 Hz alphabetic: North America
• 50 Hz ideographic: mainland East Asia
• 50 Hz alphabetic: Europe, NZ, Australia

100 -> Pirate/Homebrew/Unlicenced, NTSC
110 -> Pirate/Homebrew/Unlicenced, PAL
111 -> Pirate/Homebrew/Unlicenced, support both video standards

And this would fit into the lockout chip ID more than anything. Some people won't be satisfied until the CIC is emulated.

[Bregalad]

Because a 16 KiB CHR RAM may be cheaper than an 8 KiB CHR RAM, an 8 KiB PRG RAM, and the extra decoder circuitry.

This forces the game to have no graphics when it saves and when it resumes the saved game, this removes random acess, and anyway you need extra circcuitry to bankswitch CHRRAM wich cannot exed 8kb without any extra logic, and this remove the other advantage of having SRAM (have more work RAM to bypass the very limiting 2kb of the NES, to decompress data, etc...).

Also I don't think any 16kb RAM chips exists, you'd either need to have a 32kb one, or to use only a 8kb one, biut that means your game has almost no room for graphics.

If one would do the choise to save money and have slow acess times, he better have to use an EEPROM, so it saves the battery, and still allow graphics to work normally.

I did not meant to "emulate" the lockout chip, but rather to provide info about the region and all, wich means about the same.
Effectivly, one bit for licenced/unlicenced, onother for video standard and the third for the sub-region of a video standard would seem pretty good.

[hap]

Bregalad: mapper 16 Bandai games use several types of EEPROM chips (that I can't find any documentation of by the way).

I like your proposal kevtris, nice step forward from the chaos in this thread. A next step would be an official mapper list, including sub-mappers, backwards compatible with the current GoodNES. (not sure what should be done with semi-official ones unknown to GoodNES like mapper 155 (MMC1 without WRAM protection), or mapper 210 (N106 stripped down) )

[Bananmos]

Out of curiosity, how would "odd possibilities" such as a cart with an extra CPU containing custom code be handled? (Squeedo comes to mind, but I seem to remember talk about some japanese speech chip that would also fit in this category, even if the data would be samples rather than code)

I reckon you could get away with the hack of putting such "external ROM" data among the PRG or CHR pages, since such a cart would use a custom mapper number anyway and an emulator that supports it would know which pages are not PRG/CHR but "external ROM" data. Even if it's an ugly hack, it seems to be the best way to allow such games to be supported in iNES without using external files.

I'm still not convinced what would be the best solution, Kevin's proposed extension or a UNIF footer at the end of the iNES file. The last alternative has the advantage of being more easily upgradable, but the first one might just be more realistic due to its minimalistic approach.

Still, the list of possible RAM sizes leave a lot to be desired, since the probability of encountering a cart that uses two SRAM chips (say a 32kB + 8kB combination), and thus doesn't fit in the category, is about as high as encountering a cart that uses the 4kB or 1MB SRAM size. It seems to me these definitions try cover all possible/likely cases, but fail none the less. Maybe we CAN'T cover every possible case with a fully backwards compatible format, but then at least we shouldn't pretend it's doable.

Though I suppose any of the alternatives would be decent, if only we'll see less talk and more action on this matter. ;)

[tepples]

This forces the game to have no graphics when it saves and when it resumes the saved game

But is it an issue? Save/load during vblank, or fade to black (commonly seen when sleeping in an inn in an RPG).

, this removes random acess, and anyway you need extra circcuitry to bankswitch CHRRAM wich cannot exed 8kb without any extra logic

Which may already be present in your mapper ASIC if it is also used for games with CHR ROM.

Also I don't think any 16kb RAM chips exists, you'd either need to have a 32kb one, or to use only a 8kb one, biut that means your game has almost no room for graphics.

8 KiB for CHR + 8 KiB for each of 3 save files = 32 KiB.

[kyuusaku]

Why shouldn't SRAM size be defined by the board/mapper? Since the bankswitching will be mapper specific, it makes sense to me for the size to be mapper-defined. If you can make an NROM with 16k of SRAM, what does that mean? 16k SRAM games can't be assumed to work the same like they are with 8k SRAM. Would a 16k SRAM NROM game be legal in this new format?

It doesn't make sense to me, I think the only stuff that should go in a header are things that can apply to any game.

I think a new format also needs provisions for expansion audio and a way to store audio samples if present.

Adding all these new bits just makes more things to enter.

[BootGod]

While kev's proposal looks good, certainly the best ines upgrade I've heard yet, I'm still leaning towards the UNIF footer idea. It would be more easily incorporated into current apps and has the ability to store so much more.

Like kyuusaku said, audio data could be stored in a block. For VS. Unisystem, dip switch info could be stored in a block and maybe a palette block as well. It would be nice if an emulator did not have this info hard-coded.

[Bregalad]

Would a 16k SRAM NROM game be legal in this new format?

It would make no sense, but technically it would be doable, just like now you can do a NROM card (mapper 0) with 256kB PRGROM for example, wich aslo make no sense. There isn't much issue with that, just don't use nonsense header combinations. Most emulators currently just give error messagebox if a nonsense header is found, so I don't think that would change.

I think a new format also needs provisions for expansion audio and a way to store audio samples if present.

The provisions for expansion audio have nothing to do with the format, but with the mappers themselves. Also, if any samples are used, the game HAVE to store them in ROM, huh ?
For complex mappers (Squeedo, etc...), I just think the emus could use a plugin system. This would allow easy implementation of newer version of the same mapper, and is easy to use for both emu developpers and users.

But is it an issue? Save/load during vblank, or fade to black (commonly seen when sleeping in an inn in an RPG).

Now you said that, I think this is kinda interesting. After a bit ot thinking it is a very good idea after all. You just save a chip, and for the only price of a bit slower acess times and forcing to fade to black when saving/loading games. The only main problem is the deletion of random acess, wich definitely is a pain. You just cannot load a file of 8kb : Where do you want it to load ? You don't have RAM for that, the NES has only 2kb. So you must load it in another part of CHRAM, and you can only read that in VBlank via a complex buffering system, same for writing. This is a pain, but it still saves a chip.

[kyuusaku]

It would make no sense, but technically it would be doable, just like now you can do a NROM card (mapper 0) with 256kB PRGROM for example, wich aslo make no sense. There isn't much issue with that, just don't use nonsense header combinations. Most emulators currently just give error messagebox if a nonsense header is found, so I don't think that would change.

You can currently make a NROM with 8k SRAM which works in most emulators. My point is that there's no point in defining SRAM size in the header if it's all up to the board anyway. In other words I'd rather see a 8k version of Mapper A and a 16k version of Mapper A than SRAM size bits. MMC1 and MMC3 normally only have provisions for 8k or smaller SRAM, if somebody decides to create a game which uses 32k, a new mapper can be added since the logic will have to be anyway.

The provisions for expansion audio have nothing to do with the format, but with the mappers themselves. Also, if any samples are used, the game HAVE to store them in ROM, huh ?

No, I mean samples which are not necessarily accessible by the CPU at all, ones which are played back by other emulated hardware.

[Bregalad]

Effectivly, SRAM size depend of the board, but I disagree with you because a single mapper can have slightly different SRAM sizes, and also the same board can have SRAM that is battery backed to save the game or just additionnal Work Ram for the game.

For example :

Code: Select all

Zelda -> MMC1 -> SNROM; 8kb SRAM+battery
Kid Icarus -> MMC1 -> SNROM; 8kb SRAM

Both are the exact same, exept one has battery, 2 diodes and one resitior in addition. With the new system, one game will have 8kb save-RAM and 0kb work RAM, and the other one 0kb save-RAM and 8kb work RAM, as I undrstand things.

For the other thing :

Code: Select all

Caslevania III; Laser Invasion : MMC5; ELROM; no SRAM
Just Breed; Gemfire : MMC5; EKROM; 8kb SRAM+battery
Uncharted Waters; Napoléon L'emprereur -> MMC5; ETROM, 16kb SRAM+battery (only first 8kb batteried)
Romance of the 3 Kingdoms II : MMC5; EWROM, 32kb SRAM+battery

You don't want 4 different MMC5 mappers just because these only differs technically by their SRAM size ? That makes no sense to me.

Also, the new format allow 32kb Batteried and 8kb non-batteried or such combinations, wich are absolutely possible with a real MMC5 (but aren't used in commercial games, it would be possible to modify a ETROM board to gain such ability I think).

[kyuusaku]

Effectivly, SRAM size depend of the board, but I disagree with you because a single mapper can have slightly different SRAM sizes, and also the same board can have SRAM that is battery backed to save the game or just additionnal Work Ram for the game.

A board can only have different SRAM sizes if it matches the pinout and is smaller. The only time this can happen on original boards is with MMC5 (using a 6264/62256/62512 in the same socket.) AFAIK, no NES device can accept a universal DIP and configure itself to access it. Why is having a handful of MMC5s so bad? No matter what, mapper code has to implement the different sizes of SRAM and it's no more work to type in mapper 1XX than it is to define a SRAM size. In the grand scheme of things, there are VERY few variations of SRAM between the same board.

For example :

Code: Select all

Zelda -> MMC1 -> SNROM; 8kb SRAM+battery
Kid Icarus -> MMC1 -> SNROM; 8kb SRAM

Both are the exact same, exept one has battery, 2 diodes and one resitior in addition. With the new system, one game will have 8kb save-RAM and 0kb work RAM, and the other one 0kb save-RAM and 8kb work RAM, as I undrstand things.

Earlier in this thread I suggested having a nonvolatile bit to describe the SRAM. Having two definitions of the exact same thing (SRAM/WRAM) doesn't make sense. If a board were to have 4 separate SRAM areas, some volatile, some nonvolatile, that would again have to be described in a new mapper which defeats the new header feature's purpose.

You don't want 4 different MMC5 mappers just because these only differs technically by their SRAM size ? That makes no sense to me.

Yes because in the end it's far more economic than defining SRAM for the 4,000 ROMs with 8k battery backed RAM... It also allows for possibilities which this header is not capable of such as 4M of SRAM.

[Bregalad]

Well, I don't like doubling mappers. Maybe you could do something with sub-mappers, but I'm unsure how this works. I don't think SRAM size should be a part of sub-mappers, but should be defined as it in a byte reserved for it.
Also, even if no MMC1 card has ever had 32kb SRAM for example, it would be perfectly possible to build a card to handle that using the CHR selection line to select the SRAM banks. Bandits King of Ancient China does this with two 8kb SRAM chips, but one could have up to 32kb or even 64kb using the same trick. So if no submaper with that availability has been defined, the person who wants to devlop a MMC1 game that use a lot of SRAM will never be able to test his programm other than having a plugin for an existing emulator or to put all this together on a real cartridge. I found it would be better to keep the format open to anything new to just commercial boards.

[kevtris]

Wow ! Your new format looks pretty decent.
However, I've some minor problems with it :

- What on earth are those PPU types ? I've never heard of that. Normally, a NES game should work with all PPU revisions, huh ?

The Vs. system games use a bunch of different PPUs to prevent arcade operators from burning a new set of EPROMs to update their games.

The differences are approximately like so:

RP2C03x, RC2C0x:

Standard RGB palette, very similar to that of the regular PPU found in NTSC consoles... however 1 or 2 colours were changed on a few of them.

RP2C04-000x

These PPUs have scrambled palettes and extra colours. A good example of this would be Vs. Ice climber or Vs. SMB, or Vs. Gradius... all three use various forms of the RP2C04 PPU, and if you play these games with the regular palette, it looks like an acid trip

Each of the four PPUs has a different scrambling of the palette, and a few differences in the colours. I have dumped all four bit for bit accurately using a special device I made.


RP2C05-0x

These five PPUs have the stock palette (as far as I know, except I have not seen 2 of the chips). The difference here is register 2000h and 2001h are flipped around. Also, reading 2002h returns the usual three bits in D5 to D7 (VBL, sprite overflow, sprite 0 hit) but the lower 5 bits are different depending on the -0x revision. Games check these bits, and crash or fail to start if they are wrong.

- Why CHR-RAM could be battery backed ? I don't see much interest with that. What game could have any use of this ? To save space, a game would write all its save to the CHRRAM ? That make no sense to me, while technically possible.

That bicycling game cart, Racermate does. It has 64K of CHR RAM- 32K is battery backed, the other 32K is not. They store all the stats and such in this RAM. Why they battery backed CHR RAM, I don't know... but it DOES exist

- Why CHR-RAM/SRAM size could be less than 8kb (exept 0kb) ? I doubt any 128-byte RAM chips are used in any NES game. I think less bits would do for the RAM size.

Because the EEPROMs used on some Japanese games are only 128, 256, or 512 bytes. Also, the MMC6 RAM is only 1K. This covers all possible bases, and costs nothing to implement. Having a range of 128 bytes to 1Mbyte is very decent IMO and shouldn't be a problem.

- More info on what exactly "submappers" would look like would be welcome.

Yeah I was kinda holding off until I got some feedback.. but here is where it's really needed.

For example, there are multiple kinds of MMC1 cartridges- "regular", 16K of WRAM (8K battery backed, 8K not), Dragon Warrior 3/4 (512K of PRG ROM), and games which require WRAM to always be enabled ("The Money Game" and a few others, Japanese only).

So the submapper for MMC1 would be something like...

0 - normal MMC1.
1 - 16 WRAM present (a few Koei games do this)
2 - 512K of PRG ROM present (DW3, DW4)
3 - WRAM write protection disabled

It might be better to make the "WRAM protection disabled" a bit, so it could be turned on and off by itself, regardless of the other modes. The 16K of WRAM and 512K of PRG ROM though are mutually exclusive, since they use CHR ROM mapper bits.

- Why don't put a bit that tells if the cartridge is american on japanese ? Both are NTSC and there isn't much difference in emulation issues, but I guess it would still be cool to have that.

Something like 3 bits :
000 -> Japan, NTSC
001 -> America, NTSC
010 -> Europe, PAL
011 -> (Australia ?), PAL
100 -> Pirate/Homebrew/Unlicenced, NTSC
110 -> Pirate/Homebrew/Unlicenced, PAL
111 -> Pirate/Homebrew/Unlicenced, support both video standards

Maybe, but that doesn't directly help emulation per se. I'm not opposed to such things though.

Emulators could just look the middle bit to know if they must emulate PAL or NTSC, or have a more complex system to emulate all regions... ?

Yah... I'm not 100% sure about regioning... The only thing really enforcing regions is the lockout chip, and NTSC/PAL.

Other than this, it looks great.

EDIT : Totally outtopic, but I'm very curious to know wich games use EEPROM instead of RAM+Battery to hold saves. Wich mapper support that ? Are those licenced games or only pirate games ?

That is mapper 16. Yes, licensed games by Bandai... I'm not 100% sure on titles at the moment, but there's around 10-12 that use it. There are two kinds of EEPROM they support- I^2C and a different, similar format. Look up the datasheet for the 24C02 to get an idea of what they are doing.

I emulate both styles of EEPROM in my console and it works great.

Unfortunately, mapper 16 is really something like 5 or 6 different mappers :-/

[WedNESday]

Also on the mappers issue, I have made an absolutely comprehensive mapper guide vs. mapper number which I will be posting to my page at some point. It lists every single implemented mapper number, where it can be found, and what it is composed of. Everything on it has been tested and revised, since it was produced when I made the FPGA NES.

Annnnnnnny chance of you releasing that any time soon? I don't mind if it is not finished, and I think that it will help us all discuss a new format.

[blargg]

Also, even if no MMC1 card has ever had 32kb SRAM for example, it would be perfectly possible to build a card to handle that using the CHR selection line to select the SRAM banks. Bandits King of Ancient China does this with two 8kb SRAM chips, but one could have up to 32kb or even 64kb using the same trick. So if no submaper with that availability has been defined, the person who wants to devlop a MMC1 game that use a lot of SRAM will never be able to test his programm other than having a plugin for an existing emulator or to put all this together on a real cartridge.

How would an emulator know how you wired up your 64KB RAM?