unofficial LaunchELF v4.42

[sincro]

I have made some test. Not need to patch ps2hdd.irx

I launch your compiled version of uLaunchelf via ps2link 1.30 whit iop reset off in option and HDD work oh HD COMBO

mmm why? i have try use ps2de9.irx, ps2smap.irx and iomanx.irx from ps2link into ulaunchelf but the hdd don't work. what makes PS2LINK that ULAUNCHELEF not ago?

Any idea or suggestion?

[Experiment1106]

Question: I can not use the Rename function at MC and USB is that right

[dlanor]

Yes, this is what I had been thinking about before. Using as you said generic functions that can work for multiple devices. It sure would lessen the bloat. Trying to change LaunchELF to use a generic stat function would require a lot of work.

Yes, it would, but it would be very worthwhile work, because once we make such a switch it will solve not only the immediate problems, but also ease future implementations. And that's not just for LaunchELF. The improved drivers needed for this can be used by other software too.

Writing one version after another, over and over, of what is basically the same functions but modified for each device, that is also hard work, and NOT really worthwhile. I say that because each time we do such work, it solves only the immediate problem. Next time we want to do something similar again we still have to do it all over.

LaunchELF's current implementation doesn't quite fit the mold.

True. Like all powerful system tools, it has some unusual needs.

I'm still don't follow all the ways of doing system/driver calls for stats unfortunately.

Well, neither can I. Still, as I see it we should be able to use fioGetstat + fioChstat, or fileXioGetStat + FileXioChStat, to both read and modify basic file attributes and file date_time fields. But like I said, the current drivers don't have this properly implemented.

The best one is the MC driver, not surprisingly, as we still use the IRX internal to the console, so it was designed by Sony. The bad side of this is that we can't modify it (well I can, but I won't !!!), as that would then be illegal to distribute. But the good side is that it tells us what Sony regards as normal for these functions, so we can add similar functionality to homebrew drivers.

Here are some current results from my testing:

fio_stat_t structure elements for MC, delivered by fioGetstat:

mode = 0x17 for file, 0x27 for normal folder, 0x2F for protected save folder
That protection bit did not exist for the files, who all had 0x17.
Note also that the 'preserved'/CLOSED bit is not present here, so that still requires device specific access methods.
mode = 0x1027 is returned for PS1 save folders on a PS2 MC, when copied to the PS2 by the official PS2 browser, but the file inside such a folder still has 'mode = 0x17'. I have seen no file on PS2 MC with different mode value.

mode = 0x1F is returned for all save files on a PS1 MC, but the differing bit does not have the same meaning there, as those saves are NOT protected.

attr = Zero, at all times tested. (Sad, but true.)
size = file size, but zero for folders

ctime = create time in 8-byte struct identical to substruct '_create' in mcTable
atime = similar struct, but zeroed.
mtime = similar struct, holding modification time.

Edit: On PS1 MC some of my files have valid ctime and mtime fields, while some just have zeroes. I believe this to be the result of different copying methods. My games don't seem to care, but since the PS1 never had a proper real-time clock, I believe that the zeroes are the original standard. But it's interesting to note that the PS1 file format apparently supports time fields anyway. Possibly the original PS1 plans did include a clock, though it was left out to cut production costs.

I have not yet tested fioChstat effects, but if these too are similarily implemented for MC, then we are all set for adding the same functionality to the other drivers.

Yeah no time but it has last accessed month, day, and year from what I remember from before. I got zeros with time too. USB devices don't support time, hh:mm:ss, for last accessed even under windows.

You may have misunderstood me. Each time when I say 'time' in this context, I actually mean a struct containing both date and time. For USB these structs were all completely zeroed in each fioGetstat call. Not just 'atime', and not just the 'time-of-day' fields, but all of them were entirely zeroed. The same also applies to HOST, CD, and HDD (using fileXioGetStat).

As for 'last access time', I have always been opposed to its implementation, since way back in time, when this abysmally bad idea first appeared. I never could understand how even half-way decent software engineers could even consider adding a set of directory write accesses for each file access. Remember that in a perfect implementation the driver needs to 'touch' the 'atime' field for each new read/write call, not just when the file is opened or closed. Think of the speed loss this will inevitably cause. (esp. when streaming...)
IMHO, the entire concept is insane.

So, putting it differently:
I do not exactly mourn the lack of 'atime' support in our drivers...

That's what I was thinking before. Ps2ftpd uses FileSystem_ReadDir which uses the dread command to read in data from a device then it can use getStat later to retrieve the info.

I just had a look at that stuff (never really studied it before).

At first look it seems a bit cryptic, like in:
"pContext->m_kFile.device->ops->getstat(" and so on, but it does seem to use a function pointer from a device specific function table, and surely we can do something similar. But it remains an open question what those functions will return if we use them...

Also, we have to remember that 'ps2ftpd' executes in IOP space, whereas the main LaunchELF code executes in EE space, so whatever we do, our methods will have to differ somewhat. Just calling those functions directly is not on.

The ftp stuff I worked on gave me quite a bit of insight on attributes. I'm still almost clueless when it comes to handling them in LaunchELF itself. I had wanted to put something together that would allow me to see then from within LaunchELF. As you're aware there isn't a real nice clean way to do that.

Yes, I know. I had the same need for my testing, so I made some changes to 'filer.c', to allow stat info to be displayed when using the submenu command "Get Size". The extra display only appears when using it for a single object (either marked or selected). The 'mode' and 'mtime' fields are shown on the same screen line as the size, but with ps2client or InLink you can see the entire fio_stat_t struct (or the matching portion of an iox_stat_t struct for HDD).

I'm attaching this modified 'filer.c' so you can play around with it too.

OK. I still think that mcPaste would still be take quite a lot of work though.

Of course it will.
When I said 'Immediate implementation' I simply meant that I am ready to start immediately. Only time can tell when it will be finished.

The only thing holding me back slightly now is that I'm feeling a strong urge to fix those drivers too... Giving them a minimal fioGetstat support, similar to MC, should not be all that hard. But of course, I have to experiment with fioChstat too.

That is the real bloat-killer for cases where an application modifies dates, and that's something LaunchELF needs for ALL cases of copying, since both 'ctime' and 'mtime' fields should be preserved when a file is copied without changes.
(I know some disagree about 'ctime', but that is how I see it.)

Best regards: dlanor

[dlanor]

I have made some test. Not need to patch ps2hdd.irx

I launch your compiled version of uLaunchelf via ps2link 1.30 whit iop reset off in option and HDD work oh HD COMBO

That is very odd. Good, but still odd.

Skipping IOP Reset means that any drivers loaded before LaunchELF will remain active in IOP memory when LaunchELF starts. Many programs would fail with a driver conflict then, trying to load new drivers anyway, but LaunchELF won't do that. I added code specifically to test for the presence of 'old' drivers, to avoid such conflicts. This means that LaunchELF will be using the 'older' driver in these cases, which hopefully will work fine.

But the big question here is WHICH 'old' driver it was that caused your HDD access to work right.

mmm why? i have try use ps2de9.irx, ps2smap.irx and iomanx.irx from ps2link into ulaunchelf but the hdd don't work. what makes PS2LINK that ULAUNCHELEF not ago?

PS2LINK has no HDD support, but networking and HDD access is closely related in both hardware (partly controlled by same chips) and software (both need ps2dev9.irx).

Any idea or suggestion?

I see two direct possibilities.

1: ps2dev9.irx used by PS2LINK might have some difference from the current one of PS2SDK (used by LaunchELF), which somehow affects HD COMBO compatibility. But you seem to have tried that already, with negative results.

2:You may have used some other ELF(s) before using PS2LINK to start LaunchELF. If so, then the IRX(s) used by such ELF(s) may remain in IOP memory as LaunchELF starts, and will then be used by LaunchELF (unless using IOP Reset).

The suspects here are of course the IRXs related to HDD access, which is primarily atad.irx. The precise name of that IRX can differ, both as used inside the ELF file, and for the file name, but it always contains some variant of the strings 'ATAD' or 'atad'. Inside the ELF this is usually visible somewhere near the ELF header. (Useful when looking for embedded ELFs with a hex editor.)

Whatever the case, you should isolate the IRX(s) responsible, to use instead of the PS2SDK IRX(s), for your special version of LaunchELF. Then it should work the same way without PS2LINK, and with IOP Reset active.

I have no way of testing these theories myself though...
I have neither any 'HD COMBO' nor the console type it's used for.
All I can do is to wish you the best of luck.

Best regards: dlanor

[dlanor]

Question: I can not use the Rename function at MC and USB is that right

Yes, that is correct. The low level drivers for those devices do not support the standard functions for renaming. They have the functions, but those are just dummies that do nothing, so we have chosen to show this to the user, by 'greying out' the 'Rename' command in the submenu, when browsing such a device.

Best regards: dlanor

[Experiment1106]

ok thx for your answer - and i must give you very respect for this great tool its my Nr.1

[sincro]

Whatever the case, you should isolate the IRX(s) responsible, to use instead of the PS2SDK IRX(s), for your special version of LaunchELF. Then it should work the same way without PS2LINK, and with IOP Reset active.

I have no way of testing these theories myself though...
I have neither any 'HD COMBO' nor the console type it's used for.
All I can do is to wish you the best of luck.

Best regards: dlanor

I hope, if i find corret way, my special version will include to official ulaunchefl as an option

anyway no other elf will boot befor ulaunchelf. i boot ps2link direct from dev. now i make moore test, I MUST TO FIND A SOLUTION

bye

[dlanor]

I hope, if i find corret way, my special version will include to official ulaunchefl as an option

Sure. If it's just an alternate IRX (or a few) then we just stuff these in the 'modules' folder, and make a new alternate makefile that refers to those modules instead of the usual ones.

Edit:
I'm not sure how best to deal with the binaries though, whether to just include all four (clearly named of course), or split it into two binary releases. One for old fat PS2s and another for new slim PStwos.

anyway no other elf will boot befor ulaunchelf. i boot ps2link direct from dev. now i make moore test, I MUST TO FIND A SOLUTION

I hope you find it too, so again: Good Luck!

Best regards: dlanor

[E P]

Well, neither can I. Still, as I see it we should be able to use fioGetstat + fioChstat, or fileXioGetStat + FileXioChStat, to both read and modify basic file attributes and file date_time fields. But like I said, the current drivers don't have this properly implemented.

Yeah, it couldn't understand why there isn't a method to change the stats. I was looking for such a metod back when I was testing ftp stuff. A method to modify attributes for mass or hdd doesn't exist. I only found internal methods that set the time attributes based off the system time. The drivers are not equipped.

In regards to your testing, I got those same results before with ps2ftpd. I fixed the issue with those protected save folders. I made the ps2ftp see 0x2F as a directory as before it use to show up as a file. As for the 'attr' I got zero before too. I have gotten the same results using the debug info within ps2ftpd.

Edit: On PS1 MC some of my files have valid ctime and mtime fields, while some just have zeroes. I believe this to be the result of different copying methods. My games don't seem to care, but since the PS1 never had a proper real-time clock, I believe that the zeroes are the original standard. But it's interesting to note that the PS1 file format apparently supports time fields anyway. Possibly the original PS1 plans did include a clock, though it was left out to cut production costs.

That's very interesting.

You may have misunderstood me. Each time when I say 'time' in this context, I actually mean a struct containing both date and time. For USB these structs were all completely zeroed in each fioGetstat call. Not just 'atime', and not just the 'time-of-day' fields, but all of them were entirely zeroed. The same also applies to HOST, CD, and HDD (using fileXioGetStat).

Yeah, I misunderstood you earlier.

I just had a look at that stuff (never really studied it before).

At first look it seems a bit cryptic, like in:
"pContext->m_kFile.device->ops->getstat(" and so on, but it does seem to use a function pointer from a device specific function table, and surely we can do something similar. But it remains an open question what those functions will return if we use them...

I have some debug code which should get you most of the values. Each time a directory is changed with an ftp client it dumps the info with printf's. It just has to be uncommented again. It can retrieve mc, hdd, and usb_mass attributes including time.

Also, we have to remember that 'ps2ftpd' executes in IOP space, whereas the main LaunchELF code executes in EE space, so whatever we do, our methods will have to differ somewhat. Just calling those functions directly is not on.

Yeah, that's what I was thinking about. IOP and EE are two different animals but if it can be done for one than surely it can be done for the other.

Yes, I know. I had the same need for my testing, so I made some changes to 'filer.c', to allow stat info to be displayed when using the submenu command "Get Size". The extra display only appears when using it for a single object (either marked or selected). The 'mode' and 'mtime' fields are shown on the same screen line as the size, but with ps2client or InLink you can see the entire fio_stat_t struct (or the matching portion of an iox_stat_t struct for HDD).

I'm attaching this modified 'filer.c' so you can play around with it too.

Thanks, I'll take a look as well.

That is the real bloat-killer for cases where an application modifies dates, and that's something LaunchELF needs for ALL cases of copying, since both 'ctime' and 'mtime' fields should be preserved when a file is copied without changes.
(I know some disagree about 'ctime', but that is how I see it.)

I'm OK with preserving ctime.

[E P]

I just want to acknowledge a few things:

1. EXECFTPs does not use ps2netfs. My earlier thought that ps2netfs could be the culprit showing multiple named hdd partions in the hdd/0 listing was flat out wrong. It has do with the hdd modules and since ps2netfs needs the hdd modules that is why it shows up there as well. My guess is that the older non 48-lba hdd driver works which EXECFTPs uses. Either that or SlicStik made changes to the hdd drivers but if that's true without those source changes we're lost.

2. I was right before about the X-port and how the attributes are handled. So scratch what I had said earlier about being wrong. I believe one of my earlier tests inadvertently changed an attribute on the directory thus making me jump to conclusions. Sorry.

3. X-port doesn't create consistant backup files. The backups files don't always seem to match each other over a period of time. Perhaps some other partial data from other saves also gets in the backup. So I can forget about using those backups for long term mc save integrity tests.

4. I tested out the new "FreeUsbd v.0.1.0" from ps2dev. It's pretty new but works quite well so maybe there's a chance of using it rather than Napalm's usbd. The only way to use it is to update to the very latest ps2sdk. I found out that updating to the latest sdk is fine, if one alreadly has the usb_mass driver built before hand. Hopefully someone will soon figure out a solution to that little problem.