CRT vs LCD monitors

Go To Last Post
24 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello to all of you.
I just finished a simple vga test signal board which displays eight vertical colour bars,but not in any monitor type.It works in lcd type displays and not in the only crt monitor which is available in the place.
What kind of differencies might be in these two type monitors.Does older crt monitors require any driver installation?

Greetings.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In a crt, there is no 'line buffer'. The pixels go out the same nanosecond they come in the r,g, and b lines. It is analog. In an lcd, you can shift in a line 2,3,4,5 etc times faster than you have to. At the end of the line, there is a h sync, and the data in the shift register hops into the screen. It is digital. The timing needs to be EXACTLY right within a pixel or so for the crt.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not sure if this would help you, but I did a VGA display project using an AVR. Here is the page...

http://lucidscience.com/pro-vga%20video%20generator-1.aspx

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Timing problems is what i was afraid for.
Vga timing appnotes recomend for 640x480 60HZ an 25,175 MHZ crystal.Nearly impossible to find it.I clock it with 25MHZ and the vertical frequency is 59,3HZ.And probably that's the reason that crt goes black.

Thank you guys.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So how about using a Programmable Oscillator for the clock?

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One of the most common mistakes is to have something other than 0volts on the RGB lines during the blanking interval. That will cause the monitor to lock, but show only black.

25MHz is fine for the 640x480 standard.

Is your sync generator FPGA based? If so, you can derive just about any VGA pixel clock from a 27MHz clock using a DCM.

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can go 25.2MHz instead if 25.175MHz if you like, it only makes Vsync exactly 60Hz. But for an application like this, the actual pixel clock is not important, as long as the H and V pulse timings are similar (not required to be identical).

Yes good point AtomicZombie, the RGB signals must be black when not drawing the screen, because the monitor expects to see black and tries to calibrate to that blackness (by clamping), if RGB signals send white then monitor thinks that voltage is black reference, so it will display all voltages below that as black.

bobgardner wrote:

In a crt, there is no 'line buffer'. The pixels go out the same nanosecond they come in the r,g, and b lines. It is analog. In an lcd, you can shift in a line 2,3,4,5 etc times faster than you have to. At the end of the line, there is a h sync, and the data in the shift register hops into the screen. It is digital. The timing needs to be EXACTLY right within a pixel or so for the crt.

I would disagree a bit, but then again, I am not fully aware of how LCD panels work internally, even though I am very familiar with how they work externally and how digital video interfaces work in general.

I just don't get why in a display panel (not the monitor) it would be possible to transfer a line faster than it arrives (or if it is then why it should be done as it requires buffer memory).

Normally when a LCD monitor (not the panel) is receiving analog video (like in this case), it detects from H and V sync frequencies (you also get lines per frame from that) what the video format is and configures a PLL to generate a pixel clock from the H sync, and that pixel clock then drives the whole video system.

And since you are sampling the analog video with that pixel clock in real time, it can be sent to the panel in real time, there is no point to buffer it first somewhere for say for 1 line and then transmit that line faster than real time pixel clock, because you don't have a faster pixel clock than real-time.

edit: quote tag fixed.

Last Edited: Mon. Feb 14, 2011 - 07:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
So how about using a Programmable Oscillator for the clock?

JC

Not really, SparkFun device is the one with 133MHz oscillator, nearest integer to divide with is 5, which results into way off clock of 26.6 MHz.

Even if you had the 125MHz version you would still end up at 25.0MHz. Only difference to a 25.0MHz crystal is that crystals have better than 200ppm accuracy and SparkFun device has only 0.5% = 5000ppm.

A better would be a crystal fed PLL where both reference and output have integer divisors.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My mental model of the lcd has been like a 595... a shift register and a latch. You shift the data in as fast as you can and latch it, and it burns into your retina for 30ms. During that time you have to do the rest of the other 480 rows. Maybe some lcds shift in 8 bits in parallel, but same idea. Its refreshed a line or lines at a time. If this is completely out in left field, I apologize in advance.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another option is to clock at 20MHz and display 400x300 over the 800x600 screen (normally 40MHz).

You can also derive just about any resolution you want by cross multiplying the actual values. For instance, my AVR project draws a 256x240 screen over the 640x480 screen by working the 25.175 values back to 20MHz.

Keep in mind that with "fudged" timings, an LCD monitor will "haze" certain vertical stripes in order to compensate, which may be quite noticeable on sharp edges using lower resolutions.

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You don't need to get the frequencies exactly right - that's why we have sync pulses. Besides, if it were a sync problem, the display would be lit but scrambled up on a CRT. I'm with AtomicZombie, this is most likely a black level problem.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A scrap VGA card more than likely has the right crystal oscillator.

A LCD monitor likely does more that just '595 style shifting; though the bare module does. I interfaced one from Sharp with an FPGA a few years back; but this was with PCLK, HSYNC, VSYNC, BLANK and 18 bits RGB and timing is far less critical. No PLLs trying to achieve lock or blacklevels.

Anyway, a modern monitor also can display non-native resolution, performs all kinds of image processing for colour, gamma corrections and weird stuff like dynamic contrast. All that processing goes through a frame buffer and a processing pipe line. Can easily cause a few frames of latency.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some of the other common video "gotchas" that I have found while helping others build video based projects are...

- HSync and VSync are separate processes and always need to happen, regardless of the other. So you do not stop HSync during VSync.

- Some VGA monitors require 80 or 100 ohm resistors on the sync lines, especially of your logic is working at 5 volts.

- Always send negative going sync pulses, even if the "standards" require positive pulses. Only ancient monitors (14" VGA CRTs) require positive sync pulses.

- If this project is AVR based, keep in mind that the AVR interrupt system has a 2-5 cycle latency, and this will need to be corrected in order to have a stable image.

- Some websites incorrectly show pin 9 as being part of the ground loop, and this is incorrect on most newer monitors. This is the proper way to connect a VGA port...

http://lucidscience.com/pro-vga%20video%20generator-2.aspx

As for your analog DAC, just keep the voltage below 1 volt, and it will work fine. Actually, .7 volts is the standard, but monitors will not complain of you fudge that a bit.

Also, if you are intending to create a frame with a resolution of less than 640x480, then a simple resistor based R2R DAC will give you a better image than a quality digital DAC will. At low resolutions, the "fuzzing" effect of the R2R DAC will smooth out your image. Using a high speed digital DAC at such resolutions makes your image look much too blocky.

Good luck!

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AtomicZombie wrote:

- So you do not stop HSync during VSync.

This board is so great... I am now going to go back and try to get my video programs working. This might have been my downfall.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
V_rst:=(counter_V==524);//vertical reset pulse

when (counter_V>=480) & (counter_V<=524) then
{
BGR:=^b000;//blanking when beam returns from bottom to top
}

V_Out:=(counter_V>=490) & (counter_V<=492);//vertical sync pulse

The application is based on a cpld.Is there any chance,that this monitor needs positive pulses?It is old from 1997.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your vertical code looks good, and only the 800x600 "standard" asked for positive sync pulses, not 640x480.

You said you measured vsync, and it was close, so your error is probably in the horizontal definition someplace.

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is a difference if we live with analog or digital video. Most of this applies to analog video on VGA connector, while some does apply to digital video inside a device, perhaps fed to TFT module.

Since there is no pixel clock on analog VGA connector, the pixel clock is internally derived from HSYNC in the monitor. Hopefully the monitor chip reacts to edge of sync signal than actual length, but certain tolerances are required for it to work. So remember this when generating video from say 20MHz crystal instead of 25.175 crystal, as the monitor then internally samples VGA640x480 with internally generated pixel clock.

Jayjay, you are right but only very old video cards have the right crystal, as most cards use a single crystal with PLL to come up with a range of frequencies. And AVRs do not work at 20+MHz, so you'd have to divide that crystal by 2 externally.

Atomiczombie is right about HS and VS needing to be continuous. And the real reason why 100R resistors are required on HS and VS is it provides source termination for the cable and monitor to prevent ringing. If VS is generated by feeding HS timer output to VS timer input, then it also helps to isolate the cable and monitor from the VS timer input. This is true every time a long transmission line (cable) is driven, so it is not a quirk of VGA monitors.
Also LCD monitors may or may not be picky about expecting certain sync polarity, so best to get it right, or the image is shifted because wrong sync edge is expected. Older analog monitors use sync polarity to detect if 350, 400 or 480 lines of video is transmitted to fit it on screen vertically, but microprocessor controlled CRTs and of course LCDs can count the lines per frame so they can be of any polarity. If they expect certain polarity with certain format, then the video is shifted a bit horizontally and vertically (seen this on some TFT).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oddly enough, I am here tonight working on an FPGA based project that outputs a 1024x768 VGA signal. I like Verilog as it seems as easy as basic, so here is my sync and frame generator code....

// 1024 X 768 VGA GENERATOR BY RADBRAD

// HORIZONTAL COUNTER TO 1343
if (hcount == 1343) begin
hcount <= 0;

// VERTICAL COUNTER TO 805
if (vcount == 805) begin
vcount <= 0;

// INCREMENT VERTICAL COUNTER
end else begin
vcount <= vcount + 1;
end

// INCREMENT HORIZONTAL COUNTER
end else begin
hcount <= hcount + 1;
end

// HORIZONTAL SYNC PULSE
if (hcount < 136) begin
hsync <= 0;
end else begin
hsync <= 1;
end

// VERTICAL SYNC PULSE
if (vcount > 770 & vcount < 777) begin
vsync <= 0;
end else begin
vsync <= 1;
end

Am am using a DCM (Spartan3) to pump up 27MHz to 64.8MHz, which is plenty close to the needed 65MHz 1024x768@60Hz clock.

My timings are based on this standard...

// ----------------------------
// 1024 X 768 @ 65 MHZ TIMING
// ----------------------------
// HSP: 0136    VAL: 0000-0135
// HBP: 0160	VAL: 0136-0295
// HPX: 1024 	VAL: 0296-1319
// HFP: 0024	VAL: 1320-1343
// TOT: 1344

// VLN: 768	VAL: 000-767
// VFP: 003	VAL: 768-770
// VSP: 006	VAL: 771-776
// VBP: 029	VAL: 777-805
// TOT: 806

This code is in production in several commercal products, so it does work, and it will be very easy to just change the counter values to generate whatever VGA standard you want.

Here are the registers as they are now...

// VIDEO REGISTERS
reg [10:0] hcount;
reg [9:0] vcount;
output [3:0] red;
output [3:0] grn;
output [3:0] blu;
reg [3:0] red;
reg [3:0] grn;
reg [3:0] blu;
output hsync;
output vsync;
reg hsync;
reg vsync;

As you can see, I am using a 12 bit DAC to generate 256 out of 4096 colors. I also use a palette lookup table, but that is another part of the code.

Generating VGA is so easy to do on a CPLD or FPGA that it almost makes me feel guilty after working so hard to count cycles on an AVR!!

Please report back as your project progresses!

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you guys all of you.
After a lot of trying i finally focus the problem.
Is an experimental board and the driving circuit of RGB signal is the simplest i could think.1K resistor and 1N4148 diode in series for each colour.It has different brightness level from monitor to monitor,but in most is visible quite well.Only in old analog monitor the screen is completely dark,causing voltage drop in 1K resistors,probably the input needs more current(the board and monitor are in the home,oscilloscope is in the shop).
And another think that i cant explain is in lcd monitor when auto image adjust is pressed the 1/8 on the right edge is cut and the visible bars are wider.Information of the image is still 640x480 31.1KHZ,59.3 HZ but instead of pixel clock of 24.9MHZ pixel clock is 28.5MHZ.Horizontial and vertical shiftings are working.

Best regards.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The monitor sees something funny about timings, plus pressing auto image adjust tries to actually detect the active video horizontal position during a line. And whatever timings it detects, it tries to scale that to the TFT display, which most likely is not 640x480 anyway.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, your timings sound way off, which is why the CRT fails and the LCD tries to do its best.

Use my Verilog code and adjust it for 640x480 while using you 25MHz clock. Both monitors will show exactly 640x480 @60Hz .

Even a 100K resistor will give you video, so I guarantee it's your timings that are the issue.

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

Last Edited: Sat. Feb 19, 2011 - 01:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One think i missed in counting is that reset in 800 pixels needs 798 in code.0-799 is 800 cycles,minus 1 cycle for the output of the reset register for async reset, total counts=800.The code needs for sure some timing trimmings,but in general it works.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But if you are reading a pixel clock of 28.5MHz, then something is not right in the timing.

This would explain why the CRT cannot lock.

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Finally the two problems are solved with some slight modifications in circuit and the timings.
In crt monitors picture was complete dark,only in the highest contrast/brightness was visible and in lcd was quite well visible but not so bright.
The simple 1K resistor with 1N4148 for each of colour was the initial output stage.1K resistor reduced to 470 ohms and the picture became bright and very clear in both type of monitors.
Modifications made in timings,keeping the timing length of synchronization pulses but reduced the length between the end of the line and horizontial synchronization pulse,front porch from 16 reduced to 10 leading in an horizontial shift of the picture to the right.
Reduction made in vertical front porch from 10 to 8 leading in a vertical shift of the picture upwards.
After these two changes picture fits and refits exactly in the screen.Little differences from the standard timings.

In the end,i want to thank all of you.

DISCLAIMER:
NO DOGS WERE HARMED DURING AND AFTER DEVELOPMENT OF THIS product?,thing?,anyway VGA GENERATOR.THE CAT GOT SICK AND SOMEBODY SHOT A DUCK BUT THAT'S ABOUT IT.

Attachment(s):