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