I installed weekly build retropie-bullseye-4.8.5-rpi3_zero2w (24-Mar-2024 05:10) and added it to config.txt:

dtoverlay=vc4-kms-v3d dtoverlay=vc4-kms-DPI-35inch dtoverlay=waveshare-35dpi-3b-4b dtoverlay=waveshare-35dpi-3b dtoverlay=waveshare-35dpi-4b dtoverlay=waveshare-35dpi dtoverlay=waveshare-touch-35dpi

And I got a normal FPS!

@Ashpool Ahh, thank you for this response. I will go down this path and see what I can get going.

Thank you for this!!

Sadly the symlinks didn't work- I found out the hard way.

Huzzah! After a little bit of grep and quite some trial-and-error, I found:

$ xinit -- vt1 -keeptty

(Side note: while this works, it uses a small corner of the screen. How to make this full screen?)

With that, I was able to use xinput list and list-prop and get the device name and properties unique to my setup. This led me to:

$ xinput set-prop 'USB Optical Mouse' 'libinput Accel Speed' -0.25

This immediately slows the on-screen pointer by roughly 25% (acceptable values seem to range -1.0 to 1.0, and default is 0.0).

Alternatively:

$ xinput set-prop 6 275 -0.25

...also works, if I were confident the device number won't ever change. I don't know what happens if I reboot, or plug/unplug additional devices etc., though, so I stick with using the name.

Now, starcraftr.sh:

#!/bin/bash xset -dpms s off s noblank xinput --set-prop 'USB Optical Mouse' 'libinput Accel Speed' -0.25 matchbox-window-manager -use_titlebar no & cd "/opt/retropie/ports/starcraft/data" && ./starcraft.sh

(The trailing & used in the example was not necessary)

This worked, but still a little fast and so I dropped it down again to -0.5. Now that feels more like what I'm used to.

Now, let's say I am a user who can't or don't want to alter the root-owned starcraftr.sh in the install folder. Or, maybe I just don't want to lose my custom setting to a reinstall. So I copy it into config dir at /opt/retropie/configs/ports/starcraft/starcraftr-slowmouse.sh, make the edits there, and then edit emulators.cfg like:

default = "starcraft-slowmouse" starcraft-slowmouse = "XINIT:/opt/retropie/configs/ports/starcraft/starcraftr-slowmouse.sh"

@mitu Thank You

Please add some info about your setup, as detailed in https://retropie.org.uk/forum/topic/3/read-this-first.

@frank-0 the original pi3b is slightly slower than the pi3b+ but on my older pi3b I managed to get the CP System III games working on fbneo. That emulator was built with the capcom games in mind I believe.

Also pro tip, of you're playing street fight 3 2nd impact play it in wide-screen! One of the few arcade games that has that ability natively.

Is it really running too fast or is the analog sensitifity just set too high, press tab to check the controls.

scratch that, it's been logged! https://github.com/libretro/RetroArch/issues/10688

Actually, scratch that. I see now the game is still running fast, no matter what. I have suggested myself by the fact that it actually is still quite playable and some minigames (hospital, top down ants) look normal. The rest, I thought maybe it's down to my NTSC TV. But after comparing it with a cycle-exact version on my PC it's definitely a bit faster.

So I've spent the whole evening yesterday trying to sort it out, to no avail. I've also remembered discussions about this subject here over a year ago: https://retropie.org.uk/forum/post/105234
Basically it boils down to RPi's Amiga emus lacking the cycle exact option. Some games require it, especially in WHDLoad versions. Barbarian is another good example. The "solution" was to run adfs of these games instead, but for ICFTD it does not work either. Bummer.

Unless it explicitly says otherwise C64 roms (and Amiga, Spectrum, CPC ... all the classic 'mostly' European home computer systems) are PAL and run at the correct speed and music pitch on an emulated PAL C64. The problem then becomes running a 50hz system against a fixed 60hz refresh rate LCD, causing jerky scrolling, which you solved by switching TV mode. 'Mostly' NTSC systems with NTSC romsets like SNES and Genesis need to run at 60hz though (otherwise it's jerky scrolling and wrong speed again, this time too slow), so there should be a way to dynamically switch refresh rate for each system. I'm working on it, but my bash scripting skills are low to non-existent :)

And yes, once you cross into 3D systems it's another ballgame completely.

@adiif1 said in Pi3+ low speed sdcard?:

Pi Model or other hardware: pi3+ A
Power Supply used: Huawei charger 5v 4A

Phone chargers do not supply enough stable current to power a Pi. You need to get a dedicated PSU designed for the Pi.

@throbinson said in RaspPi - Cooling and Speed:

No idea... ordered some 3M. No use pulling the sinks off now until I have something to reattach them with. :D

Whom did you answer with this? Just curious, because my question right before was meant for @jamrom2. 😉

@lurker that was the objective. not really how long the time is between a button clicked and received. but the delay time of the recorder in contrast to the button as GPIO. but if the delay time is so minuscule then you answered my question. its useless to compare. ty

A little update about this situation.

I've contacted my ISP and i can't seem to switch out the modem. They sent me some firmware updates, which also didn't help. The solution they offered me was, buying an external WiFi adapter or hookup a router to the modem. Both options are out of the question for me.

But now something I can't put my head around. As said previously most of times i get speed under 1 Mbit/s, but as soon I transfer files over to the pi by SFTP i get much better speeds (atleast 5 Mbit/s stable). This proves there is nothing wrong with the signal or antenna in my case.

A half related question :

While SD cards are awesome for size/weight/etc., how much of a speed advantage would using an external hdd be? I can't imagine an ssd adding any value over a simple 2.0/3.0 mechanical drive being that the transfer rate is bottlenecked by the shared usb 2.0 bus which apparently is divided up by the all ports and the sd card reader. Is a top of the line sd card just as good as an external hard drive or are there any advantages?

You probably were able to figure this one out since it has been quite some time, though just wanted to reply for anyone stumbling to this; the mixed up colors seem to be an artifact of the SPI bus bandwidth limitations of the ILI9486 controller chip on the display. If the display is driven too fast that the controller simply cannot handle it, the colors on the whole display can get distorted. There is no way around it.

My ILI9486 has maximum speed of 31.88MHz (31880000), and beyond that the colors get messed up. I posted a comment on the thread you linked to with more information about the observed limits of ILI9486 with a video. With fbcp-ili9341 project I was able to squeeze out some more performance from the ILI9486 compared to the dtoverlay method, but beyond simple retro games, it looks like ILI9486 is definitely not a display controller for fast paced games.

@greenhawk84 I fired up the Super Famicom and they say right around 60 fps. Things also don't seem as fast as I was remembering them last night. Unless anyone else says they've seen it, I'm going to chalk it up to me over analyzing things looking for bugs after I rebuilt that system or being really tired. ¯\(ツ)/¯

@matchaman

Being on a modern TV myself, I keep it disabled at a system level just for the NES, as (A) it's really the only system that needs that level of response time and (B) it isn't likely to have performance affected. I've even considered just setting it to off at an individual game level for the few titles that need that level of accuracy.

Pi4's Vulkan driver has been merged into the Mesa repo. https://www.raspberrypi.org/blog/vulkan-update-merged-to-mesa/