What's new

OSX/X11 (i.e. ppc support)

sinclair44

New member
I'm trying to get 0.4 working on OS X (again). I'm okay using the X11/gtk environment, but I'm having some problems running it. Here's what I've done to get it to compile:

- modify the SDL test and makefiles to use `sdl-config --cflags` and `sdl-config --libs` as apopriate
- remove #include <malloc.h> in a bunch of places
- comment out the x86 asm in r4300/x86/rjump.c - this is probably the cause of my problems, or the next one :) removing random code is not generally a good idea, I know, but I wanted to get it to compile :)
- copy a bunch of signal defines from some page on the internet into main/gui_gtk/main_gtk.c - OS X was missing a few, so I copied the whole lot from another OS, I think BSD... again, probably not a good idea, but I wanted it to compile :)

Well, the interface runs, and can load a ROM, but it crashes when I try to run it (yes, I expected that to happen!!! it actually got farther than I thought it would). Here's a transcript of me loading Mario 64 and trying to run it:

Code:
Couldn't read config file '/Users/josh/Desktop/emu64/.//gui_gtk.conf': No such file or directory
rom size: 8388608 bytes (or 8 Mb or 64 Megabits)
file found
rom size: 8388608 bytes (or 8 Mb or 64 Megabits)
byteswaping rom...
rom byteswaped
rom loaded succesfully
80 37 12 40
ClockRate=f
Version:1444
CRC: 635a2bff 8b022326
name: SUPER MARIO 64      
Manufacturer: Nintendo
Cartridge_ID: 534d
Country Code : 4500
size: 4096
PC= 80246000
md5 code:20B854B239203BAF6C961B850A4A51A2
eeprom type:0
init timer!
memory initialized
demarrage r4300
dynamic recompiler
Signal number 4 caught:
	errno = 0 (Unknown error: 0)

My problems now:
- fixing the 3 lines of x86 asm in the whole project! They're all in r4300/x86/rjump.c
- finding the right header/defines for main/gui_gtk/main_gtk.c
- since the ROM loads sucessfully, I assume there are no endian issues... Flea got them fixed?

(To OS X users: there's really very little hope of this working, but I figured it was worth a shot.)

Thanks for any help or insight... and I apologize for any incoherentness in the above post... it's late.
 

Hacktarux

Emulator Developer
Moderator
sinclair44 said:
I'm trying to get 0.4 working on OS X (again). I'm okay using the X11/gtk environment, but I'm having some problems running it. Here's what I've done to get it to compile:

- modify the SDL test and makefiles to use `sdl-config --cflags` and `sdl-config --libs` as apopriate
- remove #include <malloc.h> in a bunch of places
- comment out the x86 asm in r4300/x86/rjump.c - this is probably the cause of my problems, or the next one :) removing random code is not generally a good idea, I know, but I wanted to get it to compile :)
- copy a bunch of signal defines from some page on the internet into main/gui_gtk/main_gtk.c - OS X was missing a few, so I copied the whole lot from another OS, I think BSD... again, probably not a good idea, but I wanted it to compile :)

Well, the interface runs, and can load a ROM, but it crashes when I try to run it (yes, I expected that to happen!!! it actually got farther than I thought it would). Here's a transcript of me loading Mario 64 and trying to run it:

Code:
Couldn't read config file '/Users/josh/Desktop/emu64/.//gui_gtk.conf': No such file or directory
rom size: 8388608 bytes (or 8 Mb or 64 Megabits)
file found
rom size: 8388608 bytes (or 8 Mb or 64 Megabits)
byteswaping rom...
rom byteswaped
rom loaded succesfully
80 37 12 40
ClockRate=f
Version:1444
CRC: 635a2bff 8b022326
name: SUPER MARIO 64      
Manufacturer: Nintendo
Cartridge_ID: 534d
Country Code : 4500
size: 4096
PC= 80246000
md5 code:20B854B239203BAF6C961B850A4A51A2
eeprom type:0
init timer!
memory initialized
demarrage r4300
dynamic recompiler
Signal number 4 caught:
	errno = 0 (Unknown error: 0)

My problems now:
- fixing the 3 lines of x86 asm in the whole project! They're all in r4300/x86/rjump.c
- finding the right header/defines for main/gui_gtk/main_gtk.c
- since the ROM loads sucessfully, I assume there are no endian issues... Flea got them fixed?

(To OS X users: there's really very little hope of this working, but I figured it was worth a shot.)

Thanks for any help or insight... and I apologize for any incoherentness in the above post... it's late.

You must define the _BIG_ENDIAN macro in your compiler settings (adding -D_BIG_ENDIAN to your gcc flags should be enough). Using a foreign OS headers for signal will probably not work, anyway if your OS don't support unix signals, don't worry, you can safely comment the signal handling part, everything will still work.

Remember that you can't use dynamic compiler on PowerPC without rewriting it for your CPU (it's the whole x86 folder). So, the 3 asm lines are useless for you because even if you translate them, the rest of the compiler won't work (unless you want to rewrite the compiler of course :p)
 
OP
S

sinclair44

New member
Hacktarux said:
You must define the _BIG_ENDIAN macro in your compiler settings (adding -D_BIG_ENDIAN to your gcc flags should be enough). Using a foreign OS headers for signal will probably not work, anyway if your OS don't support unix signals, don't worry, you can safely comment the signal handling part, everything will still work.

Remember that you can't use dynamic compiler on PowerPC without rewriting it for your CPU (it's the whole x86 folder). So, the 3 asm lines are useless for you because even if you translate them, the rest of the compiler won't work (unless you want to rewrite the compiler of course :p)

Okay, the endian stuff makes sense. But could you elaborate on the dynamic compiler (i.e. why it can't be ported to ppc without rewriting it)? I guess from the context that it dynamically turns the N64 asm into x86 asm or something?
 

Hacktarux

Emulator Developer
Moderator
the code that is in x86 folder is the code that tells how to translate n64 asm code into x86 asm code.
If you don't know what a dynarec is more precisely, use the search button of this forum, i'm sure it has been explained a lot of times.
 

LEgregius

New member
Plugins

I have gotten Mupen64 0.4 to work in Mac OS X in interpreter mode without crashing. I assume the plugins have mac ports around. At least the glN64 plugin does not compile on OS X without modifications. Since they have been used in version 0.3, they must have been ported. Where could I get said code?
 

Hacktarux

Emulator Developer
Moderator
it can be found inside the macosx port source code, it may not be very convenient to use but well... that's better than nothing. This source code has been posted by adam on emuscene.com forum.
 

timdoug

New member
Hey all,

I've been trying my hand on porting mupen64 to Mac OS X, and here are my results so far (thanks to information on this board, others, and other websites):

Completed:
- actually compile (Makefile changes, #includes and such)
- rjump.c from the old 0.3 Mac port
- GTK gui (I thought it much easier to use it than code my own)
- porting of the input plugin

Partially completed:
- Plugin loading support. I've figured out how to load symbols from other files with OSX "bundles" (because shared objects are not supported), but it does not work perfectly well: mupen64 gets the name of the plugin, but calls don't seem to work (nothing happens when the about button is clicked with the input plugin, which should bring up a GTK dialog box).

Still to do:
- glN64 plugin. I'll probably end up taking the code from the old Mac port.
- RSP plugin. same here.
- sound plugin. should be really easy; it's just a couple of SDL calls.

So the biggest barrier I see in getting this to work now is just figuring out what's not working with the plugin loading (and any endianness issues that are sure to come up). I'd love to collaborate with anybody else on this, if they want. I'll also post a patch of what I've done so far if there's interest.

Oh, and attached is a screenshot of the current behaviour.

Cheers!
-timdoug
 

Hacktarux

Emulator Developer
Moderator
Good job, unfortunately i can't help as i know nothing about shared objects and MacOSX... but good luck !
 

timdoug

New member
WOOHOO! :bouncy:

Sound doesn't work (very scratchy, but can barely make out certain tones...is the the sound plugin's fault or HLE plugin's fault?), and input doesn't seem to work, but look at this!

More updates to come.
-timdoug
 

MasterPhW

Master of the Emulation Flame
timdoug said:
Hey all,

I've been trying my hand on porting mupen64 to Mac OS X, and here are my results so far (thanks to information on this board, others, and other websites):

Completed:
- actually compile (Makefile changes, #includes and such)
- rjump.c from the old 0.3 Mac port
- GTK gui (I thought it much easier to use it than code my own)
- porting of the input plugin

Partially completed:
- Plugin loading support. I've figured out how to load symbols from other files with OSX "bundles" (because shared objects are not supported), but it does not work perfectly well: mupen64 gets the name of the plugin, but calls don't seem to work (nothing happens when the about button is clicked with the input plugin, which should bring up a GTK dialog box).

Still to do:
- glN64 plugin. I'll probably end up taking the code from the old Mac port.
- RSP plugin. same here.
- sound plugin. should be really easy; it's just a couple of SDL calls.

So the biggest barrier I see in getting this to work now is just figuring out what's not working with the plugin loading (and any endianness issues that are sure to come up). I'd love to collaborate with anybody else on this, if they want. I'll also post a patch of what I've done so far if there's interest.

Oh, and attached is a screenshot of the current behaviour.

Cheers!
-timdoug
Okay, [email protected] for the off topic, but these guy did finally a great example of the first post in this board:
NO rom request, NO beta request, NO "when comes that"...
He's trying to help! (Never thought that this still exists!)
Greet, thanks god, such guys are still out there!
And, good luck for your project timdoug and welcome to ET!
I'm not using a mac and never was, but great to see that someone is trying to help the mac users too!

Sorry again for my :spam:
 

Top