4-Screen VRAM with NES 2.0
Page 1 of 1

Author:  NewRisingSun [ Sun Dec 31, 2017 5:14 am ]
Post subject:  4-Screen VRAM with NES 2.0

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.

Author:  tokumaru [ Sun Dec 31, 2017 10:27 am ]
Post subject:  Re: 4-Screen VRAM with NES 2.0

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.

Author:  NewRisingSun [ Sun Dec 31, 2017 10:44 am ]
Post subject:  Re: 4-Screen VRAM with NES 2.0

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.

Author:  rainwarrior [ Sun Dec 31, 2017 6:06 pm ]
Post subject:  Re: 4-Screen VRAM with NES 2.0

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.

Author:  NewRisingSun [ Mon Jan 01, 2018 3:23 am ]
Post subject:  Re: 4-Screen VRAM with NES 2.0

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.

Author:  rainwarrior [ Mon Jan 01, 2018 1:19 pm ]
Post subject:  Re: 4-Screen VRAM with NES 2.0

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.

Page 1 of 1 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group