Progress Report: Wii64 Dynarec (Part 1)

In the past few months, we’ve made significant progress on the Wii64 dynarec.  Most of the bug fixes are pretty minor fixes like correcting off-by-one or other various memory errors; however, there are several substantial changes to both the infrastructure and features of the dynarec.

On the N64, there is a register called Count which keeps track of how many cycles the system has been running.  This is primarily used to determined when interrupts can be taken.  In Mupen64, Count is estimated as 2 cycles per instruction executed.  Some emulators actually increment Count differently depending on which instruction ran (because on the hardware, some instructions will take longer to execute).  The fact that Mupen was doing really well with the Count estimate led me to believe that getting an exact Count was unnecessary, and I initially tried playing some tricks to estimate without explicitly keeping track of Count.  However, I quickly discovered that even deviating from the way Mupen counts will quickly result in crashes and freezes.  Several major fixes have involved correcting edge-cases which caused Count to be somewhat off.

Initially only 32-bit integer instructions were supported in the dynarec (they comprise most of the ISA, and I just wanted to get something working before I tried anything too complicated).  Once I got the dynarec running with just those basic instructions, it was still fairly slow because a lot of instructions were still being interpreted (thus trumping any performance benefits of the dynarec).  Getting the floating-point and 64-bit instructions (which aren’t used all that often as the name N64 would lead you to believe) supported in the dynarec were important for improving the dynarec performance beyond that of the pure interpreter.

With the exception of the way floating-point comparisons and conversions are done in MIPS vs PPC and MIPS’s sqrt, floating-point was fairly straightforward to implement in the dynarec as most instructions had a 1-1 mapping.  Even the comparisons were relatively simple although they do not take advantage of what I feel is a more rich FP comparison on the PPC.  However, since the Wii does not have a floating-point square root instruction, it was difficult to support the MIPS sqrt instruction in only a few instructions.  We did manage to get it working with what seems to be good-enough precision using the PPC frsqrte (floating reciprocal sqrt estimate), Newton-Raphson refinement, and a fmul.  The only floating-point instructions left to support are conversions to and from 64-bit integers which are nearly impossible to generate code for because there is no hardware support on the Wii and the process is rather complex.

64-bit instructions were a similar story: most of the instructions had a straightforward translation from MIPS to PPC (even though the PPC in the Wii is 32-bit), but there were a few which were difficult to emulate.  The simple addition, subtraction, and logical instructions were very simple: you simply need to use two PPC registers to store a 64-bit value and there are instructions which will keep track of and use the carry bit so that a 64-bit add/sub can be performed in two 32-bit add/sub.  The 64-bit shifts were relatively complicated because you have shift both 32-bit words separately, and then determine what would have spilled from one into the other and or it into that word, but it can be done in around 10 instructions in PPC.  Like with FP, there were a few 64-bit instructions that we couldn’t reasonably generate code for: the 64-bit multiply and divide are too complicated for generating code using only 32-bit operations.

However, even with most of the ISA implemented, there was still significant room for improvement in performance.  I have since made some other significant improvements which I will be detailing in more posts to come soon.

72 thoughts on “Progress Report: Wii64 Dynarec (Part 1)

  1. Keep up the great work, looking forward to more feedback to keep the excitement up :)

  2. HOPEFULLY this will make everyone STFU.

    Good to see some updates that I don’t understand anything about, besides that Dynarec is indeed important.

  3. wow this is the most technical article I’ve read in the past 3 days! You guys are amazing at this stuff and I don’t understand half of it! Keep it that way! I thought when I first heard of dynarec is wasn’t a long process, but wow that’s amazing how you can get the 64-bit shifts into 10 instructions on a PPC. Amazing. This is epic.

  4. I dont know what any of that means (well, most of it), but i feel a lot better waiting for this project now :D .

  5. No idea what any of that means, but lets just hope part 2 comes within the next week, instead of the typical month and a half.

  6. Yay! This is exactly what I wanted from the project. Really, a release isn’t necessary, I just love knowing how the dynarec ticks. Good works guys, I’m behind you all the way.

  7. Seems very promising, basically, this mean the dynarec now translate the full N64 instuction set, right ?

    Should definitively shutoff some dirty mouths: making a full speed N64 emulator on the Wii is an hard task, harder than anyone of us could imagine since dynarec is a mandatory and does not come up magically, this article speaks for it self

  8. One more question: how does it come that the N64 cpu has instructions to handle 64 bits operations and the Wii doesn’t ???

  9. @JikaEf:
    From what I understand, its not so much that the Wii DOESNT support 64-bit instructions in general, more so it doesn’t support those certain specific ones in the old Nintendo 64.
    To put it simply, think of the CPUs, the Wii has a PPC processor, and the N64 has a different type of processor. Of course there’s going to be some hiccups in compatibility.

    Very interesting to see progress made on this, I’m looking forward to seeing a fully-functional emulator in the coming months (or however long it takes you). :)


  11. @BPzeBanshee

    I know the instruction set is not the same

    However, the fact the Wii PPC do not have an instruction to do a 64 bits shifting (they are forced to execute two or more 32 bits instructions to mimic a single N64 instruction, which is obviouly slower) made me wonder: how does it comes the N64 had a CPU designed for fast 64 bits operations and not the Wii cpu ? is it a regression or isn’t it really useful in today’s game development ?

  12. i dunt understand any of that, and i dont see the link to download it, where is the link?

    no more updates! i just want the wii64!

  13. Although I didn´t understand a thing, I think it is a good progress and for that, thank you guys!! You don`t know how much the N64 Era means to me, and to think that I will be able to play all the N64 titles on my Wii is wow!

  14. Awesome. I find it’s funny that most people were complaining for updates and technical posts on your progress and they don’t even know what it means!

    Thanks guys.

    to jonny b good. STFU and get out of here.

  15. WOO! awesome. It’s great to see such updates. Hopefully now the comment section doesn’t break down into chaos within the time of the next update.


    I almost thought you guys abondened this project. this is exactly what we needed to hear

  17. I don’t know what any of that means but it sounds like progress to me lol. Glad to see updates and keep up the good work.

  18. Awesome! Thanks for the progress update! Can’t wait for your next article. I’ll check back in a few days.

    Thank you so much! :D

  19. @JikaEf:
    64-bit is a little overkill for games. The main reason computers are slowly moving from 32-bit to 64-bit is because we’ve reached the limits of memory addressable by 32-bit addresses. Game consoles today don’t have as much RAM as even low-end PCs (because there’s not as much use for it and because the RAM in the consoles is higher quality) so they aren’t pushing the 32-bit memory limit either. I’m fairly certain the only reason Nintendo went with a 64-bit processor was for marketing reasons (64-bit was the next step in the ‘bit progression’).

  20. I just read basically 5 paragraphs worth of text which outlined the extent of their update. I have no idea at all what I just read. Like, none at all. I’m not a programmer, and I’m pretty ignorant towards the terms used.

    Basically, I gathered this:

    “N64 emulation on the Wii was very hard to write code for when we first started. We thought we could take a few shortcuts with it to make it run smoother, but that made things worse. Now we fixed the shortcuts, and its getting better. Theres still some other things we’re having problems with. We’ll let you know more later in part two!”

    Is this about right?

    BTW: I’m not being negative or sarcastic, I used to check this website everyday. Now, its about once a week or so. I genuinely want to know if I interpreted this right. Did I? Confusing update……..

    2nd BTW: I know some people have posted harsh comments over the lack of a release. I think they are less angry over a lack of a release, and more angry over lack of regular communications. Even the people who are posting positive, who support the project, and your work, who are patiently waiting for you, say things like:

    “T Says:
    June 23rd, 2009 at 1:11 am

    No idea what any of that means, but lets just hope part 2 comes within the next week, instead of the typical month and a half.”

    Notice he’s not getting angry, or being negative, or demanding an immediate release. He does however recognize the fact that your updates are usually about 45 days in between or so.

    People were starting to think you abandoned the project completely. Maybe every 2 weeks or so update. Even if its just a simple

    “Hey guys, team wii64 here, we’re still working out some kinks, and schools been hectic lately, exams and all. No real change since last update, just thought you should know.”

    Nothing fancy, just keep communication flowing. Thats all. Oh, and sorry for rambling, i meant to post the majority of this in the last updates comments, but couldn’t find the words.

  21. Great I understood MOST of that and for thoes who didnt understand it… Trust me they are definitly making progress and I cant wait for a part 2 post. Ive been going on this website everyday for the last month. Expecting the same old “No news is good news” title so it was a great feeling to see that there Is a update. And guys who are complaning about compadibility. Most games will proberly run. If you have used the really slow alpha release you will see it plays virtully every game i tried and some part of some games run nearlly full speed and thats on the alpha release. So that was released ages ago Think what a new version of the emulater a year later could be like. And like most of you guys I love the 64 era. With games like banjo kazooie (Flying through the snow leval) :,) and other aswome games like DIddy kong racing. SO I carnt wait for a release. Good work guys. Ow yea and please please don’t ignore expansian pack support… EVen if it has to be in a later update… Thanks guys.

  22. @ tehpola
    sorry but i had to ask But I heard a rumor that RARE games would not function… SO I was wondering If you could tell me If this was true or not just for pease of mind. Thanks alot and great Job

  23. Well i by no means am 100% sure but I think at least Banjo Kazooie worked on one of the very first builds of course it was very unplayable but it started up at least.

  24. @Lost My Mind:
    That’s the gist of it: I was initially overambitious, we’ve made a lot of progress on implementing most of the ISA in the dynarec, but there are some instructions which are extremely difficult to emulate in only a few instructions on the PPC.

    Most games that run in glN64 on the PC should run in the pure interpreter in our current code with a few rare exceptions (unfortunately, Goldeneye is one). However, there are issues in the dynarec that prevent several games from running. Banjo-Kazooie does work in the dynarec though, but I’m not sure about most other Rare games. We will have a fairly comprehensive compatibility list when the next release comes around.

  25. Hi,
    is the actual state of wii64 in the googlecode svn?
    I don’t need a precompiled release :-D the sourcecode is enough.
    If the devkippto path is ste correct, compiling would be easy :-D
    but i can wait if you would release the actual code later :-)

  26. “People were starting to think you abandoned the project completely. Maybe every 2 weeks or so update. Even if its just a simple ”

    and so what ? people can believe what they want and whine all they want, I don’t see the point if devs don’t want to or don’t feel the need to update this blog… again, this is not a commercial product you paid for, writing stuff takes time and devs did not signed a contract with you for periodic updates because you feel anxious otherwise.

    The fact is that begging, even for blog updates, is lame and the comment you quoted WAS negative & sarcastic.

    Now, if all the whiny people would say “I don’t support this anymore, devs do not care about us”, let ‘em go, they don’t desserve to play homebrew anyway.

    Be happy for what you get, focus your interest on something else for the time being and learn to be patient, can also be very useful in “real life” (TM)

  27. @tehpola:

    Do 8mb expansion games work as of now? Donkey Kong 64 is crying out for me to play it….

    Also, how does Conker’s Bad Fur Day require a different video plugin? That just seems really strange to me, so I may be wrong. Anyaway, does that one work, too? I’m sorry to bother you but I had to ask since you replied to other people. :P

  28. Hey first of all i want to say that you are doing a great work guys!!!!
    but there’s something that worries me….
    “Most games that run in glN64 on the PC should run in the pure interpreter in our current code with a few rare exceptions unfortunately, Goldeneye is one”
    umm so… we will not have golden eye?… or not for now…

  29. @tehpola
    Hi thanks for the quick reply I thought that it was Going to work because I remember playing Diddy kong racing on the very early altha release at about 2 fps lol. Ok thats great then thank you very much. Just one more question….. When i go select Wii 64 via homebrew channel it shows the falling N and then it comes up with code on the screen and says exemption occurd. And i have unplug the power On the Wii. However on the second turn It sometimes works OK. Hope its a simple fix… Or just the fact it’s the early release. Thanks again.


    I am making efforts towards getting 8MB expansion pak games working. We face memory limits as well as dynarec issues with those games so they are not all supported right now.

  31. @tehpola & emukidid

    Thank you for the updates. tehpola, your progress report is very interesting and very much appreciated. This will be an excellent achievement when you pull it off–not only are there a number of games for the N64 that stand the test of time, but also your emulator plus the ones Tantric is maintaining will give us pretty much the entire history of Nintendo gaming in one little white box. Cool.

  32. So I have a question, I guess. How does a dynamic recompiler handle things like self modifying code, or addresses that are computed at runtime, like function arrays? For the most part, as I understand it, dynamic recompilation involves taking the actual code part of the game and converting it, instruction by instruction, to PPC code, with optional optimization passes and things. Can the 64 even self mod its code while its running, and if so how would you handle this? What happens if, say, a game decides to copy part of its code into another faster area of ram, like some DS games that use VRAM for quick code execution?

    I understand easily how it would handle normal memory addresses and calls and things, and I figure converting the addresses that are hard-compiled into the assembly is easy, but I’m not sure how one would handle the edge cases. Is it understandable to keep the actual assembly version of the code in memory, and jump into non-dynarec (interpreted) code if the game tries to go out of the bounds of the dynamically compiled stuff? How would this affect performance, since a game generally does self-mod as a speed optimization?

    You keep talking about the ISA. As I understand it, all N64 games were compiled against a standard library (sometimes referred to as its “OS”) and that there are only a handful of unique variations on this. Would it make sense to only dynarec the library part of the code, and still interpret the actual game logic? Is this what you mean when you refer to the ISA, or is that something completely different?

    Sorry for prodding, you certainly don’t have to answer. I’m just looking at this from an outside perspective and trying to understand what’s going on. The concept of dynamic recompilation is fascinating to me and I plan to try to write a simple one on my own when I can find the time to do it. ^_^

    Needless to say: great work, I can’t wait for the release, but I’ll make do. No point in releasing it until its ready after all. ^_^ Take your time, enjoy life, and make sure that you’re having fun!

  33. I do hope GoldenEye will be able to be run on Wii64 soon, its a popular game that would boost the popularity of Wii64 back into the spotlight as soon as it releases if it does.
    Of course that’s a personal opinion, so long as the next release runs most N64 games at close to normal speed like what its been hyped up to be Im happy. :)
    Nice work, devs!

  34. @emukidid and Tehpola
    Great so in the long term all games are hoping to be supported!
    However im wondering a few things…
    First does the game save go to the Wii memory or SD card or even Gamecube card?

    And also What controllers Does the emulator support?
    Like I was Playing a VC (N64) with a classic controller and it was weird becauce the controll layout was for the SNES so the A button was where the B button was and vice-vesa. So if it supports Classic controller please put in a option to configure the controll layout and a way to save the configeration.

    Thanks alot!

    Ow and I think I already said but most of the time when I try to load Wii64 It dose a code dump and sais ecemption occurd.
    Just wondering what was that about…
    OK thaks In advance.

  35. @Nicholas:

    look for CPU emulation: binary translation

    dynamic compiler are different (and faster) from interpreters:
    Like modern compilers (which is why this technic is often mentionned as “recompiler”), they work at instruction blocks level, not opcode level (the difference with normal compilerz being that they “translate” native binary code instead of litteral code, like C or C++)
    The advantage of “dynamic recompilation” against “static recompilation” is that the translation (or “recompilation”) is performed DURING code execution, so it doesn’t matter if this is self-modified code or code execution from RAM, etc, it remains code block that can be translated…

    @Matt: I don’t think button reconfiguration or file saving is their main issue actually, this will probably be implemented since it’s so easy to do, don’t worry about those fancy features for now

  36. btw: ISA = Instrucion Set Architecture

    It defines each instruction that can be handled by the N64 CPU, like for any other CPU (x86, PPC…), each CPU have an unique Instruction Set which can perform generic or specific task and operations (arithmetics, jump, branches, load & store, etc…) .

  37. well this is good news. Let’s just hope there is a release before summer is over.:)

  38. I’ve said this before, but I really enjoy reading these explanations of what has been done/needs to be done to get these things working. As some one who has always had a strong interest in hardware and coding but went down a different path in school its always fun to read these.

    It’s clear you guys have put in a lot of hard work on this project and continue to do so. Thank you for your efforts (past, present and future)!

    Its funny how the average end user out there think:
    System A= much more powerful than System B therefor emulation should be easy.
    They always fail to account for the huge differences in architecture or the simple fact that emulating anything is going to be slower than native code, as its extra overhead. Hopefully some people get start to get this after reading these blog posts…

  39. Hello, I’m an admin from Zophar’s Domain (and I donated some money a while back). I was wondering about an emulator that is (apparently) based on PCSX Reloaded and WiiSX called PCSX Revolution. It came up in my news queue today, and I was rather confused by it. Is this version sanctioned by you guys at all, and is it alright for me to post it? It’s hard to tell what the difference between it and WiiSX is (well, mostly because GoogleCode makes it hard for me to compare the two, and I haven’t tried the emulator yet either), as it also uses things like the WiiSX icon from Wiibrew. Please e-mail me if you can, I’m rather curious to see what the take of you all is on this.

  40. @ The 9th Sage

    I’m not too sure about that version. It seems to be a unofficial fork from our WiiSX. Nothing was mentioned to us, so it’s the first I’m hearing of it. It’s a shame though as I recently picked up WiiSX and had made many improvements to it offline, but if the fork is better than our version, I’m happy that they continue it as long as credit is given where credit is deserved: to sepp256 for his GPU port, to me for my base work on the port and tehpola for his static linking of plugins in the build process.

    The version I was working on offline has a working Dynarec and is near full speed with sound too, I’m happy to collaborate with the fork version maintainers if they want any help.

  41. I love your work! You guys are amazing! I am just waiting for the day that I can play both digimon world and conkers bad fur day, that will make me a happy person. They are impossible to get in Tasmania. Thanks guys, your work is appreciated

  42. near full speed? really? that’s good news :D
    if two teams -WiiSX and PCSX revolution – did work together, that’d be awesome

  43. @Emu Kidid
    I think your version may be better than. This other version has an interface that makes changing options easy (which is better than the last version of WiiSX I tried) but the speed is kind of ‘eh’. Plus Symphony of the Night won’t work on it. Good to hear of the progress. :)

  44. I’m not exactly sure what kind of work he’s done, but I hope that you all work together.

  45. Really looking forward to finally be playing some rareware games on my wii, without having to deal with n64 controllers going dead and plugging in the console just to play blast corps for a few mins!

    keep up the good work.

  46. After a long time I feel the need to post again just to say that guys keep the good work!
    We trully are gratefull for your efforts for this project and we hope that when you release it(hopefully soon enough) you will make the success you deserve in the Wii homebrew scene!

  47. @Tehpola:

    Great job, guys! Keep it up :) I have been away from programming for years, but back in the day I remember doing a 64-bit shift on a 32-bit machine by converting the Hex value into a binary representation, performing a shift, and then converting it back.

    I also do remember that speed took a hit as the number of positions shifted increased, because I was manipulating strings… I am sure there must be a better algorithm that does not involve strings, but, say 2 x 32-bit Integers, or something…

  48. @emukidid and tehpola
    Yes I can confirm there is a new psx “revolution” emulator. Ive tried it with crash bandicute and it was averging 35fps The loader its self was bad and yes they gave you credit in the description. The two supported controllers were the gamecube pad. (all though i got a code dump whenever i tried to play it) and the wii controller which did allow me to play it. The sound is average and its in the menu of recently released home brew. I imagine that your build is better due to the fact you were saying that yours runs nearly full speed so id assume your is better as this one does not run full speed.
    Thought you should know…

  49. You guys + Tantric + ekeeke + the guy that maintains the Atari ports = Lords of Wii emulation. Thank you for your efforts.

  50. Hello, I am not a programer but I really admire your work. The 1st April tiizer was very good, and 3 months has passed since them, so I beleve now is much better. Anyway, if GoldenEye is dificult imagine his upgrade Perfect Dark. The dream to play Perfect Dark on wii is distant? I think yes. Golden Eye is a easiest game near the powerfull PERFECT DARK. Good work to you guys. You are doing a lot for us, players.

  51. I’ m expecting the following Wii64 release to be beastly near-perfect if you considered the april tiizer too buggy for a release! It has to be the best emulator ever! Don’ t give up, you look so near to the goal! :D

  52. Also, tehpola is doing a great work with his Dynarec: No MIPS–>PPC recompiler existed so far AFAIK…Or did Sixtyforce use one? IDK, but as sixtyforce’ s devs are selling their product, these dudes in here are giving it for free! Simply awesome.

  53. Do you need 64 bit precision in the multiply?
    Can you just multiple the most significant bits with a 32 bit multiply?

  54. @drk421:
    When you multiply two integers, the full result requires twice as many bits as the size of the source numbers to guarantee a correct result. On the N64, there are four integer multiply instructions: 32×32 to 64 signed and unsigned, and 64×64 to 128 signed and unsigned. The former two can be done relatively easily as 32-bit PPC has hardware support for producing the full 64-bit product. However, without hardware support for multiplying two 64-bit integers on 32-bit PPC chips, performing the multiplication is complicated. In fact, to the best of my knowledge, it cannot even be concisely described in C code due to the fact that there are no 128-bit integer types. I think to produce the lower 64 bits you can do it in around 10 instructions, but calculating the upper 64 bits is much more complicated.

  55. Can you pre-calculate it then use a lookup table? Also where can I get the current SVN? I’ve compiled the source on googlecode and it seems a bit stale.

  56. Pingback: EmulateMii » Blog Archive » Developers’ Retrospective Part 2: tehpola’s Musings

  57. Wow… I’m impressed now. I took an os-based CS class back at college and I have to say I hated MIPs and lower-object-oriented programming. Very frustrating stuff. Sounds like it will be difficult to get some of the more advanced games that actually take advantage of the 64-bit processing capability running properly. Now I’m starting to understand why it was so much easier to get SNES and Genesis emulators working than N64. Perhaps you guys should try and complete the PSX emulator first (which only uses 32 bit if I’m correct) and then return to this project. I know there’s much more demand for the N64 emulator but we all know that after programming something once, you always see ways you could have written your code way more efficiently / how to improve upon it if you were to rewrite it.

  58. @Tephola

    One other thought although I’m not sure it is helpful. In your comment above you mentioned that the 32-bit processor of the wii can’t handle 64×64 multiplication and division processes. For multiplication processes, couldn’t you merely just use lots of smaller addition processes to simulate true 32 bit multiplication?

    I’m going to try to explain what I mean with smaller numbers than true 32/64 bit numbers to make it easier to explain..

    Ok say you wanted to do a multiplication of a statement Z*C multiplication. Instead of doing a true Z*C multiplication to get the result, you could literally go and add Z to itself C times. [i.e. if you were doing a 4*10 multiplication you could get the result by adding 10 to itself 4 times (4 * 10 = 10+10+10+10 = 40).]

    To take it a step further, if we knew how much the processor could handle, and knew the maximum numbers the 32 bit processor could handle for multiplication we could simplify the process even more. If we have a statement Z*C and we find that C is a 32 bit number but Z is a 64 bit number we could calculate Z*C by taking ((Z/2 * C) + (Z/2 * C)) or even ((Z/2 * C) * 2). [i.e. (4*10 = ((10/2 * 4) * (10/2)) = 40]

    Obviously the math is a little bit more complex than that but you see what I’m saying. Pardon me if I’m rehashing tasks that you’re way beyond at this point but it was just a thought.

    Granted this would still be slower than true multiplication. But you would be able to calculate the numbers..