Hacking USB Loader GX

  • Thread starter Thread starter blackb0x
  • Start date Start date
  • Views Views 8,068,937
  • Replies Replies 30,226
  • Likes Likes 74
Hello,
I have an issue with 'meta.xml' file in usbloaderGX version 3.0 r1281.
I have modified the file to add the titleID of my game as argument (that allow me to autoboot my game on usbloaderGX startup).

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<app version="1">
<name> USB Loader GX</name>
<coder>USB Loader GX Team</coder>
<version>3.0 r1281</version>
<release_date>20230107233054</release_date>
<arguments>
<arg>--ios=249</arg>
<arg>--bootios=58</arg>
<arg>--usbport=0</arg>
<arg>--mountusb=0</arg>
<arg>--sdmode=1</arg>
<arg>RZDP01</arg>
</arguments>
<ahb_access/>

It works well, the first time, but once I go back from the game to Wii System Menu, when I tried a secondth time to start usbloadeGX, my game does not autoboot. It seems the meta.xml has been changed and my argument is lost. The file become like that :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<app version="1">
<name> USB Loader GX</name>
<coder>USB Loader GX Team</coder>
<version>3.0 r1281</version>
<release_date>20230107233054</release_date>
<arguments>
<arg>--ios=249</arg>
<arg>--bootios=58</arg>
<arg>--usbport=0</arg>
<arg>--mountusb=0</arg>
<arg>--sdmode=1</arg>
</arguments>

Is it possible to avoid losing user's arguments or do you have a tip to keep the titleID (I tried to add read only flags from Windows but it seems ignored by usbloaderGX :lol:)

Thanks in advance for your help :)
 
ok, so a minor thing, and apologies if this is known or doesn't belong here (as i am running off vWii), but my USB Loader GX (3.0 r1281) doesn't display/update my external's free space accurately (Fat 32; y-cable; correct ports; all games running fine).

the Sync to Fat option does not work, however, if i exit to CFG Loader and use its Sync FS command then the free space is corrected and shows the right amount in USB Loader GX... until another title is installed/uninstalled, and free space doesnt update.
 
Last edited by Citan_KL,
ok, so a minor thing, and apologies if this is known or doesn't belong here (as i am running off vWii), but my USB Loader GX (3.0 r1281) doesn't display/update my external's free space accurately (Fat 32; y-cable; correct ports; all games running fine).

the Sync to Fat option does not work, however, if i exit to CFG Loader and use its Sync FS command then the free space is corrected and shows the right amount in USB Loader GX... until another title is installed/uninstalled, and free space doesnt update.
It's weird that it's losing sync in the first place, but the code to perform the sync is the same. So the only difference is the FAT library version :unsure:

Does your storage device only have 1 partition? Have you checked with with something like MiniTool partition wizard, AOMEI partition assistant or GParted for any hidden partitions?
 
Does your storage device only have 1 partition? Have you checked with with something like MiniTool partition wizard, AOMEI partition assistant or GParted for any hidden partitions?
it has 2 partitions (250gb/50gb) both FAT32 but the smaller is empty (thought it might be a good idea to have for a few GCN games or EmuNand stuff in the future.. things i havent really delved into yet)

no hidden partitions as far as i can tell, and the loader loads/installs to the correct one.. but a peculiar thing about this hdd & partition is that 1) it used to be wbfs, but later converted using wbfs2fat; and 2) partition was extended using EaseUS Partition Master after conversion, preserving all data already on it.

can this be why? still odd that CFG syncs and GX doesn't.
 
If I set autoboot in Priiloader to be USB Loader GX (AHBPROT available) it automatically goes into SD card mode and does not recongize my SSD connected to USB 0. I have to go into Hard Drive settings and disable SD Card mode. Is this a bug or is my SSD enclosure maybe too slow (drive is FAT32 and MBR)?

Entering GX through system menu or HBC works fine, reads the SSD as expected.
 
can this be why? still odd that CFG syncs and GX doesn't.
Most likely. But I'll see if I can recreate that setup when I've got some free time this week.

If I set autoboot in Priiloader to be USB Loader GX (AHBPROT available) it automatically goes into SD card mode and does not recongize my SSD connected to USB 0
Follow what I said in this post :)
 
  • Like
Reactions: jeannotte
Is there a instruction on this somewhere that I missed? I followed the autoboot instructions on wii.guide,
A note was added to that guide about autobooting USB Loader GX a few days ago ^_^

If Priiloader acted like a forwarder channel instead of copying files to the NAND then this wouldn't be a problem.
 
Hello,
Yesterday night, I tried to compile USBLoader from the download page github => wiidev/usbloadergx/releases
2023-07-18 05_47_46-Releases · wiidev_usbloadergx.png
I also installed the latest DevKitPro (msys2 ver 2.10.0). I use Windows 10 to compile the project.
1689652248620.png

I compiled the code source by using the command "make clean && make" :
  1. I get a compilation error with the file 'utils/sjis.cpp' (see attached log_compilation_errors.txt)
    I fixed the problem by adding into the file #include <cstdint>

  2. When the code is compiled, I get a 'boot.dol' but the size does not match with the current release file.
    The compiled boot.dol size => 4561Ko, the download release boot.dol file => 4592Ko

  3. When I try to use the compiled file to my Wii from the SD card, an exception occurs after loading page.
It's the first time I try to compile this type of project (WiiBrew). Is it the the latest source files ? did I miss something (compilation option, etc...) ?
 

Attachments

I also installed the latest DevKitPro (msys2 ver 2.10.0). I use Windows 10 to compile the project.
The latest version of devkitPPC won't be able to compile the loader correctly until I push changes to GitHub. And I don't do that until I'm ready to release a new version of the loader.

The file sizes won't match because GCC and some libraries were updated.

If you login to GitHub and fork the project then you could press the green code button and create a codespace. Then you can edit and compile the project via your browser or your own PC with VS Code and the Codespaces extension installed.
 
Last edited by blackb0x,
  • Like
Reactions: Remus95000
speaking of USB Loader, the next update will Tintin work? In the current in the first art of the game after the lightning the game crashes and then try to make more NGC PAL games work in progressive as your last update made RE 0, 2 and 3 work in progressive
It'll be fully playable from start to finish :)
 
The latest version of devkitPPC won't be able to compile the loader correctly until I push changes to GitHub. And I don't do that until I'm ready to release a new version of the loader.

The file sizes won't match because GCC and some libraries were updated.

If you login to GitHub and fork the project then you could press the green code button and create a codespace. Then you can edit and compile the project via your browser or your own PC with VS Code and the Codespaces extension installed.
Thank you for this feedback, your solution works perfectly :yaywii:. As usual you are the best :bow:.
 
Thank you for this feedback, your solution works perfectly :yaywii:. As usual you are the best :bow:.
Editing and compiling homebrew directly from a web browser is pretty neat eh? ^_^

I'm guessing you disabled the call to editMetaArguments() in an attempt to fix quick game booting? If yes then I've already fixed that issue for the next release by adding if (Settings.skipSaving) return 0; to the start of the editMetaArguments() function.
 
  • Like
Reactions: Remus95000
Editing and compiling homebrew directly from a web browser is pretty neat eh? ^_^

I'm guessing you disabled the call to editMetaArguments() in an attempt to fix quick game booting? If yes then I've already fixed that issue for the next release by adding if (Settings.skipSaving) return 0; to the start of the editMetaArguments() function.
Indeed, yes it is very greatful to be able to compile without having to install software.
It would be possible to comment out the editMetaArguments() function, but I preferred to modify the content (to avoid adding defects into the code source) [See attached capture]. I have done this modification temporarily to test a single rom loader (while waiting for your next release ;)).
 

Attachments

  • meta_modif.png
    meta_modif.png
    59.7 KB · Views: 56
Would it be possible to get USB Loader GX to remember what the WiiU Widescreen option is set to, or to add it as an option per game for Wii games? Otherwise on Wii U certain Wii games without 16:9 support are stretched (this is regardless of whether Force 4:3 is used or not), whereas when played without the loader the Wii U would correctly display the game in 4:3 if it lacked support for 16:9.
 
I have done this modification temporarily to test a single rom loader (while waiting for your next release ;)).
I guess that'd work too. But I just skip saving entirely when booting directly into games, since there's no need to update the meta.xml file.

Would it be possible to get USB Loader GX to remember what the WiiU Widescreen option is set to, or to add it as an option per game for Wii games? Otherwise on Wii U certain Wii games without 16:9 support are stretched (this is regardless of whether Force 4:3 is used or not), whereas when played without the loader the Wii U would correctly display the game in 4:3 if it lacked support for 16:9.
That's already been added for the next release :)
 

Site & Scene News

Popular threads in this forum