pspe4all announced

Since rewrite of pcsp has gone further than we expected , and the resulting emulator has nothing to do with the old one , for avoiding confusion between old and new pcsp we decided to rename new pcsp to pspe4all.You can find the new site here : www.pspe4all.com

Old pcsp site will still be online to d/l older versions of the emulator. There might be some update to latest 0.5.4 release as well

PCSP v1.0.0 preview 1 (revision 1833)

As we already promised , pcsp is not dead , still it has been rewritting all these past months. We had some major bottlenecks in our previous implementation of pcsp and with the knowledge we have gained from our work on pcsp , we are here to present the new pcsp :)

For all that wondering is pcsp playing commercial games , the answer is NO AT THE MOMENT , but we are getting closer.

All parts of pcsp have been rewritten from scratch and some of them already show better results than previous pcsp implementations.

So far only homebrew are working but soon , we will probably have some progress on commercial games.

For now , i am posting only screenies from Nesterj (a nes emulator for psp) . Games are 100% playable (no sound yet ) . Soon or later there will be more status progress on pcsp so stay tuned :)

PCSP v0.5.4 released

Althought we have already announced the total rewrite of pcsp from scratch to provide better support (some parts was really bad in pcsp) , this is the last release of pcsp based on old source.Be warned this version isn't supported from pcsp team since we have moved our effords to the new pcsp rewrite. It is also quite possible to see a preview of the new pcsp in a few days , but also be warned that new pcsp doesn't run commercial games yet.

So what's new on this release. Basically a batch of features like:

General-----------Experimental Dynamic shaders . A lot faster works in a few demos – use it at your own riskAdded VEH handler for win32New portable fiber implementation for win, linux and macosx 32/64-bit.GLEW is now used instead of GLEEBetter thread behavior for KernelVsyncFix a bug with opengl renderer when trying to unbind a shader program never bindedHLE----Implementation of sceRtcSetDosTime ,sceRtcIsLeapYear ,sceRtcCompareTickImplemented adding of ticks. (11 syscalls)Fix sceRtcGetCurrentTick()Fixed sceKernelLibcTime()Implementation for sceKernelPollSema()Fixes in KernelEventFlagadded loading of files after resetting emu. (sceKernelLoadExec case)Improved and refactored module management code into sceKernelModule.Started implementation of restarting features for PCSP.Partially implemented sceKernelLoadExecGE---Partial implementation for CMD_SIGNALFixed pc address and stall addressAdded LogicalOperation, corrected StencilTestCMD_TLEVEL was wrongImplementation of spline decodingfix LOD issues in micromachinesfix a bug with DXTn compressed texturessound---------sceAtrac3plus: source cleanup

PCSP v0.5.2 released

Actually this is mostly a bug fix release for single core cpus. As already explained in previous post there was a bug in audio that was preventing pcsp to work on single core cpus. Now it should work okay.

Besides that this release also offer decryption of encrypted PSP games on fly!. That's right you don't need to decrypt your PSP games in order to run or use external eboot.bins. Just remember to enable the decryptor in settings dialog and everything should decrypted on fly!.

Here is the complete changelog:

Fix a bug in audio that was preventing single core cpus to run (now they should work fine)

Added PRX1-PRX2 decryption. Now you can run encrypted games without the need to provide external decrypted file. You need to enable the Decryptor in settings in order to use it. (Settings->Settings->Hack Settings->Enable Decryptor)

Some issues with pcsp v0.5.1

It appears there is a bug with pcsp and single core cpus. It is very likely that pcsp will freeze from parallel threads that it tries to syncronize. There is already a fix for that for all you ppl that still using old machines with single core (who does anyway).

A bug fix version will be release shortly among with a very interesting feature.

Stay tuned :)

--------------------

Hlide here again,

Ok I think I understand what it happens. The emulator has a state : normally it is RUNNING when interpreting a PSP game. Some events like Audio, Vsync, Clock may occur and try to set this state to an event state so the emulator thread is leaving the interpreter to handle the event. In a multi-core processor, each event has its time-critical thread running on one core whereas the emulator thread is running on another core. So a core tries to set a state to make the other core to suspend interpretation and handle event in the emulator thread. I made some changes in code prior the correction I did for 0.5.1 because I feared an event state might be set when the emulator was already set to another event set (a vsync event occuring when the emulator state is set to an audio event state) and might fix the freeze issue. It didn't but I left this code after fixing the real issue. However I never realized that code might not work properly for a mono-core as those threads will be executed in a sequential order and might create some hell slowness or worst responsiveness (because of an active polling added).

PCSP v0.5.1 released

A new minor version is here. Don't expect too much updates , the most important ones are the fix of freeze bug when you use vsnyc limiter and better opengl extension detection. Also for older cards there is software emulation of some OcclusionQuery where this is not available.

Here is the changelog------------------------

General------------ added gl_Core : now occlusion_query, vertex_buffer_object and framebuffer_object are now correctly detected to fill core functions if not- added a software version of BBOX in gl_OcclusionQuery- correct handling 32-bit overflow of timer seems to fix the "freeze" bug with some games when vsync is ON

Issue with VSYNC limiter ON seems to be gone at last!

Hlide here again.

You probably read an old post where I stated some games might randomly freeze when vsync limiter is ON. I must admit I was completely unmotivated and didn't make any progress until I decided to get back to pcsp development today and finally pinpointed what I think to be the cause. Vsync thread uses a timer to emulate a vsync event at 60 Hz. But the timer (windows has a 32-bit timer) handled uncorrectly a 32-bit overflow. Superfruit game was always exhibiting this issue when this overflow occured. Superfruit game now plays fine with vsync limiter ON.

As a result, a minor version may be released soon - or a major version if EBOOT decryption is added in the month.

So what's up after 0.4.0 ?

Although dev is a bit slow these days (we all wait christman's holidays to code ;D )there are some fixes on pcsp after 0.4.0

Many users reported an issue about their Opengl missing extensions , so a software version of OcclusionQuery has been added.Also a new way to detect Opengl extensions added so pcsp now handles more flexible the detection.

There are also some tries to make pcsp to work on Linux and macOS but still not major success.

Stay tuned for more news and who knows we might release a fix version for christmans :)

Confusion about version numbering

I read some posts where people are confusing by having pcsp-udb v0.4.0 and pcsp v0.3.0 and I am pretty sure it will be the same for pcsp-udb v0.5.0 and pcsp v0.4.0.

So we decided to change it this way :

- any changes done in pcsp-udb will be released with the svn revision as version- if a new release of pcsp vX.Y.Z is out, a pcsp-udb will be released as pcsp-udb vX.Y.Z, that is the same version as pcsp since most people seem to think this way.

So yes, pcsp-udb v0.5.0 is an issue.

So the next release will be 0.5.1 (minor fix) or 0.6.0 (major evolution).

PCSP v0.4.0 - vsync limiter on may freeze some games

Hlide here again !

Ok, Evangelion doesn't run anymore. I guess the addition of Audio and the changes in threadman are probably for something. In fact, I suspect some games were able to run in a very hacky way because the thread scheduler wasn't playing its role properly and so some waiting threads were awaked even if their waiting condition wasn't met. And it could also explain why this game was so slow.

A new vsync limiter was coded using a time critical thread to wakeup any psp threads waiting for a VSYNC event. It is a cleaner way to limit FPS to 60. A change in threadman was necessary to make it work.

An audio implementation based on PortAudio with its own time critical threads to play audio samples also needed a change in threadman.

As a result, you may really need a multi-core to keep a smooth running pcsp.

Beware, this version is very experimental : if you have some games which ran fine and have a freeze ingame with this release, try to disable vsync limiter and relaunch pcsp to check if it occurs again. There are probably issues with inter-thread synchronisations and they are very hard to spot. A new minor release will be out as soon as a fix is found.