Hacking Feedback Homebrew Nintendont + Autoboot: Fixing WiiUGamepadSlot for Fun and (not) Profit

[ghostserverd]

TLDR

I have two PRs that will enable the WiiUGamepadSlot feature for injected / autoboot games with Nintendont. I'm sending out a flare to find whomever might be able to review those PRs so we can get this feature enabled for those who want to use it.

1. Nintendont PR is here

https://github.com/FIX94/Nintendont/pull/1054

• nintendont-autoboot-forwarder PR is here

https://github.com/FIX94/nintendont-autoboot-forwarder/pull/7


Then we can go about getting the injectors (TeconMoon's, UWUVCI, Wii U USB Helper) updated so everyone can configure their WiiUGamepadSlot to their heart's content.


A medium-deep dive and explanation for these changes is below.

Background

My personal goal for my Wii U is to essentially turn it into a Gamecube. I want to play all of my old GameCube games (which I still physically have in a box in a closet upstairs) with a native HDMI output and newer controllers (Wii U Pro Controllers).


The requirements I set for myself for this project are:

1. Launch Gamecube games directly from the Wii U Home Menu (injected Nintendont autoboot).
2. Launch a game, play it, quit the game with the Wii U Pro Controller (without picking up the Wii U Gamepad or a Wiimote).
3. Be able to use the Wii U Gamepad as a controller if necessary (to support additional players).

Some games (e.g. Super Smash Bros Melee) don't really care which slot a controller is in, but for other games (e.g. Mario Kart Double Dash) the first controller is the only one that can navigate the menu.


This means that in order to accomplish requirement 2, I need to be able to be able to configure Nintendont to assign a Wii U Pro Controller as the first controller.


After setting up my Wii U with Tiramisu and installing Nintendont, I discovered 2 things:

1. There is a setting in Nintendont called WiiUGamepadSlot to configure which controller slot the Wii U Gamepad occupies.
2. The setting does not work for games installed with an injector and launched from the Wii U Home Menu.

I did notice that when launching Nintendont first and then starting a game from within Nintendont, the Wii U Gamepad would be in the slot defined by WiiUGamepadSlot. So that setting worked. It only stopped working when launching a game injected and then installed to the Wii U Home Menu.


I beat my head against a wall trying a bunch of different things to get it to work (different builds of TeconMoon's injector, different injectors alltogether, different config files, different builds of Nintendont), but no matter what I tried, the Wii U Gamepad always took up the first controller slot.


I was almost resigned to just launching games directly from Nintendont, but I was just too obsessed with playing ATV 2 Quad Power Racing without using the Wii U Gamepad, so I set out to try to figure out how I could get this to work.


This is a chronicle of the fixes I implemented, the things I learned along the way, and at the end, a call to action to hopefully get this fixed for the community once and for all.


First, some background about the WiiUGamepadSlot setting.

WiiUGamepadSlot

In 2018, a request was made in the Nintendont repo to allow disabling the Wii U Gamepad or choosing its controller slot. Eventually someone made a fork of Nintendont with a change to disable the gamepad entirely.

This actually helps get me pretty dang close to my goals, except for the 3rd one. And I almost just stopped here with the intention of buying more Pro Controllers so I wouldn't have to use the Gamepad at all.

3 years later, a PR was opened to allow choosing the controller slot for the Wii U Gamepad. This added a new configuration for Nintendont called WiiUGamepadSlot in the nincfg.bin format.


After that change was made, it was determined that it had introduced a bug where the Wii U Gamepad was disabled when Nintendont was in autoboot mode. So a workaround was introduced to always make the WiiUGamepadSlot be 0 if it was detected that Nintendont was running in autoboot mode.

if (((NIN_CFG*)0x93004000)->Config & NIN_CFG_AUTO_BOOT)
{
  if(HIDPad == HID_PAD_NONE)
    WiiUGamepadSlot = 0;
  else
    WiiUGamepadSlot = 1;
}

It's a good catch to make sure Nintendont can handle the various different controller configurations that people have. It does mean that when in autoboot mode, WiiUGamepadSlot will never work!

This is the first real clue about how there are different code paths for autoboot vs normal mode and where we might be able to implement a fix.

Let's look at how Nintendont configuration works next. Maybe that will provide some additional insight.

Nintendont configuration
nincfg.bin

Nintendont requires a nincfg.bin file in the root of your SD card to define its configuration.


From what I can tell, the nincfg.bin file format is simply a binary representation of the NIN_CFG struct defined in Nintendont in common/include/CommonConfig.h.


When you launch Nintendont, change any setting, and start a game, it updates the nincfg.bin with your changed configuration.

There is also a tool called Nicoe which can read and modify a nincfg.bin file from a Windows PC (and without having to launch Nintendont on a Wii U).

Initializing NIN_CFG

The NIN_CFG struct defines the settings and format for configuring Nintendont.

#ifndef __COMMON_CONFIG_H__
#define __COMMON_CONFIG_H__

#include "NintendontVersion.h"
#include "Metadata.h"

#define NIN_CFG_VERSION        0x0000000A

#define NIN_CFG_MAXPAD 4

typedef struct NIN_CFG
{
    unsigned int        Magicbytes;        // 0x01070CF6
    unsigned int        Version;        // 0x00000001
    unsigned int        Config;
    unsigned int        VideoMode;
    unsigned int        Language;
    char    GamePath[255];
    char    CheatPath[255];
    unsigned int        MaxPads;
    unsigned int        GameID;
    unsigned char        MemCardBlocks;
    signed char            VideoScale;
    signed char            VideoOffset;
    unsigned char        NetworkProfile;
    unsigned int        WiiUGamepadSlot;
} NIN_CFG;

...

In normal mode (i.e. not autoboot / injected mode, i.e. starting a game from the Nintendont menu) Nintendont loads sizeof(NIN_CFG) bytes of the nincfg.bin file into a memory block that is the same size as the NIN_CFG struct.

FIL cfg;
if (f_open_char(&cfg, "/nincfg.bin", FA_READ|FA_OPEN_EXISTING) != FR_OK)
    return false;

// Read the configuration file into memory.
UINT BytesRead;
f_read(&cfg, ncfg, sizeof(NIN_CFG), &BytesRead);

In autoboot mode, whatever is initializing Nintendont (the forwarder) passes the NIN_CFG bytes as an argument, and Nintendont copies those bytes into a memory block that is the same size as the NIN_CFG struct.

memcpy(ncfg, argv[1], sizeof(NIN_CFG));

This is another critical difference in functionality that hints at why WiiUGamepadSlot works in normal mode but not autoboot mode.

Versioning and backwards compatibility

Nintendont makes some provisions to sanitize config files that may not be fully up-to-date with the latest version of the config format. The NIN_CFG struct contains a Version property, and when Nintendont detects that the version of the config that was loaded is older than the current version, it sets some defaults for properties that did not exist in previous versions and updates the Version in the struct to the latest.


The important thing to note for our purposes is this:

  if (ncfg->Version == 9) {
    ncfg->WiiUGamepadSlot = 0;
    ncfg->Version = 10;
  }

The current version of NIN_CFG is 10 (0xA in hex)


If the Version in the NIN_CFG struct is 9, WiiUGamepadSlot gets initialized to 0.


So the expectation is that if you have a NIN_CFG of version 10, the WiiUGamepadSlot value is already defined, and it doesn't need to be initialized with some default value.

This points to a liklihood that Nintendont is being initialized with a NIN_CFG of version 10, but no (valid) WiiUGamepadSlot is set.

Here's the nincfg.bin I'm using opened in Nicoe. It's version 10, and WiiUGamepadSlot is 2 (this is 0-indexed so it's really the third controller slot).

This nincfg.bin is a perfectly valid Version 10 config file. Remember, launching a game from within Nintendont results in the Wii U Gamepad being assigned to the third controller slot as expected.


So maybe there's something about the injection / autoboot process that's going wrong? How do those injectors work anyway?

Autoboot forwarding

I'm going to focus on TeconMoon's Wii VC injector. There are other injectors (e.g. UWUVCI and I believe Wii U USB Helper has some injection capabilities), but I'm most familiar with TeconMoon's at the moment. Also TeconMoon's injector supports custom forwarders which is helpful for fixing the issue with WiiUGamepadSlot and autoboot.

There is a ton of detail I'm going to skip over related to Wii VC injection (mostly because I don't actually know all of the details), but for our purposes and at a very high level, an injector creates an installable file or files (likely WUP format) that you can install as a Title to your Wii U Home Menu (using e.g. WUP Installer) , which places an icon on your Wii U home page to launch some application (in our case it needs to launch the Wii VC with Nintendont and a GameCube game).


We need something to tell Nintendont to automatically launch a game instead of booting to the Nintendont menu.


Maybe something like

a simple forwarder for wii vc to autoboot a included game

Enter nintendont-autoboot-forwarder (that above comment is from the README).


Now I don't know all of the technical details, but from what I can gather, TeconMoon's injector "injects" this forwarder in the Wii VC so that when Wii VC is launched, it automatically starts Nintendont via the autoboot forwarder (my terminology is probably not quite right here, but hopefully it's close enough).


If you download the TOOLDIR from TeconMoon's injector source and unzip it, you'll find compiled dol files from the releases page of the nintendont-autoboot-forwarder repo.


If we go look at the main.c file for the forwarder, we can see a couple of interesting things:

1. 
   It reads nincfg.bin from the sd card (kind of like how Nintendont does)
   
   

   f = fopen("sd:/nincfg.bin","rb");

2. 
   It loads the contents of the file into memory (also similar to how Nintendont does)
   
   

   fread(&nincfg,1,sizeof(NIN_CFG),f);

3. 
   And then after potentially making some changes to the config (e.g. disabling all widescreen bits), it writes the config bytes back to some memory address for Nintendont to eventually read from.
   
   

   memcpy(CMD_ADDR+full_fPath_len, &nincfg, sizeof(NIN_CFG));

Notice how we're consistently using sizeof(NIN_CFG) to determine how many bytes to read in and out of memory. This is the key for why Nintendont is failing to load WiiUGamepadSlot properly in autoboot mode.

• 
  nintendont-autoboot-forwarder also has a /source/CommonConfig.h file that looks awfully familiar.
  
  

  #ifndef __COMMON_CONFIG_H__
  #define __COMMON_CONFIG_H__
  
  //#include "NintendontVersion.h"
  //#include "Metadata.h"
  
  #define NIN_CFG_VERSION        0x00000008
  
  #define NIN_CFG_MAXPAD 4
  
  typedef struct NIN_CFG
  {
    unsigned int        Magicbytes;        // 0x01070CF6
    unsigned int        Version;        // 0x00000001
    unsigned int        Config;
    unsigned int        VideoMode;
    unsigned int        Language;
    char    GamePath[255];
    char    CheatPath[255];
    unsigned int        MaxPads;
    unsigned int        GameID;
    unsigned char        MemCardBlocks;
    signed char            VideoScale;
    signed char            VideoOffset;
    unsigned char        Unused;
  } NIN_CFG;
  
  ...

Yes that is the same (almost) CommonConfig.h file that Nintendont has! In fact, you can tell it was probably copied from a previous version of Nintendont because it has some commented out lines that reference header files in Nintendont that we don't have here.


There are a few things different about this file though:

1. 
   It's out of date. This file supports NIN_CFG only up to version 8.
   
   

   #define NIN_CFG_VERSION        0x00000008

   
   But the version in Nintendont is 10.
   
   

   #define NIN_CFG_VERSION        0x0000000A

2. 
   The NIN_CFG struct is a different size. It's 1 unsigned int (4 bytes if I'm not mistaken that Wii U has a 32-bit processor) shorter than the NIN_CFG defined in Nintendont. And that unsigned int is WiiUGamepadSlot.

The problem

Now that we're (somewhat?) up to speed on configuring and autobooting Nintendont, we can start to see what the source of the problem is. There are pieces missing in both Nintendont and nintendont-autoboot-forwarder that, together, cause WiiUGamepadSlot to be broken in autoboot mode.

I'm going to refer to NIN_CFG in Nintendont as NIN_CFG_10 and the one in nintendont-autoboot-forwarder as NIN_CFG_8.

nintendont-autoboot-forwarder

1. When nintendont-autoboot-forwarder reads nincfg.bin into memory, it reads sizeof(NIN_CFG_8) bytes of the file (missing the last 4 bytes of WiiUGamepadSlot).
2. When nintendont-autoboot-forwarder copies NIN_CFG for Nintendont to read, it writes sizeof(NIN_CFG_8) bytes into memory (again, missing the WiiUGamepadSlot bytes)
3. Because the version of the file that nintendont-autoboot-fowarder loaded is 10, the Version property of the NIN_CFG struct that it writes to memory is 10 (even though it's missing the expected WiiUGamepadSlot bytes).

Nintendont

1. When Nintendont loads NIN_CFG from memory in autoboot mode, it copies sizeof(NIN_CFG_10) bytes from memory. That means it's copying an extra 4 bytes that were never written by the forwarder. When this happens, it is UNDEFINED BEHAVIOR (scary) which basically means "who knows what happens". I think what's most likely is that whatever bytes are in memory at those next memory addresses are copied into the 4 bytes of the WiiUGamepadSlot, so it likely is some value between 0 and 4,294,967,295. Now I don't think Nintendont is really equiped to handle a couple billion controllers, so it breaks in unexpected ways (like causing the Wii U Gamepad to be disabled all together).
2. When Nintendont goes to apply a backwards compatibility fix (and set WiiUGamepadSlot to something more sane, like 0) it sees that the config file is version 10, so it skips that logic.

So in autoboot mode, Nintendont ends up with a NIN_CFG that has garbage bytes for WiiUGamepadSlot. If we can fix this, I can accomplish all of my goals, and finally beat my time trial record on Baby Park from 20 years ago.

The fix(es)

In Nintendont (PR here)

There's already a workaround in place that sets the WiiUGamepadSlot to 0 in autoboot mode. But we want to be able to actually use WiiUGamepadSlot in autoboot mode, so we need to replace that. But we also don't want to break the Wii U Gamepad functionality for folks with older nincfg.bin files.

1. Add a fix in the backwards compatibility code to set WiiUGamepadSlot to 0 if we detect that it's invalid (likely because we loaded a NIN_CFG that is too small) even if the config that was loaded is version 10.
   

   if (ncfg->Version == 10)
   {
     // NIN_CFG with version 10 may have loaded
     // garbage bytes into WiiUGamepadSlot so sanitize
     // the slot if necessary.
     if (ncfg->WiiUGamepadSlot > NIN_CFG_MAXPAD)
     {
       ncfg->WiiUGamepadSlot = 0;
     }
   }

2. Remove the workaround fix for autoboot mode while retaining the logic to move the WiiUGamepadSlot up to the second controller slot if there's an HIDPad plugged in.

With Nintendont updated to allow WiiUGamepadSlot even in autoboot mode, we can upgrade nintendont-autoboot-forwarder with some fixes.

In nintendont-autoboot-forwarder (PR here)

1. Upgrade forwarder to support version 10 of NIN_CFG struct (literally a copy and paste of the same file from Nintendont).
2. Set the version of the config that is actually being written by the forwarder rather than the version specified in the file, because if the forwarder isn't up to date with the config file version, it's really writing an older version to memory (this isn't strictly necessary, but I think it's a good improvement to have going forward).

In the injectors

Once those two changes for Nintendont and the forwarder are merged and released, the injectors need to be updated to use the newer version of the forwarder. I'm planning on reaching out to the developers of TeconMoon's injector, UWUVCI, and Wii U USB Helper once we have newer releases of Nintendont and nintendont-autoboot-forwarder so those tools can get updated.

TeconMoon's injector supports custom main.dol files when injecting. So if you build the nintendont-autoboot-forwarder from my fork, you can choose that main.dol in the injection settings to avoid having to wait for the tool to officially update. Really awesome feature from that injector. Other injectors may have that capability as well, but I haven't tried them.

Conclusion and request for help

So there you have it. With those changes to Nintendont and nintendont-autoboot-forwarder (and using the custom main.dol for the forwarder with TeconMoon's injector), I'm able to accomplish all of my goals for my Wii-U-as-GameCube. I want to make these changes available to the community so other folks can use WiiUGamepadSlot with injected games.


I'm not really sure who maintains these projects anymore. They don't have a lot of activity on them these days. But I'm looking for someone to review these two pull requests and hopefully approve them, or provide feedback so I can make any necessary changes to get them merged.

1. Nintendont PR is here

https://github.com/FIX94/Nintendont/pull/1054

• nintendont-autoboot-forwarder PR is here

https://github.com/FIX94/nintendont-autoboot-forwarder/pull/7


Then we can go about getting the injectors updated so everyone can use this awesome feature.


Thank you for coming to my TED talk.

 

[Frege]

Thank you very much for this post. I recently updated my nintendon't and I think I was running a similar issue but regarding the virtual memory cards. Nintendon't is unable to read the multi-memory configuration from the NIN_CFG10 out of the NIN_CFG8 produced by the forwarder so it automatically resolves it as FALSE which means one memory for all games, which means I am unable to play my old save files unless I downgrade my nintendont (my most probable course of action for the time being) or the inconsistency gets fixed.

 

[ghostserverd]

Thank you very much for this post. I recently updated my nintendon't and I think I was running a similar issue but regarding the virtual memory cards. Nintendon't is unable to read the multi-memory configuration from the NIN_CFG10 out of the NIN_CFG8 produced by the forwarder so it automatically resolves it as FALSE which means one memory for all games, which means I am unable to play my old save files unless I downgrade my nintendont (my most probable course of action for the time being) or the inconsistency gets fixed.

TeconMoon's injector supports custom main.dol files when injecting. So if you build the nintendont-autoboot-forwarder from my fork, you can choose that main.dol in the injection settings to avoid having to wait for the tool to officially update.

I added setup / build instructions to the README that should work in a github codespace (https://github.com/features/codespaces) if you want to build it yourself. The result of the build should be a dol file.

You should be able to enable a custom forwarder with the Specify custom Nintendont Forwarder checkbox on the Advanced tab, and then the button where it says <- Specify custom main.dol file is where you'll choose your custom built main.dol file.

 

[Encarta]

I haven't got much to add myself, but I hate it when someone spends so much time and energy investigating and writing things down in great detail, as you have, and then the content gets barely any traction. It feels like such a waste of time and effort.
So I thought I'd at least comment with my issue and see if any thing comes from it.

I modded my wii and wiiU a few years back so I could install all of my (non Switch) Nintendo collection on the wiiU's usb hdd to then have all the games on one machine for convenience and best graphical quality.
I'm a bit foggy as to what I did and methods/software used but I have each console's folder with games injected that once i click on the haxchi icon, I can then click on the game's icon and it'll load up (wiiU games don't need the haxchi part).

I recently saw an official gamecube controller adapter in a shop that turns out, is for Switch or WiiU.
I only plugged in in for the 1st time today and couldn't get it to work as I expected.
I have it plugged into the front 2 usb ports, as the hdd is plugged into the back 2. (I tried black plug in one and grey in the other, and vice-versa and it made no difference.)
I loaded haxchi and then loaded up zelda 4 swords GC and tried with/without gamepad and no matter what the screen just goes black and the console locks up with needing the power plug pulled to restart.

I then loaded up Smash WiiU without needing haxchi, and that could let me use a GC controller.
I then tried loading up 4 swords without having the adapter attached, and it loaded, but once I connected it again, no controller worked.

I had a quick search on youtube and found a video that the person said, you need to have the black plug plugged into one of the rear ports, and only need the grey for rumble so it isn't critical to use it. But because of the hdd needing 2 usb ports it's not ideal. A couple of commenters said you can use the front ports fine, so I don't know if it's a case of software versions or files in folders or what.

Most people online that I can see in search results are debating over which adapters can work. Well I've got the official one so that's not an issue it seems.

As you've mentioned in your post, a newer version of nintendont may have made something worse. I'm a bit rusty on what I used and how to check versions etc. and even then, how to install different versions onto my wiiU.

Is there a simple way I can get this to work? Some say if adapter is disconnected when loading the GC game then reconnected it works. Some say you can use the front ports, but it has to be the '1st' one (I guess I need to look into which one that is). Some say the controller needs to be in the 1st port of the adapter...
I'll keep trying different variables, I just thought I may save myself time searching online first.

Beyond using GC controllers, my main target was to have 4 GBAs plugged into the adapter with link cables and be able to play 4 swords with my 3 kids.

Any help would be much appreciated, although I'm not likely to be of much help myself with regard to your original post I suspect.

Post automatically merged: Mar 18, 2023

So I went back and tried a few things again, and yes, I should have the adapter disconnected when loading up the GC games. Then I plug the black plug into the left front usb once the game's loaded (the one nearest the sd card slot) - don't know if this makes a difference?
Then I plug the gc controller into the adapter, sometimes I need to unplug then plug in again. I've not tried this with extra gc controllers yet e.g. for multiplayer.
I can plug the grey plug into the other port and that allows for rumble.

So then I tried plugging in a GBA SP, with the gc-gba link cable, and nothing happens. Tried it with 2 plugged in, as 2 are needed for multiplayer. Tried with the grey plug plugged in too. Still nothing.

I then looked online again, the consensus is the gba link cables with gbas won't work as the adapter is treated as a usb controller or something. This is really disappointing as it was the main reason I bought the adapter.
The other options I've got is either try playing 4 swords on my wii as the ports and gamecube gubbins are built in natively.
Or I could get into Dolphin emulation on PC and can use some methods that get little emulated GBA screens on the monitor, but that seems like much more effort than just using my wii.

 

[Frege]

TeconMoon's injector supports custom main.dol files when injecting. So if you build the nintendont-autoboot-forwarder from my fork, you can choose that main.dol in the injection settings to avoid having to wait for the tool to officially update.

I added setup / build instructions to the README that should work in a github codespace (https://github.com/features/codespaces) if you want to build it yourself. The result of the build should be a dol file.

You should be able to enable a custom forwarder with the Specify custom Nintendont Forwarder checkbox on the Advanced tab, and then the button where it says <- Specify custom main.dol file is where you'll choose your custom built main.dol file.

Hey! Thank you for the answer, it actually solved my problem, my injected nintendont files are working a-ok!

 

[concept8192]

Hello! This forwarder update you've drafted is really, really great! I've been waiting for this change for a while.
If I manually built your fork of nintendont-autoboot-forwarder, would it work, or do I need something else too? The Nintendont loader.dol seems to already have been updated since your commit was merged, but nintendont-autoboot-forwarder is still open. Is this correct?
Thank you

 

[fate6]

I haven't got much to add myself, but I hate it when someone spends so much time and energy investigating and writing things down in great detail, as you have, and then the content gets barely any traction. It feels like such a waste of time and effort.
So I thought I'd at least comment with my issue and see if any thing comes from it.

I modded my wii and wiiU a few years back so I could install all of my (non Switch) Nintendo collection on the wiiU's usb hdd to then have all the games on one machine for convenience and best graphical quality.
I'm a bit foggy as to what I did and methods/software used but I have each console's folder with games injected that once i click on the haxchi icon, I can then click on the game's icon and it'll load up (wiiU games don't need the haxchi part).

I recently saw an official gamecube controller adapter in a shop that turns out, is for Switch or WiiU.
I only plugged in in for the 1st time today and couldn't get it to work as I expected.
I have it plugged into the front 2 usb ports, as the hdd is plugged into the back 2. (I tried black plug in one and grey in the other, and vice-versa and it made no difference.)
I loaded haxchi and then loaded up zelda 4 swords GC and tried with/without gamepad and no matter what the screen just goes black and the console locks up with needing the power plug pulled to restart.

I then loaded up Smash WiiU without needing haxchi, and that could let me use a GC controller.
I then tried loading up 4 swords without having the adapter attached, and it loaded, but once I connected it again, no controller worked.

I had a quick search on youtube and found a video that the person said, you need to have the black plug plugged into one of the rear ports, and only need the grey for rumble so it isn't critical to use it. But because of the hdd needing 2 usb ports it's not ideal. A couple of commenters said you can use the front ports fine, so I don't know if it's a case of software versions or files in folders or what.

Most people online that I can see in search results are debating over which adapters can work. Well I've got the official one so that's not an issue it seems.

As you've mentioned in your post, a newer version of nintendont may have made something worse. I'm a bit rusty on what I used and how to check versions etc. and even then, how to install different versions onto my wiiU.

Is there a simple way I can get this to work? Some say if adapter is disconnected when loading the GC game then reconnected it works. Some say you can use the front ports, but it has to be the '1st' one (I guess I need to look into which one that is). Some say the controller needs to be in the 1st port of the adapter...
I'll keep trying different variables, I just thought I may save myself time searching online first.

Beyond using GC controllers, my main target was to have 4 GBAs plugged into the adapter with link cables and be able to play 4 swords with my 3 kids.

Any help would be much appreciated, although I'm not likely to be of much help myself with regard to your original post I suspect.

Post automatically merged: Mar 18, 2023

So I went back and tried a few things again, and yes, I should have the adapter disconnected when loading up the GC games. Then I plug the black plug into the left front usb once the game's loaded (the one nearest the sd card slot) - don't know if this makes a difference?
Then I plug the gc controller into the adapter, sometimes I need to unplug then plug in again. I've not tried this with extra gc controllers yet e.g. for multiplayer.
I can plug the grey plug into the other port and that allows for rumble.

So then I tried plugging in a GBA SP, with the gc-gba link cable, and nothing happens. Tried it with 2 plugged in, as 2 are needed for multiplayer. Tried with the grey plug plugged in too. Still nothing.

I then looked online again, the consensus is the gba link cables with gbas won't work as the adapter is treated as a usb controller or something. This is really disappointing as it was the main reason I bought the adapter.
The other options I've got is either try playing 4 swords on my wii as the ports and gamecube gubbins are built in natively.
Or I could get into Dolphin emulation on PC and can use some methods that get little emulated GBA screens on the monitor, but that seems like much more effort than just using my wii.

Taking a wild guess here but I assume what you are using is not a Ninty original adapter or one of those mayflash ones, if this is the case then nintendont simply doesn't know what to do with it and is crashing/hanging, plugin it in at different times might be getting past whatever is casuing it to hang then nintentont can see it for the GC adapter it is tho so thats good.
I know you say its an official one but just based on you saying its "for switch and wii u" it sounds like a third party adapter, a licensed one maybe but still not the Ninty original which is what stuff is looking for.

I use the original WUP-028 plugged into the front USB ports without issue so i can at least confirm it works with just the front USB ports.

Those third part adapters will work on stuff like Smash 4 but any homebrew will require updates or configs to work with it.
Now as for using GBA's that wont work as iirc the adapters are missing hardware for it, it just outright will never work unless someone feels like making a better adapter.

Could be miss remembering about that last part but coulda sworn at least.

 

[Encarta]

Taking a wild guess here but I assume what you are using is not a Ninty original adapter or one of those mayflash ones, if this is the case then nintendont simply doesn't know what to do with it and is crashing/hanging, plugin it in at different times might be getting past whatever is casuing it to hang then nintentont can see it for the GC adapter it is tho so thats good.
I know you say its an official one but just based on you saying its "for switch and wii u" it sounds like a third party adapter, a licensed one maybe but still not the Ninty original which is what stuff is looking for.

I use the original WUP-028 plugged into the front USB ports without issue so i can at least confirm it works with just the front USB ports.

Those third part adapters will work on stuff like Smash 4 but any homebrew will require updates or configs to work with it.
Now as for using GBA's that wont work as iirc the adapters are missing hardware for it, it just outright will never work unless someone feels like making a better adapter.

Could be miss remembering about that last part but coulda sworn at least.

Thanks for reply. Yes it's an official one, in a box with manual and everything. I bought it thinking it was the one from the Smash WiiU era, but realised when I got home it has 'for Switch' on too. I then saw somewhere else that they're basically the same thing except for the logo on top, as it would look a bit weird if Nintendo were selling them again for Switch Smash but it had a WiiU logo on top.
I don't know if you saw my last few paragraphs as I had a follow-up post merged with my original, but in addition to that; I tried on my Wii and for some reason (I previously had games installed on an external hdd at one point but have since disconnected and now just have 4 swords and FF Crystal Chronicles on a usb stick) in USB Loader GX (or whatever it's called) I can't get it to read the usb stick. So I instead went straight into Nintendont from the homebrew channel and it CAN see the games on the usb stick. I then stumbled across a settings page were I switched on 'virtual memory card' (or whatever it's called) and in there was a setting for native controllers (again, whatever it's called) which had some info about gba cables.
So I've managed to at least get it working on my Wii.
I now have to decide whether to buy an extra gba cable and gba console (costs more but less hassle), or start looking into Dolphin with gba emulators (free, but more hassle and we don't get a secret personal screen each).
I'll probably put this on the back burner for now as I'm busy with other things.

 

[ghostserverd]

Hello! This forwarder update you've drafted is really, really great! I've been waiting for this change for a while.
If I manually built your fork of nintendont-autoboot-forwarder, would it work, or do I need something else too? The Nintendont loader.dol seems to already have been updated since your commit was merged, but nintendont-autoboot-forwarder is still open. Is this correct?
Thank you

IDK if that change to nintendont-autoboot-forwarder will ever be merged (no one really seems to own those repositories anymore unfortunately), but I'm going to reach out to the owners of the various injectors to see if we can at least get them updated with the fix.

My response to @Frege above lists the steps you'll need to take before the injectors are updated:

1. Build the special fork of nintendont-autoboot-forwarder
2. Save the resulting main.dol file somewhere (might require a rename)
3. When injecting a new game using TeconMoon's injector, check Specify custom Nintendont Forwarder and provide the custom main.dol file with the ... button

 

[tatundria]

IDK if that change to nintendont-autoboot-forwarder will ever be merged (no one really seems to own those repositories anymore unfortunately), but I'm going to reach out to the owners of the various injectors to see if we can at least get them updated with the fix.

My response to @Frege above lists the steps you'll need to take before the injectors are updated:

1. Build the special fork of nintendont-autoboot-forwarder
2. Save the resulting main.dol file somewhere (might require a rename)
3. When injecting a new game using TeconMoon's injector, check Specify custom Nintendont Forwarder and provide the custom main.dol file with the ... button

Hi, please is it possible to share the main.dol file for those who don’t know how to build one?

 

[BRiiU]

I would also like someone to share the file, I'm a layman and I can't build the file

 

[ghostserverd]

Hi, please is it possible to share the main.dol file for those who don’t know how to build one?

For future reference, the build instructions are here and they work in a github codespace that you can easily create directly from the repo.

Here's a main.dol file that I just built using that method (currently untested on my setup, but it's the same steps I used to build the one I'm running, so barring something crazy, it should work just fine). gbatemp won't let me upload a .dol file directly so I added it as a release on github.

 

[BRiiU]

I come here very happy to say that with aroma it is possible to launch virtual Wii consoles without the need for a Wii remote, and that includes injected gameCube games.
That way we can play exclusively with the pro controller!!!!
we finally have the solution for this.



just use the plugin: Wii VC Launch

 

[andreiarturo]

Where do i get it?

 

[BRiiU]

Where do i get it?

you can get it here, look for Wii VC Launch, it's in the middle of the list.

https://gbatemp.net/threads/compilation-of-plugins-apps-for-aroma.631167/