The return of the Commandline!

After its absence for many moons, the Commandline functionality will finally be restored to PCSX2. Third-party frontend and config-manager authors rejoice! ... and hopefully stop hating my guts, too.

To paraphrase Darth Vader: "Witness the power of this fully armed and operational Command line-driven battlestation."

(we all know a command line-driven death star would have been way cooler than some click-and-drag crap.)

The new PCSX2 command line should be functional in our next beta release, which should be out pretty soon, and it will work as follows:

Syntax: pcsx2 [IsoFile] --toggle --option=value ... etc

• IsoFile - optional ISO image to load and run on startup; uses the PCSX2 internal ISO loader.

General Options :

• --cfg=[file] {specify a custom configuration file to use instead of PCSX2.ini (does not affect plugins)}
• --cfgpath=[dir] {specifies the config folder; applies to pcsx2 + plugins}
• --help {display this help text}
• --forcewiz {forces running of the First-time Wizard (selection of docs folders and what-not)}

Auto-Run Options :

• --elf=[file] {executes an ELF image}
• --nogui {disables display of the gui on exit (program auto-exits)}
• --nodisc {boots with an empty dvd tray; use this to boot into the PS2 system menu}
• --usecd {uses the configured CDVD plugin instead of IsoFile}

Compatibility Options:

• --nohacks {disables all speedhacks}
• --gamefixes=[fix,fix] {Enable specific gamefixes for this session. Valid fixes in 0.9.7 are: VuAddSub, VuClipFlag, FpuCompare, FpuNegDiv, XGKick, IpuWait, EETiming, SkipMpeg }
• --fullboot {disables the quick boot feature, forcing you to sit through the PS2 startup splash screens}

Plugin Overrides (specified dlls will be used in place of configured dlls):

• --cdvd=[dllpath] {override for the CDVD plugin}
• --gs=[dllpath] {override for the GS plugin}
• --spu=[dllpath] {override for the SPU2 plugin}
• --pad=[dllpath] {override for the PAD plugin only}
• --dev9=[dllpath] {override for the DEV9 plugin}
• --usb=[dllpath] {override for the USB plugin only}

SPU2 is more than just sound!

The SPU2 is the Sound Processing Unit for the Playstation 2, and works a lot like the sound card in your own PC; albeit still quite unique in its approach to mixing sounds/voices and the programmable interface it provides for that. But the SPU2 is more than just sound. It's one of the more reliable timing mechanisms on the PS2 and games tend to use it as such. Without at least basic SPU2 emulation, no games will boot at all. This isn't too surprising if you understand how console hardware typically works, but what might be surprising is realizing how many games won't boot even with what appears to be fairly competent SPU2 emulation.

Until SPU2-X 1.4, no SPU2 plugin had gone the distance on implementing IRQs (Interrupt Requests). IRQs are scheduled via specific SPU2 memory addresses. When a marked memory address is accessed anywhere in SPU2 memory (either read or write), the IRQ is signaled to the IOP. The most important IRQs on DMAs and audible voice playback have been supported for eons; without these no games would boot, period! Meanwhile, many of the lacking IRQ checks were known, but glossed over because of overhead required for the checks (a couple other checks were simply overlooked). The three main culprits for causing emulation errors were as follows:

1) the "free run" feature of SPU2 voices.
2) the write-back areas for each core's mixed output.
3) Reverb Processing, which uses a series of overlapping buffers to generate feedback.


Free Running Voices

The SPU2 has 48 total voices (24 voices for each core), plus two dedicated streaming audio input sources. Each voice can play a sound effect or stream audio, and can either be stopped, looping, or 'free running.' Free running voices typically zero out their volume rather than stopping or looping, and continue to 'play' forever (albeit silently). These free running voices access inaudible areas of SPU2 memory and thus trigger IRQs unexpectedly -- except, of course, some games are cleverly designed to expect these unexpected IRQs!

Because of the overhead required to free-run otherwise silent voices, all other SPU2 plugins (until now!) have opted to ignore processing them. This is the feature that fixes Fatal Frame 2 (Project Zero 2) and a dozen more games.

Output Write-back Areas

The SPU2 defines a handful of special areas of memory where it writes back sound data at various stages of the mixing process. It's perfectly legal for a game to set an IRQ address within these buffers, and then expect it to trigger when the SPU2 does its write-back to that address. The write-back areas are mapped as follows:

In specific, some games set an IRQA for Core0's write-back area. The IRQ can either be used as a timing mechanism, or as a synchronization point for post-processing audio effects. Most SPU2 plugins properly handled the write-backs, but overlooked the necessity of doing IRQ checks for them.

Reverb Processing

The SPU2 employs a clever reverberation algorithm that utilizes multiple overlapping read and writeback buffers within SPU2 memory to generate feedback. Each step of the reverb process accesses memory and must test against the IRQ address; for a grand total of 24 IRQ tests per Core. Fortunately, all reverb activity occurs within a specified area of SPU2 memory, so for most games a single simple test can be used to exclude the IRQ test.


And It All Applies to SPU2null!

This is the boring part that I'm going to look to implementing soon: In order for SPU2null to be fully emulation-compliant, it must properly simulate all of these things, which basically means it needs to have a complete sound mixer implemented; including reverb buffering/addressing logic. It probably seems silly, but SPU2null would still be without any platform dependent code or sound drivers, making it an ideal base for emulation analysis and as a base for future plugins.

Introduction to Dynamic Recompilation

This blog post is an introduction to dynamic recompilers (dynarecs), and hopes to provide some insight on how they work and why pcsx2 uses them to speed up emulation.
It is probably easier to read on our forums, because some of the code didn't wrap nicely on our main blog page....
(Click here to view blog post in forum)

To first understand why dynarecs are useful, you must first be familiar with a basic interpreter emulator.

Read more: Introduction to Dynamic Recompilation

A new kind of fullscreen!

One problem that has plagued PCSX2 since as long as most anyone can remember is it's general inflexibility and instability when flipping between windowed and fullscreen modes. This was something we really sought to address as we re-write the user interface in 0.9.7.

In 0.9.6 the situation was grim: The flip never really worked right in DX9 -- there's an "escape hack" that completely shuts down the emulator just to flip out of fullscreen mode. Hitting alt-enter is usually less forgiving (the plugin handles it, and doesn't allow PCSX2 to completely shut everything down and restart). In DX10 things were better: alt-enter typically works a couple times, but do it too often, or get an unlucky flip, and it'll still result in lost or corrupted video and possibly a crash depending on video drivers and (lack of) luck.

In 0.9.7 we've completely re-done our approach to fullscreen. Instead of using what Microsoft DirectX calls Exclusive Mode (you can read about the programmer-centric details of it here), we're taking a more modern approach and using a special type of maximized desktop window instead. Like anything there's some advantages and disadvantages to this new approach:

Advantages of the new fullscreen method:

• Works perfectly in DX9 and DX10 alike.
• No more risk of visual corruption or crashes, and no need to shutdown the emulator to avoid them.
• Much faster and seamless flips.
• Works with any GS plugin, regardless of how the GS plugin is implemented.
• Always uses your LCD display's optimal resolution (assuming you have it set in the desktop as such, and you should).
• Integrates better with your desktop -- Alt-Tab, TaskBar, popup errors, etc. are much less prone to being... annoying. (pulling up a strategy guide in a browser window, for example!)
• Super-easy to implement, from a programming perspective!

Disadvantages:

• A slight bit of extra window management overhead.
• Always uses your desktop resolution on CRT displays (this is an advantage for anyone with an LCD display, but can be a disadvantage for people with CRT displays, depending on your setup .. however few of you are left)

The performance benefit of exclusive fullscreen is mostly related to Aero under Vista/Windows7. in which case the performance is sometimes better in a window over exclusive mode (this depending on video card/drivers/etc).

The thing that really sold us on it though is the fact that overhead of the non-exclusive fullscreen mode is minimal on modern GPUs. The only real advantage of using exclusive fullscreen is that it bypasses Aero and increases the "multimedia priority" of the app. If you already have Aero disabled, then neither of those apply anyway. And looking toward the future: the next generation of GPUs will reduce that overhead of Aero even further to the point where even that will likely not make a significant impact on performance. So the idea of a seamlessly working fullscreen flip for all DirectX incarnations on all incarnations of Windows over a rather iffy, unstable, and fragile fullscreen flip that might be 2-3% faster on legacy hardware ended up being a no-brainer.

We're still leaving the door open for adding optional support for exclusive mode fullscreen, since there could still be some use to it for special scenarios like CRT displays and TV projection; though there's no timetable for the implementation of the option -- and it would depend on the GS plugin to support it properly otherwise it'll still be the corruption/crash bomb that it's always been up to now.

Global Visitor Stats

Wondering about who's watching as we make and break bleeding edge alpha/beta versions of PCSX2? I do! Here's a map representing the visits to our SVN repository at Googlecode, for the past 2 weeks.



On average, our SVN totals per day:

• 900 unique viewers
• 3,200 visits (3.5 visits per viewer)
• 9,500 page views in total.

Top visitors by city:

1. Sapporo 171
2. London 165
3. Tokyo 151
4. Shanghai 147
5. Moscow 142