Fully understanding attributes

[johnnystarr]

I have been learning with the Nerdy Nights NES tutorials for a few weeks and have some questions not
really clarified in the tuts...

I don't really get the logic behind the following:

You can see there are 8 grid squares horizontally, so there will be 8 attribute bytes horizontally. Then each one of those grid squares is split up into 2x2 tile sections to generate the attribute byte:

No 16x16 area can use more than 4 colors, so the question mark and the block cannot use the greens from the palette.

The part that eludes me is the attribute byte. How does 0013 = 000000111 in binary?
That doesn't even make sense if you are using bit-flags.

Where in the ASM would you store this information? I understand you using the .db pseudo-op,
but how would you load it in the the PPU?

Also, I haven't seen any nametable data that specifies which 2 x 2 tile gets what color pallet / attribute.

I hope these questions make sense.

[3gengames]

00.00.01.11

That means 0,0,1,3 to the NES. Each 2 bits is a value in the attribute. The order to which gets which is:

BBBB.TTTT
RRLL.RRLL

The top bits are the values for the bottom 2 tile groups. The bottom bits are the values for the top 2 tile groups. The top 2 bits inside the nibbles are the right block, the bottom 2 bits inside the nibbles are the left. Pretty much everything is opposite. (Top bits->Bottom blocks, Right 2 bits are left block, etc.)

And you can use .db, but I mostly load files with .include as 1KB of .db statements is pretty just....bad programming/data handling. But you upload the attributes at the end of the nametable. The nametable is 1KB big. The nametable is 32x30, so that's 960 tiles. The extra 64 bytes after that are the arttribute data, thats where it's stores. If you don't scroll, you almost don't even have to care about the attribute data really. Just shove all 1KB of screen data to the PPU and that's all ya have to do to get a screen up with the right palettes.

[johnnystarr]

And you can use .db, but I mostly load files with .include as 1KB of .db statements is pretty just....bad programming/data handling.

In your .include file, are you entering it as just a stream of values?
Do you need to label your other file, or can you put comma separated hex values like this:

Code: Select all

; in mynt.asm
$0F, $EE, $30, $F2...

; in other source file
nt: .include "mynt.asm"

Just curious if it would work that way.

[3gengames]

err, incbin for data. Include is for source includes. But yep, that'll work, that way you can keep screens in a file and hex editor them other than keep them in the source as huge .db statements. But read compilers functions and such to get an idea how it works for you.estassss

[tokumaru]

Code: Select all

; in mynt.asm
$0F, $EE, $30, $F2...

; in other source file
nt: .include "mynt.asm"

Just curious if it would work that way.

Not exactly like that... If "mynt.asm" is indeed a source file, you need .db statements before the byte values, but if it's a binary file (in which cse you shouldn't use the .asm extension) you should use .incbin instead of .include, like 3gengames said.