forums.ps2dev.org

[Herben]

I'm in the process of adding a number of my changes to the ps2dev SVN. These are things that I've done over the last few years that I'm finally releasing. If I end up breaking something as a result, drop me a line and I'll fix it. ;)

[Herben]

So far I've added:
- Another EE debug library. Yes, we already have at least one of those in SVN.
- An IOP debug library.
- A SBUS library for both EE and IOP.
- An IOP SBUS debug library(uses IOP debug library and IOP sbus library to communicate with EE in order to debug IOP). This also contains a "TTY" file system and Kprintf which send output to EE via SBUS.

I have yet to add:
- An EE SBUS debug library. This is the EE side of the "IOP SBUS debug library".
- Changes I've made to ps2link which makes it use the new EE/IOP debug libraries.
- ??? I'll have to see what else I can dig out of my archives..

[cosmito]

A IOP debug library would be very handy, indeed. Thanks.

[ragnarok2040]

I'm not sure if you're done updating, but the iop_sbusdbg library isn't compiling.

kprintf_handler_func_t is undefined. It's on line 187 of sbus_tty.c.

The Makefile also uses PS2SDK instead of PS2SDKSRC and was missing some include directories when the variables were switched.

I changed it to this to fix the file not found errors.

[cosmito]

[misfire]

Yes, you actually broke the SDK. :)

Here's what I get when compiling r1642:

[ragnarok2040]

I fixed the definition of the kprintf_handler_func_t by typedefining it to a char pointer, but then ran into the problem of I_iop_dbg_get_reg_frames not being defined in iopdebug. There's also another undefined type named IOP_RegFrame. I decided to remove iop_sbusdbg from the SUBDIRS variable in the toplevel Makefile. After that, ps2sdk compiled fine until common/sbus, where PS2SDK was used again. I corrected the Makefile by replacing PS2SDK with PS2SDKSRC and adding the missing include directories. And, after that, it compiled fine.

[protomank]

Strangely I'm getting the iop_sbusdbg, even checking source from SVN.
Was the commit reverted?

[ragnarok2040]

No fixes have been committed yet. I'm waiting to see if Herben has the corrections needed for iop_sbusdbg to compile, :D. Besides, I don't have commit access :/.

[protomank]

[ooPo]

If you want access, send a message to Oobles asking for it. Point out which thread has the fixes you want to add so he'll know you know what you're doing. :)

[protomank]

Well, I do not need access, maybe ragnarok does :)

Anyway, I'll test those fixes from him tomorrow, and if it does work, is it ok for me to post them in the "Patch Submissions"?

[misfire]

I don't really understand why people commit patches to the SDK without actually testing if it breaks anything.

[ragnarok2040]

I've tried for a couple years now, to no avail. I've just given up by now.

I've got some more information on that error.

I've found the definition for IOP_RegFrame in ps2_debug.h in the 'common' folder.

It looks like the only thing that isn't implemented is:
iop_dbg_get_reg_frames(&_iop_ex_def_frame, &_iop_ex_dbg_frame);
in iopdebug.

Looking at the code, it looks like it's some sort of function to copy the register frame. The iopdebug module seems to have functions related to doing that, and it looks like it was starting to be implemented, but is incomplete.

misfire, they probably do test, but there's a lot of pitfalls that can occur.
E.g. 'svn diff' patches don't neccessarily work out of the box. Files that are moved/deleted need to be handled directly using svn commands, prior to patching.
Reverting changes to a local repository doesn't revert all local changes, related to the problem above this one, so you can create a diff that works locally on a reverted repository but doesn't work on a freshly checked out repository...

[jimparis]

[ragnarok2040]

I'll do that, then, :D. That would simplify things for both of us, since I have quite a few changes to ps2sdk coming up... quite a few :D.

[misfire]

You could also use Mercurial to commit locally and create patches: https://bitbucket.org/misfire/ps2sdk/

[Herben]

sorry guys, tried to avoid breaking things where possible.

To answer your question misfire, I've been working on stuff privately(along with the public stuff I've done) for many years now and promising to release various things for most of that time. Some of these things weren't released because they were incomplete or required changes to PS2SDK to make them work. And some things haven't been touched for years so I'm simply not sure what I had to do to get them to work. I *do* try to test things as well as possible before I commit. Unfortunately the time I have for ps2dev is rather limited these days so I've been taking the position of simply releasing what I can when I can in order to make good on some old promises, and hopefully these things will help keep ps2dev alive for a while.

rag: Thanks for the feedback. I forgot to commit my changes to iop/kernel/include/sysmem.h which defines that type. Fixed now. I've also changed the Makefile to the one supplied. I really need to redo the makefiles for many of my projects.. This one in particular wasn't intended to be part of PS2SDK originally which is why it referenced the "release" PS2SDK. Many thanks. :)

regarding "iopdebug", I don't know for sure what state it was in when commited. All these things are part of a much bigger project which I'm splitting up into individual modules and I'm still working out what belongs where. Anyway, I've committed some changes to "iopdebug" which compiles fine for me so if you have problems, let me know and I'll fix it.

That should be the end of me breaking things for the time being. Currently my PS2-time is focused on my pslink project. I'm just about to post a thread on this, check it out!

Let me now if you guys have any other problems with my commits. I know that the sbus stuff isn't that useful without the EE side or some kind of example, promise to get that out soonish.

[ragnarok2040]

Thanks :D. I have a couple more fixes, and it should all be set.

The iop_sbusdbg Makefile isn't formatted right. The forum replaces tab characters with spaces, three spaces from what I saw, so it probably got mangled from that.

The common/sbus Makefile also had that PS2SDK/PS2SDKSRC problem. I also fixed up the header paths.

After that, it all compiled fine :D.

I made a svn diff patch that fixes both issues: http://pastebin.com/m40daf98f
Copying and pasting the copy below the formatted version works fine. The formatted version converted the tabs into spaces, heh.

A note for those reading this wanting to submit diffs to pastebin:
I had to double the first two @@'s in @@ 0,0 @@ lines to @@@@ 0,0 @@, since pastebin uses @@ for highlighting. After it's posted, the two extra @@'s get eaten and you're left with the original patch. Empty newlines at the bottom get eaten as well, but it didn't seem to matter for my patch.

[Herben]

Submitted. Thanks again. :D

[Herben]

Just a quick note: I've cleaned up the makefiles/directories for "sbus" and "iop_sbusdbg" to bring them more in line with the rest of PS2SDK.

[Herben]

I've also checked in "lwip 1.3.1" and a fork of "tcpip" which uses it. I haven't had a chance to actually test it out though so if anyone can, that'd be cool. :)

[protomank]

Nice. I'll try to compila the toolkit from zero to see if all problems were fixed, thanks.

[protomank]

Works like a charm.
Just 10 minutes and ps2client is installed as all the SDK.

Thank you, now developing for PS2 will be MUCH easier for a lot of people, me inclued ;)

[yoshi314]

oh, i liked it broken - the thrill of hacking it into workable state ;-)

ok, it also works for me.

[dlanor]

I can confirm that the fixes for rev 1660 again allow the current PS2SDK to be used for the USBLoader project, except that three references to the GetSyscall function had to be edited to use the new name GetSyscallHandler instead.

I agree with the logic behind that rename (considering the other 'Handler' functions added), but it is changes like this that mess up the backwards compatibility to both current and older projects...

Best regards: dlanor

[Herben]

Thanks for the confirmations guys.

dlanor: Perhaps an "inline" function with the old name that just calls the new GetSyscallHandler is in order. Personally I think it makes more sense to simply update the projects in question.

[dlanor]

[protomank]

My take: place the old functions on a lib that can be linked to (and sure, document it for newbies in ps2 development) to maintain compatibility with old programs. This lib functions can even call the new ones if they are compatible.

New project will not use this lib, people working with old code can convert it with no rush and much more easily, because you can point in the compatibiliiy lib what is the new funcion, and how it differs from the original..

Just my 2 cents :)

[misfire]

Less complicated: do not touch syscall function names (or directly related functions), especially when they've been around for years.