washed out colors from VGA to HDMI

[DiTBho]

Teardown, here

Interesting note

The PCB is relatively sparsely populated with all of the work being done by a Macro Silicon MS9288A with a few linear voltage regulators used to provide the necessary voltages. The IC is clocked by a 24.576Mhz crystal.

U2 is unpopulated, and I suspect, it may be a position for the EDID EEPROM. Note that there are no ferrite beads on any of the HDMI differential pairs – so I suspect they have been omitted in the name of cost saving.

The underside is free of components with mostly a solid ground plane and a few traces. It seems they were also too lazy to clip off the crystal’s legs – by leaving them in the air, they may act as antennas and “radiate” – not a good idea. The PCB also has some flux-like deposits as if it wasn’t cleaned properly.

[DiTBho]

At times, the image does come up a little soft as it seems it hasn’t quite synched to the VGA signal properly in terms of phase.
[ .. ]
I also found that connecting the output from the converter into an HDMI splitter resulted in a purple bar appearing on the left side of the image. The cause is not known but may be related to signal timing. But using it with my Avermedia LiveGamer Portable was no problem provided the converter had synced.

This is also interesting, because the HDMI-grabber I am using is sensitive to synchronism 

[AndyBeez]

The PCB in that teardown looks like a clone-alike from the one Dave has in his original posting. The XTAL is the same frequency and Dave's one has the EEPROM - an Atmel 24C02N.

A thought from reading the user comments on that teardown; are the VGA grounds and the converter's ground connected? In CVBS video, a missing or floating ground causes weak colours and bad sync.

[DiTBho]

are the VGA grounds and the converter's ground connected? In CVBS video, a missing or floating ground causes weak colours and bad sync.

good point ... I need to check.

Today I spent the whole day on the capture-application, rewritten in C from scratch, because the original application crashed when the udp payload is zero (probably a bug), and when the packet length is wrong due to data-corruption.

Now it's more robust and doesn't crash 

[darkspr1te]

Back when i used to repair monitors and old skool video cards (vga based) we often saw that the output on the vga side would be too high (washed out and bright) or too low (dark and washed out) . depending on the card type it may or may not have a vga signal buffer that has failed or it's input voltage has failed, matrox cards often had this issue and you would see 3.8v on the buffer VIN pin instead of 5v , this would output 0.5v peak to peak on the buffer instead of 0.7v peak to peak.


darkspr1te

[DiTBho]

Back when i used to repair monitors and old skool video cards (vga based) we often saw that the output on the vga side would be too high (washed out and bright) or too low (dark and washed out) . depending on the card type it may or may not have a vga signal buffer that has failed or it's input voltage has failed, matrox cards often had this issue and you would see 3.8v on the buffer VIN pin instead of 5v , this would output 0.5v peak to peak on the buffer instead of 0.7v peak to peak.

That's interesting, I have a couple of projects based on

• PCI/32bit Matrox Millenium 1, 2MByte VRAM, VGA-single-head, MGA-v1
• PCI/32bit Matrox Millenium 2, 4MByte VRAM, VGA-single-head, MGA-v1
• PCI/32bit Matrox G450, 8MByte VRAM, VGA-dual-head, MGA-v2
• PCIexpress, Matrox G550 MGI G55-MDDE32F, 32Mbyte VRAM, DVI-D-single-head, MGA-v2

Were they on your bad-card list? 

G450 and G550 are more recent cards than Millennium cards, and looks better manufactured, but they are more annoying on the firmware side.

I spent two years reverse engineering a binary-only driver on Windows to understand the minimal set of things to do to correctly enable dual-channel output in order to prepare some patches for my PowerPC embedded board.

A lot troubles there, including bad setup of some registers that caused incorrect colors and weird behavior, that's because inside the MGA-v2 chip there is a programmable "Warp Engine" which theoretically enhances flexibility of the chip.

Unfortunately Matrox never described the functionality of this component in-depth, and there is no Linux driver that uses this functionality, it simply remains disabled.

Little is known about it, so ... enabling is like walking in the dark without a  portable flashlight, you risk tripping and falling into more troubles.


Anyway, I am not using any Matrox VGA card with that bloody vga2hdmi+hdmi-video-grabber, I will do it in the future, but not now, I don't want to combine problems

[DiTBho]

here a pic

[DiTBho]

here it is my "Philips PM5544"-like test card 
Designed with GIMP!

[darkspr1te]

Back when i used to repair monitors and old skool video cards (vga based) we often saw that the output on the vga side would be too high (washed out and bright) or too low (dark and washed out) . depending on the card type it may or may not have a vga signal buffer that has failed or it's input voltage has failed, matrox cards often had this issue and you would see 3.8v on the buffer VIN pin instead of 5v , this would output 0.5v peak to peak on the buffer instead of 0.7v peak to peak.

That's interesting, I have a couple of projects based on

• PCI/32bit Matrox Millenium 1, 2MByte VRAM, VGA-single-head, MGA-v1
• PCI/32bit Matrox Millenium 2, 4MByte VRAM, VGA-single-head, MGA-v1
• PCI/32bit Matrox G450, 8MByte VRAM, VGA-dual-head, MGA-v2
• PCIexpress, Matrox G550 MGI G55-MDDE32F, 32Mbyte VRAM, DVI-D-single-head, MGA-v2

Were they on your bad-card list? 

G450 and G550 are more recent cards than Millennium cards, and looks better manufactured, but they are more annoying on the firmware side.

I spent two years reverse engineering a binary-only driver on Windows to understand the minimal set of things to do to correctly enable dual-channel output in order to prepare some patches for my PowerPC embedded board.

A lot troubles there, including bad setup of some registers that caused incorrect colors and weird behavior, that's because inside the MGA-v2 chip there is a programmable "Warp Engine" which theoretically enhances flexibility of the chip.

Unfortunately Matrox never described the functionality of this component in-depth, and there is no Linux driver that uses this functionality, it simply remains disabled.

Little is known about it, so ... enabling is like walking in the dark without a  portable flashlight, you risk tripping and falling into more troubles.


Anyway, I am not using any Matrox VGA card with that bloody vga2hdmi+hdmi-video-grabber, I will do it in the future, but not now, I don't want to combine problems

It was mainly matrox Mystique cards in my dept, you may even remember the advert with the hidious clown offering the card to you, 
They used a st ramdac and buffer and both were fed from the same rail with a SMD cap that would crack in most cases causing almost but not direct shorts depending on temp or bend in the board.
Anyway, one trick i learned is biasing a channel , either to gnd or 1v rail with a pot and that would confirm a number of thing for us depending on what we saw on the crt , the crts we used were sony, illyama and kyrocira  we the first two having major saturation issues often on the input  side (the had caps on the RGB inputs which would leak and short to 1v rail) , the kyrocira units didnt have these filters and hence not affected by the signal out of spec and we often swapped them into the cabinets instead of the sony for pure ease despite the sony having the better image. 

Another item we had was a break out board for vga signals and injectors too, although i never found myself using the injectors (long setup time) over just grabbing our inhouse stocks computer and using it's vga output through the breakout and a scope to measure the h/v refresh, thats where we had some fun issues, either with drift in the the frequency or locking onto the signal due to improper hyrystisis on the input buffers which suffered from silicon rot on early models, this would duplicate the matrox ramdac failure model , same image issues which is why we always request monitor, card and PSU with the PSU having failing 5v rails which would kill the 1v/3.3v rails further in the chain again duplicating the original matrox failure mode exactly.

My point to the above rambling is that the input of the vga device can be very sensitive to the output of the driver/buffer/ramdac in either voltage P2P or voltage offset and these are values you can test & alter with ease, you can even use one channel to input to a svideo input with a simple resistor+cap signal combiner to confirm your systems output.

I never actually dug further into the cards software in those days, i wish i had now as our dept was well supported by matrox directly and we had manuals and sdk's laying around, no NDA to sign either. But alas i was a 68000+arm fanboy back then so it was still all amiga & Archimedes for me and had no interest in x86/PowerPC tech(unless it was SCSI  ) . 


One thing that might help you in your warp engine RE is matrox did a direct port of quake3 dos that did not run on other layers but direct to the card and was included with some models, it was shared a lot initially as it had no copy protection but ONLY worked with matrox cards with warp engine and that was made clear in the debug file that was included which everyone though would magically help them add opengl support, but alas only pointed to the matrox specific calls which replaced the opengl calls. Back then useless, now maybe not. 
 


darkspr1te

[Nominal Animal]

I decided to take a guess at how difficult would it be to create a circuit to adjust the levels.

Analog ADA4412-3 is an integrated triple video filter chip with about 36 MHz bandwidth, designed for 720p/1080i.  It has a fixed gain of 2x, so by attenuating its inputs, we can adjust the amplification.  It also has an output DC offset adjustment of ±0.5V.  It can use the +5V supply from the VGA connector, but to be able to get a negative DC offset, we also need a negative supply between -1V and -5V.

It is in stock at JLCPCB for assembly, as well as at lcsc.com, in QSOP-20, for about USD $3.20 apiece.

Here is my idea of an implementation (but do recall that I'm only a hobbyist, not an EE, and most members here could design a better schematic for this!):


On the host VGA side, pin 1 is connected to R, 2 to G, 3 to B, 6 to RGND, 7 to GGND, 8 to BGND; pin 9 provides +5V for V+.  Pin 10, ground for VSync and DDC, is used as GND (and implicitly on the right side as the ground for the ROUT, GOUT, and BOUT signals on the converter side VGA connector).  I do not know how to provide the -1V to -5V negative supply for V-, though; some kind of inverting circuit/regulator?  Also, the V+ and V- might use some filtering, just in case.

R1+R4, R2+R5, R3+R6 are the voltage dividers for the input signals, also providing 75 Ohm termination as required.  The wiper varies between 0.27× and 1.0× of the input voltage, so combined with the 2× gain in the chip, we can adjust the gain of each color component separately between 0.53 and 2.0.

R7 and R8 form the differential input pair to the output DC offset adjust; they're multiturn 10k pots.  (R8 could be eliminated, by connecting LEVEL2 directly to GND, but this way they're both ratiometric to V+ and V-, and thus should yield a stabler offset.)  Before soldering, they're both adjusted so that the wiper is about midway, ratiometrically the same for both.

[Nominal Animal]

On the other hand, using something like TI TVP7002 to digitize the VGA inputs directly, using say an ISSI IS61C256AL SRAM chip for mapping 15-bit color input into an 8-bit run-time defined palette, and something like an FPGA, FX2LP, or maybe even a Teensy 4.x to grab the (8-bit image) data, and to program the TVP7002.  (The SRAM address lines define the 15-bit color, and the data lines the 8-bit pixel value.  TVP7002 outputs are tristated when it is in reset, so a microcontroller connected to both (and the strobes) can quickly fill in the SRAM with an application-specific SRAM pattern.  One can even map to a 4-bit color table (16 colors), halving the bandwidth needed, for 16-color capture with custom palette!)

Could be an interesting project in itself, since 1024x768 @ 60Hz has a 65 MHz pixel clock, and produces 377,487,360 data bits per second at 8 bits per pixel, which might be doable over USB on a Teensy.  1024x768 @ 75Hz has a 79 MHz pixel clock, and produces 471,859,200 data bits per second; too much for high-speed USB.  But with 16 colors, 4 bits per pixel (or two pixels per byte), even that should work; an interesting option with Teensy 4 FlexIO (flexio_t4), since both 8bpp and 4bpp would simply be a run-time format selection...  The maximum clock rate of the IS61C256AL is over 80 MHz (12 ns), so it is just a matter of getting the digital logic right (and delaying the clock/strobe from the TVP7002 by about 12ns to trigger the DMA data read).

Interestingly, if one captures 16 bits per pixel (r5 g6 b5), then one can use UVC with the RGBP format (uncompressed pixels), and standard USB Video support suffices (using standard drivers and webcam software on a computer).   A single 1024x768 frame then needs 1.5 Mbytes (1,572,864 bytes), though, and the maximum frame rate via high-speed USB is somewhere between 25 and 30 frames per second.  (No such luck with the indexed color formats.)

[DiTBho]

In the meantime, I ordered the Startech professional VGA-HDMI, to be coupled with the HDMI grabber.
Interesting the color regulator, I will keep it in consideration if the Startech shouldn't be enough to fix the problem.

[DiTBho]

On the other hand, using something like TI TVP7002 to digitize the VGA inputs directly, using say an ISSI IS61C256AL SRAM chip for mapping 15-bit color input into an 8-bit run-time defined palette

That's similar to how old VGA grabbers operate 

I bought a few just to have a look at their hardware, one can be hacked, which is the reason for the topic about Golang to C conversion. There is no documentation except a source written by someone who tried to hack the grabber.

There is no audio, it only captures the VGA without any compression, which is good because having to deal with encryption, mjpeg or h264 is not easy.

Anyway, no-audio means I will have to think about an external circuit (audio-to-usb?) to capture and synchronize it with the video.

Not good, but it's a good starting point, and a useful piece of hardware to take a screenshot of a VGA screen.

Like I said, my "computer drug dealer" gave me some video grabbers. Some have a fast USB-bulk dedicated chip (~40Mbyte/sec), some Fast-Ethernet chip (~50Mbyte/sec), but if I were to build something I would prefer Ethernet over udp/ip.


So ... instead of Teensy, I would probably think about TI TVP7002 + static ram/pram + Xilinx-FPGA + parallel/32bit Fast-Ethernet chip


We will see ... just to give you priorities
- high priority: first I want to try to hack existing VGA and HDMI grabbers
- middle priority: C790 HDMI2CSI + RPI + I2S-hack (which can add Audio)
- low priority: custom solution

[m k]

Low priority:

One possibility is also a line buffer, or many.
Then the whole thing is in own hands and interpolation speed per CPU can be low.
Timing can be tricky though.

Analog interpolation is also possible.
Then even floating points wouldn't be a problem.
But perhaps a bit out of the scope.