Hacking Configurable USB Loader

[raiderscrusade]

I too have missed out on about a month of the Wii scene

So, with this FAT support everyone is speaking about, does it mean WBFS is no longer needed on the USB Hard Drive?

 

[Sacohen9665]

I haven't been following the wii scene for some weeks, so this fat support is completely new to me.
Very cool, but how exactly does it work? Just put a single iso (trimmed?) on the drive?

The games are not iso's or ciso's anymore, they have to be converted to a wbfs file (I'm not sure why oggzee used that file extension since your not using wbfs at all any more).

He created a tool that will do the conversion also.

Dr. Clipper has a tutorial here http://gwht.wikidot.com/wbfs-to-fat-transfer.

QUOTE(raiderscrusade @ Oct 31 2009, 09:29 AM) I too have missed out on about a month of the Wii scene

So, with this FAT support everyone is speaking about, does it mean WBFS is no longer needed on the USB Hard Drive?

That's correct. You don't need a WBFS partition on the drive anymore all the games are on a FAT32 partition, for example I put mine on the same partition that has my loader and covers.

 

[kedest]

cool, thanks for that url
I really hope this will make its way to other loaders too

 

[usptactical]

I haven't been following the wii scene for some weeks, so this fat support is completely new to me.
Very cool, but how exactly does it work? Just put a single iso (trimmed?) on the drive?

The games are not iso's or ciso's anymore, they have to be converted to a wbfs file (I'm not sure why oggzee used that file extension since your not using wbfs at all any more).

Just to be clear, it absolutely is still using wbfs - just at the individual file level and not the partition level. The extension was "chosen" because that's what the original wbfs tool used.

So yes, just follow Clipper's awesome tutorials to get you started.

 

[oggzee]

@oggzee:
What is the filename of the tenth file: "name.wbf10" or "name.wb10" or any other?

I have taken a short and fast look into your code (wbfs_file) but I have not found the file name generation.
But I have found a lot of possible buffer overrun errors while processing file names, conv_to_wbfs() for example.

One hint: Use "char newname[PATH_MAX]" or "char newname[PATH_MAX+x]" instead of "char newname[1024]"
I have limited the number of splits to a maximum of 10 in all 3 places: wbfs_file tool, loader and IOS.
That should cover up to 20GB with 2GB splits.
The index is from 0-9 with the exception of the first file which uses the .wbfs extension.
Since the first split is .wbfs and second is .wbf1 the tenth file is .wbf9

the filename generation function is the first one in splits.c:
CODEvoid split_get_fname(split_info_t *s, int idx, char *fname)
{
ÂÂÂÂstrcpy(fname, s->fname);
ÂÂÂÂif (idx == 0 && s->create_mode) {
ÂÂÂÂÂÂÂÂstrcat(fname, ".tmp");
ÂÂÂÂ} else if (idx > 0) {
ÂÂÂÂÂÂÂÂchar *c = fname + strlen(fname) - 1;
ÂÂÂÂÂÂÂÂ*c = '0' + idx;
ÂÂÂÂ}
}

From the code you can also see that while the file is being created the first in the sequence is named .wbfs.tmp and at the end it is renamed to .wbfs, this is in order to avoid the possibility of leaving half-done corrupted .wbfs files around, in case something goes wrong.

Initially i was using MAXPATHLEN which is 1024 on unix. PATH_MAX is only 260
But MAXPATHLEN is not defined on windows, so i just replaced it with the literal, it's not important really.
As for the buffer overruns, i don't care about that, if you are going to have filenames that are longer than 1024 letters the program will crash, or actually i think windows might not even let you create a file with such a long path, so it's not something that is a real problem.

 

[Wiimm]

Windows: PATH_MAX is in limits.h (MVC 2005) and have the value of 512.
Linux 32bit: It resists also in limits.h has a value of 4096.

But the buffer overrun error is still there. And it depend from user input. That's bad.

P.S.: Thanx for the other info

 

[oggzee]

Windows: PATH_MAX is in limits.h (MVC 2005) and have the value of 512.

Ah, ok I'm using mingw32 compiler on windows and there it is set to 260

 

[Covarr]

I have limited the number of splits to a maximum of 10 in all 3 places: wbfs_file tool, loader and IOS.
That should cover up to 20GB with 2GB splits.
The index is from 0-9 with the exception of the first file which uses the .wbfs extension.
Since the first split is .wbfs and second is .wbf1 the tenth file is .wbf9

When are we going to need more than 4 splits? No legit games will ever be larger than a DVD9, and I doubt that any homebrew will ever get that big (even if it does, it almost certainly will run from HBC, not a USB loader).

 

[Sacohen9665]

I've been testing V46b and everything seems to be working perfectly (500GB FAT32 USB).
I've only encountered 1 error. GH5 won't load for me anymore.
I'm starting up on 223-mload. got 002 fix on, country patch on (using NTSC version on PAL wii).
Is this a known problem? or is it just some setting that's not right?
Thanks in advance for any answers.

Can you try also v46a2 and see if it makes any difference?
Is anyone else able to reproduce this problem?
Or, can anyone confirm that GH5 works for him when loaded from fat?

Oggzee;

I just swicthed over to FAT today and setup a test drvie, with my 110 games on it before I changed over my main WD 500GB My Book.

GH5 and Rock Band the Beatles both work fine for me.

I do need to convert a couple of games from .WBFS back to ISO or even better ciso. I remember reading it can be done, but I didn't think I would need it at the time and didn't really pay that much attention to it.

BTW, why did you choose a .wbfs file extension if the point of using FAT is to remove the WBFS partition and WBFS manager.
I thought it was kind of ironic that you used that extension. Disregard this. I say a reply that usptactical made earlier that explains why.

Thanks;

 

[retKHAAAN]

Please correct me if I'm talking out of my ass here

but i believe that the loader was built to load from wbfs to begin with and oggzee simply made it so that each game is in its own wbfs container so it can be stored on a fat32 partition yet still be read by the loader.

 

[Wiimm]

I do need to convert a couple of games from .WBFS back to ISO or even better ciso.

... or even WDF: much faster as ciso with equal disk usage. Try WWT.

 

[Sacohen9665]

I haven't been following the wii scene for some weeks, so this fat support is completely new to me.
Very cool, but how exactly does it work? Just put a single iso (trimmed?) on the drive?

The games are not iso's or ciso's anymore, they have to be converted to a wbfs file (I'm not sure why oggzee used that file extension since your not using wbfs at all any more).

Just to be clear, it absolutely is still using wbfs - just at the individual file level and not the partition level. The extension was "chosen" because that's what the original wbfs tool used.

So yes, just follow Clipper's awesome tutorials to get you started.

Oh, Ok. That makes sense now. I didn't know it was still using wbfs, I thought it wasa complete \new way of doing things.

Thanks for clearing that up.

My Bad.

 

[bnm81002]

I'm confused about FAT Partition and FAT32 Partition, which one is needed for the Configurable Loader? I'm planning on using a 640GB hard drive only for this loader, while my other 500GB drive be used for the other loaders,
@ Dr. Clipper, I see that you have a tutorial over here, http://gwht.wikidot.com/wbfs-to-fat-transfer.
will you be making a tutorial with a FAT32 Partition as well?

 

[Dr. Clipper]

I'm confused about FAT Partition and FAT32 Partition, which one is needed for the Configurable Loader? I'm planning on using a 640GB hard drive only for this loader, while my other 500GB drive be used for the other loaders,
@ Dr. Clipper, I see that you have a tutorial over here, http://gwht.wikidot.com/wbfs-to-fat-transfer.
will you be making a tutorial with a FAT32 Partition as well?

FAT is just another way of referring to FAT16 and FAT32. Both are supported by Cfg (but you should go FAT32 given the choice). Hence, the tutorial is for FAT32.

 

[laurozza]

I'm confused about FAT Partition and FAT32 Partition, which one is needed for the Configurable Loader? I'm planning on using a 640GB hard drive only for this loader, while my other 500GB drive be used for the other loaders,
@ Dr. Clipper, I see that you have a tutorial over here, http://gwht.wikidot.com/wbfs-to-fat-transfer.
will you be making a tutorial with a FAT32 Partition as well?

I don't know if FAT16 is supported too, but with FAT16 you can format max 4GB, so it's pretty useless.

 

[bnm81002]

I'm confused about FAT Partition and FAT32 Partition, which one is needed for the Configurable Loader? I'm planning on using a 640GB hard drive only for this loader, while my other 500GB drive be used for the other loaders,
@ Dr. Clipper, I see that you have a tutorial over here, http://gwht.wikidot.com/wbfs-to-fat-transfer.
will you be making a tutorial with a FAT32 Partition as well?

FAT is just another way of referring to FAT16 and FAT32. Both are supported by Cfg (but you should go FAT32 given the choice). Hence, the tutorial is for FAT32.

oh ok Dr. Clipper, I been reading through the past few pages and some have suggested other ways to partition the drive to FAT32, as long as your tutorial is for a FAT32 partition, I will use it

 

[oggzee]

cfg v46 (release)
Full package: SDUSB-Loader_cfg46.zip

Updated .dol: SDUSB-Loader_cfg46.dol
(or online update)

Special 222-fat version: SDUSB-Loader_cfg46-fat.dol
Which is same as 46 but with different default
options: ios=222-mload partition=FAT1
(also available in online update)

Changes since 46b:

* Support for direct launching of games from fat
ÂÂ (Useful for game channel launching, using loadstructor or similar tool)
ÂÂ To specify direct loading from fat, the parameter has to be in form: #GAMEID-X
ÂÂ Where X is 0-3 for wbfs and 4-9 for fat partitions (4 means first fat partition)
* Automatically switch to ios222 in case ios249 is used for starting games from fat
* Only allow IOS 222 and 223 in game options if fat partition is selected
* Improved drawing speed in some coverflow gui modes
* Cleanups

Changes since 45:

cfg v46b (beta)

* Added option: partition = [WBFS1], ..., WBFS4, FAT1, ..., FAT9, ask
* Saving global settings will also save current selected partition
* Increased fat cache size in IOS module
* Load FAT module in IOS early in case config has: 
ÂÂ ios=222-mload (or ios=223-mload) and partition=FAT*
ÂÂ So that IOS does not need to be reloaded another time before
ÂÂ starting the game from a FAT partition
* Added indication in global options if [FAT] module is loaded in IOS
* Cleanups

cfg v46a2 (alpha2)

* Faster loading of game list from a fat partition - should be instant now.
ÂÂ The only thing that has a slight delay is showing the hdd free space
ÂÂ in console mode game list (if it is enabled)
* Create game info file after installing on a FAT partition named:
ÂÂ usb:/wbfs/GAMEID_TITLE.txt This makes it easier to tell the titles
ÂÂ of installed games when using a filesystem explorer
* Rephrased the warning message when no WBFS partition found
* Allow to select partition if no wbfs partition is found and disable_format is on.
* Minor cleanups in partition selection

cfg v46a (alpha)

* Loading games from a FAT32 partitions. The game file has to
ÂÂ be located and named like this: usb:/wbfs/GAMEID.wbfs

 

[Covarr]

Special 222-fat version

[snip]

(also available in online update)

You just made my day! Thank you!

 

[oggzee]

Sources needed for fat support in the loader:

SDUSB-Loader_cfg46-fat-src.zip

Included are the relevant source files needed for supporting games
on a FAT partition and the ehcmodule_fat IOS222-mload module.

The ehcmodule_fat and SetWBFSMode(u8 *id, s32 partition) changes:
If the given partition is 0-3 it behaves the same as original
ehcmodule 3.1 by Hermes.
If the partition is -1 (0xFFFFFFFF) it will open the game on first fat partition.
If the partition is any other number, it will be used that as the LBA
sector address of a FAT partition to use.

The rest of the files handle listing, opening, installing and removing games
on a FAT partittion, everything is wrapped around the WBFS_* functions, so
from a loader perspective there is almost no change.

Important!
all libfat versions up to and including 1.0.5 are not suitable for writing to
files that are cluster aligned especially if multiple writes are done.
That will create a corrupted file and filesystem.
I made a fix for that and the patch has been submitted here:
http://sourceforge.net/tracker/?func=detai...amp;atid=668553
Which has also been accepted, so it should be included in libfat 1.0.6.
So the install to fat from inside the loader absolutely requires the above patch.
The version of libfat I use in cfg loader is also included. But it contains also some other
changes which might not be suitable for everyone needs, such as changes in memory
management and access to partition start lba sector.

note: the sources to the ehcmodule_fat will be published too in a day or two.

 

[9th_Sage]

Oh wow, thank you for putting in my suggestion in regards to channel loaders.

I thank you kindly for that.

*edit*
Just need to say it again, you rule, man.