[TriEmbed] RetroPie and MAME

Alex Davis alexd at matrixwide.com
Tue Dec 29 12:19:19 CST 2015

This may be a little off topic for embedded systems, but I bet there’s enough ‘old people’ like myself who remember arcade games, soo…

What I’ve been working on is a Pi2 with the RetroPie distro installed, along with an HDMI-component converter and an ‘old’ Sony Wega 480i TV (which has component inputs). The idea here is to get as close to the arcade CRT experience as possible without spending tons of money on an actual arcade CRT.

RetroPie is very handy as it is set up to boot straight to a simplified GUI meant to be controlled by an arcade stick/buttons or a game console controller. The somewhat tricky part was going through a windows-only process of processing a huge 50 GB ROM dump to weed out duplicates and broken sets to get down to about 2 GB of zipped ROMS. I have no idea what I ‘lost’ in the process, but it’s still over 2000 games.

The Sony TV was next to nothing off craigslist and is nearly the pinnacle of CRT consumer-grade TV technology. 640x480 text is clearly readable, convergence and focus is good, and geometry can be adjusted via a service menu.

The HDMI adapter worked fine under X using modeline "640x480i-2" 12.324 640 648 706 784 480 483 489 524 interlace -hsync -vsync but, using ‘hdmi_mode=6’ on the Pi, suffers from flagging at the top of the display. ( photos: http://imgur.com/a/0Bk5X ) I’m guessing some part of the video signal is a bit off from what the TV wants. There is the ability to use custom HDMI modes on the Pi, but the parameters are different from a standard X modeline, so I have no yet gotten it to work.

Alternatively, if the TV+adapter doesn’t work out, I have an HDMI-VGA converter plus a 17” multisync CRT display which will look arcade-ish when run at 640x480.

Finally, I have Trammell Hudson’s vector MAME project working. It is a patched version of MAME, a Teensy 3.1, some SPI DACs and level-shifting op-amps to get a full +/-5v signal range. This is fed into an analog scope in XY mode. Games work, but speed is very slow - I think because it still tries to write to the primary display while sending vectors to the Teensy. The Teensy handles drawing vectors from a table in RAM, so at least vector writing speed and therefore screen update is not affected by slowdowns on the computer side. I am hoping Mr. Hudson has some feedback once the holidays are over. This project could be demoed at the next meeting if there is interest. I’d also welcome any input or collaboration of taking it ‘to the next level’ once the bugs are worked out, which would be re-winding yokes on CRT monitors and supplying external deflection drive circuits, so games like Tempest and Star Wars could be played in full color.


|\ |  (¯  \/ |¯\  |V| |\ ¯|¯ |¯) | \/ | | | |¯\ (¯   /¯  /\ |V|
|-||_ (_  /\ |_/ @| | |-| |  | \ | /\ |^| | |_/ (_ . \_  \/ | |

More information about the TriEmbed mailing list