Excited about a homebrew scene

[scherzoman]

Hey, everyone. A friend of mine managed to get a PSP for me and is bringing it by today. I'm happy.

The reason I'm posting here is because the first thing I thought about doing after I've played Twisted Metal a little is homebrew development. I'm an active coder in the Dreamcast homebrew scene an I really can't wait to see what's possible on the PSP.

My question is, what is the current status of getting code to run on the PSP? Has anyone set up a cross compiled GCC for it? Are there issues about code signing to get things to run? I just want to know where I can start lending a hand as I finish up certain projects on the DC. Any information is welcome. Thanks.

[Energy]

Hey, everyone. A friend of mine managed to get a PSP for me and is bringing it by today. I'm happy.

The reason I'm posting here is because the first thing I thought about doing after I've played Twisted Metal a little is homebrew development. I'm an active coder in the Dreamcast homebrew scene an I really can't wait to see what's possible on the PSP.

My question is, what is the current status of getting code to run on the PSP? Has anyone set up a cross compiled GCC for it? Are there issues about code signing to get things to run? I just want to know where I can start lending a hand as I finish up certain projects on the DC. Any information is welcome. Thanks.

currently no one has manged to get any code to execute. It's encrypted. However if your a DC dever you will know Marcus Comstead. And he is on the job... lol. You never know, it maybe an xbox style hardware hack, or it maybe someone cracks the encryption.

So yeah code siging is an issue @ the mo... but it's early days.

[scherzoman]

Well, if it's possible then Marcus is certainly capable of figuring it out. Of course, I'm imagining a SNES emu on PSP. I'm sure once Marcus figures it out, that will probably be one of his first projects. If not, I'll definitely take that up.

[LMUCMSIMike]

i've got GCC cross compiled for it, compiling both COFF and ELF (got 2 versions cross compiled, just to be sure)
but nothing yet on the way on executing it


http://psp.wtfwasthat.com

[Guest]

i've got GCC cross compiled for it, compiling both COFF and ELF (got 2 versions cross compiled, just to be sure)
but nothing yet on the way on executing it

Say you compile "hello world", stick it on a memory stick, somehow get the PSP to execute it (lets ignore any packaging and crypto issues for a second here), how will you know that the PSP ran it successfully ?

Example here, there was some MP3 player, maybe it was a new Ipod, where people didn't know the internals in such a way that they could get any output. Without output, they had no way to know if running something succeeded, much less how to get back data such as memory location values. You can't just do a printf and expect something to appear on screen - won't work if you don't know how to associate libc printf routines with the hardware firmware's routines to display graphics on the screen.

In the case of the ipod (or whatever it was) somehow they found code that made a buzzing sound in the audio. Maybe it was a side-effect. Anyhow, this gave them the capability to "buzz" data back that helped them to learn the internals.

That is whats needed here. But there is a huge barrier to getting there on the PSP, make no mistake about it.

[ooPo]

Hooray! Someone figured out how to compile binaries for a MIPS processor!

The scene is saved! :)

[Guest]

Hooray! Someone figured out how to compile binaries for a MIPS processor!

The scene is saved! :)

Shouldn't we have the toolchain.sh scripts now start installing a MIPSR4K target toolchain now ? :)

So we will have: ee-gcc, iop-gcc, and now, psp-gcc! ;)

[pdc]

i've got GCC cross compiled for it, compiling both COFF and ELF (got 2 versions cross compiled, just to be sure)
but nothing yet on the way on executing it

Say you compile "hello world", stick it on a memory stick, somehow get the PSP to execute it (lets ignore any packaging and crypto issues for a second here), how will you know that the PSP ran it successfully ?

Example here, there was some MP3 player, maybe it was a new Ipod, where people didn't know the internals in such a way that they could get any output. Without output, they had no way to know if running something succeeded, much less how to get back data such as memory location values. You can't just do a printf and expect something to appear on screen - won't work if you don't know how to associate libc printf routines with the hardware firmware's routines to display graphics on the screen.

In the case of the ipod (or whatever it was) somehow they found code that made a buzzing sound in the audio. Maybe it was a side-effect. Anyhow, this gave them the capability to "buzz" data back that helped them to learn the internals.

That is whats needed here. But there is a huge barrier to getting there on the PSP, make no mistake about it.

Apologies for being simple here but if you want to check an app is running,
make a never-ending loop which eats CPU cycles like a crazy m0fo and then see if MP4 playback is jumpy.
Or set variables designed to occupy 90% of the free RAM and see if the PSP can successfully decode and display a large image.

Disclaimer: I have never coded anything for an alien system before :)

[ooPo]

Of course, that assumes you can run your test program in the background while you arse around with other stuff... right?

[Guest]

Hey, kudos for giving it a shot, keep thinking up ways to try something.

Oopo does have a point, so far its only been possible to run only one thing at a time on the PSP, so chances are you run your "loop" and it either waits there and runs it, or it returns, or does something completely unexpected. Assuming the PSP doesn't reject the file outright.

Even if it could run in the background (you would need to know the threading mechanism of the PSP to put it in the background, thats something we have no idea about yet), the MP4 thread may run at a higher priority and therefore not be impacted by the loop.

Once one CAN get some code to run, I imagine all kinds of crazy things will be tried just to get SOME feedback. Imagination will be helpful. The hard part, is getting to the point where the simplest loop can run.

[ooPo]

I suppose you could see if it empties the battery faster...

[dankydoo]

I'd imagine that a disassembly of a firmware update might reveal quite a bit of the innerworkings of the psp, at least maybe a framebuffer address?


dankydoo

[Guest]

I'd imagine that a disassembly of a firmware update might reveal quite a bit of the innerworkings of the psp, at least maybe a framebuffer address?


dankydoo

Sure! Let us know when you have it decrypted so we can disassemble it! :)
Oh, you missed those postings ? :)

[LMUCMSIMike]

i've got GCC cross compiled for it, compiling both COFF and ELF (got 2 versions cross compiled, just to be sure)
but nothing yet on the way on executing it

Say you compile "hello world", stick it on a memory stick, somehow get the PSP to execute it (lets ignore any packaging and crypto issues for a second here), how will you know that the PSP ran it successfully ?

Example here, there was some MP3 player, maybe it was a new Ipod, where people didn't know the internals in such a way that they could get any output. Without output, they had no way to know if running something succeeded, much less how to get back data such as memory location values. You can't just do a printf and expect something to appear on screen - won't work if you don't know how to associate libc printf routines with the hardware firmware's routines to display graphics on the screen.

In the case of the ipod (or whatever it was) somehow they found code that made a buzzing sound in the audio. Maybe it was a side-effect. Anyhow, this gave them the capability to "buzz" data back that helped them to learn the internals.

That is whats needed here. But there is a huge barrier to getting there on the PSP, make no mistake about it.

if, for instance, the PSP uses memory mapped video, and if we can figure out which memory address the video is mapped to, then we stand a good chance of moving junk onto that spot in memory and seeing if anything displays.

if we're able to draw ANYTHING to the screen, a pixel for instance, or somehow ran junk code to try toget the PSP to crash and restart, its a good start.

[Kamilion]

the PSP also seems to have a watchdog timer, if it doesn't receive a response, it simply shuts off the power.

Most probably, the best way to get output is using one of the two serial ports (Remote port or SerialInfrared)... We just need to figure out how to access them @_@

[TerryMathews]

484*172*32 = 2.5MB. If we assume that the framebuffer is a part of the main memory map, we can also assume that it's large enough to justify having a whole dedicated section of the memory map to itself.

My suggestion, to find the address it starts at, would be to write a program that at every 1000h (or even 10000h) starting at 0h, changes the value of that memory location with its address. I know the PSP wouldn't display the number, it would be a character of some sort. It would let us at the same time discern whether the PSP is using ASCII, unicode, or something else for character display AND let us figure out where in the map the screen starts (and probably stops).

Of course, we still need to know how to properly sign the binary. That's outside my area of expertise. Get me to a point where we can execute code of some sort on it though, and I can come up with some crafty ASM that will let us sort out the memory map.

[ooPo]

Actually, 480x272x32bpp = 512k...

But anyway, the vram is most likely not mapped into main memory if the PS2 is any guide to go by. In fact, the technical information floating around says it has 2MB of dedicated vram, so...

As for getting you to a point where you can execute code, that's about 90% of the effort. Once we have code running the rest falls into place. The question is IF we can get code running, not when...