Developers wanted for PCSX Revival!

[squall_leonhart]

Ok, im looking to organise a revival of PCSX, Code will be stored on a googlecode svn, and im looking for any interested developers, since im more a project manager and code tinkerer, than active developer.

Project Page is at http://code.google.com/p/pcsx-r/

Anyone interested Reply here.

PS, no "Can i beta test" posts here please, releases will likely be made when code is stable and enough noticeable changes have been made to deem it worthwhile.

[d0u6]

Hi.

Well, I'd like to join in your group. I'm implementing a Game Boy and a Genesis emulator, but I could start this project too.

Do you have some documentation about pcsx?

[MasterPhW]

It's nice to see the revive of PCSX and wish you the best with the project. Hope you'll find as much developers as the dolphin emu and PCSX2 playground had found.
I'm more of a silent dev and my code style is utter ugly, so I won't be a big help at all. And I'm more of a contributor and tester than a coder of big projects like this.

[MasterPhW]

Sorry for doubleposting, but it would appear as a new post, when edited:
New versions of PCSX Rerecording were released lateley, probably you will get them to join the team of the new project.

[Cyberman]

I forgot about this

I may be able to put some time in this don't know yet, or at least a new port (ARM 8x / EGL2.0 Beagle board)

Well a suggestion is to post change logs.

A few thoughts,

1. you don't have to use .kapture to record AVI's if you copy the context data emitted by the GPU plgun afterward into a format CODECSs the user has in the machine can use.
2. The container format can be anything thing you just need to spit the output of the CODEC into a properly formed file.
3. Sound also needs dumped into a CODEC as well. Same deal only an internal plugin is probably a better option for that.
4. I'll have to look at the code changes to see what would be needed to do these likely, what is the source version used for this?

Phw isn't this technically a thread jacking?


Cyb

[AamirM]

Why does it needs reviving? I thought PCSX was already prefect. I would be interested but I have too slow internet .

[Cyberman]

Too slow of internet for what? The PCSX source is kind of small so it's not like you would be downloading inordinate resources. The big issue is having the same build system between users.

Additionally there are some things that would be good to add to PCSX unfortunately those things aren't simple to add.

Cyb

[squall_leonhart]

Why does it needs reviving? I thought PCSX was already prefect. I would be interested but I have too slow internet .

1.5 Final, is alot slower then it could be, it also doesn't handle CDR plugins which can read subchannel data properly, and there are freeze issues in certain games due to what i think is read from memory issues.

[Cyberman]

It may be interesting to redo the dynamic recompiler in PCSX ... well actually modify it to one that is more generic.
If you are familiar with compilers they have a back end that has emitted pseudo code.
Ex:

L_495:
DEC VAR_3, BRNZ L_495

May come from

while(--counter);

Notice DEC (obviously decrement) and BRNZ (Branch if not zereo) are on the same line. This can be interpreted as "if there is a command that does a decrement and branch if not zero". It may end up being done as

dec EAX
jnz $-4

or something else depending on that TARGET archetecture.
That's also the case with dynamic recompilation. If you can create an intermediate pseudo code that can be recast into native codes (IE the pseudo code was DEC VAR_3, BRNZ L_495 which became dec EAX, jnz $-4), then some real time optimization can be done in addition it also means that porting the DREC to other archetectures is quite possible.

I might also point out it is unnecessary to create more text to process with the pseudo code (unless you want to debug the DREC) and the actual raw data is more use able (especially if you want to perform optimization passes on the emitted code).

Cyb

[Exophase]

Intermediate code is sometimes one of those things that people do because other people are doing it. The big wins in doing it are either when you're going from many possible targets and want to unify it to one representation or you're going from a complex target and need to break it down into a simple one so you can convert it generally. In this case the only target is MIPS and MIPS is already very simple (you won't get much simpler). Some additional metadata doesn't really hurt (like for constant propagation and register liveness/usage) but you can append it to the MIPS code without converting it to anything else (and PCSX probably already does).

There are actually already implementations of PCSX's recompiler that don't target x86, although I'm not sure if the mainline source incorporates them.