forums.ps2dev.org

Well, I see the speed being the same than in XMB: 1/60.0f. Anyways you can use the vlfGuiSetModelSpeed

In module_stop, do not pass the result of sctrlHENFindFunction(...) as the function address is still the original one (only the syscall entry changes). Instead pass directly the address of the patched function: e.g. PatchSyscall(sctrlHENFindFunction("sceIOFileManager", &quo...

Change 0x1007 to 0x1006. The module had the attributes to not be stopped, so module_stop don't get called.

Yeah. That would work. To delte things in other thread, it is usually better to add an eventhandler with the two first params set to 0 and -1 (0 = no buttons, the -1 indicates no delay will ever be applied), delete objects from the handler which is executed before the painting code of next frame, an...

Torch wrote:There is randomly some nasty flickering when calling the RemovePicture functions. This is truly an awesome lib.

In which thread are you calling remove picture functions? They should be called from the drawing thread, which also includes all event handlers.

Yeah, this thing is normal now that I think of it, the iso stuff in XMB requires some patches that vshctrl does when vshmain is loaded, and the patches of iop.prx are incompatible with that. I'll create later a version of iop.prx with a module_stop that clears everything to its original state.

If you want to detect just GO MESSENGER, you could use sceKernelInitFilename to know the path of the file, read it, check if it is a pbp, if it so, read the sfo and compare the game code with the one of GO MESSENGER. This wouldn't work with hombebrew pbp's because they all use same gamecode, but it ...

Super Sheep wrote:As to avoid the vshctrl hooks?

vlfGuiGetLanguage (I think thats it) returns an int. Which integers represent which language?

They are in psputility_sysparam.h.

Are all these libs required for just the wave background?? -lpsppower -lpsprtc -lvlfgui -lvlfgu -lvlfutils -lvlflibc -lpspreg -lpspsystemctrl_user -lpspkubridge -lpspwlan And is this still required or is the path set automatically now? char *path = (char *)argp; int last_trail = -1;...

phobox wrote:since you haven't used iop.prx in your sample, is it still needed?

mmm, yes, I just forgot. Maybe this last sample won't work in a normal 4.01 M33, but in one installed from DC (wher all files are written with 0777 permissions).

Search for booster ipl sdk, there is no much more. There you have all needed, the syscon/sysreg driver, and a ms driver.
A different thing is to make an ipl that patches one of Sony ipl's, that depends of the firmware.

Dariusc123456 wrote:But when faking the region, does it really give its full affect to run umd games maybe from other regions?

nope. At the moment only video umd's are using region things, and the fake region cannot make umd videos of one region to work on other.
Now, however, I know how to do that.

http://www.sendspace.com/file/br9qxh Sorry for delay, here is the version with support for termination, additionally i have included some defined types to make the prototypes more readable, and fixed a very critical bug that leaked memory each time something was loaded from a resource; also negative...

What I don't understand is why so far any of his threads have gone to hall of shame. He is lucky :p

Games use sceImposeSetLanguageMode to do that.

It has 2 params, first one is language code. Second one is button. The values are same as defined in some .h.
I have never got the point of why Sony allows game developers to change that, it is annoying for the user, mainly the language change.

There is a problem: net api is not kernel mode, so, they are no syscalls, they are pure jumps from user to user.

Real test, a file of 13064 KB which is read in 2 MB chunks. Firstly it was fragmented into 7 fragments, later it was defragmented to a simgle fragment. The results (they always give same speed after various tests): - 7 fragments -> 1306 milisecs - 1 fragment -> 1296 milisecs I guess it doesn't worth...

It is a produt code.

01 -> TA79-TA81
02 -> TA82-TA86
03 -> all psp 2000, no matter which motherboard

If you meant the other byte which is next to it, that's the region code:

03 -> japan
04 -> america
05 ->europe (there are lot more of regions but those are the typical).

3

Message too short blah blah

cory1492 wrote:moonlight: is it possible to exitVsh back to pspbtdnf*.bin?

No. That file is only loaded by the special ipl of DC7.

I will release this week a version with the unload problem fixed.

If nkSuspendThread is implemented using sceKernelSuspendThread, it will fail and return inmediatelly if you specify the current thread.
If you want to suspend a thread, you have to do that in other thread.

Don't use suspend thread for the current thread. Use sceKernelSleepThread.

vlfGuiLoadResources don't work: char *names[2]; void *datas[2]; int types[2], sizes[2]; names[0] = "tex_game"; names[1] = "tex_sdwn_game"; types[0] = types[1&a...

J.F. wrote:Does scePowerRequestSuspen() even do anything? I've never seen it used. For a button test, don't use undocumented functions - try something known to work, like sceKernelExitGame(). :)

It causes a sleep mode. But maybe it is scePowerRequestStandby what he really wanted to do.

The second param indicates the partition, usually PSP_MEMORY_PARTITION_USER or PSP_MEMORY_PARTITION_KERNEL. It has no much secrets, the main difference of this function with others, is that this one enters in lock state until the memory can be allocated (or until an optional timeout has passed). All...

Well, if the algorithm is AES128 based like the certificate verify opcode, and the "private key" is in the hardware, encryption is symetric, because the "private key" is not really private, it is public, it is there in hardware. Another different matter is that it cannot be retri...

You can't bruteforce something you don't even know the algorithm.
It is probably AES128, at least now it is a total FACT that kirk uses AES 128 algorithm (not confirmed it is used for prx's though), but mixed with lot of shits, various loops, "private" keys in hardware, etc

Try mallinfo, maybe it works.

The problem is this: vlfGuiSetTitleBar(u, 0, 1, 0);

when it should be vlfGuiSetTitleBar(u, -1, 1, 0);

0 is a valid handler for a picture, and was assigned to the battery shadow internally when calling vlfGuiAddBatteryIconSystem.