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

Danik

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.

meleu

@Danik what's the gpio joystick names? (How are they showed in the jslist/joystick_selection tool?)

obsidianspider

@Danik said in Meet the "RetroG"!!:

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

I'm defintitely going to need to learn more Python. :)

Danik

@meleu Hopefully I'm going to put it back together tonight, so, I'll get back to you soon!

Danik

This is what it looks like, painted and all:

I'll try to make some time for more pics and maybe a video!

In the meantime I just discovered that I am using the Raspberry 0/1 version of RetroPie, while using a Raspberry 3. I have messed a lot with the configuration to make it work like this (recompiled a lot of stuff, too), so I was wandering, what is really different and what do I gain from moving to the RPi3 version as well as wether there is a way to "upgrade" without losing config files...?

obsidianspider

@Danik First, great job on the paint. It looks very nice.

I don't know of a way to update without losing your config files. Even when updating within the same Pi version, stuff gets overwritten with defaults. Maybe either make a full backup of the SD card you have, or just install RetroPie on a totally new SD card and then copy stuff over from the old one?

Danik

@obsidianspider Even so, what is really different with the other version? The Pi runs smoothly with the 0/1 version, so I was wondering what do I have to gain?

obsidianspider

@Danik I'm not sure of the differences, but here in America we have a saying, "If it ain't broke, don't fix it." So if everything is working and you're happy, I'd say stay with what you have.

Danik

@obsidianspider I am aware of the saying (a wise one, too), but if I was to gain a lot of performance boost (multicore optimizations?), maybe it is worth the extra effort. The problem with backing up the SD is that I still need access to the EXT3 partition, so I think the best option is to buy another SD card and work from there by rebooting with the old SD and getting files via FTP, then reboot with new SD and transfer again via FTP.