WHY?

[Danman28]

Alright, i was wondering why the speed of the SNES emulator is so slow? I was doing some research on the Super Nintendo, and here is what i found out:
Processor Speed - 3.2 MHz...not 32, 3.2
RAM - 125 K
Ok, i know my T|E beats that on every aspect. With UDMH, my RAM is over 34000 K, thats more than 30000 K than the Super Nintendo. Also, the processor speed (with out Lightspeed) is 126 MHz, more than 120 MHz faster than the Super Nintendo. Now i understand the Super Nintendo was only made to run the game that was programed on the cartrige, but how much of the RAM and processor speed on the palm is used on programs other than the emulator? You would think that it would be easy to run an SNES game, considering the palm has much more RAM and is faster. Does anyone know why the emulator speed is so SLOW?

P.S. I hope this hasnt been already posed once, if it has been, im sorry.

[dank]

dunno, runs like a champ on my T3 , frame rate on most games is around 55 w/o sound and 45-50 with sound. barely lags at all...


peace~!

[JeremySmith]

If I understand correctly LJP (like alot of emulators) has to pretend that it is hardware of the system it is emulating. So it is running the software and pretending to be the hardware at the same time. The Snes hardware was designed specifically to run Snes games.

[Tinnus]

It's a simple concept really. An emulator needs to take each instruction made for the SNES CPU and execute it on the CPU of the host machine (in our case, that's ARM). Since the CPU types are completely different, it needs to translate each and every instruction and that's slow. One thing that can help here is to code in ASM and design the emulation from the ground up to that CPU... that's what the "ASM CPU Core" is for. That's also how gambitstudios managed to get the original Liberty to run at acceptable speeds.

Also the SNES had some extra chips I think, and could do some nice graphical effects by hardware... all of which have to be emulated, and also a separate emulator just for the sound, etc etc.

All for all, emulators in general have to be run on devices far superior to the originals. Also in PalmOS it becomes even more slow because the way the OS is designed makes it interfere in some places, although we try the best to avoid it, and with all the data security policy and all, there are some things that just aren't possible on the PalmOS platform. (Or are possible, but not documented, and considered risky. That's actually what UDMH is.)

[Danman28]

Thanks, ive always wondered why that was...But couldnt you just adjust the emulator so that it just translate one type of CPU instructions, thus making it faster? Also, Tinnus, how did u get so smart?

[Tinnus]

It works somewhat like this:

In "high-level" you have a general programming language (for example, C) that can be used to do programs for a variety of CPUs. The program called a "compiler" has the job of translating the high-level code to machine-code the CPU can understand, and so each CPU has its own different compiler.

In the lowest level, each different kind of CPU has its own direct programming language (where you tell the CPU directly what to do), and that's called ASM or Assembly. Each CPU has it's own specific features and machine-code (another name for ASM) and thus you can't just rebound a command directly to the host CPU. For example, you don't have x86 (PC) instructions on a PowerPC (Mac) CPU, so if you want to run a PC emulator on a Mac, the "emulator" needs to do something called "emulate" the CPU instructions, which is find a way to execute the commands of the emulated CPU (x86) using the available host CPU (PowerPC) commands. Sometimes you have to execute 2, sometimes 10, sometimes 500 commands to emulate just one and that's the big bottleneck in emulation.

Believe me, the CPU part of the SNES emulator is already as fast as it can get. We might only get more speed on graphics, sound and such.

Also, I'm far far away of being "so smart"... that's just what you get by being curious and wanting to know how things work