What's new

x86 64 bits support

i23098

New member
Is it possible to run in on amd 64 bits? I've tried it but I couldn't, it complains it can't find libSDL although it's there. Most probably muppen was compiled on 32 bit system and my libraries are 64 bits...
Where can I find muppen source code to try a to build it (as long as it as easy as "make" :saint: )?
 
OP
I

i23098

New member
When I wrote the post I didn't find where to download the source code :blush: . Now I have and I got the following message:

main/rom.c:1: error: CPU you selected does not support x86-64 instruction set

:down: Any idea when it will be supported?
 

clredwolf

New member
My AMD-64 experience (errors and all)

I went through an interesting experience trying to get Mupen64 working on my AMD 64 computer. A friend and I were interested in getting a 64-bit emulator for the N64, since we both have AMD 64s and wanted to at least see if it was any faster. This is all under linux, using Ubuntu (latest one, the 'Badger') with GCC 3.4.5. Here are the results of my tinkering:

(WARNING: Long post alert!)

Control:
I compiled Mupen64 on my laptop (as a control, it's an Intel Celeron based model) with suprisingly little warnings (in fact, I don't think there were any warnings). The only modification was that I changed the -mcpu=athlon line in the Makefile to -march=pentium3 (personal preference, and -mcpu is obsolete anyways). I also compiled the TR64 graphics plugin with the same modifications for the laptop.

The laptop runs the latest install of Foresight Linux, with gcc 3.4.4, FYI. Same library versions for everything else, AFAIK.

The AMD 64:
Mupen64 would not compile on the AMD 64 machine without some modification to the Makefile. First thing I did was change -mcpu=athlon to -march=k8, and added the -m64 flag (probably unnecessary). Then, I had to add the flag -fPIC in the Makefile, since the compiler would not finish compiling otherwise (complained that main.o would not compile without that specific option). Then, the compiler got stumped as soon as it hit glN64. The compiler compained of several "loses precision" errors. To circumvent this, I removed all references to glN64 from the Makefile. Now the program would compile, only without the glN64 plugin. The compiler gave several warnings this time, most of them saying either:

"warning: cast from pointer to integer of different size"

or

"pointer targets in assignment differ in signedness".

I can run both the GUI and non-GUI versions of the programs, but none of the demo roms on the download page work. The roms will 'load' fine, but when I hit the play button in the GUI, or when the ROM finished loading in the non-GUI, the program will crash and exit back to the terminal window I loaded them from.

The TR64 plugin would not run without modification to the source code. I had to remove everything marked NCopyTextureRGBA32 in texture.c (including the big function at the end of the file) before the code would compile. I modified the CFLAGS so they reflected the CFLAGS used to compile mupen64, and got similar warnings to the ones shown when I compiled mupen64. I do not know if the plugin works or not, since mupen64 will not run with either TR64 or the Soft GFX plugin. For reference, the TR64 plugin did not work (but did compile) on my laptop either when only the Makefile was modified, so with all that I'm going to assume that problems with this plugin not functioning on the AMD 64 machine do not necessarily relate to the machine having a 64 bit processor.

The Glide64 plugin flat out refused to compile on the AMD64 machine, giving several "loses precision" errors, similar to the ones given by glN64.

All roms I tested with both the dummy audio plugin and jttl's plugin, as well as both Blight's Input Plugin and the Mupen64 input plugin, to eliminate those as possibilities for Mupen64 crashing. The exact same error was given each time, by both the GUI and non-GUI programs. However, the GUI and non-GUI programs themselves report differing errors. The GUI gives:

"Signal number 11 caught:
errno = 0 (Success)"

whereas the non-GUI gives:

"Fatal signal: Segmentation Fault (SDL Parachute Deployed)". Both programs report their respective errors consistently each time I try to run a test ROM with them (regardless of the test rom).

In short, the important stuff compiles on an x86-64 processor, but no ROMs work. The graphics plugins seem to have problems compiling, except the Soft GFX plugin.

I'm writing this as part massive bug report, part 'it-works-this-far' message. I hope this post helps out, please let me know if there is something I should be doing, or if there is something anyone wants me to do!

Not sure what all will be helpful, so I'll attach the following:

Attachments:

mod-output.txt - Output of 'make' with all modifications to Makefile.
cflags-output.txt - Output of 'make' with only CFLAGS changed.
orig-output.txt - Output of 'make' with only mcpu=athlon changed to march=k8 (will not compile otherwise)
Makefile.txt - Fully modified makefile (with glN64 commented out and CFLAGS changed (uncommented CFLAGS are the minimal needed, will not compile without those two; second commented CFLAGS from the top are my modified optimized CFLAGS, that work))

I also have the code compiled with no optimizations and the Makefile completely modified for debugging, but it's too big to be attached.

Hope I've helped in some way!
 

ciruZ

New member
Mupen64 makes assumption about the sizes of types. Since the types have different sizes on x86_64, especally int, you won't get it working. You could force the sizes to the x86_32 sizes, but then you won't really use the 64-Bit instructions of your CPU. You would have a 64-Bit Binary that only uses 32-Bit Instructions then. And I guess that is not what you want.
If you want Mupen64 to use 64-Bit Instructions, you have to wait for the next version.
 

Hacktarux

Emulator Developer
Moderator
It assumes some type sizes but it's not the main problem in porting it... A new target for the dynarec has to be created to generate 64 bits instructions.
 

ciruZ

New member
The dynarec isn't the most important thing, the MacOS X port doesn't have one either. I think it should first run on x86_64 without dynarec, if that works, you can port the dynarec to x86_64.
 

MIO0

New member
I tried to get it to work on AMD64 too. I changed a bunch of data types to ones from stdint.h, but every change broke something else. It also seems that there is no clean way to remove the dynarec. The different CPU cores seem to call functions from each other. I had the idea to try again with the Mac port, which would not have the dynarec, but the archive is in a format that I can't open.

Eventually, I caved in and set up a 32 bit chroot jail. I tried to avoid doing that because my main install took several days to download, and I didn't want to wait that long again. Fortunately, the 32 bit install finished overnight when I finally did it.
 

ciruZ

New member
You don't need a full installation of a 32 bit system. A 64 bit system with a few 32 bit libraries is enough.
 

MIO0

New member
According to the distro docs, setting up a chroot jail is the recommended way to run 32 bit programs. Because the 64 and 32 bit libraries have the exact same name, attempting to install both would result in one overwriting the other(or cause the package manager to fail).

I didn't need a full installation anyway. I just installed the base system, compiler, and dev libraries. I then used the 64 bit X server through TCP/IP.
 

ciruZ

New member
That's why you have /usr/lib and /usr/lib32. In /usr/lib32 are the 32 bit libraries. If your distro overwrites the 64 bit libraries with the 32 bit libraries, then it's broken.
 

Hacktarux

Emulator Developer
Moderator
I'll probably port mupen64 to 64 architecture but i wouldn't expect any improvement on these machines (they're already fast enough to emulate n64 fullspeed in 32bits anyway).
 

caller9

New member
32 bit mode

I'm running Ubuntu's latest as well. I downloaded the mupen64 binary and attempted to run it in 32 bit mode. I got all of the usual XYZ.so.0 missing messages. I went to the ubuntu package mirror, downloaded the appropriate i386 .deb packages and extracted the /usr/lib folders to get the relevant module not the symlink. Placed that module in /usr/lib32 and did an ldconfig to create symlinks etc. Ran mupen64 again, read package missing error, got package, extracted, moved, ldconfig..... until it didn't report any errors

Now I get these warnings and a segfault.


(mupen64:18446): Gdk-WARNING **: locale not supported by Xlib

(mupen64:18446): Gdk-WARNING **: cannot set locale modifiers

(mupen64:18446): Gdk-WARNING **: Error converting from UTF-8 to STRING: Conversion from character set 'UTF-8' to 'ISO-8859-1' is not supported

(mupen64:18446): Gdk-WARNING **: Error converting from UTF-8 to STRING: Conversion from character set 'UTF-8' to 'ISO-8859-1' is not supported
Segmentation fault

If someone has done this successfully on amd64 let a guy know what went wrong.

Any other working amd64 n64 emulator advice would be appreciated as well.
 

clredwolf

New member
Hacktarux said:
It assumes some type sizes but it's not the main problem in porting it... A new target for the dynarec has to be created to generate 64 bits instructions.

Ahh, I see. It's good that you're porting this to 64-bits, even though we probably won't see any improvment in speed (32-bit support is a pain on some distros, even with /lib32 involved).
 

Top