Talk:Programming UNROM

NES 2.0 advocacy

Converting a ROM from original iNES to NES 2.0 isn't strictly necessary unless the mapper is ≥ 256 or the iNES header is ambiguous. For example:

• Several VRC mappers are ambiguous as to which low CPU address lines are connected to the mapper's port select.
• Mapper 1 is ambiguous between SIROM (PRG A14 from MMC1 output) and other SxROM boards using 32K PRG (PRG A14 from CPU A14).
• Mappers 1, 4, and 5 are ambiguous among PRG RAM sizes. For example, SNROM vs. SOROM, MMC3 vs. MMC6.
• A few games (notably Low G Man) require the PRG RAM to be absent.

What's ambiguous about mappers 2 (UxROM), 3 (CNROM), and 7 (AOROM), other than whether or not the ROM has a positive chip enable to avoid bus conflicts? --Tepples (talk) 22:19, 26 February 2013 (MST)

Two things-

1. the comment about PRG-RAM: due to iNES's shortcomings one can't distinguish between 0="no ram" and 0="unspecified ram"; and
2. the entire point behind NES2.0's backwards compatibility is the encouragement of its adoption without infringing on non-NES2.0-aware emulators. Creating mindshare makes it possible to say that it really is a solution.

—Lidnariq (talk) 01:50, 27 February 2013 (MST)

True, perhaps NES 2.0 might be warranted to keep programs from relying on an implied PRG RAM circuit that iNES emulators emulate but which is not present on official mapper 2 boards. I'll see how I can work it in. --Tepples (talk) 11:45, 27 February 2013 (MST)

Leaving the .byte $00 ;UNROM has no PRG RAM comment is explicitly misleading in light of the above.

In any case, because of NES2.0's backwards compatibility, I don't see an argument for why we should recommend plain iNES headers. —Lidnariq (talk) 14:51, 27 February 2013 (MST)