4-Screen VRAM with NES 2.0

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

4-Screen VRAM with NES 2.0

Post by NewRisingSun »

For games that have additional VRAM for four-screen mirroring, does that extra RAM count as part of the NES 2.0 CHR RAM size field? I would think no, because VRAM isn't CHR-RAM, but on the other hand it is mapped into PPU address space, so I was not completely sure.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 4-Screen VRAM with NES 2.0

Post by tokumaru »

CHR-RAM is part VRAM, but not all VRAM is CHR-RAM. That being said, 4-screen is specified the same way as in classic iNES, through but 3 of byte 6, and doesn't affect the CHR-RAM field.

I don't know what to do about programs that have more than 4kb for name tables though, such as GTROM, which IIRC can switch between 2 sets of 4 name tables.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: 4-Screen VRAM with NES 2.0

Post by NewRisingSun »

That's what I thought as well, that it's not needed because the 4-screen bit already indicates the presence of the extra VRAM. I also noticed however that when the battery bit is set, the correct amount of PRG-NVRAM (usually 8 KiB) must be specified separately in the NES 2.0 header, otherwise the header is considered invalid (battery with null bytes of RAM to be backed), so I was considering whether 4-Screen Mirroring is similar.

And for Zhongguo Daheng, which uses both the two CIRAM pages and four additional VRAM pages on the cartridge for a total of six simultaneous nametables, Quietust recommended to me that I should use CHR-RAM for that, but then that extra VRAM certainly would need to be included in the CHR-RAM field, otherwise Nintendulator would mask that memory off. Of course, that advice could also have been a recommendation for that edge case of a game using a total of six nametables together with the way Nintendulator implements CHR-RAM. Nevertheless, as NES 2.0 was defined for such edge cases, at some point the NES 2.0 wiki page should resolve this matter explicitly.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: 4-Screen VRAM with NES 2.0

Post by rainwarrior »

If the iNES header says 4-screen then there is 4k of RAM for nametables, unrelated to CHR-RAM.

For most mappers these two things are completely orthogonal. If on the original board the nametable RAM happens to be the same chip as CHR-RAM doesn't actually matter to the iNES header or emulator. You can specify CHR-RAM and/or 4-screen as two separate unrelated things.

If the mapper can do nametable banking, though, then it matters, and that's a mapper specific implementation. Like if you have a mapper that can share banks between CHR-RAM and the nametables, yes that's part of CHR-RAM size and the 4-screen setting in the header is most likely irrelevant (the iNES mirroring bits only apply to simple cases), but it depends on that mapper.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: 4-Screen VRAM with NES 2.0

Post by NewRisingSun »

rainwarror wrote:If the iNES header says 4-screen then there is 4k of RAM for nametables,
Is that really so? Because the various wiki entries only describe the 4-Screen-Mirroring bit as the game using four nametables regardless of how they are realized; they could be realized by adding extra 2 KiB of VRAM together with the two CIRAM pages and additional decoding logic, or by completely replacing CIRAM.

But in any case, regarding the original question, the consensus seems to be that whatever method the board uses to allow four (or six, or whatever) nametables, that RAM is not to be included in the CHR-RAM field, but has to be known by the mapper-specific code.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: 4-Screen VRAM with NES 2.0

Post by rainwarrior »

Maybe a simpler way of putting it:

If the 4k of nametable RAM is only accessible from $2000-3EFF and not mirrored or banked anywhere else, then only the iNES header bits for mirroring apply, and it's not part of "CHR-RAM" specified in the header.

Otherwise it's mapper specific and the iNES header mirroring bits should be ignored (or treated in a special way). The meaning of any CHR-RAM size bigger than 8k is mapper specific anyway.


That majority of mappers are that simple case where you could just add on 4-screen without touching any other features, and where that's the case there is no reason to include it in the CHR-RAM part of the header. How it gets implemented in hardware doesn't matter either way; the fact that it would be sensible/simple to use the same RAM chip across $0000-1FFF and $2000-2FFF doesn't really matter from the iNES header perspective. If it's a feature that the header bits saying H/V/4 could turn on and off cleanly, then leave the CHR-RAM spec out of it.

If on the other hand the mapper lets you bank the nametable RAM or something like that, yeah that seems to make sense if it's part of the CHR-RAM spec.
Post Reply