Long overdue progress update and… a 1up on bigN!

We must start by saying that yes, it sure has been a while since our last update. Followers can rest assured though that we have been actively developing all of our projects in one way or another. As mentioned before, all three of us have very little time to work on this stuff due to real life commitments, but combined we seem to be getting things done at what we think is a decent pace.

WiiSX has seen some tinkering to try and get compatibility up, but has run into other issues. We have been keeping in sync with pcsx-reloaded whilst trying to maintain the PPC dynarec for it. Eventually we need to add more recompiled functions to the dynarec in WiiSX, particularly GTE. We initially wanted to do a full PPC dynarec re-write, but that doesn’t seem feasible time-wise at the moment. Future plans for WiiSX also include porting a hardware renderer now that Pete’s OpenGL plugin is open-sourced.

The Wii64 port to PS3 now has a near-complete hardware renderer since our last post. However, the dynarec needs some work to run on a 64bit PPC architecture. The Pure Interpreter core has little (if any) performance increase over the Wii running the same core, so PS364 really needs the dynarec.

Wii64 for the GC/Wii has seen the most in terms of progress. There has been USB2 support added as well as a port of Rice (graphics plugin) amongst other smaller bug-fixes and optimizations since the last release. One notable feature that we’re really excited about is…

That’s right, high-resolution, custom texture paks are now supported on the Wii using Wii64! :) Of course, this is still Work-In-Progress, but we’re nearing completion.. Expect a release after this feature is complete. We feel like this is where homebrew emulation on the Wii can really shine and provide an enhancement that Nintendo is not able to offer with their official software.

June 2010 Progress Update

It’s been a while since we’ve said much about what’s going on behind the scenes in terms of general progress and development, so here we are, filling you all in on what we’ve been working on.

In terms of WiiSX progress, we’re nearing the beta 2 milestone we have had in mind for a few months now. The majority of features and bug fixes we have had planned are nearing completion. To be specific, WiiSX beta 2 will encompass a feature rich graphical user interface much like that seen in Wii64 and in the preview video posted below. Some other important features to note include newly ported CDR, Sound and input plugins, boasting features such as dual shock, configurable controllers, clear crisp audio and a good range of CD image support, including subchannel data. Most of the features have been implemented, but we are currently ironing out some show stopping bugs such as seen in certain Capcom fighter games.

On the Wii64 front, we managed to finish migrating the private SVN commits to the public googlecode repository up to Beta 1.1 Honey, so now you can see all of the individual commits and work that went into the last version. Since the last release, we’ve made some progress with bugfixes in the code, but we have larger plans ahead of us for the next beta in order to increase speed and compatibility. Once WiiSX beta 2 is out, we are looking forward to giving Wii64 some more of the TLC it deserves. :)

Here’s one last juicy tidbit for you all… There’s yet another emulator that the Wii64Team has been longing to see on the GC/Wii, so we’ve started working on a port in our spare time, and we’re hoping that it will arrive in all of your Homebrew Channels later this year. Kudos to anyone who can guess the platform (although we’re not promising to confirm if you’re right…) ;)

Wii64 Beta 1.1 “Honey” Release

It’s out!
Downloads are available for Wii64, Cube64, and the source.

We were planning on releasing this baby last week, but Cube64 was broken! Anyway, good things come to those who wait because we made huge progress on the emulator this past week (see video). We’ll be sharing more technical details later, but for now we hope you enjoy Beta Version 1.1 “Honey”!

If you appreciate our work, or just feel like helping us out, please feel free to something to show your appreciation. Donations are what keep this website alive, so they’re very much appreciated.

Developers’ Retrospective Part 2: tehpola’s Musings

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.

Developers’ Retrospective Part 1: emu_kidid’s nostalgia

Since that first post I made, all the way back on the 27th of May 2007 over at tehskeen.com .. the emulator sure has progressed! Back at the time which I created that thread, I considered myself a rather experienced coder, but nothing could’ve prepared me for the long road of development we had ahead of us. Looking back, I think we were all a little naive at how quickly this could be done. It wasn’t until we had an alpha version out that we realized what hard work lied ahead of us. Wii64, then known as mupen64gc simply because we only thought it would ever run on a Gamecube, would soon change my knowledge of N64 hardware, coding and debugging forever.

It was only a few months after that post in which tehpola (mainly) and I quickly got together a mupen64 port which would actually do something on a GC. One of the first games we ever saw emulated in mupen64gc was Rampage World Tour. I remember it would run with bad graphics, no sound, very bad input, direct saving (which would take up to a minute each time a single byte wanted to save), and on top of all that, it wouldn’t even reach past 4 or 5 FPS before eventually crashing anyway due to a limited software rendering graphics plugin. We eventually got Super Mario 64 to work with the software rendering plugin at around 4-5FPS too, but we soon realized we would need a better hardware accelerated plugin.

A little bit of trivia, we actually emulated the public domain ROM “Fire Demo by LaC” before anything but we didn’t see it running as the software graphics plugin was rendering the screen too dark :P

Very shortly after our initial work and after our search for a graphics coder, sepp256 joined the project. He was keen to learn about the N64, and showed us quick results by porting the mupen64 software rendering graphics plugin to work with some GX hardware acceleration and Super Mario 64 was running at around 35% of the speed. Around this time (October 2007), we released the first alpha for the general public to see, known as the “Basic GX Build” which was followed shortly by the “DVD Loading Build”, enabling users to load ROMs from their Gamecube DVD drive. These builds had quite a large number of graphical glitches, extremely screechy audio, and general lack of features, however the emulator was starting to show positive progress.

As time progressed and we entered the new year of 2008, there was new hope on the horizon, Wii homebrew would soon be possible thanks to Team Twiizers, so we were quite motivated to move forward. The mupen64gc project would continue, with many bugfixes, a GUI with a menu system now slowly coming together, threaded audio emulation, a ROM cache, a TLB cache, native saves working and even more graphics plugin bugfixes and improvements than you could poke a stick at! There was yet another alpha version released for the GC at this point to show the public some more progress, labelled “New Year’s Edition”. This was the first official alpha release to feature the GX graphics plugin and the version 1 menu (pink coloured backdrop made by brakken from tehskeen).

Shortly after this, we were given the ability of being able to load homebrew on the Wii (thx Team Twiizers!), this was great news for us as we would now have so much more CPU horsepower and memory to play with, not to mention the new peripherals. It didn’t take us long to have our code working on the Wii, and we quickly realized how much more power we had in our hands thanks to the Wii. Word got out around the scene, and we were special enough to have a build labelled “Wii64 Tiizer Edition” be included in the Homebrew Channel initial release. This alpha build was pretty far along, but used a very early port of the glN64 graphics plugin port and the Pure Interpreter for everything.

After May 2008′s Tiizer edition release, we started to see a very large influx in the amount of unofficial builds popping up with Wiimote support, and 100′s of different button mappings and other attempts to better the emulator. As a result of this, we were bombarded with bug reports which weren’t even ours to fix, and even more so, there were bugs introduced in the unofficial builds because of bad tool chains people were using to build the emulator which took us a while to track down the causes of (thinking they were problems in our code too). After that, things went a little quiet for a bit as we all continued on with our real lives, but development continued to trickle into the public googlecode repository as we made changes.

Shortly after this time, sepp256′s port of Orkin’s glN64 graphics plugin work was showing major progress and we would soon have a working port on the GC/Wii with hardware acceleration via GX. Although, this was never yet marked with a milestone alpha version as there was a silent boom of progress in another part of the emulator we were awaiting to happen. Around early January 2009 and after a few rewrites, the dynamic recompiler was actually starting to run games and most homebrew demos. This was not a quick step, and whilst things were actually starting to run on the new core, there were major issues. The first notable thing to run on the dynarec was “Fire Demo by LaC” .. which is quite interesting since it was the first thing to run on the pure interpreter. By “run”, you’d all probably think, full fps, etc .. , but in truth, it only executed enough code to emulate 90 video interrupts which showed us about 3 frames of graphics on screen. It wasn’t realized until I coded a N64 demo by hand to print the instruction execution count to the screen that we would need to be a lot more accurate in our emulation.

During early February 2009, we decided to setup a private SVN to get us through what was basically going to be a complete rewrite of the most major part of the emulator, the MIPS to PPC dynarec. You can imagine our relief at the time, it would be the first time in a long while that we could now work on the crucial parts of the emulator at our own pace and not have to worry about people compiling every single small changed revision and making complaints. We did this because the working copy of the source code would be obviously broken until major work was done in the areas of the Dynarec and the menu.

During this time, there was a great increase in progress, tehpola was hard at work on the dynarec, sepp256 was making progress in leaps and bounds on the glN64 bugfixes and the new menu system, and I was tinkering with various areas of the emulator such as thinking about ways to fit the expansion pak support into the emulator and testing everyone’s code out. From this point on, the positive progress never stopped, sure there were hard times when we would find bugs that not even days of debugging would solve, but we always moved on. Some bugs were so hard to debug on the Wii that tehpola found it easier to resolve them by porting his dynarec to the PS3 (which is further explained in this article).

In about a 7 month period after this, which leads us up to this beta 1 release, to sum things up, we managed to transform the emulator to go from only running 3 frames of a homebrew demo to playing The Legend of Zelda Majoras Mask with 2xSaI filtered textures, framebuffer effects, expansion pak support, all at a very playable frame rate with a nice new menu backing the emulator with artwork from Wii homebrew artist drmr.

The future of Wii64 is looking pretty optimistic with many bugfixes and optimizations up our sleeves to better it. We expect to have a minor version out shortly to address some of the bugs which users have come across in beta 1.

I hope on behalf of the team that everyone enjoys emulating their old favourites with the Wii64 beta 1 release as much as I had developing and testing the emulator. Since release, we have had some very positive reviews from you all, which have provided us with motivation to get working on beta 2 and making the emulator more compatible and feature rich in the coming versions. We also really appreciate everyones support towards our hardware and hosting donations fund.

Wii64 Beta 1

It’s out!
Downloads are available for Wii64, Cube64, and the source.

We’ve put a lot of hard work into this, and we hope you guys will have as much fun playing as we have developing it. If you’re feeling generous, we’re always accepting donations to keep this site running and to purchase any hardware we need for testing. You can donate here.

A few notes about this release

Wii64 users (Wii build):

The emulator can be controlled with any combination of GC controllers, Classic Controllers, and Wiimotes with Nunchuks (sorry, Wiimotes must have nunchuks). See the included readme for details on the controls. You can load ROMs (only uncompressed) and saves from a FAT formatted SD or USB (details on the folders required are in the readme).

Cube64 users (Gamecube build):

Due to memory limitations, there is no expansion pak support, it uses TLB cache, 2xSaI and FB Textures may break things and of course ROMs will run slower.

Fellow Developers:

We don’t want to discourage other people forking and working on the emulator; however, any unofficial builds must not be called “Wii64″ or “Cube64″ nor use the Wii64 or Cube64 logo in order to avoid confusion. For now, we’re just releasing a snapshot of the source used to build Beta 1, but we’re planning on updating the public repository with each commit we’ve made to our private repository so that everyone can see the progression of the code. This process will begin soon. Public SVN is up to date with beta 1 code.

Support:

Finally, there is a support forum located on TehSkeen, so if you are having trouble with Beta 1, please seek help there before submitting issues to the Google code tracker. You can also join in and discuss the project with other users there.

Sadly, TehSkeen is no longer around, it served as a great website for the GC/Wii homebrew community, for now, you may post any issues you have on the GoogleCode tracker.

Progress Report: Wii64 Dynarec (Part 2)

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.

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.