FCE Ultra FAQ

Last updated August 11, 2004
Valid as of FCE Ultra 0.98.11

Table of Contents:


General

Why is FCE Ultra so slow?
FCE Ultra is much slower than emulators like LoopyNES and NESA. These emulators are written in assembly, which gives them a definite advantage over FCE Ultra, which is written in C. FCE Ultra is also more accurate that these emulators, and some accuracy can only be achieved by taking more CPU time.

FCE Ultra could be faster than what it is now. However, this is not a high priority. FCE Ultra should run full speed, with sound disabled, on a Pentium 2 300MHz machine, or an "equivalent" processor. I have run *older* versions on Pentium MMX 200MHz machines. Recent versions of gcc produce executables that seem to perform poorly on AMD Athlon processors, so it may be beneficial to download the source code and compile a version of FCE Ultra with CPU-specific optimization flags.

FCE Ultra will perform fastest on older systems(or systems with limited video acceleration) when using an 8BPP video mode. 16BPP video modes come next in terms of speed, followed by 32BPP, and lastly 24BPP. Avoid 24BPP video modes if at all possible.

In MS Windows, while FCE Ultra is in windowed mode, it will perform best with a "desktop" bit-depth setting of 16BPP, as expected.

Emulation

Why do some games make a popping sound(Rad Racer 2, Final Fantasy 3)?
These games do a very crude drum imitation by causing a large jump in the output level for a short period of time via the register at $4011. The analog filters on a real Famicom make it sound decent(better).

I have not completely emulated these filters.

Why don't some NSF rips work correctly on FCE Ultra?
Some NSF rips are bad. Some read from addresses that are not specified in the NSF specifications, expecting certain values to be returned. Others execute undocumented instructions that have no effect on less-accurate software NSF players, but will cause problems on NSF players that emulate these instructions. Also, the playback rate specified in the NSF header is currently ignored, as it is inherently inaccurate.

Some NSF rips neglect to write to $4017, which can cause notes to terminate too quickly and other similar effects. Many Konami NSF rips are affected by this.

Why don't some games work correctly on FCE Ultra?
Many factors can make a game not work on FCE Ultra:
Why does Super Mario Bros. start off on level 0?
This happens if you're using a hacked copy of the Super Mario Bros. ROM image. The hacked version is reading from uninitialized RAM, apparently to get the starting level number. This bad copy of SMB was likely extracted from a bootleg multicart, which would have had a menu run before the game started, initializing RAM and setting the starting level.
Why does my hack/translation not work correctly?
If a hack or translation that you made does not work on FCE Ultra, when the original game does, FCE Ultra may be applying header correction based on CRC32 value. These changes are only made to the copy of the game loaded in RAM.

To see what changes have been made, go to "Help->Message Log" on GUI ports. On command-line ports, the information is printed to stdout when the game is loaded. You can then update your hack/translation with the corrected header information.