PSX-P Beta 1 Released - Playstation Emulator for PSP

[Tinnus]

Um... put your glasses please.

zodttd's post was not meant to say Yoshi's right and the source is not required to be released

He didn't said he used pieces of PCSX, on the contrary he said it used MOSTLY PCSX code and there's still a lot to change to non-PCSX

[zodttd]

Please re-read my post.
It was stating that BOTH PacManFan's code AND PSXP violate the GPL. The only excuse would be that PacManFan wasn't done and his source was leaked. And besides that fact, there isn't much to care about since PSXP is far from where it needs to be anyways.
The intention of the post was to say that PSXP is already overclocking the PSP to 333MHz though.

If you want to get technical, let's talk about PCSX and how it's very similar in design to FPSE's open sourced versions. And how AdriPSX uses PCSX's interpreter code. PSX emulator code is almost always borrowed from either a previous emulators idea, or the code itself. You see the same thing in PCSX. When generic code gets GPL'd, what do you do? In PSXP's case, it was a blatant port, so it violates it. But what if the concepts are used? Just something to think about. If Yoshihiro wants to redesign PSXP based on the concepts of PCSX's design, he has some work ahead of him, but it could be for the better.

So how's PCSX development while we have a developer here? Is there going to be a version 1.7 after the 1.6 beta was released oh, 5 years ago? What's the limit on how long code stays GPL'd? ;P

[F9zDark]

It doesn't matter... As seen with LUA (IN THIS VERY FORUM) hell breaks loose whenever code is similar to another games' code.... Just cuz he used pieces doesn't excuse him from releasing the source...

And I'm starting to wonder, why is the download back, if PCSX's (NOT PACMANFAN'S emulator) GPL is still violated... Right, real legal...

Why does GPL need to be an issue? I like Open Source programming but to me, its a double bladed sword; its great in that anyone can learn from someone else's work. But it also allows for 100 programs that all the do same thing but are different in one minor detail. This is highly counterproductive and goes against all the tenets that Open Source is meant to represent.

Now imagine if Yoshi released his source, how many people out there, would drop everything and begin working on a PS1 emulator for the PSP? Yes, competition leads to a better end product, but rather than having 1 or 2 superb emulators we would be left with 20 $#@!ty ones, none of them complete.

Personally, I'd rather be limited to 1, awesome emulator, than have to filter through the piles of $#@! to find one that is a fraction better than the last.

[dagger89]

Why does GPL need to be an issue? I like Open Source programming but to me, its a double bladed sword; its great in that anyone can learn from someone else's work. But it also allows for 100 programs that all the do same thing but are different in one minor detail. This is highly counterproductive and goes against all the tenets that Open Source is meant to represent.

Now imagine if Yoshi released his source, how many people out there, would drop everything and begin working on a PS1 emulator for the PSP? Yes, competition leads to a better end product, but rather than having 1 or 2 superb emulators we would be left with 20 $#@!ty ones, none of them complete.

Personally, I'd rather be limited to 1, awesome emulator, than have to filter through the piles of $#@! to find one that is a fraction better than the last.

U know what, no1 gives a damn what ANY OF YOU THINK. IT IS PCSX'S CODE, NOT YOURS! get it thru your thick skulls... I'm VERY disappointed with this forum... U claim to be anti-piracy, yet you let this go on???? Shame on you

I'm sure the coders will have their fair share of words for YoshiZERO... Remember the SMS emu incident here? Right...


I HOPE NO MORE RELEASES OF THIS CRAP COME OUT... I AM ASHAMED BY THE PSP COMMUNITY...

[Exophase]

PCSX is far from complete in the stage the open source was left in. PSXP has a VERY long way to go...
It needs:
- To convert the GTE to VFPU instructions the PSP R4000A supports.

Few PC emulators do this (of course, few can run decently on machines as limited as PSP either). I did some work with some MMX (not dynarec'd, too long to be worth it, especially on PSP with its limited icache) implementations of GTE instructions a million years ago but it doesn't make much difference. I was once told the MIPS:GTE instruction ratio is typically around 100:1 (by the author of this emulator), I don't know how spot on this is of course.

Anyway, I've heard a lot of talk about you wanting to do GTE with VFPU for your emulator (mainly from Epicenter on the gp32x boards).. are you 100% sure that it won't come at a precision loss that matters for most games? 48bit fixed point integer to 32bit floating point may work but that amount of error could really blow up >_> Of course I've always been an advocate of VFPU for GTE too, I just want to know if it's really viable.

Nitpicking, but PSP's CPU is Allegrex, it's quite different from the actual R4000 you're probably familiar with.

- Map the PSP GPU to the PS1 GPU

DEFINITELY. In the mean time at least put in frameskip, heh.

- Make an optimized MIPS Dynarec. Just making a dynarec won't help much, if you do it, do it right.

Maybe I don't know what you're getting at by the difference between the two.. by optimized do you mean typical compiler optimizations like liveness analysis and constant propogation or do you mean more fundamental things like actual register allocation? Because the former, while having benefits for going from MIPS to other platforms, probably wouldn't help so much in MIPS->MIPS if the code has already been optimized.. the latter is just a given.

Constant propogation/range analysis is useful even if you can't fold assignments down to fewer instructions because it'll make memory locations more known at compiletime and reduce the amount of calculation going into them, but to get this on a really large scale to the point where you'd really notice the benefit you'd have to reduce probably at least half of all load/stores, and only very complex loop analysis can do this. I don't know of any dynarecs that go that far, although it's still kinda my dream to do this somehow -_-

For ARM I saw big improvements even with a really bad dynarec, but ARM has so much more overhead in interpreting... You're probably right, a MIPS dynarec with NO register allocation would probably not be several times better than an interpreter. Maybe 2x.

- Get compatibility up by not just changing the BIAS define in PCSX for a cheap speed boost.

Well, that explains a lot. *_*

- Get sound working.

On the ME I hope.. and something much more optimized than PeOpS SPU in its current state, look at SexyPSF for PSP, even that barely runs. Of course if you're dedicating the entire ME to that it may very well not matter.

And someone figure out how to program the PSP's VME so we can get the PSP's DSP hardware to emulate PS1's SPU (if this is even remotely possible).. yeah, I can dream about that too.

[niki205]

oh no.. a pass?

what is the pass of extracting ?

[zodttd]

Hi Exophase!

The VFPU in the PSP can be mapped quite well to the "GTE" (Sony love's using fancy names for chipsets), which handles the vector math for the PS1. At least that's what the instruction set the PSP has available shows. From seeing some example code for the VFPU, it's not a difficult job to do. Remember the PSP has an actual VFPU and doesn't need to be done with regular/vanilla MIPS instructions, which might be where you get the 100:1 figure from.

As for ARM, I found out there's vector math instructions that can be used for the GTE as well, and has a 16:1 to the actual PS1 GTE mostly. I remember it being somewhere around 16:1, should be a good figure to go by though.

What I meant by using a MIPS dynamic recompiler, was that if you do a dynarec, it should be programmed in a way to not only reduce the ratio of op's (my MIPS Dynarec for the V43 is mostly 1:1 for arithmetic ops), but also utilize the translation cache properly and other optimizations that can be done. ;P

The ME (yet another fancy name for a second MIPS processor?) is definitely an option for sound, but it could also be used for the GPU/GTE I'd imagine. Of course using Peop's GPU's won't allow that by design. Custom code comes in handy, no GPL worries.

Thanks for the reply Exophase.

[chrisrulz555]

Dude 2nd post be carefull wraggy has laid the law down NO MORE FLAMING so make it your last whinge.Yoshi DOES some great work on the scene.

WTF are you talking about? Yoshi has done nothing but steal code and claim it as his own. People like this deserve no gratitude or respect and should go die in a hole. The guy you told to be careful was on the PCSX team who had their code stolen, dont defend people who blatently steal others ideas and claim it as their own.

[carpy]

Even if he claims it as his own, what does he get for it? "Internet props"? who gives a rats ass? If he's not getting paid for it, then it simply doesn't matter. Free Homebrew is free homebrew, and any jackass who makes a free software should Thank the next guy who comes along and makes his work even better.

Unless you're selling a product, and are losing on your investment by people stealing your work, it doesn't mean anything. You internet legend isn't going to do anything for you.

[Exophase]

Hi Exophase!

The VFPU in the PSP can be mapped quite well to the "GTE" (Sony love's using fancy names for chipsets), which handles the vector math for the PS1. At least that's what the instruction set the PSP has available shows. From seeing some example code for the VFPU, it's not a difficult job to do.

Yeah, the actual vector operations should map nicely, I'm just worried about the data representation being different. The implementations I've seen of the GTE (unfortunately never got to see the best emulators, because they were closed source) all used 64bit floats or 64bit integers to map the 48bit precision. With 32bit floats you'd be losing a lot of precision, but you'd retain the range (I think..).. well, I guess a test should be done. Actually, this could be tested pretty easily, just by taking one of the existing open emulators and changing the doubles to floats. What do you think..?

Remember the PSP has an actual VFPU and doesn't need to be done with regular/vanilla MIPS instructions, which might be where you get the 100:1 figure from.

Right.. the 100:1 figure I was quoting was the ratio of normal integer MIPS instructions to GTE instructions as they actually appear in the PS1 game's code. Meaning that GTE can get away without being lightning fast to emulate when you (IF that ratio is anywhere near correct) only really need to emulate them within 0.33MHz of the R3k's clock speed.

But there's no question that VFPU would be more elegant than calling MIPS functions to perform it (wouldn't want to compile integer MIPS code for it..).. not only would they usually be less code emited than a function call, but you'd get easy register caching too.

Oh yeah, I had another concern with this. As I recall GTE operations set a LOT of flags (at least some do) and I know at least some games rely on them enough to make it a pain (Tekken 2 comes to mind)... I haven't looked too closely at VFPU but I'm thinking that it doesn't deal with all of these. Maybe some dead flag elimination can be used to determine when the flags are actually needed, and do a more generic version then?

As for ARM, I found out there's vector math instructions that can be used for the GTE as well, and has a 16:1 to the actual PS1 GTE mostly. I remember it being somewhere around 16:1, should be a good figure to go by though.

16:1 isn't too bad for this. It's probably better than what you'd get for divide. -_- Although at that point I would not want to be emiting code for it, especially on icache sensitive devices (I know GP2X is one, as is PSP).. function calls would incur a bit of an extra overall cost but won't pollute cache that much.

What I meant by using a MIPS dynamic recompiler, was that if you do a dynarec, it should be programmed in a way to not only reduce the ratio of op's (my MIPS Dynarec for the V43 is mostly 1:1 for arithmetic ops), but also utilize the translation cache properly and other optimizations that can be done. ;P

Yeah, 1:1 for arithmetic ops.. assuming they're in the register cache.. what is the hit percentage like for that on ARM anyway? If your design is anything like mine I'd expect you to have around 10-11 of the 15 ARM registers free for caching (15 minus 1 for stack pointer, 1 for link register, 2 for function parameters/scratch), depending on your overall design and how often you call functions (if you have to for memory access, for instance.. which I do.. and I need plenty of scratch). That's okay for the ~31 for PS1 but not ideal. Fortunately for gpSP I'm super lucky and can fit every last ARM register on the MIPS register file (BARELY squeezed everything in, even have to stomp on $gp.. it was quite a frantic design but it worked)... being able to do static register allocation over dynamic is great because you can do self-reentrant blocks which improves translation cache locality and reduces the overall redundancy of the generated code, and it removes the need to have any kind of retirement code (except when calling C functions, which in gpSP is relatively rare).

By proper translation cache management.. do you mean being able to flush caches partially? Of course this can't (reasonably) be done without making hard indirect links between basic blocks, and even with self-reentrant blocks this is expensive. gpSP is what I consider a "deeply recursive" recompiler, in that it will compile recursively as far as it can on all paths until it hits indirect jumps. You can't get rid of a piece of it without having a bunch of dangling branches left behind, but fortunately the cache rarely needs to be flushed (relatively.. except for some games >_<).. I know this is more or less the case for PS1 too, maybe more so because it has a lot more RAM than GBA.

Actually, gpSP does ease flushing a little bit by partitioning the caches into three independant sections for ROM, RAM, and BIOS, since code for all three are separated by indirect links naturally in GBA code (and transitions between the three aren't too often).

The ME (yet another fancy name for a second MIPS processor?) is definitely an option for sound, but it could also be used for the GPU/GTE I'd imagine.

Technically the ME (Media Engine) is the name of the second CPU, the DSP, the sound chip (VME, virtual mobile engine or.. something, go Sony acronym power), and the video decoder chips.. maybe some other stuff. As far as real commercial devs are concerned it's just a black box that does media stuff for them since they don't have access to it. Homebrew kernel mode hackers are better off, I guess.

GTE.. if VFPU DOES work it'd be much better, because ME's CPU doesn't have a VFPU. For GPU.. that should mostly map in hardware right? Good thing about the PSP: VRAM is 100% fast and memory addressible, so you get to do all the fancy framebuffer effects PS1 can in a natural way.

Of course using Peop's GPU's won't allow that by design. Custom code comes in handy, no GPL worries.

Yeah, absolutely. Although I was wondering today, just how hard Pete's OGL would be to port (was that ever made open??).. since there is an OGL implementation for PSP (PSPGL). Don't know how complete it is.. and plus you'd probably really want to use native 4bpp and 8bpp textures on PSP, they're very fast and map well to a majority of the textures PS1 games use. They're typically even faster than swizzled textures!

Thanks for the reply Exophase.

Thanks for your post for me to reply to ;D I love technical emulation conversation, especially from dynarec devs. Maybe I can stop stirring up trouble on gp32x for a while.. heh..

It's interesting though, don't you think? Here you're doing a MIPS->ARM recompiler and I'm doing an ARM->MIPS recompiler, and they both have such clearly defined (and quite different) pros and cons in relation to each other. I quite honestly can't say which one has the edge here, although in general ARM is a much more fun ISA.