Video Overscan Showing on LCD Monitor?

[Osgeld]

on your older top side copper if you look directly above the E in the "comp side" text you have a trace that forms a Y. It may not be a big deal but I see you corrected it, try to avoid those as eddy currents in those regions turn into little antenna's

 

also if you are going to fill the top side with a plane do the bottom side as well and attach the two electrically, you will have better noise immunity, otherwise, interesting project, and good work

[+mytek]

on your older top side copper if you look directly above the E in the "comp side" text you have a trace that forms a Y. It may not be a big deal but I see you corrected it, try to avoid those as eddy currents in those regions turn into little antenna's

 

also if you are going to fill the top side with a plane do the bottom side as well and attach the two electrically, you will have better noise immunity, otherwise, interesting project, and good work

 

Good points. I mainly did the ground plane just because it's an easy way to minimize any imbalanced ground currents, while also making all of the required connections. Realistically due to the small size of this board and the relatively short signal paths, I'm not too worried about noise radiation (especially considering that the A8 motherboard is likely to be far worse). Also my existing breadboard prototype is performing well, and it has a far worse situation going on (very long leads on some of the high speed circuits including the 3.58 Mhz clock line, poor power decoupling, and no power planes what-so-ever). On the plus side, the x4 PLL is internal to the PIC, so the 14.318 Mhz clock is pretty well contained. But I still do appreciate the tips .

 

Thank you,

 

- Michael

[+mytek]

My boards arrived 2 days ago from ALLPCB (not bad considering that I placed this order one day after an order with OSH Park, and those still haven't arrived).

 

 

 

I'm glad to report that it works beautifully on my XEGS. Now I just need to test it on a few other systems to be sure. Nice thing is it does what it's suppose to without any other connections required (just plug 'n' play). And I am very happy with the quality, cost, and fast shipping I received from ALLPCB.

 

So as can be seen the board is pretty minimal, not very many components, small footprint, and for the most part thru-hole design (there is one 5-lead SOT device). Besides being a video over-scan eliminator, this board also serves as a break-out for useful signals connected to GTIA that several other upgrades can take advantage of. So for instance, if I install a U1MB, Stereo Pokey, and a TK-II, all the signals except for two will be available on the Accessory Support Header, thus only requiring two solder connections (far better than the original 10 solder connections). Sometime around next week I should have a complete installation photo showing just such a setup.

 

And now a short little video showing this board in action...

 

https://www.youtube.com/watch?v=5cuSC6fLjW4

 

 

- Michael

[Brentarian]

Your PCB designs are like pieces of art!

[+mytek]

Your PCB designs are like pieces of art!

 

Thank you Brent

 

It is my way of expressing my creativity, and although I'm not an artist, I do strive to make my boards not only functional, but pleasing to the eye.

 

- Michael

[+mytek]

Full Install in XEGS

 

 

Using the break-out header on the V-Gate board really helps organize the wiring between the various upgrades

 

- Michael

[+mytek]

Using either the U1MB SO or S1 outputs to control V-Gate

 

The SO and S1 outputs = Device 2 and Device 3 respectively in the Ultimate 1 Meg Setup screen.

 

 

Enabled will bring the output 'high' with Disabled taking it 'low'. Its state can be saved by pressing 'B', which will also exit the setup menu.

 

So as the name implies, if you set the Sx output connected to the 'EN' pin on V-Gate to 'Enabled', then over-scan will be eliminated. However if set to 'Disabled', then V-gate is disabled and the Atari will show the entire screen including over-scan if present (stock video).

 

- Michael

 

Edit: of course if you don't have a U1MB you can just use a mechanical switch instead...

 

 

Note: V-Gate is automatically 'Enabled' when no connection is made to the 'EN' pin (pulled high by 10K resistor).

Edited November 12, 2016 by mytekcontrols

[+mytek]

The GTIA V-Gate Board is now Officially Released

 

Well I think it's time to let it go out into the wild. Although I haven't tested it with all of the different A8's, it looks good on the ones that I have. The only possible problem that I see, is that it might not like every type of 'color' circuit that was implemented in the various models. And to be fair on my 1200XL I only tested it with the ClearPic 2002 mod already done. My recommendation if it doesn't work for you, is to look into doing one of these mods or better yet use a UAV board.

 

Known Issues

 

There is a synchronization problem that occurs on power-up, where the clock is slightly out of phase that feeds the PIC MCU timing generator from the Atari. This will result in a pixel width shift either to the left or the right where the V-Gate window begins. Not really a big deal, but for some people it might be a deal breaker. I tried using the reset from the Atari to reset the PIC MCU but that made no difference what-so-ever. Interesting thing is that wherever it syncs, it stays there until you power down and back up again (the reset button has no effect). Other than the viewable window being slightly off center, everything looks great.

 

I created a new page on my website: ataribits.weebly.com/gtia-v-gate.html So this will be the place to get everything that's needed to build one of these.

 

- Michael

[peteym5]

Being someone that develops retro games for the Atari 8-bits realize the overscan issues with modern HDTVs and widescreen monitors. I played with several video software tricks to minimalize the issue. One is not use overscan mode if colbak is one solid color and not change with DLIs. The other trick is using HSCROL and setting the HOZ Fine Scroll Bits in the Display List. Then Shift the display over until those right screen fuzz is down to one/two pixels. I have a few upcoming releases that used wide screen and did see this being an issue for wide screen displays.

[+mytek]

Being someone that develops retro games for the Atari 8-bits realize the overscan issues with modern HDTVs and widescreen monitors. I played with several video software tricks to minimalize the issue. One is not use overscan mode if colbak is one solid color and not change with DLIs. The other trick is using HSCROL and setting the HOZ Fine Scroll Bits in the Display List. Then Shift the display over until those right screen fuzz is down to one/two pixels. I have a few upcoming releases that used wide screen and did see this being an issue for wide screen displays.

Yeah the problem can be avoided in software, but depending upon what is required in a game, I would imagine it is tricky. And obviously for games and apps that were created back in the CRT days this would not be an option. So a hardware solution was needed, hence the reason for this project. Haven't the means to test this on a PAL system, but I suspect that it should still work as is, and if not an adjustment in the timing generator code should fix it. Now I just need to find someone in the US that has a PAL setup to test this on.

 

- Michael

[+bob1200xl]

The GTIA V-Gate Board is now Officially Released

 

Well I think it's time to let it go out into the wild. Although I haven't tested it with all of the different A8's, it looks good on the ones that I have. The only possible problem that I see, is that it might not like every type of 'color' circuit that was implemented in the various models. And to be fair on my 1200XL I only tested it with the ClearPic 2002 mod already done. My recommendation if it doesn't work for you, is to look into doing one of these mods or better yet use a UAV board.

 

Known Issues

 

There is a synchronization problem that occurs on power-up, where the clock is slightly out of phase that feeds the PIC MCU timing generator from the Atari. This will result in a pixel width shift either to the left or the right where the V-Gate window begins. Not really a big deal, but for some people it might be a deal breaker. I tried using the reset from the Atari to reset the PIC MCU but that made no difference what-so-ever. Interesting thing is that wherever it syncs, it stays there until you power down and back up again (the reset button has no effect). Other than the viewable window being slightly off center, everything looks great.

 

I created a new page on my website: ataribits.weebly.com/gtia-v-gate.html So this will be the place to get everything that's needed to build one of these.

 

- Michael

 

If you are going to PLL the Atari clock up scale, you may need to sync the Atari clock with the PLL clock. I XOR the new clock with the old and kill any clock cycle where XOR is not 0. This will only happen once - all the future clocks will be in sync until you power off.

 

Bob

[+mytek]

Very

If you are going to PLL the Atari clock up scale, you may need to sync the Atari clock with the PLL clock. I XOR the new clock with the old and kill any clock cycle where XOR is not 0. This will only happen once - all the future clocks will be in sync until you power off.

 

Bob

Very interesting idea I'll have to play around with that. Not sure if I can accomplish it in the MCU's firmware alone, and it might require some additional hardware. Interesting thing is that it is not a direct result of the clock up scale, and I saw this phase error problem when I was running without the x4 PLL in circuit. Although in that case the offset was greater than a pixel due to more time required per instruction with the slower clock. My theory is if I were to double the 14.318 MHz PLL internal clock the shift would be imperceptable. This would also require some more hardware as in clock doubling prior to entering the MCU, then applying the x4 PLL. Doubling could be done with an XOR and a delay line on one leg. But I'll see if it's first possible to do something purely in software.

 

Thanks for the suggestion.

 

- Michael

Edited November 20, 2016 by mytekcontrols

[+bob1200xl]

This 'offset' seems to be the result of not using the Atari generated 1.79mhz clock, so I can see how it would also happen without a PLL. It looks like the GTIA does not divide down the 3.58mhz oscillator at the same phase every time it powers on. Since there is no RESET on the GTIA, this phase offset will persist until power is cycled.

 

I suspect that a simple solution may be to feed the 3.58mhz oscillator to GTIA from the clock divider rather than the Atari oscillator.

 

Bob

[+mytek]

This 'offset' seems to be the result of not using the Atari generated 1.79mhz clock, so I can see how it would also happen without a PLL. It looks like the GTIA does not divide down the 3.58mhz oscillator at the same phase every time it powers on. Since there is no RESET on the GTIA, this phase offset will persist until power is cycled.

 

I suspect that a simple solution may be to feed the 3.58mhz oscillator to GTIA from the clock divider rather than the Atari oscillator.

 

Bob

Yes not having a reset on GTIA is what I felt is a good part of the problem, since it's startup is random, and not synced. Oh well nothing that can be done about that.

 

In the XEGS and I believe the XE's derive the 3.58 MHz clock from Freddie which is being fed by a 14.318 MHz clock generator. This is of course different than the 400/800 and XL's (don't recall exactly what their clock circuit looks like). So to keep things simple I stuck with sourcing the PIC MCU clock from GTIA which was good for a number of reasons, not the least of which was that I was piggybacking that chip anyway so the signal was readily available. And if I were to provide a solution to this startup phasing problem, it would still be great to somehow do so without having to grab additional signals that are not available from GTIA.

 

One of the good things about the PIC chip is that I can start and stop the clock without anything programmically speaking getting messed up or skipping a beat. So perhaps there would be a way to look at CSYNC and OSC, and when a specific relationship exists, startup the PIC clock. As to what this relationship is (or what phase the OSC is in), doesn't really matter so long as the PIC is always started under the exact same conditions each and every time. This would seem like a possible solution.

 

- Michael

[+slx]

_{Found out about this by chance and wondered if it is NTSC specific or if it can be used on PAL GTIAs as well?}

[+mytek]

_{Found out about this by chance and wondered if it is NTSC specific or if it can be used on PAL GTIAs as well?}

Works for both. This is the same chip, but with revised code that I am using in the 1088XEL. However I also had to make a small hardware change, because I later discovered that it wasn't ok to leave the color input to the analog video circuit floating during the off period. Interestingly the polarity during the no color selection is different depending upon what video mode you are in (PAL vs NTSC), so this required a jumper to select between GND or +5V going to the once floating input on the analog switch. I've uploaded the revised code on my website (narrows view port as compared to first rev), but I haven't revised the GTIA V-GATE PCB yet, although I intend to sometime next month.

 

- Michael

[tane]

... but I haven't revised the GTIA V-GATE PCB yet, although I intend to sometime next month.

 

GTIA V-Gate Website has a warning:

Any chance of resuming the project?

I'm getting this with Sophia installed:...

[jc13]

The Sophia (DVI version at least) has V-Gate ability built in. If you have a U1MB, try this replacement for the default plugin and you can toggle it on and off. There are versions for the 1.25 and the 2.0 U1MB firmware in the post.

 

http://atariage.com/forums/topic/278040-u1mb-plugin-development/?do=findComment&comment=4078393

[tane]

The Sophia (DVI version at least) has V-Gate ability built in.

 

The Super Cobra picture was with a Sophia DVI Rev. C.

 

It's not installed a U1MB, it's a complex and spacious PCB. A functional V-Gate would be a small, bespoke and easy solution.

 

 

Edited: last line.

Edited October 28, 2018 by tane

[jc13]

That's the one I have as well. With that alternate U1MB default plugin you can enable/disable it through the setup menu.

[+mytek]

You can also do this with some pokes into memory location $D01D (53277) as well.

 

GTIA V-Gate is only required for the normal Atari video output, and does not work with either Sophia or the VBXE, hence the reason I suggested to Simius to incorporate it into his core code.

 

As for updating the GTIA V-Gate board I'll get around to that sometime next year. I have enough irons in the fire as it stands, and I don't believe it's even on many peoples's wish list. The fix will be to substitute a different analog switch for the one that was previously spec'ed, and of course revise the PCB layout to accommodate it.

[tane]

The Sophia (DVI version at least) has V-Gate ability built in.

 

You can also do this with some pokes into memory location $D01D (53277) as well.

 

GTIA V-Gate is only required for the normal Atari video output, and does not work with either Sophia or the VBXE, hence the reason I suggested to Simius to incorporate it into his core code.

 

So, I'm understanding that Sophia has the ability. That's excellent.

Memory location $D01D --> I don't know how to do it, sounds software approach.

 

Is there a hardware modification to enable the V-Gate ability in Sophia without a U1MB?

Edited October 28, 2018 by tane

[Simius]

Try these files

VGATEOFF.XEX

VGATEON.XEX

[tane]

Excellent !!!!:

 

The only detail is that must be executed each time, but what a change, now it looks how it's supposed to be.

 

 

If perfection is relevant, if now the hidden band has a width of 100%, I think it should be only 50%-60%, see picture, in order to not hide too much:

[+mytek]

If perfection is relevant, if now the hidden band has a width of 100%, I think it should be only 50%-60%, see picture, in order to not hide too much:

 

This depends upon the game. In order to get rid of overscan from everything, it requires a bit wider cut-off region. If you were playing this on a old school CRT you probably would not see any of that screen data you are concerned about cutting off.

 

But I'd like to check this out with the V-Gate chip. What game is that?