Using Arcade Monitors With The Raspberry Pi

mame

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

    1. 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.

    2. 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.”

      1. 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.

  1. 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.

    1. 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:
      http://www.digitpress.com/forum/showthread.php?145551-Thinking-about-RGB-on-Genesis-instead-of-S-Video&p=1735217&viewfull=1#post1735217
      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.

  2. 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.

          1. 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.

    1. 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).

      1. 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.

  3. 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?

  4. 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…

Leave a Reply to DanAdamKOFCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.