Well, to put things in perspective, the engine I'm using for Stargazer, WITHOUT using the blitter, achieves over 115 FPS performing far more graphical processing work than any other homebrew title using SDL I've seen-- this is with an OGG Vorbis audio file being played at the same time as the game runs. Will things be faster if written from the ground up in ASM or working with the hardware on a memory-address basis? Yes. Is SDL slow? By no means.
ASM-- I never said an emulator with a C core should be fast! They generally are not. C-based CPU Cores are notorious for being slow, and their only advantage is crossplatform compatibility with just a recompile. Of course, an ARM9 ASM 68000 core like Cyclone is lightyears beyond a C-based one, same goes for DrZ80 and others.
Linux-- not sure where this bit about the GP32 running emulators faster at lower clockrates THAT dramatic comes from. Now, you say the GP32 overclocked to 166 MHz outperforms 'the GP2x overclocked'-- the average overclocked speed people use on the GP2X is 266 MHz. I've not seen one emulator whose GP32 iteration ran faster given that skew of clockrate and the same CPU architecture, just because of the operating system sitting between the hardware and emulator. I saw .. I believe it was a PC-Engine emulator that ran faster on the GP32 at 166 MHz than the GP2x at 200 MHz. That sort of a difference is logical, a 100 MHz clock defecit on the same architecture and still yielding performance gains is quite unlikely unless the two programs are not on a level playing field-- e.g. the GP2X version uses a C CPU core and the GP32 version an ARM9 ASM core. That's not exactly a fair competition. The PCE scenario is the ONLY comparison of this nature I've seen drawn-- I recall watching the thread with interest. If you have more examples, I'd love to hear them. But I watch this forum with a hawk's eye for topics of interest and I've seen no others crop up.
As for NES emulation, we're now seeing a good NES emulator (GPFCE) run most NES games at 100% speed at the stock 200 MHz with a C 6502 core-- when an ASM core is implemented, I'd expect a full 60 (or 50 in European games) FPS at *100* MHz ARM920T clock or perhaps lower, as this is the most stressful bit of the emulation.
GB Emulation? Again, matches the GP32's offerings amazingly well. SMS/Game Gear? You can run games at full speed with 920T clockrates well below 100 MHz. In fact they can run faster than full speed there. MegaDrive emulation? On par with how it ran on the GP32, but capable of far more due to the ARM9 achieving clockrates >200 MHz-- MD emulation with DrMDx really comes into its own at 230-250 MHz.
Do try running a MegaDrive or NeoGeo emulator with a C core on the GP2X and the GP32. It will be very, horribly slow on both. It'll be slow on some older PCs, too. I'm not talking ancient history, more the Pentium III/K6-2/3 based class of computers from not very long ago.
I don't get your argument about the 940T. You say it's only accessed to be turned off? Did you forget about its role in video playback? It's a fully-capable ARM9 processor at 200 MHz by default, it just lacks an MMU and has less cache than its big-brother 920T so is not as simple to utilize, e.g. in an SMP-style setup. It can be used to do many helpful things; one individual on this forum is writing a 3D engine that utilizes it for example, so does Vektar, and this early on, you can be quite certain they won't be the last applications to do so-- it just requires knowledge and finesse to operate the 940T effectively.
Linux's impact on software interaction with the hardware affects a quite small set of cases-- SNES emulation is not faulty due to Linux, it's faulty because of a NUMBER of issues, e.g. a problematic implementation of transparency emulation-- Note that SNES emulation was horrible faulty until just a FEW years ago-- a high-quality working SNES emulator update was a SLASHDOTTED EVENT! It's not logical to expect incredible, PC emulation-scene equivalent performance from the GP2X on the same task this early on, and dropping Linux out of the equation won't be an instant 'easy button' to trigger ideal SNES emulation on the platform by any means. There are some gains it could provide, but they are not as significant as they are blown up to be, won't independently provide stellar SNES emulation and will open several new cans of worms in terms of complexity for development and operation. It's also one of very few applications where working closer to the hardware is feasible and has a probably-favorable returns-to-investments ratio for the developer in terms of invested time and gained performance.
What will provide the most immediate gains in SNES performance emulation? An ASM core for the 65c816 CPU. That's right, it's a *C EMULATION CORE*, like you just said-- very very slow, near unplayably slow, when used in most applications. Lots of optimization, cleanup, and bug-fixes. Seeing as removing a battery meter just added a supposed 10 FPS to overall performance of the emulator, that says a good bit about how much work is left to be done on it-- and makes it clear it's nowhere near hitting a performance ceiling created by Linux.
