What is it?

This adapter lets you use a Nintendo 64 controller to play Wii Virtual Console rereleases of Nintendo 64 games, rather than a GameCube controller.

Unlike other Nintendo 64 to GameCube adapters, this is the first and only adapter which features accurate analogue stick correction for every Wii Virtual Console release. This makes playing feel exactly like playing on the N64!

Features

The Wii Virtual Console Stick Mapping:

In order to compensate for the differences between a Nintendo GameCube analogue stick, and a Nintendo 64 analogue stick, Nintendo implemented a mapping function in the Wii Virtual Console (as well as in the GameCube rereleases of OOT and MM). This function takes a pair of GameCube X and Y joystick values, and via a complex 2-dimensional mapping function, converts them to X and Y in-game N64 joystick values.

I have plotted four of the 2-dimensional mapping functions as surface plots for a single axis, so you can clearly see the problem at hand... and why assuming linearity simply won't work:

The Solution:

In order to get the correct analogue stick values in-game, the adapter needs to know the exact function mapping performed by each game on the Wii Virtual Console. The adapter can then lookup the values required in-game, and figure out what X and Y values need to be fed into the Wii (or GameCube) in order for it to reproduce the original values in-game. In practice, this is done by storing the inverse-function mapping on the adapter, allowing it to quickly lookup the required X and Y values in real-time, without any lag!

Here are the same surface plots as before, now both without the adapter (left) and with the adapter (right):

Within the possible Nintendo 64 range (-80 to +80), the plots look much more linear than they did before, and you can see the deadzone is gone. Note that values outside the possible N64 stick range are not possible in-game, and are therefore mapped manually to the closest possible values which preserve the angle of the joystick. This is why the graphs are not linear at the edges, but the adapter will still function correctly in-game. This makes the adapter work just as well with third-party controllers, which might have a larger range than the official N64 controller, such as the Hori Mini Pad.

Here are the same plots again, but after restricting the range to what is possible on a Nintendo 64 controller. This shows much more clearly the success of the adapter at inverting the four mapping functions:

Virtually no input lag?

That's right! Other popular adapters use a microcontroller, which are not able to truly multitask. The way in which they work is they poll the Nintendo 64 controller once every 5 milliseconds, and once the Wii / GameCube polls the adapter, the latest inputs are used. This means there can be up to 5 milliseconds of lag for any given input frame.

My adapter works differently, in that it uses a CPLD, rather than a microcontroller... this allows it to truly perform multiple operations at once. Because of this, the adapter can poll the Nintendo 64 controller after it starts to get polled by the Wii / GameCube, and still respond within the same frame! meaning it very consistantly has unbeatable input lag of around 0.1 - 0.2ms.

The graphic below demonstrates the difference between the worst-case delay for my adapter, compared to other adapters which poll once every 5 milliseconds:

If any N64 button is pressed, or input occurs during the green region, the adapter will correctly inform the console the next time it polls the adapter, meaning no lag is experienced for that particular input. However, if the input occurs within the red region, the adapter will not catch it in-time to make the current frame... meaning you will experience an entire frame of input lag in that instance!

In reality, even a worst-case delay of 5 milliseconds is still pretty good... for reference, many HDTV's have an input delay of multiple frames when upscaling old analogue video, which will be in the order of hundreds of milliseconds! So you're likely not going to notice the ~5ms difference (worst-case) unless you're really picky... but I challenge anybody to be able to spot the difference between no lag, and 0.2ms of lag!

GameCube to N64 Stick Mapping (Dual-Input Version Only)

In order to invert the Wii VC stick mapping for a GameCube controller, the same inverse mapping function is used. However, before the GameCube controller stick values can be passed into the inverse Wii VC mapping function, they first have to be shifted and squashed in order to fit into the range of a Nintendo 64 controller's analogue stick. In order to achieve full range in the diagonals, the corners also need to be stretched to fit the shape of the N64 stick.

Different adapters have their own mappings for this, and my adapter has two built-in mappings which can be used. One is my own custom mapping, and the other is a mapping identical to the GC->N64 Raphnet Version 2.0 adapter mapping.

Here is a plot of the possible range of the stick of an official GameCube controller:

And here is a plot of the possible range of the stick of an official Nintendo 64 controller:

In order to display how values are mapped across the entire range of the stick, I will show plots of various GameCube stick values within the normal working range both before being mapped, and after being mapped into the range of a Nintendo 64 stick.

Here is a plot of a variety of possible GameCube analogue stick values before being mapped:

And here are the same values again, but after being put through my mapping function:

As you can see, the values are mapped to precisely fit within the working range of an official Nintendo 64 controller. The overall range is squashed, and the diagonals are stretched out by the minimum amount necessary to allow full range in every Nintendo 64 rerelease.

There are two main benefits to my mapping compared to many other mappings available, which make playing with a GameCube controller feel as close as possible to playing with a Nintendo 64 controller:

• More Precision - All values are stretched by no more than is absolutely necessary. This gives you a greater amount of precision across the entire working range, since no part of the GameCube stick range is wasted on values which aren't even possible with a Nintendo 64 controller.
  
  
• Unskewed Central Values - The diagonal values do not get warped equally across the entire range. Values closer to the edge of the stick range are warped by a larger amount than the more central values. This means that many of the diagonal values are not altered, meaning movements around the center of the stick's range do not get skewed at all!

Here is a animation of the values before the diagonals are warped, and after they get warped. As you can see, many of the central values are left completely unchanged, giving a smoother, and more original feel across the majority of the stick range:

Since the Raphnet GameCube to N64 adapter is a very popular adapter, I decided to include a mapping identical to their version 2.0 stick mapping in addition to my own. This is selectable via a switch on the side of the adapter.

This means people who are used to playing with a GameCube controller on the Nintendo 64 using the Raphnet (version 2.0) adapter, can play any Wii VC release with my adapter, and it will feel exactly the same.

For reference, here are the same GameCube plots as before, but after being warped by the Raphnet mapping:

It is personal preference which mapping you choose, and I decided to include it to give people the choice. However, in my opinion, there are a few reasons why their mapping isn't the better of the two:

• Less Precision - The values (especially the diagonals) are stretched more than necessary. It is clear from looking at the plot that the values are all much more significantly warped throughout the entire range of the stick. This makes the warped range appear much more square than octagonal! This gives you less precision in the analogue stick compared to my own mapping.
  
  
• Inaccurate Range and Angles - To compensate for the over-stretching of the values, they are clamped between -80 and +80 as can be seen in the plot. This gives the illusion of an accurate stick mapping, but it is clear from looking at the inner values that they would've been much too high otherwise. Clamping the values like this will cause angles to be very slightly off if the stick is at (or near) full range.
  
  
• Values Too High Proportionally - Diagonal values are warped throughout the entire range of the stick, even in central areas where precise movements may be required. This will make all diagonal values consistantly higher than they actually are, potentially making movements feel less smooth, and less like playing on N64. This can be very clearly seen when comparing the animation of my mapping above, to the animation of this mapping below. Far fewer values get warped in my mapping, and the onces which do get warped by a smaller amount.
  
  
• Zero Isn't Zero!? - The mapping is offset by -1 in the y-axis. This isn't a problem with my version of the mapping, this is how it actually is for some reason. Realistically this isn't noticeable, and therefore isn't really a problem... but it's definitely weird.

As with my mapping, here is a animation of the same values before the diagonals are warped, and after they get warped by the Raphnet mapping. This makes it much clearer to see that the values are warped much higher than necessary, throughout the entire stick range: