It is currently Mon Oct 16, 2017 9:10 pm

 All times are UTC - 7 hours

 Page 1 of 1 [ 3 posts ]
 Print view Previous topic | Next topic
Author Message
 Post subject: PPU VRAM address write behavior?Posted: Fri Aug 30, 2013 2:10 pm

Joined: Fri Jul 19, 2013 11:38 am
Posts: 115
I was reading "The skinny on NES scrolling", which, among other things, describes what happens with the current/temporary VRAM address when a program writes to \$2000, \$2005 and \$2006. I either don't understand the general way the document explains things, or I just don't understand the VRAM address's working. This is what I mean:

Quote:
\$2000 write:
t: ...BA.. ........ = d: ......BA

Where t is supposedly the VRAM value, and d is the data written to it. So, as far as I can understand, if a program writes 11 to \$2000, the VRAM value is set to 0001100 00000000? Why is this? Why is the location so seemingly random?

There are more of these cases which I cannot understand:

Quote:
\$2005 first write (w is 0):
t: ....... ...HGFED = d: HGFED...
x: CBA = d: .....CBA
w: = 1

I just don't get the general premise of this one. What is meant with HGFED...? Am I misunderstanding when I say that any of these letters is a random 1 or 0? So if that's the case, HGFED... could be something like 10110000, right? And what's with the second value, .....CBA? Does that belong with the previously mentioned HGFED...? Is the written value actually HGFEDCBA, and does it get split and written to different registers, i.e. the first 3 bits are written to the X register, and the last 5 are written to the T register? Why is this? What's the logic behind this functioning? The only thing I understand is the w: = 1, but other than that, all of this seems completely random. The same thing applies to the next couple of things:

Quote:
\$2005 second write (w is 1):
t: CBA..HG FED..... = d: HGFEDCBA
w: = 0
\$2006 first write (w is 0):
t: .FEDCBA ........ = d: ..FEDCBA
t: X...... ........ = 0
w: = 1
\$2006 second write (w is 1):
t: ....... HGFEDCBA = d: HGFEDCBA
v = t
w: = 0

\$2005 second write: what's with the random ordering of the bits?

\$2006 first and second write are more understandable to me. I assume the first time data is written, the latter 7 bits are used to store the data, and the second time data is written, the first 8 bits are used to store it. What I don't really understand is the t: X...... ........ = 0 statement when doing the first write to \$2006, and the v = t when doing the second write to \$2006.

I know the question seems a bit large and vague, but I just don't understand the concept behind these registers. I hope someone can explain this to me.

Top

 Post subject: Re: PPU VRAM address write behavior?Posted: Fri Aug 30, 2013 2:22 pm

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19084
Location: NE Indiana, USA (NTSC)
ArsonIzer wrote:
I was reading "The skinny on NES scrolling", which, among other things, describes what happens with the current/temporary VRAM address when a program writes to \$2000, \$2005 and \$2006. I either don't understand the general way the document explains things, or I just don't understand the VRAM address's working. This is what I mean:

Quote:
\$2000 write:
t: ...BA.. ........ = d: ......BA

Where t is supposedly the VRAM value, and d is the data written to it. So, as far as I can understand, if a program writes 11 to \$2000, the VRAM value is set to 0001100 00000000? Why is this? Why is the location so seemingly random?

It's not random. In the NES memory map, those two bits are the bits that control which nametable the PPU will read from.

Quote:

There are more of these cases which I cannot understand:

Quote:
\$2005 first write (w is 0):
t: ....... ...HGFED = d: HGFED...
x: CBA = d: .....CBA
w: = 1

I just don't get the general premise of this one. What is meant with HGFED...? Am I misunderstanding when I say that any of these letters is a random 1 or 0? So if that's the case, HGFED... could be something like 10110000, right?

Yes.

Quote:
Is the written value actually HGFEDCBA, and does it get split and written to different registers, i.e. the first 3 bits are written to the X register, and the last 5 are written to the T register?

Yes.

Quote:
Why is this?

Scrolling on the NES works by reading part of a tile every 8 pixels of the screen, converting that tile to a sequence of 8 pixels, and delaying this sequence by a value between 0 and 7 pixels. Because each tile is 8 pixels wide, the horizontal position in tiles is one-eighth (1/8) of the horizontal position in pixels. Changing the nametable address moves around in the background plane by units of eight pixels. To move in units smaller than one tile, you need to control the delay value, which is why that's called the "fine scroll amount".

When you divide a binary number of the form HGFEDCBA by eight, you always get HGFED, remainder CBA. So the bits of the nametable address corresponding to the horizontal position in tiles are set to HGFED, which is the horizontal position divided by eight, and the fine scroll amount is set to CBA.

Quote:
what's with the random ordering of the bits?

Again, converting a Y coordinate to position of the tile within the nametable (HGFED) and position of the pixel within the tile (CBA).

Top

 Post subject: Re: PPU VRAM address write behavior?Posted: Sat Aug 31, 2013 5:09 am

Joined: Fri Jul 19, 2013 11:38 am
Posts: 115
Thanks a lot for taking the time to explain this tepples, I now fully understand the role and working of the VRAM addresses

Top

 Display posts from previous: All posts1 day7 days2 weeks1 month3 months6 months1 year Sort by AuthorPost timeSubject AscendingDescending
 Page 1 of 1 [ 3 posts ]

 All times are UTC - 7 hours

#### Who is online

Users browsing this forum: Bing [Bot] and 7 guests

 You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum

Search for:
 Jump to:  Select a forum ------------------ NES / Famicom    NESdev    NESemdev    NES Graphics    NES Music    Homebrew Projects       2017 NESdev Competition       2016 NESdev Competition       2014 NESdev Competition       2011 NESdev Competition    Newbie Help Center    NES Hardware and Flash Equipment       Reproduction    NESdev International       FCdev       NESdev China       NESdev Middle East Other    General Stuff    Membler Industries    Other Retro Dev       SNESdev       GBDev    Test Forum Site Issues    phpBB Issues    Web Issues    nesdevWiki