forums.ps2dev.org

You obviously don't look very hard now do you...

No because the type of thread (user vs. kernel) is stored in the thread's control UID block, k1 was the early mechanism for determining how the function was called to allow single functions to do different things depending on how they are called (e.g. sceIoRead will error if trying to read into kern...

Eh?

Well yah with 5 I suppose it doesn't matter when you do it, I just cloned what other stuff did. But the maual building of the structures is for alignment reasons. It isn't totally logical but for what Sony needed to do it does the job, plus it is internal APIs so they probably couldn't care less abo...

1. Because you have to.
2. Yes
3. Because how else would you specify the PID?
4. There isn't one
5. Because you have to for alignment reasons.

The real problem is you need to build a new version of prxtool, the binary version you have doesn't handle the post 3.X prxes which no longer have section headers

Ooops, my bad obviously :)

Erm where do you want it to go exactly? If it is to the psp's screen then you would have to implement your own stream to handle it, if you want it to a file you should be able to reopen the C libraries stderr handle, if you want it to a terminal get psplink. As for calling function info etc. I don't...

You obviously didn't search very fucking hard.

http://forums.ps2dev.org/viewtopic.php? ... free+space

I think there is a function in the custom firmware sdk to get all registered drivers. Could be wrong though ;)

Not going to happen :) Well unless someone upissues the old psplink and tries to port it across to CFW, it might not be that hard to do.

And the old psplink did have a wifi GDB stub :)

The alternative to working out where the problem is is to try and use psp-gdb, as long as your crash is repeatable it will be easy to track it down (as long as you build your app correctly :P)

psplink works fine on the slim, I can run it fine on the latest m33. The issue with it is gdb doesn't always work. Tbh I have no idea what you are doing wrong, you using the correct release_oe version of the EBOOT?

I can't be arsed to find my password these days and don't even have a toolchain installed on this machine so someone else can commit this fix for psplinkusb/usbgdb/main.c which dynamically modifies its memory ranges if you are on a slim with large memory support. --- main.c (revision 2452&am...

Okay then you are using a slim ;) There is a minor issue with the slim in that the gdb stub restricts reads to the lower 32MB of memory (hey I didn't know the slim would ever be released :P).

I refer you to http://forums.ps2dev.org/viewtopic.php?t=11006 for a fix :P

You probably need to specify no optimisation (use the -O0 switch when compiling), MIPS stuff can get fairly heavily optimised and local variables are in registers which confuses GDB (not PSPLink's fault, it just follows GDB's lead).

RemoteJoyLite is not mine, well the basic core is but it is actually implemented as a standalone thing by a Japanese guy (who doesn't even give me any credit, ah well :P). Knock yourself out :) Of course as far as I know it _might_ be compatible with the basic RemoteJoySDL application anyway, maybe...

Well the "changed" version if the pspDebugScreenKprintf which I modified to use the kernel's callback formatter. Alas due to obvious name conflicts there was no easy and compatible way of matching the two up :) Now if we had a clear separation between kernel and user libraries that wouldn'...

This really isn't the kind of thing we should be talking about here, we all know "backups" is a euphemism and if you going to start talking about cracking then this is where the thread gets locked :)

Or perhaps not play backups, just a thought here...

Is the update thread actually being created? You are using PSP_HEAP_SIZE_MAX which in the past has caused in certain situations to totally drain all of user memory which then makes it impossible to create a new thread because you don't have any free stack. It might work in kernel mode because it wil...

Unfortunately I don't think the kernel stores much in the way of the the actual file name as from the PSP's point of view it doesn't much care. Seems there is some stuff in the Iob UID block (not seen that one before :P) but not much. I think as pointed out the only way would be to capture it at sce...

There is a hard limit (or there used to be) on open fd's on the memory stick, I think it was around 16 or so :)

Unfortunately really the best you can have is sceKernelNotifyCallback as it is able to be called in an interrupt context (which I assume this is). If that is still screwing things up, well it is difficult :) You could try EventFlags but not sure that is going to significantly help you.

I would ask what on earth you are doing, but then I realised you have no idea what you are doing so I can't be bothered to give you a sensible answer :)

Then you would be wrong, there is nothing particularily special about a network interface which means it has to be implemented in a specific device chip. Just because I used libusb doesn't mean it wasn't a custom device, what you _actually_ mean is no-one has written a class device which implements ...

Other than usbhostfs ? :)

The kernel libc's printf doesn't support printing of floats or doubles, you have to write code to convert the float yourself to a string then print that. As for advantages/disadvantages for plugins while you have more user ram if nothing is using it games will almost always use as much as possible s...

It would be theoretically possible, however it wouldn't be practical :)

What does psplink do if you list a UTF8 filename on host? Although you might not be able to do it on Windows (you probably need Linux for that kinda trick as I make not effort to encode the filenames appropriately). That would at least narrow down to whether it is something in the guts of sceIoDread...