Ok, I've updated script and had success to install mame2013-plus.
This topic may be closed, thank you!

Just my findings:

commit 0343e3dbd8a22f64698e824e30b08e0887d77b6b
Author: retro-wertz retro-wertz@users.noreply.github.com
Date: Sun Mar 4 21:47:52 2018 +0800

Add missing variable to save state

This is the commit that breaks the loading of existing state files from old pi's.

And for anyone's future reference: here is the github issue regarding it: https://github.com/libretro/libretro-fceumm/issues/215

To get the scph1001.bin to work is simple. First you have to rename -> "SCPH1001.BIN" To all lower case and then rename the ".bin" Part to ".cue" that will change it to a .cue and still work as both parts....Or at least thats how I got Mine To Work. :P

Thanks for you reply. No, I don't get the undervoltage symbol. I'll upload the run command.log ( not at home )

I recently changed to RetroPie from RecalBox and didn't have this issue with the wired controller so its less likely to be issues with the power supply.

@GoldenSword This version of Emulationstation knows how to display videos, but in order to show them you have to

Add video tags for the games to the gamelist.xml file used by Emulationstation. This is usually done by a scraper - try Universal XML Scraper or Skraper. Use an Emulationstation theme that supports the video tag and configure the layout of the theme to video so that videos are shown. Most RetroPie included themes for Emulationstation support video - here is a list of them.

@rmigd it depends on the emulator, if not handled properly, size of savestates can be different between 32 and 64 bits. Most likely your android device is using arm64 retroarch while your rpi is using arm32 retroarch.

@TheSkyrish It seems this is a mobile geared device - for IOS and Android - so it might not be compatible. Looking over some reviews and specs, it seems to have a 'mode switch' between different conenction modes (Gamepad/Mouse/ICade ?).
Can you try switching between them, re-pair and see if it's detected as gamepad ?

@mitu Yes

@edmaul69 Can you get the system log file and put it on pastebin.com ? It would show us how the drives are detected. Run from a command line

dmesg > logfile.txt

then upload logfile.txt to pastebin.com.

I wasn't going to bring that up in this thread but since we went that direction...
I was actually planning my cabinet to have player one as one set of joystick/buttons off of Pi USB 1, player two as the second set off Pi USB 2, the dedicated buttons on the third controller on Pi USB 3, and then a hub stuck into Pi USB 4 which would tie (via extension cables) to two external USB ports on the cabinet, to which I could plug in a keyboard, or two SNES joypads or other types of joypads or joysticks. I was going to cross that "hot swappable/which is active/how do I program that" bridge when I came to it.

It sounds like, from above, it actually matters which of the 4 USB ports on the Pi I plug into? I figured they were all just addressed the same. Is that true? If so, I assume I plug a hub into USB 4 and those become 4, 5, 6, 7...?

To clarify what I'm actually doing...

I'm making a portable console like those ones you can buy online, which simply has a power cord and an HDMI cable and can be plugged into a TV anywhere. But my intent is to have the central portion of the panel have all the "hotkey default" dedicated buttons - save, load, exit, reset, etc. - and then have each of the two joy/button controller areas be small pull-out boxes with long cords, so the "base" can sit on the coffee table while the two controllers get passed between the kids sitting on the sectional sofa. I have plans in my head, and I'm using USB extension cables as the "pull out" cables (connecting the zero-delay boards to the Pi in the base).

But what this means is that I can't (at least easily) use the pin plugs on the zero-delay boards in each "remote controller" for the buttons which I want on the base. Each zero-delay board will be in the pull-out box, and the "hotkey" dedicated buttons will be several feet away in the base on the coffee table. The only way to have those "hotkey" buttons plugged into the boards which operate the joysticks and action buttons would be to do some wire dissecting and soldering, and I don't want to bother with that.

So my original question above was, can I use a third zero-delay board in the "base" which would only have those load-save-exit-reset-RGUI dedicated buttons, but NO actual controls tied to it? I suppose another way of looking at it is, can you "null" out all the hotkeys on player one and player two, and then null out all the directional/joystick/X/Y/A/B stuff on player 3 and still assign the hotkey commands?

I'm working up a sketch of what I'm imagining for more clarity and will post when done, if this isn't clear... or too long that you didn't read it... :)

@skykid said in Shaders not displaying properly, weird issue / CRT-PI etc.:

I have the backup of the retroarch.cfg I had before I replaced it with the dist version. To restore the console retroarch.cfg’s I should be able to pull them from a previous backup - but do I need to replace all the console files?

You can easily compare the versions you have on your backup with what you currently have installed.

The switching of the resolution between frontend and rom sounds like it was set prior in the runcommand, but I assure you it wasn’t! When I went in there today it was all totally vanilla. I never messed with anything in there before.

'in there' where ? How do you check it ? The video modes switch should be saved in the /etc/retropie/configs/all/videomodes.cfg file, you can also check there.

@mitu

Thanks so much for the help. I'll let you know how I make out.

yea the default isint a big deal it can be changed. It would be nice for me as well if the default was classic but someone else who only plays st2 may have a differing opinion. Sticks and stones at the end of the day :)

thank you. I did not change any video modes via run command. Not even sure how to do this? I know during emulation you can make changes but I can't see the options because the screen is so zoomed in I can only see the first few options. Same for changing emulators but I may be wrong with that as well.

I may need to switch emulators but I'm not 100% how to do this through the CLI / config menu's ATM. I'm going to take a stab at that too. Update: I was already using lr-fbalpha (NEOGEO), and tried switching to pifba but got a black screen no sound no nothing (so worse). Thinking I can update the emulator software and have better results? worth a try.

OK I tried editing the config.txt and it didn't make a difference in the menu or the emulation.

here is the current config.txt

# For more options and information see # http://rpf.io/configtxtreadme # Some settings may impact device functionality. See link above for details # uncomment if you get no picture on HDMI for a default "safe" mode hdmi_safe=1 # avoid warnings, 1 only remove overlay, 2 allos turbo avoid_warnings=2 # hide splash rainbow disable_splash=1 # uncomment this if your display has a black border of unused pixels visible # and your display can output without overscan disable_overscan=0 # uncomment the following to adjust overscan. Use positive numbers if console # goes off screen, and negative if there is too much border overscan_left=16 overscan_right=16 overscan_top=16 overscan_bottom=16 # uncomment to force a console size. By default it will be display's size minus # overscan. #framebuffer_width=1280 #framebuffer_height=1024 # uncomment if hdmi display is not detected and composite is being output #hdmi_force_hotplug=1 # uncomment to force a specific HDMI mode (this will force VGA). Now 720p is set (josete2k) #hdmi_group=2 #hdmi_mode=4 # uncomment to force a HDMI mode rather than DVI. This can make audio work in # DMT (computer monitor) modes #hdmi_drive=2 # uncomment to increase signal to HDMI, if you have interference, blanking, or # no display #config_hdmi_boost=4 # uncomment for composite PAL #sdtv_mode=2 #uncomment to overclock the arm. 700 MHz is the default. #arm_freq=800 # Uncomment some or all of these to enable the optional hardware interfaces #dtparam=i2c_arm=on #dtparam=i2s=on #dtparam=spi=on # Uncomment this to enable the lirc-rpi module #dtoverlay=lirc-rpi # Additional overlays and parameters are documented /boot/overlays/README # Enable audio (loads snd_bcm2835) dtparam=audio=on #gpu_mem_256=128 #gpu_mem_512=256 #gpu_mem_1024=256 #overscan_scale=1 # Overclocking (moderate) #dtparam=sd_overclock=100 #arm_freq=1300 #core_freq=500 #over_voltage=5 #sdram_freq=400 #gpu_freq=400 gpu_mem=256 #sdram_schmoo=0x02000020 #over_voltage_sdram_p=6 #over_voltage_sdram_i=4 #over_voltage_sdram_c=4 #v3d_freq=500 #h264_freq=333```

@slimbrick That's most likely some video codec that's not understood by omxplayer. It's also a common problem, there are a few topics on how to re-encode those videos to be compatible with omxplayer.

@Brigane Actually they didn't stop - there was an update in August (see this topic). There's hope that one day it might be open sourced.

It's enough to look in the /etc/emulationstaton/es_systems.cfg - that's where the folder/system mapping is kept.

@raymate Raspbian updates (systemd package) will disable the auto-login settings added by RetroPie. Login as user pi (password raspberry) and enable the auto-login to console from raspi-config - see here - then reboot to get back to automatically starting Emulationstation on boot.