New video upgrade coming soon!

[dwmcqueen]

Are there any current UAV boards available? I need to get one for my XEGS.

[CZroe]

Having trouble navigating this thread on mobile. The OP doesn't have links to updates and relevant posts. Where do I go to order these?

[Brentarian]

Bryan's plan is to make these available in the AtariAge store. He is in the process of moving back to the United States though, so my guess is that it will be towards the end of the year. I'm patiently waiting to buy a few myself!

Edited August 8, 2016 by Brentarian

[CZroe]

Bryan's plan is to make these available in the AtariAge store. He is in the process of moving back to the United States though, so my guess is that it will be towards the end of the year. I'm patiently waiting to buy a few myself!

Thanks. Going to want several myself!

 

Q: Can I wire directly to the old monitor output on the 800/800XL or will I need to cut traces?

 

Plan to do both of those plus a 5200, 2600, and 7800 at a minimum.

Edited August 8, 2016 by CZroe

[+DrVenkman]

Thanks. Going to want several myself!

 

Q: Can I wire directly to the old monitor output on the 800/800XL or will I need to cut traces?

 

 

 

Don't know about installation on the 800, but to install in an 800XL for the cleanest video signal you'll want to isolate the output as much as possible from existing components; that involves lifting a couple inductors in the signal path and solder jumpers to the pads where you lifted. All in all though, a pretty simple installation and excellent output, especially via S-Video.

[+DrVenkman]

Okay folks, I know there are some photos buried in the thread somewhere, but has anyone installed a bare UAV board into a 4-Switch 2600 who can provide some annotated photos showing where to take off the signals (and which signal is which!) from the TIA, and where to grab sound for the RCA jacks I will be installing? I've got Bryan's diagram showing where the signals go to and come from on the UAV itself, just need to see where to pick them up.

 

Thanks!

[Bryan]

Okay folks, I know there are some photos buried in the thread somewhere, but has anyone installed a bare UAV board into a 4-Switch 2600 who can provide some annotated photos showing where to take off the signals (and which signal is which!) from the TIA, and where to grab sound for the RCA jacks I will be installing? I've got Bryan's diagram showing where the signals go to and come from on the UAV itself, just need to see where to pick them up.

 

Thanks!

This post shows a 2600 install:

http://atariage.com/forums/topic/246613-new-video-upgrade-coming-soon/?p=3411171

This one's relevant too:

http://atariage.com/forums/topic/246613-new-video-upgrade-coming-soon/?p=3413611

 

As many of you know, my wife and I started the process of moving back to the US from Costa Rica. Right now most of my stuff is packed and on its way back. However, we were offered a house-sitting job near Jaco and it'll give us a chance to make a little money before we move back for good. I'm planning on keeping enough stuff with me to get these boards done as soon as we're settled. Sorry for the delays.

[+DrVenkman]

This post shows a 2600 install:

http://atariage.com/forums/topic/246613-new-video-upgrade-coming-soon/?p=3411171

This one's relevant too:

http://atariage.com/forums/topic/246613-new-video-upgrade-coming-soon/?p=3413611

 

Hi Bryan - thanks, I found those earlier. I was hoping to see an annotated example showing which signal comes from which pin on the TIA. No worries - I found a TIA pinout that will work. And I'll just grab audio using the instructions for some other a/v mod.

[Ikrananka]

Am I correct in thinking that the output from this, when installed in a 2600, is s-video? Will the video quality be any better than the design that is sold by electronicsentimentalities?

[Bikerbob]

Quick update...

 

After our last trip to the States, my wife and I have decided to move back from Costa Rica so I've been dealing with getting arrangements made and boxing stuff up. The good news is that in a couple months my development schedule will no longer need to be planned around my trips back and forth and I can ship product as needed. We will be moving to Michigan so my wife can spend some time with family and especially her ailing mother.

 

Hi Bryan, not to sound too impatient.. but I am, is there an update? we are two months from when you said should be two months, till you can ship. Is there an update?

 

Between myself and another local fellow we have 10 machines we want to put this board into.

 

Is there a revision going on? or is this a logistics to get it to AA to retail?? Can we get a batch before that? or have someone else produce it? or supply it as a DIY?

 

James

[+orpheuswaking]

Recent communication indicates that Bryan is still moving and has most of his stuff in boxes. It may be a little while longer (but well worth the wait)

[Bryan]

My wife and I are in the (never ending) process of moving our things from our cabin in the Costa Rican mountains to a place right on the Pacific coast (see pic of the view outside our door). The good news is, we don't have to pay rent for looking after this property. The bad news is everything is in boxes and our place is very small.

 

I still plan on moving back to the US soon and ramping up for full production. This place was just too good of an opportunity to pass up. We basically live where this year's World Surfing Games were held. I'm not a surfer, but watching the curls go by outside makes you think about it.

 

-Bry

[+Stephen]

Congrats on living the dream! That's an amazing view.

[Bryan]

Since moving to a small cabin on the beach I've been unable to do much with the Rev. D UAV. However, today I dug out a few tools and managed to get a picture on the screen for the first time. Hopefully I'll be able to make some final tweaks in the next week, and then I'll start ordering everything I need to make a new run. When I know something for sure, I'll start a Rev. D thread.

 

Right now the picture looks very good. One of the hardest decisions to make is where to set the brightness. Atari machines aren't very consistent and the brighter ones have less color saturation. I tend to lean toward backing off the brightness a tad to get better color.

[cjameslv]

If anyone really needs one bad lol, i bought a few and ended up with 1 extra. They output amazing svideo. Don't be a fool and use them for composite! Anyways, i'd be willing to part with my last one just send me a pm.

[Bryan]

For those who are wondering, Rev D is slightly different from C in how it works. For most people the difference will be minimal, but Rev D will have a greater artifact adjustment range, and it will have better electrical isolation from the host machine. It will also be a little easier to install in the 7800.

[adam242]

For those who are wondering, Rev D is slightly different from C in how it works. For most people the difference will be minimal, but Rev D will have a greater artifact adjustment range, and it will have better electrical isolation from the host machine. It will also be a little easier to install in the 7800.

Awesome... My 7800 is what I want this for most.

[GlowingGhoul]

I have 5 extra new UAV plug in boards, if anyone is interested PM me.

[cjameslv]

If anyone really needs one bad lol, i bought a few and ended up with 1 extra. They output amazing svideo. Don't be a fool and use them for composite! Anyways, i'd be willing to part with my last one just send me a pm.

Just updating this is sold, Thanks

[Bryan]

Rev D just hit a snag.

 

It was working great until I tried RastaConverter pictures. Real-time changes to color registers are asynchronous with pixel boundaries. So if you change a color while it's being displayed, the change happens somewhere mid-pixel. If the next pixel is a different luminance from a different register (leading to a short blip of a new color), Rev D cannot detect that the color was latched so it doesn't dump the delay cap (kinda like how paddles work). This totally throws things off and it stops updating until it sees the currently latched luminance again resulting in bars in the picture.

 

So, Rev D relies on pixels only changing on certain intervals. The Rev C method does work, though...

 

Gotta go ponder this for a while.

[+mytek]

Rev D just hit a snag.

 

It was working great until I tried RastaConverter pictures. Real-time changes to color registers are asynchronous with pixel boundaries. So if you change a color while it's being displayed, the change happens somewhere mid-pixel. If the next pixel is a different luminance from a different register (leading to a short blip of a new color), Rev D cannot detect that the color was latched so it doesn't dump the delay cap (kinda like how paddles work). This totally throws things off and it stops updating until it sees the currently latched luminance again resulting in bars in the picture.

 

So, Rev D relies on pixels only changing on certain intervals. The Rev C method does work, though...

 

Gotta go ponder this for a while.

So is the better electrical isolation of Rev D involved in this problem? If not then perhaps just implementing this alone may be the way to go, since Rev C's only problem as I saw it appeared to be related to this. And in all other aspects Rev C had fantastic video. Of course I am also assuming that Rev C was the last release, which maybe I'm mistaken in my assumption.

 

- Michael

[Bryan]

So is the better electrical isolation of Rev D involved in this problem? If not then perhaps just implementing this alone may be the way to go, since Rev C's only problem as I saw it appeared to be related to this. And in all other aspects Rev C had fantastic video. Of course I am also assuming that Rev C was the last release, which maybe I'm mistaken in my assumption.

 

No, it's the way the pixel latching works in C vs D. When the 4 Lum lines no longer match what's being displayed (what is latched), there's a variable RC delay (via the pot). Once a new latch is triggered, there's a match condition again which dumps the capacitor for next time. So, you can only adjust the artifacting delay by the width of the narrowest pixel minus whatever propagation delay overhead is in the chips. You also lose some range due to the fact that GTIA's 320 even and odd pixels aren't exactly symmetrical.

 

Rev C used a transparent latch, so any time there wasn't a match and the delay time had passed, the new pixel info was passed though to the output. Rev D used flip-flops to tighten up the timing a bit but it can be tripped up by a color write to the active pixel followed by a different colored pixel. In this case, the loss of a match starts the delay, and by the time the new data is latched the incoming pixel has changed yet again resulting in no match and no capacitor dump. It begins working again once the stored luminance appears in the image again and there's a match condition. It's fascinating to turn the delay pot and watch lines appear and sparkle in different areas of a RastaConverter image which shows just how messy the timing can be. I'd like to write a test program to capture it on a scope.

 

The solution is to go back to a transparent latch but with Rev D's FET based capacitor dump (Rev C does it passively with a diode across the adjustment pot). I'll work up another Rev D board and see how it goes. If I wanted to make the board bigger and more expensive, I could go nuts with real delay lines and all kinds of other ideas I have, but most people just want a clean picture and the main indulgent feature I wanted was some control over the artifacting.

[+mytek]

Thanks for the detailed explanation on the differences between the two revision levels in how they handle the artifacting. But you also mentioned something about better isolation earlier. How exactly is this being done? Because I remember a post way earlier that had talked about using series resistance in the lum lines as a possibility.

 

- Michael

[Bryan]

Thanks for the detailed explanation on the differences between the two revision levels in how they handle the artifacting. But you also mentioned something about better isolation earlier. How exactly is this being done? Because I remember a post way earlier that had talked about using series resistance in the lum lines as a possibility.

That's true. All input lines now have resistors which provides several benefits, especially since much of the CMOS logic on the board is regulated at 4.5V.

[+mytek]

 

If I wanted to make the board bigger and more expensive, I could go nuts with real delay lines and all kinds of other ideas I have, but most people just want a clean picture and the main indulgent feature I wanted was some control over the artifacting.

 

Bryan I totally understand the indulgent feature aspect, since I did the same with the custom Caps Mode in my TK-II. Most likely I'll be one of the few to actually use it, but it was a pet peeve of mine to include it .

 

 

That's true. All input lines now have resistors which provides several benefits, especially since much of the CMOS logic on the board is regulated at 4.5V.

 

The extra benefit being level shifting? And I presume the main benefit being similar to having the inline resistors on the data lines for DRAM, to minimize ringing.

 

- Michael