Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Pal to vga converter

Status
Not open for further replies.

Bar Ettdgui

Newbie level 4
Joined
Mar 30, 2015
Messages
7
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
63
Hello
I am doing a project using TERASIC DE2 board to convert pal 720×576 to vga.
I am using the adv7180 for pal adc and adv7123 for vga dac.

I have a problem finding the right resoltion of vga wich will be good for pal conversion

1 frame of pal is 0.04s but i cant seem to find the right resoultion in vga wich resembles this kind of timing... the closest one was 800×600 100hz and it was 0.01s with 67.18MHZ pixel clock but the pll can give me 68.181818MHZ wich will couse problems.

Ideas will be a great help!

Help please.?
 

Hi,

0.04s is 25Hz, or in your case 25fps.

You may need to synchronize to your incoming PAL rate.
Otherwise there will be some artefacts.

A PLL could be used to synchronize.

Klaus
 

I have no problem syncing to my pal income i have a problem finding the right frame ratio in tge vga part that will fit the incoming pal rate i preper to deinterlace the pal using line dubbling for evry field
So i need a vga rate that will alow me to intrlace properly but for now i am serching for a vga rate that will cordinate to 0.04s frame or 0.02 field
 

There was another thread about this on edaboard located here. I didn't follow any of the links provided by others, so who knows if any of them will help.

Also this might help you out.
 

Thanks for the reply but i all ready saw this tread and my problem is with the timing and resoultion... and the replys in the tread don't cover it..

The second link you gave aproved what i thought, using 800x600 100hz in vga will probbly give the best solution but in order to use this resoltion a pixel clock of 68.18Mhz is needed but my PLL can only give me 68.181818 wich will couse timing problems...
 

I don't think you clued in on the gist of the threads, there is no direct translation between the two formats you have to interpolate/rescale/resample for the best results.

But given your pixel clock rates you mentioned above (not checked for accuracy or suitability), a VGA monitor syncs to the incoming video signal, so 68.18181818 is approximately off by +20 ppm from the 68.18, which if the monitor can't sync to that then it's not a very good monitor. A +20 ppm clock difference is pretty good, many products use +/-100 ppm oscillators and I suspect a typical commodity PC video card doesn't use much better than +/-50ppm (the more accurate the more expensive). So I suspect your VGA output will sync without a problem even with a pixel clock that is off by quite a few ppm.

If you meant 67.18 then that is ~15,000 ppm, which goes back to the first paragraph, there is no direct translation possible.
 

I'm working on something related to this. I have a number of different solutions that work better in different scenarios.

To help you best we can look at your project two different ways, each having a different set of initial questions and each leading to different discussions.

A. Doing it the way you're doing it.
Question 1: What device is the source of PAL signal?
Question 2. What is the output display that you want to drive with the VGA signal?

B. A more abstract look at your project.
Question: What is the end goal that you want to achieve with the solution? What's it used for?

------------------------

Some facts to help you a bit:

PAL (and NTSC) are both television standard signals. Both have about 15KHz horizontal refresh rate, while VGA specification requires 30KHz+.

Although PAL is often said to have a vertical resolution of 576 lines, the signal is interlaced, and each field at 50Hz is only 288 lines vertical resolution, so it's best looked at like this, 576 lines at 25Hz or 288 at 50Hz. To get 576 in a single refresh cycle the signal has to be deinterlaced. This is something that you don't mention above, whether you already deinterlace your signal or not. Depending on your signal source deinterlacing technique can vary, so that's something to keep in mind. If you work with 576 line frames at 25Hz, you don't necessarily have to pick 100Hz refresh rate for VGA like you said above. 75 is a multiple of 25, so 75Hz can be a good option, and it has the advantage that LCD monitors can sync to that, while they won't sync to 100Hz.

Horizontal resolution if PAL, there's an interesting topic. PAL being a CRT TV signal doesn't really define a specific horizontal resolution. You can divide a scanline into as many segments (or pixels) as you want. 720 is just a number, it has no real relation to PAL. Are you sure that 720 for horizontal resolution is the most optimal for your application? It's an analog signal, a pixel is a digital concept. Pixels don't really exist in PAL. So that's something you can perhaps reconsider.

Generally LCD monitors with VGA input will sync to 60 to 75Hz vertical refresh, rarely anything outside that range.

Generally VGA monitors will sync to an entire range of vertical refresh rates, they don't have to be one of the common values like 60, 70, 75. You can have (as an example) a vertical refresh of 62.5Hz, and that's acceptable for a VGA monitor. In fact often CRT VGA monitors will work with 50Hz vertical refresh, the flicker will be strong though, but that depends on the phosphors of a particular CRT. While I said you can do 50Hz with a VGA CRT, you still have to obey the 30KHz+ specification for horizontal refresh.
VGA LCD monitors will not sync to 50Hz vertical refresh because LCD monitor manufacturers are just being jerks, there is no technical reason why they can't work with that refresh rate. There is actually a way to get around this, but it's a rather extreme measure.

VGA signal also technically has no horizontal resolution. But to show picture on an LCD, which *does* have a fixed horizontal resolution the LCD monitor does clock-from-data recovery on your VGA signal to get the pixel clock and then buffer the frame and then scale it (if needed) to the native resolution of the LCD. The scaler chip in LCD monitor usually only works with a few common input resolutions.
Unlike LCD however, a CRT monitor will accept any horizontal resolution you like, so that's something to keep in mind. This fact becomes useful when you add pixel clock constraints into your project.

So to make your PAL signal into a VGA-compatible one it's mostly the task of converting that 15KHz horizontal refresh into something 30KHz+. And there's more than one way to do it.

Because VGA is a computer monitor signal standard I will give you a real world computer example. In the past 320x200 was a common computer resolution, and when VGA standard was introduced there was a need to display it. The problem with 320x200 modes is that they also had 15KHz horizontal refresh rate, but VGA specification requires 30KHz+ horizontal refresh rate. The solution here was double scan. The VGA controller would repeat each scanline of the 200 to paint 400 lines on the monitor, to achieve the necessary 30KHz horizontal refresh rate. It's just an example for you to examine.

If you haven't abandoned this thread yet, let me know if you want to discuss further. I work on many projects like this.
 
Last edited:
  • Like
Reactions: HasHx

    HasHx

    Points: 2
    Helpful Answer Positive Rating
So the principles I described above are applicable to the selection of pixel clock. For example I believe the clock generator in your FPGA should be able to make 37.500000MHz from 50MHz clock (3/4 ratio), for which you can set up the following VGA mode: 800 total pixels wide (720 active) by 625 total lines (576 active) at 75Hz vertical refresh, which results in 37.500000MHz pixel clock.

Similarly, if you wanted to go with the 100Hz vertical refresh, the same resolution, 800 total pixels wide (720 active) by 625 total lines (576 active) at 100Hz vertical refresh is exactly 50.000000MHz pixel clock, which you have readily available on your board.

Those 67 and 68MHz numbers you picked for pixel clock are a little high. Best to keep pixel clock under 50MHz. Keep in mind that higher pixel clock will also demand faster video memory and more strict memory timings.
 
Last edited:

thank you very mach for your reply has been a great help.

1. Deinterlacing: my method of deinterlacing is line dubbling menning i'm going to display twice every line.
2. PAL: 625 lines(576 active) by 1728pixels(720 active) in BT.656 digital protocol, wich comes from ADC-adv7180 chip.

1 PAL frame(576 lines) = 2 fields (288 lines) =0.04s per frame mening 0.02s for field.

I hope to find a VGA resolution that has 0.02s per frame so i could take the 288 line (pal) and transmite every line twice (deinterlacing) getting 576 lines.

* you suggested i use "800 total pixels wide (720 active) by 625 total lines (576 active) at 75Hz vertical refresh, which results in 37.500000MHz pixel clock" meaning = 800*625*1/37.5MHZ= 0.0133333s per frame wich is not comptible to the 0.02s per frame of PAL .

using the 100hz refrash rate using a 50MHZ pixel clock = 800*625*1/50MHZ = 0.01s which has a 1/2 ratio to the PAL frame of 0.02s meaning that if i will transmit every frame twice i will rich my 0.02s goal and won't have timing issues.

my only fear is that the monitor won't support the 100 hz refrash like you said.
 

You need to get your terminology down. Frame is 576 lines, once 0.04s. Field is 288 lines, once 0.02s. A frame has two fields.

To deinterlace a TV signal like PAL or NTSC means to take two fields and make them into one frame and display at once. This results in a 25Hz framerate, which you can bring up to 50, 75 or 100Hz by showing each frame two, three or four times.

For that reason your math above is not necessarily correct.

What you say about taking a single scanline of a field and showing it twice is called double scan (in VGA terminology), or scandoubling (in TV terminology). That's not a true deinterlace.

Which is why this question is important:

What is the resolution of your video source? What device creates the picture? If you are deinterlacing a PAL VHS movie, your picture has 576 vertical resolution originally, and you would ruin it by doing a double scan on it, it is the wrong way to deinterlace it.
If your video source was an old game console, it probably has half the vertical resolution, 288 or less. For this scenario double scan is a good solution.

So what's the video source?

And you didn't say what kind of monitor you want to use. And why you're doing it.

You know, there's a way to show 50Hz on an VGA LCD monitor, but it's a bit extreme...
 
Last edited:

The resoultion is 576×720 from a pal camera.

The monitor is a dell pc minitor with cbvs input.

It is a project for my exprince in vhdl

Is there a 800 total pixels wide (720 active) by 625 total lines (576 active) at 50Hz vertical refresh rate ?
 

The resoultion is 576×720 from a pal camera.
Does the camera support progressive scan? Does it support NTSC mode?

Also, don't do double scan to deinterlace this, it will not look good.

The monitor is a dell pc minitor with cbvs input.
Is it an LCD?
You don't mention a lot of details, like if your monitor was widescreen and your input was not, you could add aspect ratio correction into your project.

It is a project for my exprince in vhdl
You can already see that PAL to VGA is not an ideal case for conversion, all solutions have many drawbacks. You still get to have experience with VHDL, but you can simplify your task by changing your input video standard. That's just a suggestion, you can stay with PAL but it's an extra challenge.

Is there a 800 total pixels wide (720 active) by 625 total lines (576 active) at 50Hz vertical refresh rate ?
If you had a VGA CRT monitor, yes, it will work, because 625 times 50 is 31250Hz horizontal refresh, which satisfies VGA specification of 30KHz+ horizontal refresh.

It won't work on most LCD monitors due to artificial limitation in the firmware of those monitors, requiring a minimum of 60Hz vertical refresh. You can however make it work if you change the crystal/clock oscillator in the LCD monitor to something 5/6 of the original clock, it's only a reference clock so it doesn't have to be an exact value.
 
Last edited:
  • Like
Reactions: HasHx

    HasHx

    Points: 2
    Helpful Answer Positive Rating
I got a similar to above setup working with interlace, reading pixel data from onboard RAM. Did you make any progress?
 

I am working on some basic modules i haven't yet completed all modules in order to try the setup.
 

Hi can anyone give me the spec needed for 576x720 100hz
Pixel clock:
H_frontporch
H_sync
H_backporch
V_...

or a set of formulas and i will calculate my self
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top