Any chances about implementing CDX support?

[bootsector]

Hi folks (LE developers, mainly),

Are there any chances to implement CDX support in LaunchElf, just like MCLoader? I have a unmodded PS2 (EXPLOIT method) and the only way I have to access CD data is from MCLoader using a CDX format CD.

It would be great to have that feature on LaunchElf.

Best regards,

bootsector

[E P]

Hi folks (LE developers, mainly),

Are there any chances to implement CDX support in LaunchElf, just like MCLoader? I have a unmodded PS2 (EXPLOIT method) and the only way I have to access CD data is from MCLoader using a CDX format CD.

It would be great to have that feature on LaunchElf.

No, reasons:
1. Drakonite wouldn't like it.
2. SMS has a more current implementation with SMSCDVD that us exploit can also use.

I wanted to get SMS's CDVD implementation to work with LaunchELF but it will require a rewrite to main.c, changes to some header files, and changes to LaunchELF's makefile. SMS's CDVD is not just a drop in replacement for CDVD lib. I tried evilo's CDVD implementation and had issues with LaunchELF's loader. The only viable option now is SMS's CDVD implementation but it won't likely be easy based on my earlier attempts.

[dlanor]

I wanted to get SMS's CDVD implementation to work with LaunchELF but it will require a rewrite to main.c, changes to some header files, and changes to LaunchELF's makefile.

True, and it won't stop there, as we'll also need to rewrite some of the sector reading routines to add some form of CRC checking. Running completely without checks might be acceptable for pure media playing purposes, but when it comes to generic data storage and program code, it's completely unacceptable.

This also means that we'll need to rewrite the PC tool to generate these ISO files, so as to add the CRC generation there too. And of course all of this should be done in cooperation with EEUG, so that the final implementation is used for both SMS and uLE (as well as future apps that need such features).

In order to not affect CPU loading for SMS, we could make the use of CRC checks optional when reading sectors, so that time critical routines may skip such checks for media playing. The CRC codes will still be present on the disc of course, which is still valuable for copying and verification purposes, but they will not affect the processing speed of SMS.

SMS's CDVD is not just a drop in replacement for CDVD lib. I tried evilo's CDVD implementation and had issues with LaunchELF's loader. The only viable option now is SMS's CDVD implementation but it won't likely be easy based on my earlier attempts.

Agreed, but this is something we really need to do at some stage, and this might be a good time to get started. After all, most other 'urgent' needs of uLE have been more or less satisfied, and the code itself has held stable for over two weeks now, without complaints other than those relating to terminology

The only unreleased changes I've made lately are the change of one of those terms (to "MISC/Configure"), plus a bugfix for the text editor to make it able to save files to HDD. Perhaps I should make a release with that stuff, just to 'clean the slate', so we can get started on a new CDVD implementation...
What do you think ?

Best regards: dlanor

[bootsector]

Perhaps I should make a release with that stuff, just to 'clean the slate', so we can get started on a new CDVD implementation...
What do you think ?

I know this quote is for E_P, but i THINK THAT'S GREAT!

Keep up the good job, guys!!

Regards,

bootsector

[E P]

True, and it won't stop there, as we'll also need to rewrite some of the sector reading routines to add some form of CRC checking. Running completely without checks might be acceptable for pure media playing purposes, but when it comes to generic data storage and program code, it's completely unacceptable.

Yeah, I remember you mentioning this before but I don't quite understand why the checks were removed. From what I have been able to gather some of the earlier cdvd code was transplanted then modified. I saw that in some of the source and header files. Although it was most likely done as a performance tweak. I agree though that if it were an optional function within the driver then LaunchELF could use it and SMS could pass on it.

This also means that we'll need to rewrite the PC tool to generate these ISO files, so as to add the CRC generation there too. And of course all of this should be done in cooperation with EEUG, so that the final implementation is used for both SMS and uLE (as well as future apps that need such features).

Yes, but of course we don't have the source to CDXplorer so we would just be better off talking to EEUG in regards to that. Of course, it would be great to allow both SMS and uLE to share the same implementation and try to make it the future standard.

In regards to making a new release to start work on a CDVD implementation, I'm all for it. A clean slate would be a good thing, as that CDVD stuff could get real ugly.

Oh and before I forget. SVN updated two other ps2sdk src files: libpad.c and libpadx.c.

I'll attach the updated versions here:

[dlanor]

Yeah, I remember you mentioning this before but I don't quite understand why the checks were removed.

As I understand it they didn't have to be removed because they never were present. CDDAFS is just an abused audio track format, and apparently audio tracks don't have any checks...

I agree though that if it were an optional function within the driver then LaunchELF could use it and SMS could pass on it.

Yes, that should be easy to implement, regardless of the details of the CRC method.

Yes, but of course we don't have the source to CDXplorer so we would just be better off talking to EEUG in regards to that.

Right, and I think he won't mind releasing the source either. I think the only reason he didn't already do it is because it's not for the PS2, so he felt it wouldn't be 'fitting' for the PS2Dev SVN.

Of course, it would be great to allow both SMS and uLE to share the same implementation and try to make it the future standard.

Exactly. Then everyone can use these methods, and we can forget about non-mod access problems to data files on CD/DVD. (Except for old programs of course.)

In regards to making a new release to start work on a CDVD implementation, I'm all for it. A clean slate would be a good thing, as that CDVD stuff could get real ugly.

I'll get on it, releasing v3.79 later today.

Oh and before I forget. SVN updated two other ps2sdk src files: libpad.c and libpadx.c.

I'll attach the updated versions here:

Thanks. I noticed the mention of these updates over at ps2dev.org, but I haven't gotten around to merging them with our sources. I'll do that now as well, so they too get into the v3.79 release.

Best regards: dlanor

[E P]

I'll get on it, releasing v3.79 later today.

Alright, I got the package and updated all my source files from the v3.79 source package.

Thanks. I noticed the mention of these updates over at ps2dev.org, but I haven't gotten around to merging them with our sources. I'll do that now as well, so they too get into the v3.79 release.

No problem those files were merged versions with the previous changes. SVN tries to update our prior modified files, but I usually check them again to make sure it did that correctly.