VGA using 8 bits RRGGBBII + HS & VS = 10 pins - Discussion....

Cluso99

Postedit- RRGGBBII where ii is intensity, seems the better option from the discussion below. Therefore I have changed the title from RRRGGGBB.


I am thinking that there is no more hub space taken using 6bit VGA versus 8bit VGA. I know it uses 2 more pins (or 1 with and XOR gate and 4 resistors - Phils circuit).

Has anyone tried this and does it produce a better display ???

Which color is best to be left at 2 bits (R,G or ???

I am thinking of putting this on an upcoming pcb so I am interested in comments. I have the pin(s).

Jack Buffington

I haven't tried it but can say that Blue would be the best one to leave at 2-bit. Our eyes are most sensitive to green light and least sensitive to blue light. It is sort of interesting that we don't need as much color information from blue and red as we do from green as well. Try this sometime if you have the right software: Take an image that is of a certain dimension (let's say 400x400 pixels) Now split it into three images that are red only, green only, and blue only. Scale down the red image to 200x200 pixels. Scale down the blue image to 100x100 pixels. Now scale them back up using nearest neighbor instead of bilinear or bicubic interpolation. The blue will appear quite pixely. Combine all three images back together into a RGB image once again and it will look virtually identical to the original. You will see a tiny bit of color fringing at the edges of things but otherwise, you don't see any pixelation. Do the same thing with the channels rearranged and you will see the pixelation. I have also tried this with color depth. You start seeing big artifacting when you get down to three bits per channel. You see less with blue.

Ariba

AFAIK, Bill Henning has done this on the Morpheus, some years ago.

Andy

pedward

Here is a sample image using a RRRGGGBB palette:



I attached a GIMP palette which has the proper colors.

Tubular

Yeah I also recall Bill Henning tried this. Others have suggested from time to time but I thought bill actually did it.

How come you have spare pins? Unfamiliar waters, surely?

Cluso99

Tubular wrote: »

How come you have spare pins? Unfamiliar waters, surely?

More than 1 prop

Rayman

Well, I've done it for PTP2's 3.5" touchscreen. But, it's not quite the same because it doesn't need H and V sync signals.
I think it was Phil who said a long time ago that it should be possible.

One trick is going to be getting gray scale to come out right using a resistor DAC. I figured out how to do it for a 24-bit DAC, but it might be harder with resistors...

RossH

All,

Yes, Bill implemented a HiRes video driver using RRRGGGBB for the Morpheus. Catalina supports this video mode. The resulting shortage of pins and Hub RAM on that CPU is not really a problem with Catalina because you can run your VGA display on one CPU and your other drivers (keyboard, mouse, SD card etc) on the other CPU. Your actual program can run on either CPU.

Ross.

Lawson

To fix any grey scale issues, how about running the LSB of the blue and red from the same pin?

Lawson

Cluso99

Thanks Ross and others. Perhaps Bill might chime in with his observations.

the-new-guy

I have always thought that the reason blue bits have less effect on image quality (particularly on pictures) because part of the blue data was already stored in the green... I suppose I did just assume this, and I have not researched the subject much.

Rayman

red, blue and green are independent. Your eye is much more sensitive to green, so that is the channel that gets the extra bit, if one's around.
red and blue are about the same, but red usually gets the second bit.

Another option is RRGGGGBB. But, in the 80's people spent a lot of time on this and someone decided RRRGGGBB is best...
There was actually a computer system that used this mode (according to wikipedia anyway).

Phil Pilgrim (PhiPi)

Another option would be RRGGBBII, where the two II pins are shared as LSBs for R, G, and B. The advantage is that you get 16 gray levels, in addition to colors in a wide range of saturations. Here's a spreadsheet that shows the circuit and the resulting palette. I've rotated the rows in the palette so that the grays line up in the left-hand column:



One possible glitch in this process is the generation of HSync and VSync. One thing I discovered when doing slides with a separate inset is that timing the overlay video with a system-clock offset from the video-generated syncs results in a shimmering effect as the pixels jiggle back and forth. The same would also be true for generating the syncs from the system clock, since it would not be synchronized to the video PLL. What might work is to switch vcfg back and forth between the color pins and the sync pins. This will restart the internal counters, but at least they'll be sync'd to the video PLL.

-Phil

Cluso99

Nice work Phil - thanks!

Do you think it is worth the trouble to use the 8 bits ??? Unless the VGA is much improved, there is no point in making non-standard video.

A quick question about the HS and VS... Does the HS activate during the VS ? Is the VS and HS normally a low going pulse or high going pulse ? (yes, I could look at the code but you probably know this) - I just want to be sure the XOR works on 1 pin.
Next question is what drive is required for the HS and VS ? ie. with your XOR circuit of 10K+5K+5K+10K can one of HS or VS be driven from the first 10K/5K junction without buffering?

With regard to the shimmering, why does using multiple cogs for generating alternate lines not have this problem (or does it)?

Phil Pilgrim (PhiPi)

Cluso99,

The advantages I can see for 8 bits, per the RRGGBBII scheme are the 16 gray levels and the subtle, non-saturated mid-tones, which would work well for skin tones and other natural shades. Unfortunately, my color compression would not work with it, since I need the extra two bits for indexing.

I've only worked with 640x480, and for that the syncs are negative-going. For some other resolutions, they're positive-going.

Regarding the buffering, I don't think a 5K source impedance is adequate. The syncs, in the XOR case, should be buffered.

Regarding the shimmering, multiple cogs probably begin by syncing their video PLLs to a common pin and remain in sync from there on. The shimmering occurs when two, non-synchronized clock sources are used for combining image signals, i.e. the video PLL and the system clock.

-Phil

Rayman

Can't you just use a series of waitvid followed by outa modify commands to do the sync signals and thereby keep it to one cog?

Tubular

What about just changing the pin group to a different group of 8 (that contains the HS and VS pins) during the porch periods, and switching back to "active video" pins in time for the next scanline?

keep the same cog, PLLA etc, or does rewriting vcfg reset the plla?

Phil Pilgrim (PhiPi)

Rayman wrote:

Can't you just use a series of waitvid followed by outa modify commands to do the sync signals and thereby keep it to one cog?

No: outa is synchronized to the system clock; video outputs via waitvid are synchronized to the video PLL. You will get shimmering due to different timing mismatches on different scan lines.

Tubular wrote:

What about just changing the pin group to a different group of 8 (that contains the HS and VS pins) during the porch periods, and switching back to "active video" pins in time for the next scanline?

That's what I was referring to when I suggested changing vcfg. That register is not double-buffered to sync with waitvid, so every change to it is immediate. Changing it might restart the internal video counter. But I think it's the best hope for a steady image.

-Phil

Ariba

two other ideas:

1) use the I - bits and NAND gates to generate the sync signals. The I bits are synchronized to the pixel clock, so H and V will be also. Not sure if it is allowed to have a little voltage on R,G,B while the sync signales occure.


2) Only 128 colors and 8 gray levels. Then you can use the 8th bit for the H sync signal, which is the critical one. V sync is just another pin, not in the same VGA pin group. This would need only 3 additional resistors to the standard circuit.


Andy

Cluso99

Andy: I was trying to achieve the HS & VS using a single sot23 gate

If using two gates, then your option 1 seems likely to be the safest solution as shimmering should/would not be a problem here. However, because of feedback between the resistors, this may cause problems. So I will need to check this out, as I0 and I1 may need buffering/gating as well.

Tubular

What's nice about Andy's first solution is that it doesn't use any existing pins, and so could be a small plug inline adapter, to fit any existing vga design

Ariba

A bit improved:


This should be compatible to the existing VGA drivers if you don't connect the 9th pin (Sync Enable). If the Sync Enable is pulled low by a 9th Prop pin you can use I0 and I1 for 256 colors according Phils circuit.

Andy

Rayman

Neat idea Andy. This way uses one less pin and one less cog, but needs an external IC.

Cluso99

Here is a circuit I proposed quite some time ago. It saved 2 pins but I have to admit I never tried it.

SRLM

Ariba wrote: »

two other ideas:

1) use the I - bits and NAND gates to generate the sync signals. The I bits are synchronized to the pixel clock, so H and V will be also. Not sure if it is allowed to have a little voltage on R,G,B while the sync signales occure.

No, unfortunately it's not allowed. I ran into this problem when I wrote my VHDL VGA driver. You have to zero the colors while the VSYNC signal is returning to the top of the screen.

Phil Pilgrim (PhiPi)

Cody,

I can understand why blanking during VSYNC is desirable with a CRT display, since you don't want a visible retrace. But is it also necessary with an LCD?

-Phil

Cluso99

This should work provided the HS & VS is active low and the vfg does an inversion of the pins in software for HS & VS.
BTW Using 74LVC00 & 74LVC08

There would be a small amount of crosstalk between the R,G & B via the I bits and the resistors.

SRLM

Phil Pilgrim (PhiPi) wrote: »

Cody,

I can understand why blanking during VSYNC is desirable with a CRT display, since you don't want a visible retrace. But is it also necessary with an LCD?

-Phil

I tried it on an HP2509 LCD and some other LCD display, and both rejected the signal unless I set the RGB channels to 0. The displays would receive the signal (indicated by the backlight being on, and the display not going into sleep mode with the orange LED), but they wouldn't display an image. I don't know if all LCDs need it, but it took me two days of debugging to figure this one out.

I based most of my design off of this document from Digilent, page 15: www.digilentinc.com/Data/Products/NEXYS3/Nexys3_rm.pdf Note that nowhere does it mention anything about zeroing the RGB channels during syncs.

As a side note, I think writing a VGA driver in VHDL is one of the most rewarding classroom experiences for VHDL there is. It's a bunch of fun to take a million unmolded gates and to create something uniquely yours. Much more fun than making an adder or memory.

pik33

Phil Pilgrim (PhiPi) wrote: »

Another option would be RRGGBBII, where the two II pins are shared as LSBs for R, G, and B. The advantage is that you get 16 gray levels, in addition to colors in a wide range of saturations. Here's a spreadsheet that shows the circuit and the resulting palette. I've rotated the rows in the palette so that the grays line up in the left-hand column:



One possible glitch in this process is the generation of HSync and VSync. One thing I discovered when doing slides with a separate inset is that timing the overlay video with a system-clock offset from the video-generated syncs results in a shimmering effect as the pixels jiggle back and forth. The same would also be true for generating the syncs from the system clock, since it would not be synchronized to the video PLL. What might work is to switch vcfg back and forth between the color pins and the sync pins. This will restart the internal counters, but at least they'll be sync'd to the video PLL.

-Phil

Maybe something like this can be used for 8-bit Atari emulation....

Phil Pilgrim (PhiPi)

Cluso,

Your circuit won't work, I'm afraid. When /sync is high, P16..P17 affect both sync and color. When /sync is low, they affect neither. What is needed is a circuit like this (yours with an added NOT function):



The important thing is that with P16..P17 low, changing the SyncEn input does not change either the color or the sync outputs. That way, it can be applied asynchronously to the video PLL. The other thing that's important is that neither I-MSB nor I-LSB suffer more than one gate delay between input and output. And those gates have to be really fast, since one pixel time is less than 40 ns. To avoid skew, it may be necessary to buffer the RGB outputs with the same logic family as the gates.

-Phil

Toby Seckshund

"I can understand why blanking during VSYNC is desirable with a CRT display, since you don't want a visible retrace. But is it also necessary with an LCD?"

Most monitors will use the blanking period to do a "Black level clamping operation" so anything other than 0 Volts will confuse this.