Join Mupen

[nmn]

Last night, I was trying to sign up here to join the projects development team. I sent an email to hacktarux last night because EmuTalk appeared as if it wasn't really sending out emails, but it just took a while and then got placed in my Gmail spam (oops!)

So, Basic overview of how i recently got interested in Mupen... My brother had this urge to play Kirby 64 (lol) and so, He took the obvious choice and ran it in Project 64 initially. I've always been interested only in the "mainstream" (if you will) emulators... But Its been a long time since I've used n64 emulators and I've long abandoned Windows for Linux. So, I tried many drastic measures, Only to find that Mupen worked better anyways (after getting my 32bit GTK libraries to work)

So, Now i want to join the project. I have expeirences with C, C++, GTK+, QT, Some basic emulation and optimizations, and a few other things.

 

[Danny]

Last night, I was trying to sign up here to join the projects development team. I sent an email to hacktarux last night because EmuTalk appeared as if it wasn't really sending out emails, but it just took a while and then got placed in my Gmail spam (oops!)

So, Basic overview of how i recently got interested in Mupen... My brother had this urge to play Kirby 64 (lol) and so, He took the obvious choice and ran it in Project 64 initially. I've always been interested only in the "mainstream" (if you will) emulators... But Its been a long time since I've used n64 emulators and I've long abandoned Windows for Linux. So, I tried many drastic measures, Only to find that Mupen worked better anyways (after getting my 32bit GTK libraries to work)

So, Now i want to join the project. I have expeirences with C, C++, GTK+, QT, Some basic emulation and optimizations, and a few other things.

Well aside from the email you sent, it is open source so even if you didn't join the team you could always work on it yourself

 

[Hacktarux]

Yea, you can download the source code in this thread:
http://www.emutalk.net/showthread.php?t=29643

and start by learning how the emulator work currently.

 

[nmn]

I noticed Mupen was open source. Maybe I'll try porting the newer versions of Rice and see if it fixes the rest of the visual problems that exist on Mupen... (After playing the game, I realized theres a few more bugs than i first noticed.)

Additionally, Recently QT has won me over - I'd always liked GTK for some reason, but QT has advantages that matter more than "ease of use" or "less code"... Perhaps I can port the GUI over sometime...

Or better yet, I could probably just try to get Mupen to build from source and do some optimization work on it. Yeah, For now I'm doing that.

 

[Danny]

Or better yet, I could probably just try to get Mupen to build from source and do some optimization work on it. Yeah, For now I'm doing that.

Sounds good. I presume your focusing on Linux?

 

[nmn]

Yes, But I usually write fully portable code anyways. (Sometimes POSIX threads and POSIX sockets, but never Winsock or Windows threads, or directly programming to the Linux kernel) I'm making Mupen work in 64-bit mode (and cleaning up SDL_ttf so it doesn't use internals, sometime) because my 32-bit builder box isn't booting right now, and -m32 is severely broken on this box (I'll rebuild GCC sometime maybe.)

Its pretty easy - I've made a crap load of progress already... The main reason is so far the only portability issue I'm having is "int = long" on 32-bit processors but long long is the same as long for 64-bit... I'm using #ifdef AMD64 #else #endif a few times around non-portable code and using a -d flag for lack of knowing what/if the defines would automatically be if there were auto ones.

Also, It seems the dynamic re-compiler has been broken for a while. I'm not going to do any major assembly work in 64-bit (I barely do it in 32-bit!) but if i get 32-bit GCC working I'll take a look at it... Perhaps if it can be built without assembly or it doesn't use any, I'll give fixing it a shot.

 

[hugelandmonster]

nmn I am very interested in your progress. If you wouldn't mind I would like to chat with you on instant messenger of your preference.

 

[nmn]

You can catch me on AIM throughout the day. I'm gonna update my profile, but until then:

AIM: notmyname06
MSN (only occasionally i'm there): nmnnotmyname [ a t ] gmail.com

edit: I redid the whole 64-bit port using a new method. Now, its alot cleaner -- i added to the CFLAGS, -Dint64="long long" and now all i had to REALLY do was replace all instances of long long int and long long and longs needed to become ints. Now, as for Mac OSX (on G5 atleast), this probably makes it not work... But without a real G5, its hard to make sure it will work.

So, your probably wondering, does the 64-bit port work? As far as i can tell (I can't compile glN64 yet, but i never could before so i have to solve that issue before i can fully answer this question) Pure Interpreter mode is working.

 

[Surkow]

...

Additionally, Recently QT has won me over - I'd always liked GTK for some reason, but QT has advantages that matter more than "ease of use" or "less code"... Perhaps I can port the GUI over sometime...

...

I assume if you would port it that you would use version 4 of the QT toolkit? Even though I prefer to use Gnome I don't mind using QT based programs.

 

[nmn]

If i port it to QT, Yes, Version 4.

Currently, I'm trying to fix up glN64 to build in 64-bit. I got it building, but now its failing to work.

 

[Danny]

Yes, But I usually write fully portable code anyways. (Sometimes POSIX threads and POSIX sockets, but never Winsock or Windows threads, or directly programming to the Linux kernel) I'm making Mupen work in 64-bit mode (and cleaning up SDL_ttf so it doesn't use internals, sometime) because my 32-bit builder box isn't booting right now, and -m32 is severely broken on this box (I'll rebuild GCC sometime maybe.)

Its pretty easy - I've made a crap load of progress already... The main reason is so far the only portability issue I'm having is "int = long" on 32-bit processors but long long is the same as long for 64-bit... I'm using #ifdef AMD64 #else #endif a few times around non-portable code and using a -d flag for lack of knowing what/if the defines would automatically be if there were auto ones.

Also, It seems the dynamic re-compiler has been broken for a while. I'm not going to do any major assembly work in 64-bit (I barely do it in 32-bit!) but if i get 32-bit GCC working I'll take a look at it... Perhaps if it can be built without assembly or it doesn't use any, I'll give fixing it a shot.

Please don't make the update 64bit only

Both would be great

 

[nmn]

Of course its not 64-bit only. All of the "long" and "long int"s become "int"s which are the same size on 32-bit Intel. 64-bit intels have longs as 64-bit values - Thats where most of the problems are coming from. So, We define what a 64-bit value is with the -D flag. Ex: Add this to the CFLAGS with my new source to get a 64-bit build:

-Dint64="long" -m64

and for the old 32-bit, it would be

-Dint64="long long" -m32

Of course, There needs to be int32, int16, and int8 for fully portable code, but thats for another day

As of now, nothing works, just a blank screen with glN64 - but by examining changes and remaining bad code, i can probably fix that.

 

[Danny]

Of course its not 64-bit only. All of the "long" and "long int"s become "int"s which are the same size on 32-bit Intel. 64-bit intels have longs as 64-bit values - Thats where most of the problems are coming from. So, We define what a 64-bit value is with the -D flag. Ex: Add this to the CFLAGS with my new source to get a 64-bit build:

-Dint64="long" -m64

and for the old 32-bit, it would be

-Dint64="long long" -m32

Of course, There needs to be int32, int16, and int8 for fully portable code, but thats for another day

As of now, nothing works, just a blank screen with glN64 - but by examining changes and remaining bad code, i can probably fix that.

Nice if you need any help either with coding or testing im your man I know of most bugs in it due to being a linux user.

Il add you on msn anyway and we can have a chat

 

[nmn]

Okay, 64-bit port status update.

Video: None work properly, but glN64 is not crashing, just having a tough time with ucode detection

Sound: Works perfectly, which is a sign that the CPU is working perfectly too.

Input: I didn't test, but theres no reason why not.

RSP: Obviously working.

 

[MIO0]

I made my own version of Mupen64 that works on AMD64 a while back. I basically ripped out every trace of the recompiler to do it. I also made extensive use of the fixed size integer types defined in stdint.h.

 

[nmn]

I suppose you never released it? I never saw it... Anyways, I'm getting giberish on glN64 right now, which is better than nothing, but still quite useless... I should port that one unofficial rice plugin, it basically fixes everything the older one left broken (Thats awesome BTW, having 1964 running games Project64 still can't play, not because i don't support Project64, but because its still actively developed and its 1.7 betas can't yet run it either. Both are shaky on wine, but once they begin running, they never stop... too awesome.)

Any does the dynamic recompiler in Mupen64 work at all? Never could get it to work.

I might submit my current 64-bit version if there are enough people here to help me find where i screwed up at. It seems to be a video only problem - I can here the whole intro and the menus of the game (And maybe someday I'll be able to get all of my other roms...)

 

[Surkow]

I love to help with testing...but I'm currently running a 32bit version of Ubuntu. So I obviously can't test the 64bit build.

 

[nmn]

Its not testing so much as its "debugging". I think the error lies in "CopyUnswapping" (possibly paraphrased name) but theres no way in hell i can fix it.

On the other hand, it may lie somewhere else, considering its detecting what i believe is the correct ucode.

 

[nmn]

*bump*

Okay, first graphics are showing in 64-bit. Still seems to be uninteresting to most people, but when i get this done I'll probably start porting the newer Rice plugins

 

[TwistedWhizz]

Crikey! I know nothing whatsoever about coding, but I'm a devoted Ubuntu and Mupen64 user. I'm completely thrilled that someone is actually using their own time to develop Mupen64 further, and I can't wait to see the fruits of this. I know loads of people who are looking forward to trying this out! Sorry I'm no help practically though.

All the best. :mupen64: