The missing dot is not just a thing that helps stabilize the colors in a picture, it's literally a missing dot. The first scanline is literally twitching left and right by one pixel every other frame. You probably can't see it on your TV without messing with the vertical hold.
It turns out which scanline counts as "first" depends on whether we're talking about SMPTE 170M (analog composite video) or Rec. 601 (digital composite video). Per the specifications, in 170M there are half lines but in Rec 601 there aren't.
As far as I understand it, the missing cycle at the end of the pre-render scanline means that the first scanline will start a cycle early every other frame. When this happens, that scanline will be drawn one pixel to the left of where it should be. In practice, this typically causes the first few scanlines to get skewed slightly (you can see this at the top right corner of your Mighty Bomb Jack screenshot) but I don't know enough about NTSC decoding to explain why this happens. This is more noticeable if you can get footage of the system displaying tiles on the top of the background, rather than the plain blue background at the top like your Mighty Bomb Jack screenshot has.
The missing dot is not just a thing that helps stabilize the colors in a picture, it's literally a missing dot. The first scanline is literally twitching left and right by one pixel every other frame. You probably can't see it on your TV without messing with the vertical hold.
I thought the first scanline was wacky because it's sending one extra pixel than the other ~239 lines...
Side rant, isn't that actually scanline 22? Scanline 21 is off-screen, its where closed captions used to come from...
It turns out which scanline counts as "first" depends on whether we're talking about SMPTE 170M (analog composite video) or Rec. 601 (digital composite video). Per the specifications, in 170M there are half lines but in Rec 601 there aren't.
Nothing is actually rendered on the pre-render scanline, though?
As far as I understand it, the missing cycle at the end of the pre-render scanline means that the first scanline will start a cycle early every other frame. When this happens, that scanline will be drawn one pixel to the left of where it should be. In practice, this typically causes the first few scanlines to get skewed slightly (you can see this at the top right corner of your Mighty Bomb Jack screenshot) but I don't know enough about NTSC decoding to explain why this happens. This is more noticeable if you can get footage of the system displaying tiles on the top of the background, rather than the plain blue background at the top like your Mighty Bomb Jack screenshot has.
That's probably in an overscan area on most TVs, so it might not even show up.
That is correct. The PPU does the memory fetches that would be done for that line, but no pixels are rendered.
For details: https://www.nesdev.org/wiki/PPU_rendering
Also, RGB PPUs (with the exception of the RC2C05-99 found in the Famicom Titler) do not do this, as they don't have to contend with a colorburst.
Growing up I definitely noticed the wobble.
But I'm also so used to it that I didn't realize a lot of examples were videos.
Really interesting investigation!
See also: https://www.nesdev.org/wiki/NTSC_video
The VS system that Nintendo built for arcades with high-quality CRTs has a graphics processor that does output RGB, unlike the NES/Famicom PPU.
Don't the vast majority of RGB PPUs forego the missing dot? IIRC only the Famicom Titler RGB PPU has the missing dot.