@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

jamesaslett1985 created this issue in libretro/RetroArch open Overlays appear to be overly resource heavy #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/

@joabro One possibility: usually ROMs are either European or American, and these regions have different video systems compatible with the TVs of their respective markets. The former games are PAL 50Hz, meaning they refresh at 50fps. The later are NTSC 60Hz and refresh at 60fps, running slightly faster. So one possibility is that if you are from an European country and are loading a set of US ROMs, you may have this perception that it’s all a bit too fast (and they are, indeed, faster than you remember). If that’s the case, I’d say stick to them as this is how the games are meant to be played. People prefer US ROMs even in Europe, so much so that even Nintendo have loaded their European mini consoles with American versions of their games.

@morpie For what it's worth, I have a cocktail style cabinet and play most vertical games rotated by Retroarch (my setup has a three-sided control panel) and performance is great on those games. Actually, vertical orientation works great in other emulators as well. For example, Tempest in AdvanceMAME runs fine rotated to fill a vertical.

I still use Emulation Station as a front-end since this can be managed from the horizontal position on my system. However, I am using an LCD display upside-down (this is typically the best viewing angle for a table top cocktail design) and I need to rotate everything 180 degrees using config.txt. I don't believe my system pays much of a penalty for that, if any. But I did try running with 90 degree rotation at the system level and I can confirm that games definitely slow down.

So, from personal experience, if you can keep the operating system horizontal and let the emulators do the rotation for vertical games, you get the best performance. And if Attract Mode has the ability to rotate itself, well, that's the best vertical solution I have heard of on the Pi so far.

you need to start runcommand (pressing main button when starting the game) change your (Resolution/frequency) to any with 60 hz.

Yeah you can. Like the guy above says, if you use FBA you can set diagnostics mode in the Retroarch GUI and change a number of options using it, like turbo speed, demo sounds etc.

@mitu Alright, it's the lr-snes9x2010. Thanks for your help with that one.