Mupen 64bit

[nmn]

This is a port of Mupen to 64-bit. It contains the port of glN64, RSP, Mupen64 Software Video, JttL's SDL Audio Plugin, Dummy Audio, Mupen64 Audio, Mupen64 Basic Input, And last but not least, the CPU and GUI. The glN64 port is VERY bad - It will get you through games like Kirby64 but it will quickly become corrupted on games like Mario 64 due to texture (cache?) bugs... Still plays, but with messed up textures. Sometimes you can use savestates to get around this.

--

Status:
Video - 80%, still buggy
Audio - 100%, flawless as far as i can tell
Input - 50%, blights plugin uses SDL_ttf, which will not build on my PC(improper truetype usage) so i could not do much to get it running
RSP - 100%, I can't find very much that could go wrong here because I'm not sure what it does.
CPU - 100%, Interpreter works excellently. DynaRec works exactly the same as it does already on Linux, Meaning not.
GUI - 99%, One little hack still somewhere...

--

I'll be trying to port Rice Video, but please help if you can. I really need it, after doing all of this work I'm beginning to lose my patience.

--

TO BUILD:
Edit Makefile with your favorite text editor... Enable the configuration you want by commenting the already in use configuration and uncommenting the one you want.

When your done, type make onto a terminal in the mupen directory.

OPTIMIZED BUILD IS NOT DEFAULT.
64-BIT BUILD IS DEFAULT.

 

[Tillmann]

Congrats man!

it's nice to see mupen64 running under x64

 

[nmn]

Thanks... I'll just be trying to port Rice which HOPEFULLY doesn't share the same issues with the newer GCCs that glN64 did. (If you look you'll notice some similar standards voilations in the source of Rice Video) Maybe Microsoft is to blame for MSVC being lenient on code it shouldn't be, I don't know. GCC is also to blame though, for having crap inline assembly. I wonder if i should just use ICC for Rice... Or try ICC for everything, considering how fast its made my code in the past... As much as i love GCC, ICC is more practical for porting code from MSVC. Too bad it doesn't do any cross-compiling or else it would be my compiler of choice... Well, Sometimes. For many of my projects, GCC is either more practical, Or its better because it would work and its Open Source.

 

[Tillmann]

Please try to rely on gcc if you can
It would be nice not only for portability but to the opensource community
Cheers and good luck!

 

[Hacktarux]

The dynarec has always worked on linux (x86 32 bits). I'm always testing with this core when developing and i'm sure many people are using it. So if it's not working on your system, i'd be very interested in your exact configuration: distro, glibc version, kernel version, kernel compilation options...

It is normal that it does not work on x64 architecture. The dynarec has to be rewritten for this target processor.

 

[nmn]

Weird, Everyone setup I have can't run with DynaRec, it just crashes. I just figured its broken in Linux like Assembly in glN64 and i didn't bother trying to porting it over.

Heres my setups:

Mupen64 Binary or from source, any version of GCC behaves the same from source.
Either a modified Gentoo (Sabayon) 64-bit distribution or OpenSuSE 10.0 32-bit distribution. My kernel is pretty messed up on 64-bit, but it seems to run OK. My other kernel is the stock OpenSuSE 10.0 32-bit kernel that came with it.

DynaRec seems to crash on all of the games I've tried: Super Mario 64, A whole crap load of Intros, Kirby 64, Some Puyo Puyo Game i have no idea why i have (probably accidentally picked it up when getting PDRoms from regular rompacks).

I'm gonna debug the issue sometime. I did once, but i failed to notice anything wrong.

 

[Richard42]

Hey, I'll help with the 64-bit port. I have a lot of experience in x86 and amd64 assembly language also, so maybe I can get the dyna-rec working natively in 64-bit mode. This is a cool project.

Should I start with the 6.1.0 Rice Video plugin source that was linked in another message, or is there something newer? Does your 64-bit port have any patches/fixes above mupen64 0.5?

Thanks.

 

[nmn]

Hey, I'll help with the 64-bit port. I have a lot of experience in x86 and amd64 assembly language also, so maybe I can get the dyna-rec working natively in 64-bit mode. This is a cool project.

Feel free to help, I'm only so good at assembly ATM... Just keep resubmitting changes and/or whole source packages (if you changed a lot) and I'll find a way to keep the fixes in sync. I'd do diffs, but that can get confusing without source control.

Should I start with the 6.1.0 Rice Video plugin source that was linked in another message, or is there something newer? Does your 64-bit port have any patches/fixes above mupen64 0.5?

Well, There is Mudlords awesome unofficial version if your feeling heroic Theres alot of porting with it to do, but soon I'll submit a glade file for a configuration GUI, which should have equivalent naming.

https://ricevideo.bountysource.com/

Thats not ported to linux yet, though. I was trying to port it but i never came up with any good code because it makes extensive use of WGL code (Though i made an attempt to port that i hadn't finished yoet)

Anyways, yeah, anyone can submit code or full packs here and i'll adopt the code into any of my future versions if it works.

And BTW: Since this version works on both 32-bit and 64-bit, I think it would be OK if we tried to improve any of Mupens weak spots in the rare case that this code ever becomes official. I can tell you right now i wouldn't mind spending a few weeks writing some networking code ontop of Zoidcom or with a plugins system or something.

 

[Richard42]

Thanks for the link. I checked it out, and unfortunately Mudlord doesn't provide the source with the newer versions, so I guess I'll have to stick with 6.1.0.

I've attached a zip of some diffs off of the vanilla 0.5 source which provide screenshot capability in the glN64 driver - it requires libPNG, which means makefile changes. I didn't include a diff for the makefile because my makefile is set to build the 32-bit version on a 64-bit machine. If you want that, I can upload that too.

Richard

 

[nmn]

To get his source, use SVN. Its opensource.

edit: Almost forgot: https://svn.bountysource.com/ricevideo/trunk

You can use your svn utility with that.

 

[niteice]

First off, thanks for providing this groundwork, it's incredible to actually be able to emulate n64 (well) on my box. Unfortunately, there seems to be a nasty bug in glN64 - the same texture is used on almost all polygons:

If it matters, I used GCC 4.1.2, but also have ICC 10 available.

 

[nmn]

Unfortunately, I can not pin point the source of the above bug. I suppose it has to do with texture caching. Its a well known bug, though. It effects games less when they use less textures, but you'll still find most n64 scene intros that worked before biting the dust.

 

[niteice]

Ah OK, I thought it was related to the 64-bit code.

 

[nmn]

Well, It appears to be related to the very few changes in GCC. After i solved my byte swap problems, i noticed that textures were mixed, but it would take some debugging that I'm not up to in order to find the exact roots of the problem... I should really work on Rice Video, but it has assembly code, which makes the default code sometimes not work and is usually not the most efficient after porting.

 

[Richard42]

Well, It appears to be related to the very few changes in GCC. After i solved my byte swap problems, i noticed that textures were mixed, but it would take some debugging that I'm not up to in order to find the exact roots of the problem... I should really work on Rice Video, but it has assembly code, which makes the default code sometimes not work and is usually not the most efficient after porting.

Tell you what; this weekend I'll spend a day and port all of the assembly to 64-bit. I looked around and it doesn't seem to be too much. You'll need to install YASM to assemble the 64-bit code. The stuff which isn't MMX/SSE2 is pointless; I'll convert it to C or verify any existing C code. I can post it here or PM me with your email address.

 

[nmn]

That sounds great... Love to see that.

And as for where to put it, just put it up on here.

 

[Richard42]

Hello NMN,

I have ported the ricevideo-6.1.0 plugin to the 64-bit architecture, and also worked on your port of mupen64 itself. The zips are attached here, but I have opened also up an SVN server, the URL of which is:

svn://fascination.homelinux.net:7684/mupen64-amd64/trunk/

The svn login is 'mupen64', and the password is 'Dyson5632-kart'. Anyone who feels qualified is welcome to commit fixes or improvements, providing that you also write a good commit log message.

So, the RiceVideo port was fairly straightforward – I changed the data types as necessary and re-wrote the assembly code. I found a couple of notable things in this code. The assembly stuff was fairly messy; I deleted some of it and replaced with straight C code, and ported the rest. The changes which I made to the RiceVideo vanilla build should be portable, and it should still build just fine in both Windows and 32-bit Linux, though I didn't test this. If you use this video plugin with a different version of Mupen than what I've put here, you should make sure that the data types in the GFX_INFO structure in 'winlnxdefs.h' are the same as in your version of Mupen. Otherwise it may hang or GPF. Also, you must have the RiceVideo6.1.0.ini file in a subdirectory called 'plugins' relative to the location of the executable. Otherwise it may throw a bunch of GTK warnings and crash.

I made some modifications to Mupen64 also. I started with the vanilla 0.5 source which I had earlier patched for saving PNG files from the glN64 plugin. Then I merged in most of your changes for the 64-bit port. I did it a little differently though. To avoid having a definition for the int64 type, I used 'long long' everywhere for 64-bit integers. This will work on both 32-bit and 64-bit systems. There were a couple of discrepancies that I saw while merging, and I don't know if your code was newer or if mine was newer, so this is something that remains to be resolved.

I modified the makefile to add the 'SDL_ttf' library to the build, so that the blight input plugin would link, because the Mupen one doesn't recognize my joystick. It built, but crashed upon startup. I debugged it and found the cause to be that the SDLK_* enum consists of all positive numbers, and in this case the compiler forces the enum to be an unsigned int. One of the SDL routines was returning a -1 for this value, causing an array to be indexed by 2^32-1, and crash. I fixed this and now the blight input plugin works, so I was able to really play some N64 games in 64-bit on the PC! Super Mario 64 looked very good and ran at full speed with the Interpreter on my Athlon64 3800x2. Mario Kart 64 reveals that there is still a porting issue in the RiceVideo plugin – sometimes the polygons in the road flash gray.

There are a lot of little things that need to be fixed or cleaned up in this source code. I'll try to get a few more things done on this in the next week or so. The ultimate goal is to port the dynamic recompiler, but that could be a big project.

Richard

 

[nmn]

_WOW_

Thats extremely good. Man. You should be the one leading me.

 

[Richard42]

_WOW_

Thats extremely good. Man. You should be the one leading me.

Thanks. I write software for a living; I love it. The nice thing about open source is getting such a huge base of high quality software for free, which others have poured so much time and effort into. Now it's my turn to give back and get involved too.

Having a source control repository is very important for working together and making controlled progress. Sending zip files doesn't scale. I just hope others will take advantage of this and contribute; using SVN is a piece of cake. There are a lot of little things which need to be fixed: the printout of the selected plugins is incorrect, the program segfaults when exiting about half the time, the command-line options and config file stuff is all messed up. I looked at the SVN commits on Mudlord's server for Rice Video since 6.1.0; there are only about 5 of them that are relevant, so they could easily be merged.

We could make the 64-bit port just as good as the 32-bit one. The AMD64 instructions are extremely advantageous for the performance of this emulator; 64-bit is the way to go.

 

[nmn]

Yes. I write software as a hobby ATM. I'm only in high school right now, but i highly support Open Source Software and the ability to also sell the products for a nominal fee (Of course alongside the source being free, Kinda like Crossover office and nothing like Cedega who just don't understand).

SVN rocks, glad you have a server up for it.

Also, since our port goes backwards, I believe that we should attempt to improve the emulator beyond the core. I think we should try to improve it GUI wise, and feature wise, too. Kaillera seems to be in the windows build. It shouldn't be too hard to have that code ported to a library like Zoidcom or POSIX networking (Not SDL_net, but only because SDL_net is blocking only and its not thread safe either.)

So I have a question: You agree we should try to improve it too?
And also, as a side question: about removing int64. I know that using long long is safe. The point here is that C and C++ don't define the sizes of the types. This leaves a large problem: Architectures, even in other little-endian ones, won't be guaranteed to have the same type sizes... ARM comes to mind... Shouldn't we try to make all of the basic types customizable? Or is there another way? And this makefile dislikes my computer. It picks the wrong libs. I'll modify my pkgconfig files later on and see if i can fix that.