unofficial LaunchELF v4.30

[dlanor]

Like the subject says, I've just released uLE v4.30, in the first post of this thread as usual.

LaunchELF v4.30 (2008.09.30)
-Fixed HDD mountpoint issues in HddManager (due to changed methods from v4.23)

This release fixes some problems with HddManager usage of uLE v4.23-v4.29, which caused several operations to fail. The most obvious one is that 'user' type partitions with standard PFS filesystem were instead indicated as 'Inaccessible' when selected (due to failed mountpoint usage).

Best regards: dlanor

[kevstah2004]

Originally Posted by dlanor

How could I possibly do that when some of that equipment never was sold in this country ? (Sweden)
Import maybe?
AFAIK the PCMCIA stuff was never sold in this country and that goes for NTSC network adaptors as well (I also think Sony forbids such cross-region sales). Even PAL network adaptors are now nearly impossible to find, since they are long since out of stock with all retailers here.
Fck Sony
I know I found it near impossible to find one too.
However, I am not aware of anything that would make the NTSC/PAL network adaptors bound to any particular console region. I suspect that both types can be used on consoles of any region. (Though I don't myself have the hardware to test this.)

Best regards: dlanor

The only difference I know is the NTSC adapter had an extra phone line cable port for 56K internet so maybe the PCB layout is completely different.
Also does it make any difference using an official 40GB HDD
or doesn't that matter because uLE uses it own drivers? is the ps2 compelled to liking 40GB HDD's better?, any thing lower or higher it doesn't like? also is the original HDD driver file system only set to read 40GB HDD's?
Thanks! for recognizing and solving the issue your work is greatly appreciated

[tonybologna]

Originally Posted by dlanor

Like the subject says, I've just released uLE v4.30, in the first post of this thread as usual.

LaunchELF v4.30 (2008.09.30)
-Fixed HDD mountpoint issues in HddManager (due to changed methods from v4.23)

This release fixes some problems with HddManager usage of uLE v4.23-v4.29, which caused several operations to fail. The most obvious one is that 'user' type partitions with standard PFS filesystem were instead indicated as 'Inaccessible' when selected (due to failed mountpoint usage).

Best regards: dlanor

Thanks dlanor!

[atreiu]

Hi, I have a Zen Iridium Modchip and I can't start LaunchELF as BOOT.ELF.
I read about this problem but I didn't find a solution.
Is there something I can do?
Thanks

[slicer74]

What is ur setup, dows this chip support DEV1, DEV2 ?

[atreiu]

This chip supports DEV1.
I copied LaunchELF as BOOT.ELF in the BOOT folder of MC0.
If I try with SMS (renamed as BOOT.ELF) it works!
My PS2 is V9

[slicer74]

Maybe u have to hold a button for DEV1.

[atreiu]

yes I hold it!
but it's strange because if I use SMS as BOOT.ELF it starts while if I use LaunchELF it doesn't...

[slicer74]

U sure that u rename exactly BOOT.ELF and u place that file in the BOOT folder ?
Try with boot.elf

What happens then when u set ule as boot.elf in mc0/boot and holding the correct button ?

[atreiu]

i have a black screen.
i'm sure it's correct because if I use the same memory card in another PS2 with another modchip it works!

[Berion]

Many modchips use different file names for booting ELFs (case sensitive).

• mc0:/BOOT/BOOT.ELF
• mc0:/\BOOT\BOOT.ELF
• mc0:/MATRIXTEAM/MANAGER/ELF

[atreiu]

it seems an iridium zen problem's because sms renamed BOOT.ELF and placed as mc0:/BOOT/BOOT.ELF works.
And also HDloader.
Only LaunchELF doesn't work

[slicer74]

Where have u take ur ULE.

[JNABK]

Are you using the latest version of uLE? Are you using the compressed BOOT.ELF or the uncompressed one?

Seems very odd other .ELF files boot, but uLE doesnt.

[slicer74]

Snif, snif, it smell no good ELF file.

[atreiu]

I downloaded the last uLE from this post but I think it's an Iridium Zen problem...

[donsanto]

first of all best regards to all are involved in developing of ule ....
great work dudes ....
i found a bug in ule .....
when i try to rotate the image in left or right it seems to be all ok ...
but when the image rotating up ''reverse'' the display print a strange lines and artifact ....
i browse the pic's on my hd usb mass storage cd dvd mc and the result is equal

this bug appears after the version 4.12 ....


ciao a tutti and sorry for my bad english .....

[Berion]

Proposition for adding parameters support:

Maybe stupid idea but I dreaming of replace RadShell on my mc.

[dlanor]

Originally Posted by donsanto

first of all best regards to all are involved in developing of ule ....
great work dudes ....
i found a bug in ule .....
when i try to rotate the image in left or right it seems to be all ok ...
but when the image rotating up ''reverse'' the display print a strange lines and artifact ....
i browse the pic's on my hd usb mass storage cd dvd mc and the result is equal

This is weird, but it appears that the only effect is some temporary screen garbage, as it is even possible to continue rotating to the next 90 degree step, and that is then displayed correctly.

To be honest, this is not something I will even attempt to fix.

When Polo35 contributed the JpgViewer code for uLE he had added lots of bells and whistles beyond the simple Jpg skin ability we had asked for. And that is the only reason why the JpgViewer subprogram even exists, as we felt it would be a shame not to use what he had made for us. The fact that it is no longer possible to turn a picture upside-down has no real bearing on the normal use of uLE...

this bug appears after the version 4.12 ....

That is very odd, as it should have existed earlier too.
I am not aware of any JpgViewer changes for that particular version.
All recorded changes from v4.11 to v4.12 concerned networking.

The changes between v4.12 and v4.13 were more extensive, but contained nothing intended to change the JpgViewer, though that could be a side effect of the restructured lib usage. (Still very odd though.)

Still, you are correct as it does work correctly in v4.12 and older versions, so I guess the problem must have something to do with our restructured lib methods (which we will not abandon).

But like I said above, this issue is not of such a nature that I consider it worthwhile to work on, though i will naturally fix it if I 'stumble' on the cause for it in other work.

Best regards: dlanor