Why Doesn't the NES Show Artifact Colors?

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Why Doesn't the NES Show Artifact Colors?

Post by tepples »

In PAL, the V plane flips relative to U on every other scanline.

"Phase reversal" in the NTSC sense refers to a different phenomenon. Because a standard scanline is 227.5 cycles long, a vertical edge in a conforming picture will hit opposite phases of U and V from one scanline to the next, causing any color artifacts to visually cancel out. It could be seen as both U and V flipping relative to the start of the horizontal sync pulse.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Why Doesn't the NES Show Artifact Colors?

Post by lidnariq »

Great Hierophant wrote:Apparently [Tandy's CoCo] did not do enough right with composite color because you cannot guarantee which pattern of colors will be generated when you boot the system.
As far as I know, the Apple 2 was the only system that was explicitly designed to make use of artifact color. So I'm not terribly surprised that everywhere else it was a convenient discovery rather than carefully designed in.
tomaitheous
Posts: 592
Joined: Thu Aug 28, 2008 1:17 am
Contact:

Re: Why Doesn't the NES Show Artifact Colors?

Post by tomaitheous »

Speaking of NTSC color artifacts: PC-Engine demo by Chris Covell http://www.youtube.com/watch?v=g51QqurGqg0

7.159mhz dot clock mode used, dot crawl filter turned off (no cycling per frame-to-frame difference).
__________________________
http://pcedev.wordpress.com
supercat
Posts: 161
Joined: Thu Apr 18, 2019 9:13 am

Re: Why Doesn't the NES Show Artifact Colors?

Post by supercat »

lidnariq wrote:When you say "artifact colors", do you mean "composite artifacts" ? Or do you actually mean artifact colors ?

For the latter, to meaningfully be able to generate useful artifact colors, your pixel clock must be at least twice as fast as the NTSC colorburst. The only thing we've really managed on the NES is tepples's "tvpassfail" test that uses specific pixel choice to cancel the actual chroma content. (In fact, because the pixel clock is less than twice the colorburst frequency, i.e. the colorburst frequency is above the Nyquist rate, nothing else is even possible)

Additionally, for it to be practical, it should be a "nice" ratio with a small denominator in the ratio. 1's easy, 2 or 3 would be ok, 7 would be actively obnoxious.
Composite artifact tricks can yield a nice range of colors my NES and television set, even just using a single "four-color" background palette. The one problem I haven't figured out is how to determine the chroma state. There are six chroma states at the start of each frame, which I'll call AA, BB, CC, AB, BC, and CA. If rendering is disabled at the end of vblank, they progress through the states AA, BC, CC, AB, BB, CA. With rendering enabled, they alternate in one of three patterns: AA<->BC, BB<->CA, and CC<->AB. The system can easily display a test pattern to identify the chroma state, and nudge things into any desired state by disabling rendering for 1-5 frames, but don't know of any practical alternative to asking the user to indicate what color things are.

Once color phase is set, all that is necessary to exploit chroma artifacts in the background of a game is to have the three foreground colors be 4 apart, and have three versions of each tile--one for each color phase. While some sets of hardware colors will work better than others, each combination of a background color and three phase-shifted colors can yield up to 64 different colors. While most colors will show some diagonal striping, they are solid enough that they could be used in things like sunset or rainbow effects.

This demo is set up for an NTSC televsion set. Push down (and release) to play chroma roulette. There's a 50/50 shot you'll land on a bad phase (flickery mess); if you do, just push down again. The three groups of 64 boxes show the same colors, but in different order. The four "hardware" colors are in the upper left (black), second row sixth column (lavender), third row tenth colmn (orange), and bottom right (greenish).

One way to think about this demo is to regard the NES as showing each of its built-in colors one of three ways depending upon its exact position and chroma phase, and each pixel will alternate between two of these ways of being displayed. Mixing three colors chosen from a set of four would offer only 20 choices if the order and phase didn't matter (000, 001, 002, 003, 011, 012,013, 022, 023, 033, 111, 112, 113, 122, 123, 133, 222, 223, 233, 333) but on a real set the order and phase do matter, thus enhancing the set to 64 colors.

PS--The demo shows aliasing effects in MESEN with an NTSC video filter selected, but the chroma roulette behavior doesn't match my real system.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Why Doesn't the NES Show Artifact Colors?

Post by lidnariq »

Where's the attachment?
supercat
Posts: 161
Joined: Thu Apr 18, 2019 9:13 am

Re: Why Doesn't the NES Show Artifact Colors?

Post by supercat »

lidnariq wrote:Where's the attachment?
Oops.
Attachments
colorArtifact1.nes
(64.02 KiB) Downloaded 334 times
User avatar
aa-dav
Posts: 220
Joined: Tue Apr 14, 2020 9:45 pm
Location: Russia

Re: Why Doesn't the NES Show Artifact Colors?

Post by aa-dav »

The same question via google led me here.
But I still have a couple of questions.

First of all - then we talk about '~227.5 color bursts per line in NTSC video signal' - how do HBlank periods affect to it?
AFAIU '227.5' number derives from direct calculation with frequencies of 3.58 and 525/60 (latter is approx, I know).
But if we talk about color bursts as about some kind of 'color resolution' we must remember that HBlanks periods in lines take significant amount of time. So what is 'effective color resolution' of the visible NTSC picture per line (or just 'color bursts' in visible picture)?

Second - this article here https://wiki.nesdev.com/w/index.php/NTSC_video states that NES emits 12 consecutive color signals per color burst (making color encoding for NTSC), but makes it 8 times per pixel. That is it 'mixes' 3 pixels into 2 color bursts using some kind of interpolation, however not ideal one. This gives 256/3*2~=171 color bursts per visible line. Am I right? And how this interpolation works? Article has a lot of code, but it is heavy to understand. I am not interestend in exact formulas, but in principles. Is this mixing analog or digital? Or is it automatic consequence of QAM encoding of color information in color burst and no special hardware ever needed?

Thanks.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Why Doesn't the NES Show Artifact Colors?

Post by lidnariq »

aa-dav wrote: Fri Mar 12, 2021 6:23 pm First of all - then we talk about '~227.5 color bursts per line in NTSC video signal' - how do HBlank periods affect to it?
AFAIU '227.5' number derives from direct calculation with frequencies of 3.58 and 525/60 (latter is approx, I know).
227.5 is by definition.

Audio carrier is at 4.5MHz
Hsync rate is 1/286 of audio carrier.
Chroma carrier is at 227.5 times hsync rate.
But if we talk about color bursts as about some kind of 'color resolution' we must remember that HBlanks periods in lines take significant amount of time. So what is 'effective color resolution' of the visible NTSC picture per line (or just 'color bursts' in visible picture)?
Irrelevant, as it turns out. That's not how color decoding works.
Or is it automatic consequence of QAM encoding of color information in color burst and no special hardware ever needed?
This. The QAM signal is demodulated with a defined bandwidth, and that's the color resolution available. It's roughly 1.5MHz, and the NES draws an active portion of 256/341 ≈ 3/4 of a scanline, so there's room for 1.5MHz×2×¾÷15745Hz ≈ 143 distinct colors per scanline.
User avatar
aa-dav
Posts: 220
Joined: Tue Apr 14, 2020 9:45 pm
Location: Russia

Re: Why Doesn't the NES Show Artifact Colors?

Post by aa-dav »

lidnariq wrote: Fri Mar 12, 2021 6:58 pm
aa-dav wrote: Fri Mar 12, 2021 6:23 pm First of all - then we talk about '~227.5 color bursts per line in NTSC video signal' - how do HBlank periods affect to it?
AFAIU '227.5' number derives from direct calculation with frequencies of 3.58 and 525/60 (latter is approx, I know).
227.5 is by definition.
That I meant is:
if we take 3.58MHz frequency, and divide it by number of lines per second we'll get exactly 227.5. But we know that clocks of 3.58MHz are 'distributes evenly across time', so significant count of clocks do not form useful picture being in VBlank+HBlank. So I tried to figure out real 'payload' and so 'resolution'.
Or is it automatic consequence of QAM encoding of color information in color burst and no special hardware ever needed?
This. The QAM signal is demodulated with a defined bandwidth, and that's the color resolution available. It's roughly 1.5MHz
Interesting! But how this number is obtained? Some physical properties of QAM or that? And again, how VBlank/HBlank affect to it?
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Why Doesn't the NES Show Artifact Colors?

Post by lidnariq »

aa-dav wrote: Fri Mar 12, 2021 7:34 pm Interesting! But how this number is obtained?
By definition. (How'd they pick it? I don't know, but it leaves very roughly equal bandwidth below for luma and luma mixed with chroma.)
Some physical properties of QAM or that?
Part of the process of converting CVBS to separate YUV signals involves demodulating the chroma and bandlimiting that. Original (1953) NTSC used different bandwidths for orange-vs-blue ("I") and green-vs-purple ("Q"), but this appears to have been dropped very early on. NewRisingSun has some simulated pictures here: viewtopic.php?p=213874#p213874
aa-dav wrote: Fri Mar 12, 2021 7:34 pm And again, how VBlank/HBlank affect to it?
I did actually answer that in my previous reply.
User avatar
aa-dav
Posts: 220
Joined: Tue Apr 14, 2020 9:45 pm
Location: Russia

Re: Why Doesn't the NES Show Artifact Colors?

Post by aa-dav »

lidnariq wrote: Fri Mar 12, 2021 6:58 pm ...so there's room for 1.5MHz×2×¾÷15745Hz ≈ 143 distinct colors per scanline.
Did I miss this formula first time I read answer? :oops:
It's really the answer I need! Now I see there blanks are turned out.
Last two questions:
- is there simple interpretation of coefficient 2 (like two half-periods) or it's something from deep math behind process?
- how it's better to define "distinct colors/pixels" in analog world? For now I think about it in form of 'ability to change color from deep green to deep red (for example) back and forth during scanline. Am I correct?
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Why Doesn't the NES Show Artifact Colors?

Post by lidnariq »

aa-dav wrote: Fri Mar 12, 2021 8:16 pm Did I miss this formula first time I read answer? :oops:
I probably edited it in while you were composing your preceding reply... :oops:
- is there simple interpretation of coefficient 2 (like two half-periods) or it's something from deep math behind process?
Yes, two half-periods. If the highest frequency you can represent is 1.5MHz, then the sample rate needed for that frequency is twice that.
- how it's better to define "distinct colors/pixels" in analog world? For now I think about it in form of 'ability to change color from deep green to deep red (for example) back and forth during scanline. Am I correct?
Conventionally they seem to talk about "TVL"/"TV lines" of horizontal resolution in the analog world. I don't entirely understand where they come from, but they seem to roughly be a 70-75% derating relative to the theoretical digital equivalent resolution.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Why Doesn't the NES Show Artifact Colors?

Post by tepples »

It's 75 percent because SDTV is 4:3.

TV lines (TVL) are how many distinct pixel-equivalents across fit in the same physical distance as the screen's height. For example, NES video draws 280x240 pixels* (including border) into a 4:3 frame, giving it 3/4 * 280 = 210 TVL.


* Assuming the Rec. 601 definition of active picture area.
Post Reply