emukidid posted this interesting article over at the emulatemii site:
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
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.
