I've been trying to get this working using USB Loader GX. I think the only other loader compatible with gameconfig.txt is CFG loader. There are some old threads in which @Cyan mentions the need to run at least one ocarina code for the gameconfig.txt to be enabled, but I think that was corrected at some point since I am getting the same behavior with and without ocarina active. Thanks for looking into this.
I've been trying to get this working using USB Loader GX. I think the only other loader compatible with gameconfig.txt is CFG loader. There are some old threads in which @Cyan mentions the need to run at least one ocarina code for the gameconfig.txt to be enabled, but I think that was corrected at some point since I am getting the same behavior with and without ocarina active. Thanks for looking into this.
- Joined
- Oct 27, 2002
- Messages
- 23,749
- Trophies
- 4
- Age
- 45
- Location
- Engine room, learning
- XP
- 15,649
- Country
The need to activate at least one ocarina has been fixed. I changed it to load gameconfig.txt only by enabling one hook type, which loads the geckoOS patcher sources.
So, if gameconfig.txt work fine with geckoOS itself, maybe the problem is the cIOS ?
I'm sorry I took this conversation midway, so maybe I might not understand what this patch is doing.
Is it a way to add gamecube pad support to Wii games, or is it a way to add HID USB support to wii games?
That's two completely different things.
If you are on wiiu, or using the official gamecube controller adapter, then it's NOT gamecube ! it's HID USB.
It works fine with nintendont because Crediar added HID USB Support to nintendont (and not to gamecube game !). Nintendont is loaded in memory and responsible for communicating with the USB. it then converts HID controller signal by writing the corresponding button value into the memory address where the gamecube game is expecting it. it acts as a gateway (interpreter more than emulator).
When you play a wii game, there's no program in memory doing this conversion HID->button writing to memory. The loader is not in memory anymore and can't act as interface between hardware and the game.
So, tell me what this patch is doing :
1. replacing Wii controller drivers with gamecube controller's driver ? (if it's a generic patcher, it should work only on games using the exact same controller driver version, and located at the exact same address, unless it's a "search&replace" patch)
or
2. replacing Wii controller driver with HID support writing HID value to memory like nintendont does?
If it's doing the first one, then you can only use your Wii and a real gamecube controller port.
if it's doing the second one, then you (might) need cIOS r53 to enable USB Port1 ! if you use cIOS it's limiting the available USB Port.
So, when you tried to connect the adapter on back bottom port of WiiU, did you use d2x r52 or r53?
try r53 please
I don't have a GC adapter to test.
So, if gameconfig.txt work fine with geckoOS itself, maybe the problem is the cIOS ?
I'm sorry I took this conversation midway, so maybe I might not understand what this patch is doing.
Is it a way to add gamecube pad support to Wii games, or is it a way to add HID USB support to wii games?
That's two completely different things.
If you are on wiiu, or using the official gamecube controller adapter, then it's NOT gamecube ! it's HID USB.
It works fine with nintendont because Crediar added HID USB Support to nintendont (and not to gamecube game !). Nintendont is loaded in memory and responsible for communicating with the USB. it then converts HID controller signal by writing the corresponding button value into the memory address where the gamecube game is expecting it. it acts as a gateway (interpreter more than emulator).
When you play a wii game, there's no program in memory doing this conversion HID->button writing to memory. The loader is not in memory anymore and can't act as interface between hardware and the game.
So, tell me what this patch is doing :
1. replacing Wii controller drivers with gamecube controller's driver ? (if it's a generic patcher, it should work only on games using the exact same controller driver version, and located at the exact same address, unless it's a "search&replace" patch)
or
2. replacing Wii controller driver with HID support writing HID value to memory like nintendont does?
If it's doing the first one, then you can only use your Wii and a real gamecube controller port.
if it's doing the second one, then you (might) need cIOS r53 to enable USB Port1 ! if you use cIOS it's limiting the available USB Port.
So, when you tried to connect the adapter on back bottom port of WiiU, did you use d2x r52 or r53?
try r53 please
I don't have a GC adapter to test.
Last edited by Cyan,
Not exactly either, but 2. is closer:
It replaces the gamecube controller (SI) driver with a "HID" driver.
I put that in quotes because it's tailored specifically to the official Wii U Gamecube Controller Adapter. (Slight differences)
Another important distinction to be made is that it doesn't just "write controller values to memory."
Rather, it redirects calls to gamecube controller related functions (SI, PAD) to functions that
accomplish the same goal, but with the adapter.
Basically, it redirects all traffic going to/from the gamecube ports (which are only in the original wii) to the adapter.
As for the IOS:
My code doesn't use the IOS module USB_HID.
It uses OH0/1, the USB 1.1 module, communicating with raw interrupt transfers.
This module is in all versions of IOS, to my knowledge.
At the very least, I know it's in IOS36, which Brawl uses.
It looks like the wii u has some wierd ways of handling the USB ports.
The original wii only has 2 USB ports, both in the back, so it's up to the wii u to determine how the vWii sees it's 4 ports.
Based on what you said, I'm guessing it handles this by either...
1. It exposes the extra ports as a USB hub.
2. It only shows the vWii either the front or the back ports at any given time. (Your guess is as good as mine as to how it decides which ports should take priority.)
If it's 1., then it could be caused by the fact that my code only scans for 2 USB devices, since that's all there can normally be on a wii. Fixing this should be fairly trivial.
If it's 2, which I find more likely, try plugging in both a hard drive and the adapter in either front/back. (Keep in mind, the grey cable on the adapter doesn't matter.)
D
Deleted User
Guest
that is brilliant, I hope the next games you plan patching for is mario kart wii (and ctgpr. I Idk how your going to get that to work since latest version of ctgpr is closed source) and sonic riders zero gravity.
MKW is probably #1 on the list, once I begin work on porting this to other games.
CTGPR: Brawl was closed source too, wasn't it? :^)
USBLoaderGX is ripping Brawl right now. I'll test it as soon as it's finished.
For clarification: Third setup only worked in Gecko OS, not USB loader?
For clarification: Third setup only worked in Gecko OS, not USB loader?
So, when you tried to connect the adapter on back bottom port of WiiU, did you use d2x r52 or r53?
try r53 please
I don't have a GC adapter to test.
I just installed r53 to 251 base 57 but didn't notice any difference other than losing the ability to modify game settings in USB Loader GX
I also tried hexediting the ISO as a whole with the patch values with no success
Just to be clear, all of these patch values overwrite data starting at the destination address (inclusive)? Is it possible to generate a list of original values so we can identify what file they originate from? Can we use the alt dol feature in USB Loader GX to test dol modifications rather than transferring an entire ISO over and over?
EDIT: all of my testing has been with USB HDD in top back port and black Wii GCN Adapter in bottom port.
Last edited by JacobM,
IMO patching the ISO directly removes a variable in determining what is failing. If we are making the correct assumption that these patches belong in main.dol, then the black screen that Peninsula and I encountered would suggest a CIOS limitation since our results matched when tested via SD loading and USB loading. Based on the gameconfig.txt findings, it could still be the USB Loader implementation of gecko support and/or CIOS incompatibility.
Edit: Just to be clear, Gecko OS loaded the patch from the disk with a Wii HDD in the top back port and the adapter in the bottom back port? Would running this patch on a regular Wii work since it only has the two ports?
Last edited by JacobM,
D
Deleted User
Guest
True, but ctgpr does a lot of things differently than what project M does. and with getting projectM to work with the code was pretty easy. Problem is, ctgpr doesn't support gecko for obvious reasons (or outside gecko patches. userstuff. No cheating online) . So he would need to get in contact with the creator of ctgpr to make a official patch to the mod. And project M however was open sourced.
Last edited by ,
You people are dense.
CTGPR 1.03 was made to only properly launch through their channel launcher or something like that. No one has found a way to patch it onto an ISO. And if the devs found a person to be tampering with CTGPR, they're immediately permabanned from Wiimmfi completely.
D
Deleted User
Guest
I'm not dense, check my response I changed it, before you sent that message
Last edited by ,
1. I didn't hack Project M, I hacked Brawl, which in-turn affects PM. As such, PM being open/closed source are completely irrelevant.
2. If I was to attempt hacking CTGPR, there's no reason I'd have to restrict myself to using Gecko for that. It's 100% possible to hack it.
3. The devs don't have the authority to ban you from Wimmfi completely; CTGPR is only one of the games Wimmfi supports.
4. This hack would only be a client-side mod. They're servers would never see any difference.
5. Keeping in mind that they CAN ban me from netplay for using hacks of any kind... I'll take my chances.
6. If I port my hack to vanilla MKW, then they can apply it to their hack themselves. Wii GCA Inject is open source.
</rant>
2. If I was to attempt hacking CTGPR, there's no reason I'd have to restrict myself to using Gecko for that. It's 100% possible to hack it.
3. The devs don't have the authority to ban you from Wimmfi completely; CTGPR is only one of the games Wimmfi supports.
4. This hack would only be a client-side mod. They're servers would never see any difference.
5. Keeping in mind that they CAN ban me from netplay for using hacks of any kind... I'll take my chances.
6. If I port my hack to vanilla MKW, then they can apply it to their hack themselves. Wii GCA Inject is open source.
</rant>
Mr. Bean pretty much had the adapter working with CTGP ~December 20th, 2017. After a few days of testing relatively flawlessly, there was a minor graphical glitch that put the project on hold.
http://forums.mkboards.com/threads/...-tracks-thoughts-and-suggestions.23387/page-6
https://www.reddit.com/r/WiiUHacks/comments/7k8ylb/mr_bean_is_currently_livestreaming_research_into/
D
Deleted User
Guest
Similar threads
- No one is chatting at the moment.
