Hello!
I couldn't find any direct mention of this anywhere, so here I am. I've had this problem for a while, but have only recently narrowed it down to this. It turns out that an R4, specifically the "R4i Gold 3DS Plus," an r4ids.cn card, has nearly half the apparent read speeds of an original DS cartridge.
Below is a recording of scrolling through the bag in Pokémon White 2, one done on an R4, and the other on an authentic cartridge. I'm assuming that this is related to read speed due to the nature of having to load every item's image and description as the bag is scrolled through.
The MicroSD card I'm using in the R4 is a Sandisk Extreme that's rated at read speeds of up to 100MB/s. I have tried it on SD cards of varying speeds, capacities, and allocation sizes, and have gotten similar results.
I originally thought that it could be due to one of two things. One, that this was related to the R4 running in DS mode, as opposed to DSi mode with its higher CPU clock speed. And two, that it was due to limitations that are inherent of SD cards. These were both shown to be false when I tried running the game through TWiLightMenu++ and NDS-Bootstrap, which allow you to run DS games off an SD card. While running at the normal DS mode CPU clock, I was able to get the scrolling speeds of an original cartridge.
So, I'm curious about if this applies to all R4 models, or if it's less pronounced on others. I've attached the White 2 save file that I used in this test, and am hoping that someone can try the same scroll test on their R4 and post their results here.
Of course, these are just my own thoughts, and I'm not very knowledgeable about these subjects. I may be horribly wrong about all of this.
Almost every flashcart has this issue, there are actually a few reasons this happens, I will list them.
Reason #1:
Compare the quality of a flashcart to the quality of an actual game cartridge, if you have dealt with enough game cartridges and flashcarts in your life you are more than capable of telling and even feeling the differences. Flashcart hardware is usually cheap, the cheaper the hardware the cruddier the quality tends to be, that honestly applies to almost everything in the world, sometimes cheaper just won't cut it with the big dogs. There have been multiple flashcarts out there that were so damn cheap, some wouldn't last more than a month tops (I'd say the worst I have heard about was one lasting only a week). I am not saying all flashcarts are poorly made, there are some out there that have a decent build quality, the
R4i Gold 3DS Plus is a good example of one of many out there that actually isn't bad, compare that to the original R4 though and you will realize the quality differences there too (the original R4 uses a slightly thicker shell and overall feels much more sturdier than the current R4 models, in terms of performance I feel the original R4 is slighter faster). Some flashcarts like the SuperCard DSTWO, CycloDS, EDGE DS, EX4DS, etc had built in CPU's to increase the speed of DS games, homebrew, etc. (none of which exists anymore), regardless those still had their own flaws.
Reason #2:
The flashcart kernel is what allows you to view your games, homebrew, etc. These kernels carry out tons of compatibility and features for people to play with. However when there is features and compatibility, there is always some bugs/flaws. People tend to make the wrong assumptions when they encounter a problem in their games, blaming either the flashcart itself or in very few cases, the actual DS console itself (wrong 100% of the time). There is one thing people never think about though, the one question they never ask, how is the code handled under the hood? We all know coding allows these things to be possible, but people never question how optimized the code really is under the hood. Let's take a look at all these flashcart kernels out there for a second....We have M3, AKAIO, Wood R4, YSMenu, etc. each of which containing compatibility for certain games, each of which is different from each other in terms of performance, compatibility, etc. If you actually sit for a moment, you will realize that just about all of these kernels are pretty old, now realize that since these are all pretty old, they all use old coding knowledge versus what we know currently (yes even YSMenu, even if it is still updated the base of the kernel is still using old code). Some of these kernels were designed by Chinese developers as well, where as others were developed by other foreigners around the world, most of which were mostly closed source (some old open source kernels still exist on the internet), making it nearly impossible for the communities to improve anything to current standards.
Reason 3:
This sort of acts as an extension of Reason #2, but this is about support and the community. Flashcart kernels are supported by the developers, however the way they handle support is sort of questionable. These developers don't actually play through the whole game to see if it actually works the whole way through when launched via their kernel, instead they rely on the community to do the bulk dirty work for them. At this point people are reporting issues they encounter in whatever game they play, this sends the developers back to the drawing board to figure out solutions to the problem. Well, at least that is what is supposed to happen anyways, some occasions support is handled poorly. The developers themselves could be unprofessional and ignore peoples issues, use half assed methods to workaround the issue, or just all around be a prick to people (I know quite a few who were back in the day, it's hard to forget). The most important problem though is lack of communication, when there isn't good communication then new problems end up taking place, so bad that sometimes it could take place in the very thing people use. However it's not just a one sided issue, you see the developer isn't the only problem, the community itself is the problem as well. The community is like a mixed bag of jelly beans, the flavors vary, some good, some really bad. "Define good and define bad..", good members in the community are informative, they actually want to find out what causes the problem and give a good, detailed, report about the issue, they don't try to argue or start trouble, they communicate clearly with the developers and usually this results in a quick looking into and in some cases, a good fix right then and there. Even with the other communities members they are usually helpful and overall aren't hostile. Then you have what I like to call, the bad rotten apples, the dirty, smelly, sour apples nobody wants to deal with. These people have nothing better to do than to start trouble, they thrash at the developers and even other community members, it's inevitable. Fights break out, rumors are formed in some cases and even spread around (rumored bugs, glitches, etc included), you name it, it probably happened, they make a negative impact. Some people in general don't make good bug reports, they just say some small details and leave it at that, which makes it hard for the developers to understand what's wrong, even if the developer states how to submit bug reports, some people just don't seem to listen and end up doing their own thing. Some of those people do end up pissing the developers at times, causing them to potentially drop support for the project(s). It's a bag of mixed results that sort of spiral out of control eventually if you don't take the proper procedures. This is the internet though, shit is always weird here.
