Future roadmap for the official PS2SDK –
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:
- 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.
- 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)
- 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:
- 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.
- 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?
- 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:
- 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).
- 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.
- 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:
- The old Sony standard had all EE RPC libraries to use 16-byte alignment instead of 64 (Different alignment structure sizes, obviously programmatically incompatible).
- 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.
Last edited by SP193; 03-20-2013 at 05:01 AM.
Unmodified SCPH-77006 with SM 3.6
SCPH-39006 with M-chip modchip, SCPH-10281 NA and refurb Seagate 80GB HDD
SCPH-10000 v1.00 with SCPH-10190 PCMCIA NA and SCPH-20400 HDD unit