Open PS2 Loader Project - v0.9

[jimmikaelkael]

PS2 Elf binary, rev62:
http://www.4shared.com/file/14516788...SBLDrev62.html

iso2usbld binary, rev62:
http://www.4shared.com/file/14516828...bld_rev62.html

@volca:
Please test this iso2usbld binary to install Lego Indiana Jones and report, it's working for me.

[savov]

PS2 Elf binary, rev62:
http://www.4shared.com/file/14516788...SBLDrev62.html

iso2usbld binary, rev62:
http://www.4shared.com/file/14516828...bld_rev62.html

@volca:
Please test this iso2usbld binary to install Lego Indiana Jones and report, it's working for me.

You are my hero!
Gonna try it right now.

[JNABK]

@volca:
Please test this iso2usbld binary to install Lego Indiana Jones and report, it's working for me.

After i've finished preparing your requested files for debugging, i can use iso2usbld to install 2 Lego games i have:

Legos Starwars II : The original Trilogy
Legos Starwars: The Video Game

I also have a lot of other games i havent had a chance to test, so i'll use both of those binaries for my next batch of tests.

[Bootlegninja]

PS2 Elf binary, rev62:
http://www.4shared.com/file/14516788...SBLDrev62.html

iso2usbld binary, rev62:
http://www.4shared.com/file/14516828...bld_rev62.html

@volca:
Please test this iso2usbld binary to install Lego Indiana Jones and report, it's working for me.

On a related note, I'm testing this on another non working game. Primal. (what can I say, it's one of my favorites. )

edit - a no go on my end. still black screen. but it was worth a shot.

by the way, nice upgrades on the GUI with the icon and the start network message.

[dlanor]

My new results after compiling a source package downloaded today:

This version works much better, in that the config file is now handled correctly on MC, and its values revived after each new launch of the program.

It also works better in that some few games even do launch from the USB drives now, although some that always worked with ancient USBA versions, as well as with both branches of the original USBLD v0.41 release (the one with two kernel versions). It is only in this new version that they fail, possibly because of the lib revision issues I keep nagging about...

Having gotten this far I have also started trying to get the network functionality going, but with total failure so far. And here is what I did so far:

----- start of my USBLD networking efforts -----
I switched one of my PCs (the one in USBLD PC_IP config) to use simple file sharing instead of the secure system it used previously.

In an HDD folder of that PC I stored a collection of USBA-installed games, prepared by USBUtil, and working with USBA if copied to a USB device. And I set this folder up to be a new network share named "PUBLIC". While doing this I had SMS open and could see the new share appear in the listing as "PUBLIC:".

However, in all future launches of SMS the login consistently fails, so I will have to abandon these networking attempts anyway, until secure login procedure is properly implemented. I MUST keep SMS configured for such login, since I use it for multiple computers, and changing all of them to insecure (==simple) file sharing is not an option.

But for the time being I did make a number of additional experiments with simple filesharing active, but I never got USBLD to notice the existence of the PUBLIC share nor its content in any way. I tried it both with manual network start and by setting the config option for automatic network start and relaunching the program. Nothing had any visible effect.
----- End of my USBLD networking efforts -----


Btw:
I'm not sure if others have noticed it, but the USB functionality both of USBLoader and USBAdvance seems oddly dependent on having a direct USB slot connection. Modern homebrews work equally well in any USB slot, including those of an external hub, but this does NOT apply to USBAdvance or USBLoader... I get distinctly different crash screens when attempting to launch any game through a hub, and for a launch via hub these attempts always crash with a white screen with the new USBLD I have, and with old USBAdvance I usually get black-screen crash. I suspect this dependency is due to an outdated USBD version which does not properly handle hub slots.


While I was writing the above, a number of new posts appeared which I have chosen to reply to in the remainder of this post:

Normally it has been applied to one of the latest SDK rev, but after 1611 if I remember well.
But since the latest SDK have been broken, I can't suggest to update.
I'm sorry of the lack of info about needed patches, but our goal was latest SDK needed, but no patches required... but since it's now broken...

This broken state is an extra complication, but even without that issue the precise lib revisions can still matter. A lib doesn't have to be completely broken in order to cause inconsistent results for users with different revisions of it.

Maybe I can compile the latest for you, so that you could be able to see if it's definitely an incompatibility of your device or something wrong in sdk ?

It is definitely not a device incompatibility, as I tested it with half a dozen different USB devices, all of which work perfectly with USBAdvance.

A public precompiled binary would be a good way to get more consistent test results, and not just from myself. But I'll leave that up to the choice of you guys who are actively involved in the development of the project.

Normally i would agree, but in this particular case, the skins will be a 2.17MB files , if all images are used in a skin.

Then perhaps it is time to consider a compressed image format.

I know some people wouldnt mind using that amount of space on their MC, but as a default location for such a large size im sticking to it should be on a USB device, but with a configuration choice to place it elsewhere by the user. The usbld.cfg i can understand could be placed on the MC in the SYS-CONF folder as a default location, also with a choice by the user to configure its path.

Configuring the default path to look for a config file is obviously ineffective, as the config file must already be loaded for any config to take effect. But having alternate locations is easily done anyway, and once the file is found in any valid location that is the location to be used for saving as well, so this is not a problem. The only critical choice is the default location of the main config file, and that should always be MC. But it may still indicate skin files stored on other devices, just like we can do it for uLE.

I dont know the revision number used by GSHI to create the msys/mingw package, but the sbv folder i used from the SVN was 1644 and i updated all the files from that folder. I have never updated before (im a noob at this) and perhaps i did something wrong, i replaced each file manually, as i couldnt get mingw to update for me with the 'svn co' command.

If I understood you correctly this means that you know the lib revision only of that "sbv" folder, and nothing else... This does not really help much, for someone who just downloaded all libs from current SVN revision, except for PS2SDK which I reverted to 1611.

Hey go easy dlanor, it's far to be complete, there's no write support at all, and I have only implemented needed stuff to connect/login as guest/read files...

That is what I had already assumed myself.
But I hope you will implement secure login too, much like in SMS.

That write support might be crucial to uLE, no ?

Not necessarily. Even for the HOST protocol the default of uLE is to have the write support disabled. It takes 'hand editing' of the CNF file to enable it (as a safety precaution for the PC content).

One of the most common uses of uLE networking is just to copy stuff onto a memory card, or to normal file partitions of a PS2 HDD, and that requires no write support at the PC end. But it will of course be needed for making PSU backups to a PC, and similar needs.


@jimmikaelkael:
I've downloaded both 'rev62' files and will test them a bit later.

Btw:
I do have a MinGW setup for PC_only use (so no PS2 toolkit), and with this I too could compile the iso2usbld.exe from the package sources without problems, and that exe file seemed to work fine. But I just checked the results 'visually', not by running the game.

Best regards: dlanor

[Bootlegninja]

In an HDD folder of that PC I stored a collection of USBA-installed games, prepared by USBUtil, and working with USBA if copied to a USB device. And I set this folder up to be a new network share named "PUBLIC". While doing this I had SMS open and could see the new share appear in the listing as "PUBLIC:".

The shared folder is now PS2SMB. This was brought about when JNABK had some conflicts in his shared folders on his network.

[JNABK]

And I set this folder up to be a new network share named "PUBLIC".

The Share Name has been changed to PS2SMB.


edit- bootleg with that quick reply, almost as fast as his ban stick .....

[volca]

@jimmikaelkael:
I tried your program with wine (no windows here ) and it failed the same way: "Error: failed to locate elf path from ISO file!"

Now looking at the way the SYSTEM.CNF is loaded. There seems to be offsetting problem. In midnight commander I can view the file and see the BOOT2 line, whereas looking at the data isofs read I only see zero bytes (after dumping into a file).
This is the address of the SYSTEM.CNF as detected by isofs, and it's length. The length fits.

offset =38901760 nbytes = 57

Damn, I cant find a single program to list file adresses in iso files to verify if this.

Edit: Never mind, I found the source of the problem: in isofs.c on line 984, the fh->lsn loses most significant bits as it seems it stays in int context.
Typecasting to s64 fixed it:
offset = (((s64)fh->lsn) << 11)+ fh->position;

[jimmikaelkael]

ok so it comes from the fact of using long long type on Linux I think.

[JNABK]

One thing i noticed that changed and is a little confusing is the themes selection.
When you are selecting a theme to use, it will display the 'current' theme after you have selected a theme to use, but before it displayed the theme your intending to use.

I first thought it was an error at not selecting the chosen theme, but realized it was saying its the current theme in use, before saving.

It should be the other way around. Dislpay the current theme when you first open the theme configurations, then once you select a theme, it should remain displaying that theme name until you either save or choose another.