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.
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.
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.
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.)
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.
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.
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.
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.
Neither is mine but wow 33 Mbytes in 63 seconds now that is fast. I had heard that host has less overhead.
How did you identify the 'elfload' case ?
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);
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. For the present I just 'pretend' that 'host:' means PS2Link, but with 'fakehost' launching that is untrue.
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.
Yeah I agree there will most likely be conflicts with the loading of the ps2ftpd.irx module so it could be kept separate.
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...
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.
The ps2ftpd sources are available, so it's just a matter of getting time for digging into it.
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. :(
Hmm, I just found something interesting in FileSystem.c of ps2ftpd:
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 !!!
// 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)) )
// scan filesystem devices
ppkDevices = DEVINFOARRAY(pkModule,dev_offset);
while( pContext->m_kFile.unit < num_devices )
int unit = pContext->m_kFile.unit;
if( !ppkDevices[unit] )
if( !(ppkDevices[unit]->type & IOP_DT_FS) )
pInfo->m_iSize = 0;
pInfo->m_eType = FT_DIRECTORY;
Why not? It can be done in perfect safety.
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.
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.
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.
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. :)
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