How to code an installable channel?

Discussion in 'Wii U - Homebrew' started by TheTechGenius, Apr 28, 2017.

  1. TheTechGenius
    OP

    TheTechGenius </Web Dev>

    Member
    546
    133
    Apr 7, 2017
    United States
    I have been searching my ass off for the past few hours, and I can't find anything about coding an installable channel or forwarder channel for a homebrew app.

    I am trying to find some kind of tutorial or something, so I could at least start developing a forwarder channel. I would like to learn all I can about coding homebrew for the Wii-U.

    I am trying to code a forwarder channel for TCPGecko. lol.

    Because when I boot up Breath of the Wild, before I boot the game I have to go into HBL via the Homebrew Channel and load TCPGecko, so I can use the BOTW Trainer while I play. But if I have a channel for TCPGecko, I can just launch TCPGecko from the channel.

    Are there any good tutorials or some where I can learn to code homebrew? I am pretty good at C#, but im not a professional. I just like learning new programming languages, its fun to me.
     
  2. Maschell

    Maschell GBAtemp Advanced Fan

    Member
    914
    1,331
    Jun 14, 2008
    Gambia, The
    You need to create a homebrew and link it using wut to create a .rpx.
    Once you have the .rpx you can create a channel using NUSPacker.

    But creating TCPGecko as a channel is not that easy, because it requires kernel rights. Normally the HBL does this for you. You would need to add the kernel exploit and memory management to TCPGecko to able to use it standalone.

    Edit: the easiest would be some kind of forwarder by creating a custom HBL channel that autoloads the tcp gecko .elf
    But this is not really the cleanest solution (I mean to copy the HBL code into everyforwarder.)
    I would may be better to add .elf loading via a parameter to the HBL channel and make a real forwarder instead of a clone with a few LOC changed
     
    Last edited by Maschell, Apr 28, 2017
    lordelan likes this.
  3. lordelan

    lordelan GBAtemp Advanced Maniac

    Member
    1,691
    481
    Jan 4, 2015
    Gambia, The
    But in other words you could make in installable HID to VPAD by including the mentioned things?
    I know I'm blowing your head off already with this but I wanna use my GC controller on RetroArch so badly. :P
     
  4. Maschell

    Maschell GBAtemp Advanced Fan

    Member
    914
    1,331
    Jun 14, 2008
    Gambia, The
    It wouldn't solve the problem
     
  5. Felek666

    Felek666 retarded memekid which no one likes

    Member
    3,520
    4,004
    Jan 3, 2017
    Poland
    reddit.com/r/satania/
    RetroArch Launcher freezes with HIDtoVPAD running in memory.
    HBLC returns to HIDtoVPAD so you still can't use it.
     
  6. lordelan

    lordelan GBAtemp Advanced Maniac

    Member
    1,691
    481
    Jan 4, 2015
    Gambia, The
    Yeah figured that out already (my GC Controller arrived today) but it could be solved if the app would take another memory section than Mii Maker or whatever HID to VPAD and RetroArch are using. Correct me if I'm wrong.
     
  7. Felek666

    Felek666 retarded memekid which no one likes

    Member
    3,520
    4,004
    Jan 3, 2017
    Poland
    reddit.com/r/satania/
    Homebrew apps are only allowed to allocate HBL's memory, nothing else.
     
  8. BullyWiiPlaza

    BullyWiiPlaza Nintendo Hacking <3

    Member
    1,791
    1,462
    Aug 2, 2014
    Germany
    Uh, this might explain why I have been running into "out of memory" problems so quickly. If there is any solution to this, it would be great.
     
  9. lordelan

    lordelan GBAtemp Advanced Maniac

    Member
    1,691
    481
    Jan 4, 2015
    Gambia, The
    Yeah but the HBLC is taking it's own memory (not Mii Maker's) so a homebrew that would be programmed in a way to take it's own memory might work?
    Like any native Wii U title.
     
    bennyman123abc likes this.
  10. bennyman123abc

    bennyman123abc Master of the Script Kiddies

    Member
    696
    327
    Mar 21, 2013
    United States
    Training some more Script Kiddies
    That might just work. Problem is, how would we accomplish this?
     
    lordelan likes this.
  11. lordelan

    lordelan GBAtemp Advanced Maniac

    Member
    1,691
    481
    Jan 4, 2015
    Gambia, The
    Dunno at this point. Just suggesting things.
    But Maschell's knowledge is big enough so I'm sure he would have made it already if it would be that simple so I guess it won't happen.
    So GC USB adapter (or general HID to VPAD) support has to be implemented into RetroArch directly.
    But as the RA devs don't seem to care about the Wii U any longer and Maschell didn't succeed in finding out how to do it (or he didn't manage to compile it I think) that won't happen either.
     
  12. Felek666

    Felek666 retarded memekid which no one likes

    Member
    3,520
    4,004
    Jan 3, 2017
    Poland
    reddit.com/r/satania/
    If you manage both apps allocate x amount of memory needed to run, then it might work.
    But issue with RetroArch might be that it takes everything from HBL memory pool and doesn't allow for another code to be present.
     
  13. QuarkTheAwesome

    QuarkTheAwesome Working for Hugs

    Member
    838
    2,076
    Apr 19, 2015
    Australia
    Stuck in the PowerPC
    Did someone say HBL MEMORY MANAGEMENT?

    HBL has a pretty simple memory setup, and it shows when you start using stuff like TCPGecko and HID to VPAD that have the sheer audacity to leave the safety of Mii Maker and venture into the heap-centred madness of the world beyond. In essence, HBL tells the PowerPC to take a bit of memory that's usually allocated to root.rpx and point 8MB starting at address 0x00800000 to it. This basically means that when you try to read, say, 0x00800004, the PowerPC translates that to 4 bytes into this root.rpx area and reads there. This works well enough, and it means that HBL has its own dedicated little bit of memory at address 0x00800000 all to itself (a rarity in Cafe OS).
    To load an application, HBL just copies it to 0x00802000 (the extra 0x2000 bytes are for HBL's internal use) and runs it. It does this every time you load any application, with no changes and no changing addresses. 0x2000 bytes into the region, every time.
    Hopefully you can start to see the problem here.
    If I open HID to VPAD, it gets loaded into 0x00802000. It then sets up its patches, returns to the main menu, and sends me on my merry way. I can open any native Wii U app I'd like and the HID to VPAD code stays put; the 0x00800000 memory area is dedicated to HBL, so other apps don't affect it. So, what happens when I try to run another HBL application? HBL does what it always does - load up the file, copy it to 0x00802000, and run it. This works fine and does exactly what you'd expect for any other application, but stuff that has patches like HID to VPAD or TCPGecko have modified bits of code outside of the HBL area to run bits of code that are inside the HBL area. So, when the well-intentioned HBL goes and overwrites the HBL memory area with the new application, all those bits of system code that were once pointing at HID to VPAD are now pointing at goodness knows what and it all goes down the toilet very quickly from there.
    This boils down to one simple fact - HBL can only hold one application in memory at a time, and every application expects to be in the same spot in memory. Considering what HBL was meant for, this is exactly what you'd expect - application, back to the menu, new application with no trace of the old. However, we've now got homebrew that doesn't fit this mold, and HBL has no way to deal with this. Short of moving to RPX (which would still cause problems, but with code that we didn't write) or setting up their own memory area (which Maschell already stated he doesn't want to do), such homebrew really doesn't have another option here. They just have to claim incompatibility with HBL applications and call it a day.

    As for solutions, the native RPX loader can handle several executable files at once (although putting homebrew here may cause problems with app switching, a fatal problem for patching homebrew) and each app can set up their own memory area (which gets complex quickly). I started a project a little while ago that aims to unify all these apps into one memory area (separate to HBL) while also making them compatible with each other, although I haven't really been doing much with it lately (motivation, woo-hoo!).

    So yeah, hopefully that helped your understanding of how this works on the backend. You can see how clashes occur so easily and why it's not an easy problem to fix.
     
    pelago, Brawl345, rw-r-r_0644 and 6 others like this.
  14. pwsincd

    pwsincd Garage Flower

    Member
    GBAtemp Patron
    pwsincd is a Patron of GBAtemp and is helping us stay independent!

    Our Patreon
    3,375
    1,750
    Dec 4, 2011
    Manchester UK
    Bring on COSSubstrate
     
    rw-r-r_0644, vgmoose and Felek666 like this.
  15. lordelan

    lordelan GBAtemp Advanced Maniac

    Member
    1,691
    481
    Jan 4, 2015
    Gambia, The
    Thanks QuarkTheAwesome, very interesting! :)
     
  16. Felek666

    Felek666 retarded memekid which no one likes

    Member
    3,520
    4,004
    Jan 3, 2017
    Poland
    reddit.com/r/satania/
    Wii U homebrew memes
     
  17. Maschell

    Maschell GBAtemp Advanced Fan

    Member
    914
    1,331
    Jun 14, 2008
    Gambia, The
    Even if you solve the memory management thing, you would run into problem if you try to chain multiple app that patch the same OS functions ~
     
  18. QuarkTheAwesome

    QuarkTheAwesome Working for Hugs

    Member
    838
    2,076
    Apr 19, 2015
    Australia
    Stuck in the PowerPC
    I'm writing my own patching engine to deal with that. You're still right in that there will definitely be compatibility issues with existing stuff though. That said, most patching homebrew has been carried through from userspace and is starting to need a rewrite anyway.
     
    lordelan likes this.
  19. BullyWiiPlaza

    BullyWiiPlaza Nintendo Hacking <3

    Member
    1,791
    1,462
    Aug 2, 2014
    Germany
    @QuarkTheAwesome oh, that's why. We need like multiple homebrews loaded and operating at once though. Why was that not intended? Homebrew apps can exit and then a new one is loaded in its place. When it doesn't exit however, we may want to load more into different memory areas till out of memory. Or just keep allocating the respective space for each of them by default so no clashes will occur.

    Thanks for the explanation even though there is no easy solution right now. :/
     
    Last edited by BullyWiiPlaza, Apr 30, 2017
  20. QuarkTheAwesome

    QuarkTheAwesome Working for Hugs

    Member
    838
    2,076
    Apr 19, 2015
    Australia
    Stuck in the PowerPC
    One could keep on allocating, but when you consider that HBL only has a little under 8MB of space available you'd start to run out fast. I can't speak for why dimok designed it this way, but I do think that it makes sense when you consider that without extra fiddling, HBL apps will return to the launcher menu rather than the home menu. It was clearly meant to run an app, quit to HBL, then run a different app. I wonder if HBC does this? That seems to be where HBL's inspiration is from...

    (random side note: the blue menu with all the homebrew is actually a HBL application, just like any other. There's a backend that's totally separate which handles all the ELF stuff)
     
    lordelan likes this.