Why Doesn't the NES Show Artifact Colors?
Moderator: Moderators
Re: Why Doesn't the NES Show Artifact Colors?
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.
"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.
Re: Why Doesn't the NES Show Artifact Colors?
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.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.
-
- Posts: 592
- Joined: Thu Aug 28, 2008 1:17 am
- Contact:
Re: Why Doesn't the NES Show Artifact Colors?
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).
7.159mhz dot clock mode used, dot crawl filter turned off (no cycling per frame-to-frame difference).
__________________________
http://pcedev.wordpress.com
http://pcedev.wordpress.com
Re: Why Doesn't the NES Show Artifact Colors?
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.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.
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.
Re: Why Doesn't the NES Show Artifact Colors?
Where's the attachment?
Re: Why Doesn't the NES Show Artifact Colors?
Oops.lidnariq wrote:Where's the attachment?
- Attachments
-
- colorArtifact1.nes
- (64.02 KiB) Downloaded 335 times
Re: Why Doesn't the NES Show Artifact Colors?
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.
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.
Re: Why Doesn't the NES Show Artifact Colors?
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.
Irrelevant, as it turns out. That's not how color decoding works.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)?
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.Or is it automatic consequence of QAM encoding of color information in color burst and no special hardware ever needed?
Re: Why Doesn't the NES Show Artifact Colors?
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'.
Interesting! But how this number is obtained? Some physical properties of QAM or that? And again, how VBlank/HBlank affect to it?This. The QAM signal is demodulated with a defined bandwidth, and that's the color resolution available. It's roughly 1.5MHzOr is it automatic consequence of QAM encoding of color information in color burst and no special hardware ever needed?
Re: Why Doesn't the NES Show Artifact Colors?
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.)
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#p213874Some physical properties of QAM or that?
I did actually answer that in my previous reply.
Re: Why Doesn't the NES Show Artifact Colors?
Did I miss this formula first time I read answer?
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?
Re: Why Doesn't the NES Show Artifact Colors?
I probably edited it in while you were composing your preceding reply...
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.- is there simple interpretation of coefficient 2 (like two half-periods) or it's something from deep math behind process?
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.- 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?
Re: Why Doesn't the NES Show Artifact Colors?
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.
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.