Hacking USB Loader GX

  • Thread starter Thread starter blackb0x
  • Start date Start date
  • Views Views 8,062,095
  • Replies Replies 30,225
  • Likes Likes 74
2) Priiloader 0.8.1 + ForwarderV5.1.dol at the root of the SD (both cases: fresh install of Priiloader 0.8.1 or update from 0.7 with the .dol already install)
I installed the forwarder.dol and when Priiloader boots it, USB Loader GX starts without AHB access (according to credits and to Nintendon't)
3) Priiloader 0.8.1 + ForwarderV5.1.dol in a dedicated folder in app folder, renamed boot.dol with a dedicated meta.xml requesting AHB access (<ahb_access/>)

Do you have a meta.xml with AHB access in ULGX?
I also updated from Priiloader 0.7 a while ago without any problem.
I found a boot.dol and a ForwarderV51.dol (they are the same) from ForwarderV5.1 at the SD root, no meta.xml at root, no other boot.dol for ForwarderV51 on the SD (see below), no dedicated app folder. Although, I wouldn't know what file did I installed from Prilloader 0.7's time.

I do keep a copy of ForwarderV51.dol in apps/usbloader_gx_/ForwarderDol/ with no other files in this subfolder. But I don't think Priiloader would be smart enough to locate it by itself.
And i noticed right after the ULGX logo comes up, a message saying something like "loading application cios requested from meta.xml" (its too quick for me to read clearly). I don't know if this message is from the forwarder or from ULGX itself.

The size of the forwarder.dol is 882,816 bytes. Are you sure you are using the right files? Wii or vWii? (I am on Wii)
 
Do you have a meta.xml with AHB access in ULGX?
I also updated from Priiloader 0.7 a while ago without any problem.
I found a boot.dol and a ForwarderV51.dol (they are the same) from ForwarderV5.1 at the SD root, no meta.xml at root, no other boot.dol for ForwarderV51 on the SD (see below), no dedicated app folder. Although, I wouldn't know what file did I installed from Prilloader 0.7's time.

Yes I have a meta.xml with AHB access in ULGX folder.
If I understand correctly your post, you have:
- Priiloader 0.8.1
- the dol forwarder installed in Priiloader (from the root of the SD without any meta.xml)
Are you able to boot NGC games via Nintendon't from USB Loader GX booted via Priiloader?

The size of the forwarder.dol is 882,816 bytes. Are you sure you are using the right files? Wii or vWii? (I am on Wii)
I am using a Wii, and the size of the forwarder is 882816 bytes and its SHA1 26BBE3A4BB59CB4FF641C8C4D15A48CFD8F87FDF
 
Yes I have a meta.xml with AHB access in ULGX folder.
If I understand correctly your post, you have:
- Priiloader 0.8.1
- the dol forwarder installed in Priiloader (from the root of the SD without any meta.xml)
Are you able to boot NGC games via Nintendon't from USB Loader GX booted via Priiloader?


I am using a Wii, and the size of the forwarder is 882816 bytes and its SHA1 26BBE3A4BB59CB4FF641C8C4D15A48CFD8F87FDF

Yes, I have 0.8.1.
I didn't play GC games for any length of time but at least they boots to in-game menu screen and ULGX's credit page shows AHB.

I did try to re-install the boot.dol from Priiloader 0.8.1 and it still works with AHB and plays GC games.

I notice Priiloader 0.8.1 now allows you to install the apps.dol directly (can't remmember if 0.7 allows that) and I tried to install ULGX directly and the credit page still shows AHB.
True that might not get updated as you update ULGX but installing the forwarder app with dedicated folder is a good work around although I don't have any problem with the old method myself.

PS. The message "loading application cios requested from meta.xml" is from ULGX - verified by loading ULGX app from HBC
 
thanks for tinyXML update.

@Cyan Any idea what magic_patcher.o actually does?
It was made by Giantpune, and I don't have the sources. I think it's some ASM coding he did.
It's supposed to enable MEM2 prot to be disabled. (acts like AHB access) But that's how far I understand it. I don't know what it really does.

Maybe @dimok knows about it. I don't know if he get notification from here.

i noticed right after the ULGX logo comes up, a message saying something like "loading application cios requested from meta.xml" (its too quick for me to read clearly). I don't know if this message is from the forwarder or from ULGX itself.
The message is from the loader. It's the first thing it does (reloading into the meta.xml IOS argument).

Technically, the loader is not loading the meta xml, but the argument is sent from the forwarder which is the one reading the xml.
when launched from HBC, HBC is the one reading the XML and loading "boot.dol IOS=xxx"
but the text is from the loader, the forwarder is already unloaded from memory when you see this message.
 
It looks like it originally came from Wii System Menu Player so I'll see if I can find out from dimok or giantpune maybe. I was thinking maybe the runtimeIOSPatch library might be able to replace it.
 
I think we can replace it.
I just haven't took the time to rewrite all the IOS reloading part to use only libruntimeIOS instead of keeping two cpp files doing the same things.
 
I'll see what I can figure out. I'm working on a JavaScript addition too but I have to make bindings for it to do anything. :P
 
@Cyan

Is it possible to add GCN controller support through the USB adapter for Wii U?

In addition to that, is it possible to add it to existing Wii games as well like Super Smash Brothers Brawl and Mario Kart Wii?
 
@Cyan
Is it possible to add GCN controller support through the USB adapter for Wii U?
In addition to that, is it possible to add it to existing Wii games as well like Super Smash Brothers Brawl and Mario Kart Wii?
1) in the loader : yes, but last time I did it had memory issues and users lost their HDD partition ! I removed HID support until I know better about memory.
in the games : no.

2) no. the game is not developed to read USB HID controllers. it would require recompiling the game from the sources, which only the developers and nintendo have.
 
I've noticed some issues since upgrading to 1262, clicking on the filter icon makes the UI unresponsive and when it does respond the banners are not appearing. Any ideas?
 
damn, then it became unstable again ?
It either reached a memory or filesize issue. We had it on a previous version (and users lost their HDD partition !)
Maybe users shouldn't use 1262...

I really don't know how to fix memory issues.
that is what discouraged me to update/work on that loader for the past year.
 
The executable is smaller than other homebrew like WiiMC so it shouldn't be the dol size. There could be a memory leak but it's hard to find stuff like that without being able to connect to the console. :/

I guess counting new/delete and malloc/free occurrences to see if they're unbalanced is an option. :P
 
there are more delete than new haha (it counted them all, even the commended ones)
but I guess some are even in condition/loop (like new cover for each game, and this should be deleted for each loaded covers, so it's based on number of detected covers)

Maybe it would require a full code check to find the issue.
There are still part of the loader I never worked on (like all the banner view)


maybe what could be done is a new log function in mem2, like adding a way to count or map each used memory addresses (it's doing it in CFG loader).
doing it, it can even graphically map in real time the used/free memory.

I can review all my changes since v3.0, but if I'm the one looking for it maybe I'll do the same mistake.
And it could even be a bad code created before 3.0 but it's only an issue now due to memory usage.
 
Reference counts are handy for that.

The newer TinyXML was changed to reduce memory leaks by preventing users from calling "new" for XML elements. They have to be created with document.NewElement() now and are tracked by the document and all destroyed when it is.
 
I noticed that Gecko is loggin a "&" when accessing homebrew browser, which is probably an issue with the meta xml parser. it's maybe one of my xml which is malformed, but it's very long to load and shouldn't log anything.
Maybe your patch will fix it.
I'll try it :)

the patch adds "tinyXML2", but doesn't delete the old one. This is still used in the loader?

edit:
you patch seems to fix that "&" log issue.
I don't know what caused it, but I'm sure it's better now.
thank you for your patch.
 
No, I thought it included the deletion. You only need tinyxml2.h and tinyxml2.c.

It's wrapped in a namespace now so if you use it elsewhere make sure you add "using namespace tinyxml2;" to the top of the source file or the "tinyxml2::" qualifier to the references.

What does the "&" mean? I really need to get a Gecko. :P
 
the gecko was loggin that character when I went into the homebrew browser, I don't know why.
it should log errors, with proper text (if any were found), but for my SD card with its homebrew content, I always got one single character logged out to my gecko as if something was wrong but without a proper text. I never tried to find what caused it. I thought it wasn't important.
but your patch fixed it.

edit:
I tried going/exiting the filter window, but I don't have any issues.
It probably is user based, depends how many games or filters you have.

edit again :
hmm, there's no more meta.xml parsed in the homebrew launcher.
tiny2 broke it.
 
I found a bug in r1260. When scraping media for NGC games, at the end of scraping, only NGC games are displayed even if Wii games are selected and were displayed before scraping. I attached a detailed example.

By the way, what is the best for you @Cyan? Post the issue here or open a ticket on the official bug tracker (Sourceforge)?
 

Attachments

Site & Scene News

Popular threads in this forum