• Please review our updated Terms and Rules here

CGA (digital) to VGA/Component/HDMI

For quality, the gglabs TTL to RGB DAC paired with the OSSC (with properly dialed in sampling and phase for pixel perfect results) is likely the one to beat. The OSSC allows for pass-thru of the original 240p signal if your monitor or capture card supports it or can scale the signal up to 5x resolution.
 
So i've actually been having this same telegram conversation with a couple friends of mine, and one of them pointed to this video he originally did using the GGLabs product and the Scart to HDMI box (which apparently I had forgotten about). It's still a pricey solution as well (luckily in my case I already have the SCART to HDMI piece since I needed it for my Atari ST), but of course those GGLabs products are always out of stock and apparently went up from $40 to $49 now which puts this entire solution up to about $80-100 after adding the converter, the box, and whatever cables you need. Kinda crazy you have to spend as much, if not more, then some of these computers are worth to just get them to output a display. :)

Anyway, heres the video...

https://www.youtube.com/watch?v=HpfrelhokKQ
 
I don't think I've seen that with mine. Can you help me see if I can duplicate what your seeing on my rig? Specific application? ASCII #17 ?

Sure, grab the CGA Compatibility Tester and just sit on the first Disclaimer screen; the background is drawn with ASCII 176:

jr8bpj.png


It's my understanding that the MCE scales everything to 480 lines, and leaves the 640- wide alone but provides 40 pixels of overscan on each side, making a 720x480 images, which would look like this:

fel3q9.png


If I'm wrong about these assumptions, please correct me. I am going off of screenshots I've seen plus the information at https://sites.google.com/site/tandycocoloco/mda-cga-ega-to-vga

You can also use the Monitor Calibration -> Moire pattern tests to see if scalers are introducing artifacts. The Moire (interference) test should produce screens where each line is the same size as every other line displayed, and each pixel is the same size as every other pixel displayed.

Are there any disadvantages to just adding a VGA card (that supports 8-bit ISA) and calling it a day?

The OP is using a PCjr which can't take a VGA card. But for other 808x-based PCs, it usually breaks down like this:

  • Pros: Can use modern monitors; can run programs that use VGA text features or VGA graphics
  • Cons: Lose 68-72KK of upper memory range that could be used by memory cards to provide UMBs (VGA uses A000-AFFF for video RAM and C000 or C800 for a 4K or 8K ROM); VGA graphics are extremely slow on 808x systems; some CGA-only games won't work properly; system no longer has "stock" or "authentic" look'n'feel

So, every user needs to weigh these when making their decision. For people who just want to run apps, a VGA card makes a lot of sense: The text is crisper, there are extended text modes, and the font can be changed. For people who have an 808x system to run old games, a VGA card can be more of a detriment than an advantage, as some CGA-only games that bang on the hardware won't work properly (or at all).
 
but of course those GGLabs products are always out of stock and apparently went up from $40 to $49 now which puts this entire solution up to...

As noted, if making your own is an option here is a complete open-source schematic for the equivalent of the GGlabs RGBI adapter. It only uses two generic 74-series logic chips and some resistors, there's no programmable logic or anything.

https://github.com/FozzTexx/SeaGeelog

I'm guessing it's well short of $5 in parts minus cables, sockets, and PCB.
 
As noted, if making your own is an option here is a complete open-source schematic for the equivalent of the GGlabs RGBI adapter. It only uses two generic 74-series logic chips and some resistors, there's no programmable logic or anything.

https://github.com/FozzTexx/SeaGeelog

I'm guessing it's well short of $5 in parts minus cables, sockets, and PCB.

neat! I'm gonna try one next time I order PCBs from JLCPCB
 
Sure, grab the CGA Compatibility Tester and just sit on the first Disclaimer screen; the background is drawn with ASCII 176:

jr8bpj.png


It's my understanding that the MCE scales everything to 480 lines, and leaves the 640- wide alone but provides 40 pixels of overscan on each side, making a 720x480 images, which would look like this:

fel3q9.png


If I'm wrong about these assumptions, please correct me. I am going off of screenshots I've seen plus the information at https://sites.google.com/site/tandycocoloco/mda-cga-ega-to-vga

You can also use the Monitor Calibration -> Moire pattern tests to see if scalers are introducing artifacts. The Moire (interference) test should produce screens where each line is the same size as every other line displayed, and each pixel is the same size as every other pixel displayed.



The OP is using a PCjr which can't take a VGA card. But for other 808x-based PCs, it usually breaks down like this:

  • Pros: Can use modern monitors; can run programs that use VGA text features or VGA graphics
  • Cons: Lose 68-72KK of upper memory range that could be used by memory cards to provide UMBs (VGA uses A000-AFFF for video RAM and C000 or C800 for a 4K or 8K ROM); VGA graphics are extremely slow on 808x systems; some CGA-only games won't work properly; system no longer has "stock" or "authentic" look'n'feel

So, every user needs to weigh these when making their decision. For people who just want to run apps, a VGA card makes a lot of sense: The text is crisper, there are extended text modes, and the font can be changed. For people who have an 808x system to run old games, a VGA card can be more of a detriment than an advantage, as some CGA-only games that bang on the hardware won't work properly (or at all).

@Trixter
OK, I ran cga_comp. That looks just like the background that Norton Utilities used. Now I remember fussing with the firmware on my MCE2VGA Converter to make it look better. Mine looks nearly as good as your first image but the dots are larger. I think if the latest firmware is used without any tweaking it looks more like the second image. Also, Flat Panel Monitors vary in their ability to "Auto Adjust" to center the image and set the pixel clock and phase. At any rate, text on mine looks very good, especially with the "scan lines" turned off.

Greg
 
In all fairness screens like that also look a little weird on MDA and VGA cards, granted for different reasons. (The pinstripe effect caused by the 9th-column doubling on the graphics characters always sort of bugged me. This might be a muddled memory but I would swear that back in the day there were a few "text-cli" programs that had a command-line switch to use a seamless EGA-resolution text mode on VGA instead?)

With the MCE2VGA presumably this same dot-pattern disruption issue would affect any graphical program that does halftones like that. (Which would basically describe any 640x200 CGA graphics program.) That might be annoying but possibly really difficult to work around unless you're using a scaler that can massively oversample onto a very high-res LCD/or use an LCD that can "letterbox" a dot-perfect rendering of a lower resolution mode into the middle of a higher resolution panel.
 
I am resurrecting this thread a little over a year later to see if there are any updates from people trying these various options. I am looking to do something similar and I have found what seems like three good quality options (so not the Chinese GBS8XXX boards).

1. MCE2VGA $100 (with the FPGA) https://www.serdashop.com/MCE2VGA
Pros: Supports most of the digital RGB formats
Cons: No HDMI

2. OSSC $125 https://videogameperfection.com/products/open-source-scan-converter
Pros: HDMI Output
Cons: Doesn't support digital RGB (CGA etc) directly so you need a converter

3. GGLABS $49 https://ebay.us/shLXmn + SCART HDMI $27 https://ebay.us/dNGzLY
Pros: Could support additional input types through the SCART and onboard SOC
Cons: Lots of custom wiring

How do these compare in terms of quality? Any updates from the past year or so?

I already have a SCART to HDMI box and I can solder my own RGB digital to analog board, so I am strongly considering option 3.
 
#2 + #3 is the best quality output (gglabs does a good conversion, but no scan doubling, so the OSSC does the scan doubling), but costs more. MCE2VGA is a plug'n'play version that works with most typical usage for connecting VGA monitors, but the output is scaled. So it depends on what you want to do.
 
if you intend to use the setup for capture it doesn't matter, but for gameplay be aware that the MCE2VGA adds lag
 
I don't own one so I can't measure it, but due to integral framebuffer design, we can safely assume a minimum of 16ms
 
Did you ever try to make/build this? It seems awefully simple to be effective, but no idea?

It is simple, but remember, it's only the "DAC" to convert RGBI output into the Analog format that's more directly compatible with most scalers. It actually doesn't take any more than resistors to make one if you don't care about the "dark yellow/brown" problem. You still need a scan converter (GBS-8200, RGB SCART to VGA/HDMI, OSSC, whatever) to finish the job.

What had seemed like the "healthier" of my two Commodore 1084 monitors made a sad "pffft" sound last week and died in the middle of using it, so I'm finding myself increasingly the position of needing to get serious about finding some kind of video conversion solution. I've been thinking very seriously of trying out Hoglet67's RGBtoHDMI converter, which is a combination of software running on a Raspberry Pi zero and a CPLD to help massage the timing issues with capturing that fast of a bitrate. It looks pretty good and might not cost *much* more than a GPS-8200 and a DIY digital-to-analog DAC, but if lag is really an issue to you I'm sure the latency is at *least* a frame.

While I'm still mulling over the Raspberry Pi thing I've been thinking of doing a DAC based on a programmed GAL chip to try with the GBS-8200 I already have. I just need to get my hands on the correct resistors, and the result should give me the same brown fix with one chip instead of three.
 
It is simple, but remember, it's only the "DAC" to convert RGBI output into the Analog format that's more directly compatible with most scalers. It actually doesn't take any more than resistors to make one if you don't care about the "dark yellow/brown" problem. You still need a scan converter (GBS-8200, RGB SCART to VGA/HDMI, OSSC, whatever) to finish the job.

What had seemed like the "healthier" of my two Commodore 1084 monitors made a sad "pffft" sound last week and died in the middle of using it, so I'm finding myself increasingly the position of needing to get serious about finding some kind of video conversion solution. I've been thinking very seriously of trying out Hoglet67's RGBtoHDMI converter, which is a combination of software running on a Raspberry Pi zero and a CPLD to help massage the timing issues with capturing that fast of a bitrate. It looks pretty good and might not cost *much* more than a GPS-8200 and a DIY digital-to-analog DAC, but if lag is really an issue to you I'm sure the latency is at *least* a frame.

While I'm still mulling over the Raspberry Pi thing I've been thinking of doing a DAC based on a programmed GAL chip to try with the GBS-8200 I already have. I just need to get my hands on the correct resistors, and the result should give me the same brown fix with one chip instead of three.

Yes, I have a scan converter (RGB Scart) already, I was just curious if he built this particular implementation and if so, if it worked very well (things like timings and brown fix being the usual issues, as you noted). I was looking into the many variations with my friend (Adrian from ADB) and we kinda played with one board but it needed parts that were impossible to find so that was a wash (including finding the correct resistors which mostly means you need close resistors and some trimmer pots for tweaking) . He was also going to look at doing a programmed GAL and started to make up a board but got sidetracked on other projects.

So besides the SCART, I do have one of those GBS boards and honestly they really are crap. Adrian did some tests using the CGA2RGB with both the Scart box and the GBS and the GBS was almost unusable. I'm currently using the Scart box with my Atari ST and the appropriate cable and i'm pretty happy with the output. My 'gaming' is limited to things like Ultima, so i don't really know about timings and such.

As for the CPLD ones, I personally would rather something that was a little simpler to build which is why i prefer the GAL option and mostly through-hole design, if at all possible, so that regular folks can build it if they are so inclined.
 
Hoglet67's RGBtoHDMI converter, which is a combination of software running on a Raspberry Pi zero and a CPLD to help massage the timing issues with capturing that fast of a bitrate. It looks pretty good and might not cost *much* more than a GPS-8200 and a DIY digital-to-analog DAC, but if lag is really an issue to you I'm sure the latency is at *least* a frame.

Thanks!!! I was not aware of this option and it looks very doable. I am adding this as a fourth option to my list. :)
 
What had seemed like the "healthier" of my two Commodore 1084 monitors made a sad "pffft" sound last week and died in the middle of using it, so I'm finding myself increasingly the position of needing to get serious about finding some kind of video conversion solution. I've been thinking very seriously of trying out Hoglet67's RGBtoHDMI converter, which is a combination of software running on a Raspberry Pi zero and a CPLD to help massage the timing issues with capturing that fast of a bitrate. It looks pretty good and might not cost *much* more than a GPS-8200 and a DIY digital-to-analog DAC, but if lag is really an issue to you I'm sure the latency is at *least* a frame.

I'm getting ready to consolidate monitors, too. I mean, I love using the "correct" monitor for a particular machine, but they just take up too much space. I want to be able to stack all my boxen in a pile and just use one monitor with all of them, as well as one keyboard/mouse when possible.

My idea, assuming it doesn't result it too much signal loss through all the cabling, is to feed everything into a multisync VGA CRT. To that will be attached a VGA/PS2 KVM switch. One of its input ports will be plugged into a composite/svideo-to-VGA converter, which itself will be plugged into a composite/svideo switch box. Another input of the KVM switch will be plugged into a GBS8200, whose input will be plugged into *another* KVM switch, for all the 15KHz analog RGB boxen. One of the inputs to that second switch will have a circuit on it to convert TTL RGB to analog RGB, which will be plugged into a 9-pin serial A/B/C/D switch with some connectors swapped to the right gender. The original VGA/PS2 KVM switch will then plug into a VGA/USB KVM switch, with PS2-USB converters between them for the mouse and keyboard. That one will feed the more modern boxen that don't do PS2 (mostly rPi boxen, but also my video rendering machine once I finish consolidating all my garbage in the new workshop).

I'm also going to try to use an svideo a/b switch to switch one adb keyboard/mouse between the Mac IIci and the Apple IIgs, if I can figure out how to do it without eventually frying the noise-reduction coils on the ADB ports. It might just be as easy as an anti-spike diode soldered into the a/b switch, but I haven't looked into it yet.

Phew, that was a mouthful. :p

If I get too much signal degradation out at the end of the three KVM switches, I'll start shortening VGA cables and clamping more ferrite beads on. Hopefully that will make everything happy............. But I am still waiting for one package before I try to put this plan into effect. =:3

PS: Even though everyone and the entire rest of their family makes Commodore Repair Videos on Teh Youtoobs, it would be an interesting project to film. What do you think is wrong with it? I have a Daewoo one that I need to fix the audio amp in, but I've been putting it off because I don't want to make Yet Another Commodore Video, heh.
 
Last edited:
Yes, I have a scan converter (RGB Scart) already, I was just curious if he built this particular implementation and if so, if it worked very well (things like timings and brown fix being the usual issues, as you noted). I was looking into the many variations with my friend (Adrian from ADB) and we kinda played with one board but it needed parts that were impossible to find so that was a wash (including finding the correct resistors which mostly means you need close resistors and some trimmer pots for tweaking) . He was also going to look at doing a programmed GAL and started to make up a board but got sidetracked on other projects.

I can't imagine "timing" being something that would affected by any of these DAC board designs, although there may be some black magic in the separate-to-composite sync circuitry in those that handle that. There is a lot of variation in how the actual RGB conversion is handled, which broadly split into "Diodes! Lots of Diodes!" and "Diodes? Why?" camps...

For laughs I just sat down to try to take a crack at GAL code for the equivalent of the SeeGeeLog converter linked earlier. In the process I also found the schematic to the three different generations there's been of the GGLabs board, and to broadly summarize the difference:

1: The GGLABs board sets the GAL up as an according-to-hoyle 6-bit DAC with two intensities of each color; the "intense" resistor is about twice the value as the "base" resistor; the programming of the GAL simply sets which 16 color subset of the 64 possible colors are used, which is how the "brown fix" is implemented. The SeeGeeLog one, on the other hand, had me scratching my head for a while in terms of how it uses the 74LS138, but after working out a truth table for it it looks like it uses a weird "pull down" arrangement to reduce the voltage on "G" under the one specific circumstance.

Frankly after looking at it if you have a GAL I'm inclined to say the GGLABS arrangement makes more sense, it actually requires fewer parts and is easier to grok. The only downside is it doesn't let you "tweak" the brown-ness. You essentially get a "brown" from the EGA palette, which I'm not sure *quite* matches CGA brown... but it also almost certainly hardly matters.

2: The later versions of the GGLABs board use a proper op-amp to provide the final drive of the analog pins with 75ohm impedance matching. If there's a solid quality difference between the current version of the CGA2RGB and a homebuilt one this may well be where it's coming from.

Something I'm not super clear on is why the *first* version the CGA2RGB, which doesn't have a proper op-amp, uses a 74AC541 line driver between its GAL16v8 and the resistor ladders. According to the datasheet the AC541 has an output source/sink of 24mA; the GAL20v8 datasheet I have handy claims it has a drive current of up to 64mA, so... not sure why they used it.

I think I'm tempted to basically build a GGLabs rev 1 without the '541 on a breadboard and see what I get. Worst case I'll blow up a $1.50 GAL, I guess.

So besides the SCART, I do have one of those GBS boards and honestly they really are crap. Adrian did some tests using the CGA2RGB with both the Scart box and the GBS and the GBS was almost unusable. I'm currently using the Scart box with my Atari ST and the appropriate cable and i'm pretty happy with the output. My 'gaming' is limited to things like Ultima, so i don't really know about timings and such.

I have a GBS lying around that I haven't tried yet so I'm thinking there's nothing to lose, but it won't surprise me if it's too terrible to bother with; the GBS is currently configured to work with an Apple IIgs and I sure can't say it does a great job there.

As for the CPLD ones, I personally would rather something that was a little simpler to build which is why i prefer the GAL option and mostly through-hole design, if at all possible, so that regular folks can build it if they are so inclined.

One potentially neat thing about the Raspberry Pi-powered dingus is *maaaybe* it might end up being possible to do capture with it.

I mentioned op-amps above, one thing that I think might be interesting if it turns out they really are necessary to get decent quality out of the first stage conversion is there are some schematics out there for doing RGB->YPbBr color space conversion using some fairly cheap video op-amps. (Which unfortunately only seem to come in surface mount packages). Those RGB-capable SCART converters are sort of hard to find; what might be a preferable strategy, at least for those in non-SCART-using regions, would be to make something like the GGLabs board but with built in component video conversion. Component to HDMI converters are only about $20 and I'd assume they probably have the effectively same guts as the SCART models, and it would also enable direct-plug to TVs and monitors that'll take component video. Component is starting to die out but it was common on TV LCDs until pretty recently.
 
Last edited:
Back
Top