Mupen64Plus

[ari64]

No progress anymore?

What were you expecting? Most games work.

There are some bugs in the floating point code which I'm looking into, but it's not major. There's another little issue with the emulator slowing down after awhile, due to too many code blocks being marked 'dirty' (potentially modified) but it looks like this can be solved by periodically marking pages clean again if they have not been recently modified. I'll post a fix for this when I'm done testing it. I know that some of the graphics aren't quite right but investigating that will have to wait until I get an actual Pandora.

I'm sure there will be a big flood of bug reports once the Pandoras start shipping.

 

[Exophase]

Criminy, give the guy more than a couple weeks before complaining about there not being updates.

 

[Dead1nside]

We all appreciate your work Ari64. Last video of Ocarina of Time was awesome

 

[Adventus]

What were you expecting? Most games work.

Its certainly improved dramatically.

I've actually tested alot of games but was hesitant to post my results here for fear of people getting annoyed that X game doesn't work. Here's what i remember from the current sources, i may add a proper list later:

Spoiler

Mario 64: Works well.
Starfox: Works well.
Mario kart 64: Works well.
Fzero X: Works well.
Snowboard Kids 2: Dynarec works, bad rendering issues (only displays skybox).
Goldeneye 007: Works, its a bit slow.
Perfect dark: Works (after i added a mempak to the controller). Renders fine (runs pretty well actually ~50-80% @ 800mhz).
Banjo Kazooie: Works well, I'm up to the 4th world.
Banjo Tooie: Doesn't work at the moment, has in the past.
1080 Snowboarding: Works well.
Majora's Mask: Shows intro, but doesn't get into game.
Ocarina of Time: Works.
Paper mario: Works well but screen flickers.
Turok 1: Works well.
Turok 3: Works, bit slow.
Diddy Kong Racing: Doesn't work at the moment, has in the past.
Super Smash Brothers: Dynarec works (after i removed some asserts ). Plays fine depending on how many characters your versing, the eyes of the characters aren't rendered though.
Yoshi Story: Dynarec works, has rendering issues (probably can be fixed with framebuffer textures).
Hybrid Heaven: Works well.
V-rally 99: Works, bit slow.
Top Gear Rally 2: Works, bit slow.
Ridge Racer: Works bit slow, cars are rendered black though.
The World Is Not Enough: Works pretty well, renders fine.
Blast Corps: Doesn't work.
Jet Force Gemini: Doesn't work (I think we're missing a 64bit opcode).
Shadowman: Doesn't work.
Indiana Jones: Doesn't work.
Mario party: Works well, has flickering issue.
Mario party 3: Works well, has flickering issue.
Pokemon Stadium 2: Works well. Has a few rendering issues that doesn't affect the gameplay.
Neon Genesis Evangelion: Works, bit slow.
Buck Bumble: Works well.
Knockout Kings 2000: Works bit slow.
Ready to rumble 2: Works bit slow.
Body Harvest: Works bit slow.
Castevania 2 - Legacy of Darkness: Doesn't work.
Custom Robo V2: Works well.
Donkey Kong 64: Doesn't work.
Excitebike 64: Doesn't work.
Extreme-G XG2: Works, rendering problem (only displays skybox).
F1 World Grad Prix 2: Works well.
Gauntlet Legends: Doesn't work.
Glover: Doesn't work.
LEGO racers: Works pretty well.
MACE - The Dark Ages: Works.
Mario Golf: Works slow, has rendering issues.
Mega Man 64: Works well.
Mystical Ninga starring Geomon: Works but really slow.
Mario Tennis: Doesn't work.
Pilot Wings 64: Works, bit slow.
Rayman 2: Works well.
Resident Evil 2: Doesn't work.
Starcraft 64: Doesn't work.
Space Station Silicon Valley: Works ok, has some minor rendering issues (geometry).
Starwars Episode 1 Racer: Works well, but sets wrong viewport for rendering.
Starwars Episode 1 - Battle for Naboo: Doesn't work.
Tony Hawks Pro Skater 3: Works slow, has texture rendering issues.
Wipeout 64: Doesn't work.
Worms Armageddon: Works, has nasty rendering issues.
Sin and Punishment: Works.
Bangai-O: Doesn't work.

I believe the flickering issue with 2d games (and maybe the skybox) can be fixed by using framebuffer textures, which i should be able to add pretty easily but will likely come at a rendering expense. Maybe not using double buffering would works as well, I'm investigating this at the moment.

 

[Exophase]

Paper Mario's flickering problem has been documented before for another emulator, I think that it has to do with frame flushes occurring on an operation they shouldn't occur on. I think MooglyGuy talked about this in his N64 MESS blog.

I am very curious to see how fast glReadPixels can be, though...

 

[Adventus]

Paper Mario's flickering problem has been documented before for another emulator, I think that it has to do with frame flushes occurring on an operation they shouldn't occur on. I think MooglyGuy talked about this in his N64 MESS blog.

I am very curious to see how fast glReadPixels can be, though...

I had a look on the blog, but it wasn't immediately obvious. I know its been documented and I believe fixes exist. From observation it just looks like it expects the render buffer to be the same after its been submitted to be displayed, whereas with double buffering you flip between two buffers. So its only updating the portions of the screen that have been changed without re-rendering the background.

I don't think we actually need glReadPixels, I thought the framebuffer effects used the CPU before, but it looks like its contained within the gfx plugin.... glN64 already has code to handle this stuff, but i need to port it to OGLES2. I would guess it's expensive though, but that might not matter for these 2D games.

 

[kikeminchas]

I'm also following the DaedalusX64 for PSP development. I'm not a developer myself but I have seen reports in the forum about Paper Mario flickering. In the last build this has been fixed, I don't know if the fix is something generic you could use or it's just a hack for this game in particular but I leave the link to the svn here for you Adventus. Maybe it woudl be a good idea to contact Kreationz or Salvy from that project since they are also trying to port a N64 emulator to a limited resources system...

http://daedalusx64.svn.sourceforge.net/viewvc/daedalusx64?view=rev&revision=477

http://forums.daedalusx64.com/

 

[Surkow]

Are there any plans to send patches upstream? I know the developers from Mupen64Plus wouldn't mind receiving patches (and it would prevent fragmentation of projects). It would be nice to officially include an ARM dynarec in Mupen64Plus. Patches for glN64 would be more difficult. Due to licensing issues (more the lack of a license) glN64 has been replaced by a GPL fork of glN64 called Arachnoid. Most of the work would be to port the current work to the new Mupen64Plus 2.0 API. Mupen64Plus has the goal to become platform agnostic.

[quote name=Richard42]The biggest change is that Mupen64Plus is no longer an application; it is now a library, just like the plugins. All of the user interface code has been removed from the emulator core and all of the plugins. With the latest versions of Mupen64Plus, and extra component called a Front-end application is required[/quote]
http://www.emutalk.net/showthread.php?t=50350

 

[Mithrildor]

Criminy, give the guy more than a couple weeks before complaining about there not being updates.

I didnt complain at all, I just asked if there were any updates.

Ok im gonna leave this topic to the devs again, im not replying here anymore

 

[ari64]

Banjo Tooie: Doesn't work at the moment, has in the past.

It never really worked, seems to crash randomly.

Majora's Mask: Shows intro, but doesn't get into game.

Any idea what the problem with this is? It works with the original glN64 on x86.

Jet Force Gemini: Doesn't work (I think we're missing a 64bit opcode).

Hmm.. I hadn't noticed this before since it doesn't crash until you try to start a new game. Doesn't look like 64-bit code, probably something else.

Shadowman: Doesn't work.

Part of the intro doesn't render, game looks okay.

Donkey Kong 64: Doesn't work.

http://code.google.com/p/mupen64plus/issues/detail?id=273

Mario Tennis: Doesn't work.

So there actually is one N64 game that uses the SDR instruction. I never did that instruction because I had nothing to test.

Starwars Episode 1 Racer: Works well, but sets wrong viewport for rendering.
Starwars Episode 1 - Battle for Naboo: Doesn't work.

http://code.google.com/p/mupen64plus/issues/detail?id=323
http://code.google.com/p/mupen64plus/issues/detail?id=324

 

[ari64]

Are there any plans to send patches upstream? I know the developers from Mupen64Plus wouldn't mind receiving patches (and it would prevent fragmentation of projects). It would be nice to officially include an ARM dynarec in Mupen64Plus.

The original dynarec is really slow, so getting the new one merged would be good, but there are a few issues that need to be resolved first.

The floating point stuff needs to be fixed, or at least get rid of the hacks that break the other cores. There needs to be some way of selecting which dynarec you want (perhaps --emumode 3 or something like that. Currently it's an ifdef.) Someone should also check that the mmap stuff works on various operating systems.

Other than that I think it's in pretty good shape.

The x86-64 code generator could be improved, but it does work.

 

[craigix]

Ari, have you tried underclocking the N64 CPU to, say, half of what it is defaulting to (I know it defaults low anyway), to see if some games are still happy?

You might not be one for hacks like that but I know some people like to make up lists of tweaks which work well on certain games.

 

[Adventus]

I'm not a developer myself but I have seen reports in the forum about Paper Mario flickering. In the last build this has been fixed, I don't know if the fix is something generic you could use or it's just a hack for this game in particular but I leave the link to the svn here for you Adventus.

Thanks for pointing this out. The Hack they're using halves the number of VBLANK interrupts in the CPU core. Its definitely not a generic solution but i think a similar hack could be easily added to Mupen64Plus (i could just ignore every second buffer flip in gles2n64).

So there actually is one N64 game that uses the SDR instruction. I never did that instruction because I had nothing to test.

Heh, No great loss, I'm pretty sure gles2n64 cannot render it properly anyway.

Any idea what the problem with this is? It works with the original glN64 on x86.

I'll get back to about this. As i say this list was purely from memory.... i cannot remember the details.

Hmm.. I hadn't noticed this before since it doesn't crash until you try to start a new game. Doesn't look like 64-bit code, probably something else.

I though it failed with "opcode!=0x1A&&opcode!=0x1B".... the 64bit load instructions? Or is there something else going wrong....

EDIT: Ahh i see, its not actually a full 64bit load instruction, it just loads the least/most significant bytes from an 64bit unaligned access.

Do savestates work? I might be able to test DK64 a bit better.

 

[ari64]

Ari, have you tried underclocking the N64 CPU to, say, half of what it is defaulting to (I know it defaults low anyway), to see if some games are still happy?

It's not something I'd experimented with, but I went ahead and tried it with a few games. Generally the games ran slow. Goldeneye kept roughly the same timing but ran at a very low framerate. Zelda OoT normally runs at a fixed framerate and with the CPU underclocked it ran noticably slow. Super Mario 64 slowed down in certain areas.

I'm not a developer myself but I have seen reports in the forum about Paper Mario flickering. In the last build this has been fixed, I don't know if the fix is something generic you could use or it's just a hack for this game in particular but I leave the link to the svn here for you Adventus.

Thanks for pointing this out. The Hack they're using halves the number of VBLANK interrupts in the CPU core. Its definitely not a generic solution but i think a similar hack could be easily added to Mupen64Plus (i could just ignore every second buffer flip in gles2n64).

I wonder what Rice is doing? It still flickers, but not as much as glN64.

I though it failed with "opcode!=0x1A&&opcode!=0x1B".... the 64bit load instructions? Or is there something else going wrong....

EDIT: Ahh i see, its not actually a full 64bit load instruction, it just loads the least/most significant bytes from an 64bit unaligned access.

Yes, it's a 64-bit unaligned load. There seem to be some other problems with Jet Force Gemini besides this though.

Do savestates work? I might be able to test DK64 a bit better.

Save states don't work (or at least loading them doesn't work) and I don't think Donkey Kong 64 works in any version of mupen.

 

[argor]

Banjo Tooie: Doesn't work at the moment, has in the past.

It never really worked, seems to crash randomly.

on the desktop version of mupen64plus Banjo Tooie work somewhat well as long as you don´t go into sertan areas then it will crash
rare was famous for put copy protection into games
it will be some time before you will see perfect emulation of rare games
http://code.google.com/p/mupen64plus/issues/detail?id=311&colspec=ID%20Type%20Component%20Status%20Priority%20Stars%20Milestone%20Owner%20Summary

 

[Surkow]

Are there any plans to send patches upstream? I know the developers from Mupen64Plus wouldn't mind receiving patches (and it would prevent fragmentation of projects). It would be nice to officially include an ARM dynarec in Mupen64Plus.

The original dynarec is really slow, so getting the new one merged would be good, but there are a few issues that need to be resolved first.

The floating point stuff needs to be fixed, or at least get rid of the hacks that break the other cores. There needs to be some way of selecting which dynarec you want (perhaps --emumode 3 or something like that. Currently it's an ifdef.) Someone should also check that the mmap stuff works on various operating systems.

Other than that I think it's in pretty good shape.

The x86-64 code generator could be improved, but it does work.

Thanks for the information. One of the developers told me merging is at the moment not possible due to changes to the underlying cached interpreter code which breaks x86 support. Do you have any plans to port your edits to the 32bit x86 version of the dynarec?

 

[ari64]

Thanks for the information. One of the developers told me merging is at the moment not possible due to changes to the underlying cached interpreter code which breaks x86 support. Do you have any plans to port your edits to the 32bit x86 version of the dynarec?

One of the inefficiencies of the original dynamic recompiler was that it checked the coprocessor status register for every floating point instruction. This really only needs to be done for the first of a group of instructions, and doing so makes it run faster. The hack that I put in to do this was kind of sloppy and breaks things as Cpasjuste described. You can take this out and everything will work (just slower).

Improving this code is a long-term goal, I just haven't gotten to it yet.

I have tested the dynamic recompiler on x86. With all the optimizations enabled, it runs pretty well, eg I can play Ocarina of Time on a 1.6GHz Intel Atom with no frameskip. Majora's Mask is not quite full speed, but close. Given how much complaining there is on the emutalk forums about things being slow, I suspect people would be interested in this.

There are a few things that could be improved on x86. One issue is that it generally loads memory addresses into registers before referencing them. On x86 it's usually better to use absolute addresses, so changing this could result in a slight improvement.

 

[ari64]

http://bunnitude.com/ari64/mupen64plus-arm-20100402.tar.gz


Changes since 20100227:


Better branch prediction for call/return pairs

Move dirty blocks back to the clean list after a while if they remain unmodified

Fixed self-modifying code detection where a compiled block crosses a 4K page

Fixed register allocation for the BC1 instructions

Fixed SLT instructions in delay slots

Fixed LDL/LDR instructions

 

[alucart1984]

http://bunnitude.com/ari64/mupen64plus-arm-20100402.tar.gz


Changes since 20100227:


Better branch prediction for call/return pairs

Move dirty blocks back to the clean list after a while if they remain unmodified

Fixed self-modifying code detection where a compiled block crosses a 4K page

Fixed register allocation for the BC1 instructions

Fixed SLT instructions in delay slots

Fixed LDL/LDR instructions

Wow where/how did you learn coding, if you don't mind me asking? I wish I knew how to code.

 

[Cpasjuste]

I think at this level its not about coding anymore

http://bunnitude.com/ari64/mupen64plus-arm-20100402.tar.gz


Changes since 20100227:


Better branch prediction for call/return pairs

Move dirty blocks back to the clean list after a while if they remain unmodified

Fixed self-modifying code detection where a compiled block crosses a 4K page

Fixed register allocation for the BC1 instructions

Fixed SLT instructions in delay slots

Fixed LDL/LDR instructions

Wow where/how did you learn coding, if you don't mind me asking? I wish I knew how to code.