unofficial LaunchELF v4.40

[E P]

OK, here is the unofficial version of LaunchELF. (Note: It's based off Mirakichi's source to LaunchELF v3.41)

Some of you may have no idea what this is all about, so here is a link to a brief tutorial on uLaunchELF (aka: uLE).

Changes: Unofficial LaunchELF releases by EP + dlanor

LaunchELF v4.40 (2009.09.08)
-Reimplemented 'paddata', to allow button combos independent of debounce
-Merged in a new mcman module by jimmikaelkael, fixing the FTP server bug

LaunchELF v4.39aa beta (2009.08.24)
-Fixed a weird 'strcat' bug that used to break TextEditor 'Save As...' pathname
-Suppressed FileBrowser display of garbage filesize + timestamps for ".." links
-Rearranged init of pad & CDVD modules to avoid problem detecting pad mode
-NB: The above fixes an old problem with pad running amok with disc-control ON

LaunchELF v4.39z beta (2009.04.09)
-Fixed a bug from previous beta v4.39y preventing access to MC folders having a 'hidden' attribute bit set.

LaunchELF v4.39y beta (2009.04.06)
-Merged in new MCMAN and MCSERV modules by jimmikaelkael
-Modified FileBrowser to allow renaming of all MC file/folder objects
-Fixed "DEVICE_UNITS" again, to really allow 10 USB drives/partitions in FTP

LaunchELF v4.39 (2009.02.17)
-Updated gsKit and existing source files to SVN rev 1470.
-Upgraded USBHDFSD to SVN rev 1534 by radad.
-Updated ps2ftpd and existing source files to SVN rev 587.
-Changed "DEVICE_UNITS" from 4 to 10 for the newer USB driver.
-Altered an old workaround to allow multiple USB devices to show up properly within FTP clients.

LaunchELF v4.38 (2009.01.22)
-Fixed a bug affecting two of the timeout functions changed in v4.37
-Modified CDVD tray checking for browsing to cdfs:

LaunchELF v4.37 (2009.01.21)
-Changed VSync-based timeouts to use Timer() instead, to eliminate PAL/NTSC variations and cure an old bug causing uncontrolled button repeats
-Changed libcdvd tray checking, to eliminate a case of FileBrowser freezing

LaunchELF v4.36 (2009.01.19)
-Fixed 'disc control' bugs in FileBrowser and JpgViewer browser
-Improved recognition of disc types, displayed in main menu. ESR discs are shown as "ESR DVD (off)" if ESR driver needs to be activated to access disc contents, but as "ESR DVD (on)" if no driver activation is needed (if already running, or when used with a modchip)
-Upgraded USBHDFSD of uLE to SVN rev 1516 by radad, fixing a bug in FAT16 usage

LaunchELF v4.35 (2009.01.17)
-Merged in the latest USBHDFSD version by radad (SVN rev 1513) to further improve compatibility

LaunchELF v4.34 (2009.01.13)
-Fixed some bugs that could sometimes prevent 'Left'/'Right' buttons from activating elf launches defined by user for those buttons
-Changed to use fioGetstat instead of fioDopen+fioDclose to scan for USB drives
-Restructured main menu event loop and centralized GUI screen redraws to it
-Changed from dynamic to static font buffer allocation (as it's always needed)
-Modified USBHDFSD to eliminate an irritating and unnecessary delay
-Added rom0:ROMVER content to "MISC/Debug Info" screen (shows PS2 bios version)

LaunchELF v4.33 (2009.01.12)
-Raised a debug constant which limited v4.32 USB_mass drives to 4 instead of 10
-Added a horizontal offset to the "About uLE" display

LaunchELF v4.32 (2009.01.11)
-Upgraded USBHDFSD to SVN rev 1503 by radad, which cures the bug causing large-file corruption in the previous uLE release, and also adds support for multiple partitions (each accessed as a separate mass?: drive) and extends the hotplugging limits (max 5 simultaneous devices with a total of max 10 partitions). Exceeding the limits will cause no harm, but the additional devices/partitions will not be accessible.
-Upgraded USBD to SVN rev 1494 by radad, making uLE "mass:" identical to that of old applications when using multiple USB drives in uLE.
-Improved MISC/PS2Disc subprogram to support launch of either DVD-Video disc or ESR-patched disc (but might not recognize disc type if a modchip is active)
-Added "ESR elf" entry to "Startup Settings..." configuration menu
NB: If no ESR elf has been configured a default of "mc:/BOOT/ESR.ELF" is used

LaunchELF v4.31 (2009.01.04)
-Added new "MISC/About uLE" subprogram, displaying a program credits screen
-Enhanced FileBrowser to support multiple hotplugged USB mass drives
-Upgraded usbhdfsd to SVN rev 1490 by radad, for multiple USB drive support. Note that this may require running the new "setup.sh" script, for those who wish to compile uLE themselves. (Or use the new script "upgrade_usbhdfsd.sh".)
-Fixed various issues with TextEditor (inability to insert CRLF at CRLF etc)
-Fixed a partition unmounting issue, that sometimes caused non-fatal failure of the TextEditor to show proper partition contents when browsing for a text file

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

LaunchELF v4.29 (2008.09.25)
-Fixed a new bug in the CNF parser, introduced when fixing the previous one. That bug cause the character after the equal sign in a variable assignment to be skipped. This should not matter for uLE or FMCB CNF files, where that character will always be a space. But it does matter when parsing SYSTEM.CNF for PS2 discs, since those files sometimes have no space in that position. This caused some discs to fail booting, both with the uLE MISC/PS2Disc command, and with the disc launcher of FMCB.
-Minor changes to CDVD checking
-Added DVD-Video launch capability for MISC/PS2Disc

LaunchELF v4.28 (2008.09.07)
-Fixed a bug in the CNF parser, preventing variables from being accepted when not separated by any other character from the '=' character preceding its value string.
NB: Since uLE always uses a space separator in creating CNF files, this bug has never affected CNF files created by uLE, but only CNF files edited by 'hand' and the SYSTEM.CNF files of game discs, causing some of those not to work with the PS2Disc command of uLE. So try again now, with games that failed earlier.

LaunchELF v4.27 (2008.09.04)
-Added ability of MISC/PS2Disc subprogram to also boot PS1 discs
(Based on ideas and examples contributed by jimmikaelkael @ psx-scene)

LaunchELF v4.26 (2008.09.02)
-Fixed a bug preventing detection of PAL/NTSC mode on some slim PStwo units.
(Now reads "rom0:ROMVER" instead of using gsKit's function "gsKit_detect_signal")

LaunchELF v4.25 (2008.08.19)
-Fixed a bug preventing proper updates of IPCONFIG.DAT (open file)
-Fixed a bug preventing Cancel command from working in some file selections
-Modified Skin CNF saving to allow selection of existing filenames
-Corrected cursor positioning for LNG translated network settings

LaunchELF v4.24 (2008.08.15)
-Fixed a bug preventing unmounting of VMC devices for some cases

NB: Though VMC usage should no longer be able to interfere with normal HDD access, it may still lock up in some VMC operations. This VMC driver is still to be considered a beta version, though the uLE release is otherwise stable. You should therefore not use VMC operations without backup of each VMC file used.

LaunchELF v4.23 (2008.08.15)


-Fixed a bug that made it possible to select uLE configurable files (drivers, skins, etc) on VMC
-Fixed a bug preventing psuPaste from restoring PSU files to gamesave folders on VMC
-Restructured the HDD mountpoint usage to eliminate conflicts between VMC and other browser needs. Conflict should now only be possible between ftp server and VMC browsing, so these activities should never be combined (user responsibility)
-Enforced 32 character limit for vmc object names in FileBrowser (same as on MC)
-Modified VMC mounting to last only throughout a FileBrowser session. Leaving the FileBrowser automatically unmounts any mounted VMC files
-Fixed a VMC driver bug causing it to consider a VMC to be mounted even after a failure to do so due to unformatted content

LaunchELF v4.22 (2008.08.14)
-Fixed various bugs that could crash the RunELF function when called with improper device names or paths to non-ELF files. From now on on real launch attempts are made only after accessing the file and checking its ELF header.
-Fixed a bug dealing with SYSTEM.CNF files for the "MISC/PS2Disc" subprogram (string termination for a file buffer from malloc was made one byte beyond the allocated area)
-The above changes also fix the inability of the previous beta to launch ELFs from virtual memory cards.
-Made a new revision of 'ps2client_for_uLE'. This rev8 fixes a problem with file open modes that prevented the new VMC driver from mounting VMC files over network.

NB: Mounting VMC files over network is not recommended at this stage, since it is very slow. The VMC driver will need a new caching strategy to make network use practical.

LaunchELF v4.21a beta (2008.07.21)
-Embedded virtual memory card driver by Polo35 and ubergeek42, and implemented its use in FileBrowser. Note that vmc0: and vmc1: will not be shown in FileBrowser until some VMC file has been mounted, using new commands in the R1 menu of FileBrowser.

LaunchELF v4.21 (2008.07.20)
-Changed FileBrowser icon colour assignment to use Color5, Colour6, and Color7 for folders, ELF files, and generic files, respectively
-Changed default colour values for FileBrowser icons to be yellow, green, white, used for folders, ELF files, and generic files, respectively. This change also affects HddManager pie charts as they use two of the same colour definitions

summary of prior changes:

LaunchELF v3.41a (2005.05.30) - LaunchELF v4.20 (2008.07.17)
-Many other tweaks and improvements (see "changes.txt" of latest release)
-Implemented an icon mode for the FileBrowser
-Implemented "Load Skin CNF" and "Save Skin CNF" commands in "Screen Settings". (more -Implemented uLE-related file selection.
-Major updates to the source package structure and lib usage, reverting to avoid new bugs
-Added support for GUI-like skin JPG for alternative use in main launch menu.
-Enforced filename limits: 32 char for MC, 256 char for other devices
-Updated to use the current ps2sdk changes added by jbit.
-Implemented FileBrowser command "New Icon" (for Sony-style MC icon definitions)
-Improved host: to allow display of file sizes and timestamps in FileBrowser
-Switched to using networking modules by EEUG
-Changed FileBrowser to use denser text for long file/folder names
-Improved browser of JpgViewer to include new features of FileBrowser (PathPad etc)
-Modified MC attribute handling for PS1 gamesaves
-Improved HddManager unmounting
-Added new "Debug Info" popup to "MISC"
-Extended FileBrowser from 2 display modes to 3
-Extended FileBrowser from 2 sort modes to 4
-Added 8 new character definitions to "font_uLE.c", for use as 4 double-width D-Pad button characters
-Added new popup to FileBrowser, to control new display and sort modes. (opened by L1 button, as it obsoletes the old Title ON/OFF functionality)
-Added new LNG definitions to cover all new features
-Modified initialization of uLE to improve compatibility with SwapMagic ELF launching. These changes allow uLE to find its CNF in the same folder as the ELF when launched on mass: by SwapMagic, despite the incorrect path passed in argv[0] ("mass0:\SWAPMAGIC\"). Note that this is NOT the same modification used in earlier betas, which caused other bugs. This method does not involve IOP reset, and should therefore be bug-free. That has been verified both for exploit booting and the 'back to browser' feature of SMS, which were both bugged by the old method.
-Shortened the LNG(Modes) lang.h definition of earlier betas to LNG(Mode)
-Extended HddManager size limit for logical partitions to 128 GB
-Corrected a bug in HddManager sizeSelector tooltips (missed using an LNG definition)
-Modified HddManager sizeSelector to use L2/R2 to step partition size -/+ 10 GB
-Modified tooltips for HddManager sizeSelector to include new features
-Merged loadable font system (by Polo35)
-Replaced old usb_mass driver with embedded "usbhdfsd" (by Herben)
-Patched gsKit to prevent 'lost' rectangle plots in non-interlace mode
-Improved timestamp support in FileBrowser
-Merged additional font characters (by Polo35)
-Increased font resolution to 8x16 and font size to 256 characters
-'Paste+Rename' pseudo renaming command
-PSU gamesave support
-gsKit adaption (by Polo35)

-JpgViewer (by Polo35)
-TextEditor (by Polo35)
-HddManager (by Polo35)
-Improved CNF handling functions
-Abortable Paste/mcPaste transfers
-USB Keyboard support
-Rename support for PS1 MC files
-User defined launch key titles
-PathPad array for user defined browser shortcuts
-Option for opaque VS transparent popups
-Skin 'Brightness' control
-Improved resolutions 640x512(PAL) and 640x448(NTSC) (by Polo35)
-Full support for NTSC and PAL modes for any console type
-Event driven menu handling
-Menu Frame option
-Menu Titles
-JPG 'skin' implementation (by Polo35)
-Support for 'slim' PStwo using IDE HDD
-ELF loader compatibility improvements
-progress reports when copying files
-capability to write files to a PC used as host: device
-mcPaste for safe backup of MC gamesaves
-IOP reset
-multiple CNF config loading
-key mapping to swap X and O associations
-FTP server and PS2NetFS support through key config MISC/PS2Net
-host: device support using ps2client
-alternate sort order for showing titles: L1=sort_by_title, L2=sort_by_folder
-network settings menu for changing IPCONFIG.DAT settings
-new CNF format that allows for easier file editing
-ability to copy timestamps and attributes of saves from one PS2 mc to another
-special preserved attribute set on mc saves when restoring saves from other devices
-selectable USBD.IRX module
-various changes and bug fixes to many different things

Detailed change log can be found in changes.txt file.

If you find errors with this build, please report them here. Thank you.

Special thanks to: EP, dlanor, kthu, Slam-Tilt, sincro, and Polo35 for all their contributions.
And an especially big thank you to: Mirakichi's excellent program LaunchELF.

Documentation for uLaunchELF can be found in this thread at ps2-scene and the Wiki here.

NB: The ISO files provided in the ZIPs below are minimal, containing only the files needed to launch the elf properly (sizedummy + SYSTEM.CNF + elf). So you should also download the main release file (no ISO in the name), to get the source code and some documentation, including the heavily commented example CNF file.

[dick_onion53]

The two configs is a really great idea... congrats...

[peeman]

can you add a nice GUI like KeyLauncher?

[Agent_underfire]

yeh keylauncher has a beautiful interface

[MISTA]

MISTA

I think il stick with v 3.33 cos its got umcdr, as i dont have a chipped (modded) machine, if i want to get mp3`s etc on the HDD i use umcdr.

I carnt remember if the later versions have it... i dont think so thats why i use the old one.

A gui would be a good idea, maybe a .jpg?
get ppl to send in a pic?

No music though. (shudders) menu music is always BAD!

KiIT
1 Satin silver ps2 (with the dreaded click!!) Launch v 3.33 (cos of umcdr) HDLoader (latest)
1 Black PS2 no Drive at all
1 Black PS2 with dodgy laser (wont read nothing)
2 Bust pads

[_zaphod_]

if you have draks cdvd.irx then you can create umcdr-enabled builds, if youi don' then you can't. tryign to fork from 3.33 won't help one bit.

however such builds are for personal use only, and not for distribution.

[dlanor]

I most strongly advise AGAINST any fancy graphics for LaunchELF.

Remember that this is an application that will often be used from memory card, so it is imperative to keep its size down. Adding a fancy JPG background would be possible, but it would probably magnify the size by a factor of 10 or worse !!!

The same phenomenon is noticeable with HDL too, where those with supersimple BMPs pack to a size of appx 155KB, whereas those with complex BMPs pack to a size of appx 1300KB, with even worse results for some of them. The factor would be larger with LaunchELF however, as the added picture would be a larger percentage of the payload.

Summing up: If any graphics are added, keep them simple, to minimize size.

Best regards: dlanor

[<G>]

if people are going to cry so much then why not just simply use libpng or libjpg and let people make simplistic backgrounds for it. This way you dont have to worry about the interface yourself and people can beat themselves up making skins if they want them so bad.

[c0d3x]

i think it's not so simple G

[<G>]

Originally Posted by c0d3x

i think it's not so simple G

i have tons of imaging tools that will let you view files outside of the elf. I used these to test various images on the ps2 for user interfaces. How could it be "not so simple"?

[retro]

G use the sorce and do it then. me and the rest of the "nice gui viners" would realy apriciate it.

[<G>]

i never said i have the source to these UI testing tools now did i?
I just said its possible. But now we are getting off subject. EP and dlanor have done a terrific job so far. Adding a better UI is completely up to them and not us. Lets not take the heat away from their fire.

[dlanor]

Originally Posted by E P

changes:

LaunchELF v3.41a
-Added reset IOP on start as a toggle (Note: off by default).

I can verify that this works fine, and completely cures the bug of not being able to access USB files properly from a LaunchELF launched by LaunchELF. (Like when using the old 'trick' for extra menus.)

Unfortunately it does not fix all the problems involved with running LaunchELF from USBadvance (total failure) or HDLoader. In the latter case it seems to work, but something is wrong, so that some APPs can't be launched, or will have problems after launch. (For example: A second instance of HDL will fail to launch any ISO.) I believe those problems are due to things done by USBadvance and HDLoader which can't be undone just by an IOP reset.

So the IOP reset is really OK now, though it alone wasn't sufficient to fix all the things we had hoped.

-Added dlanor's fix for the elf launching bug.
-Changed text info from "away" to "subtract" in the menus because it's more proper to say add or subtract than add or away.
-Changed text for setting "INIT" to "INITIAL SCREEN SETTINGS".

Those changes are all OK.

-Added support for two total configs press d-pad left or right to switch between configs. (Note: the two configs are LAUNCHELF.CNF and LAUNCHELF1.CNF).
-Added two menus below the Select config item - left and right to load configs via menu.

Something has been messed up in initial loading of CNFs. If no CNF is found in the same folder as the LaunchELF ELF, then the folder 'mc0:/SYS-CONF' should be used for loading the CNFs instead, but that never happens if the ELF was loaded from another device than 'mc0:'. (tested with 'mass:' and 'hdd0:')

'mc0:/SYS-CONF' is set up as new path for CNF loading, but the CNFs in it are NOT loaded. Instead I see an empty menu, until I press <Left> or <Right> to force the CNFs to be loaded. When I do that the correct CNF does get loaded, but without affecting either IOP reset (so no cure for the USB bug) or the screen positioning (and my set needs non-default offsets).

Note that this is more serious than it seems, as it affects all cases where LaunchELF is run from the HDD, since it can never find CNFs on HDD. This also means that the bug affects everyone who uses LaunchELF for Dev.2 booting. (Which I started doing yesterday, using the new Matrix Infinity firmware.)

Another variation on this, which is less serious but rather strange, is that if the LaunchELF ELF is started from a folder on 'mc1:' and without any CNFs beside it, then the CNFs in 'mc1:/SYS-CONF/' will be used (if present), rather than those on 'mc0:', and the default path for CNF switching will also be set up as 'mc1:/SYS-CONF/'. This I can live with, as it may be debatable if the folder on 'mc0:' is more valid than the one on 'mc1:'. But it's still odd...

Well, that's all I've found so far. I'll check some more and see if I can come up with some constructive fixing advice, rather than just error reports.

Best regards: dlanor

[_zaphod_]

Umm, try using mode 3/kill hdl after launch for launch elf when you launch it from hdloader. then the reset will wipe the wrapper and it shouild work perfectly.

[Powder7891@hot]

LOL that would be funny if mode 3 fixed every thing lol

[dlanor]

Originally Posted by Powder7891@hot

LOL that would be funny if mode 3 fixed every thing lol

Sure it would be, but that is obviously not the case.
(I think you already realized this, unlike _zaphod_)

Naturally I made my tests both with and without mode 3 active, so as to observe any differences. But no differences were visible. The problems I mentioned occur in both cases. Like I said, a simple IOP reset does not restore the entire console to normal boot conditions, so even with such a reset it is still not advisable to run LaunchELF via HDLoader. It can work for some things, but not for everything.

Best regards: dlanor

[E P]

Ok, about custom backgrounds for launchELF I don't really have a need for such a thing. I also wouldn't want it bloating the elf if it were placed inside the elf. I'm probably not the one who could implement such a thing anyway no real graphics programming experience. However, if I ever found a way to add external graphics file loading I would probably add it. That way the program would either use the background file if its there on startup, or operate like it currently does without one.

Originally Posted by dlanor

I can verify that this works fine, and completely cures the bug of not being able to access USB files properly from a LaunchELF launched by LaunchELF. (Like when using the old 'trick' for extra menus.)

Unfortunately it does not fix all the problems involved with running LaunchELF from USBadvance (total failure) or HDLoader. In the latter case it seems to work, but something is wrong, so that some APPs can't be launched, or will have problems after launch. (For example: A second instance of HDL will fail to launch any ISO.) I believe those problems are due to things done by USBadvance and HDLoader which can't be undone just by an IOP reset.

So the IOP reset is really OK now, though it alone wasn't sufficient to fix all the things we had hoped.

Those changes are all OK.

The IOP reset is probably not complete I just used the source from another program. I also didn't include the IOP reset just prior to launch do to problems with my tests with EXECFTPs. So IOP reset currently only resets on startup if enabled.

Originally Posted by dlanor

Something has been messed up in initial loading of CNFs. If no CNF is found in the same folder as the LaunchELF ELF, then the folder 'mc0:/SYS-CONF' should be used for loading the CNFs instead, but that never happens if the ELF was loaded from another device than 'mc0:'. (tested with 'mass:' and 'hdd0:')

'mc0:/SYS-CONF' is set up as new path for CNF loading, but the CNFs in it are NOT loaded. Instead I see an empty menu, until I press <Left> or <Right> to force the CNFs to be loaded. When I do that the correct CNF does get loaded, but without affecting either IOP reset (so no cure for the USB bug) or the screen positioning (and my set needs non-default offsets).

Note that this is more serious than it seems, as it affects all cases where LaunchELF is run from the HDD, since it can never find CNFs on HDD. This also means that the bug affects everyone who uses LaunchELF for Dev.2 booting. (Which I started doing yesterday, using the new Matrix Infinity firmware.)

Another variation on this, which is less serious but rather strange, is that if the LaunchELF ELF is started from a folder on 'mc1:' and without any CNFs beside it, then the CNFs in 'mc1:/SYS-CONF/' will be used (if present), rather than those on 'mc0:', and the default path for CNF switching will also be set up as 'mc1:/SYS-CONF/'. This I can live with, as it may be debatable if the folder on 'mc0:' is more valid than the one on 'mc1:'. But it's still odd...

Well, that's all I've found so far. I'll check some more and see if I can come up with some constructive fixing advice, rather than just error reports.

Best regards: dlanor

Congratulations you passed the test. I found this same bug in my testing but it later went away only to reappear again. I think it's only in the compressed version BOOTc.ELF. Could you please test the bigger, BOOT.ELF, file? It's strange because I first made a hack to fix this but later ended up removing the hack only to see the problem show up in the compressed version. I looked over the my changes many times but it seems that a quarter of the way through loadConfig(char *mainMsg, char *CNF) it somehow forgets what the passed CNF is. Strange indeed.

update:
Ok I think I see where it's going wrong it's in main.c. Now to try to find a workable solution.

[dlanor]

Originally Posted by E P

Ok, about custom backgrounds for launchELF I don't really have a need for such a thing. I also wouldn't want it bloating the elf if it were placed inside the elf. I'm probably not the one who could implement such a thing anyway no real graphics programming experience. However, if I ever found a way to add external graphics file loading I would probably add it. That way the program would either use the background file if its there on startup, or operate like it currently does without one.

I agree completely.

The IOP reset is probably not complete I just used the source from another program. I also didn't include the IOP reset just prior to launch do to problems with my tests with EXECFTPs. So IOP reset currently only resets on startup if enabled.

Yes, but I didn't expect any other form of IOP reset anyway.

Doing it for all launched ELFs would be dead wrong, so if it is to be implemented for them at all, then we must first come up with a way to flag which ELFs it should be done for. This means we must modify both the CNF format and the file browser, to allow for launches with or without IOP reset.

Congratulations you passed the test. I found this same bug in my testing but it later went away only to reappear again. I think it's only in the compressed version BOOTc.ELF. Could you please test the bigger, BOOT.ELF, file?

I have now tested the unpacked version too, and that does indeed work correctly, which gives some clues as to the cause of the problem. (more on that further down)

It's strange because I first made a hack to fix this but later ended up removing the hack only to see the problem show up in the compressed version. I looked over the my changes many times but it seems that a quarter of the way through loadConfig(char *mainMsg, char *CNF) it somehow forgets what the passed CNF is. Strange indeed.

I don't think anything is 'forgotten' really, since even after a failed initial CNF load I can still use <Left> or <Right> to load CNFs, and these are then loaded correctly from 'mc0:/SYS-CONF'.

update:
Ok I think I see where it's going wrong it's in main.c. Now to try to find a workable solution.

I can't inspect your source myself, but the fact that the unpacked version works right is a vital clue. The only difference between running a packed and unpacked ELF is that the packed one does not launch directly, but only after the unpacking stub has finished its work. That work may have left residual garbage in RAM which may affect the program if that RAM is then used for data structures that assume initial zeroes. My prime suspect would therefore be some variables and/or data structures that need explicit initialization.

Edit: I have just tested the unpacked ELF as Dev.2 boot.elf, and started this way it suffers from the same bug as discussed above. This pretty much nails down the cause as being initial RAM content, as the Dev.2 launcher probably leaves power-on garbage unchanged in RAM when starting the ELF.


My latest tests have also shown a different CNF handling bug, which happens identically with packed and unpacked ELF. When LaunchELF is started from 'mass:' with valid CNF files in the same folder, then those CNFs are used correctly for the initialization. But if I then press <Right> or <Left> to switch CNFs, then the CNFs will incorrectly be loaded from 'mc0:/SYS-CONF'.


Btw: I hope you can help me with a problem that hinders me from helping you better.
My Win32 PS2Dev setup lacks some of the standard tools, including that to apply diffs to sources. I assume this would be named 'patch.exe' (as per Linux standards). I haven't found a Win32 version outside of a full Cygwin install (which I won't do). I assume you have that tool, so could you please post it here for me (and possibly others with the same need) ?

Best regards: dlanor

[Danin]

I have a suggestion: Add a config option to swap X and O, PLEASE! I'm a US user, so I'm quite used to X being OK, and O being Cancel, and whatnot.. I already modified the code, as well as a few other tricks, but I can't build a Linux toolchain (I primarily use Linux.) due to lack of WORKING resources, and my Win32 toolchain refuses to compile libito....

[E P]

Originally Posted by dlanor

I agree completely.

Yes, but I didn't expect any other form of IOP reset anyway.

Doing it for all launched ELFs would be dead wrong, so if it is to be implemented for them at all, then we must first come up with a way to flag which ELFs it should be done for. This means we must modify both the CNF format and the file browser, to allow for launches with or without IOP reset.

Yeah I agree and I still don't plan on adding the other way of IOP reset. I think this is why KeyLauncher had problems.

Originally Posted by dlanor

I have now tested the unpacked version too, and that does indeed work correctly, which gives some clues as to the cause of the problem. (more on that further down)

I don't think anything is 'forgotten' really, since even after a failed initial CNF load I can still use <Left> or <Right> to load CNFs, and these are then loaded correctly from 'mc0:/SYS-CONF'.

I can't inspect your source myself, but the fact that the unpacked version works right is a vital clue. The only difference between running a packed and unpacked ELF is that the packed one does not launch directly, but only after the unpacking stub has finished its work. That work may have left residual garbage in RAM which may affect the program if that RAM is then used for data structures that assume initial zeroes. My prime suspect would therefore be some variables and/or data structures that need explicit initialization.

Edit: I have just tested the unpacked ELF as Dev.2 boot.elf, and started this way it suffers from the same bug as discussed above. This pretty much nails down the cause as being initial RAM content, as the Dev.2 launcher probably leaves power-on garbage unchanged in RAM when starting the ELF.


My latest tests have also shown a different CNF handling bug, which happens identically with packed and unpacked ELF. When LaunchELF is started from 'mass:' with valid CNF files in the same folder, then those CNFs are used correctly for the initialization. But if I then press <Right> or <Left> to switch CNFs, then the CNFs will incorrectly be loaded from 'mc0:/SYS-CONF'.


Btw: I hope you can help me with a problem that hinders me from helping you better.
My Win32 PS2Dev setup lacks some of the standard tools, including that to apply diffs to sources. I assume this would be named 'patch.exe' (as per Linux standards). I haven't found a Win32 version outside of a full Cygwin install (which I won't do). I assume you have that tool, so could you please post it here for me (and possibly others with the same need) ?

Best regards: dlanor

Well if you want to see what when wrong you don't necessarily need patch.exe as I included all the files I modified in the released archive. Sorry for the confusion, but I included both diffs as well as the actual src files I used to make the binary.

In order to compile LaunchELF, you will need libito 0.2.1, which is now available at Lukasz.dk and libcdvd located at ps2dev.org. It should compile fine even with an older sdk at least it did when I tried it once. All the talk I had with mcjules about makefile modifications with regard to EE_OBJS order is no longer a problem with litito 0.2.1. I guess I only need to see where iomanX.irx goes wrong.

If you still want patch.exe, do a search for patch-2.5.8-8.tar as that is the name of the package I'm using. I'm using a cygwin setup with ps2dev stuff via lukasz toolchain that takes up less than 300 megs all together.

I see exactly where the problem is now but I don't have a winning solution yet unfortunately.

[E P]

Originally Posted by Danin

I have a suggestion: Add a config option to swap X and O, PLEASE! I'm a US user, so I'm quite used to X being OK, and O being Cancel, and whatnot.. I already modified the code, as well as a few other tricks, but I can't build a Linux toolchain (I primarily use Linux.) due to lack of WORKING resources, and my Win32 toolchain refuses to compile libito....

I agree with this but I have become accustomed to it like MGS2 and MGS3. I haven't looked at it yet but this is definately something worth adding. To bad the main options menu is full now thanks to reset IOP.

Still I'm afraid if I make too many more changes it will become its own project, which I surely won't be able to completely maintain. The original author may see it as such and may not be willing to add some of these changes.

[dlanor]

Originally Posted by E P

Well if you want to see what when wrong you don't necessarily need patch.exe as I included all the files I modified in the released archive. Sorry for the confusion, but I included both diffs as well as the actual src files I used to make the binary.

Ooops! My mistake. I assumed that the diffs were needed, rather than just duplicating the changes in those source files.

In order to compile LaunchELF, you will need libito 0.2.1, which is now available at Lukasz.dk and libcdvd located at ps2dev.org. It should compile fine even with an older sdk at least it did when I tried it once. All the talk I had with mcjules about makefile modifications with regard to EE_OBJS order is no longer a problem with litito 0.2.1. I guess I only need to see where iomanX.irx goes wrong.

That's good to know. I don't see much reason for me too to start compiling it (except maybe to test some fix before posting here), but it is still an important step to gain compatibility with the latest libs.

If you still want patch.exe, do a search for patch-2.5.8-8.tar as that is the name of the package I'm using.

Thanks! That search string led me to several sites with Cygwin tools in separate packages, so now I found what I needed (both 'patch' and some other stuff).

I'm using a cygwin setup with ps2dev stuff via lukasz toolchain that takes up less than 300 megs all together.

Maybe I should look into that, but all deals I've seen so far talk of hours/days of DL for total size in the gigabytes. This followed by additional days of configuring stuff. And all that just to get a bad imitation of a Linux sýstem, which I don't even like in original form. (I've had it installed on older systems, and have also tried an old Cygwin version which used 1.5 GB...)

Perhaps later versions of Linux/Cygwin have changed, but until I see it I remain sceptical. My present setup works fine, anyway, except for the lack of a few tools (as mentioned).

I see exactly where the problem is now but I don't have a winning solution yet unfortunately.

Ok, but I'm sure you'll think of something later. I too will have a look at the source, and let you know if I find any solutions.

Best regards: dlanor

[E P]

dlanor, yeah I agree I didn't want to deal with cygwin either but I took on the task as a challenge. You're right though it's huge unless you specify which parts to download and install. The default is large and I have more than 80 megs of installer packages from the installer. It took many days to figure out what I only needed for ps2dev. I still need to do a total reinstall someday to make sure I got everything straight. I did create a list somewhere of all the individual packages that are needed based off my prior use of another ps2dev win32 environment package.

The problem is with this in main.c main():

loadConfig(mainMsg, strcpy(CNF, "LAUNCHELF.CNF"));
if(setting->resetIOP){
Reset();
loadModules();
}

setupPad();

mcInit(MC_TYPE_MC);

I moved loadConfig further up so the config could be loaded to check whether to reset IOP - Reset(). Unfortunately, this causes a problem when LaunchELF can't find the config file (Note: Only happens when the config file isn't in the same location as the program). If it can't find the config file, it then tries to load from mc SYS-CONF which it can't because it needs mcInit(MC_TYPE_MC) which isn't called until later.

I tried some rearranging the other day but was unsuccessful. I will also say that setupPad() needs to executed prior to mcInit(MC_TYPE_MC) otherwise you loose pad functionality for LaunchELF in the Filebrowser. Also if you try this:

setupPad();
mcInit(MC_TYPE_MC);

loadConfig(mainMsg, strcpy(CNF, "LAUNCHELF.CNF"));
if(setting->resetIOP){
Reset();
loadModules();
}

setupPad();
mcInit(MC_TYPE_MC);

It will load but lock up before displaying the screen. It's as if setupPad isn't cleared after reset of the IOP thus a crash. However, it does read the CNF file before crashing. Maybe there is a way of freeing setupPad from memory if that's is the problem? Note: it works fine if reset() never happens.

[dlanor]

Originally Posted by E P

The problem is with this in main.c main():

loadConfig(mainMsg, strcpy(CNF, "LAUNCHELF.CNF"));
if(setting->resetIOP){
Reset();
loadModules();
}

setupPad();

mcInit(MC_TYPE_MC);

I moved loadConfig further up so the config could be loaded to check whether to reset IOP - Reset(). Unfortunately, this causes a problem when LaunchELF can't find the config file (Note: Only happens when the config file isn't in the same location as the program). If it can't find the config file, it then tries to load from mc SYS-CONF which it can't because it needs mcInit(MC_TYPE_MC) which isn't called until later.

I think I see. When the ELF is launched from MC, then the MC driver has already been initialized by the external launcher (whatever it is), and then there is no problem loading CNFs from MC, whether that is done from the same folder as the elf, or from /SYS-CONF/. But when the ELF is launched from some other device then the MC may be inaccesible, so the initial search for CNFs fails, and so does the default loading from mc0:/SYS-CONF/.

I'm still not entirely clear on this however. Why would something like that work differently for packed and unpacked elfs ???

I tried some rearranging the other day but was unsuccessful. I will also say that setupPad() needs to executed prior to mcInit(MC_TYPE_MC) otherwise you loose pad functionality for LaunchELF in the Filebrowser. Also if you try this:

setupPad();
mcInit(MC_TYPE_MC);

loadConfig(mainMsg, strcpy(CNF, "LAUNCHELF.CNF"));
if(setting->resetIOP){
Reset();
loadModules();
}

setupPad();
mcInit(MC_TYPE_MC);

It will load but lock up before displaying the screen. It's as if setupPad isn't cleared after reset of the IOP thus a crash. However, it does read the CNF file before crashing. Maybe there is a way of freeing setupPad from memory if that's is the problem? Note: it works fine if reset() never happens.

That is odd of course, as all drivers should be removed by IOP reset.
This could even be a bug in 'padman'. You'd better check that at ps2dev.org

But I find it equally odd that using mcInit before setupPad should kill pad functionality... I see no sensible connection here. Initializing MC access should have no effect at all on pad handling... Right?

Since the connection isn't sensible in any case, perhaps it isn't setupPad which is needed before mcInit, for the pad to work, but rather the call to mcInit after setupPad. Those cases are very similar but not identical, as the latter allows you to remove the topmost setupPad call from the code above, which could eliminate some conflict. It's worth trying anyway.

But I'm also unsure if repeated MC initialization is allowed, so perhaps this order is better:

	setupPad();
	mcInit(MC_TYPE_MC);
	
	loadConfig(mainMsg, strcpy(CNF, "LAUNCHELF.CNF"));
	if(setting->resetIOP){
		Reset();
		loadModules();
		setupPad();
		mcInit(MC_TYPE_MC);
	}

But for the case where reset is made, this will perform exactly like your ordering, so presumably this will then crash too...

Best regards: dlanor

[E P]

Originally Posted by dlanor

I think I see. When the ELF is launched from MC, then the MC driver has already been initialized by the external launcher (whatever it is), and then there is no problem loading CNFs from MC, whether that is done from the same folder as the elf, or from /SYS-CONF/. But when the ELF is launched from some other device then the MC may be inaccesible, so the initial search for CNFs fails, and so does the default loading from mc0:/SYS-CONF/.

I'm still not entirely clear on this however. Why would something like that work differently for packed and unpacked elfs ???

Yes this is pretty much how I see it. The only thing is though why did it take a packed elf to point this out to me? Unless parts of the memory are left out with the packed file or stub for the execution of the file.

Originally Posted by dlanor

That is odd of course, as all drivers should be removed by IOP reset.
This could even be a bug in 'padman'. You'd better check that at ps2dev.org

But I find it equally odd that using mcInit before setupPad should kill pad functionality... I see no sensible connection here. Initializing MC access should have no effect at all on pad handling... Right?

Since the connection isn't sensible in any case, perhaps it isn't setupPad which is needed before mcInit, for the pad to work, but rather the call to mcInit after setupPad. Those cases are very similar but not identical, as the latter allows you to remove the topmost setupPad call from the code above, which could eliminate some conflict. It's worth trying anyway.

But I'm also unsure if repeated MC initialization is allowed, so perhaps this order is better:

	setupPad();
	mcInit(MC_TYPE_MC);
	
	loadConfig(mainMsg, strcpy(CNF, "LAUNCHELF.CNF"));
	if(setting->resetIOP){
		Reset();
		loadModules();
		setupPad();
		mcInit(MC_TYPE_MC);
	}

But for the case where reset is made, this will perform exactly like your ordering, so presumably this will then crash too...

Best regards: dlanor

Yeah I had tried that before and got the same crash. I too would have thought resetIOP would take care of it.

I have now since found that setupPad is actually in pad.c src file for launchELF. So the setupPad is its own creation for LaunchELF. Here it is from pad.c src file. (Note: I never touched it.)

//////////////////////////////////////////////////////////////////////
// setup PAD
int setupPad(void)
{
	int ret, i, modes;
	
	padInit(0);
	if((ret = padPortOpen(0, 0, padBuf)) == 0)
		return 0;
	waitPadReady(0, 0);
	modes = padInfoMode(0, 0, PAD_MODETABLE, -1);
	if (modes != 0){
		i = 0;
		do{
			if (padInfoMode(0, 0, PAD_MODETABLE, i) == PAD_TYPE_DUALSHOCK){
				padSetMainMode(0, 0, PAD_MMODE_DUALSHOCK, PAD_MMODE_LOCK);
				break;
			}
			i++;
		} while (i < modes);
	}
	return 1;
}

The problem occurs after execution of the above function after IOP reset. Without calling setupPad again there wouldn't be any controller function since the reset clears everything or should have cleared everything.