NTSC artifacting -- use it or not?

[Flipper]

I've been doing some experiments over the past couple of days to try and get my head around the NTSC artifacting on the 7800. I understand the cause, but not how to use it.

 

 

That said...it only works when I'm using composite/RF out, not S-Video. Again, that makes sense as S-Video was created to eliminate NTSC artifacting. However, as more and more people mod their consoles for S-Video out, should we stop using the artifacting, and instead assume it will not occur?

 

It does seem like an either-or choice. If you ignore the artifacts and write colors as you please in 320 modes, users on unmodded consoles will find the screen smudged beyond all recognition. If you use artifacting, and a user plays it on an S-Video console, the screen will look messed as well.

 

My particular experiment was with 320D mode, hoping to make something like an Apple II graphics mode. If I recall from those years, on the Apple you only had Green or Purple pixels (or Red and Blue), but if you put a green pixel next to a purple pixel, you ended up with a white pixel because the color decoder in the monitor would screw up. That doesn't seem to work on the 7800, or at least not with my fancy HD TV (yeah, it's got RF in). I get some color that looks mostly like the SECOND color I draw. As in, if I draw green, purple, green, purple, green, purple, I get a solid purple bar.

[supercat]

My particular experiment was with 320D mode, hoping to make something like an Apple II graphics mode. If I recall from those years, on the Apple you only had Green or Purple pixels (or Red and Blue), but if you put a green pixel next to a purple pixel, you ended up with a white pixel because the color decoder in the monitor would screw up. That doesn't seem to work on the 7800, or at least not with my fancy HD TV (yeah, it's got RF in). I get some color that looks mostly like the SECOND color I draw. As in, if I draw green, purple, green, purple, green, purple, I get a solid purple bar.

 

I don't remember exactly where the color phase is on the 7800, but for simplicity suppose that when you draw with white on black the even pixels show up as red and the odd ones show up as green.

 

Mentally divide each double-pixel into 15 pieces. These pieces will be colored according to the Atari color sequence (starting with yellow, then orange, then red, then magenta, then blue, then cyan, then green, then back to yellow). When you specify a color, you're asking the Atari to turn on half of those 15 pixels (more or less, the selected one, and the 3 before, and the 3 after).

 

With S-video, the lower 4 bits of the color number go into the luma wire, while the upper 4 bits select a color to go out the chroma wire. Crosstalk between luminance and chrominance is largely averted. Nonetheless, there is still potential for using (or having to suffer with) chroma artifacting.

 

To figure out what's likely to appear, figure out what's going to be displayed based upon the subdivision of each 160-mode pixel into 15 pieces. Then add up the colors.

 

Too bad I don't know how to whip up java applets; it'd be easier to show than describe.

[EricBall]

Hmm, you bring up a good point - S-video won't have the same color artifacts as composite/RF. Tower Toppler should be a good example of what will happen. (Note: MESS doesn't attempt to emulate color artifacts, although I did give some thought to how it could be done.)

 

TV color (PAL or NTSC, composite or S-video) is encoded as the phase and amplitude of a colorburst frequency (3.579545MHz for NTSC). On the 7800 (and 2600) the amplitude is fixed (except for B/W when it's supressed) and only the phase changes.

 

The 320 color artifacts have two causes. The primary cause is alternating light and pixels which can create a strong 3.579545MHz signal either in phase with the colorburst (gold) or out of phase (blue). The second cause is each 320 pixel is only half the length of the colorburst waveform, therefore some TVs may have difficulty decoding the abrupt phase shifts.