@doctordruidphd said in [solved] Emulators won't start ubuntu 20.04 RPi4b:

Some things don't seem to be working -- the sega cd emulator just goes to a black screen

More likely you're missing the SegaCD BIOS - look it up in the docs.

Sources are downloaded and unpacked in $HOME/RetroPie-Setup/tmp/build.

@dankcushions Thanks, but I was curious what people are choosing for different packages and why. Like, I update lr-mesen from source, because of X.

@dankcushions I wasn't sure if it'd be worth the hassle of having to reset to head to be able to update again is all. if that's fairly trivial then I'll follow your instructions.

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.

@retropi19 in game there should be resolution settings. May have to set it to windowed mode or something too. I can't remember off the top of my head what the ideal settings are. When I have a chance I can boot up the game and see what settings I was using.

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.