Page 1 of 1
PS2SDK enhancement ?
Posted: Sat Jan 20, 2007 9:56 pm
by evilo
I was just curious,
What would you generally expect as future enhancements for the PS2SDK or related libraries ?
Regards,
evilo
Posted: Sun Jan 21, 2007 2:20 am
by jbit
My wishlist (not in any order):
(some of this I have started work on...)
- Fixed and optimized ps2ip/smap/host IOP driver
more debugging support
unify some libraries (libpad/libpadx/etc)
Real async. I/O
Some more open IRXs (xpadman, xsio2man, etc)
Some drivers/libraries brought more up to date and/or completed
Bluetooth support (using a USB dongle), mainly for possible wiimote and SIXAXIS fun.
IEEE1394 support (no particular reason for this)
And probably some more stuff which I'm sure I'll remember when it causes me problems :)
Not really sdk related, but I'd like to see a standard specification for homebrew loading. (What state you can expect the iop to be in etc)
And a resurrection of something similar to send0r (but probably with psp/ps3/etc support in it)
Posted: Mon Jan 22, 2007 3:41 am
by evilo
nice ones !
my wishlist would be :
- (x)padman IRX replacement (with functions like opendir, readdir,...)
- maintained cdvd replacement (Pixel mentioned a new one soon to be released a long long time ago..)
- openGL extension to gsKit
- SDLnet library in order to play SMW through a network :)
- time.c implementation
- better C++ support (iostream, etc...)
- more debugging support as well
I agree also on a more standard stuff for homebrew loading :)
what is send0r by the way ?? I never heard about it..
Posted: Mon Jan 22, 2007 4:33 pm
by jbit
http://send0r.com/index.jsp
It was an attempt at direct distribution to the PS2, so you just install and run one program on your PS2 and can then download demos/games/etc directly onto your hdd/memory card/mass storage.
It never really spawned much interest..
But I think if we make a nice little protocol (think RSS kinda thing) that's platform interpendant, we could create clients for the PSP, PS2 and PS3. And have a little web-based application for uploading and updating content. Would be quite nice.
However for this to work on the PS2, we'd need some standards. For example a standard way to tell the executable where it's resources are (obviously via. argc/argv), a standard set of IRXs the executable can expect to have loaded, a standard global config file (net setup, NTSC/PAL/VGA select, screen position, 4:3/16:9 select, etc, etc) and a few other things.
Posted: Tue Jan 23, 2007 3:26 am
by Henk
Sounds like an interesting project. I'd be willing to program the web application.
Posted: Tue Jan 23, 2007 9:36 am
by Herben
evilo:
The CDVD driver Pixel mentioned was likely "CDVDDRVR" that I generated from reversing CDVDMAN and splitting the ISO9660 stuff off into a seperate module. So I have CDVDDRVR.IRX and ISOFS.IRX. I've never released them because the code is ugly and several of the functions are untested(though should work). There's also the fact that a number of Sony's security features are included in CDVDMAN and I'd rather not have the wrath of Sony come down on me over that.
Other than that I'm down with releasing both ISOFS and CDVDDRVR. Would be cool if we could also have a JOLIETFS and perhaps CDDA/DVDVFS drivers too.
I don't understand what you mean about xpadman, afaik there's no file system support for pad!
Now for my own wish list:
- Combination of PS2/PSP toolchain scripts/patches so we can avoid the problems we're seeing where a bug is fixed in one but never fixed in the other.
- Doing away with the old IOP library management system and designing a way to resolve IRX dependencies and automatically include the necessary import stub information. I really hate having to make an entry for EVERY SINGLE IMPORT I make! I also think the irx_imports.h is almost pointless.
- A singular IOP module for managing system extension like that done by iomanX to extend the functionality of ioman. We have 3 different modules that I know of that have hacks just to get io device lists and I think some of them are still bugged. It makes sense that some l33t apps would want to hook, extend, or replace library functions and such. I think it would be good to have a single module which exports libraries to handle this. iopmgr was supposed to do this I guess but never made it far.
- Complete seperation of TTY/HOST from PS2LINK(seperate IRX loaded by PS2LINK)
- Complete seperation of exception handler stuff from PS2LINK, use a standard library instead and have PS2LINK register a handler.
I have plenty more but they get a bit more "out there". ;)
As far as the exception stuff in PS2LINK, I'm nearing completion of my own PS2 debug library(IOP and EE) which I'll use to do that myself. I also have some other modules reversed/partially reversed that I hope to release soonish though I doubt many of them will be of any interrest to most people.
Posted: Tue Jan 23, 2007 1:28 pm
by Oobles
On the topic of Send0r, about a year ago (maybe more) I did some work on this with RekLess. A number of parts have been written.
Send0rLib: A java based library to do all the server side tasks like updating a database, etc.
Send0rWeb: A java based web site to be the home page for Send0r.
Send0rAuthor: A java/struts based web site to allow an author to create packages.
Send0rClient: A PSP based client.
This is all in different states of disrepair. I was building it as another way to play around with my Argot/Colony communications code. I need pick a license for the code and open up the subversion repository. I'll try and look at doing this in the next week. Any sugestions on which license?
David. aka Oobles.
Posted: Tue Jan 23, 2007 3:00 pm
by jbit
Herben wrote:- Doing away with the old IOP library management system and designing a way to resolve IRX dependencies and automatically include the necessary import stub information. I really hate having to make an entry for EVERY SINGLE IMPORT I make! I also think the irx_imports.h is almost pointless.
I have done some work on this, basically it involves a pre-linker, an IRX function database and some fun in the IRX headers... It just automagically generates a .o file with the required stubs in based on info found in a special section (which is stripped later) and any unresolved symbols. I never got it working fully though.
Herben wrote:- Complete seperation of TTY/HOST from PS2LINK(seperate IRX loaded by PS2LINK)
- Complete seperation of exception handler stuff from PS2LINK, use a standard library instead and have PS2LINK register a handler.
Yes, plus ps2link probably wants a decent rewrite anyway.
Herben wrote:I have plenty more but they get a bit more "out there". ;)
Post them, some nutters might have already started work on them, or at least be interested. ;)
Herben wrote:I also have some other modules reversed/partially reversed that I hope to release soonish though I doubt many of them will be of any interrest to most people.
Which modules would these be? :P
Oobles wrote:Any sugestions on which license?
AFL2 like ps2sdk? or new BSD? Anything but GPL... :)
Posted: Tue Jan 23, 2007 5:03 pm
by evilo
Herben wrote:evilo:
I don't understand what you mean about xpadman, afaik there's no file system support for pad!
duh... sorry I was thinking about mcman ..... :)
Posted: Wed Jan 24, 2007 7:35 pm
by dlanor
I hope it's OK if I butt in on this conversation too.
Herben wrote:The CDVD driver Pixel mentioned was likely "CDVDDRVR" that I generated from reversing CDVDMAN and splitting the ISO9660 stuff off into a seperate module. So I have CDVDDRVR.IRX and ISOFS.IRX. I've never released them because the code is ugly and several of the functions are untested(though should work). There's also the fact that a number of Sony's security features are included in CDVDMAN and I'd rather not have the wrath of Sony come down on me over that.
The only safe way to insure against that would be some kind of 'clean room' approach. You could start by trying to reduce your work on CDVDDRVR into a set of algorithm-free specifications, as those Sony algorithms are covered by copyright (perhaps even patents). Then you take that, together with your newly designed API for interaction between CDVDDRVR and ISOFS (or other new similar modules), and hand it all over to some other programmer who will have to design brand new algorithms for a new incarnation of CDVDDRVR which will then be free of direct Sony influences from CDVDMAN. Then they'll have no legal beef with this new implementation. They'll probably dislike it anyway, on general principles, but they'll have no legal grounds for complaints.
You can still continue developing ISOFS and other related drivers yourself of course, as those will not be 'copied' from Sony code, and will simply depend on that new API which is also independent of Sony.
Other than that I'm down with releasing both ISOFS and CDVDDRVR. Would be cool if we could also have a JOLIETFS and perhaps CDDA/DVDVFS drivers too.
Yes, that would be terrific. EP and I have long wanted to switch to a new CDVD driver for uLaunchELF, and have planned to base that work on EEUGs sources, but it would be much better to have a generic solution for such needs, and not just another project-specific adaptation.
- Combination of PS2/PSP toolchain scripts/patches so we can avoid the problems we're seeing where a bug is fixed in one but never fixed in the other.
I second that. I'd hate to see the kind of situation where PS2Dev and PS2SDK become more or less forgotten in favour of PSPDev and PSPSDK. Even now it has reached the point where I sometimes see people posting PSP-specific replies to PS2-related questions, for which the PSP-specific solutions do not apply...
----- snip ----- re: Entirely new IOP library management system
I agree with you in principle, but I think it's a mighty tall order. There could be some complex compatibility issues for people needing to use modules of both that new kind and of the old kind in the same application. A new form of IOP reset may also be needed to deal with such mixed usage.
- Complete seperation of TTY/HOST from PS2LINK(seperate IRX loaded by PS2LINK)
For HOST this has been done by several applications already (eg: Altimit, uLaunchELF, SMS). So all that really needs to be done anew is to make an 'official' package, possibly including some EE-side support libs as well.
As far as the exception stuff in PS2LINK, I'm nearing completion of my own PS2 debug library(IOP and EE) which I'll use to do that myself. I also have some other modules reversed/partially reversed that I hope to release soonish though I doubt many of them will be of any interrest to most people.
Well, 'most people' are not programmers, so that's always to be expected for development releases. I know that many others besides myself look forward to your new modules. And that goes regardless of whether that stuff is directly applicable to our current projects or not.
Best regards: dlanor
Posted: Thu Jan 25, 2007 3:13 pm
by Herben
evilo wrote:duh... sorry I was thinking about mcman ..... :)
err, mc0: has dir function support already. both MCMAN and XMCMAN. have you tried this since you resolved your earlier issues? :)
Posted: Thu Jan 25, 2007 3:42 pm
by Herben
let's see, reversed modules to be released are:
loadcore(basically done)
threadman(partially done)
dmacman(done, simple)
sifman(done, fairly simple)
excepman(done)
cdvddrvr and isofs(cdvdman replacement)
perhaps others I forgot, have to look around my hdds...
I also wrote a USB link cable driver that's pretty elaborate, though incomplete(perhaps 98%, really just needs cleanup). It supports up to 4 USB cables at a time, each one has a seperate thread and heap independant of the other. You can even connect both ends of the same cable to the same PS2 and it will go through handshakes and everything. ;P
I'm just finishing up my EE and IOP debug library which includes exception/breakpoint API. In addition to that I've written EE and IOP SBUS and SIF2 libraries which provides a nice system for communication between EE and IOP. It has a system similar to SIFRPC and can be used for all sorts of stuff like IOP->EE->SIO TTY, IOP debugging, etc.
Now as to the CDVDDRVR thing, it's not really about algorithms and the like. Sony wasn't stupid enough to put their encryption algos in code, it's all in hardware. CDVDMAN has things for reading the disc keys, setting the encryption method(s) used when reading data from CD, etc.
Anyway, I'll probably release it regardless. I highly doubt PS3 utilizes the same stuff so Sony doesn't have much, if anything, to be worried about anymore. PS2 still has some life yet but not much.
Posted: Tue Apr 28, 2009 10:11 pm
by misfire
Herben wrote:I'm just finishing up my EE and IOP debug library which includes exception/breakpoint API. In addition to that I've written EE and IOP SBUS and SIF2 libraries which provides a nice system for communication between EE and IOP. It has a system similar to SIFRPC and can be used for all sorts of stuff like IOP->EE->SIO TTY, IOP debugging, etc.
Does anybody know if this was made public? I'm especially interested in the SBUS library.
Posted: Thu Apr 30, 2009 11:26 pm
by cosmito
I see so many cool things in this thread... It's a pity the scene has lost so many steam :S
I would be great if the projects even incompletes would be released so other could continue the work (which I somewhat doubt...)
Posted: Fri May 01, 2009 7:31 pm
by yoshi314
excuse me for possibly asking the stupid question, but is there a port of curl library for ps2?
if not, is there an equivalent replacement library?
i could really use this, for some simple homebrew experiments.
Posted: Thu May 14, 2009 5:17 am
by Mega Man
Can please someone remove parameter "-c" from IOP_CFLAGS in Makefile.iopglobal. When I include this file, I get always compile errors.
Posted: Thu May 14, 2009 5:29 am
by J.F.
Mega Man wrote:Can please someone remove parameter "-c" from IOP_CFLAGS in Makefile.iopglobal. When I include this file, I get always compile errors.
No. Without that option, it'll try to link the file after compiling. Linking is always done with LD in another step. It's clearly something else causing the error.
Posted: Thu May 14, 2009 5:38 am
by Mega Man
J.F. wrote:Mega Man wrote:Can please someone remove parameter "-c" from IOP_CFLAGS in Makefile.iopglobal. When I include this file, I get always compile errors.
No. Without that option, it'll try to link the file after compiling. Linking is always done with LD in another step. It's clearly something else causing the error.
It is linked using the following rule in Makefile.iopglobal:
Code: Select all
$(IOP_BIN) : $(IOP_OBJS)
$(IOP_CC) $(IOP_CFLAGS) -o $(IOP_BIN) $(IOP_OBJS) $(IOP_LDFLAGS) $(IOP_LIBS)
So it uses IOP_CFLAGS when linking.
Posted: Thu May 14, 2009 6:23 am
by J.F.
Mega Man wrote:J.F. wrote:Mega Man wrote:Can please someone remove parameter "-c" from IOP_CFLAGS in Makefile.iopglobal. When I include this file, I get always compile errors.
No. Without that option, it'll try to link the file after compiling. Linking is always done with LD in another step. It's clearly something else causing the error.
It is linked using the following rule in Makefile.iopglobal:
Code: Select all
$(IOP_BIN) : $(IOP_OBJS)
$(IOP_CC) $(IOP_CFLAGS) -o $(IOP_BIN) $(IOP_OBJS) $(IOP_LDFLAGS) $(IOP_LIBS)
So it uses IOP_CFLAGS when linking.
I see, yes, that would be a problem. If that's the link step, maybe the error is in including IOP_CFLAGS, not that IOPCFLAGS has -c in it. IOP_CFLAGS should only be used in the compile step.