PS2SDK - creating a whole development force ?

[pixel]

Hi there.

I created that new forum so we might try to discuss about how the ps2sdk should be handled, and where we are heading toward with it. Hope you don't mind, and hope people will get interested in joining more efforts into that work :)

So, there are several topics I'd like to talk about with all of you (and others assurely; if some ps2 homebrew developpers out there are not yet aware of the forum, spread the word! :)

First, well, maybe we should try to define "maintainers" about chunks of the ps2sdk. Most of you obviously noticed that I did lots of (yeah, small, I know ;) ) cvs commits to the ps2sdk lately, but I am really not the best one to be able to talk about the ps2sdk widely. I mean, for example, I can talk about the libc part, without too much problem, and I can eventually take the maintainship of that ee/libc directory. But, for example, I am quite unaware of other stuff here and there, so when people are reporting bugs on the pad part, I am strictly not able to judge "yeah, it's true, there's a bug here, let's fix" or "no, you misunderstood, please use it that way".

What I want to say is I can't handle that whole sdk all alone :) So we need dedicated people who would work on cleaning and (*gasp*) documenting (doxyfying) the sdk.


Then, we'd need to get some clues about "what to do now". For me, I'd take the path of "beeing free from newlib, while beeing the most compatible AND light", by improving our libc, by adding a libm, by having some light libstdc++, etc... But, as I just said, there are other things to get done here and there, which could be handled by some different people in parallel. Proper USB support ? Stronger sound layer ? Keyboard/mouse ? So, what do we do ? :)


Finally, I'd like that we define some "standards" about the SDK. For example, paths. Or environment variables. Which would lead to the question of getting a canonical Makefile, with "the right CFLAGS and LDFLAGS and environment variable", as well as, maybe, some more general paths for libraries, like gsKit, or others. I think libraries like gsKit shouldn't make their way "directly" inside the sdk. Rather should they become "optionnal", but binary package releases should then match a certain policy we would define here, so that users would always follow the same way of installing a binary package addon inside their SDK.


Well, there are too much things in that very topic, maybe I should split them inside subtopics inside that new SDK forum ;) Feel free like doing so though. That is, instead of replying to this topic, just create a new thread that would be a better starting point than any phrasing I could do :)

[Drakonite]

First, well, maybe we should try to define "maintainers" about chunks of the ps2sdk. Most of you obviously noticed that I did lots of (yeah, small, I know ;) ) cvs commits to the ps2sdk lately, but I am really not the best one to be able to talk about the ps2sdk widely. I mean, for example, I can talk about the libc part, without too much problem, and I can eventually take the maintainship of that ee/libc directory. But, for example, I am quite unaware of other stuff here and there, so when people are reporting bugs on the pad part, I am strictly not able to judge "yeah, it's true, there's a bug here, let's fix" or "no, you misunderstood, please use it that way".

What I want to say is I can't handle that whole sdk all alone :) So we need dedicated people who would work on cleaning and (*gasp*) documenting (doxyfying) the sdk.

To an extent there have already been maintainers of the various parts, or in some cases a couple of people who constitute a maintainer... And while I don't think we can force someone to keep things updated, I do agree that the SDK is getting to the point it would be nice for some people to stand up and take charge of the various parts if for no other reason than there to be a person to go to who always knows whats going on with that piece of the puzzle.
A year ago it seemed there were a lot of people who knew all the pieces, but we've grown too much or that :)

[Drakonite]

Then, we'd need to get some clues about "what to do now". For me, I'd take the path of "beeing free from newlib, while beeing the most compatible AND light", by improving our libc, by adding a libm, by having some light libstdc++, etc... But, as I just said, there are other things to get done here and there, which could be handled by some different people in parallel. Proper USB support ? Stronger sound layer ? Keyboard/mouse ? So, what do we do ? :)

Sure, we can name all sorts of things we need to get done, but since it's just people working in their spare time on what they want to do is kinda hard to set a list of goals isn't it? ;)

IMO a couple of the more important things would be to finish the USB driver in ps2sdk, a better sound layer, and a new padlib as the current one seems to be getting more and more hacked up. But the most important thing that no one really wants to do, is to write some significant documentation (or a tutorial) to make it easy to get started.

If someone wants to work on those, or the libc/libm situation, or anything else for that matter I say more power to them :)

[ooPo]

Make up a list of parts. Make up a wishlist. Then we can go from there.

[Drakonite]

Make up a list of parts. Make up a wishlist. Then we can go from there.

Before we start listing the parts of the sdk, would be nice for those that have all but claimed an area of it to speak up with what they have, it'd kinda help break it up into parts ;)

[ooPo]

Or, here's a list based upon directories in cvs:

EE: debug, kernel, libc, loader, rpc, sbv, startup
IOP: debug, dev9, fs, hdd, kernel, sbusintr, siftoo, sound, sound, system, tcpip, usb
OTHERS: samples, tools

So, now try to attach names to each part. Who contributed/etc... then ask if they want to be listed as an official maintainer of that part. A maintainer doesn't have to actually be actively working on it, just someone who has a general idea of how it works and what's needed.

Next, we can talk about what's missing and would be nice to add. We really should have a graphics library in there, say gskit... generally a SDK has everything you need to get started on a platform.

[Anonymous Coward]

I will take responsibility for the troll analyzer and compacting device!

[blackdroid]

I could take care of samples and tools, im working on doing some nice snapshot builds, and part of that I want some sort of regression test ( doing automated tests on the ps2 would be nice, and something that I feel like Id like to tinker with ), ive just started on that though so not much to be seen yet(tm).

[Lukasz]

I can document all kernel and SIF related functions in ps2sdk and code some samples which show how to use the most common kernel and SIF functions.

[Neovanglist]

After I get gsKit 0.2 out, my next priority before gsKit 0.3 is fixing the "Golden Combo". (PS2IP/PS2IPS/LWIP) Since I'm going to be digging around in here anyway, I'd be happy to maintain them. My only concern is that I will need to get clearance for this once I start for IOI. (I will be doing TCP/IP stack work for them as well, and don't want to step on any toes.)

[jum]

I would like to see a tidy, documented, working USB framework that will facilitate writing new USB drivers.

IMHO, a gfx lib and other stuff like a 3D vector/matrix lib should also be included, to avoid the situation where you have an external gfx lib version X which only works with ps2sdk version Y, and then when the ps2sdk version changes, it don't work anymore.

A "test suite" that tests most of the important ps2sdk functionality would make life easier when testing a new release of ps2sdk, and could also serve as examples. Frustration reduction.

I can contribute to creating sound/audio examples and docs.

- Jum

[Oobles]

As with last year, I'll be available to do stuff like write news posts, maintain the web site and generally have very little to do with coding. :)

Neov, If you need any help with ps2ip let me know. I haven't touched it in a long time but I'm sure there's some knowledge still left in my head about it. Also to let you know.. lwip 1.1.0 has recently been released. re-incorporating changes would be worth while. Also looking at ways of keeping changes to separate files as much as possible to reduce the upgrade pain of lwip.

And I agree with others.. a ps2sdk test suite, a more complete graphics library and examples, and better documentation on how to get started are all needed.

One possibility for getting cygwin setup is to maintain a list of packages on ps2dev.org which work directly with the cygwin setup.exe. I did this back in 2002 on ps2def.sf.net. Now ps2dev.org has better setup, it might be worth having another look at it.

[Lukasz]

I've created the cygwin setup file and I'm currently uploading it. It contains a ps2sdk build from 01.06.05 (yesterday), lastest ee, iop and dvp toolchain (11.30.04) and ps2client 2.0.0. It also does postinstall which sets the necessary env paths for the toolchains, ps2client and ps2sdk.

I'm currently uploading it, I will post some instructions once its done. Hopefully we can get some people to test it with a "clean" install of cygwin and see how that goes.

UPDATE
I've now posted instructions in this topic: http://forums.ps2dev.org/viewtopic.php?t=920

[ooPo]

So, where do we stand with this these days? I've seen pixel working hard on libc and he added a math lib, I've added standard dma/packet functions as well as a graph and 3d math lib. People have been bugfixing and adding plenty of other stuff that slips my mind at the moment (sorry!)... so where do we go from here?

I'd like to start a list of pieces in ps2sdk and assign maintainers to them. Being a maintainer doesn't mean you do all the work - it just means you control the general direction of that module and can answer questions people may have about it.

I'd also like to see a packaged up release happen in the near future if possible. Perhaps a package with the toolchain, ps2sdk, gsKit, ps2link, ps2client, maybe sdl, etc all up to date and ready to compile/install. We should probably aim for a regular release schedule, too.

Comments?

[pixel]

Luckily, I have no PSP to waste my time on... even though I have very very little time nowadays. Anyway, I prolly ask for libc maintainment. And about packages, I still have this daily-build script, but it needs work though. Do you think it would be worth putting my scripts in CVS somehow ? (and rewritting some so that they don't get "path-hardcoded" as much of them are right now :P) with more environment variables, and more logic in it.

[blackdroid]

yeah having buildscripts in CVS would be neat, I have crossdev toolchain setup on a box, so I can potentially compile FreeBSD, Linux and mingw binaries of pc side tools, having one set of buildtools that more than one person use would be nice.

I also vote for using scons instead of Makefile if you are using make at all, but thats just wish :)

[Drakonite]

I'd also like to see a packaged up release happen in the near future if possible. Perhaps a package with the toolchain, ps2sdk, gsKit, ps2link, ps2client, maybe sdl, etc all up to date and ready to compile/install. We should probably aim for a regular release schedule, too.

I agree. I think it's definitely time for a nice package release as many of them have had some major changes since the last one... And IIRC, didn't numerous things that were supposed to get released the first of the year end up not getting released?

[pixel]

I also vote for using scons instead of Makefile if you are using make at all, but thats just wish :)

I actually only wrote script shell for now... The yet-ugly-and-hacky scripts are there: http://nnoble.nerim.net/ps2dev/build-scripts/ entry point beeing "update.sh"...

[blackdroid]

looks nice enough to comit I think.