nesdev.com

How am I susposed to write bytes to the attribute table? The attribute table must be part of the PPU... and it sits under the nametable, I think.

You write the high, then low byte of the address of the attribute byte you want to update to $2006, then you write the byte you want written to that attribute byte to $2007. This must be done during vblank or while rendering is disabled.


See this for the addresses: http://wiki.nesdev.com/w/index.php/PPU_attribute_tables

Kasumi, thank you!


... I don't understand.

Yeah, it's exactly the same as writing tiles to the name tables. After the 960 name table bytes there are 64 attribute table bytes.

Ah, so that's how it works... I remember now that my sister said it (NESst) saved the attributes with the nametable. Great to know, thank you tokumaru!

I think this means that this value byte would contain the bit order bottomright,bottomleft,topright,topleft... which seems backward to me. Could it be 00000000b instead?

It is how the wiki says it is... You can't really change how the PPU works, the best you can do if a particular order of bits doesn't please you is to use a translation table, to convert from your format to the hardware format.

There's little advantage in that though, because you'd be wasting 256 bytes of ROM and some CPU time reading from the table instead of directly writing values to VRAM without any benefit other than making the attribute data easier for you to type.

Does the wiki say this value byte contains the bit order bottomright,bottomleft,topright,topleft? (Thank you for helping me so much though tokumaru! )

Heh, I always have to check, but yeah, it seems that the attribute bits are arranged like this:


It may look kind backwards since we read numbers from left to right, but when you consider that numbers grow from right to left it's not so weird.

Perhaps what's backwards is that the leftmost part of a pattern table byte is in the high bits, but the leftmost part of an attribute table byte is in the low bits.

^ I don't remember anything about pattern table bytes.



Thank you, kind sir!


It took me a bit to understand because I've never ever thought about numbers growing from right to left... but they do!

Is there a possible way to make the 6 labels a part of the machine? Like, well, make them local labels that I could use. Would I have to make each label different in every file? I'd like to make an assembly object... something like jmp bg0.@MetatileCollision. Is that possible?


Sweet thank you for explaining to me how to use 4bit numbers. I hope, after playing with them a bit, I'll get comfortable using them.

I didn't really understand the question... Why would you JMP to a data table? That would most likely crash the program!

Do you want to use different data for each level or something like that? If that's the case, then the answer is the indirect indexed addressing mode (i.e. LDA ($XX), Y). With that addressing mode you use pointers to define the tables that will be read, and you can alter the pointers as much as you want.

For example, you could have a different name for each collision table (or whatever table you want), and then make a table with all the addresses:


Then you can read the address for the current level and put it in a pointer using the level's index:


Then you can use indirect indexed addressing to read the data, instead of what we had before. The only real difference is that now you'll have to use Y as your index register, because this addressing mode doesn't work with X:




There are lots of ways to use 4-bit numbers. In this case it was convenient to use 4-bit values because 4 bits are enough to represent the metatile coordinates inside a single screen.

hahaha hahaha hahaha (laughing at myself) hahaha ok hahaha! No I shouldn't have typed JMP... ... ...should have gone with lda bg0.@MetatileCollision, 3. I was trying to say I would make an assembly object named bg0. And then I would try to access the third entry of its MetatileCollision array (labeled @MetatileCollision). I wanted to use @MetatileCollision because it is a local label/variable and then hopefully I could leave each file with a label named @MetatileCollision. Or would I need to have a unique label name in each .NAC (nametable & collision) file? We would replace each .NAM file with a .NAC file.

tokumaru, thank you so very much for your explanation of the indirect indexed addressing mode and for the code examples. : )


Ah yes! That's amazing!

Ok here's^ 3 metatiles,each using 6 bytes. Does this mean each new metatile will use 6 bytes? It's confusing trying to complete one .NAC (Nametable & Collision) file. For the attribute bytes we have 64 bytes (8 * 8 ). For the Collision part we will have 240 bytes (16 * 15). So 64 != 240.......... My solution is to increase our metatile size to 32x32. Then we would have 64 bytes for both of them, I think. But, then it's confusing to think about, for me at least. I need some help. Dear God, please help me. Thank you God! Amen.