unofficial LaunchELF v4.42

[dlanor]

My myPS2 elf is ok because i could launch it on ulaunchelf 3.42, now black screen is the results of execute this elf on 3.46

myPS2 was not one of the programs I had tested with v3.46 yet, and it appears that there is some problem specific to this program.

I'll have to investigate this a bit further before I can say anything more conclusive about it.

-----
Edit: Problem solved!
NB: Replacement ELFs for myPS2 v1.1 are attached at the bottom of this post !!!

Analysis of the myPS2.ELF file shows that it has been packed with an unusual unpacker stub. That stub will load the data block to a high (normal) address, but will load the unpacker itself to a very low address == 0x88000 (unusual for these circumstances).

That RAM usage conflicts with the new ELF loader of LaunchELF v3.46, which uses the address range 0x83000-0xa8000, which is just below the area that would be used by the new ps2link version if that was also resident. Thus it is not an acceptable solution to raise the addresses of the LaunchELF loader to the values previously used (main range=0x90000-0xb0000), as that would break ps2link compatibility again.

A better solution is to use a different unpacker stub for myPS2, or even to use an unpacked version of myPS2 (for use on mass: or HDD of course). I have tested both methods, proving that uLaunchELF v3.46 then has no problems launching myPS2.

As I know many users are unfamiliar with ELF packing methods, I am supplying two ELFs for myPS2 v1.1, which are guaranteed to work with uLaunchELF v3.46 (and future versions). Note that those ELFs were not recompiled by me. I just took the ELF of the original release, unpacked it, made an extra copy, and then repacked that copy.

So the attached ZIPs contain one unpacked copy and one repacked copy of what is still the original release version of the ELF for myPS2 v1.1, without any alterations by me, apart from the unpacking/repacking.

Best regards: dlanor

[RoVeR]

Yes, now myPS2 1.1 run on uLaunchELF 3.46, but it still returning my error loading gui table :-(. Dlanor can you make the same with the 1.0 version?

Sorry for my english

[dlanor]

Yes, now myPS2 1.1 run on uLaunchELF 3.46, but it still returning my error loading gui table :-(. Dlanor can you make the same with the 1.0 version?

Sure I could, unpacking and repacking is dead easy with the right tools.

But I think it would be a very bad move to go back to that version. You would then be reviving many bugs that the author worked hard to fix for the new version. I can't say that myPS2 is my kind of program, but once you install and configure it correctly v1.1 does work, without the error message you mention.

However, once you do have errors in config.dat and possibly other files too, then you need to replace those with new copies of the originals. For HDD use this naturally means an 'almost' original of CONFIG.DAT, after adding the two lines defining the hdd boot folder (with unix-style line-endings).

Also, I never got the program to work very well until I allowed it to make a myPS2 partition on the HDD. Though it isn't used for much (thumbnails), the program seems to need it somehow, just to accept other settings.

But please, if you need more help with myPS2, get it in the forum for that program.
Our main concern right here is uLaunchELF, so other APPs are on-topic only in how they and their uses relate to uLaunchELF and its uses.

Sorry for my english

I've seen lots worse

And this is in any case an international forum. Though our common language is english, lots of us only use it as a second language, and many of us (Like me ) have never even visited a country where english is the main language.

Best regards: dlanor

[E P]

Nice work dlanor and Drakonite. I tried out the new ps2link 1.46 with uLaunchELF v3.46 and everything appears fine so far. With the changes made to loader.c, I decided to check if it would also resolve the issue with evilo's libcdvd. It didn't so perhaps it's a combination with something else. Oh well, it was worth a try.

I tested out host: and no real issues to report. It did lock up once on a directory with 'get size' but I think it was do to long path's that was mentioned before. However, it worked quite well at renaming and deleting windows files and folders.

Right now I'm in the process of getting all my stuff together to do some final testing with the mc backup routine. I finished updating my save database file so it shouldn't take long to check the saves. Once I salvage part of my Onimusha 3 save I'll re-format my 8 MB card and restore all the backups from the ps2 hdd.

[truemajik]

I haven't been able to successfully set-up a working dev. environment to to lend a helping hand at making PS2Script part of uLaunchELF. The attached file are steps I was taking to put EEUG's toolchain, ps2sdk, libcdvd, libito, ps2eth, etc. in some working fashion but cold not get it done properly. If possible, can any of you point me out to what I am doing wrong? I would really much like to assist in the task of implementing PS2Script in uLaunchELF. Thanks.

[lonwern]

I haven't been able to successfully set-up a working dev. environment to to lend a helping hand at making PS2Script part of uLaunchELF. The attached file are steps I was taking to put EEUG's toolchain, ps2sdk, libcdvd, libito, ps2eth, etc. in some working fashion but cold not get it done properly. If possible, can any of you point me out to what I am doing wrong? I would really much like to assist in the task of implementing PS2Script in uLaunchELF. Thanks.

Perhaps this link may help to you
http://www.lukasz.dk/ps2dev/cygwintutorial.html

[E P]

I haven't been able to successfully set-up a working dev. environment to to lend a helping hand at making PS2Script part of uLaunchELF. The attached file are steps I was taking to put EEUG's toolchain, ps2sdk, libcdvd, libito, ps2eth, etc. in some working fashion but cold not get it done properly. If possible, can any of you point me out to what I am doing wrong? I would really much like to assist in the task of implementing PS2Script in uLaunchELF. Thanks.

Sure I've been meaning to put together a tutorial for compiling uLaunchELF.

I'll just mention some things I noticed in your setups-steps file:
1. The path for the ps2dev dir should be 'cygwin\usr\local\ps2dev'.
2. You will need the latest source files for the ps2sdk. Just get them from svn(svn checkout svn://svn.ps2dev.org/ps2/trunk/ps2sdk). Move all the modified ps2sdk files from the uLaunchELF source package to ps2sdk. Then rename the ps2sdk directory to ps2sdksrc. Now do a 'make release' on the ps2sdksrc to build the latest ps2sdk. This is where I believe your real problem currently is.

Dlanor is usually better at explaining things.

[cmal1492]

I am using uL from dev1 mode. I just used an older version of uLaunchElf (3.41r) from a different memory card (one of the offical 8MB ones) to get the file off my 64MB Max card, and hex compared to the origional compressed elf from the archive, they are identical (corruption doesnt appear to be an issue), and when I revert to 3.45 I get the same error on the SMS, but the other stuff I could run previously is fine.

Leads me to look a little deeper... perhaps corruption/fragmentation on the memory card is a problem (I have know this type of thing to slow down game saves before, and break infinities application manager entirely)

The problem appears to be me breaking the "golden rule" of not having directories within directories. Older version of uL seem OK with running files inside of these directories but not in these latest revisions. My bad, I will move my files up a level and suffer having to find some more icons to get rid of the corruption.

Thanks for looking into it dlanor. I wish I had a better explanation for why its not a good idea to have folders inside of folders than my assumption that the MC access drivers dont like it, and why it seems to be getting pushed out slowly as the program advances. No biggie though, Im sure I can scam some icons somewhere... or suffer a mass of duplicates.

On another interesting note: the mcPaste function backed up my 64MB memory card to host completely, subfolders and all

edit:/ I can launch alot more of the nested files after reupping the BOOT.elf (the compressed one) using flashfxp instead of windows explorer. Not sure what difference that makes but..

edit2:/ well, Im really at a loss now, I formatted the entire card and put the files on with no subfolders and I am still getting alot of problems. For example, I can run the file mc0://BOOT/BOOT.ELF (which is uL, but it crashes when it runs) but I cannot run the file mc0://MATRIXTEAM/MANAGER.ELF (which is the same uL, but it gives the "not an elf file" message and promptly halts/crashes) - after multiple tries I am indeed able to run the file some of the time, occasionally it even boots up uL again. Im figuring its running it instead of giving an error about it not being an elf 1 in 10 reboots

I think the ELF "detection" needs to be looked at again with the latest changes that were done to increase bootrates and such. It really should not be crashing if it gives the error "this is not an elf" on an elf file (and it seems to be pretty erratic as to when this happens for me).

[dlanor]

@cmal1492:
Your last post stated clearly that for you LaunchELF v3.46 was completely incapable of launching any ELF. Now you say that it sometimes can, but is not consistent about it.

To me that would mean either that LaunchELF itself is damaged, which it seems you have tested for, or that the ELFs you want it to run are damaged, or that some hardware is so bugged/broken that nothing can operate properly.

NB: No one else has reported v3.46 as refusing to run ELFs, so it is an error unique to your setup. This means that we must question the validity of that setup, and the most suspect item of those you mention is your 64MB MC.

I am using uL from dev1 mode. I just used an older version of uLaunchElf (3.41r) from a different memory card (one of the offical 8MB ones) to get the file off my 64MB Max card, and hex compared to the origional compressed elf from the archive, they are identical (corruption doesnt appear to be an issue), and when I revert to 3.45 I get the same error on the SMS, but the other stuff I could run previously is fine.

Please try the following:

Install BOOTc.ELF of "uLaunchELF v3.46", together with its default LAUNCHELF.CNF to a folder on your 8MB MC. (But not the folder where you have v3.41r working, and not to /SYS-CONF/).

Do NOT take either of those two files from the 64MB MC, but unpack fresh copies from the ZIP, and use those.

After this, reboot with the 8MB card and use v3.41r to start v3.46.
Finally test if v3.46 now also can start ELFs (like itself for example ).
That should work, both consistently and reliably.

Leads me to look a little deeper... perhaps corruption/fragmentation on the memory card is a problem (I have know this type of thing to slow down game saves before, and break infinities application manager entirely)

Just so you know:
Such problems are extremely rare on proper MCs that are used properly.

The problem appears to be me breaking the "golden rule" of not having directories within directories. Older version of uL seem OK with running files inside of these directories but not in these latest revisions.

Wrong. uLaunchELF has no problem dealing with subfolders. That is not the cause of the problem.

My bad, I will move my files up a level and suffer having to find some more icons to get rid of the corruption.

It is a good idea to avoid subfolders on MC, but once you have real corruption there is NO way to cure it other than to reformat. Just eliminating subfolders will not remove corruption that has already occurred.

Thanks for looking into it dlanor. I wish I had a better explanation for why its not a good idea to have folders inside of folders than my assumption that the MC access drivers dont like it, and why it seems to be getting pushed out slowly as the program advances.

The drivers can access subfolders, but that is not the problem. The real problem is the official PS2 browser, and possibly some other commercial software using similar routines.

Those routines simply assume that no subfolders exist, and don't use the generic fileio methods to access them (which would work). Instead they dig directly into the raw directory sectors, still with the assumption that folders can only exist at top level, so they treat anything inside top level folders as files, which is not a good thing to do with folders...

When such methods are used to copy a folder with subfolder content, then the wrong amount of MC space may be allocated for the copy, which will in any case be incomplete. The miscalculated amount of space is simply lost, and can only be regained by reformat.

When those methods are used to erase a folder with subfolder content, then all space used by those subfolders and their content will also be lost until the MC is reformatted. By lost I don't mean erased, as erased items have their space released, but subfolder content will in these cases simply be ignored, and never released.

Some tests also indicate that the operation of the 'remaining' space on such an MC becomes unreliable, possibly because drivers become confused by conflicting information in some directory sectors after such mismanagement.

No biggie though, Im sure I can scam some icons somewhere... or suffer a mass of duplicates.

Good, do that for the future then, but be aware that it doesn't cure present corruption (like I said above).

On another interesting note: the mcPaste function backed up my 64MB memory card to host completely, subfolders and all

Sure, it should be able to do that.
But if you really have corruption on that MC, then the value of the backup is dubious. 'mcPaste can only save what is present, and if that was corrupted already, then the backup will be so too.

edit:/ I can launch alot more of the nested files after reupping the BOOT.elf (the compressed one) using flashfxp instead of windows explorer. Not sure what difference that makes but..

I repeat. If both LaunchELF and the other ELFs are undamaged, then LaunchELF should be able to launch them regardless of the folder level they are stored in. Those routines have no known problems with subfolders.

edit2:/ well, Im really at a loss now, I formatted the entire card and put the files on with no subfolders and I am still getting alot of problems. For example, I can run the file mc0://BOOT/BOOT.ELF (which is uL, but it crashes when it runs) but I cannot run the file mc0://MATRIXTEAM/MANAGER.ELF (which is the same uL, but it gives the "not an elf file" message and promptly halts/crashes) - after multiple tries I am indeed able to run the file some of the time, occasionally it even boots up uL again. Im figuring its running it instead of giving an error about it not being an elf 1 in 10 reboots

Sorry, but to me that seems typical of failing hardware.
I mean, a digital program running the same test on the same digital file repeatedly should give the same result EVERY time, not just 9 out of 10.

I suspect that MC is 'dying', though it may be some less fatal problem too.
(Bad/dirty/oxidized connectors, for example.)

I think the ELF "detection" needs to be looked at again with the latest changes that were done to increase bootrates and such.

Sorry, but I disagree. What you say would be true if others had the same error, but you are the only one who has reported anything like this.

It really should not be crashing if it gives the error "this is not an elf" on an elf file (and it seems to be pretty erratic as to when this happens for me).

The fact that all the tests are erratic in their results may in itself be a clue, at least I take it as such. And to me that clue hints at a hardware problem of some kind. And if it is the MC that is failing, then LaunchELF can also be expected to show weird bugs, as it was loaded from a failing device, and may have been corrupted in that process.

Please do the tests I asked you to, near the top of this post, to see if v3.46 works better on another MC of the standard 8MB type.

Best regards: dlanor

[zabolyx]

Sounds as if a stack assignment list should be made and agreed upon...

Thus allowing for development projects to not clash with each other so often... although the only reason this is happening is that by making uLE compatable with one program you've crossed into others domains where things were fine before....

In all practicality it seems that changing the stack of PS2link would have been a better means of fixing this....

But a set list of apps and good locations would help with many things in the future... such as if a plugin system is developed for uLE... so that needed room can be planned for and allowed for, as to not conflict with other programs that have there own stack locations...

now is all 32MB of the PS2 addressable for homebrew purposes?

If so then allowing certain sections to be used by apps such as....

lower segments for loaders and residents
above this allowing for plugins and extra support code
above this most apps
and at the top (with the largest block of all) for data usage for programs such as SMS and MyPS2 for video and audio work.....

This may for may not work of course and getting every dev group to adopt any kind of logical idea seems nearly impossible.... but hey... it's an idea none the less.