Battle Fleet, Famista '90, Kaijuu Monogatari, Mindseeker

http://bootgod.dyndns.org:7777/profile.php?id=3344
http://bootgod.dyndns.org:7777/profile.php?id=1602
http://bootgod.dyndns.org:7777/profile.php?id=1599
http://bootgod.dyndns.org:7777/profile.php?id=3842

There is a battery but no external RAM on the circuit board. Looking at what addresses Battle Fleet accesses when saving the game, it seems that the battery powers the 128 bytes of the Namco 163 chip that other games use for sound generation ($4800). How would this properly be described in the NES 2.0 header? The PRG-NVRAM field seems to always apply to the $6000 range, and the 128 bytes of the Namco 163 chip are emulated in all emulators regardless of the PRG-(NV)RAM field's content.

We haven't decided... see my comments on the wiki.

Reproduced here for ease of threading:

Having taken a closer look at all battery-bearing Mapper 19 games, no game seems to use both chip RAM and WRAM to store save data:

Games with battery that only powers the internal 128 bytes of chip RAM. They can be easily represented by setting PRG-NVRAM to 128 bytes:

• Battle Fleet
• Famista '90
• Hydlide 3: Yami Kara no Houmonsha
• Kaijuu Monogatari
• Mindseeker

Games with battery that powers only 8192 bytes of WRAM and use chip RAM for audio and thus cannot use it for save data. They can thus be represented by setting PRG-NVRAM to 8192 bytes and PRG-RAM to 128 bytes (the latter for consistency):

• Digital Devil Story: Megami Tensei II
• Sangokushi: Chuugen no Hasha
• Sangokushi II: Haou no Tairiku
• King of Kings

NesCartDB does claim that King of Kings backs both chip RAM and WRAM, but that seems implausible given that the game uses expansion audio and has well-working save/restore in emulators that do not save chip RAM.

Juvei Quest has a battery that powers only the 8192 bytes of WRAM and doesn't access the chip RAM at all, especially not during restore/save. It can thus be represented by setting PRG-NVRAM to 8192 bytes and PRG-RAM to 128 bytes, since the chip registers do not need to be saved.

Dokuganryuu Masamune has 8K of WRAM which is not battery-backed. Accordingly, when selecting CONTINUE, only the 128 bytes of chip RAM are accessed, and during saving, the game state is output to chip RAM. This game can thus be represented by setting PRG-NVRAM to 128 bytes and PRG-RAM to 8192 bytes, since WRAM is not battery-backed.

If someone could confirm that King of Kings' chip RAM is not battery-backed, contrary to NesCartDB's entry, then the problem of 8192+128 NVRAM would not exist, and the NES 2.0 headers of these games would be as described.

With the N163, it's not possible to battery-back the 8 KiB PRG RAM without also battery-backing the 128B audio RAM.

I mean, there's basically three options here for the value desired in the header, right?



Option 1, per the "round up" rule, produces non-intuitive results. There isn't 16 KiB of anything.
Option 2 is internally inconsistent: the 128B are marked when they're the only thing present, but ignored when they're not.
Option 3 also has non-intuitive values. But it does accurately represent the amount of memory added.

I kinda like option 3 better ... it feels more uniform if the correct value for mappers with ASIC-internal storage is that they aren't counted.

No, there's a fourth option, which is the one I like best: for battery+WRAM games, pretend that the N163 isn't battery backed (B10=$71), even though it actually is, because it isn't used for save data, and so an emulator doesn't need to save it. It's only non-intuitive if you think of the NES 2.0 header as an all-purpose hardware description as opposed to a a set of instructions for an emulator.

If that is too kooky for you, then I opt for option 1 --- rounding up to 16K in the NES 2.0 header, and having the mapper code adjust the actual size of the SRAM file. Option 3 is bad for a Nintendulator Mapper DLL because the sum of PRG-RAM and PRG-NVRAM defines the maximum size that the SRAM file may take, so one would have to modify the main emulator core to implement such a thing. It would also create an inconsistency between Mapper 19 and the MMC6, which doesn't add any external WRAM on the PCB either.

Surely that knocks out option 2, also?

I'm still uncomfortable with option 1.

There's certainly some merit to saying that the header value should indicate how it's actually used. It would resolve the Datach mess neatly—mark with $20 for the (singular, pack-in) game that uses the internal EEPROM, and mark with $10 for the games that use an external EEPROM.

On the other hand, it drastically increases the amount of effort that someone has to go to in order to choose a correct set of headers. It's not just enough to say "this is what's present" but now you have to exhaustively analyze the game to make sure whether something nonvolatile is never used. Is this an acceptable cost?

How about redefining value $F, which so far is "reserved", to something useful for this purpose. How about defining value $F to mean "mapper-specific size"? It would be defined as 5120 for Mapper 82, 8320 for Mapper 19, and 384 for Mapper 157. One would still have to modify the core emulator executable for this purpose (similar to options 1 and 2), but at least it would be for something that is clean and precise.

Tentatively, I like that, but I should sleep on it to see if I still think that sounds good tomorrow.

Alternatively, maybe some emudevs (Sour? Fhorse? YoukaiCountry? zeroone?) could pop in and offer an opinion?

I'd be tempted to say we shouldn't use the prg ram bits to count built-in mapper RAM that cannot be removed from the cart, but only any optional RAM that can.
e.g in this case, it will always have that 128 bytes of internal ram, there isn't even a way to remove it from the cartridge, so from my point of view, that's more or less part of the mapper's definition.

If the worry is to indicate whether or not that ram is battery backed, a submapper might be good enough? e.g: submapper 0: use battery flag, submapper 1: not battery backed. This would apply well to mapper 19 & 82, imo.
157 on the other hand is eeprom, so always "battery-backed" - since there are different non-standard memory sizes available for the mapper, submappers might be sufficient here too?

Using reserved as "mapper-specified" ends up having to use submapper numbers to specify different sizes if needed, too, so we might as well just use submappers directly and avoid using that altogether.

Just my opinion - I'm far from an expert on mappers, after implementing hundreds of them, you kind of lose track of what you did implement :p

So far I have regarded the PRG-NVRAM field always as a "size of the save file" field, and so does the Nintendulator main executable. Changing this definition to mean additional NVRAM would be a major change in that intuition, and would lead to MMC6, Mapper 80, 82 and several Mapper 19 games having the battery flag set with PRG-NVRAM value of "0", which even in the knowledge of its meaning bothers me greatly. It would also break compatibility with existing NES 2.0 emulator implementations that do assume that PRG-NVRAM also include internal RAM.

I'm opposed to excessive submapper use because you would be using the submapper to reflect something that the other fields are already supposed to reflect, but cannot because of the stupid decision (sorry for being blunt) to define the fields as powers of two. My proposal of using the previously reserved value 0xF as an "Other", with the mapper number providing the actual oddball size, would merely rectify that mistake for the rare cases where it's needed. It would keep compability with existing NES 2.0 emulator implementations for all games that do not use oddball sizes, because value 0xF has always been "special".

Sour is right in theory that one would have to use submappers anyway if there were more than one oddball size per mapper number. But in practice, there is no reason to believe that there is. So far, no unlicensed game is known that uses oddball NVRAM sizes at all, and only three mappers --- 19, 82 and 157, are known to use one oddball size per mapper number. And in the unlikely case that one turns up, we can go back to the submapper idea for those few cases after all.

Still yet another proposal could be to go for the 0xF value as "Other", but instead of then deducing the actual oddball size from the (sub)mapper number, one could define another header field to specify the exact size in some way. For example, PRG-NVRAM value 0xF could mean that the PRG-RAM value nibble no longer specifies the power-of two non-battery-backed RAM size, but one of sixteen pre-defined RAM-NVRAM-configurations having oddball sizes, e.g. 0x0:=8320 bytes NVRAM/0 RAM, 0x1:=5120 bytes NVRAM/0 RAM, 0x2:=384 bytes EEPROM, 0x3-0xF reserved for future use.

Let's see what the options proposed so far are (correct me if I misrepresent them):

1. Include internal and external NVRAM in PRG-NVRAM field, always round up for oddball sizes. (Current NES 2.0 specification)
2. Include internal NVRAM in PRG-NVRAM field only when there is no external NVRAM. Prevents oddball sizes resulting from the sum of internal and external NVRAM. Oddball sizes resulting from other reasons (Mapper 82) are still rounded up. (Lidnariq)
3. Only include external NVRAM in PRG-NVRAM field. The mapper code itself has to know how many bytes of internal NVRAM to add. Will result in several headers with battery flag set and a PRG-NVRAM size of "0". If necessary, use submappers to denote if internal RAM is not battery backed but external RAM is. (Lidnariq, Sour)
4. Include internal and external NVRAM in PRG-NVRAM field, use PRG-NVRAM value 0xF for oddball sizes whose actual value is derived from the mapper number, and should it be discovered that there are several oddball sizes for one mapper number, also from the submapper number. (NewRisingSun)
5. Include internal and external NVRAM in PRG-NVRAM field, use PRG-NVRAM value 0xF for oddball sizes whose actual value is one of sixteen pre-defined configurations chosen by a repurposed PRG-RAM nibble. (NewRisingSun)

Thank you for compiling them, so that one of us can take the list to kevtris in #nesdev for his thoughts.

Has kevtris given his thoughts in #nesdev within the past two months?

You can add kevtris to proposal B, which I described to him as "Include mapper RAM in the count only if no dedicated RAM chip. This would mark the game as having 8192 bytes, to which the emulator adds 128 bytes because of mapper 19."

Thank-you for consulting him.

I am not comfortable making a decision about Mapper 19's NVRAM though until it is fully understood how the Save process in Dokuganryuu Masamune works, in particular, the role of the extra glob-top chip on the board. The Save procedure basically writes 126 bytes of data both to $4800 (the write address of the N163's wavetable RAM) and to $6000 (not indexed!) in the same loop. When selecting Continue, the 126 bytes are only read from $4800, not from $6000.

Battery-backed wavetable sample ram? Now I've seen everything.

There are a significant number of 163-using games (edit:) that battery-backed the wavetable RAM and used it to store save data instead of using it for audio. List on nesdevwiki:iNES Mapper 210 ("internal").

Should SRAM files be interchangeable between emulators? If so, then it needs to be specified whether internal or external NVRAM data comes first. For compatibility with existing emulators that do not save the N163's internal RAM at all, I suggest that external NVRAM comes first.

Not knowing about this thread, I unwittingly continued this discussion over here:
Namcot 163/MMC5/Konami VRC6 Audio Level test program

Though probably if you were looking for the continuation you'd want to fast forward to NewSunRising's restatement here (most of the stuff before that is about audio, and then a bunch of me being confused).
https://forums.nesdev.com/viewtopic.php?p=222934#p222934

Maybe I am asking the dumb question, but: should EEPROM-bearing games have the iNES "Battery" bit set (in addition to having the EEPROM size in the NES 2.0 PRG-NVRAM field)? The NES 2.0 wiki page seems somewhat ambiguous about this.

Maybe the battery bit should be set for SRAM and not be set for EEPROM. There is a field for "battery backed" WRAM in the NES 2.0 header and a field for the non-battery backed WRAM. Right now we distinguish between EEPROM and SRAM by size, SRAM generally being 1K or larger and EEPROM being smaller than 1K. I only know of 128B and 256B varieties of EEPROM used in licensed Famicom games, perhaps some of the unlicensed or bootlegs may use more. I believe 2K was the smallest discrete SRAM chip used in licensed cartridges, I can't speak for the unlicensed stuff beyond what I put in my list. There could conceivably be some game out there that uses a 1K SRAM chip and another game that uses a 1K EEPROM, so the battery bit may be the key to distinguishing what type of chip to emulate.