Yes, there are both mapper 3 things that require the presence and absence. That's why I put CNROM in the list on the page.rainwarrior wrote:So for mapper 3 the question should be the opposite. Are there any mapper 3 games that require no bus conflicts? If yes, we should propose the submapper for this. If not, we don't need it yet.
And yes, emulators are beginning to move towards "discrete logic mappers enforce bus conflicts by default", even in iNES1 images.
Looks like Titanic 1912 and/or Darkseed.Union Bond [...] the ROM that needs it I don't think we should worry about it.
It is incorrect to provide PRG RAM to a game whose header says it does not have PRG RAM.023: 15 - the mapper articles claim that this is already compatible with the existing PRG-RAM implementation, i.e. it's not a compatibility issue.
For the compatibility argument, there are only seven original games that require NES2.0's PRG RAM field. They are:
* Low G Man and/or StarTropics, because the former is the only game that requires the absence of RAM (but it uses the MMC3's PRG RAM disable) and the entire problem here is due to the MMC3/MMC6 PRG RAM protection differences
* The games that used SXROM and SOROM. (FF1+2, Best Play Pro Yakyuu, Genghis Khan, Nobunaga's Ambition, Romance of the Three Kingdoms)
Every other game could be safely emulated with 8 KiB of PRG RAM, except:
* Those that use MMC5, which needs somewhere between 32 and 64 depending on just how klever you're being.
* Those that use Bandai's LZ93D50 with I²C EEPROMs, where they need 128, 256, or 128+256 bytes of EEPROM, but this division is already accurately handled by the three assigned iNES1 mappers.
These seven games are a small enough list that marking this set of games could easily have fit in the submapper field. Since it was NOT put in the submapper field, I can only conclude that the intent of the field was to accurately represent the amount of nonvolatile storage on the cartridge. And, therefore, I have to conclude that a "compatibility" implementation is against the spirit of NES2.0, at the very least for the PRG RAM size field.
Basically, my opinion is that this emulation container should handle both the "simple emulators" use case, as well as people making reproductions, as well as people making ROM hacks. And that means we can't just implement the lowest common denominator, but must enforce extra restrictions to keep people from assuming things that happen to be false.