Hacking USB Loader GX

  • Thread starter Thread starter blackb0x
  • Start date Start date
  • Views Views 8,066,540
  • Replies Replies 30,226
  • Likes Likes 74
he changed the detection of nintendont (to base it on month name detection).
New nintendont version are not working with USBLoaderGX r1231, he just added a new method to check compiled date (I was planning on releasing a fix, but I have few others things to edit at the same time so I won't release it until all is fine and tested).
Quick question, will you keep the changes in the mod made by airline38 in the next release or will you create you own ones?
 
The new revisions of nintendont have the version number located somewhere else in it's binary from where it used to be located so airline38 did a quick edit and build to verify it by build month instead of version number, cyan will most likely make his own code to use for detecting nintendont versions again.

Essentially a lot has changed in the nintendont source code and it broke quite a bit of features linked with usb loader gx like the autoboot feature which is used to boot the game after passing the settings arguments, If you go back a page I posted that, that specific thing had happened with newer revisions of nintendont with an older usb loader gx revision (R1228)
 
I'm trying out a 4TB Western Digital My Book USB Hard Drive to see if it will work. First problem I come to is that every program that I have tried won't format the entire drive with a cluster size of 32k. The lowest it will let me go is 64k. I partitioned out 1TB set to 32k and put all my GameCube games there. I was planning on partitioning the other 3TB worth and putting all my Wii games there but still it only lets me choose 64k. Will Wii games run if the second partition is 64k? Would it be better if I just created two 2TB partitions set to 32k? And if I did that, could I have my GameCube games on the first partition and my Wii games on the second partition? And if I created a wbfs folder on both partitions and stored some wii games on partition 1 and others on partition 2 will USB Loader GX see and play Wii games from both partitions just fine?

On a side note, does anyone know of any program that would be able to format and entire 4TB drive to Fat32 with 32k clusters or if it is even possible to do so?
 
I would suggest keeping the 1TB for gamecube set it to primary and active, set the second partition to logical, i'm pretty sure wii games will be fine with a 64kb cluster size I use it
you can try easus partition master Home see if that helps with the 4TB as a fat32 but I wouldn't suggest it fat32 has a file limitation size of 3.99 GB
 
  • Like
Reactions: Clutz450
Quick question, will you keep the changes in the mod made by airline38 in the next release or will you create you own ones?
It will depend how the next version of nintendont will work.
Airline's method is fine and easier, less strict with the detection and allows nintendont to change without breaking the detections.
 
  • Like
Reactions: sonictopfan
cyan you stated that the detection code airline38 made detected upon build date, the date that is assigned when the make file is run?
If that is the case I would say keep that detection method, to me it seems like the best way to detect nintendont versions.

If there is a way to detect build version number by verifying meta.xml for the date after verifying it in the binary if the dates match display the version number from meta.xml in usb loader gx, however the meta.xml doesn't get updated very often, so I don't know how well this theory would work
 
current detection is already based on build date, but it looks for "Nintendont Loader" string, then load the written date at a fixed location past the search string.
airline is doing it differently, after the "Nintendont Loader" string is detected, he launches another detection for all month names (Jan, Feb, Mar, Apr, etc.) in the next bytes past the search string and use that new matched string position as start of the build date.
he just include an additional search loop for the date after the name, instead of using a fixed location. it's better in the sense that it's less subject to fail when nintendont change the text string written at the top of nintendont loader.
But USBGX was already using build date as version detection, it's just not a good solution because anybody can re-compile an old version of nintendont with a newer date ! USBGX will send the incorrect configs

the meta xml is not always up to date, for example if you just updated nintendont from the loader the meta.xml is not updated yet, or if you copied the boot.dol manually and the meta.xml is not present.
 
current detection is already based on build date, but it looks for "Nintendont Loader" string, then load the written date at a fixed location past the search string.
airline is doing it differently, after the "Nintendont Loader" string is detected, he launches another detection for all month names (Jan, Feb, Mar, Apr, etc.) in the next bytes past the search string and use that new matched string position as start of the build date.
he just include an additional search loop for the date after the name, instead of using a fixed location. it's better in the sense that it's less subject to fail when nintendont change the text string written at the top of nintendont loader.
But USBGX was already using build date as version detection, it's just not a good solution because anybody can re-compile an old version of nintendont with a newer date ! USBGX will send the incorrect configs

the meta xml is not always up to date, for example if you just updated nintendont from the loader the meta.xml is not updated yet, or if you copied the boot.dol manually and the meta.xml is not present.
But who would compile a different version of Nintendont and give it the wrong date by accident? I'm sure if this happens that person already know what he or she is doing and then they're the one to blame if it doesn't work with USBLGX, in any case since airline's method is working fine and as you said is easier to implement I don't see why there should be a different method used, unless someone thinks of another solution I'm fine with USBLGX checking for the date, it seems like a good idea to get around that issue!
 
But who would compile a different version of Nintendont and give it the wrong date by accident?


How about those mods out there and noods that download them?

even in the trunk the meta.xml isn't updated as often as boot.dol is

Currently, Nintendont will update the meta.xml EVERYTIME it boots unconditionally. See https://code.google.com/p/nintendon-t/source/browse/trunk/loader/source/main.c -line 134; but I really don't like the redundancy to write to SD/USB unnecessarily, a simple version check should be in place.

Anyway, the meta.xml will be accurate once you run Nintendont after you updated it (but not before)
 
So how about when a usb loader updates nintendont it boots nintendont after completing the update so that the meta.xml is updated then it returns back to the loader to have the update process completed.
 
That's not how things should work.
And Airline mod is not a fix for "how it should work", it's a fix for the date detection because nintendont broke it in 200+
and using the date is not the way it should work, so using Airline detection is not the solution.

But as currently nintendont doesn't contain the version string, it's the only method used until now.
There's no way to change this for older version of nintendont.

What I'm telling is that nintendont should change it internally to allow loaders to detect version number (but it will work only for newly released version, older nintendont will still require the build-date detection).


Thanks for trying to help me, but I'll choose the best way I think.
I have 4 days off, I'll try to update it now.
 
I dunno if anyone has this issue or its just me but with the mod I cannot use memory cards or I get an exception on vWii. I'm playing my games off of a fat32 HDD.
 
Since Nintendont 2.208 if i boot a GC game via USBLGX i always get the flickered video.
If i boot nintendont via HBC i can set force deflicker and the picture is ok.
Any tips?
 
Since Nintendont 2.208 if i boot a GC game via USBLGX i always get the flickered video.
If i boot nintendont via HBC i can set force deflicker and the picture is ok.
Any tips?

I'd just wait for Cyan to update USBLGX and keep booting nintendont through HBC. He did say last night that he has the next 4 days to work on it...
You could also try forcing the video mode to anything not 480p in USBLGX and see if any of them work.
 
What do you mean by memory cards?

Ah I guess I should have been clearer. I'm talking about Nintendont's memory cards. When you use the above mod to play gamecube games and select use a memory card in USB Loader GX I get an exception as soon as I start the game and Nintedont pops up. It doesn't matter if I select On or Individual either.

Truth be told I haven't found a way to use memory cards with a fat32 HDD. I tried usb loader gx with the mod(needed if you use the latest revision and with fat32) and I get an exception. I tried usb loader cfg and as far as I can tell there's not even an option to use a memory much less anything else related to Nintendon't >.< Nintendn't itself refuses to even work with fat32(it gives an error that theres no fat or usb/games) so I can't even configure it. SD card works just fine but I'm having bad luck with fat32 :/ games work! just not memory cards.
 

Site & Scene News

Popular threads in this forum