Hacking USB Loader GX

[GreyWolf]

I don't understand the point in either gamepad or HID support. You can't play Wii games with either and I don't think you can launch external games from a HDD from within WiiVC.

 

[MrKatanaObiWan]

.

 

[Badablek]

you know how to keep different devkitppc version for different homebrew needs?

create (extract) each devkitppc to different folders inside devkitpro.
example :
devkitPPC/ <-- I keep this one updated (also, autoupdate would replace it, if you ever launch the devkitpro installer again)
devkitPPC_r27/
devkitPPC_r29-1/

and before compiling, or in your makefile, set the path to the devkitppc you want. it will affect the environment variable only temporarily, for the current session (current MSdos window only):

build.bat

set DEVKITPPC=/f/devkitPro/devkitPPC_r29-1
set devkitPPC
make clean
make -j4

the second line is just a way to check it worked, it displays the temporary environment variable path.

or
makefile

export DEVKITPPC   :=   $(DEVKITPRO)/devkitPPC_r27
...

You still need to edit the libogc version manually to match the version used by your project.

There's a more complicated (automated) way if you want to also use different portlib/libogc path, which involve editing the "wii_rules" file in devkitppc folder, and then just "set" the devkitPPC variable to the folder with the wii_rules you want.

devkitppc_usbgx/ with wii_rules set to usbgx libogc and portlib path
devkitppc_oldhomebrewname/ with wii_rules set to specific libogc and portlib path
etc.

or edit the path to wii_rules in your makefile :

include $(DEVKITPPC)/wii_rules

or, overwrite the path in your makefile after wii_rules include:

add this to edit the path in your makefile (or if not using wii_rules) :

export LIBOGC_LIB   :=   $(DEVKITPRO)/libogc/lib/wii
export PORTLIBS       :=   $(DEVKITPRO)/portlibs/ppc

they will be loaded here:

export LIBPATHS   :=   $(foreach dir,$(LIBDIRS),-L$(dir)/lib) \
                   -L$(LIBOGC_LIB) -L$(PORTLIBS)/lib

thanks @Cyan , but I already have my own batch file, which let me have "portable(s)" devkitpro, so I can use as many devkitpro as I want (and as many libogc/portlibs/etc revisions in it)

compile_wii.bat :

@ECHO off
TITLE Compilation d'USBLoader GX

CD..\..\..
SET PATH=%cd%\msys\bin;%cd%\devkitPPC\bin;C:\Program Files\TortoiseSVN\bin
SET DEVKITPRO=/%CD::=%
SET DEVKITPRO=%DEVKITPRO:\=/%
SET DEVKITPPC=%devkitpro%/devkitPPC
SET DEVKITARM=%devkitpro%/devkitARM
CD %~dp0

make -j5
wiixz boot.dol HBC\boot.dol
pause

Then in devkitpro folder, I should have a folder structure like this : Homebrews\Wii\whatever_homebrew_name\makefile + compile_wii.bat
and everything works nicely.

The hard part I was talking about is mainly to know which version of libogc/devkitppc/portlibs is needed for which homebrew

 

[Cyan]

@Cyan is the wiiu gamepad support currently on the to-do list one which will use it regardless of whether usbloader is injected into VC? Would love to be able to not bring a wiimote around for that if it didn't require injection!

Ultimately holding out for HID support but this could be great in the mean-time

I'm working on it, and I started adding it to the sources, but haven't tested yet.
I'll need to create a forwarder WiiVC, but I don't understand the different patching options (wiimote passtrhough?)

Also, you should note that the gamepad will NOT work if it's not launched from a WiiVC.
the gamepad support is full integrated part of IOS255 (fw.img injected into wiiVC) and that cIOS can't be changed while in vWii mode.
if launched from vWii, the WiiU hardware is completely deactivated.


Greywolf : the only advantage is to launch nintendont on SD card without wiimote.
a lot of users are now using nintendont injected wiiVC to play games, but only one nincfg.bin file is shared among all launched games.
Using a loader allows users to set different game settings, but some users don't have a wiimote or a procontroller, so they can't use USBGX interface to launch a gamecube game.
That's only used for a short period (pick the game, launch!) but will help a lot of users.

that's also why I would like to fix the AHB and sysmenu resources access. If it's not possible, I'll limit the banner layout access when using WiiVC, but also the "start/option" button below the animated banners. that's the less problematic of both resources access issue.

 

[GreyWolf]

I'm working on it, and I started adding it to the sources, but haven't tested yet.
I'll need to create a forwarder WiiVC, but I don't understand the different patching options (wiimote passtrhough?)

Also, you should note that the gamepad will NOT work if it's not launched from a WiiVC.
the gamepad support is full integrated part of IOS255 (fw.img injected into wiiVC) and that cIOS can't be changed while in vWii mode.
if launched from vWii, the WiiU hardware is completely deactivated.


Greywolf : the only advantage is to launch nintendont on SD card without wiimote.
a lot of users are now using nintendont injected wiiVC to play games, but only one nincfg.bin file is shared among all launched games.
Using a loader allows users to set different game settings, but some users don't have a wiimote or a procontroller, so they can't use USBGX interface to launch a gamecube game.
That's only used for a short period (pick the game, launch!) but will help a lot of users.

that's also why I would like to fix the AHB and sysmenu resources access. If it's not possible, I'll limit the banner layout access when using WiiVC, but also the "start/option" button below the animated banners. that's the less problematic of both resources access issue.

Have you checked to see if the system menu is even in the VC image? That might be why it's unable to load it. It shouldn't be too difficult to replace the assets, especially for the banner view. It's just a pinstriped background and two buttons.

 

[JacobM]

I'll need to create a forwarder WiiVC, but I don't understand the different patching options (wiimote passtrhough?)

Below is everything I could find about the -passthrough option implemented in Fix94s fork of nfs2iso2nfs 0.5.4

ok so the first piece to the puzzle is done, updating nfs2iso2nfs to allow for a better flexibility.
-separated wiimote passthrough patches from homebrew patches (as some homebrew may want to keep that emu around)
-improved wiimote vertical patch, now also swaps around the A/B/1/2 buttons
-improved homebrew AHBPROT patch, should now work correctly
https://mega.nz/#!EkoTWDaT!L6jfHa-rK97wecprnfpmuofrzGkNDaJZcWdKmAH0FSY
Basically for homebrew that wants to use the gamepad, add -passthrough into its command line together with -homebrew, for homebrew that doesnt want it (like my upcoming wiiware launcher) just use -homebrew and also maybe -wiimote or -vertical depending on whatever is best for that particular title.

also another thing, from nfs2iso2nfs 0.5.4 onwards for things like nintendont the "-homebrew" flag isnt enough, it'll also need "-passthrough" to work with the gamepad, I dont see that option implemented at all either. only things like the vwii channel booter dont need "-passthrough" as that actually makes use of the official gamepad wiimote/classic controller emu.

that and you'll have to edit the script to include -passthrough into the script nfs2iso2nfs cmd since you'll be using it with nintendont.

sure.
https://github.com/FIX94/nfs2iso2nfs/releases/tag/v0.5.5
please make sure to add -passthrough to the -homebrew flag though for nintendont/homebrew files, and maybe for homebrew files add an option to also not have -passthrough so homebrew that doesnt use it (like the channel booter) will work properly.

If I recall correctly, the unaltered fw.img from Nintendo could not see Wii remotes if WiiVC was set to gamepad mode. I THINK the passthrough patch is needed because homebrew doesn't use the official SDK and has varying implementations of classic controller support thus requiring individual gamepad patches. I also think this patch was developed so that homebrew that has not yet been updated could still be used to some extent.

 

[FIX94]

If I recall correctly, the unaltered fw.img from Nintendo could not see Wii remotes if WiiVC was set to gamepad mode. I THINK the passthrough patch is needed because homebrew doesn't use the official SDK and has varying implementations of classic controller support thus requiring individual gamepad patches. I also think this patch was developed so that homebrew that has not yet been updated could still be used to some extent.

its not just about seeing wii remotes but in code, its basically either execute the old wiimote code to allow them being used or fully emulate the entire interface and ignore any and all real hardware bluetooth input. -passthrough basically will keep the old wiimote code active as if you chose to not use the gamepad, so wii homebrew can keep using real hardware bluetooth data. The magic of it is that the actual gamepad connection still is active though and the IOS keeps updating the gamepad input buffer, thats where libwiidrc hooks in and basically processes that IOS buffer and makes it available to be used as another input option when the library is used. The actual gamepad input in IOS is being read by a separate thread, thats why it still gets updated even when processing the real hardware bluetooth input.
also the whole emu does not work with the libogc bluetooth implementation so thats why -passthrough is required in the first place. -passthrough does not only allow the wiimote data to stick around but also makes that gamepad input buffer available to easily read out from the PPC processor in the first place by adding some memory cache flush code of that buffer from ARM side.

 

[JacobM]

its not just about seeing wii remotes but in code, its basically either execute the old wiimote code to allow them being used or fully emulate the entire interface and ignore any and all real hardware bluetooth input. -passthrough basically will keep the old wiimote code active as if you chose to not use the gamepad, so wii homebrew can keep using real hardware bluetooth data. The magic of it is that the actual gamepad connection still is active though and the IOS keeps updating the gamepad input buffer, thats where libwiidrc hooks in and basically processes that IOS buffer and makes it available to be used as another input option when the library is used. The actual gamepad input in IOS is being read by a separate thread, thats why it still gets updated even when processing the real hardware bluetooth input.
also the whole emu does not work with the libogc bluetooth implementation so thats why -passthrough is required in the first place. -passthrough does not only allow the wiimote data to stick around but also makes that gamepad input buffer available to easily read out from the PPC processor in the first place by adding some memory cache flush code of that buffer from ARM side.

Thank you for the clarification Fix94! I figured that is what your patch did considering you were able to re-add bluetooth support with a relatively small patch. Good to know the reason why it was needed for Nintendont and not the channel booter. Everything makes a lot of sense now! Really appreciate the time you took to write that out.


Cyan: Have you tried reverting back to TeconMoon's 2.2.6 WiiVC Injector? That one acts as a "portable" app and doesn't store files in any external directories. You can also follow the WiiInjectScript.bat if you want to manually create a package. I think the dol section starts at line 438.

 

[cucholix]

I wonder if fw.img (IOS255) even has vWii NAND access at all. I suppose it does to read/save the savegame. I don't think the savegame is stored on wiiu, is it?

it can read/write save files into vWii nand.

 

[Larsenv]

I recreated the banner repository since gxarena is down, and I had all the banners.

To use it set the banner path to http://banner.rc24.xyz/ (is it still possible to grab the banners via usb loader gx?)

The GitHub repository is at https://github.com/larsenv/Custom-Banners

 

[GreyWolf]

I recreated the banner repository since gxarena is down, and I had all the banners.

To use it set the banner path to http://banners.rc24.xyz/ (is it still possible to grab the banners via usb loader gx?)

The GitHub repository is at https://github.com/larsenv/Custom-Banners

Thanks! Yes, the banner URL is actually a setting so it can be changed without a recompile.

Hopefully I can get SSL working soon and we can just the repository instead.

 

[Larsenv]

Thanks! Yes, the banner URL is actually a setting so it can be changed without a recompile.

Hopefully I can get SSL working soon and we can just the repository instead.

Could you test it out please? I set it to not enforce SSL because I know how the Wii is with it. If it doesn't work I can host it with Apache.

I looked through all the options, there wasn't one I saw for downloading custom banners...

 

[GreyWolf]

Could you test it out please? I set it to not enforce SSL because I know how the Wii is with it. If it doesn't work I can host it with Apache.

I looked through all the options, there wasn't one I saw for downloading custom banners...

There's not a setting option in the loader for it. You have to set it in the GXGlobal.cfg file. The name is "CustomBannersURL".

 

[godreborn]

I have a strange issue with usb loader gx. on the wii u, whenever I enter the virtual wii and load up usb loader gx, my pro controller has to be resynced in wii u mode.

 

[Cyan]

if the pad keeps the linked console in memory, you should also need to resync it everytime you go into vWii mode (after syncing it in Wiiu mode).
But the wiimote is sync to both WiiU and vWii at the same time, so I guess the CCpro should work the same way.
I'll have to test on my console, but I had to resync the vWii after playing Zelda wiiU with the Classic Pro, so I guess it lost vWii sync.

Maybe CCpro can only be sync to WiiU or vWii, not both?

 

[godreborn]

if the pad keeps the linked console in memory, you should also need to resync it everytime you go into vWii mode (after syncing it in Wiiu mode).
But the wiimote is sync to both WiiU and vWii at the same time, so I guess the CCpro should work the same way.
I'll have to test on my console, but I had to resync the vWii after playing Zelda wiiU with the Classic Pro, so I guess it lost vWii sync.

Maybe CCpro can only be sync to WiiU or vWii, not both?

actually, it's the wii u pro controller. the wii remote seems to stay synced. the wii u pro controller only seems to lose sync if I load usb loader gx.

 

[cucholix]

actually, it's the wii u pro controller. the wii remote seems to stay synced. the wii u pro controller only seems to lose sync if I load usb loader gx.

I had the same problem, what base and d2x are you using?

 

[Cyan]

yeah, I meant the wiiu Pro controller, not the "classic pro" which is a wiimote extension.

your wiimotes are not losing sync too?
usually, when a cIOS is not installed correctly, it unsync all wiimote at load (at cIOS load), so it happens when booting the loader or launching a game which uses the cIOS.

I didn't hear about the WiiU Pro losing sync without the wiimote losing it too.

 

[wicksand420]

I have a wii u pro controller that wont sync also, but it is a knockoff

 

[JacobM]

I didn't hear about the WiiU Pro losing sync without the wiimote losing it too.

I haven't needed to resync any controllers to SysNAND, RedNAND, or vWii in 6 months or so. I can't remember if this is necessary or not, but one of the guides recommended syncing WUPC in the vWii system menu rather than in homebrew.

I had desyncing issue a long time ago on both my Wii and my Wii U, but I think my issues resolved on their own. Come to think of it, my Wii desync issue might have been related to tinkering with USBLoaderGX emuNAND settings.