raphnet / gc_n64_usb-v3 Goto Github PK

Hi. I'm currently building one of the Raphnet GC/N64 to UISB V3 adapters using an Arduino Leonardo (ATmega32u4). Everything is working fine but I noticed an inconvenient behavior (maybe also not intened behavior or a bug) while changing modes. If I use the cmd to execute "gcn64ctl -f --set_mode 0" (Singleplayer) or "gcn64ctl -f --set_mode 16" (Dual Player), I need to disconnect and reconnect the USB cable to my PC so that the adapter gets recogniced correctly. I don't know if that is a bug or intended behavior but it would be definitely more conveniant if the change could be made without reconnecting the USB. Took me some hours to find this out. At first I thought it just wouldn't work at all (when executing the commands the only thing that changed inside the adapter manager were the adapter modes. But the adapter didn't actually used these modes until I learned that I had to reconnect).

Hello awesome project!

I was wondering,
Will it be possible to integrate an esp32 chip to send inputs via Bluetooth like this project https://github.com/NathanReeves/BlueCubeMod ?

I’m secretly dreaming of the ascii GameCube keyboard in Bluetooth ..

Ability to interface with Dolphin for use with it's implementation of Game Boy Advance to GameCube Connectivity when using the "GameCube – Game Boy Advance link cable"

When loading a controller rom off of a flash cart, (example: https://github.com/extremscorner/gba-as-controller), or via downloading the file directly from a Gamecube running Gameboy Interface or Gameboy Player software, It will connect through the adapter for use as a controller. However there is no ability to communicate with emulators for games such as Four Swords Adventures or Wind Waker because the serial connection is not currently supported on this (or any other existing) adapter.

https://wiki.dolphin-emu.org/index.php/The_Legend_of_Zelda:_Four_Swords_Adventures#Game_Boy_Advance_.3C-.3E_GameCube_Connectivity

Hi.
I'm currently playing around with the code (I'm using an ATmega32u4) and ran into an issue. Since there is no forum or other way I thought that I might get some help here. I should mention that I have no prior experience with AVR and only few experience with C.
What I'm trying to do is to use PD4 as an input pin to switch between single mode and dual mode (high = dual, low = single).

So what I did first was to modify main.c line 533:
DDRD = 0x60;
Setting it to 0x60 instead of 0x70 just enables PD4 as an input while keeping the other pins the same they were before.

Then inside the int main function during the while(1) loop I inserted after line 747:

if(!(PIND & 0x10) && g_eeprom_data.cfg.mode == 16)		// if PD4 is low and we are in dual mode change to single mode
{
	g_eeprom_data.cfg.mode = 0;
} else if((PIND & 0x10) && g_eeprom_data.cfg.mode == 0))	// if PD4 is high and we are in single mode change to dual mode
{
	g_eeprom_data.cfg.mode = 16;
}

Ok that seems to work. If I unplug the usb cable and then replug it again it typically changes the mode if I pull PD4 low or high (sometimes two replugs are needed). So I just tried to reset the adapter from code like this:

if(!(PIND & 0x10) && g_eeprom_data.cfg.mode == 16)		// if PD4 is low and we are in dual mode change to single mode
{
	g_eeprom_data.cfg.mode = 0;
	resetFirmware();
} else if((PIND & 0x10) && g_eeprom_data.cfg.mode == 0)	// if PD4 is high and we are in single mode change to dual mode
{
	g_eeprom_data.cfg.mode = 16;
	resetFirmware();
}

And now the adapter just doesn't get recognized if the code is called. I guess it just ends in an endless loop or something.
So my next idea was to just give it some time before resetting by using a while loop that runs for a short time. So I defined an interger variable like this: uint32_t shouldReset = 0;
And the code looks like this:

if(!(PIND & 0x10) && g_eeprom_data.cfg.mode == 16)		// if PD4 is low and we are in dual mode change to single mode
{
	g_eeprom_data.cfg.mode = 0;
	while(shouldReset < 20000)
	{
		shouldReset++;
	}
	shouldReset = 0;
	resetFirmware();
} else if((PIND & 0x10) && g_eeprom_data.cfg.mode == 0)	// if PD4 is high and we are in single mode change to dual mode
{
	g_eeprom_data.cfg.mode = 16;
	while(shouldReset < 20000)
	{
		shouldReset++;
	}
	shouldReset = 0;
	resetFirmware();
}

Now everything gets out of control. Sometimes it works after some reset attemts, sometimes it just hangs up and sometimes nothing happens. I then tried to get it into the cmdbuf inside of hiddata.c. Sadly I was unable to get any success that way.
However since it works really well with the command line (gcn64ctl -f --set_mode 16 --reset) I would assume that the problem I have is related to interrupts. I'm really new to AVR but I guess that these USB commands trigger some sort of interrupt.
That's where I'm currently at. If anyone could tell me how to properly trigger the resetFirmware() function I would highly appreciate it.

Thanks and have a nice day

• Jannis

Just thought Id ask since arduino unos are extremely common, its also found on the pro mini

The left thumbstick is biased to the downward position on the (1) port of the gc usb adapter v3 2 player version where as the other lead unmarked but assumed to be (2) does not exhibit any bias away from the center. When swapping controllers plug position the (1) port yields the same biased result independent of which controller is plugged in.

In windows 10 when using the 2.1.5 raphnet-tech adapter manager and with an adapter updated with the 3.5 version of the firmware the vibration test does not function. When trying the same adapter but with the 3.4 firmware loaded the vibration test functions on a standard DOL-003 controller but not on a wavebird DOL-004 controller. Trying older firmware yields the same results as 3.4.

Unlike the original Brawler 64 (as tested by Utilisateur), the wireless edition of the Brawler 64 controller that was just released does not work with the adapter in 3.6.

So, this Dolphin version is very updated but I can't seem to make the vibration work when setting up the GC controller in Dolphin.

I've tried all vibration methods available there (such as Sine, Ramp etc) and the test will never make the controller vibrate. Vibration works fine in the adapter manager testing though.

Is this a Dolphin issue?

Thanks in advance for any help.

The first time I tried I hadn't the management tool updated. Then I updated it but even after that I'm getting an "update failed" while trying to update to firmware version 3.6. It always fails before reaching 30%.

I'm using Win 7.

Any help would be appreciated. Thanks!

I recently purchased this adapter, and was disappointed that it did not work out-of-the-box with retroarch: while 9 N64 buttons did get detected, 5 did not trigger any event.

I dug a bit, and the first level of this issue is that SDL2 lacks a profile for this controller, and the one it seems to internally auto-generate is incorrect (in my case, preventing L, R, Z, Cleft and Cright from being detected). I have not dug into SDL2's default mapping yet.

This can be worked around by the following controllermap line:

030000009b2800006000000001010000,raphnet technologies GC/N64 to USB v3.6,platform:Linux,a:b0,b:b1,start:b3,leftshoulder:b4,rightshoulder:b5,dpup:b10,dpdown:b11,dpleft:b12,dpright:b13,leftx:a0,lefty:a1,-rightx:b8,+rightx:b9,-righty:b6,+righty:b7,lefttrigger:b2,

and by setting the SDL_GAMECONTROLLERCONFIG_FILE environment variable to that file's path before running retroarch.
I could then assign all the buttons:

$ cat ~/.config/retroarch/autoconfig/sdl2/raphnet\ technologies\ GC_N64\ to\ USB\ v3.6.cfg
input_driver = "sdl2"
input_device = "raphnet technologies GC/N64 to USB v3.6"
input_vendor_id = "10395"
input_product_id = "96"
input_a_btn = "0"
input_b_btn = "1"
input_l2_btn = "2"
input_start_btn = "6"
input_l_btn = "9"
input_r_btn = "10"
input_r_y_minus_btn = "6"
input_r_y_plus_btn = "7"
input_r_x_minus_btn = "8"
input_r_x_plus_btn = "9"
input_up_btn = "11"
input_down_btn = "12"
input_left_btn = "13"
input_right_btn = "14"
input_l_x_plus_axis = "+0"
input_l_x_minus_axis = "-0"
input_l_y_plus_axis = "+1"
input_l_y_minus_axis = "-1"
input_l2_axis = "+4"
input_r_x_plus_axis = "+2"
input_r_x_minus_axis = "-2"
input_r_y_plus_axis = "+3"
input_r_y_minus_axis = "-3"

The second level of this issue is that retroarch cannot provide a default mapping for this adapter, because they cannot distinguish between an N64 controller and a GC controller being plugged in, and both will report different events for the "same" button. This applies to the above SDL2 controllermap, which will likely only work for N64 controllers (I do not have a GC controller at the moment to confirm this, though).

Here is an idea I had: could the adapter change its descriptors based on what controller is plugged in ? I believe it could be:

• its current descriptor (possibly without the controller HID descriptors) when no controller is plugged, allowing to configure and flash it
• an N64-only adapter descriptor (with another product id) when an N64 controller is plugged
• a CG-only adapter descriptor (with yet another product id) when a GC controller is plugged
  Mode change would be disabled during flashing, but I believe it is already the case (but did not check the code) as I expect DFU mode to not provide any HID event.

I believe it should be possible for the device to disconnect itself from the bus and then to reconnect itself, in order to trigger a new enumeration, allowing the descriptor changes to be noticed by the host, but I have not checked its documentation (I know it is possible on the Cypress FX2 µC).

If this is done, then it becomes reliably possible to write:

• SDL2 controllermaps, which could either be upstreamed to SDL2 or automatically registered in retroarch when initialising the SDL2 input plugin
• retroarch default mappings
  which I think would improve the user experience out-of-the-box.