PCSP v0.5.1 released

[shadow]

A new minor version has just been released. 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

You can d/l pcsp from the following link:
http://www.filesonic.com/file/65106073

A version with pcsp-udb (the pcsp frontend) is also available from the following link:
http://www.filesonic.com/file/65106077

[Kai3213]

Kind of an odd bug, every time I load up v0.5.1 my cpu usage shoots up to 100% and everything freezes until I somehow manage to close the emulator. Didn't happen in version 0.4

[hlide]

Kind of an odd bug, every time I load up v0.5.1 my cpu usage shoots up to 100% and everything freezes until I somehow manage to close the emulator. Didn't happen in version 0.4

can you give more details about your hardware ?

[Kai3213]

Kind of an odd bug, every time I load up v0.5.1 my cpu usage shoots up to 100% and everything freezes until I somehow manage to close the emulator. Didn't happen in version 0.4

can you give more details about your hardware ?

AMD Sempron Processor LE-1300 2.30 GHz
1.25GB of DDR2 Ram
Nvidia GeForce 6150SE nForce 430 adapter with 447MB Total Memory
Windows Vista Home Basic 32bit

[hlide]

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 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), so in 5.1.0, i changed into something like that :

Code:

step 1:
    lock mutex;
    if emulator state is RUNNING,
        set emulator state to event and unlock mutex;
    else
        unlock mutex and repeat step 1;

it didn't fix the freeze issue but i left this code. 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 slowness or deadlocks indeed.