...and attribute tables complete the upper two bits? Is this simply to save memory? Also, why are attribute tables set up to represent a 4x4 grid of 8x8 pixel tiles?
Regards,
-Zom
total NES n00b
I'm not sure what you mean by the first question, but I imagine name tables were set up so all the color and tile data could fit into 1k of data. So with 1024 bytes, the first 960 bytes are tile entries, and the last 64 are attribute entries. I'm not sure if they were forced do have it this way for any reason, but I imagine it was just because that seemed to work out.
It reduces the amount of video memory needed to specify an image. An important aspect is that there is less data to set up when changing the image. Just consider a smooth progression from a pixel-mapped display to the NES:
1. Each pixel has its own 24-bit word of memory that specifies the RGB values. Scrolling requires rewriting every pixel. Memory: 360K
2. There is more video memory than pixels on screen (let's say double), and the base address can be changed. Now scrolling just involves changing the base address (except when you hit the edge of the video memory and have to wrap around). Memory: 720K
3. Pixels contain an 8-bit index into a palette of RGB values, reducing data by 66%. Memory: 240K
4. Instead of a single index for every pixel, you have a single 8-bit index for tiles of 8x8 pixels, and a table of 256 8x8 tiles. This is about 1/64 the amount of data (excluding the tile data, which wouldn't be changing constantly). Memory: 1K + 16K for tiles
5. Have multiple palettes, and along with each tile index, an 8-bit index that specifies which palette to apply. Now you can display the same tile graphic in different colors at the same time, instead of having to use separate tiles for the different color schemes. Memory: 2K + 16K for tiles
6. Some systems also add flags for each tile index that specifies whether it's flipped horizontally and/or vertically. Again, this reduces the amount of tile data needed.
The NES stores the palette index for a group of four tiles, rather than for each tile, probably because they wanted a nametable to fit within a power of two bytes. An average of half a bit per tile (32x30 tiles total) fits within 64 bytes, but two bits per tile wouldn't.
blargg wrote:
4. Instead of a single index for every pixel, you have a single 8-bit index for tiles of 8x8 pixels, and a table of 256 8x8 tiles. This is about 1/64 the amount of data (excluding the tile data, which wouldn't be changing constantly). Memory: 1K + 16K for tiles
Just wanted to clarify that in any NES game bigger than 40 KiB, the tile data does change over the course of the program. There are two different ways this happens, and you'll learn them a bit later.