Hacking Configurable USB Loader

[oggzee]

Hi oggzee, (1) at the moment implement the splitted wbfs into my tool wwt. So I have some questions:
(2)- Is the current format stable or are modifications planned? (perhaps moving the files into a sub directory)
(3)- Is the description text file needed for anything or is it only informative?
(4)Please send me the sources of the usb loader again (or commit them).
Greeting, Wiimm
(1) Nice to hear.
(2) I don't plan any further changes on the wbfs file location or format.
(3) The description text file is purely informative, loader or cios never reads it, so it can be renamed or removed at wish. The only reason it exists is to be able to quickly associate the ID to the title while looking at the directory listing.

One other improvement I was thinking about would be to automatically run some checksumming tool after the splits are created, so that the consistency can be verified later. Something like:
md5sum -b RHAP01.wbf? > RHAP01.md5
So that you can verify the integrity later with
md5sum -c RHAP01.md5
But anyone can do that manually if he wishes to.

(4) will do.

QUOTE(OtakuGamerZ @ Oct 30 2009, 03:26 PM) l think someone said this before, but now it's
usb:/wfbs/GAMEID.wfbs
but it kinda looks jumbled up and messy after many split games are added so maybe changing to
usb:/wfbs/GAMEID/GAMEID.wfbs
so each game gets its own directory. Just makes things simpler when looking at them on a pc.

If the files were each in it's own directory then the id_title.txt files would not be useful anymore, as you would be seeing all the directories first, and after that all the txt files, (at least on windows) so the direct association between the gameid and title is lost. While if the txt file is moved along the rest of the files in the separate directory then you can't have a quick overview of all the titles. I know that a view of all the files named by ID is not pretty to look at, but i don't think moving them to separate directories will make that any better? Besides now that this is all in place and working I don't feel like changing it anymore.

 

[retKHAAAN]

l think someone said this before, but now it's
usb:/wfbs/GAMEID.wfbs
but it kinda looks jumbled up and messy after many split games are added so maybe changing to
usb:/wfbs/GAMEID/GAMEID.wfbs
so each game gets its own directory. Just makes things simpler when looking at them on a pc.

If the files were each in it's own directory then the id_title.txt files would not be useful anymore, as you would be seeing all the directories first, and after that all the txt files, (at least on windows) so the direct association between the gameid and title is lost. While if the txt file is moved along the rest of the files in the separate directory then you can't have a quick overview of all the titles. I know that a view of all the files named by ID is not pretty to look at, but i don't think moving them to separate directories will make that any better? Besides now that this is all in place and working I don't feel like changing it anymore.

I haven't even used this new feature yet (don't have room anywhere to move games to) but with regard to OtakuGamerZ questions, what about the following:

games ---> usb:/wbfs/GAMEID/GAMEID.wbfs
id_title.txt ---> usb:/wbfs/id_title.txt

That way you'll still have the txt file in the wbfs directory and the games a little more organized.

 

[redia]

If the files were each in it's own directory then the id_title.txt files would not be useful anymore, as you would be seeing all the directories first, and after that all the txt files, (at least on windows) so the direct association between the gameid and title is lost. While if the txt file is moved along the rest of the files in the separate directory then you can't have a quick overview of all the titles. I know that a view of all the files named by ID is not pretty to look at, but i don't think moving them to separate directories will make that any better? Besides now that this is all in place and working I don't feel like changing it anymore.

Oggzee,

I have a couple of questions.

1. why do you name the files by gameid ?
is it "simply" a matter of parsing or is there another reason ?
I mean that I know there is a reference to the gameid in the file (offset 200 if I am not wrong, but this is by memory I have to wbfs file to check)
you must have a very good reason but I have no clue, I figured it could be either a matter of parsing speed (it is faster to list the file than checking for information within the file), or maybe is it something like to keep an easier call within the loader itself as you probably are using the gameid as a variable...

2. if you do a sub-folder structure you could maybe you could name the folder by the gamename, and keep the wbfs file named as gameid ?
i.e.
usb:\wbfs\NHL 2K10\R7OP54.wbfs
or if the space character is not allowed
usb:\wbfs\NHL_2K10\R7OP54.wbfs

edit : I just realized that this could make our life easier.
for example I do not like to mess with my iso changing the name inside.
so using such a structure would ease the use of localized titles and/or titles.txt and/or wiitdb xml file

just an idea out of the blue

cheers,
R

 

[oggzee]

If the files were each in it's own directory then the id_title.txt files would not be useful anymore, as you would be seeing all the directories first, and after that all the txt files, (at least on windows) so the direct association between the gameid and title is lost.

I haven't even used this new feature yet (don't have room anywhere to move games to) but with regard to OtakuGamerZ questions, what about the following:
games ---> usb:/wbfs/GAMEID/GAMEID.wbfs
id_title.txt ---> usb:/wbfs/id_title.txt
That way you'll still have the txt file in the wbfs directory and the games a little more organized.

That is what the first part of my reply was describing, maybe it's best if i give an example of what I view the problem with this approach would be - in windows explorer what you will see is:

RHAP01
ABCD12
EFGH34
IJKL56
...
...
...
XYZW99

followed by:

RHAP01_title.txt
ABCD12_title.txt
EFGH34_title.txt
IJKL56_title.txt
...
...
...
XYZW99_title.txt

So, there's no proximity link as it is now:

RHAP01.wbfs
RHAP01_title.txt

ABCD12.wbfs
ABCD12_title.txt

EFGH34.wbfs
EFGH34_title.txt

IJKL56.wbfs
IJKL56_title.txt
...
...
...
XYZW99.wbfs
XYZW99_title.txt

As you see it's debatable what looks better. And again, at this point i don't see a benefit large enough to make a change. Besides, someone could make a nice looking gui on top of that to show the file listing as the current wbfs managers do which would solve the problem.

 

[retKHAAAN]

Any reason why you couldn't generate the .wbfs names as gameid_title.wbfs and have the loader ignore everything after the underscore?

It doesn't matter to me either way since I don't use it. Just brainstorming

 

[redia]

That is what the first part of my reply was describing, maybe it's best if i give an example of what I view the problem with this approach would be - in windows explorer what you will see is:

RHAP01
ABCD12
EFGH34
IJKL56
...
...
...
XYZW99

followed by:

RHAP01_title.txt
ABCD12_title.txt
EFGH34_title.txt
IJKL56_title.txt
...
...
...
XYZW99_title.txt

So, there's no proximity link as it is now:

RHAP01.wbfs
RHAP01_title.txt

ABCD12.wbfs
ABCD12_title.txt

EFGH34.wbfs
EFGH34_title.txt

IJKL56.wbfs
IJKL56_title.txt
...
...
...
XYZW99.wbfs
XYZW99_title.txt

As you see it's debatable what looks better. And again, at this point i don't see a benefit large enough to make a change. Besides, someone could make a nice looking gui on top of that to show the file listing as the current wbfs managers do which would solve the problem.

oggzee,

that makes total sense to me.
and as you mentioned I am pretty sure that someone will create a gui pretty soon.

but I believe (people correct me if I am wrong) that one of the concern is also the multiplication of files in the folder.
having to maintain one folder per game could be much easier...

R

 

[oggzee]

Oggzee,

I have a couple of questions.
why do you name the files by gameid ?
is it "simply" a matter of parsing (faster to list the file than checking for information within the file), or is there another reason ? (sorry if the question sounds stupid)

if you do a sub-folder structure you could maybe you could name the folder by the gamename, and keep the wbfs file named as gameid ?
i.e.
usb:\wbfs\NHL 2K10\R7OP54.wbfs
or if the space character is not allowed
usb:\wbfs\NHL_2K10\R7OP54.wbfs

just an idea out of the blue

cheers,
R

Because I have maintained the interface to IOS: Disc_SetWBFS(u32 mode, u8 *id)
Which only accepts a GAMEID, which is of fixed length [6].
One of the problems is the thing has to go through dipplugin for which the source is not available.
One solution could be to add additional ioctls to the ehcmodule to specify a pathname
Another solution could be to scan the files and folders in IOS for the appropriate ID but that would make the loading slower.
Any change means more complications inside IOS and I want to stay away from that as much as possible.
In my view the current solution is simple and and usable enough.
Maybe someday someone will improve that, but as far as I'm concerned I'm satisfied with it as is.
If someone wants a nicer display or easier management, a gui can always be build on top of that.

 

[oggzee]

1. why do you name the files by gameid ?
is it "simply" a matter of parsing or is there another reason ?
I mean that I know there is a reference to the gameid in the file (offset 200 if I am not wrong, but this is by memory I have to wbfs file to check)
you must have a very good reason but I have no clue, I figured it could be either a matter of parsing speed (it is faster to list the file than checking for information within the file), or maybe is it something like to keep an easier call within the loader itself as you probably are using the gameid as a variable...

Forgot to comment on the question about speed, yes that is too an issue.
You can check the first version v46a, which looked up ID and TITLE inside each of the .wbfs files when making a list of games, and that took a couple of seconds (about 8 seconds for 50 games I think, but that could still be optimized a bit i think to at least 4 sec per 50 games) And compare that to v46a2 or v46b, where the game listing is instant as it just uses the ID from the file name and doesn't read the .wbfs file till you actually try to launch it.

 

[laurozza]

A little question: the support for FAT32 works even for SD/SDHC?

 

[oggzee]

A little question: the support for FAT32 works even for SD/SDHC?

Sorry but no, it doesn't.
Mostly because ios222 doesn't support loading games off SD .
But it could be done with some work.

 

[redia]

Because I have maintained the interface to IOS: Disc_SetWBFS(u32 mode, u8 *id)
Which only accepts a GAMEID, which is of fixed length [6].
One of the problems is the thing has to go through dipplugin for which the source is not available.
One solution could be to add additional ioctls to the ehcmodule to specify a pathname
Another solution could be to scan the files and folders in IOS for the appropriate ID but that would make the loading slower.
Any change means more complications inside IOS and I want to stay away from that as much as possible.
In my view the current solution is simple and and usable enough.
Maybe someday someone will improve that, but as far as I'm concerned I'm satisfied with it as is.
If someone wants a nicer display or easier management, a gui can always be build on top of that.

QUOTE(oggzee @ Oct 30 2009, 03:33 PM) Forgot to comment on the question about speed, yes that is too an issue.
You can check the first version v46a, which looked up ID and TITLE inside each of the .wbfs files when making a list of games, and that took a couple of seconds (about 8 seconds for 50 games I think, but that could still be optimized a bit i think to at least 4 sec per 50 games) And compare that to v46a2 or v46b, where the game listing is instant as it just uses the ID from the file name and doesn't read the .wbfs file till you actually try to launch it.

oggzee,

thanks for the clarification.
it is pretty close to what I suspected. man I am good

lol
ok returning to humble mode

and how hard would the implementation of sub-folder would be ?
do you think you would also be limited to the gameid ?
if that's the case then I fully understand why you are not doing it.
and we shall wait until someone (nubecoder ? omegafrost ?

) update their nice gui.

one last question before I give you a break.
you probably remember we discussed the 2gb size limit issue.
I believe this is far from being on top of your to do list.
but if you ever implement it, it would be great if you provide a tool to concatenate the existing file

Cheers,
and once again thanks for your huge work.

R

 

[oggzee]

one last question before I give you a break.
you probably remember we discussed the 2gb size limit issue.
I believe this is far from being on top of your to do list.
but if you ever implement it, it would be great if you provide a tool to concatenate the existing file

You can already do that using standard tools:
windows:
copy GAMEID.wbfs + GAMEID.wbf1 + GAMEID.wbf2 OUTFILE.wbfs
unix:
cat GAMEID.wbfs GAMEID.wbf[1-9] > OUTFILE.wbfs
and on unix split -b command can be used to do the reverse

 

[laurozza]

A little question: the support for FAT32 works even for SD/SDHC?

Sorry but no, it doesn't.
Mostly because ios222 doesn't support loading games off SD .
But it could be done with some work.

Ok, no problem, i asked only for curiosity.

I noticed that deleting the WBFS partition, increase the compatibility of other homebrews with my hard disk, as i said here: http://gbatemp.net/index.php?s=&showto...t&p=2359781

So thanks again!

 

[redia]

one last question before I give you a break.
you probably remember we discussed the 2gb size limit issue.
I believe this is far from being on top of your to do list.
but if you ever implement it, it would be great if you provide a tool to concatenate the existing file

You can already do that using standard tools:
windows:
copy GAMEID.wbfs + GAMEID.wbf1 + GAMEID.wbf2 OUTFILE.wbfs
unix:
cat GAMEID.wbfs GAMEID.wbf[1-9] > OUTFILE.wbfs
and on unix split -b command can be used to do the reverse

ok.. my main concern was to know if there was any information embedded in each file that would forbid us from doing that, or even the number of expected parts in the first file.. but from your answer I guess that's obviously not the case

shouldn't we use
copy /b GAMEID.wbfs + GAMEID.wbf1 + GAMEID.wbf2 OUTFILE.wbfs
/b being for Binary ?

R

 

[oggzee]

shouldn't we use
copy /b GAMEID.wbfs + GAMEID.wbf1 + GAMEID.wbf2 OUTFILE.wbfs
/b being for Binary ?

Yes, you are right!

 

[Skizzo]

Is the source of the loader available? Didn't saw it in the archive nor a link, that's why I ask.

Are you asking because you're interested in adding fat32 support to some other loader?
If so, I will release the relevant fat32 sources after v46 is released, to give 46b a bit more testing time.

I know we've talked in PM, but I don't think you ever answered the question about what the actual status of the loader is? Is it indeed licensed under GPL or using other code that is (which I guess would mean this has to be as well)? If it is GPL'd, isn't a simple request enough to get the code or can you pick and choose who is allowed the code depending on their answer to your questions? Just wondering why you stopped releasing the source code with the app. I can somewhat understand your reasons for this particular version, but you haven't included the source for quite some time, correct? Don't take any of this to imply that I'm some sort of licensing police or anything, just curious is all.

 

[giantpune]

why do you want the source now? it is better for the person who best understands this code to work out the bugs before people that dosnt know alot about how it is set up start messing with it. better to just be patient and when they think that its ready, we can all swoop in and steal it and to with it as we please.

 

[oggzee]

I know we've talked in PM, but I don't think you ever answered the question about what the actual status of the loader is? Is it indeed licensed under GPL or using other code that is (which I guess would mean this has to be as well)? If it is GPL'd, isn't a simple request enough to get the code or can you pick and choose who is allowed the code depending on their answer to your questions? Just wondering why you stopped releasing the source code with the app. I can somewhat understand your reasons for this particular version, but you haven't included the source for quite some time, correct? Don't take any of this to imply that I'm some sort of licensing police or anything, just curious is all.

Yes I send the sources out by request. I never send out alpha/beta versions. And usually i don't send the current version, but one before that, partially to avoid forks and quirks and unofficial builds and mods. And i still think this mostly complies with the license. Oh and before anyone starts analysing and commenting on the license, don't bother i'm not interested in discussing it. After all as hibern put it, it's just a some stupid tool mostly used by pirates, what are you gonna do, sue?

Ayway here's v44 source:
http://sharebee.com/154938b2

Oh and fat32 support will be an exception, i will release that part as soon as it's ready.

 

[Skizzo]

why do you want the source now? it is better for the person who best understands this code to work out the bugs before people that dosnt know alot about how it is set up start messing with it. better to just be patient and when they think that its ready, we can all swoop in and steal it and to with it as we please.

Assuming you're talking to me, I think if you actually read what I wrote, you'd see I didn't ask for the code anywhere. As I've said, I've already spoken with oggzee by PM regarding the source, and was perfectly content with the results of that discussion, other than the questions mentioned. Again, none of which were a request for the source code. In fact, I even went so far as to state that I understood the reasoning behind not releasing the code for this version with the new features, yet. Oh, and acquiring the source code to GPL projects isn't exactly stealing. But thanks for reading (or not).

 

[Narolez]

Yes I send the sources out by request. I never send out alpha/beta versions. And usually i don't send the current version, but one before that, partially to avoid forks and quirks and unofficial builds and mods. And i still think this mostly complies with the license. Oh and before anyone starts analysing and commenting on the license, don't bother i'm not interested in discussing it. After all as hibern put it, it's just a some stupid tool mostly used by pirates, what are you gonna do, sue?

The one hand, you're right, but if you use one component that's under GPL (for example WBFS) you're obligated to publish the source code. That's just the way it is. Set up a SVN repository or something else and commit the release versions, then you're "clean" and no one will discuss.