Homebrew Need help with vWii gc adapter for project M

[JacobM]

you'll have to read how neek works with cheat. but then, you can use neek with extracted game FS or even neek2o with wbfs format.

For some reason, I couldn't get my FS game to load without neek reporting a disk read error. Unfortunately, I have limited experience with this format and am probably doing something wrong. It could also be a limitation of beta 9.6. Some old discussions suggest cheats have better compatibility with FS vs. wbfs. I also couldn't get wbfs to load the cheat and believe this is due to the code exceeding the .gct max lines. I couldn't find any documentation that suggests neek supported gameconfig.txt. I haven't exhaustively tested this yet as it is is a fairly annoying process and I'm finding the 1+2 menus unstable.

I leave for ONE week, and everything's dissolved into cIOS chaos. Lovely.

I got sucked down a rabbit hole. In my defense, its finals week and I don't have anything better to do.

One of the main two outcomes is the Now Loading loop. The other result is a normal loading of the game with no adapter support. vWii cIOS are based on IOS56-58 and the results show those original IOS cannot load the code in its current state. I noticed that I am far more likely to get a Now Loading loop if I leave my Wii U formatted USB device connected. I would still like to do some testing with IOS 38 based cIOS this weekend if you think there is any value to it. I do not have any debugging setups, so this is the only way I can help at the moment. I agree, ideally, we should avoid the end users tampering with cIOS because they always find creative errors and never make backups!

I'll see if I can setup Dolphin sometime in the next few weeks. Unfortunately, my Windows Tab & Windows PC have graphics driver issues with Dolphin and I typically like to keep my Macbook in its little walled garden.

Good luck with your meme magic!

 

[Cyan]

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.

I found some information for OH0/1, but maybe you already know about it?
the OH module is not present in latest IOS.

it seems IOS57/58 are using a different oh0 implementation, with limited commands.
http://wiibrew.org/wiki//dev/usb/oh0

Only IOS_OPEN, IOS_CLOSE and IOS_IOCTL are valid commands. The other commands immediately return IPC_EINVAL (-4).

if you use IOCTL commands, then it should still work.


http://wiibrew.org/wiki/IOS

OH0/1
USB OHCI (1.1) driver
/dev/usb/oh0 for the external USB bus
/dev/usb/oh1 for the internal USB bus
IOS57, 58 and 59: the OH0 module is gone and replaced by the OHCI0 module, which seems to implement a different, internal interface, similar to /dev/usb/ehc

EHCI
Present in IOS58. This module seems to be internally used as USB 2.0 backend for /dev/usb/usb.
/dev/usb/ehc

/dev/usb/ehc (only used in IOS58, which implement USB2.0)
/dev/usb/usb (also present in IOS57, which can be one of the working cIOS base. Not present in IOS56) /usb/usb seems to use /usb/ehc/ internally which can be an issue with cIOS.


a lot of people are using IOS56 as base for USBLoaders, which seems to still use oh0/1, but maybe like you said cIOS replaces the oh module (1.1) with ehci (usb2.0), which breaks your code.
how hard is it to rewrite your patch for ehci?
There's also the solution of using the /dev/usb/hid interface, which is available in more IOS.


Edit:
Is your code open source? just curious to see how you use an USB gamepad without HID.

 

[MrKatanaObiWan]

.

 

[JacobM]

I have no idea if this is relevant or correct, but a recent discussion in WiiVC Injection was mentioning that USB Lan Adapters don't work in vWii when running USB loaders. I don't have one to test myself.

https://gbatemp.net/threads/release...homebrew-support.483577/page-264#post-7898771

 

[wilm0x42]

AHA! I think I've got it! Thanks for having me take a closer look at those links, @Cyan !
Alright, so...

Older IOSes (first IOS with USB up IOS56, inclusive), had games use /dev/usb/oh0 directly, if I'm not mistaken. This includes IOS36 (SSBB IOS), which is why my code follows suit and directly talks to /dev/usb/oh0. However, other launchers were mysteriously causing IOS_Open(/dev/usb/oh0) to return -1. This completely stumped me for a while, but the aforementioned wiibrew links revealed that this is likely caused by the new IOS versions:
In newer IOSes (IOS57 and beyond), games are supposed to talk to /dev/usb/ven or /dev/usb/hid, which are basically just simple abstraction layers for the now-internal /dev/usb/oh0 (USB1.1), and /dev/usb/ehc (USB2.0). Because OH0 isn't supposed to be used directly anymore, trying to open it from the powerpc results in -1, EACCES.

tl;dr It's not cIOS's fault, it's an incompatibility problem with USB in new IOSes (57+).

Additionally, this is probably why usb doesn't work in Animal Crossing (IOS38). This also matches up pretty nicely with @JacobM 's test results. (Thank you for that!)

Possible solutions:

1. I guess I'll make wii gca inject automatically detect which USB implementation to use. Shouldn't be a big deal... hopefully.
2. New OH0 checks the UID of ioctls to make sure they're coming from IOS and not the powerpc. Maybe cIOS could just patch out this check?
   
3. cIOS should maybe support older base IOSes, for maximum compatibility. Definitely not my area of expertise, though.

I'll get to work on solution #1 as soon as I have time.

 

[Cyan]

thank you for taking the time to look at wiibrew
I think 1. will be the fastest solution, as cIOS update are unlikely. Unless someone take the time to work on cIOS again, I don't think we will get new patches or versions. (ok, maybe quick patches)

it would be great to fix the new USB 3.0 initialization issues if someone look at cIOS sources


Good luck updating your patch
I won't try it, but I know a lot of users are waiting for it.
if possible make it a gameconfig.txt or cheat code release. (or do you think I should add GPF support to the loader anyway? your patch might be the only released file. We'll see later)

 

[JacobM]

This also matches up pretty nicely with @JacobM's test results. (Thank you for that!)

Yay! Good news all around. I had a feeling it was a change in the original IOS based on what I was seeing. I planned to do some testing with 37 base cIOS on my Wii to help rule it out cIOS incompatibility, but I forgot to bring my WiiU Adapter to my parents house (DOH!). I guess that test isn't needed anymore!

I thought I read somewhere that vWii IOS 56 had a significant update/upgrade compared to the Wii variant. Broadly speaking, based on my exploration with hex editors, the vWii IOS 56 seems to contain a lot more non-zero values.

I think option 1 makes the most sense since cIOS on vWii isn't as well developed and is a bit more brickable vs a Wii.

if possible make it a gameconfig.txt or cheat code release. (or do you think I should add GPF support to the loader anyway? your patch might be the only released file. We'll see later)

I still plan to attempt to patch a WBFS directly once we confirm the gct+gameconfig.txt works. Here is how I see it:

1. If patching a WBFS works, .gct would make integration easier (at least for brawl)
2. The full gameconfig.txt has similar compatibility as GPF files, so I don't think adding GPF support is critical.
3. I would assume the .gct + gameconfig.txt option will likely result in an increase in support inquiries for USB Loaders as less experienced users would have more areas prone to errors.​

 

[Cyan]

yeah, cheatcode are easier for users because they already know how to do it, though it would require the users to merge their .gct with the existing one from the automatic download (gecko site).
using gameconfig.txt will be the same, they will have to merge it with another existing file if they use the modded version of SSBB. I doubt users have multiple games defined in they gameconfig.txt (even if possible) so it would be easy to just copy/paste some text in it.
GPF is the easiest for users, but it will require a loader's update.

 

[wilm0x42]

I got gecko code output working flawlessly a couple weeks ago, so there won't be any trouble with that aspect of things.
...You know, except for the fact that the code is over 700 lines long. Nonetheless, it works just fine, in practice. (As long as you have the gameconfig.txt that comes with PM, as it extends the maximum codelist length.)

As for IOS57+ support, it's already working in dolphin. (Stay tuned for proper console testing.) I basically just had to paste and modify some cherry-picked bits of code from libogc's USB code.
That theoretically fixes USB loader support, but I'm encountering some anomalous behaviour from the PM launcher. It seems to make things act as though there's the USB module from new IOSes, but I can see via dolphin that we're still in IOS36. Any ideas?
I'm formulating some tools to debug this on console, so we'll see how well that works out.
(Also to note, dolphin's IOS emulation may be innaccurately lenient as far as what /dev nodes are available. IDK, we'll see.)

Also, here's the current state of the implementation methods we've looked into:

• GCT: Gecko code implementation is totally working. It just requires PM's gameconfig.txt in order to fit the absurdly large code. Basically, it should work anywhere that PM's codeset will work. So, direct WBFS patching should work just fine when I finish the latest changes, @JacobM
  
• GPF: I intend to still provide GPF for whomever has a setup compatible with it. The convenience is just REALLY nice imo. As for whether or not it'd be a good idea to support GPF in more loaders, @Cyan, I agree that it's probably fine to leave it out of other loaders, unless other hacks end up using it.
• gameconfig.txt: Um... Besides the fact that gameconfig.txt is NOT the place to be implementing hacks like this, it was only tested in this format for temporary debugging purposes. Needless to say, GCT should obsolete this entirely.

Btw, it's totally theoretically normal for gameconfig.txt to have config for multiple different games in it.

 

[Chadderz]

I know I'm incredibly late to notice this thread (sorry!) but as someone mentioned I did get a version of the adapter working as a BrainSlug module. This means it can dynamically detect the methods it needs to patch within a game, so theoretically it should work with any game. I've just put my work up here: https://github.com/Chadderz121/wup-028-bslug

Hopefully it can be useful to someone either directly or as a reference for how I did it. We do have problems porting it into CTGP-R in that it seems to cause arbitrary memory corruption after being used for some time, but that's as likely to be a bug in the port as a bug in the actual code.

 

[Peninsula]

I know I'm incredibly late to notice this thread (sorry!) but as someone mentioned I did get a version of the adapter working as a BrainSlug module. This means it can dynamically detect the methods it needs to patch within a game, so theoretically it should work with any game. I've just put my work up here: https://github.com/Chadderz121/wup-028-bslug

Hopefully it can be useful to someone either directly or as a reference for how I did it. We do have problems porting it into CTGP-R in that it seems to cause arbitrary memory corruption after being used for some time, but that's as likely to be a bug in the port as a bug in the actual code.

Hey better late than never! Unfortunately I just tried it with NTSC-U Super Smash Bros Brawl and I'm not having any luck. I tried 2 different SD cards and the front and back ports USB ports.

Also, since brainslug is specifically a disc loader, I take it there's no way this method can support wiiware games (e.g. Bomberman Blast)?

 

[JacobM]

Hopefully it can be useful to someone either directly or as a reference for how I did it. We do have problems porting it into CTGP-R in that it seems to cause arbitrary memory corruption after being used for some time, but that's as likely to be a bug in the port as a bug in the actual code.

Woah! Thanks for dropping by and sharing your implementation Chadderz! Quickly looking through some of the code, I noticed you discovered the differing USB Interface implementations across IOSs which is what @wilm0x42 is working on right now. I'm sure he will find it useful!

Is it safe to say the GCN Adapter support won't make it into the upcoming (April?) update?

 

[Chadderz]

Hey better late than never! Unfortunately I just tried it with NTSC-U Super Smash Bros Brawl and I'm not having any luck. I tried 2 different SD cards and the front and back ports USB ports.

Also, since brainslug is specifically a disc loader, I take it there's no way this method can support wiiware games (e.g. Bomberman Blast)?

Interesting, I admit I just put the last built version up without testing it, so maybe it's a dud? I'll try to get it tested soon.

BrainSlug is just a disc loader, but the technology behind it would work with anything. It would just be a case of someone editing the disc loading section of the code to instead load a channel. The patching engine should be able to cope with that just fine.

Woah! Thanks for dropping by and sharing your implementation Chadderz! Quickly looking through some of the code, I noticed you discovered the differing USB Interface implementations across IOSs which is what @wilm0x42 is working on right now. I'm sure he will find it useful!

Is it safe to say the GCN Adapter support won't make it into the upcoming (April?) update?

Ah good, hope it is useful. I tried to be fairly thorough in my testing and document what I discovered in the comments, so things like alignment constraints and parameters and so on should be correct and minimal.

Yes, the next update for CTGP won't contain the adapter support due to the memory corruption. It actually normally specifically corrupts player position data which is obviously very concerning and could potentially be exploited if someone could work out how it works before we do.

 

[JacobM]

Yes, the next update for CTGP won't contain the adapter support due to the memory corruption. It actually normally specifically corrupts player position data which is obviously very concerning and could potentially be exploited if someone could work out how it works before we do.

Completely understandable! Hopefully the memory corruption will be figured out one day!

I had a few minutes to test NTSC-U MKWii and SSBB during my lunch break. The brainslug implementation works for MKWii, but not for SSBB just like @Peninsula described.

I was fairly surprised the brainslug implementation works with and without the Wii U drive in bottom back port & vWii drive in top back port. Hopefully that feature can be ironed out for wilm0x42's GPF version.

At least we can finally play vanilla Brawl or MKWii with the adapter! I'm shooting to test it out with some friends tonight and will report back! Thank you both.

 

[wilm0x42]

Awww, shoot! My thunder has been thoroughly stolen! Also now I don't have to make a brainslug implementation myself! Also my work apparently still isn't done here!
Nicely done, @Chadderz !

Exclamations aside, I can tell from the first 2 comments in Chadderz's code that the Brawl issue is super trivial. (From my point of view.)
Brawl uses IOS36, which is the last IOS before /dev/usb/hid happened; this is what Chadderz is using.
In order to support Brawl, it'll need to support /dev/usb/oh0.

So, funnily enough, I (basically) started with usb/oh0 and now need to support usb/hid, while Chadderz started with usb/hid and now needs to support usb/oh0.
Fortunately, this puts us at a convenient position for collaborating. So... I guess I'll fork it when I have a chance.

Another funny observation: My code is basically a whole bunch of sources put together, studied, and ruined by me, to make things work in the most "compatible" way possible, with existing technologies. On the other hand, Chadderz's code is like, all home-grown. He implemented entirely original USB interface code, whereas I just borrowed pieces from libogc.
I'm TOTALLY getting exposed as a fraud. XD

 

[Legacyblade]

Awww, shoot! My thunder has been thoroughly stolen! Also now I don't have to make a brainslug implementation myself! Also my work apparently still isn't done here!
Nicely done, @Chadderz !

Exclamations aside, I can tell from the first 2 comments in Chadderz's code that the Brawl issue is super trivial. (From my point of view.)
Brawl uses IOS36, which is the last IOS before /dev/usb/hid happened; this is what Chadderz is using.
In order to support Brawl, it'll need to support /dev/usb/oh0.

So, funnily enough, I (basically) started with usb/oh0 and now need to support usb/hid, while Chadderz started with usb/hid and now needs to support usb/oh0.
Fortunately, this puts us at a convenient position for collaborating. So... I guess I'll fork it when I have a chance.

Another funny observation: My code is basically a whole bunch of sources put together, studied, and ruined by me, to make things work in the most "compatible" way possible, with existing technologies. On the other hand, Chadderz's code is like, all home-grown. He implemented entirely original USB interface code, whereas I just borrowed pieces from libogc.
I'm TOTALLY getting exposed as a fraud. XD

(I've been lurking in this thread for awhile now)

Watching this develop has been pretty exciting and interesting. Can't wait to see what happens when you and Chadderz combine your powers.

I'm keeping my fingers crossed that it'll work with USB loading and VC Injection sometime in the next few months. But even if it takes longer than that, it's pretty cool just to watch this play out.

Keep up the good work!

 

[Chadderz]

Awww, shoot! My thunder has been thoroughly stolen! Also now I don't have to make a brainslug implementation myself! Also my work apparently still isn't done here!
Nicely done, @Chadderz !

Exclamations aside, I can tell from the first 2 comments in Chadderz's code that the Brawl issue is super trivial. (From my point of view.)
Brawl uses IOS36, which is the last IOS before /dev/usb/hid happened; this is what Chadderz is using.
In order to support Brawl, it'll need to support /dev/usb/oh0.

So, funnily enough, I (basically) started with usb/oh0 and now need to support usb/hid, while Chadderz started with usb/hid and now needs to support usb/oh0.
Fortunately, this puts us at a convenient position for collaborating. So... I guess I'll fork it when I have a chance.

Another funny observation: My code is basically a whole bunch of sources put together, studied, and ruined by me, to make things work in the most "compatible" way possible, with existing technologies. On the other hand, Chadderz's code is like, all home-grown. He implemented entirely original USB interface code, whereas I just borrowed pieces from libogc.
I'm TOTALLY getting exposed as a fraud. XD

Haha, didn't mean to tread on any toes! As your rightly point out our two implementations are quite different, so I think we've managed not to duplicate any major effort which is nice.

Well, I'd agree about Brawl's issue, except for the fact that I'm pretty sure BrainSlug does not currently load the game's requested IOS. It just boots under whatever it loaded under and lies to the game. This is obviously a dodgy thing to do, but in practice it hasn't caused any problems.

Yeah I started out in Homebrew the same as you, patching code together. Over the years I've gotten to the point where I understand a lot better, so I now prefer the home grown approach. It's nice not to be too reliant on other people or libraries, but it's definitely not the faster or more efficient approach!

 

[Marotheit]

Not to bump/necro a thread for no reason, but from checking the githubs it seems like development has fallen to the wayside. Any progress to report? Everything posted here is already incredibly promising and I wouldn't like to see it be halted.

 

[Peninsula]

Not to bump/necro a thread for no reason, but from checking the githubs it seems like development has fallen to the wayside. Any progress to report? Everything posted here is already incredibly promising and I wouldn't like to see it be halted.

This thread is the progress report. As it stands, wilm0x42 said he'll fork brainslug when he gets a chance and combine his powers with Chadderz's. This stuff just takes time to implement.

 

[wilm0x42]

I hit a roadblock in debugging efforts, which is why things would seem to have stalled a bit, but I should be getting things back on track before too long.
A summary of current plans seems in order:

Although I do plan on helping polish Chadderz' BrainSlug solution, I intend to finish the one I've been working on:
While the BrainSlug one is an excellent solution for most games, afaik it can't (currently, at least) be used with other, more common, modding formats. (Gecko codes and whatnot) As such, it wouldn't (easily) be usable with existing Brawl mods like PM. Also considering the possibility/likelihood of Smash-specific optimizations, I think it's a good idea to maintain them both.
As the plan has been from the beginning, I'll make a proper release (GCT and GPF) as soon as everything's ready. (Basically, whenever the todo list is complete)

To report on actual progress, support for newer IOSes seems to be working, and the GCT implementation is working like a charm. ~750 line gecko code, but whatever. (Haven't pushed these changes to the github repo yet, waiting 'til things are more stable.)
My biggest concern rn is making it work when launched from the official PM launcher. (It's currently only working on Gecko OS.) This has proven to be quite a mysterious issue, but I think I'm making some headway.

One question if anyone can help, though: Does anyone know if dolphin keeps track of what IOS is supposedly running? Pretty sure the PM launcher is using a newer IOS and lying in the global vars in low MEM1 about it being IOS36; it's made things quite confusing.