I'm trying to port FCE Ultra to a WinCE 2.11
machine (IBM Z50) running on a MIPS VR4121
at 131 Mhz. Speed is a major concern since
now it's quite slow, even with frameskipping
and with sound off.
I remember I could run Nesticle 0.42+ on
a 486DX2-66Mhz and still get more or less
half to full framerate. (The windows port was
slower than the DOS version, but still not
too bad)

Does anyone know or have a conjecture on why
their emulator was so fast?

1) Pure assembly? Mostly Assembly?
(Well written assembly usually can speed
up your code about 2x or so?)

2) Any kind of dynamic recompilation going on?
(I serious doubt it though)

3) Do they do analysis of code paths to eliminate
or speed up certain operations? HLE at the
sprite level or something like that?

4) Anything else that may help speed up the code?

Any thoughts appreciated,

1) If I am not mistaken, Nesticle contained a bit assembly code. I guess nothing beats the speed of good old assembly. :) I know, me and my friends NES-emulator for AmigaOS, A/NES CGFX (written in pure 68000 asm) runs close to fullspeed on a 68040 at 40mhz!
2) I am 99% sure it uses standard interpretive compilation.
3) I think the CPU-emulation is the easy part. The PPU-emulation part is the bottleneck. However with intelligent cache-routines for sprite/backgrounds...
4) Intelligent cache-routines for sprite/background code. Try not to draw anything that has been drawn previous frame and stuff like that.

While not directly related to emulation, through my experience game programming for Palm OS, I have found that something as 'simple' as accessing an array in a loop can have a HUGE hit on performance. Since your memory emulation is probably an array, try to get the accesses down - try using a pointer, then adding/subracting from that offset wherever you can.

This helped on a Palm, but I guess we're talking different hardware/compilers/etc.

Programming in ASM instead of C helps, but the key factor in speed here is ROM compatibility. FCE Ultra supports all sorts of mappers, and fixes *most* timing issues with NES ROMs.

Quite simply, NESticle does not.

- Tricob.

Yes that is true. If the C/C++ functions are coded right, then ASM will only help a small bit. I would suggest you run through some of the graphic functions and do ANYTHING possible to speed those up. Also make sure you aren't using to many IF's in a loop. If statements can cuase some speed loss.
Basically look at all your subrutines, try to use inline functions, and use macros.

C is not as fast as assembly, as far as drawing PPU data to the screen. My method of drawing the PPU tileset could not be used in C, as it involves the Carry flag:


shl ah,1
rcl bl, 1
shl al, 1
rcl bl, 2
mov word ptr [edi], bx


In only a few instructions, a pixel from the NameTable can be drawn to the screen. This is far more optimized than any C routine could be.

I don't know whether this applies to computers more advanced than 8-bit, but I've seen some programmers say that when speed is a concern:

"Use self-modifying code. It's faster."

Does anyone recommend against this or recommend the technique as well? I'd say don't try it unless you're *very* experienced with Assembler.

- Tricob.

There's no difference between accessing an array using the bracket operators or using a pointer.

int a = foo[3];

is equivalent to

int a = *(foo + 3);

The speed hit comes from recomputing an array index instead of just incrementing; for example, writing pixels inside a double for loop. Chances are you're doing something like:

pixel[y*WIDTH + x] = val;

every iteration. Computers are very good at adding 1 -- just start the pixel pointer in the right place and then increment it each time through.

I'd have to disagree, especially for present-day systems. There's really no reason to do this; it's a technique intended for small-profile processors (things like mainboard ICs, bootproms, or BIOSes), not full-fledged applications.

I won't deny there are some really good uses for self-modifying code, but most of the time it just adds complexity while adding the benefit of being able to say "my program is cooler than yours."

For lack-of a better example, look at what used to be common practice in the days of 65xxx, 68K, and early x86 -- unrolling loops. This was one of the best ways to gain speed at the cost of size. I've yet to see much of a speed gain using gcc -funroll-loops on any processor other than a 486. :-)

So, my advice would be to sway from going down the path of self-modifying code.

Well, now I know why I can't find any examples of Self-modifying code for newer processors.

Thanks for your time. :-)

- Tricob.