forums.ps2dev.org

so implementin intrinsics didn't prove itself really feasible?

can you share the whole library? i'm really interested in that.

Just use fread/fwrite on the whole data structures. Way easier than writing out all the elements by hand. You will fail epically if your classes have virtual functions (and hence a pointer to vtbl) or you keep pointers to some other stuff. One way to fix vtable issue is to really write the whole ob...

Is GE's hardware clipper doing such a bad job you need to clip manually? I suggest you just feed your model to GE and let it handle all the clipping for you.
Or you plan for a software renderer?

jsharrad wrote:it works fine for me, although my code is hardly an extensive test :)

getting the code to compile and link correctly is already a win to me. :-)
but indeed, we need some kind of a testbench. i'm not sure whether built-in testsuite will do since it's a cross-compiler we build.

Fixed top message for truth. © :-) UPD: I experience major slowdown when working with this version... For some reason it chews the disk for a few seconds and only then does the work... And that for each file being compiled. I'm not sure whether this is my cygwin installation's broken or the compiler...

sure, take it from http poly-glu.eu/temp/gcc-4.3.0-PSP.patch

In fact, you can tell them to install anywhere. All that is needed is to tell gcc's configure where to find them. A good idea would be to just let them configure with default prefix and install over current cygwin libraries -- you'll just update your own system. Then nothing will be necessary to be ...

I think 4.3.0 will be better. :-)

hlide wrote:I guess what it lacks is vfpu now.

If you mean compiler intrinsics for VFPU like that is done for, say, SSE or AltiVec, then it's a damn load of work... I'm not sure even where to start.
But that'd be very nice to have, surely.

Oh, they really are. Thanks!

On the secont thought... How can I track whether the transfer completed or not? Do these calls block?

if the sdk GU library routines are modeled after "official" ones, then you should expect that framebuffer pointers get stored somewhere inside userland data. see GU library for more info.

I'm using 3.x firmware... looks like these functions are no longer exported.
But, on the other hand, officially released software should still work with new firmwares. How do they manage to do that?

And we get no chance to see if our transfer request has been fulfilled...
Can you point where sceDmacMemcpy is exported from? There's nothing on this in pspsdk.

didn't they increase the size of VRAM too on Slim? or sceGeEdramGetSize() still reports 2M?
sorry, no Slim here to check...

Is it possible to do a DMA transfer from user code? It seems that DMA module is accessible only from kernel-land.
I need that for moving textures and V&I-buffers to VRAM. Please, do not suggest GU fransfers since they are a bit inconvenient for me.

I cannot find in this patch where you add TARGET_ALLEGREX for ISA_HAS_ROR. it's at @@ -823,6 +831,7 @@ || TARGET_MIPS5400 \ || TARGET_MIPS5500 \ || TARGET_SR71K \ + || TARGET_ALLEGREX \ || TARGET_SMARTMIPS) \ && !TARGET_MIPS16) ...you scared me. i've just thought i really mi...

well, here it is...
needs fresh gmp and mpfr built and available (for static link to gcc).

UPD: take it from http poly-glu.eu/temp/gcc-4.3.0-PSP.patch

hmm, configure refuses to --prefix with relative path. damn it. :) use some absolute path then..

(I've patched 4.3.0 at least, now building it) strange, they should build and install without any problems... for now, you can try the following... script for gmp-4.2 #!/bin/bash echo "***" echo "*** Building gmp-4.2" echo "***" if [ ! -d gmp-4.2 ] then ...

considering the -mpreferred-stack-boundary... sorry, i've posted old patch :( surely, i've added this option, but on my another machine... my fail. about 4.3.0 -- they say 4.3.1 will be soon out... maybe we should wait for it? but surely i'll look into patching 4.3.0 too. does 4.3.0 build with 2.16 ...

I've ported the patches to gcc-4.2.3. Looks OK to me, my code compiles and runs without problems. Anyone please test it with yours. :-) Yes, binutils-2.16.1 still do... Didn't manage to port all the changes to 2.18. UPD: fixed for -mpreferred-stack-boundary... sorry, took the wrong patch. diff -burN...

I use default settings for the heap, e.g. I set nothing. :-)
Thread creation does not fail, the threads seem to work.

Unfortunately, it still fails. The screen is still flickering. :-(

I've bumped into unexpected problems with multiple threads having PSP_THREAD_ATTR_VFPU attribute set. Let me describe the setting... I have main thread and, say, 8 workers. All of them have the attribute set (potentially). In the main thread i do rendering stuff, worker threads are created for sound...

What is the reason for -G0 to be used? It seems that without this option the programs compile to much smaller code.

moonlight wrote:Anyways, if you want to see the rest of opcodes, get prxtool ;)

Hmmm. Didn't think about that. Thanks for the advice!
An updated IDA Pro plugin will be completed in a day or two. :-)

When going thru interruptman code with IDA, I've noticed some unknown opcodes here and there. The first ones seem to map to COP0 family, but they are marked reserved in MIPS docs. These insns seem all to be R-types and use rs=0x04 or 0x06 or 0x00. The second ones appear to be SPECIAL3-BSHFL insns, b...

Just go straight to ps2dev.org and download pspsdk win32 build. it has an installer and everything you need to set up working toolchain under win32/cygwin. no need to install cygwin itself.

jean, I do not see any way to perform general purpose calculations on the fixed-function pipeline.

I've grabbed latest prxtool sources and has successfully built it for win32. There's one minor problem with tinyxml sources in tinyxml.cpp: ./tinyxml/tinyxml.cpp: In member function `TiXmlElement* TiXmlNode::FirstChildElement()': ./tinyxml/tinyxml.cpp&...