Hi folks,
I'm new to the group and while I've been busy compiling and testing the various tools and utils surrounding ps2link, I was wondering if anyone has yet to port code from the T10000 development kit?
Our project reboots the IOP immediately to load our kernel image and subsequent irx files. This, I assume, would logically kill ps2link and we're left dead. Now while I assume I can reload the mem card with the appropriate files and write a loader to do what the start of our application does before launching ps2link, does anyone know if there are other issues I'll need to deal with that might render this experiment futile?
A couple more questions in the event that this will work...
1. I've installed the ps2dev environment (appending "sf-" to all the utils so as not to clash with the sce tool chain so my Makefiles will be a bit different than the groups ;o), but will the standard sce tool chain still work ok? I assume yes if the above iop issue is taken care of.
2. What are you folks using as a debugging solution over ps2link (if any)?
3. Can ps2link/ps2client load files (other than the specified startup .elf)? I assume I can just use "host:" and the pathname? or no?
Great job all, I really like the effort here and if I can get something useful out of this experiment, I'll be more than happy to share my knowledge of the ps1 and ps2 as I've done/am doing development on both systems (including cop0,cop2 asm on ps1 and cop0,cop1,cop2,vu1 asm on ps2).
Cheers!
Chris
T10000 Port
2. The most used debugging solution has easily been printf'. IIRC there is a gdb stub but I've been told it's quite slow.
3. You can read/write any files you want to host:. There currently isn't a working Dread for host:, but otherwise it acts very much like any other filesystem.
I don't have access to a T10k so I don't really know about your other questions.
3. You can read/write any files you want to host:. There currently isn't a working Dread for host:, but otherwise it acts very much like any other filesystem.
I don't have access to a T10k so I don't really know about your other questions.
Shoot Pixels Not People!
Makeshift Development
Makeshift Development
Hi Chris,
You're correct, rebooting the IOP will kill ps2link. We currently don't have a workaround for this, and because we've done all previous development without Sony libraries we only rely on the modules shipped in the BIOS. This means that very few SCE libraries will work under ps2link. There is code out there that can detect IOP resets (which would allow you to reload ps2link's modules later) but this would be a pretty big task for someone to add to ps2link.
As far as your memcard loader idea, I don't think that would work as ps2link also resets the IOP at least once during loading. However this might be something that we could look into to see if it's possible to load ps2link without resetting the IOP.
As Drakonite says, host: is available and can be accessed pretty much the same way as host: in the SCE libs. sceOpen(), sceClose(), etc. become fioOpen(), fioClose().
You're correct, rebooting the IOP will kill ps2link. We currently don't have a workaround for this, and because we've done all previous development without Sony libraries we only rely on the modules shipped in the BIOS. This means that very few SCE libraries will work under ps2link. There is code out there that can detect IOP resets (which would allow you to reload ps2link's modules later) but this would be a pretty big task for someone to add to ps2link.
As far as your memcard loader idea, I don't think that would work as ps2link also resets the IOP at least once during loading. However this might be something that we could look into to see if it's possible to load ps2link without resetting the IOP.
As Drakonite says, host: is available and can be accessed pretty much the same way as host: in the SCE libs. sceOpen(), sceClose(), etc. become fioOpen(), fioClose().
Thanks for the speedy replies guys!
Well I've answered my first question, the sce tool chain works just fine. I rebuilt Tony Saveski's "turnip" demo using the sce tool chain and the libs from here and it runs fine. This will certainly help avoid inevitable conflicts that will arise from using the two chains in one environment.
That aside now, I've been looking at the source for ps2link and I think I'm going to take a shot at a version that works around my IOP rebooting. I'd love the source for EXPINST.ELF if it's available and someone could point me towards it to save a little time. If not, no worries.
Marcus, what do you know about the gdb stub Drakonite mentioned? Has anyone done any work towards a more practical debugging solution? (of course printf's are practical, but I'd like something that can get me to the hardware). I'm no stranger to cop0 or gdb so don't assume anything is too ambitious here... it would be nice to contribute something ;o)
Thanks again!
Chris
Well I've answered my first question, the sce tool chain works just fine. I rebuilt Tony Saveski's "turnip" demo using the sce tool chain and the libs from here and it runs fine. This will certainly help avoid inevitable conflicts that will arise from using the two chains in one environment.
That aside now, I've been looking at the source for ps2link and I think I'm going to take a shot at a version that works around my IOP rebooting. I'd love the source for EXPINST.ELF if it's available and someone could point me towards it to save a little time. If not, no worries.
Marcus, what do you know about the gdb stub Drakonite mentioned? Has anyone done any work towards a more practical debugging solution? (of course printf's are practical, but I'd like something that can get me to the hardware). I'm no stranger to cop0 or gdb so don't assume anything is too ambitious here... it would be nice to contribute something ;o)
Thanks again!
Chris
-
blackdroid
- Posts: 564
- Joined: Sat Jan 17, 2004 10:22 am
- Location: Sweden
- Contact:
no work has yet been done on the gdb stub ( that is really slow atm ), another issue is the license of it, an integration with ps2link ( which is they we have more or less decided on ) will require a rewrite and the use of a less restrictive license than the current stub, AFL preferred.
apart from printf, you have dumpmem, dumpregs commands in ps2link, I use those quite often when I debug vu code, or need to inspect dma registers. now these are not flawless though. they still need work to become robust and reliable. but its there.
apart from printf, you have dumpmem, dumpregs commands in ps2link, I use those quite often when I debug vu code, or need to inspect dma registers. now these are not flawless though. they still need work to become robust and reliable. but its there.
Kung VU