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 (http://sksapps.com/ule_noobie_guide/main.html) 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 (http://www.ps2-scene.org/forums/showthread.php?t=40179) and the Wiki here (http://ps2ulaunchelf.pbwiki.com/).

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>]

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? :p
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]

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 :lol: :dance:

[dlanor]

LOL that would be funny if mode 3 fixed every thing lol :lol: :dance:
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.

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.


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. :banghead:

[dlanor]

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. :banghead:
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]

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.


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 (http://www.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]

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]

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 (http://www.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]

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]

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.


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.

[E P]

This was the other code change I used once that worked around the config issue even with or without reset of the IOP. No crash on startup but a lockup when trying to access mc0:/ or mc1:/ only if IOP is reset. This I guess points out the problem with reset IOP and mcInit()?

Note: The McInit is apparently needed to find the config file from outside LaunchELF's location, which is the directory named SYS-CONF. It works fine with a compressed binary.


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

setupPad();

mcInit(MC_TYPE_MC); // no difference with or without again so not needed?


Maybe mcInit needs to be cleared although I would have thought reset would have done just that? The mcInit should be called again but right now I don't see any difference either way. It just results in a lock up when trying to check the memory cards after a reset through LaunchELF's FileBrowser. :(

[HypERSoniC]

launchelf is the first point of call for most systems using it, so it needs to be nice and clean. == no jpg backgrounds

if you want a good looking program that does alot of what launchelf does check out ps2os over at www.ps2world.it

[dlanor]

----- snip ----- re: how ELF location affects MC access after launch

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.
Well, the only thing different with a packed elf is that the unpacking stub, with the real elf as packed data, exists somewhere in RAM while unpacking it, and may leave garbage there (and in stack as well) when it is done. That is why I guessed earlier that the problem had to do with this RAM being used for some data structure, which needed it initialized to zeroes.

----- snip ----- re: (setupPad and mcInit) both before and after IOP reset

Yeah I had tried that before and got the same crash. I too would have thought resetIOP would take care of it.
That is the mystery of it. Apparently something specific to this module survives the IOP reset, and we need to know how that works, so as to stop 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.)
----- snip ----- re: setupPad source

Ok, but we are now using it differently from the original usage, so changing it may now be necessary. Also, the sick dependency of setupPad to be called before mcInit may be due only to part of it. Perhaps it is enough to use only padInit before mcInit, saving the rest for later, and for the IOP reset case you should then add another padInit call inside the conditional clause, like this:

padInit(0);
mcInit(MC_TYPE_MC);

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


If that doesn't hit the spot, it might still be a good idea to split setupPad into two parts, used like above, to find out what functions need to go before mcInit.

Btw: I could understand this weird dependency better if this was a PS1, where the ports for MC0 and pad0 use exactly the same serial interface, and can even 'overhear' the traffic of each other (used by some 3rd-party PS1 MCs), but I thought they were separate on the PS2. Right/wrong ???

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.
Weird. We clearly need to investigate this more, to find out exactly what is going on here.

Another wild guess:
I noticed that we use a padPortOpen call in setupPad, and that a matching function named padPortClose exists but is never used by us. Could that possibly help in cleaning up for an IOP reset ?

I also note that there exists a function named padEnd, which presumably matches padInit. While I do think an IOP reset should supercede all such functions, cleaning out everything, these might still be worth trying.

Best regards: dlanor

[dlanor]

This was the other code change I used once that worked around the config issue even with or without reset of the IOP. No crash on startup but a lockup when trying to access mc0:/ or mc1:/ only if IOP is reset. This I guess points out the problem with reset IOP and mcInit()?
So, considering what we discussed earlier, this means that BOTH the pad driver and the MC driver can leave some residue after IOP reset. Or does it ?

Perhaps it is rather that our MC setup is too primitive ?
Is it really enough to just call mcInit ?
And if that is normally so, does that still hold true directly after IOP reset ?

Note: The McInit is apparently needed to find the config file from outside LaunchELF's location, which is the directory named SYS-CONF. It works fine with a compressed binary.
----- snip ----- re: mcInit, cond IOP reset. setupPad, mcInit

WHAT ?!? Are you saying that (when packed) this example works right for BOTH of the cases, regardless of whether IOP reset is made or not made...?!? And it only fails when NOT packed (which should add NO complications) ?!?
(I suspect I misunderstood you on this one.)

Maybe mcInit needs to be cleared although I would have thought reset would have done just that? The mcInit should be called again but right now I don't see any difference either way. It just results in a lock up when trying to check the memory cards after a reset through LaunchELF's FileBrowser. :(
Ok, so the example you referred to above does not in fact work correctly, it just managed to 'correctly' survive the initialization. Right ?

I agree that something seems missing from our setup of MC handling.

From what I can see, no other MC related function is called between the initial mcInit and the "fioOpen(path, O_RDONLY);" used by loadConfig in the attempt to open the CNF file.

Is that really valid ?
Can we rely on fioOpen to do anything else that may be necessary ?

This is the kind of thing that might work fine after some previous MC access (like for ELF loading), but might fail if this is the first MC access. Perhaps it would be useful to add two mcGetInfo+mcSync combinations, to ensure that the driver has identified both cards (if any), before attempting to use loadConfig (and thus fioOpen).

Best regards: dlanor

[barf]

5x (X) + R1 copy + /\ + R1 paste
(Marking 5 files in sequence, copy, parent, paste )

I have a problem with launchELF, official or unofficial does not matter, this is what fails: I mark files with (X) making * appear in front of the filename, then I press R1 and then copy, when I go to parent folder and try to R1 paste, I get paste failed.

R1 copy + /\ + R1 paste + O + R1 copy + /\ + R1 paste + O + R1 copy + /\ + R1 paste + O + R1 copy + /\ + R1 paste + O + R1 copy + /\ + R1 paste + O
5x( copy, parent, paste )
However doing this operation manually for each file without marking the files just press R1 copy + /\ + R1 paste for each file it works.

Does anyone have a clue to what is wrong?

can you add a nice GUI like KeyLauncher?
That is the entire point of LaunchELF.

If you want a bitch with lipstick use KeyLauncher, GDI!

[E P]

padInit(0);
mcInit(MC_TYPE_MC);

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


If that doesn't hit the spot, it might still be a good idea to split setupPad into two parts, used like above, to find out what functions need to go before mcInit.

Doesn't work when reset IOP is enabled otherwise it's fine. Reset IOP just doesn't appear to do a good job with clean up.


Btw: I could understand this weird dependency better if this was a PS1, where the ports for MC0 and pad0 use exactly the same serial interface, and can even 'overhear' the traffic of each other (used by some 3rd-party PS1 MCs), but I thought they were separate on the PS2. Right/wrong ???


I had looked at libmc.h at ps2dev docs and found this for mc:

/*
NOTE: These functions will work with the MCMAN/MCSERV or XMCMAN/XMCSERV modules stored in rom0. To determine which one you are using, send the appropriate arg to the mcInit() function (MC_TYPE_MC or MC_TYPE_XMC)
NOTE: These functions seem to work for both psx and ps2 memcards to use memcards:
1) first load modules (sio2man then mcman/mcserv)
2) call mcInit(MC_TYPE)
3) use mcGetInfo() to see if memcards are connected
4) use mcSync to check that the function has finished

all mc* functions except mcInit() are asynchronous and require mcSync() usage to test when they are done
*/


Weird. We clearly need to investigate this more, to find out exactly what is going on here.

Another wild guess:
I noticed that we use a padPortOpen call in setupPad, and that a matching function named padPortClose exists but is never used by us. Could that possibly help in cleaning up for an IOP reset ?


Haven't tried this yet.


I also note that there exists a function named padEnd, which presumably matches padInit. While I do think an IOP reset should supercede all such functions, cleaning out everything, these might still be worth trying.

Best regards: dlanor

never had any luck with padEnd I did a padInit(0) followed by a padEnd(0) then setupPad() and lost all pad functionality this without reset IOP.


So, considering what we discussed earlier, this means that BOTH the pad driver and the MC driver can leave some residue after IOP reset. Or does it ?

Perhaps it is rather that our MC setup is too primitive ?
Is it really enough to just call mcInit ?
And if that is normally so, does that still hold true directly after IOP reset ?


Yeah good questions. I think the reset has problems mainly with mcInit and adding setupPad just compounds the problem.


----- snip ----- re: mcInit, cond IOP reset. setupPad, mcInit

WHAT ?!? Are you saying that (when packed) this example works right for BOTH of the cases, regardless of whether IOP reset is made or not made...?!? And it only fails when NOT packed (which should add NO complications) ?!?
(I suspect I misunderstood you on this one.)


OK I think I see where you're confused. That code was my other attempt that works for the most part. It gets around the load config bug. Yes, I works whether its compressed or not. However, only after a reset does mc access get messed up and causes a lockup when trying to access the memory cards through LaunchELf's fileBrowser.

So it appears that mcInit is the root cause of the problem afer a reset.

[dlanor]

----- snip ----- re: pad dependency test with only padInit before mcInit
Doesn't work when reset IOP is enabled otherwise it's fine. Reset IOP just doesn't appear to do a good job with clean up.
Yes, but that same test did clarify the 'pad vs mc' dependency issue quite a lot, since that part of the test is valid even without IOP reset, and you just said that it's fine then. So now we know that only padInit needs to precede mcInit for the pad to work right. (Or did you forget to test that ?)

I had looked at libmc.h at ps2dev docs and found this for mc:
----- snip ----- re: mc* function usage

Yes, I too found that, and I do know that both PS1 and PS2 MCs use a similar hardware interface, which is also similar to that of the pads. But what I really was wondering about was if the dependency we see between mcInit and padInit functionality is due to a dependency in the hardware. For example, both may need to access the same hardware register in order to setup the interface and one of them may mess up something for the other.

----- snip ----- re: padPortClose as cleaning help for IOP reset
Haven't tried this yet.
Ok. Let's get back to this later then.

never had any luck with padEnd I did a padInit(0) followed by a padEnd(0) then setupPad() and lost all pad functionality this without reset IOP.
That's odd, but 'libpad.h' does say 'not tested :/' about this function, so maybe it doesn't work right. It is something normal programs never use, so there probably hasn't been any need to debug it...

----- snip ----- re: on validity of simple MC initialization
Yeah good questions. I think the reset has problems mainly with mcInit and adding setupPad just compounds the problem.
I have to disagree here. The system itself doesn't have a problem with this, and neither do commercial games, many of which do use IOP reset in their initialization. So I don't see this as a problem which IOP reset has, but more as a problem which we have in how to use it. And I'm convinced that we will solve that problem. We just haven't quite managed it yet.

Looking closer at the Reset() function, I must say I find the core of it rather odd: SifIopReset("rom0:UDNL rom0:EELOADCNF",0);

That doesn't match the description in iopcontrol.h of ps2sdk:
/*!
Resets IOP, arg can be NULL or a module that will be loaded afterwards.
@param arg a const character pointer for path to module or NULL
@param mode 0x100 for magicgate anything else for no magicgate.
@return 1 for success or 0 for failure.
*/
int SifIopReset(const char *arg, int mode);
That description only mentions specifying a single module in 'arg', whereas our code specifies two modules separated by a space character.

Is that really valid ?
And even if it is, do we really want those two modules loaded ?
And if so why, and how ? Is that really the best way to do it ?
To me it seems that our IOP reset code is too specific to the context from which we have borrowed it.

I think we need to look deeper into how this really works, and inspect more than one example of how others have used it. I think Krevnik discussed some aspects of this in his work on the hddemolisher project, before he had to drop out of it, and I think romz has been investigating such things too in his work on that project. But then again, they are both interested in circumventing IOP reset, which is the opposite of what we want to do. But I do have some other source with IOP reset.

Here is an example from Altimit.cpp:

if (boot == CD_BOOT) // just reset IOP for CD boot atm.
{ // although it may be worth doing in all
printf("CD BOOT?\n"); // cases eventually. it is currently useful
cdInit(CD_EXIT); // to still have ps2link functioning in the
cdExit(); // background
fioExit();
SifExitIopHeap();
SifLoadFileExit();
SifExitRpc();
#ifdef VERBOSE
scr_printf("Reset IOP\n");
#endif
SifIopReset(img, 0);
#ifdef VERBOSE
scr_printf("Wait for IOP sync\n");
#endif
while (SifIopSync());
#ifdef VERBOSE
scr_printf("Init RPC\n");
#endif
SifInitRpc(0);
cdInit(CD_INIT_NOWAIT);
}
In the above 'img' has been previously declared as: 'char *img = "";'

And here is an example from the emulator neocd:
/*
if (boot_mode != BOOT_HO)
{
SifInitRpc(0);
SifExitIopHeap();
SifLoadFileExit();
SifExitRpc();
SifIopReset("rom0:UDNL rom0:EELOADCNF",0);
while (!SifIopSync()) ;
// is cdvdman irx needed after that ?
}
*/
This is more similar to ours, but with a radically different order for some of the stuff. Note however that the entire section is inside a comment bracket, which may indicate that it doesn't work right !?!

----- snip ----- re: results without padSetup before the 'early' mcInit
OK I think I see where you're confused. That code was my other attempt that works for the most part. It gets around the load config bug. Yes, I works whether its compressed or not. However, only after a reset does mc access get messed up and causes a lockup when trying to access the memory cards through LaunchELf's fileBrowser.
I see. But there is a positive side to this test too. This code had an early mcInit with NO padSetup before it, and then (after the conditional IOP reset) came the call to padSetup and a second call to mcInit, and you just said that it worked fine when no IOP reset was made. So even if it didn't solve the reset problem, it shows that this code order (without early padSetup) can work.

So it appears that mcInit is the root cause of the problem afer a reset.
I'm not at all sure of that myself. It obviously plays some role in our problems but I don't think there's anything really wrong with mcInit. We just need to learn more about how the IOP reset really works.

Best regards: dlanor

[crazyc]

Yes, I too found that, and I do know that both PS1 and PS2 MCs use a similar hardware interface, which is also similar to that of the pads. But what I really was wondering about was if the dependency we see between mcInit and padInit functionality is due to a dependency in the hardware. For example, both may need to access the same hardware register in order to setup the interface and one of them may mess up something for the other.
Both are on the sio2 bus.


Looking closer at the Reset() function, I must say I find the core of it rather odd: SifIopReset("rom0:UDNL rom0:EELOADCNF",0);
This is valid. UDNL loads the modules listed in EELOADCNF. This is part of the problem with hdloader on v12.

[dlanor]

Both are on the sio2 bus.
That does make it rather likely that some of the control registers affect both interfaces.

This is valid. UDNL loads the modules listed in EELOADCNF. This is part of the problem with hdloader on v12.
Now I see. So the string argument to SifIopReset doesn't just specify a module name, but more like a command line, with the part after the module name being passed as argument to that module when it is launched. Right ?

Best regards: dlanor

[crazyc]

Now I see. So the string argument to SifIopReset doesn't just specify a module name, but more like a command line, with the part after the module name being passed as argument to that module when it is launched. Right ?


I think so.

[E P]

----- snip ----- re: pad dependency test with only padInit before mcInit
Yes, but that same test did clarify the 'pad vs mc' dependency issue quite a lot, since that part of the test is valid even without IOP reset, and you just said that it's fine then. So now we know that only padInit needs to precede mcInit for the pad to work right. (Or did you forget to test that ?)


I tested padInit(). It can go either way this works fine for example:
Reset();
loadModules(); // reloads SIO2MAN, MCMAN, MCSERV, and PADMAN
mcInit(MC_TYPE_MC);
loadConfig(mainMsg, strcpy(CNF, "LAUNCHELF.CNF"));
setupPad(); // calls padInit(0)

Of course, we want to load the config to see if reset IOP is on/off by loading the CNF file first.

I looked at some other programs and usually you call setupPad() - padInit() after setting up the memory card. The reason I first thought it had to be a certain order was because that's how the source was before I changed it.


----- snip ----- re: mc* function usage

Yes, I too found that, and I do know that both PS1 and PS2 MCs use a similar hardware interface, which is also similar to that of the pads. But what I really was wondering about was if the dependency we see between mcInit and padInit functionality is due to a dependency in the hardware. For example, both may need to access the same hardware register in order to setup the interface and one of them may mess up something for the other.

----- snip ----- re: padPortClose as cleaning help for IOP reset
Ok. Let's get back to this later then.

That's odd, but 'libpad.h' does say 'not tested :/' about this function, so maybe it doesn't work right. It is something normal programs never use, so there probably hasn't been any need to debug it...


Yeah that might explain why I had no luck with padPortClose and padEnd.


----- snip ----- re: on validity of simple MC initialization
I have to disagree here. The system itself doesn't have a problem with this, and neither do commercial games, many of which do use IOP reset in their initialization. So I don't see this as a problem which IOP reset has, but more as a problem which we have in how to use it. And I'm convinced that we will solve that problem. We just haven't quite managed it yet.


Yeah I agree. We need to figure out what SifIopReset("rom0:UDNL rom0:EELOADCNF",0); is doing and what it is specifically not doing. That line of code is what is resets the IOP or could be seen as part of the conflict.

I tested some of the other IOP resets and got the same result order doesn't seem to matter here. We'll just have to see what else needs to be done prior to calling for a reset of the IOP.

update:
OK since I've tried pretty much everything I could think of I moved on. I have pretty much finished the load config stuff now. Dlanor I'm sure you will be happy to hear this: I now allow the user to have as may config files as he or she wants. I changed it so you have "LEFT: LOAD CONFIG--" and "RIGHT: LOAD CONFIG++", which now does indeed cycle. :)

I placed the somewhat broken ResetIOP in a new menu called "startup settings" along with a new option (NOTE: startup settings are just that they only work off the default config at launch). The new option is called "number of cnf's" which allows you to set a minimum of one config file to as many as the user wants. So to anyone out there wants a hundred config files or even a few thousand you will soon be able to do that now. :p

Hopefully; in the future I can rearrange the menus and allow for a longer launch list. That's what I first wanted until I implemented dlanor's idea of config switching. :)

Maybe if the reset IOP function can be patched up soon, I can get the new 3.41b version out.

[kthu]

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....

Here you go. A config option to swap x and o was added. The zip contains a precompiled .elf and a diff against the 3.41 sources. Enjoy.

Edit: Uploaded new version that fixes bug that prevented the X entry from the list being launched when pressing X. Also improved wording.

[E P]

Here you go. A config option to swap x and o was added. The zip contains a precompiled .elf and a diff against the 3.41 sources. Enjoy.

Edit: Uploaded new version that fixes bug that prevented the X entry from the list being launched when pressing X. Also improved wording.

Thanks, I just got it working with my b build. It will be in my next release and I'll also give you the credit. :)

Thanks again.

[HypERSoniC]

my brain has been programmed to use the japaneese method ^_^

[vg132]

I have a USB device that I cant get working with LaunchELF, it works fine with GT4 so is there a way to make LaunchELF use GT4's USBD.IRX? I run LaunchELF from a memorycard.

[E P]

my brain has been programmed to use the japaneese method ^_^

Same here I probably won't use it now either but it will be optional. I added it to the startup settings menu and it works. (Note: If you change any of the startup settings, none of the changes in that menu will work until you run LaunchELF again).

I did notice something from before that there appears to be a renaming function in libmc but it was never implemented in launchELF. I'm affraid to try to implement it for fear it may mess up my memory card in the testing of it. Anyone want to take a crack at implementing MC file/directory renaming and the testing of it. :lol:

[dlanor]

Same here I probably won't use it now either but it will be optional. I added it to the startup settings menu and it works.
Good! Taste in this differs, obviously, but this is one thing that many users have asked for. I myself don't really care though, and will probably continue using the old method.

(Note: If you change any of the startup settings, none of the changes in that menu will work until you run LaunchELF again).
Understood, but we may want to change this in the future, except for the things that are tied to the LaunchELF boot process (such as IOP reset).

I did notice something from before that there appears to be a renaming function in libmc but it was never implemented in launchELF. I'm affraid to try to implement it for fear it may mess up my memory card in the testing of it. Anyone want to take a crack at implementing MC file/directory renaming and the testing of it. :lol:
Sure. I have several MCs, including a brand new (still empty) 32MB Datel card, so I have nothing to lose by it.

FYI: I have just started setting up the necessary stuff to recompile LaunchELF myself, so I can paricipate more actively in the debugging. I'll let you know later when/if I've made some progress on that.

Best regards: dlanor

[E P]

Understood, but we may want to change this in the future, except for the things that are tied to the LaunchELF boot process (such as IOP reset).
I agree but it's only a temporary workaround because I don't want the user to have to change the number of configs and button swapping in each and every config.

If only I could find a workaround for the reset IOP issue. I looked at the source PS2MP3SE 1.2. The mc initialization and pad initialization are only started after the reset of the IOP. This is how I had it before but we all know LaunchELF looks to SYS-CONF if the CNF isn't in the same directory as the program. I really wouldn't want to change this either.

Sure. I have several MCs, including a brand new (still empty) 32MB Datel card, so I have nothing to lose by it.
OK I can say that directory creation and file deletion are there so maybe there is something to go by. Of course, it could be that the libmc's rename has problems and that's why it was left out.

FYI: I have just started setting up the necessary stuff to recompile LaunchELF myself, so I can paricipate more actively in the debugging. I'll let you know later when/if I've made some progress on that.

Best regards: dlanor
That's good let me know if you run into problems. I believe I have found all the workarounds to compiling LaunchELF. :)

[dlanor]

That's good let me know if you run into problems. I believe I have found all the workarounds to compiling LaunchELF. :)
I can compile it fine, but I don't get exactly the same results as with the binary you posted, even when I use exactly the same sources that accompanied it. This is particularly clear when I launch the ELF from a non-MC device. When started from MC results do seem identical though.

For example:
Launching the ELF from 'mass:' in a folder without any CNF files.

Your ELF:
Boots WITHOUT finding any CNF (even on MC), but when I press <Right> or <Left> it does correctly load a CNF from mc0:/SYS-CONF/

My ELF:
Boots WITHOUT finding any CNF (even on MC), and ALSO fails to find any CNF when I press <Right> or <Left>. However, if I press <Select>, make some config changes, and end by selecting "OK" in the config menu, then this new CNF will overwrite the one in mc0:/SYS-CONF/. However, when I thereafter press <Right> or <Left> it still fails to find any CNF... (goes back to trying to find it on mass: )

I don't understand the above at all (yet!), but I'll keep on digging.

In the meantime, I have found a few things that I consider incorrect.

1: In function 'loadConfig', of file 'config.c, we init the pointer 'setting' by giving it the base address of a memory block acquired by 'malloc'. That memory block is never released before calling 'loadConfig' again, to switch configs, so this is a memory leak. It should be cured by using 'free(setting)' before (or as part of) each new 'loadConfig' call.

2: Function 'CheckMC', of file 'config.c', contains two calls to 'mcGetInfo', so as to test both mc0 and mc1. But the parameters to both calls are identical, so only mc0 can be found this way. The first parameter of the second call should be changed from '0' to '1'.

3: Another problem with 'loadConfig' is that 'LaunchElfDir' remains unchanged after failing to load any CNF from there, thus being forced to load one from mc0:/SYS-CONF/ instead. This means that every future attempt to switch CNF will waste time on attempting to load from the launch directory even though the CNF currently in use comes from mc0:/SYS-CONF/. I feel it would be more correct to set 'LaunchElfDir' to be the path of any successfully loaded CNF, to save time on future attempts. (NB: This also affects 'saveConfig' and may require some fix there too.)

That's all for now, but hopefully I can provide more useful stuff when/if I get around the weird problems I mentioned earlier (my ELF behaving differently from yours).

Btw:
I've now installed PS2SDK v1.2, which may affect my results. Which version are you using ?
I am also using libito v0.2.1 and libcdvd v1.15, so how does that match what you have ?

Best regards: dlanor

[E P]

Yeah, there are many things that need to be sorted out. I have rearranged some of the code since version a. It still could use a good clean up.

I looked at the CheckMC function and it could be changed to possibly fix that issue with reset IOP and packed versions. Although I could be wrong, but that's after looking at Stefy's PS2MP3 1.2 version.

I'm using a newer ps2sdk than 1.2 but I probably will start using 1.2 for future compiles of LaunchELF. An older version of IomanX.irx wouldn't be necessary for compiles then. I'm using the same versions of libito and libcdvd.

[dlanor]

I'm using a newer ps2sdk than 1.2 but I probably will start using 1.2 for future compiles of LaunchELF. An older version of IomanX.irx wouldn't be necessary for compiles then. I'm using the same versions of libito and libcdvd.
Weird... I'm completely unable to compile v3.41a so as to get identical behaviour as your ELF. Mine is completely unable to load any CNF from MC when launched from mass:. It will save CNF to MC, but not load it from there... Your ELF, on the other hand has no problem loading CNF from MC, unless the ELF is packed.

If I include LAUNCHELF.CNF in the same folder, then it is now loaded, but the <Right> and <Left> commands fail to load anything (but I can see the USB stick blinking), so the CNF that was originally loaded is then forgotten. Your ELF, on the other hand, succeeds in loading the CNFs stored with the ELF, although it incorrectly switches to memory card at <Right> or <Left> commands.

But if I compile v3.41 (without adding your changes) then my ELF behaves identically to the original v3.41 ELF. So when this ELF is launched from mass: it succeeds in loading the CNF stored with it, and if that file is absent the ELF instead loads the CNF from mc0:/SYS-CONF/ correctly.

I can't understand why there is such a huge difference in behaviour between v3.41a ELFs compiled on different systems, but no difference at all between similarily compiled v3.41 ELFs. Unless, of course, you happened to forget including some file that was changed for v3.41a... Could that be it ?

Best regards: dlanor

[E P]

Weird... I'm completely unable to compile v3.41a so as to get identical behaviour as your ELF. Mine is completely unable to load any CNF from MC when launched from mass:. It will save CNF to MC, but not load it from there... Your ELF, on the other hand has no problem loading CNF from MC, unless the ELF is packed.

If I include LAUNCHELF.CNF in the same folder, then it is now loaded, but the <Right> and <Left> commands fail to load anything (but I can see the USB stick blinking), so the CNF that was originally loaded is then forgotten. Your ELF, on the other hand, succeeds in loading the CNFs stored with the ELF, although it incorrectly switches to memory card at <Right> or <Left> commands.

But if I compile v3.41 (without adding your changes) then my ELF behaves identically to the original v3.41 ELF. So when this ELF is launched from mass: it succeeds in loading the CNF stored with it, and if that file is absent the ELF instead loads the CNF from mc0:/SYS-CONF/ correctly.

I can't understand why there is such a huge difference in behaviour between v3.41a ELFs compiled on different systems, but no difference at all between similarily compiled v3.41 ELFs. Unless, of course, you happened to forget including some file that was changed for v3.41a... Could that be it ?

Best regards: dlanor

That's strange, I compiled with an older sdk and experienced no problems either. I thought I included everything but I'll do some tests later and see if I forgot something.

Did you apply each of the diffs or use my changed source files? Or did you try both?

edit
Nope. I just tested both ways applying each of the diff's and just using the incuded changed src files and both compiles work fine. Of course, I chaged the make files a little but I doubt that's it. :chinscrat

The only other thing I haven't tried yet is the official sdk 1.2 package. I never trusted it before because I believe those libaries were compiled with the bug infested iop 3.2.2.

edit
OK just tried out binaries created with sdk v1.2 and both iop 3.2.2 and iop 2.8.1 compilers and no issues either. :chinscrat

edit
OK I just had some success with the bug not finding the config file with the compressed ELF. By just bypassing CheckMC(), I was able to get it to work with a compressed elf. So CheckMC() needs mcInit() I gather. (Note: mcInit() can't be cleared with IOP reset). I wonder if a new implementation can be put in place to allow me to keep this code in main.c:

loadConfig(mainMsg, strcpy(CNF, "LAUNCHELF.CNF"));
maxCNF = setting->numCNF; // set total number of extra configs
swapKeys = setting->swapKeys; // swap keys on or off
if(setting->resetIOP){
Reset();
loadModules();
}
mcInit(MC_TYPE_MC);
setupPad();

[dlanor]

That's strange, I compiled with an older sdk and experienced no problems either. I thought I included everything but I'll do some tests later and see if I forgot something.
I don't think you forgot anything, because now I've got things working much better.

Did you apply each of the diffs or use my changed source files? Or did you try both?
I used the changed source files, to avoid possible hassles with the diff tools.

edit
Nope. I just tested both ways applying each of the diff's and just using the incuded changed src files and both compiles work fine. Of course, I chaged the make files a little but I doubt that's it. :chinscrat
Well, obviously we have to change some paths in the makefile, for the compilation to work, but those paths shouldn't affect the run-time code.

The only other thing I haven't tried yet is the official sdk 1.2 package. I never trusted it before because I believe those libaries were compiled with the bug infested iop 3.2.2.

edit
OK just tried out binaries created with sdk v1.2 and both iop 3.2.2 and iop 2.8.1 compilers and no issues either. :chinscrat
These issues I've seen are very odd indeed, and I can hardly believe how it appears to work. Believe it or not, but I got rid of most of the problems simply by replacing/reordering some string handling function calls, with some that *should* perform the very same things, but evidently differ somehow...

I had a vague memory of some of the guys at ps2dev.org discussing erroneous optimizations that could affect 'sprintf', so when I found some cases of 'sprintf' being nestled with other string functions in 'config.c' I decided to try rewriting those sections. I simply rearranged and simplified the expressions so as to avoid nestling, even at cost of an extra statement here and there (may still optimize to equivalent binary code), and the effect on my problems was significant.

Once I had got rid of those problems I started making a few improvements, so now I have a version fixing all problems that I currently know about. I've tested it on USB, HDD, and MC, and all the problems I had earlier are gone.

I'm attaching a ZIP with this BOOT.ELF and the two files I revised to make it.
(Only 'main.c' and 'config.c' differ from your release of v3.41a.)

Note that this still doesn't implement any new functionality, such as MC rename or the 'X vs O' button usage. But with the old problems out of the way, I'm at last ready to work on real improvements and additions.

Best regards: dlanor

Edit: The attached version still has a serious bug affecting MC access.

[E P]

OK thanks dlanor I'll rework these into b. Although after testing your binary I still can't access mc0 or mc1 if IOP reset is on. Note my last edit which explains a workaround for this problem.

[dlanor]

OK thanks dlanor I'll rework these into b. Although after testing your binary I still can't access mc0 or mc1 if IOP reset is on. Note my last edit which explains a workaround for this problem.
Well, I discovered that there is indeed a problem with MC access, although it is not quite as bad as you think. I have no problem using MC if I launch the ELF from LaunchELF. (Which is how I mostly tested it earlier.) I only see this problem on an initial boot, and even then I can somehow eliminate the problem, by using the browser to launch an identical ELF from any device except MC. This obviously means that this bug can be eliminated.

I'll make some more experiments with this, and post my results later.

Best regards: dlanor

[E P]

Well, I discovered that there is indeed a problem with MC access, although it is not quite as bad as you think. I have no problem using MC if I launch the ELF from LaunchELF. (Which is how I mostly tested it earlier.) I only see this problem on an initial boot, and even then I can somehow eliminate the problem, by using the browser to launch an identical ELF from any device except MC. This obviously means that this bug can be eliminated.

I'll make some more experiments with this, and post my results later.

Best regards: dlanor

Hum, nevermind now it works fine. Added all your changes to b so hopefully I'll get b around for release real soon. Maybe I got mixed up with which elf I was testing I have so many now.

[dlanor]

Hum, nevermind now it works fine. Added all your changes to b so hopefully I'll get b around for release real soon. Maybe I got mixed up with which elf I was testing I have so many now.
No, the bug is REAL! It is just more complex than it appears when you first run into it. Part of that complexity is that it disappears when launched by other means than initial booting.

Also, it is not at all mcInit which causes this. Just for fun I put in an extra mcInit call at both places where I had them before. This had no effect whatever on the functionality. For the cases where the bug appeared previously, it still did so, and likewise it disappeared for cases where it had disappeared previously. So making mcInit calls twice in a row is not what causes this problem.

We have also misunderstood what the real problem is, because even when the bug appears it is not really due to MC access. I noticed that after an initial boot with IOP reset (which triggers the bug) I was able to switch CNFs several times back and forth between the two CNFs in mc0:/SYS-CONF/, showing that MC access did work fine at that time. But when I then entered the file browser to view mc0 contents the bug struck, freezing the system.

I have seen it happen this way both with the normal file browser, and with the browser used for config setup, so something in the coding of these must be responsible.

I'll experiment some more to try pinpointing the cause for this problem.

Best regards: dlanor

[E P]

OK I have released v.3.41b to the first page. Give it a test dlanor. :) Hope that bug is gone in this build.

[dlanor]

OK I have released v.3.41b to the first page. Give it a test dlanor. :) Hope that bug is gone in this build.
It seems to work well now, though I've only had time for brief testing as yet.

The only problem with this version (that I've noticed) is probably of minor importance. Because it has no mcInit before the first loadConfig, it is unable to find 'mc1:/SYS-CONF' for default loading of CNF when mc0 is absent... But then again, that has never worked as intended, in any version I know of. (Except the one in my last post, which had other problems instead.)

Another odd feature (no bug) is that when I boot this ELF by Dev.2, then the first CNF switch I make will be very slow, even though there is no similar delay at all in opening either mc0 or mc1 for normal browsing. This could also be related to our initial use of CheckMC without prior mcInit. Like I said, this is no bug, just something to be aware of (and get rid of if we get an opportunity).

Your v3.41b is probably a 'keeper', being both the most stable and most capable of these unofficial builds. But we should test it a bit more before recommending it to others.

Best regards: dlanor

[E P]

It seems to work well now, though I've only had time for brief testing as yet.

The only problem with this version (that I've noticed) is probably of minor importance. Because it has no mcInit before the first loadConfig, it is unable to find 'mc1:/SYS-CONF' for default loading of CNF when mc0 is absent... But then again, that has never worked as intended, in any version I know of. (Except the one in my last post, which had other problems instead.)
Yeah it's the only way I know of around the bug where you can't access memory cards through LaunchELF's fileBrowser. Hopefully in the future someone will find a better way to resolve this.
Another odd feature (no bug) is that when I boot this ELF by Dev.2, then the first CNF switch I make will be very slow, even though there is no similar delay at all in opening either mc0 or mc1 for normal browsing. This could also be related to our initial use of CheckMC without prior mcInit. Like I said, this is no bug, just something to be aware of (and get rid of if we get an opportunity).
That's odd but you're probably right about the CheckMC and the mcInit. I can only test LaunchELF through exploit no modchip here and I have not noticed any delay.
Your v3.41b is probably a 'keeper', being both the most stable and most capable of these unofficial builds. But we should test it a bit more before recommending it to others.

Best regards: dlanor
I just wanted to get it out for some testing. Also can now better see what else needs to be added/changed with the new src release of v3.41b.

I looked for programs with a rename implementation for memory card and found this: ps2ftp (http://cvs.ps2dev.org/cgi-bin/viewcvs.cgi/ps2ftp/ps2ftp/aio/aioMc.cpp) This program has since been replaced with ps2ftpd but mc rename was apparently implemented. So maybe it is possible to make it work with launchELF and add the implementation to the already existing Rename method in filer.c.

if(!strncmp(path, "hdd", 3)){ // already implemented }
else if(!strncmp(path, "mc", 2)){ }
else

[dlanor]

I just wanted to get it out for some testing. Also can now better see what else needs to be added/changed with the new src release of v3.41b.
Well, I still haven't found any new bugs in it, so I think we can concentrate on new additions instead.

I looked for programs with a rename implementation for memory card and found this: ps2ftp (http://cvs.ps2dev.org/cgi-bin/viewcvs.cgi/ps2ftp/ps2ftp/aio/aioMc.cpp) This program has since been replaced with ps2ftpd but mc rename was apparently implemented. So maybe it is possible to make it work with launchELF and add the implementation to the already existing Rename method in filer.c.

if(!strncmp(path, "hdd", 3)){ // already implemented }
else if(!strncmp(path, "mc", 2)){ }
else
Good. We really should try to implement proper renaming for all supported read/write media, so we need it for both MC and USB. Even if it turns out that the functions in the available drivers won't do it directly, then we'll just have to find some indirect approach instead. It shouldn't be too hard, doing it something like this:

1: Read a directory sector from USB/MC to a RAM buffer.
2: Patch a name in that buffer.
3: Write the buffer back to USB/MC.

Of course, that would need us to dig a little deeper into the filesystem implementation, to do it right, but if we have to do it this way, then we can.

Another thing I've been thinking about is adding proper 'host:' support, as that is one of the few PS2 media still not supported. It would also be a very handy way for people to copy large amounts of data (like MP3 collections etc) from a PC to the PS2 HDD. I remember using Altimit that way (before I got my large HDD which it can't handle). It was way faster than FTP, and I'm sure the same kind of speed would be possible with LaunchELF. Since LaunchELF is already capable of loading (and switching) the CNF files via 'host:', I'm sure it would be feasible to add support for it in the file browser as well.

Best regards: dlanor

[E P]

Another thing I've been thinking about is adding proper 'host:' support, as that is one of the few PS2 media still not supported. It would also be a very handy way for people to copy large amounts of data (like MP3 collections etc) from a PC to the PS2 HDD. I remember using Altimit that way (before I got my large HDD which it can't handle). It was way faster than FTP, and I'm sure the same kind of speed would be possible with LaunchELF. Since LaunchELF is already capable of loading (and switching) the CNF files via 'host:', I'm sure it would be feasible to add support for it in the file browser as well.

Best regards: dlanor
Yeah, host support would be great but don't you need a text file with a listing of all the files you wish to transfer on host? That's how it worked with ps2menu. It worked but it was so much easier later on with ps2ftpd and an ftp client.

As for it being faster I think that maybe do to the older ps2smap.irx. Ps2smap.irx was slowed down do to transfer issues like we saw with ExecFTP. Although I could be wrong about the irx and whether host support is tied directly to it.

Maybe having ftpd.irx would be good. I had made changes to FtpClient.c to support more clients so maybe it would be possible to add this to LaunchELF. It could maybe replace ExecFTP if only I knew what changes SlicStik made to get it to show hdd partiton names.

[niemand0815]

nfs support or something similar would also solve the problem (hey, maybe windows share could somehow be made accessible by launchelf?)

[rlbond]

what does IOP reset do?

[barf]

Garbages the modules, named #?.IRX

[dlanor]

Yeah, host support would be great but don't you need a text file with a listing of all the files you wish to transfer on host? That's how it worked with ps2menu. It worked but it was so much easier later on with ps2ftpd and an ftp client.
True, but that was with ps2menu, which didn't use all the capabilities of 'host:'. The method of specifying all files in a text file is not the only one (probably the oldest one though). Altimit is capable of browsing files and folders (and sub-folders etc) of the directory that was active work directory on the PC when ps2client.exe was launched. By specifying the full path for the client, it is possible to have the work directory entirely unrelated to the location of the client, even on another drive. I used this in copying my MP3 collection to my previous PS2 HDD. I can't do it now, as Altimit doesn't work right for large HDD, not even with 48-bit atad.irx. I can still use it to browse the PC in the same way, but the HDD isn't available as destination... :(

I'll try recompiling it later, to see if it will work right then, but that doesn't really affect anything in our work on LaunchELF. It's the access through 'host:' that we're after, and that does work in Altimit, so studying those sources should teach us how to do it.

As for it being faster I think that maybe do to the older ps2smap.irx. Ps2smap.irx was slowed down do to transfer issues like we saw with ExecFTP. Although I could be wrong about the irx and whether host support is tied directly to it.
Well, regardless of where the 'host:' code sections reside, they will always be dependent both on the high-level TCPIP 'stack' (ps2ip) and the low-level hardware driver (ps2smap), so any problems with either can have major impact on transfer efficiency.

Maybe having ftpd.irx would be good. I had made changes to FtpClient.c to support more clients so maybe it would be possible to add this to LaunchELF. It could maybe replace ExecFTP if only I knew what changes SlicStik made to get it to show hdd partiton names.
This may be a worthwhile addition in itself, but I don't think it can replace fully functional 'host:', though it can be a good complement.


Now. you may have wondered why I've been so silent lately, and the reason is that I've been busy making some changes I've long hesitated to make. I refer to the switchover to a real Cygwin installation from the simpler setup I had earlier. It's consumed just as much time as I expected, and I'm not entirely finished with it yet, though most things seem to work now. Hopefully I should be able to continue as before shortly, and this time without some of the odd problems that the simpler setup sometimes caused. (eg: subtasks of 'make' would sometimes fail to use the correct shell, calling directly on the Windows DOS tools, rather than bash and the ps2dev utilities.)

Another thing I've spent some time on today is to make a drag-drop interface for the Cygwin setup, through Windows batch files, similar to what I had for my old setup. This is something that others too may find useful so I'm attaching it to this post, as "Cygwin_DD.zip".
(NB: Non-devers shouldn't bother with it, as it is strictly for Cygwin...)

The effect is somewhat similar to the old "CygwinPromptHere", except that it's more versatile, and requires NO messing with the Windows registry.

Best regards: dlanor

[E P]

Dlanor I belive the hold up with altimit is with number of partitions. Old ps2 apps only looked for a few like ps2menu for example. KaylaKaze changed this for ps2menu-k, which is what most everyone uses now. I think altimit only looks for a few partitions so if you're are over it just won't work unless you change the source.

That's great about all the cygwin environment stuff. I myself have gotten launchELF up and going with Visual C++ 6.0 so no more WordPad for me. :) It's also handy to have a tool button assigned to inlink. Just a click of a button sends ELF's right to the PS2 that's running PS2link.

I also got to test the mcRename function and it acts like it will works but it doesn't. :( Here is the code I added to the Rename function in filer.c:
else if(!strncmp(path, "mc", 2)){
sprintf(oldPath, "%s%s", path+2, file->name);
sprintf(newPath, "%s%s", path+2, name);
mcSync(0,NULL,NULL);
mcRename(path[2]-'0', 0, oldPath, newPath);
mcSync(0, NULL, &ret);
if(ret == -4)
ret = -17;}
(NOTE: Be sure to set if(!strncmp(path, "mc", 2)) enable[RENAME] = TRUE; inorder to test).
I tested it with a test directory but it would not change the name. I also found out that ps2menu had implemented it and the author said in the source that it wouldn't work there either. So I guess the mcRename function is a no go. :chinscrat

[dlanor]

Dlanor I belive the hold up with altimit is with number of partitions. Old ps2 apps only looked for a few like ps2menu for example. KaylaKaze changed this for ps2menu-k, which is what most everyone uses now. I think altimit only looks for a few partitions so if you're are over it just won't work unless you change the source.
I don't think that is the problem, as the behaviour is very different. PS2Menu will not be able to show all partitions, but will allow you to browse the ones it has checked for (of course only the real APA partitions). But Altimit will not allow any HDD access at all on my new drive. 'hdd0:' is not even shown in the browser device list. To me that indicates an entirely different problem.

That's great about all the cygwin environment stuff. I myself have gotten launchELF up and going with Visual C++ 6.0 so no more WordPad for me. :)
Are you saying that you can compile ps2dev stuff with VC++ ???
Or do you simply use it for editing ? (I use UltraEdit-32 for this myself.)

It's also handy to have a tool button assigned to inlink. Just a click of a button sends ELF's right to the PS2 that's running PS2link.
I prefer to drag-drop stuff myself, as that allows more combinations than the available (and unused) hotkeys.

I also got to test the mcRename function and it acts like it will works but it doesn't. :(
I was afraid of that, so we'll have to do it the hard way then...
Either by low-level directory access or redundant file copying (VERY slow :( ).
I'm not sure yet what kind of access the mc manager allows.

Btw: My memory of 'host:' browsing with Altimit was a little 'off' earlier. You can browse files freely, but only on one folder level. When you go one level down into a subfolder, all the names are visible, but accessing those files/folders fails. But since file access does work fine at the top level I suspect that it is merely a limitation of Altimit, rather than of the 'host:' protocol.

Best regards: dlanor

[E P]

I don't think that is the problem, as the behaviour is very different. PS2Menu will not be able to show all partitions, but will allow you to browse the ones it has checked for (of course only the real APA partitions). But Altimit will not allow any HDD access at all on my new drive. 'hdd0:' is not even shown in the browser device list. To me that indicates an entirely different problem.
Hum maybe it sees too many partitons and just gives up. LaunchELF appears to look for up to 100 before it stops. Of course, you're probably right it's been about a year since KaylaKaze fixed whatever the issue was with ps2menu in ps2menu-k. Altimit could have a completely different problem.

Are you saying that you can compile ps2dev stuff with VC++ ???
Or do you simply use it for editing ? (I use UltraEdit-32 for this myself.)
I'm using it as just an IDE primarily. You can set executables and include files in options-directories. I followed a tutorial by Loser and can compile code through makefiles using cygwin all through VC++. You just have to make a few changes to some of the makefiles. I had this working before so I just needed to modify a few things to get LaunchELF to make and make clean all in one shot.

I prefer to drag-drop stuff myself, as that allows more combinations than the available (and unused) hotkeys.

Yeah and I'm still using all your ELF_repack bat's.

I was afraid of that, so we'll have to do it the hard way then...
Either by low-level directory access or redundant file copying (VERY slow :( ).
I'm not sure yet what kind of access the mc manager allows.

Btw: My memory of 'host:' browsing with Altimit was a little 'off' earlier. You can browse files freely, but only on one folder level. When you go one level down into a subfolder, all the names are visible, but accessing those files/folders fails. But since file access does work fine at the top level I suspect that it is merely a limitation of Altimit, rather than of the 'host:' protocol.

Best regards: dlanor
So like copy a file, prompt for a new name, and save that name. Delete the file then paste the same file over with the new name. This could work but then the date/time stamp of the file would change as well. :( Plus there could be all sorts of problems if it's not implemented correctly.

[E P]

Hum just copied a good chunk of stuff from ps2menu to do a few tests. I can now safely say that LaunchELF is based almost entirely off of ps2menu. :) So KaylaKaze could surely help us with some things if we could draft her.

Anyway I added ps2ip and ps2smap as builtins like in the ps2menu src as well as that getIpConfig function. Then I allowed the loading of ps2ftpd.irx from memory card and it worked none the less. Now I can ftp after loadHddModules is called. I wasn't sure if it would work but it suprised me. :) The changes may do something for getting true host support as well.

NOTE: I even transfered a file to my mounted main partition +MAIN this all while running LaunchELF in the background. There are bound to be problems since all I did was hack it all together. It is a start though, now if only I knew what SlicStik did to get all the partitions to show in the hdd folder.

[k0k0daimon]

Great job! Just wondering, is it possible to improve the USB compatibility of launchelf? It does not work with both of my USB thumbdrives, although they work with USBAdvance fine. I've tried using the latest USB.IRX versions without any luck.
Here's hoping the compatibility level would improve to at least the level of USBadvance...

Thanks!

[dlanor]

Hum just copied a good chunk of stuff from ps2menu to do a few tests. I can now safely say that LaunchELF is based almost entirely off of ps2menu. :) So KaylaKaze could surely help us with some things if we could draft her.
I think all these projects have borrowed from earlier ones, so they are all related to some degree. But I doubt that KaylaKaze will have time for this project, as she has (apparently) put several of her own projects 'on ice'.

Anyway I added ps2ip and ps2smap as builtins like in the ps2menu src as well as that getIpConfig function. Then I allowed the loading of ps2ftpd.irx from memory card and it worked none the less. Now I can ftp after loadHddModules is called. I wasn't sure if it would work but it suprised me. :)
I've tried this too, but the speeds I get are so slow that it's meaningless.
(appx 5 KBytes per second...).

The changes may do something for getting true host support as well.
That requires extensive additions to 'filer.c'. I have done it, getting host: working as well as it can (limited operations), and with a speed of appx 500Kbyte per second. The only R1-menu commands that can be implemented for it are 'Copy' and 'Get Size', but 'Copy' is the only important one in any case, as it allows stuff from the PC to be pasted into the PS2 HDD. (The command limitation is due to the driver implementation of PS2Client etc.)

I also managed to improve the subfolder functionality, so that it worked fine both for the work directory of PS2Client and for files and folders one level deeper. So with my 'Beatles' folder as work directory I could copy the 'Rubber Soul' Album folder in it, and all the MP3s it contained, in a single-object copy-paste operation. Those 33 MBytes then transferred to the PS2 HDD in appx 63 seconds.

Unfortunately I've run into some other problems though. (As usual, it's the module conflicts again.) So this version I'm working on is in no way ready for release.

NOTE: I even transfered a file to my mounted main partition +MAIN this all while running LaunchELF in the background.
Sure, the IOP has multithreading to allow independent servers. I even tried transferring stuff over FTP while browsing host:. It works, but I wouldn't implement such a combo in a release, as it can lead to conflicts.

There are bound to be problems since all I did was hack it all together. It is a start though, now if only I knew what SlicStik did to get all the partitions to show in the hdd folder.
I'm not sure what you mean, as the main problem I see with what ps2ftpd shows, is that it shows too many devices which it doesn't really support. Showing ALL partitions would just be more in that vein, as all the HDL partitions are useless for FTP.

Hmmm, what more to say? Oh, yeah, I found a bug in the 'copy' function of 'filer.c'. This bug will only strike if copying to a non-HDD destination with a write error occurring. The present code will then assume that the partial file is on memory card, and will use MC-specific functions to remove it. That is of course NOT a good idea if the real destination was not MC... You can find it at line 830 of filer.c from v3.41b, where it says:

outsize = fioWrite(out_fd,buff,buffSize);
if(buffSize!=outsize){
fioClose(out_fd); out_fd=-1;
mcSync(0,NULL,NULL);
mcDelete(out[2]-'0', 0, &out[4]);
mcSync(0, NULL, NULL);
goto error;
}
Naturally we want to change that to work for all non-HDD destinations, but that is tricky, as they need different functions. Fortunately we have a generic delete function defined in this very same file. So I suggest that we change the above sequence to the one below:
outsize = fioWrite(out_fd,buff,buffSize);
if(buffSize!=outsize){
FILEINFO *FI_p = &file;
fioClose(out_fd); out_fd=-1;
delete(out, FI_p);
goto error;
}

That should fix it, assuming that 'delete' lives up to expectations...

Another thing I did today was to fix the alternate sort order we discussed earlier. I simply split the current 'title' variable into two, 'title_show' and 'title_sort'. I changed the sort routine so it only sorts by 'title' if both 'title_show' and 'title_sort' are set, and made the display routine care only for 'title_show'. Finally I added some code where L1 caused the old 'title' to be toggled. I made it so that either L1 or L2 will toggle 'title_show', but with 'title_sort' being set by L1, but cleared by L2. And finally I changed the bottom line prompts (4 similar strings) from saying "L1:TitleON" to saying "L1/L2:TitleON" etc. So L1 displays titles sorted by titles, whereas L2 displays titles sorted by folder names.

Now, if I could only solve those wretched module init conflicts, I'd really have something, but so far I'm groping in the dark here. :(

Best regards: dlanor

[E P]

I've tried this too, but the speeds I get are so slow that it's meaningless.
(appx 5 KBytes per second...).

Really with ps2ftpd?, I get about 170 to a little more than 200 KB/sec. It took about 9 minutes to transfer 90 Megs worth of files to the hard drive.

Here is what I did:
I added a new function to MISC called PS2Net. Pressing a button that I assign it to runs my new stuff in main.c - loadNetModules(), getIpConfig(), and then loads ps2ftpd.irx from mc0:/SYS-CONF. It works quite well only real issue is if I open a hdd partion in LanchELf. It is mounted so when I connect via ftp I see it mounted with psf/0.

That requires extensive additions to 'filer.c'. I have done it, getting host: working as well as it can (limited operations), and with a speed of appx 500Kbyte per second. The only R1-menu commands that can be implemented for it are 'Copy' and 'Get Size', but 'Copy' is the only important one in any case, as it allows stuff from the PC to be pasted into the PS2 HDD. (The command limitation is due to the driver implementation of PS2Client etc.)
That's great I don't really want to touch it because I'm not sure how it all works. I have tried ps2client a few times but I wouldn't really know where to begin with implementing it into LaunchELF.

I also managed to improve the subfolder functionality, so that it worked fine both for the work directory of PS2Client and for files and folders one level deeper. So with my 'Beatles' folder as work directory I could copy the 'Rubber Soul' Album folder in it, and all the MP3s it contained, in a single-object copy-paste operation. Those 33 MBytes then transferred to the PS2 HDD in appx 63 seconds.

Unfortunately I've run into some other problems though. (As usual, it's the module conflicts again.) So this version I'm working on is in no way ready for release.
Neither is mine but wow 33 Mbytes in 63 seconds now that is fast. I had heard that host has less overhead. Module conflict was an issue here as well mostly with ps2ip.irx so I ended up using this in my loadNetmodules()
// if not running from ps2link or reset IOP is on, load ip module
if (elfload != 1 || resetIOP == 1)
SifExecModuleBuffer(&ps2ip_irx, size_ps2ip_irx, 0, NULL, &ret);


Sure, the IOP has multithreading to allow independent servers. I even tried transferring stuff over FTP while browsing host:. It works, but I wouldn't implement such a combo in a release, as it can lead to conflicts.

I'm not sure what you mean, as the main problem I see with what ps2ftpd shows, is that it shows too many devices which it doesn't really support. Showing ALL partitions would just be more in that vein, as all the HDL partitions are useless for FTP.
Yeah I agree there will most likely be conflicts with the loading of the ps2ftpd.irx module so it could be kept separate. Right now it loads only if found on memory card. I guess what I was thinking about was using my loadNetModules() as something that could work for what you're doing as well.

In regard to ps2ftpd showing too many devices, SlicStik changed this in ps2ftpd in release 0.65:
- "Dummy"-devices removed from ftp-client root listing. (now only shows mc,hdd and pfs)
If only I knew where to change this. :(
Getting the partitions to show up in the hdd folder is what could be used as a name reference nothing more. I did some checking and SlicStik must have made changes to the PlayStation 2 hdd.irx module. I don't even want to consider changing anything in the ps2sdk.

Ok I added your bug fix for 'copy' function of 'filer.c'. Thanks. It's also good to hear that you got alternate sort to work as well. :)

About problems with module conflicts I can give you my code changes to main.c, filer.c, and makefile if you want. I still don't trust making a release do to possible problems which I haven't encountered yet. Although if the changes I made keep working as they are now I may do so. :)

[dlanor]

Really with ps2ftpd?, I get about 170 to a little more than 200 KB/sec. It took about 9 minutes to transfer 90 Megs worth of files to the hard drive.
With execftps 0.69 I get speeds similar to yours, but when I tried with ps2ftpd in LaunchELF I got those superslow speeds. Maybe it was just some glitch... I'll have to experiment more with it to find that out. But I've been concentrating on other things, since I knew you were already working on the FTP case.

Here is what I did:
I added a new function to MISC called PS2Net. Pressing a button that I assign it to runs my new stuff in main.c - loadNetModules(), getIpConfig(), and then loads ps2ftpd.irx from mc0:/SYS-CONF. It works quite well only real issue is if I open a hdd partion in LanchELf. It is mounted so when I connect via ftp I see it mounted with psf/0.
My conflict is far worse. It makes LaunchELF show garbage when browsing the HDD. No garbage is placed on disk though, it's just shows garbage instead of any real partitions.

Preprogrammed launch buttons for ELFs on HDD still work, but browsing any HDD partitions is impossible. It doesn't happen all the time though, and it never happens if I run LaunchELF from PS2Link, probably because I then just keep some of the modules loaded by PS2Link so I never have to load them internally (ps2ip, ps2smap, ps2host). If I run it another way (without those modules), or when doing IOP reset (invalidating modules), then I do have to load those modules, and then HDD access gets messed with as described.
(Naturally, I'm not sure which module causes it. It could be another one.)

That's great I don't really want to touch it because I'm not sure how it all works. I have tried ps2client a few times but I wouldn't really know where to begin with implementing it into LaunchELF.
I borrowed an IRX module from Altimit, and checked out how it had been used there. Of course, I couldn't (and wouldn't) use exactly the same methods in LaunchELF (Altimit is CPP), but it wasn't too hard to recode it into more appropriate form. The tricky bit was to implement both the 'elflist.txt' method and free browsing. The latter is still limited to a depth of one folder level below work directory, but I did extend the 'elflist.txt' usage, so it can also include paths to folders (not just files as in Altimit), and can also refer to stuff on different PC drives. So in fact the 'elflist.txt' provides even wider browsing range if you put some effort into making a useful list.

The nice thing about 'host:' is that you don't have a server process constantly stealing system resources. It's just a device driver hanging around until you call it. The server part is on the PC where resources don't matter to us ;), and even there it doesn't need to run constantly. When I want to transfer something from a folder I just drag-drop that folder to a shortcut on the desktop, which launches ps2client.exe in 'listen' mode with that folder as work directory. Then I can browse to 'host:' on the PS2 to copy my stuff, and afterwards I just close the console window on the PC. This drag-drop method is the reason I don't think it matters much that 'free browsing' is so limited.

Neither is mine but wow 33 Mbytes in 63 seconds now that is fast. I had heard that host has less overhead.
Well, as you can see from the above, there is really NO overhead. Any output method requires some device driver, so that is no overhead, and this device driver sends the stuff directly to the network drivers. The only overhead costs for the server are at the PC end, so don't concern the PS2.

Module conflict was an issue here as well mostly with ps2ip.irx so I ended up using this in my loadNetmodules()
// if not running from ps2link or reset IOP is on, load ip module
if (elfload != 1 || resetIOP == 1)
SifExecModuleBuffer(&ps2ip_irx, size_ps2ip_irx, 0, NULL, &ret);

How did you identify the 'elfload' case ?
I have no way myself of telling the difference between a launch by ps2Link and a launch from HDD by LaunchELF, or any other launcher using 'fakehost'. In both cases I see the same launch arguments with argc==1 and "host:BOOT.ELF" in argv[0]. For the present I just 'pretend' that 'host:' means PS2Link, but with 'fakehost' launching that is untrue.

Yeah I agree there will most likely be conflicts with the loading of the ps2ftpd.irx module so it could be kept separate.
In fact I see no module conflict at all with this one, but the mere fact that it has been launched does create a running server, and each FTP call will create new instances of that server... (Possibly not cleaned out properly if an FTP client 'goes AWOL'.) So I agree that this should not be running by default.

Right now it loads only if found on memory card. I guess what I was thinking about was using my loadNetModules() as something that could work for what you're doing as well.
It might, but if it is to be supported, then I'd rather have it built-in. It's still possible to launch it with a MISC/ command that way, so that' how I'd do it. On the other hand, you could develop your way into a generic method for launching IRX programs...

In regard to ps2ftpd showing too many devices, SlicStik changed this in ps2ftpd in release 0.65:
- "Dummy"-devices removed from ftp-client root listing. (now only shows mc,hdd and pfs)
If only I knew where to change this. :(
The ps2ftpd sources are available, so it's just a matter of getting time for digging into it.

Hmm, I just found something interesting in FileSystem.c of ps2ftpd:
// get module

num_devices = FS_IOMANX_DEVICES;
dev_offset = DEVINFO_IOMANX_OFFSET;
if( NULL == (pkModule = FileSystem_GetModule(IOPMGR_IOMANX_IDENT)) )
{
dev_offset = DEVINFO_IOMAN_OFFSET;
num_devices = FS_IOMAN_DEVICES;
if( NULL == (pkModule = FileSystem_GetModule(IOPMGR_IOMAN_IDENT)) )
return -1;
}

// scan filesystem devices

ppkDevices = DEVINFOARRAY(pkModule,dev_offset);
while( pContext->m_kFile.unit < num_devices )
{
int unit = pContext->m_kFile.unit;
pContext->m_kFile.unit++;

if( !ppkDevices[unit] )
continue;

if( !(ppkDevices[unit]->type & IOP_DT_FS) )
continue;

strcpy(pInfo->m_Name,ppkDevices[unit]->name);
pInfo->m_iSize = 0;
pInfo->m_eType = FT_DIRECTORY;

return 0;
}
To me that looks like it's building the device list you mentioned, so this can be pruned right there, by checking for the names of useful devices. But I'm even more intrigued by the idea of using a similar method to identify loaded modules, of any kind. If that works right, it just might solve most of our worries !!!

Getting the partitions to show up in the hdd folder is what could be used as a name reference nothing more. I did some checking and SlicStik must have made changes to the PlayStation 2 hdd.irx module. I don't even want to consider changing anything in the ps2sdk.
Why not? It can be done in perfect safety.
Here are some tips on how to do that sort of thing.

I have four versions of ps2sdk installed myself, two of which are selfcompiled, and I can easily switch between them just by modifying a symbolic link, for which I have four simple two-line shell scripts. Like shown below:

ps2sdk-1.1.sh == for activating ps2sdk official release v1.1
rm -f $PS2DEV/ps2sdk
sln -s $PS2DEV/_ps2sdk/ps2sdk-1.1 $PS2DEV/ps2sdk

ps2sdk-1.2.sh == for activating ps2sdk official release v1.2
rm -f $PS2DEV/ps2sdk
sln -s $PS2DEV/_ps2sdk/ps2sdk-1.2 $PS2DEV/ps2sdk

ps2sdk-2005.04.17.sh == for activating ps2sdk compiled from CVS of 2005.04.17
rm -f $PS2DEV/ps2sdk
ln -s $PS2DEV/_ps2sdk/ps2sdk-2005.04.17 $PS2DEV/ps2sdk

ps2sdk-2005.06.11.sh == for activating ps2sdk compiled from CVS of 2005.06.11
rm -f $PS2DEV/ps2sdk
ln -s $PS2DEV/_ps2sdk/ps2sdk-2005.06.11 $PS2DEV/ps2sdk

After using any of the above scripts the symbolic link "ps2sdk" in my $PS2DEV folder will point to the selected ps2sdk installation folder. Now, my $PS2SDK variable is set to "$PS2DEV/ps2sdk" so this will use the symbolic link, causing all tools and sources referring to it, to in fact use the currently selected ps2sdk folder indicated by the link. (Typically "$PS2DEV/_ps2sdk/ps2sdk-2005.06.11/")

I use a similar technique with symbolic links for all ps2 dev libs that I may need different versions of, such as libito, ps2lib, libcdvd, and more. For all such I can select the active version simply by using a script to modify the corresponding symbolic link.

And of course, I keep the sources (when available, like for ps2sdk) of each version in separate folders too. (It's important to copy them from CVS to some other place before compiling, to avoid CVS hassles.)

With this method it would be a cinch to create a fifth ps2sdk version, say "$PS2DEV/_ps2sdk/ps2sdk_experimental_1/". Activate this through the means described above, and then compile the modified ps2sdk files.

Three warnings though:
1: Symbolic links do NOT work with normal Windows DOS commands.
You MUST use the bash environment PROPERLY to ensure that only the Cygwin tools are used. (E P: The fact that you still use 'del' in the makefile could mean that you use the windows shell to invoke 'make'. That is NOT safe with my methods.)

2: You need to keep track of what libs you have active in each link.
This is easiest done simply by opening $PS2DEV in an explorer window, and just pointing the mouse at any symbolic link (look like a windows shortcuts), at which a 'tooltip' will display what folder it links to.

3: Symbolic links are NOT identical to Windows shortcuts.
Cygwin style symbolic links will appear like normal Windows shortcuts when inspected in explorer, but they are NOT identical. If you create a normal shortcut in windows it will NOT be a valid symbolic link to Cygwin tools.

Ok I added your bug fix for 'copy' function of 'filer.c'. Thanks. It's also good to hear that you got alternate sort to work as well. :)

About problems with module conflicts I can give you my code changes to main.c, filer.c, and makefile if you want. I still don't trust making a release do to possible problems which I haven't encountered yet. Although if the changes I made keep working as they are now I may do so. :)
Please post the stuff you have, or PM me about it, if you prefer. Some of the things we deal with may be a bit 'heavy' for handling in the forum anyway, as very few others would be interested in the hardcore techie stuff.

Edit:
I've investigated the 'device list' stuff mentioned above (re: ps2ftpd). That stuff was apparently inspired by the 'sbv_patches' lib, which we already use with LaunchELF. It contains all we need to build a search function that can directly scan the module lists, to eliminate all the current guesswork as to whether or not a module has been loaded. This info, while blatantly obvious to any devers already familar with that stuff, is a major breakthrough for me, as I can now check (rather than guess) the initial launch state.

It doesn't solve everything, but a lot. For example: while I can not detect whether or not mcInit has been used previously, I can at least detect the presence of MCMAN and MCSERV. I'm still at a very early stage in these experiments, so I'll get back later with more info on how it works in real use.

Best regards: dlanor

[E P]

Thanks for all the info dlanor, I also found that function in ps2ftpd after posting my prior message. :)

I understand the garbage you're talking about. I discussed this before with mcjules. I had to use an older version of iomanX.irx.

OK here is a src package with changes to main.c, config.c, filer.c, and the Makefile. I have also included a modules folder with the IomanX.irx that the makefile points to. The ps2ftpd.irx module is also included with src changes in the ps2ftpd directory.

No diffs this time or LaunchELF binary since this is not a true release but here are the changes so far:
-Added config name to both failure messages (Name of config that failed to load/save).
-Added preliminary ftp support through new MISC item "PS2Net". (Note: Need both ps2ftpd.irx and IPCONFIG.DAT, edited with proper network settings, in mc0:\SYS-CONF\).
-Added dlanor's bug fix for the copy function.

[dlanor]

I'm in the middle of some hectic testing, but I just wanted to tell you a few things.

First, something I should have told you earlier, but forgot...:
It is possible to compile LaunchELF with the very latest ps2sdk if you just edit launchelf.h to move the "#include <ito.h>" down by at least 7 lines, so it comes after the "#include <string.h>". This is because itomisc.h defines a bzero macro, which messes up the inline definition of bzero that string.h contains.

Second, I just wanted to tell you that things are looking up at my end. The module checking enabled by the 'subversion' lib is working, except for a few modules that don't use any proper module names. Fortunately I can identify these cases by other means (argc, argv), so it seems to work out, though I'm not quite done yet. The only real problem so far was that the old 'subversion' package we were using ("sbv-1.0-lite") was bugged, and locked up my check functions. So I linked to the new 'subversion' package instead (part of ps2sdk), and then it works fine.

Best regards: dlanor

[E P]

I'm in the middle of some hectic testing, but I just wanted to tell you a few things.

First, something I should have told you earlier, but forgot...:
It is possible to compile LaunchELF with the very latest ps2sdk if you just edit launchelf.h to move the "#include <ito.h>" down by at least 7 lines, so it comes after the "#include <string.h>". This is because itomisc.h defines a bzero macro, which messes up the inline definition of bzero that string.h contains.
I noticed this when you mentioned it at the ps2dev forums. Personally I just used a prior one from a few weeks earlier and that string.h file works fine. No extra warnings and no need to change launchelf.h. :)

Second, I just wanted to tell you that things are looking up at my end. The module checking enabled by the 'subversion' lib is working, except for a few modules that don't use any proper module names. Fortunately I can identify these cases by other means (argc, argv), so it seems to work out, though I'm not quite done yet. The only real problem so far was that the old 'subversion' package we were using ("sbv-1.0-lite") was bugged, and locked up my check functions. So I linked to the new 'subversion' package instead (part of ps2sdk), and then it works fine.

Best regards: dlanor
I never used sbv-1.0-lite for any of my released builds. I always used the one that was integrated into the SDK. My included make file also shows this. ;)

I think I got ps2ftpd to only show pfs and mc as folders in ftp client side. So the user won't see all of those dummy directories. :) Thanks for the assistance.

OK Here it is: if( strcmp(ppkDevices[unit]->name, "mc") && strcmp(ppkDevices[unit]->name, "pfs") ) return 0;

ppkDevices = DEVINFOARRAY(pkModule,dev_offset);
while( pContext->m_kFile.unit < num_devices )
{
int unit = pContext->m_kFile.unit;
pContext->m_kFile.unit++;

if( strcmp(ppkDevices[unit]->name, "mc") && strcmp(ppkDevices[unit]->name, "pfs") )
return 0;

if( !ppkDevices[unit] )
continue;

if( !(ppkDevices[unit]->type & IOP_DT_FS) )
continue;

strcpy(pInfo->m_Name,ppkDevices[unit]->name);
pInfo->m_iSize = 0;
pInfo->m_eType = FT_DIRECTORY;

return 0;
}

[dlanor]

Thanks for the ps2ftpd fix. Fixing that and integrating it with a MISC command like you did is next on my list of changes. I've reached most of my targets for my own changes.

Here's the main news:
host: now allows free browsing regardless of folder depth. Without elflist.txt this only applies to the work directory of ps2client.exe and all subfolder levels of that, but with elflist.txt you can add links to any drive and folder on the pc. Adding one such link for each drive root allows browsing the entire PC filesystem from the PS2... Only one problem remains, and that is the ELF type checking. I'll need to work on that, as selecting a nonelf file will currently cause lockup when LaunchELF tries to execute it.
(This only happens on host: )

The iomanX module you posted helped with the HDD garbling, and the module check routines I made have eliminated ALL module conflicts.

The only problem that then remained was the inability to use mcInit both before and after IOP reset. I found the reason for that in the source for libmc, and have now recompiled ps2sdk with that limitation fixed. My present version successfully uses mcInit both before and after the reset. What I did was to add an init type to use for telling the lib that the module is dead, so after IOP reset I first use the new call mcInit(MC_TYPE_RESET), and then I am free to use mcInit(MC_TYPE_MC) again (after reloading MCMAN+MCSERV of course). I posted my changes at ps2dev.org, and there's some hope that equivalent changes will be adopted by the official version. (Not just for libmc, but others too.) One important consequence of such fixes is that it allows us to reset IOP to avoid module conflicts with ELFs to be launched. Otherwise it would be impossible to launch ExecFTPs or PS2Link directly after using host: or ps2ftpd in LaunchELF. (Just some eamples. Other conflict variants also exist.)

Now I'm going to try combining your stuff with mine and will probably post a test version here later today.

Best regards: dlanor

[E P]

Wow, that all sounds great but just a word of warning I accidently left in mcRename in my changes so you might want to leave it out. I doubt it will hurt anything.

[dlanor]

Wow, that all sounds great but just a word of warning I accidently left in mcRename in my changes so you might want to leave it out. I doubt it will hurt anything.
I copied it over into my source too, knowing full well that it doesn't work at present, but maybe we can get a grip on that later some time. I've now finished combining stuff, so now it just remains to test it... Most things work as I expected, including the still dubious results with Dev.2 booting.
(Lets face it, that launch method is NOT well implemented.)

As for the host: interface, this loads the needed modules and initializes them when you select host: as browser device. This means that it's nearly impossible to get server (ps2client) and client (LaunchELF) to start communicating in one try. Here's how I do it. Normally I go to host: in LaunchELF first. Without server this times out shortly showing an empty dir,, at which I back out to the device list. Next I launch ps2client on the PC, and then again select the host: device in LaunchELF, which then connects and shows the directory from the PC. Of course, if you start LaunchELF from PS2Link (without IOP reset), then host: will work at once, as the modules are already loaded.

One thing to remember, both for host: and the FTP server, is that when either (or both) of these have been used it will not be possible to launch other ELFs that also need to use the network modules, unless you first restart LaunchELF in a folder where you have CNF files that command an IOP reset.

Ideally LaunchELF should be able to detect the need for such things, or at least we humans should be able to do it directly (new MISC command RESET), but we need further lib improvements and extended module recognition to make it possible to do such things safely (without crashing or losing control of some interfaces).

There's a lot more work to be done to resolve all these issues, but at least we have now found some of the tools and methods that allow us to tackle them.

Edit: I almost forgot. At present my host: interface relies on how the Windows version of ps2client works, demanding backslash paths in the low-level access functions. Code is in place to allow use of forward slashes instead, to fit low-level functions on linux systems, but that code is not yet activated. So for the present it probably won't work with linux versions of ps2client.

Best regards: dlanor

[E P]

Wow dlanor, that's a lot of changes. Real nice. :)
Only two issues that I've noticed so far.
1. Net config: doesn't show the entire settings string in main msg. It only shows "Net config ".
2. Boot problems with exploit when iop reset is on. (noted in the changes file)

Hum, maybe the exploit problem is do to the fact that your changes to mcInit() need to be applied to a new binary of title.db. So perhaps the exploit needs to be recompiled with your changes to mclib?

I recompiled the sdk with your changes to libmc.c and libmc.h. So now I can get your changes integrated into my own builds of launchELF for future releases.

edit: I made a workaround for issue number one all I did was set char netConfig[MAX_PATH] = "";

edit 2: I found another way to crash this release just run BOOT.ELF from the pc side via ps2link and inlink with reset IOP on. Looks like Reset IOP is truely broken now. :(

[jackielo]

E_P & dlanor,

Thanks for your keeping enhance LaunchELF.

Wiith the font file ELISA100.FNT, original 3.41 can display Japanese title when i push L1. But with the latest 3.41c, it is not work.

Can you correct this issue? Tks.

[dlanor]

Wow dlanor, that's a lot of changes. Real nice. :)
Only two issues that I've noticed so far.
1. Net config: doesn't show the entire settings string in main msg. It only shows "Net config ".
2. Boot problems with exploit when iop reset is on. (noted in the changes file)
1: I'll fix that next time, so it shows the settings properly.
2: Yes, there are still issues with IO reset that need resolving. We don't have all relevant info on possible initial launch states, and some IOP modules in use have no identifiers. Checking for their presence is not possible by any standard means. Ideally IOP reset should restore everything to a clean state, and the EELOADCNF we specify should alter that to a normal bootup state. But the real situation is not quite that simple. We have some work to do before we can use IOP reset in all the ways we want/need to. But well get there eventually, I'm sure of that.

Hum, maybe the exploit problem is do to the fact that your changes to mcInit() need to be applied to a new binary of title.db. So perhaps the exploit needs to be recompiled with your changes to mclib?
No I don't think that's the reason. When we use mcInit the exploit has already completed its work, and handed control over to us. The only EE routines for libmc that are then active are the ones inside LaunchELF, including my changes. However, my change was only intended to allow mcInit to send the proper command to a newly loaded MCMAN+MCSERV combo, nothing else. That does not mean it can solve any other potential conflicts with modules that were active/missing at exploit activation and modules needed/loaded by LaunchELF.

I recompiled the sdk with your changes to libmc.c and libmc.h. So now I can get your changes integrated into my own builds of launchELF for future releases.
Good. This means we can both keep up to date with other changes too, which we may need to make in relation to IOP reset. I'm afraid the PS2SDK (and all older dev libs) have completely ignored the possibility of IOP reset being used anywhere else than at the initial stage of a program, before any modules at all are used. They also ignore complications caused by modules inherited from launching programs, that still remain present with the programs they launch if no IOP reset is used at program init. And that is what has caused most of the problems for us, since a program like LaunchELF must be able to deal with situations of both those kinds, which most programs can ignore.

edit: I made a workaround for issue number one all I did was set char netConfig[MAX_PATH] = "";
That's a good change to make in any case, as uninitialized strings or pointers are a common source of problems. But the real error should be somewhere in getIpConfig. It should set up that string in all cases, regardless of the presence or contents "IPCONFIG.DAT".

edit 2: I found another way to crash this release just run BOOT.ELF from the pc side via ps2link and inlink with reset IOP on. Looks like Reset IOP is truely broken now. :(
I don't check you on this. When I try this, it works just fine.
I can even use an endless cycle, like this:

1: Boot up LaunchELF on your PS2 (by any reliable means)
2: Start InLink on your PC (v1.3.7) in a folder containing LAUNCHELF.CNF set up for IOP reset
3: Use LaunchELF to launch PS2Link (v1.24 from MC)
4: Wait for InLink to show 'Connected'
5: Use Inlink to send BOOT.ELF or BOOTC.ELF to the PS2
6: Once LaunchELF has booted, go back to step 2 above.

I can go through that loop any number of times, using either BOOT.ELF or BOOTC.ELF, and I have also tested that the IOP reset really has worked in these cases (each new LaunchELF instance can copy stuff from mass:, which demands IOP reset when restrarted). And of course I can do the same using ps2client instead of InLink (that is my most common test method).

So I don't know what causes your problem, but it doesn't seem to be the IOP reset as such. Maybe we have a version issue here (I use a PAL v9 PS2) ?!?

Edit:
Possibly your problem occurred in trying to browse host: with InLink as server. That will not work at all, as InLink is not fully compatible with the host: interface of ps2client. It works just barely enough to read simple files (like LAUNCHELF.CNF for instance), but browsing will not work at all. For that you must use ps2client instead.

Best regards: dlanor

[lonwern]

E_P & dlanor,

Thanks for your keeping enhance LaunchELF.

Wiith the font file ELISA100.FNT, original 3.41 can display Japanese title when i push L1. But with the latest 3.41c, it is not work.

Can you correct this issue? Tks.
Yes,i get the same problem

[E P]

No I don't think that's the reason. When we use mcInit the exploit has already completed its work, and handed control over to us. The only EE routines for libmc that are then active are the ones inside LaunchELF, including my changes. However, my change was only intended to allow mcInit to send the proper command to a newly loaded MCMAN+MCSERV combo, nothing else. That does not mean it can solve any other potential conflicts with modules that were active/missing at exploit activation and modules needed/loaded by LaunchELF.
Yeah, I looked at the exploit source, payload.c, and mcInit is never used so I was wrong.

I don't check you on this. When I try this, it works just fine.
I can even use an endless cycle, like this:

1: Boot up LaunchELF on your PS2 (by any reliable means)
2: Start InLink on your PC (v1.3.7) in a folder containing LAUNCHELF.CNF set up for IOP reset
3: Use LaunchELF to launch PS2Link (v1.24 from MC)
4: Wait for InLink to show 'Connected'
5: Use Inlink to send BOOT.ELF or BOOTC.ELF to the PS2
6: Once LaunchELF has booted, go back to step 2 above.

I can go through that loop any number of times, using either BOOT.ELF or BOOTC.ELF, and I have also tested that the IOP reset really has worked in these cases (each new LaunchELF instance can copy stuff from mass:, which demands IOP reset when restrarted). And of course I can do the same using ps2client instead of InLink (that is my most common test method).

So I don't know what causes your problem, but it doesn't seem to be the IOP reset as such. Maybe we have a version issue here (I use a PAL v9 PS2) ?!?
I did what you said above only through exploit and got a crash with IOP reset on. So exploit is not a reliable means of running LaunchELF I take.

I'm now back to using my old BOOT.ELF to run this release. My old custom BOOT.ELF resets IOP before executing the new c version. I just have to leave Reset IOP off for LaunchELF 3.41c.

In other words exploit -> custom BOOT.ELF -> LaunchELF 3.41c
I also even modified the exploit by adding reset IOP to payload.c. However, it's probably better to just use my cusom BOOT.ELF since some other programs use execute boot.elf on exit. Of course, that's a whole new can of worms when LaunchELF crashes after MP3SE tries to launch it. I believe that issue is do either to the elf's compression or a poorly implemented runELF function in MP3SE.

[dlanor]

E_P & dlanor,

Thanks for your keeping enhance LaunchELF.

Wiith the font file ELISA100.FNT, original 3.41 can display Japanese title when i push L1. But with the latest 3.41c, it is not work.

Can you correct this issue? Tks.
Thanks a lot for the error report. This is a problem I can't test myself as I have only games from US and Europe. (Except for FFX International, which uses English for save names.)

I will of course try to fix this, but I need some save to test it with. And this should by preference be a save that you have seen the problem occur for. In other words, as save that has this problem with the unofficial LaunchELF release, but no problem with official LaunchELF v3.41. If I try to find a save myself, I might still wind up with one that doesn't show the problem...

If you just post a relevant save here, I will get on the problem ASAP.
Best Regards: dlanor

[E P]

Hum interesting I used my new TITLE.DB with changes to payload.c and LaunchELF v3.41c as my BOOT.ELF. It works ok on boot even with resetIOP on. Still doesn't through Ps2Link with Inlink though. However, It can execute itself again and again with reset IOP on. Something still must still be there to cause trouble in places.

[dlanor]

Yeah, I looked at the exploit source, payload.c, and mcInit is never used so I was wrong.

I did what you said above only through exploit and got a crash with IOP reset on. So exploit is not a reliable means of running LaunchELF I take.
It should be, and once we find out why the present problem occurs it will be made reliable, one way or another. ;)

Unfortunately I have serious problems testing exploit booting myself, as each attempt to boot the exploit CD consumes several minutes, regardless of whether the attempt is successful or not. My PS2 laser is dying, getting worse all the time. Reading DVDs has been totally impossible for months, and now CD capabilities are slowly going too... :(

I shall try to fix this, by making a new exploit file using more IDs, so I have more disks to try with, and also by burning CD-Rs of some trigger games. Since I have a chipped console that too should work. Hopefully this can cut down the exploit boot time, but if not then I'm going to have a hard time testing this stuff.

I'm now back to using my old BOOT.ELF to run this release. My old custom BOOT.ELF resets IOP before executing the new c version. I just have to leave Reset IOP off for LaunchELF 3.41c.

In other words exploit -> custom BOOT.ELF -> LaunchELF 3.41c
I also even modified the exploit by adding reset IOP to payload.c. However, it's probably better to just use my cusom BOOT.ELF since some other programs use execute boot.elf on exit. Of course, that's a whole new can of worms when LaunchELF crashes after MP3SE tries to launch it. I believe that issue is do either to the elf's compression or a poorly implemented runELF function in MP3SE.
I have never, ever, been able to use that capability of PS2MP3SE.
It has crashed every time, with every version of LaunchELF I've tried it with.
I know that others have used it, but I never could. (PS2 version diffs ?)

Whatever the cause of that may be, I don't think that failures of that kind say much of anything about LaunchELF, or how we can improve it. The important thing to find out here is why IOP reset doesn't seem to work with the exploit, or with Dev.2 booting. For the latter I too use a method like yours, but with a variation. I do boot v3.41c, but without IOP reset, then I use that to boot another instance of itself, this time with IOP reset, which then works right.

Apparently there are conditions where IOP reset doesn't work right, and we must experiment a bit more to find out why, and how to work around it. The experiments already made do prove that a workaround is possible, so now we just need to find more details, so we can do it without launching any 'extra' ELFs.

Best regards: dlanor

[dlanor]

Hum interesting I used my new TITLE.DB with changes to payload.c and LaunchELF v3.41c as my BOOT.ELF. It works ok on boot even with resetIOP on. Still doesn't through Ps2Link with Inlink though. However, It can execute itself again and again with reset IOP on. Something still must still be there to cause trouble in places.
That must indeed be the case, and the problem is to find out exactly why it happens, or at least some reliable way to cure it. Could you please post the changed payload.c plus a link to the original source you used it with. I want to try some variations on that theme, and I'd prefer to start with a combo that worked for you. (Might save time.)

Best regards: dlanor

[E P]

That must indeed be the case, and the problem is to find out exactly why it happens, or at least some reliable way to cure it. Could you please post the changed payload.c plus a link to the original source you used it with. I want to try some variations on that theme, and I'd prefer to start with a combo that worked for you. (Might save time.)

Best regards: dlanor

Sure here are the changes I made to payload.c
from this:
/* Let's go. */
argv[0] = mc_boot;

fioExit();
SifResetIop();

FlushCache(0);
FlushCache(2);

ExecPS2((void *)eh->entry, 0, 1, argv);

to this:
/* Let's go. */
argv[0] = mc_boot;

fioExit();

SifIopReset("rom0:UDNL rom0:EELOADCNF",0);
while(SifIopSync());
fioExit();
SifExitIopHeap();
SifLoadFileExit();
SifExitRpc();
SifExitCmd();

SifInitRpc(0);

FlushCache(0);
FlushCache(2);

ExecPS2((void *)eh->entry, 0, 1, argv);


You can get the source from mr. browns page "ps2-id-0.1", but since it's down go to PS2SaveTools (http://www.ps2savetools.com/). It's in the downloads PS2 Independence Exploit section. It is listed as the Exploit Source package.

What you'll need to do to compile the package is change the PS2LIB's to PS2SDK in the makefile for compiling with the newer SDK.

Once you have made the necessary changes to payload.c, you need to strip the ELF header and copy all but some of the extra parts of the bottom. You will then need to copy this over the prior code with a hex editor in TITLE.DB.

If you need any futher assistance just ask. :)

[dlanor]

What you'll need to do to compile the package is change the PS2LIB's to PS2SDK in the makefile for compiling with the newer SDK.

Once you have made the necessary changes to payload.c, you need to strip the ELF header and copy all but some of the extra parts of the bottom. You will then need to copy this over the prior code with a hex editor in TITLE.DB.

If you need any futher assistance just ask. :)
I think I'll manage, but if not I'll get back to you on that. To begin with, I think I'll try making some more tests to see if I can make it work right with the normal exploit. If those tests fail, I'll have to experiment with variations of the exploit code, to see exactly what it needs.

Best regards: dlanor

[dlanor]

Hum interesting I used my new TITLE.DB with changes to payload.c and LaunchELF v3.41c as my BOOT.ELF. It works ok on boot even with resetIOP on. Still doesn't through Ps2Link with Inlink though. However, It can execute itself again and again with reset IOP on. Something still must still be there to cause trouble in places.
Our results still don't check...:

When I boot standard exploit using LaunchELF v3.41c as BOOT.ELF, with IOP reset configured OFF (in mc0:/BEDATA-SYSTEM/LAUNCHELF.CNF), then I can use PS2Link+InLink as described previously, in the endless loop of launching LaunchELF v3.41c with IOP reset configured ON (using host:LAUNCHELF.CNF), and this works fine for me.

I don't understand why the same thing doesn't work for you...!?!

Even here, it is still an error that I can't use IOP reset with the exploit-launched LaunchELF v3.41c, and I'll try to fix that, but even if/when I succeed, I can't trust such a fix to work for you too, if we get different results on the PS2Link tests.

Best regards: dlanor

[E P]

Our results still don't check...:

When I boot standard exploit using LaunchELF v3.41c as BOOT.ELF, with IOP reset configured OFF (in mc0:/BEDATA-SYSTEM/LAUNCHELF.CNF), then I can use PS2Link+InLink as described previously, in the endless loop of launching LaunchELF v3.41c with IOP reset configured ON (using host:LAUNCHELF.CNF), and this works fine for me.

I don't understand why the same thing doesn't work for you...!?!
Yeah it's weird I have mine set up the same way in mc0:/BADATA-SYSTEM/LAUNCHELF.CNF. No mod chip though and I'm using PS2LINK 1.30. So far I've tried my own compile of the exploit, the original one, and the crazyc modified one. They all have the same issue with ps2link. Maybe it's my embeded compiled version of ps2link although I haven't ever had problems with it before. (NOTE: Don't compile a new one from ps2dev as currently there are now problems with older apps like ps2menu). I got an older version I can test out later but are you using an irx embeded version?


Even here, it is still an error that I can't use IOP reset with the exploit-launched LaunchELF v3.41c, and I'll try to fix that, but even if/when I succeed, I can't trust such a fix to work for you too, if we get different results on the PS2Link tests.

Best regards: dlanor
I agree I'll see if I can test an older version of ps2link.

OK it works with 1.24 just tested non embeded though. :chinscrat

[jackielo]

Thanks a lot for the error report. This is a problem I can't test myself as I have only games from US and Europe. (Except for FFX International, which uses English for save names.)

I will of course try to fix this, but I need some save to test it with. And this should by preference be a save that you have seen the problem occur for. In other words, as save that has this problem with the unofficial LaunchELF release, but no problem with official LaunchELF v3.41. If I try to find a save myself, I might still wind up with one that doesn't show the problem...

If you just post a relevant save here, I will get on the problem ASAP.
Best Regards: dlanor

I post a attachment with 3 Japanese game's save file. Thanks. :)

[E P]

So dlanor we seem to be on the same page now. I'm currently using my own altered version of the exploit with Reset IOP and it works great. Also I have kept Reset IOP on at all times with LaunchELF. I'm using my own compiled version of LanchELF based on your source changes. It can execute itself again and again. It can also run via pc side with ps2link 1.24 as well with reset IOP on. I just need to figure out why the embeded 1.30 I made a few months ago has problems when Reset IOP is on. It could be any number of things like Highload version, its irx's are embeded, etc. Ps2link 1.30 hasn't let me down until now. :banghead:

[HypERSoniC]

BUG: When copying a file from a non-renamable device to a renamable device, rename will still be greyed out when you use X to highlight the file, then bring up the submenu. (its not meant to be greyed out)

The rename is not greyed out when you dont use X to highlight the file. (correct functionality)

ISSUE: Program freezes(keeps trying to access host) when not run from host: and host: is selected until the na driver gets the poweroff signal... so maybe inplement a timeout?

----------

PS2Menu writes corrupted files when they are read from host and written to HDD. Does LaunchELF do this aswell?(a possibility if the host: code was copied from ps2menu)

[dlanor]

So dlanor we seem to be on the same page now. I'm currently using my own altered version of the exploit with Reset IOP and it works great. Good, but it shouldn't be needed any more, as I've fixed the bug ;)
All kidding aside, I do think you should go back to the more primitive standard version of the exploit, simply because it is the standard. That is what most others will be using, so you need it to test compatibility of new stuff.

Also I have kept Reset IOP on at all times with LaunchELF.
That is definitely to be preferred, as it makes LaunchELF more independent of other launchers, and prelaunch conditions. Without IOP reset some capabilities can be handicapped by 'inherited' IOP modules. (eg: dysfunctional mass: etc.)

I'm using my own compiled version of LanchELF based on your source changes. It can execute itself again and again. It can also run via pc side with ps2link 1.24 as well with reset IOP on. I just need to figure out why the embeded 1.30 I made a few months ago has problems when Reset IOP is on. It could be any number of things like Highload version, its irx's are embeded, etc. Ps2link 1.30 hasn't let me down until now. :banghead:
I have heard of problems with newer versions than v1.24 earlier, and of course older versions lack capabilities, so v1.24 is the only version both fully safe and fully capable. Some other time I might be tempted to look into those issues, but currently I don't have time for that.

And now for some good news about LaunchELF v3.41d:
(Quoted from the new changes.txt)

-Fixed bug from v3.41c, causing IOP reset to fail in some cicumstances
This was fixed by not using initsbv_patches before IOP reset.
For future updates, we need to be aware of possible conflicts with this.
-Fixed bug from v3.41c, causing Net Config values to not be displayed.
NB: Matrix Infinity Dev.2 boot works for either ELF, with or without IOP reset.
NB: Matrix Infinity Dev.1 boot works for either ELF, with or without IOP reset.
NB: Exploit boot works with either ELF, with or without IOP reset.

Btw: I made some more patches for ps2sdk, but these are not used yet. They are intended to help libpad (and padx) recover from IOP reset, so that we can use that freely in some later version. But at present that still won't work, so that section of LaunchELF source is commented out for now.

Best regards: dlanor

[HypERSoniC]

ps2bins updated

[E P]

Thanks for the new fixes dlanor, I've now switched back to the normal exploit again. :)

OK now for a good laugh my compiled PS2LINK 1.30 works fine with the new 3.41d. :D

[dlanor]

BUG: When copying a file from a non-renamable device to a renamable device, rename will still be greyed out when you use X to highlight the file, then bring up the submenu. (its not meant to be greyed out)

The rename is not greyed out when you dont use X to highlight the file. (correct functionality)
I'll look into this later, but as you still can rename it, this is not a top priority fix.

ISSUE: Program freezes(keeps trying to access host) when not run from host: and host: is selected until the na driver gets the poweroff signal... so maybe inplement a timeout?
That might be appropriate, but as yet I've made no major change to the ps2host module, and I do NOT see any freezing normally. I believe the freezing you see is due to the lack of IOP reset, with which the previous version (v3.41c) of LaunchELF had some problems.

Also, you are mistaken in thinking that it is necessary to run LaunchELF from host: in order to access host:. That was the case for earlier implementations, but nor for LaunchELF. You just need to start ps2client in 'listen' mode on your PC, and then you can access host:. Or at least that is how easy I wanted it to be, but here is what you will have to do.

To begin with you should have booted LaunchELF with IOP reset active, as that is the preferred mode (there are many good techie reasons). Then go to LaunchELF file browser and select host:. After a brief delay this will time out to show an empty directory (failed contact). Back out from this so you see the device list again. Next start ps2client on your PC, in 'listen' mode. A typical command line for that would look like this:

ps2client -h 192.168.0.10 listen

Finally, select host: in LaunchELF again, and this time it should connect, showing the work directory of ps2client, from which you can browse any subfolders. But in fact there are many ways to browse even more freely.

For example, I have a batch file containing the following three lines:
%~d1
cd "%~f1"
%~dp0\ps2client -h ps2 listen

This means that any folder dropped on this batch file (or its shortcut) will become the work directory of ps2client for the new session, and can thus be browsed from LaunchELF.

Another good idea is to put a file named 'elflist.txt' in the work directory of ps2client, and let it contain any links you need to files or folders on the PC. And this can even include root directories.

The following three-line file might be useful to most Windows users:
C:
D:
E:

Yes, it really is that easy... ;)

PS2Menu writes corrupted files when they are read from host and written to HDD. Does LaunchELF do this aswell?
Not that I've noticed, and I use it a LOT...
But this is still a new implementation and needs longterm testing.
That is where the normal users get a chance to contribute to the project, as I can only make a limited amount of testing myself.

(a possibility if the host: code was copied from ps2menu)
No chance ;)
IMO ps2menu was worthless at host: stuff, so I looked more at Altimit instead (not that it was much better), and early versions of my code borrowed some structure from it, but the present routines are completely new.

Best regards: dlanor

[dlanor]

I post a attachment with 3 Japanese game's save file. Thanks. :)
Thanks, I have copied these to one of my memory cards, and I have also found and installed ELISA100.FNT. Now I have both bad news and good news for you...

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

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

Best regards: dlanor

[HypERSoniC]

ah i see :) the system you use is much better.

i remember it corrupting files on my system - maybe it is some kind of setup difference between you and me(other users reported this issue) that is causing the files to become corrupted.

[dlanor]

ah i see :) the system you use is much better.

i remember it corrupting files on my system - maybe it is some kind of setup difference between you and me(other users reported this issue) that is causing the files to become corrupted.
If that is correct then it is a serious problem.

I'll make some experiments by copying some various ZIP archives from host: to mass:, and then move the USB pen drive to the PC to verify those ZIPs. If any errors occur, then the CRC32 checks of the ZIPs are bound to show it.

Best regards: dlanor

[HypERSoniC]

i will do this also

[dlanor]

i will do this also
The problem is real. Out of 18 ZIPs I tested (average size 180 KB) three ZIPs had CRC errors caused by host:, so this is the next high priority problem. But fixing it will still have to wait a bit. Partly because I do have to sleep some time too, and partly because it will take some time to find out what causes it and to fix that.

For now I can only caution everyone to not rely on host: .

Best regards: dlanor

[HypERSoniC]

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


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

[dlanor]

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


i reccomend to avoid copying from host to the HDD directly. Instead copy to MC or USB first.
Maybe you're right, but I doubt it. In my earlier test I did transfer directly from host: to mass:, and still got 3 out of 18 ZIPs damaged.

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

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

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

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

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

Best regards: dlanor

[jackielo]

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

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

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

Best regards: dlanor

Thanks. It is working now!

[E P]

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

[dlanor]

Dlanor I too had problems with ftp when I was using 3.41c. I think those problems pretty much went away upon using the older ps2dev9.irx included in the launchELF source. I can't say with absolute certainty but I think this may be a factor.
The choice of I/O drivers certainly should have some effect, but I don't think that it's so easy to solve. I'm afraid the problem is more general than that.

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

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

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

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

Best regads: dlanor

[E P]

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

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

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

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

[dlanor]

Oh yes I agree I also wish iomanx.irx didn't have that issue but perhaps there is a way to get around it by changing a few things in the source. It's just too bad that LaunchELF is built primarily on an older sdk and the old libito.
I'm glad we agree on this, and changing to the newer lib variants is something that I do plan on doing. Eventually ALL libs used should be those of the latest PS2SDK, even if that means having to help changing them.

Oh and you left one of my minor changes out of your releases:
-Added config name to both failure messages (Name of config that failed to load/save).
Sorry, I just forgot about that one. I'll add it in next time, but I don't want to delay a bugfix release on that account.

It's a slight modification in config.c. It's in that package name pre-c, which I had posted a few days ago. You're still using the older config.c from version b. Thanks :)
I have the file, and I promise to include the fix next time.

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

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

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

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

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

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

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

Best regards: dlanor

[E P]

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

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

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

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

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

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

[HypERSoniC]

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

[HypERSoniC]

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

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

[E P]

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

I got it working fine now. I'm using a newer ps2client.exe from PS2World dated May 2005. I'll probably end up compiling my own sooner or later.

Dlanor was concerned before about host: support not working right with the slashes under linux.

Host: support is all dlanor's addition. :) FTP was something I had thrown together, which still has issues from what I've been told and had seen earlier. :chinscrat

edit: Warning: running PS2Net whether IOP reset on or off causes the entire program to go kaput:
1. I start up LaunchELF via booting from exploit.
2. Run PS2Net.
3. Opened up Bulletproof FTP client and successfully connect to ps2 as anonymous.
4. Tried to transfer a file from pc to mc.
5. Everything locks up and the file never transfers.

It's strange because I don't recall seeing this issue with my own builds before everything was integrated into the ver c. :chinscrat Granted there are a lot of changes in the newer builds.

[HypERSoniC]

so the ftpd is broken all together?

[E P]

so the ftpd is broken all together?

Yeah, it's broken here anyway. However, my own module works fine after running ps2link 1.30 and then loading my ps2ftpd.irx.

OK the module included in launchELF is broken I get crashes under ps2link my own compile doesn't so there you go. IOP Exception handler: Module name 'mcman'. I had this problem before I think that's another reason why I always compile with the older IOP.

Don't worry I'll supply one of my own working ones and that should solve it. ;)

Edit: OK here it is, dlanor you can just add all this to the next release package with its source as well. :)

Edit 2: :oops: I forgot to include the changes.txt file now added.

[dlanor]

Hum that's interesting perhaps a partial reset to clean up some modules would get around this issue? I'm pretty sure it has to be done in loader.c, which makes it difficult to make it optional.
Difficult, but not impossible. Any way whatsoever to pass some argument or simple semaphore will do. Essentially we just need to pass one bit to request this special handling ON/OFF, so we can definitely find some way to do that.

KeyLauncher resets IOP right before the execution of any ELF or at least that's how I see it in its source. I tried to do something similar but I couldn't get it to work right in my testing.
That could very well be related to the problems we had with v3.41c, where IOP reset would sometimes malfunction due to previous use of 'initsbv_patches'. Possibly this, and perhaps some other EE lib functions interact to make IOP reset itself, or maybe just those EE libs, malfunction that way. For the case we had that was fatal, as we needed LaunchELF to proceed working in that state. But for a new launch operation it might not be fatal, as the newly launched ELF will reinitialize its own instances of all EE libs it uses. Any fatal problems which LaunchELF may have had with its EE libs, as part of the launching process, will then be forgotten (as those lib instances are no longer in RAM).

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

Anyway about coruption with ExecFTPs, I couldn't help but overhear that you used version .69. You do know that it doesn't support large hard drives?
Yes, I do know that. But it's not really a problem. Partly because of the stuff you mention below, and partly because I've made sure that all FTP-able partitions are below the 128GB limit. So ExecFTPs will never be called upon to make any calculation of size or position of partitions that exceeds what it was designed for. (One reason why some apps do not work with large drives even after patching them with 48-bit LBA atad driver.)

I had mentioned this before in other instances. You should be ok though if you're loading it with LaunchELF and the program is on a hdd partition. LaunchELF would supply its own modules thus bypassing the older ps2atad.irx one.
Exactly, and that is notable as a positive case of 'inherited modules', which is one reason we should never make IOP reset mandatory for ELF launching.

----- snip ----- re: your problems with ps2client

I take it (from your edit) that those problems were all solved. Right ?

Although I got it to run "C:/WinZip/Unzipped/Ps2exec/BOOT.ELF" on several instances that was in my elflist.txt file.
At present it will not matter whether you use forward slashes or backward slashes as path separators in elflist.txt, but my plan is to change that, to provide better support for linus users.

At present all paths passed back to the PC are translated into using backslash, so as to work with the routines in ps2client, which call DOS functions of Windows. But on a linux system ps2client will need forward slashes in those paths. The current 'translator' already has code to handle that, dependent on the setting of a flag, which at present remains set always to use backslash.

My plan is to change this so that the flag will be set according to what is found in elflist.txt. If the file is absent, or contains only root paths, or any paths with backslash as separator, then it will use backslash mode in translation. But if the file is present and uses forward slashes as path separators, never using any backslash, then forwardslash mode will be used in translation (basically no translation at all, as it's what PS2 uses internally).

The basic idea is that the paths in elflist.txt should use the path format valid on the host itself, and that will then inform my host: routines of what translation to use.

So far I'm amazed by what true host: support can do. :) I'm sold dlanor.
I'm glad you like it, though I must say I'm still surprised myself that it could come out on top of the other methods when it comes to data integrity. That is something I had definitely not expected... :)

And on that note, I have to repeat again, that I'm deeply worried by my findings about the unreliability of all operations involving the HDD.

I mean mainly those experiments where I simply copied a collection of ZIPs back and forth between some HDD partitions, ending up with copies that were (some of them) corrupt when tested back on my PC. This needs to be verified using many different copying methods (also non-LaunchELF) and investigated thoroughly until we can eliminate such errors. Unfortunately I suspect that this will require modifications to modules of PS2SDK, but if so then we can't let that stop us. This MUST be fixed, one way or another.

Best regards: dlanor

[dlanor]

Yeah, it's broken here anyway. However, my own module works fine after running ps2link 1.30 and then loading my ps2ftpd.irx.
Does running ps2link really influence this result ? Surely it should work the same way using that ps2ftpd.irx from LaunchELF.

OK the module included in launchELF is broken I get crashes under ps2link my own compile doesn't so there you go. IOP Exception handler: Module name 'mcman'.
I too have just noted that transfers to mc in ps2ftpd of LaunchELF doesn't work, though transfers involving HDD do. Weird...!

I had this problem before I think that's another reason why I always compile with the older IOP.
I'm not sure what you mean here. The old IOP compiler, or the old IOP libs of PS2SDK ? Either way, I can not agree. Using obsolete tools or libs is not going to help us move forward. Backing a version for some component should never be regarded as anything other than a temporary workaround.

NB: The old IOP compiler is not just one version, or even a few versions, older than the present one. It really is obsolete ! We're talking about backing to version 2.8.1 from 3.2.2, which is a bit much for my taste.

Don't worry I'll supply one of my own working ones and that should solve it. ;)

Edit: OK here it is, dlanor you can just add all this to the next release package with its source as well. :)

Edit 2: :oops: I forgot to include the changes.txt file now added.
Thanks, I will test this and see if I can make it work right with the latest libs and compilers too. If not, then I will include your version as-is, but I will then regard the real problem as unsolved, and continue working on a solution for it. (Just as I already regard fileXio and iomanX...)

Best regards: dlanor

[slartibartfast]

Hi, i noticed a bug(?) in config.c, line 173:
p = (char*)malloc(sizeof(size));
it would have to be
p = (char*)malloc(size);
or i'm missing something?

[E P]

Yeah, dlanor host works fine just had to use a more update ps2client.

Does running ps2link really influence this result ? Surely it should work the same way using that ps2ftpd.irx from LaunchELF.

I too have just noted that transfers to mc in ps2ftpd of LaunchELF doesn't work, though transfers involving HDD do. Weird...!
Yes and no I use ps2link to signal problems for me. I think the module in the release you made was with the newer mostly bugged iop-3.2.2. I only trust iop-2.8.1 like I think most of those at ps2dev do.

I'm not sure what you mean here. The old IOP compiler, or the old IOP libs of PS2SDK ? Either way, I can not agree. Using obsolete tools or libs is not going to help us move forward. Backing a version for some component should never be regarded as anything other than a temporary workaround.
The old IOP compiler works a lot better with some ps2dev projects. I compile the sdk and pretty much everything with it. It's been tested and most binaries that come out of ps2dev are made with iop-2.8.1 like ps2link 1.24 for example. Iop-3.2.2 still has issues and many projects still won't work right with it example: ps2ftpd.
NB: The old IOP compiler is not just one version, or even a few versions, older than the present one. It really is obsolete ! We're talking about backing to version 2.8.1 from 3.2.2, which is a bit much for my taste.
That's what I first thought until I ran into the same problems that many other ps2dev programmers had. I now keep both iop compilers but I mostly use the older more reliable one. I use Lukasz's setup so I can switch back and forth between them using use-oldiop.sh/use-newiop.sh.

Thanks, I will test this and see if I can make it work right with the latest libs and compilers too. If not, then I will include your version as-is, but I will then regard the real problem as unsolved, and continue working on a solution for it. (Just as I already regard fileXio and iomanX...)

Best regards: dlanor
No problem it worked fine here on my test build. Of course, mine was built with the older IOP compiler.

[dlanor]

Hi, i noticed a bug(?) in config.c, line 173:
p = (char*)malloc(sizeof(size));
OMG! That's horrible...

it would have to be
p = (char*)malloc(size);
or i'm missing something?
No, you're quite correct, and thanks for pointing this out.

We were very fortunate here, that this code is normally executed when nothing else needs to allocate space dynamically. It is of course always incorrect to write larger amounts of data than the allocated block size (which is what happens here), but I think it was harmless under these particular circumstances.

Naturally I will correct the current sources at once, and the next release after the one I'm making now (in my next post) will include this change. Due to the nature of the error I will also double-check every use of the malloc function throughout the LaunchELF sources.

Best regards: dlanor

[dlanor]

Yes and no I use ps2link to signal problems for me. I think the module in the release you made was with the newer mostly bugged iop-3.2.2. I only trust iop-2.8.1 like I think most of those at ps2dev do.
I'm aware of the issues, but I feel that calling them bugs is a misrepresentation. AFAICT it is rather a case of changed standards of optimization for the global GCC community, and these new standards are not chosen with any particular regard for the needs of the MIPS cpus of a PS2. Neither were the old standards for that matter, but those are what everyone got used to and what all the old makefiles are adapted for. We just need to find out what extra flags are needed in our makefiles to enforce the compiler behaviour needed for our projects when using v3.2.2.

The old IOP compiler works a lot better with some ps2dev projects. I compile the sdk and pretty much everything with it. It's been tested and most binaries that come out of ps2dev are made with iop-2.8.1 like ps2link 1.24 for example. Iop-3.2.2 still has issues and many projects still won't work right with it example: ps2ftpd.
I agree with your facts, but not with the causes. The problem is not any bug in the new compiler but lack of adaptation in old project files to the new compiler standards.

That's what I first thought until I ran into the same problems that many other ps2dev programmers had. I now keep both iop compilers but I mostly use the older more reliable one. I use Lukasz's setup so I can switch back and forth between them using use-oldiop.sh/use-newiop.sh.
I too used Lukasz's setup, and (as I've told you earlier) I've adopted his symbolic link methods too, both for this purpose and all other cases of conflicting lib variants. It is a very powerful method to gain control of a programming environment with multiple branches.

No problem it worked fine here on my test build. Of course, mine was built with the older IOP compiler.
I've made fullly functioning versions with both v2.8.1 and v3.2.2 of the compiler, but as yet I can do the latter only by turning off all optimizations. (Removing "-O2" from IOP_CFLAGS in Rules.make.) That causes a 64% increase in the size of the IRX, which is unacceptable. So for the moment I'm including the one you supplied as-is, but that is only until I find out the necessary compilation flags to do it right with the modern compiler.

Here are the changes for the new release v3.41f:
-Added config name to both failure messages (Name of config that failed to load/save).
-Replaced ps2ftpd module to eliminate a problem with memory card transfers.
NB: Matrix Infinity Dev.2 boot again works with either of the ELFs.

Edit: Somehow I managed to misplace one of those failure messages in config.c, but I have fixed this now, and it will be included in the next release, v3.41g.

Best regards: dlanor

[E P]

I'm aware of the issues, but I feel that calling them bugs is a misrepresentation. AFAICT it is rather a case of changed standards of optimization for the global GCC community, and these new standards are not chosen with any particular regard for the needs of the MIPS cpus of a PS2. Neither were the old standards for that matter, but those are what everyone got used to and what all the old makefiles are adapted for. We just need to find out what extra flags are needed in our makefiles to enforce the compiler behaviour needed for our projects when using v3.2.2.
Ok this makes more since I'm still new to GCC so you'll have to excuse my improper phrasing/understanding of things. I'm just a java programmer not much c++ let alone c programming experience.

I agree with your facts, but not with the causes. The problem is not any bug in the new compiler but lack of adaptation in old project files to the new compiler standards.
Yeah I think I can understand as those projects were made back when everything was built with v2.8.1 thus the use of different optimizations.

I too used Lukasz's setup, and (as I've told you earlier) I've adopted his symbolic link methods too, both for this purpose and all other cases of conflicting lib variants. It is a very powerful method to gain control of a programming environment with multiple branches.
Yes, those symbolic links are very helpful in switching back and forth easily. The layout is also nice and clean so it's easy to maintain.


I've made fullly functioning versions with both v2.8.1 and v3.2.2 of the compiler, but as yet I can do the latter only by turning off all optimizations. (Removing "-O2" from IOP_CFLAGS in Rules.make.) That causes a 64% increase in the size of the IRX, which is unacceptable. So for the moment I'm including the one you supplied as-is, but that is only until I find out the necessary compilation flags to do it right with the modern compiler.

Here are the changes for the new release v3.41f:
-Added config name to both failure messages (Name of config that failed to load/save).
-Replaced ps2ftpd module to eliminate a problem with memory card transfers.
NB: Matrix Infinity Dev.2 boot again works with either of the ELFs.

Best regards: dlanor
OK, I'll do some tests with this one and if I notice any problems I'll be sure to post them. It would be very helpful to pin point issues with the iop optimization as more people are now using the newer 3.2.2.

[E P]

OK I did some investigating on the issue with iomanX.irx. I can safely say that
it is do to some changes that herben submitted back in February. I recompiled the module using the older source for iomanX.c file dated October 11, 2004. That binary matched the IomanX module we are currently using so there you have it. Maybe it could be possible to fix the partition display mess on the LaunchELF end but I'm not sure. At least we know where the culprit is.

Location of the file in the sdk is for those who are interested:
ps2sdk/iop/system/iomanx/src/iomanx.c

Now if only we could understand the ps2dev9 issues as well. :(

[dlanor]

OK I did some investigating on the issue with iomanX.irx. I can safely say that
it is do to some changes that herben submitted back in February. I recompiled the module using the older source for iomanX.c file dated October 11, 2004. That binary matched the IomanX module we are currently using so there you have it. Maybe it could be possible to fix the partition display mess on the LaunchELF end but I'm not sure. At least we know where the culprit is.
Interesting, but unfortunately I don't have any ps2sdk sources that old backed up. I only recently started using these CVS sources, so the oldest I have backed up are from april this year.

Location of the file in the sdk is for those who are interested:
ps2sdk/iop/system/iomanx/src/iomanx.c

Now if only we could understand the ps2dev9 issues as well. :(
Yes, and the weird issues with the new IOP compiler...
Until those issues are resolved I've decided that we have to avoid using that compiler entirely. I hate taking such a decision, but at present it is necessary.

So I will recompile my experimental ps2sdk setup using the old IOP compiler, and then use that ps2sdk package to recompile LaunchELF, also using the old IOP compiler. And that version will then be released as v3.41g, having this recompilation as its main update reason, though also incorporating two other changes. (The message fix I missed earlier plus the malloc fix slartibartfast requested.)

Best regards: dlanor

[E P]

Interesting, but unfortunately I don't have any ps2sdk sources that old backed up. I only recently started using these CVS sources, so the oldest I have backed up are from april this year.
You can get the older version from the cvs repository through http://cvs.ps2dev.org/ here is a link to it: link (http://cvs.ps2dev.org/ps2sdk/iop/system/iomanx/src/iomanX.c)
Just view Revision 1.5 and copy it to a new file. ;)

Yes, and the weird issues with the new IOP compiler...
Until those issues are resolved I've decided that we have to avoid using that compiler entirely. I hate taking such a decision, but at present it is necessary.
Yeah that's what I have been doing all along I didn't want to make that decision either. :(

[Stealth-kill]

@dlanor

Can you make a max drive game save support?
i will extract my max saves with launchELF.
Teh MAx drive software is shit.

[dlanor]

@dlanor

Can you make a max drive game save support?
i will extract my max saves with launchELF.
Teh MAx drive software is shit.
We have no plans to make special adaptations of LaunchELF for any commercial product whatsoever, and I myself will never agree to such. There is also no real need for such support.

You can already use PS2SaveBuilder (search for it) on the PC to extract or rebuild saves, and you can use LaunchELF to copy the saves in the form of normal folders, just as they are stored on a memory card. No special adaptation is needed for that sort of use.

The only problem exists with some 'protected' saves, using special access flags that are specific to memory card operations and do not survive copying to/from other media. I have considered the possibility of adding the ability to handle such access flags to LaunchELF. That will then be part of the general memory card support, so still not related to any non-Sony products. But such changes are still only vague ideas, not quite ready for implementation.

Best regards: dlanor

[dlanor]

You can get the older version from the cvs repository through http://cvs.ps2dev.org/ here is a link to it: link (http://cvs.ps2dev.org/ps2sdk/iop/system/iomanx/src/iomanX.c)
Just view Revision 1.5 and copy it to a new file. ;)
I should have thought about that but I was being unimaginative (a capital crime for a programmer ;)), getting stuck on the lack of a 'Download' link except for the latest version, but the 'view' links will of course serve just as well.

Yeah that's what I have been doing all along I didn't want to make that decision either. :(
Right, but here it is in any case. A version completely untouched by the new IOP compiler, not that it seems to have made any difference...

I made the same tests as before, copying that bunch of ZIPs back and forth, and I still get a few damaged CRCs (out of 18 ZIPs) in almost all cases. 'host:' still succeeds best, but even it has had an occasional error, so NO copying is entirely safe. It is clear that the entire IO subsystem needs debugging...!

Now for the new release, with the following changes:
-Added config name to another failure message (missed it for 'save config' earlier).
-Corrected a malloc size error (Reported by 'slartibartfast' at ps2-scene)
-Recompiled all components (including ps2sdk) using v2.8.1 of the IOP compiler

Best regards: dlanor

[slartibartfast]

Hi again, with the latest cvs version of the usb_mass.irx, my pendrive finally work!
I'm glad if you will include in the next version of launchelf, i hope that work also for other people.

[dlanor]

Hi again, with the latest cvs version of the usb_mass.irx, my pendrive finally work!
Good! I have suspected for some time that the problems did not lie in USBD.IRX, as many of the non-functioning drives were 'recognized' at that level, but still failed to work right.

I'm glad if you will include in the next version of launchelf, i hope that work also for other people.
First I will test it, and check its sources to see that none of the new code adds any problems for existing LaunchELF code. Then, if all goes well, I will of course include it.

Best regards: dlanor

[slartibartfast]

I have been tested and work fine with new usb_mass.irx, the diff from version 0.30 (originally shipped with launchelf) and 0.31 they have added three scsi command (sense request) at line 965 in file mass_stor.c
//send "request sense" command
//required for correct operation of some devices
//discovered and reported by BraveDog
cbw_scsi_request_sense(&cbw); //prepare scsi command block

XPRINTF("-REQUEST SENSE COMMAND\n");
usb_bulk_command(dev, &cbw);

XPRINTF("-RS DATA\n");
usb_bulk_transfer(dev->bulkEpI, buffer, 18);

XPRINTF("-RS STATUS\n");
stat = usb_bulk_manage_status(dev, -TAG_REQUEST_SENSE);

I'm very sorry for my bad english...

[szczuru]

I Can't Compile Src :( (Useing PS2SDK give me an error [main.o Error:1])

[wasabist]

Add cheatcode function, please.

[Quant]

Hi,

thank you for the nice work.

I tested the f and g version and have a little problem.

I put the usbd.irx in the mc0:/sys-conf/ dir, but i can't see it in the ulaunchelf filebrowser. With execftps and FlashFxp i see it and elfs they need this file works correctly.

How does the PS2Net works? It starts in mc0: and if i go back to the root dir, it hangs.

Sorry for my very german english.

Quant

[dlanor]

I Can't Compile Src :( (Useing PS2SDK give me an error [main.o Error:1])
The sources coming with the current releases are not complete, but need to be added to the original full release of v3.41 source code. That is why we use a folder named "_changed-files" in the current releases, as that only contains the files changed since the original v3.41 release.

Best regards: dlanor

[dlanor]

Hi,

thank you for the nice work.

I tested the f and g version and have a little problem.

I put the usbd.irx in the mc0:/sys-conf/ dir, but i can't see it in the ulaunchelf filebrowser. With execftps and FlashFxp i see it and elfs they need this file works correctly.
That's funny. I have such a file myself in that folder and it is perfectly visible, just as it should be. Are you sure you were using the real file browser, started by pressing a preprogrammed key ?

Remember that you can also enter another form of the file browser, when you are programming the keys, and that form of the browser normally shows only ELF files, since those are what you normally need for the keys. Even then, you can force it to show all files, simply by pressing the <Square> key.

How does the PS2Net works? It starts in mc0: and if i go back to the root dir, it hangs.
It should never start in mc0: by itself !!!

It should start by showing you "mc" and "pfs" or maybe just "mc" if you have no HDD.

If you want to enter mc0: you should first have to doubleclick the pseudofolder "mc" and then doubleclick the pseudofolder "0". If you go into these folders automatically, then that must be due to some weird action by your FTP client. Some clients allow you to specify start directories, and this feature could possibly have some side effects, depending on how those clients do it. Try to turn such features off, if possible.

Sorry for my very german english.
That's OK. I'm Swedish myself, and it just so happens that I do know some german too.
(Aber nur ein wenig. Viele Jahren haben doch passiert, seid ich dieser Sprach studiert habe. Und der deutsche Grammatik ist ganz schwer...)

Best regards: dlanor

[dlanor]

Add cheatcode function, please.
No, I don't think so.
That is a highly specialized function which would probably demand that LaunchELF increase to several times its present size, and that all other LaunchELF improvements come to a halt, merely to provide support for that cheat mode. Such a changed destiny for LaunchELF is not well motivated.

Other tools for such purposes already exist, and if new ones are needed I think they should be independent projects in their own right, not addons to LaunchELF.

Best regards: dlanor

[dlanor]

I have been tested and work fine with new usb_mass.irx, the diff from version 0.30 (originally shipped with launchelf) and 0.31 they have added three scsi command (sense request) at line 965 in file mass_stor.c
----- snip ----- re: sense request code
Here is the new version, identical to the last one except for the replaced usb_mass driver. Note that I didn't use the one you sent, but compiled my own, so I could add in some changes designed by the original LaunchELF author.

I'm very sorry for my bad english...
That's OK. People come here from all over the world, so we can't expect perfect english from everyone.

Best regards: dlanor

[cajosc]

Here is the new version, identical to the last one except for the replaced usb_mass driver. Note that I didn't use the one you sent, but compiled my own, so I could add in some changes designed by the original LaunchELF author.

Works great with my Kingston DT 128 MB. :) Thanks!

[wasabist]

No, I don't think so.
That is a highly specialized function which would probably demand that LaunchELF increase to several times its present size, and that all other LaunchELF improvements come to a halt, merely to provide support for that cheat mode. Such a changed destiny for LaunchELF is not well motivated.

Other tools for such purposes already exist, and if new ones are needed I think they should be independent projects in their own right, not addons to LaunchELF.

Best regards: dlanor
Hmm, I see.
Thank you for a reply.

[Quant]

That's funny. I have such a file myself in that folder and it is perfectly visible, just as it should be. Are you sure you were using the real file browser, started by pressing a preprogrammed key ?

Remember that you can also enter another form of the file browser, when you are programming the keys, and that form of the browser normally shows only ELF files, since those are what you normally need for the keys. Even then, you can force it to show all files, simply by pressing the <Square> key.

Yes i'am sure it is the real file browser. I can see all files in the folder like .cnf or .elf the only file i can't see is the usbd.irx. But i think it is not a problem of uLaunchElf, because i go back to the original V3.41 and it is the same.
perhaps it is my system?

It should never start in mc0: by itself !!!

It should start by showing you "mc" and "pfs" or maybe just "mc" if you have no HDD.

If you want to enter mc0: you should first have to doubleclick the pseudofolder "mc" and then doubleclick the pseudofolder "0". If you go into these folders automatically, then that must be due to some weird action by your FTP client. Some clients allow you to specify start directories, and this feature could possibly have some side effects, depending on how those clients do it. Try to turn such features off, if possible.

Ok, i take a look for this feature. It is possible, because i set a Bookmark for the PS2 in the FTP client.

That's OK. I'm Swedish myself, and it just so happens that I do know some german too.
(Aber nur ein wenig. Viele Jahren haben doch passiert, seid ich dieser Sprach studiert habe. Und der deutsche Grammatik ist ganz schwer...)

Best regards: dlanor

Auch wenn viele Jahr vergangen sind, seit deinem letzten Deutschunterricht, man kann dich sehr gut verstehen. Leider kann ich kein Wort Schwedisch. :)

[dlanor]

Yes i'am sure it is the real file browser. I can see all files in the folder like .cnf or .elf the only file i can't see is the usbd.irx. But i think it is not a problem of uLaunchElf, because i go back to the original V3.41 and it is the same.
perhaps it is my system?
This is very strange indeed. I have never seen anything like that myself. Could you please try using one of the tools that can see it, such as the FTP server, to erase that copy of the file, and then send a new copy over from the PC.

My thought on this is that the file may have received an abnormal attribute flag of some kind, through some earlier error. The memory card drivers do support several PS2-specific attribute flags, and we don't have full insight into that, as these drivers are from the BIOS ROM by Sony. (Such attributes could include 'invisibility'.) Erasing and then reinstalling the file as I suggest should get rid of any PS2-specific attributes.

Auch wenn viele Jahr vergangen sind, seit deinem letzten Deutschunterricht, man kann dich sehr gut verstehen.
I'm glad to hear it. I do think I retain most of the vocabulary, but the grammar, well, let's just say that I'm very shaky in that department...

Leider kann ich kein Wort Schwedisch. :)
Not many do, outside of our own country. I guess that's why we've decided to make english a mandatory subject for all school children. I don't know how early they start now, but when I went to school we started on english in the 4th grade (4th year of the 9 mandatory school years). German was an optional choice from the 7th year and on.

In fact you probably do know some swedish words after all, without being aware of it, because we've borrowed quite a lot of words from the german language in the past. Also, since the languages are related from ancient times, some words are more or less identical even without borrowing.

Best regards: dlanor

[taz030485]

All I can say is "WOW :wow: " this project is really advancing.
So lets see if I undersatnd what I've read.
- LaunchELF has an FTP server built in. Is it 48-bit compatible?
- LaunchELF has HOST. Which I have never gotten working yet. (Only tried once, didn't work)
- There are some errors when copying to and from pretty much anything. (Or is this fixed?)
- And a lot of cosmetic and implementation fixes.

I'm not sure if it's a bug or anything but I'm currently using the latest offical launchELF and I put some ELF demos from 'The Third Creation' onto my USB drive and tried to run them and it said they were not elfs, so I copied them to HDD and it said the same, so I ran execftps and transfered them to HDD and the ran fine. This might be fixed but still might be a bug, just letting you know.

To use the FTP in LaunchELF is it as simple as running the FTP thing and then connecting that same as Execftps?

Also would it be possible to upload a copy of the latest PS2Client for windows? :-pray:

Thanks in advance.

[E P]

- LaunchELF has an FTP server built in. Is it 48-bit compatible?
Yes just assign MISC/PS2Net to a button.

- LaunchELF has HOST. Which I have never gotten working yet. (Only tried once, didn't work)
You probably need a better version of ps2client get the May 2005 release from ps2world. It's the only one that works for me. I tried compiling my own from ps2dev cvs but it didn't work correctly.
- There are some errors when copying to and from pretty much anything. (Or is this fixed?)
It's not fixed but I haven't noticed any errors here yet. However, I'm going to do some tests similiar to dlanor's today.
- And a lot of cosmetic and implementation fixes.
Yeah and don't forget Reset IOP, and loading of as many extra configs as you want all in the new Startup Settings menu. :)

I'm not sure if it's a bug or anything but I'm currently using the latest offical launchELF and I put some ELF demos from 'The Third Creation' onto my USB drive and tried to run them and it said they were not elfs, so I copied them to HDD and it said the same, so I ran execftps and transfered them to HDD and the ran fine. This might be fixed but still might be a bug, just letting you know.
I can't help you with the USB stuff as I still don't have a thumb drive yet.
To use the FTP in LaunchELF is it as simple as running the FTP thing and then connecting that same as Execftps?
Yes exactly the same just make sure your IPCONFIG.DAT is in mc0:/SYS-CONF/.
Also would it be possible to upload a copy of the latest PS2Client for windows? :-pray:

Thanks in advance.
I would but I want to see where the issue is with the one I compiled.

[rivaldinho]

how does this host thing work

[dlanor]

All I can say is "WOW :wow: " this project is really advancing.
I'm glad to hear it. We aim to please..., ourselves mostly. ;)
But seriously, I mean that just like I said it. This is the kind of project you get hooked on because you need it for your own use, and the improvements added were mostly done because we had a need for them ourselves.

Now, since E P has already replied to many of your questions, I'll keep my own reply brief, mainly filling in what he skipped.

I'm not sure if it's a bug or anything but I'm currently using the latest offical launchELF and I put some ELF demos from 'The Third Creation' onto my USB drive and tried to run them and it said they were not elfs, so I copied them to HDD and it said the same, so I ran execftps and transfered them to HDD and the ran fine. This might be fixed but still might be a bug, just letting you know.
Actually this might be due to how you did the copying on the PC.

Plug-and-Play devices under Windows can be configured to either:
"Optimize for quick removal" or "Optimize for performance"

This is a setting which you can find by selecting the drive in explorer, and then clicking through "Properties/Hardware", then again selecting the proper device and clicking through "Properties/Policies". That will bring up the dialog where this setting is made. (There are also other ways to reach it.)

The "quick removal" setting is quite useless, as the copying rate is then extremely slow (often a hundred times slower than for the other setting), so most people choose to optimize for performance instead. But when you do this, you MUST follow correct discipline... You must always use the 'tray' gadget for safe removal of the drive (or the equivalent 'Eject' command), even if hours have passed since the last copying. Else you must expect damaged files on the USB drive, and after each such occurrence it may even need reformatting, if part of the damage was to a directory sector. (And yes, that has happened to me, so I KNOW it can happen.)

Also would it be possible to upload a copy of the latest PS2Client for windows? :-pray:
You already have it, in a reply I made in another thread...

Best regards: dlanor

[dlanor]

how does this host thing work
I wrote a couple of pretty detailed explanations recently, of how I use it myself. I really don't feel like retyping all that stuff again, so please try to find the posts I already made, partly here and partly in the HDD forums.

Best regards: dlanor

[rivaldinho]

i checked in the hdd part but i don't understand what to do is ther an easier way

[E P]

dlanor, I did my own tests with LaunchELF's FTP "h" verson. I copied 17 zip files to the root of my MAIN hdd partition. I then copied them all back to the pc side after a ps2 reboot. The size of the copied files matched the original files on the pc so I then checked them all using a hex compare. Each one matched the original file, so like I said before I have not had any isses with FTP to speak of.

Is there something else I should check or am I just lucky? Did you try using a different partition for your tests? Maybe one of your partitions got slightly corrupted? :chinscrat (Note: Using Bulletproof FTP client with Passive Mode off)

[dlanor]

dlanor, I did my own tests with LaunchELF's FTP "h" verson. I copied 17 zip files to the root of my MAIN hdd partition. I then copied them all back to the pc side after a ps2 reboot. The size of the copied files matched the original files on the pc so I then checked them all using a hex compare. That sounds like a very awkward method for testing.

A much better way is to use the 'Test archive' function of a packer like WinRAR. All I need do is to select any number of ZIPs in a normal explorer window, rightclick any one of those selected files, and then click 'Test archive' in the context menu. That will test each of the selected ZIPs, checking individually the CRC32 values for each file they contain. Any errors will then be reported in a new window.

Each one matched the original file, so like I said before I have not had any isses with FTP to speak of.
Odd. I do get some error almost every time I transfer my test batch of ZIPs (originally 18, but now 20).

One thing that might affect results is that I don't just transfer the ZIPs as such. I transfer a containing folder, and inside that are 10 ZIPs, a few unpacked files, and another subfolder containing the remaining 10 ZIPs. That goes not just for FTP, but also for my tests of copying between different media or different partitions. So each transfer has to deal with two folder levels each containing 10 ZIPs (not identical sets). Back on the PC I then test each of the two sets of 10 ZIPs by the methods described further above (WinRAR).

Is there something else I should check or am I just lucky? Did you try using a different partition for your tests? Maybe one of your partitions got slightly corrupted?
I've used mainly two different partitions, "+MP3" and "+ELFS", and I've also used mc0:, mc1:, and mass:. The only thing these devices have in common are (in part) some driver modules, yet I've gotten errors with all of them.

:chinscrat (Note: Using Bulletproof FTP client with Passive Mode off)I use FlashFXP for FTP myself, but I discount that as a factor in this.

The only thing that is common to all of my tests is that I have used mass:, my USB pen drive, to carry data back to the PC for verification. I suppose something could be wrong with it, though it seems to work fine for all other things. In any case I really have to use it.

I have no real choice in this, as FTP from PS2 to PC still gets a maximum speed of 4KB per second, and I'm not prepared to wait that long for my results (appx 20 minutes per test). That's another thing I don't understand, why the FTP speed in that direction is so horribly slow ?!?

Best regards: dlanor

[zabolyx]

SLOW DOWN Dlanor.... I jsut installed g last night... and now I see that h is done....

great work guys... I have a simple idea to throw out... for each of the configurations allow a menu name to be placed at the top of the menu... I have my four configs setup as 1.HD gaming tools (hdloader, file browser, MC manager), 2.EMUs (TG16,SNEStation, PSMS,infoNES...) 3. Media (PS2 Reality, SMS, MP3 Station...) as simple name that could be placed at the top and saved into the corresponding config file would be lovely....

[E P]

That sounds like a very awkward method for testing.

A much better way is to use the 'Test archive' function of a packer like WinRAR. All I need do is to select any number of ZIPs in a normal explorer window, rightclick any one of those selected files, and then click 'Test archive' in the context menu. That will test each of the selected ZIPs, checking individually the CRC32 values for each file they contain. Any errors will then be reported in a new window.
Yeah I agree that's awkward but it works for files other than compressed archives. I usually use winRAR to check CRC test archive like you said.
Odd. I do get some error almost every time I transfer my test batch of ZIPs (originally 18, but now 20).
OK, so I got to transfer more than 17 for the bug to appear.
I've used mainly two different partitions, "+MP3" and "+ELFS", and I've also used mc0:, mc1:, and mass:. The only thing these devices have in common are (in part) some driver modules, yet I've gotten errors with all of them.

I use FlashFXP for FTP myself, but I discount that as a factor in this.

The only thing that is common to all of my tests is that I have used mass:, my USB pen drive, to carry data back to the PC for verification. I suppose something could be wrong with it, though it seems to work fine for all other things. In any case I really have to use it.

I have no real choice in this, as FTP from PS2 to PC still gets a maximum speed of 4KB per second, and I'm not prepared to wait that long for my results (appx 20 minutes per test). That's another thing I don't understand, why the FTP speed in that direction is so horribly slow ?!?

Best regards: dlanor
OK so there are problems with file integrity pretty much everywhere then? So it's just a manner of time before something mistransfers? So the file is damaged when it reaches the ps2 hdd, mc, etc not just on the way back to the PC side?

Yes that is an interesting question about the ps2ftpd.irx module with transfers being faster one way than the other. Host doesn't have that issue as far as I could tell but the ps2ftpd module hasn't had much work done to it. The ps2ftpd module even has that attribute problem with the transfered files to the hard drive that you have mentioned before.

[zabolyx]

hey Big D.... I'd Love to help.... currently have a crapload of time on my hands...

What would you like for me to do (no coding though, I ain't know no C :) )... I can run some tests... I've got a network setup, HDD, USB Mass, MCs, and a Nonmodded V10. Anything I can do to help test this code.... I also would like to observe the source as it grows (trying to learn C/C++)... is the latest source available... I saw the older one on here...

Thanks for the great app... well the enhancements to the great app...

EDIT: Nevermind... I see the source is with the file.. just DLed it...

[dlanor]

SLOW DOWN Dlanor.... I jsut installed g last night... and now I see that h is done....
The updates have come a bit too frequently lately , due to a combination of bugfixes and driver updates. I expect the pace to slow down now.

great work guys... I have a simple idea to throw out... for each of the configurations allow a menu name to be placed at the top of the menu... I have my four configs setup as 1.HD gaming tools (hdloader, file browser, MC manager), 2.EMUs (TG16,SNEStation, PSMS,infoNES...) 3. Media (PS2 Reality, SMS, MP3 Station...) as simple name that could be placed at the top and saved into the corresponding config file would be lovely....
Hmmm, that's not a bad idea, really. Sort of a context menu title, which we could place at the left edge of the top line, which is mostly vacant anyhow... We only use the rightmost part of it to show the LaunchELF version, so the leftmost part could well be used as you suggest (with an enforced limit on the string length of course).

What do you think E P ?

Best regards: dlanor

[dlanor]

OK, so I got to transfer more than 17 for the bug to appear.
Well, the total amount of data is probably more important than the number of files, though I do consider it important to use multiple files and folder levels too, so all special cases in the code are covered.

However, generically it's the total amount of data that increases the chance of catching an error. My own test folder contains appx 4.5 MB, distributed over 20+ files.

OK so there are problems with file integrity pretty much everywhere then? So it's just a manner of time before something mistransfers?
Those are my results, yes, and the reason I've said repeatedly that I'm deeply concerned about it. Such a situation is unacceptable.

So the file is damaged when it reaches the ps2 hdd, mc, etc not just on the way back to the PC side?
That is very hard to ascertain, as I have no real chance to test the data until I have it back on the PC. Only then can I know if any errors were injected, but I can't detect at which transfer stage that occurred.

Yes that is an interesting question about the ps2ftpd.irx module with transfers being faster one way than the other. Host doesn't have that issue as far as I could tell but the ps2ftpd module hasn't had much work done to it. The ps2ftpd module even has that attribute problem with the transfered files to the hard drive that you have mentioned before.
True. We really should fix it so that at least those attributes which have a matching equivalent on the destination media are translated correctly. That only leaves the problem of PS2-specific attributes, which can't be translated to any corresponding attributes on a PC. For the present we can ignore those, though we may eventually add some command to the file browser to manipulate them.

Best regards: dlanor

[taz030485]

Actually this might be due to how you did the copying on the PC.

Plug-and-Play devices under Windows can be configured to either:
"Optimize for quick removal" or "Optimize for performance"

This is a setting which you can find by selecting the drive in explorer, and then clicking through "Properties/Hardware", then again selecting the proper device and clicking through "Properties/Policies". That will bring up the dialog where this setting is made. (There are also other ways to reach it.)

The "quick removal" setting is quite useless, as the copying rate is then extremely slow (often a hundred times slower than for the other setting), so most people choose to optimize for performance instead. But when you do this, you MUST follow correct discipline... You must always use the 'tray' gadget for safe removal of the drive (or the equivalent 'Eject' command), even if hours have passed since the last copying. Else you must expect damaged files on the USB drive, and after each such occurrence it may even need reformatting, if part of the damage was to a directory sector. (And yes, that has happened to me, so I KNOW it can happen.)
Best regards: dlanor

I have it set to quick removal, but I always use the eject thing anyway, maybe thats why it takes so long to put mp3's on my player. I'll change it and see how the transfer speds go.

You already have it, in a reply I made in another thread..
Yeah I got it.

[zabolyx]

Actually from looking over the code... it seems that more of the C++ book that I've been working at digesting has been absorbed.... I could for the most part understand and follow the code structure of the source..

Nice to see that you've been documenting it as well... I've printed out 3.41h and am chewing the code... and busting out the books again... THANKS INTERNET... for the free books...

NOTE: about the menu ... how hard would it be to place 2 spaces in side the menu box at the top to have the menu there...


mc0:/system............................................ ..............LaunchElf 3.41h
---------------------------------------------------------------------
| MENU TITLE
|
| ^: PS2OS
| O: Boot
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


like so in this "HiRes" illustration....

[E P]

Hmmm, that's not a bad idea, really. Sort of a context menu title, which we could place at the left edge of the top line, which is mostly vacant anyhow... We only use the rightmost part of it to show the LaunchELF version, so the leftmost part could well be used as you suggest (with an enforced limit on the string length of course).

What do you think E P ?

Best regards: dlanor

It wouldn't be bad but I would probably do more than just that such as allow the user to name each item like what others want. Unfortunately, I would have to make a lot of changes to the CNF structure if I wanted to do it right. This is something I'm not really willing to do just yet. My reason is because it would require making a lot of changes to the CNF order within the CNF file through changes to config.c. It's most likely doable but at the cost of more interesting bug fixes and features. Personally I'm just happy with seeing which config was loaded with path on the top line below the version number. :)

Well, the total amount of data is probably more important than the number of files, though I do consider it important to use multiple files and folder levels too, so all special cases in the code are covered.

However, generically it's the total amount of data that increases the chance of catching an error. My own test folder contains appx 4.5 MB, distributed over 20+ files.

I definately got to dig deeper then my basic test. Too bad my memory card has some corruption from something before. Right now something ate 1.3 MBs of my card and I can't delete it because there isn't anything there to delete. :crazy: Pretty bad when you have an 8 Meg card but can't even use 6.6 megs of it. I guess I'll have to reformat it again to get that space back. I think my X-port did it but I can't say for sure.

Those are my results, yes, and the reason I've said repeatedly that I'm deeply concerned about it. Such a situation is unacceptable.

Yeah it definately goes to the top of the list.

That is very hard to ascertain, as I have no real chance to test the data until I have it back on the PC. Only then can I know if any errors were injected, but I can't detect at which transfer stage that occurred.

Perhaps a CRC file checker for the ps2 side. :) This is where it would be good to know what is contributing to the bug but it's difficult if the bug can't be reproduced consistently.

True. We really should fix it so that at least those attributes which have a matching equivalent on the destination media are translated correctly. That only leaves the problem of PS2-specific attributes, which can't be translated to any corresponding attributes on a PC. For the present we can ignore those, though we may eventually add some command to the file browser to manipulate them.

Best regards: dlanor
Yeah I agree but the attribute issue for ps2ftpd.irx is probably supposed to be handled by the hdd driver. Another thing is that the rename function isn't implemented for ps2ftpd.irx either probably because the memory card mcRename function doesn't work anyway.

Nevermind I think I found it in FtpClient.c. Currently it does ----------, the else statement, for all files created on the hard drive. Any ideas as to what I should add to a new elseif statement or modify with the current if statement?
strcat( buffer, (FT_DIRECTORY == pInfo->m_eType) ? "d" : (FT_LINK == pInfo->m_eType) ? "l" : "-" );
for( i = 0; i < 9; i++ )
{
if( pInfo->m_iProtection&(1<<(8-i)) )
{
switch( i%3 )
{
case 0: strcat( buffer, "r" ); break;
case 1: strcat( buffer, "w" ); break;
case 2: strcat( buffer, "x" ); break;
}
}
else
strcat( buffer, "-" );
}

[zabolyx]

How does LaunchElf react to not having am IPCONFIG.DAT file.... does it default or ask for a use inputted IP... I saw in the elf that 192.168.0.10 255.255.255.0 192.168.0.1 was listed in the file....

How hard would a simple IP input like FAPLink would be to implement... Just wondering...

[dlanor]

How does LaunchElf react to not having am IPCONFIG.DAT file.... does it default or ask for a use inputted IP... I saw in the elf that 192.168.0.10 255.255.255.0 192.168.0.1 was listed in the file....
Those are the defaults used if no IPCONFIG.DAT is found, or if the file is unreadable. That has always been the defined default behaviour for programs using IPCONFIG.DAT. So if you use those defaults, you don't really need the file.

How hard would a simple IP input like FAPLink would be to implement... Just wondering...
I'm not sure what you mean as I've never used FAPLink...
When I started using HDL, FAPLink still had its 2GB limitation, so using it was never an option, and after using WinHIIP and HDL_Dump (yes, I do use both) I've never seen any reason to try others. They've never let me down yet.
(I know others have had problems, but I never did.)

Possibly you mean that you want the ability to enter an IP using the controller, but I see no reason to add code for this. The IP address is not something you'll need to change from session to session, so it's better to set it up in a file and have done with it. Especially when the same file fixes this setting for other programs too. (PS2Link, ExecFTPs, etc.)

Best regards: dlanor

[dlanor]

----- snip ----- re: suggestion of user defined title at top of screen

It wouldn't be bad but I would probably do more than just that such as allow the user to name each item like what others want.
Sure, but that could come later. No need to do it all at once.

Unfortunately, I would have to make a lot of changes to the CNF structure if I wanted to do it right.
Indeed yes, but we are rapidly approaching the point where that will be necessary anyway.

This is something I'm not really willing to do just yet. My reason is because it would require making a lot of changes to the CNF order within the CNF file through changes to config.c.
"Yes, But No", is what I have to respond to that.
"Yes," we will have to make extensive changes.
"But No", we can no longer rely merely on the order of lines in the CNF file.

We will definitely need to add keywords and parse the CNF file for them, irrespective of the order in which the keyed lines occur. But doing so will also gain us far more freedom than anything discussed yet can allow, such as extensible menus (beyond those for programmed keys), and alternate launching methods (specified by different keywords).

Once we switch to a system of properly parsed keywords, a whole new vista of possibilities opens up.

It's most likely doable but at the cost of more interesting bug fixes and features.
Yes, of course we must expect initial bugs, and be prepared to fix them, but that really goes for any significant improvements.

Personally I'm just happy with seeing which config was loaded with path on the top line below the version number. :)
For now, sure, that will do nicely. And there's no need to rush into further developments, but there's no need to hold back for too long either...

----- snip ----- re: Your memory card problems.

I'm sorry to hear it, and I hope you won't lose any irreplacable saves in reformatting (as LaunchELF can't backup all special attributes). I have Several memory cards myself (3x 8MB, 2x 32MB, many PS1 cards) and I still get worried every time I have to reformat one of them, though I've never lost anything irreplacable yet (knock wood ;))

Perhaps a CRC file checker for the ps2 side. :)
That is not a bad idea for a test tool, but getting it to a point where it can be used for reliable and practical testing would be a pretty big project all its own.

This is where it would be good to know what is contributing to the bug but it's difficult if the bug can't be reproduced consistently.
And consistent behaviour is exactly what we can never expect from a bug... :(

Yeah I agree but the attribute issue for ps2ftpd.irx is probably supposed to be handled by the hdd driver. Another thing is that the rename function isn't implemented for ps2ftpd.irx either probably because the memory card mcRename function doesn't work anyway.
Yes, but if/when we make a workaround for this in LaunchELF , we can easily add the same for ps2ftpd. For the moment I'm prepared to accept the renaming limitation in both of them.

Nevermind I think I found it in FtpClient.c. Currently it does ----------, the else statement, for all files created on the hard drive. Any ideas as to what I should add to a new elseif statement or modify with the current if statement?
----- snip ----- re: code excerpt from ps2ftpd
To me that entire method of getting the file attributes looks suspicious and I think it needs to be studied in detail. I know that this has worked differently in old versions of ExecFTPs, so it may be due to some struct definition relying on some HDD standard struct that may have been redefined since then. Whatever the true reason, it is clear that ps2ftpd, and recent versions of ExecFTPs, do use some bogus data for the file attributes, so we don't have much to lose by changing it. (Though we must still take some care, so as not to invalidate any folder structures.)

Best regards: dlanor

[zabolyx]

OK... in the latest version of FapLink Server... it starts up (in PAL mind you) a screen asking if you want to use the standard IPCONFIG.DAT or to imput a IP for FAPLink to use...

with a simple up down for each item...

PS2 IP: XXX.XXX.XXX.XXX limited to 0 - 255... (like used in the Screen Setup of LaunchElf)
NetMask: XXX.XXX.XXX.XXX
Gateway: XXX.XXX.XXX.XXX

[dlanor]

OK... in the latest version of FapLink Server... it starts up (in PAL mind you) a screen asking if you want to use the standard IPCONFIG.DAT or to imput a IP for FAPLink to use...
TBH, that sounds downright stupid to me. If the file is present at all, then it should be used, no questions asked. Only if the file is absent, or damaged, would it be meaningful to use manual input.

Coding such input is no big deal, and once it's done it would also be simple to save the data as a file for future use. But while it wouldn't be hard to add such stuff, that still doesn't mean it's a good thing to do. Not if only one out of a thousand users will ever use it, and even then just once or twice before making a proper configuration file. Adding in everything that might be useful on very rare occasions is a surefire way of making bloat-ware...

If I do this at all, then I will probably do it by adding a simple generic text file editor, which may then be used to edit any text file, not just IPCONFIG.DAT... But it will not happen very soon, because such an addition would need keyboard support too, and I'm not quite ready to code that. (I have a USB keyboard, but need time for experiments.)

Best regards: dlanor

[zabolyx]

a good text editor for the PS2 would be a much better idea.... but I'm in no hurry... just a suggestion...

[glob30]

Hello ! Nice work... but .... my USB Stick is still not recognized, even with the last usbmass driver. When I try to paste a file, the console seems to freeze...
I have may be a way to explore :
With the ARMax Evo and my USB stick, the size shown is incorrect. It's 8 times the size it should be (2Go instead of 256 Mo). May be it's because my stick has a sector size of 4096. I can't format my stick using another size for the sector (an error occured saying the sector size is invalid when I try to format the stick with 512 for sector size). May be it can help to modify the driver, no ?
What ever, thanks for all this work.

Hops ! My stick is a verbatim usb 2.0 with 256 Mo

[barf]

Yes, writing a text editor would be great!

Even if I might be able to get USBKBD.IRX to work,
I don't know how to extend the size of a text file...
and read/write... from the different devices.

Would it be smart to be parting blocks?
with accompanying counters for offsets and lengths?
Or what is best practice?

[kritenks]

Suggestion: How about making the square button = Space when renaming files?

Question: Why does PS2 keylauncher have a smooth looking font whereas all other ps2 apps including LaunchELF have a font that i can hardly read on my TV(OLD)?

[Dymiox]

Black with white backround is easier on the eyes then the System font with white text and a black backround.

[unmodify]

ps2 V10 mat infini fw v1.5
ulaunchelf 3.4.1h

when launching ulaunchElf, if there is no disc in the dvd/cd tray then I can only access mc0. mc1, hdd0, and cdfs all hang. When there is a disc in the tray I can access all of those. The discs in the tray I tested were a ps2 dvd back up and a half-size cdr. Also once launched with a disc I can swap in other discs, and it continues to work fine. If I have the tray out it waits until I put it back in, and if nothing is in there it just reuses the previous table of contents.

I would like to run with out anything in the tray.

Thank you for uLaunchELF, ftp & simple file management capability. Truly, thank so much

[HypERSoniC]

keine idee... can you describe more your setup? (modchip, etc). i assume since you mentioned ToC you are bootnig from a swapmagic :p

[dlanor]

Suggestion: How about making the square button = Space when renaming files?
Sure, why not ? I'll think about it, and see if I can come up with something better, but I agree that all available keys should be used, to minimize the efforts of the user.

Question: Why does PS2 keylauncher have a smooth looking font whereas all other ps2 apps including LaunchELF have a font that i can hardly read on my TV(OLD)?
I have no problems reading the LaunchELF font, nor have I seen any other complaints on this, so I guess your picture tube must be really old...

But the only real reason why that font is used, is that it's what the original sources used, and therefore the only font I have available in that particular form. (It's in text form, as the C source code for an initialized byte array.)

Maybe we'll make the font replacable in some future version, though that does raise the possibility of new problems too. (People trying to use truetype fonts, and suchlike nonsense.)

Best regards: dlanor

[dlanor]

Black with white backround is easier on the eyes then the System font with white text and a black backround.
That is a matter of taste, and I will not change the defaults on account of a single opinion. If you don't like the colour scheme, then use the "SCREEN SETTING" page of the configuration section, to fix it to your liking.

COLOR1 = Background
COLOR2 = Box Borders
COLOR3 = Title/Highlight_Text
COLOR4 = Normal text

Best regards: dlanor

[dlanor]

ps2 V10 mat infini fw v1.5
ulaunchelf 3.4.1h

when launching ulaunchElf, if there is no disc in the dvd/cd tray then I can only access mc0. mc1, hdd0, and cdfs all hang. When there is a disc in the tray I can access all of those. The discs in the tray I tested were a ps2 dvd back up and a half-size cdr. Also once launched with a disc I can swap in other discs, and it continues to work fine. If I have the tray out it waits until I put it back in, and if nothing is in there it just reuses the previous table of contents.
I recognize this problem from my own console, at the time when the original author added some disc recognition code to LaunchELF. I think it had something to do with better support for swapping. Anyway, it was then discovered that all models later than v9 had problems with that code, so there is an option in LaunchELF for disabling it. I too must have this code set in LAUNCHELF.CNF, in order to boot without any disc in the tray.

I would like to run with out anything in the tray.
And so you can, if you just change the setting "DISC CONTROL:" to "OFF" instead of "ON".

Thank you for uLaunchELF, ftp & simple file management capability. Truly, thank so much
We're glad you like it. Though I find it a bit embarrasing that I can't pass your thanks (or others') on to the original author, as I still don't even know his name... (It can't be helped. I can't read japanese, and none of the original docs used english.) I can only hope that he does follow what we do here and that he's aware of how grateful we all are to him, both for writing LaunchELF to begin with and for releasing its sources.

Best regards: dlanor

[zabolyx]

see this is why we all need to learn to hardest language ENGLISH ;)

[hbk2005v1]

i think key launcher is much better than launchelf it looks better its easy to add programs to it and much more stable to run

[strikeuk]

It may look better but functionality plays an important role too, look at launchelf now you could transfer files between your pc and ps2 at a faster rate compared to execftp. Both programs are stable in my opinion i haven't had any issues with both of them, as for which is easier to add programs i still prefer lelf since you don't have to modify the elf locations on your pc and then transfer it to the ps2. It also has the ps2menu functionality in it using the filebrowser option.

[HuMz]

Wow I just switched from DMS explorer to uLaunchELF and this prog is amazing! I was chocked by the fact you could launch elfs from the hdd or usb device, lol yeah I know dms explorer sucks! well good job guys.
(btw a *.mod music playing ability would be very nice! and a function to remove the access to options menu (select) in a CFG file or something only modifiable via ftp)

[zabolyx]

adding this layer of extra functionallity would be "not much fun".....

I think if they decide to do such a task... a "plug-in" style system would work the best. Simply having a chunk of code that can be put on the HDD in a predetermined directory to be loaded as needed by launch elf to perform a particular task.

Such as a module named mp3.lem (Launch Elf Module) could be loaded and ran from within Launch Elf when a file with the same extention it selected. So a person wanting to look at a jpg image could select it within Launch Elf and Launch Elf would load the file jpg.lem and the file would be generated on the screen. Then pressing select would make Lauch ELf unload the module and refresh the screen for it's own use.

So the only thing that the guys working on Launch Elf would need to do is build the code for loading and unloading and the transfer of the information of which file the module will load. And by using the name of the module for the reference to the type of file it can open this will eliminate the need of a maintained list for Launch ELf to have to reference all the time. Just when a file without the elf extention is selected it runs a quick search of the modules directory and runs that module if one exists. EDIT: This also would limit the capablilities of a single module. The module jpg.lem would load only .jpg and not .jpeg images. So the same module would need to be renamed to jpeg.lem for using with .jpeg files. This would breing up the idea of using a file to track the modules and extentions that they work with. But like I said this would be too much. You would need Launch Elf to maintain and add new modules to the list. This being an inflation of code to the system. If left up to the user to add the modules to the list manually and maintain it over network or other means, this may be an acceptable way of achieving this.

I'm definately not playing this off as an easy task. Or saying that it should be done. I'm just suggesting the best way to keep the original app as small and clean as possible if such functions were to be added. Hell I remember the pains I had with QuickBASIC in high school getting modules to function, but I was writing the modules. What I'm suggesting is that if a user can program and wants a module then make one using the guidelines set by the Big "D", EP, and anyone else working on Launch Elf.

The FTP was a great "base" feature because it is very useful to have on the MC with Launch Elf. By placing this code within the app they have actually saved some space.
But applying all the functions that everyone wants would make it into a monster. KISS people.

Also to help with thte module development. It would be helpful to have a "sign up" list for those looking to contribute a module. Therefore two similar modules wouldn't get released... and those wanting to create the same type module could work together and make it better or get it done faster.

This is my two scents (stinky and poo)

[SnowSurfer]

this may be the wrong topic or it may not, how do i get launch elf to boot off the hard drive in dev 2 mode with a matrix infinity. i tried using the instructions in the infinity launcher zip but all i get is a red screen of death when i try to boot...any suggestions?

[HuMz]

Nice idea zabolyx, I like the module idea. I think a lot of modules would be released quickly by random people if they implement that. Just tell us the coding rules/limitations of a module and lets code.

[dlanor]

In fact I've been considering the possibility of some kind of plugin system, but unfortunately it is not as easy to do as it would be in a standard operating system. Here we don't even have any standard method for a subprogram to terminate. As usual for consoles, every program is considered a main program which owns the entire system, and the only normal ways to terminate are either to shutdown/reset the whole system, or alternatively to lock up in an eternal loop until the user turns the system off. Unfortunately I'm NOT kidding here. Those are the normal ways to implement program 'end' on PS2.

The system functions that would allow a launched subprogram to terminate and return control to its launcher, simply do not exist at all...

So instead of just using normal OS functions to implement a plugin system, we would first have to create a fairly extensive API and some libs, just to simulate some of the standard stuff that all real OS contain, but which the PS2 lacks.

I'll keep thinking about this stuff, with a view towards future implementation, but don't expect much to come out of it anytime soon.

Best regards: dlanor

[zabolyx]

ok... but the modules couldn't reset the IOP and would be branched to. so the module would not be a seperate program but more like a sub routine of Launch Elf... once the end of the routine is reached Launch Elf would just continue with its normal function... Of course, as standard app like HD Loader would not be able to return control to Launch Elf,

the way we did it with QuickBASIC was to make a subroutine and use special C++ based functions to find the location of the subrourine in the RAM then use this as the linking place to upload the modules... then when the module has been used or a nother one was needed just be removed from RAM and a new module would replace it.

man I wish I knew more about C... I'd love to jump in and do some work with this app....I always thought that programming a game would be great but now I think something like this would end up being more satisfying....

I do have to say that the source I have DLed is very clean... and seems well organized.

And "D" I'm not saying that I expext this from you guys..... I know you guys have plans and that you are working on... I'm just answering all these guys that keep pestering about this and that (why can't Launch Elf view movies, why can't it do my laundry, where's my handjob....) and explaining the best means for this implementation.

[E P]

Yes, but if/when we make a workaround for this in LaunchELF , we can easily add the same for ps2ftpd. For the moment I'm prepared to accept the renaming limitation in both of them.
Yeah you're right it would give us something to work with if we had a working implementation.


To me that entire method of getting the file attributes looks suspicious and I think it needs to be studied in detail. I know that this has worked differently in old versions of ExecFTPs, so it may be due to some struct definition relying on some HDD standard struct that may have been redefined since then. Whatever the true reason, it is clear that ps2ftpd, and recent versions of ExecFTPs, do use some bogus data for the file attributes, so we don't have much to lose by changing it. (Though we must still take some care, so as not to invalidate any folder structures.)

Best regards: dlanor
Yeah, but I wonder if making a test build that forces all the other attributes to rwxrwxrwx. The directory attribute seems to to fine except with memory card saves that are copy protected. Although you can access those directories simply by manually entering the file name to change directories.

OK I found a bug the other day with one of my changes to ps2fpd.irx. I have made a working fix for it. The bug is with the root ftp directory listing that I first saw it with the FileZilla client. It lists a lot of dummy directories which happen to not have filenames making a mess on the screen. You can also see this with the ftp commandline based ftp with windows. My change is only minor though it fixes the problem. I may release a new LaunchELF version "i" with the fix to ps2ftpd and make a separate source package for ps2ftpd.irx. :)

Edit: OK get the "i" version from the first page. The ps2ftpd src package and irx are included separately.

[SnowSurfer]

when i start PS2Net, where does it read the config file from?

and it says No Disc at the top of the screen...is that normal??

i can connect with wsftp, but i can't mount harddrives...

thanks a bundle guys keep up the good work

[E P]

when i start PS2Net, where does it read the config file from?
It reads the IPCONFIG.DAT file from mc0:/SYS-CONF

and it says No Disc at the top of the screen...is that normal??
Yes I believe so if you have disc control option off.

i can connect with wsftp, but i can't mount harddrives...

thanks a bundle guys keep up the good work

I've used FileZilla, Bulletproof FTP, and Windows command line FTP clients which all work fine here. Make sure you're mounting it correctly SITE MNT /pfs/0/ hdd:+MAIN. You can also cheat by viewing a partition with launchELF. By doing this it will mount the partition for you then all you have to do is open pfs/0/ in your FTP client.

[SnowSurfer]

ok thanks for the help, now i am able to mount a partition, this is great, no need for execftp anymore

[zabolyx]

I didn't know about the mounting from within Lunch Elf "lunch"

[HypERSoniC]

well it makes sense, since to use data on the hdd you must mount the filesystem before hand

[dlanor]

In fact there is a nice side effect of this feature, which allows you to use the LaunchELF browser as a dynamic partition selector for your FTP client. First open one HDD partition with the LaunchELF browser and then FTP into /pfs/0/ to view the contents of that partition. Next use LaunchELF to browse to another partition and then click the refresh button in the FTP client toolbar. This automagically changes the contents list from the old partition to the new one.

This is just an 'oddity' to a feature-packed FTP client like FlashFXP, which already has very convenient ways to mount/unmount partitions (user defined system commands). But to a more primitive client I think this 'oddity' could be a very useful feature, since many of them lack any real support for the kind of mounting needed by the PS2. Some of them require you to retype the mount/unmount commands completely each time you use one, and that gets verrry boring, verrrrry quickly... ;)

So then it's much more convenient to pick up the PS2 controller and just browse to the new partition instead.

Best regards: dlanor

[dlanor]

----- snip ----- re: various changes to FTP server
I'm not too keen on working on the FTP server myself, so I'll entrust it to you.

----- snip ----- re: latest bugfix to ps2ftpd

Edit: OK get the "i" version from the first page. The ps2ftpd src package and irx are included separately.
I'm not happy with the format of this release..., for two reasons:

1: It is not our task, nor is this the right place, to release new versions of ps2ftpd. It's proper home site is ps2dev, and proper release of that package should be done through CVS. Making a private version for use in compiling LaunchELF is one thing, and perfectly fine, but only as long as it's kept part of the LaunchELF project. (Just as we did with usb_mass.)

2: This format means that anyone with just the uLaunchELF ZIP plus access to ps2dev is no longer able to compile the latest version correctly. He must rely on the supplied version of ps2ftpd for its changes.

I suggest that we do what we did before, adding a subfolder named 'src (new and changed)\ps2ftpd\' to hold the modified source files of ps2ftpd, while still including the ps2ftpd.irx (precompiled with latest changes) in the folder 'src (new and changed)\modules\'. It may be a little messier, but it supplies all that is needed in a single ZIP, while also avoiding potential trouble about the official ps2ftpd maintenance. (A task I do not want us to 'inherit'.)

Best regards: dlanor

[dlanor]

ok... but the modules couldn't reset the IOP and would be branched to. so the module would not be a seperate program but more like a sub routine of Launch Elf... once the end of the routine is reached Launch Elf would just continue with its normal function...
True, but that is only a small part of it. In fact very few worthwhile plugins could work with just an IOP part, or just an EE part. Like real applications they would need both EE and IOP modules, and that easily gets very messy. Methods must be implemented to have the plugins request use of global resources, and return them properly after such use. Additional methods would also have to be implemented for cases of use that don't fit the request/return pattern. Effectively this means developing a PS2 specific API for subprogram use of console resources, which the plugins would use instead of normal OS calls. The complications grow quickly when you dig into this, trust me...

Of course, as standard app like HD Loader would not be able to return control to Launch Elf,
Obviously not, as each plugin must be coded to make use of the specific API mentioned above. Only then can system resources be used in a 'returnable' way, so that LaunchELF can continue its work undisturbed after a plugin has finished.

the way we did it with QuickBASIC was to make a subroutine and use special C++ based functions to find the location of the subrourine in the RAM then use this as the linking place to upload the modules... then when the module has been used or a nother one was needed just be removed from RAM and a new module would replace it.
But QuickBASIC itself rests on a solid OS, and relies on it to handle all the real tasks. To implement a plugin system is then mostly a matter of designing proper 'wrapper' functions to handle arguments and return values. But in our case we'd also have to perform much of the work normally handled by an OS, since we have none...

man I wish I knew more about C... I'd love to jump in and do some work with this app....I always thought that programming a game would be great but now I think something like this would end up being more satisfying....
I think you're right about that, though I've never had a unique game idea good enough to develop very far, so I may not be the best judge of this.

I do have to say that the source I have DLed is very clean... and seems well organized.

And "D" I'm not saying that I expext this from you guys..... I know you guys have plans and that you are working on... I'm just answering all these guys that keep pestering about this and that (why can't Launch Elf view movies, why can't it do my laundry, where's my handjob....) and explaining the best means for this implementation.
I quite understand, and I personally don't mind any suggestions for functional improvements, though few of them may be realized in the end. The suggestions I dislike are the type of 'eye candy' cosmetic stuff that would (in some cases) even reduce functionality if implemented.

This subject of plugins and subprogram modules in general is highly functional stuff, though I'm afraid it's too large a concept (design-wise) for short term development as part of LaunchELF. Maybe later, if someone starts work on generic subprogram use over at ps2dev, so we can get wider support for this sort of thing, using PS2SDK libs. That is really where stuff of this sort belongs, as part of the PS2SDK project.

Best regards: dlanor

[HuMz]

dlanor, im doing a little personal tweaking on your awesome prog... and basically I wanna have the timeout counter stop only when I push select (option button) not when I move the DPAD. So editing the main.c file, I wanna // the line 989 "case DPAD: [...]" to the line 1019 "[...] break;" do you think that will do what I want... thanks and btw to use the makefile you need linux right I will use knoppix I think

[E P]

----- snip ----- re: various changes to FTP server
I'm not too keen on working on the FTP server myself, so I'll entrust it to you.

I'm not happy with the format of this release..., for two reasons:

1: It is not our task, nor is this the right place, to release new versions of ps2ftpd. It's proper home site is ps2dev, and proper release of that package should be done through CVS. Making a private version for use in compiling LaunchELF is one thing, and perfectly fine, but only as long as it's kept part of the LaunchELF project. (Just as we did with usb_mass.)

2: This format means that anyone with just the uLaunchELF ZIP plus access to ps2dev is no longer able to compile the latest version correctly. He must rely on the supplied version of ps2ftpd for its changes.

I suggest that we do what we did before, adding a subfolder named 'src (new and changed)\ps2ftpd\' to hold the modified source files of ps2ftpd, while still including the ps2ftpd.irx (precompiled with latest changes) in the folder 'src (new and changed)\modules\'. It may be a little messier, but it supplies all that is needed in a single ZIP, while also avoiding potential trouble about the official ps2ftpd maintenance. (A task I do not want us to 'inherit'.)

Best regards: dlanor

That's the way I wanted it to begin with. :) I got the feeling that you wanted them kept separate so that's why I did it. I guess I should stop the second guessing since we've pretty much agreed with everything thus far.

Anyway I changed the release package to the way I first wanted to do it like you mentioned. It should make things a lot easier this way that's for sure. :)

The only thing I wasn't sure of at first was whether to include everything like you did for host - the whole build package. However, it's probably better to treat ps2ftpd like usb_mass only include the changed src files and compiled modules for unofficial LaunchELF.

Another note: I have decided to drop diff files as I think it's easier just to work with the complete source files. Although I still may release diffs at a later time.

[dlanor]

dlanor, im doing a little personal tweaking on your awesome prog...
Fine, except that it's not 'my prog' at all. I'm just one of the guys who try to improve on this prog which another guy created. Unfortunately I can't give him proper credit (by name) as he never revealed who he is. (All his docs were in japanese, which I can't read.)

and basically I wanna have the timeout counter stop only when I push select (option button) not when I move the DPAD. So editing the main.c file, I wanna // the line 989 "case DPAD: [...]" to the line 1019 "[...] break;" do you think that will do what I want...
No, that will not work. The crucial section is at 1022, containing this:
if(timeout/SCANRATE==0 && setting->dirElf[0][0] && mode==BUTTON){
RunElf(setting->dirElf[0]);
timeout = (setting->timeout+1)*SCANRATE;
}
This makes the timeout counter value be ignored when the variable 'mode' has any other value than BUTTON. If you inspect the code more you'll find that the timeout counter is NEVER halted. It keeps decrementing (at line 945) for each turn of the main loop. Instead the counter is simply ignored when we consider timeout to be halted. This is controlled by the variable 'mode', not only for the 'main' function, but also for the 'drawMainScreen' function, which uses it to know when to display the timeout counter value (rounded to seconds).

The lines you referred to only affect the timeout in other ways, mainly resetting the timeout value when reactivating the timeout by setting mode=BUTTON. This is needed to avoid having the timeout strike immediately for such cases.

thanks and btw to use the makefile you need linux right I will use knoppix I think
You do not need Linux to use makefiles.

What you need is a GCC setup, and for some of the tools you need a Linux-like environment. I use Windows XP myself, with Cygwin installed for the Linux-like environment, and with the ps2dev toolchain installed for the PS2 related stuff.

Best regards: dlanor

[SnowSurfer]

dlanor do you happen to have a guide to getting started with cygwin and ps2 programming in general? even if it is something as simple as a hello world thing

thanks :)

[dlanor]

That's the way I wanted it to begin with. :) I got the feeling that you wanted them kept separate so that's why I did it. I guess I should stop the second guessing since we've pretty much agreed with everything thus far.
We do seem to be pretty much 'in tune' on these things, which is a very good thing for the project of course. Imagine the problems we'd have if we disagreed on everything instead... (shudder)


Anyway I changed the release package to the way I first wanted to do it like you mentioned. It should make things a lot easier this way that's for sure. :)
Great.

The only thing I wasn't sure of at first was whether to include everything like you did for host - the whole build package.
Ah, then I see, but I had a specific reason for that. This package does not exist as an independent project in the ps2dev.org CVS, so it could be difficult for someone not already familiar with it to find it. And even if they did find it, it might not be exactly the same one I used (again because of the lack of a CVS standard for it).

However, it's probably better to treat ps2ftpd like usb_mass only include the changed src files and compiled modules for unofficial LaunchELF.
I suggest we use this method for all components that exist as independent projects in CVS (just in case we add some more later).

Another note: I have decided to drop diff files as I think it's easier just to work with the complete source files. Although I still may release diffs at a later time.
Agreed. Supplying them won't cause any harm, though I will prefer using the complete files in any case.

----- subject change -----

I've been thinking a lot about what the next big addition should be, in functionality that is, not necessarily in size.

One thing I've wanted, but don't think we're ready for, is some kind of plugin or other subprogram capability. But that may have to wait a while, as it alone would be a major project.

Another thing that may fill some of the same needs is some kind of script interpreter, allowing us to use simple batch programs. One typical use of such scripting would be to let LaunchELF handle installation of exploits and other homebrew software. This way less experienced users can easily do such things by using scripts prepared by the more experienced ones. Such script handling is already implemented by some other launchers (eg: DMS Explorer), so if LaunchELF is to replace those, then it too should have such a capability (though very different in its implementation).

I'm considering making a script language interpreter going beyond those simple ones I've seen for the PS2 so far, so that it may be useful in almost the same ways as a real programming language. Simple loop and choice constructs should not be all that hard to implement, and with those and some variable handling, the distance is not so very far to a proper programming language...

So what do you think ?

Best regards: dlanor

[dlanor]

dlanor do you happen to have a guide to getting started with cygwin and ps2 programming in general? even if it is something as simple as a hello world thing

thanks :)
Sorry, but no. I haven't seen any comprehensive guide on this stuff.

My current setup was achieved by first making a generic Cygwin install, including most stuff, EXCEPT database applications and X-Windows specific stuff. Then with that as a basis, I continued by using the toolchain script of Lukasz Bruun, which you can find on his site http://lukasz.dk/. For most other PS2DEV related things the central site is of course http://ps2dev.org/.

I also use the separately installed program WinCvs v1.3 to fetch sources from the ps2dev CVS repository, mainly because I prefer a Windows client for this sort of thing. But Cygwin also has command line tools for it, which you can use from bash. (Maybe even directly from Windows command.exe, though a more proper 'shell' is preferable.)

Best regards: dlanor

[BarFly]

I know this might be considered spam or whatever but I'd like to thank you guys for
keeping this program up to date. I use it every time I turn on my ps2 and I realised I
haven't even uttered a small thank you. so thank you ;) keep up the good work!

[E P]

----- subject change -----

I've been thinking a lot about what the next big addition should be, in functionality that is, not necessarily in size.

One thing I've wanted, but don't think we're ready for, is some kind of plugin or other subprogram capability. But that may have to wait a while, as it alone would be a major project.

Yeah this is something I keep hearing about but I'm not sure what it could be used for. However, I could see this as a huge asset if we had more developers to make little apps for LaunchELF and what not.

Another thing that may fill some of the same needs is some kind of script interpreter, allowing us to use simple batch programs. One typical use of such scripting would be to let LaunchELF handle installation of exploits and other homebrew software. This way less experienced users can easily do such things by using scripts prepared by the more experienced ones. Such script handling is already implemented by some other launchers (eg: DMS Explorer), so if LaunchELF is to replace those, then it too should have such a capability (though very different in its implementation).

I'm considering making a script language interpreter going beyond those simple ones I've seen for the PS2 so far, so that it may be useful in almost the same ways as a real programming language. Simple loop and choice constructs should not be all that hard to implement, and with those and some variable handling, the distance is not so very far to a proper programming language...

So what do you think ?

Best regards: dlanor
Yes, this could be good but I haven't tried scripting with any loader or even used DMS Explorer. I remember seeing exploit install scripts before but I ended up going in a different direction making X-port exploit saves.

Yeah I do know install scripts are mostly for those who have mod chips. Although I agree with the possibility of phasing out yet another program like we did with ExecFTP. :) I think that's a good idea to go beyond normal scripting like you said. The extra functionality could come in handy but I'm not sure what it would require to implement into LaunchELF.

Perhaps I just need to put together a listing of things that have been considered and list issues that we need to resolve.

On a side note: I have been looking at possibly getting one of Datel's Max Memory 64MB cards. Only can find the 32 MB ones in stores here. I know that the 32MB ones are supposed to work with X-port but I'm not sure about the 64MB ones. The X-port can format 8, 16, and 32 meg cards as I found with a little hacking. However, I know that just because the X-port can't format a 64MB card doesn't mean it can't simply transfer saves to and from the memory card.

I still got to get all my files backed up so I can get my 8 Meg card cleaned up again. To bad neither MCManager nor X-port can restore the timestamps of the restored saves. My backup routine involves backups with X-port and MCManger so I have backups on both the PC and PS2. I also keep an Excel spread sheet for listing timestamps, filesizes, and names of the saves. Unfortunately, this all takes a lot of time to maintain and I'm not even half way done yet.

[zabolyx]

yeah... I think ebgames has the 64MB cards.... I've thought about getting 2 of them.... I'm getting tired of copying from MC to HDD and back with games and saves....

[-priestar-]

just a few questions :

is it possible to read normal cdrs using the filebrowser with an unmodded ps2?
i want to make a cdr containing all the elfs & tools i need. But every cd i made was unreadable with the filebrowser.
Or do i just have to use special Nero settings to get this cdr working?

thx :)

[HuMz]

thanks dlanor

[zabolyx]

Priestar

you would need a modchip or use the swap trick... the CD needs to be in PS2 CD format...

Hey E and D... are you guys going to include the new CDDAFS in the program?

[Kormann]

I have DM$3 chip, I started to use LaunchELF today..
I found a bug that it would be interesting if someone could fix it...
My DM$3 is configured to auto-change PS2VIDEO to NTSC, so pal games that are installed with HDL would work well..

In the past when I used this option plus dm$hddexplorer1.31 it worked perfectly
but now when I try this with LaunchELF.. LaunchELF get a blackscreen of death.. so i think this dm$ video fix option conflicts with LaunchELF..

Can you please fix this dudes?
Thx 4 all
Kormann

[E P]

Hey E and D... are you guys going to include the new CDDAFS in the program?

Dlanor said before that it would be nice to try to get CDDAFS into launchELF but I myself haven't even looked into it. I think CDDAFS is still a WIP so I'm not sure it should be added just yet but if someone is willing I guess it wouldn't be a problem.

I have DM$3 chip, I started to use LaunchELF today..
I found a bug that it would be interesting if someone could fix it...
My DM$3 is configured to auto-change PS2VIDEO to NTSC, so pal games that are installed with HDL would work well..

In the past when I used this option plus dm$hddexplorer1.31 it worked perfectly
but now when I try this with LaunchELF.. LaunchELF get a blackscreen of death.. so i think this dm$ video fix option conflicts with LaunchELF..

Can you please fix this dudes?
Thx 4 all
Kormann

Sorry Kormann I don't even have a chip so I can't be of much help. Does this problem occur with both the compressed and uncompressed binaries? I don't recall any of us changing the video mode functionality mabe it changed with the official v3.41 which our source changes are based on.

[Kormann]

;/ It happens with uncompressed binary.. i haven't tried the compressed.

[BarFly]

What are your other settings Kormann? I have a DM$3 and had the PS2 video set to none.
So I changed it to what you had (Force NTSC) just to test and its still works fine.
The DM$ doesnt conflict with uLaunchELF one bit.
Do you have it in the BOOT directory on mc0?

[Kormann]

No, I have uLaunchELF installed at psf0:/__boot/boot.elf
I replaced DMSHDDExplorer ELF for uLaunchELF.
Oh and also I had put "reset IOP" enabled at uLaunchELF.
And I also had created a boot.cfg (a config for dms) with "reset IOP".
Maybe thats the problem.. dunno

I ll test it later
Kormann

[dlanor]

No, I have uLaunchELF installed at psf0:/__boot/boot.elf
I replaced DMSHDDExplorer ELF for uLaunchELF.
I boot it from "hdd0:/__boot/boot.elf" using Matrix Infinity, which works fine. But LaunchELF contains no special fixes to cater to any specific mod chip, so any problems you see with the DMS chip are bugs that it has, not bugs of LaunchELF.

It's not very surprising, as their Dev.2 boot method has always been defined only for their own supplied HDDExplorer, not for general homebrew use. Because of that, they've never been forced to fix the limitations that such use would have exposed, but which were not shown by HDDExplorer.

I'd still be willing to find a workaround for such DMS bugs, except that I have no such console to test with. So I'm afraid someone else will have to do that.

Oh and also I had put "reset IOP" enabled at uLaunchELF.
That is the preferable mode to use, unless it conflicts with some other need. It gives LaunchELF a clean start, after throwing out any old IOP modules that may have been in use before LaunchELF. But I do hope you realize that you must put this LAUNCHELF.CNF in mc0:/SYS-CONF/ when you are booting from HDD.

And I also had created a boot.cfg (a config for dms) with "reset IOP".
Maybe thats the problem.. dunno
Doing it twice should not be harmful, assuming it's done *correctly* both times. In this I can only answer for the IOP reset of LaunchELF, which has been extensively debugged for some time now. I trust it myself, but you make up your own mind...

In any case, though there's not much sense in doing it twice, why not try all four possible combinations? Surely it would be worth the effort of four reboots to find out if any of those combinations work right.

Best regards: dlanor

[BarFly]

Yeah it's def a Dev.2 problem on the DM$ side, I tried to boot from Dev.2 by
replacing their elf with this and got the black screen or the $ony browser. I
looked everywhere and many say you can't boot because of how DM$ made it
only choose their elf (tho I've heard of others booting to HDL...). Some say its
because LaunchELF wasnt made to boot from HD (which is pure uninformed crap)
unless someone else has a DM$3 and can shed some light on this, I'd say just
boot of MC. The compressed one is more than small enough not to interfere
with game saves or anything like that. :)

[Neme]

Hi all!
I created a DVD (using cdvdgen) that I use to boot LaunchELF (CDs are very noisy and my PS2 doesn't like them). I also added some utils to the compilation. The booting works fine but when I try to browse the contents of the DVD in LaunchELF via 'cdfs:', the listing is empty. Same happens when trying to browse my older boot DVD that was used to boot HDLoader. On the other hand when I insert a general data DVD-ROM which was created with whatever standard burning software, LaunchELF reads the contents just fine. I did some search and found this thread (http://forums.ps2dev.org/viewtopic.php?t=281&sid=a78cc28fdb784657901e8db2c66d63f2) on the ps2dev forums.

Can it be that because of some minor difference in the DVD structure created
by cdvdgen the cdvd.irx driver cannot handle it properly? Has anyone got the
same problem? Would be nice if someone could compile & test LaunchELF with
the cdvd fix mentioned in the thread above.

[joe34]

Hi all!
I created a DVD (using cdvdgen) that I use to boot LaunchELF (CDs are very noisy and my PS2 doesn't like them). I also added some utils to the compilation. The booting works fine but when I try to browse the contents of the DVD in LaunchELF via 'cdfs:', the listing is empty. Same happens when trying to browse my older boot DVD that was used to boot HDLoader. On the other hand when I insert a general data DVD-ROM which was created with whatever standard burning software, LaunchELF reads the contents just fine. I did some search and found this thread (http://forums.ps2dev.org/viewtopic.php?t=281&sid=a78cc28fdb784657901e8db2c66d63f2) on the ps2dev forums.

Can it be that because of some minor difference in the DVD structure created
by cdvdgen the cdvd.irx driver cannot handle it properly? Has anyone got the
same problem? Would be nice if someone could compile & test LaunchELF with
the cdvd fix mentioned in the thread above.


Sorry if I'm missing something here, but couldn't you then just edit the iso of a DVD image a program created and keep the main structure but then hide your own files (ELFs and things) in the VIDEO_TS or something?

[Neme]

Sorry if I'm missing something here, but couldn't you then just edit the iso of a DVD image a program created and keep the main structure but then hide your own files (ELFs and things) in the VIDEO_TS or something?

I'm not really competent in this DVD-ROM thing and all I know is that in order to create a PS2 bootable DVD-ROM you need to use cdvdgen by Sony. My problem is that LaunchELF is not able to read the contents of any of such DVDs. If you know some other method of making bootable DVD discs that work with LaunchELF, please let me know.

[BarFly]

@Neme:
I use Nero instead of cdvdgen. When you make a new compilation to DVD use "DVD-ROM (UDF/ISO)".

I know the ISO tab doesnt matter but here's what I have....The UDF tab is IMPORTANT however if you want it to boot.

Under the ISO tab: for system I have "ISO 9660 + Joliet", for file name length i have "(Level 2)",
for character set "ISO 9660 (standard ISO CD-ROM)". Then for relax restrictions: I have "Allow
path depth of more than 8 directories", "Allow more than 255 chars in path" and "Allow more
than 64 chars for Joilet names" checked off.

Then under the UDF tab: I have Physical Partition selected and UDF 1.02 for File system.

Then import your files as usual, don't forget that SYSTEM.CNF pointing at BOOT.ELF or whatever your uLaunchELF is called.

Boots everytime on DVD-RW too (just incase I need to update something on my compilation) ;)

Hope this helps you out somewhat...and assuming you have a modchip try a RW (if your mod chip allows the PS2 to read them)
I don't want to be blamed for a coaster :p

[jackielo]

dlanor and EP,

Do I can build a Japanese version of LaunnchELF? What have to be done?

[Neme]

BarFly,
Thanks a lot, I'll try that as soon as I get home.

[dlanor]

dlanor and EP,

Do I can build a Japanese version of LaunnchELF? What have to be done?Well, you obviously need a ps2dev setup, and use this to recompile the code after modifying all the text strings to use Kana rather than english characters.

Less obvious is that you also need to modify the text display routines, so as to be able to use a font containing Kana characters, and of course you must also add such a font to the code as well. I'd suggest using the ELISA100.FNT, which is already used (optionally) by LaunchELF for showing japanese save game titles.

Finally, you'll probably have to redesign the screen layout of some config screens, due to the larger height needed by Kana characters.

All in all, it's a lot more work than I'd be willing to invest, just to produce a localized version. I never considered making a version localized even for Sweden, my own homeland. IMHO such work is a waste of time. I'd rather spend my time on real improvements (or recreations of course ;) ).

Best regards: dlanor

[dlanor]

@Neme:
Concerning your problems with using LaunchELF to browse DVD discs, I'm afraid that's something I can not experiment with at all. My PS2 lost all ability to read DVD discs several months ago, so I have no way of testing any PS2 access to any DVD media.

Hopefully other testers and dev'ers (E P ?) can check this problem out and see if it truly is a LaunchELF bug. Naturally it is our intention that LaunchELF should be able to read ALL media types that can be used with a normal PS2, regardless of which program (here cdvdgen) has been used to create the image. But how best to achieve this remains to be seen, and it is work in which I can't participate myself, because of my half-dead PS2 laser...

Best regards: dlanor

[E P]

@Neme:
Concerning your problems with using LaunchELF to browse DVD discs, I'm afraid that's something I can not experiment with at all. My PS2 lost all ability to read DVD discs several months ago, so I have no way of testing any PS2 access to any DVD media.

Hopefully other testers and dev'ers (E P ?) can check this problem out and see if it truly is a LaunchELF bug. Naturally it is our intention that LaunchELF should be able to read ALL media types that can be used with a normal PS2, regardless of which program (here cdvdgen) has been used to create the image. But how best to achieve this remains to be seen, and it is work in which I can't participate myself, because of my half-dead PS2 laser...

Best regards: dlanor

OK Neme, you're right about the inability to read DVD's how strange. I saw the thread at the ps2dev forums that you mentioned but I don't understand how exactly this is supposed to be implemented.

ole mentioned making changes to cdvd_iop.c
int getSectorCount(int dirSize) {
int result = dirSize / 2048;
if ((dirSize % 2048 ) > 0) {
result++;
}
return result;
}

I don't see where the variable dirSize comes from. Also there are two instances of ">>11" and two instances of ">> 11" for a total of four in the cdvd_iop.c source code. I also don't want to change anything unless I know that it won't mess something else up. At least, we know about the bug now.

[jackielo]

Well, you obviously need a ps2dev setup, and use this to recompile the code after modifying all the text strings to use Kana rather than english characters.

Less obvious is that you also need to modify the text display routines, so as to be able to use a font containing Kana characters, and of course you must also add such a font to the code as well. I'd suggest using the ELISA100.FNT, which is already used (optionally) by LaunchELF for showing japanese save game titles.

Finally, you'll probably have to redesign the screen layout of some config screens, due to the larger height needed by Kana characters.

All in all, it's a lot more work than I'd be willing to invest, just to produce a localized version. I never considered making a version localized even for Sweden, my own homeland. IMHO such work is a waste of time. I'd rather spend my time on real improvements (or recreations of course ;) ).

Best regards: dlanor

dlanor,

I totally agree with you. The most important thing is real function improvement. But I just want to learn the PS2 programming from locolize a open source application.

thanks.

Jackie

[dlanor]

int getSectorCount(int dirSize) {
int result = dirSize / 2048;
if ((dirSize % 2048 ) > 0) {
result++;
}
return result;
}

I don't see where the variable dirSize comes from. Also there are two instances of ">>11" and two instances of ">> 11" for a total of four in the cdvd_iop.c source code. I also don't want to change anything unless I know that it won't mess something else up. At least, we know about the bug now.I just want to emphasize some connections you might have missed (I'm unclear on that):

The operation ">> 11" is in fact identical to the operation "/ 2048", so those sections with the bit shifts are probably converting byte counts to sector counts too, just like the quoted code section.

Similarily, you can expect the operation "% 2048" to be matched by equivalent operations like "& 2047" or even "& ((1<<11)-1)" or suchlike cryptic stuff. With integer math, it's all the same really, but some expressions yield better optimizations.

Best regards: dlanor

[Neme]

@E P:
As Ole mentioned in his original post the problem is likely the bad sector number calculation from TOC and DIR size. I just browsed through the cdvd_iop.c source and found only one instance where sector_num is calculated from tocSize at line 1033:
CachedDirInfo.sector_num = CDVolDesc.rootToc.tocSize>>11;
This can easily be taken care of by changing the line to something like:
CachedDirInfo.sector_num = (CDVolDesc.rootToc.tocSize>>11) + ((CDVolDesc.rootToc.tocSize & 2047)!=0);
Interestingly the creator used this same formula at other places in the code,
e.g. check line 473. This fix makes sure that for TOC sizes that are not multiples of 2048, the bits that get shifted out by the >>11 operation are taken into account as well. There are other cases where >>11 is used, for example at line 1236:
CachedDirInfo.sector_num = localTocEntry.fileSize >> 11;
I guess as this is sector_num calculation from fileSize it doesn't concern us, however if later problems occur when copying files etc. you could try the same fix on that line as well.

Can you possibly test the fix for line 1033 above initially, to see if it reads the TOC and if file copy is working?

[adam31]

just a few questions :

is it possible to read normal cdrs using the filebrowser with an unmodded ps2?
i want to make a cdr containing all the elfs & tools i need. But every cd i made was unreadable with the filebrowser.
Or do i just have to use special Nero settings to get this cdr working?

thx :)

just use a flashdrive, a lot easier...then you can access files through mass: on launchelf...

[E P]

OK Neme, your first noted src change gets root dvd support and the second is required for vewing the subdirectories. I made the changes to cdvd_iop.c using evilo's modified CDVD Filesystem v1.16 as I haven't been able to get v1.15 to compile.

I still have many problems with the module so it looks like I won't be releasing a "j" version anytime soon. The newly modified cdvd.irx module is causing problems with launchELF's ability to launch applications.

Anyway I will still probably release a test build for you and anyone else to test sometime. :)

Thanks.

[dlanor]

OK Neme, your first noted src change gets root dvd support and the second is required for vewing the subdirectories.
Good! So this DVD compatibility problem is completely solved then. Right ?

I made the changes to cdvd_iop.c using evilo's modified CDVD Filesystem v1.16 as I haven't been able to get v1.15 to compile.
v1.15 compiles error-free here..., so I don't see why it fails to compile for you. Are you sure your v1.15 files are healthy ?
I can send you mine if you wish.

I still have many problems with the module so it looks like I won't be releasing a "j" version anytime soon. The newly modified cdvd.irx module is causing problems with launchELF's ability to launch applications.
AFAIK no version of LaunchELF has ever been tested with v1.16 of libcdvd, so there could be any number of compatibility issues we've never met before. Better to stick with the module we're familiar with (for now) and add your improvements to it. Of course, we need to solve your inability to compile that version first, but that has to be done anyway IMHO.

Anyway I will still probably release a test build for you and anyone else to test sometime. :)
Good, though I won't be able to test this stuff myself anyway, due to the half-dead state of my laser...

Best regards: dlanor

[rivaldinho]

when i use the ps2net function it won't reckonise the hdd just the mc so i have to still use execftp

[E P]

Good! So this DVD compatibility problem is completely solved then. Right ?
Yes, it work now. I tried my Burnout 2 disc and I can now view all the directories and files.

v1.15 compiles error-free here..., so I don't see why it fails to compile for you. Are you sure your v1.15 files are healthy ?
I can send you mine if you wish.
I thought I got it to compile before but I still haven't found a way around what appears to be a ps2lib dependency. So if you can get yours to compile with the current SDK please post them. Thanks.

AFAIK no version of LaunchELF has ever been tested with v1.16 of libcdvd, so there could be any number of compatibility issues we've never met before. Better to stick with the module we're familiar with (for now) and add your improvements to it. Of course, we need to solve your inability to compile that version first, but that has to be done anyway IMHO.
Exactly that's just it. There are strange issues with 1.16 with or without those slight changes so it looks like I just need to get 1.15 to compile.

Good, though I won't be able to test this stuff myself anyway, due to the half-dead state of my laser...

Best regards: dlanor
Yeah I know but at least the testing of this DVD reading issue doesn't require a modchip since I don't have one. :)

[E P]

when i use the ps2net function it won't reckonise the hdd just the mc so i have to still use execftp

You should see both a mc directory and pfs directory in your ftp client if you have a hard drive in your playstation 2. The hdd directory viewing from ftp client side was removed because it is pretty much useless.

You could also try letting launchELF mount a partition and then view the partition with your client in pfs/0.

[rivaldinho]

my partition is called +ELFS so should i put SITE MNT /pfs/0/ hdd:+ELFS and theb search pfs/0 for the partition i mounted

[zabolyx]

yes

[rivaldinho]

cheers

[dlanor]

Yes, it work now. I tried my Burnout 2 disc and I can now view all the directories and files.
Great! Then we just need to fix your libcdvd compilation problem.

I thought I got it to compile before but I still haven't found a way around what appears to be a ps2lib dependency. So if you can get yours to compile with the current SDK please post them. Thanks.
I never said I use current PS2SDK to compile it. It wasn't created to use that, so doing this would demand a major rewrite, which simply isn't on...

I compile it with PS2LIB, as intended in the original design, and I think your problem may be due to an incorrect PS2LIB version. I use "v2.2-final", and with this I have no problems compiling. I don't think there's any problem with the libcdvd files themselves. I don't recall having to edit anything there, not even the 'Makefile' (though it usually needs to be edited for PS2LIB projects). I think it'll work OK for you too, if you just use the right PS2LIB version.

Please try again with PS2LIB v2.2-final, and if it still doesn't work just let me know. I'll send/post my entire setup if needed, but I'd rather avoid wasting the time that would take (both yours and mine...)

Best regards: dlanor

[E P]

I never said I use current PS2SDK to compile it. It wasn't created to use that, so doing this would demand a major rewrite, which simply isn't on...

I compile it with PS2LIB, as intended in the original design, and I think your problem may be due to an incorrect PS2LIB version. I use "v2.2-final", and with this I have no problems compiling. I don't think there's any problem with the libcdvd files themselves. I don't recall having to edit anything there, not even the 'Makefile' (though it usually needs to be edited for PS2LIB projects). I think it'll work OK for you too, if you just use the right PS2LIB version.

Please try again with PS2LIB v2.2-final, and if it still doesn't work just let me know. I'll send/post my entire setup if needed, but I'd rather avoid wasting the time that would take (both yours and mine...)

Best regards: dlanor
No I killed off ps2lib but I backed it up to a cd sometime ago. I just thought you did something to get it working with the current sdk. I know libcdvd 1.15 is old. I was just hoping to get it working with the sdk but even evilo's that does compile with the sdk has problems with LaunchELF. Oh well, I don't think we'll be recompiling libcdvd a whole lot anyway.

OK I got it to compile with ps2lib so I'll do some more testing. I'll see if there are any issues like I had before with evilo's modified libcdvd. Then I should be able to release a new version "j" with the changes to libcdvd's cdvd_iop.c. :)

Edit: OK I have released "j" please test it out and report any new errors. :)

[pangestu80]

You should see both a mc directory and pfs directory in your ftp client if you have a hard drive in your playstation 2. The hdd directory viewing from ftp client side was removed because it is pretty much useless.

You could also try letting launchELF mount a partition and then view the partition with your client in pfs/0.

sorry i'm a complete noob on this, how do you mount a partition using launchelf?

there is 'host:' in launchelf, what does it do/connect to? its empty when i open it....

thx...

[E P]

sorry i'm a complete noob on this, how do you mount a partition using launchelf?

there is 'host:' in launchelf, what does it do/connect to? its empty when i open it....

thx...

Host requires ps2client to run from the PC side. It's a little hard to expain without going into great detail.

To mount a partiton with LaunchELF after running PS2Net, view the desired partition with launchELF's FileBrowser.

Note: You can assign both PS2Net and FileBrowser to keys. They are both listed in the MISC menu. Just run PS2Net then access the FileBrowser and view a particular partition to make LaunchELF mount it. Now connect with a PC FTP client and connect to the mounted partition at PFS/0. When you're all done, close the FTP client on the PC side. Then press select and LaunchELF will unmount the partition for you.

[jackielo]

Another question,

I have made a LaunchELF iso file with ELISA100.FNT Japanese font file. But it can not work correctly. LaunchELF only can load this font file from the CNF's directory - SYS-CONF. Do you can change the search pass to ELF's directory first? tkx.

Jackie

[dlanor]

Host requires ps2client to run from the PC side. It's a little hard to expain without going into great detail.
Not all that hard, really, if you concentrate on keeping it simple.
Here's a fairly simple explanation of basic host: usage:

First of all, host: uses the same networking stuff that FTP uses, set up the same way. So you either use the default IP addresses, or you set up your own preferences in "mc0:/SYS-CONF/IPCONFIG.DAT". This is described in every turorial on FTP, so no need to repeat it here.

Second, you need to get hold of "ps2client.exe", the PC-side client program for the PS2Link server. The 'host:' part of ps2client is really a server, though, and that's how we use it with LaunchELF as the PS2-side client.

Third, you need to know the '3-point startup' method for host: in LaunchELF:

1: In LaunchELF, attempt to browse to host: (times out to empty dir)
-- This sets up the PS2 end of the host interface, similar to PS2Link launch.

2: On PC, start "ps2client.exe -h YOUR_PS2_IP_NUMBER listen"
-- Use either a dos command, batch file, or an edited shortcut for this.
-- It sets up "ps2client" to run in 'listen' mode, as a host: server.

3: In LaunchELF, make a new attempt to browse to host:
-- This will now establish contact and show the host: root directory.

What the host: root directory will show can be varied by very flexible methods, but I promised to keep this simple... If you don't do anything special it will be identical to the work directory of "ps2client.exe", and frequently (depends on starting method) that will be the same directory where that program is stored.

Best regards: dlanor

[dlanor]

Another question,

I have made a LaunchELF iso file with ELISA100.FNT Japanese font file. But it can not work correctly. LaunchELF only can load this font file from the CNF's directory - SYS-CONF.
This is intentional. Adding this font is a form of configuration, so it belongs with the other configuration stuff, stored in the same place as the CNF. At least that's my reasoning, but in fact the font handling is mostly untouched from the original source release.

Do you can change the search pass to ELF's directory first? tkx.
Of course I could change the search methods, but I'd need a good reason.

Maybe I haven't understood you correctly, but I really don't see why you have a problem with using SYS-CONF for the font, when you do mention using it for the CNF...

Best regards: dlanor

[jackielo]

This is intentional. Adding this font is a form of configuration, so it belongs with the other configuration stuff, stored in the same place as the CNF. At least that's my reasoning, but in fact the font handling is mostly untouched from the original source release.

Of course I could change the search methods, but I'd need a good reason.

Maybe I haven't understood you correctly, but I really don't see why you have a problem with using SYS-CONF for the font, when you do mention using it for the CNF...

Best regards: dlanor

I have made a bootable LaunchELF CD. It is working great in my PS2 with MC0:\SYS-CONF\ directory. But I also want to share it with my firends. They just want to run it from CD. So I have this quest to change the font file' searching pass. tks.

Any way, thank you and EP to keeping enhance this great app.

Jackie

[dlanor]

I have made a bootable LaunchELF CD. It is working great in my PS2 with MC0:\SYS-CONF\ directory. But I also want to share it with my firends. They just want to run it from CD. So I have this quest to change the font file' searching pass. tks.
Ok, I see what you mean now, as it might not work for them if they have no SYS-CONF folder with that font on their MC. I'll look into it.

However, I really think that everyone who uses homebrew programs for the PS2 should have a SYS-CONF folder, so perhaps it would be a good idea for you to include such a folder on your CD.

Then when you want to use that CD with the PS2 of a friend, who has no SYS-CONF, you can just start by copying that folder to his MC, thus giving him both your default LAUNCHELF.CNF and ELISA100.FNT, as well as the icon.sys and icon files needed by the PS2 browser. That's up to you, of course, but it's what I'd do.

Best regards: dlanor

[jackielo]

Ok, I see what you mean now, as it might not work for them if they have no SYS-CONF folder with that font on their MC. I'll look into it.

However, I really think that everyone who uses homebrew programs for the PS2 should have a SYS-CONF folder, so perhaps it would be a good idea for you to include such a folder on your CD.

Then when you want to use that CD with the PS2 of a friend, who has no SYS-CONF, you can just start by copying that folder to his MC, thus giving him both your default LAUNCHELF.CNF and ELISA100.FNT, as well as the icon.sys and icon files needed by the PS2 browser. That's up to you, of course, but it's what I'd do.

Best regards: dlanor

Thanks. That's what I do now. Forget it. That's a tiny problem. Please focus on major function enhancement.

Jackie

[zabolyx]

In the future it might be something to look into... having Launch Elf look in MC0:/CONFIG-SYS then the dirctory it starts in... This would make installer CDs easier for users to use first time... altough they have to learn how to config Launch Elf just to use it the first time... not a bad thing though...

[dlanor]

----- snip ----- re: advice on copying "SYS-CONF/" from CD.

Apparently everyone else missed my mistake in that advice, so I'd better take this chance to correct it myself, before it's to late... Copying SYS-CONF/ from CD like that will work, except for one small detail. "icon.sys" will be stored as "ICON.SYS" on a PS2 CD, so that is the name it will have when copied to MC as well. This means it will NOT work right with the PS2 browser which demands that the name be "icon.sys", using only lowercase characters.

That sort of problem is one of the things we need a proper scripting language for, so that we can specify a name for the destination that differs from the name of the original file.
(eg: "copy cdfs:/SYS-CONF/ICON.SYS mc0:/SYS-CONF/icon.sys")

Thanks. That's what I do now. Forget it. That's a tiny problem.
Maybe, but I'll keep it in mind when making other changes.

Please focus on major function enhancement.
Always... ;)

Best regards: dlanor

[zabolyx]

Well the icon is not needed... only to make it show up in the PS2 browser.. So a user could add it later if needed.

edit.. before this gets pointed out...

So a user could add it later if needed. So a user could add it later if wanted...

[HypERSoniC]

----- snip ----- re: advice on copying "SYS-CONF/" from CD.

Apparently everyone else missed my mistake in that advice, so I'd better take this chance to correct it myself, before it's to late... Copying SYS-CONF/ from CD like that will work, except for one small detail. "icon.sys" will be stored as "ICON.SYS" on a PS2 CD, so that is the name it will have when copied to MC as well. This means it will NOT work right with the PS2 browser which demands that the name be "icon.sys", using only lowercase characters.

That sort of problem is one of the things we need a proper scripting language for, so that we can specify a name for the destination that differs from the name of the original file.
(eg: "copy cdfs:/SYS-CONF/ICON.SYS mc0:/SYS-CONF/icon.sys")

Maybe, but I'll keep it in mind when making other changes.

Always... ;)

Best regards: dlanor

not nessesarily. ps2dev driver is much better and supports joliet for filenames...

[laplace82]

EDIT: resolved! :D
------------------------------

hi, i would like to konw a thing...

there's a way to launch ulaunchELF from CD with the ulaunchELF configuration file?
i'm searching a way to configure che .CNF file of ulaunchelf to start the file manager only pressing a pad button (at the start of ulaunchELF) instead assign every time a button and only then start file manager pressing it.

[laplace82]

sorry but i have a question... in the "Startup Setting" there are 3 options:
- reset IOP
- Number of CNF
- Key Mapping

What are their functions?

[E P]

sorry but i have a question... in the "Startup Setting" there are 3 options:
- reset IOP
- Number of CNF
- Key Mapping

What are their functions?

reset IOP - Clears out the currently loaded modules so LaunchELF can load it's own modules when it starts. This results in a cleaner slate in other words. (Note: not perfect but it does the job for the independence exploit).

Number of CNF's - Sets the maximum number of config files you can select from. (Note: Use left and right to cycle through different config files and save the changes for each individual CNF file).

Key Mapping - Swaps X and O buttons so X is confirm and O is cancel. A lot of users wanted this including myself at one time but I'm used the regular way so I just leave it off.

[laplace82]

thaks a lot!
sorry for my awful english but i'm italian!!

another thing: the configuration file (if number of CNF is set to 1) is named "LAUNCHELF.CNF; if i want to use multiple CNF what name they must have?

[zabolyx]

The program will make them when you configure the app.... it will name them LAUNCHELFx.CNF where x is the number... no need to make up the configuration before you install Launch Elf...

[laplace82]

ok, thanks.
the numeration of LAUNCHELFx.CNF starts from 0 (0 omitted => LAUNCHELF.ELF) or from 1 (1 omitted => LAUNCHELF.ELF)??
anyway... the second LAUNCHELFx.ELF is LAUNCHELF1.ELF or LAUNCHELF2.ELF?

[E P]

ok, thanks.
the numeration of LAUNCHELFx.CNF starts from 0 (0 omitted => LAUNCHELF.ELF) or from 1 (1 omitted => LAUNCHELF.ELF)??
anyway... the second LAUNCHELFx.ELF is LAUNCHELF1.ELF or LAUNCHELF2.ELF?

Default config is the one that is first loaded is LAUNCHELF.CNF.
Then each extra config is LAUNCHELFx where x is 1 through what ever number of CNF's is set to -1.

So in other words, 1 (default) = LAUNCHELF.CNF, 2 = LAUNCHELF1.CNF, 3 = LAUNCHELF2.CNF, etc.