Need help with vWii gc adapter for project M

Discussion in 'Wii U - Homebrew' started by ada010, Mar 7, 2018.

  1. JacobM

    JacobM GBAtemp Regular

    Member
    129
    35
    Jun 16, 2017
    United States
    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 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! :P

    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!
     
    Last edited by JacobM, Mar 22, 2018
  2. Cyan

    Cyan GBATemp's lurking knight

    Global Moderator
    19,576
    9,587
    Oct 27, 2002
    France
    Engine room, learning
    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
    if you use IOCTL commands, then it should still work.


    http://wiibrew.org/wiki/IOS
    /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.
     
    Last edited by Cyan, Mar 31, 2018
    JacobM, cruplezone and Lyrin like this.
  3. cruplezone

    cruplezone GBAtemp Fan

    Member
    376
    90
    Feb 3, 2014
    Canada
    https://github.com/wilm0x42/wii-gc-adapter-inject
     
    Cyan likes this.
  4. JacobM

    JacobM GBAtemp Regular

    Member
    129
    35
    Jun 16, 2017
    United States
  5. wilm0x42

    wilm0x42 Member

    Newcomer
    24
    43
    Mar 10, 2018
    United States
    AHA! I think I've got it! :D 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.
     
    JacobM, Stephano, Peninsula and 4 others like this.
  6. Cyan

    Cyan GBATemp's lurking knight

    Global Moderator
    19,576
    9,587
    Oct 27, 2002
    France
    Engine room, learning
    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 likes this.
  7. JacobM

    JacobM GBAtemp Regular

    Member
    129
    35
    Jun 16, 2017
    United States
    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.

    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.​
     
  8. Cyan

    Cyan GBATemp's lurking knight

    Global Moderator
    19,576
    9,587
    Oct 27, 2002
    France
    Engine room, learning
    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.
     
    JacobM likes this.
  9. wilm0x42

    wilm0x42 Member

    Newcomer
    24
    43
    Mar 10, 2018
    United States
    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.
     
    frogboy, Legacyblade, ada010 and 5 others like this.
  10. Chadderz

    Chadderz Member

    Newcomer
    46
    88
    Apr 12, 2009
    England
    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.
     
  11. Peninsula

    Peninsula Advanced Member

    Newcomer
    89
    28
    May 7, 2014
    United States
    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)?
     
  12. JacobM

    JacobM GBAtemp Regular

    Member
    129
    35
    Jun 16, 2017
    United States
    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?
     
  13. Chadderz

    Chadderz Member

    Newcomer
    46
    88
    Apr 12, 2009
    England
    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.

    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 and Peninsula like this.
  14. JacobM

    JacobM GBAtemp Regular

    Member
    129
    35
    Jun 16, 2017
    United States
    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.
     
  15. wilm0x42

    wilm0x42 Member

    Newcomer
    24
    43
    Mar 10, 2018
    United States
    Awww, shoot! :D 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! :P :P :P
    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. :P
    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
     
  16. Legacyblade

    Legacyblade Member

    Newcomer
    11
    8
    Nov 9, 2017
    United States
    (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!
     
    Yoni Arousement, ada010 and wilm0x42 like this.
  17. Chadderz

    Chadderz Member

    Newcomer
    46
    88
    Apr 12, 2009
    England
    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!
     
    wilm0x42 and JacobM like this.
Loading...