koitsu wrote:
If there isn't CHR-RAM on the cartridge, and there's no CHR-ROM on the cartridge, then your pattern table (PPU $0000-1FFF) will be most likely gibberish/trash/gobbledegook.
Yeah, there's no way to produce real NES graphics without *something* inserted into the cartridge slot. In order to use the the internal VRAM for patterns, you need to some pins in the cartridge port connected together.
Quote:
Otherwise, the NES *natively* has memory for two nametables (1024 bytes each, which includes the attribute table), 16 bytes for palette, and an internal 256 bytes for OAM. (1024*2)+16+256 = $910 = 2320 bytes. This does not include internal buffers (say, a couple bytes) for latches and whatever else.
Just to be a little pedantic: The palette actually has 28 physical entries (16 for the background, out of which only 13 are normally displayable, and 12 for sprites), but AFAIK the PPU doesn't store the upper 2 bits of a color entry (NES colors are only 6 bits after all), so the palette is more like 168 bits, the equivalent to 21 bytes. The same goes for the OAM: unimplemented bits in the sprite attribute byte are not kept, so the OAM is actually 1856 bits, the equivalent to 232 bytes. And there's more memory worth of other stuff we don't have direct access to, like secondary OAM, which the wiki says is 32 bytes.
Anyway, while 2KB of VRAM sounds really pitiful compared to the 10KB the NES normally has access to, I still think it's a fun setup to develop simpler games for. If you use 1KB for the background, you get 1KB for patterns, enough for 64 tiles, shared between sprites and the background. If you dynamically allocate tiles for active sprites and animate them by rewriting their patterns, and keep the backgrounds simple, it might be possible to make a game that doesn't feel too far off from earlier NES titles. You could also sacrifice some screen space in the single name table you have in order to get some extra tiles, depending on the kind of scrolling you're doing.