forums.ps2dev.org

try

sudo apt-get install compat-gcc*

and do the ls *gcc* thing.

(Compat is way back like 3.4).

Try and install compat-gcc via apt or synaptic and head into /usr/bin then type

ls *gcc*

and post the output, assuming you got compat-gcc installed.

I had to use an older version of gcc on both the psptoolchain and ps2toolchain.

What do you mean? If you mean changing test_buffer and size and such, then test_buffer and the size argument would just be changed to the buffer containing the binary(and if it was large, you'd do a loop) i.e. int flash_file(char *filedest, char *filesrc) { int fd0 = sceIoOp...

I think it's because you're writing test_buffer, which is empty. I'm almost positive this is the problem. To confirm, do something like sprintf(test_buffer, "Test"); right before flash_file("flash0.... okay, that works, it flashes the text what ever is in the brackets, but how do i u...

I think it's because you're writing test_buffer, which is empty. I'm almost positive this is the problem.

To confirm, do something like

sprintf(test_buffer, "Test");

right before flash_file("flash0....

Yeah, it's not so much has it been hacked as much as has the hack been released.

I figured as much. The problem is that never happens. With your code in there it ends in a endless loop. Have you tried it? It's always worked fine for me. In english: "Lets check if sceKernelLibrary is loaded, you know, the kernel. If it is, lets go ahead and skip this delay here, else we'll ...

Just a shot in the dark, but in the if(fd < 0) in the flash_file function, try

if(fd <= 0)

because it looks fine, writewise.

Can't be the plugins, the only one in game.txt is my kernelmodule.prx - which attempts to load usermodule.prx. Edit : I exchanged the ku one for the normal sceKernelLoadModuleMS and now I get the error code 0x8002013A which equals the constant SCE_KERNEL_ERROR_LIBRARY_NOT_YET_LINKED. But how can th...

Could try

Anything with sce* is just an import, there is no source. The headers, however, are in /usr/local/pspdev/psp/sdk/include and such.

Be creative :).

Torch... that's... a brilliant idea! Why didn't I think of that possibility before? I can already patch the function memory properly... the only thing left to do is create a usermode module and launch it side by side with mine. But seriously. I would far more prefer doing it over syscalls directly ...

Another thing you could do(99% sure) is be epicly ghetto about it and find an import syscall of whatever usermode thing you want to do, and just hook the desired function to that syscall, but then hook that syscall to your kernel mode function. For example, in my case, I could hook your usermode fun...

1. I'd ask someone besides myself, lol
2. sceKernelLoadModule, sceKernelStartModule
3. kubridge from the cfw sdk?

Likewise with source compiled.

From my experience, if you patch the syscalls(via sctrlHENFindFunction, sctrlHENPatchSyscall) they can do it flawlessly, without all the jabber.

Rich43 wrote:I think the ps2dev remote joy only does nethostfs?

No, it works with like all of the *hostfs's, last I checked. I know for sure it works with usbhostfs, though.

Have I ever told you I want to bear your children? Because I do.

svn checkout svn://svn.ps2dev.org/psp/trunk/prxtool
cd prxtool
sh bootstrap
sh configure
make
make install
make clean


Should work.

I'm using fedora 10 with countless things compiled from source, some packages, some this and that, and it's worked fine for me so far.

Is your OS 64 or 32 bit?

Why are you in the flash? Can you get to the recovery menu? Try to add to the makefile "LIB = -lpspi2c_driver"?[/url] He has the library loaded compiler-side, just not prx-side, similar as if you were to try to make a usb connection with none of the usb modules loaded. I'd borrow loadstar...

Another thing is that you're going to have to learn some MIPS to be able to understand what all of the prxtool stuff does, as it doesn't output in C/C++.

Just a note, but for some reason(Well, for very clear reasons in that it's just not compatible) the toolchain compiles perfectly with no previous psp* stuff installed, while it fails with the older stuff already installed.

In the CFW systemctrl_kernel library(probably others too, but that's the one I know off the top of my head), you can hook syscalls like

int func_addr = sctrlHENFindFunction(modname, libname, nid);
sctrlHENPatchSyscall(func_addr, &function_name);

That's one of the easier ways to do it.

slasher2661996 wrote:WARNINGS DO! MATTER!!![/i][/b]

Sometimes. Other times they are indeed just warnings and are more of an annoyance than anything.

Anyways, very nice, and thank you for sharing this..complex piece of code, and licensing it under the GPL :D.

It tells you where the exception happened and dumps all the registers so you can read what is in what register. This is more useful to the projects developers in my opinion as they know more of what's going on, but, usually it'll give a hint as to what triggered what, just gotta somewhat understand ...

To decompress a gzipped one:

Delete the first 0x150(or until the 0x150 mark) then rename to .gz. Works like a charm for me.

Oh, my bad. Sorry 'bout that.

jojojoris wrote:yeah... it was me!!!

But i'm not a good coder. I don't think i am able to finish this project.

No, it was not you, it was SANiK.