forums.ps2dev.org

sKQuerySystemCall returns the syscall ID, IIRC. That's the easy way to find the syscall ID if you happen to have access to kernel mode and have the function address / syscall ID for sKQuerySystemCall in hand. But if you're working at a very low level in raw assembly and don't have access to niceties...

To answer the original question : there's an opcode, syscall 0xnnnn, which will directly invoke a syscall. The tricky part is figuring out what the syscall ID that you want is. In the early days, syscall tables were static, varying only depending on the firmware and mode (VSH, game, etc.) in use. Bu...

I am wondering why you need to worry? Let the PSP firmware do its job and handle memory allocation for you and not pay any attention to where you stack ends up :) I think the aim was to understand how to understand static memory dumps - where of course the firmware can't really help. However the be...

Yes, but compare that to the ir main loop - it doesn't even bother trying to translate the serial from whatever into pikey format. It's clearly just a debugging tool, or perhaps just a skeleton that was never fleshed out since there was never a need for it. You either need to redo the SIO input mod...

The stack will be different for every thread running, since they all share the same address map (there's no MMU in the PSP) - otherwise, they'd trample on each other's stacks. If you have access to the thread info structures, you can query those as I believe they store the origin of $SP directly, fo...

There are user-mode funcs to initialize the network, ever since something like FW v2.00.

Assuming that you want the config to apply at run-time, rather than at compile-time, then you're going to need to write some code in your program to open the file, read it and parse it. If you want to see some really crap code for doing this, then the PiKey source code contains some simple and small...

Of course the aim of piKey was to provide a framework into which you could easily slot input plugins for all manner of different hardware, feeding into a (hopefully) widely-adopted set of output plugins. I'm keen to get piKey back up to speed again, though it would be interesting to hear what you gu...

Just to make sure the record is straight in the places where it matters...

This effort was much more than simply the Noobz team. See the readme / release post for more details.

This is hardly the place to get user support for other people's plugins.

Having said that, you might try deleting the settings file - looks like that might work.

Take a look at framework/pikey.c, around line 830 or so.

Basically I think you need to look at what how that thread there is initialised.

Should be fine for executables, but just be aware that it doesn't work for PRXs - although they maintain a record of their current directory, that isn't set to any useful initial value.

The piKey source may help you, the SIO plugin happily does SIO in VSH.

I bought one at that price from Amazon (and the same supplier, IIRC), it was brand new in original sealed packaging and came with all the relevant software etc. It didn't seem too unreasonable a price to pay.

What errors do you get?

They got more strict with user/kernel interaction as time went on. 3.30/3.40 seem to be extremely picky about trying to ensure that kernel code doesn't call into user mode functions. Security considerations, I guess. Incidentally I have now managed to get 3 of the 4 piKey modules that were misbehavi...

Typically the convention is just to pass '0' for any unknown fields, and hope for the best...

I'm seeing a similar problem with piKey on 3.30/3.40OE.

At the moment I suspect it is the flags on the module import / export stubs, but haven't had time to investigate properly. I'm pretty sure it is not to do with import of any user mode imports from the system libraries.

Sounds like a plan. Should I try to "unblock" some of the other keyboard drivers first? I just did the Palm one because that's what I have. I suspect the others are OK, your fix to the palm is the same I think as one that went into the non-PRX code - I hadn't expected it to be needed in b...

You can send changes to me if you like, although Monsti is the official owner. I think Monsti had more or less abandoned the PRX flavour, and my interest is much more in using piKey as a more generic library, than using the lib as a PRX, but I'm happy to help you keep it updated if you want to work ...

Well spotted, I just committed your capslock fix to SVN.

Happy to commit any other fixes for you if you need it.

I just spent a couple of weeks poking away at a frustrating crash, apparently during module_load of the piKey PRX in game mode. I finally managed to nail it, and learnt a few things along the way. Seems these things aren't new, but aren't widely publicised, so it seemed worth making a post to save o...

In that case I would suggest talking to monsti about the direction he feels his lib should be developing towards, but I would guess that a serial keyboard isn't a natural fit.

It certainly sounds like something we'd like a driver for in piKey, one way or the other.

I'd like to add a driver for this too, but does it belong in this or just in PiKey? Assuming your driver fits naturally in libpspirkeyb, I'd recommend putting it there, and then more people can benefit from it - since piKey just picks up the pspirkeyb lib and so can make use of any changes people a...

piKey Based in part on Monsti's fine work with libpspirkeyb, piKey aims to be an open and extensible input driver framework. The model is that you have a central framework managing input queues and plugin loading, and then 2 flavours of driver plugin: - input plugins, which are a source of input da...

True, I would imagine this only applies to wallpaper in VSH.

Note that the alpha byte in the framebuffer gets filled with random values since firmware 2.5, as a countermeasure against exploits that use code loaded in the framebuffer.

(Actually, it might not be random, it might just be 0 - I don't remember exactly.)

Isn't it something like SelfStopUnloadModule() ?

And make sure to undo the socket clips before unplugging any ribbon cables - it's easy to ruin the cables otherwise.

Not as far as I know.

For running code via the TIFF exploit, you can grab the TIFF SDK from www.noobz.eu, it does most of the work for you.