Driving an VGA screen with arbitrary timing

Hello,

From your experience can modern LCD screens (with a VGA input) be driven with "out of spec" resolutions and timings (much under the maximum bandwidth) ?

For example:
800x600 30FPS , 600x500 11FPS etc...

Assume no screens work out of spec. The spec is there for a reason.

I'll rephrase my question.
Have you ever tried (and succeeded) to drive an LCD screen with a VGA input - at a resolution / frame rate that wasn't mentioned in the user manual ?

difficult to say without having more details provided.

VGA is an analog IF with RGB +Hsync +Vsync.
LCD panels work on a digital base with TCON ICs. They have digital IF, eg RGB888, RSDS, oLDI etc.

So somewhere in betrween there has to be a ADC converter unit involved, which does the sampling & convertion to digital world.
The sampling clock has to be synced to the VGA sync signals by usage of a PLL or similar.
This is the critical point: if the resolution /framerate is too low, the PLL may be operated out of range and loose sync.
You may test it, there should be no risk to damage the LCD.

As you posted in DigitalDesign, what is your application?
Maybe you can skip VGA and directly use a digital IF?

No. And why would you?
Ive seen an odd classified spec once, but all we did was convert it to a real spec.

I'd you want to go out of spec you either have to try yourself or speak to the manufacturers.

But I still don't see why you'd do it. If it was for a customer then surely the customer should provide a supportive screen.

I have an image source with non-standard resolution and frame rate.
I want to connect it to an LCD, through an FPGA. For start, the FPGA will be a "logic short circuit".
The off the shelf LCD is for debugging purposes - the final product will be connected to a screen (currently not in my possession) that's designed to handle the non-standard image format.

I want to avoid having to design an image converter - that's all.

so the final application will be an analog image source with non-std timing, connected to an analog screen, right?
And for developing purpose, you want to replace the screen with an FPGA + LCD?
In this case, you will have to design an image converter.
Remember that VGA is analog, you cannot connect it to a digital FPGA and just bypass...

so the final application will be an analog image source with non-std timing, connected to an analog screen, right?

Click to expand...

Not exactly. the image source is digital (data, pixel clock, vsynch, hsynch).
The screen's display controller is also digital - designed to accept the above signals.

Remember that VGA is analog, you cannot connect it to a digital FPGA and just bypass...

Click to expand...

Sure. There's a DAC after the FPGA.

In this case, you will have to design an image converter.

Click to expand...

Or perhaps my off the shelf display will be kind enough to show a picture (even though the timing isn't quite what it expects).
I'll have to try and see.

Now the picture gets clearer...
Final application:
ImageSource with proprietary timing (eg 800x600@11fps) ==(IF:digitalRGB)==> Screen
Test setup:
ImageSource with proprietary timing (eg 800x600@11fps) ==(IF:digitalRGB)==> FPGA ==> DAC ==(IF:analogVGA)==> LCD display
Right?

In this case, you may still need to adopt somehow the timings (front/backporches) when converting to analog. And I doubt a VGA monitor will align to framerates as low as 11Hz. But give it a try...
To get some overview about timings, have a look here

My suggestion would be to stay digital (which may need a different LCD):
ImageSource with proprietary timing (eg 800x600@11fps) ==(IF:digitalRGB)==> FPGA ==(IF:digitalRGB)==> LCD display
FPGA does the format conversion by storing the RGB data to Dualport ram and outputting it with different timings/framerate, which fit the LCD datasheet.

Now the picture gets clearer...
Final application:
ImageSource with proprietary timing (eg 800x600@11fps) ==(IF:digitalRGB)==> Screen
Test setup:
ImageSource with proprietary timing (eg 800x600@11fps) ==(IF:digitalRGB)==> FPGA ==> DAC ==(IF:analogVGA)==> LCD display
Right?

Click to expand...

Yes.
Although it may not be exactly 800x600@11fps...

FPGA does the format conversion by storing the RGB data to Dualport ram and outputting it with different timings/framerate, which fit the LCD datasheet.

Click to expand...

On-chip DPR to store a 800x600 image? I think not.
I'll have to go to external memory.

Shaiko, I suggest you visit this site, it lists all the currently recognised VGA standards of which there are a great many:
http://tinyvga.com/vga-timing

Just click on whichever one interests you.

When you plug in your (unknown) analog signal, the monitor will measure the horizontal and vertical sync periods, and seek out in a lookup table in memory, all the correct settings to display a perfect picture.

The specifications are pretty tight, if the horizontal rate is supposed to be 60 Khz, and it measures only 59 Khz, it may not recognise it.
You will likely be faced with a blank screen and an error message such as "format not recognised" or something similar.

Chances are, you will either get a perfect picture first attempt, or a completely blank screen.

Don't worry too much about front and back porch, or sync widths, or vertical blanking interval. The picture may be shifted or cropped, or you get a black band along some edges, but it will display.
The really critical parameters are vertical and horizontal positive going sync edges, and the frequencies for both need to be almost EXACT.

You can then manually adjust the height and width, and centring to get it right.

Obviously if you stick rigidly to one of the recognised standards, that will not be necessary, as the lookup table in memory will set everything up for a picture that exactly fills the screen without tweaking anything.

The dot clock and number of vertical lines you generate at the source need to be either correct or an exact sub multiple.
For instance, if there are 1024 visible lines, you could generate only 512 lines of information and send the same line data twice to generate 1024 lines.

Same with the dot clock. If 150 Mhz (or whatever) dot clock is needed to energise every pixel in a line, 15 Mhz would work fine, your horizontal resolution will be only one tenth, and you turn on and off ten pixels at a time along the line.

Suppose you waned to display a bar graph of ten vertical bars. The horizontal video would only need to be ten times the horizontal frequency rate.

So yes, its perfectly possible to run at a much lower screen resolution, but you need to go about it with a bit of care, or the monitor will just not display anything.
I have successfully done this myself and had to discover all this the hard way !

I completed my design.
The VGA screen I'm working with seems to be pretty tolerant working with out of spec resolutions.

But one thing I learned the hard way is that the pixel values must be all zero's during blanking times.
If it's not zero during blanking time - the picture gets disfigured...why do you think this happens?

Only a wild guess, but the monitor may measure what is supposed to be blanking to set up some reference dc level.
If there is active video present at the sampling point, the dc level may change dramatically from line to line corrupting the displayed brightness levels.

I never noticed that effect on my monitor, but my video was only a digitally generated bar graph, and the first vertical bar was well after where the normal blanking period would have ended.

Its all really interesting stuff, quite a challenge, and something to be proud of when its all finally working.

Well done Shaiko.

I never noticed that effect on my monitor, but my video was only a digitally generated bar graph, and the first vertical bar was well after where the normal blanking period would have ended.

Click to expand...

I created a black white chess pattern.
It works flawlessly as long as I drive R/G/B to 0 at blanking time. Otherwise, the picture gets disfigured (on more than one monitor)
My guess would be that the monitor tries to synchronize on green - but I'm not sure.
I synthesized my project on an old DE2-150 board. A generic VHDL VGA timing controller with a pattern generator connected to it.
If anyone is interested, please let me know and I'll send him the project.

My guess would be that the monitor tries to synchronize on green - but I'm not sure.

Click to expand...

All the monitor needs to synchronise are positive edges on the vertical and horizontal sync edges. Both are edge sensitive only, duty cycle (sync width) does not matter.
The RGB video inputs do not need any sync directly added to them, both syncs go into the monitor as separate individual signals.

If you feed in say a completely grey screen, or a completely white screen, the only difference is the continuous dc level of the active video.
As there are no syncs the video input to the monitor, the video might just be a continuous dc voltage.
The brightness level needs to be set somehow, because the only difference between grey and white is brightness.
That is usually done by clamping the back porch blanking level to some fixed reference, then whatever video follows on after that, becomes a recognisable brightness level.

So as you have already discovered, R,G, and B all need to be set to zero during horizontal blanking.

I still don't understand the sense behind designing an LCD Rx controller that reacts to the RGB levels during blanking...
If I was to design the receiving end - I'd process the pixel data only during the non-blanking period (after synchronization is established) and ignore it during the blanking period.

Its a historical thing.
Most video in the past was always ac coupled.
Think of TV transmission, or where you have multiple video amplifiers in a long chain between the TV camera in a studio, and your own TV at home.

What happens if you try to send an all black screen, or an all white screen ?

If its ac coupled the video brightness level will always try to average out to some kind of mid grey. So usually there has to be some kind of clamping of the blanking level to some fixed reference.

Now all computer RGB video these days is fully dc coupled coming typically from three DACs. But if it comes from somewhere else, such as a video camera, the video may be ac coupled, and if you do not have some method of restoring true brightness levels (with respect to blanking) the picture quality will be awful.

Night scenes will look like thick fog, as the dc level drifts up into grey.
Bright daylight scenes will drift down so you only see deep black where there is any shadow. Ac coupling just averages everything to some mid level.

So any monitor of reasonable quality will sample the blanking level during the back porch interval, and correct everything to that.
Either with an analog dc clamp, or digital addition and subtraction of a constant in software.

Thanks for your help Tony.

I have another question:

Does VSYNC appear on the same clock edge as HSYNC ?

For example, suppose our HSYNC and VSYNC signals are active low.
At a certain clock edge - VSYNC drops from high to low (becomes active).
Is it mandatory for HSYNC to also drop on the same edge ?

The VGA standard for syncs is the positive going edge only, for both horizontal and vertical syncs.
The syncs are fed to the monitor separately to the RGB video, so the sync waveform could be a 50%/50% square wave, and it will work fine.

So don't worry too much about sync pulse width. As long as the positive going edges are in the correct place with respect to the video, it will bo o/k.

Vertical and horizontal syncs are usually just the direct outputs from some kind of counter or frequency divider.

Vertical and horizontal syncs are usually just the direct outputs from some kind of counter or frequency divider.

Click to expand...

So when VSYNC asserts, HSYNC should also assert ?