Along with the growing popularity of the Raspberry Pi, we’ve also seen a related uptick in MAME arcade cabinet builds. Putting this $35 computer in an arcade cabinet makes a lot of sense, but connecting it to one of the monitors found in old arcade cabinets is a bit of a pain. Luckily, [Celso] figured out how to connect a Raspi to one of these 15kHz RGB monitors, making for a much more accurate emulation of old arcade classics.
The Raspi only has two video outputs – an HDMI port and an RCA composite jack. The old arcade CRTs have an RGB input, so directly connecting a Raspi to one of these CRTs is a no-go.
The solution comes from two converters: one to convert the HDMI output to VGA, and another video downscaler that takes the 31kHz VGA signal and translates it into a 15kHz RGB signal. [Celso] settled on the GBS-8100 video converter, a rather uncommon piece of kit that can fortunately be found on a few Chinese eBay auctions.
After connecting the old arcade cabinet power supply to the Pi, hooking up an audio amp, and converting the controls to USB, [Celso] has a very accurate MAME machine.
27 thoughts on “Using Arcade Monitors With The Raspberry Pi”
Good way to get a shitty arcade experience, because it will be latency from the downscalers.
Unnoticeable. It’s analog video, lag is close to zero.
no not until it reaches the VGA converter. has to buffer a frame, there’s no way around it.
1 frame of latency is not that big of a deal :)
Surely composite->RGB (both at the same resolution…) is much easier and cheaper? After all, it’s exactly what CRT TVs did…
I was thinking along similar lines. In fact, with the expense of arcade monitors, I figured you could just bolt up a CRT TV chassis into the arcade cabinet. You’d have some composite video noise, but it wouldn’t be much worse than the ringing/fringe-ing of older (70’s, early 80’s) arcade monitor RGB amp boards. Just my $0.02.
Because the composite is just that, the signal is composite of the RGB, meaning it’s too late to get the original R,G and B signals, they’ve been combined (or COMPOSITEd). Try reading the article:
“The problem with that is the Raspberry only outputs HDMI digital video or 15Khz composite video (no RGB), so there’s no easy / cheap solution to get pure 15Khz RGB signals out of the Pi to feed the arcade CRT.
You could try to demodulate the composite video into RGB signals but that’s complex and expensive, and you’d lose a lot of information, picture would be poor.”
No it wouldn’t. Picture would be no worse than analogue broadcast TV, in fact better since there’s no RF demodulation involved. For screens on the order of 320×200, it’s not going to make a big difference.
All TV sets up to a couple of years ago used to demodulate composite into RGB. Was fine. Aren’t there even chips that could do it? Or as people mentioned here, use a TV set with the case off.
yes the quality would be worse read this page http://retrorgb.com/rgbmonitors.html or at least have a look at some of the comparison pictures.
Accurate and USB aren’t usually mentioned in the same sentence either…
It’s also unfortunate that this is one of those “I bought some pre-built crap off the internet and hooked it all together” sort of post. The only mildly interesting part of this is the GBS-8100.
If he had built his own arcade controller off the raspi’s GPIOs, we may have something here. Or even something like an Uzebox for the pi.
I’m pretty lazy about this sort of thing though. I would rather stick an HDTV on the pi and run some scaling/smoothing in MAME so it looks good. Like Max said, he should have gone from composite to RGB in the first place.
A color TV *is* a composite->RGB converter. But composite->RGB won’t give you great results regardless of how you do it. Take a look at:
S-Video->RGB is much better (no “color burst”, but instead a dedicated Chroma), but the RPI doesn’t have S-Video outputs. So the only “decent” solution is to spend $17 on an HDMI->VGA converter and another $30 on a VGA->TV/RGB scan converter.
You wouldn’t need the scan converter if you could program the chipset to output a 15.7khz scanrate (as you can with many PC VGA cards), but no chance with HDMI.
The industry has adopted HDMI because of the DRM, not because of its flexibility. The few “features” of HDMI (mainly embedded multichannel audio) are hindered by HDCP. So ultimately, it’s a kinda useless format. The RPi (and others) should have included DVI with DVI-A and SPDIF for audio.
Now say “thank you” to Broadcom and praise Rasppi Binary blob!
If not for the blob you could just pump 15Khz signal over HDMI and use simple $20 HDMI-to-VGA converter.
VGA is really easy to get out of a BeagleBone. I wonder if the raster clock could be slowed down to 15kHz? If it could be done it would end up cheaper than the RasPi solution and have more horsepower behind it.
I just wrote about it one message above yours – it cant be done because GFX is handled in ze BLOB.
I don’t dislike this but the guy basically used off-the-shelf parts… as a longtime video geek I’m not a fan of the GBS scalers personally, they’re cheap, but not just in price.
Can’t the Pi video timings simply be changed through sysfs like on every other Linux distribution???
I haven’t had time to play with mine yet.
doesn’t matter since the signal types are incompatible, arcade monitors take 15khz RGB.
are you dense or something? they are incompatible BECAUSE OF video timings
“The Raspi only has two video outputs – an HDMI port and an RCA composite jack”
I’m all ears as to how fiddling with timings is going to tease 15khz RGB out of either of those.
What rasz said you clod – HDMI can output RGB so altering timings (having hardware control of all the signal pins) would allow you to generate the correct signal natively.
HDMI is entirely digital, I don’t understand how you think it outputs RGB. If you’re thinking of video cards that allow VGA to share pins on a DVI connector, that’s not the same thing.
If broadcom released register-level hw specs and open drivers, perhaps. But broadcom will never do that, ever.
HDMI isn’t exaclty DVI. One thing HDMI rigidly defines are the CEA/DMT video modes. They’re like VESA BIOS modes. There is no mode that defines a ~15khz clock. In PC/VGA land, you could program the PLL of some video cards and get to 15hkz, but not all. Another complication is the HDMI->VGA converter and how faithfully it can reproduce a dot clock it was never designed to generate (if you could generate it).
It is true that HDMI really tries to conform to CEA, but it is also DVI compliant for RGB and DVI does not have any restrictions on the format timings other than the upper and lower pixel clock rates.
Most HDMI sources, whether discrete or integrated, have a fully programmable timing generator and somewhat programmable pixel clock generator (depends on the device PLL and clock architecture)
If the HDMI timings can be configured for the desired timing then connecting the HDMI output to a DVI reveiver (e.g. TFP401A) then connect this to a video DAC (e.g. THS8135) then this would work and maintain full color integrity.
The key to all this though is does the Pi Linux distribution expose the hooks to change the HDMI output timings? I would expect that there are more than one mode currently supported but since I haven’t looked at my board in a while I can’t recall.
X11 supposedly allows modes to be changed/added through “xrandr” or /etc/XF86Config.
fbset might also allow the timings to be changed but I have seen both bad and good implementations of this.
Anybody look at the datasheet for the GBS-8100? What could this Engrish possibly mean: “Chip & Memory Don’t Demolition if not our Company” ??? lol
Maybe it means if you go with another company it will work, and that they sell you some cheap broken junk! :p
Even if you get a decent picture with minimal latency from all of that converting, you are still running a Pi, which is too puny to run the latest build of mame. The later the version of mame, the more accurate the emulation.
Also building a cabinet costs at least 300 bucks in lumber alone and finding an old one costs around the same. Why would you get cheap on the computer, the most crucial part of the whole rig?
And most important fact is that Pi does NOT output progressive 15 kHz even through its analogue video socket! Pi is simply not a good option for emulation with authentic CRT screen. It makes no sence to use Pi and then additional video encoders that are likely to cost good amount of money not to mention electricity and of cource all the space taken for what reason really…
Please be kind and respectful to help make the comments section excellent. (Comment Policy)