SNES9x (Super Nintendo Emulator) PS3 Port Arrives!

[eventum]

I wouldn't mind 2-3x larger font when browsing files. I'm climbing towards 40 and my eye sight is not what it used to be.

Great work guys in any case!

[squarepusher2]

I'd love to see bsnes on the PS3, but not enough to buy the console, mod it, and do it myself. But I can at least offer some info in case you guys want to give it a go

Your main issue in using bsnes is going to be its use of C++0x. You will need GCC 4.4 or newer to build bsnes. If you can not get that, then you will need to use bsnes v060, which doesn't have the faster performance core but is C++98. Both are under the "all downloads" link on Google Code. Alternatively you could backport the v068 code to C++98.

Hi there byuu,

great to see you taking the time to post on this forum. I have a lot more to respond to in your post, but first things first -

The PS3 SDK 1.92 is (AFAIK) around three years old - the PPU level 2 GCC version is at 4.1.1

$ ppu-lv2-gcc-4.1.1 -v
Using built-in specs.
Reading specs from c:/usr/local/cell/host-win32/ppu/bin/../../../target/ppu/lib/prxspec.4.1.1
Target: ppu-lv2
Configured with: /work2/toolchain/gcc/configure --target=ppu-lv2 --host=i386-pc-mingw32msvc --build=i686-pc-linux-gnu --prefix=/usr/local/cell/host-win32/ppu --with-sysroot=/usr/local/cell/target/ppu --with-headers=yes --disable-threads --disable-shared --disable-hosted-libstdcxx
Thread model: single
gcc version 4.1.1 (CELL 4.1.2.7, RTTI, $Rev: 1830 $)

I'm running this on a Windows box running Msys since this build that is publicly available does not have PPU GCC/G++ binaries for Linux (don't ask me why, since the official SDK comes with both host-linux and host-win32 folders, yet it's missing PPU binaries for Linux - I'm guessing this is something that got left out of the leaked SDK release.)

Is there any chance you could provide a diff in the future to get around the GCC 4.4 requirement, or is this not a trivial task? I'm guessing this would help out people on other platforms as well.

[byuusan]

What a shame, I was hoping the PS3 devkit was at least semi-up to date.

Well, the thing is there's a lot of C++0x code. Porting it every time I release a new build would be way too much work, may as well not use it, but I use it because it makes writing the emulator much easier.

The main areas:
- foreach macro relies on auto keyword for type deduction (will have to add type parameter to every call in the cartridge/xml.cpp mapper)
- string, vector and array classes use move semantics and perfect forwarding (can be removed, core emulation do not use them so no performance penalty)
- most classes use = delete; on unused copy constructors (can be removed, they are just safeguards)

Probably a weekend task, or you could use v060 directly which is almost exactly the same in terms of accuracy, but lacks the faster performance core. I'm not huge on doing the backport myself, because I'm crazy busy with other things at the moment, but I'd be willing to help with any parts you don't understand, since few people know C++0x already.

[squarepusher2]

What a shame, I was hoping the PS3 devkit was at least semi-up to date.

It might be up to date for all we know - this is just a leaked devkit from three years ago - the only one that's out there for public consumption through somehow less than legal means.

This scene is pretty much in the same situation as the original Xbox scene was in (with no real open-source - and thus legal - means to program homebrew software) - most probably this scene's equivalent of OpenXDK will take a similar amount of time to gestate and by then everyone will have moved on to some other platform. (and even then, OpenXDK never had hardware accelerated graphics - so it was always second-best to program in from a pragmatic point of view)

Byuu: Hi there byuu, not sure if I should be the right one to try to port bSNES over to PS3 since I am well below your level of programming prowess - but anyway, I hope you can forgive the ignorance I'm exemplifying here - seeing as I'm almost embarrassed to be asking you about something as trivial as a Makefile.

Given the advice you gave me, I was first looking at porting bSNES 0.60, and go from there basically. If I can get that to actually run, I figure I might as well go ahead and immerse myself in C++0x and try to get the latest version ported.

Basically, I'm stumped at the Makefile basically.

Let me first give you an example of what most of the sample Makefiles look like from Sony's SDK samples directory -

http://github.com/eiz/ps3_snes9x/blob/master/Makefile

What I've tried to do with the Makefile from bSNES 0.60 (the one in src) is to basically model everything after the Makefile I linked to above, take everything from the original bSNES makefile beginning at the #libraries, and put it all inside the variable PPU_SRCS.

So you get something like this:

PPU_SRCS = lib/ruby/ruby.cpp $(call rwildcard,lib/ruby/*) $(call compile,$(rubydef) ) lib/libco/libco.c lib/libco/* cartridge/cartridge.cpp cartridge/* cheat/cheat.cpp cheat/* memory/memory.cpp memory/* memory/smemory/smemory.cpp $(call rwildcard,memory/smemory/) cpu/cpu.cpp cpu/* cpu/core/core.cpp $(call rwildcard,cpu/core/) cpu/scpu/scpu.cpp $(call rwildcard,cpu/scpu/) smp/smp.cpp smp/* smp/core/core.cpp $(call rwildcard,smp/core/) smp/ssmp/ssmp.cpp $(call rwildcard,smp/ssmp/) dsp/dsp.cpp dsp/* dsp/adsp/adsp.cpp dsp/adsp/* dsp/sdsp/sdsp.cpp dspsdsp/* ppu/ppu.cpp ppu/* ppu/bppu/bppu.cpp $(call rwildcard,ppu/bppu/) system/system.cpp $(call rwildcard,system/) chip/supergameboy/supergameboy.cpp $(call rwildcard,chip/supergameboy/) chip/superfx/superfx.cpp $(call rwildcard,chip/superfx/) chip/sa1/sa1.cpp $(call rwildcard,chip/sa1/) chip/bsx/bsx.cpp chip/bsx/* chip/srtc/srtc.cpp chip/srtc/* chip/sdd1/sdd1.cpp chip/sdd1/* chip/spc7110/spc7110.cpp chip/spc7110/* chip/cx4/cx4.cpp chip/cx4/* chip/dsp1/dsp1.cpp chip/dsp1/* chip/dsp2/dsp2.cpp chip/dsp2/* chip/dsp3/dsp3.cpp chip/dsp3/* chip/dsp4/dsp4.cpp chip/dsp4/* chip/obc1/obc1.cpp chip/obc1/* chip/st010/st010.cpp chip/st010/* chip/st011/st011.cpp chip/st011/* chip/st018/st018.cpp chip/st018/* chip/msu/msu.cpp chip/msu/*

Basically, this succeeds up until a point - it errors out at a specific point (at the SDSP part - it complains about sDSP being undeclared.

As a second experiment, I also tried taking the bSNES makefile, this time retaining all the parts of your Makefile, but commenting out/editing out everything having to do with the GUI (such as 'include lib/nall/Makefile), ui := ui_qt, most of the platform stuff) and then executing make as follows:

make compiler=ppu-lv2-gcc-4.1.1 (notice I've omitted platform since I totally edited/commented all that stuff out)

This gives me even more spectacular errors.

Lastly, I also tried to do it the even more rough way - basically go over every directory inside the src folder structure, and put every file ending with .CPP inside PPU_SRCS. This also ended in failure.

Do you have any ideas? Once again, sorry for the general display of ignorance here (both on a language level (C++) and understanding of bSNES) - but it's quite hard to wrap my head around what might be wrong here. I don't think I'm omitting anything that is crucial.

Lastly, thanks for the advice on the sound APU. Just with the port of SNES9x alone, I tried out a wide range of input frequencies - I noticed that at a certain point, the crackling appeared to drown out, but on the minus side I started to notice frame skips / missed frames which previously weren't there - so I had to move the input frequency up again. Here's a list of values I had tried out with SNES9x:

32000
31968
31920
31910
31900
31890
31880
31870
31860
31850
31840
31830
31820
31810
31800
31790
31780
31760
31750
31740
31730
31720
31710
31700
31690 (starting to notice the crackling starting to subside, but on the flip side slowdown seems to be setting in)
31680 (same, if not worse slowdown)
31670 (and on)
31660 (and on)

Perhaps try what you seemed to hint at - if SNES9x generates 10 samples more than what is needed due to the PS3's display frequency and output frequency, perhaps start with an input rate of 32040 and subtract by 10 until I finally arrive at an ideal value?

Do you suppose we'll be running into the same problems with bSNES? While I'm on the subject, while I was able to get sound working just fine with previous versions of bSNES on my Opensuse 11.3 Core 2 Duo system, as of version 0.68 sound crackling also started to appear in a manner similar to that seen in this PS3 version of SNES9x - so I'm guessing that with the new APU core, this fiddling around with the Sound input frequency is part of a ritual that you have to endure once with every PC configuration because of the level of accuracy aimed at or something? This never seemed to be much of a problem with zSNES and SNES9x in the late '90s and on - I take it that was because of accuracy not being much of an issue.

Just to add to this - I also tried to exclude ruby from PPU_SRC since that is also platform-dependent - didn't change anything.

[deadpixel99]

Hey squarepusher , you seem pretty smart but you do realize that it will not compile for the PS3 if the bsnes source code wasn't recoded for the PS3... You can't just take some random source code and try to compile it for a different system... Did you do anything to the source code first... doesn't seem like it.

[ionbladez]

Hey squarepusher , you seem pretty smart but you do realize that it will not compile for the PS3 if the bsnes source code wasn't recoded for the PS3... You can't just take some random source code and try to compile it for a different system... Did you do anything to the source code first... doesn't seem like it.

ya, you pretty much can. that's why it's called "source code" not "compiled binary".

[squarepusher2]

Hey squarepusher , you seem pretty smart but you do realize that it will not compile for the PS3 if the bsnes source code wasn't recoded for the PS3... You can't just take some random source code and try to compile it for a different system... Did you do anything to the source code first... doesn't seem like it.

The SNES9x port you see here had zero changes made to it to make it run on the PS3 - all that was added to it was one single file (cell.cpp) where a bunch of SDK libraries are used to set up/initialize sound, graphics, hook up the controller ports to Snes9x, register it to a button, and then use a rudimentary file manager (once again courtesy of the SDK) to start a ROM.

Snes9x as it is was compiled unchanged with no PS3-specific changes.

[eventum]

Do you guys have any idea of how much system resources the current version of Snes9X consumes on the PS3? Is there any way to tell? With regard to CPU and RAM utilization.

[squarepusher2]

The SNES9x port you see here had zero changes made to it to make it run on the PS3 - all that was added to it was one single file (cell.cpp) where a bunch of SDK libraries are used to set up/initialize sound, graphics, hook up the controller ports to Snes9x, register it to a button, and then use a rudimentary file manager (once again courtesy of the SDK) to start a ROM.

Snes9x as it is was compiled unchanged with no PS3-specific changes.

Well, to be entirely correct, there were a few trivial changes to the source -

<include ctype.h> was included in memmap.cpp, and some of the functions in movie.cpp were filled in instead of just 'FILE_NOT_FOUND' (only the ones that threw some errors - S9xMovieOpen and a couple of others - the function implementations were taken from snes9x-gtk).

Those were all the changes. Just unzip the contents of SNES9x v1.52 src and do a git clone of the Snes9x PS3 git repository, and compare the two with diff to see the changes:

diff -u -r snes9x-1.52-src ps3_snes9x

'snes9x-1.52-src' is the location to the folder where you have unzipped the Snes9x 1.52 source, and likewise for 'ps3_snes9x'.

So yeah, still, no real changes were made to the source - so it's as close to a 1-on-1 straight port as you can find. Declaring <include ctype.h> in memmap.cpp was to get around a bunch of errors to do with inbuilt functions such as isdigit - I'm guessing this is down to this outdated GCC version we're using.

Edit: OK, I finally succeeded in getting clear sound. This is a major milestone as we can now run all games at 60fps in 480p (vsynced) with perfect sound.

What I did was - I started from scratch. Downloaded the SNES9x 1.52 source, instead of deleting all of the jma/filter/unzip directories, I left them in (will help later on when we need to implement that stuff), I carried over the Makefile, the shader files and the cell.cpp files from eisz's original port.

Then I did the two main changes that this port has to make it compile on PS3:

1 - in memmap.cpp - add #include <ctype.h>
2 - in movie.cpp - basically carried over the changes made by eisz in his port.

After that, I took a long look at all the different patches that have been committed by bearoso since the SNES9x 1.52 release - ones that were specifically related to the sound APU.

It looks like the SNES9x 1.52 build (while released in February 2010) is actually a commit dating back to the beginning of January 2010 - because every patch after that actually seems to be a fix or an improvement.

So I implemented the following patches:
1 - patch revision 258
2 - patch revision 259
3 - patch revision 260
4 - patch revision 272
5 - patch revision 282
6 - patch revision 283
7 - patch revision 287

I made diffs for all of these patches in a folder called 'patches' just for reference's sake.

Applying all of these patches one after another finally took care of the sound crackling. So now the sound is as close to perffect as we can get - I did notice one pop after extensive playing but it's so rare it might as well not exist - but perhaps fiddling around with the InputRate can even take care of that slight pop.

Perhaps at some point we might still want to fidlde around with the InputRate - I have left it at 31968 (the setting that was originally in eisz's version) - perhaps might require some tweaking to get it right totally perfectly.

Now that the core is working alright - we need to turn this port into something usable. Have a decent UI, exit game functionality, filter functionality (2xSAI), decent performance under higher resolutions (going to test this next), and perhaps create some kind of multi-emulator thing where we can choose between bSNES and SNES9x to play a game (once bSNES has been successfully ported over).

I would recommend to eisz that he downloads this zip that I will be providing in this post and make this the trunk version on his git repository - this version is by now so superior to the original version it's not even funny - so this should become the official version.

Basically, the whole problem all along seemed to be SNES9x itself - and not the PS3 audio server API or anything of the sort.

All the more reason I guess to make porting bSNES a real priority since there's no telling what kind of other problems we will struggle with down the road - they (SNES9x developers) seem to be having real problems getting rid of all their outdated cores and supplanting them with more accurate cores - as byuu himself has pointed out, all of the HDMA hacks in memmap.cpp seem to be evidence of that.

So, here's build 4:

Build 4
CHANGED:
* Started from scratch - redownloaded 1.52, took everything from eisz to make it compile for PS3
* Set SoundSync to TRUE
* Set AutoSaveDelay to 0
* Applied the following patches from snes9x-gtk:
- Revision r258 - Add a fixed-point linear resampler option. 
- Revision r259 - Use the APU_DEFAULT_RESAMPLER macro. 
- Revision r260 - Optimize the linear interpolation macro. 
- Revision r272 - Merge zones' timing stuff. 
- Revision r282 - Use APU clock that yields 32040hz output instead of 32000. 
- Revision r283 - Integrate timing hack variables into the clock ratios to allow integers in all cases. 
- Revision r287 - Don't push samples if there aren't any.

* Finally, the sound scratching is gone as a result of applying all the patches one after another. People will still want to fiddle around with the SoundInputRate to get it totally perfect - the crackling is gone, that is no longer a problem, but if you focus really hard, you will hear a slight pop - SoundInputRate is now set at 31968 - try lowering it, subtract by 10.

In case this writeup makes it sound like the sound is bad, you will probably not even notice what I'm talking about here - the sound is pretty much perfect now.

[cvp]

Bro, VERY NICE WORK!!!! Donkey Kong haves Sound and Saving/Load States is possible!

one question, will be coming upscalling to 720p/1080p ?