You're not talking rubbish, but you're missing a few key things
Firstly, emulation is by definition very tough work for a machine to do; the rule of thumb was always "10 times performance needed to do the job halfway right", but it really depends on what needs doing; the ST was approx 8MHz, but one must factor other components in (memory model, blitter, etc etc).. you're emulating a processor, plus other stuff. The reason Castaway worksd as well as it does is because its fairly tightly optimized, though still portable C, and the ST is basicly a pretty simple machine. Emulating a SNES is much more work due to the SNES having some funky hardware... not only are you emulating the processor, but you're emulating what the hardware does. So having software do what hardware does for a totally different platform.. now thats a lot of work to do, and it cannot run fast, just by definition. ie: A SNES can do scaling and rotation with minimal investment by the SNES developer.. its just fast, no worries, so they can rotate a picture around 60 frames a second with no real overhead; but to emulate that piece of rotation or scaling hardware, imagine rotating every pixel on a 320x200 screen 60 frames a second.. millions of operations. Bam, hard to do fast in software
So emulators vary by speed based on the hardware they're trying to emulate, and the time invested in the emulator, which of course is directly proportional to the skills and available manpower. Niche platform here, so there you go.
So.. Castaway again, is written entiwrely in C; early versions had bunch of ARM assembly put in to speed it up, but then I tossed all that as I work cross platform and didn'r want to tie myself to ARM specifics, or even GP32 specifics (notice now that I've got Castaway running on Palm OS). Its pretty well optimized C code, but could be topimzied more still.. and runs fast. Rewriting it all in assembly for the GP32/ARM would make it much faster still.. but there inlines another issue. Writing an emu in C is measured in weeks for simple projects (like a Galaxian emu, say), but in assembly.. months. (assuming from scratch). So I built and got Castaway for GP32 done over a couple of months (and I'm a very experienced coder and emu coder), and hence it does a lot of thigns very well. But if it was written in assembly, you'd still be waiting for it
Writing it in C is one thing; wiriting it in assembly is a huge huge huge task, and the output is few things. 1) Fast running, and 2) Incomprehensivble to most, and 3) Not portable. So does someone want to work their bones of like mad for many months, only to come up with something that has very limited portability and lifespan, or they can work on somethign less, and get much more out of it.. something for many machines that lasts forever. The answer is.. sure, you build emus out of love for the machine, so you'll do it.... maybe. People like me work on a half dozen platforms each day, so woudlnt' go near such a thing. I routinely port code I wrote a decade ago to new platforms.. thats nice. (ie: Thats why you have XCade for GP32; it took 2 days ot get half working, and another week to make it more pollished. So theres 10 year old code brought to GP32 in a week! Thats why I make things portable.... yet if XCade was assembly, it woudln't have been ported to the half dozen platforms it runs on today)
Now, if you have a sufficiently large developer base, there'll be people who don't mind to do the assembly or have the time; like on the PC intel platform.. theres Z80 processor emus in C, assembly, java, you name it.. millions of developers, everything gets done many ways. Cool. But for the GP32 and ARM, you have so many fewer developers that you're relying on a vital few.. and thus they usually don't have the time to go writing things in assembly all day time.
As it is, theres almost no Emu coders for GP32 -- theres mostly emu porters, porting code from other platforms. They're going for high speed delivery and glory and fun, but likely don't have the skills or time to go writing an emu from scratch. Like MAME.. MAME is a pretty darned successfull project, with thousands of people donating time. Its obviosuly not optimized for any platform, let alone small ones like the GP32 (small in architectural sense); so rewriting somethign like MAME.. forget it -- if thousands of peopel wrote it, you know it'd take 1 person a few lifetimes
But porting it is conceivable. So no way you're going to see an assembly version of MAME. Take the same for most other emus on GP32...
(Of course, a lot of the emus have a little assembly and lots of GP32 specific optimization in them, of course. Pieces of the puzzle.)
Anyway, withoru going into the whole development cycle.. emulation is itself a niche-ish thing, and you'r e on a niche platform, and thus you're not going to get too many devvers with so much time they can waste it making an ASM version of something, when they can instead make use of whats already there and get you something to play with now, rather than a year later
jeff