PPUCTRL Address Increment

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
nesfanatic
Posts: 2
Joined: Sun Dec 06, 2015 2:06 pm

PPUCTRL Address Increment

Post by nesfanatic »

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?
User avatar
Disch
Posts: 1848
Joined: Wed Nov 10, 2004 6:47 pm

Re: PPUCTRL Address Increment

Post by Disch »

nesfanatic 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?
Correct
If the VRAM address is equal to 0x2000 and PPUCTRL.VRAMAddressIncrement IS set, what should it be set to after a read/write?
0x2020

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.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: PPUCTRL Address Increment

Post by tokumaru »

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 is 32 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.
Last edited by tokumaru on Sun Dec 06, 2015 9:06 pm, edited 1 time in total.
nesfanatic
Posts: 2
Joined: Sun Dec 06, 2015 2:06 pm

Re: PPUCTRL Address Increment

Post by nesfanatic »

Thanks, guys. I understand now.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: PPUCTRL Address Increment

Post by tepples »

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.
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.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: PPUCTRL Address Increment

Post by tokumaru »

Crap, did I just say each tile is 32 bytes? Sorry about that.
tepples wrote:What this does is access the same plane of the same row 2 tiles apart.
Yeah, that would be the correct description.
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.
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.
Post Reply