forums.ps2dev.org

As, yes, I've been a bit of a spanner. The OE firmware version bootstrap requires the psplink prx in the same directory to be able to work...

It's all good now.

--JW

Yeah, I have the normal PSPLINK 2.0 Final running from the GAME150 directory. I wanted to get it running on 3.10 as well for testing purposes. It's no biggie at the moment as everything I'm working on works fine under 1.5, but I'd like to get 3.10 running out of interest as well. According to other ...

I'm trying to get PSPLINKUSB to run under 3.10 OE-B. It's all built and I'm running the EBOOT from boot271 in the normal GAME directory (fw 3.10). It boots but I then get an "Error 0x80001002 loading module". I've had a search on the forum but can't see it mentioned anywhere... :EDIT: This...

Encrypt and/or compress it. Search the web for "file encryption source code". Or something really simple like CRC/MD5 check on the file contents. As long as the encryption and decryption are done by the same application it's crackable, though. Personally I wouldn't bother, other than for c...

You'd need to remove any exploit code from your game and also get it to load your data from host0: rather than the memory stick. The devkits will run PRX or ELF, but make sure they're user mode and not kernel. The best way to test would be to get your game running as a PRX using psplink. As psplink ...

Yes, I found this too -- UV's are not signed, which is a real pain at times. Just make sure your models do not use negative UV's. Using 16 bit verts is fine for models, though, not had any problems myself. I even use 8 bit verts where the models are very small. You need to scale your models verts do...

a) I was hoping you would have.
b) Nope, tend to read the forums for news. ;o)

Nice one, much kudos to you. Time to get a debug and file server sorted out for Windows.

- Jw

Sony announce WiFi hotspot demo download service. Interesting...

http://www.gamesindustry.biz/content_page.php?aid=14981

- Jw

That's exactly the info I was after, cheers fella! :o) I take it these are fairly standard USB structures? From my little experience of USB a lot of the PSP stuff was quite familiar. Have you tried writing a USB protocol driver yet, TyRaNiD? I've got a kernel mode PRX build environment setup ready t...

Sounds intriguing, although I cant find it in /trunk/pspsdk/src/usb/ or usbstor/ through the SVN web interface (no native TCP client installed here). Is that where it should be?

Thanks!

-Jw

I have been hacking around with the USB code on the PSP and there appears to be a USB subsystem which you can register custom protocol drivers with. This is how things like the USB mass storage and inter console communication are handled - ie. through different "plugins" for the USB subsys...

With a brief scan through the source distribution, I would say this would be a big job. There's lots of decompiled x86 assembly from the original game (I'm guessing), which you need an x86 compatable processor to run. As the PSP uses a MIPS, you're out of luck unless you rewrite all the assembly cod...

Has anyone made any headway with the USB protocol drivers on the PSP? I've managed to make some sense of it, but there are a few calls which register protocol drivers which pass in an unknown structure to set it all up, and I've had no time to look into further recently due to work and having to fre...

MS Visual Studio 6.0 with custom written cygwin / GCC integration. As slick as you can get...

-Jw

Ah, ok. Yes, I am using a kernel mode PRX, but assumed you could create a user mode thread from this as you can a kernel mode ELF. As has been mentioned before, there isn't any difference between an ELF and PRX, so I didn't see any reason why this wouldn't work. However, I now realise that as the PR...

With indexed you have to read the index, then the vert (done by hardware). In non-indexed, you just read the vert. So, basicly, you have an extra read involved with indexed mode. If space is your concern rather than speed, indexed can be good, otherwise it's bad... ;o)

Hmmm... I've been poking around in some ELF's and the top bit of byte 0x43 seems to be set when in kernel mode, along with the 0x1000 attributes. If I set this bit along with the 0x1000 attributes on a normal elf I get the previously mentioned error. Any ideas what this bit is doing? *EDIT* Right, t...

What more do you have to do to get an ELF to boot in kernel mode over changing the module attributes to 0x1000? If you simply change the attributes of an elf which works perfectly with 0x0000 to 0x1000 you get an 0x80020001 error. Please dont say "just compile with the latest PSPSDK" as I'...

Ah, ok, I thought gp may have been some kind of base pointer. This doesn't explain my crash, then. I have tried a while(1) in the thread, and it still crashes. It's as if actually calling the thread is what is causing the crash, but the address looks OK for user mode code (ie. top nibble clear). Ver...

I'm having trouble starting and running a user mode thread from a kernel mode bootstrap (not using the normal crt0). Can anyone tell me why this does not work -- it crashes when sceKernelStartThread is called): int _main(int args, void *argp) { return 0; } int _star...

Thanks TyRaNiD, that's what I was missing. All working as expected now... :o)

Should it be possible to use LoadModule and StartModule on a decrypted PRX? I've decrypted one and you dont seem to be able to use LoadModule on it -- it comes up with 0x80020148 (SCE_KERNEL_ERROR_UNSUPPORTED_PRX_TYPE). Am I missing something?

Just out of interest, why are the pspsdk elf's not relocatable?

Is there a tool around the net which will decrypt a PRX and dump it to the memory stick? I've been disassembling PRX's using the dump module from pspinside, but I've just noticed prxtool which looks the dogs. Will make things a load easier.

What's the deal with the *ForKernal and *ForUser libraries? Can you only call kernel functions (*ForKernal) when in kernel mode and user functions (*ForUser) in user mode?

This is one area I'm a bit foggy on, and can't seem to find any definitive information...

I'd forgotten how much of a pain in the arse disassembling risc code is -- all the 16-bit immediate loads to create 32-bit address pointers really screws up the ability to easily trace back pointers in the code... Anyway, I've made some good progress with the disassembly now, and am actually startin...

Right, I've started disassembling and commenting usbpspcm.prx now. Thanks to pspinside I have a few system calls already documented, however there are quite a few missing. Could be a bit tricky figuring out what's going on with absolutely no point of reference... :o/

PSP is USB2. Although there is nothing stopping it working on a USB1.1 connection afaik. So a USB1.1 logger should work ok... I've been thinking and I think the best bet is either logging via the usb.irx on the PS2, or by writing something which communicates directly with the PSP USB port. Maybe som...

Yes, the PSP can operate in a few different ways by the look of it -- the normal mass storage mode, talking to peripherals such as the microphone thing and talking to the PS2. Hence the different HIDs. You wont be able to snoop around and find anything interesting about the USB connection, really --...

The same thing happens when you try and look for a connected PS2 on the PSP when it's plugged into a PC. It's just presenting itself using different HID's, and hence the PC doesn't know what to do. To get the PC communicating with the PSP we need to write a USB device driver which mimics the way the...