So, what does this do for you? Many things! Here are the key advantages:
No calibration required. As the game talks to the controller directly, it
reads exactly the same axis values it would in a non-emulated setup. In other words,
the controller works, responds and feels exactly as it would in real life.
Low latency. When the game must read the controller, the request is forwarded
directly to the controller by the adapter. The later immediately returns the controller's
answer to the game.
Potential support for any expansion accessory without any intervention nor device-specific
functionality required on the part of the emulator, of the plugin or of the adapter (except for
the direct access feature), which means:
And just like with a real N64 system, you simply need to insert the accessory you
wish to use and the game will take care of everything else. No emulator configuration required
to switch accessory...
Support for peripherals other than controllers.
N64 mouse (tested)
VRU (confirmed, requires special ports1_4 version of the plugin)
N64 Keyboard (not confirmed)
 I cannot test accessories I do not own yet. But the nice thing about this plugin is that
it probably already works. Please contact me if you get the chance to test.
Warning: This project is experimental and still in development. While it is already usable,
some of the features above, especially the ones that are unconfirmed, may be found not to work at all.
There can (and will) be bugs, and there are still many missing features such
as multi adapter support.
Your help and patience in testing as well as your constructive feedback are welcomed.
Here are a few screenshots taken with a memory card present in the N64 controller. The Mario Kart 64
built-in mempak manager (hold the START before running the emulator) is usable despite
a few visual glitches. Then once in the game, we can see ghost data exists (saved in a previous
session. The emulator had been restarted since). Later (and on a different machine, in this screenshot
on a Linux system) the data written by MK64 can be accessed with
the adapter management tool.
MK64 built-in manager
Note: For now at least, it is better not to run the adapter manager and a game (with this plugin) at the same time.
Controller, Transfer and Tremor paks
MaMaLuigi9001 tested the Transfer Pak and a Tremor Pak Plus
(Third party Rumble Pak equivalent) and reports it works fine. The games he tested with the Transfer Pak are Pokemon Statium
and Pokemon Statium 2, using Project 64 version 18.104.22.168 under Windows 10. He mentions however that the emulator crashes with a blank screen when he goes to the Gameboy Tower...
Here are a few screenshots of the Pokemon games:
Pokemon Stadium 2
Pokemon Stadium 2
Pokemon Stadium 2
MaMaLuigi9001 also confirmed the VRU works, but the ports1_4 version of the plugin where adapter port 2 acts as N64 port 4 is required. This version will be included in release 1.0.0.
This plugin is for third generation raphnet GC/N64 to USB adapters. If you are not sure which generation yours are, there
is a very quick way to tell: If it has a removable USB cable, it is a third generation unit.
ADAP-GCN64-USB: N64 or Gamecube controller to USB adapter (no longer manufactured)
ADAP-N64-USB: N64 controller to USB adapter (no longer manufactured)
Note: It's not that I do not want to support old versions. It's just that direct
controller communication is not possible with those.
How it works
Here is a diagram outlining the main differences between the usual architecture (input-sdl) and this plugin.
The normal event chain is more or less the following: (written with mupen64plus in mind, but also applies to project64)
The adapter polls the controller and stores the answer containing button and axis status data in RAM.
The host PC polls the adapter over USB and receives the most recently read data.
This newly received data makes its way through a few software layers including the HID driver, the DirectX (DirectInput) or
joystick driver and the SDL library. (The data is in fact stored in a buffer somewhere)
When the game being emulated requests a controller status update, an answer is built using the most recent
data returned by the SDL library.
The emulator does not need to wait. Relatively fresh data is always available immediately (the SDL library returns it without delay)
so the emulator only needs to reformat the data to make it look like what a real controller would answer.
This approach works with almost all controllers and adapters usable through SDL.
The exact axis value are often lost (calibration, dead-zone, assumptions on the exact axis range from the part of the emulator
that are not met by the adapter-driver stack, etc) and restoring the original feel can require a lot of subjective tweaking.
The emulator needs to know what kind of pack to emulate (i.e. mempak or rumble a pack?). This means the user must
configure this depending on the game. While rumble packs can work mostly as intended (through HID PID) mempack emulation
is almost always virtual (i.e. file-backed).
The "direct access" event chain is more or less the following:
The emulated game requests a controller status update.
The plugin forwards the request as-is to the adapter through USB.
The adapter in turn forwards it to the actual controller (or other peripheral).
The controller (or peripheral) answers the request.
The adapter receives the answer and retransmits it through USB.
The input plugin receives it and serves it unmodified to the game.
The game actually communicates with the controller. Accessoires such as memory packs and rumble packs (and potentially
others) are therefore supported natively.
The answer from the controller does not undergo any transformation. The axis values received by the game are
exactly what they would be on a non-emulated setup. No unknowns and no tweaking!
Since the request has to do a round-trip to the controller, the action of reading the
controller status takes a bit more time. When there are a lot of exchanges (especially when writing
and reading mempacks) this can cause a temporary slow down of the emulator.
Only possible on adapters offering a way to communicate with the controllers directly. (For me of course that's a pro)
The .zip files for Project 64 (see the download section) contains several raphnetraw DLLs. Here's a summary
of what those are and what they are for:
Purpose and description
The standard version. Supports up to 4 players through any combination of 1 and 2 player adapters.
Special version supporting only one controller, regardless of how many ports your adapter has. Meant
for use with dual-controller adapters where there can be, depending on the game, a small performance penalty
caused by polling the second (unused or absent) controller.
If you mostly play alone, you should use this version. When playing with friends, you should use the above (Standard)
Ports 1 and 3
Special build where the first two adapter ports are mapped to ports 1 and 3 on the emulated N64 console.
Intended to be used with Densha de GO! where the game expects a special controller in port 3.
Ports 1 and 4
Special build where the first two adapter ports are mapped to ports 1 and 4 on the emulated N64 console.
Intended to use with the VRU which must be connected to port 4.
There are some (currently) unexplained compatiblity issues for netplay with Project64k. It does not work
unless a very old adapter firmware (v3.3.2) is used. A feature was introduced in firmware version 3.4.0 to
boost performance, and raphnetraw v0.9.4 make use of it, but when this feature is used, it breaks netplay...
As a temporary solution, this version disables the use of the offending feature and hopefully fixes netplay.
Question: Which file do I need? What is the difference between the .zip and .tar.gz files?
Answer: The .zip files contain ready to use plugin files (.DLL) for Windows. The .tar.gz files
contain the source code. If using Linux, this is what you need.
Only handle channels supported by the adapter. This increases performance (reduces lag) by preventing meaningless attempts to communicate with controllers connected to non-existing ports on the adapter. It also fixes issues where games would see more controllers than actually present (on single-player adapters).
Changed the plugin specification version (Now using v1.0 instead of v1.1) in order to be usable with old Project 64 releases (v1.4 - v1.6).
Changes common to both plugins:
Controller polling is now disabled only while a ROM is open. (In the previous version, after using the plugin, to use the adapter normally (eg: Through DirectInput) one had to disconnect and reconnect it.
If you use a 64-bit version of mupen64plus, copy the files from the dist_win64 directory. For
the 32-bit version, copy the files from the dist_win32 directory.
Copy the appropriate plugin (.dll files) to the directory your mupen64plus installation uses for plugins (eg: Along
with the main executable and other plugin .DLL files). Then run the emulator like this:
(of course you will add other arguments such as the rom file...)
Confirming that it works (mupen64plus)
If you are not sure if you were able to enable, have a look to the emulator output:
I cannot be held responsible for any damages that could occur to you
or your equipment while following the procedures present on this page.
Also, I GIVE ABSOLUTELY NO WARRANTY on the correctness and usability
of the informations on this page. Please note, however, that the procedures
above have worked in my case without any damages or problems.