Pixel 250->256 change

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Pixel 250->256 change

Post by Zepper »

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.
Last edited by Zepper on Fri Jan 11, 2013 8:58 am, edited 2 times in total.
User avatar
James
Posts: 431
Joined: Sat Jan 22, 2005 8:51 am
Location: Chicago, IL
Contact:

Re: Pixel 250->256 change

Post by James »

where do you see that in the wiki?
get nemulator
http://nemulator.com
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Pixel 250->256 change

Post by tepples »

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.
Zelex
Posts: 268
Joined: Fri Apr 29, 2011 9:44 pm

Re: Pixel 250->256 change

Post by Zelex »

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.
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Pixel 250->256 change

Post by Quietust »

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.
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: Pixel 250->256 change

Post by Zepper »

Thanks Q. :)
User avatar
James
Posts: 431
Joined: Sat Jan 22, 2005 8:51 am
Location: Chicago, IL
Contact:

Re: Pixel 250->256 change

Post by James »

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).
Thanks. BTW, does dot = 0-based cycles? i.e., dot 0 = cycle 0.
get nemulator
http://nemulator.com
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Pixel 250->256 change

Post by Quietust »

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

Re: Pixel 250->256 change

Post by tokumaru »

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".
Now that's confusing, because we're used to counting pixels from 0 to 255...

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?
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Pixel 250->256 change

Post by Bregalad »

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

Re: Pixel 250->256 change

Post by tokumaru »

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
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.
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Re: Pixel 250->256 change

Post by blargg »

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.
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: Pixel 250->256 change

Post by Zepper »

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).
Last edited by Zepper on Sat Feb 09, 2013 12:44 pm, edited 1 time in total.
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Re: Pixel 250->256 change

Post by blargg »

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.
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: Pixel 250->256 change

Post by Zepper »

I got it.
Last edited by Zepper on Sat Feb 09, 2013 12:44 pm, edited 1 time in total.
Post Reply