Sidequest: VGA scan doubler

[Smonson]

Super nice well done!

I assume your using the 32mhz shifter clock to sync the ripple counters to the video sampling ?

Thanks Exxos!

That's right, the counter that's addressing the RAM that's being read (twice) gets the 32MHz clock, and the counter for the RAM that's being written gets the clock divided by 2.

I'll post the schematic later and you can have a look.

[exxos]

Cool . I was just wondering if you was latching data at the end of a rgb cycle causing odd issues? Inverting the 32mhz may help ? Or you may need to add a small delay before samplings to give the shifter chance to settle ... Just thinking out loud mostly

[Smonson]

Cool . I was just wondering if you was latching data at the end of a rgb cycle causing odd issues? Inverting the 32mhz may help ? Or you may need to add a small delay before samplings to give the shifter chance to settle ... Just thinking out loud mostly

I don't think there's actually a way for the mod to know for sure when the RGB cycle is... That's an unsolved problem for now. But I don't think the screen artefacts that I'm seeing are related to RGB lines settling - in all cases I'm seeing pixels intended to be displayed at one location appearing earlier or later in the scanline, which you can see when moving the mouse around the screen.

I'm assuming that this behaviour is more likely to be happening at the moment of writing the data, since a tiny settling time when reading wouldn't be as noticeable.

The address counter is being clocked from the 16MHz divided clock, so that gives me 4 possible timings for the ram's WE signal (off the 32MHz). But I tried them all to no avail. This is the kind of comment that's best accompanied by diagrams so I'll get into detail tonight when I get home from work

[Smonson]

Schematics attached.

[exxos]

So what happens when you display a solid red, green, blue colour on screen ?

[Smonson]

If a scanline is all one solid colour, then it looks good apart from reflections that appear outside the border.

Thinking on what you said about latching, I added a latch on the RGB lines coming out of the RAM when generating video, and that improved it a bit. So that's defeated my line of thinking about how it was more likely to be appearing at the write stage. Clearly, there are noticeable glitches appearing at read time.

One thing about this design is that I'm driving those 4040 binary counters way too fast. And when the RAM's being read to generate the scanlines, it's double the speed of the one doing writing, so it does make sense that issues would show up there.

I used SN74HC4040PWR, and looking at the datasheet, I can't expect them to work at 32MHz. Possibly it's all down to that reason. And the more I think about it, the more likely it seems, since those counters are made up of a string of flip-flops and there's a propagation delay between each bit, with the most significant bit changing last.

What I can do is go up to the next bigger CPLD package (100 pin) on the next revision and generate those counters in there. That would, at the least, remove the settling time delay of the ripple counter. Depending of course on whether it will fit OK on the board. I've kept it to the dimensions of the shifter's metal box.

[Smonson]

Here's the level of working-ness that was reached. Not too bad for the first try, and valuable information about the feasibility of this project has come out of it.

doubler3.jpg (219.65 KiB) Viewed 6527 times

[Smonson]

...I just did a rough add-up of all the main bits and it came to about $15 USD.

[exxos]

Thinking on what you said about latching, I added a latch on the RGB lines coming out of the RAM when generating video, and that improved it a bit. So that's defeated my line of thinking about how it was more likely to be appearing at the write stage. Clearly, there are noticeable glitches appearing at read time.

Have you checked signals like RW on your scope to make sure simply noise on that line causing the issues ?

One thing about this design is that I'm driving those 4040 binary counters way too fast. And when the RAM's being read to generate the scanlines, it's double the speed of the one doing writing, so it does make sense that issues would show up there.

I used SN74HC4040PWR, and looking at the datasheet, I can't expect them to work at 32MHz. Possibly it's all down to that reason. And the more I think about it, the more likely it seems, since those counters are made up of a string of flip-flops and there's a propagation delay between each bit, with the most significant bit changing last.

You need a synchronous counter in that case.. The asynchronous counter you are using is where each clock will have a delay to the next flip flop. The synchronous ones drive all the clocks from one pin so you do not get the delay..

What I can do is go up to the next bigger CPLD package (100 pin) on the next revision and generate those counters in there. That would, at the least, remove the settling time delay of the ripple counter. Depending of course on whether it will fit OK on the board. I've kept it to the dimensions of the shifter's metal box.

I agree. Like you say, a lot has been learned from this board and it is totally possible for the project to work. So that is great news a huge step forward!

Placing as much logic in the CPLD I think is the best way, as you can easily reconfigure things then if needs be for any reason..

So my thought is just design a board and get it working fully, and not worry about physical fitting yet. Trying to do too much at once is never a good thing IMHO. After all this is more of an experiment than a final product at the moment.

But my hat off to you for this project in any case. I wanted something to do something like this myself for years but never have got time to even think about it.

[Smonson]

Thanks Exxos, I couldn't have made it this far without all your support and help!

I'll investigate those synchronous counters. That sounds like exactly could be needed (whether discrete or inside the FPGA).