Pattern Table entry color bits

[comegordas]

hi everybody! i'm trying to write a NES emu and i'm having some problems while fetching the 2 lower bits of the palette index given by a pattern table entry. i'll try to be as clear as possible, but since english isn't my native language it's gonna be kind of hard. hope you can understand me...

i've been reading a few documents i've found in NESDEV, and so far what i understand is this:

* in the pattern tables, tiles are stored "layered" into 2 bitplanes
* each bitplane is divided into 8 rows of 1 byte
* each bit in each row represents 1 pixel of the tile

now look at this picture:


EDIT: the pink colored number at the bottom bitplane should be the fourth number at the first column (not the fifth), from bottom to up.

in the image you can see marked in colors how i'm trying to fetch and combine the 2 bits. i mean:

(Notation: Value -> Color number)
00 -> Transparent (marked in red)
01 -> Color #1 (marked in blue)
10 -> Color #2 (marked in green)
11 -> Color #3 (marked in pink)

to get the values listed above, i'm proceding like this:

Bit0 = VRAM[0x000X] & YY;
Bit1 = VRAM[0x000X + 8] & YY;
Index = (Bit1 << 1) | Bit0;

...where YY is 0x80 in case i would want to extract bit 8 of a row, or 0x40 in case i would want to extract bit 7, or 0x20 in case i want would to extract bit 6,...

so thats what i understood, but in this post tepples said: "each row has 8 pixels; the most significant bit of each row is drawn on the left" (it's the penultimate comment in the post).
what did he meant whit "the most significant bit of each row"? since there are 8 rows, by fetching the most significant bit of each row i would be fetching the 2 bits from only the first pixel in each row, so what about the others 7 pixels? i think i'm getting something wrong...

thank you all in advance!

[tepples]

"Most significant bit" refers to the 8 bits in a byte. The bit corresponding to place value $80 is "most significant" because it has the largest place value.

Each 8x1 pixel sliver consists of two 1-byte bitplanes. The pixel corresponding to the most significant bit of each byte is on the left; the least significant bit is on the right. PC CGA/EGA/VGA, Mac, SMS, Apple IIGS super hi-res mode, Genesis, and Super NES also follow this convention. Apple II ordinary hi-res mode, Virtual Boy, and Game Boy Advance follow the opposite convention, with the least significant bit on the left.

[tokumaru]

what did he meant whit "the most significant bit of each row"?

He just meant that bit 7 (the most significant one) represents the left side of the tile. This means that the pixels are displayed on the screen in the same order as they are written in their binary representation (i.e. the pattern %10000000 will have a set pixel at the far right, because the "1" is at the right). It looks obvious, but the PPU engineers could very well have made it the opposite way, so it has to be said.

[comegordas]

thanks for your response tepples!

i know what MSB is, maybe i've formuled the question in a correct way.
let's try it again:
to get the 2 lower bits of the color index i'm fetching one bit of a byte from the first bitplane (in the image, the upper one) and then fetch the corresponding bit in the second bitplane (the lower one). by "corresponding bit" i'm standing for the bit in the second bitplane wich is in the same relative position than the bit in the first bitplane. am i proceding right?

also, i've found this on qeed's doc "The Software Emulation of the NES Console":

pixel_index = ((pattern_table[0] & 0x80) >> 7) | ((pattern_table[7] & 0x80) >> 6));

is that right? or should it be "...pattern_table[8] & 0x80..."?

[tepples]

let's try it again:
to get the 2 lower bits of the color index i'm fetching one bit of a byte from the first bitplane (in the image, the upper one) and then fetch the corresponding bit in the second bitplane (the lower one). by "corresponding bit" i'm standing for the bit in the second bitplane wich is in the same relative position than the bit in the first bitplane. am i proceding right?

Yes.

also, i've found this on qeed's doc "The Software Emulation of the NES Console":

pixel_index = ((pattern_table[0] & 0x80) >> 7) | ((pattern_table[7] & 0x80) >> 6));

is that right? or should it be "...pattern_table[8] & 0x80..."?

Correct: you appear to have found a typo.

[comegordas]

ok i'll notify qeed about his little typo.

so i'll have to do 8x8 = 64 fetches for just every tile i need to show? sounds like the process will be a little slow :\
or theres a faster way to fetch those bits?

[Dwedit]

Usually you do 16 fetches and a bunch of bit shifts/rotations.

[tepples]

PPU reads memory on odd dot clocks from x=1 to x=335 of every scanline, and then it halts from x=336 to x=340 while finishing the horizontal blanking period. Every 8 cycles, the PPU reads memory four times:

x+1: Fetch tile number from nametable
x+3: Fetch color base from attribute section of nametable
x+5: Fetch plane 0 of one sliver from nametable
x+7: Fetch plane 1 of one sliver from nametable and load nametable data into two 8-bit shift registers

Each displayed sliver (8x1 pixel area) comes from four fetches. So each tile needs 32 fetches: 8 for the tile number (1 for each scanline), 8 for the color base (1 for each scanline), and 16 for tile data (1 for each scanline). All of these can be affected by mapper circuitry, which selects which memory area is mapped to a given part of PPU address space or even (in the case of MMC5 ExGrafix) puts data directly on the data bus.

[comegordas]

ok, thank you all for the replies. think i've got it...