unofficial LaunchELF v4.42

[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.42 (2010.06.12)
-Added kernel patcher and kernel patch as designed by jimmikaelkael to make v0 japanese consoles compatible with newer models in use of homebrews. This cures v0 problems for many other applications too (including ESR) as the kernel remains patched for the duration of a session (until next hard reset/power on). This patching is compatible with that to be added into new versions of "Open PS2 Loader" too, and includes conflict protection when multiple patchers are used. This change has no effect at all on newer consoles, but was required to make it possible to keep the homebrew MC modules in future versions of uLE, and still retain uLE compatibility to all PS2 models.

LaunchELF v4.41a (2010.06.03)
-Fixed a problem with uLE initialization, causing problems with the new MC drivers when used on a PS2 of very old model. This change means that 'initsbv_patches' is now called early in 'loadBasicModules', and nowhere else.
-Reinstated MC drivers by jimmikaelkael, and thus FileBrowser renaming on MCs
-Added corrections by jimmikaelkael to the EE_SIO debug output module of ps2sdk
-added the 'sior' module to uLE with changes in "makefile", "launchelf.h", "iopmod_name.h" and "main.c"
-Added 'SIO_DEBUG' flag to "launchelf.h" for use only in compiling special debug versions of uLE, that use EE_SIO interface for debug feedback instead of PS2LINK
(NB: This is required for debugging with oldest models, as PS2LINK won't work...)
-Remerged all of the changes described for beta v4.40j described further below

LaunchELF v4.41 (2010.05.30)
-Updated ps2sdk and existing source files to SVN rev 1682.
-Fixed some compiler warnings with the vmcfs driver do to changes in the latest ps2sdk revison.
-Removed the modified screen update delay methods, restoring previous functionality.

LaunchELF v4.40j (2010.05.29)
-Added libcdvd_orig folder to CSD folder, so as to provide original libcvd source now that it is no longer available for download at ps2dev.org, and edited setup.sh accordingly so as to use the local copy.
-Edited VMC sources to correct hundreds of incorrect references to "vmcfs" module which is in fact named "vmc_fs". This was mainly in 'DEBUGPRINT' error messages. This also required some editing of the main uLE source files.
-Changed vmc_fs from being an 'uncheckable' module to being 'checkable' (changes in "main.c" and "iopmod_name.h")
-Started work on merging smbman by jimmikaelkael into uLE
-SMB routines now allow successful server connection, using a test menu inside the subprogram "MISC/Debug Info". Note that the SMB functionality requires a suitable "SMB.CNF" file stored as "mc0:/SYS-CONF/SMB.CNF"

LaunchELF v4.40i (2010.04.09)
-Updated ps2sdk and existing source files to SVN rev 1678 and removed a previous source file as it's no longer needed.
-Updated the vmcfs driver with Polo35's changes to vmc_io.c in order to possibly fix virtual memorycard corruptions.
ps2ftpd new additions and changes:
-Added a fix to better resolve the hard drive compatibility issue with later ps2sdk updates.

LaunchELF v4.40h (2010.02.12)
-Modified screen update delay methods, so as to avoid freezing in PCSX2 use due to their incomplete implementation of EE timers.
-Reverted to use MCMAN and MCSERV modules from bios, as required not only for compatibility to PCSX2, but also for compatibility to v0 PS2 consoles.

LaunchELF v4.40g (2010.02.09)
-Updated gsKit and existing source files to SVN rev 1664.
-Readapted and added a few changes back to the gsKit to resolve issues with non-interlace mode.
-Fixed a compiler warning, do to a change with the newer ps2sdk, by changing the data type from "ee_thread_t" to "ee_thread_status_t" for the ReferThreadStatus prototype.

LaunchELF v4.40f (2010.02.08)
-Added preclearing of icon.sys struct buffer for "New Icon" command
(Needed to avoid crashing Sony Browser of v0 PS2 consoles at showing such icons)
-Emphasized warning of old partition destruction for HddManager Format command
-Corrected gsKit coordinate rounding (for proper 'upside-down' JPG display)

LaunchELF v4.40e (2010.01.26)
-Modified load_ps2host function to eliminate 'stalling' of its network init, by adding a setupPowerOff() call before the load_ps2ip() call.

LaunchELF v4.40d (2010.01.24)
-Updated ps2sdk and existing source files to SVN rev 1663 after resolving a long-standing issue with the poweroff handler.
-Fixed an issue that would have caused problems with ps2netFS and ps2ftpd network devices using newer ps2sdk versions.
-Reorganized parts of the setup to build LaunchELF with newer versions of the ps2sdk.

LaunchELF v4.40c (2009.10.13)
-Special test version, reverting to MC drivers from bios instead of the new ones
NB: This is only intended for temporary debug testing, not for wide distribution

LaunchELF v4.40b (2009.09.14)
ps2ftpd new additions and changes:
-Forced memory card items to two, mc/0 and mc/1, in order to prevent the possible trigger of a buffer overflow noted by jimmikaelkaele for use with the new mc drivers.
-Changed PFS items to only look for 4 mount points as before. This change was only made do to the earlier change of DEVICE_UNITS being set to ten for USB devices.
-Fixed an issues that prevented PS1 memory cards from appearing in the listing with the new mc drivers. Now should work correctly for either driver.

LaunchELF v4.40a (2009.09.13)
-Modified gsGlobal usage at rez init and changes, to better follow standards
-Merged EPs bugfix for FTP server's HDD mount bug, reverting it to SVN rev 371

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

summary of prior changes:

LaunchELF v3.41a (2005.05.30) - LaunchELF v4.32 (2009.01.11)
-Added ability of MISC/PS2Disc to launch ESR discs correctly (not mistaken as DVD-Video)
-Many other tweaks and improvements (see "changes.txt" of latest release)
-Support for multiple hotplugged USB drives and partitions
-Added ability of MISC/PS2Disc subprogram to boot PS1 discs as well as DVD-Video launch capability
-Fixed auto detection of PAL/NTSC mode on some slim PStwo units
-Embedded "virtual memory card" VMC driver support including plenty of internal fixes (by Polo35 - initial IOP implementation by ubergeek42)
-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, Polo35, and jimmikaelkael 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 psx-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.