It is currently Wed Oct 18, 2017 6:18 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Sun Nov 28, 2004 11:27 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 615
Why do some games use ROM and some use RAM for graphical storage? I have some ideas.

With mapperless games it is evident why. As the PPU can addres 8KB of graphics and the CPU 32KB of code, why waste a large portion of the 32KB space reserved for code? After all, if the tiles do not come from the character rom, then they must come from program rom.

Adding mappers changes makes the decision more complex. I think cost is the main factor. An 8KB RAM module costs less and is far more easier to procure than a custom ROM chip. Each character ROM chip is unique to a game and is manufactured that way in the factory. If a game is only to be 128KB then there may be no cost-justifying purpose for using character rom. Moreover, bankswitching character rom with a simple 161 mapper leaves less space for program rom banks. Such mappers only switch in 8KB banks, which can be inflexible. More complex methods of bankswitching character rom is generally not found outside Nintendo's MMC chips, and the Big N's technology didn't come cheap.

I have heard that accessing RAM is faster than accessing ROM, but on the NES are the savings worth it? With ROM, all the programmer has to do is send the index numbers of the tiles he wishes to use in his background straight to the NES's PPU and thence to V-RAM (I know this is a gross simplification of how name tables work.) But if he has character RAM he must send the tile data to the CPU, then to the PPU which will send it to the RAM sitting right beside the program ROM, in addition to all of the above.


Top
 Profile  
 
PostPosted: Mon Nov 29, 2004 2:37 am 
Offline

Joined: Mon Nov 22, 2004 3:24 pm
Posts: 162
Location: Sweden
There are some other things you might want to consider when choosing between ROM and RAM.

The obvious advantage of ROM banking is that it enables you to switch tilesets a whole lot faster. While this might not be much of an issue when changing levels it's a very neat feature to dynamically switch sprites as needed. The later Megaman games uses the MMC3's capability to switch multiple parts of the sprite tileset individually to swap in new enemies and animations mid-level.

Perhaps the greates advantage of RAM is that it enables you to compress the tilesets in ROM. Even some of the faster algorithms can often halve the their size.
RAM can also be used to animate a single tile to achieve many special effects that would otherwise waste multiple ROM banks (think paralax scrolling or snow/water effects).
And then there's the infamous Elite that does vector graphics by plotting to the tileset.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Nov 29, 2004 11:26 am 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
CHR-RAM allows for your game to do graphic edits without needed to have all the graphics pre-rendered (so.. dynamic image manipulation). Final Fantasy 3 does some nifty animation with its overworld water that couldn't be done with CHR-ROM without wasting a whole lot of graphics space.

CHR-RAM also allows you to change and rearrange individual tiles instead of having to work with bank restrictions. You can 'swap out' a single tile with CHR-RAM.. whereas I believe the smallest swappable CHR-ROM bank is 1k (64 tiles).

But as already mentioned... swapping out CHR-ROM banks is WAY faster than rewriting your pattern tables in CHR-RAM


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 09, 2004 6:00 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 615
Essentially using RAM is simple (no need to bank 8KB of CHR-RAM), cost-effective, and flexible. Using ROM is speedy and good when you are approaching the board's PRG-ROM limit.

Quote:
The later Megaman games uses the MMC3's capability to switch multiple parts of the sprite tileset individually to swap in new enemies and animations mid-level.


Only Mega Man 3 and 5 do this, as they use CHR-ROM. Mega Man 4 and 6 use CHR-RAM, so they would have to rely on other methods to swap sprite tiles in mid-level.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 10, 2004 4:02 am 
Offline

Joined: Mon Nov 22, 2004 3:24 pm
Posts: 162
Location: Sweden
Great Hierophant wrote:
Only Mega Man 3 and 5 do this, as they use CHR-ROM. Mega Man 4 and 6 use CHR-RAM, so they would have to rely on other methods to swap sprite tiles in mid-level.

My god, you're right.
I just checked MM6 out and it implements some very clever swapping of both for the foreground and background tiles.
Essentially the game emulates an MMC3 with 4 swappable background banks and 2 swappable sprite banks, both of which can be updated while the display is on. A few frames before a new enemy is introduced the sprite tiles begins to change, this must require very calculated enemy sequences to work seamlessly.
Considering that the vblank is only about 2000 cycles of which 800 or so is allocated for sprite dma and scrolling and that a copying a single byte takes 8 cycles, this means that a single swap occupies about 14 frames. Maybe the PPU is turned off a few lines early to gain a few precious vblank lines?

I'm impressed. I'm even considering switching to CHR-RAM myself.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 10, 2004 2:00 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7227
Location: Chexbres, VD, Switzerland
Quote:
My god, you're right.
I just checked MM6 out and it implements some very clever swapping of both for the foreground and background tiles.


That souldn't be that hard to do, you just need a few buffers saying if you're swapping something and read them every frame.

Chr-Ram option also as a great advantage : You can "switch" every single tile to have any custom tileset. For exemple, any playable or unplayabe character from Final Fantasy 1-3 are 16 tiles weight. You always have the playable hero in sprite pattern table #00-#0f, then other people. This would be impossible using ChrRom (exept having a bank per playable hero, so 12 similars banks in FF1, and about 24 in FF3 !!). This is the equivalent to swap 16 tiles banks.
One other example from FF2 and 3 (not 1), every time you attack, the weapon's graphics are set in the pattern table before animation. Using chr-rom, this would be imposible, so a smaller space would be present for the other sprites, like FF1.
Here you are a list to compare different graphics methods :

CHR ROM :
Automatic swap (don't need to have huge transfer subroutines) : YES
Fast tileset swap (usefull for animation) : YES
100% Custom tileset : NO (fixed tileset)
Special BG animation effect : YES, but this waste a lot of space (usefull only with 1kb/2kb swapping)

CHR RAM :
Automatic swap : NO (you need huge transfer subroutines)
Fast tileset swap : NO
100% Custom tileset : YES
Special BG animation effect : YES (but only a smal number of tiles can do this)

MMC5's ExGrafix mode (using CHR ROM) :
Automatic swap : YES for sprites, NO for bg (you need to set the ExRam)
Fast tileset swap : YES for sprites, NO for bg
100& Custom tileset : NO for sprites, YES for bg (ExRam parameters can cover the whole Chr chip, you don't need to switch Chr banks midframe, etc...)
Special BG animation effect : NO (unless if you change the ExRam every frame, Just Breed does this, but it should be still hard to do)

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


Last edited by Bregalad on Sat Dec 11, 2004 7:38 am, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 10, 2004 3:44 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3470
Location: Indianapolis
Some code I wrote for an unfinished game had to update at least 64 bytes of CHR-RAM every frame (not including name/attrib table updates) for animating various 16x16 sprites from a huge selection of possible tiles.

So I had a really large unrolled load routine for it in RAM, it was just basically like this:
Code:
lda #0
sta $2006
lda #0
sta $2006
lda #0
sta $2007
lda #0
sta $2007
etc.


That's only 6 cycles per byte during vblank, though it costs some time to pre-load that buffer.

I really like using CHR-RAM, myself. If you've seen the title screen fadeout effect on Munchie Attack, on there I'm simply changing one bit per frame on a single tile.

The only thing that would make CHR-RAM more fun for me is if a 4kB page could be fixed while the other 4kB can be bankswitched. Unfortunately, my Squeedo cart just swaps the whole 8kB page, but it's still pretty cool.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 10, 2004 10:26 pm 
Bregalad wrote:
Chr-Ram option also as a great advantage : You can "switch" every single tile to have any custom tileset. For exemple, any playable or unplayabe character from Final Fantasy 1-3 are 16 tiles weight. You always have the playable hero in sprite pattern table #00-#0f, then other people. This would be impossible using ChrRom (exept having a bank per playable hero, so 12 similars banks in FF1, and about 24 in FF3 !!). This is the equivalent to swap 16 tiles banks.
One other example from FF2 and 3 (not 1), every time you attack, the weapon's graphics are set in the pattern table before animation. Using chr-rom, this would be imposible, so a smaller space would be present for the other sprites, like FF1.


As well as sprites, FF3 also uses mix-n-match custom BG tilesets in its "locations" (caves, towns, buildings, etc). Each location uses one of three sets of 26 tiles for the common objects (doors, chests, stairs), one of a dozen or so sets of 14 tiles for walls and floors, and three sets of 16 tiles and three sets of 8 tiles out of a "palette" of over 1000 tiles for other, location-specific objects. This fine-grained customization wouldn't be possible with CHR ROM bankswitching, not without duplicating a whole lot of tiles.


Top
  
 
 Post subject:
PostPosted: Sat Dec 11, 2004 12:12 am 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 615
Quote:
The only thing that would make CHR-RAM more fun for me is if a 4kB page could be fixed while the other 4kB can be bankswitched. Unfortunately, my Squeedo cart just swaps the whole 8kB page, but it's still pretty cool.


Get a Videomation CPROM cart, which does exactly that with 16KB of CHR-RAM, and replace the ROM with something writable. Of course, 32KB of PRG-ROM isn't much to work with these days, so you may wish to use the extra lines on the '161 to increase the PRG-ROM up to 128KB, ala BNROM. Even still you won't be creating Grand Theftendo with such a cart.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Dec 11, 2004 4:38 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7227
Location: Chexbres, VD, Switzerland
Memblers wrote:
If you've seen the title screen fadeout effect on Munchie Attack, on there I'm simply changing one bit per frame on a single tile.

Yeah, many SNES square games uses a similar effect when a monster is anihilated, ie FFMystic Quest, Final Fantasy 5, Live a Live, Chrono Trigger, ...
Quote:
I just checked MM6 out and it implements some very clever swapping of both for the foreground and background tiles.

I just noted that this stuff is already used in the first megaman, so it's not modern-stuff or anything.

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


Top
 Profile  
 
 Post subject:
PostPosted: Sat Dec 11, 2004 6:01 am 
Offline

Joined: Mon Nov 22, 2004 3:24 pm
Posts: 162
Location: Sweden
Bregalad wrote:
Quote:
I just checked MM6 out and it implements some very clever swapping of both for the foreground and background tiles.

I just noted that this stuff is already used in the first megaman, so it's not modern-stuff or anything.

But MM1 doesn't do any "live" sprite swapping (at least according to my rather limited investigation). It only swaps sprites at "zone" boundaries where any non-player sprites would be hidden anyway, and I didn't even see any mid-level backround tile switching at all.
My original point wasn't that the technique itself was advanced but rather that being able to cram the same amount of graphics as in the earlier CHR-ROM games without any aparent restrictions is impressive.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Dec 11, 2004 11:33 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7227
Location: Chexbres, VD, Switzerland
Yeah, MM6 swapping seems to be more advanced.
Take a look on Final Fantasy's ending : When the last boss is anihilated and when the word "the end" is sown on the screen are typical Chr-Ram SFX.

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


Top
 Profile  
 
 Post subject: CHR-ROM/RAM
PostPosted: Sat Dec 11, 2004 5:28 pm 
Bregalad wrote:
Quote:

MMC5's ExGrafix mode (using CHR ROM) :
Automatic swap : YES for sprites, NO for bg (you need to set the ExRam)
Fast tileset swap : YES for sprites, NO for bg
100& Custom tileset : NO for sprites, YES for bg (ExRam parameters can cover the whole Chr chip, you don't need to switch Chr banks midframe, etc...)
Special BG animation effect : NO (unless if you change the ExRam every frame, Just Breed does this, but it should be still hard to do)


If you didn't use Exgrafix mode then background could be swapped just fine. Sprites would have more tiles then the background if using 8x16 sprites, but still it would work the same. Although that always confused me how the MMC5 did that. It used the whole memory for sprites....I guess it could switch the tiles around so that'd the background would work too. But what if it needed the exact same tile for both the background and the sprite at the same time?

Hmmm, think about using MMC5 ExGrafix with CHR-RAM. That'd be interesting. You could have a whole screen filled with unique RAM tiles. Effectively making the whole screen bitmapped.

You could then have a buffer of the pixels on the onboard SRAM (you'd prolly need 15 KB and the MMC5 supports that). You could even do double buffering of the screen (which would prolly be necessary as it would take A LOT of VBLANK time to update the whole screen, which means the updating would take many frames to complete). Prolly the VERY best you could do is 4 fps, but you'd have to be a very good coder and use many tricks.

All in all it'd prolly be too hard and slow to do, but not impossible. I guess you'd have too:

1) Switch CHR-ROM with 256KB of CHR-RAM
2) Put MMC5 in ExGrafix mode
3) Put 0-127 into internal NES video ram (1ST nametable RAM), and loop it around 8 times (well until the 960 bytes are full). So put the bytes like 0, 1, 2, 3 etc....and then when you put 127 loop around back to 0 until the whole screen is filled up with 0-127 tiles.
4)Same thing as step 3, but do it with 128-256 and to NameTable 2.

5)Then put 0s in the first 128 bytes of $5C00-$5CFF, and then 1s in the second 128 bytes, 2s in the third 128 bytes, and so on. That would allow both the nametables to then have their own bitmapped screen.

6) You should then use MMC5 IRQs to allow you to get 15 more VBLANK scanlines. Put 224 into $5203 and activate IRQs with $5204. As soon as the IRQ triggers turn off the screen and use the 15KB of on-board RAM and write the bytes to CHR-RAM (you'll need to turn turn ex-grafix mode off, and switch banks to eventually write to it all).

7)You could show NameTable 1 and then write to Nametable 2 and then when your done updating Nametable 2 switch to it via $2000. You could prolly only get 1 frame per second, but possibly more if you code it real well and/or reduce the screen resolution. All of the 15KB buffer of pixel memory would be updated outside of VBLANK and then written to CHR-RAM in VBLANK (this that is the only time it can, or if you turn off the screen that would allow you to write to VRAM).

Hmmm, I'm was just thinking that might work, but it prolly doesn't matter because it's very impractle. Just an idea.


MMC5's ExGrafix mode (using CHR RAM) :
Automatic swap : YES for sprites, NO for bg (unless you didn't use EX-Grafix mode)
Fast tileset swap : YES for sprites, NO for bg (unless you didn't use EX-Grafix mode)
100& Custom tileset : YES for sprites, YES for bg (ExRam parameters can cover 256KB of CHR-RAM + you can change the RAM in VBLANK if you wanted)
Special BG animation effect : YES (You could change around some tiles in RAM during VBLANK every frame if you wanted)

The MMC5 even lowers the attribut color range so that each 8x8 pixels could have their own unique 4 colors from the palette.

---------------------------

Anyway, I like CHR-RAM a lot, but CHR-ROM is pretty useful too. Although you could use a board that has both CHR-ROM and RAM (I think an MMC3 board had something like that).

In some vertical shooters (like Crisis Force and Uchuu Keibitai SDF) use CHR ROM (Uchuu Keibitai SDF also uses an MMC5, not Ex-grafix though) and have tiles bankswitched every frame to produce an awsome looking effect, it makes a pseudo vertical scrolling split (it looks cool) by using 8 different tiles for each animation and then changing the banks which "scrolls them" and then using actually scrolling to change the speed and stuff (it looks cool, but I can't explain too well).

I think the effects like that though would do well with CHR-RAM though. You could have attributes for tiles and could scroll then or horizontally flip them and stuff. Like you could scroll a tile by taking the CHR-RAM tile and every frame shifting it's bytes down and looping them around.

All-in-all:

CHr-ROM:

Con:
-Limited tiles (a certain maximum of tiles to have)
-Limited Page Flipping (depending on mapper, smallest is 64 tiles unless you use MMC5)
-Takes up a lot of space with animations

Pro:
-Tiles already are there so less hassle
-More PRG space
-Can switch very fast (mid-frame, even mid-scanline)


CHR-RAM:

Con:
-Longer time to update
-Have to update from PRG-ROM to CHR-RAM, which (with exceptions) can only be done in precious VBLANK time.
-Possible longer loading times if a whole 4KB needs to be updated, while CHR-ROM can do it in a few cycles and it doesn't need to be in VBLANK.
-Animations are possible (completely custom), but only within a certain range of tiles depending on the routine (because it needs to use precious VBLANK time).

Pro:
-Tiles completely customizable.
-Any range of routines can deal with the tiles to produce very neat effects and it could be very flexible, while CHR-ROM would have to waste a whole mess of ROM and would be fixed effects.
-The tiles could be compressed in PRG-ROM (thus overall ROM needed would be less)


Top
  
 
 Post subject: Re: CHR-ROM/RAM
PostPosted: Sun Dec 12, 2004 2:12 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19094
Location: NE Indiana, USA (NTSC)
J2 wrote:
Although that always confused me how the MMC5 did that. It used the whole memory for sprites....I guess it could switch the tiles around so that'd the background would work too. But what if it needed the exact same tile for both the background and the sprite at the same time?

The NES PPU does not read background and sprite data at the same time; instead, it reads background data during draw and sprite data during hblank. The MMC5 appears to count nametable accesses (of which there are always 34 on a scanline).

Quote:
think about using MMC5 ExGrafix with CHR-RAM. That'd be interesting. You could have a whole screen filled with unique RAM tiles. Effectively making the whole screen bitmapped.

CPROM, the Videomation mapper, does nearly the same thing.

Quote:
You could then have a buffer of the pixels on the onboard SRAM (you'd prolly need 15 KB and the MMC5 supports that). You could even do double buffering of the screen (which would prolly be necessary as it would take A LOT of VBLANK time to update the whole screen, which means the updating would take many frames to complete). Prolly the VERY best you could do is 4 fps, but you'd have to be a very good coder and use many tricks.

Better would be to make a custom mapper that uses a really fast SRAM to map VRAM simultaneously into $6000-$7FFF and into PPU space.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Dec 12, 2004 3:50 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7227
Location: Chexbres, VD, Switzerland
Quote:
Hmmm, think about using MMC5 ExGrafix with CHR-RAM. That'd be interesting. You could have a whole screen filled with unique RAM tiles.

How do you want to write to your 256kb Chr-Ram ? MMC5 doesn't support this at all, as far I know. ExGrafix mode was created in compensation of this.
If you want choose between Chr-Rom and Chr-Ram, you should already choose your mapper. Only a few mappers supports both of them (MMC1, MMC3, and I don't know if there is any other). CNROM, MMC2, MMC4 and MMC5 supports only Chr-Rom, and UNROM, ANROM suports only Chr-Ram.

PS : I looked at the Brian povancio's site about his project, Grand Theftendo. He said he's using MMC5 mapper and he also spoke about a tool to compress his graphics. So, that's impossible.

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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users 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