@rgrs You can set it up manually, but if it's not detected by Emulationstation it will not work in it. You can however set it up in RetroArch - https://retropie.org.uk/docs/RetroArch-Configuration/#autoconfigurations. Get the button values and add them to a .cfg file named after your controller - there's an example in the doc page.

Retried using Android mode on the controllers instead of Switch mode and everything seems to work fine. I'm going to go with that. Thanks!

@mitu OK thanks

Hi, I had a similar problem. It appears I have solved it by forcing the monitor to use HDMI input in the settings as opposed to autodetect. Hope this helps people encountering this issue in the future ;D
Cheers,
Tina^^

@Efriim

Thank you! This fixed it. Player 2 is not set up yet as I am waiting for the second dolphinbar to arrive from Amazon which is tomorrow :)

@gregyone yeah vertical is for player 2 spinner if you say had a 2 player cocktail. Or you just want both players to have separate controls.

Well the guys who make the OdroidRetroArena make a Retropie LIKE build for Odroid, which is close enough that you can use it without much trouble.

Resolved it by configuring retropie to boot to the command line and then i'll edit .bashrc to house the if logic to launch X or ES depending on TOD and of course

if [ "`tty`" = "/dev/tty1" ]

Was much easier than I was trying to make it...

##### # Set the hours between which PiClock will Launch #### minHour=6 maxHour=9 #Get Current Hour cHour=$(date +%H) # Get current time and time of boot. # calculate minutes since boot cSec=$(date +%s) sSec=$(date +%s -d "$(uptime -s)") uMin=$(( ($cSec - $sSec)/60 )) # Ensure that we are within 2 minutes of boot. This ensures that user can exit ES to the command line # without this script re-launching ES in an endless loop if [[ $uMin -le 2 ]]; then # Ensure this is tty1 if [[ "`tty`" = "/dev/tty1" ]]; then # If between min and max hour then startx and PiClock else execute autorun if [[ $cHour -ge $minHour && $cHour -lt $maxHour ]]; then startx else bash "/opt/retropie/configs/all/autorun.sh" fi fi fi

The issue I see is trying to drop to the command line from ES in which case I believe it will just launch back into ES... i'm ok with this. Maybe some other unintended consequences but I'll find out soon enough.

Edit: Added an additional If statement to check for minutes since boot so that one can successfully drop from ES to the CL without

@Sades160 in the end, everyone comes back to Retropie...

lr-mupen64plus-next is released. And it is good, you must try it and ignore my previous post. It is in the experimental section.

@BuZz I feel like an idiot. Thanks for the help

@2Play if you install windows 3.11 you need to choose /pcdos/ as the c: drive. Then do command “cd WINDOWS” Otherwise you will start installing all your windows games and software in the windows folder creating a huge disaster. There are a couple dos games you need to actually install the soundblaster drivers and set the c drive as /pcdos/ as well so it can find the soundblaster drivers folder. Personally i set my “pcdos” (i use a different name) folder as c: and “cd “game folder name”” on all games to avoid any conflicts.

I think I found the solution.
In mupen64plus.cfg you can find the overscan options.
Need some fiddling around with it but probably this is what I was searching for.

Though I don't know why the standard resolution (640x480) doesn't need overscan and higher resolutions need this to be able to fill the whole screen. Any one know why?

@mitu

Quick update.
Changing line 447 in /opt/retropie/emulators/mupen64plus/bin/mupen64plus.sh fixed my problem. I have changed pulse to alsa.

Further more I've created a simple script, named n64audio to run at start/boot.
In this script:

#!/bin/sh sed -i 's/pulse/alsa/g' /opt/retropie/emulators/mupen64plus/bin/mupen64plus.sh

Made the script executable sudo chmod +x n64audio
After that sudo crontab -e
And added the line @reboot /home/retropie/n64audio

Now after every reboot pulse will be changed to alsa in the file /opt/retropie/emulators/mupen64plus/bin/mupen64plus.sh , if the line pulse exists.

So if I update RetroPie and mupen64plus gets updated and overwrites my file (and put pulse back in to play) it will be overwritten on the next reboot.

Again, thanks for all your help!

@Armyguy31b01 https://www.libretro.com/index.php/goodbye-fbalpha-welcome-fbneo/

@DrFunkenstein said in Pi Zero Won't Boot Under Any Circumstances:

Another idea: Is there some way to check if the Zero itself is faulty?

Get another SD and see if things change with it. From the looks of it, sounds like a SD card problem.
If you manage to boot, run from the command line dmesg > log.txt and try to upload the resulting log.txt file to pastebin.com. That's the system log contents.

@rkoster Cool!

@fabricioavil For the dreamcast you can easily convert tracks to chd, this will save space and make one file fore every game. This link should help https://www.reddit.com/r/RetroPie/comments/72kh6q/stepbystep_guide_how_to_convert_sega_cd_or_pc/

As for scraping all the dos games, im not going to lie, it will be a pain in the rear. Shell scripts will scrape like any other rom. Many of the dos games on screenscraper.fr do have shell scripts associated with them; but CRC checksums will likely vary. I use Unversal XML, which will at least create an entry for every game, making it easier to fill in manually. Setting it to check by file name only will help, but it will have to match pretty close.

In my experience there has been no system that scraped pefectly, there is always a game being missed when it shouldn't, wrong box art, and so forth. So I have had to take a machete to every gamelist.xml (except for neogeo pocket). But it gives me something to do while the Lady of the House is watching America's Got Talent.

Good Luck

We have quite the setup guide here if anyone comes to this post looking: https://support.xgaming.com/solution/articles/5000554993-how-to-use-x-arcade-with-raspberry-pi