(PS3) Build issue

[peteuk]

I am unable to build the PS3 version of SSNES with the Genesis-next Libsnes.A Output log: http://pastebin.com/tKk73Ryb

Also, to get SSNES to PKG with psn_package_npdrm, I had to edit PS3/PKG/package.conf to the following:

Content_ID = UP0001-SSNE10000_00-0000000000000001 K_licensee = 0xc0a3b3641c2ad1ef23153a48a3e12fe7 DRMType = Free ContentType = GameExec PackageVersion = 00.01 APP_VER = 00.01

[Themaister]

It might be a case where dependencies in libsnes.o are not resolved. In the makefile, try putting libsnes.c as the top-most source file in LIBSNES_SRC :=. Don't have toolchain available atm so cannot test myself.

Also, this is more of a genplus port issue than SSNES itself.

[inactive123]

I just tried it here - it links and it's definitely working.

I suggest git cloning the Genesis Next repo from scratch, doing make -f Makefile.libsnes platform=ps3, then put libsnes.a in the SSNES source dir, compile SSNES PS3 (make -f Makefile.ps3) and see if it works now.

[peteuk]

Just tried again and have managed to get it to build. I don't think that the Makefile is detecting that I am running windows. I have edited the following in the makefile:

ifeq ($(uname),) platform := win else platform := linux

to

ifeq ($(uname),) platform := win else platform := win

and I changed the SDK path to: CELL_SDK := /c/usr/local/cell

[inactive123]

But SNES9x Next libsnes Makefile works as expected right?

I've pushed what I can see as the only change with regards to setting 'platform' between the SNES9x libsnes Makefile and the Genesis one. See if it fixes your issue.

[peteuk]

Sorry I meant SSNES not Genplus.

[inactive123]

OK - I'll add that logic there as well then.

[inactive123]

OK - I just pushed a fix - try to see if it works for Windows.

[peteuk]

Has not made any difference as far as I can tell. It's still looking for the SDK in host-linux.

$ make -f makefile.ps3 /usr/local/cell/host-linux/ppu/bin/ppu-lv2-gcc -O3 -g -DSSNES_CONSOLE -DHAVE_OPE NGL=1 -DHAVE_CG=1 -DHAVE_FBO=1 -D__CELLOS_LV2__ -DHAVE_CONFIGFILE=1 -DHAVE_NETPL AY=1 -DHAVE_SOCKET_LEGACY=1 -DPACKAGE_VERSION=\"0.9.4.1\" -DHAVE_SCREENSHOTS_BUI LTIN=1 -Dmain=ssnes_main -c -o fifo_buffer.o fifo_buffer.c make: /usr/local/cell/host-linux/ppu/bin/ppu-lv2-gcc: Command not found make: *\ [fifo_buffer.o] Error 127

[inactive123]

OK - pushed another fix to the Makefile. Try it again.

[peteuk]

Still the same result.

[inactive123]

Try if this commit fixes it -

https://github.com/Themaister/SSNES/commit/989962f5a98d68a23c0236f785aac4820e78b20f

[peteuk]

Yep thats fixed it. Now building fine.

[peteuk]

I haven't tried to build SSNES for the PS3 for a while and I am now having problems getting it to run. Looking through makefile.ps3, I take it I should be building by running the following:

make -f makefile.ps3 pkg-signed-cfw

which produces the following error:

make_self_npdrm ssnes-salamander.elf ps3/pkg/USRDIR/EBOOT.BIN UP0001-SSNE10000_0 0-0000000000000001 make: *\ [create-salamander] Error 5

So I ran, make -f Makefile.ps3.salamander, which completed with out error and created ssnes-salamander.elf. I ran make -f makefile.ps3 pkg-signed-cfw again and it completed without error. As I have not got python2 setup I used psn_package_npdrm with this package.conf (http://pastie.org/3665800) as I received an error when trying to create the PKG with the one included.

The PKG installs fine on my PS3. When I try to run SSNES it quits straight back to the XMB without any error.

[inactive123]

Yes, you need to first create SSNES Salamander ELF by doing make -f Makefile.ps3.salamander.

After that, you need to do make -f Makefile.ps3 pkg-signed-cfw.

I'd recommend you do set up Python 2 on your PC so that you can run the setup script in there and use that to make your PKGs (by simply issuing make -f Makefile.ps3 pkg-signed-cfw) instead of winging it with 'psn_package_npdrm' (somebody has never been able to tell me exactly how this differs from the original Failoverflow tools, what changes are in there that make a difference and whatnot), which is unsupported.

After you've got Python 2 installed, you would have to go into ps3/ps3py, then run 'python2 setup.py install'. Ignore any error message you might get - what is important is that it created a pkgcrypt.so/pkgcrypt.dll file in a subdirectory. Go to that subdirectory (it should be in the directory you're at right now), and move pkgcrypt.so (or .dll, whatever) to ps3/ps3py. After that, making a PKG with the Makefile should just work.

[peteuk]

I have installed Python 2.7.2 and have exported the path to my Msys profile. I ran "python setup.py install" (I take it you meant "python" and not "python2") and I seemed to complete ok:

running build running build_ext building 'pkgcrypt' extension error: Unable to find vcvarsall.bat

The problem is that I cannot find pkgcrypt.dll anywhere on my system.

Thanks for the help.

[inactive123]

No, I mean Python2. The script will only work with Python 2 (don't blame me, blame the PSL1GHT people who have not bothered updating it to Python 3).

Try to find out which version of Python is invoked by 'python' by typing 'python -v' at the commandline - if it's Python 3 or higher you will need to use 'python2' instead.

if the command was successful (ie. python2 setup.py install) it should create a 'build' directory in your ps3py directory with a pkgcrypt file there in it. It will also tell you where it has saved this extension after you have ran this command (at least it does on Linux).

[peteuk]

I am running Python 2.7.2, It's the only version I could find at http://www.python.org Do I need an older version? Looking in the Python27 folder, the only executables are python.exe and pythonw.exe

[peteuk]

I think I am getting somewhere. I first of all had to rename python.exe to python2.exe & then ran setup.py in snes9x-next/ps3/buildtools/ps3py and it created pkgcrypt.pyd. I then copied this to ssnes/ps3/ps3py. I cleaned the sources and rebuilt again. The build seemed to go fine and it cloned the shader GIT. Heres the output from the python part:

python2 ps3/ps3py/pkg.py --contentid UP0001-SSNE10000_00-0000000000000001 ps3/pk g/ ssnes-ps3-cfw-"0.9.5"-kmeaw.pkg [X] Magic: 7f504b47 [X] Type: 00000001 [X] Offset to package info: 000000c0 [ ] unk1: 00000005 [X] Head Size: 00000080 [X] Item Count: 000000df [X] Package Size: 000000000062bbb0 [X] Data Offset: 0000000000000140 [X] Data Size: 000000000062ba10 [X] ContentID: 'UP0001-SSNE10000_00-0000000000000001' [X] QA_Digest: 1CA7BB373F6A885BAC88BD4061B52B7E [X] K Licensee: 00000000000000000000000000000000

package_finalize ssnes-ps3-cfw-"0.9.5"-kmeaw.pkg /bin/sh: package_finalize: command not found make: *\ [pkg-signed-cfw] Error 127

It has created the PKG but I have not had a chance to try it on the PS3 yet.

[inactive123]

Yes, it seems the PKG generation is now going correctly - the only thing it's not yet finding is 'package_finalize' - which should be somewhere in your environment path. On Windows, we should add a '.exe' there - I can change that in the Makefile at least.

[peteuk]

I have tracked down package_finalize.exe and placed it in host-win32/bin and the build is now completing without error.

I am still unable to get it to run on the PS3 though. It installs the package fine but when I run SSNES it starts to load then quits back to the XMB without an error. Just in case it matters, I have been using the SNES9X libsnes.a.

Here is the outputted PKG and ELFs: https://rapidshare.com/files/895023343/SSNES.zip

[inactive123]

If you're using Rebug CFW, SSNES won't work correctly - this is because Rebug apparently has some problem to do with making the function call 'cellFsRename' - this won't work on Rebug CFW. I'd advise Kmeaw instead.

As for how the bootup procedure works -

EBOOT.BIN is first launched - this is SSNES Salamander. SSNES Salamander will check if CORE.SELF is present in USRDIR/CORE.SELF. If present, it will boot this file. if not, it will try to find an existing 'SELF' to boot (which is stored in the config file).

When CORE.SELF has been booted, the CORE.SELF file will be renamed to a better name based on the name of the emulator (for instance - the Genesis Plus CORE.SELF will be renamed to genesis-plus-gx.SELF).

Do you know for sure that the PKG you create has an EBOOT.BIN and a CORE.SELF?

[peteuk]

I am using 3.55 Trueblue v2. I have made a new clone of the SSNES and Genesis-next gits, compiled the libsnes.a and placed it in SSNES and then built again with the package-signed-cfw flag. The build finishes without and error. Inside the usrdir folder there is a CORE.SELF but I am still having the same issue.

[inactive123]

I've never tried or used Trueblue so I can't really help you there.

Looks like SSNES Salamander (EBOOT.BIN) is not working correctly with the True Blue dongle for some reason - it should look for a file called 'CORE.SELF' and exitspawn to that - it should try that first with the NPDRM version of exitspawn, and if that fails it should fall back to the non-NPDRM version of exitspawn.

I could talk to Deank about this issue and see if he has any solution to this but I doubt he even has a True Blue dongle.

What you could do in the meantime to get it to work nevertheless is to rename CORE.SELF to EBOOT.BIN and replace the existing EBOOT.BIN. It should at least boot the emu then. This is less than ideal though because SSNES Salamander acts as an 'emulator manager' whenever you install a new emulator for use with SSNES.

[peteuk]

I will install kmeaw tomorrow and test it again.

[peteuk]

I have got GraVoX to test my build on his KMEAW PS3 and he is having exactly the same issue as me, so it can't be an issue with Trueblue V2 firmware. When we start SSNES the screen flashes black for a second and then returns straight back to the XMB.

[opium2k]

peteuk, I tried the pkg you posted above on cobra and kmeaw and had the same result. When I renamed core.self to eboot.bin and replaced the existing eboot.bin with it, I got error 80029530 According to PS3DevWiki 80029530 = SCE_NP_DRM_ERROR_FORMAT Looks like core.self is an npdrm self, meant for debug units. Try packaging it with make_self_wc

[inactive123]

I'll try it out on Kmeaw CFW today - release date is April 2nd anyway so you could wait until then.

[peteuk]

@opium2k The core.self was been created with make_self_wc. I think you are getting the NPDRM error because the EBOOT.BIN need to be created with make_self_npdrm.

[inactive123]

It doesn't need to be made with make_self_npdrm - the EBOOT doesn't need to be NPDRM at all on non-debug PS3s - such as CFW PS3s.

It's supposed to fall back to the non-NPDRM version of exitspawn on non-debug PS3s if the NPDRM version of exitspawn doesn't work in SSNES Salamander.

[opium2k]

It looks like cobra/tb are likely the cause. I was running cobra cfw (SSNES wouldn't load) switched to kmeaw (still wouldn't load) went to ofw and back to kmeaw (still wouldn't load) decided to do a full restore and ~7 hours later the vba test pkg and the one posted by peteuk load normally.

[opium2k]

Update: I reinstalled multiman 4.02.00 and SSNES started kicking me back to the xmb again. As soon as I uninstalled multiman, SSNES started working again. I uninstalled and reinstalled both programs a couple of times to make sure and it seems like it's able to be duplicated.

[peteuk]

I will be home in an hour or so and will see if I can replicate. On Mar 30, 2012 12:01 PM, "opium2k" < reply@reply.github.com> wrote:

Update: I reinstalled multiman 4.02.00 and SSNES started kicking me back to the xmb again. As soon as I uninstalled multiman, SSNES started working again. I uninstalled and reinstalled both programs a couple of times to make sure and it seems like it's able to be duplicated.

---

Reply to this email directly or view it on GitHub: https://github.com/Themaister/SSNES/issues/7#issuecomment-4840398

[peteuk]

I was able to replicate it. I removed multiman and SSNES has started to work.

[almostalive]

same here

[inactive123]

OK, so it looks like the Multiman support in SSNES PS3 right now is what is causing the problems.

Guess I will need to get in contact with Deank about this pronto - so far he hasn't responded yet.

[peteuk]

Seems to be working fine with multiman on commit: debba76dc442ca40bb7e84868775df79e25764bd