PSPLINK
PSPLINK
Well it had to happen eventually, hope no-one kills me for using the PSPLINK name ;P For people who don't watch svn commits very closely I committed an alpha of psplink to subversion. As I am going away for abit so I thought I would get it out now, even if it isn't really finished.
If you didn't encounter ps2link then basically this is a tool to aid in development of applications. Its job is to setup a basic development environment, installing things like a tty and an exception handler so you don't have to. It requires an SIO cable to operate as it places a simple shell on the serial port which you can interact with using standard terminal software such as minicom or erm Hyperterminal. From the shell you can load standard pspsdk applications and when you are done you can just reset psplink and run another app straight after. This means you should never need to run your app in kernel mode again, or use some kernel mode cludges to install all the various useful debugging features which have appeared in pspsdk.
At the moment there is still alot of work to be done, there is no host driver for example, although there is less need for one as usb mass storage runs all the time. There is also currently no working gdb stub, it is in there but it doesn't currently work which is annoying.
Anyway people with a SIO cable built are welcome to check it out, call it rubbish, fix it etc. Have fun and read the README :P
If you didn't encounter ps2link then basically this is a tool to aid in development of applications. Its job is to setup a basic development environment, installing things like a tty and an exception handler so you don't have to. It requires an SIO cable to operate as it places a simple shell on the serial port which you can interact with using standard terminal software such as minicom or erm Hyperterminal. From the shell you can load standard pspsdk applications and when you are done you can just reset psplink and run another app straight after. This means you should never need to run your app in kernel mode again, or use some kernel mode cludges to install all the various useful debugging features which have appeared in pspsdk.
At the moment there is still alot of work to be done, there is no host driver for example, although there is less need for one as usb mass storage runs all the time. There is also currently no working gdb stub, it is in there but it doesn't currently work which is annoying.
Anyway people with a SIO cable built are welcome to check it out, call it rubbish, fix it etc. Have fun and read the README :P
Congrats Tyranid !
Good work, I'm hurry to get Tmator build the SIO cable... I'm slap him hard if needed !
Good work as usual !
Good work, I'm hurry to get Tmator build the SIO cable... I'm slap him hard if needed !
Good work as usual !
- TiTAN Art Division -
http://www.titandemo.org
http://www.titandemo.org
I finally got around to testing this. Nice work! I only had some minor issues for which I've committed fixes:
- accept ascii 127 as backspace
- pass argp in load_start_module, otherwise the first exec wouldn't get any argv[0] passed.
-
- Posts: 11
- Joined: Fri Sep 16, 2005 3:18 am
- Contact:
*bump*
Anyway alot has happened since I last posted about psplink, so thought it was about time to do something.
There have been many minor and major additions since october, the main one of interest to people is no doubt a wifi network shell. This works much like the SIO shell (but with a few caveats, like missing Kprintf output). Hopefully it should be sufficient for the time being. Other inclusions are such useful/pointless tools such as realtime memory display and poking, ability to generate screenshots, many many more commands and simple scripting support. Alas the inbuilt disasm which I was planning on putting in is not quite available yet, still that should come soon once the right people get around to finishing a new release of a certain tool :P
Anyway someone at least try and give this a play so I can get some feedback, I have no idea how many if any are using it at all :)
Oh and a binary release is up at http://ps2dev.org/psp/Tools/PSPLink_0.9a
RTFM before asking silly questions :)
Anyway alot has happened since I last posted about psplink, so thought it was about time to do something.
There have been many minor and major additions since october, the main one of interest to people is no doubt a wifi network shell. This works much like the SIO shell (but with a few caveats, like missing Kprintf output). Hopefully it should be sufficient for the time being. Other inclusions are such useful/pointless tools such as realtime memory display and poking, ability to generate screenshots, many many more commands and simple scripting support. Alas the inbuilt disasm which I was planning on putting in is not quite available yet, still that should come soon once the right people get around to finishing a new release of a certain tool :P
Anyway someone at least try and give this a play so I can get some feedback, I have no idea how many if any are using it at all :)
Oh and a binary release is up at http://ps2dev.org/psp/Tools/PSPLink_0.9a
RTFM before asking silly questions :)
- nullp01nter
- Posts: 26
- Joined: Wed Jan 04, 2006 7:40 am
- Location: Saxony/Germany
Hi TyRaNiD,
I wonder why this thread isn't full of enthusiastic and totally thrilled developers jumping on your tool. For me it's something which really decreases my turnaround times a lot (before it was always the procedure enabling usb, scrolling right, starting app, waiting for gameboot...). Now its just typing a shell command. Great! (Although it took me a while to find out how exactly to build an ELF which can be loaded with psplink - would be nice if you could give some hints in your readme file).
My only problem: I use mikmod (from svn.pspdev.org) to play some music in the background. When I compile the app as EBOOT, it loads and plays fine. Everytime I exec it through psplink, mikmod fails loading the music from relative paths (inside of the same folder as the app). If I specify a full path (e. g. ms0:/music.it), it will load. Can you maybe tell me the difference?
And, did I miss something or is the gdb support still, lets say, not perfect?
Keep it up!
Thoralt
I wonder why this thread isn't full of enthusiastic and totally thrilled developers jumping on your tool. For me it's something which really decreases my turnaround times a lot (before it was always the procedure enabling usb, scrolling right, starting app, waiting for gameboot...). Now its just typing a shell command. Great! (Although it took me a while to find out how exactly to build an ELF which can be loaded with psplink - would be nice if you could give some hints in your readme file).
My only problem: I use mikmod (from svn.pspdev.org) to play some music in the background. When I compile the app as EBOOT, it loads and plays fine. Everytime I exec it through psplink, mikmod fails loading the music from relative paths (inside of the same folder as the app). If I specify a full path (e. g. ms0:/music.it), it will load. Can you maybe tell me the difference?
And, did I miss something or is the gdb support still, lets say, not perfect?
Keep it up!
Thoralt
Well the lack of enthusiasm is probably in part down to the lack of people with SIO cables, either through lazyness or lack of solder skills. Hopefully with the new wifi shell (and nicer PC terminal app I just added) more people might get interested. It is at least nice to find someone who actually finds it useful :)
As far as I was aware there is nothing special you should need to do to your ELFs to get them to run, I don't think a packed EBOOT loads, I have never tested ;P but normal elfs/prxes which use the sdk with its accompanying crt0 should work, at least I have not seen any problems. I guess the only ones which could cause issues are ones which directly use sio, play with the kernel to any great degree or load modules which are already there. Is there a simple example of a program you can build which doesn't work so I can look at it, or at least a description of what _you_ have to do to make elfs work.
Not sure what your issue with relative paths are, relative paths are handled on a per-thread basis from what I understand, if you are using newlib and the default crt0 then it _should_ work. It is of course possible that it inherits the base directory from the one which was used to load it and as my thread does not set the current thread before running the module it might not work. I'll have a look at it.
Oh and yes gdb support is far from perfect, not 100% sure what causes the problems. I might move the gdb stub from SIO based to wifi based because then at least it doesn't get in the way of the basic shell or the kernel, it is something which has fallen by the way side as I am yet to really use psplink in anger so to speak, it needs testers and they seem thin on the ground :)
Hopefully i'll soon add at least a simple instruction level debugger in the coming days so you can at least do some redimentary debugging, even if it is not quite as nice as gdb (I can't believe I just said that :P)
As far as I was aware there is nothing special you should need to do to your ELFs to get them to run, I don't think a packed EBOOT loads, I have never tested ;P but normal elfs/prxes which use the sdk with its accompanying crt0 should work, at least I have not seen any problems. I guess the only ones which could cause issues are ones which directly use sio, play with the kernel to any great degree or load modules which are already there. Is there a simple example of a program you can build which doesn't work so I can look at it, or at least a description of what _you_ have to do to make elfs work.
Not sure what your issue with relative paths are, relative paths are handled on a per-thread basis from what I understand, if you are using newlib and the default crt0 then it _should_ work. It is of course possible that it inherits the base directory from the one which was used to load it and as my thread does not set the current thread before running the module it might not work. I'll have a look at it.
Oh and yes gdb support is far from perfect, not 100% sure what causes the problems. I might move the gdb stub from SIO based to wifi based because then at least it doesn't get in the way of the basic shell or the kernel, it is something which has fallen by the way side as I am yet to really use psplink in anger so to speak, it needs testers and they seem thin on the ground :)
Hopefully i'll soon add at least a simple instruction level debugger in the coming days so you can at least do some redimentary debugging, even if it is not quite as nice as gdb (I can't believe I just said that :P)
Any chance to support USB connection too?TyRaNiD wrote:Well the lack of enthusiasm is probably in part down to the lack of people with SIO cables, either through lazyness or lack of solder skills. Hopefully with the new wifi shell (and nicer PC terminal app I just added) more people might get interested.
- nullp01nter
- Posts: 26
- Joined: Wed Jan 04, 2006 7:40 am
- Location: Saxony/Germany
To answer your questions:
The other problem with the relative paths I still investigate. I also had such errors without psplink now, so its no "feature" of your tool :) but something more general.
I checked out your PC terminal app from svn. I found the idea of having a nice command history very good, but wasn't able to link the thing (I use a cygwin psp setup "out of the box", and yes, I installed readline5). Missing symbols are:
I also tried to compile it on a more or less clean linux system, but also got missing symbols (although the symbol names were different then, but I cannot list it here at the moment because the linux system is out of reach). Maybe you can give me some hint to compile the terminal.
[Edit] Just found your very explanative article "Building PRXes in PSPSDK", so the build questions are now clarified and therefore cut out. [/Edit]Is there a simple example of a program you can build which doesn't work so I can look at it, or at least a description of what _you_ have to do to make elfs work.
The other problem with the relative paths I still investigate. I also had such errors without psplink now, so its no "feature" of your tool :) but something more general.
I checked out your PC terminal app from svn. I found the idea of having a nice command history very good, but wasn't able to link the thing (I use a cygwin psp setup "out of the box", and yes, I installed readline5). Missing symbols are:
Code: Select all
gcc -Wall -g -lreadline.dll pcterm.c -o pcterm
/cygdrive/c/DOKUME~1/thofr/LOKALE~1/Temp/ccz3SuHo.o: In function `cli_handler':
/home/thofr/projects/svn.pspdev.org/psp/trunk/psplink/pcterm/pcterm.c:110: undefined reference to `_rl_line_buffer'
/home/thofr/projects/svn.pspdev.org/psp/trunk/psplink/pcterm/pcterm.c:110: undefined reference to `_add_history'
/home/thofr/projects/svn.pspdev.org/psp/trunk/psplink/pcterm/pcterm.c:111: undefined reference to `_rl_line_buffer'
/home/thofr/projects/svn.pspdev.org/psp/trunk/psplink/pcterm/pcterm.c:115: undefined reference to `_rl_line_buffer'
/home/thofr/projects/svn.pspdev.org/psp/trunk/psplink/pcterm/pcterm.c:123: undefined reference to `_rl_callback_handler_remove'
/home/thofr/projects/svn.pspdev.org/psp/trunk/psplink/pcterm/pcterm.c:124: undefined reference to `_rl_callback_handler_install'
/cygdrive/c/DOKUME~1/thofr/LOKALE~1/Temp/ccz3SuHo.o: In function `init_readline':
/home/thofr/projects/svn.pspdev.org/psp/trunk/psplink/pcterm/pcterm.c:134: undefined reference to `_rl_insert'
/home/thofr/projects/svn.pspdev.org/psp/trunk/psplink/pcterm/pcterm.c:134: undefined reference to `_rl_bind_key'
/home/thofr/projects/svn.pspdev.org/psp/trunk/psplink/pcterm/pcterm.c:135: undefined reference to `_rl_callback_handler_install'
/cygdrive/c/DOKUME~1/thofr/LOKALE~1/Temp/ccz3SuHo.o: In function `read_socket':
/home/thofr/projects/svn.pspdev.org/psp/trunk/psplink/pcterm/pcterm.c:275: undefined reference to `_rl_callback_handler_remove'
/home/thofr/projects/svn.pspdev.org/psp/trunk/psplink/pcterm/pcterm.c:276: undefined reference to `_rl_callback_handler_install'
/cygdrive/c/DOKUME~1/thofr/LOKALE~1/Temp/ccz3SuHo.o: In function `shell':
/home/thofr/projects/svn.pspdev.org/psp/trunk/psplink/pcterm/pcterm.c:346: undefined reference to `_rl_callback_read_char'
/home/thofr/projects/svn.pspdev.org/psp/trunk/psplink/pcterm/pcterm.c:393: undefined reference to `_rl_callback_handler_remove'
/cygdrive/c/DOKUME~1/thofr/LOKALE~1/Temp/ccz3SuHo.o: In function `sig_call':
/home/thofr/projects/svn.pspdev.org/psp/trunk/psplink/pcterm/pcterm.c:406: undefined reference to `_rl_callback_handler_remove'
collect2: ld returned 1 exit status
make: *** [pcterm] Error 1
Last edited by nullp01nter on Sat Jan 07, 2006 7:16 am, edited 1 time in total.
-
- Posts: 13
- Joined: Fri Jan 06, 2006 5:44 pm
That seems to be the general sentiment. I'd be willing to build some at cost for all the PSP devs. A little "thank you" from a person who uses all this wonderful homebrew software. Of course, donations would also be accepted.Chrighton wrote:I'd love to use this if I had a SIO cable. My soldering skills are fairly decent, but I can't be arsed to build one at the moment, much less find my iron hehe. I'd promptly buy one at this point to save the time and trouble, if only to validate my procrastination :)
The cost of these should be under $10, including shipping, especially if more than one person want them, to help pad shipping from other places (A few dollars to ship $0.50 capacitors is outrageous.).
PM me if interested. And thank you for all the wonderful homebrew, including this very nifty tool. Any idea how long before we *will* be able to toy with the kernel with this? Something about a serial port being opened up just screams "port linux" to me.
nullp01nter, try getting the latest makefile for pcterm, I have reworked it so that the libraries are after the object files in the link line. Not sure why it works for me and not for anyone else. In theory it should not have worked before :) It should be noted though that pcterm doesn't currently support serial ports, that is on my todo list (and even then may not work on a windows box even with cygwin :()
And as for a USB connection, when, eventually, the USB hardware is reversed it should be technically possible, until then sorry.
And as for a USB connection, when, eventually, the USB hardware is reversed it should be technically possible, until then sorry.
-
- Posts: 13
- Joined: Fri Jan 06, 2006 5:44 pm
If you're talking about the device which is inserted into the PSP with the pins on it, that's simple. Double sided PCB. Easy to cut and work into shape. One piece of that double sided copper board from RadioShack (the one used for eching) should be more than enough for several boards.jimparis wrote:I've been meaning to make a batch, but I've had no luck finding a source of the connector on the PSP side. Have you? Short of cannibalizing $10 remotes, of course. I don't have any experience with doing custom molding for things like that.DustinFraze wrote:I'd be willing to build some ...
I was hoping we could come up with something a little more stable (using the existing HPRM cable is quite nice, because you can freely move the PSP around without worrying about mangling the pins or having it fall out.) I guess that would have to do if we can't find anything else.DustinFraze wrote:that's simple. Double sided PCB.
-
- Posts: 13
- Joined: Fri Jan 06, 2006 5:44 pm
Using the current HPRM cable as a template, it should fit rather snugly (so long as you measure twice and cut once). So long as you're not tossing the PSP across the room, it should stay. I don't see the movement as much of an issue; you're tethered to the PC anyway.jimparis wrote:I was hoping we could come up with something a little more stable (using the existing HPRM cable is quite nice, because you can freely move the PSP around without worrying about mangling the pins or having it fall out.) I guess that would have to do if we can't find anything else.DustinFraze wrote:that's simple. Double sided PCB.
If it's a *terrible* concern, place a mini-phono jack on the PSP connection end of the cable you're making. The headphone jack has a pretty hard hold on the thing that gets plugged into it. As an added bonus, you wouldn't need to plug in head phones to run the serial port. I'll do it this way as well, if requested.
Well there are numerous advantages/disadvantages with each
SIO Advantages:
1) The guts are 100% kernel mode, runs at a higher priority and has less impact on user mode (e.g. memory usage)
2) Has Kprintf hooked up so any kernel error messages will be printed to your terminal
3) Is a direct terminal which allows certain things to be done such as having options to page through memory dumps etc.
4) Slightly more portable, only need the sio cable rather than having a wifi access point etc.
5) Arguably faster reset time.
SIO Disadvantages:
1) Command line editing is minimal, limited history facility which is lost when you reset.
2) Takes up the remote control port so if you need to use that for say a media app you cannot.
3) You have to have exclusive use of the serial port so it cannot be used for anything else.
4) You have to build the cable in the first place.
Wifi Advantages:
1) Easy to get setup, just go into a store and buy a 802.11b wireless access point
2) When combined with pcterm has a pretty reasonable command line interface, almost unlimited history, full command line editing
3) Remote port can be free for other uses.
Wifi Disadvantages:
1) Uses up user mode memory space
2) Runs at a lower priority than the sio shell, could encounter more apps which prevent the reader thread from running.
3) Uses considerably more power when in operation, needs to be ideally always powered from the mains.
4) Missing kprintf means in some cases you have to go and dig out the error code to determine what has gone wrong.
5) Slower reset time, even with the sio shell disabled.
6) As the wifi modules are loaded you applications would need to ensure it doesn't load them again and the network stack isn't reset. Means it is harder to use it to load any app you come across.
In an ideal world I would have both, in reality the sio shell would be my way to go but if you cannot easily build an sio cable then wifi is a reasonable substitute, it is still completely usable as a development application for your own stuff, perhaps less well suited to playing with other peoples code and binaries.
SIO Advantages:
1) The guts are 100% kernel mode, runs at a higher priority and has less impact on user mode (e.g. memory usage)
2) Has Kprintf hooked up so any kernel error messages will be printed to your terminal
3) Is a direct terminal which allows certain things to be done such as having options to page through memory dumps etc.
4) Slightly more portable, only need the sio cable rather than having a wifi access point etc.
5) Arguably faster reset time.
SIO Disadvantages:
1) Command line editing is minimal, limited history facility which is lost when you reset.
2) Takes up the remote control port so if you need to use that for say a media app you cannot.
3) You have to have exclusive use of the serial port so it cannot be used for anything else.
4) You have to build the cable in the first place.
Wifi Advantages:
1) Easy to get setup, just go into a store and buy a 802.11b wireless access point
2) When combined with pcterm has a pretty reasonable command line interface, almost unlimited history, full command line editing
3) Remote port can be free for other uses.
Wifi Disadvantages:
1) Uses up user mode memory space
2) Runs at a lower priority than the sio shell, could encounter more apps which prevent the reader thread from running.
3) Uses considerably more power when in operation, needs to be ideally always powered from the mains.
4) Missing kprintf means in some cases you have to go and dig out the error code to determine what has gone wrong.
5) Slower reset time, even with the sio shell disabled.
6) As the wifi modules are loaded you applications would need to ensure it doesn't load them again and the network stack isn't reset. Means it is harder to use it to load any app you come across.
In an ideal world I would have both, in reality the sio shell would be my way to go but if you cannot easily build an sio cable then wifi is a reasonable substitute, it is still completely usable as a development application for your own stuff, perhaps less well suited to playing with other peoples code and binaries.
The SIO is definitely my way. TyRaNiD, thank you for your time and effort. The PSPLINK is development tool I was waiting for!TyRaNiD wrote:In an ideal world I would have both, in reality the sio shell would be my way to go but if you cannot easily build an sio cable then wifi is a reasonable substitute, it is still completely usable as a development application for your own stuff, perhaps less well suited to playing with other peoples code and binaries.
-
- Site Admin
- Posts: 347
- Joined: Sat Jan 17, 2004 9:49 am
- Location: Melbourne, Australia
- Contact:
I just installed psplink last night to use over wireless lan. I had a problem which I mentioned on IRC that it wasn't bringing up the IP address,etc. I managed to get it working tonight. I *think* the issue was that I edited the psplink.ini in wordpad which gave it nice CRLF line endings. I *think* it may not have passed these correctly. What do you think?
David. aka Oobles.
www.livemedia.com.au/Blog
David. aka Oobles.
www.livemedia.com.au/Blog
-
- Site Admin
- Posts: 347
- Joined: Sat Jan 17, 2004 9:49 am
- Location: Melbourne, Australia
- Contact:
I've possibly found another bug or feature. :)
I've started PSPLINK then loaded up the LuaPlayer eboot I've been working on. After getting an exception I can still enter commands into PSPLINK, however, it seems that LuaPlayer redirected the stdout and stderr to the screen. Would be better if psplink could steal back the stdout/stderr back to the telnet session.
The other option I guess is to stop LuaPlayer from redirecting stdout and stderr? What do you think?
David. aka Oobles.
I've started PSPLINK then loaded up the LuaPlayer eboot I've been working on. After getting an exception I can still enter commands into PSPLINK, however, it seems that LuaPlayer redirected the stdout and stderr to the screen. Would be better if psplink could steal back the stdout/stderr back to the telnet session.
The other option I guess is to stop LuaPlayer from redirecting stdout and stderr? What do you think?
David. aka Oobles.
Well the redirection of stdout/stderr by another application is in part an issue with the kind of software you are developing. My original vision for psplink was really more so you could develop user mode applications only (although it would work with kernel mode stuff), the reason we don't use user mode only is due to all the various little tricks we need to support certain kernel features such as stdio which is a final "release" of a piece of software isn't really required. If an app needed something from kernel mode for a release version my idea was to provide a cut down bootstrap which just doesn't contain any of the shell code from psplink which will load things like netmodules before kicking off your application.
It certainly would be possible to redirect sceIoReopen once we have installed our stdout hooks to prevent lua stealing them from us, it is just a question of whether it is truely necessary. THe same would go for the exception handler which no doubt luaplayer steals as well :) If luaplayer was usermode only it wouldn't be able to install its own stdout hooks anyway. That said a command to reinit stdout wouldn't be a bad idea.
And GDB... thorn in my side if ever there was one :) Seems that the SIO one in psplink has some weird caching issue, if you set a breakpoint somewhere once gdb stops it cannot seem to resume, just keeps breakpointing, personally I haven't really looked at it at all since I merging the code in. My preference is to add a wifi based gdb as that really is a better solution and I prefer the sioshell at any rate. However I guess an SIO based solution would be okay for when you are only using the wifi shell. Ill try and start having a look at it.
It certainly would be possible to redirect sceIoReopen once we have installed our stdout hooks to prevent lua stealing them from us, it is just a question of whether it is truely necessary. THe same would go for the exception handler which no doubt luaplayer steals as well :) If luaplayer was usermode only it wouldn't be able to install its own stdout hooks anyway. That said a command to reinit stdout wouldn't be a bad idea.
And GDB... thorn in my side if ever there was one :) Seems that the SIO one in psplink has some weird caching issue, if you set a breakpoint somewhere once gdb stops it cannot seem to resume, just keeps breakpointing, personally I haven't really looked at it at all since I merging the code in. My preference is to add a wifi based gdb as that really is a better solution and I prefer the sioshell at any rate. However I guess an SIO based solution would be okay for when you are only using the wifi shell. Ill try and start having a look at it.
- nullp01nter
- Posts: 26
- Joined: Wed Jan 04, 2006 7:40 am
- Location: Saxony/Germany
Hi there,
I just wanted to refresh the topic a bit. Due to the discussion whether SIO or wifi I decided to get a SIO connector. Only problem: No serial port on my laptop. Also I didn't want to spend money for a USB2Serial converter, so I ended up constructing this here:
It's some kind of homebrew SIO2USB converter, inserted into the original PSP remote cable. A jumper allows for switching between normal remote operation or USB/serial connection. A small LED shows traffic going on and everything is not more than 18 mm x 48 mm in size. Nifty, isn't it?
If you want to know more about it, read on here: http://www.thoralt.de/projects/SIO2USB/SIO2USB.html
Cheers,
Thoralt
I just wanted to refresh the topic a bit. Due to the discussion whether SIO or wifi I decided to get a SIO connector. Only problem: No serial port on my laptop. Also I didn't want to spend money for a USB2Serial converter, so I ended up constructing this here:
It's some kind of homebrew SIO2USB converter, inserted into the original PSP remote cable. A jumper allows for switching between normal remote operation or USB/serial connection. A small LED shows traffic going on and everything is not more than 18 mm x 48 mm in size. Nifty, isn't it?
If you want to know more about it, read on here: http://www.thoralt.de/projects/SIO2USB/SIO2USB.html
Cheers,
Thoralt