Here is an alternate version of smap. Its name is pktdrv.irx (iop source included, and supplied with pktdrv_rpc.h and pktdrv_rpc.c to insert in your ee source code in order to call it)
http://home.tele2.fr/~fr-51785/ps2_pktdrv.zip
Why a new version?
This one has no cross references with ps2ip. (smap is doing a strange call to ps2ip just to handle a silly small task...)
I could easily compile an old version of the wattcp tpc/ip stack on ee side with it and I made the source compatible with pc and xbox(openxdk) as well. I wanted fine control in order to merge background internet data download and smooth hardware accelerated graphics (with gsKit) at 60fps (i.e to have no blocking -waiting- mechanisms that supercede detection of new incoming frame and the need to update graphics).
It's probably appropriate for people who want to use their favorite tcp/ip stack and want to discard ps2ip (and have the choice to compile the stack on iop side or ee side).
The packet driver will enqueue up to 32 incoming packets until your main code decide to explore them (number defined as a constant).
Have fun! (and feel free to add it to your svn tree)
Independant packet driver source for ps2dev (based on smap)
Nice work.
You got me a little excited that you'd rewritten it from scratch (and thus removed the problematic GPL code from the driver), but it seems that's not the case.
A few of us (me included) have been talking about rewriting ps2ip on the IOP, which would include a nice async API. But this seems like a nice stop gap while we try to do that.
What kind of performance do you get out of this? ps2ip/etcs performance is pretty terrible.
How does this work with ps2link (have you tried it)? ps2link loads ps2smap, so I'd guess this would at least need to remove that IRX from the IOP, if not a complete reset. And after such things, the "host:" fs probably wouldn't work, and ps2link wouldn't be able to receive any commands.
You got me a little excited that you'd rewritten it from scratch (and thus removed the problematic GPL code from the driver), but it seems that's not the case.
A few of us (me included) have been talking about rewriting ps2ip on the IOP, which would include a nice async API. But this seems like a nice stop gap while we try to do that.
What kind of performance do you get out of this? ps2ip/etcs performance is pretty terrible.
How does this work with ps2link (have you tried it)? ps2link loads ps2smap, so I'd guess this would at least need to remove that IRX from the IOP, if not a complete reset. And after such things, the "host:" fs probably wouldn't work, and ps2link wouldn't be able to receive any commands.
Yes that's true, unless you rebuild all the listening task with the new stack, you no longer have your nice debug infos and remote control possibilities.
Here is what I've obtained :
I'm pretty satisfied with my HTTP and FTP tests. On big files, I obtain the same speed and reliability as other platforms. I certainly don't have the 20% failure I get when I try to upload programs in my ps2 with ps2client and ps2link. I can swear the existing smap code is not faulty, if lack of reliability occurs it's the fault of stack above.
I'm using the same initialization functions as SMS (this program is great, and the will of the author to let others study it to make programs fast is marvelous!). That means iop and ee are resetted and for debugging, I'm just using my own font system with gsKit in order to have all the infos I need. I've just copied/pasted the exception handler for ee side from ps2link and I manage to have the list of last functions my code entered in before the crash (I just make a call at beginning of my functions to store its name in a small fifo that will be read by exception handler). It's quite easy to debug even if I've to read that infos on ps2 screen instead of pc screen.
I've given up on any debug feature on iop side.
That's why I've put my stack on ee side. And I don't plan to develop anything on iop side. Existing irx are fine (beside the pktdriver I've, let's say, reassembled differently). When I write a program I compile its source on pc, xbox and ps2 at same time (just a few compilation directives to declare).
I hope to be able to publish some little multiplayer game as demo (with source included) allowing a ps2 player to connect with a friend playing on xbox for example, with binaries compiled from same source.
Currently, I'm trying to contribute to openxdk, because in matter of 3D hardware accelerated graphics this open dev kit is completely late compared to the nice gsKit. I have good hope to be able to compile pushbuffers sending code from same source on ps2 and xbox by end of this year.
Also, craig, owner of openxdk.org, is preparing an official stack release. It's possible he will ask to wattcp authors if my modified version can be published as it is (impossible because of the old license attached to it, at the moment which says a written permission is needed from author). If it happens you will be able to do many test because the source is immediately compilable for both consoles (if you use openxdk you declare ENABLE_XBOX, if you use ps2dev, declare nothing) and supplied with the HTTP (get) and the FTP (get, put, dir) test program. Don't worry if that happens, I will post myself a link to the files.
On the other hand, it's possible he will choose another stack. In that case, if I have time, I will see if I can try to make it compilable with ps2.
Wait & see (or just grab a stack and build it upon the independant packet driver)
Honestly, I don't see the interest of putting stack on iop side.
The enqueueing task and interrupts management related to network interface are of course to be on iop side, but beside that... A stack doesn't do much more than extracting data and reassemble it from received packets. It doesn't consume much time and can be easily stopped in case more important tasks have to be done (like updating graphics at VBL time)
For sure the way you married one stack to kit is more a constraint than an advantage.
If you want to try your luck with wattcp author or just do test for yourself I can let you grab the source though PM, but only you. License doesn't grant me (or you) the right to publish modified source of old wattcp without permission (more recent versions are GPL).
I have the feeling you dislike GPL... So you rather like AFL?
Can you explain difference?
Here is what I've obtained :
I'm pretty satisfied with my HTTP and FTP tests. On big files, I obtain the same speed and reliability as other platforms. I certainly don't have the 20% failure I get when I try to upload programs in my ps2 with ps2client and ps2link. I can swear the existing smap code is not faulty, if lack of reliability occurs it's the fault of stack above.
I'm using the same initialization functions as SMS (this program is great, and the will of the author to let others study it to make programs fast is marvelous!). That means iop and ee are resetted and for debugging, I'm just using my own font system with gsKit in order to have all the infos I need. I've just copied/pasted the exception handler for ee side from ps2link and I manage to have the list of last functions my code entered in before the crash (I just make a call at beginning of my functions to store its name in a small fifo that will be read by exception handler). It's quite easy to debug even if I've to read that infos on ps2 screen instead of pc screen.
I've given up on any debug feature on iop side.
That's why I've put my stack on ee side. And I don't plan to develop anything on iop side. Existing irx are fine (beside the pktdriver I've, let's say, reassembled differently). When I write a program I compile its source on pc, xbox and ps2 at same time (just a few compilation directives to declare).
I hope to be able to publish some little multiplayer game as demo (with source included) allowing a ps2 player to connect with a friend playing on xbox for example, with binaries compiled from same source.
Currently, I'm trying to contribute to openxdk, because in matter of 3D hardware accelerated graphics this open dev kit is completely late compared to the nice gsKit. I have good hope to be able to compile pushbuffers sending code from same source on ps2 and xbox by end of this year.
Also, craig, owner of openxdk.org, is preparing an official stack release. It's possible he will ask to wattcp authors if my modified version can be published as it is (impossible because of the old license attached to it, at the moment which says a written permission is needed from author). If it happens you will be able to do many test because the source is immediately compilable for both consoles (if you use openxdk you declare ENABLE_XBOX, if you use ps2dev, declare nothing) and supplied with the HTTP (get) and the FTP (get, put, dir) test program. Don't worry if that happens, I will post myself a link to the files.
On the other hand, it's possible he will choose another stack. In that case, if I have time, I will see if I can try to make it compilable with ps2.
Wait & see (or just grab a stack and build it upon the independant packet driver)
Honestly, I don't see the interest of putting stack on iop side.
The enqueueing task and interrupts management related to network interface are of course to be on iop side, but beside that... A stack doesn't do much more than extracting data and reassemble it from received packets. It doesn't consume much time and can be easily stopped in case more important tasks have to be done (like updating graphics at VBL time)
For sure the way you married one stack to kit is more a constraint than an advantage.
If you want to try your luck with wattcp author or just do test for yourself I can let you grab the source though PM, but only you. License doesn't grant me (or you) the right to publish modified source of old wattcp without permission (more recent versions are GPL).
I have the feeling you dislike GPL... So you rather like AFL?
Can you explain difference?
http://forums.ps2dev.org/viewtopic.php?t=185ps2devman wrote:[...] I have the feeling you dislike GPL... So you rather like AFL?
Can you explain difference?
GPL part removal
Ok, I see...
smap part is really, really small...
It won't be hard to rewrite.
If I'm to publish something big, I will try to do it. Wait & See.
smap part is really, really small...
It won't be hard to rewrite.
If I'm to publish something big, I will try to do it. Wait & See.
Last edited by ps2devman on Tue Oct 10, 2006 4:57 pm, edited 1 time in total.
In your case, it doesn't matter what processor the stack is running on.ps2devman wrote:Honestly, I don't see the interest of putting stack on iop side.
But there are several applications where you would want the stack on the IOP:
* If you use a network filesystem and want to use it via normal ioman commands.
* If you want any IOP module to do anything on the network (I have a debug monitor that runs on the IOP, for example).
* Doing network processing (TCP/IP + protocol) on the IOP does remove a little load from the EE, and if you're trying to squeeze the EE for all it's got, it's worth it IMHO.
But if you're not doing any of these things, running the stack on the EE is fine, and you might get more throughput too. You could even do what PS2Linux does and run the SMAP driver on the EE, which might simplify your setup a bit. (You need an interrupt and DMA router running on the IOP, but that's it)
Anyway, it'd be nice to have it in the ps2dev.org SVN repository, though I don't think it could be in ps2sdk due to the GPL code. (Same reason why ps2eth isn't in ps2sdk).
Test yourself performance
I may not have the best environment to be able to compare performances, actually.
I didn't know ps2ip was so badly rated.
My goal is to be able to produce code for many platforms from one single source, so a very small source like wattcp 16bits v1.2 (gotten from msdos web browser bobcat source), compiled on ee side is perfect for me (you just have to switch between packet drivers).
Here is the binary of the demo. It requests a dynamic IP address from any available dhcp server (a modem, or windows xp itself configured as ICS, see readme.txt file for details), then it reads first quote of xbox-scene.com home page through HTTP protocol (downloads 60Kb).
http://home.tele2.fr/~fr-51785/ps2_watt ... t_demo.zip (1Mb, zipped 328Kb)
I'm currently trying to do the xbox version by trying to know more about xbox gpu (need to do something like gsKit in openxdk).
I didn't know ps2ip was so badly rated.
My goal is to be able to produce code for many platforms from one single source, so a very small source like wattcp 16bits v1.2 (gotten from msdos web browser bobcat source), compiled on ee side is perfect for me (you just have to switch between packet drivers).
Here is the binary of the demo. It requests a dynamic IP address from any available dhcp server (a modem, or windows xp itself configured as ICS, see readme.txt file for details), then it reads first quote of xbox-scene.com home page through HTTP protocol (downloads 60Kb).
http://home.tele2.fr/~fr-51785/ps2_watt ... t_demo.zip (1Mb, zipped 328Kb)
I'm currently trying to do the xbox version by trying to know more about xbox gpu (need to do something like gsKit in openxdk).
Under AFL now!
Ok, it took me a few days, but now you have no more excuse for being lazzy...
I removed the smap code and replaced it with a very naked and short code that quite does the same effect (there aren't hundred ways of putting right value in right register at right time...)
Wattcp demo binary has been updated (new AFL packet driver is inside it now) :
http://home.tele2.fr/~fr-51785/ps2_watt ... t_demo.zip
Source of new packet driver source (under AFL license) :
http://home.tele2.fr/~fr-51785/ps2_afl_pktdrv.zip
changes :
- smap code removed
- new naked and very short driver code added
- new couple of file in order to immediately encapsulate irx (made with bin2c)
- smallest sample program source detect_ping.c added (detects pings)
- AFL license added
- added a note in readme.txt about how asynchronous receiving and sending are done
Happy now?
I removed the smap code and replaced it with a very naked and short code that quite does the same effect (there aren't hundred ways of putting right value in right register at right time...)
Wattcp demo binary has been updated (new AFL packet driver is inside it now) :
http://home.tele2.fr/~fr-51785/ps2_watt ... t_demo.zip
Source of new packet driver source (under AFL license) :
http://home.tele2.fr/~fr-51785/ps2_afl_pktdrv.zip
changes :
- smap code removed
- new naked and very short driver code added
- new couple of file in order to immediately encapsulate irx (made with bin2c)
- smallest sample program source detect_ping.c added (detects pings)
- AFL license added
- added a note in readme.txt about how asynchronous receiving and sending are done
Happy now?
Yep I keep links alive. Don't worry. Still unused I think.
Be aware the ps2 network adapter is a bit annoying because it has only 4Kb of internal buffer (well I can be wrong since I worked on it long time ago now). That means you can enqueue for a total of 4kb packets but after that some part of your code has to wait before enqueuing more.
Depending on the mechanism you use to handle this part, you may end up with slow stuff. I remade a tcp/ip stack on EE side and didn't feel too much slow down. Can't tell for stack inside ps2sdk, lwip, I don't use it.
Be aware the ps2 network adapter is a bit annoying because it has only 4Kb of internal buffer (well I can be wrong since I worked on it long time ago now). That means you can enqueue for a total of 4kb packets but after that some part of your code has to wait before enqueuing more.
Depending on the mechanism you use to handle this part, you may end up with slow stuff. I remade a tcp/ip stack on EE side and didn't feel too much slow down. Can't tell for stack inside ps2sdk, lwip, I don't use it.