nesdev.org

As I said last time, I think I do like best the answer of "if there's ASIC-internal RAM, it doesn't get counted in the header unless it's necessary for disambiguation (i.e. MMC6)"

And I think that's what you've settled on?

Obviously with Taito's X1 mappers it's irrelevant: mapper 80 always has 128 bytes of RAM, it's always battery backed, if the header specifies anything else that's not well defined so (for good and ill) the header can then be ignored.

tl;dr sgtm?

No, and you did not answer the other points I made about serial EPROM either.

Well, that was a waste of time. Sorry I asked you anything.

Yeah, if there's only one possible value for the field, I don't think we need to have a specification for it. Doesn't matter what goes there. 0, 128, 256, whatever, the emulator will have to ignore it anyway. The FCG mappers don't seem to have capability of varying sizes for mapper? Why specify?

It also says we should round up for mapper 82's 5k internal, but again the size is fixed and incompatible with normal WRAM. I sort of feel like we shouldn't even mention it, because it just complicates the spec. (Now we have to think about rounding up everywhere else? For this one case where the value is implicitly known anyway?)

(Also, like I was saying before, unless you're using iNES 2 header to disambiguate something else, there's no need to even use this header for RAM sizes that don't need disambiguation. iNES 1 is fine.)


I feel like a lot of this was written with the idea that NVRAM size was supposed to correspond to how much data you need to save to disk, but I think the power-of-2 constraint sank that already.

I actually did think that NES 2.0 should be used, or at least able to be used, for all ROM images, instead of a weird messy mix of NES 1.x and 2.x headers and 2.x headers only used when absolutely necessary. Oh well.

rainwarrior wrote:I feel like a lot of this was written with the idea that NVRAM size was supposed to correspond to how much data you need to save to disk, but I think the power-of-2 constraint sank that already.

Relying on the NVRAM size field to know how much to save to disk is merely the way it is currently implemented in most NES 2.0-supporting emulators, so maybe it's indeed an absurd assumption.

I mean, I do think we should encourage the use of NES2.0 headers everywhere.

And, in hindsight, I do see how both Nintendulator's code base and kevtris's recommendation to round up to powers of two are mutually consistent... I just don't personally like it.

With the repeated (and sometimes unmarked) edits to all the posts, small wonder everything's gotten confusing. It's hard to have a coherent response when the current contents of the thread are only 50% the same as what was there the first time I read it.

I like the current contents of your FCG specification, which I'm going to quote just so that it can't be edited out from under me again:

NewRisingSun wrote:The Mapper 16 page would state: "Some games have 256 bytes of serial EPROM; they must have the NES 2.0 PRG-NVRAM field set to 256 and the battery bit set. Games without serial EPROM must have the NES 2.0 PRG-NVRAM field set to 0 and the battery bit not set. Games with 128 bytes of serial EPROM must use Mapper 159."

It is probably also worth mentioning the planned submapper for FCG-1 and -2 behavior here, too.

The Mapper 159 page would state: "This mapper is only used for games with 128 bytes of serial EPROM. Although redundant, for consistency with Mapper 16, they must have the NES 2.0 PRG-NVRAM field set to 128 and the battery bit set."

The Mapper 157 page would state: "The Datach unit has 256 bytes of serial EPROM which is shared among all Datach games. The battery and PRG-NVRAM fields of the NES 2.0 header do not refer to the Datach unit, but only to the game cartridge itself. Only Battle Rush: Build Up Robot Tournament has an additional 128 bytes of serial EPROM in the game cartridge itself. This means that all other Datach Games must have the battery bit clear and PRG-NVRAM set to 0. The emulator, when seeing mapper 157, will maintain a common 256-byte save file for all Datach games. For Battle Rush: Build Up Robot Tournament, the battery bit must be set, and PRG-NVRAM must be set to 128. This causes the emulator to emulate the second game-specific EPROM in addition to the common Datach unit EPROM." Right now, Mapper 157 is another ambiguous case, and this proposal would rectify that.

Actually, yeah there's definitely reasons to use the new headers for almost everything. The region flags alone are a probably worthwhile even if there's nothing else to disambiguate.

I tried to reorganize Byte 10, trying to make the "normal" $6000 case as clear as I can, and otherwise grouping the exceptions as they appeared to be organizable. Not sure if it lists everything, but I think has the important groups at least. The more fiddly details can probably be clarified on the mapper pages.

I separated N163 (internal RAM + standard PRG-RAM) from other things with Internal RAM, which seems to make usage otherwise consistent.

There might potentially be another group for "boards that have register conflicts and need 0 in this field", but the only one previously mentioned was JF-13 and I'm not sure if that's really a conflict. (Does a write register overlapping the PRG-RAM region actually prevent its use?)

"Again". I have not edited out anything of substance out of my posts, only added to them. I try to verify that the person to whom I am responding is not listed as currently reading the forum before making an edit, but that is unreliable because many users hide their online status. I suppose I will then always make my amendments as separate replies for safety.

So there is agreement that the N163 internal RAM should never be included in the PRG-RAM and PRG-NVRAM fields. As I understand, there is also agreement that only Datach Battle Rush's additional serial EPROM is included in the PRG-NVRAM field, and the other Datach games have no battery bit and a zero PRG-NVRAM field. There is still disagreement about whether Mapper 16's and Mapper 159's serial EPROM should be denoted in the PRG-NVRAM field nor not. One needs to definitely denote whether a mapper 16 game has EPROM or not, but that could be done with the battery bit alone. I am also not certain what the conversation status regarding the Taito mappers is.

I would say that only after these particular decisions have been made will it be possible to reformulate a general rule about the NES 2.0 PRG-RAM/NVRAM fields. Only this much: if the general rule were to be "exclude ASIC-internal RAM and EPROM unless necessary for disambiguation", then MMC6 would be denoted with zero PRG-NVRAM, because mapper 4 submapper 1 already disambiguates the MMC6 from the MMC3.

I think the general rule should just be if PRG-RAM at $6000 is possible, use the field for only that. (i.e. this leaves the option to cleanly add or remove PRG-RAM with stuff like UNROM 512, N163, etc.)

Otherwise the things that overlap/conflict PRG-RAM I don't really see a problem with redundantly specifying the size in byte 10, even though it's dictated by the mapper already. Worst case the field just gets ignored, because it doesn't really matter what you put there. (I think in all of these cases the mapper trumps it anyway?)

The symmetry for MMC6 to use that field is sort of "nice". The FCG things seem to have it in the same place as PRG-RAM so maybe it's not that bad. The whole thing about rounding up for the 5k Taito board is weird, but I guess it's fine.

There may be some other special cases, but it doesn't really seem too inconsistent to me. (Though I would think it's equally okay to say to use 0 in these fields if it's not standard PRG-RAM... but maybe a moot point anyway since the mapper already pre-decides the real sizes.)


I did add a note that the PRG-NVRAM field can't tell the whole store about how much data to save. Maybe using it for the overlap/conflict cases helps keep the number of cases it doesn't work a little bit smaller, though.

The Bandai boards indeed access the serial EPROM at $6000-$7FFF, but that is only where the serial register lies; it's not that the content of the EPROM itself is directly mapped there. Famicom Jump II of course being the exception.

My preference now has shifted towards not including the serial EPROM in the PRG-NVRAM field, except to disambiguate Datach Battle Rush from th other Datach games. For Mapper 16, the battery bit alone should disambiguate between LZ93D50 without serial EPROM and LZ93D50 with serial EPROM, while the submapper I proposed should disambiguate between FCG-1/2 (which does not support serial EPROM) and LZ93D50.

I am moving towards the general rule of "PRG-RAM/PRG-NVRAM only specify what the mapper and submapper do not already necessarily imply. The battery bit on the other hand must be set even if the mapper is never seen without a battery or EPROM." Advantage: simplest to explain, and consistent for all mappers. Disadvantage: compatibility --- breaks emulators that look at PRG-NVRAM alone to know how many bytes to save, such as Nintendulator.

NewRisingSun wrote:There is still disagreement about whether Mapper 16's and Mapper 159's serial EPROM should be denoted in the PRG-NVRAM field nor not. One needs to definitely denote whether a mapper 16 game has EPROM or not, but that could be done with the battery bit alone.

Mapper 16 has three variants, if I remember correctly:
FCG-1/2 ; necessarily no EEPROM
LZ93D50 , no EEPROM
LZ93D50 , X24C02

rainwarrior wrote:The FCG things seem to have it in the same place as PRG-RAM

This is basically why I think the canonical value for mapper 16 with 256b I²C EEPROM should mark 256b NV PRG storage.

I am also not certain what the conversation status regarding the Taito mappers is.

As I understand it: canonical headers should mark 128 or 8k NV PRG storage as appropriate. Emulators probably have to ignore other values as nonsense.

NewRisingSun wrote:I am moving towards the general rule of "PRG-RAM/PRG-NVRAM only specify what the mapper and submapper do not already necessarily imply. The battery bit on the other hand must be set even if the mapper is never seen without a battery or EPROM." Advantage: simplest to explain, and consistent for all mappers. Disadvantage: compatibility --- breaks emulators that look at PRG-NVRAM alone to know how many bytes to save, such as Nintendulator.

The other disadvantage is that it re-opens the decision to deprecate MMC1 submappers 1, 2, and 4.
... and to some lesser extent, asks why the PRG/CHR NV/S RAM fields are present at all rather than specified by the submapper.

So to summarize: The PRG-RAM status quo remains except for Mappers 19 and 157:

• N163's 128 bytes of internal chip RAM do not get denoted at all in the NES 2.0 header;
• the Datach unit's common 256 bytes of serial EPROM do not get denoted in the NES 2.0 header;
• every other RAM or serial EPROM that is neither CHR-RAM nor VRAM gets denoted in the NES 2.0 header, be it internal, external or whatever.

Also:

• Submappers 16.4 and 16.5 distinguish between FCG-1/2 and LZ93D50, while submappers 16.0-16.3 remain listed but marked as deprecated;
• Submappers 19.2, 19.3, 19.4 and 19.5 distinguish between N163 with no/+12 dB/+16 dB/+18 dB expansion audio;
• Submapper 19.6 may be added in the future if we get another Namco Classic II cart, find it similar to mine and decide that it deserves its own submapper;
• Submappers 19.1 and 19.9 remain listed but marked as deprecated.

Did I miss or misunderstand anything?

I also promised emulated samples of Rolling Thunder with the N163 at +16 dB vs. +18 dB. Using the ABX Comparator Plugin in Foobar2000, I identified 16 out of 16 correctly, indicating that the difference is indeed audible.

NewRisingSun wrote:19.9 remain listed but marked as deprecated.
Did I miss or misunderstand anything?

19.9 was only ever hidden as an HTML comment on [NES 2.0 Submappers] or on the proposals list. I see no need to retain it in any form.

I also promised emulated samples of Rolling Thunder with the N163 at +16 dB vs. +18 dB

[listens, can also hear the difference] Fair enough!

If rainwarrior agrees as well, then I am going to make the changes to the wiki. While I am at it, I plan to also more cleanly separate the N163 from the N175/N340 pages, since people (including myself) are getting confused by the current structure.

NewRisingSun wrote:If rainwarrior agrees as well, then I am going to make the changes to the wiki.

Umm, I am not entirely sure what encompasses what I am being asked to agree to, but I'll try to outline it:

1. Mapper 19 submappers: the plan seems fine, as I understand it. 1 = deprecated (implies no WRAM + battery, no audio), 2 = no audio, 3-5 = low/mid/high audio. (The specific dB we might tweak if we get more sample data.)

2. Separating mapper 19 and 210 into individual pages: probably fine, would probably be just as good to more clearly organize the differences on the same page.

3. iNES 2 Byte 10 usage

"N163's 128 bytes of internal chip RAM do not get denoted at all in the NES 2.0 header" - I agree this is the best way to do mapper 19.

"every other RAM or serial EPROM that is neither CHR-RAM nor VRAM gets denoted in the NES 2.0 header, be it internal, external or whatever." - I wouldn't suggest a general rule to this effect, but in practice I would agree about this for all the mappers listed, I think?

What I did suggest is that if PRG-RAM in a mapper is present at this location, or can be trivially added due to lack of conflict, then these bytes should only refer to that. Mapper 19 / N163 is definitely included by this guideline, because PRG-RAM can be added separately. Same deal with the EEPROM homebrew mappers. (The idea of PRG-RAM being added to both UNROM 512 and GTROM has been openly discussed... I suspect it will happen eventually.)

Otherwise, in all cases I'm aware of, it seems like the mapper designates a fixed size anyway so this field becomes redundant. The question of how to use this field when it is redundant I do not have strong opinions on, but...

I would say that at least in the case of MMC6, I think there is some intuitive value of putting 1k in this field to treat it like "standard" PRG-RAM. (...and I suspect some emulators may already be depending on this particular value.)

For FCG stuff, byte 10 can't refer to standard PRG-RAM at $6000 for these mappers, so if we want to reuse this field for some coarse save-RAM size designation, probably fine. Similarly if you put 0 in the field here, the mapper overrides what really goes there anyway. Doesn't matter much. I'd vaguely lean toward "okay, put 128/256 in byte 10" but only vaguely. The additional EEPROM for Datach I don't think I've spent enough time thinking about to really weigh in on. (The documentation is so scattered and confusing that I am not confident I understand all the issues around these games at this point. The Datach thing seems like such a huge special case that it seems like you need a lot more than just a header to solve the problem.)

If there was some other mapper that turned out to have variable sizes of internal RAM somewhere else and could also support PRG-RAM at $6000, then maybe we'd have some special case to think about, I don't know, but I don't really care about this until it comes up. Other weird stuff could come up in the future. I don't expect there to be a general rule that can solve all our problems with this field until the end of time. It's okay to me if one case ends up being different.

4. "Submappers 16.4 and 16.5 distinguish between FCG-1/2 and LZ93D50, while submappers 16.0-16.3 remain listed but marked as deprecated;"

A deprecated submapper that refers to a different iNES mapper is pretty easy to implement for an emulator author, IMO. E.g. 001:3 seems fine to me, so it also seems fine here.

rainwarrior wrote:The additional EEPROM for Datach I don't think I've spent enough time thinking about to really weigh in on. (The documentation is so scattered and confusing that I am not confident I understand all the issues around these games at this point. The Datach thing seems like such a huge special case that it seems like you need a lot more than just a header to solve the problem.)

To the best of my knowledge, the additional EEPROM in the Datach base station is specifically to hold half the save data for Battle Rush. One can move one's combatant between the base station and the cart, and this lets you bring your fighter to other people with base stations and/or carts.

As such, the save data more-or-less has to be split into two files to be fully useful.


Caveat: the above might actually be a fever dream rather than having any basis in fact. I just think I remember reading someone saying it worked that way.