News and Insight from the Wii64 Team

Main menu

About tehpola

I am a senior at UT Austin studying computer science spending what time I can working on Wii64. I'm mainly focusing on writing a MIPS to PPC dynamic binary translator and any other tweaks to make that possible given the memory constraints of the GC/Wii.

It was probably around two years ago that I first got a recompiler working that could actually recompile something. I had written some MIPS assembly code in a computer architecture course which would compute factorials. I fed my MIPS code into my recompiler and it computed factorials on the Wii. At the time, that was really exciting for me, but the recompiler was very far from doing much useful. Over the two years, a lot of the original recompiler was overhauled, and I made a couple attempts at rewriting the recompiler more or less from scratch; however, in the end, I came back to the once-reworked original code, and continued to improve on it. After a while I was starting to run more than carefully crafted demos, and after a lot of blood, sweat, and tears, we have a dynamic recompiler which will stably run several games at full speed. This is the first release with a working dynarec. It generates native code for almost all of the N64 instructions; it has, as far as I’ve seen, an accurate cycle count (as relative as mupen64, anyways); and already several optimizations have gone into it. Its still not perfect, several games won’t run at all, and not all games that do run are full speed, but we’re working on improving on that for subsequent releases. For more technical details on the dynarec, see Wii64 Dynarec Part 1 and Part 2 (I’m still planning on continuing the series when I have a chance).
Also, due to sound quality issues with the RSP plugin we were using (rsp_hle-ppc), we’ve begun fixing mupen64′s rsp_hle to be endian agnostic. I believe that rsp_hle-ppc was derived from an early version of the RSP plugin which would later become the rsp_hle in mupen64. Unfortunately, whoever had done all the significant improvements to it since had neglected to maintain endian-neutrality. So, we had to either use the dated, but working, rsp_hle-ppc or work to fix rsp_hle, with all its improvements, so that it would work on the big-endian systems. Up until this release we’ve been using rsp_hle-ppc which has resulted in some sound quality issues, and some games’ sound just didn’t work (StarFox 64, for example). With Beta 1, we’ve fixed up many rsp_hle endian issues and hope to get those changes upstream to other projects so that people can enjoy better sound on other big endian systems. There are still issues, but overall, the sound quality has improved, and certain games which previously had garbled sound (Starfox 64) now sound excellent.
Working on this emulator has been a huge learning experience for me, and I hope everyone is excited about the Beta 1 release as I am.
Since the release we’ve started updating the google code SVN with all the commits we had made to our private repository. We made sure to include a source archive with the binary, but felt that having the whole source history publicly accessible would give more insight into our code and motivations and allow others to see the progression in our work. It will take some time before all the code has been migrated because we’re checking to make sure we don’t have any conflicts, but hopefully it will be appreciated.
In the not-too-distant future, we’re planning on releasing a Beta 1.1 version which will improve some minor changes which were brought to our attention after the Beta 1 release. Hopefully, although these will only be small changes, they will address some of the larger annoyances people have reported.

The structure of the dynarec itself is an important factor in the performance of the emulator. In order to convey some of the changes we’ve made to the dynarec, you have to understand how its structured and how it works. You can divide my dynarec into a few distinct pieces: the translator, the trampoline, the code cache, and some run-time helper functions.

The translator is given an address at which it will translate a chunk of MIPS code into PowerPC. It uses a total of 3 passes to accomplish that. Pass 0 reads in a instruction at a time until it hits an unconditional jump, a jump register, or an exception return, which signifies the end of the function its trying to recompile. Its main purpose is to identify any branch instructions and determine where they are branching to; it does this to ensure that no branches will be branching into a register mapping. Pass 1 actually does the translation by converting each MIPS instruction to a sequence of PowerPC instructions. Branches are left unfilled because we don’t yet know how many PowerPC instructions will be between any given source instructions. Pass 2 then fills out the branch destinations now that every instruction’s position is known. The translator uses volatile and nonvolatile PPC registers in its generated code. Nonvolatile registers are used to store constants like the memory address to store the register values into, the address of the N64 memory, and a few other useful emulator variables. Volatile registers are used to temporarily store N64 registers for the generated instructions to operate on. These are mapped to hardware registers as needed, and stored to memory when changed and no longer needed.

The code that’s generated by the translator goes into the code cache. On a PC with no real memory limit this isn’t necessary. However, on the Wii, memory is quite constrained. In total, we have access to a little under 88MB of memory. However, using the larger MEM2, which is 64MB, is somewhat slower than using the 24MB of MEM1, so we have to limit the code to fit in MEM1 for it to run as fast as possible. Not to mention that the cache has to share MEM1 with all of the emulator code and static structures.

I have a few functions which the recompiled code will call in order to reduce the amount of generated code generated for complex instructions. For example, interpreted instructions, updating Count, and taking floating-point unavailable exceptions. These are just ordinary C functions which will only be invoked by the recompiled code. These functions allow for a reasonable trade-off: faster than interpreting and relatively small code generated for just the function call.

The trampoline, or dispatcher, is at the heart of the dynarec. The trampoline is responsible for determining if code at a given N64 address is recompiled, and if its not, recompiling it, and then calling the recompiled code. When the code that the trampoline invoked needs to branch to another block of code, it returns to the trampoline with the N64 address of the code it wants to run, and the process begins again: the trampoline looks up the new address, possibly recompiles, and then calls the desired recompiled code. Branches within a function don’t need to return to the trampoline, but because any function can be freed from the code cache at any time, every branch outside of the function must return to the trampoline to be dispatched.

I’m sorry for those of you who will be disappointed that I’m not posting to talk about Wii64 or WiiSX right now, but I have another little release I’d like to announce. A month or so ago, I was working on porting OpenJazz, a Jazz Jackrabbit 1 engine, to the Wii, and I got it in a pretty polished condition. However, I didn’t release it earlier because I couldn’t get the network support just right. I’ve decided to roll it out in its current state without networking and hopefully someone else interested in the project will pick it up because I’d like to focus more on Wii64. Anyone interested should check out: the google code page.

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.

As its been a while since our last binary release, we wanted to clarify why its been so long and what we’re waiting for for our next release. Early on in development we were making relatively big changes which significantly improved the emulator; however, we’ve gotten to the point where a lot of the big things have been done, and only need perfecting (with the exception of the dynarec). Thus, we haven’t felt the need to make several binary releases as most of the users who aren’t interested in compiling the source themselves are mostly uninterested in the kinds of changes that have been made. We do indeed have a milestone for our next release planned: a working, stable dynarec. Most of the work that has gone into the emulator since our last release has been focusing on the dynarec, and since we still don’t have a completely working dynarec, there haven’t been many noticeable changes. So we’re holding out for a dynarec which supports at least most games without crashing before we make our next release. After getting it running initially, there will likely be more room for optimization if there are still any performance issues. In that case, we will likely have frequent releases once again as there will be noticeable improvements with each optimization that is made. As always, please be patient. We’re working hard to make the next release something worth the wait.

On an unrelated technical note, we have managed to free up 1.75MB in RAM by consolidating the various memory LUTs (look-up tables) into a single LUT for all memory operations. In Mupen64, there are 8 different memory LUTs which are used to determine how to handle memory accesses at different addresses. These 8 are split up by read/write byte/half-word/word/double. Instead of having 8 large LUTs, I created one LUT for all memory operations which points to smaller LUTs which handle the different memory operations in the specified segment. Memory operations only require an additional load for the second level LUT so there is no performance impact by this change. We are still looking into other ways to further reduce our memory usage to make sure that we have plenty of room in memory for recompiled code produced by the dynarec.

Since this is my first post on the blog discussing the dynarec, I’d like to first explain what a dynarec is and why we’re going to need one to accomplish full speed emulation on the Wii. Then I’d like to describe the history of the dynarec in our emulator, where its at now, and what needs to be done to get it working.

First of all, dynarec stands for dynamic recompiler, which is actually a bit of misnomer in the console emulation world: usually its not accomplished by creating an abstract syntax tree or control flow graph from the emulated machine code and running a target machine code compiler over it, which is what recompilation would really entail. The proper term would be binary translation: for each emulated instruction, I convert it to an equivalent target instruction. Since the N64 is a MIPS architecture machine, I take a MIPS instruction, decode it (determine what kind of instruction it is and what operands it operates on), and then generate equivalent PowerPC (GC/Wii use PPC) instructions to perform the operation that the MIPS instruction intends to. What we try to do is take a block of code that needs to be run, and fill out a new block with PowerPC code that was created by converting each of the MIPS instructions in the block. The emulator then runs the block of code as a function: it will return when a different section of code needs to run and the process repeats for the next block of code.

What we’re doing now is running an interpreter: instead of translating the MIPS code we want to run, we just decode each instruction and run a function written in C which performs what the MIPS instruction would do. Though this may seem like less work: we don’t have to translate all the code and then run it; we just run it, but because the code is ran so many times and running the translated code is much faster than running each instruction through the interpreter, the extra time translating is made up for my the faster time running through long loops.

The dynarec was the first thing I started working on with the emulator: it seemed like the most interesting aspect and the most crucial for such a port (besides the graphics which I didn’t understand well enough at the time to do much useful work besides porting a software renderer). It’s gone through a few different stages different stages: 1-to-1 register mapping binary translator, quickly dropped attempt at reworking the translator to be object oriented, slightly further progressed attempt at a MIPS to Scheme translator, and where I’m currently at: the first binary translator without 1-1 register mapping, confirming to the EABI (Embedded Application-Binary Interface).

I was concerned about performance initially, and I got a little greedy: I decided that since both MIPS and PowerPC had 32 general purpose registers, and MIPS has one hardwired to 0, and PowerPC has an extra register (ctr) I could move values into for temporary storage, I could do a simple translation of most of the instructions by using all the same registers as the MIPS would use on the PPC. The idea was that I wouldn’t have to shuffle things in and out of registers; I would load the whole MIPS register set values into the PPC registers, run the recompiled code which would operate on those values, and then when its done with a block, store those values back and restore the emulator’s registers. This was a bad idea for several reasons: small blocks that only fiddled with one or two registers still had every single register stored, loaded, and then stored and loaded again for each block, I had to disable interrupts because I destroyed the stack and environment pointers that were expected if any interrupts were taken, and because I couldn’t take interrupts, it was very difficult to debug because I couldn’t run gdb in the recompiled code. I had developed a pretty large code base and a somewhat working recompiler before I truly came to realize all the drawbacks of the method: it ran some simple hand-crafted demos I had written in MIPS which computed factorial and a few other simple things, but overall it was too unweildy and inefficient to continue to debug.

My attempt at refactoring the code I had written in a OOP way was soon abandoned, but it did inspire some improvement to the way I generated instructions. Instead of piecing together the machine code from all the different parts, I wrote new macros which would do that for me for specific instructions thus reducing some major code clutter in the translator functions.

I was unimpressed by the improvements I predicted I would see by refactoring the code in C++, and inspired by Daeken’s work on IronBabel to start the dynarec from scratch using a high-level language. The idea and the code was much simpler: decode the instructions using high-level magic and instead of generating low-level machine code, generate high-level code to execute each instruction, collect all the code together, and run it as a function for each basic block. I chose Scheme because how easy it is to generate and run code on the fly (since in Lisp, code and data are only differentiated by how they’re used). The recompiler was a breeze to write, but interfacing with the C code proved troublesome. Although I eventually got the code to run, I ran into issues with the unlimited precision numbers in MzScheme, and my other choice of Scheme, Tiny Scheme, didn’t support some bitwise operations and I never got around to adding them.

Finally, I decided to go back to the old code base and improve on it with respect to the issues I had discovered along the way. I wrote more macros to clean up the code generation, I did away with 1-1 register mappings, and worked on compliance with the EABI so that I wouldn’t have any issues with interrupts and calling the recompiled code as a C function. Now, instead of loading and saving 31 registers for each dynarec block, I load each register as its used, and I store their values at the end of the block or if I used up the alloted registers for storing MIPS registers (I use volatile registers so I don’t have to worrying about saving their values). It’s not much more complicated to translate the instructions with the new mappings because for each block, the mappings are static and are kept track of while recompiling so I simply build up a table of mappings while recompiling which I flush at the end of each block. EABI compliance was a matter of creating a proper stack frame for the recompiled code, and not touching certain registers; since I have a few special values (base address of MIPS registers in memory, address of interpreter function, zero, and a running count of instructions) that I need to be maintained to any other calls, I needed to save those registers on the stack in the proper locations and restore them when I returned to the emulator. EABI compliance allows me to leave interrupts enabled while the recompiled code is running (in general, leaving interrupts disabled for extended periods of time is a bad idea) and allows me to step through recompiled code in gdb which greatly improves my ability to debug the dynarec.

The new format allowed me to debug things much easier: I could much more easily compare the original code and the effects of the recompiled code by stepping through. Soon after the reworked dynarec was completed, I pushed through all the obvious bugs in the apploader (I had some issues with the calculation of the checksum of the ROM and invalidating recompiled code that was overwritten with new code). Now the dynarec executes the standard apploader successfully, and begins running the code unique to each game. However, I still haven’t seen anything much happen after that point as far as any graphics showing up or anything like that except for in a demo I wrote that blits an image to the screen after running some unit tests.

As I’ve recently purchased a PS3 and installed Linux on it, I have a full environment to test the recompiler under without the hassle of running on the Wii. I’ve already made a quick port of my dynarec to run under PPC Linux, and I believe its breaking at the same points it was on the Wii. Running in a full OS gives me access to more tools such as valgrind and better support in gdb which helps improve the rate at which I can narrow down and fix bugs especially as the progress further into the execution of the games.

Barring some issues dealing with interrupts and exceptions, I believe the dynarec is feature-complete at this point and there are some lingering bugs (possibly dealing with some instructions which I haven’t previously seen in action or some edge cases dealing with translation or execution) which need to be resolved in order to get the recompiler working. There are a few instructions not recompiled which I intend to support after I have the basic integer instructions working: floating point instruction, 64-bit instructions, and loads/stores from/to the stack which will hopefully improve the performance of the dynarec once its running. Of course, finding these bugs take time, and its hard to put any kind of ETA on finding and fixing them because I don’t know how many issues are lurking behind the one I’m currently stuck on, and its not always easy to track down the source of the issue so please be patient as we work to resolve these issues as its hard to get this all right. However, I believe that with the dynarec running and the hardware accelerated graphics we have now, we can accomplish smooth, full speed emulation of most titles, and possibly even support some extras like high-resolution textures. As things progress, I hope to keep everyone informed of how things are going, so look for more posts on this topic later on. In the mean time, emu_kidid has made a video demonstrating the emulator in its current state on the GC so check it out.

Hey everyone, we’d like to welcome you to our new site. The idea behind this site is to have a central location for information about our project in hopes that we can reduce rampant speculation, and to hopefully avoid repeating our answers to frequently asked questions, etc. The three of us, sepp256, emu_kidid, and I (tehpola), are often too busy with real life and doing actual work on our projects (mupen64gc and pscxgc and more) that we don’t always have time to answer everyone’s questions. We’ve created this site in hopes of improving our communicates with the public: we’d like to be more open about what our goals our, what we’re working on, how we’re doing things, and we would like the information collected mostly in a central location.

We’d like to begin by thanking the people who donated to help us get the site running:

Ninth Sage

iSynic

Jason

And many others (if you weren’t listed and would like to be, send us an email)

We’d also like to thank the great guys at OzModChips for donating a USBGecko to help us with our debugging needs.

We’ve already have a page dedicated to the goals for mupen64gc in great detail and we’re in the progress of developing an extensive compatibility list for it which will give information on how various titles perform. So check out our site and let us know how we can improve it.