[$threadinfo[title]]

[rhetoric]

I've searched far and wide and found no information on compiling mupen64 for powerpc linux. I've tried to compile, and I get this from sudo ./configure (ubuntu feisty fawn):

Found a working C compiler (gcc).
Checking SDL...
./config.temp: 3: Syntax error: "(" unexpected
*** Couldn't find a working SDL library!

Prior to this, I got errors telling me to install libsdl, so I installed every libsdl related package I could find.

Does anyone reading this have any experience compiling/using mupen64 on a powerpc linux machine?

edit: for clarity, this refers to 32bit ppc, and this is the error I got trying to compile mupen64 0.5

[sultanoswing]

I got this same error when trying to compile a recent (as in a week or two ago) SVN build on Ubuntu Gusty (32-bit x86). Same as you, I tried adding various sdl-dev packages, but to no avail.

[GarulfoLinux]

look at that : http://www.emutalk.net/showpost.php?p=368731&postcount=19

[Richard42]

I got this same error when trying to compile a recent (as in a week or two ago) SVN build on Ubuntu Gusty (32-bit x86). Same as you, I tried adding various sdl-dev packages, but to no avail.

You may be talking about 2 different things here. Rhetoric, are you trying to compile from the 0.5 source or my SVN build? Because I removed the 'configure' script from my SVN build - it's not there anymore. If you try to compile the mupen 0.5 source I'm pretty sure that you'll have major problems. That's the reason why I started my own branch -- to port it to 64-bit architectures. You can download the source for mupen64-amd64 v1.1 in another thread on this forum and give it a shot with 'make'. Let me know how it turns out.

[rhetoric]

You may be talking about 2 different things here. Rhetoric, are you trying to compile from the 0.5 source or my SVN build? Because I removed the 'configure' script from my SVN build - it's not there anymore. If you try to compile the mupen 0.5 source I'm pretty sure that you'll have major problems. That's the reason why I started my own branch -- to port it to 64-bit architectures. You can download the source for mupen64-amd64 v1.1 in another thread on this forum and give it a shot with 'make'. Let me know how it turns out.

I was trying to compile the 0.5 source. Why would I use source designed for amd64 for a powerpc box?

[Richard42]

I was trying to compile the 0.5 source. Why would I use source designed for amd64 for a powerpc box?

This branch should be able to build and run on your powerpc box, or at least get closer than the vanilla 0.5 source. The reason it's called -amd64 is that I needed to have something which designated that this is for 64-bit machines (as opposed to Win32 or Linux 32), and it would be kind of ridiculous to call it Mupen64-64 so I settled on -amd64. The C code in Mupen 0.5 will not compile properly on your powerpc 64 with GCC, but the C code in my branch should. There may be some problems with the inline assembly code; I don't know because it hasn't been tested on a powerpc yet.

[rhetoric]

This branch should be able to build and run on your powerpc box, or at least get closer than the vanilla 0.5 source. The reason it's called -amd64 is that I needed to have something which designated that this is for 64-bit machines (as opposed to Win32 or Linux 32), and it would be kind of ridiculous to call it Mupen64-64 so I settled on -amd64. The C code in Mupen 0.5 will not compile properly on your powerpc 64 with GCC, but the C code in my branch should. There may be some problems with the inline assembly code; I don't know because it hasn't been tested on a powerpc yet.

I should have been more specific. As far as I know, I'm using 32bit ppc. . .

[nmn]

Honestly we really shouldn't be naming Mupen64-AMD64 special to 64-bit. Really it doesn't do anything specific to AMD64. Well, OK, some of the code may be specifically there for AMD64 and will only work on AMD64 architectures but that code is not needed for compiling the emulator on other architectures. For example, Mupen64-AMD64 compiles to i386 Linux without any modifications whatsoever. The only real thing you should be worried about with the AMD64 branch (besides if it doesn't compile properly) is that it is not specifically set up to handle the endianness of the PowerPC (Which is backwords of Intel >_<)

[rhetoric]

I don't know how to compile this source.. (64 1.1) I'm a bit of a noob, but I know the default CFLAGS are very wrong (i686 for one). I have no idea what to set though. the file pre.mk seems to be some sort of configure script but it doesn't have ppc included so...

edit: I want to thank you all for your help and attention. I've also been talking with the current developer of pcsx-df about my problems compiling and running that psx emulator. I have fceu working for NES, and snes9x working for SNES on my powerpc linux box so far, and I intend to create a thread on the Ubuntu Forums ppc section dedicated to emulation in ppc linux. The thread will document my experiences with each system and collect input from others. So.. don't think I'm just out to have someone hold my hand I'm trying to make things possible for all ppc linux users, especially idiot noobs like myself :)

[nmn]

No problem :) In the meantime, i have a PPC Mac OSX 10.4 working now. I'll install Linux on a seperate partition, and see if i can add a true port of Mupen64. I may or may not be able to test 3D graphics.

Oh, About the compilation - its pretty straight forward if you have GNU Make, GTK 2.0, and anything else that i forgot. Just enter a terminal, go to the Mupen64-AMD64 source directory, and run "make". Then all you need to do is read the output so you can enter the correct parameters for make the next time.

[Doomulation]

...and it would be kind of ridiculous to call it Mupen64-64 so I settled on -amd64...

Hey, why not call it Mupen4096 (64 x 64)? :D

[GarulfoLinux]

Otherwise Mupen64b, all simply :D

[rhetoric]

Here's what happens. Remember I'm a big noob so.. sorry if I'm missing things that are obvious.

rhetoric@wintermute:/usr/local/src/Mupen64-amd64-1-1-src$ sudo make
Mupen64-amd64 makefile.
Targets:
all == Build Mupen64 and all plugins
clean == remove object files
rebuild == clean and re-build all
Options:
BITS=32 == build 32-bit binaries on 64-bit machine
DBG=1 == turn on debugging functions
DBGSYM=1 == add debugging symbols to binaries
VCR=1 == enable video recording
rhetoric@wintermute:/usr/local/src/Mupen64-amd64-1-1-src$ sudo make all
gcc -o main/adler32.o -Wall -pipe -O3 -march=i686 -mtune=pentium-m -mmmx -msse -ffast-math -funroll-loops -fomit-frame-pointer -fexpensive-optimizations -fno-strict-aliasing `sdl-config --cflags` `pkg-config gtk+-2.0 --cflags` -D_GTK2 -c main/adler32.c
cc1: error: unrecognized command line option "-march=i686"
cc1: error: unrecognized command line option "-mmmx"
cc1: error: unrecognized command line option "-msse"
main/adler32.c:1: error: bad value (pentium-m) for -mtune= switch
make: *** [main/adler32.o] Error 1

[Richard42]

Here's what happens. Remember I'm a big noob so.. sorry if I'm missing things that are obvious.

I got it to compile this morning on a PS3 with just a few small changes. I'll do a proper fix to the makefiles tonight and post a new source package in this thread for you to try. One thing that would help me is if you could post the output of the command 'uname -m' here.

[rhetoric]

I got it to compile this morning on a PS3 with just a few small changes. I'll do a proper fix to the makefiles tonight and post a new source package in this thread for you to try. One thing that would help me is if you could post the output of the command 'uname -m' here.

sure.

rhetoric@wintermute:~$ uname -m
ppc

[nmn]

Well, Generally i'd say change -march="i686" to -march="ppc" and remove -mmmx -msse. I think if we ever did any real port (e.g. one with a recompiler of its own possibly) it would be nice to have altivec support so that we could take advantage of the extensions in PowerPC processors.

[rhetoric]

Well, Generally i'd say change -march="i686" to -march="ppc" and remove -mmmx -msse. I think if we ever did any real port (e.g. one with a recompiler of its own possibly) it would be nice to have altivec support so that we could take advantage of the extensions in PowerPC processors.

Where do I change those in the Makefile? Another file?

BTW I'm just using a ppc laptop, but I'm sure a real ppc linux port would make alot of ps3 users happy as well :)

[Richard42]

Rhetoric, Here is are new source packages with updated makefiles. I haven't tested the RiceVideo one so there may be unforeseen issues but the Mupen64 one should build. If not, post the error messages here.

Building and running are 2 different things, however. :) I believe that the earlier Mupen releases were supposed to run on big-endian machines. And I don't think that any of our recent changes and fixes should have broken this. But the only way to find out for sure is to try. Let us know how it goes.

[nmn]

Earlier i found a PPC port of Mupen64. I think I remember a byte order issue of some sort going on with the RSP plugin on PPCs.

[rhetoric]

I was able to build it, but the RSP settings will indeed not load. I've yet to try building the ricevideo. Where do I put it if I can build it?

Edit: also can't load controller plugin config, only the "about" button works (same as RSP) :( cant load any settings for mupen64 video plugin, but can get settings for glN64. As for sound, I can't load settings for JttL's plugin but the "test" button returns results in the terminal. I can load setting(s) for the mupen64 sound but test does nothing.

I'll try a ROM I guess and let you know. Any especially friendly games people could recommend (so I can hopefully rule out game-related issues)?

Edit2: I think this output in the terminal which appears immediately upon launch of mupen is important:
Couldn't load plugin '/usr/local/src/Mupen64-amd64-1-1-development-src/./plugins/blight_input.so': /usr/local/src/Mupen64-amd64-1-1-development-src/./plugins/blight_input.so: undefined symbol: TTF_WasInit


Edit3: Tried to run Mario Golf, here's the terminal output (the emulation window vanishes when the output stops):

rom size: 25165824 bytes (or 24 Mb or 192 Megabits)
rom loaded succesfully
80 37 12 40
ClockRate=f
Version:1449
CRC: 664ba3d4 678a80b7
name: MarioGolf64
Manufacturer: Nintendo
Cartridge_ID: 4d46
Country Code : 4500
size: 4096
PC= 80025c00
md5 code:7A5D0D77A462B5A7C372FB19EFDE1A5F
eeprom type:0
init timer!
memory initialized
[glN64]: (II) Initializing SDL video subsystem...
[glN64]: (II) Getting video info...
[glN64]: (II) Setting video mode 640x480...
(II) JttL's sound plugin version 1.3
(II) Initializing SDL audio subsystem...
(II) Allocating memory for audio buffer: 65536 bytes.
demarrage r4300
R4300 Core mode: Dynamic Recompiler
PC=a4000044:0
reg[ 0]: 0 0 reg[16]: 0 0
reg[ 1]: 0 1 reg[17]: 0 0
reg[ 2]: 0 ebda536 reg[18]: 0 0
reg[ 3]: 0 ebda536 reg[19]: 0 0
reg[ 4]: 0 a536 reg[20]: 0 1
reg[ 5]:ffffffffc95973d5 reg[21]: 0 0
reg[ 6]:ffffffffa4001f0c reg[22]: 0 3f
reg[ 7]:ffffffffa4001f08 reg[23]: 0 0
reg[ 8]: 0 c0 reg[24]: 0 3
reg[ 9]: 0 0 reg[25]:ffffffff9debb54f
reg[10]: 0 40 reg[26]: 0 0
reg[11]:ffffffffa4000040 reg[27]: 0 0
reg[12]:ffffffffed10d0b3 reg[28]: 0 0
reg[13]: 01402a4cc reg[29]:ffffffffa4001ff0
reg[14]: 02449a366 reg[30]: 0 0
reg[15]: 03103e121 reg[31]:ffffffffa4001550
hi: 0 0 lo: 0 0
apr�s 20480 instructions soit 5000
(II) Cleaning up SDL sound plugin...

[Richard42]

Hmm. You won't be able to use the Dynamic Recompiler; you should set the emulator mode to 'Interpreter' in the main settings dialog. If there are problems with the RSP plugin it might not work at all. We really need a developer who is familiar with Mac/PPC to join this effort, because I can't debug and fix the core problems without access to the hardware. It's gonna have to be all up to NMN on this one.

[rhetoric]

Hmm. You won't be able to use the Dynamic Recompiler; you should set the emulator mode to 'Interpreter' in the main settings dialog. If there are problems with the RSP plugin it might not work at all. We really need a developer who is familiar with Mac/PPC to join this effort, because I can't debug and fix the core problems without access to the hardware. It's gonna have to be all up to NMN on this one.

I thought you had a PS3?

The RSP plugin doesn't seem to work as I mentioned before. Neither does the controller plugin.. which is also troubling...

I tried Interpreter mode and Pure Interpreter mode with the one ROM I have (Mario Golf) and both said Unknown Microcode, asked me to pick one, and crashed.

Also as far as the blight input plugin, check out the first line of this output:

ldd /usr/local/src/Mupen64-amd64-1-1-development-src/./plugins/blight_input.so
linux-vdso32.so.1 => (0x00100000)
libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0x6fe77000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x6fdda000)
libz.so.1 => /usr/lib/libz.so.1 (0x6fda3000)
libc.so.6 => /lib/libc.so.6 (0x6fc3b000)
libasound.so.2 => /usr/lib/libasound.so.2 (0x6fb24000)
libm.so.6 => /lib/libm.so.6 (0x6fa58000)
libdl.so.2 => /lib/libdl.so.2 (0x6fa34000)
libdirectfb-0.9.so.25 => /usr/lib/libdirectfb-0.9.so.25 (0x6f9ab000)
libfusion-0.9.so.25 => /usr/lib/libfusion-0.9.so.25 (0x6f983000)
libdirect-0.9.so.25 => /usr/lib/libdirect-0.9.so.25 (0x6f94f000)
libpthread.so.0 => /lib/libpthread.so.0 (0x6f916000)
/lib/ld.so.1 (0x08000000)


vdso32 seems to be something that's not compiled into ubuntu feisty kernel? The error I get is related to TTF_WasInit which makes no sense as I have SDL_ttf packages installed...

[nmn]

blight is just a bit strange, you might want to try mupen64 basic input to try to get things running. In the meantime, i'll try to download a PPC Linux. All of the download attempts fail...

edit: Ah hah, unknown microcode. Theres a bit of data that needs to be byteswapped for that error to go away, but thats by far the closest you've gotten to running the game. I have to leave very soon, so i'll try to remember to fix this issue when i get back.

[Richard42]

I have a PS3 at work but it's set up for SW development on the Cell processor. I can compile things on it (like I did yesterday) but I believe there are no hardware accelerated 2d/3d drivers so I doubt that mupen64 would run worth a darn. Your problem with the Blight input is because I pulled a linker dependency out which I thought was not necessary. Turns out, it is necessary. :) If you modify the blight_input/Makefile to add $(SDLTTF_LIBS) after the $(SDL_LIBS) under the line that says "blight_input.so: $(OBJ_BLIGHT)", then do a 'make clean' and 'make', this should go away.

[rhetoric]

nmn: here (http://cdimage.ubuntu.com/ports/releases/7.04/release/ubuntu-7.04-alternate-powerpc.iso) is the distro I'm using (non-gui installer)

Look in the same dir if you want a gui installer.

So.. it seems like this RSP plugin is going to be the main obstacle. Hope we're lucky :)

the fix to the makefile for blight works and blight now shows up in mupen and i can use the config (have yet to try it with my controller because it's buried somewhere.. today is cleaning day).

also the basic input plugin is *not* working (cant config), but at least shows up in mupen.

[Surkow]

[...]

also the basic input plugin is *not* working (cant config), but at least shows up in mupen.

I don't think it worked for me from since the beginning. So it's not something to worry about.

[rhetoric]

I don't think it worked for me from since the beginning. So it's not something to worry about.

Yea and with blight working it shouldn't matter, but I figured the information might help some developer(s) in some capacity. Still cleaning the house but once I find the controller and take a break I'll try a couple more ROMs even though the RSP plugin doesn't seem to be working.

edit since no posts after this one yet:

Richard here is the output when I try to make Ricevideo

rhetoric@wintermute:/usr/local/src/RiceVideoLinux-1-1-development-src$ sudo make all
g++ -o OGLGraphicsContext.o -DUSE_GTK `sdl-config --cflags` `pkg-config gtk+-2.0 --cflags` -D_GTK2 -fpic -DPIC -O3 -ffast-math -funroll-loops -mcpu=powerpc -c OGLGraphicsContext.cpp
g++ -o Debugger.o -DUSE_GTK `sdl-config --cflags` `pkg-config gtk+-2.0 --cflags` -D_GTK2 -fpic -DPIC -O3 -ffast-math -funroll-loops -mcpu=powerpc -c Debugger.cpp
g++ -o Video.o -DUSE_GTK `sdl-config --cflags` `pkg-config gtk+-2.0 --cflags` -D_GTK2 -fpic -DPIC -O3 -ffast-math -funroll-loops -mcpu=powerpc -c Video.cpp
g++ -o Config.o -DUSE_GTK `sdl-config --cflags` `pkg-config gtk+-2.0 --cflags` -D_GTK2 -fpic -DPIC -O3 -ffast-math -funroll-loops -mcpu=powerpc -c Config.cpp
Config.cpp: In function ‘bool isMMXSupported()’:
Config.cpp:538: error: unknown register name ‘eax’ in ‘asm’
Config.cpp: In function ‘void ROM_ByteSwap_3210(void*, unsigned int)’:
Config.cpp:2058: error: unknown register name ‘edx’ in ‘asm’
Config.cpp:2058: error: unknown register name ‘eax’ in ‘asm’
make: *** [Config.o] Error 1

[nmn]

Oh, we must've forgotten assembly won't work OOB. Can we get around this?

[rhetoric]

Oh, we must've forgotten assembly won't work OOB. Can we get around this?

What about the problem with microcodes and glN64 (so I don't have to use Rice I guess) and the RSP plugin? No errors from the RSP plugin btw I just can't config.

[Richard42]

What about the problem with microcodes and glN64 (so I don't have to use Rice I guess) and the RSP plugin? No errors from the RSP plugin btw I just can't config.

The problems that you reported in Rice are fixable easily enough, but the ramifications that can come about in an emulator between a little-endian and big-endian CPU architectures are serious. I believe that RiceVideo was written for and only tested on Win32 machines. It could have hard-to-find issues with the PPC processor. From what I've read online, Mupen64 v0.5 was supposed to run properly on the PPC, so it may not be as hard to get running.

[rhetoric]

The problems that you reported in Rice are fixable easily enough, but the ramifications that can come about in an emulator between a little-endian and big-endian CPU architectures are serious. I believe that RiceVideo was written for and only tested on Win32 machines. It could have hard-to-find issues with the PPC processor. From what I've read online, Mupen64 v0.5 was supposed to run properly on the PPC, so it may not be as hard to get running.

The OP in this thread is as far as I got with v0.5... the 64 version at least compiles and runs just the plugins arent working properly/at all. I wasn't really expecting RiceVideo to work, and was hoping I could get by with glN64. Is that not going to be possible? I'm at a loss :(

[Richard42]

I found an old forum thread of people discussing mupen64 on a PPC. One of the posters was MasterPhW - he still hangs around here. Perhaps he can shed more light on the shared library compatibility issue?

I found another tweak to make, and I have applied it to my pre.mk file. I tried to upload the new file but there's something wrong with this forum - the upload failed every time. But you can change it by hand. Just edit line 74 in pre.mk to be like this:
CFLAGS += -mcpu=powerpc -D_BIG_ENDIAN
instead of like this:
CFLAGS += -mcpu=powerpc

Then do a 'make clean' and a 'make'. This will at least get you a little closer.

[rhetoric]

Thanks Richard. That didn't seem to fix anything, but it didn't break anything either.

Here is a screenshot of the furthest I've managed to get. This is in Interpreter mode (although I was able to reproduce in Pure Interpreter mode) with Perfect Dark 1.0 US. When it asked me to choose a microcode I of course chose "Perfect Dark." There is crazy stuttering sound to go along with the picture, btw.

http://64.72.123.87/thumb/5749184/thumb.png (http://www.zshare.net/image/57491840d5e742/)

[sultanoswing]

Now builds without hitch from source on my setup, and using this build, the icons' relative paths are corrected - thanks! (although the icons when selecting "Options > Configure... > Plugins" are still missing)

[nmn]

Sort of the wrong thread, but yes. They've been fixed for a few days now. And yes again, the configure window still needs changing. I have alot of work to do on this though.

[Richard42]

Thanks Richard. That didn't seem to fix anything, but it didn't break anything either.

Here is a screenshot of the furthest I've managed to get. This is in Interpreter mode (although I was able to reproduce in Pure Interpreter mode) with Perfect Dark 1.0 US. When it asked me to choose a microcode I of course chose "Perfect Dark." There is crazy stuttering sound to go along with the picture, btw.

I'm surprised that you got anything to work. I'll take a look at it next week and see if there's anything else that's obviously wrong.

I have all of next week off and my goal is to get dynamic recompilation working natively with 64-bit code. It should be a lot faster than the 32-bit dynarec due to the extra registers, and especially for any games which actually use the 64-bit mode of the r4300.

[rhetoric]

bump (just for fun!). really enjoying mupen on my intel box now at least... anyone tried compiling the latest version on a PPC linux machine yet? i'll try soon (just for fun!)

[juanitobanana]

Hello,
I'm actually on an ibook g4 running ubuntu 8.04, and as far as I understand from this post, a mupen64 version for linux PPC (32 bit) is not available yet. Please let us know if this will be available and will gladly post a how-to on ubuntuforums for all the ubuntu powerpc user out ther!

thanks
Juan