I'm new to the site and NES programming. The basic architecture of the NES is making more sense each day, but I can't seem to wrap my head around pattern, name, and attribute tables, especially the extent to which they are interdependent.
The nestech docs, "How NES Graphics Work" file, and NES 101 tutorials all touch upon these concepts, but not clearly enough to make sense to me. Anyone care to take a stab at these three in plain English?
Thanks for helping a beginner.
It depends on how much you know about other display systems that use similar principles. Do you know anything about "text mode" of MDA/CGA/EGA/VGA?
Found a good explanation here:
http://nesdev.com/bbs/viewtopic.php?t=987
Sorry to re-ask a simple question. Back to reading...
Quote:
It depends on how much you know about other display systems that use similar principles. Do you know anything about "text mode" of MDA/CGA/EGA/VGA?
Never heard of it. That's probably not a good sign, huh?
noattack: What was your first computer? Commodore 64? Apple II? ZX Spectrum? Or are you too young to remember anything before Mac and Windows?
I never owned a Commodore or an Apple II as a kid, but we had them in school at the time, so that's what I technically 'grew up with'. I'm 27, so I remember that era, just not in any technical sense.
Let me try to explain it.
Memory is very cheap now, and most computers have enough video memory to have each pixel on the screen 100% independent from all others. In fact, they have much more memory than that.
But at the time the NES was deisgned, they couldn't afford one color for each pixel on the screen. If they had made the NES like that, It'd need at least 60KB of video memory. Also, the 6502 would not be fast enough to draw individual pixels to the screen, and games would be very slow when scrolling and all.
So, they broke up the display in smaller, interdependent units. Let's look first at the pattern table. What is it? It's a collection of tiles (squares of 8x8 pixels) that are used to form the full picture. It's just like if you were laying tiles on your kitchen wall... you have a number of tiles with different patterns, that you use to cover the wall as you like. The ness can use 256 different patterns at a time, and you can place as many of them as you want over your wall.
Your "wall" is the name table, the surface where the tiles are placed. It contains the numbers of the tiles that go in each position. When drawing the screen, the NES reads each value in the name table, and since these values point to tiles in the pattern table, it then draws the patterns pointed by the name table.
That really cuts down the ammount of memory used for video. See, instead of indexing 61440 (256x240) individual pixels, it now indexes only 16384 pixels (arranged as 256 tiles of 8x8 pixels). Plus the memory used by the name tables, of course, but that is much less then the ammount used for patterns.
However, that's still too much, and this is where the attribute tables and the palettes come in. If it was exactly as I said above, each pixel of a tile would use a full byte, be able to point to any of the colors the NES can generate, and there'd be no need for a palette. But that's not the case.
So, the NES let's you define 4 palettes for the background, each composed by 4 colors (not exactly 4, as the first has to be the same for all of them, but ignore that for now). To really cut down on the ammount each pixel uses, each pixel can only have 1 of 4 values. That makes it possible to define the pixels in the patterns with only 2 bits, so the ammount of memory used to define 256 tiles has dropped to 4KB, which is what the NES uses for the background.
Now, since each pixel can only assume 4 values, each tile can only use 4 colors. but you have 4 palettes of 4 colors, and the attribute table is there to tell the NES which of the 4 palettes to use. However, because of more memory limitations, it will only let you assign a different palette to groups of 4 tiles (16x16-pixel square) in the name table. That's why most games build their worlds with 16x16-pixel blocks.
I hope it makes more sense now, but words are words, and the best way for you to really understand that is to try it yourself. You can try to make simple demos, to experiment with the tables. You can also use emulators with good debug capabilities (such as FCEUXD) to manipulate the video memory and see what side effects you get.
Thank you tokumaru, that makes a lot more sense now, especially concerning the attribute tables. As others have said before, this message board is unlike most on the 'net, as you vets are all very helpful and considerate with your time. Thanks.