unofficial LaunchELF v4.42

[HypERSoniC]

copied an elf to hdd using host, and launchelf could not run the file(corrupted). however, if i copied the file to MC, launchelf could successfully launch the file.


i reccomend to avoid copying from host to the HDD directly. Instead copy to MC or USB first.

[dlanor]

copied an elf to hdd using host, and launchelf could not run the file(corrupted). however, if i copied the file to MC, launchelf could successfully launch the file.


i reccomend to avoid copying from host to the HDD directly. Instead copy to MC or USB first.

Maybe you're right, but I doubt it. In my earlier test I did transfer directly from host: to mass:, and still got 3 out of 18 ZIPs damaged.

In the meantime, here is a result that shifts the 'heat' away from host:. I just transferred the same 18 ZIPs as before to HDD using ps2ftpd (built into LaunchELF). Then I copied them to mass: and moved that to the PC for testing ZIP integrity. This time four of the ZIPs were damaged, and host: was not involved in any way...

The only common factors here are the TCPIP interface and the USB drive I used to carry the files back to the PC. That drive (a HP Disgo) is above suspicion IMO, and has also been verified as good in long usage. So the only real suspect here is the TCPIP stack...

This obviously needs further testing, with other clients too, as that should show if such results are tied to this particular project or not.

Edit: I have now made further tests using ExecFTPs 0.69 to transfer the same 18 ZIPs as before. This time the number of damaged ZIPs was 2. Naturally we must expect some random variations in this kind of testing, so roughly ALL of these tests have errors of the same order. And this final test proves that the errors are NOT specific to the LaunchELF project, but rather to the TCPIP stack. Apparently we can't rely on this for safe transfer at present, regardless of the choice of high level protocol handler (host:, ps2ftpd, ExecFTPs).

Results of this importance should not rely on testing only by one or two persons. I would appreciate it if others could make ZIP transfer tests similar to mine, using the non-LaunchELF transfer methods (eg: ExecFTPs, PS2OS FTP etc) to verify or refute whether this does indeed affect all of them !!!

Best regards: dlanor

[jackielo]

Thanks, I have copied these to one of my memory cards, and I have also found and installed ELISA100.FNT. Now I have both bad news and good news for you...

The bad news is that I will not make any new version to handle this font.
The good news is that this is because the current version (v3.41d) already does handle it correctly. When I installed ELISA100.FNT into mc0:/SYS-CONF/ I could directly thereafter press L1 and view the japanese characters in the names of your game saves, and I also discovered that there are four japanese characters in the names of the game saves for FFX international that I already had.

So, this feature is already working correctly, and if it doesn't work for you, then it may be because you have the font in the wrong place. It will only be used if stored in the same folder as the currently used LAUNCHELF.CNF, and if you don't keep the CNF in the same folder as the ELF, then the default folder will normally be mc0:/SYS-CONF/ (except if the ELF is on MC1, because then the CNF and FNT will be looked for in mc1:/SYS-CONF/ first).

Best regards: dlanor

Thanks. It is working now!

[E P]

Dlanor I too had problems with ftp when I was using 3.41c. I think those problems pretty much went away upon using the older ps2dev9.irx included in the launchELF source. I can't say with absolute certainty but I think this may be a factor. All my builds used the older ps2dev9.irx module along with the old iomanX.irx module.

[dlanor]

Dlanor I too had problems with ftp when I was using 3.41c. I think those problems pretty much went away upon using the older ps2dev9.irx included in the launchELF source. I can't say with absolute certainty but I think this may be a factor.

The choice of I/O drivers certainly should have some effect, but I don't think that it's so easy to solve. I'm afraid the problem is more general than that.

In one of my latests tests I placed the same collection of 18 ZIPs onto the USB drive using th ePC, and tested the integrity of all the ZIPs to 100%. Then I moved the USB drive to the PS2 (after using the eject function on the PC of course, for safe removal). On the PS2 I then used LaunchELF to copy the collection folder from mass: to HDD, erasing the original on mass: afterwards. Then I copied that folder back and forth between different HDD partitions several times, each time making sure to 'copy' the latest created one, so as to allow maximum risk accumulation. Finally I copied the folder back to mass:, exited from browsing mass:, and moved the USB drive to the PC again. On the PC I then tested the integrity of the ZIPs again, and now one of them had been damaged (one subfile of one ZIP had a bad CRC, and a damaged header).

We have some basic problems with some of our IO drivers, and these definitely affect more than one of them. NB: By 'we' I don't mean just us who work on LaunchELF, but the entire PS2DEV community. (As reported earlier, the same problems exist with ExecFTPs and other non-LaunchELF stuff.)

All my builds used the older ps2dev9.irx module along with the old iomanX.irx module.

As you know, I used the PS2SDK version of ps2dev9.irx in the latest build, which may have been a mistake for the present. I'll repeat my tests with a recompiled version using the old irx, and if that improves my test results I'll release that as v3.41e. (If it does fix things, such a fix alone is worth a new release.) But if it doesn't work out that way either, then I'll just post a notice about this instead.

Anyway, I hope you realize that going with old driver versions is only a temporary solution, and that the PS2SDK versions are our ONLY hope of any longterm solutions to these problems. (Most old stuff has limitations we don't want to accept, and in any case such drivers won't adapt to future needs.)

Best regads: dlanor

[E P]

Anyway, I hope you realize that going with old driver versions is only a temporary solution, and that the PS2SDK versions are our ONLY hope of any longterm solutions to these problems. (Most old stuff has limitations we don't want to accept, and in any case such drivers won't adapt to future needs.)

Best regads: dlanor

Oh yes I agree I also wish iomanx.irx didn't have that issue but perhaps there is a way to get around it by changing a few things in the source. It's just too bad that LaunchELF is built primarily on an older sdk and the old libito.

Oh and you left one of my minor changes out of your releases:
-Added config name to both failure messages (Name of config that failed to load/save).

It's a slight modification in config.c. It's in that package name pre-c, which I had posted a few days ago. You're still using the older config.c from version b. Thanks

[dlanor]

Oh yes I agree I also wish iomanx.irx didn't have that issue but perhaps there is a way to get around it by changing a few things in the source. It's just too bad that LaunchELF is built primarily on an older sdk and the old libito.

I'm glad we agree on this, and changing to the newer lib variants is something that I do plan on doing. Eventually ALL libs used should be those of the latest PS2SDK, even if that means having to help changing them.

Oh and you left one of my minor changes out of your releases:
-Added config name to both failure messages (Name of config that failed to load/save).

Sorry, I just forgot about that one. I'll add it in next time, but I don't want to delay a bugfix release on that account.

It's a slight modification in config.c. It's in that package name pre-c, which I had posted a few days ago. You're still using the older config.c from version b. Thanks

I have the file, and I promise to include the fix next time.

Now for the new release v3.41e, changes.txt says this:
-Changed ps2dev9.irx module from present PS2SDK to an older version, to achieve much
improved reliability for the host: interface. All other functionality is unchanged.
NB: Matrix Infinity Dev.2 boot again requires the non-packed ELF for this version.

This short description really needs some clarification. I spent several hours testing this version with the same ZIP transfers as before (so I could test CRC32 integrity). The results were not quite as expected. I still got errors with the built-in ps2ftpd, and also with ExecFTPs and PS2OS FTP when I launched them (expected, as they load their own modules), but the big surprise was what happened to host:...

When I used host: to transfer those same ZIPs directly to a folder on mass: I managed to do it completely without errors (tested with WinRAR on my PC). So I erased all those files and tried it once more, in another PS2 boot session, and got the same error-free result again. I'm not saying it's perfect, and I don't believe it is, but it's a hell of a lot better than those FTP clients, which give some errors every time.

But we need to consider WHY those errors occur, and why they ceased for host: with this change. Changing ps2dev9.irx obviously affects any device based on the network adapter, but why not the same improvement for FTP as for host: ? I believe the answer is that host: can transfer stuff directly to mass: instead of HDD (unlike FTP), and transfers to mass: do NOT use fileXio and iomanX, which are used for HDD.

So for maximum safety, aim FTP at memory card (no use of fileXio/iomanX), and use 'host:' for transfers either to memory card or mass:, but be wary of any transfers aimed directly at HDD.

And remember (though it is VERY hard to accept) that some of my experiments show that corruption can occur with any copying involving HDD. I don't think this is tied to any of the transfer programs used, but derives directly from the driver modules used by everyone...

Clearly more research is needed to clarify those problems, but for the moment all we can do is to be careful, and keep backups of everything important on our PCs.

Best regards: dlanor

[E P]

Hum that's interesting perhaps a partial reset to clean up some modules would get around this issue? I'm pretty sure it has to be done in loader.c, which makes it difficult to make it optional. KeyLauncher resets IOP right before the execution of any ELF or at least that's how I see it in its source. I tried to do something similar but I couldn't get it to work right in my testing.

One example where a partial reset could be beneficial:
Crazyc released a hack to I think was the ps2atad.irx module. This change prevents the hdd from powering down after 20 minutes of no use. This is good for some games where lockups can occur when a game tries to start the hard drive back up. I had this mess up only happen to me once thus far but the hack is useless for those who keep hdloader on a hdd partition and use LaunchELF. This is of course because the hdd partition drivers have to be loaded to execute the elf. The modified module is never used because LaunchELF has alreadly supplied it's own hdd modules.

Anyway about coruption with ExecFTPs, I couldn't help but overhear that you used version .69. You do know that it doesn't support large hard drives? I had mentioned this before in other instances. You should be ok though if you're loading it with LaunchELF and the program is on a hdd partition. LaunchELF would supply its own modules thus bypassing the older ps2atad.irx one.

I have had problems with host support maybe its my version of ps2client (Note: using Lukasz Bruun's as part of the cygwin toolchain). I couldn't get it to read my C: and E: drives from elflist.txt. It keeps telling me "This file isn't ELF". I got it to read my floppy drive and CD drive but once I go back a directory it goes from A:\ to A: and says "This file isn't ELF" when I try to open it. Maybe it's a Windows XP thing I have no idea. Although I got it to run "C:/WinZip/Unzipped/Ps2exec/BOOT.ELF" on several instances that was in my elflist.txt file. I'll have to see if I can get ps2client running on my 98 machine but it doesn't have cygwin installed.

edit: nevermind I got a newer version from PS2World that came with a GUI tool for loading ELF's. I guess I need to compile my own ps2client soon.

So far I'm amazed by what true host: support can do. I'm sold dlanor.

[HypERSoniC]

EDIT - no i was kind of right after all...

[HypERSoniC]

I have had problems with host support maybe its my version of ps2client (Note: using Lukasz Bruun's as part of the cygwin toolchain). I couldn't get it to read my C: and E: drives from elflist.txt. It keeps telling me "This file isn't ELF". I got it to read my floppy drive and CD drive but once I go back a directory it goes from A:\ to A: and says "This file isn't ELF" when I try to open it. Maybe it's a Windows XP thing I have no idea. Although I got it to run "C:/WinZip/Unzipped/Ps2exec/BOOT.ELF" on several instances that was in my elflist.txt file. I'll have to see if I can get ps2client running on my 98 machine but it doesn't have cygwin installed.

if you need me to test anything, im on a linux system and have the latest ps2client compiled from source.