How does the VRAM address increment field in PPUCTRL affect the VRAM address when reading/writing? Specifically, I don't understand what "add 32, going down" means, which is what http://wiki.nesdev.com/w/index.php/PPU_ ... #PPUSCROLL mentions that the VRAM address should do when the field is set.
For example:
If the VRAM address is equal to 0x2000 and PPUCTRL.VRAMAddressIncrement is NOT set, it should be set to 0x2001 after a read/write?
If the VRAM address is equal to 0x2000 and PPUCTRL.VRAMAddressIncrement IS set, what should it be set to after a read/write?
PPUCTRL Address Increment
Moderator: Moderators
Re: PPUCTRL Address Increment
Correctnesfanatic wrote:If the VRAM address is equal to 0x2000 and PPUCTRL.VRAMAddressIncrement is NOT set, it should be set to 0x2001 after a read/write?
0x2020If the VRAM address is equal to 0x2000 and PPUCTRL.VRAMAddressIncrement IS set, what should it be set to after a read/write?
You either add 1 or 32 (0x20) to the address on read/write depending on that bit. Adding 1 conceptually moves the address to the "right" one tile, while adding by 32 conceptually moves the address "down" one tile (since there are 32 tiles per row).
So setting this bit will allow games to draw a column of tiles to the screen.
Re: PPUCTRL Address Increment
0x2020. The "going down" part refers to the fact that name tables are 32 tiles wide, so adding 32 is effectively the same as going 1 tile down. It's useful for drawing columns of tiles, something that's commonly done in side scrollers.
Of course, the expression "going down" doesn't really apply when other parts of VRAM are accessed, such as pattern tables. Since each tile is32 16 bytes, the increment 32 mode would result in every nth byte of each pair of tiles being accessed. Not particularly useful.
For attribute tables it still goes down, but since each attribute table is 8 bytes wide, it goes 4 attribute blocks down, instead of one, which is still useful (a full column update can be done by setting the address 4 times, instead of 8).
EDIT: For some reason I said that each tile is 32 bytes, but tiles are obviously 16 bytes each.
Of course, the expression "going down" doesn't really apply when other parts of VRAM are accessed, such as pattern tables. Since each tile is
For attribute tables it still goes down, but since each attribute table is 8 bytes wide, it goes 4 attribute blocks down, instead of one, which is still useful (a full column update can be done by setting the address 4 times, instead of 8).
EDIT: For some reason I said that each tile is 32 bytes, but tiles are obviously 16 bytes each.
Last edited by tokumaru on Sun Dec 06, 2015 9:06 pm, edited 1 time in total.
-
- Posts: 2
- Joined: Sun Dec 06, 2015 2:06 pm
Re: PPUCTRL Address Increment
Thanks, guys. I understand now.
Re: PPUCTRL Address Increment
What this does is access the same plane of the same row 2 tiles apart. It turned out to be just what I needed when unrolling a loop to copy a rendered line of proportional text from a buffer in RAM to VRAM.tokumaru wrote:Of course, the expression "going down" doesn't really apply when other parts of VRAM are accessed, such as pattern tables. Since each tile is 32 bytes, the increment 32 mode would result in every nth byte of each tile being accessed. Not particularly useful.
Re: PPUCTRL Address Increment
Crap, did I just say each tile is 32 bytes? Sorry about that.
Yeah, that would be the correct description.tepples wrote:What this does is access the same plane of the same row 2 tiles apart.
Well, I guess it can be useful if you're drawing images entire lines at a time, as opposed to doing it in blocks. The pattern tables would feel more linear.It turned out to be just what I needed when unrolling a loop to copy a rendered line of proportional text from a buffer in RAM to VRAM.