This begins a series of blog posts intended for ps2 developers and ps2 emu authors. Its purpose is to give some light to some of the secrets I've learned about the VUs while developing my mVU recompilers, and to describe what happens in situations that are a bit questionable.
In pcsx2's advanced options dialog (if you've dared to look), you've might have noticed there's "FPU Clamp Mode" and "VU Clamp Mode" settings. You may even have experimented with some of these modes and found out they fix or break games. But what are they doing? And why so many options?
One of the first things I sought to do when I first started contributing to PCSX2 was to improve the emulator's overall stability and error handling; and to this day it's still one of my top priorities.
If you'd like to make comments or ask questions in response to a devblog entry you can now do so from the PCSX2 Public Forums . Yes, unlike some frivolous free-for-all blog with a thousand disgusting comment spams, our DevBlog requires that you must be a registered user and logged in to post.
As most of you know we use Google Code for our Public SVN repository, and doing so has its pros and cons.
One of the major changes planned for the next release of PCSX2 is a complete overhaul of the gui/frontend, switching from the current "native" Windows/Linux interfaces to a single unified interface that's (more or less) the same for both platforms. To make such a grand vision possible we needed the help of a third party gui tooolkit, from which there were several to choose from. After much consideration we settled on wxWidgets , which is the same toolkit used by a few other notable emulators, such as Dolphin .
While not likely to win the prize of being featured in PCSX2's next release (presumably 0.9.7, but you can never be too sure), this logo might deserve honorable mention. I present for you a moment of Zen:
There are a lot of buzzwords in emulator recompilation. Popular ones include:
One of the less obvious things that has plagued Pcsx2's compatibility over the years is its event handling system. The system in place as of 0.9.6 is adequate for interpreter-based emulation but is not well-equipped to handle the methods that a recompiler uses to manage cpu cycle updates. This is something we aim to fix in the coming weeks.
Zerofrog documented the concepts of Virtual Memory a few years back. So now I figure it's VTLB's turn, since it's the new exclusive memory model used in current AVNs and any future releases.