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.

hummmmmmmmmmm got it, sorry to hear that =x thanks alot anyways for this amazing comunity and software!

@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.

@gorgar said in wanted any mini pc recomendations.: I love the pi and its form factor but I hate I always having to skip the majority of N64 and yes I am aware you can tweak and overclock but I don't want to :) but I have seen videos of people running retopie on their PC and the N64 stuff looks silky smooth so I wonder if anyone has any recommendations to get good performance on any of the new mini PCs and configurations that are out? Thinking of the NUC or anything similar perhaps an old alienware steam machine? Gigabyte Brix is another. But hell, why not just get a Nvidia Shield TV? It has the oomph to run all of those, plus runs retroarch. This might work as well: https://www.amazon.com/Beelink-Z83-V-Graphics-x5-Z8350-bluetooth/dp/B073DYLJG5/ref=sr_1_30?s=pc&ie=UTF8&qid=1509200109&sr=1-30&keywords=mini+pc

PAL will generally run at a slightly higher resolution at 50hz. NTSC runs at a slightly lower resolution at 60hz. A lot of the developers were lazy and/or rushed, and barely altered their NTSC titles to run on PAL systems, so you'll generally find the NTSC version to be superior. The black bars come from PAL having extra resolution that goes unused, and the slower speed is from them not bothering to adjust the game timings or logic and just having a game that formerly ran at 60hz run at 50hz, which is a 17% slowdown. (Sometimes they didn't even bother adjusting the tempo of the music to compensate!) The PAL version should be on par or superior for those titles in which the developers actually put in the effort, but I can't recall which those are off-hand. In the retroarch settings, you can also toggle whether games run at 50/60hz by hand in case that makes it run better.