Talk:NES 2.0

"Kevin Horton reports that Nintendulator supports NES 2.0."

No it doesn't - it detects them (and the mapper interface has room for them), but it doesn't actually read any of the fields. --Quietust 01:58, 5 January 2010 (UTC)

• ...though now it at least handles larger ROM images (including "Super 8-in-1 99 King Fighter (Unl).nes", which should actually be Mapper 45 with 1MB PRG and 2MB CHR, but with the 256KB CHR blocks 0/1/2/3/4/5/6/7 rearranged to be 0/2/3/1/4/5/6/7). --Quietust 03:30, 5 January 2010 (UTC)

An observation: it would've made more sense for the TV system byte to use bit 0 to mean "Supports NTSC" and bit 1 to mean "Supports PAL", since it would've made it trivial to support Dendy timing by just adding another bit. --Quietust 04:52, 14 January 2011 (UTC)

Zero CHR ROM

Observation: if a ROM is marked as NES 2.0 and has zero banks of CHR ROM, it must set the CHR RAM size field to a nonzero value (ideally 0x07, for 8KB non-batteried), otherwise it technically doesn't have anything at all connected to the PPU bus. --Quietust 02:20, 26 August 2011 (UTC)

Good point. I'll mention 0x07 as the most common CHR RAM size in the article. But I do know of two ways to make a cart with no CHR ROM or CHR RAM. The Game Genie uses one way: wire CHR address lines to data lines through a mux to make 4x4 pixel squares. The other way, which I've talked about before on the forum but have never seen used in a game, involves always enabling CIRAM and wiring PA13 to CIRAM A10, which gives 1-screen mirroring (all banks at $400-$7FF) plus 64 tiles of CHR RAM (at $000-$1FF). --Tepples 10:57, 26 August 2011 (UTC)

Just to close the loop- nocash built a game that used VRAM as CHRRAM: (http://forums.nesdev.org/viewtopic.php?t=9342) and allocated it to iNES Mapper 218.—Lidnariq (talk) 14:46, 13 March 2013 (MDT)

I think it would makes sense that if there is neither CHR ROM nor CHR RAM and the mapper is one that normally has at least one of these, then it should just use CIRAM for pattern tables, as if CIRAM A10 is wired according to the mirroring header (and/or software-controlled), and CIRAM is always enabled. Should you specify this? --Zzo38 (talk) 22:29, 21 March 2013 (MDT)

RAM size

I'm torn about how to deal with RAM-inside-mappers. As far as I know, there are five ICs that have some: MMC5, MMC6, X1-005, X1-017, and Namco's 163.

Some of these are easy: for the MMC6, X1-005, and X1-017, their internal RAM is at the exclusion of external RAM. The RAM size byte can just hold $40, $01, $10, or (per rounding up) $70 as appropriate.

For the MMC5, that RAM can be thought of as either of CPU or PPU memory, it's not clear whether it should be marked (and where it should be marked). Apparently no game ever battery-backed only the 1k internal RAM, so perhaps leaving the RAM size byte at 0 for MMC5s without external RAM is best, even if it's contradictory to the advice for the previous three. Only 2k, 8k, and 32k RAMs were available during the MMC5's commercial life, and they were only ever combined as (none, 8+0, 8+8, 32+0); clearly adding 1024 and rounding up would cause nonintuitive values here. (As an aside, there's also no way to express the 2+8 or 8+32 configurations in NES2.0; fortunately neither were used commercially)

The N163 came in 3 of the 4 possible variants: neither battery nor external RAM; battery but no external RAM; battery and external RAM; the first two would easily be $01 and $10, but the last worries me—adding internal+external and storing the rounded-up value in the "RAM size" means we'd have $80=16384 for 8192+128 battery-backed, or $60=4096 for 2048+128 battery-backed. This feels unintuitive to me. Simply always excluding internal RAM here (in addition to being contradictory to the advice given for the MMC6) means we'll have the nonsensical value 0 with the battery bit set in the rest of the header. Maybe the right answer is to only count the internal RAM when there's no external RAM? —Lidnariq (talk) 13:43, 10 February 2013 (MST)

Vs PPUs and $2002

"RC2C05-02 (with ID ([2002h] AND 3Fh)=3Dh)" - How can that be? Does the RC2C05-02 not implement the sprite overflow flag? --Quietust (talk) 21:30, 21 March 2013 (MDT)