I did some more tests and I guess I found out what was causing this problem. After cloning the sd card everything works fine until I copy my rom's to the ssd. I just attached the ssd with the usb adapter to my Ubuntu machine and copied everything there to get faster speeds. But it seems that this method changes something in the filesystem that then causes all sorts of problems when booting from the ssd.

I now simply copied the sd card to the ssd again to get a fresh start and then copied everything with SFTP and now everything seems to be running fine.

@elvis said in Raspberry Pi OS 64bit version:

Definitely backs the choice of SDL without x11 as the preferred video output. Fairly similar upper bounds on each, despite no-video runs different by a scale of almost 3.

it's strange then the findings of @George in that thread - but maybe the retropie environment has an additional affect (again, we use a custom version of sdl)

Is there any comment on what future improvements to VC4/V3D drivers will bring to these speeds? Or are we seeing internal bandwidth limits here?

i would have thought the simple stuff like blitting to screen is about as good as it's ever going to be, but like i say, check out that thread - there may be a compounding issue for retropie. i'm currently building mame on my 64-bit x-less retropie install so will be able to test myself on some of these games. will be using ddp3 to try and recreate @George's findings.

(maybe we should continue this discussion there)

THANK YOU @dankcushions !

Your pointer was half of the solution so let me write the other half in case anyone else searches for this answer.

Setting the resolution in the retroarch Options menu did not have any effect until I also turned on "Alternate render method" in the same menu. At that point all resolution changes took immediate effect (upon leaving the retroarch UI) and now this all works perfectly.

I will write up the rest of my method to launch rom-less system soon!

Thanks again.

@dankcushions Thank you for the response. I was just asking as it has been five months and I wanted to make sure there wasn't an update that I had missed. I see improvements in emulation all the time. I can now run far more MAME games with lr-2016 and lr-mame than I could with previous generations emulators even on the same hardware so I don't think my question was that outlandish.

Thank you for the update, though.

@mitu ok thank you i kinda made it work more smooth but the only problem i would have will be the cam freezes and that is sad hahah

@jamrom2 Definitely. When the cable company upgraded to the 'slide' version, I played with it endlessly.slide box

@jgeibel @wossquee Not sure if you still care about this, but this is now possible by using the new retroarch core dosbox-pure. Just tested it out and now I'm able to get this pinball game working vertically on my cocktail table setup. Now to add 2 flipper buttons on the side so it plays like a real pinball table.

Also note that I had to change the IRQ setting to use IRQ 5 instead of IRQ 7 (the default) to get the sound effects to work.

That depends. First and foremost, it's a secure behaviour to only give yourself administrator rights (e.g. via sudo) when absolutely necessary. Also, if you happen to change the file's owner or permissions by accident in a way that the normal user can't access them anymore, it can cause further problems.

In short, by training yourself to use sudo only when necessary you avoid future problems and, at worst, security holes.

In your particular case, mere editing an existing file shouldn't make you any trouble, but if the file doesn't exist, you'll create it with the owner root instead of pi. Because a new file will be created with only write permissions for the owner, any application like an emulator that's run by pi wouldn't be able to write to this file afterwards.

Again, that may or may not be a problem depending on the file, but avoiding to use sudo will negate this uncertainty alltogether.

@muldjord

Just downloaded the script, is there anything you can see here that would mess things up?

#!/bin/bash

pushd /home/pi/
wget https://github.com/HoraceAndTheSpider/RetroPieAmigaSetup/archive/master.zip
unzip master.zip
rm master.zip
mv RetroPieAmigaSetup-master .retropie_amiga_setup
cd .retropie_amiga_setup
python3 amiga_setup_script.py
cd ..
rm -r .retropie_amiga_setup

cp /home/pi/RetroPie/BIOS/Amiga/kick13.rom /home/pi/RetroPie/roms/amiga-data/_BootWHD/Devs/Kickstarts/kick34005.A500
cp /home/pi/RetroPie/BIOS/Amiga/kick31.rom /home/pi/RetroPie/roms/amiga-data/_BootWHD/Devs/Kickstarts/kick40068.A1200
cp /home/pi/RetroPie/BIOS/Amiga/kick12.rom /home/pi/RetroPie/roms/amiga-data/_BootWHD/Devs/Kickstarts/kick33180.A500

popd

I have checked the cp entries and all the relevant rom files I extracted from the other image are in that folder anyway so I wouldn't think that part would be an issue..

UPDATE: Looking at that script and digging through I've found a RetroPieAmigaSetup-master.zip and a UAEConfigMaker-master.zip downloaded and scripts contained within were executed. I'll dig through those and see if there anything that has moved/re-routed something

@bilu just to say thanks. To date, I've been underwhelmed by the PI4 performance since I swapped from my pi3.

I've been struggling with all kinds of screen tearing issues, despite overclocking to 2.1ghz.

I borrowed this configuration and everything is now running buttery smooth.

Thanks for sharing.

Try editing /boot/config.txt with ignore_lcd=1
Then reboot. Your RPI should know show over HDMI instead of lcd

Ok apparently there is a compatibility issue with the display driver, because if I uncomment that the display doesn't work. They have drivers that are compatible with Retropie on the Rpi3 but not the Rpi4 yet. I guess I'll reach out to them and see if they have a solution

@mitu Thanks, I check those areas as I can't remember.

@wiuenright said in Are you having problems running Roms from SSD Pi4???? + Question:

Whenever I plug into the USB 3.0 it just writes non stop. I don't know what the problem is. Could it be the enclosure??? Is the lack of USB speed going to make a noticeable difference in gaming? Any ideas why this could be happening?

Try looking at the system's messages when you plug in the drive, by running dmesg -w (CTRL+C to interrupt) on the console and see if any errors are displayed.

Make sure you've updated your system (sudo apt update && sudo full-upgrade) to get the latest stable USB firmware and kernel/firmware release.

There's a sticky topic in the RPI forums here for troubleshooting problematic USB3 SSDs, you might want to take a look and see if your enclosure's USB SSD adapter could be one of the models reported with issues.

Next to mame2003, I can recommend its enhanced fork mame2003-plus and another arcade emulator called Final Burn Neo that is under ongoing development. But beware that every emulator needs its very own romset for the games to work, see Validating, Rebuilding, and Filtering Arcade ROMs.

@MrCoffee The RetroFlag Snes controllers are the best aftermarket wired Snes controllers i have tested.

@mitu I added:

hdmi_ignore_edid=0xa5000080

to the config.txt in the boot partition, just above

#config_hdmi_boost=4

on line #35.

That seems to do the trick. Excellent, thank you.

@mitu Awesome, thanks!

Welcome to this forum. Please provide more information about your setup:

all the information that's asked for in https://retropie.org.uk/forum/topic/3/read-this-first What do you mean by "not the same"? Are the control settings different or gone? Does the effect happen in Emulation Station (the frontend where you choose the games) and/or in the games themselves? What kind of "a few things" did you try?

edit: typo

@tsarevfs Hi, unfortunately, the PowerBlock does not provide this capability because it does not loop through the data lines of the USB connector.