mupen 64 on Eee PC?
- Thread starter BomarJr
- Start date
GarulfoLinux
New member
I don't know but you can always try to run Mupen64 and posting here your feedbacks for others users of eeePC 
The 900MHz Celeron-M is probably right on the edge of being able to emulate the r4300 at real-time speeds with the dynamic recompiler. It should be pretty close. The deciding factor will be the graphics chipset. If it's fast enough then you should be able to get a pretty good gaming experience running without sound on this machine. I'm actually one of the Intel community testers for their open source driver development. I did a little searching to see if I could find out more about this UMA chipset but I couldn't find many details. Is it based on the 965? The 945? Right now their drivers are very hosed for the 965 but they are slowly fixing bugs.
I agree with Garulfo - If you buy the EEE you should definitely give it a try and post your findings here.
I agree with Garulfo - If you buy the EEE you should definitely give it a try and post your findings here.
I am planning to install eeeXUbuntu this weekend on my EEE. Just need to image my Windows install first.
I'll let you know how it goes and my thoughts on it. I'll try to post some video as well.
Also to note the EEE actually has a GMA910 chip. Using Project64 under Windows runs great. Very little audio snafu's if any most of the time.
I'll let you know how it goes and my thoughts on it. I'll try to post some video as well.
Also to note the EEE actually has a GMA910 chip. Using Project64 under Windows runs great. Very little audio snafu's if any most of the time.
Last edited:
F
fbff
Guest
I don't think so. From memory a 2Ghz chip is needed to run full speed with sound. Turning off the sound ain't gonna help that much.
The sound processing doesn't take a lot of CPU time, but with the sound on it's very obvious when the frame rate drops below real time, because you get stuttering. With the sound off you may not notice small dips in the frame rate. I have a 1.8 GHz dual core Athlon64 and with the 32-bit dynarec most games seem to take about 50% of one CPU to run at real time. There is a high variability in the IPC of various chips, ie a 1 GHz Core 2 chip is probably faster than a 2GHz Pentium 4. The Pentium-M is actually a pretty good design so he might have a chance of getting a decent gaming experience with the Celeron-M.
I'm happy to report that the EeePC runs Mupen64 quite well... even with sound on. I've only tested mario64 so far
I get about 15-20fps when the CPU is running at its default 630mhz
and around 20-30fps when running the CPU at 900mhz.
oh and a note about that: the EeePC comes out of the box with its FSB underclocked to 70mhz, which limis the CPU to 630mhz. No idea why ASUS did this (as the hardware itself is designed to run at full speed), but regardless, it does affect 3D games a little (althought thats about all). Its not really a huge task to "overclock" the CPU back to 900mhz, you can find information about doing so at http://wiki.eeeuser.com/howto:overclockfsb
Also, somewhat off topic but, the EeePC is one hell of a machine, The CPU actually performs on par with my old celeron 2ghz.
I get about 15-20fps when the CPU is running at its default 630mhz
and around 20-30fps when running the CPU at 900mhz.
oh and a note about that: the EeePC comes out of the box with its FSB underclocked to 70mhz, which limis the CPU to 630mhz. No idea why ASUS did this (as the hardware itself is designed to run at full speed), but regardless, it does affect 3D games a little (althought thats about all). Its not really a huge task to "overclock" the CPU back to 900mhz, you can find information about doing so at http://wiki.eeeuser.com/howto:overclockfsb
Also, somewhat off topic but, the EeePC is one hell of a machine, The CPU actually performs on par with my old celeron 2ghz.
- Thread Starter
- #8
well thanks to anybody who tried and letting me know the results. one more reason on why i should get an eee pc.
also, they said (wikipedia) that memory is not recoverable on eee pc. is that true?
and thanks evilgold, i didn't know that they limited the speed to 650 and if i get one ill make sure to install that kernel.
also, they said (wikipedia) that memory is not recoverable on eee pc. is that true?
and thanks evilgold, i didn't know that they limited the speed to 650 and if i get one ill make sure to install that kernel.
Last edited:
well thanks to anybody who tried and letting me know the results. one more reason on why i should get an eee pc.
also, they said (wikipedia) that memory is not recoverable on eee pc. is that true?
and thanks evilgold, i didn't know that they limited the speed to 650 and if i get one ill make sure to install that kernel.
Not sure what they meant by memory not recoverable. The EEE does use an internal SSD (2/4/8 gig depending on model). I've personally reinstalled on mine about 4 times total now while playing around with stuff (twice with default OS and twice with Windows). My understanding is ALL SDD devices like this do have a more limited life, however many users have done the math for MTBF and it seems you will get a good number of years from it even with lots of writes. And actually even if the SSD were to die you can always also use a SD card, flash drive, or external HD on the system no problem. I boot from all 4 devices quite easily for doing a number of different things.
I did get eeeXubuntu installed this weekend. I followed this wiki for tips on setup specifically for the EEE. As well as followed the installation of Compiz it pointed to. Everything went great except my Grub install. I was installing to my external USB drive which is HD2 when booting from a flash drive, but turns into HD0 when you boot from it directly. I decided that I wanted to keep my Windows install on the SSD, but did not want Grub on there. So I selected HD2 during the eeeXubuntu install, but my Grub script had HD2 on boot up and it could not "find" itself? So I had to change it to (HD0,0) and all is well.
Now I'm a little green about the whole Compiz program as it's my first time using it really. Is Compiz the same thing as Beryl or do they just generally get talked about at the same time? I only installed Compiz I guess again based on the link in the above wiki. Everything went fine and I have all the wobbly windows and spinning cube desktop I can stand.
I install Mupen64 by downloading directly from the Mupen website. I had an isue at first where I couldn't see or pick all the plugins properly. I finally sorted out this to be an issue with eeeXubuntu install libstdc++6 by default and Mupen64 needs libstdc++5. After installing it all was well with Mupen64.
Runs quite well. Sound was a tad choppy and seemed to get better, but like evilgold, I only tried Super Mario 64 so far. I didn't notice any speed issues while actually playing. I did have Compiz running. And I did not change my clock speed when testing. So I'm sure it would have been even better had I done so.
All in all I would say a success. I do plan to do a video soon of it running. Maybe today if I can just a matter of time thing. Wife, kids, life, work, Super Bowl weekend, etc... etc...
Last edited:
RJARRRPCGP
The Rocking PC Wiz
You shouldn't need 2.0 Ghz or higher with most games. The most taxing appears to be Rare games.
But, should have at least 1.2 Ghz for most games.
Last edited:
Flash
Technomage
Mupen64 isn't much slower than PJ64. As for UHLE - do you remember how many games it runs. Fully playable, w/o glitches ? Super Mario 64, Doom 64 аnd a few others. Mupen64 runs 96% of N64 games. And it isn't a bunch of hacks glued together, there's still a lot of HLE but there's also many things emulated at low level.
P.S. Zelda OOT was quite slow on faster machine (K6-2 333Mhz)
P.S. Zelda OOT was quite slow on faster machine (K6-2 333Mhz)
I didn't mean to flame, just to point out that things could be made a little faster and some of us with low-end PCs would highly appreciate it.
On my PIII 750 with Radeon 9700 Pro (dual boot), in Windows Project 64 works and is playable, Mupen's Windows build is not, it's too slow. In Linux with fglrx drivers, Project 64 is just playabe under WINE (40 fps average/ occasional audio stuttering). Mupen64 is not playable on my machine. Either with the fglrx driver, (too many artifacts - this is a driver issue ATI refuses to fix) or the open source radeon driver and Rice Video plugin (no textures - missing the Quake ARB2 extension in the driver the plugin seems to need) or glN64 (too slow).
On my PIII 750 with Radeon 9700 Pro (dual boot), in Windows Project 64 works and is playable, Mupen's Windows build is not, it's too slow. In Linux with fglrx drivers, Project 64 is just playabe under WINE (40 fps average/ occasional audio stuttering). Mupen64 is not playable on my machine. Either with the fglrx driver, (too many artifacts - this is a driver issue ATI refuses to fix) or the open source radeon driver and Rice Video plugin (no textures - missing the Quake ARB2 extension in the driver the plugin seems to need) or glN64 (too slow).
Last edited:
I've done a fair amount of profiling Mupen64 and can tell you where the CPU time is going. The graphics plugins use a relatively small amount of CPU time: 10% or less with a fairly modern card. If your card or its drivers are slow, this could eat up a lot of time but with most newer cards this won't be a bottleneck. The majority of the CPU time (60-70%) is taken up by the R4300 processor emulator. The MIPS processor ran at 95MHz in the N64, so emulating it with anything less than a 10x faster CPU (1GHz) machine is challenging. You must use the Dynamic Recompiler in order to get the highest performance - it is about 2x faster than the Interpreter.
It would be unfair to compare the speed of PJ64 using a dynarec and Mupen64 using an Interpreter. The 32-bit Dynarec in Mupen64 is already pretty fast, and it's unlikely that it will see any big speed gains with further optimization.
I have an EEEpc with Ubuntu installed and Mupen loads the GUI set everything up double click the rom and the program crashes. When I navigate to the directory in Ubuntu and try to run mupen64 from terminal I get
bash: cd: mupen: No such file or directory
I'm using mupenamd64 as per link in the forums, the standard version from the homepage seems to crash loading a game.
The game I'm trying is LOZ:OOT
may I add that the same version works fine on my desktop under Ubuntu
bash: cd: mupen: No such file or directory
I'm using mupenamd64 as per link in the forums, the standard version from the homepage seems to crash loading a game.
The game I'm trying is LOZ:OOT
may I add that the same version works fine on my desktop under Ubuntu
What graphics plug-in are you using?
If you're trying only Rice, it may be the Quake ARB2 or some other OpenGL extension issue. I find the glN64 is less demanding in terms of extensions.
The EEE PC runs an Intel GMA900 graphics chip which a) isn't very fast and b) lacks hardware transforms for a lot of extensions.
This may be a driver issue, or an its just not fast enough issue. I know MESA has received a lot Intel updates recently, so it might be worthwhile (if you're comfortable doing this - I should warn this is a great way to waste a day and fubar your install) to recompile a newer version of X.org, libdrm, and MESA / i915 dri module and see if that makes a difference. I see a noticeable difference in the performance of the radeon dri module for MESA between Debian stable and git.
I'm assuming your desktop has a half-decent GPU, Intel i965 or something Nvidia/ATI and is using a different driver.
If you're trying only Rice, it may be the Quake ARB2 or some other OpenGL extension issue. I find the glN64 is less demanding in terms of extensions.
The EEE PC runs an Intel GMA900 graphics chip which a) isn't very fast and b) lacks hardware transforms for a lot of extensions.
This may be a driver issue, or an its just not fast enough issue. I know MESA has received a lot Intel updates recently, so it might be worthwhile (if you're comfortable doing this - I should warn this is a great way to waste a day and fubar your install) to recompile a newer version of X.org, libdrm, and MESA / i915 dri module and see if that makes a difference. I see a noticeable difference in the performance of the radeon dri module for MESA between Debian stable and git.
I'm assuming your desktop has a half-decent GPU, Intel i965 or something Nvidia/ATI and is using a different driver.
@Tillin9
I think that's not due lack of ARB2 in Mesa's r300 driver with your ATI 9700 (that card is fast enough for all N64 games, even with Mesa), PIII processor is slow to get realtime performance with Mupen64, even with Dynarec.
When downclock Athlon 2200+ procesor to 1350MHz i get graphic glitches and scuttering in sound, but when use it's default values (1800MHz) i get realtime performance in almost any game with perfect sound. Also when i slightly overclock to 2000MHz all games that plugins patronize works great... So, i assume that 2GHz=> processor is needed to play any game in Mupen64.
edit: I use Mesa 7.03beta, r200 driver on ATI9250 and prefer Glide64 v12 plugin.
I think that's not due lack of ARB2 in Mesa's r300 driver with your ATI 9700 (that card is fast enough for all N64 games, even with Mesa), PIII processor is slow to get realtime performance with Mupen64, even with Dynarec.
When downclock Athlon 2200+ procesor to 1350MHz i get graphic glitches and scuttering in sound, but when use it's default values (1800MHz) i get realtime performance in almost any game with perfect sound. Also when i slightly overclock to 2000MHz all games that plugins patronize works great... So, i assume that 2GHz=> processor is needed to play any game in Mupen64.
edit: I use Mesa 7.03beta, r200 driver on ATI9250 and prefer Glide64 v12 plugin.
@kosmi, this isn't a performance issue. My FPS in Rice and glN64 are roughly the same. The r300 driver just lacks ARB2 and other extensions: http://megahurts.dk/rune/r300_status.html This manifests as missing textures in Rice. With fglrx the textures are there, though there are other issues. I'd be interested to know if your r200 card can do these extensions. As far as CPU, I know mine is on the slow side. However, if Project64 can do it, we should be able to as well.
No, r200 based cards is not OpenGL 2.0 (GLSL) capable or 1.5, neither 1.4, but use some of extensions and functions from it in hw. Yes, Mesa/DRI miss GLSL for r300>=, that is what Quake4 needs for ARB2 interact, but it work good with r200 interact (Doom3 also). Note: Both games needs some minimum CPU power (Doom3-PIII@1GHz and Quake4-PIV@2GHz). Fglrx has GLSL in drivers for r3xx>=
and Quake4 ARB2 interact will work, but i know that fglrx also not perform well in bunch of other cases.
But that is not point for Mupen64, it is matter of plugin in use. If Rice or glN64 dont work good for you due lack of extensions in Mesa or bugs in fglrx or maybe bugs that these plugins have, i suggest you to compile Glide64-wonder+ v12 and use it with Mupen64amd64 v1.2.
And for CPU slowness, you can try to recompile everything with optimization for PIII, but i'm sure that most games will not performs realtime.
edit: that r300_status from megahurts is pretty old
and Quake4 ARB2 interact will work, but i know that fglrx also not perform well in bunch of other cases.
But that is not point for Mupen64, it is matter of plugin in use. If Rice or glN64 dont work good for you due lack of extensions in Mesa or bugs in fglrx or maybe bugs that these plugins have, i suggest you to compile Glide64-wonder+ v12 and use it with Mupen64amd64 v1.2.
And for CPU slowness, you can try to recompile everything with optimization for PIII, but i'm sure that most games will not performs realtime
.edit: that r300_status from megahurts is pretty old
Last edited: