Do you have specific questions?

http://www.nintendoage.com/forum/...
Nerdy Nights - Week 4 (Color Palettes, Sprites, Second App)

You beat me to it. This is the lesson I am working on now. My earlier post can be ignored.

http://www.nesmuseum.com/images/p...

.... what... the hell... is going on here?......

0+1=4?.. wat?!?! --- essentially the +1 is making me go 'waaaat?!?!' most of all.. 
0+1*2upperbits&lowerbits, so this = 4 sure sure.. but.. ... what????

the 2 +1*2upper&lower makes 6, so seems to fit fine.. but.... .. what?! (doesnt seem to fit with all the other info.. I dunno..)

(been sittin here 20 mins lookin at it feeling my brain tie up into a supercurly knot.. q.q .. )

(note, i r nubish@this..)

- it seems like it's extremely simple to understand, so moving past this without figuring it out makes me feel like Im ignoring a chest that takes a very easy jump just cuz I cant find the right pixel to jump from.. which imo *should* be there...
something like that anyway..

O the left is the pixel data, bits are from 0 to 3. He adds the attribute value*4 to basically "adjust" the output numbers for the tile, basically to show how other colors are chosen. Think of it as a math equation, except with an array.

TileColor+(Palette*4)=Final Color.

PatternTableEntry is 2 bits
AttributeTableEntry is 2 bits

ColorIndex = (AttributeTableEntry << 2) + PatternTableEntry

<< is a "bit shift left" operator

In the example, PatternTableEntry is 2, AttributeTableEntry is 1, thus:

ColorIndex = (1 << 2) + 2 = 4 + 2 = 6

I love you

Ok, so I've been writing these guides down inside a notebook,and I need toknow: can I get a listof what exactly the 16 colors used in the example chart are? like I know #7 is white but what about the rest?

Rephrase the question? The colors are viewable in fceux. But still, the exact colors don't really matter...or at least I see no purpose to needing to know what they are...I mean, the palette data is in the file.

Your code picks the 16 color palette, so that number/color chart is not something to memorize.

Question: The first table above shows a layout of the various addresses and what they are for. The second table goes into further detail for $0000 thru $3FFF and shows $2000 thru $23C0 as being a name table of 30x32 tiles.

1) What exactly is a name table? (I'm not a programmer)

2) How come later on in the tutorial specific values/settings are stored in the low $2000's? These don't seem to be related to tiles.

1) A name table is basically the background for one full screen.

2) The name table starting at $2000 is in the PPU, the values written to the low $2000's are in the CPU. You can't write directly to the PPU, or read from it.

Can someone explain what Attribute Table does to the Pattern Table Entry to change 0 to 4, 1 to 5 and 2 to 6.

The pattern table for that example is using attribute table 1 (remember, we're using hex here), which basically means it's only using colors 4-7. (Attribute table 0 would use 0-3, Attribute table 2 would use 8-11, etc).

The pattern table numbers are showing which color each pixel is using from that attribute table.

The 0s are using the first color out of the second set of attribute colors, which would be color 4 (or black).
The 1s are using the second color out of the second set of attribute colors, which would be color 5 (or red).
The 2s are using the third color out of the second set of attribute colors, which would be color 6 (or yellow).
If there were any 3s, it would use white.

Maybe I'm missing something but what would the possible benefit to having CHR as RAM be? Aren't you just adding a step for the program to copy the data from PRG before it can send sprites to the PPU? Wouldn't that be worse overall for the game?

You can upload graphics on a per-level or per-area basis in your engine is a good one. Animate graphics using less memory in total, and other cool effects like changing all chars by uploading 1 tile instead of changing all the tiles, or swapping a whole bank.

I have a couple other questions. Is the information on the cart viewed as part of the CPU by the console? I see it on the CPU map diagram. Also, if I keep making bigger and bigger cartridges won't they eventually push the system too far? Like how Action 52 and other multicarts can overheat?

There are 2 separate computers in the NES. One is the PRG-ROM, which only sees the CPU ROM. The other is the CHR-ROM, which is used by the PPU for the graphics. BUT if RAM is here, the CPU and upload data to the PPU-RAM. But, they are 2 entirely separate computers. And no, the hardware can do what it can do and that is the limit, cart size can get to as big as you ever need it. The heat problem is entirely bad cart hardware design, nothing about the limits of the system, there are systems in place in the chips and such to make sure even big hardware doesn't use that much power.