News via http://www.pcsp-emu.com/news.php?readmore=44#comments

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

Shadow and Hilde have released a new version of the most advanced PSP Emulator for Windows, heres the release news:

And here we are! I new release of pcsp is here and as always new features! . PCSP v0.4.0 supports OSK keyboard , MessageDialogs , complete new Save system that works with many games anddddd partial implementation of sound

Here is the complete changelog:

General
-----------
- Fixed a bug in PSF reading.
- Fixed refer ms free size command in sceIoDevctl and implemented a basic Memory Stick manager
- OSK implementation
- sceMsgDialog implementation
- Total rewrite on save system. Now it supports save modes 1,2,3,4,5,8,12,13,14,15,16,17,18,22. List Save and List Load dialogs are working too as well.
- Loader now loads ms0 device in UMD mode
- IoFileMgrForUser getStat now scans for files and dirs as well before return an error
- memstick statfile can now fill scePSPDateTime struct with proper values
- Memory: pcsp was crashing when accessing the end of psp vram

GE
---
- NREV implementation was missing for OpenGL version w/ shader
- GE - vertex shader : attempted to get a more accurate shade mapping
- Fixed lighting in many games
- sceDisplay/sceAudio: a new vsync thread which allows to limit fps to 60. No more need for the hacky opengl vsync anymore.

Audio
--------
- Implemented most of sceAudio functions.
- Implemented partial scelibSasCore. Some games now have sound effects some others get bad sound
- Implemented sound output using portaudio API.

You can d/l pcsp from our download section or from the following link:
http://www.filesonic.com/file/36569781/pcsp v0.4.0.zip

http://www.filesonic.com/file/36529005/pcsp v0.4.0+udb.rar

Remember to post your screenshots on pcsp forum at :

http://www.emunewz.net/forum/forumdisplay.php?fid=48

Enjoy
The PCSP team

http://www.pcsp-emu.com/news.php?readmore=43#comments ...

News via http://www.joystiq.com/2010/11/27/am...h-150-psp-gos/



If you didn't manage to snag a PSP "3-Game Digital Pack" at your local retailer yesterday, Amazon's offer of a $150 PSP Go -- lasting until "Cyber Monday" -- should help mend your broken heart. If Sony's digital-only handheld doesn't get you going, perhaps the site's other Cyber Monday deals will? You can find all the specifics after the break.
Consoles:

PSP Go (Piano Black): $ 149.00, from 11/25/2010 - 11/29/2010
PSP Go (Piano White): $ 149.00, from 11/25/2010 - 11/29/2010

Games:

America's Test Kitchen: Let's Get Cooking: $8.99
Dragon Quest IX: $19.99
Kung Zhu (Nintendo Wii): $14.99
NBA 2K11 (PS3 and X360): $29.99
Pokemon HeartGold: $24.99
Pokemon SoulSilver: $24.99
Professor Layton and the Diabolical Box: $17.99
Professor Layton and the Unwound Future: $17.99
Spider-Man: Shattered Dimensions (Nintendo DS): $9.99
Zhu Zhu Pets: Wild Bunch (Nintendo DS): $14.99

http://www.amazon.com/exec/obidos/AS...kiangagenew-20 ...

Sony announced this week that BBC America programming is heading to PlayStation 3's across the United States. To kick off the new partnership, BBC America has made the first episode of the American version of "Top Gear" available at no charge (normally $1.99 for SD, $2.99 for HD), at least for the first two weeks. "Doctor Who" and "Being Human" will join "Top Gear" on the network's launch list at some point in December, and BBC America promises to "rapidly add BBC programming each week, including the best of the BBC's library as well as currently airing series."

As you've likely already guessed, the BBC's offerings can be found in the video section of the PlayStation Store starting right now.

http://www.joystiq.com/2010/11/27/bb...ilable-on-psn/ ...

Kinect had what most people would call a successful launch, moving over one million units worldwide during its first week on store shelves; however, the device wasn't met with quite as warm a reception in Japan. According to Media Create, Microsoft's new all-seeing eye had a "quiet start" in the region, moving just 26,000 units during its launch weekend of November 20 -- that includes both standalone and 360-bundled Kinects.

Also troubling is that no Kinect games made it onto Media Create's Top 20 software sales chart. The highest-selling launch title was DanceMasters, which managed to sell 6,000 copies. On the other hand, four PlayStation Move launch titles made it onto the Top 20 during the controller's launch week, with a combined total of 50,000 copies sold. There's a lot of factors at play, here -- the data coming from a two-day period, the lower install base for the 360, and so on -- but Microsoft's going to have to make a concerted effort if it wants to get the peripheral off the ground in Japan.

http://www.joystiq.com/2010/11/28/ki...aunch-weekend/ ...

News via http://emu-russia.net/en/

- For Dolphin(DX10/DX11 Only): Buildin a filter to simulate YPrPb colors
- For PCSX2: Buildin Filter to simulate YPrPb/YCrCb colors. And added some stuff to adjust saturation,Bright and contrast.

News source: http://gens32.emubase.de ...

News via http://emu-russia.net/en/

- For Dolphin(DX10/DX11 Only): Buildin a filter to simulate YPrPb colors
- For PCSX2: Buildin Filter to simulate YPrPb/YCrCb colors. And added some stuff to adjust saturation,Bright and contrast.

News source: http://gens32.emubase.de ...

News via http://emu-russia.net/en/

CaH4e3 posted new screenshots of Dirty Pigskin Football (Atomiswave) emulated in Demul.

News source: http://forum.emu-russia.net/viewtopi...p=13475#p13475 ...

More news from Pate of his work on the Dos emulator for the DS:

After posting my previous blog post, I got an email from Grégori Macário Harbs, who said that he is interested in screen scaling and interpolation algorithms, and has some ideas to share. He suggested a more efficient division of the pixel weights when interpolating over 5 input pixels to produce 4 output pixels. He had even gone so far as to provide an example of how the WC2 title screen would look with different interpolation methods, and he also provided some source examples. Many thanks for the tips Grégori!

Using the ideas that he provided, I was able to make the DS2x86 interpolation algorithm much faster, and also improve the quality. The new algorithm converts the first 4 input pixels with 75%/25%, 50%/50% and 25%/75% weighting to 3 output pixels, and the fifth input pixel is directly output as the fourth output pixel. Since the 25%, 50% and 75% values can be given as 1/4, 2/4 and 3/4, they are much simpler and faster to calculate than my original 80%, 60%, 40% and 20% weights.

Some other ideas that I learned from him for future use is the possibility to precalculate the weighted palette values beforehand, which would be especially useful when interpolating the 16-color modes, and the fact that bilinear interpolation of the Mode-X 320x240 screen is actually 5/4 interpolation on both axis. Neither of these I have implemented yet, but I am looking forward to when I have time to implement and experiment with these. Here below are the screen copies from my original interpolation algorithm (on the left) and the new improved algorithm (on the right). I think the new image looks noticeably sharper with fewer artifacts.


Audio work
By the end of last week I had gotten the new screen interpolation working, so I finally looked into DSTwo SDK audio support. I studied the example provided with the SDK, and then began to look into ways to implement that in DS2x86. Compared to the audio features of Nintendo DS itself, the audio support of the DSTwo SDK is very limited. It only supports one 16-bit stereo audio channel, which can run at 11025, 22050 or 44100 Hz. In DSx86 I had allocated one separate 8-bit audio channel to the SoundBlaster digital audio, one PSG audio channel to the PC speaker sounds, one 8-bit audio channel to the Covox or SB Direct DAC audio, and 9 separate 16-bit audio channels for the AdLib emulation. Packing all of these to the single stereo channel will be quite a challenge.

In DSx86 I coded the audio support so that it will be as close to the x86 method as possible. The game running in the main emulator will send the audio command bytes to an I/O port, which then get sent to the ARM7 side using the FIFO mechanism. The code running on ARM7 then interpreted these bytes (like it was the actual SoundBlaster card) and performed the proper operations. Now in DS2x86 I have to use the same CPU for both running the main emulation and handling the audio emulation.

I decided to start with the simple case of trying to get the SB digital audio channel working. I still used Wing Commander II as the test bench, as it plays speech during the game intro. In DSx86 I could run the separate audio channel at whatever frequency the x86 game requested, but now I needed to select one of the supported frequencies. I decided to go with the 22050 speed, as I thought that going to the full 44100 Hz will slow the emulation down unnecessarily. Since the input audio is 8-bit and I need to convert it on-the-fly to 16-bit and use interpolation to adjust the playing frequency, the quality will be pretty poor in any case, so 44100 Hz will certainly be overkill.

The SDK example had no timing features, it just used a spin loop to check when the audio buffer is free to handle the next block of the WAV file. It was not quite clear to me how the audio buffer interaction works, and whether handling the buffer filling in a timer interrupt (like in my screen handling) will work, so I spent quite some time experimenting with different methods of filling and swapping the buffers, with different buffer sizes. I need to have a timer interrupt running at 60Hz, so that I can use it to handle screen refresh and vertical retrace signalling to the x86 game (many of which sync to the screen retrace signal). I wanted to use this same interrupt for the audio buffer filling, mainly so that the screen contents sending and audio sending from the MIPS side to the ARM side do not conflict with each other. There are some difficulties syncing this 60Hz timer with the buffer filling, as there are three different buffer sizes that need to be taken into account. The ds2 audio buffer size needs to be divisible by 128, the number of samples played during each 60Hz period is 22050/60 = 367.5, and the third size is the DMA buffer length that the x86 game (in this case Wing Commander II) uses. In WC2 the buffer is 4000 bytes (not 4096 bytes), and the frequency it uses is 10752 Hz, so that each 4000-byte x86 ...