Jump to content
IGNORED

Atari 800 NTSC artifacting


phaeron

Recommended Posts

It's is really neat to see this being worked on. I seem to recall in the past I made a post how it was impossible to tune Altirra to display the correct colors in Ultima-IV. It seems impossible to get the landscape and water color combo to make sense. One would be brown, the other green. Or blue land and purple water. Something like that. The last screenshot shows an Apple II and displaying the colors as the developer intended.

 

I'm familiar with how this is generated in the Apple II circuit, not so much the Atari 800. The Apple II is sometimes spoken of as having false color, it can only tickle the Luma component. It knows nothing of Chroma. The circuit was the result of cost-cutting and simplicity. Back when IC chips were still expensive and consumed a lot of board space. Apple II had few analog parts. I remember being totally amazed that Atari had custom chips (TIA and GTIA) that were so versatile just a year or two later

 

For those of you wanting to experiment seeing the effects of all this, play around with the Artifacting Phase adjust slider in the color palette tuning dialog. And don't forget to turn artifacting to high in the video drop-down.

 

In Flight Simulator II it looks like it can be adjusted to what it's supposed to be.

FS2.zip

 

Here we have none. And phase slider does nothing. The artificial horizon and instrument panel numbers appear to be higher resolution than the out-of-the-window view. As it should be.

post-4806-0-84461500-1519415269.png

 

And here we turn it on and adjust the phase to various points. Notice how the out-of-the-window view doesn't change much. My color picker tool says the RGB values vary by about 6 or 7 each. Theoretically they shouldn't change at all.

post-4806-0-98909300-1519415270.pngpost-4806-0-12982600-1519415272.pngpost-4806-0-26895400-1519415273.pngpost-4806-0-39773400-1519415274.png

 

Notice how adjusting L+C color has no effect on artifacting. The false colors are rock solid compared to the out-of-the-window view. As it should be.

post-4806-0-01913900-1519416236.pngpost-4806-0-23338900-1519416237.pngpost-4806-0-91438000-1519416237.png

 

But in Ultima IV I can't get the right combination.

post-4806-0-40184500-1519418817.pngpost-4806-0-43630500-1519418818.pngpost-4806-0-43575900-1519418819.pngpost-4806-0-43024100-1519418820.png

 

The Apple II outputs what I believe to be the correct colors, green landscape, and blue water. It's remarkable and interesting to see how similar the two systems are in terms of resolution in these funky non-standard modes.

post-4806-0-08362700-1519418953.png

 

 

TRIVIA: IIRC the 1084S monitor has a "color-killer" circuit that can be turned on/off by a front-panel switch. It either processes L+C together for color graphics with a bit of smearing and artifacting. Or it asks for separate L and C, giving you a sharper B/W display, like for 80-columns, provided you are feeding composite into the L connector only. And here it displays FS2 like in the first example screenshot.

Link to comment
Share on other sites

To make things 100% clear, here's a demonstration of how it occurs.

 

I ran the following program:

10 GRAPHICS 8+16:COLOR 1 (high rez)

20 POKE 712,148 (blue border)

30 POKE 710,4 (gray screen = no color)

40 FOR X=1 TO 319 STEP 2 (skip every other X)

50 PLOT X,0:DRAWTO X,191 (vertical lines)

60 NEXT X

70 GOTO 70 (halt with screen intact)

 

You can see the output in S-Video and in Composite. Instead of lines we now see a solid red screen.

 

Now look at the scope images of a single line from the middle of the screen. First is the Luminance channel. Once we get to the playfield area, we see the alternating lighter and darker pixels that make up the lines. I also took a zoomed in image to show the pattern more clearly.

 

Next is the Chrominance channel. We see that there is the off-screen colorburst, followed by the widely spaced color information for the blue borders. The playfield is gray, and thus has no color signal.

 

Now look at the 2 Composite (mixed) channel pictures. The Luminance and Chrominance have been combined and now there's a waveform across the entire width of the screen. Because the Atari generates pixels with the same clock as it generates color, the frequency is the same and it is now impossible to separate what came from Luminance and what came from Chrominance. This signal looks just like a colored playfield signal.

 

The C64 uses about a 12% faster pixel clock, so vertical line patterns won't trick the TV like this (also, the faster clock makes its playfield a little narrower).

post-3606-0-27326300-1519420820_thumb.jpg

post-3606-0-17463200-1519420827_thumb.jpg

post-3606-0-02288600-1519420832_thumb.jpg

post-3606-0-15868100-1519420836.jpg

post-3606-0-59996900-1519420841.jpg

post-3606-0-25606800-1519420846.jpg

post-3606-0-19080700-1519420850.jpg

post-3606-0-13998800-1519420856_thumb.jpg

  • Like 7
Link to comment
Share on other sites

I have a borrowed oscilloscope, but it's been 15 years since I used one, and I'm pretty sure it's been a few years since anyone used this one... so I'm going with photos first. The TV/CRT pictures are taken with my phone, so interpret the colors with a grain of salt, as the phone particularly has problems with very saturated images.

 

First, color maps. These are all done using the ColorMap utility on the Altirra additions disk.

 

post-16457-0-76039600-1519453478.jpg

Atari 800 on Commodore 1702. The color control is turned down a bit.

 

post-16457-0-36989700-1519453829.jpg

Atari 800 on Samsung TV. The phone's getting overwhelmed with the saturation -- the color spectrum is not that far from the 1702, though color 1 is more yellow as usual. Artifact colors are very different again.

 

post-16457-0-69339600-1519453924.jpg

Atari 800 on All-in-Wonder USB. This most clearly shows the dark bands between luma levels.

 

post-16457-0-73347100-1519454120.jpg

For comparison, Atari 130XE on Samsung TV.

 

post-16457-0-86036100-1519454400_thumb.jpg

Atari 800 running Ultima IV on the Samsung TV. Didn't get a single good shot, so two exposures. Hey, look at that -- green trees and blue water. If you look at the left shot, you'll notice something weird -- there's three artifact colors! The bright green and pink on the lettering is on double wide pixel stems. This effect shows up on the 800XL and 130XE but much less so. Annoyingly, there are two versions of Ultima IV, the other version using opposite artifacting colors. This one is marked as version 1.

 

post-16457-0-67184300-1519455007.jpg

Atari 800 running Ultima IV, captured on the All-in-Wonder. Interesting thing here: the color fringing on the text stems is also green and pink here, so the artifacting from double-wide pixels seems more consistent with the TV.

 

post-16457-0-79687000-1519454706.jpg

Atari 800XL running Ultima IV on the Samsung TV. Note the near lack of color fringing on the double-wide pixel stems on the text, vs. the 800.

 

post-16457-0-03130300-1519455290.jpg

Atari 800 running Flight Simulator II on the Samsung TV. The top portion of the screen is Antic E, while the bottom is Antic F with artifacted colors. You can't really see it in this picture, but the blue and green colors in the top half are a reasonably good match for the artifacted blue and slightly pukish green on the pitch indicator

 

post-16457-0-05116200-1519456648.jpg

Atari 800 running Flight Simulator II on the AIW. This one's interesting because the sky is also more purple, and that's not artifacted. Reproduction of deeply saturated or dark blues is tricky and it doesn't take much to swing between blue and purple, so this didn't surprise me... but there's one more interesting thing, which is that Flight Simulator II uses a gray background that reduces the strength of the artifacted colors. All of that got me thinking, so I went back to the 1702 and recalibrated it to match color 1 against the TV....

 

post-16457-0-52284900-1519463559.jpg

Atari 800 color map on 1702 monitor with tint adjusted for standard reference color. Two things here -- artifacting colors are now blue/green, and if you try brightening the picture in most photo editors, the blue turns purple... sounds familiar.

 

My current theory, based on this and the greater color fringing on the text, is that this isn't really an issue with the phase of the artifacted colors. Rather, I suspect that the 800 is putting out a weaker color signal that is causing the artifacting colors to be very oversaturated compared to the XL/XE models, which would cause hue shifts due to output limitations in the display and differences in the way the decoded color values are clamped. I can get the 800XL to show a somewhat similar effect on the TV if I crank color all the way to max and then tune the tint to match the 800's phase offset.

 

 

 

 

  • Like 8
Link to comment
Share on other sites

My current theory, based on this and the greater color fringing on the text, is that this isn't really an issue with the phase of the artifacted colors. Rather, I suspect that the 800 is putting out a weaker color signal that is causing the artifacting colors to be very oversaturated compared to the XL/XE models, which would cause hue shifts due to output limitations in the display and differences in the way the decoded color values are clamped. I can get the 800XL to show a somewhat similar effect on the TV if I crank color all the way to max and then tune the tint to match the 800's phase offset.

 

It's very true that the amplitude of the burst will determine how much artifacting you see on high-rez text. Early sets only calibrated color phase off the burst, but modern sets (starting in the late '70s probably) calibrate color strength as well. A weak burst means the TV will assume all color is weak and it will bump up the "COLOR" control leading to stronger artifacts. This is one of the tough things to set when designing something like the UAV. If the color is strong, then the composite picture gets clearer but faint jailbars can start to appear on some TVs that don't filter Chroma out of the picture very well.

  • Like 2
Link to comment
Share on other sites

Interesting about the calibration of colour strength in the burst. So the burst strength can be weakened to boost colour.

 

Do you know how sets calibrate brightness?

Changing the burst level only works if you change it independently of the rest of the color. Atari used this trick in the 6-switch 2600 and then in the 1200XL. TIA/GTIA only puts out one level of color, but on those models the burst was made to be a lower level than at all other times so the colors would be more saturated. I don't know if any TVs adjust brightness, but some of them might set the black level after sync. That's something I need to investigate further.

Link to comment
Share on other sites

I forgot to mention in my post with the screenshots. The correct Artificial Horizon colors are Blue for the top half representing the sky, and Tan-Brown-Orange for the bottom half representing the ground. It's standard throughout the aviation industry.

https://www.google.com/search?biw=1024&bih=623&tbm=isch&sa=1&ei=3u6RWryqB4m15gKFzJyoCw&q=artificial+horizon+indicator&oq=artificial+horizon+indicator&gs_l=psy-ab.3..0j0i24k1.5360.11749.0.12046.21.20.1.0.0.0.204.2362.2j17j1.20.0....0...1c.1.64.psy-ab..0.20.2249...0i13k1j0i7i30k1j0i8i13i30k1.0.D2suVc8yvYY

  • Like 1
Link to comment
Share on other sites

Sorry, no fancy digital scope like Bryan, going to have to do this old school.

 

post-16457-0-27934000-1519520385_thumb.jpg

Atari 800 signal, GR.0 screen -- horizontal sync, color burst, horizontal blank / border, playfield

 

post-16457-0-67450100-1519520420_thumb.jpg

Atari 800XL signal, GR.0 screen

 

post-16457-0-93534200-1519520407_thumb.jpg

Atari 130XE signal, GR.0 screen

 

Looks like I was right about the 800's chroma signal being weaker... although I didn't expect such a difference between the 800XL and 130XE either.

Edited by phaeron
  • Like 7
Link to comment
Share on other sites

Sorry, no fancy digital scope like Bryan, going to have to do this old school.

That's okay, I've had several people send me scope caps of video issues they're having and it's almost always from a better scope than mine.

 

Looks like I was right about the 800's chroma signal being weaker... although I didn't expect such a difference between the 800XL and 130XE either.

Yeah, when I started trying to define what a "standard Atari signal" should be, I kinda gave up and just aimed for what would be closest to the industry standards.

  • Like 1
Link to comment
Share on other sites

We can rule out duty cycle:

 

post-16457-0-70767300-1519525168.jpg

800 - eye diagram

 

post-16457-0-28791500-1519525191.jpg

800XL - eye diagram

 

post-16457-0-18659900-1519525209.jpg

130XE - eye diagram

 

With alternating on/off patterns between lum 0/14, all of the computers are close to 50/50. The 800XL probably has the "cleanest" pixels; the 800's edge transitions are so slow the output is almost a triangle wave, while there is noticeable overshoot on the 130XE output.

 

  • Like 3
Link to comment
Share on other sites

Did a test to check for timing skew between luminance bits... turns out there isn't any difference in when they switch, it's rise/fall time that's the difference:

 

post-16457-0-77321400-1519528222.jpg

Atari 800 - luminance bit timing

 

post-16457-0-81755400-1519528266.jpg

Atari 800XL - luminance bit timing

 

post-16457-0-67555400-1519528276.jpg

Atari 130XE - luminance bit timing (yuck)

 

This appears to be what is causing the gaps in the color chart, though I can't put my finger on exactly why it occurs:

 

post-16457-0-16053500-1519528868.jpg

Atari 800 - grayscale ramp. Notice the very pronounced gap between luma 7 and 8.

 

post-16457-0-59699500-1519528752.jpg

Atari 800XL - grayscale ramp

 

post-16457-0-68767600-1519528767.jpg

Atari 130XE - grayscale ramp (yuck!)

 

This will also result in slight phase shifts in the artifacted color depending on luminance, though nowhere near green/blue.

 

  • Like 3
Link to comment
Share on other sites

Yeah, the LUM bits don't seem to reach the output with identical timing (meaning they probably are clocked prior to some additional output logic). That's the main reason for UAV's delayed latching (UAV detects that the LUM has changed, then latches the new value after a small delay).

 

post-3606-0-39828200-1452206438_thumb.jp

 

post-3606-0-77769000-1452228189.jpg

  • Like 6
Link to comment
Share on other sites

It's neat to see these. The 800 and 800XL waveforms appear to be soooo close. But I guess close isn't enough.

 

This puts me in mind of my other interest (analog synthesizers). Techs in that business lament about the same thing -- slight variances in circuitry that shouldn't make a difference but actually are noticeable.

  • Like 1
Link to comment
Share on other sites

They're not actually that close. The pulses I showed are from GR.9 pixels, so those pulses are four hires pixels wide. That means the 800's video circuit takes a full hires pixel to fully switch between on and off. The 800XL and 130XE are considerably faster, though the XE has a lot of ringing.

 

The thing about the luma lines is that there doesn't seem to be different delays between them. Rather, the on and off times differ:

 

post-16457-0-26688300-1519705595.jpg

 

This is a superposition of three patterns: luma 7/0/7/0, 0/8/0/8, and 7/8/7/8. This is in GR.9, so pulses are 4 hires pixels wide. The 7/8/7/8 pattern is pretty much exactly what you'd expect from summing the luma 7 and luma 8 patterns, so no funky stuff there. The problem is that in both the 7->8 and 8->7 transitions the luma signals that are currently on are turning off before the ones that are off can turn on. This results in a dip in the output during the crossover. Otherwise, the on/off curves look reasonably matched -- if they had coincided better they probably would have mostly canceled and the exponential decay curve would only have been in the difference between luma 7 and 8. If it were skew between the luma lines, one of these transitions would be overlapped and would have a hump instead of a dip, or we would see a messier transition for LUM0-2 (which is not the case).

 

Now, here are the signals for what originally started all this:

 

post-16457-0-66313900-1519707236.jpg

Atari 800 - color $14 against %1010 pattern at luma 14

 

post-16457-0-43488200-1519707241.jpg

Atari 800 - color $14 against %0101 pattern at luma 14

 

These are full amplitude artifacting patterns laid over hue 1, which doubles as the colorburst. The sweep is positioned to align each color cycle to two divisions on the grid. As we can see here, the artifacting signals are about double the amplitude of the chroma signal, so they will produce extremely saturated colors. More importantly, the %0101 pattern is just about in phase with the colorburst (-U or -57deg from +I), while the %1010 pattern is just about 180deg from it (+U). Consulting a standard YUV chart, this would indeed produce colors in the yellow-green and blue-purple regions, with phase deviations contributing to more green or blue. This means that there is nothing unusual about the phase here, and I'll bet we could get these colors out of the UAV with the saturation amped up.

 

The downside is on the emulation side. One thing I realized while analyzing this is the reason why the TV can reproduce these colors: it's much brighter than your average monitor, so the white produced by the 800 only reaches midlevel on the TV display. This gives it plenty of headroom to display the deeply saturated colors. On a computer monitor, the emulator is hitting the limits of the sRGB color space, and this is particularly causing the shift from blue to faded purple. If you crank the contrast way down in Altirra and crank the artifact saturation way up, it is possible to achieve blue-green artifacting. Which means this is turned into a problem I've beat my head against before, which is gamut mapping. Ugh.

 

Final note, the gamut for Adobe RGB is apparently larger than sRGB and a better fit for NTSC. The larger discrepancy is on the green side instead of the blue side, but this may explain why my Dell monitor was able to reproduce these colors as well. I'll have to do experiments with it set to Adobe RGB to see whether that helps with the color reproduction in emulation.

Edited by phaeron
  • Like 5
Link to comment
Share on other sites

  • 2 months later...

They're not actually that close. The pulses I showed are from GR.9 pixels, so those pulses are four hires pixels wide. That means the 800's video circuit takes a full hires pixel to fully switch between on and off. The 800XL and 130XE are considerably faster, though the XE has a lot of ringing.

 

The thing about the luma lines is that there doesn't seem to be different delays between them. Rather, the on and off times differ:

 

attachicon.gifa8-luma78.jpg

 

This is a superposition of three patterns: luma 7/0/7/0, 0/8/0/8, and 7/8/7/8. This is in GR.9, so pulses are 4 hires pixels wide. The 7/8/7/8 pattern is pretty much exactly what you'd expect from summing the luma 7 and luma 8 patterns, so no funky stuff there. The problem is that in both the 7->8 and 8->7 transitions the luma signals that are currently on are turning off before the ones that are off can turn on. This results in a dip in the output during the crossover. Otherwise, the on/off curves look reasonably matched -- if they had coincided better they probably would have mostly canceled and the exponential decay curve would only have been in the difference between luma 7 and 8. If it were skew between the luma lines, one of these transitions would be overlapped and would have a hump instead of a dip, or we would see a messier transition for LUM0-2 (which is not the case).

 

Now, here are the signals for what originally started all this:

 

attachicon.gifa8-artifacting-1010.jpg

Atari 800 - color $14 against %1010 pattern at luma 14

 

attachicon.gifa8-artifacting-0101.jpg

Atari 800 - color $14 against %0101 pattern at luma 14

 

These are full amplitude artifacting patterns laid over hue 1, which doubles as the colorburst. The sweep is positioned to align each color cycle to two divisions on the grid. As we can see here, the artifacting signals are about double the amplitude of the chroma signal, so they will produce extremely saturated colors. More importantly, the %0101 pattern is just about in phase with the colorburst (-U or -57deg from +I), while the %1010 pattern is just about 180deg from it (+U). Consulting a standard YUV chart, this would indeed produce colors in the yellow-green and blue-purple regions, with phase deviations contributing to more green or blue. This means that there is nothing unusual about the phase here, and I'll bet we could get these colors out of the UAV with the saturation amped up.

 

The downside is on the emulation side. One thing I realized while analyzing this is the reason why the TV can reproduce these colors: it's much brighter than your average monitor, so the white produced by the 800 only reaches midlevel on the TV display. This gives it plenty of headroom to display the deeply saturated colors. On a computer monitor, the emulator is hitting the limits of the sRGB color space, and this is particularly causing the shift from blue to faded purple. If you crank the contrast way down in Altirra and crank the artifact saturation way up, it is possible to achieve blue-green artifacting. Which means this is turned into a problem I've beat my head against before, which is gamut mapping. Ugh.

 

Final note, the gamut for Adobe RGB is apparently larger than sRGB and a better fit for NTSC. The larger discrepancy is on the green side instead of the blue side, but this may explain why my Dell monitor was able to reproduce these colors as well. I'll have to do experiments with it set to Adobe RGB to see whether that helps with the color reproduction in emulation.

 

Don't know exactly what is the latest development on this subject, but you are definitely into something...

 

No need to have the TV as output media for this experiment, as the following (purpose-coded) mini-test shows FOUR (4) artifact-colors on a Viewsonic VP950b "pro" monitor, coupled with the DVDO iScan video-processor (source is my Atari 800 with revised resistors for bringing Luma-signal closer to reasonable levels, otherwise the top brightness tonal-band gets blown-out from factory config.):

 

post-29379-0-70616600-1525401214_thumb.jpg

 

 

And here are FS2 and Ultima Samples (FS2 shows pretty much as I remember it):

 

post-29379-0-02949900-1525403354_thumb.jpg post-29379-0-81808200-1525403436_thumb.jpg

 

I DO NOT recall ever seeing FOUR artifact colors from my former (and first) Atari 400 nor my 800XL, in any of the CRTs i remember using (!)

 

On the other hand, i DO remember repairing a 800XL struck by a brick-like power supply (gone rogue) and frying some passives on its video path. Upon by-passing a specific capacitor, straight to the video port, I noticed that the 800XL immediately began producing the same type and LEVEL of artifacts (on-screen) than the former 800... even in Gr.0 40-col chars. against a black background (!!!)... which suggested that some crap has been added in later board-revisions to mitigate some of these by-products...

 

Boy, this one may be a really hard one to crack on emulation... and most interestingly, when playing 60fps video with your wonderful VIDEO PLAYER: once you switch to the COMPOSITE input on the DVDO iScan, the colors become even more SATURATED and VIBRANT compared to Y/C input (s-Video)... and it is not about iScan post-processing parameters of Composite vs. s-Video inputs (which are kept entirely separate)... FYI, tried in on Altirra and it does not get this right, yet.

 

No idea how that could be possibly replicated on emulation....

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...