We all know the GP32 can handle fantastic 8bit emulators, including NES, SMS etc. And Skeezix proved it can even do very capable 16bit emulators.
So - what's the realistic limit in your informed opinions? While I'm happy to hear anyone's opinions on the subject, I'd especially like to hear from people like Rlyeh, Skeezix, Black, Yoyo, Flack, DarkFader - and all the other talented GP32 coders that visit this board from time to time.
I bet these discussions go on at #gp32dev all the time - give us board surfers a taste of your wisdom!
Do you think full speed Genesis emulation is possible with sound?
How about SNES?
Amiga?
And arcade games - we haven't seen much development on that front for the GP32. Imagine if something like Sparcade or HiVE, with fast ASM cores and tight optimized code were developed! What could the GP32 pull off?
I really wonder where the GP32 will be in 6 months in terms of emulators.
Speculate away...
Thats an easy question to answer --
It 100% depends on how much work someone wishes to put into it. The old 80/20 rule.
(This is a long not thought out splurge of brain dump; likely many typos, and likely many bad off-the-envelope cacs, but you shoudl get my drift)
Remember, most of "us" (in the gop32 context) are doing it on the side, for larks. I work 12 hour days, but I also do stunts on the side like my GP32 work, since its too fun to not do. That puts an upper cap on the amount of work one is willing to take on (physical max limits, plus the limit on how much of your free time you want to throw away, multiplied by how productive you are when you go at it.. knowledge levelof emulation, etc etc).
Also, most emu porters (remember, most people are *porting*, not writing new emulators) have it pretty easy.. a port is not difficult, just a bit of tedium once you know how to port for gp32 at all. And since its easy, most porrters do it for glory.. they want to do 3 days work, get a beta out, and then people say "your'e the best cool guy out there!". So they're never going to get that far, since they want the short devo cycle to get the glory. So we'll skip those "script kiddy"-types
So whats left is the people who do it for fun or love, and have limited amount of time. (either work or school or the like takes of most of your time). Thats me, rlyeh, wub, groepax, spiv, and eveyrone else.. no one works full tiem at gp32 except a lucky few.. we just ahck around in our spare time. (Apologies for speaking in the royal-We
Now note that most work is port work as I said, not new emu work; or new emu work 75% derived from other emus. Few emus for GP32 are "new" at all.
So a port is porting C code form one platform to GP32; GP32 makes it a pain since no standard C lib routines, for instance, for file IO.. so for a port you either rip out the file ops, or implement wrappers that look like standard file ops, or you toss out the file op dependant code and just keep the emu core. Porting this is easy (couple hours to a couple of days) and gets you gp32 work. Example.. quake or descent for gp32 -- they're direct prots without any gp32-ification, and hence very slow. But for an emu, you can get very decent work.. XCade arcade emu for GP32 (mine) is a 100% C port from Palm OS to GP32 (and originally from Unix and DOS, too). Very portable, but written very tightly too.. and runs perfectly well on Palm and GP32 alike. No GP32-ification needed. That was a 3 day job for the msot part, plus some time to finesse it up. That emu works by rendering to a buffer, andf then the emu shell blits it to the display; so the same code does all the work for PAlm, GP32, etc.. and you lay a thin veneer over ti to handle th eGP32 junk. Easy.
So most 8bit emus are like this.. you port it *fast* (a few days) to get it alpha/beta; then if its a NES or the like, it runs slow since theres some graphic hardware, and you tune and tune (the 80% of the 80/20 rule) and you get it faster.. thats why fNES and the like took a long time to come to fruition.. tuning is needed. But a lto fo emus need none.. just port and its "good enough".
(Hence why most emus have no docs, no decent UIs etc.. I spent a tonne of time writing a nice html manual and making a useful GUI, so that people could just use the emu without having to westle with it, installation, or the like. I did it for passion to make a nice work, so went that extra on the manual, etc. Your glory hounds wll not bother)
So.. the lifecycle is a few days for alpha, then 0 to a few weeks to get some tuning in for a usable release for more sophisticated machines.
So far its all in portable languages like C.
Now we come to sophisticated machines like SNES, Genesis, etc.. lots of hardware action to make them work, and since the GP32 doesn't have any of that, it has to be doen in software. Emulating not only processors, but the graphcis hardware,. Uh oh! (like XCade Space Invaders.. SI just renders to a 256x256x1bpp buffer; I just blit that to the gp32 8bit screen with a rtranslation.. so easy it hurts.)
Somethign like this the GP32 *cannot do as a straight port.*. A straight C job is portable, but you're not talking mega opimized (though it could be very well optimized, witness XCade which can run full speed on a 486 -- but in SNES, a straiht C port to a 132mhz platform with no hardware help is just not going to cut it.
A SNES can have little hardware help ot a lot of hardware help, depending on the game in question. If the game is maxxing out on hardware stuff (blending, rotation, etc) you're talking some serious cycles to render that. Consider.. 200x200 screen is 40,000 pixels; What if its rotated from something, and that something is actually tiles and not a bitmap? Rotationg ain't cheap, so you'd better roatte only changed parts if you can, but what abotu blend layers, etc? Thats a lot of work just to render a screen :/
Doing it mostly in C (processors and rendering ) gets you Snes9x (which may have have a little assembly in it). Portable, accurate and sluggish.
How well could it be optimized?
This is where I say it 100% depends on investment of time; you could at the biggest extreme rewrite the entire thing in assembly, at which point I'm sure you could get full speed SNES, if you made it good assembly. (Good design and well executed).
But its not likely anyone will *want* to invest a year of their life into writing a pure assembly (non portable) codebase; it'd only be good on ARM machines, and likely heavily tier to the GP32 rendering scheme.. so you'd kill yourself writing this, and then you'd have only the GP32 to show for it (ouch at that cost); if you're swift, you'd make the processor cores in assembly for ARM Thumb, and then you'd be able to use it on Palm OS and other AERM machines; but the renderer may be GP32 dependant to get the max speed. Killer. ("year" depending on time investment and complexity of system; not really as year.. a hardcore coudl pull it off in a month, but it'd be a nasty month with a lot of pizza
Mind you, you could generate ARM processor emulators "pretty fast" (a few weeks of hard work); or write a perl script or the like to spit out the cpu emu for you. Or translate intel assembly ones to ARM (not too hard). Whatever.
But the obvious is.. you can port eays things fast and easy; medium things like NES take some work. The ST has little graphical hardware, so is actually easier than a SNES I would argue, thoguh its a big complex machine.. most of the complex stuff I swiped from an already tuned emu, or used from my TOSEmu which was written and proofed years ago.. I've already written a couple ST emulators.. so I come well prepared to gp32.
So SNES and Genesis and Amiga are tougher cookies to crack (obviously); I'm betting you can get them to run pretty well with a few frameskip, with a few weeks work. But to get them to run *well* takes a serious time investment. Not terribly difficult, but *time*.
And *time* is the toughest resource to come by...
If you spend an hour a day, it'll take a long long time
But if you splurge, or if your'e a student and can skip those calculus classes, you coudl suerly pop something out.
I'm certain Amiga coudl be done fairly well (a little slower than Castaway/GP) with not too much work for some games, and chug for other more involved emulation games. To do Amiga reeally well woudl take some meat though (check your PC stats to find out how much PC you need to run UAE for the heavier games; hence you'd need some assembly to tighten down UAE).
Likewise for SNES and Genesis.. we can alreayd see that a simple port gets you not bad but with a few frameskip; you want to get that last 20% and frameskip 0 or 1? You need to spend 80% of your time getting it... and not the most fun
There is of course a cap as to how far you can go; ie: The GP32 has onyl 8MB of RAM, and a 132MHz is not much of a processor for emulation. But you can do some wild things given enough time
So.. how many peopel woudl step up to invest a killer pile of time? Mad skillz are nice (in this day and age when post coders dont' know how machines reall work anymore :/), butits time as your enemy here and some skillz.
jeff
