nesdev.com
http://forums.nesdev.com/

PPUCTRL Address Increment
http://forums.nesdev.com/viewtopic.php?f=3&t=13597
Page 1 of 1

Author:  nesfanatic [ Sun Dec 06, 2015 2:14 pm ]
Post subject:  PPUCTRL Address Increment

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?

Author:  Disch [ Sun Dec 06, 2015 2:41 pm ]
Post subject:  Re: PPUCTRL Address Increment

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

Quote:
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.

Author:  tokumaru [ Sun Dec 06, 2015 2:44 pm ]
Post subject:  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 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.

Author:  nesfanatic [ Sun Dec 06, 2015 7:26 pm ]
Post subject:  Re: PPUCTRL Address Increment

Thanks, guys. I understand now.

Author:  tepples [ Sun Dec 06, 2015 7:51 pm ]
Post subject:  Re: PPUCTRL Address Increment

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.

Author:  tokumaru [ Sun Dec 06, 2015 9:13 pm ]
Post subject:  Re: PPUCTRL Address Increment

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.

Quote:
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.

Page 1 of 1 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/