This specification should allow you to play any compatible game with good speed, graphics, sound and control, subject to the limitations of the emulator. Note that this specification is still not sufficient for every option available, but with proper configuration you shouldn't have significant limitations.

• Intel Pentium 3 1.5Ghz or higher or AMD Athlon 1.5 GHz or higher
• 512MB RAM or more
• nVidia GeForce FX or later or ATI Radeon 9500 or later
• 1GB or more free hard drive space
• Creative Soundblaster Live! or higher
• Adaptoid and original Nintendo N64 controller for each player
• Microsoft Windows XP with latest updates.
  

Optional extras:

• video card with TV out and a high quality widescreen television set
• high quality stereo speakers supporting dolby virtual surround
• USB hub and/or controller extension cables
• genuine Nintendo Rumble Pak for each player

This specification will be sufficient for you to enjoy some of the compatible games with good graphics, sound and control, subject to correct configuration and some limitations of the emulator. You are likely to suffer some performance problems (leading to audio problems), and you will not be able to use all the options in the emulator. Look into using 3rd party plugins.

• Intel Pentium 3 700Mhz or AMD Athlon 800Mhz CPU*
• 256MB system RAM
• 200MB free hard drive space + additional 20MB-100MB free hard drive space per game, depending on game and number of saves you make
• 100% Microsoft DirectX 7 compatible video, sound and input devices**. See below for realistic minimum video hardware!
• Microsoft Windows 98
• Microsoft DirectX 8

*the plugins contain SSE optimisations, early Athlons did not have SSE.

**The video device must be a primary device, have at least 16MB local memory and two texture units. Depending on the features supported by your video card some content may not be displayed correctly and thus some games marked as compatible may suffer glitches or not be playable on your system. The exact features required vary from game to game.

Realistic minimum video hardware for the v1.5x video plugin: 
nVidia GeForce256 (GF1) and ATI Radeon (early models) are suggested as realistic minimum video hardware. With good drivers they have the required features (blend modes etc.) for the D3D6 plugin.

Realistic minimum video hardware for the v1.6 or later video plugin
nVidia GeForce3 or ATI Radeon 8500 or later. With good drivers they have the required features (pixel shaders v1.1 etc.) for the D3D8 plugin.

Better cards mainly allow higher resolutions, filtering, anti-aliasing and so on without substantially increasing emulation accuracy.

The following graphics chipsets (thus all graphics cards based on them) can be considered below minimum specification:

• 3dfx Voodoo 1,2,3 (1,2 - not at all, 3 - poor image quality)
• ATI Rage128, Rage Pro (poor image quality)
• Intel i740, i810 (poor image quality)
• Matrox G200, G400, G450 (poor image quality)
• nVidia Riva128 (poor image quality)
• S3 Savage 4, Savage 2000 (particularly bad, these cards hang)

You may find that Project64 usable on a lower-specification system than described here, particularly with some games and careful configurationm, and/or 3rd party plugins. If so then enjoy, but please don't expect too much, and we do not support below min. spec. systems sorry.

Ideally do this before you start using Project64, if you haven't, please read this page now anyway.

Make sure you have a clean and stable system, which means:

1. Have all the latest drivers intalled for all your hardware, especially video hardware.
2. Have as few applications running as possible - the emulator needs a lot of resources, the more you free the better it will perform.
3. Defragment your hard drive - this could speed ROM loading and improve swapfile performance.
4. Temporarily disable any virus checkers or scheduled tasks - if these start while you're playing performance could suffer badly

If you know your PC is not stable generally (maybe it locks up occasionally while playing PC games, or applications quit or crash for no apparent reason), stop right here and get it fixed! The emulator pushes system components hard and although it will not cause any damage, any existing stability problems that your PC may have are likely to show up when you start using the emulator.

The current version of Project64 is provided from the {ln:download section} with a Windows installer.

1. Download and double click the install file.
2. You will be prompted for the path on your hard drive where you would like Project64 to reside (or use the default path, which is in Program Files) and continue to click Next through the installer.
3. Run Project64 from the shortcut in your Start Menu.
   

All the necessary files to get you started and playing N64 games are included (apart from the games themselves!).

You will be asked to choose a language the first time PJ64 is run.

If you are not sure what to do next, please refer to the Using Project64 section of this manual.

N. B. There are no games supplied with Project64! It is your responsibility to acquire games. The Project64 team cannot help you find commercial games, for legal reasons. Requests for ROMs are not welcome in official Project64 areas of the Internet.

To use a game in Project64, the ROM file of that game simply needs to be available locally on your system. This could be your hard drive (recommended) or a CD-ROM or other removable media (since removable media is generally slower, loading times will increase but performance of the emulation itself will not be affected). It is not recommended to try to load games across a network, because apart from the increased time taken, there are possibilities of corruption, although this has been found to work.

It is essential that you {ln:verify your ROMs}. Project64 absolutely requires 100% good images... hacked, corrupt, truncated etc. files are not supported.

To view a ROM or collection of ROMs in the Project64 ROM browser, simply tell Project64 where your ROMs are by selecting the folder via the File menu or by right clicking in the Browser.

Points:

1. Make sure that your ROMs are either uncompressed or are compressed in standard Zip file format. No other file compression format is supported.
2. The ROM file must have a standard N64 ROM file extension, such as .z64, .v64, .rom or in the case of a compressed ROM, one of these extensions inside a .zip file.
3. The byte order of your ROMs is not important, Project64 can read all standard byte orders. Byte order makes no difference to emulation performance.
4. If you are using zipped ROMs, there must be only one ROM per zip file, so compress your files individually (there are tools available to do this).
5. If you want to arrange your ROMs in subfolders, you can choose the top level folder and enable the Directory Recursion option. Project64 will search through all the subfolders and list all the ROMs together for you.
6. You cannot add ROMs in seperate trees. For example, if you have some ROMS on one hard drive and some more on another drive, you will have to pick one or move them together.
7. There is no practical limit AFAIK to the number of ROMs you can have in your folder(s), except for the amount of storage space you have.
8. Having zipped ROMs does not effect the speed a game runs at, only the loading time (which may actually be faster, depending on your system).

If you want to backup your Project64 installation (before formatting your hard drive for example) or move your Project64 installation to another computer etc., you need to know where all your personal settings are stored.

The Windows Registry is used for most application settings and plugin settings. You could save this data if you wanted to (athough its probably easier and quicker just to set up the application and plugins again) by exporting the relevant registry keys (function of Windows built in Registry Editor).

• [-HKEY_CURRENT_USER\Software\JaboSoft\Project64 DLL]
• [-HKEY_CURRENT_USER\Software\N64 Emulation]

Changes to ROM Settings are saved in the ROM Database (Project64.rdb) This applies to you if you have added any ROMs to the file or changed any entries for existing ROMs.

Any cheat codes you added are saved the Cheat Code file (Project64.cht), so back that up aswell if you want to keep them.

You input configuration can be exported to a file (see input plugin configuration).

Don't forget to also backup:

• any 3rd party plugins if your plugins folder is a subfolder of your Project64 folder (as by default)
• any save files if your Saves folder is a subfolder of your Project64 folder (as by default).
• any ROM files you may have put in your Project64 folder

 

Project64 v1.6+ has an uninstaller which makes uninstallation very simple: 

1. Go to Add/Remove programs in Windows and find Project64 in the list, highlight it and  click Remove.
   
2. Confirm choice.
   

The install only removes files that it put in your system. Extra plugins, saves etc must be removed by hand, this is for safety to make sure people don't lose saves or anything else.

Background Info for plugins.

Project64 uses an open plugin specification. This means that other people are free to write compatible plugins, which you might like to use in Project64 instead of the ones provided. These may be available standalone or taken from another emulator package - visit some quality websites or use a search engine.

You should first check that the plugin you want to install is to the Project64 specification (sometimes referred to as "Zilmar spec.") and to the correct version of the specification. Consult the plugin or emulator documentation if you are not sure.

Project64 is backwards compatible with all public versions of the specification up the date of its release. (It was not made forwards compatible because there is no way of knowing in advance how the specification might change).

If you attempt to install a plugin that is not to a suitable specification then it should not show up in the menus in Project64.

How To Install Plugins:

Extract the plugin (file ending .dll) and any support files it requires to the root of your Project64 plugin folder (by default, "\Plugin\" subfolder of your PJ64 folder). Start PJ64, go to Options > Settings > Plugins and select the new plugin from the appropriate list and press OK. If the plugin initialises (starts) correctly there will be no error message.

Notes:

1. Remember, if you are using 3rd party plugins the standard Project64 compatibility lists and notes may no longer apply to you!
2. Some plugins require extra DLLs which won't be included with Project64! Consult plugin documentation. Normally these extra files must be put in the root directory (alongside Project64.exe) not in the Plugin folder.
   
3. Generally, if you have problems with a plugin, please consult the appropriate author or group. The Project64 team is not in any way responsible for the performance of 3rd party plugins! Nor can we gaurantee the peformance/stability of the application while using 3rd party plugins.

 

Should be straightforward enough - starting fom the top:

Title bar, showing the internal name of the loaded ROM, followed by the app title and version number. Minimise, maximise and exit buttons. Note that maximise is only available in the ROM browser. If you want to go fullscreen, this is under the Options menu or shortcut ALT+ENTER.

File menu - deals with all ROM loading tasks, Start/End emulation and language selection.

System menu - only available while emulator is running, everything you will need while running games.

Options menu - all configuration is done from here, including access to main settings dialog and plugin selection.

Help menu - access to documentation and About information.

At lower left, the status bar, provides feedback on the current state of the emulator, and is also used for the CPU load statistics if enabled.

At the bottom right, the FPS counter.. note that this displays current VI/s or you can think of it as "Fields Per Second" of the CPU core, not Frames Per Second from the graphics plugin.

• Status and colour coding
• "Notes" fields
• Navigation, Sorting, Configuration

General Points:

1. The ROM Browser does not verify your ROMs! you must use a seperate ROM verification utility in conjunction with it - GoodN64 is what we use and highly recommend. See Reference > Verifying ROMs
2. The "Good Name" is simply a field in the RDB that was filed in with the correct value at the time the RDB was made. It is included for people who have good ROMs without the right names, and to help the RDB author navigate the file, and to make sure we're all using the same names. Don't make the mistake of thinking this verifies your ROMs! See point above.
3. ROMs are identified in the Browser by a pair of CRCs in their header and a country code, which references a pair of CRCs and a country code in the RDB. This means that bad ROMs with codes that match good ROMS will be identified as their good counterparts! See point 1.
4. Status categories, colours and notes come from the RDB file. This is supplied with Project64 but you may edit or change it (advanced users only).
5. Any ROM with status "Unknown" is very likely to be a bad ROM, or should be assumed to be a bad ROM, because (very nearly) all the known good ROMs are in the RDB
6. The Browser uses a cache (it creates a file in the Project64 root folder) to speed loading between sessions. Don't forget to refresh if the ROM folder contents have changed! Project64 does not do this for you.

---

Default Status colour coding:

You are probably famililar with the terms "Playable" and "Not playable" from other emulators. Although these words are easy for beginners, they have limitations which the authors of Project64 wanted to avoid (such as being open to a very large degree of personal opinion). Project64 uses the term "Status". "Status" is a definate category (the categories are explained below) giving a summary judgement about the compatibility of particular game with Project64 as a whole. For precise details, see the Notes fields. Status is a field in the RDB which the RDB author defines based on his and other peoples' experience of the compatibility of each game (this is where some human error inevitably comes in). Project64 uses the Status field to define a colour for each row in the ROM Browser. By default (with the RDB supplied) you will come across some or all of the following colours (depending, of course, on which games you actually have!):

"Compatible" (green)
The game is, to the best of our knowledge, fully playable, with no issues severe enough to seriously effect gameplay. Some judgement exercised here; being green does not equal "flawless", only the original console will guarantee that. Note that system requirements are variable within this category - minimum spec may not be enough to run all "Compatible" games. There is also the possibility of mistakes, because not all games can have been fully tested. However, a lot of these games have been completed in Project64, you should be reasonably confident that you can do the same.

"Issues (core)/Issues (plugin)" (muddy yellow)
These games can be played, but they have moderate to severe issues that may effect your enjoyment of the game. If a game is marked "Issues (plugin)" then switching to another more suitable plugin could resolve the issue. If a game is marked "Issue (core)" then you can't do anything about the problem short of rewriting parts of the core (out of the question for most people!) or looking for a newer/different version or a different emulator altogether. "Issues (mixed)", as you might guess, means that the game shows both core and plugin issues.

"Needs video plugin" (turquoise)
These games are (we believe) supported on the core of the emulator, but are known to have serious enough problems with the default plugins that they cannot be considered playable (although often it's just the menu portion of the game that's missing, and if you can get past this you might be OK). Because of this, and the obvious problems in testing a game we cannot see properly, you should consider core status on these games as being somewhat uncertain also. You need to find a suitable 3rd party video plugin to be able to play this game - one may or may not exist. Check your favourite emulation news sites.

"Needs audio plugin" (turquoise)
As for "Needs video plugin"(see above) but the issue is with the audio plugin rather than the video plugin. This sitaution is very rare.

"Unsupported" (dark red)
These games areknown to not work on the core of the emulator. No amount of plugin switching or settings fiddling will help you here, further (probably highly difficult!) development of the core would be required to get these games working.

"Broken (core)/Broken (plugin)" (brown)
You are advised to use an older version of either the Project64 application or a Project64 plugin to play this game. See Notes for details. Important! See which field the recommended is in. For example, if it says "use older version" in the Notes (default plugins) field, you only have to use an older plugin, NOT an older version of the Project64 application! Remember you can mix and match plugins and executables. Similarly, if it says "use older version" in the Notes (core) field, you should only have to use an older version of the Project64 application - you can continue to use the newer plugins! This way you are not missing out on all the other benefits of the newer versions.

"Region issue" (blue)
This is to let you know that although this ROM doesn't work properly, there is another version of it (i.e. the same game) that does work. Read the note to learn which area of the emulator has the problem and which version of the ROM you should use instead.

"Uncertain" (black)
It could not be determined before release exactly what the status of this game was... you'll have to try it and see for yourself how well it works... check for an updated RDB.

"Unknown" (grey)
This ROM has not been found in the RDB, OR there is no status defined in the RDB by the RDB author. A ROM is marked Unknown probably because it is not a known good GoodN64 ROM, and hence hasn't been included, because only good ROMS are supported in Project64. There is also chance that the reason you are seeing Unknown status is that you have a newer version of GoodN64 than the RDB was based on, so check for an updated RDB. If the ROM is still marked Unknown, you are advised to find an alternative ROM or add it yourself.

---

Notes fields:

Notes (sometimes called "Comments" in other emulators ) are split into two fields in Project64 to reflect the fact that the core and the plugins are seperate and have seperate compatibility. (Each game's status is derived from both the core and the default plugin compatibility considered together).

When reading both Notes fields it will help you to keep this in mind:

• most text is explaining known issues, such as a graphics glitch, that you cannot prevent.
• most instructions to the user start "use..." - pay attention!
• if the notes are particularly complex i preferred to just refer you to the GameFAQ, where i have more space to explain things properly. The GameFAQ is accessible from the Help menu.

Some abbreviation was necessary to keep the notes within the space:

• the colon ":" is used to give an explanation, it stands for "for" e.g. "Framebuffer:flare" is shorthand for "enable Framebuffer for flare".
• the semicolon ";" is used as "therefore" or "so" e.g. "doesn't start; use PAL version" means "the game does not start, so you are advised to use the PAL version (which does)".

some common abbreviations:

• "res." = resolution
• "v." or "ver" = version
• (E), (U) etc. are standard GoodN64 country codes.
• "NTSC" means US, Jap etc
• "PAL" means Europe, Australia etc.
• ? = RDB author was not sure about something!

---

ROM Browser Navigation:

In addition to using the mouse to move around the Browser (scroll bars, mouse wheel and buttons), you may find the shortcut keys speed up your navigation (see below).

You can sort by any column by clicking in the header of that column - click once to sort descending, subsequent clicks reverse the direction of sort.

The browser is highly configurable (see Application Settings).

In case you are not familiar with the N64 console, it has a reset button. Pressing this is equivalent to turning the power off and back on - it's just smoother and quicker. Of course there is no direct power button equivalent on Project64, but the reset is emulated - go System > Reset ROM.

Keyboard shortcut: F1

Some points to note about reset:

1. There is no prompt to reset, so be careful, it happens instantly. Make sure you save your game if you want to, there is no way to go back (undo).
2. On reset, Project64 checks all core settings, so if you have made any changes to the RDB or general options they will take effect now.
3. After resetting, PJ64 has no memory of any state loads before the reset. In other words, the RDRAM (the game's memory space) is totaly wiped clean. This is significant if you are using hacks/cheat codes or have core errors - do a native save, reset the ROM, and load through the game menus. This is a smart dodge that can save you when your states go bad or a combination of cheat codes ruins your game.
4. Project64 (v1.0-1.6) only emulates a Hard Reset, i.e. a full power cycle, it does not emulate the soft reset that some games e.g. Mario64 use slightly differently. There is little need for a soft reset that we can see.
   

  

 

 

There are two main types of save that you need to know about:

• native saves
• state saves

---

General Points

1. It is highly recommended that you make regular native saves. Although state saves usually work OK, this is not guaranteed due to many things that can go wrong in the core and memory of the emulator. Native saves are more reliable (and smaller!) than state saves. By using both methods (rather than just state saves) you have a backup if anything goes wrong.
2. For state saving to work the ROMs must be identical - that is, the ROM that the game was saved from must match exactly the one that the state is loaded into. You may be able to share native saves between different versions of a game, but you cannot ever do this with state saves. Project64 tags state files with ROM header information and will check for and prompt you on violation of this rule.
3. Native save files must not be Read Only, games need to be able to read/write at any time. for example if you back up your save files to a CDR, when you copy them back to your harddrive they may still be marked read-only - you must change the attributes with Windows Explorer. Project64 does not do this automatically, in case you don't want your file to be updated for any reason.

---

Native Saves

To understand the game data saving and loading of Project64, you must also understand the N64's own saving and loading systems (if you aren't already familiar with them), because Project64 emulates all those systems.

There are four types of save system used on the N64...

• EEPROM (a cartridge save type), which comes in two sizes:
  • 4Kbit EEPROM
  • 16Kbit EEPROM
• SRAM (a cartridge save type)
• FlashRAM (a cartridge save type)
• MemPak (an optional hardware accessory for the N64, plugs into controller*)

...which we will call the "native" N64 save systems (to differentiate them state saving, which is something entirely different, see below).

The cartridge save types use either non-volatile memory (EEPROM, FlashRAM) or a battery (SRAM) to keep a small amount of writeable memory intact inside the actual game cartridge, when the power to the console is off. Although it is on the same PCB, this save memory is physically seperate from the game ROM chips - Project64 does not write to the ROM file or anything like that. You don't have to worry about the difference between EEPROM, SRAM and FlashRAM, because all three are handled the same from your point of view. You should be aware that MemPaks, unlike that other save types, can be handled by input plugins, which is logical if you consider the original system again.

1. Whenever an N64 game would save to or load from its game cartridge, Project64 automatically updates a file called {internal ROM name}.{type}** on your hard drive (you can configure folders to choose the location). If this file does not exist, it is created as soon as the ROM is first booted, and is the only file Project64 will use for this game.
2. Whenever the N64 game would save to a Controller Pack (MemPak), either Project64 creates a file on your hard drive, or the input plugin manages the saving process, depending on the capabilties and configuration of the input plugin (see plugin selection and input plugin configuration).

The resulting save files will be compatible with both other N64 emulators and a real N64 system (if you possess the means to insert and extract them (see importing and exporting).

*Mempak is required by some games to save, is an optional extra in some games, is not used at all in some games. Any particular game can use any one cartridge save type, and/or the Controller Pak. This is normally handled transparently by the emulator.

** for example, you are playing the game Mario64. Mario 64 uses the EEPROM save type, and your ROM has the internal name "SUPER MARIO 64". Therefore the save file automatically created and managed by Project64 will be called "SUPER MARIO 64.eep" in your configured folder.

---

State Saves

In addition to emulating the native save types, Project64 is also capable of saving the entire state of itself - everything that it needs to know to recreate an exact point in time during the emulation of a particular game.

can be broken down into two types:

1. slot saves ("Quick Save")
2. named saves ("Save As..."

A game saved and loaded in this way does not "know" that it has been saved and loaded - it is as if the interruption never happened. This is clearly something quite different to what you can do a real N64. This is called "state saving", the resulting file is a "state save" or "saved state", and will be relatively large compared to a native save file.

State save files will not be compatible with other N64 emulators unless they explicitly support the Project64 state save file format (at the time of writing, several do). It is worth noting that a state save file will also save any errors that may have occurred and be present in the memory of the emulator, and for this reason, state saves are generally less reliable than native saves, especially over a long period of time playing.

To provide you with more flexibility in state saving, a number of "slots" are provided. A "slot" is simply a number, which is associated with a particular keyboard key so that you can select the file with a single button press. The advantage of slots is that you save switch between quickly, the disadvantage is that you might have trouble remembering what you put in each slot! Every game has its own independent set of 11 slots, so don't worry about one game overwriting another.

Save As... just means you can choose a filename and location for your state save file. This is good when you finish a session and want to make a note of where you were in the game.

It is normal for the system to pause for a short while while generating, compressing and writing the save file. The quicker your system, the shorter the pause.

• ...to and from other emulators
• ...to and from a real N64 system

Project64 is compatible with the N64 saves (not necessarily state saves) from other N64 emulators and a real N64 system, but you may need to byteswapp the files (use e.g. Azimer's saveswapper utility) and you will definitely need to rename the files to what Project64 expects (see your existing save folder for the correct file name - if you are not sure what the filename should be, save in the game anywhere a file will be created and you can use that name). The format is also explained under "native saves" above.

The advanced cheat system contained in Project64 was developed almost seperately from the rest of the application and is supported seperately aswell. Please use the cheats site link under the support menu.

There are three ways to capture screenshots from Project64:

1. The standard Windows Printscreen function (PRTSCRN or ALT+PRTSCRN, these are keys on your keyboard!)
2. An external capture utility such as "SnagIt"
3. The internal Project64 screenshot function (System > Screen Capture, shortcut F3)

What's the difference between these different methods?

• The Windows function copies the whole desktop (PRTSCRN) or the current window (ALT+PRTSCRN) to the clipboard, you must then paste the data into a suitable application such as Paint or Photoshop. The "clipboard" as it's known can only (usually) hold one shot at a time, so if you take another you overwrite the first. If you take shots while windowed, ALT+PRTSCRN will include the Project64 GUI.
• The Project64 D3D6 capture function writes sequentially numbered Bitmap Image files (snap0000.bmp, snap0001.bmp ... snap9999.bmp) and D3D8 capture function writes sequentially numbered JPEG Image files (ROM File Name snap0000.jpg, ROM file name snap0001.jpg ... ROM file name snapsnap9999.jpg) into the current Screenshots folder (which can be configured in application settings). Even if you take shots while windowed, it will not include the Project64 GUI. You can press the button as many times as you like (given enough storage space, up to 10,000 captures per game!)

---

Important Points:

1. There is no included way to capture a video clip or animation sequence from Project64. You could try an external capture utility such as is provided by Microsoft.
2. Bitmap and JPEG Image files written from the internal function will have the same colour depth as Project64 is currently running in.
3. All screenshots from Project64 or the Project64 video plugin(s) published should credit Project64 and contain a link to the Project64 website please!

If you are finished playing and want to leave Project64 you can simply close the emulator like any normal Windows application (use the X, or File > Exit, or shortcut). There is no need to End Emulation etc. before you quit. If you are going to be away for a short period of time you could leave the emulator paused (by default losing window focus or mininimising the window will automatically pause for you, this is an option under app settings).

Project64 does not prompt you to save and does not save automatically on exit, so do not forget to make a state save if you want to be able to pick up exactly where you left off. You'll probably want to make a named save, so go System > Save As (shortcut) to open the dialogue and type in a path and name you'll remember.

If you want to play a different game,you can go back to the ROM browser to make your selection by choosing File > End Emulation, or you can go ahead and load it directly from File > Open or the Recent ROM menu, even while the old game is running. Project64 will automatically End Emulation of the old game and load and start the new one (without any promps, be careful!).

You can reset/restart/reboot the current game quickly without reloading the ROM.

You can have more than one copy of Project64 open and running at the same time.

The ability to have multiple instances can be a good thing, if you want to compare two windows side by side for example, or a bad thing, if you don't understand that there can be complications, or do it accidently! (i.e. if you start another instance without noticing you already have one running).

Important Points:

1. Only one instance of the emulator can have access to a particular save file at a time. So if you try to open the same game twice, you can expect the second instance to be denied access to the save data, resulting in an error msg.
2. Plugins could act in unexpected ways, depending on how they are written, for example, an audio plugin may only give sound from the first instance, or an input plugin may only send keypresses to the instance that has focus. The default plugins should work with all instances.
3. Following on from the point above, this could also be complicated by your DirectX and hardware and driver capabilties, for example, the number of 3D rendering surfaces your graphics card can manage, or the number of audio streams your sound card can handle. These may or may not be issues on your system.
4. Because the application uses the Windows registry, which is a centralised database, you cannot keep configurations seperate for multiple instances of the same version of Project64. (This was partly an intended effect).
5. Running more than one instance of Project64 increases the system requirements dramatically. Don't expect any instance to run as well as it would on its own, unless you pause the others (if you only have one instance actually running at a time, and have sufficient memory, you shouldn't notice performance problems).

Important Points:

1. The shortcut keys available to you depend on the state of the emulator (this reflects the availability of the associated menu items).
2. Remember you can also navigate the menus with the ALT+(key) indicators, e.g. by default ALT+F opens the file menu, then pressing S would Start Emulation (these keys are set up by the language file so they depend on the file and your current language selection).
3. Note that CTRL+ key combinations open dialogues while F(function) keys have instant effects.
4. F-key shortcuts are available while fullscreen but CTRL+keys are not.
5. You cannot change the shortcut keys in Project64 (but if you have a gamepad with lots of buttons and good software you could map to those).

---

Shortcuts available in browser and during emulation:

open ROM dialog	CTRL+O
settings dialog	CTRL+T
quit application	ALT+F4
start emulation	F11
end emulation	F12

Shortcuts available during emulation:

switch fullscreen/windowed	ALT+ENTER/Escape
reboot ROM	F1
pause/resume emulation	F2
generate bitmap	F3*
enable/disable speed limiter	F4*
state quick save	F5
state save dialog	CTRL+S
state quick load	F7
state load dialog	CTRL+L
select quick state save slot	0-9
always on top toggle	CTRL+A
cheat dialog	CTRL+C
edit cheats	right mouse button*
cheat button	F9

Shortcuts available in ROM Browser:

refresh	F5
jump to top	Home
jump to bottom	End
up one page	Page Up
down one page	Page Down
up one line	Up arrow
down one line	Down arrow
jump to ROM starting with...	0-9 A-Z
start selected game	Enter
open menu	right mouse button

*only available in Advanced mode.

 

 

This is aimed at people who are new to Project64 or emulators in general:

If you accept the following advice as coming from a friend who knows a lot more about the emulator than you (that's me :p), you'll have an easier time of things :) You may think some of the advanced options are obvious but they all have side effects that you cannot possibly guess! (and which i'll go into in depth elsewhere in this manual).

All the default settings of Project64 are very carefully chosen to be (already) correct for the majority of people.

• Don't change plugins! If you change plugins, you change the emulator, and if you change the emulator, I can't help you.
• Don't uncheck "Hide Advanced Settings" in the application or the video plugin. This simple step will keep you away from most of the things you could mess up!
• Don't start using cheat codes straight away - they can cause crashes.

Until you have some experience with the emulator!

All you need to set to start with is {ln:input plugin configuration} (where you set up your controls), {ln:video plugin configuration} (where you set resolutions), and the Options tab (see below).

The first time Project64 is started, it asks you to choose a language. The choices available depend on the contents of the \Lang folder. Project64 ships with a reasonable but of cause far from complete set of translations included (thanks to everyone who made them!). If the language you want is not in the list, seek an updated/alternative file (see Downloads section) or make/edit one yourself! (see Reference section).

To change languages at a later date, use the Language menu under the File menu in Project64. Simply click an entry in the list and you should see the GUI text update immediately. The plugins do not yet support translation

 

(Options > Settings > Plugins)

The choice of plugins has a huge impact on the running of the emulator. It is highly recommended that people new to Project64 do not change plugins until they have used the emulator for a while and familiarised themselves with it. It is also recommended that you change one plugin at a time to start with, so you can see clearly the effects each is having on the system and trace any problems.

It is impossible for me to state here exactly which plugins you should be using, it depends on factors such as:

1. What plugins are available at the time you read this!
2. Which games you play
3. Your system specification
4. Your personal preferences

You will have to read up about the other plugins, try them, ask knowledgable people on the internet for advice, and ultimately decide for yourself which plugins you should be using.

There are three types of plugin that can be selected in Project64. One plugin of each type can be selected at a time via the Project64 Settings dialog. (It is not possible to assign specific plugins to specific games).

1. Video plugin (also called Graphics Plugin)
2. Audio plugin (also called Sound Plugin)
3. Input plugin (also called Controller Plugin)

After reading those sections, if none of the reasons to change plugins apply to you, stick with the defaults! If you are not sure, try the default plugins first and see how you go. There are time tested reasons for this advice.

Each plugin type has an "About" button next to the menu. When pressed, this opens a dialogue from the selected the plugin, which the author of that plugin may use to display information such as his name, the version etc. (It is not compulsory for a plugin author to provide an About box, if not the button will be greyed out - it also not compulsory to provide a configuration dialog - if not, the appropriate menu item will be greyed out).

 

Saving your plugin selection

After making your plugin selection, press OK. If a ROM is currently running, you will be prompted to reset the ROM, because plugins cannot be changed during execution. If you don't want to lose your game position, answer No, save your game, and go back to the configuration. Otherwise, answer Yes. Project64 will immediately attempt to initalise all the plugins, if this is successful the game will boot with the new plugin selection. Your plugin selection is permanently saved by Project64 until you go back to the configuration and change it. If any plugin fails to initialise, you will recieve an error message to this effect - consult the plugin documentation for help with 3rd party plugins.

 

Changing RSP plugin

Since the Project64 GUI does not have an RSP plugin selection, you change RSP plugins by replacing RSP.dll with another file of the same name. (At the time of writing there are no other RSP plugins available).

 

 

Video Plugin Selection

Points:

1. The video plugin interfaces with Project64's RSP. You must have the RSP configuration correct for the type of video plugin (HLE or LLE) you wish to use. Even if you are using an HLE video plugin, the RSP can still be pre-processing some graphics, for example the 2D backdrops in Zelda, this is the default situation. At the time of writing, all N64 emulators are using HLE video, there is no true LLE available.

Reasons to choose a non-default video plugin include:

• a game is marked "Needs video plugin" and you have a 3rd party plugin which you know does support the game
• a 3rd party plugin better supports your (probably legacy) hardware
• video plugins are extremely complicated, there could be many reasons why you would want to change.

 

Audio Plugin Selection

Points

1. The audio plugin interfaces with Project64's RSP. You must have the RSP configuration correct for the type of audio plugin (HLE or 'LLE') you wish to use.

Open the configuration dialogue of the current audio plugin from the Options menu.

Reasons to choose a non-default audio plugin include:

• you have no sound card, or a non-functional sound card - select the dummy audio plugin*
• you want to use HLE audio (perhaps for more speed on a slow system)
• you want adjustable or more advanced sound buffering of a 3rd party audio plugin
• you want e.g. any filtering and advanced processing options of a 3rd party audio plugin

Assuming all those capabilties are available in another plugin, please see Links.

*In this case you should also disable audio emulation in the RSP to save CPU time. Note that some games will not work with a dummy sound plugin selected. For compatibility it is better to simply turn the volume all the way down.

Input plugin selection

Points

1. The input plugin is responsible for handling input (obviously), but also optionally MemPak (depending on plugin capability and configuration) and any other type of N64 controller accessory such as the Transfer Pak or Voice Pak.

Open the configuration dialogue of the current input plugin from the Options menu.

Reasons to choose a non-default input plugin include:

• you want mouse support
• you want "rapid fire" etc. capabilities, macro scripting etc.
• you want modifier capability (analogue movement emulation etc.)
• you want better control over e.g. range and threshold values
• you want Force Feedback support (rumble is broken in v1.6 with default plugin)
• you want direct support for Rumble Pak, Transfer Pak or Memory Pak*

Assuming all those capabilties are available in another plugin.

*at the time of writing, only available for the Adaptoid and with N-Rage's input plugin or the Adaptoid plugin.

 

Configuration: Options
Options > Settings > Options

---

1. "Pause when window loses focus"
2. "Fullscreen automatically after loading games"
3. "Remember selected cheats for games"
4. "Hide Advanced settings"

---

"Pause when window loses focus"

• default setting: enabled
• generally recommended setting: user preference!

If enabled, the emulator will pause when it detects that it no longer has focus in Windows. This is useful if you are multitasking and want the emulator to pause whenever you go to another application.

If disabled, the emulator will carry on running regardless of whether or not it has focus. Use this if you want Project64 to carry on running in the background while you do something else (you can still keep it always on top with the Always on Top option!). Note that if this option is unchecked the peformance of Project64 will probably be lower while focus is lost because of the way Windows handles resources. This is normal and not a fault of Project64.

---

"Fullscreen automatically after loading games"

• default setting: disabled
• generally recommended setting: disabled

If enabled, Project64 will automatically instruct the video plugin to switch to fullscreen once after loading each ROM. This is good (saves you a key press) if you know a game works and doesn't need any configuration changes. You can still return to windowed mode in the usual ways (Escape, ALT+ENTER).

If disabled, games will start windowed. You can switch to fullscreen mode yourself in the usuall ways (Escape, ALT+ENTER, Options menu). This is a little more work (one key press) but recommended, because you can make sure your configuration (particularly graphics plugin tabs) is correct before getting into your game.

Notes:

• The emulator actually goes fullscreen before starting emulation. This is so that plugins/hardware that only work in fullscreen can be supported. If you have such a plugin or hardware then you must enable this option!
• Don't enable this option with "Start emulation after ROMs are opened" (Advanced) disabled! It will go fullscreen but you your games won't start, which could be confusing...
• The RDB can override this option and prevent automatic fullscreen on a defined status (by default, games with status "Unsupported"). Hopefully it's obvious why this is done; if you don't like it you can either edit the RDB to remove the line from the status definition, or you could change the status of the game(s).

---

"Remember selected cheats for games"

• default setting: disabled
• generally recommended setting: disabled

If enabled, Project64 will save your cheat code selection between sessions. This is for your convenience, and it means that if you close the emulator and go away, then play some hours/weeks/anytime later, the same cheat codes will be applied as before... this is important to keep in mind if your games are acting strangely!

If disabled, the cheat code selection is lost as soon as you load a new ROM, or quit the application, whichever happens first. This is recommended because cheat codes tend to cause problems...

---

"Hide Advanced settings"

• default setting: enabled
• generally recommended setting: beginners should keep this enabled, advanced users should disable it.

This is a very important control and new in v1.5. When enabled, most of Project64's other controls are hidden from the user. This is because casual fiddling by inexperienced users tends to result in people getting themselves into a mess. It is therefore highly recommended that new users, people with low technical/emulator expertise, and young children, to give a few examples, use the application with this option enabled - the emulator runs just as well will this on or off!

---

 

Configuration: ROM Browser
Options > Settings > ROM Selection

This tab is only available if Hide Advanced Settings is unchecked!

---

• Enable/Disable the Browser completely by toggling the Use ROM Browser checkbox
• Enable/Disable Directory Recursion by toggling the Directory Recursion checkbox
• Add or Remove fields from the Browser by selecting (click on) the field you want to add or remove and clicking the Add or Remove button.
• Change the order of fields by clicking the field you want to move and clicking Up or Down. Top to bottom in the window represent Left to Right in the browser.

The following customisations can be made from within the browser itself:

• Resize the browser window by dragging the window edges
• Maximise/Restore the browser window with the maximise/restore button
• Resize the width of any column by dragging the edge of the column header
• Sort by any column by clicking inside the column header. You can sort in either direction by repeated clicking.

Configuration: Folders
Options > Settings > Folders

This tab is only available if Hide Advanced Settings is unchecked!

---

N.B. It is purely a matter of personal preference how you set these folders, but you must have the Plugin folder set correctly for Project64 to start up properly, if valid (working) plugins aren't found at the configured path when Project64 is started, you cannot start games. This is by design - plugins are an essential part of the system. You can of course still get into Options to correct the paths.

Project64 allows you to set up to 5 different folders:

1. Plugin folder - all the plugins you want to be available to Project64 must be placed together in one folder, by default \Plugin\ subfolder of main Project64 folder
2. ROM folder - by default Project64 remembers the last used folder and opens to this folder, but if you want to force it to always use the same folder you can.
3. Native save folder - all the native save types generated will be placed together in this folde, by default \Save\ subfolder of main Project64 folder
4. State save folder - if you use state slots, all files generated will be placed in this folder, by default the same folder as for native saves.
5. Screenshots folder - this information is passed to the video plugin for its screenshot function, by default \Screenshots\ subfolder of main Project64 folder

Each folder can either use a default path, or one that you choose.

You can either type a path in directly, or browse to a folder by pushing the "..." button. Press OK and it will fill in the path for you.

Press OK to save your changes.

 

(Options > Settings > ROM Settings)
Note: This tab is only available if Hide Advanced Settings on Options tab is unchecked

This tab covers configuration of the core for each individual ROM. Some of these settings are also available under the General tab, and although the settings have the same meaning there, they have a slightly different purpose.

Controls available:

1. "R4300i core"
2. "Self -mod. code method"
3. "RDRAM size"
4. "Advanced Block Linking"
5. "Cartridge save type"
6. "Counter Factor"
7. "Larger Compiler Buffer"
8. "Use TLB"
9. "Register Caching"
10. "Delay SI interrupt"
11. "SP Hack"
12. "RSP Audo Signal"

 

Points

1. It is highly recommended that you do not make any changes here unless you understand exactly what you are doing. Understanding what you are doing takes experience that cannot be obtained from this manual alone. You are likely to reduce performance and/or stability.
2. The emulator is (hopefully!) supplied with the optimal configuration for (almost) every game!
3. When you make changes here, you are actually editing the Project64 ROM Database (the file Project64.rdb). You can also edit this file directly in a text editor - advanced users only! If you get in a mess, the only way to go back to the supplied settings is to replace Project64.rdb (from the original downloaded archive). There is no "reset to defaults" button or similar, because the settings are unique for each ROM, so be careful.

---

"R4300i core"

Possible settings:

1. * use general setting
2. Interpreter
3. Recompiler
4. Synchronise Cores (debug builds only)

• default setting: * use general setting (by default: Recompiler)
• generally recommended setting: Recompiler if it works

The Recompiler and Interpreter are two seperate cores in the emulator (although the Recompiler implementation is based on the Interpreter). Generally, any game that works on the Recompiler will also work on the Interpreter, but not always vice-versa. Explaining the difference between a Recompiler and an Interpreter in a general sense is beyond the scope of this document, suffficient to say that the Recompiler is (usually much) faster but (a little) less compatible, the Interpreter (usually much) slower but (a little) more compatible. If you have a fast enough PC that peformance is not an issue for you, you can probably use the Interpreter all the time, but i wouldn't recommend it since it generally shouldn't offer much advantage.

Note that if you are using the Interpreter, the following settings are ignored (they are only relevant to the recompiler):

• Self. mod code method
• Advanced Block Linking
• Larger Compile Buffer
• Register Caching

---

"Self -mod. code method"

Possible settings:

1. * use general setting
2. None
3. Cache
4. Check Memory & Cache
5. Check Memory Advance
6. Change Memory & Cache
7. Protect Memory

• default setting: * use general setting (by default: Check Memory Advance)
• generally recommended settings: highly game dependant! (see below)

Many games use "self modifying code". In a nutshell, this makes them harder to keep running during play. Project64 has several methods of dealing with these situations, which range from fast at one end to more secure (stable) at the other. In order from fastest to most secure these are:

None > Cache > Check Memory and Cache > Check Memory Advance > Change Memory and Cache > Protect Memory

If a game does not use self modifying code (e.g. Mario64) this can be set to None (but read notes below). A typical self modifying code game such as Zelda (and many others) are optimal on "check memory and cache" or "change memory and cache" or "check memory advance" (depends on game). Some games will only run stable on "protect memory", which is a very secure method. Some trial and error is needed for you to find out which setting is best - you are looking for the fastest method that doesn't crash.

Notes:

• Which is most secure out of Check Memory Advance and Change Memory & Cache depends very much on the particular game, sometimes one is more secure, sometimes the other.
• In general, Check Memory (either variant) and Change Memory & Cache are the most useful self. mod code methods, offering a good balance of performance and stability.
• Unfortunately sometimes a game will be fine on one method (e.g. Check Memory & Cache) except for one single point where it fails, and Protect Memory is needed. If you find this is the case, and Protect Memory is significantly slower, try changing back to Check Memory and Cache after you have passed the point.
• For reasons unknown to me, if you aren't using Advanced Block Linking, some games that don't use self mod. code need a self mod code method set. Cache is sufficient. This should already be set by RDB, this is just a warning.
• Protect Memory can cause severe slowdown, either all the time a game is running, or during particular periods, and in rare cases a game will not work at all with it. Only use Protect Memory when necessary.

---

"RDRAM size"

Possible settings:

1. * use general setting
2. 4MB
3. 8MB

• default setting: * use general setting (default: 8MB)
• generally recommended setting: 4MB, unless needed.

An emulated RDRAM size of 4MB is the standard amount of memory an N64 console has.

An emulated RDRAM size of 8MB represents an N64 console with the 4MB memory expansion accessory installed, plus the original 4MB. This results in larger state saves and can lower performance. Most games do not benefit at all from the Expansion Pak. Some games require the Expansion Pak (e.g. Zelda2), some games give you more with it (e.g. Perfect Dark), some games just use it to raise resolution (in which case we recommend you don't use the Expansion Pak since graphics are HLE anyway, see below).

Notes:

• if a game supports the Expansion Pak as an option it will usually tell you in its introduction screens (usually two lines, like "Expansion Pak supported, Expansion Pak detected"). If a game doesn't support the Pak, or absolutely requires it, it probably won't say anything.
• you gain nothing by using the Expansion Pak on a game that doesn't support it - you just waste resources.
• further, if a game has optional Expansion Pak support where the Pak is used only to raise screen resolution, it is generally recommended you set this to No, because there's no point wasting resources on higher native resolutions when the graphics are high level emulated (hence largely resolution independant) anyway, also it can often cause severe aspect ratio problems in the video plugin.
• in rare cases, for reasons unkown to me, the Project64 video plugin requires the Expansion Pak to avoid an Access Violation (even in games that don't use the Expansion Pak). The RDB is already set up for this for all known cases.
• the above two points explain why the setting may sometimes appear to be logically incorrect - it has been set that way for a good reason!
• this setting should already be correctly configured for every game by the RDB, don't change it unless you know what you're doing!

---

"Advanced Block Linking"

Possible settings:

1. * use general setting
2. Off
3. On

• default setting: * use general setting (default: On)
• generally recommended setting: highly game dependant! (see below)

Advanced Block Linking is one of Project64's speed optimisation techniques - it usually provides a speed vs. smoothness tradeoff that you'd want to set globally (for all games) under the General tab, according to whether you have a fast or slow PC. On is usually (often significantly) faster than Off but may be less smooth. This depends on the game. Afew games run particularly badly with this On, or may require this to be On or Off, which is why the RDB sometimes does set this control.

---

"Save type"

Possible settings:

1. * detect first used type
2. 4kbit EEPROM
3. 16kbit EEPROM
4. 32kbyte SRAM
5. 128kbyte FlashRAM

• default setting: * detect first used type
• generally recommended setting: * detect first used type, unless game uses 16kbit EEPROM or a copy protection system that tries to trick the emulator into using the wrong save type.

You can set any of the four possible native cartridge save types here, but the only one that should be needed is 16kbit EEPROM, because it is not possible for the emulator to detect the difference between a game asking for 16kbit and a game asking for 4kbit - Project64 assumes 4kbit, the more common size. If a game actually needs 16kbit it will either fail to save or not boot unless set to 16kbit EEPROM. The other settings are included for the rare possibility that the autodetect goes wrong - generally, don't set them. Note that MemPak is treated seperately and will work in addition to whatever is selected here.

---

"Counter Factor"

Possible settings:

1. * use default (2)
2. 1
3. 2
4. 3
5. 4
6. 5
7. 6

• default setting: * use default (2)
• generally recommended setting: 1 or 2 (possibly 3, see below)

Counter Factor effects the timing in the core, it's a difficult option to explain, what you need to know is that 2 is the default and best speed you can get in most games without causing problems like missing video frames, 1 is required by some games to prevent flicker or optionally to increase smoothness, and 3 is a possibility for some games to improve performance. Values higher than 3 are likely to cause severe frame loss, leading to instability. But in the hands of experienced users this setting can be used as a crude form of frame-skip. Experienced users only!

---

"Larger Compiler Buffer"

Possible settings: checked or unchecked

• default setting unchecked
• generally recommended setting: unchecked unless it helps

Some games generate particularly complex code structures which tend to overlow the default 20MB compiler buffer and temporarily stall the system, causing a pause in gameplay. By enabling this a game will be given a 50MB buffer, which obviously increases resource usage but may help reduce occurence of overflows and thus improve performance. Most games do not need more than 20MB hence this will usually only waste resources.

---

"Use TLB"

Possible settings: checked or unchecked

• default setting: checked
• generally recommended setting: unchecked if not needed, checked if needed.

This is another highly technical core feature, it's part of the N64 CPU, used extensively by some games (Goldeneye, Mario etc) and not at all by others (Zelda, Banjo etc). If a game uses the TLB (end user can't tell this without knowing or by trial and error) then this must be enabled or the game will fail with various error messages, usually soon after boot. TLB is an option mainly because you can gain some performance by turning it off where not needed.

---

"Register Caching"

Possible settings: checked or unchecked

• default setting: checked
• generally recommended setting: checked, unless it causes a failure.

Probably the recompiler's most significant optimisation technique, register caching usually dramatically improves the efficiency of the recompiler, and usually without side effects. The reason this is included as an option is that sometimes register caching will produce an error in a game. Register caching can cause many kinds of obscure errors, such as events in a game not triggering, or a game becoming stuck in a loop, or graphics being messed up, aswell as obvious errors such as a crash. If you find you are having stability problems with the recompiler and not the interpreter, try disabling register caching to see if you can get past the point/game with at least some of the performance of the recompiler.

---

"Delay SI interrupt"

Possible settings: checked or unchecked

• default setting: unchecked
• generally recommended setting: unchecked unless needed

This option was added in v1.5 to help a small number of games that were broken in v1.4. It's simply either needed (for example Cruis'N USA) or it isn't. Usually it isn't.

---

"SP hack"

Possible settings: checked or unchecked

• default setting: unchecked
• generally recommended setting: checked unless it causes failure

This option was added in v1.5 simply as a performance feature - enabling it gives typically 5% more speed from the core, however a large numbe of games will not be stable with it enabled, therefore it's not set often. Try it if you are desperate for speed, but for most people most of the time it's recommended you leave it off.

---

"RSP Audo Signa"

Possible settings: checked or unchecked

• default setting: unchecked
• generally recommended setting: unchecked for most, but enabled for certain specific games.

This option has allowed for some once unsupported Musyx games like: Hydro Thunder, NBA Showtime, Disney’s Tarzan  to be playable with either loading with sound available or now accessing speech although not perfect in games such as The World is Not Enough and Resident Evil 2.

 

Configuration: Shell Integration
Options > Settings > Shell Integration

This tab is only available if Hide Advanced Settings is unchecked!

---

Associating your ROM files with Project64

1. Go Options menu > choose Settings > Shell Integration tab.
2. Check each box that has a file extension your would like associated with Project64.
3. Press OK.
4. All your file icons may flash a few times - this is normal.
5. In Windows, you will see your ROM icons change to the Project64 icon.
6. You can now start a game by double clicking a ROM in Windows.

---

Removing ROM file associations from Project64

1. Go Options menu > choose Settings > Shell Integration tab.
2. Uncheck each box that has a file extension you don't want associated with Project64.
3. Press OK.
4. All your file icons may flash a few times - this is normal.
5. In Windows, you will see your ROM files lose their Project64 icon.
6. You cannot now start a game by double clicking a ROM in Windows.

 

Configuration: Advanced
Options > Settings > Advanced

This tab is only available if Hide Advanced Settings is unchecked!

---

Upper tab - Core Defaults (drop down menus):

1. R4300i core
2. Self-mod code method
3. Expansion Pak
4. Advanced Block Linking <- Important control, read this!

Lower tab (checkboxes):

1. "Start emulation after ROMs are opened"
2. "Overwrite these default settings with ones from RDB"
3. "Zip compress all state saves"

 

---

"R4300i core"

• default setting: Recompiler
• generally recommended setting: Recompiler (should not matter if using RDB)

Setting explained under ROM Settings. This setting can be overriden on a per-ROM basis (by the RDB, see ROM settings), if "Overwrite these default settings with ones from RDB" is enabled and a value is set in the RDB - this control will then be ignored.

Notes:

• Project64 was only tested extensively on the Recompiler, with the Interpreter used as a backup if the Recompiler failed - if you set this to Interpreter, there is a (small but real) chance that some games with not work - be prepared to put games back to using the Recompiler on a per ROM basis.

This is almost always set by the RDB, therefore this control is not normally used.

---

"Self.-mod code method"

• default setting: Check Memory Advance
• generally recommended setting: Check Memory Advance (should not matter if using RDB)

Setting explained under ROM Settings. This setting can be overriden on a per-ROM basis (by the RDB, see ROM settings), if "Overwrite these default settings with ones from RDB" is enabled and a value is set in the RDB - this control will then be ignored.

Self.-mod code method is almost always set by the RDB because the optimal value should be known by the RDB author. It won't be set (in Official files) if the RDB author couldn't determine the correct value (prompting you to find it yourself). Therefore it should not matter what you set this control to.

---

"Expansion Pak"

• default setting: Yes
• generally recommended setting: No (should not matter if using RDB)

Setting explained under ROM Settings. This setting can be overriden on a per-ROM basis (by the RDB, see ROM settings), if "Overwrite these default settings with ones from RDB" is enabled and a value is set in the RDB - this control will then be ignored.

Generally I suggest setting this to No because most games don't need the Expansion Pak and you are only wasting resources... the RDB should enable the expansion pak when it is appropriate.

Expansion Pak should always be set by the RDB. Therefore it should not matter what you set this control to.

---

"Advanced Block Linking"

• default setting: On
• generally recommended setting: Off, unless you need the speed (see below)

Advanced Block Linking is one of Project64's speed optimisation techniques, although this is available in ROM Settings, the setting on this tab will be in effect most of the time. Where this is the case (i.e. where ABL is not being forced by the RDB) this control is a performance option for the recompiler, where setting On gives more speed (higher maximum and overall average speed) and setting Off gives better "smoothness" (higher consistency of speed, less variation from one part of a game to another, fewer jerks and slowdowns, but a lower overall speed). The effect of having ABL on vs. off is probably most noticeable in fast moving racing games such as Didddy Kong Racing and Mario Kart.

This setting can be overriden on a per-ROM basis (by the RDB, see ROM settings), if "Overwrite these default settings with ones from RDB" is enabled and a value is set in the RDB - this control will then be ignored.

Notes:

• Project64 game compatibility was only thoroughly tested with ABL enabled, due to time constraints. If you turn ABL off, there is a possibility that some ROMs may need their settings adjusted - occasionally a higher self-mod code method is needed. There is also a chance that some games will not work at all with ABL turned off, so be prepared to turn it back on on a per-ROM basis.
• Some background info: ABL is not new to Project64 1.4+. The emulator was always using ABL, what is new in 1.4+ is the ability for you to turn it off! During the early stages of Project64 development performance was a major concern, but we expect Project64 to perform better on future PCs without ABL.

This is NOT normally set by the RDB, therecore this control IS normally used! (unlike all the other controls on Advanced tab)

 

---

---

 

"Start emulation after ROMs are opened"

• default setting: enabled
• generally recommended setting: enabled, unless you want to edit RDB before boot (see below)

If enabled, Project64 will (always) begin emulation immediately after a ROM has finished loading. This is usually what you would want to happen, it saves you having to press "Start Emulation" in the file menu every time you want to play a new game.

If disabled, the emulator will wait, with the ROM loaded, until you press Start Emulation to boot the ROM, or do something else. This is to allow you to edit ROM settings before booting the ROM (otherwise you would need to edit settings while the ROM is running and then reset it, which is normally OK but creates a catch-22 if, with the current settings, the ROM is not bootable!).

Changes take effect at next ROM boot.

---

"Overwrite these default settings with ones from RDB"

• default setting: enabled
• generally recommended setting: enabled

If enabled, the Project64 core will use the settings defined in the RDB for each ROM, unless no entry exists, or the settings in the RDB are "Default" or "Global", in which case the settings defined on the lower half of this tab will still be used.

If disabled, the core settings defined in the RDB will be ignored, and all the default settings defined on the lower half of this tab will be used, for every game. Settings that cannot be defined on this tab will take the default values as explained in ROM Settings.

Notes:

• If you want to see which value is actually being used at any particular time, check the ROM Settings tab while the game is running.
• There is little reason why you should ever turn this option off - Project64 requires carefully considered per-game settings for good results, and many important options (e.g. Register Caching) can only be set by the RDB file. This option is included mainly for the developers and advanced users testing games.

Changes take effect on the next ROM boot, or when current ROM is reset.

---

"Zip compress all state saves"

• default setting: enabled
• generally recommended setting: enabled

If enabled, Project64 will zip compress state save files (Slots and Save As...). This may increase the time taken to complete save operations, but the advantage is the reduced hard drive space usage per save (typically half to a third the space).

If disabled, Project64 will write normal (uncompressed) state save files. This may be quicker, depending on your system, but will definately use more storage space (files will be 4MB or 8MB depending on whether or not the Expansion Pak is enabled).

Notes

• this setting makes no difference to the loading of state saves - you can still load a compressed state if this is disabled.
• you cannot adjust the level of compression, a medium level was chosen by the authors.
• there is no compression for native saves, the files are so small the authors decided it wasn't worth the extra hassle for them or the user.

Changes take effect immediately, or when the next state save is made.

This page covers configuration of one tab of the default Project64 video plugin.

1. Video Card [label]
2. "Windowed Resolution" [menu]
3. "Fullscreen Resolution" [menu]
4. "Full Screen Sync" [menu]
5. "Anisotropic filtering" [Slider]
6. "Full Scene Antialiasing" [Slider]
7. "Brightness" [Slider]
8. "Super2xSaI textures" [checkbox]
9. "Always use texture filter" [checkbox]
10. "Hide Advanced Settings" [checkbox]

---

"Video Card" [label]

This is your graphics card name as known by Windows - in v1.6 the plugin is autodetecting a number of features based on your hardware capabilities, although the name is not used directly, this is simply here as a reminder for you when you are configuring the plugin, and if you ever need support online.

---

"Windowed Resolution" [menu]

The menu lists all standard resolutions from 320x240 up to 1600x1200.

• default setting: 640x480
• generally recommended setting: 640x480, or your preference.

This control sets the resolution of the window, or to put it another way (since your screen resolution is not changed) the size of the window.

Notes:

• plugin window resolution and position is independant of the Project64 ROM Browser window resolution and position. This is by design, it may seem strange to you at first.
• large windowed resolutions can reduce performance, it's usually better to go fullscreen.
• see points at top about resolution choices.

About resolution selection:

1. The N64 has a low native resolution compared to typical PC resolutions, N64 games are designed in the range 320x240 - 640x480. This means that choosing high resolutions can create a noticeable distinction between 3d parts and 2d (pre-rendered bitmap) parts of a scene, in games that mix the two (e.g. Zelda). Arguably the best appearance is achieved by using a "low" resolution such as 640x480 and a high level of FSAA.
2. Although the plugin allows you to set any resolution, you should really only use ones that are exact multiples of native n64 resolution (which you can assume is 320x240), such as 640x480 and 1280x960. Using other resolutions, particularly ones with non 4:3 aspect ratios (4:3 is the aspect ratio of a conventional TV set), can lead to image distortion that is very noticeable in some games. The decision is left up to you however.

Changes take effect immediately.

Widescreen windowed resolutions

848x480, 1024x576 and 1380x768 (depending on your desktop full screen resolution) will make PJ64 windowed act like a WS view for a delightful new gaming concept, although still in its experimental stage! try playing Zelda OOT or MM with "adjust aspect ratio..." checked in the ROM Settings tab for a proper generated widescreen with correct aspect that even the real N64 can't produce :)

---

"Fullscreen Resolution" [menu]

What is available in this menu depends on what is detected on your system. If a mode that you wish to use is not available, consult your graphics card documentation, because it's a problem with your graphics card or drivers, they either cannot do the mode or the drivers are reporting wrongly.

• default setting 640x480 16-bit 60 Hz (Refresh Rate)
• generally recommended setting: 640x480 32-bit, 1280x960 32-bit or your desktop resolution (see below)

The plugin enumerates and lists all available modes on your system in this menu, in the format: (Horizontal Resolution) x (Vertical Resolution) x (Colour Bit Depth)

Notes:

• If 24 bit colour modes are listed, do not select them. Most graphics cards cannot render 3D in 24 bit colour, or they are slower - choose a 32 bit colour mode instead.
• Do not select a mode that you know your graphics card cannot render 3D in (as a limitation of your graphics card) - for example any 32 bit colour mode on a 3dfx Voodoo3.
• if you match the fullscreen resolution to your Windows desktop resolution and colour depth, you will be able to switch the emulator quickly between windowed and fullscreen mode without your monitor having to re-synchronise. However, your desktop resolution may not be a good choice... I happen to use 1280x960x32 as my normal windows resolution, which is also a good N64 resolution.
• see points at top about resolution choices.

Changes take effect next time you go fullscreen.

See points under "Windowed Resolution" above!

---

"Full Screen Sync" [menu]

What is available in this menu depends on what is detected on your system, out of a maximum 5 possible settings. If you want to use a setting not available, consult you graphics card documentation.

1. Transfer Memory
2. Double Buffer Vsync
3. Triple Buffer Vsync

• default setting: Transfer Memory
• generally recommended setting: Triple Buffer

Transfer memory means use no extra buffering. This saves video card memory and may be the best option on cards with limited memory. However, all modern cards should be able to buffer without penalty, I suggest you try triple buffering. The other choice is whether you want Vsync or not (see Glossary), I personally prefer not to use Vsync. Note that use of Vsync also depends on your graphics card driver settings, it may already be forced on or off there.

Changes take effect next time you go fullscreen. This control does not apply to windowed modes.

---

"Anisotropic filtering" [Slider]

If the checkbox is greyed out, the plugin has detected that your system (hardware/drivers) is not capable of any level of anisotropic filtering. If the slider remains greyed when the checkbox is enabled, the plugin has detected that your system is only capable of one level of anisotropic filtering (2x - this is true of all GeForce1 and GeForce2 class systems). The range of anisotropic filtering levels available depends on your hardware and drivers. Consult system documentation if you need further assistance.

• default setting: Off
• generally recommended setting: enabled and as high as possible without losing performance.

If enabled, the plugin instructs your graphics card drivers to use anisotopic filtering. This can improve texture filtering quality dramatically, with a possible performance cost. (A good place to see this difference is e.g. on the grass in Zelda, looking in the mid to far distance).

If disabled, you will get standard bilinear texture filtering from your graphics card.

---

"Full Scene Antialiasing" [Slider]

If this option is greyed out, the plugin has detected that your system (hardware/drivers) is not capable of any level of anti-aliasing. Consult system documentation if you need assistance.

• default setting: Off
• generally recommended setting: enabled

Usually referred to as "FSAA" (Full Scene Anti-Aliasing), this option simply instructs your video card drivers to enable anti-aliasing. The results (performance and quality effects) depend on your ardware capabilities, drivers and configuration. Consult your system documentation for further information.

Notes:

• nVidia's drivers appear not to suppport this function in DX6. If you have nVidia hardware you will probably need to force anti-aliasing using via your driver controls or a driver tweak utility.
• This control will work both windowed and fullscreen, provided your graphics card is capable of both.
• Some graphics cards may require a particular Buffer Display Mode selected for FSAA to work when in fullscreen (e.g. the Voodoo5 probably won't give you FSAA if set to Transfer Memory).

Setting may require restart of ROM or App for changes to take effect

---

"Brightness" [Slider]

• default setting: Off (100% game default)
• generally recommended setting: user preference (ideal for dark games likes Doom64, Quake II etc) GF2 cards or lower are not supported on this function.

---

"Super2xSaI textures" [checkbox]

• default setting: disabled
• generally recommended setting: disabled \ user preference

doubles the size of textures using a special enhancement filter so you can get the best overall experience with it. there may be a small performance hit when you use this enhancement but the effect in most cases would be worth it.

---

"Always use texture filter" [checkbox]

• default setting: disabled
• generally recommended setting: disabled, for most games

Forces rendered primitives to be alpha tested for transparency, then blended with the frame buffer. Generally, this causes more problems than it fixes, even within one game, but it can sometimes help, particularly with sprite edges. See browser notes for occasional advice as to when this is required (rare).

---

"Hide Advanced Settings" [checkbox]

• default setting: enabled
• generally recommended setting: disabled once you have read all this documentation!

When enabled both the Advanced and ROM Settings tabs of the video plugin configuration dialog are hidden from the user. This is to make Project64 easier and "safer" for beginners to use. You will probably find you need to disable this at some point to get access to the full range of controls, however note that casual fiddling with the options will cause problems, so don't touch anything you don't understand, and remember what you changed!

 

(Options > Configure graphics plugin... select Advanced tab) Hide Advanced Settings on Settings tab must be unchecked for this tab to appear.

This page covers configuration of one tab of the default Project64 video plugin.

All settings on this tab are saved in the registry and apply globally i.e. to all games.

Controls available:

1. "Adjust game aspect ratio to match yours"[checkbox]
2. "Use legacy pixel pipeline"[checkbox]
3. "Force alpha blending" [checkbox]
4. "Wireframe Rasterization" [checkbox]
5. "Use Direct3D transformation pipeline" [menu]
6. "Force Z compare" [checkbox]
7. "Copy framebuffer to RDRAM" [checkbox]

---

General Points:

1. As the tab name suggests, these options have some quite difficult to understand effects. Do not turn any of these option on unless you've first read and understoof the explanations below.
2. These options are all OFF by default for a good reason - in general they cause more problems than they fix!
3. If you turn any of these things on, don't forget that you've done it! What works in one game may cause problems in another.

---

"Adjust game aspect ratio to match yours" [checkbox]

• default setting: disabled
• generally recommended setting: disabled.

if the game doesn't support the aspect ratio for the display you have chosen this will change it manually but may cause problems

---

"Use legacy pixel pipeline" [checkbox]

• default setting: disabled
• generally recommended setting: disabled

Use this option on high end video cards if you experience problems with coloration or blending

---

"Force alpha blending [checkbox]

• default setting: disabled
• generally recommended setting: disabled, for most games

Forces rendered primitives to be alpha tested for transparency, then blended with the frame buffer. Generally, this causes more problems than it fixes, even within one game, but it can sometimes help, particularly with sprite edges. See browser notes for occasional advice as to when this is required (rare).

---

"Wireframe Rasterization" [checkbox]

• default setting: disabled
• generally recommended setting: disabled

If enabled, all graphics in the scene will be rendered as triangle edges only. This is mainly a novelty feature for the end user, with one particular use to gamers - it allows you to see objects that would normally be hidden behind others. Some games (e.g. Mario64) "smear" with Wireframe Rasterization, others work as expected.

If disabled, graphics are rendered normally, i.e. solid with lighting etc.

Setting only holds for the current session (until you End Emulation).

---

Use Direct3D transformation pipeline [checkbox]

• default setting: disabled
• generally recommended setting: disable

The internal pipeline has been improved to the point where it almost always works, therefore this control is kept mostly for debugging purposes and cases where it is faster.

If unchecked, the plugin will use it's own geometry transforms engine develeoped by the plugin author. This is usually more accurate (than the alternative, see below), and is required by some games, but it may be slower, depending on system. It is also missing some standard geometry engine features, and therefore requres your hardware to perform certain tasks that not all hardware can do (guard band etc.). The internal pipeliene has border control, meaning the edges of games with borders should be kept clean.

If checked, the plugin will use standard DirectX transforms. This could be faster on some systems, and should work on all graphics cards, but it's less accurate, hence not recommended. Some games will not work at all with external transforms. The external pipeline does not have border control so the screen edges may get messy.

---

"Force Z compare" [checkbox]

• default setting: disabled
• generally recommended setting: disabled

This forces the relevant depth buffer operation to execute even if the N64 turns them off. This can solve some game or system compatibility issues. It is highly game and situation dependant, refer to browser notes for any games or situations that require this enabled (they are sometimes refered to as FDE/FDC). Try enabling if you notice depth problems, i.e. objects being front of objects that they should be hidden behind. Do not leave these controls enabled generally however, they are known to cause complications with many games.

---

"Copy framebuffer to RDRAM" [checkbox]

• default setting: disabled
• generally recommended setting: disabled

This is a framebuffer control. Some games use the screen itself as a texture within the game. A classic example is the board ("jumbotron?") above the bridge in the first level of Mario Kart 64. This has a very serious performance impact, due to PC architecture (data must be copied from video card back into system memory every frame) so if enabled it will make the game run very slow and you will be better off without that kind of loss to performance.

Untitled Document Direct3D8 Video Configuration - ROM Settings tab

This page covers configuration of one tab of the Project64 default video plugin. About other plugins.

All settings on this tab are saved in the RDB and are specific to each ROM. The controls on this tab are only available when a ROM is loaded, and will only affect the currently loaded ROM. Unlike core ROM Settings, all changes take effect instantly. The emulator should be supplied with the correct settings for each ROM - do not make any changes here unless you understand what you are doing. If you mess up the settings, you must reinstall Project64 (or at least, revert to the original (or better yet, the latest official) RDB - there is no "return to defaults" button, so remember what you changed!

1. "Emulated Width" [text box]
2. "Emulated Height" [text box]
3. "Direct3D Clear Mode" [menu]

Note that there is one further setting that you should be aware of that cannot be controlled from this tab, because it works not on a per-ROM basis but on a per-calculated-uCode-CRC basis: this is detection of the RSP code simulation, or uCode detect for short , i'll cover it here this page.

---

"Emulated Width" [text box]

This refers to the native horizontal resolution of the game. This is normally autodetected correctly by the plugin, however in some cases this can go wrong, hence this control is available to allow you to force any resolution. Values must be integers (whole numbers). A sensible place to start is 320, the horizontal resolution of most N64 games.

Note that this control cannot be used effectively when a game has dynamic or mixed resolution!

---

"Emulated Height" [text box]

Exactly as per "Emulated Width", except for vertical resolution, tends to be used more often to correct PAL resolution problems, and has a typical value of 240.

Note that this control cannot be used effectively when a game has dynamic or mixed resolition!

---

"Direct3D Clear Mode" [menu]

Possible settings:

• Default (0)
• Only per frame (1)
• Always (2)

The default setting ("default") means none and was always used in previous versions of the plugin.

"Only per frame" is a possible solution for games suffering from the "black layer" problem, where the whole screen is hidden behind a black layer. This was added in v1.5 for Chameleon Twist 2 and is also used for several other games.

"Always" is a possible solution for games suffering from screen clearing problems within a particular part of the screen. It was added in v1.5 for the sky in Perfect Dark, and is also used for several other games.

Non-default settings can cause problems with some games and should only be enabled if needed.

---

Setting up microcode detect references

Microcodes are nearly always detected correctly internally by the plugin and therefore it should not be something a user has to think about. However, the database is probably not complete and in v1.6 games can switch microcodes at any time during execution, thus the probability of a detect failure somewhere is rather high. We cannot force a particular microcode per ROM, so now the RDB file header is used. If you suffer a uCode detection failure, please refer to the RDB for an example of how to set this up.

uCode ID	uCode	example(s)
0	RSPSW	Mario64, most early games
1	RSPSW_EXT	Star Wars - Shadows of the Empire
2	RSPSW_GE	Goldeneye 007
3	RSPSW_PD	Perfect Dark
4	RSPSW_DKR	Diddy Kong Racing
5	RSPSW_RARE4	Jet Force Gemini
6	S1DEX	(sprite microcode)
7	F3DEX1	(most later games are either this...
8	F3DEX2	... or this)
9	F3DZEX2	Zelda
10	F3DEXGB2	Conker's Bad Fur Day
11	S2DEX	(sprite microcode)

These are all the different microcodes supported by the graphics plugin. Note that these are the real names for the microcode as taken from the game code. This is a technical subject beyond the scope of this document, it's enough for the user to know that if detect fails you should first seek an updated RDB file. Advanced users can add references themselves via the RDB. You must set the correct uCode - you either know, you ask someone who knows, or you find out by trial and error!

This page covers configuration of the default Project64 input plugin. About other plugins.

1. " Player1/Player2/Player3/Player4" [tabs]
2. "Game Device..." [menu]
3. "...deadzone of X%" [slider]
4. "Plugged In" [checkbox]
5. "Controller Pak" [drop down box]
6. "Load Profile" [button]
7. "Save Profile" [button]

• default keys

• instructions for setting keys
  • Analogue stick & Range
  • C-buttons
  • D-pad
  • other buttons

 

---

" Player1/Player2/Player3/Player4" [tabs]

The system supports four independant simultaneous sets of input, select the one you wish to configure by clicking the appropriate tab. Each is identical, but the four players correspond to the four physical ports on an N64 system, so you usually must use Player1 for a single player game, Player1 and Player2 for a two player game and so on.

---

"Game Device..." [drop down menu]

• default setting: None
• generally recommended setting: whichever input device (gamepad etc.) you wish the current player to use!

---

"...deadzone of X%" [slider]

• default setting: 25
• generally recommended setting: as low as is possible with your input device

This slider allows you to set the deadzone in 1% increments from 0 to 100.

A sensible range would be from 5% (a good quality controller) to 25% (a poor quality) controller.

The lower the deadzone, the potentially better your fine control, but the more likely you are to suffer from "ghost" movements and other input errors that arise from the less than perfectly accurate physical reading mechanism your device employs. A device read optically (such as a genuine N64 controller, on a USB port adapter) is likely to be more accurate (so you can use a smaller deadzone) than a device read by potentiometer (such as most current low-cost PC gamepads).

Deadzone only applies to analogue input devices! Leave it at default for digital devices.

---

"Plugged In" [checkbox]

• default setting: enabled on Player1, disabled on all other players
• recommended setting: enabled for each player you wish to participate

If enabled, the plugin indicates to the core (which indicates to the game) that there is a controller present on the relevant port (players1-4 correspond to ports1-4)

If disabled, the game will not find a controller present on the relevant port and any settings for that player are ignored.

---

"Controller Pak" [drop down menu]

• default setting: Memory Pak
• recommended setting: enabled

If  None is selected, the plugin indicates that there is no Controller or Rumble Pak present (an empty controller slot). You will not be able to save a game that uses MemPaks.

If Rumble Pak is Selected, the plugin indicates to the application that there is a rumble pak present. This enables the use of Rumble (Force Feedback) for games and Controllers that support this, but it also means that you will not be able to save a game that uses MemPaks until you change the setting back.

---

"Load Profile" [button]

press to open a file browser to select and load a a complete controller profile for the current player, that you saved earlier, or copied from another location (see below).

---

"Save Profile" [button]

press to save the complete configuration for the current player to a file. you will be prompted for path and filename.

---

Default Keys

After installing Project64 you will find Player1 already given a basic keyboard control setup:

Analogue

• L - left arrow
• R - right arrow
• U - up arrow
• D - down arrow

C-buttons

• L - delete
• R - page down
• U - home
• D - end

Digital

• L - Numpad 4
• R - Numpad 6
• U - Numpad 8
• D - Numpad 2

A - X
B - C
S - Enter
L - A
R - S
Z - Z

 

Players 2-4 are not pre-configured (or enabled)

Depending on your keyboard layout, personal preferences, and what input devices you have available, you will probably want to change this (see below).

---

Instructions for setting keys:

1. Choose the N64 control that you wish to set (e.g. the "A" button)
2. Decide which keyboard key or gamepad button you wish to assign to it. If it's not a keyboard key, make sure you have the correct device selected under "Game Device".
3. Press the small square button to the right of the control.
4. You will see "Press Key..." and a countdown in seconds appear in the title bar.
5. During this time, press the button on your input device that you wish to assign to that control. The first input detected is used.
6. If you make a mistake or wish to change a control, repeat steps 1-5 for each control that you wish to change.

L, R, U, D denotes Left, Right, Up, Down directions respectively for each set of controls.

"Analogue Stick" [4 buttons and indicators] and "Range"

In order to allow people without analogue input devices to use Project64, the plugin accepts 4 buttons as a substitute for two axes.

If you have an analogue stick, set it in exactly the same way, but make sure the positive and negative direction of each axes is correctly mapped to a pair, i.e. L and R or U and D. Analogue input detected will be described as "Joy ..." e.g. Joy Left.

"Range" [slider]

• default setting: 100
• generally recommended setting: around 65% (see below)

New in v1.5, this sets the outer limit of your analogue movement, but like Deadzone, a smaller value gives better control. If you set this too low you will find that e.g. you cannot run fast in Mario64, if you set it too high, you will use up all your available range too early in the stick's travel (so you would find it harder to walk slow). This control is probably easiest to understand by experimentation. I have found values around 65% seem to be best, so that may be a good starting point.

"C-Buttons" [4 buttons and indicators]

This is the four yellow buttons on the right of an N64 controller. Set in exactly the same way as "Analogue Stick"

"Digital" [4 buttons and indicators]

This is the d-pad (4 way direction pad, cross-pad) on the left of an N64 controller. Set in exactly the same way as "C-buttons".

Other buttons

The remaining 6 controls correspond the remaining 6 buttons on the N64 controller (all are digital controls):

• A and B are the main (blue and green) buttons.
• L and R are the two "shoulder" buttons, on the top of the controller.
• S is the recessed red START button in the centre of the controller.
• Z is the grey "trigger" button underneath the controller.

 

This page covers configuration of the default Project64 audio plugin - Jabo's DirectSound v1.6

For information on other plugins please consult the relevant authors' documentation.

The controls available are:

1. "Volume"

2. "Audio Logging"

3. "Sync game to Audio"

Important general points

1. The audio plugin does not include an audio emulator! It must be used in conjunction with the RSP plugin. The RSP plugin must be configured with "send Audio Lists to Audio Plugin" disabled or the audio plugin will recieve no audio data and hence you will hear no sound (in most games).
2. The audio plugin uses a fixed audio buffer, size chosen carefully by the author and not adjustable.
   

---

Volume [slider]

• default setting: 100%
• generally recommended setting: user preference!

This control was added in v1.5 mainly as a way to balance Project64 against other applications. It's function should be fairly obvious. You can use the Up and Down arrows and Page Up and Page Down keys and Mousewheel as shortcuts. Setting all the way down is equivalent to muting the emulator.

This setting is global (applies to all ROMs), takes effect instantly, and is saved in the registry.

---

Audio Logging [button pair]

This control has two buttons, Start and Stop.

If you want to save all the audio produced by the emulator to your hard drive, press Start. You will be prompted for a path and filename. You can close the dialog. When you want to stop logging, go back to the dialog and press Stop. Don't forget to stop recording, or you may get a corrupt .wav file!

Notes:

• You can record for as long as you have hard drive space available.
• You cannot record particular parts of the audio (background music, sound effects etc.), just the whole stream. games may have options to adjust levels.
• Note that the file written is a simple waveform (datarate similar to a CD), so it uses a large amount of hard drive space.
• You could edit the resulting file in any standard waveform editor, compress it to MP3 format, etc., as you wish.

---

Sync game to Audio [checkbox]

• default setting: disabled
• generally recommended setting: disabled

If disabled, the audio plugin will output the audio stream as it is supplied. There will be some degree of "popping" or clicking" as the core speed fluctuates slightly, but the core (and hence gameplay) is not interrupted. The benefits of this - smoother gameplay - probably outweigh the drawbacks for you.

If enabled, the audio plugin will stall (momentarily stop) the emulator when audio data is being supplied faster than it can output cleanly. This will prevent some artifacts, but will have a slight to severe effect on the peformance of the whole system. There are three degrees of severity to the side effects that enabling Sync can produce, which applies depends entirely on the game:

1. slight (I would think noticeable to most people) loss of smoothness of the whole system* (e.g. Mario64, Zelda, most games)
2. lowering in VI/s (reduction in speed of whole system*) from the normal value (e.g. 60FPS) to a new value (e.g. 45FPS) (e.g. Ridge Racer, Mario Party 2)
3. complete stall of the whole system* (e.g. Turok2)

*"whole system" means the whole emulator, not your PC!

Notes:

• If you enable "Sync game to Audio" you will not be able to use the speed limiter disable (System menu, shortcut F4) as a "fast forward".
• "Sync game to Audio" is very useful in one particular situation: if you want a clean logged audio file (see below).
• In v1.5+ the "Sync game to Audio" setting is saved per-ROM in the registry.

 

Note: using cheat codes is basically equivalent to having a bad ROM in many ways. Do not use cheat codes if you are experiencing problems similar to those caused by bad ROMs! (See {ln:error messages page})

Though hardly specific to Project64, understanding and having good ROMs is so important to using Project64 successfully that I'm going to cover it briefly here.

First you need to download the following, which can be found on any good emulation website (try here )

1. The latest version of "GoodN64" by Cowering
2. "GoodWindows" by Master of Puppets (note: GoodGUI also does the job, but these instructions are for GoodWindows)
3. a file called "bin.zip" containing "zlib.dll", if it doesn't come with GoodWindows.
   

If your ROMs are compressed, you need to download whatever utility is needed to decompress them - i suggest 7-zip as it's free and can do most formats.

Have your unverified and decompressed ROM files available somewhere on your hard drive, e.g. "C:\Temp"

Unzip all the utilities listed above to one folder on your hard drive e.g. "C:\Program Files\GoodTools\" (zlib.dll should end up in a "\bin" subfolder of this folder). Browse to the folder and run GoodWindows.exe.

1. Select mode "Good Tool"
2. Select "Nintendo 64" as system. You will be prompted to browse to GoodN64.exe. Do so.
3. Set "Directory to work on" to the folder containing your unverified ROMs ("C:\Temp" if you are following my instructions exactly)
4. Keeps "Options" set to "rename"
5. Press the "Execute" button and wait until the program is finished. This may take some time.

Close GoodWindows and browse to you ROM folder ("C:\Temp" if you are following these instructions exactly) , and you will find GoodWindows has created some subfolders and text files. All known ROMs have been moved to a subfolder "N64ren". Any ROMs that are not moved and not renamed are not known by GoodN64, it is safe to assume they are bad - probably best to delete them.

So how do you know which ROMs are good? It's very simple, a good ROM will now be in the "N64ren" subfolder and have "[!]" in its name. If it does not have a "[!]" in the name then there is something wrong - the full key is included in GoodWindows, under Legend > Good Tools.

Only "[!]" ROMs are supported by Project64. If your ROM is not good, find another. Usually ROMs that are not good don't even start but sometimes they fail midway during a game - you do not want this!

 

Background - how Project64 finds translations
When Project64 is started it looks for all files ending .pj.Lang in the \Lang\ subfolder, opens each file, takes the line beginning "#1 # " (which will be the internal name of the language) and uses all of these to populate the Language selection menu. Note that the filename itself is not used except by us to identify the files.

Starting a new translation
To make a new translation file for Project64, simply copy one of the existing .pj.Lang files - it doesn't matter which, you'd probably take the original English, then open the copy in a text editor (such as Microsoft Notepad, included with Windows) and you can begin editing the text.

Preserving file layout
Be careful that you don't change the formatting (layout) of the file at all. Every line must start hash-number-hash (e.g. #460#), then open quotes ("), then the actual text you want, then close quotes ("). Anything prefixed by "//" or contained within "/* ... */" is a comment and will be ignored by the emulator i.e. it is only for humans reading the file. Make sure you use Notepad to edit the file, not Word or some other complex program which might mess up the formatting.

Line breaks
Line breaks (the movement from one line to the next, or line spaces) are taken literally, so to start a new line of text e.g. in an error message, you actually press ENTER in the translation file. Do not use the end quote (") until the end of the last line. (Also, don't use quotes anywhere in your text!)

Shortcuts
To create keyboard shortcut keys, put a "&" symbol before the letter you want to as a shortcut. For example l#127# "&Load State" in the .Lang file will become "Load State" in the application and pressing "L" when in the System menu will instantly load a state :). These shortcut keys are optional. You cannot change the CTRL+ or Function key shortcuts via the language file.

Don't forget to test your file! Make sure it loads properly (if not, check for missing closing quotes), and that the text fits the space available (if not, abbreviate!)

The ROM Browser gets its data from several sources, and it's not obvious which field comes from where.

The following fields are read directly from the ROMs:

• Filename (w/o extension)
• CIC Chip
• Country
• CRC1
• CRC2
• Internal Name
• Manufacturer
• ROM size

The following fields are read from Project64.rdb:

• Good Name
• Status
• Notes (Core)
• Notes (default plugins)

The following fields are read from Project64.rdx (if available):

• Developer
• Genre
• Players
• Release Date

The following fields are read from Project64.rdn (if available):

• Notes (User)

Any data not available will simply appear blank.

Stability problems can be broadly broken down into three categories, reflecting the complex nature of an emulator:

1. System
2. Application
3. Game

System failures

This type of problem refers to a complete lock up of your PC or an operating system STOP error (BSOD), usually requiring a hard reset of the system.

There are no known bugs in Project64 (we cannot vouch for 3rd party plugins, of course) that would cause a system crash/lockup/other form of operating system failure. It is not possible for PJ64 to crash Win2k/XP directly because it's running in user space (it simply doesn't have the rights). If you experience such a problem while using Project64, it is very likely that you have a hardware or driver or directx or operating system problem. Run diagnostic software and check that your system is stable in other Direct3D applications, games, benchmark utilities etc. Find some torture-testing utilities. Consult hardware documentation if you need further help. You could try changing plugins, and use dummy plugins to see if you can narrow down to one area thats causing the problem (doesn't mean its necessarily a fault in that area of the emulator, but that area of the complete system).

• Check that other applications are not leaving your system (particularly video and DirectX) in an unusable state, by starting the OS with no other applications.
• Do a complete virus and spyware scan of your system.
• Torture test your system with benchmarking utilities etc. Even then, PJ64 makes unusual use of hardware, that may not show up in other usage. Video card companies unfortunately probably don't test with Project64, this is not our fault if they crash when we make valid calls!
  
• Check again that the problem is not bad drivers, for example we have seen STOP errors being caused by drivers from a specific hardware company - use Project64 on any other company's hardware and in the same situation it works fine. Contact the appropriate organisation for technical support, there are so many things that could be wrong with a PC it's very hard for us to help :/
  

Application failures

This type of problem refers to an actual crash or hang in the Project64 application, resulting in a generic Windows error messsage "this program has peformed an illegal operation" or "this program is not responding" etc. The exact type of message depends on your version of Windows, but the point is that you are seeing a Windows error message not a Project64 error message - in other words, Project64 has failed to handle an error, which could indicate a bug in Project64 or a system failure:

• Are you running a supported game with the correct ROM settings? A small number of games can cause Project64 to fail under some conditions.
• Known ways of crashing PJ64 (bugs in PJ64) will be listed in the {ln:Known Issues section} under Application issues.
  
• Is your hardware OK? Memory problems, overclocking etc. can cause applications to fail.

Game failures

This type of error refers to an error in the Project64 application or plugin(s) that is handled succesfuly by the application or plugin error handlers. a good example of this is the "UnHandled OpCode" error (OK, the OpCode itself is unhandled, but the situation is handled - you can end emulation, reboot the game, or play another game, without Project64 crashing). Another example is a graphics Access Violation. This type of error neary always indicates a bug or a configuration error in the emulator or a bad ROM!

• Are you running a supported game with the correct ROM settings? Almost any game will crash without the correct configuration.
• Is your ROM verified good? See the {ln:reference page}
  
• Anything you can do to improve core security (see Configuration > ROM Settings) may prevent the problem.
• See {ln:games section} for Known Issues for the game if applicable.
  

Please refer to the {ln:error messages page} for information on specific error messages.

"Direct3D failed to initialize your HAL device. Make sure you have a properly configured 3D graphics card compatible with Direct3D..."

"The default or selected video plugin is missing or invalid / Check that you have at least one compatible plugin file in your plugin folder."  

Q: Why won't Jabo's video plugin initialise on my system?

There are quite a few possible causes of this, so please read this section carefully before asking for help - this is a fairly common problem.

• Do you have a hardware 3D accelerator?

If the answer is "no", you cannot use the Direct3D HAL, and you effectively won't be able to use Project64 sorry, so go no further* (See {ln:requirements}). If the answer is "not sure", find out from the people who made your computer, or look in the Windows control panel for your model and find out on the web is it has 3d capabilities (or use RUN > DXDIAG) . If the answer is "yes, I have some sort of modern 3d hardware accelerator", we can probably get you going, so read on :)

 *You can technically run the D3D plugin using RGB emulation but the performance and quality will be dire even on the fastest of systems.

•  Have you tried rebooting your system? 

It is possible for other applications to leave your system (windows, directx) in an unusable state. (In this case, the fault lies with the other applications, not PJ64). Simply rebooting and running PJ64 with as few other apps running as possible can solve the prolbem.

 

• Have you exceeded the capabilities of your hardware?

The simplest thing that may work is to try changing your desktop colour depth to 16-bit (that's "High Colour", not 16 colours). Some cards can only render in 16-bit mode, while others have issues in higher depths that stop then running PJ64.

• Do you have the most recent / best drivers for your video card properly installed?

This means downloading the newest drivers from your card manufacturer's homepage, uninstalling your current ones using Windows Add/Remove programs (there should be an entry in there for them, if not just continue) and then running the install program for your newly downloaded drivers. After installation is complete, reboot Windows if the software doesn't force you to anyway.

Note: if you have an older nVidia graphics card, the newest drivers may NOT be the best for you, because nVidia have stopped supporting the older chipsets properly in favour of their newer ones. GF2MX/GF4MX owners report the 56.72  driver working well.

• Adjusted your video card driver options?

If there is a tweak utility available for your card, download (try www.tweakfiles.com) and use it. Relevant settings to change are z-buffer depth, texture colour depth, and probably others depending on the card you have. If there is no tweak utility, look under Windows display properties (right click on desktop > Properties > Settings > Advanced). Your video card drivers may provide extra options on the screens there.

• Plugin still won't initialise? Install latest DirectX and the drivers for your chipset (AGP drivers etc.).
  

You get DirectX from Microsoft.com, and you get your chipset drivers from your motherboard manufacturer's site. Install, reboot Windows and try again. If your installation of Windows is damaged you may need to reinstall Windows, but that's not something i can go into here, be sure to backup etc and we're not responsible for any loss or damage.

• Tried all the above? Still can't get the plugin to start?
  

To use Jabo's video plugin, it seems you'll need to get a better video card. See {ln:requirements} page for suggestions.
Or, you can still use most of Project64 if you use a 3rd party video plugin (see {ln:links}), but of course that will change compatibility etc. so we won't be able to support it.

 

Q: Graphics used to initialise OK but now won't, why?
Probably because something has changed in your PC setup, most likely not in your PJ64 setup. If you have changed any system display related settings, like colour depth, z-buffer depth and so on, change them back to how they were when it was last working. If you can't remember, read the answer above.

If you have tried everything you can think of but still can't get it to init., try this:

• Properly uninstall your display drivers, and reinstall them.

This means using the Windows Add/Remove programs entry, and rebooting, BEFORE installing the (new) drivers. It doesn't usually matter whether you install the same version again or not, the important thing is that you completely remove all the relevant settings from the Windows registry. Your graphics card manufacturer may provide a downloadable utility to do this, in which case you MUST use that utility, it is NOT sufficient to simply change drivers through the Windows display properties screens.

• If you are using any tweak utility that loads automatically on startup, DISABLE it before changing drivers as it may simply recreate the problem after you reboot!

If you have tried all this and it still isn't working:

• Reinstall DirectX (or update it) and chipset drivers, then try different (newer AND older) display driver versions. If it STILL isn't working, you've probably got something seriously wrong with your Windows installation and may need to reinstall windows.

The main point is, if it used to work and now doesn't, and you are using the same version of PJ64, logically it must be a problem in your system, so look carefully there.

Simply rebooting a PC often helps.

Access Violations are a general error in the execution of the video plugin. Despite what some people seem to think, the Exception Handler (the code which catches the error and produces the error message) does not cause crashes, it actually prevents them - without it (as in old versions of Project64) such a problem would simply result in a hung display or crashed application - at least now you have some idea what went wrong and have a chance of solving the problem.

Important points, please read this first:

1. AVs are usually, but not always, fatal (unrecoverable, and you lose game progress since your last save) - you may be able to click OK and continue playing, but usually after the first message you will keep getting more errors until you quit the app. Although ending emulation will usually be sufficient, you are advised to always restart the app after the first error to make sure everything is reinitialised.
2. Do not try to save your game after an Access Violation, except to a to a new save file - you are unlikely to be able to continue from a state save made after an access violation.
3. Access violations (and plugin failures generally) have from our experience only about a 50% chance of being caused by a fault in the plugin - many times the cause is the core sending invalid data to the plugin.
4. Sometimes the plugin will show AVs when running a particular game on below minimum spec video hardware - check that your system meets the minimum {ln:requirements} for PJ64 and that your video drivers are good/up to date.
   

The error message itself (in versions of PJ64 that display memory details, newer versions do not) is not very meaningful to the end user (this dialog was simplified in v1.6). What I can do here is give you a general list of possible solutions for you to try:

In case the error is caused by a core fault:

• Verify your ROM if you haven't already!
• Check that you have the latest RDB.
  
• Try turning off all cheat codes and resetting the game. Cheat codes can cause Access Violations. Don't load previous state saves that were made while using cheat codes!
• In case your core settings are already optimal but you have suffered a random core error (more likely if you use state saves a lot), try making a native save, resetting the ROM, and loading from the native save (avoid state saves). This ensures the contents of the N64 memory space are clean.
• Anything you can do to increase security in the CPU core via ROM settings may solve an access violation. Check that you have the latest RDB. (If performance is a problem, you may be able to revert to original settings as soon as you have passed the problem point).
• Try a different version ROM (e.g. different region etc. of the same game)

 

In case the error is caused by a video plugin fault:

• Check that your system meets the minimum {ln:requirements}.
• Some users report running in fullscreen rather than windowed solves this problem for them. (Laptop integrated video chipsets?)
  
• Verify your ROM if you haven't already!
• Check that you have the latest RDB.
  
• Check that video options are at defaults (particularly Framebuffer setting). If you are confused, reinstall the emulator.
  
• If the ROM is running on 4MB RDRAM, try 8MB (Core ROM Settings). For some reason this is known to fix the problem in some cases.
• Try a different version ROM (e.g. different region etc. of the same game)

If all this does not help, try a different video plugin - or the same plugin in a different emulator, to see if you can narrow down the problem to core or video and thus find a combination that works.

 

The first thing to understand is what speed to expect from Project64 - as a rough guide, the following specifications should be barely fast enough for each game at full speed with the default configuration:

• Mario64 needs ~P2-450Mhz
• Zelda needs ~Athlon 800Mhz
• Perfect Dark needs ~Athlon 1.2Ghz

These are approximate figures only, see detail below for factors.

Important Points:

1. As a general rule, FPS in Project64 depends on your CPU, not your graphics card, but the graphics card can become the limiting factor at high resolutions with high levels of FSAA, or if you have a below minimum spec. graphics card.
2. Not all the suggestions below will improve performance for you. Some will only reduce quality, stability etc. You have to try them and see the effects for yourself.
3. Some of these suggestions have the potential to do damage to your hardware or software or data or all three. Any such damage that results from your following the suggestions listed on this page is entirely your own responsiblity - take care and don't do anything you are no confident you understand - seek advice from hardware internet sites etc. if you need to.
4. The generally most significant factors are listed first, descending to the least significant (i.e. the most to the least likely to help, in my opinion and experience).

Check problem is not being caused by one of your plugins - plugins can stall the emulator by design or due to bugs in their coding.

What you can do to speed up PJ64: 

Hardware level

1. increase CPU clock rate or upgrade CPU. This is the single most important hardware factor. But note there is no point having multiple CPUs or muti-core CPUs as they are not useful for emulation. You need one fast CPU.
2. increase font side bus/RAM clock rate
3. add RAM if you are short*
4. choose a CPU with SSE (& MMX!) capability
5. adjust RAM timings, cache timings etc.*
6. increase graphics card clock rates*
7. use PCI rather than ISA sound card
8. disable any unneeded ports/hardware
9. use USB rather than Gameport input devices

Driver level

1. update drivers, video card drivers, chipset drivers, sound drivers*
2. use 16 bit colour desktop rather than 24/32*
3. use lower level of anti-aliasing, or none at all*
4. disable Vsync
5. disable multi-display if your system supports it*
6. use 16 bit z buffer (rather than 24/32)*
7. use texture compression*
8. lower or raise monitor refresh rate*

Operating System level

1. shut down all non essential (background) processes
2. disable findfast/file indexing/system restore/task scheduler etc.
3. adjust process priorities
4. use Win2K/XP series OS if you have enough RAM (192MB+)
5. use Win98SE if you don't have enough RAM (WinME seems generally a bad choice)
6. update DirectX version
7. just rebooting Windows can help free resources
8. clean reinstall Windows in extreme problem cases
9. compact memory
10. fix pagefile size
11. move pagefile to fastest drive*
12. defragment hard drive
13. lower debug levels on DirectX
14. don't use debug (usually beta) builds of drivers or DirectX

Application level

1. don't run multiple instances of Project64
2. fullscreen modes may be considerably faster than windowed modes*

Emulator core

1. use Recompiler instead of Interpreter**
2. disable the speed limiter (!)
3. enable Register Caching**
4. enable Advanced Block Linking**
5. enable Larger Compiler Buffer**
6. use less secure method to handle self-modifying code**
7. don't enable the expansion pack if it's not needed**
8. state saving and loading sometimes helps the recompiler**
9. disable TLB (but only if not needed!)**

plugins

1. use Direct3D HAL rather than RGB Emulation or Reference Rasterizer (!)
2. use the RSP recompiler core rather than Interpreter core
3. Send Audio Lists to Audio Plugin (and use an HLE capable audio plugin if you want audio!)
4. don't use any form of Framebuffer emulation (!)
5. don't enable Sync game to Audio**
6. use a lower resolution*
7. use 16 bit colour modes rather than 24/32*
8. if you want true colour, use 32 bit rather than 24*
9. use different buffer display mode e.g. Double or Triple Buffering rather than Transfer Memory*
10. use External Geometry pipeline rather than Internal
11. don't use anisotropic filtering*

 

* effectiveness depends on system (hardware)
** effectiveness depends on game
(!) indicates a very important point 

The first thing to understand is what level of graphics quality to expect. Games marked compatible should look generally good and not have any flaws serious enough to stop you playing the game. The {ln:games section} should give you a good idea what to expect. Perfection is not realistic to expect, regardless of how good a system you have, because the emulation isn't perfect, and nor are the APIs used (and interestingly... nor are the games themselves).

Before you ask for help, please take yourself through the following questions:

1. Is the problem a limitation of your video hardware? Do you meet the recommended specification (read Manual)? Remember that different games and different parts of games use different hardware features - only the recommended or better hardware can display everything the plugin is capable of. If you have poorer hardware, you may be able to get better results from older versions of the video plugin, which use less complex effects. (You can see whether any problem is a limitation of your system or a bug in the emulator by selecting Reference Rasterizer in the video plugin options and comparing the result to normal Direct3D HAL - if the problems dissappears in Reference Rasterizer, it's your fault, if it doesn't, it's the emulator's fault - difficult to enable Ref. Raster in v1.6+)
2. Does the problem lie with your video hardware drivers or driver configuration? Try newer drivers, or sometimes older drivers help especially for nVidia. Be wary of tweak utilties and beta/leaked drivers. Make sure you uninstall drivers properly when changing them. For example, the ATI Radeon hardware is capable of drawing everything that PJ64 asks, but many of ATI's drivers aren't, and your system is only as strong as the weakest 'link in the chain'.
3. Is it a problem with your video plugin configuration? Have you changed anything from the defaults?
4. Is there an instruction you have to follow to configure the emulator specifically for that ROM? Check the ROM Browser Notes. e.g. Aidyn Chronicles needs Display List Culling disabled.
5. Is the problem a known game specific issue? Check the ROM Browser Notes e.g. the Conker's Bad Fur Day has a problem with the pause screen. You can't do anything about known issues, except look out for an updated or better emulator.
6. Is the game using a framebuffer effect at that particular point? Try all the framebuffer options to find out. The framebuffer can be used for all sorts of things that are not obvious to the user e.g. one of the gun scopes in CBFD multiplayer.
7. Is the problem a known general plugin issue? e.g. the near clipping plane problem, you may only notice this in Extreme-G but its a general limitation of the API that effects all games. See {ln:Known Issues section}.
   

Remember graphics problems are not necessarily the fault of the video plugin, they could also, though it less usual, be caused by faults in the core or RSP of the emulator you are using. If you are using Jabo's plugin with the core of another emulator, try with the complete Project64 package first.

The first thing to understand is what to expect. Games marked Compatible should sound generally good with only minimal and barely noticeable (to most people) cracking/popping/clicking. Major stuttering or distorted sound, or missing parts of sound, is not normal. Perfection is not realistic to expect - occasional stuttering at a few points in a game is normal (although not necessarily un-preventable), often as the core slows down. Also a mild general stutter may be noticeable in some background music etc as a result of core timing problems.. this sort of problem is usually fixed by Sync Game to Audio (but read the warnings carefully!)

Before you ask for help, please take yourself through the following questions:

1. Are you running the game at the correct speed*? This is the most important point. If the answer to this question is no, and you are below the correct speed, you have a performance problem, not an audio problem. Read Troubleshooting > Speed / Performance problems. If the answer to this question is no, and you are above the correct speed, you have almost certainly turned off the speed limiter (system menu, shortcut: F4) and must turn it back on in order to get good audio.
2. Are there known game specific audio issues? Check the ROM browser and read the notes provided.
3. Are you using the audio plugin or the RSP for audio emulation? Read RSP configuration if you don't understand the distinction. We recommend RSP low-level emulation unless your system is too slow.
4. Are you using Sync game to audio? This option may be exactly what you need or it may make this much worse, please read the Manual about that control carefully.
5. Has another application taken control of your sound card? Some cards can only play one stream at once, or another app may be interfering.

*NTSC games should be running at 60VI/s, PAL games at 50VI/s. If they are not running at exactly this speed or within a few VI/s of it (e.g. 57-61 is a reasonable range for an NTSC game) then there is no way you can get good audio (this is just a basic truth, not a flaw in the emulator).

 

Assuming you have installed PJ64 from the official installer (so the plugins are not missing) this error generally indicates that default plugin has not started, i.e. it is invalid for your system. To resolve this, please read system {ln:requirements} then video initialisation {ln:troubleshooting}.

(this error msg exists with variations for each type of plugin)

This indicates a problem with your Windows installation. read this Microsoft support page or search their site for more information.

"...make sure you have a properly configured 3d graphics card compatible with Direct3D8" (or similar msg).

Please read Manual and Guides > Troublshooting >  Video Initialisation (Initialization) problems for a full explanation of how to solve this problem (it's a long topic).

 

Please see {ln:Troubleshooting} category for full details for this problem as it's a complex topic.

This text (or a translation of it if using Lang file) is shown in the "Good Name" field (by default the first column of the ROM Browser) if the ROM is not in the RDB.

1. Right click on the game, click 'ROM information' (or 'Properties'), and read the filename to work out which ROM it is refering to on your system.
2. You must then {ln:verify your ROMs} with GoodN64.
3. Also look for an updated RDB ({ln:Download section})!

Non-[!] ROMs are not officially supported by PJ64. (People with a reason to use other kinds of ROM will be able to add them themselves to the RDB).

1. Usually indicates a Bad ROM - read how to {ln:verify your ROMs}.
2. If your ROMs are [!], this error may indicate incorrect ROM Settings. Check {ln:download section} for updated RDB.
3. If none of the above help, try restarting the emulator and don't load from a state save (loading from native saves is OK). This will test for random memory/core errors.
   

1. Read ROM Browser notes to check game is supported
2. Check {ln:Games section} for known issues for the game.
3. Check {ln:download section} for updated RDB.
   

 

Try updating your DirectX version and controller drivers, if there are any.

Update your DirectX version to at least 8.

You have selected a zip file without a valid N64 ROM inside, or one that the emulator can find.

Check the file contains a valid N64 ROM which can be extracted by a zip program. Try recompressing the ROM using a reliable zip utility.

1. Usually indicates a Bad ROM - read how to {ln:verify your ROMs}.
2. If your ROMs are [!], this error may indicate incorrect ROM Settings. Check {ln:download section} for updated RDB.
3. Cheat codes can cause core errors. Disable all cheat codes and reset the game (default shortcut: F1). Load from the native save (through the game's menus). Do not load from a state save (F7 etc.), because states store memory changes. Usually loading from the native save is OK. In some cases cheat codes can damage the native save aswell so that the game crashes; it may even be necessary to start the game again, either by using a different "slot" or by deleting the native date in your Project64 \Save subfolder. (try all other suggestions here first!).
   
4. If none of the above apply, try restarting the emulator and load from the native save - through the game's menus (do not load any PJ64 state save (F7 etc.) because state saves can store memory errors). This point will test for other random memory/core errors. If you find this works, overwrite your bad state save with a new clean state save.
   

1. Check (with a Task Manager) you have no zombie (processes without windows) instances of PJ64 running. If you don't understand this, try logging off and back on windows or restarting your PC.
2. Check that your save files are not read-only.
   
3. Check that you have write permissions (i.e. NTFS permissions in WinXP) to the save directory, or move your save dir to somewhere you have write access such as your windows user profile folder.
4. Read the notes about Multiple Instances in the Manual.

Nearly always indicates a bad ROM - read how to verify your ROMs. Only [!] ROMs are supported by Project64.

1. This nearly always indicates you have a bad ROM - read how to {ln:Verify ROMs}. 
2. In rare cases, this could indicate incorrect ROM Settings, so check you have the latest RDB ({ln:Downloads} > Updates) and haven't changed any settings.  

The only compressed standard supported is .zip. if your file is compressed with anything else (.rar, .7z, .ace etc etc.), decompress it with the appropriate program then try loading. If it still doesn't work, verify the uncompressed file with GoodN64 (see elsewhere in documentation).

This error should rarely appear in PJ64 v1.6 since the resource usage was made lower, so  if you're using an older version please upgrade to v1.6 or later
If you still see the error, we suggest you try the following in this order. Try running Project64 after each step:

1. Free as much RAM as possible (preferably over 100MB) by shutting down unneeded processes.
2. Make sure you have set a large permanent Windows swapfile (preferably over 512MB).
3. If you use WindowsXP try using a Windows compatibility mode (right click on Project64.exe > Properties > Compatibility. Choose e.g. Windows 98, and press OK). Or if you are using a compatibilty mode, try not using one, or using a different one.
4. You could try running a "RAM freeing/compacting" type program for example FreeRAM XP Pro (this is not an endorsement of this particular software).
   
5. Try removing any spyware on your computer with a spyware removal pograms sych as Ad-Aware or Spybot.
6. Some users report that Windows XP Hotfix - KB828741 or KB841356 causes this error, you could try uninstalling that (though we are not responsible for any security implications of doing this!). Others say installing SP2 for WinXP fixed this problem.
7. If you use a program called MSN Plus! or Messenger Plus try closing them. Also other IM programs.
8. Some users report uninstalling Logitch Mouseware fixed this problem.
9. If you use a Win9x based OS (Win98,WinME) some users suggest you should probably upgrade to WinXP.

This is a rather mysterious problem rarely seen by the PJ64 team...

Close the ROM ("End Emulation") or simply quit PJ64 with the GUI or ALT+F4

Probably because the graphics plugin is asking your video card to do something it is not capable of. Read the log (open in text editor) and it should provide some clues to where the problem is. Check you have everything set up right in the plugin and your drivers. Ultimately you may need to get a better graphics card to avoid the errors... you cannot stop the plugins from logging, you could try making the files read only. The occasional error from even a good graphics card is normal and not a cause for concern unless you notice any ill effects.