Stealth Bagel said:
How about no, that's a 7.16MHz 68k for you, less than 1/10th the power of the CPU in the GBA.
Stealth Bagel said:
or any PC system emulated in DOSbox
Any PC system, lozlz. I guarantee you that not a single person is emulating a PC system with a CPU anywhere near GBA's at an acceptable framerate, that'd have to be like a 33MHz 486 or something. Most anyone using DOSBox on GP2X (if anyone does) is emulating old 8088's that are tons weaker than GBA's CPU.
Stealth Bagel said:
, and higher-end arcade hardware (NeoGeo, high-clocked 68K/Z80 pairs in many arcade platforms) should about break even with it, or exceed it....
Oh man, you really have no concept of how these old CPUs performed do you. Okay, let me break it down for you, both of them get in the range of 0.08 to 0.12 or so MIPS per MHz, while GBA's ARM7TDMI will get closer to 0.8 or more MIPS per MHz. Maybe you don't believe me, but I've seen GBA games pull exactly this, and Lordus has given me numbers that Genesis games pull (Genesis has that exact combination) because we've both been heavily profiling CPUs. 68K + Z80, please, don't joke with me. If that were even close to true then none of the emulators for those platforms would run well at all because they're all using interpreters.
Oh, and the ARM ISA is more sophisticated than 68k's, don't even mention z80's. That's just ancient by its standards.
Stealth Bagel said:
I am not referring to raw capability alone, but also the amount of host CPU cycles used trying to emulate the hardware in question....
Let's see, opcodes that are generally 8 or 16bit in length vs 32bit instructions with dense encoding, hmmm, having to handle conditional execution on every opcode, a barrel shifter on every ALU op2, being able to modify the program counter with almost any instruction, those things must all be easy to emulate. That or you just don't know the first thing about emulation, you probably don't even know the first thing about these CPUs to begin with :rolleyes:
Granted, GBA games often spend a lot of time in Thumb mode which is simple, but games can and DO spend a lot of cycles in ARM. Go play Asterix 3D and tell me that your Neo Geo can do that.
Stealth Bagel said:
also if I'm not mistaken, the GBA's ~16 MHz ARM7TDMI is badly bottlenecked in the manner it accesses the bus, reducing its effectiveness quite substantially....
You're wrong, again. That's only true if the game isn't programmed to strongly utilize the 32KB of zero wait-state IWRAM on the GBA, which almost every game ever released for GBA does, some much more than others. Ignore the MIPS figures dwelch reported in his benchmark, he was running the ARM code in ROM which is not a realistic setup.
Stealth Bagel said:
The GBA's video hardware is impressive, but its CPU is by no means a regular powerhouse.
Look, you don't know what you're talking about. Go look at the library of emulators available for GBA, you will be absolutely shocked. Comparing GBA's CPU to SNES's is a disgrace, it's in a totally different league. There's an SNES emulator
for GBA that actually runs some games at good speed.
QUOTE
If you say so. I'll take your word for it since you're an emulator programmer and I'm not, but I find it pretty hard to believe hardware blitting of the different graphical layers and implementation of transparency could not be accelerated in such a fashion, at the very least.
Funny, that doesn't sound like taking my word for it at all
QUOTE
It might be less accurate than drawing everything completely in software.... however such a thing can be switched on or off for the bigger sticklers for maximum accuracy. Most people here seem concerned with speed over 100% accuracy, since this is a handheld we're talking about, and portable emulators are usually a great deal less accurate than their PC counterparts.
Actually, since SquidgeSNES gets great speed if you turn off transparencies and raster effects and whatever and yet so many people still complain (because I guess they want an accurate gaming experience, unthinkable) I would say you're way off the mark.
And there you go again saying portable emulators are less accurate than PC ones, which is just something you've made up. The only time this might apply is for DS emulators using hardware acceleration (which is much more feasible than doing it on a 3D accelerator because lo and behold, it has very traditional styled 2D acceleration)
Most emulators for handhelds are PORTS you know.
EDIT: Come to think of it.. and I hate to pull a craigix on this one, but some of the stuff you're saying sounds a LOT like what Epicenter went on about (XScale being 50% speed and not a "true ARM", handheld emulators being inherently inaccurate, insisting that hardware acceleration be used in emulating 2D consoles).. if I find out it's you again I'm gonna be really peeved