Debug PlayStation3

Since I did a similar post for the Xbox 360 XDK a while back and since this is intended to be mostly a developer-oriented blog, I thought it would be in keeping with that spirit to let people have a general idea of what to expect from a debug PS3 – which recently arrived.

Photo album: All of the screenshots linked to below (and more) can be viewed separately in this photo album here.


There are some limitations as to what you can do with regards to profiling – even on a Debugging Station. Code instrumentation through gcov is entirely possible, but this was not very appealing to me anymore given that we have been able to do this more or less even on Retail with Themaister’s net-stdio implementation. Gprof seems to have been made unavailable as Sony started moving more and more away from the open source GNU toolchain they originally based their development environment on. What’s left is a proprietary profiler that will not work on Debugging Stations but requires a Reference Tool instead – it has 256MB extra main RAM, bumping up the main system RAM in total to 512MB (plus 256MB RAM for the RSX) – which, together with the unit’s Communication Processor, gives it the extra horsepower it needs to do real-time profiling on-the-fly amongst some other things like realtime video capturing and graphical analysis through GPAD – which I’ll touch on in a moment.


A very nice feature which seems to be only available on debug PS3s is the ability to run code with an RSX profiling tool called ‘GCM HUD’. As the name would imply, this is a Heads-Up Display overlaid on top of the application you’re running that neatly provides you with a point-and-click interface giving you access to features such as as:

  • Fragment/Vertex program debugger (with the ability to set breakpoints and step through the code line by line from the console itself – with no PC having to be involved or connected to the PS3.
  • RSX Performance Counters (telling you how effectively you’re utilizing the RSX).
  • RSX Command Buffer log (showing you the workload of the RSX in real-time)

The whole interface is mouse-driven – so to interact with it, you have to hook up an USB mouse to be able to control it. This is not where the usefulness of this tool ends, however – GPAD (Graphics Performance Analyzer and Debugger) allows you to interface your PC with this HUD and dump all the performance data to your PC. However, again, some options – such as live video capturing – can only be done with the Reference Tool.

GPAD on a Windows PC interfacing with a debug PS3 running GCM HUD


A brief rundown of the samples that struck my eye –

Deferred shading

Deferred shading lends itself well to the architecture of the PS3 where you have a comparatively humble GPU (RSX) and up to 6 SPEs each running at 3.2GHz – the idea is to essentially subdivide the result of a shading algorithm into multiple parts that can be spread across different render targets/CPUs only to combine them at the end into one composite whole. Using this approach, the RSX can simply offload a lot of the vertex and fragment computations that are done in shaders to the SPEs which in turn crunch through the calculations (the original shader algorithm having been subdivided into parts for each SPE to chew through) only for the RSX to combine all these separate parts and render the picture.

Commercial game developers like DICE have started using this approach for games like Battlefield 3 to achieve graphical results and performance which normally would have been unattainable if all that was available to them was the RSX alone. A link to a slideshow presentation is available here.

Deferred shading sample pics

Yes, the FPS count starts to drop heavily once you start adding extra spot lights.

PSGL samples

At one point, Sony was asking developers whether they would be interested in having PSGL conform to the OpenGL ES 2.0 specs (link here). This has unfortunately never happened however, as developers seem to have mostly preferred to go with libGCM as their main graphics API of choice on PS3. This has meant that the development environment has started becoming more libGCM-centric over the years with PSGL eventually becoming a second-class citizen – in fact, new features like 3D stereo mode is not even possible unless you are using libGCM directly.

However, this has not deterred them from still making available a couple of nice samples that illustrate what PSGL is capable of in conjunction with Cg shaders (which is mostly what we use with the homebrew emulators up until now). Some nice examples show Cg being applied to render hair, skin mapping, normal mapping, parallax mapping, and sophisticated water effects (the latter ones definitely being a cut above our own shader – made by Themaister).

Below you can see some screenshots illustrating nice tech demos using Cg and SPUs in tandem –

Cg being used for hair specular highlights

Cg being used for water ripple effects


What the debug PS3 will allow us to do is to finally start getting rid of bugs – memory leaks that were simply impossible to flush out with a retail box because of the inherent limitations of printf debugging. There are quite a few memory leaks that can now be tracked down in FBANext PS3 through crash dumps and live TTY logging.

Most ambitious of all, it will finally allow us to start writing code for SPUs – which I didn’t even want to attempt doing before because of the pain that was the retail environment. It remains to be seen whether we can really offload much if anything in the emulators to the SPUs – however, I have seen many creative uses for PPU-to-SPU offloading in some samples already, including function/virtual function call offloading to specific SPEs amongst a host of other things I didn’t even consider before.

Expect to see some real solid progress on MAMENext PS3 very soon, and for the emulators to improve immeasurably overall. Still, there are some inherent limitations even to the Debugging Station – the proprietary profiler will only allow me to do static analysis right now with a Debugging Station – if we wanted real-time profiling, we would have to be in possession of a Reference Toolkit, which is simply above anybody’s budget to be honest. This means that it might be impossible for any homebrew dev to ever do a serious attempt at porting a demanding emulator such as PCSX2 or Dolphin even with a debugging station because libgcov will only carry them so far – definitely forget it altogether on the retail units and the limited development environment they have available to them (whether it be the PS3 SDK or PSL1GHT).

The debugger that comes with it however is a seriously powerful tool and can carry us a long ways since it shows us live disassemblies of the code – meaning we can at least set a breakpoint somewhere, look at the ASM that the ‘shitty’ PS3 compiler turned our C/C++ code into, and then rewrite the code ad nauseam until the code generation starts to make more sense of our code and translate it to faster ASM code.

VBANext – Launch

As of today, VBA PS3 has evolved into VBANext. All future development will happen on this page :

In short, VBA PS3 is dead – long live VBANext. The same will happen to SNES9x PS3 shortly when it blossoms into SNES9x Next (new name for SNES9x Slim).


Phoenix Wright: Ace Attorney (Japanese version – Gyakuten Saiban) on VBANext (PS3 version shown here) with the dot shader.

This new project will be a faster, slimmed-down version of VBA-M that is currently aimed at three platforms:

  • PlayStation3
  • Xbox 360 (WIP)
  • Mobile (WIP)

It will replace both VBA PS3 on PlayStation3 and Lantus’ VBA360 0.03 on Xbox 360. In addition to that, a port to mobile platforms is tentatively in the works.

A few screenshots (taken from the PS3 version) can be viewed here.


Donkey Kong ’94 with Super Game Boy borders on VBANext (PS3 version shown here).

As for the PS3 port – a lot of progress has been made over the past few weeks. Super Game Boy border support is now in – when you select a game that is Super Game Boy-compatible from the ROM menu, it will display the border that would be visible on a real SNES with a Super Game Boy add-on cart.

It will perhaps be possible to add fourplayer gamepad support at a later date for Super Game Boy games as well – certain games like Wario Blast made use of the Super Gameboy’s access to the host hardware (SNES) to allow for multiplayer support with regular SNES pads. VBA-M supports this out of the box – so it would be a shame to let it go to waste.

On the display front – FBO mode will be added – this will allow for two shaders to be selected at once. All the features that are currently in SNES9x PS3 and other emulators will be added as well – for instance, border support (different from the Super Game Boy border support which is built into VBA-M) and possibly game aware shaders as well.

Mega Man V – another Super Game Boy-compatible game – shown running here on VBANext (PS3 version shown).

Xbox 360

Final Fantasy Tactics Advance running on VBANext (PS3 version shown) – now sans the FPS slowdown in the introduction screen.

The Xbox 360 port will require some cleaning up. I will use Lantus’ VBA360 0.03 sourcecode at first and then try to slim it down by removing dependencies such as libSDL. I’m confident performance will be even better now than it previously was on 360 – since VBA PS3 was based on Lantus’ core code changes after all – with the new slimline core, it is only bound to get better.

Sonic Advance 1/2 will work again with this updated Xbox 360 version because of the removal of the SFML network code (note – if a porter wishes to do so – he can reimplement this again by defining the switch ‘NO_SFML’ – the SFML network code’s only purpose is to allow Dolphin – the Gamecube/Wii emulator – and VBA-M interoperability – it has no other purpose and it actually breaks these two games from working).

I also got rid of a rather annoying display bug in Advance Wars 2 for the PS3 port (now evolved into VBANext) – so obviously that will be fixed on 360 as well, since it suffered from the same problem.


A mobile port for Android is tentatively in the works. More progress on this one will be posted shortly.

Debug 360/PS3 + future of console emulator ports

Xbox 360 XDK

I have acquired an Xbox 360 XDK recently and am in the process of acquiring a Test PS3 as well. The main reason for me buying these two is to further improve the already existing emulator ports on PlayStation3 – the lack of any decent performance profiling tools was really becoming a hindrance to the future development of the ports, and to get anywhere, I thought it was necessary to take a financial hit and buy proper debug units.


Some still images I’ve taken from the 360 XDK –

360 XDK screenshot album

Future of the PS3 emulator ports

Now that I’m able to target both Xbox 360 and PlayStation3 (and also given that the two consoles are quite similar to each other), I’m planning to make the emulator ports cross-platform in a similar vein to FBANext. FBANext runs on both Xbox 360 and PlayStation3 with only minimal differences. If I take a look at my own PS3 emulator ports – there exists the possibility to do something similar for projects like VBA, SNES9x, FCEU and Genesis Plus GX PS3. VBA PS3 is very heavily based on Lantus’ VBA 360 – and since Lantus does not actively maintain VBA 360 anymore and there is still some work remaining to be done on the 360 front (such as Sonic Advance 1/2 support and D-pad controls) – I’m planning to make a separate project on Google Code so that both platforms will have an up-to-date version of the emulator –


VBANext will target both PS3 and Xbox 360, and will be based on the VBA PS3 codebase. It will most likely supersede VBA PS3 as it stands.

MAME 360/PS3

This is Lantus’ MAME 0.72 port to Xbox 360. I have co-ownership of the project – and I will be porting it to PS3 shortly.

Games like Mortal Kombat 1/2/3/Ultimate run at full speed on 360 – similar performance is expected on PS3.

I could target even more machines than just these two – I have DevkitPro set up for Wii and I’m also able to compile for Xbox 1 – but perhaps it’s best to focus on 360/PS3 for now instead of spreading myself too thin. I’m still intent on helping out madmab with his Xbox 1 port of SNES9x 1.52 though –

SNES9x Slim

SNES9x Slim aims to be a slimmed-down version of SNES9x for use on platforms that currently struggle to run the latest versions. The codebase still lags behind the PS3 version considerably – but once done, it will target PS3, Wii, Xbox 1, Android, Xbox 360 and other systems. Most of the improvements/removals are totally platform-agnostic.