It is currently Tue Feb 19, 2019 12:41 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 8 posts ] 
Author Message
 Post subject: CHR-ROM vs. CHR RAM
PostPosted: Sat Jan 31, 2009 12:09 am 
Offline

Joined: Mon Oct 30, 2006 8:32 pm
Posts: 122
MetalSlime wrote:
And one of the issues that I wanted advice on was CHR-ROM vs. CHR-RAM :)


This seems to be an issue that usually comes up with beginners who have learned about how the NES works and maybe written some programs for it. They eventually realize that a game that they want to make won't fit into the small memory of a mapperless (NROM) cartridge. So they first wonder what type of CHR memory to use, as this will greatly affect how the game is programmed and what is possible with the program. This topic will address the benefits of using each type of memory so that those just starting to make more complex NES games will have something to look at to decide which they want to use.

BANKSWITCHED CHR-ROM:

-Faster and easier to use. No need to load tiles into CHR memory, they are all there for you in ROM and if some tiles need to be switched out all one needs to do is write a few bits to the mapper. The small amount of time needed to switch banks frees up VBlank cycles which would otherwise be spent writing tiles to CHR-RAM.

Possible advanced effects:

-Storing non-graphics data in CHR-ROM. Can help save PRG-ROM.
General method: The region of the CHR-ROM with the non-graphics data is read during VBlank or while PPU rendering is disabled. It can then be stored or decompressed into RAM.
-Requirements: Rendering must be off during reads.
Examples: Super Mario Bros. (stores name table of title in CHR-ROM), some other NROM/CNROM games that I forgot

-Switching between which tiles are displayed in the HUD and the game play area by using a raster interrupt. Allows more tiles to be displayed on screen at one time.
General method: A bank full of text characters and other HUD-related tiles is switched to while the PPU is drawing the HUD and a bank full of game world-related tiles is switched to while the PPU is drawing the game play area.
Requirements: HUD must be horizontally oriented, one raster interrupt between HUD and game play screen.
Examples: ... crap I forgot, someone help me out here

-Parallax scrolling without raster interrupts. Parallax scrolling is where things far away from the screen move slower than things closer to the screen. Using the CHR memory to do parallax scrolling frees up cycles for the processor to do other things and makes vertical and "window" parallax possible on the NES. If no raster interrupts are used it also makes it easier to play DMC samples in your game.
General method: Banks containing parallax pattern are switched from bank to bank containing pattern in different scrolling positions to create a scrolling effect independent of the one made using the NES's scroll registers.
Requirements: Pattern being parallax scrolled should repeat often - most games use 1- or 2-tile-wide patterns for this effect. Small bank sizes are desirable as they make it possible to use less memory for this effect.
Examples: Batman: Return of the Joker (horizontal), Crisis Force (vertical), Metal Storm (window), Sword Master (window along with raster interrupt-based parallax)

-Switching to banks of "blank tiles" during first and last 8 or 16 scanlines while using 4-way scrolling with vertical mirroring. Using 4-way scrolling without 4 nametables (ie in one-screen mode or with vertical or horizontal mirroring) creates glitches on the edges of the screen whenever the screen is scrolled in a direction that is mirrored. Horizontally mirrored games with 4-way scrolling, like Super Mario Bros. 3, have glitches on the horizontal edges. Vertically mirrored games with 4-way scrolling, like Super C, have them on the vertical edges. If one is making a game with 4-way scrolling and vertical mirroring, one way to remove the glitches is to use the following method, which doesn't need the PPU to ever be disabled.
General method: During VBlank, all of the banks have been switched to the "blank tile" bank (bank filled with tiles whose bits are all set to zero) so that when the visible screen starts being drawn, only the blank tiles are fetched by the PPU. This makes the vertical mirroring with vertical scroll glitches impossible to see. Once 8/16 scanlines have been drawn, a raster interrupt triggers the 2A03 to switch the banks back to their normal values. Once there are only 8/16 scanlines before the screen is done being drawn, another interrupt triggers the 2A03 to switch the banks back to the blank tile bank, and the cycle begins anew.
Requirements: No HUD made of background tiles, 2 raster interrupts (one for top and one for bottom) or at least very carefully timed code.
Examples: Jurassic Park

8k CHR-RAM:

-Much more flexible. Instead of having to switch out big banks of 1k or more, CHR-RAM allows you to control every bit of every tile.
-Can compress tiles to save memory. Tokumaru wrote a tile compressor that compresses tile data down to about 70% of the original size (link and link). So if you're using 128k of uncompressed tile data in a 256k UOROM you could compress the tile data down to around 90k and have 38k more PRG-ROM for whatever.
-If you're making physical cartridges, you only need to program one chip.

Possible advanced effects:

-Parallax scrolling without raster interrupts. Parallax scrolling is where things far away from the screen move slower than things closer to the screen. Using the CHR memory to do parallax scrolling frees up cycles for the processor to do other things and makes vertical and "window" parallax possible on the NES. If no raster interrupts are used it also makes it easier to play DMC samples in your game.
General method: Tiles containing parallax pattern are changed by 2A03 to create a scrolling effect independent of the one made using the NES's scroll registers.
Requirements: Pattern being parallax scrolled should repeat often - most games use 1- or 2-tile-wide patterns for this effect. Lots of VBlank time is desirable as it makes it easier to update more tiles. Some games increase the VBlank for this purpose by disabling rendering at the top and bottom of the screen.
Examples: Battletoads, Bee-52

-Using 2A03 to render some of the screen. This makes drawing programs and 3D vector/polygon games possible on the NES.
-General method: Update tiles during VBlank with new screen.
-Requirements: Lots of VBlank time for update - disabling PPU rendering at top and bottom of screen to extend VBlank is desirable, especially for NTSC games. Banked CHR-RAM is also desirable as it allows double buffering.
-Examples: Color a Dinosaur, Videomation (drawing), Elite, Tank Demo (vector 3D), some projects by NesDev community

BANKSWITCHED CHR-RAM:

-Bankswitched CHR-RAM allows one to do most (if not all) of the techniques possible with bankswitched CHR-ROM and 8k CHR-RAM. However, there were few mappers produced during the NES's lifespan that had bankswitched CHR-RAM. The only one I can think of is CPROM, and that has only 32k of PRG-ROM. So most mappers using bankswitched CHR-RAM are custom-made by homebrewers. Examples: Garage Carts 1 and 2 (I think) and Glider.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jan 31, 2009 2:30 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21105
Location: NE Indiana, USA (NTSC)
I rewrote this for the wiki.

But storing non-graphics data in CHR ROM to save PRG ROM isn't an advantage of CHR ROM; it's a workaround for fragmentation. With CHR RAM, you just don't have to worry about it as much.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jan 31, 2009 7:08 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11166
Location: Rio de Janeiro - Brazil
tepples wrote:
But storing non-graphics data in CHR ROM to save PRG ROM isn't an advantage of CHR ROM; it's a workaround for fragmentation. With CHR RAM, you just don't have to worry about it as much.

Storing data in CHR-RAM seems like an interesting way to get more than 2KB of RAM. If you can spare a few tiles, you could get enough memory to remember states of many objects.

Even if you can access this extra RAM only during VBlank, game objects are usually activated and deactivated in small quantities, meaning that changes to this memory could be buffered and executed during VBlank without much sacrifice.

What I mean is that CHR-RAM obviously can't be used for storing regular variables, but it's a good place to store tables that are manipulated few elements at a time or not very often.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jan 31, 2009 11:08 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2157
Location: Minneapolis, Minnesota, United States
tokumaru wrote:
tepples wrote:
But storing non-graphics data in CHR ROM to save PRG ROM isn't an advantage of CHR ROM; it's a workaround for fragmentation. With CHR RAM, you just don't have to worry about it as much.

Storing data in CHR-RAM seems like an interesting way to get more than 2KB of RAM. If you can spare a few tiles, you could get enough memory to remember states of many objects.


Really? I thought reading from $2007 would give you garbage...


Top
 Profile  
 
 Post subject:
PostPosted: Sun Feb 01, 2009 2:52 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7664
Location: Chexbres, VD, Switzerland
Quote:
But storing non-graphics data in CHR ROM to save PRG ROM isn't an advantage of CHR ROM

Yeah it is also possible to write non-graphics data in CHR-RAM, and read it back later, like Tokumaru said. The fact it would only be accessible during VBlank pretty much kills it but after thinking a little....
If you have levels that are compressed in ROM, you could decompress them into CHR-RAM before the level starts, where the screen is blanked, and then read the data from CHR-RAM and write it to nametables, and then write actual graphics on CHR-RAM and turn the screen on. That wouldn't work with levels scrolling over more than 2 screens. I'm sure clever things like that are possible.

When it comes to what is on the wiki I have a few problems with that but I don't feel like editing it straight without discussing first :
Quote:
(Only one MMC3 game had a board with MMC3 + CHR ROM + CHR RAM, and it was a Japan-exclusive RPG.)

Which game is mentionned here ? Pinbot is not a japanese RPG, nor is High-Q.

Quote:
In some pseudo-3D games, each row of the floor texture can be stored in a separate bank. Racing games and things like 3D World Runner might have two to four banks; one forward-scrolling shooter called Cosmic Epsilon had dozens.

3D-Worldrunner uses CHR-RAM so it's relly not good to mention it in the list of advantages of CHR-ROM.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Feb 01, 2009 6:21 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21105
Location: NE Indiana, USA (NTSC)
Bregalad wrote:
When it comes to what is on the wiki I have a few problems with that but I don't feel like editing it straight without discussing first :
Quote:
(Only one MMC3 game had a board with MMC3 + CHR ROM + CHR RAM, and it was a Japan-exclusive RPG.)

Which game is mentionned here ? Pinbot is not a japanese RPG, nor is High-Q.

Typo. I meant "CHR RAM + PRG RAM", and "Final Fantasy III". Fixing...

Quote:
3D-Worldrunner uses CHR-RAM so it's relly not good to mention it in the list of advantages of CHR-ROM.

Fixed there too.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Feb 01, 2009 8:31 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11166
Location: Rio de Janeiro - Brazil
Celius wrote:
I thought reading from $2007 would give you garbage...

The first byte is garbage, but the following ones are valid. While rendering is disabled, of course. How do you think commercial games used data that was stored in CHR-ROM (such as SMB's title screen data)? Quite a few CNROM games had data stored in CHR-ROM too.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Feb 01, 2009 3:54 pm 
Offline

Joined: Mon Oct 30, 2006 8:32 pm
Posts: 122
Good job, and thanks for the link. I only see one problem:

wiki wrote:
A game that scrolls in all four directions will often have artifacts on one side of the screen because the NES doesn't have enough VRAM to keep the "seam" where new map data is loaded clean. To hide this, a game such as Jurassic Park might display tiles from a blank pattern table for the first 8 scanlines.


Jurrasic Park DOES do this, and it hides both the top and bottom 16 scanlines (taken from tokumaru's posts here and here.)

Also, you might want to add something based on this to the wiki.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: BARBEERIAN, infidelity, tepples and 8 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