New video upgrade coming soon!

[_The Doctor__]

I just want to see if it produces a readable 80 col. display.....

I fear the horrible dot pitch on the jvc monitor your using may not let us see how good this upgrade is.... the moire patterns tend to be the result of dot pitch and not bit crawl..

most of the better nec monitors do not have that problem... one more reason I hated commodores monitors... the dot pitch always mucked things up

some of the lesser quality lcd tv's are a mess as well...

keep the shielding on folks... it does matter... it keeps radio stations from mucking up data cassette audio... it keeps rf from radio stations affecting the Atari... It keeps ham radio cb and gprs from messing with the Atari and the Atari from messing with them...... I know alot of people don't care about others radio reception etc... but time and time again at least where I live... putting the shielding back on has solved alot of 'random' problems and noise issues.... it wasn't just put on for no reason or to make the fcc happy.... it helped you and your neighbors whether you realized it or not.....and rather than re hashing it all just look thru the years on atariage and see different discussions for and against the shielding...

keeping at least the bottom half on and making the keyboard metal connected to shield ground is as close to a decent compromise as I have seen.. although some have foil backed the inside of the case after having tossed the original shield to solve their problems... you never know when some new tower radio device wifi tv system will go live in your area with some new standard and you no longer have the shields to deal with it. Been at this forever.. shields up! best strategy ever.

[Bryan]

The old-school look of the TM-A13SU is one of the things I like about it. But you're right, it's not a very good way to showcase the upgrade. LCD's aren't either since they have their own weird artifacts.

[_The Doctor__]

In the late 80's early 90's many televisions had s video, composite and great dot pitch sharp had a few monitor class televisions as did goldstar, nec, proscan, radioshack..JVC but NEC had something in their composite only monitors for a few years that loved the 130XE, wonderful display without hacking things up much at all.... Perfectly readable 80 col and proper color artifacting ..... no banding ....Mack Truck supplied the monitor I used.... I ran the monitor till it died in 2001. Quite a few stores had the NEC monitor for displaying the Atari in the Lehigh Valley and with good reason..

 

Someone Near Costa Rica should gift bryan with a nice mid to late 80's NEC composite color monitor....I think he deserves one and would appreciate it!

[Bryan]

Someone Near Costa Rica should gift bryan with a nice mid to late 80's NEC composite color monitor....I think he deserves one and would appreciate it!

 

I actually got rid of all my better video monitors when I moved here.

[Elwood]

I'm also interested in buying one, please let me know when it's available.

[Bryan]

I've ordered 200 boards and they should be here next week. Lots of parts coming too. Hopefully I'll have an update soon!

[ZuluGula]

Could you give us an estimate price and shipping cost?

[Bryan]

No more than $25 for the full board, I'd imagine. Still working out the details. Shipping should be low because it's so small.

[olix]

I'm also interested in buying two or three (it depends on the price), please let me know when it's available.

 

olix

[lemiel]

I want one.

[kazmat]

Very nice !

 

I need 2 or 3 units for my atari

[+tf_hh]

Hi,

 

Hope this helps. However, remember this is still a prototype.

 

Some questions... I don´t (!) want to blame this, but where´s the difference between the lot of video mods already running in the wild?

 

Which video amplifier or generator you are using? I rebuild some times the solution by low_budget (see schematics in attachment) and it´s the best solution I´ve seen until now - on also every atari (computer or console) using a CTIA or GTIA.

 

Next, all screenshots shown are from tube monitors. Using a tube, in most cases the picture is already very good using S-Video (XE, XEGS, XL "rose") or a simple "Supervideo" mod must be done to get a good picture. Totally different any result appears when using LCD/TFT monitors or television. And that´s what today is mostly used. So it would be very important to see some screenshots from 2 or 3 different TFT/LCD monitors.

 

The low_budget solution for example has a very sharp, clear und impressive picture on Sony or Philips TFT televisions, but runs bad on a lot of china lowprice devices. Otherwise a lot of these cheap china devices (no name TVs or so) like "Funai" produces a very good picture on a lot of unmodified Atari or need just a simple Supervideo mod. Unfortunenately all of these mods become more and more useless, because more and more TFT/LCD monitors only accept Composite-Video, but not S-Video

 

Would be nice to see more...

 

Regards, Jurgen

 

[Sowden]

I would be interested in this, but I want to see how it is put together and installed before I take the plunge and purchase it.

[Bryan]

Some questions... I don´t (!) want to blame this, but where´s the difference between the lot of video mods already running in the wild?

 

Hi! The main differences:

 

1. My #1 goal is eliminaton of banding on the screen. All upgrades I know of use the output of the CD4050-based DAC. This is a major source of noise since there is no isolation between the V+ rail and the output pins (no PSRR in logic chips!!). This is why even after installing an upgrade you can usually still see bus activity (DRAM is noisy stuff!). The UAV board has a high-performance voltage regulator for clean power.

 

2. My #2 goal is sharpest possible 320 mode picture. This involves the amplifier performance and the elimination of skew between LUM signals. The LUM lines don't always change exactly together (and this is somewhat GTIA dependent). UAV aligns all 4 LUM bits perfectly for better pixel edges.

 

3. Adjustment of artifact colors for NTSC users. Because the LUM alignment delay is adjustable, you can change the timing between Chroma and Luma which renders different artifact colors.

 

4. Clean sine-wave output for Chroma at both 3.58 and 4.43MHz. Atari machines often produce a distorted Chroma waveform and this distortion can affect picture quality.

 

5. Small size and easiest possible installation. I tried to make it stay out of the way of other upgrades.

 

6. Can be installed without disabling the factory video output.

 

7. Ability to use Composite and S-Video simultaneously. Most upgrades with a dedicated video buffer chip will support this as well. The Atari circuit is overloaded when both are used.

 

Which video amplifier or generator you are using? I rebuild some times the solution by low_budget (see schematics in attachment) and it´s the best solution I´ve seen until now - on also every atari (computer or console) using a CTIA or GTIA.

 

The video amp is a NCS2553. It has a very good PSRR and a nice roll off characteristic for this application.

 

Next, all screenshots shown are from tube monitors. Using a tube, in most cases the picture is already very good using S-Video (XE, XEGS, XL "rose") or a simple "Supervideo" mod must be done to get a good picture. Totally different any result appears when using LCD/TFT monitors or television. And that´s what today is mostly used. So it would be very important to see some screenshots from 2 or 3 different TFT/LCD monitors.

 

I have two LCD TVs here and I'll be enlisting a couple beta testers to show their results as well. LCDs are certainly more picky and never look as good as CRTs imo. The goal was to get everything looking as textbook-perfect as possible on a scope, then see how it looked on real-world monitors.

 

The low_budget solution for example has a very sharp, clear und impressive picture on Sony or Philips TFT televisions, but runs bad on a lot of china lowprice devices. Otherwise a lot of these cheap china devices (no name TVs or so) like "Funai" produces a very good picture on a lot of unmodified Atari or need just a simple Supervideo mod. Unfortunenately all of these mods become more and more useless, because more and more TFT/LCD monitors only accept Composite-Video, but not S-Video

 

Well, a big part of that is getting the sync and blank levels right. Atari video is already a bit different than real video and a sloppy upgrade can make it so that new TVs won't detect the signal properly at all.

 

Would be nice to see more...

 

Regards, Jurgen

 

Hopefully in the coming weeks!

 

-Bry

[Level42]

Did someone say LCD's are used mostly today ?

 

Not here. Never will.

 

I like this mod. It's simple yet effective. I've done regular video mod's on XL's with fine results on my CRT using S-video. There could be only one serious step up and that would be true RGB but that would require a lot more hacking....

[Bryan]

There could be only one serious step up and that would be true RGB but that would require a lot more hacking....

I tried once to derive true RGB from the Atari's signals. I say 'true' because I wanted perfect clarity, not using the normal decoding method.

 

The A8 has 15 different delays it can apply to the color clock (3.58MHz for NTSC). The delay can be changed once per cycle (once per 160 mode pixel). So, in theory, you could capture any rises or falls during the middle part of a pixel interval and calculate which color the computer was sending. My circuit sort-of worked. Some pixels were stable and some flickered. You need a very fast clock to do this (over 50MHz). It would be even more difficult on PAL because the color runs on a different clock than the rest of video. I'd probably cheat and use an NTSC GTIA.

 

Today, I think I could get decent precision out of it but having a GTIA core for an FPGA is the cleaner way to go.

[+bob1200xl]

I'd like to try that color decode some day. I have a good 28MHz clock, so 56MHz should be no problem. On a scope the CHROMA transitions look pretty stable at 18.6ns. If this is all done inside a fast CPLD, it should work pretty well.

 

Were you using discrete logic?

 

Bob

[Bryan]

I'd like to try that color decode some day. I have a good 28MHz clock, so 56MHz should be no problem. On a scope the CHROMA transitions look pretty stable at 18.6ns. If this is all done inside a fast CPLD, it should work pretty well.

 

Were you using discrete logic?

 

Bob

Yes. The main problem is that there aren't 16 delays, there's 15. So, the best clock to track them with is 53.69MHz. Also, I'd drop the first and last couple clocks of the color cycle (where the transition noise is) and instead look for a H-L or L-H that happens in the middle region.

 

Once you've got that and the LUM pins, use LUTs/EPROMs to drive the RGB ladders.

[+bob1200xl]

There are 15 delays plus no delay, right? Actually, a delay of 15 and a delay of 1 are the same color, shifted into the next LUMA cycle. (how weird is that?)

 

Keep in mind that you can set the clock delay to anything you want with the coloradj pot. The timings don't have to match a stock Atari, they just have to be decodable. Your output wants to be the CHROMA component value for each LUMA cycle. Obviously, color 15 will have to be pulled back into its own LUMA cycle.

 

Bob

[Bryan]

Yep, you can space them however you want if you just want to sample them. According to the CGIA datasheet, color 15 is supposed to be a delay of 261ns (not quite the next cycle, which happens at 279ns). I think it's just a matter of the colors decoding to something very close.

 

The list of color names and their positions on the wheel seems a little skewed, though (especially in the greens). Maybe it's due to the low saturation?

 

EDIT: I now think the CGIA sheet (and thus this image) are wrong (not in keeping with Atari's established conventions).

[Bryan]

Quick comparison of Atari's claimed color specs and the NTSC standard:

C#   NAME     DELAY REAL-PHASE
C1   GOLD     0°    180° gold, burst phase
C2   ORANGE   24°   156° pure yellow is considered to be 167°
C3   RED-OR   48°   132°
C4   PINK     72°   108° pure red is considered to be 103°
C5   PURPLE   96°   84°
C6   PUR-BLU  120°  60°  magenta is considered to be 61°
C7   BLUE1    144°  36°
C8   BLUE2    168°  12° 
C9   LT-BLU   192°  348° pure blue is considered to be 347°
C10   TURQ    216°  324°
C11   GRN-BLU 240°  300°
C12   GREEN   264°  276° cyan is considered to be 283°
C13   YEL-GRN 288°  252° pure green is considered to be 241°
C14   OR-GRN  312°  228° 
C15   LT-OR   336°  204° 

It seems to me like Atari defined the color names a little ahead of where they should be. This would be consistent with making the first and last colors the same.

 

EDIT: Here's a probably more accurate chart with color 1 & 15 at the same point:

C#   NAME     DELAY REAL-PHASE
C1   GOLD     0°    180° gold, burst phase
C2   ORANGE   26°   154° pure yellow is considered to be 167°
C3   RED-OR   51°   129°
C4   PINK     77°   103° pure red is considered to be 103°
C5   PURPLE   103°  77°
C6   PUR-BLU  129°  51°  magenta is considered to be 61°
C7   BLUE1    154°  26°
C8   BLUE2    180°  0°   pure blue is considered to be 347°
C9   LT-BLU   206°  334°
C10   TURQ    231°  309°
C11   GRN-BLU 257°  283° cyan is considered to be 283°
C12   GREEN   283°  257°
C13   YEL-GRN 309°  231° pure green is considered to be 241°
C14   OR-GRN  334°  206° 
C15   LT-OR   360°  180° back to gold

[+bob1200xl]

These traces seem to indicate that the CHROMA transitions are uniform and stable. Not a great display, but this shows the different timings of the CHROMA signal (top trace) and the color clock (bottom trace).

 

This is Colorbars on the SALT cart.

 

Bob

 

[Bryan]

These traces seem to indicate that the CHROMA transitions are uniform and stable. Not a great display, but this shows the different timings of the CHROMA signal (top trace) and the color clock (bottom trace).

 

This is Colorbars on the SALT cart.

Yep, it looks clean. The only issue is it can get jagged on boundaries of different colors. Put up vertical bands of a constant color and a looping color and you'll see it.

[Bryan]

I think the CGIA datasheet is full of it (written by someone who made assumptions). If SALT tells you to make 1 and 15 the same, then the color spacing is actually 25.7ns. I'll revise the above chart...

[phaeron]

Uh, just a bit of warning... you aren't going to find a consistent authoritative reference on the NTSC color delay even from Atari. SALT tells you to match 1 and 15 and the PAL GTIA hardcodes that, but the Atari Hardware Manual has 1 and 15 labeled different. Then there are games like EPYX Summer Games that use color 15 for red and will show nasty flags if the color delay isn't set to push 15 beyond 1. There's no way to win with one particular setting.