jail bars - atari 800 - chroma luma working through possible fixes

[Rocinante800]

This is a journey to have an A800 produce a modern/clean (s)video signal.

 

already R168 replaced with 220 ohm

baseline video. connected with an ebay atari din to s-vid/Rred/Lwhite/Cyellow cable (C not plugged in)

this is my first scope and I've had it about a week (so I'm not proficient)

measured at MB/power supply pin connector

 

decided to look after watching this video:  

chroma running about 300mv blue trace

luma running about 700mv yellow trace

 

I would really like to measure the ground in the "ideal" way, but I need to learn how.

my ground test at A103 pin 8 says 40-50mv noise? but it looks as good as his improved signal

grounding A103 pin 8 to the power supply board made no difference.

I have read about s-video cable quality and monitor/tv issues, so I am going to test that as well.

 

I have a suspicion that the best fix may be to use newer tech to fix the signals.

like to get a fms6400 and add it externally (maybe change composite out to +5v) and put a box near the monitor

this would be mimicking the low_budget 5200? mod.

 

 

[+mytek]

3 hours ago, Rocinante800 said:

I have a suspicion that the best fix may be to use newer tech to fix the signals.

like to get a fms6400 and add it externally (maybe change composite out to +5v) and put a box near the monitor

this would be mimicking the low_budget 5200? mod.

This might give you a head start on that idea: https://ataribits.weebly.com/ugv.html

 

[Rocinante800]

I used the color bars generator

colorx.xex

the grey bars screen doesn't appear to have jail bars

but it does have weird artifacts, you can see the dips in the steps on the scope

the large dip in the middle produces a green bar dividing the picture.

colorbars have lots of consistant jailbars

 

I magnified the chroma signal:

 

on this next pic look at the area from the triggerpoint (top orange arrow) and look to the left 3 screen divisions (graph paper marks)

I see 10 peaks on the scope and on the color bars I see 20 pixels? per bar. 

leads me to believe it draws every other line per pass interlacing to form a picture.

(I did read that A800 was not interlaced, maybe differs by graphics mode.)

on my screen every other pixel? is the "wrong" color creating jail bars.

the yellow wave (luma) has a step in it that I am suspect about.

 

[Rocinante800]

I want to assume that Atari tried to improve their product.

I compare the 800 video circuit:

to the 1200

 

they changed so much I am researching where to start.

time for inductor lessons.

 

[Rocinante800]

when I look at the colorbars picture, I see 15 color stripes the 16th (I assume) is first and all black w/o jail bars. 

so I searched and read up on the data from the guy who made Altirra

https://www.virtualdub.org/blog2/entry_243.html

320 pixel mode, or 40-column mode as it is called in the docs, is where the weirdness starts. Most of the logic in the GTIA works in 160 resolution (3.58MHz) and is too slow for 320 resolution, so the 40-column mode actually involves a bit of a bypass. 40 column mode is activated by ANTIC during horizontal blank and during the active region it overrides the playfield outputs to force PF2. The two bits AN1-AN0 that are normally decoded into the playfield are instead serialized into a 40 column bitstream that bypasses most of the priority logic and goes to the encoding section. There, the bitstream selectively replaces the luminance output with the value from PF1, regardless of playfield or player/missile. This bypass is why 40 column mode acts strangely in some ways compared to other modes. I was surprised to find special logic for collision detection, though. I knew from getting Race in Space working that collisions do work in 320 mode and that they return PF2, but I didn't know why. Well, there's logic in GTIA just for 320 mode that ORs together the two bits and outputs a special PF2C line to the collision detector, which is separate from the PF2 line to priority that is forced on. Whaddaya know.

so I found 10 per division, which is 20 sections per colorbar...  320 pixels

The hue goes to an oscillator that produces the color signal, and the luminance goes out through a resistor bank to converted to a luminance level.

and this to consider:

One of the side effects of enabling a GTIA mode is that it forces the 40 column mode flip flop off so that the circuitry on the output side doesn't whack the luminance of the output. 

looking into this function

[Rocinante800]

connected to the monitor

disconnected from the monitor

yellow is luma. 

glitchy sinewave goes away - wave gets more? noisy.

more to think about.

 

 

[Rocinante800]

 

I already changed R189 to 220 ohm (from 75) pink and circled in yellow

amazon delivering 4050s tomorrow

 

I also managed to get this scope trace:

which causes me to think the circuit is a very noisy oscillator.

 

next I jammed a cap in the luma signal (yellow) where my probe is. the other end of the cap is my pink signal.

voltage levels are too low, but the sinewave looks much improved.

I need to pull out R189 and change that to a resistor-capacitor series pair.

trial 1: I want to see how this looks on screen when I get it back to the 700mv luma range.

 

curious scope screen

yellow luma, blue croma, pink comp

not sure if it glitches 60 deg out of phase as it draws the off-playfield blank area?

 

 

trial 2:  rebuild the LUMA with new parts

jumper from A103 inputs (yellow) to a breadboard LUM circuit so I can baseline the scope measurement and then try various power supply, 800XL and decoupling strategies.

reinject the breadboard signal to R189 to see the picture 

 

alternate step: remove resistors R205 R200 (maybe R201) R206 from circuit to disable MOD and COMP VIDEO from leaching off the signal (scoping after each) and causing anything unexpected. (pink in pic)

some of what I post may be dead ends, just trying to keep my thoughts in one place.

 

Edited September 7, 2022 by Rocinante800
messed up the trial steps

[Rocinante800]

from the altirra docs:

https://www.virtualdub.org/downloads/Altirra Hardware Reference Manual.pdf

Importantly, the horizontal and vertical scan rates deviate from ideal NTSC and PAL broadcast timing. For NTSC,
the machine clock runs at exactly half the color subcarrier rate (3.58MHz), but the scan line is 114 machine
cycles instead of 113.75 cycles and the frame has 262 scan lines instead of 262.5. This prevents the color
subcarrier from inverting phase on each scan line and produces a non-interlaced display with 15.700KHz /
59.92Hz timing instead of an interlaced one with 15.735KHz / 59.94Hz timing. Similarly, the PAL ANTIC
produces 312 scan lines instead of 312.5 and also produces a non-interlaced display.

 

I think this mean s 2 "pixels" per signal ripple? maybe?

I may have confirmation bias n the weird stepping luma ripple I found in my third post last picture.

[phaeron]

24 minutes ago, Rocinante800 said:

from the altirra docs:

https://www.virtualdub.org/downloads/Altirra Hardware Reference Manual.pdf

Importantly, the horizontal and vertical scan rates deviate from ideal NTSC and PAL broadcast timing. For NTSC,
the machine clock runs at exactly half the color subcarrier rate (3.58MHz), but the scan line is 114 machine
cycles instead of 113.75 cycles and the frame has 262 scan lines instead of 262.5. This prevents the color
subcarrier from inverting phase on each scan line and produces a non-interlaced display with 15.700KHz /
59.92Hz timing instead of an interlaced one with 15.735KHz / 59.94Hz timing. Similarly, the PAL ANTIC
produces 312 scan lines instead of 312.5 and also produces a non-interlaced display.

 

I think this mean s 2 "pixels" per signal ripple? maybe?

I may have confirmation bias n the weird stepping luma ripple I found in my third post last picture.

1 lores pixel = 2 hires pixels = 1 color subcarrier cycle = 280ns.

[Rocinante800]

I built a daughterboard with the updated circuit I found online similar to the one used for the 2600 upgrade. 

I added ways to add caps to the 4050 +v. added ways to draw + and - from remote areas on the board in case the power supply was noisy.

I somehow managed to get a noisier signal and more profound jailbars. 

may need to just order a prefab board for top mount components with the bottom as a ground plain to kill noise.

 

also looking at FMS6400 chip for post buffer? video processing.

[Rocinante800]

next discovery:

the wave I don't like with the little glitch in it - is a backfeed from the chroma circuit? monitor?

also (I'm sure it's not advisable) I powered it on with the board I assembled remote jumpered and it tried to work with no ground and no +5

pic rolled had bad depth of color and it had jailbars, but it worked-ish

I am starting to think that the video out circuit is just too primitive for the clean signal that is expected by equipment today. (maybe FMS6400 will fix it)

 

pic of the composite output:

 

[Rocinante800]

luma - chroma crosstalk reduction: 

all current modifications:

removed R202, 205, 206

(R189 was changed to a 220 ohm previously)

 

after paying about $30 on ebay for a cable 

like this one from that seller: Atari 800 / 65XE / 130XE Color S-Video, Composite Video & 2 Channel Audio Cable | eBay

seller: gdoinventer on eBay

I contacted the seller to see what he will do for me.

 

built my own s-video cable from a comp & sound only out 800 cable I got somewhere and a quality s-video cable I had laying around. Individual shields

it does very faint narrow jailbars (chroma-luma crosstalk) and some of the wider variety (ground power blamed?) 

 

signal with crappy cable:

 

signal with new cable:

 

there is still a crosstalk issue, but it is greatly reduced.

SALT colorbars screen compare

 

to get better will require better isolation of signals and cleaner power.

I have a pretty good phone camera but it seems to have "cleaned up" the jailbars a bit.