It is currently Tue Jul 17, 2018 10:17 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 6 posts ] 
Author Message
PostPosted: Sun Dec 31, 2017 5:14 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 560
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.


Top
 Profile  
 
PostPosted: Sun Dec 31, 2017 10:27 am 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10593
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Sun Dec 31, 2017 10:44 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 560
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.


Top
 Profile  
 
PostPosted: Sun Dec 31, 2017 6:06 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6402
Location: Canada
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.


Top
 Profile  
 
PostPosted: Mon Jan 01, 2018 3:23 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 560
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.


Top
 Profile  
 
PostPosted: Mon Jan 01, 2018 1:19 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6402
Location: Canada
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: imid and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group