Meet the "RetroG"!! [Update 17/8: Paintjob Pics]

GreenHawk84

That thing is pretty crazy dude. Where did you get those shorty HDMI cables?

Danik

@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 ;)

silentq

The link to the picture seems to not be working? This looks interesting just want to see what it looks like.

Danik

@silentq Should be fixed by now, please refresh!

silentq

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?

Danik

Does this work for you?

https://postimg.org/gallery/1dj3dtlye/3dfe2d63/

EDIT: I meant refresh the forum page, not the (broken) link

silentq

That works thanks!

meleu

@Danik
That display is really cool! :-)
How do you get the system and the game name to display there?

Danik

@meleu

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

meleu

@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)

Danik

@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)

meleu

@Danik and you can send the "<0>" to the arduino using runcommand-onend.sh.

caver01

I love this project, especially how it integrates the little display. What a great use for the new "onstart"/"onend" updates to runcommand!

bizxaero

Awesome build!
Love that LCD-screen. Are there any guides for such a thing? (execute script in retropie / sending text to arduino).

Danik

@bizxaero

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? :)

bizxaero

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

meleu

@bizxaero don't forget the new features of runcommand.sh! It can help you a lot.
And, please, share your results with us. ;-)

Danik

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?)

obsidianspider

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.

Danik

@obsidianspider

It was a conscious choice. However, to make retroarch to listen to two ports simultaneously, it would take some effort. You could always use a hardware switch and read its state via a simple python script that reads the gpio pins it is connected to, then editing the appropriate config file.