forums.ps2dev.org

nice.. okay. I'll go then.

Maybe you should read what I wrote.. I wasnt building an ee-gcc at all.. blackdroid seemed to think ee-gcc works fine with floats.. (which conflicts with your comments) and you seem to think ee-gcc can build many different variants.. have you tried it?

Skippy - not your fault.. GLVOX.exe was corrupted on upload.. Reuploading now.. sorry about that. Have a new one in a zip try this: http://users.on.net/~dlannan//Files/PSP/GLVOX.zip Turns out my host doesnt like exe's :-) .. thats why convimage16 probably is broken.. fixing now.. use this like to dl...

No probs.. but erm.. it will be just my demo? Its basically a dev tool - so you really need to be able to build it to try your own apps. Heres the PC exe: http://users.on.net/~dlannan//Files/PSP/GLVOX.exe The idea is that you can make your own demos without a PSP.. then when you get access to a V1.0...

Sorry I did actually work on the gcc chain on PS2 as a devver about 3/4 yrs ago. Snsystem actually were forced to release their 2.95.2 compiler becuse it was GPL'd gnu compiler.. the subsequent ones they made afterwards were different. If you run the info on ee-gcc I saw it was similar to the one re...

If it works with floats then whats the fix for the c.lt.s problem? Looking at the MIPS instruction set 4K is wildly different to 5900. Sure the opcode may translate is some way, but as far as I can tell they are actually substantially different devices? Unless the 4K on the MIP website is different ...

Replace your xmain in glvox with this. Also make a RED 256x256 pixel height map. Convert it with ConvImage using this: ConvImage16.exe <your red image> HeightMap Full red represents highest point, black represents lowest.. and shade in between.. is.. erm.. inbetween :-) Also at the top of the glvox ...

Yeah. binutils went mostly ok - minus the yacc issues (you have to manually run through some steps that dont seem to happily go through automake).. and gcc needed some manual modifying (some c files dont build properly and some compiler settings fall over too).. yes, I sort of wish I had written it ...

hi. to make a sky.c use: ConvImage <image name> Sky there should be a working ConvImage.exe in the Src zip. As for heightfiled, it currently uses a simple perlin noise function to build it: ComputeMap() does this. To place your own heightmap, simply dont call ComputeMap(). And set the array HMap to ...

Quick q too - qould it be a good idea to put up a zip of the compiler + libs (i used newlibs so should be okay for most stdlib gear). Or is there going to be a pspdev made up like the ps2dev? just wondering? Sorry I sounded grumpy.. hehe I should be sleeping.. <edit> actually ignore that.. since I b...

Im not duplicating anything.. just rebuilding the cross compiler? so I end up with a r4000 set of binutils? this is right isnt it? Last was when I built one fer ps2 about 3 yrs ago? I realise fully gcc has plenty of cross platform targets.. thats why Im doing it? and the current ps2dev.. is definite...

Welp. I am pretty sure whats happening is that the cross compiler has only been built for the r5900. If you try other -mcpu options you will find that the compiler cant build them (unrecognised option). Essentially by specifying -mgp32 the compiler builds only for the 32bit assembly of the r5900. I ...

This is how I mage ConvImage.. CImage in the atl lib supports a heap of formats.. so you dont have to worry about deciphering the image type :-) Flips the 32bit ARGB to 16 bit BGR #include <stdio.h> #include <math.h> #include <windows.h> #include <atlimage.h> #include <string> int main&#40;int a...

Hi.. I added a similar thing to nems PG library. Source here: http://forums.ps2dev.org/viewtopic.php?t=1752 it adds a clip flag to the function - there are times you will want to bitblt to an offscreen buffer (esp for things like the panorama sky map used in my terrain src) and they wont necessarily...

I found lots of bugs in ImageConv.. sorry to those who tried it. I really dont know how I got any usable data!!! Anyhow.. its all fixed now, and I am providing the source so you can see how simple it actually is to do :-) http://users.on.net/~dlannan//Files/PSP/ConvImage16.zip Also I have fixed a fa...

Soz Drakonite - I never look at general discussions cos I thought it perm locked :-) .. good to see it back! :-)

BTW the sources has an emul of sorts to play with too - so people without v1.0 PSPs can dev.. and see what ppl are making.

I was wondering that the gcc built for ps2dev kit was actually built for the r5900? hence the missing ISA implementations. I have used the -march=mips32, with no luck. Also on another note, is the PSP r4K a 64-bit or 32-bit series (there are many) does anyone know for sure the type it is? Its not a ...

Heres the source.. it wasnt _that_ bad :-) .. Also I must send thanks to Nem and the original writer of glvox.. Andrea. Theres alot of their code that did this.. I just tied it together :-) .. Also in the TerrainSrc.zip I have included a simple image convertor. Converts almost any standard windows i...

This is my first effort on PSP .. and after 10 hrs.. I must say this little device is damn sweet. http://users.on.net/~dlannan//Files/PSP/PSP_Terrain096.JPG Im using alot of nems gear, and will post all the source with some minor additions (like a sin/cos and few other bits). Also I have made a simp...

I think this is a compiler problem - Im trying to rebuild gcc with a set of r4000 cpu sources, which will hopefully resolve this. As far as I can tell.. both the 64-bit and 32-bit r4000's cupport c.lt.s .. in all cases. Hence.. why I think the compiler might be at fault. For a quick fix for this jus...

alonetrio: thats sooooo wiked. utterly old skool amiga days dude.. awesome stuff...

btw that font at end.. hehe sweet as...

PRX files appear to be similar in operation to IRX files on PS2. Ie they are separate callable modules that sit in mem (ala dll's).

Just my 2 cents: Id agree with PsPet. Cracking / Using something from CodeWarrior or Snsystems should be a big no-no. At the moment, it is fair to say, that there has been no real 'cracking' at all - simply an explot/hole that the original V1.0 PSP's have that allow people to execute ELF's. By using...

Thanks qubitz - the seller couldnt tell me what it was and didnt wanna open the box. I have found a place with a demo one (with def v1.0 firmware).. which they might sell.. hopefully..

Another q. To the people who made this - is the elf a normal ps2 elf? Or something a little modified?

Quick question for those who have this all working - I have found a PSP 1001K to buy, is there anyway to tell if this will work or not? I know the original japanesse ones were PSP 1000K.. so is this a jap PSP with a patch?

Yeah you can put anything in there.. and youll get the same results on V1.5 firmware. I put in a jpg :-)

I think lmx misunderstood what I said. Basically if the EBOOT.PBP is run to _install_ V1.5 onto a V1.0 system, then the EBOOT.PBP would be unencrypted because the V1.5 isnt yet installed? Hence, you pull apart EBOOT.PBP, say the DATA.PSAR or DATA.PSP and try and find the likely parts that are doing ...

Im not sure if this is the right place for this but, if the version 1.0 Jap versions (like I have) were updated then the EBOOT.PBP installer they run, must be unencrypted right? If this is so, then sure this can be reverse engineered to find out the 'flags/whatever' needed to turn encryption back of...

yah.. Oopo has basically shown what people asked for in the other thread. This is the s**t.. kudos to you Oops.. thanks..

Interestingly this EBOOT.PBP wasnt put together with elf2psp command line tool - either there is a necessary update for this tool, or need a different tool? BTW please bash me.. for being so pessimistic about this.. there has been alot of hype.. and has been driving me nuts.. Its wiked this is now p...

Well now.. that is frikkin sweet!!!