Namcot 163/MMC5/Konami VRC6 Audio Level test program

I have finished my first "hot-plugging" program. It displays a white screen and beeps, expecting the user to exchange the RAM/Flash cartridge with an original Namco 163 Audio-equipped cartridge, then press A. It will play three 440 Hz tones: NES APU (gray screen), Namco 163 one channel (dark blue screen), Namco 163 eight channels (bright blue screen). I intend to acquire all ten of the games that use N163 Expansion Audio and record each one's output using the same hardware (Sharp Twin Famicom AN-505BK with clean audio mod; has nice APU vs. Expansion balance). That will provide a more precise measurement, using the exact same test tone rather than each game playing different music, of the relative volumes of the several games that use this expansion sound chip. This information then may help to update the Submapper proposal to reflect the relative expansion audio level of each game. Emulators can then let the user choose between original Famicom and GPM/AV Famicom APU vs. expansion sound levels.

The ROM has been successfully tested on real hardware, first by using an Everdrive N8 to upload the program to RAM, then exchanging the Everdrive with a Megami Tensei II cartridge and pressing A.
It sort-of works in most emulators, although most fail to honor the Sound Disable bit ($E000 bit 6), so they produce hanging notes when the screen goes black. Also, given the volume register value that I use, the one-channel and eight-channel test tone are just as loud; on emulators, the eight-channel tone is louder. Also on real hardware, the single-channel test tone sounds clean, while the eight-channel tone sounds "dirty", as expected.

Thanks for doing this. I'll give it a try later, though I only have 2 N163 carts. I think ideally we want to try a lot of N163 carts on the same hardware, since the relative mix across games is the most important information here.

I've been thinking NSFe could accomodate an optional chunk for N163 volume, and 2A03 square vs. equivalent is an easy enough thing to standardize the mix values on. Plus we could have Famitracker export an NSFe with a value that represents "FT standard mix" for it and people might stop complaining to me that NSFPlay doesn't match their Famitracker expectations.

(The other expansions don't seem to need it. 5B / VRC7 only had one game. FDS mixing wasn't part of the game. VRC6 had 3 games but I think they had a standardized mix, even though there's a lot of variance in the part tolerance.)

I think I should expand the program to play both APU and Namco 163 at all fifteen volume levels. Right now, the APU plays at maximum amplitude while the Namco 163 plays at minimum amplitude, which might not provide sufficient information when taking into account the NES APU's nonlinear mixer.

And here it is, all 15 volume levels for APU, N163 single channel, and N163 eight simultaneous channels. As before, the N163 waveform is one 32 sample/16 byte waveform consisting of 8 bytes $FF and 8 bytes $00.

When recording the output, it must be kept in mind that at the maximum volume, the N163 becomes much louder than the NES, up to eight times, depending on the particular mixing resistor on the game's circuit board.

When you catalog the cart volumes, would you be willing to open and read, or measure the resistance across, the AUDIO FROM 2A03 and AUDIO TO MODULATOR pins ?

It really ought to be the case that the resistor there should be the only thing that determines the loudness of the mix, but what data we have is inconsistent.

Is a simple $20 Ohmmeter sufficient for that task, or is something fancier required to do it correctly?

A $20 ohmmeter is more than sufficient.

I have now gathered all Namco 163 games except for Mappy Kids, which continues to be only available from overseas sellers. Since having to collect the package at the customs office is a long enough drive for me to want to avoid that at all costs, I would appreciate if a European-Union-based seller (or donor/lender) could offer for sale/provide me with a copy, so I can start making those test recordings from all games using the same console and setup.

I can already say that there must be several revisions of the audio circuit used on different runs of the same game. Sangokushi: Chuugen no Hasha is listed as having a 4.7k resistor, while I measure a whopping 32.82k on my cart. Other carts measure the same resistance as in that wiki article, so it's not my testing method being wrong. For that reason, I consider the proposed method of measuring relative audio levels between NES and N163 for all cartridges using that test program to be the more reliable choice.

I also have a hunch that later games seem to have their mixing resistors adjusted for the HVC-CPU-GPM console mainboard with its (relatively) louder expansion sound. The in-game expansion audio from Namco Classic II (1992) is almost inaudible against the RP2A03 on my AN-505BK Twin Famicom, and is just barely audible on a YouTube video recorded from (I think) an AV Famicom.

Yeah, I've long thought the resistor values weren't useful data (at least not by themselves). I don't think all versions of the N163 have equivalent output to begin with. Measuring the output volume relative to a single source is good.

Also, every time I've gotten measurements from two different carts of the same game there's been a significant difference anyway, and that's not even getting into carts that had multiple runs with different parts.

You can be confident that these are standard E24 5% resistors, so that's "just" 33k.

As announced, I have recorded the expansion audio output of all ten Namco games that use the N163's expansion audio capabilities.

I have also recorded two MMC5 games and one VRC6 game.

The test ROMs used for this purpose are attached. To be specific, I used the Everdrive N8 (60 pin edition) to load the test ROM into the CPU memory of my Sharp AN-505-BK Twin Famicom, then hot-swapped the Everdrive N8 with the cartridge to be tested. The output was recorded from the Audio Out socket to a computer's rear Line In with Audacity at 96 kHz, 16 bit. No normalization or level adjustment was done to the resulting audio files; all were recorded at the same input gain settings (which I have noted so I can repeat the procedure in the future).

The Twin Famicom has had the low-pass-filtering C205 capacitor removed for crisp(er) audio. A different console may have a different APU<->Expansion Audio balance, so it's the APU/ExpAudio ratio of the several cartridges relative to each other that is informative. Subjectively, all cartridges' balances sound great to my ears, with the exception of Namco Classic II, which has too quiet expansion audio, and which for some reason also low-pass filters the incoming APU audio.

All four test ROMs play a $02/$22 sample waveform on the APU's DAC waiting for a press of button A to be done once the cartridges have been swapped. Then they share the same one APU square wave channel playing at all fifteen non-zero volume levels, followed by:

• The N163 test ROM then plays fifteen volume levels using an FF 00 waveform, first while enabling only one channel, then with all eight channels enabled and all playing the same waveform simultaneously at the same volume. Since the N163 plays the channels sequentially, there should be no waveform clash. The test ROM makes use of the $E000 registers to disable all sound channels in the pauses in-between, which most emulators don't replicate properly.
• The VRC6 test ROMs (VRC6TEST for mapper 24, VRC6TESA for Mapper 26) then play fifteen volume levels of a single square wave, then fifteen volume levels of a single saw wave with the lower two bits of the six-bit "accum rate" register forced to 11b.
• The MMC5 test ROM then plays fifteen volume levels of a single square wave, then the same $02/$22 sample sequence on the MMC5's DAC.

The N163 test recordings can also serve to test the emulator output once the volume-specific submappers to mapper #19 have been finalized.

I was asked to measure the resistance of the Audio In/Out pins with an Ohmmeter. Result:Make of these what you will.

Here are the recordings (207 MiB .7z file with .flac files inside). All recordings close with a sample of in-game audio. Notice how annoying the eight-channel N163 games sound. This is already mentioned in the wiki, but I was still taken aback when I heard it on real hardware.

I can repeat the procedure if a mistake is pointed out, or should I purchase/receive additional VRC6 and MMC5 cartridges. I would also be curious about the relative balance of the Sunsoft 5B, but am not willing to spend $300 or more to satisfy that curiosity.

I have not had the time to actually analyze these recordings.

Edit: Updated N163TEST to initialize the N163 as soon as you press the A button; previously it was only initialized after the APU square wave. Also made the code run at $E000 to not rely on PRG register initialization.

I think that some of the later games like Namco Classic II and Gimmick! and Uchuu Keibitai SDF may be meant for GPM and AV Famicoms, not the HVC or Twin Famicoms. Most of the games that use expansion audio were released or in development prior to the adoption of the GPM-02 Famicoms in 1989.

It's still good data anyway, for the N163 carts. We can still deduce their amplitude relative to each other from this, which we can combine with other sources to extrapolate/estimate what they would have been like on other Famicom models.

MMC5 and VRC6 aren't really a problem in this respect, as I don't think there's ever been any mention of variation in levels from game to game like N163, just variation due to the tolerances of the components involved. 5B and VRC7 only have one game anyway. FDS doesn't very by game, obviously, so it's been easier to get data on too.

(Uchuu Keibitai SDF isn't in those recordings, BTW. Did you mean Shin 4 Nin Uchi Mahjong?)

Analysis results. I used Audacity's "Contrast" function between the loudest APU and the loudest N163 single-channel square wave. The plugin measures RMS dB differences.

I was using Uchuu Keibitai SDF as an example of quiet games even though it was not among the games NRS recorded. I would not trust the EverDrive's handling of any expansion audio levels in an HVC or a Twin, they'll sound too quiet.

When you look at all the FDS titles, most of which were released in 1986, 87 or 88, the mixing preference must be fore the earlier systems because they were the only systems developers had to work wtih.

While there is generally a linear relationship between the measured resistance of a cartridge and its relative volume level, the results are not always predictable :

What the hell are you talking about? I am not recording the games from the Everdrive N8, but entirely from the original cartridges. The Everdrive N8 is only used to load the test program into CPU memory.

I know that, I did something similar once with Chris Covell's TapeDump. The sentence "I would not trust the EverDrive's handling of any expansion audio levels in an HVC or a Twin, they'll sound too quiet" really does not make sense in the context of this discussion and should not have been included.

My only guess is that there were (at least?) two production runs of the silicon dice for the 163. Between NewRisingSun's data here and the data I compiled here, we have several variations:
Final Lap has been found with both 4.7k and 15k resistors
Sangokushi (1) has been found with both 33k and 4.7k
King of Kings has been found with both 10k and 4.7k

But ... man, what is going on with Namco Classic 2? Rainwarrior felt a good balance from that was roughly +15dB, not the +2dB measured here.

Ignoring that, the volume range of a single voice seems to vary from +11dB (Rainwarrior's comment here of 3.6x on Final Lap) to +19.5dB (Sangokushi), how precise do we want to be?

Is it worth trying to be more accurate than 3dB, given that there's clear mix variations? Just two submappers, one for +12dB and one for +18dB?

I would like to find out for sure though, which is why I will try to get the two other VRC6 games. The two MMC5 games' expansion sound volumes on the other hand are exactly identical. In fact, perhaps unsurprisingly, each MMC5 square wave channel seems to be almost exactly (+/- 1dB) as loud as the APU's on the Twin Famicom, even though both games were published when the GPM was already being produced. The DAC is a tiny bit louder --- writing the same value should make the MMC5's DAC sound 6 dB quieter than the APU because of the additional bit, but I measure it only being 4-5 dB quieter.

I don't know what's going on with Namco Classic II. Instead of attenuating the APU, it seems to merely low-pass filter it, though I don't know enough about electronics to explain how an attenuator could by accident turn into an low-pass filter. I could try to acquire a second copy, though I don't exactly find the game worth it.

I would be fine with just two submappers. Since nobody seems to be willing to ask the Mysterious Oracle of Kevtris directly what his proposed submapper #1 was for, I would venture the opinion that it was for games like Mindseeker that store save data in the N163's internal 128 bytes of chip RAM, eschewing WRAM. Since that information is expressed in the NES 2.0 header in its PRG-NVRAM field, submapper #1 should be deprecated. Also, I am not sure what the point of using submapper #9 instead of #2 is, given that no N129 game (of which I only know one, Namco Star Wars) uses expansion audio to begin with, and there is no description in what way the expansion audio is "buggy".

Not well quantified. The only knowledge we have is Naruko's initial comment, and his subsequent recordings.

It sounds to me like there's some arithmetic error in how it does the lookup into the waveform: pitches are still usually correct.

But you're right that it doesn't warrant a submapper.

I'll record my own soon to add to the data.

I'm not sure what I'd suggest for submappers, but now that some good measurements have been taken (thanks so much!) I'm going to implement a new NSFe packet for mixing specs. Had it planned for a long time, but now there's finally something to use it for that isn't just people complaining the Famitracker mix doesn't match NSFPlay.

For what it's worth, here are PCB images of my strange-sounding Namco Classic II PCB. When I opened the cartridge shell, I found that for no apparent reason, there were two toothpicks attached to the inside of the cartridge shell with adhesive tape. I'm not kidding.

Well, uh, this explains the lowpass filter you heard:

But... why? No other game has this, though Mappy Kids has a weird thing (probably unrelated) that looks like a solder pad.

HA HA HA that's a good twist. :>

That looks like a place to add the same lowpass filter.

Maybe someone was using it for homebrew music, and modified it trying to get 8-channel to sound better?

I guess I need to get that second copy after all.

But the LPF being optional and to be used for eight-channel music makes sense.

I guess you can check Sean Riddle's webpage for M50805 levels for Family Aerobics Studio. The Jaleco level test program could just probably swap through all the different mappings for the chip.

You got source for these things?

I've recorded these with my (AV modded) Famicom vs. the carts I have:

• MMC5 Just Breed
• MMC5 Uchuu Keibitai SDF
• VRC6 Esper Dream 2
• N163 Rolling Thunder - 16.9 dB
• N163 Erika to Satoru no Yumebouken - 18.9 dB

https://www.dropbox.com/s/2um1i5kr6l2ae ... 6.zip?dl=0

I also have Erika to Satoru no Yumebouken, but hotswapping into it creates a horrible noise. Whatever your test does, I think it needs to do more thorough initialization of N163 (with source code I could maybe tell you what). Also, you have VRC6TESA.NES and VRC6TEST.NES but the VRC6a variant seems to be VRC6TEST and not VRC6TESA?

Rough results: MMC5 is more or less the same volume as my APU, just inverted (as expected). VRC6 is close to APU (as expected), though slighlty quieter. Rolling Thunder N163 is 16.9 dB louder than APU. Erika to Satoru no Yumebouken is 18.9 dB louder.

Edit: Updated with recording of Erika to Satoru no Yumebouken.

I dunno, that solder job looks contemporary to the resistor.

It'd be nice to get a frequency sweep to extract the corner frequency of the added lowpass. Too bad SMT ceramic capacitors often don't mark their capacitance. Doing my best to analyze how the spectrum of the square wave's been modified, it looks like it might work out to a lowpass at 3kHz?

Both the 2A03 and 163 should be subject to the same corner frequency, because of Thévenin equivalent circuits.

Updated N163TEST to initialize the N163 as soon as you press the A button; previously it was only initialized after the APU square wave. Also made the code run at $E000 to not rely on PRG register initialization.I did not have the wiki names in mind when I named the files this way. I initially made VRC6TEST for Mapper 24 but then remembered that it cannot work with Madara because of the address bit swap, so then created VRC6TESA for Mapper 26.
I meant it made sense for Namco's hardware designers to add the possibility of a LPF to the circuit in general. It makes no sense for this particular game, though.

Re-recorded Erika and added it to that ZIP in my previous post. Funnily enough it wasn't doing the same thing on swap this time anyway... would have worked with the original test I guess.

Whatever the charge/temperature conditions were with it before have changed, I guess. BTW, as I recall the mix varied in my previous tests as the Famicom warmed up, so I wouldn't expect these to be precisely the same if I did them on different days anyway.

Was trying to figure out where the old "2 samples" for Rolling Thunder came from that I estimated as a 6.5x average.

I did find two old threads from when I was beginning to look at this years ago:
N163 cartridge volume survey
Famicom expansion hardware recordings

After some more digging I found jrlepage made 4 recordings from the ROM in that N163 cartridge volume survey thread. I think these were the other 4 samples I had, besides my own two.
http://www.mediafire.com/file/tsip335vftwoxoh/n163_test.rar

Re-measuring these now, on jrlepage machine the differences were:

• N163 Rolling Thunder - 16.0 dB
• N163 Final Lap - 11.2 dB
• N163 King of Kings - 17.3 dB
• N163 Megami Tensei 2 - 11.9 dB

I think this has a nice consistency with your recordings, as well as mine. Seems likely that jrlepage's APU is ~1 dB louder than yours.

I think we need three submappers after all; Rolling Thunder seems to consistently measure as between the 4.7kohm and 10kOhm games, and the difference is definitely audible, assumed manufacturing tolerances notwithstanding. Plus the one for no expansion audio.

Submapper 2 - No expansion audio
Submapper 3 - +12 dB
Submapper 4 - +16 dB
Submapper 5 - +18 dB
and dropping Submappers 1 and 9.

Kevtris only ever suggested submapper 1. The others were sort of floated by lidnariq a long while back, but we had less information, and he seems to have deliberately left them "hidden". Aside from submapper 1, which Kevtris may have implemented somewhere, the rest are no more than proposals, and most of those very iffy. (I'm not even sure why I unhid them... probably because I thought there was no need to hide stuff that was then relegated to the proposals page.)

As far as deprecating a redundancy caused by Kevtris, this has come up before. Maybe not a big deal to keep this one?

I know in the other thread lidnariq pointed out that Kevtris had made some comments about later changes to the spec, but I might point out that at that point when he said that the "proposals" had not been separated from the actually implementable stuff on the Wiki and it was a huge mess, so I think he was basically very correct in his assessment at that moment. That argument was part of what led to it getting cleaned up and separated like this.

The submapper 9 thing is a bit of a unicorn. Someone found it once in one game and I don't think it's been seen again. That same game has also been seen with more "normal" N163 chips in it. Leave it in the proposals, maybe one day some useful information about it will surface.

The difference to the other redundancies is that we do not even know with certainty what his submapper 1 does. My description was merely plausibility-based conjecture. Unless he condescends to explain, I would definitely remove it, regardless of any idiosyncratic implementation.

When I said "keep" I meant to mark as "deprecated" and leave allocated, like the other cases so far. (I'm mostly indifferent to the issue though. I just think a handful of deprecated entries is probably a better situation than incompatible forks of the spec.)

Is what it specifies really unclear? Doesn't it just mean to battery back the internal mapper RAM? The situation seems very similar to the MMC1 redundancy cases which were left deprecated as well.

If the lowpass filter turns out to be consistently present on Namco Classic, it'll need a submapper too.

Is the difference between +16dB and +18dB sufficiently audible? Especially on top of the documented ±1dB variation from console to console?

(The ±5% accuracy for the resistors used here should only cause 0.4dB maximum variation from cartridge to cartridge, so there's got to be something else adding on)

What I want is to come up with a final specification as quickly as possible, meaning patiently waiting until all hardware and software information is available, but not keeping it in limbo just because somebody proposed something ten years ago but nobody knows why, and in the case of submapper 1, nobody knows for sure exactly what was proposed.

I'm fine with finalizing #1 as "deprecated" based on the battery RAM assumption, #2-#5 as expansion sound info per my last proposal, and #9 documenting N129 even though it's not strictly necessary for accurate emulation of the known games, similar to my VRC7 submapper proposal, or to most CNROM games' bus conflict behavior.

I will post audio files from emulation showing the audible difference in Rolling Thunder between +16 and +18dB later.

I don't really see any point in explicitly allocating the N129 submapper (yet). The only place we've found it, the only difference we know of is hidden by the lack of a mixing resistor.

As far as submapper 1, the approximate most achievable answer seems to be "go to IRC and ask him". But your guess does sound probable.

I don't use IRC, and am not going to start using it just because somebody cannot be bothered to explain himself when and where he should.

So instead you expect from him an answer to a question you haven't asked of him? He doesn't actively read this forum, and he doesn't have an account on the Wiki.

Using IRC takes no more effort than visiting a webpage. You don't have to install anything or register an account.

(And sure, if someone proposed adding something new to the spec as ill defined as Kevtris' submapper doc, I'd push back and get it clarified, but he's not the one adding new things. It's a 12 year old spec that he started and we're continuing.)

Everone here seems to be agreed that Submapper 1 should be deprecated, but not reassigned. I doubt any emulators supported it except for maybe FCEUX. However, the Analogue Nt Mini requires Mindsweeper to have Submapper 1 enabled for it to work properly in its jailbreak firmware. I doubt kevtris would be able to explain off-hand why this game and not any of the other Namco games requires this submapper to work correctly on his FPGA console.

Totally unrelated, but I measured 21.8Kohms across pins 45 & 46 of my Rolling Thunder cart, the only Namco 163 game I own. I'd record my original Akumajou Densetsu cartridge using this program but it has to go through my Famicom's the RF modulator first, then the VCR.

Maybe this is also a good time to ask for clarification on the PRG-RAM part of the iNES 2 header. I find the current state of things confusing, and I'd like to be able to make it clearer on the wiki.

tepples added this to the wiki with the edit note "Kev clarified what to do for the 8320 bytes you get when you add 8K of RAM to an N163":

In another recent thread Sour and NewRisingSun wrote:



There seem to be 4 relevant fields of the header: the battery backed bit, PRG-RAM unsaved, PRG-RAM saved, and submapper. Bootgod has 20 results for mapper 19 games, and there's 5 different cases represented in its data:

1. No WRAM, no battery backing.

A (no battery, 0 unsaved, 0 saved) or B (no battery, 128b unsaved, 0 saved) ?

I had interpreted the spec given on the wiki as this field normally specifying external RAM only, so I'd expect to use A here. NewRisingSun appears to expect B because of the header used in the test program, except it contradicts the statement above (neither are battery backed, so internal RAM should be unspecified?).

• Dragon Ninja
• Erika to Satoru no Yume Bouken*
• Final Lap*
• Mappy Kids*
• Namco Classic
• Namco Classic II*
• Rolling Thunder*
• Star Wars
• Youkai Douchuuki*

2. No WRAM, battery backed N163.

A (battery, 0 unsaved, 0 saved, submapper 1) or B (battery, 0 unsaved, 128b saved, submapper irrelevant) ?

I assume this was the case targeted by Kevtris' submapper 1, and A seems consistent with the wiki to me. B is how I'd interpret NewRisingSun's statement.

• Battle Fleet
• Famista '90
• Kaijuu Monogatari
• Mindseeker
• Hydlide 3

3. Unbacked WRAM, battery backed N163.

A (battery, 8k unsaved, 0 saved, submapper 1) or B (battery, 8k unsaved, 128b saved, submapper irrelevant) ?

• Dokuganryuu Masamune edit: NewRisingSun says this is incorrectly identified, has no WRAM but some sort of protection circuit instead? Does that need its own submapper?
• Hydlide 3 (edit: mistakenly included here)

This category might actually be empty.

4. Only battery backed WRAM.

A (battery, 0 unsaved, 8k saved, submapper not 1) or B (battery, 128b unsaved, 8k saved, submapper irrelevant) ?

• Juvei Quest
• Megami Tensei II*
• Sangokushi II*
• Sangokushi*

This category might actually have battery backed N163 as well. According to lidnariq it's not possible to back just one?

5. Battery backed WRAM, battery backed N163.

A (battery, 0 unsaved, 8k saved, submapper 1?) or B ? (battery, 0 unsaved, 8k saved, submapper irrelevant) ?

• King of Kings*

So...

A. My wiki interpretation seems to be that the header specified PRG-RAM is only for external RAM on N163, and submapper 1 is used to designate that battery backing also applies to internal N163 RAM. This seems to cover everything except King of Kings. Not sure if King of Kings actually needs the N163 saved, so it might be totally moot, but worst case seems to be that this game needs its own submapper for audio + battery N163. (Adding audio submappers should also imply that submapper 1 is no-audio?) This also seems consistent with the immediately following edit suggesting that flash games should specify battery save, but 0 PRG-RAM.

B. NewRisingSun instead appears to want to specify that 128b in the RAM fields as often as possible. King of Kings becomes a special case again, but this time because the 128b bytes as "unlisted" is being used to imply that it should be saved? Have I got this correct?

Thankfully, except for King of Kings the games using audio expansion don't seem to fall on the stickier cases.

I have long given up on expecting anything. Nowadays I just hope for the best.
That is contradicted by the statement further that the Taito X1-017's 5120 bytes should be rounded up.
You missed the most important part of the specification: "If a cartridge has both dedicated RAM and RAM in the mapper". According to the spec (or at least how I understand it):

- Internal RAM, no WRAM, no battery -> denote internal RAM as PRG-RAM (most N163 games)
- Internal RAM, WRAM, no battery -> does not apply to any game. Spec would say denote only WRAM as PRG-RAM, and expect the emulator to add internal RAM by itself.
- Internal RAM, no WRAM, battery -> denote internal RAM as PRG-NVRAM (Mindseeker)
- Internal RAM, WRAM, battery -> Megami Tensei II, King of Kings. Spec would say denote only WRAM as PRG-NVRAM, and expect the emulator to add internal RAM by itself. Given that I verified that no such game uses internal RAM for save data (Megami Tensei II and King of Kings use it for expansion audio), I would say denote internal RAM as PRG-RAM and WRAM as PRG-NVRAM, which at least would be permissible under the spec as well, even though pedants would insist that the internal RAM technically is battery-backed as well.

The discussion that led to tepples asking kevtris-sama about this is here. Feel free to ask him, but I see no need for a further clarification. I do agree though that the wiki should explicitly denote that unless there is both WRAM and internal RAM, PRG-RAM should denote internal RAM.

Also, Dokuganryuu Masamune has no WRAM. Nescartdb is wrong on this; the additional glob performs some kind of internal RAM protect, if I remember correctly (lidnariq has investigated this, I think).

This statement you are quoting from me is about when there is no WRAM, and that wiki quote has no suggested specification for "no WRAM and no battery backing", it only specifies if both are present. This is part of what I'm trying to clarify.


So I did interpret your intention correctly for this.


Maybe, but MMC6 at least has its internal RAM at the same memory location as traditonal WRAM, so I don't think it's entirely inconsistent here. I'm not very familiar with Taito X-somthing, but there don't appear to be any mapper 80 games with WRAM anyway so there isn't really a conflict opportunity for it like there is with e.g. flash homebrew mappers. Judging by this, mapper 80 doesn't appear to be a NES 2.0 candidate anyway, battery backing can only imply its internal RAM is saved because that's its only existing case.

...at any rate, though, this is kind of an aside. Mappers are by their nature inconsistent, I don't think we can make one rule to fit them all, and probably there's always one that will be stupidly special, but at least we can try to document a practical specification in the end. Right now I'm just trying to assess what can work, and to a certain extent what's already working (e.g. romsets and/or implementations already in the wild).

Like from what I outlined, it seems like submapper 1 can imply that 0 in one or the other ram field can imply a 128b entry in some cases. That doesn't seem to cause any practical conflict with the spec you want to use, at least... though to be honest I think it would be easier if there was just 1 way to do it and I'm not quite sure what is so deficient about using submapper 1.


I'm confused by this statement. There are a bunch of N163 games with a visible battery and no external WRAM.

King of Kings I can certainly believe is just accidentally battery backing the N163. ...or I'd believe if you told me that you found it didn't battery back the N163 at all and Bootgod's database has it wrong for that game. I'd find the other ones harder to believe though, why would there be a battery if there's no save?


Thanks. I missed that thread and did not find it while searching earlier.


Okay, I'll make a note of this in my post. Does that require its own submapper as well then?

No such game. "Such" in a paragraph about N163 plus WRAM plus battery. Yeesh.
Now I am confused about what you mean.

Furthermore, if if the specific thing emulated is "battery-backed internal RAM" then submapper 1 should also be necessary for all games marked as "internal battRAM" here.

In fact, mappers 80, 82, and 207 were all only ever used with a battery and no external RAM.

I was confused because you included MT2 and King of Kings together, which are not both in this category by the bootgod database. Maybe you know different. I don't know. That's why I'm asking.

Look, I'm just trying to understand what you mean, which was unclear to me, so I'm asking a question. This is not an attack, this is an attempt to understand what you're trying to express.

Why would I not include them together? Both have 8 KiB of WRAM, both have a battery, both have the N163 chip, and both use its 128 bytes for expansion audio.

Either way, it's becoming clear that the NES 2.0 PRG-RAM spec is not clear at all. I thought I understood it, but given that both rainwarrior and Sour understood it differently, then it can't be considered clear.

Ah, sorry with the rapid replies and edits I missed this.

If a game doesn't need disambiguation past iNES 1 spec, the iNES 2 fields are kind of irrelevant. There is no compatibility or accuracy need to put an iNES 2 header on it, so you don't really have any mandate to specify the internal RAM size anyway.

Like there's some argument that maybe battery backed RAM size should match the size of the file you need to save the state in, but that ship seems to have sailed already because of the power-of-two sizings.


Yes that's the same 6 that I had on my list above based on Bootgod. King of Kings is the possible outlier (almost certainly doesn't need battery N163 though).


From the rapid editing, I'm not sure at what stage my revised version of this appeared vs when you were reading, but just to clarify what I'm after:

To which end I was trying to say that I'm mostly trying to gather information here so I can see what's possible at this point. Maybe you've already gone through some reasoning or conclusion that submapper 1 is a garbage idea or internal RAM has to be specified etc. I don't know, but that's not something I can follow and reference until it's actually laid out. In a similar vein, I had assumed submapper 1 was useless from the tone of the discussion, but the more I looked at it there seemed to be a big lack of information around it, so I'm trying to open this up as a possibility too.

All right. Let's try this again. There are three kind of N163 save data situations:
Situation 1. N163, no WRAM, no battery. Most games. Can be expressed in iNES (1.0) by simply not setting the battery bit.
Situation 2. N163, no WRAM, battery. This means the game saves its data inside the N163 chip. Cannot be expressed in iNES (1.0), as most NES emulators will assume that the battery refers to the $6000-$7FFF area. (fwNES from 1998 being a notable exception).
Situation 3. N163, WRAM, battery. This means that the game saves its data using WRAM, and uses the N163 chip RAM for audio or not at all. Easily expressed in iNES (1.0), as it works like any other mapper's save function.
There is no N163 game that uses WRAM but has no battery.

The only iNES 1.0 problem in need of a solution therefore is situation 2. I assume that kevtris proposed to use submapper 1 for this. One could indeed do that.

But: NES 2.0 not only has submappers, but also PRG-RAM and PRG-NVRAM fields, and emulators interpret them whether we want it or not.
We must therefore define correct PRG-RAM and PRG-NVRAM values for all three scenarios, unless we say that situations 1 and 3 may not have a NES 2.0 header at all, which would be absurd.
The problem is that once we specify PRG-RAM and PRG-NVRAM fields for all three situations, however we do it, submapper 1 necessarily will become redundant.

What are the correct PRG-RAM and PRG-NVRAM fields for each of these three situations? My understanding based on the above description was:
Situation 1. BATT=0, PRG-RAM =128, PRG-NVRAM =0.
Situation 2. BATT=1, PRG-RAM =0, PRG-NVRAM =128.
Situation 3. BATT=1, PRG-RAM =128, PRG-NVRAM =8192.
This is based on the assumption that the 128 bytes of internal chip RAM count as PRG-RAM because they can be used for any purpose by disabling sound output. The spec and previous discussions implicitly assume this (and that may be the problem).

Now, lidnariq stated in the thread I linked to that the PCB is such that one cannot connect the battery to the 8 KiB WRAM chip without also connecting it to the N163, so 3 would have to be specified as:
Situation BATT=1, PRG-RAM =0, PRG-NVRAM =8320

And since 8320 cannot be specified because it must be a power of two, and because we did not want to round up to 16384, the sentence "If a cartridge has both a dedicated RAM and RAM in the mapper (such as that of Namco 163), and both or neither are battery-backed, include only the size of the dedicated RAM in the header." was added to the wiki, so Situation 3 is now specified as:
BATT =1, PRG-RAM =0, PRG-NVRAM =8192 if one insists that the N163 is technically battery backed, OR
BATT =1, PRG-RAM =128, PRG-NVRAM =8192 if one is willing to ignore that.
This is the current spec, as I understand it, which is quite hard to explain.

Now, one could be of the opinion that because the N163's chip RAM is not directly mapped into CPU address space at all, it is a special case and should not be included in the PRG-RAM/PRG-NVRAM fields at all. This would be okay since mapper 19 already tells us that there are 128 bytes of chip-internal RAM that are only accessible via $4800/$F800. The three situations would then be described as:
Situation 1. BATT =0, PRG-RAM =0, PRG-NVRAM =0.
Situation 2. BATT =1, PRG-RAM =0, PRG-NVRAM =0.
Situation 3. BATT =1, PRG-RAM =0, PRG-NVRAM =8192.
Which would be very consistent, and which I would like very much, but is contrary to the current spec and contrary to all previous discussion on the subject. And again, the PRG-NVRAM field would already disambiguate between situations 2 and 3, making submapper 1 redundant. I think some people did not like the sight of a header saying "a battery with 0 bytes of PRG-NVRAM", and stock Nintendulator indeed complains about that.

I got a much better idea after reading that old thread. I had misidentified Hydlide 3 in my list by mistake, and lidnariq claryfing that WRAM and N163 are always battery backed together or neither was a big lightbulb.

As for iNES 1, in that case WRAM is always assumed and battery should presumably just save the N163 as well. Is there any compatibility issue there? (Does Mindseeker or some other game rely on open bus at $6000?)

Assuming our goal here for iNES 2 is accuracy and not merely compatibility, it seems that N163 RAM should always be saved if battery backed. Doesn't matter that it's not used, for accuracy's sake it belongs. There should be no such thing as an 8192 byte save for N163 in terms of accuracy, but an emulator could detect 128 byte or 8192 byte files if they exist and interpret them in a compatible way to fill the RAM.

So... the only remaining issue is just whether it's got 8k of WRAM or open bus at $6000.


I think this last suggestion works very well for this, and removes ambiguity. "BATT=1, PRG-RAM=128" in the other suggestions is an inaccurate fiction because it can't not be battery backed, right? That last suggestion also removes all need for specifying this with a submapper, which is good too. Makes the audio mix submappers easier to implement, and is pretty cleanly open for 129 or other variant compatible subspecies if they ever appear.

(As for what's on the wiki, derived by telephone tag with Kevtris and tepples, I don't think it's actionable, and I'd suspect probably doesn't even effect his Analogue NT thing anyway. I'd vote we replace it with this ^ instead.)


So, deprecated submapper 1... looking at it again maybe it doesn't have the meaning I thought. Maybe this means "WRAM not present" (redundant) or maybe it means something about the battery needing to be saved, in which case it's like submapper 0 but with a redundant "battery save the N163" hint, not compatible with the audio mixing effort but we don't need to care about that -- it will be a compatibility mapper, not an accuracy one.

I am still not sure how to word my last suggestion in the form of a general rule. I was proposing to add to the NES 2.0 wiki page "The PRG-RAM and PRG-NVRAM fields apply to memory, both ASIC-internal and ASIC-external, that can be mapped into CPU address space. It therefore excludes the Namco 163's chip-internal RAM." But that would be incorrect as well, because the PRG-NVRAM field was explicitly designed to also handle serial EPROM, and that one cannot be directly mapped into CPU address space either. Dang.

I don't think we need to tear our hair out trying to make every rule universal. Maybe there will be some special cases we can't iron out. A rule of thumb that works most of the time is still practical.

The specifics for what to do about N163 should really be on the N163 page, IMO. I sort of back-linked it from there earlier while trying to get a handle on the information, but really I think any mapper with internal RAM or something similar is a special thing that needs to be explicitly detailed on its mapper page. We can allude to them on the NES 2.0 page, but probably better to state a rule of thumb there and then make a list of links to the mappers it effects.

So the NES 2.0 wiki page would simply state: "The PRG-RAM and PRG-NVRAM fields, as a general rule, describe the amounts of non-battery-backed and battery-backed RAM, both ASIC-internal and ASIC-external, that are mapped into CPU address space. Special rules apply for mappers with RAM that is not mapped into CPU address space ([[Namco 163]]) and for mappers with serial EPROM ([[INES Mapper 016]], [[INES Mapper 157]], [[INES Mapper 159]]). For these mappers, it may be permissible to have the battery bit set, yet PRG-NVRAM having a value of zero."

The Namco 163 page would state: "The NES 2.0 PRG-RAM and PRG-NVRAM fields have non-zeros value only if there are 8 KiB of additional WRAM on the PCB. They do not include the 128 bytes of chip-internal RAM. This means that for games like Mindseeker, which save data to battery-backed chip-internal RAM, the NES header's battery bit will be set, yet PRG-NVRAM will have a value of zero."

I have to think about what the Mapper 16/157/159 pages should say about that.

Doing some digging, but I didn't find any open bus access in Mindseeker.

I did notice that FCEUX had a header hack for the 5 games that had battery but no WRAM to force the header on. Masamune conspicuously absent, but I assume this is due to the persistent idea that it had WRAM.
https://github.com/TASVideos/fceux/blob/master/src/ines.cpp#L278


So... my guess is that Kevtris had it on his radar for iNES 2 because of being on CRC detection lists, but mistakenly not due to a need in the iNES 1 spec, just bad headers from people clearing the battery flag if no WRAM.

As such, I think submapper 1 most probably means specifically: no WRAM, battery backed. (Whether the emulator should enforce or override conflicting settings elsewhere in the header, probably up to them. I don't think this needs to be defined rigorously for a deprecated submapper.)

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."

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.

Opinions on these PRG-RAM/NVRAM ideas (and the revised Namco 163 one)?

I haven't changed any of the information here yet, but I've regrouped it so that all the weird notes are now just a list of special cases.
http://wiki.nesdev.com/w/index.php/NES_2.0#Byte_10_.28RAM_size.29

I'll wait on more consensus before changing anything to do with the N163 thing but maybe at least this structure it'll be easier to get to needed info.


Edit, actually looking at the wording that's there...

That "both or neither" case is useless, since those are the only two possible cases if both chips are present. (That was a big part of what confused me; I thought there were other combinations, and Bootgod's inconsistent database seemed to confirm this.)

Since it only specifies the "both chips" case, what to do without WRAM was left unspecified. (This is the reason I think both Sour and I were surprised to find 128 in your test header.)

I am just going to tentatively replace it with that last proposal, which doesn't actually disagree with the letter of what it said before, since the no-WRAM case wasn't even specified:

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.
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:
It is probably also worth mentioning the planned submapper for FCG-1 and -2 behavior here, too.

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.

Mapper 16 has three variants, if I remember correctly:
FCG-1/2 ; necessarily no EEPROM
LZ93D50 , no EEPROM
LZ93D50 , X24C02
This is basically why I think the canonical value for mapper 16 with 256b I²C EEPROM should mark 256b NV PRG storage.

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.

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.

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.

[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.

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.

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.

This summary.

Lidnariq's description of Battle Rush is correct. I've got it working nicely in NintendulatorNRS.

That was what I responded to, though. Was there some part of it missing in my reply that you are asking my opinion of?

I was more aiming for a short "Yes, except for point x" kind of reply to a summary, but either way, I now have all the answers I need. Thanks.

I suppose I should write a test ROM for the mapper 16 submappers now, before moving them out of the proposal wiki page. Edit: Done.

I'm finished with my N163 wiki edits, so feel free to make any corrections or changes. I'll do the Bandai stuff over the weekend, because I'm exhausted now.