UltraHLE FAQ
by Zorkwiz Version .3 (Second Public Release) This document has been altered by me. Comments by me have the initial "J". This faq has been put into html formatto make navigating easier (thanks to Zico). Released on February 4, 1999 by (Zorkwiz).



Table of contents

1: Credits
2: Version History
3: General Questions
4: Game Specific Questions
5: Technical Questions
6: Legal Issues
7: UltraHLE Technical Document
8: Compatibility List



Thanks to BG and [-UT-] for their conversation. Thanks to ^SeiGGy^ in #ultrahle for Joystick support info, and info on the key mapping problems. Thanks to Marine_ and Furon in for their key remapper. Thanks to Prozac- and Demi for compatibility info. And most of all: Thanks to Epsilon and RealityMan for such an amazing piece of software. And RealityMan again for the technical doc, and some legal info.



2. Version History:

1. This release was not supposed to be publicly released, but it was for a short time.
2. The first public release, added some missing URLs and a few more questions.
3. Added sections for legal issues and technical questions. Added an explanation of the technology behind UltraHLE (straight from RealityMan himself!) Added a straightforward compatibility list (thanks to Prozac- and Demi for the info) Updated credits, added a few questions to existing sections, and generally made the FAQ easier to read.



3. General Questions:

Q: What is UltraHLE?
A: UltraHLE is an advanced Nintendo 64 emulator for PCs with 3dfx chipsets.
J: Don't worry non-3dfx owners, you can still use UltraHLE by using a "wrapper".

Q: Where can I get UltraHLE?
A: UltraHLE is discontinued, and has been removed from most sites. Check on IRC if you can't find a copy otherwise.
J: Look in file section of this site.

Q: What kind of system do I need to play games with UltraHLE?
A: It is recommended that you have at least a Pentium 2 processor with a Voodoo1, Banshee, or Voodoo2 graphics board. A 3dfx board is required, although Glide wrappers can be used to emulate the 3dfx instruction calls to some extent. (See Part 5: Technical Questions) To get full speed emulation in many games a 300mhz+ processor is recommended.
J: I have a celeron 300a and using a wrapper with my TNT is very good albeit not as good as using a voodoo II. All you people with P166's, stop asking if UltraHLE will work. The bare minimum is a PII 233 Mhz when using a 3dfx Voodoo I card. You will need a higher cpu if you need to use a wrapper. You also need a good quality 3d card in order to use a wrapper. Something like an Nvidia TNT/128, Matrox G200, Intel i740, Ati Rage Pro, will work to various quality/speed.

Q: Where can I find N64 ROM images?
A: Unless you own the N64 carts, use of commercial ROMs is illegal. This doesn't stop many people from downloading them anyway, however, It is not the purpose of this FAQ to help you find ROM images. If you want to find commercial ROMs to play, that is up to you. DO NOT E-MAIL ME ASKING WHERE TO FIND ROMS!
J: Do not e-mail me about roms.

Q: Which games work with UltraHLE?
A: Although many of the best N64 games work quite well with the emulator, compatibility is quite low overall due to the method which was used in programming it. The name "UltraHLE" means "Ultra High Level Emulator" and implies that the emulator skips emulation of many of the N64's basic functions in favor of emulating the high level functions which the best games really need in order to run. Because of this, many demos and simple hombrewn games which have worked on other N64 emulators fail to even load with UltraHLE. For a largely complete compatibility list scroll down to the compatibility section (Part 9).
J: LOOK IN THE INI FILE. STOP ASKING "DOES SOUTHPARK WORK", "DOES CASTLEVANIA WORK"!!!

Q: Why don't the ROMs I downloaded show up in the UltraHLE GUI??
A: You either need to edit the ultra.ini file to set up the directory in which the emulator looks for ROMs, or you need to change the extension of your ROM to one of the supported file types. (.n64 .v64 .u64 .rom .bin .mov)
J: This is how I have it setup. I created a folder called ultrahle in c: drive ---> C:ultrahle I then created a shortcut to the desktop. Then created a folder in ultrahle called roms ----> C:ultrahleroms If you do this, the .ini doesn't need to be changed and your roms should show up when you start UltraHLE. I also created a save folder at c:ultrahlesave

Q: Why doesn't my ROM work with UltraHLE???? The Compatibility page said that it would.
A: There are a few reasons for this problem. First of all, you might not have the complete ROM, or the ROM that you have could be corrupted. Before you delete your ROM however, check to make sure that the filename has NO SPACES in it, and that the file extension is either .v64 .rom .n64 .u64 .bin or .mov The emulator's GUI can recognize spaces in filenames, and will correctly read a ROM's header, but the EMU will not load ROMs with spaces in their filenames. Lastly, if you get an error loading a rom, try to load it a few times, as sometimes the emulator fails to load it correctly on the first try. Hitting F5 when a game is trying to load also sometimes (but rarely) helps. If all else fails, look for another copy of the ROM.
J: There are bad roms out there. Check rom with rtool. You can also try loading a rom another way. Example: Double clicking on rom; file, open, click on rom, open, f5; etc

Q: Why does sound skip when I play game X??
A: One of the most noticeable problems with emulation in UltraHLE is the sound emulation. Although sounds is emulated very well in most cases, many games, like Waverace64, Mario, and Zelda among others have sound skipping problems to various extents.
J: This is a problem with the emulator because everyone has sound skips to an extent. There is not much you can do to stop skipping. If you are using a wrapper, you can try to use another one.

Q: Why can't I rotate the camera left in Mario and other games, and why doesn't the left d-pad button work correctly??
A: The key for left camera (left-c) is incorrectly mapped to the "F" key. The control setup screen shows that it should be mapped to the "J" key, but it is not. Unfortunately, the "F" key is also used for left on the d-pad (digital pad). This makes Pushing left on the D-pad impossible with the default keys. In games where you have the choice of using the d-pad or the analog pad, always use the analog, as it is correctly mapped to the arrow keys. You can use "F" for left-c, but another (better) solution is to use a nice little utility made by Furon called HLEconfig. This utility allows you to remap most of the buttons of the N64 controller to different keys than the emulator defaults to. Using this program, you can get the left-c button correctly mapped to "J", or whatever else you might want. HLEconfig can be found at http://www.locknload.net/n64
J: Use the invaluable tool for UltraHLE called UltraHLP, available in the file section. Instructions on use are available in the help section.

Q: Joystick support sucks! The default joystick/joypad settings are too hard to use. What should I do?
A: The solution to this is to use a key binder for your joystick/pad. You can set up a custom configuration for your stick/pad this way. Gravis products come with their own key binder, and MS Sidewinder pads also have their own key binder. If your joystick/pad doesn't fall into these categories, there are other binders floating around the net. One such program is called RB-joy, which you can find at http://alf.zfn.uni-bremen.de/~rbsoft/prod05.html. Also, if you are looking to buy a joypad for use with UltraHLE, the Gravis Xterminator has been recommended to me because of it's analog controls (just like the N64 controllers).
J: You can buy or build your own interface to connect a N64 controller to your computer. A review of the interface/adapter and link can be found at EmuHQ. If you want to use your current joystick but want to change the layout, use UltraHLP. A joystick to recommend would be the Gravis Xterminator.

Q: Why can't I save my game? When I quit out, my save is gone!
A: You need to use the emulator's "Save State" option. When you want to save your game, hit escape to quit back to the GUI, then go to the file menu and choose "Save State" (or hit shift-F6). Now type in the filename you wish to use for your saved game. To load a saved game, start the game you wish to play, hit escape to get to the GUI, go to "Load State" in the file menu (or hit shift-F9), and choose the file which corresponds to the saved game you wish to load. You can also use F6 for a quick save, and F9 for a quick load.
J: Example, when you finish a stage in Mario64 you get a save screen. If you choose "save", your game is not actually saved. You will have to use UltraHLE's save state option.
Some wrappers will not allow you to hit escape to go back to the GUI. In that case just press shift-F6 and hope the save screen shows up. When you finish saving, press F5 to continue the emulator. If the graphics become screwed after doing this, you will have to start ultrahle again and load the save game. However, UltraHLE does produce corrupt save states, as mentioned in the README, so save often.

Q: Game X runs too slow/too fast, is there anything I can do?
A: Since there is no frame-skip or auto frame-skip in UltraHLE, the only way to speed up or slow down emulation is to change the resolution which you are running the game at, or disable the sound. Choose a high resolution to slow the emulation down, or a low resolution to speed it up. Disabling the sound also gives a speed boost. Also make sure that you have the most current drivers for your video and sound card, and that you aren't running any programs in the background while using UltraHLE. Of course upgrading your PC is always an option as well.
J: To disable sound, open the ini file and find where it says "sound=" put it "=0" Also close all background programs. These programs take up valuable system resources.

Q: I found a patch for one of the ROMs, will it work on UltraHLE if I apply the patch?
A: Generally No, the patches are mostly designed for backup machines, and they do not effect performance in UltraHLE, in fact, many patched ROMs are incompatible, whereas their unpatched counterparts work fine. The only worthwhile patch I've seen is for the HS (High Society) version of Zelda. There is a patch for this rom which can be found at http://ppgr.webjump.com/n64/n64-playable.htm (scroll down to Zelda)
J: I don't know what this patch does as I have not tried it. Zelda should be 32.0 MB unzipped.

Back to top

4. Game Specific Questions:

Q: Why is there no in-game sound in Goldeneye?
A: This is one of the most common complaints I have heard about any game, and the funny thing is, it's the easiest to fix. Simply press the start button ("S" by default) once the game starts to go look at your watch, then press left a number of times until you get to the options menu. You'll see that the music and sound are turned all the way down! Turn them up, and the sound is great. Not even any skipping that I heard.
J: There is also another way around this. Check out the bugs/help section.

Q: Why can't I get WaveRace 64 to work?
A: Only the Japanese version of WaveRace64 works with UltraHLE (I've heard that there may be a working US rom, but I've yet to speak with anyone who has seen it).

Q: Why can't I get Virtual Chess 64 or Mischief Makers to work?
A: Only the European version of these ROMs are compatible with UltraHLE.

Q: Why is Banjo, the main character in Banjo Kazooie, so small?
A: Due to a strange bug, Banjo is very small, and cannot make many of the larger jumps in the game. This makes it basically unplayable.

Q: Why can't I get past X part of Zelda?
A: I've heard people complain about Zelda crashing at various parts in the game. I have personally not had problems, but I haven't played very far either.
J: I have heard that you cannot finish the game because of a bug. There is a fix included in ini version 1.0.11+ that will stop the time allowing you to finish the game at the end. This fix is not enabled by default. Check the help section for details.

Back to top

5. Technical Questions:

Q: How can UltraHLE work so well after only 3-4 months of work, whereas other N64 emu's could barely get demos working after a lot more time?
A: UltraHLE is not an emulator in the normal sense. It does not attempt to emulate every piece of the N64 hardware. It interprets hardware calls within the ROMs and attempts to emulate them as they are called. Because of this, the authors didn't have to emulate every chip in the N64 to perfection, they apparently used a debugger to see which calls the more popular games used, and they did their best to emulate these until the games were working.

Q: Can I try adding stuff to the INI file to get more games working?
A: You could try, but it would take a hell of a long time to see results, if you ever did. It took the authors themselves a few weeks just to figure out the hacks for Zelda, so anyone not familiar with the program would probably be wasting their time to try this.
J: Here is what ^SeiGGy^ (works on the ini with others) said about the ini:

"well...the ini file does quite a few things...it basically hex edits addresses permanently... so that you don't have to use a hex editor every time you open a rom to fix a problem. It also modifies ways that UltraHLE handles the roms, ie: the area of the rom that it searches for the boot codes. It's also where you can put gameshark codes and it's very usefull... for programmers... not to be messed with by inexperienced user... It's also used to add comments and change the displayed title in the gui."

It's not something inexperienced people can play with other than putting in gameshark codes. INI version 0.0.10 has some instructions on how to fiddle with the ini if you want to know how.

Q: I have a TNT card (or some other non-3dfx board). Are you SURE I can't try out the emulator?
A: Some people have claimed to have some success running non-3dfx boards with a Glide wrapper and being able to use UltraHLE. I have heard that TNT users in particular have had little success, but if you have a non-3dfx board, and want to try it out, goto Glide Underground.
J: Wrappers are advancing at a rapid rate and improving big time. Mario and Zelda are very playable using a wrapper and a TNT card. You can read reviews about wrappers in the Glide Wrappers section.

Q: What is UltraHLE programmed with?
A: Mainly with Visual C 6.0 (With SP1), dynamically recompiled into ASM.

Back to top

6. Legal Issues:

Q: Are emulators legal?
A: Well, this is a tricky question. An emulator is legal in theory, as long as it is used exclusively for playing games which the user has paid for, and as long as no stolen information was used in the creation of the emulator. This argument has not been proved in court as of yeah, although a case from 1982 when Atari sued Coleco over their machine which would play Atari 2600 games failed in court. The true test will come in the upcoming suit which Sony has filed against Connectix over it's "Virtual Game Station" Playstation emulator for Macintosh. The outcome of this lawsuit may well set a precident for years to come, so let's hope and pray that Sony's suit fails.

Q: What is the IDSA?
A: The Interactive Digital Software Association is a lobby group whose members include many of the largest software companies in the world. They have taken a firm stance that emulation is illegal: period, and thus they have stirred up a lot of negative feelings from people in the emulation community. There is even a boycott of IDSA affiliate's and their software. Check it out at http://www.jpisp.com/idsab

Q: Has Nintendo sued the authors of UltraHLE?
A: Not yet. They have threatened a lawsuit, but they have not contacted the authors or anyone at Emulators Unlimited as of now. It is still unknown whether they will indeed take legal action.

Q: Are backup devices legal?
A: Nintendo has tried very hard to wipe out backup units, especially in the U.S. They are available from many import houses however, and thus are not be illegal in all countries. The EU directive 91/250 states that they are NOT illegal in the UK at least.

Q: Am I going to get in trouble if I distribute emulators or ROMs?
A: It is perfectly legal to distribute emulators, but commercial ROMs are another story. If you distribute ROMs on the web, you may get a nice form letter from the IDSA very soon. I have never heard of a ROM site being sued however, but many have been shut down voluntarily after a threat of legal action from the IDSA.

Back to top

7. UltraHLE Technical Document

(Thanks to RealityMan for this Doc)

If you are interested in programming or emulators in general, this text is for you. The purpose is the explain the basic architecture behind UltraHLE and tell how it differs from many other emulators.

The HLE in the name pretty much sums it up. It stands for High Level Emulation. Instead of trying to emulate the hardware as closely as possible and supporting low level operations, the approach is just the opposite: Emulate as little as possible and try to detect operations as early as possible, and emulate them using optimized C-code.

For example there is no boot rom and even boot code in rom images is ignored. Common operating system routines like interrupt adjustments are intercepted and ignored. When dealing with graphics and sound, the abstraction level is high (display lists and sound lists). CPU and DMA emulation is at a lower level, but still uses some tricks to detect common operations and perform them more efficiently.

This probably wouldn't work on an older console, where low level programming and hand tuned assembly were the rule. But the Nintendo64 is quite different. Most of the code is written in high level C eliminating need for 100% exact CPU emulation (so things like exceptions or virtual memory can be emulated only approximately). Graphics and sound both use command lists, that are reasonably standard between different games.

On the real console display and sound lists are executed using the Reality Signal Processor (RSP) which executes code from the rom image. It is a vector processor with operations specifically designed for fast geometry and audio, and as such is difficult to emulate efficiently. In UltraHLE the lists are interpreted with C-code, which has been created by studying the lists games generate. There has been no attempt to translate the RSP code, since it works so closely with the hardware and uses integer arithmetic. Instead the C-code can use floating point, which is easier and faster on the PC. This means the results are not 100% same as those on the real console, but on the plus side things are a lot faster, and often results look better (for example increasing game resolution is trivial).

It is also possible to do things the original code doesn't do. For example, on the N64 loading new textures is a rather fast process, and all textures are loaded each frame. On the PC 3D-architectures, texture loading is generally a slower operation. The solution is to cache textures on the PC side and eliminate all unnecessary loads. This give a big performance boost and practically all textures can be cached, since PC has so much more texture memory.

Other display optimizations include removal of hidden triangles, extra matrix loads, unused mode changes and the like. Since texture and mode changes are more expensive on the PC, it makes sense to do extra geometry processing to eliminate as many changes as possible. Triangles are also collected into larger groups (sorted by mode) to allow faster rendering.

Finally, the graphics emulation has to cope with all the different rendering modes of the N64. The RCP contains a very configurable 3D-rendering unit which supports many modes that are impossible to emulate directly on 3DFX, even when using glide. UltraHLE performs pretty complex mode conversion to find the best PC-modes for each N64-mode. Things that the N64 does in a single pass are converted to 1-3 passes on the PC, depending on mode complexity. The modes are cached like textures, so the relatively slow mode decoding process does not slow things in practice.

Since there is so little information on Nintendo64 hardware, emulating sound and graphics on hardware level would probably have been extremely difficult (unless one had access to all N64 documentation, which we didn't). So in a way this high level approach was pretty much the only way to proceed. But it was a good way nevertheless, as the results show.

The high level approach doesn't extend that well to CPU emulation, but luckily the CPU is a standard MIPS R4300 with excellent documentation available. So it's just a matter of following instructions, and then making it fast (which is the hard part). What helps us, is that the games don't use the CPU to its full extent. Practically no 64-bit code is used, and virtual memory usage is limited.

Initially the CPU was emulated in C like in most emulators to get things started, but that was way too slow. The next logical step also was to compile MIPS code into Intel code. All instruction decoding overhead is eliminated, but it still takes multiple Intel instructions to emulate a MIPS instruction (since MIPS has more registers and because the Intel FPU implementation just plain sucks). Also things like branches are not that easy to handle. The speedup was about 5-10x compared to C-emulation.

The next step was to add optimizations to the compiler. By allocating MIPS registers temporarily into the few Intel registers, many memory accesses can be eliminated. This allows compiling small connected instruction groups into about 2 Intel ops for each MIPS ops ratio. Nearby memory accesses with similar addresses can be simplified by caching the base addresses in registers. It is also possible to replace some RISC instruction pairs with single CISC instructions. Since our target (Pentium II) does out of order execution, it was not necessary to reorder instructions, which made optimizations a lot easier. These optimizations increased speed 2x.

On a Pentium II the R4300 emulation speed is now close enough to allow real time operation on many games and demos. Of course the PC has to do the work of the Reality Co-Processor too, so that will slow things down. But PCs are getting faster, and a 450Mhz Pentium II should run at excellent speed. And there are probably more possible optimizations, just waiting to be done.

UltraHLE is a very unusual emulator. It doesn't run many titles (yet), but what it runs, it runs well. This is because the high level emulation routines either work (if what they assume of the game is current) or they fail (if the game uses a totally different display list format, for example).

The goal of UltraHLE is not to run as many titles as possible. It is to run the best titles as well as possible. And looking at the current compatibility list, this is exactly what UltraHLE does. Compatibility will no doubt improve in the future, but the emphasis will still be on quality instead of quantity.

Back to top

8. Compatibility List:

This list is not 100% complete, but it's getting close. (thanks to Prozac- and Demi for the info)
J: Also check the ini file to see which games are playable.
Prozac-'s Compatibility Page can be found here. Demi's Compatibility list can be found here. Pay attention to country info... many games are only playable if you have the right version.