[petrockblog]

There is a libretro core – it didn’t work before though. There have been some changes since then so im testing now and if it works, I’ll include it.

[petrockblog]

oldchocobo

Take it up with emulationstation – we are mostly following their naming scheme.

https://github.com/Aloshi/EmulationStation/blob/08c2c561ca34f185dacca7621ce0841e5503a4e3/es-app/src/PlatformId.cpp#L54

We can add a symlinked playstation folder if people really do get confused, but it is common to call the PlayStation “PSX”. No-one has got confused over this yet. If they had I’m sure you would be around to offer help in your usual manner.

“The PlayStation (officially abbreviated as PS and unofficially, but more commonly known as PSX or PS1) is a video game console developed and marketed by Sony Computer Entertainment”

http://en.wikipedia.org/wiki/PlayStation_%28console%29

Oh and you are right, I’ve not had much time for playing games – if I had, you wouldn’t have a v3.0 beta to moan about.

[petrockblog]

nothing that stands out, but I wasn’t expecting so many configs in that file – usually it would just be a few configs to override the defaults so i assume you must hve saved the configs out at some point to it – did you try stripping it back to just the “include” to see if that helps ?

have you also modified the all/retroarch.cfg file ?

I really think you should start from the beta image – and go from there. I don’t really have time to help further. sorry.

[petrockblog]

Then I will need to see some configs – use an external site like pastebin please.

[petrockblog]

in the pre launch menu (press x or m when you get the black screen before emulator loads)

[petrockblog]

that won’t matter – the only way to upgrade is the full binary install – but to be honest, I recommend backing up configs and starting from a fresh image. quicker to do it like that imho.

[petrockblog]

also – please post the contents of /opt/retropie/configs/fba/retroarch.cfg

[petrockblog]

trixter: when you say you updated all the emulators you use ? do you mean you did that from menu 5? that will not be sufficient if so – you need to do a full binary install.

[petrockblog]

sounds like your romset isn’t correct for mame4all ? but perhaps the config is not right.. check the mame.cfg – should be symlinks from /opt/retropie/emulators/mame4all/mame.cfg -> /home/pi/dists/retropie-rpi/opt/retropie/configs/mame-mame4all/mame.cfg and should have the correct rom path in it.

I can’t help more without actual logfiles etc and so on though. errors when launching are logged to /tmp/runcommand.log

[petrockblog]

if you do a new binary install of mupen64plus now it should be working again.

[petrockblog]

yeh – you need to move roms to the new locations if upgrading. see https://www.petrockblock.com/forums/topic/retropie-3-0-beta-overview/#post-92865 for the new rom folder list.

[petrockblog]

1) you need to move any roms to the new default folders and then delete the old folders. here is an updated rom folder list

amiga
amstradcpc
apple2
atari2600
atari5200
atari800
atarilynx
atarist
c64
fba
gamegear
gb
gba
gbc
genesis
intellivision
macintosh
mame-advmame
mame-mame4all
mastersystem
megadrive
msx
n64
neogeo
nes
pc
pcengine
ports
psx
quake3
scummvm
sega32x
segacd
sg-1000
snes
vectrex
zmachine
zxspectrum

2) a full binary install, and then enabling “usbromservice” (if you use it), and it should be enough.

[petrockblog]

the old mame folder used to be used for mame4all. you now have 2 folders.

mame-mame4all (can be switched between mame4all or libretro imame4all)
mame-advmame (can be switched between advancemame 0.94 and 1.2)

Can you be more specific regarding your issue. Are you saying the mame4all game launching is not working or ?

[petrockblog]

which mame ? mame4all/lr-imame4all or advancemame ? where have you put the rom files ?

[petrockblog]

I just made a minor change related to this, so make sure you have the latest retropie-setup and go from there. it should update the configurations without breaking anything, but take a backup to be sure.

[petrockblog]

you shouldn’t overwrite the retroarch.cfg’s – the updater will not delete any content from them, but it does add some important stuff, which you will have overwritten when copying yours back over.

[petrockblog]

Looks like when I built the binaries something went wrong. Will fix and get back to you.

[petrockblog]

Recalbox has some excellent features. However, there is no need to be rude to other users. If you don’t have anything helpful to say, perhaps you should say nothing?

[petrockblog]

I have written to the project and petRockBlock.

[petrockblog]

I’m somewhat confused as at the bottom they refer to licences and link to some licence for retropie that has nothing to do with retropie

(3) RetroPie © 2013 Frank (No last name given) View licence: https://github.com/solygen/dotfiles-RetroPie/blob/master/LICENSE

[petrockblog]

if you did a full binary install, when it says to hit x or m it will also say that errors are logged to /tmp/runcommand.log – so you can check that file. if it doesn’t say that, you haven’t updated.

[petrockblog]

after updating do a full binary install.

[petrockblog]

there were some recent changes – you need to have a retropie folder on the usb if you want the rom folders created.

[petrockblog]

you will need to do a full binary install, to a) get the latest runcommand b) update the emulators with their new configs, so they will be available to switch to when launching.

[petrockblog]

Does it work, when you use sudo raspi-config, choose “Advanced Options”, and enable I2C from there? Enable the ARM I2C interface from there and also enable the automatic loading of the I2C kernel module by default.

[petrockblog]

Some information regarding building from source:

Plenty of the emulators are not updated too often – and the source is a static archive – so there is no newer version from building from source.

building things like retroarch and some libretro cores will get you the very latest code, but also the very latest bugs too (was broken on the pi for a period recently).

The binaries are updated quite often.

:)

[petrockblog]

great job :) appreciated.

[petrockblog]

ok updating runcommand should fix it.

sudo ./retropie_packages.sh runcommand install

[petrockblog]

just had a quick play and think I have a fix that also solves the keyboard input on retroarch being echoed to the screen. Will get back shortly.

[petrockblog]

aah yeh that will be because it’s xml – can use

& lt ;

(removing the spaces – the forum is converting it so I can’t type it correctly)

maybe. assuming the value will be decoded correctly. alternatively it might be possible to adjust the runcommand script – I’ll have a test and see.

[petrockblog]

you can leave out runcommand also for this one.

[petrockblog]

try adding

 </dev/tty

to the end of the commandline.

[petrockblog]

One way to debug the GPIO ports is the following:

1. Set the gamepad type in the configuration file of the ControlBlock service to “arcade”. after changing the configuration you need to restart the ControlBlock service, e.g., with the command “sudo service controlblockservice restart”.
2. Connect a (jump) wire to one of the Ground terminals of the ControlBlock.
3. Use the tool”jstest” to test each of the GPIO pins. To test the pins on the player 1 side use the command “sudo jstest /dev/input/js0”. Use the wire to pull the pins to Ground one after another. Jstest should register this and show a state change for the corresponding button or axis. Pulling the pins to Ground with this configuration means for the ControlBlock driver in this configuration that a button was pressed. To exit the jstest tool press Ctrl-C. To test the pins on the player 2 side use the command “sudo jstest /dev/input/js1” and repeat the above procedure.

Can you observe these virtual button presses?

[petrockblog]

Ah, I see. I had the same problem. The rainbow in the top right corner means that the power that reaches the RPi is too weak: http://www.raspberrypi.org/forums/viewtopic.php?f=29&t=82373.
When I first encountered that problem myself, I did not think about this, because I did not have this problem without the ControlBlock. However, the power switch functionality of the ControlBlock leads to a tiny voltage drop which seems to just lead to a critical voltage when using certain combinations of power supplies and USB cables.
It took me some time to find that out. When I changed to a better USB cable (usually this means a thicker, bit more expensive one: more copper, less resistance), the problems vanished immediately.
So, before everything else: Change to another USB cable and/or power supply so that the rainbow does not appear in the top right of your screen.

[petrockblog]

P1 and P1 share the same Ground, so that is perfectly ok. My first guess is that the service „SNESDev“ is running in the background – it is the driver for the RetroPie GPIO Adapter and (unfortunately) uses some of the GPIO pins that the control block service is also using.
You can check if the service is installed with the command “service —status-all“.

So that might interfere with each other. You can uninstall the SNESDev service, e.g., either with the RetroPie-Setup Script, with the makefile that comes with the SNESDev-Rpi repository (https://github.com/petrockblog/SNESDev-RPi/blob/master/README.md#uninstalling-snesdev-service), or – if you are familiar with the command line and Linux – directly from the console.

[Author]

Posts