Meet the "RetroG"!! [Update 17/8: Paintjob Pics]
-
Hello everyone! I'm Stefanos from Greece and I just finished my project (just needs painting)!
It is a Raspberry Pi 3-Based console running Retropie with a few modifications.DISCLAIMER: Much (if not all) of what I have done might as well be absolutely wrong! I am in no way an expert, just a passionate hobbyist who likes to build stuff. Take everything you see here with a grain of salt or two! (Also, excuse my poor english :P )
Features:
-
Play NES,SNES,Atari 2600, Atari 7800, Master System, Genesis, Sega CD, Sega 32X, PSX* games with the original controllers (no modification required). This uses the DB9-GPIO-RPI driver for Atari/SMS and SEGA Genesis controllers. This driver is switchable (more on that later), depending on whether you want to use the genesis controller or anything else (2 button generic joystick). The NES and SNES systems use the ControlBlock SNES driver (the ports are wired in parallel, only one joystick per port works at a time - this means if you want to play SNES games you'll have to disconnect the NES controllers etc).
*The PSX games are playable with Bluetooth PS3 Controllers. There wasn't enough room for more ports, plus, let's face it: the controller hasn't changed much since then!
You can use the PS3 controller to play any other system such as turbografx, saturn etc, but the systems that have their own controller port listen only to that port. Two USBs are also present in the side panel for Wireless keyboard/mice and/or PS3 controller pairing/charging. -
360GB USB2 HDD (taken from an old WD Passport I had lying around) - this makes plenty of space for disc image-based emulators
-
5V System Fan (dropped using a 27R resistor to minimize noise - I know, it's not efficient, but I have a beefy 3,5A 5V PSU, so I'm less desperate for power than lazy :P The fan was used because PS1 emulation does get the Pi3 pretty hot and the HDD inside the case doesn't help either. Some holes were also drilled at the bottom of the case to help airflow.
-
The System Fan and the HDD are powered directly from the PSU to minimize load on the RPi.
-
Soft Power On and Power Off thanks to the amazing ControlBlock!
-
Relay switch to turn on/off USB HDD and system fan off upon shutdown and on upon power on.
-
2x16 OLED display with useful information and basic user feedback. This display's main task is to show during gameplay the system and rom name (eg. "NES - Contra"). The OLED display is driven by an arduino duemilanove (at first I needed to save GPIO pins and when I ordered the PowerBlock it was too late to go back). The display (arduino) is connected via USB with the RPi. I edited the runcommand script and made it export the rom path (eg. /home/pi/Retropie/roms/nes/contra.nes) to a single temporary file and then used python to read that file, truncate that string and then serially transmit to the system and the rom name to the Arduino. Arduino then prints said info on the screen, then handles scrolling if it doesn't fit. It's complicated, ugly and poor, but it does the job, so, there you go...
-
The front panel also utilizes two momentary buttons connected to the RPi GPIO header and handled by another ugly python script that reads them and emulates keypresses. Their use is multiple. Their behaviour is the following:
- hold the left button (a momentary press does nothing): reset the system (the emulated one, not the raspberry)
- hold the left button for longer: exit the emulator back to the main menu (in cased where a joypad with no select and start buttons is used (such as the atari ones or the genesis which lacks reset). after all, back in the days you had to get off your seat to change the cartridge, let alone a system!)
- press right button: pause the game in case of master system emulation (again, extra authenticity if you get off your seat to pause the game!)
- hold left button, then press right button (only applicable in EmulationStation, as opposed to during gameplay): switch the D-SUB9 controller ports mode between Atari/SMS (which does "modprobe db9_gpio_rpi map=2.2) and SEGA Genesis (which does "modprobe db9_gpio_rpi map=4,4). A visual feedback is displayed on the OLED screen (eg. "Controller Mode: Sega Genesis")
It is 100% hand crafted, the case was drilled by hand (I hope it's going to look better when I do the final filing before painting it). It uses the awesome pixel theme (props to @Rookervik ), has a simple custom animated boot logo and really feels like a console... Uses HDMI output with no bilinear filtering at 1080p. This retains a rather close-to-the-original pixel-to-pixel image, although of course it is not pixel-perfect in all systems. All systems use the dispmanx driver for less input lag. Overall, I'm very satisfied with the result, even though it is a bit of a hack rather than a properly written piece of software (again, I'm a hobbyist and far from expert!)
I also want to thank @petrockblog for this amazing project and @meleu for his precious help during the final steps of the controller configuration!
More photos will follow when I take it apart for painting explaining what I did more clearly and maybe a video sometime!
Cheers! -
-
That thing is pretty crazy dude. Where did you get those shorty HDMI cables?
-
@GreenHawk84 said in Meet the "RetroG"!!:
That thing is pretty crazy dude. Where did you get those shorty HDMI cables?
Thanks man! They're pretty common on eBay. If you search for "short HDMI", it'll come up with tons of options ;)
-
The link to the picture seems to not be working? This looks interesting just want to see what it looks like.
-
@silentq Should be fixed by now, please refresh!
-
Unfortunately no go with the link I just see https://s10.postimg.org/9fbis5otl/ .jpg and I get a 404 error when I click on it. Maybe go with imgur?
-
Does this work for you?
https://postimg.org/gallery/1dj3dtlye/3dfe2d63/
EDIT: I meant refresh the forum page, not the (broken) link
-
That works thanks!
-
@Danik
That display is really cool! :-)
How do you get the system and the game name to display there? -
When this whole thing started, I had in mind only 3-4 systems to emulate, so when I made the arduino (which is the OLED controller in reality) listen to the serial port for data I thought there was no need to transmit two lines or even that many bytes. So I thought of a system where "<" would start the string, followed by a number, followed by the rom title, followed by ">" which ends the string. Anything outside of "<>" is ignored by the arduino.
So if you sent serially to the arduino "<1Super Mario>", it displays "Nintendo NES" on the top row and "Super Mario" on the second one. 1=NES, 2=SNES etc. It's a little system that I wrote that is no more needed, but I'm too lazy to change, since it does its job. So, that's the arduino side of things.On the pi side of things:
I have edited runcommand.sh and made it echo $rom (if I remember correctly) - which is essentially the romfile path (for example "/home/pi/Retropie/roms/psx/Ridge Racer.cue") to the temporary file /tmp/rom. This file contains only one line (it gets deleted when you return to ES, thus its existence helps determine if you are on the menu or in a game for other functions such as the db9 driver switching). I then run a python script (still in runcommand.sh) which reads that file, truncates the whole "/home/pi/Retropie/roms/" so you end up with, say, "psx/Ridge Racer.cue". Then I truncate the last 4 characters of the string, leaving us with "psx/Ridge Racer". I then split the string using "/" as the delimiter, so I end up with two strings:
string_a = "psx"
string_b = "Ridge Racer"
Then, my (ugly) script does a series of equality checks:
It then decides which number corresponds to string_a. Eg. PSX = "7"
It then serially prints "<7Ridge Racer> to the Arduino, which, in turn, handles printing and scrolling the text.
When runcommand.sh exits a serial "<0>" is sent to the Arduino, which makes it restart, thus returning it to it's original state in which it just displays some text and waits for next serial input.Let me note that I had to do the resistor thingy to make Arduino not automatically restart everytime it is serially connected, since that happens everytime it is refreshed).
-
@Danik
Coool man! Very ingenious!Maybe you like to know that recently BuZz have implemented some cool features in runcommand that can make you get the info to feed your display more easily.
You can now write a customized script at
/opt/retropie/configs/all/runcommand-onstart.sh
and/opt/retropie/configs/all/runcommand-onend.sh
. They will be executed on start and on end of the runcommand.On
runcommand-onstart.sh
you can get the system (arg 1), the emulator (arg 2), the rom name (arg 3) and the command (arg 4).Here is the line where the
runcommand-onstart.sh
script is called:
https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/supplementary/runcommand/runcommand.sh#L768(we discussed this feature here: https://retropie.org.uk/forum/topic/2211/a-question-about-runcommand-sh/9)
-
@meleu
That's awesome! Maybe I could bypass the temp file altogether by passing arguments to the python script that writes to the lcd (if that's possible) -
@Danik and you can send the "<0>" to the arduino using
runcommand-onend.sh
. -
I love this project, especially how it integrates the little display. What a great use for the new "onstart"/"onend" updates to runcommand!
-
Awesome build!
Love that LCD-screen. Are there any guides for such a thing? (execute script in retropie / sending text to arduino). -
No, unfortunately I did it on my own. I could write a guide sometime soon, but right now unfortunately there isn't a lot of free time... May I remind you that the software "just barely works" and it's very ugly. Maybe even someone could make it (a hell of a lot) better, too? :)
-
@Danik
Ok, understand. Will try something similar for my arcade. I got inspired and ordered an arduino-kit after I saw your project. Will try it out when it arrives. Only just started with the woodworking though. -
@bizxaero don't forget the new features of
runcommand.sh
! It can help you a lot.
And, please, share your results with us. ;-) -
Today the Atari Controllers arrived! I needed to tweak my config files, but everything is done now! Tomorrow I'll take it apart to paint it.
I tried to handle the lcd screen using the runcommand-onstart/end.sh but, I couldn't pass the arguments correctly.
When I manually "python lcdwrite.py emulatorname romname" it works but in the script it doesn't work... Back to previous (working) scenario for now until I figure it out.EDIT: Something else that bothers me is that the driver switching for the DSUB9 ports isn't as stable as I'd like it to be. Sometimes, the machine hangs upon driver switch (the driver switch is merely a modprobe -r command followed by another modprobe command, with 1s delay between them (doesn't help), some other times it leads to kernel panic, most of the time it is working. But it is not implemented correctly, it is a python script that is called on rc.local using & to not wait for it to finish (so that it is constantly running its loop which waits for keypresses on the GPIO (the two buttons on the front panel I mention in the original post). Maybe I must do it as a service? Actually maybe instead of having lots of shell scripts and python scripts calling each other I could write it all in one python script that runs as a service (is that even possible?)
-
This is fantastic. I really love the display, and I'm definitely inspired to do something like it with my own build.
Do you have the system set up only to use Bluetooth for systems that don't have a dedicated port because of a technical limitation or was that a conscious choice? I'm working on putting a Pi in a Super Famicom (when it gets here) and I'm wondering how it will work if I wanted to use GPIO controller ports, or if I wanted to sometimes use a Bluetooth controller.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.