forums.ps2dev.org

Not yet, but it would be easy because of Rafael's fd management that keeps track of the filename that goes with each open file. You could add a field to __psp_descriptormap_type to store the offset, and then add two hook functions: one that loops through all open file FDs and gets the offset, then ...

sceIoOpen is buggy when it comes to relative paths. I don't recall the details, but the newlib wrappers just canonicalize everything before passing to sceIoOpen. Unless you're really performance sensitive, you should use the newlib wrappers when available. They're easier to use (since they're well-...

Always use sceIo* functions instead of f* functions. Why ? f* uses buffers. The issue is if you let PSP to go in standby whereas you have FILE* handles open, you'll get problem when you wake up your PSP.

Going back to dcache_wbinv_all Wouldn't: void dcache_wbinv_all&#40;&#41; &#123; int i; for&#40;i = 0; i < 8192; i += 64&#41; &#123; __builtin_allegrex_cache&#40;0x14, i&#41;; __builtin_allegrex_cache&#40;0x14, i&#41;; &#125; &#125; Use a few less cycl...

sheeh, another guy trying to port it... a port of a port of a port... dude, it's like redoing ps1p or psxp...

m0skit0 wrote:I knew what the MIPS standard said about it, but not what PSP firmware used them for. Thanks for info.

yeah, i realised too late. But let's say it might be instructive for other people ;).

but this is the first instruction executed by the psp (the first instruction of the preipl).. how is it possible to copy v0 to $4? what is it stored in v0? ok, you don't know how the hardware of a processor runs. When resetting, you call a interrupt handler. Under a very specific condition, when se...

@m0skit0: $k0 and $k1 : kernel registers - those registers used to be reserved by the an OS as temporary save/restore registers in a interrupt/exception handler. PSP firmware uses them for another purpose : $k0, something like KTLS probably (not sure about it as i don't care about) and $k1 to contai...

when calling an interrupt/exception handler, psp uses to save $v0 and $v1 into COP0 $4 and $5(not sure for it) so the handler can use $v0 and $v1 for temporary need. At the end of the handler, it restores original values of $v0 and $v1 through those both COP0 registers. Normally MIPS uses $k0 and $k...

dark_hex wrote:BUT THE ORIGINAL MAIN.C ARE VERY DIFERENT.
WHAT IS THE PROBLEM?

in mathematical term, compiling and decompiling are not bijective. So if you are expecting to get your original source, you're not qualified.

__asm__ volatile &#40; "lv.q C000, %0\n" "lv.q C100, %1\n" "vsub.t C000, C000, C100\n" "vdot.t S010, C000, C000\n" "vsqrt.s S010, S010\n" "sv.s S010, %2\n" &#58; "m"&#40;*v1&#41;,"m"&#40;*v2&#41;...

I mean you must post the exact code of your function using "lv.q" which are not working. I'm not sure you are using __asm constraints correctly.

your case is weird. C++ or C isn't the issue.
I use Heimdal' pspsdk and never fail with lv.q.

I'm not sure you're using them in gcc correctly

use heimdal's pspsdk.

__asm__ volatile &#40; "lv.q C000, %1\n" "lv.q C100, %2\n" "vsub.t C000, C000, C100\n" "vdot.t S010, C000, C000\n" "vsqrt.s S010, S010\n" "sv.s S010, %0\n" &#58; "=r"&#40;result&#41;&#58;"m"&#40;...

if you don't care about compatibility with PSP1K (fat/phat/tank), you can use "ulv.q" to load your vectors and just compute with .t. Normally the fourth component of a vector is not changed by the computation so you can store it through "usv.q". But in your example, a "sv.s&...

The problem is: If we release syscall estimation code with the eLoader, Sony will probably find another method to randomize syscalls. And if this happens, the work we have done will be nearly useless. I'm sure they aren't going to TOTALLY randomize syscalls (it's a BIG waste of memory), but a great...

Criptych wrote:Okay, I understand the concept but I'd never heard that term used before. Thanks. :)

This is a technical term. Just google it and you'll find a ton.

I'm not sure I understand what you mean by a "save-callee" register. Are you saying the values in other registers get clobbered anyway? Ok, a caller is the code which calls a function. Callee is the code of the called function. Locals in a function are allocated through save-callee regist...

Okay, it accepts "$f2." But does that last part mean you can't use clobber constraints or that their values won't get clobbered? If the former, it sounds like crazyc's idea won't work. :( I tried to use this feature in my old yapse4psp (psx emulator) and found out it only works on save-ca...

@crazyc: Adding clobber constraints gave me several errors like "error: unknown register name '$fp2' in 'asm.'" But since I'm not using ulv.q anymore, I wouldn't worry about it. if I'm not wrong, it should be '$fpr2' or '$f2'. And it only works for save-callee registers, which are $f20-$f...

the issue is only with ulv.q, not with usv.q. You have choice between lv.q (16-byte alignment) or lv.s (if you use 2D for instance). Okay, I've changed my code to use only lv.q, and seems to be working. Normaly I added an option to psp-gcc to make stack alignment to what you want. It is the same op...

I'll give it a shot. Is this register corruption the only reason not to use ulv.q/usv.q? From what I read in the diggins they aren't significantly slower than the aligned version; how do they compare to lv.s/sv.s * 4? the issue is only with ulv.q, not with usv.q. You have choice between lv.q (16-by...

yeah, ulvq is corrupting fpu registers, i tested it on my old psp1k. As long as you need to be compatible, you have no choice but no using ulvq.

can you be more precise about which instructions are giving bad results ?

can you be more precise about what you get with vtfm3.t ?

on PSP1000, using ULV wiill scratch FPU register with the same index so if you are using VFPU register $C000 to load it from memory, you're modifying $fpr0 with the same value as $S000 as well. That's why you MUST never use ULV if you plan to keep compatibily with psp1000. The reason is ULV is mappe...

You sorta use sceGuPatchDivide to set the level of details as it is GE which will subdivide your nodes into a 2 x udiv x vdiv vertex list to draw. Is it your intention for getHeightAt not to be aware of the level of details? If you really want to have a more accurate height, you need to take into ac...

Shop shop = new Shop(); I'm sorry but : Shop *shop = new Shop; is perfectly valid and should not be the issue. And you're plainly wrong without "*". @OP: It seems Shop.o is missing in your OBJS flag (Makefile), so it cannot resolve the address of your VMT which is normally defined in Shop...

%&#58;include<stdio.h> int _&#40;int __,int ___,int ____,int _____&#41; <%for&#40;;____<___;_____=_____*__,____++&#41;; return _____;%>main&#40;&#41;<%printf &#40;"%d\n",_&#40;2,5,0,1&#41;&#41;;%> main&#40;&#41;<%printf&#40;"32\...

Arrrf arrf arrff i cannot stop laughing !!! and you call it a toolkit !?

sheeh... you could at least make a RAD using those tools !