nesdev.com

Was it to improve composite picture quality? If it was, they should've had a missing half cycle every frame instead, so that artifacts cancled out entirely.

To improve it even better, each scanline would have been 341.25 pixels (1365 master clocks) long, with the extra master clock not inserted during each of the three lines of vsync. But that would probably have required more logic (therefore more expensive die area and/or more circuit golf) than what they ended up doing.

_________________
Pin Eight | Twitter | GitHub | Patreon

It's definitely there to counter-act composite artifacts, I can't think of any other valid reason.

There's a good thread on the subject here, though it's mostly centered around how to disable the "feature", so I'm not sure if it's able to add anything of value: https://shmups.system11.org/viewtopic.php?f=6&t=61285

Well, I think frame cancellation is more important than line cancellation because you don't lose any information for static screens.

The NES PPU's composite output could have been improved far more by separating chroma from luma signal generation like on the Commodore 64. Not only would this have allowed for separated video output, it would have allowed filtering the chroma signal to the appropriate narrow bandwidth before combining it with the luma signal. The reason why the NES' dot crawl is so bad is mostly not the non-standard line rate, but the fact that there are chroma components above 0.6 MHz that should not be there. I can post simulated images later of how the NES would look at its usual line rate but with proper chroma signal filtering during signal generation.

Really it should just have had native RGB output like almost every other console :\

Trouble is that would have been more expensive in 1983.

_________________
Pin Eight | Twitter | GitHub | Patreon

A bit perhaps, but not much. Commodore did it with their VIC-II chip in the Commodore 64, and Commodore certainly were no-frills minded. In any case, here are the simulated pictures I mentioned earlier:

Chroma signal not filtered before combining with luma signal (i.e. normal NES), single field:


Chroma signal not filtered before combining with luma signal (i.e. normal NES), two merged fields:


Chroma signal low-pass filtered to a 0.61.5 MHz bandwidth before combining with luma signal (i.e. hypothetically improved NES), single field:


Chroma signal low-pass filtered to a 0.61.5 MHz bandwidth before combining with luma signal (i.e. hypothetically improved NES), two merged fields:

How would the four look for a hypothetical NES with a 341.25-dot line? No different from a Wii Virtual Console?

_________________
Pin Eight | Twitter | GitHub | Patreon

Like this:

Chroma signal not filtered before combining with luma signal (i.e. normal NES), single field:

Chroma signal not filtered before combining with luma signal (i.e. normal NES), two merged fields:

Chroma signal low-pass filtered to a 0.61.5 MHz bandwidth before combining with luma signal (i.e. hypothetically improved NES), single field:

Chroma signal low-pass filtered to a 0.61.5 MHz bandwidth before combining with luma signal (i.e. hypothetically improved NES), two merged fields:


As you can see, the merged fields would be almost identical between filtered and unfiltered chroma scenarios in the 341.25 pixels-per-line case; the unfiltered chroma picture being slightly softer. The filtered chroma signal would still be preferable because the individual field is cleaner, and there would be less crawling pixels during scrolling (which I personally find to be the most annoying aspect of the NES' composite output).

Thanks. Halting the PPU and CPU for one master clock to all lines except the 3 sync lines looks like a winner. Famiclone engineers, please take note.

_________________
Pin Eight | Twitter | GitHub | Patreon

But the chrominance bandwidth isn't supposed to be 0.6MHz, it's supposed to be 1.5MHz...

No, not in NTSC. You must be thinking of SMPTE-170M, which came out in 1994 (if I remember correctly), and only applies to "studio applications". 1953 NTSC calls for 1.5 MHz I and 0.6 MHz Q, and since no receiver after 1953's RCA CT-100 goes the exta mile to recover the wideband I signal, chrominance is effectively reduced to 0.6 MHz for both in-phase and quadrature signals. Re-checking my source, given my Gaussian kernel size, I'm actually filtering to 1.78 MHz and not 0.6 MHz as stated, so real decoders will look a bit worse.

Either way, by generating the signal the way it does, the NES generates luminance and chrominance both at 5.37 MHz, which is not as it should be, and is the reason for most of the visible dot crawl.

I don't think I believe that it could possibly be as low as 600kHz.

That's worse than VHS chrominance bandwidth.

Unfortunately, I don't have access to any TVs more than 20 years old to do tests on. :/

But that's what the 1953 NTSC standard calls for:In a 4.2 MHz television channel, only one of the sidebands of the wideband I channel is kept, so unless you do single-sideband demodulation for the high-frequency components of the I signal, there is no way around the 0.6 MHz limit. VHS has 0.4 MHz of chrominance bandwidth, by comparison.

Note that these limitations only apply to 4.2 MHz bandlimited composite signals, and they provide the mathematical basis for "RF quality".

A baseband composite signal on the other hand, where the whole signal can go up as high as 14 MHz or more, can of course retain a chrominance bandwidth up to the subcarrier frequency itself, though no TV receiver will demodulate chrominance components above 1.5 MHz.