Thanks again for doing this!

Looks like the binary has been created already @mitu. Installed and working like a charm. Thank you!

Okay, thanks - it could be possible, that I did a setting in RPi setup script by mistake. I played around with that - and maybe did not put it back later. This is a real good advice for my performance issue - thanks gpu_mem will be fixed, too. Thanks Edit: Oh holy man! This was the point. I thought it's only a booster for my slow graphics - but it fixed the installation issue! After that modification, I also got the possibility to install RetroArch by binaries (which was not shown before). Now the installation works. Thanks a lot.

Ah, so that was it, thanks! I tried to update it without removing the older version first.

@mitu - thanks for the reply. To answer your questions: Are you sure ? Do you have the latest RetroPie-Setup version installed ? Yep, absolutely. I downloaded the standard image from the site, deployed it, checked and it says 'installed from source'. I then updated the setup script and it stays the same. Manual installation will not install the package - it's installed explicitely on the Pi images. But, about the installation from source - are you looking at the same platform (Pi) when comparing the available options ? Yep, same platform (my Picade), Rpi 3. The buster image I used on this was from back in Jan and was from the weekly builds, so it was an image (not manual). I have two SD cards - one which is 'production' (which has been subsequently updated) originally deployed back in Jan with a buster weekly image - and another SD with a brand new image which I put on there yesterday to test. So am using exactly the same hardware and setup. In theory, the buster image back from Jan should have installed usbromservice as it wasn't a manual install. It also had the source files in the tmp/build folder, but the script was suggesting it wasn't installed. Perhaps I removed it but I don't think so. This isn't an issue though, as we are only really fussed with how the 'current' image behaves. To replicate the source install thing, all I need to do is deploy a fresh image (current is April 28, 2020, Pi 2/3 variant) and that's it (updating script post install doesn't change anything). You can then see in the package manager that usbromservice appears to be 'installed from source'. You can also click 'update from source' and it'll update. However, as I mentioned above, if you remove it, the install from source option goes away, and you can then only install via pre-compiled binary, which I assume is what it should be displaying in the first place. Yes, that's an oversight, should be fixed. Great, no worries! There are other modules that are binary only, but they're not packaged since there's no point in doing so (i.e. ports that install through .deb files or 3rd party emulatorts which supply binaries). It's normal. I see. Currently my picade is only running the main/core packages, nothing 3rd party nor any ports. I only mention because none of the other binary packages installed on the system display like this, they all say 'you are running the latest binary'. This one is the only exception in terms of showing the message 'Binary update may be available (Unable to check for this package)'. So I wanted to ask, just in case that was another bug of sorts.

If we run the game without the x session (using SDL 2) its possible to run the game in windowed mode and set a specific resolution in game. The performance increases greatly, however the mouse pointer no longer seems to line up properly with objects in the game. I think this is because the display resolution doesnt match the render resolution. So what I tried to do was run the game through runcommand so that a specific display resolution could be set. Only problem is that when I run the game through runcommand the game will no longer launch properly. I had the same issue with OpenRCT2. Running a simple shell script to launch the both games works but as soon as I pass it through runcommand I have issues and the game wont launch.

The way RetroPie manages this is by running an additional script after the input configuration phase - see here. The script then reads the es_temporaryinput.cfg file and generates auto-configuration for various emulators - see the script here. You can probably create a similar utility (in Delphi/Pascal) that parses the es_temporaryinput.cfg file and generates configurations for the emulators you need.

Sorry for the extreme late reply! In reference to my original issues, I got the controller issue fixed (Yay!) but my other problem remains in that I cant get Beavis and Butthead to load from the start. From my last post, I discovered that the game does in fact run properly IF I load a save file from it, however, I get booted back to the main EmulationStation screen if I try to start a game from the beginning. Here are the contents of my runcommand file: Parameters: Executing: bash /home/pi/RetroPie/roms/scummvm/+Start\ ScummVM.sh "bbvs-win" Using joystick: SWITCH CO.,LTD. USB Gamepad Virtual keyboard pack 'vkeybd_default' loaded successfully WARNING: No hardware input were defined, using defaults! User picked target 'bbvs-win' (gameid 'bbvs')... Looking for a plugin supporting this gameid... MTV's Beavis and Butt-head in Virtual Stupidity Starting 'Beavis and Butt-head in Virtual Stupidity' Using joystick: SWITCH CO.,LTD. USB Gamepad /home/pi/RetroPie/roms/scummvm/+Start ScummVM.sh: line 4: 1506 Aborted /opt/retropie/emulators/scummvm/bin/scummvm --fullscreen --joystick=0 --extrapath="/opt/retropie/emulators/scummvm/extra" $game When I try and start a new game and get booted back to the main screen, this line of text briefly shows up... *** Error in `/opt/retropie/emulators/scummvm/bin/scummvm': double free or corruption (out): 0x7ee9b2d0 *** Any ideas, thoughts or help would be greatly appreciated!

Such option doesn't exist right now, but you can use the auto-update just for the sections which always have binaries - i.e. excluding experimental. The experimental section recently started providing binaries, so that would work for most of them - my guess you have the extra repository enabled and those don't have binaries. If you open a package from the menu, it will detect if there is a binary update available and you can choose to update or not. Sure, it's just a workaround, but how many experimental packages do you have installed ?

@barbudreadmon Yeah, it was the principality of it, saving and loading game specific options in a global config. I think I could not get either the macros or cabinet settings to work this way, rendering them beyond completely pointless. I think the actual cabinet settings for the retroarch core are saved in /roms/neogeo/FBA/ along with high score, and I don't know what was up with the macros.

That seems to have worked @mitu , thanks. However, the script didn't want to update at first, I had to do a "git stash" beforehand as an error was thrown up over lots of updated files Playing again now though, so happy!

Hi there! I extract all the roms, configs, images, gamelists, themes, etc... and build a new sd card now with Stretch. Now, scraper work properly. You can close the thread. Thank you very much!

PS. BTW, the Debian install links from opensuse.org appear to be broken on the .sh script as there is only a folder for Debian 9.0 now - Debian 8.0 isn't there anymore.

It will likely require reworking of the RetroPie module script. It's still on my to-do list :-)

Modify the atari800 package script and replace the URL to download with your own URL to the new version. Make sure that it's not a 'redirect' or 'wait x seconds to download` and it's a direct link. After you replace the URL, use RetroPie-Setup to install from source the emulator.

@sub_atomic Press Ctrl+C, I think this will get you back.

Of course, that worked like a charm. Thank you for the support!

I know this topic is old, but I was having a problem with building this as well recently. Basically the same error. Resolution was to disconnect all controllers (I had 5 plus keyboard plugged in.) Confirmed this as the solution in my case, and adding it here in case others experience it.

This was unrelated to Stretch and has today been fixed in RetroPie-Setup.