Future roadmap for the official PS2SDK

[SP193]

Since the official PS2DEV forums is dead and I could never join it anyway (As far as I remember, it rejected both my e-mail addresses when it was still up in 2009), I thought that I'll follow AKuHAK's advice and create a thread for the remaining developers here to discuss on the future roadmap of the PS2SDK.

Right now, I believe that improving the usability and updating it to 2013's standards is of utmost importance. The lack of documentation is one big problem, but that can be partially relieved if we make the PS2SDK less buggy and follow closer to their original functions (as defined by SCEI in their official manuals), since most of the system functions were based off Sony functions that work in the same way.

Please feel free to voice your thoughts and to add on!

From my end, I have the following suggestions to make to the existing PS2SDK:

1. If whatever MegaMan has been doing to Binutils means that support for the MIPS R5900 (The EE) and the IOP's IRX format has been officially accepted, we should update the PS2SDK toolchain to use the newest version of Binutils.
2. The same thing goes for GCC, but I didn't find any posts on the Sourceware/GCC forums that suggest that he has submitted a complete and working patch to the GCC steering committee. (Or that he even has one yet)
3. We should standardize the names of the functions available on the EE and IOP. For example: On the IOP, cdInit() is called sceCdInit() and the CDVDMAN header has the compiler preprocessor definitions named differently from their equivalents in libcdvd.h (For the EE). The same headache comes from the SIFDMA functions as well. Sony gave the EE and IOP equivalents of each functions the same name in order to make porting between the 2 processors easier. D:
4. We should fix/improve the DMA library on the EE and update gsKit, libgs and libgraph to use it.... since each of these graphics libraries are using their own implementation of getting DMA support on the EE working. While it works as it is now, I see that there is redundancy. From what I remember, this library would call FlushCache() before executing a DMA transfer. Like Sony wrote, FlushCache() will cause a performance hit.
5. The default linker script should be fixed. I realized that ExecPS2() will set the stack pointer to right below the EPC by default, and that WILL corrupt something if the stack is used before SetupThread() and SetupHeap() are invoked by the CRT. Plus Sony has always been ensuring that the EPC of their programs are always at the start of the program (Nicely at 0x00100000), but I don't know how to fix the default linker script to achieve that.
   Right now, the entry point will sometimes be at 0x00100008 with two NOPs at the front, which is fine. But sometimes some functions will be placed before the entry point. If the CRT was written in assembly (which it currently is) and is run at the start of the program, it's fine... but what if the CRT isn't used?
6. libcdvd on the EE needs to be fixed, badly. The alignment structure has been fixed by me, but I realized that rom0:CDVDFSV and rom0:XCDVDFSV were based on different specifications too. Like rom0:FILEIO and the FILEIO module that comes with games, rom0:XCDVDFSV is similar to the CDVDFSV module that comes with games, and the alignment structure was designed for 64-byte alignment instead of 16... since its EE client uses SifWriteBackDCache(). This problem applies to LIBMC and LIBPAD too. D:
7. About the point above, what should we do? By right, the programmer should know which IOP modules are being used since he/she will reset the IOP... so the libraries should each be designed to link up with their counterparts in ROM (So maybe a xlibcdvd should be created for XCDVDFSV and libcdvd shall be modified for CDVD and so on?). Currently, libpad is split into two (libxpad for XPADMAN and libpad for PADMAN), while libmc has got support for BOTH IOP modules in itself (Which I think is unncessary - you specify which IOP module you loaded during initialization and it never changes during runtime, at all).
8. Like the Sony EE RPC client libraries, there should be a version check on the IOP RPC server, and the end-user programmer should be notified if there is a version mismatch.
9. Why don't we have any official, pre-compiled binaries of the toolchain? D: GCC and Binutils have never been upgraded in years, and even the PSPSDK has such a thing.

EDIT: And oh yea, I need to commit NETMAN and the new SMAP driver. But none of them are in a form that is suitable for being committed yet.
(The paths in their Makefiles and some of their C files won't work right)

I have other stuff too, but I think that I'll continue with my list some other time. I think that these are the more pressing issues, since they affect my projects as well.

I have an updated libcdvd library that has got more functions added, but I'm stuck with deciding on how to solve the problem with CDVDFSV and XCDVDFSV following different standards (This applies to all IOP modules in general). This was what the old standard had:

1. The old Sony standard had all EE RPC libraries to use 16-byte alignment instead of 64 (Different alignment structure sizes, obviously programmatically incompatible).
2. Some modules used blocking RPC calls (Or were just designed to call their corresponding function on the IOP and blocks until the operation completes). FILEIO is a really great example here, as linking our FILEIO EE RPC with the newer Sony FILEIO modules will cause the IOP kernel to crash.

The main issue is actually with 1, as most libraries didn't have a change in their operational schematics (Only FILEIO was affected). Since the Protokernel consoles will only have the old Sony IOP modules and none of the X-modules, the programmer will be forced to at least use the old CDVDFSV since we don't have a homebrew replacement for the new CDVDFSV module yet.

Using the 64-byte alignment structure with the old CDVDFSV module will cause data corruption if alignment is done by the IOP.

Ah yes, I need to re-ignite the flame (and get other developers working on fixing the PS2SDK) in the PS2 scene before my mandatory army enlistment starts, which will happen in a few months. Once it does, I'll probably disappear from the PS2 development scene for a long, long time.

[Mega Man]

The VU0 support for the official binutils is still in progress. There is no R5900 support in the official GCC at the moment.

I already tried to fix some issues. I created a patch for PS2SDK. This was needed for building with GCC 4.3.

SourceForge.net Repository - [kernelloader] Contents of /linux/simple-toolchain/ps2sdk-mips64r5900el-ps2-elf.patch

This is not a clean patch, but there was basic stuff working with the GCC 4.3.

[SP193]

The VU0 support for the official binutils is still in progress. There is no R5900 support in the official GCC at the moment.

I already tried to fix some issues. I created a patch for PS2SDK. This was needed for building with GCC 4.3.

SourceForge.net Repository - [kernelloader] Contents of /linux/simple-toolchain/ps2sdk-mips64r5900el-ps2-elf.patch

This is not a clean patch, but there was basic stuff working with the GCC 4.3.

Thank you for sharing!

I took a look at the patch, and I have just one question: Why does it seem like the sizes of the data types has been changed? Was it changed because the old setup (unsigned int -> 32 bit, unsigned long -> 64-bit etc) didn't work well with GCC 4.3?

Do you have any plans to complete a patch for GCC, which is to be submitted to the GCC steering committee? The work that you have done with Binutils is marvelous.

[Mega Man]

My plan is to keep it compatible with the normal GCC, because this will be accepted. This is also compatible with existing code for Linux. For hardware access standardized types like uint32_t or uint64_t should be used (my patch is also not correct here).

The GCC will be updated in small steps. This means that the first version will only work in Linux when you know what you are doing. Only the latest step will fully work with ps2sdk as you know it today.

[SP193]

My plan is to keep it compatible with the normal GCC, because this will be accepted. This is also compatible with existing code for Linux. For hardware access standardized types like uint32_t or uint64_t should be used (my patch is also not correct here).

The GCC will be updated in small steps. This means that the first version will only work in Linux when you know what you are doing. Only the latest step will fully work with ps2sdk as you know it today.

Ah, alright.

I'll be looking forward to the day where full support for the MIPS R5900 is officially added into GCC.

[cosmito]

Good to read this post. Currently like in the previous last year I cannot devote time to this, but my interest is still on.
The issues you mention are really low level stuff and that is a department I am not knowledgeable.

Some stuff that still need to be fixed is the SDL libs for sound. I believe the problem lies in the thread managing done there.

I still want to get back into ps2 dev. I have some nice ports I want to bring and some stuff of my own, not to mention fixing the problems with those SDL libs.

[SP193]

Good to read this post. Currently like in the previous last year I cannot devote time to this, but my interest is still on.
The issues you mention are really low level stuff and that is a department I am not knowledgeable.

Some stuff that still need to be fixed is the SDL libs for sound. I believe the problem lies in the thread managing done there.

I still want to get back into ps2 dev. I have some nice ports I want to bring and some stuff of my own, not to mention fixing the problems with those SDL libs.

Hey, that's great.

Like doctorzyx has said time and again, this is just a hobby. So do whatever you want to the PS2SDK at your own time and target.

---

By the way, do you know what is the purpose of those "weak" functions in the CRT like _ps2sdk_libc_init_weak()? :S

I can't seem to find them declared anywhere else in the PS2SDK, and the Sony CRT doesn't have all that crap in it (In fact, their CRT is really short).

[cosmito]

Hey, that's great.
By the way, do you know what is the purpose of those "weak" functions in the CRT like _ps2sdk_libc_init_weak()? :S
I can't seem to find them declared anywhere else in the PS2SDK, and the Sony CRT doesn't have all that crap in it (In fact, their CRT is really short).

Sorry, I don't have a clue.

[doctorxyz]

I hope this link helps: forums.ps2dev.org :: View topic - Proper C++ support in ee-gcc?

[SP193]

Sorry, I don't have a clue.

Ah, nevermind. But thanks anyway.

I hope this link helps: forums.ps2dev.org :: View topic - Proper C++ support in ee-gcc?

Wow. Thank you!

But what about functions like _ps2sdk_libc_init_weak()? I now see why _init() and _fini() exist, but what about those other weak functions?