CHR-ROM vs. CHR RAM

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

CartCollector
Posts: 122
Joined: Mon Oct 30, 2006 8:32 pm

CHR-ROM vs. CHR RAM

Post by CartCollector » Sat Jan 31, 2009 12:09 am

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.

tepples
Posts: 22331
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Sat Jan 31, 2009 2:30 pm

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.

User avatar
tokumaru
Posts: 12042
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Sat Jan 31, 2009 7:08 pm

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.

Celius
Posts: 2157
Joined: Sun Jun 05, 2005 2:04 pm
Location: Minneapolis, Minnesota, United States
Contact:

Post by Celius » Sat Jan 31, 2009 11:08 pm

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...

User avatar
Bregalad
Posts: 8018
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Sun Feb 01, 2009 2:52 am

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 :
(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.
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.
Useless, lumbering half-wits don't scare us.

tepples
Posts: 22331
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Sun Feb 01, 2009 6:21 am

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 :
(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...
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.

User avatar
tokumaru
Posts: 12042
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Sun Feb 01, 2009 8:31 am

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.

CartCollector
Posts: 122
Joined: Mon Oct 30, 2006 8:32 pm

Post by CartCollector » Sun Feb 01, 2009 3:54 pm

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.

User avatar
poorstudenthobbyist
Posts: 231
Joined: Fri Jun 24, 2016 4:20 pm

Re: CHR-ROM vs. CHR RAM

Post by poorstudenthobbyist » Thu Jan 07, 2021 8:42 pm

Sorry to bump such an ancient thread, but I'm having a hard time finding the answer.
On the wiki on this page, the bottom line mentions that some emulators cannot handle NROM with CHR RAM instead of ROM. I can't find the source for this info though, can anyone point me in the right direction? Would this possibly extend to emulator-based clone consoles like the Retron?
Check out my website for NES, SNES, and Genesis tutorials here. And visit my store for some custom tools and boards for making games here.

You can also follow me on Twitter for infrequent updates and bad jokes!

User avatar
rainwarrior
Posts: 8016
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: CHR-ROM vs. CHR RAM

Post by rainwarrior » Thu Jan 07, 2021 11:12 pm

I don't know which emulators do or do not emulate mapper 0 with CHR-RAM, though you can sidestep the problem pretty easily? An NROM + CHR-RAM game could be converted to mapper 2 (extremely common and always with CHR-RAM) with just a couple lines of code. The wiki seems to recommend mapper 34, which is another option, though it's a less widely used mapper. If you don't need the second nametable, you could also use mapper 7, which is very common, but doesn't have horizontal/vertical nametable mirroring.
Last edited by rainwarrior on Fri Jan 08, 2021 12:03 am, edited 1 time in total.

User avatar
tokumaru
Posts: 12042
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: CHR-ROM vs. CHR RAM

Post by tokumaru » Thu Jan 07, 2021 11:34 pm

Mapper 34 (BNROM) with 32KB (or less) of PRG is functionally identical to NROM with CHR-RAM, you don't even need to do any mapper writes, but like rainwarrior said, it's not a very common mapper. Mapper 2 (UNROM) is the second best match, but you need one mapper write to make sure that the bottom 16KB of PRG-ROM are mapped correctly. Just put the reset routine in the upper 16KB and do something like this:

Code: Select all

MapBank:
	lda #$00
	sta MapBank+1 ;must write 0 to a ROM location that contains 0, because of bus conflicts
As for emulator-based consoles, if you're talking about the ones that take actual cartridges, I'm pretty sure that they only support games that are present in their databases. Consoles that use regular ROM files should work well with any common mapper.

User avatar
aquasnake
Posts: 224
Joined: Fri Sep 13, 2019 11:22 pm

Re: CHR-ROM vs. CHR RAM

Post by aquasnake » Fri Jan 08, 2021 8:00 am

mapper241, mapper177, mapper178, mapper15, mapper227

with their default/power-on settings.

it means you do not need to access any mapper registers, already it has been.

User avatar
rainwarrior
Posts: 8016
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: CHR-ROM vs. CHR RAM

Post by rainwarrior » Fri Jan 08, 2021 2:41 pm

aquasnake wrote:
Fri Jan 08, 2021 8:00 am
mapper241, mapper177, mapper178, mapper15, mapper227
All of these are obscure mappers, though. If you're worried about an emulator that doesn't support NROM + CHR-RAM, you're probably also worried about that same emulator not supporting obscure mappers. (E.g. the PowerPak doesn't support any of those except 241.)

Mapper 2 will work on every NES emulator, since it was extremely common.

Mapper 34 works in most emulators, but it was only used in 1 game that isn't generally well liked (Deadly Towers). In recent notability: NES mini doesn't support it.

Mapper 1 or mapper 7 are very common with CHR-RAM too, but start to require more conditions/constraints on what you're doing.

User avatar
poorstudenthobbyist
Posts: 231
Joined: Fri Jun 24, 2016 4:20 pm

Re: CHR-ROM vs. CHR RAM

Post by poorstudenthobbyist » Fri Jan 08, 2021 9:11 pm

rainwarrior wrote:
Fri Jan 08, 2021 2:41 pm
aquasnake wrote:
Fri Jan 08, 2021 8:00 am
mapper241, mapper177, mapper178, mapper15, mapper227
All of these are obscure mappers, though. If you're worried about an emulator that doesn't support NROM + CHR-RAM, you're probably also worried about that same emulator not supporting obscure mappers. (E.g. the PowerPak doesn't support any of those except 241.)

Mapper 2 will work on every NES emulator, since it was extremely common.

Mapper 34 works in most emulators, but it was only used in 1 game that isn't generally well liked (Deadly Towers). In recent notability: NES mini doesn't support it.

Mapper 1 or mapper 7 are very common with CHR-RAM too, but start to require more conditions/constraints on what you're doing.
Ok, I forgot to subscribe to the thread/board, so I almost missed these responses. It sounds like Mapper 2 is the best option.
Apologies if this is a dumb question (it is the Newbie Help Center, though, so hopefully it's acceptable) - if a game that uses Mapper 2 is 16K or less, is it functionally an NROM, since you won't need to use the '161 for mapping anything?

I am pretty familiar with hardware and the theory of operation, so I am trying to expand my knowledge on the software side of things more.
tokumaru wrote:
Thu Jan 07, 2021 11:34 pm
As for emulator-based consoles, if you're talking about the ones that take actual cartridges, I'm pretty sure that they only support games that are present in their databases. Consoles that use regular ROM files should work well with any common mapper.
Wait, really? So, there are emulation consoles that can't run homebrew games at all? I know the Retron can't play NES Maker games, for example, but I figured that was because the emulators might not know what to do with mapper 30.
Check out my website for NES, SNES, and Genesis tutorials here. And visit my store for some custom tools and boards for making games here.

You can also follow me on Twitter for infrequent updates and bad jokes!

User avatar
rainwarrior
Posts: 8016
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: CHR-ROM vs. CHR RAM

Post by rainwarrior » Fri Jan 08, 2021 9:26 pm

poorstudenthobbyist wrote:
Fri Jan 08, 2021 9:11 pm
if a game that uses Mapper 2 is 16K or less, is it functionally an NROM, since you won't need to use the '161 for mapping anything?
Yes, that should in theory act the same as NES-128k, since $C000-FFFF is fixed to the last bank already.
poorstudenthobbyist wrote:
Fri Jan 08, 2021 9:11 pm
Wait, really? So, there are emulation consoles that can't run homebrew games at all? I know the Retron can't play NES Maker games, for example, but I figured that was because the emulators might not know what to do with mapper 30.
The Retron 5 won't play any cartridge that isn't already in its database. Doesn't matter about the mapper.

However, since under the hood it just dumps to an .NES and runs FCEUX internally, people did find a workaround. You can just use its IPS patching feature to apply a "patch" that replaces the whole ROM, header included, and it'll run anything its version of FCEUX does.

Post Reply