Nadia wrote:
1) What all can we compress in an NES game? CHR area or PGM area or Both?
For obvious reasons CHR-ROM can't ever be compressed, but if you are using CHR-RAM it makes sense to compress your tiles using the scheme you see fit. However, if you plan on animating patterns during gameplay I suggest you leave those specific tiles uncompressed so you can transfer them to VRAM faster.
I don't see much benefit in compressing code, but data should be compressed whenever possible. Note that compressing data doesn't always mean using one of the classic schemes (RLE, LZSS, LZW, etc) and decompressing big chunks of data to WRAM prior to using them... there are several compression techniques that don't work like that at all.
For example, using metatiles is a form of level map compression, and it doesn't require any more RAM, because you can decompress it on the fly. Without metatiles, each screen would need 1KB of memory (960 tiles + attributes), but with 2x2 metatiles a screen will need only 240 bytes. Of course there is the overhead of the dictionary (metatiles), but the more screens you have the less significant this overhead will be.
In fact, depending on the type of project you're working on, the overhead for metatiles can be close to nothing. I've seen people using 6 bits of the metatile index to indicate which 4-tile group from the pattern table it uses and 2 bits for the palette. This will work fine depending on the complexity of your graphics, and is extremely compact.
Quote:
2) When a cart(like the one used in MC Kid) provides additonal RAM storage, does it have CHR ROM?
There is no rule preventing an MMC3 game from using extra RAM and CHR-RAM, but like tepples said not many commercial games used that combination. It is certainly possible though, even if making carts with that configuration might require some modding of the boards.