Pixel 250->256 change
Moderator: Moderators
Pixel 250->256 change
Well, it's been a long time since the affirmation of Y incrementing at dot 251 (pixel 250), and now it comes that it occurs at 256 instead, for my surprise. I remember of someone said of such condition (at 251) as "essential" for Battletoads in terms of accuracy.
Could someone clarify such change? I read it at the wiki right now.
Could someone clarify such change? I read it at the wiki right now.
Last edited by Zepper on Fri Jan 11, 2013 8:58 am, edited 2 times in total.
Zepper
RockNES author
RockNES author
Re: Pixel 250->256 change
The wiki's copy of "The skinny on NES scrolling" has been completely overhauled.
I think the issue is this:
"At dot 256 of each scanline: If rendering is enabled, the PPU increments the vertical position in v."
That used to say 251.
I think the issue is this:
"At dot 256 of each scanline: If rendering is enabled, the PPU increments the vertical position in v."
That used to say 251.
Re: Pixel 250->256 change
I thought the end of a scanline was X==341 (with the exception of the pre-scanline which alternates between 340 and 341)
Nevermind, your talking about something else.
Nevermind, your talking about something else.
Re: Pixel 250->256 change
It was something I posted on the Talk page after doing some testing with Visual2C02 - effectively, the VRAM address increments both the H and V bits at dot 256 and then reloads the H bits one pixel later (dot 257).
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.
Re: Pixel 250->256 change
Thanks. BTW, does dot = 0-based cycles? i.e., dot 0 = cycle 0.Quietust wrote:It was something I posted on the Talk page after doing some testing with Visual2C02 - effectively, the VRAM address increments both the H and V bits at dot 256 and then reloads the H bits one pixel later (dot 257).
get nemulator
http://nemulator.com
http://nemulator.com
Re: Pixel 250->256 change
I'm assuming the 0-340 "dot" timings, though the PPU actually starts outputting pixels at "dot 1" and stops outputting them at the end of "dot 256".
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.
Re: Pixel 250->256 change
Now that's confusing, because we're used to counting pixels from 0 to 255...Quietust wrote:I'm assuming the 0-340 "dot" timings, though the PPU actually starts outputting pixels at "dot 1" and stops outputting them at the end of "dot 256".
So there are 341 dots, numbered 0 through 340, but there's 1 dot before the visible area of the scanline? The scroll counters are updated at the same time that the last pixel is rendered (dot 256)? Which dot is skipped every other frame when rendering is enabled?
Re: Pixel 250->256 change
I think the numering is arbitrary really. There is a periodic thing that takes 341 cycles, 256 of them being visible pixels and 85 of them being hblank.
There is 341 ways to number this, but only 2 of them really make sense :
1) Put the HBlank before the visible scanline
2) Put the HBlank after the visible scanline
Also the dots can be numbered from 1 to 341 or from 0 to 340, it's a matter of preference.
For some reason Nintedulator and all the NEStech docs uses the second one when I think the 1st one would make more sense, especially when you know sprites are evaluated during HBlank for what they will be displayed on the following drawn pixels. Depending on where you "imagine" the HBlank it could be the same scanline or the following scanline. Probably the reason HBlank was placed "after" the scanline is because the NNI fires after the last HBlank. (I think, I don't know all this stuff by heart so I might be wrong).
There is 341 ways to number this, but only 2 of them really make sense :
1) Put the HBlank before the visible scanline
2) Put the HBlank after the visible scanline
Also the dots can be numbered from 1 to 341 or from 0 to 340, it's a matter of preference.
For some reason Nintedulator and all the NEStech docs uses the second one when I think the 1st one would make more sense, especially when you know sprites are evaluated during HBlank for what they will be displayed on the following drawn pixels. Depending on where you "imagine" the HBlank it could be the same scanline or the following scanline. Probably the reason HBlank was placed "after" the scanline is because the NNI fires after the last HBlank. (I think, I don't know all this stuff by heart so I might be wrong).
Re: Pixel 250->256 change
Well, Quietust apparently put 1 cycle of HBlank before the visible scanline and 84 after. With so many ways to number these thinks, I can never know what people actually mean when they say "the vertical scroll increments at dot 256". IMO these times should all be relative to the pixels, because they are easy to visualize, and not two numbering styles running in parallel so that you have to constantly convert between them to understand what happens when.Bregalad wrote:There is 341 ways to number this, but only 2 of them really make sense :
1) Put the HBlank before the visible scanline
2) Put the HBlank after the visible scanline
Re: Pixel 250->256 change
I'd think they'd be numbered relative to whatever internal counter keeps track of the 341 count. When it's zero, you're on dot zero, even if the first pixel starts on dot 42.
Re: Pixel 250->256 change
Example: "at pixel 256", is this the 256th PPU pixel or it's being counted from zero, as "pixel 0, pixel 1... pixel 255"?
For my best (most of you will disagree), "256th PPU pixel" means the output pixel number counted from 1 up to 256, and "dot" as the relative PPU scanline cycle, starting at zero, after the last HBlank cycle).
For my best (most of you will disagree), "256th PPU pixel" means the output pixel number counted from 1 up to 256, and "dot" as the relative PPU scanline cycle, starting at zero, after the last HBlank cycle).
Last edited by Zepper on Sat Feb 09, 2013 12:44 pm, edited 1 time in total.
Zepper
RockNES author
RockNES author
Re: Pixel 250->256 change
My take on naming:
"at pixel 256" is referring to the pixel with the label 256, sort of like "at pixel Marvin". So the meaning of 256 here depends on how we've defined them. Usually this means they're numbered from 0, otherwise we'd just say the 256th pixel if they were numbered from 1.
"at the 257th pixel" uses the standard definition of 257th, that is, that there are 256 prior pixels.
"at pixel 256" is referring to the pixel with the label 256, sort of like "at pixel Marvin". So the meaning of 256 here depends on how we've defined them. Usually this means they're numbered from 0, otherwise we'd just say the 256th pixel if they were numbered from 1.
"at the 257th pixel" uses the standard definition of 257th, that is, that there are 256 prior pixels.
Re: Pixel 250->256 change
I got it.
Last edited by Zepper on Sat Feb 09, 2013 12:44 pm, edited 1 time in total.
Zepper
RockNES author
RockNES author