What's new

Developers wanted for PCSX Revival!

squall_leonhart

The Great Gunblade Wielder
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

New member
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

Master of the Emulation Flame
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

Master of the Emulation Flame
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

Moderator
Moderator
I forgot about this :D

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? :D


Cyb
 
Last edited:

AamirM

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

Cyberman

Moderator
Moderator
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
 
Last edited:

AamirM

New member
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.
You didn't get it :D . Oh well, I need to dig out my PSX CDs and try this thing. The last PSX emu I used was Bleem O_O . And I remember it displayed the games better than they did on the real thing (now I can't remember that game, I think it was The Mummy).
 

Cyberman

Moderator
Moderator
I used Bleem when it first came out just to see what it would do. I used it on Chrono Cross I believe. I freaked out a bit because I said "holy frijoles!" when I saw CC in my old 300mhz P2 machine.

PCSX is actually fairly good you can run most of the PSX games with it.

I was researching modifications to the GTE engine it had in combination with a modified GPU plugin.

Cyb
 
OP
squall_leonhart

squall_leonhart

The Great Gunblade Wielder
Cyberman, thats what the SVN is for, lol. keeping the source updated between the devs.

the 1.6 source needs some work though, sure, it compiles, but it barely works.

There are fixes in the PCSX2 source which might be backported to pcsx as well.
 
Last edited:
OP
squall_leonhart

squall_leonhart

The Great Gunblade Wielder
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

Moderator
Moderator
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:

Code:
L_495:
DEC VAR_3, BRNZ L_495
May come from
Code:
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
Code:
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

Emulator Developer
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.
 

Cyberman

Moderator
Moderator
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.
Yes I noticed that, however I haven't seen there branch information. I'm looking to port it to the OMAP3 processor, but by creating intermediate code there is more going on than what you think. In reality I want the intermediate code for tagging information for the GTE coprocessor in a more generic manner. I suppose the best way to look at it is I want to deal with the 3d data and the 2d data that is generated from it in the perspective transform functions in the GTE. I want to track the 2d data to it's texture offsets, thus getting the offsets used in textured polygons and there associated 3d data.

Cyb
 

zodttd

New member
Hello! I have been working with PCSX code for awhile now. I have added an ARM dynarec to it, modified some of the CDR code, and others hae chipped in with a completely custom software GPU rasterizer. The SPU has also been tweaked. It's no longer "plugin" based as everything is linked in as I had felt that was better for handhelds long ago when I started things.

Of interest, I have it running on the OMAP3 EVM as well as the Pandora handheld which is OMAP3 based. It runs great but could use improvement and polish.

It runs Ridge Racer 1 (notoriously slow) at 60 FPS with sound on the Pandora clocked at 800MHz when scaled to ~800x400. When outputting to 320x240 and letting the hardware scaler be used we can get down to the 600-700MHz mark.
Many other games are just fine at 600MHz.

A good friend of mine, Tinnus is writing an OpenGL ES 2.0 GPU for this as well.

The code is very ugly at this point and the GTE suffers. It could use some NEON instruction treatment it seems. If you are interested in helping, I would be glad to return the favor. :)

So this revival has already started in some aspects with my lil psx4all project here. I've been keeping quiet about going back to PCSX code for portions of the Pandora release, though plan to open source it as expected once it is made public.

Thanks for the heads up on this thread Exophase. ;)

If I could gather some greater minds to make this code faster, cleaned up, and more compatible (very interested in that subchannel issue for instance), I'm up for it.

Thanks,
ZodTTD
http://www.zodttd.com
 

Cyberman

Moderator
Moderator
If you are using linux jettisoning the plugin interface isn't needed, however if you believe it is a performance issue, then I can see. The pandora isn't my cup of tea, but I am working on the beagle board (have system have tools waiting on pico projector and time) which is the same processor just less RAM and NAND (128M and 256M respectively). Right now I am working through ideas and structure, scripting a road map to walk and improve the base PCSX code with. There is the neon but TI has that nifty DSP in there as well (audio/video stream processing) so many neat toys so little time.
As said I would like to work through the theory first before tackling it with a hurculean effort (lots of dumb work LOL). Small changes to the base code is my first aim. I've set up QEMU on my windows machine for doing the cross compilation (weird emulating a linux system on windows to develop for .. Linux).
Erstwhile the work should be usable with PC and OMAP. Did you change the general function of the DREC system or merely change the code emitted? Is it like the modular approach in the original PCSX code (SH4/ix86 directories for there DREC location).

Cyb
 

Cyberman

Moderator
Moderator
SquallLeonhart
what is your compiler setup for the PCSX-R variant of PCSX?
I'm trying to sort things out on my end and I have too many possibilities so the simplest things for me is to follow something straight forward (I am not into collecting tools I have too many as it is).

Cyb
 

Top