this was on emulatemii (The wii64 teams page) about the video and update thought i would pass it on here im sure im not the only one mega excited about the update
First off, the April 1st Tiizer video is actual gameplay using a recent dev build of Wii64. As you can tell, tehpola has made tremendous progress in debugging and optimizing the dynamic recompiling core. However, there are still a handful of showstopping bugs that we need to work through before we can make a public release. Also, you should be aware that not all of your favorite games will run on the initial release because of a variety of reasons. We are not planning on initially supporting the Expansion Pak because of memory limitations. After further optimizations, tweaks, and profiling to reduce our memory consumption, then we hope to addExpansion Pak support. We may not initially support games that execute code directly from the cart or that use virtual memory (i.e. Goldeneye) because this requires more investigation and significant code changes in the dynarec to implement. Also, some graphics microcodes arenít supported in glN64, so a fewgames such as Conkers BFD wonít work just yet. But, sit tight and weíll continue to work on more features for Wii64 after the initialrelease.
A complete re-code of the Wii64 gui is underway, so youíll be able to enjoy using the wii-mote for navigation and also some sleek new graphics. Weíll have a new look for the initialrelease, but we also plan on adding more features to the gui over time for your enjoyment.
If you have watched any of the recent gameplay videos, then you know that the accuracy of the glN64 port has increased substantially since the Wii64 Tiizerrelease we made for the Homebrew Channel. Because GX is not 1:1 with openGL, there was a lot of investigation and tweaking required for me to get the behavior on GC/Wii close to what glN64 looks like on PC. There are still a variety of bugs for differentgames , so donít expect everything to look perfect, yet. Emu_kidid is a great tester, and he is maintaining an internal graphical issue list to work on. I hope to add a couple more features to glN64 prior torelease , including glN64ís primitive framebuffer texture support as well as 2xSaI scaling for textures. The plan is, of course, to continue hunting down bugs and adding features after the upcomingrelease.
As for the other graphics plugins, glN64_GX is much faster than both soft_gfx and GX_gfx, so we may only release a build with glN64_GX. The only drawback is that currently glN64_GX wonít render graphics for demos that only directly manipulate the framebuffer with the CPU. However, when I have time Iíll add a feature into glN64_GX that will allow it to render the N64ís framebuffer rather than rendering primitives passed through the N64ís graphics pipeline. Then, you can just flip an option in the menu when you are running homebrew N64games and demos that write directly to the framebuffer. Also, I have already done some work on porting Riceís video plugin to Wii64. Rice supports more microcodes than glN64, including the one that Conkers BFD uses, and it should be faster than glN64. We have a vision of supporting custom texture packs in Wii64, so we will implement that feature as well. We hope that you, our users, will contribute your creative talents in developing texture packs to share with the Wii64 community. We canít say when custom texture pack support will be finished, but expect it sometime in the future.
Some of you have been asking for an update on WiiSX. We are planning on working on a release of WiiSX after the upcoming Wii64 release. The reason we have not done a release yet is because there were some serious bugs in SVN last fall, and we also wanted to focus on completing Wii64. We have since resolved some WiiSX issues, internally, and so once Wii64 is out the door, we feel that we can also follow up with a WiiSXrelease relatively soon afterwards.
Finally, weíd continue to ask that if you enjoy using Wii64 when itís out that you consider donating to the project. Right now, most of the donations we receive go toward hosting costs. However, there are also some small accessories like component cables and classic controllers that we are considering purchasing with donation funds to aid in development.
No news is good news?
We donít really appreciate the negative comments on the site. It is obvious that there is a lot of anticipation for homebrew N64 emulation on the Wii/GC. Believe us when we say that we are equally excited to see Wii64 enter public beta stage. We have devoted a lot of our free time to this emulator for nearly two years, which is since the days before Wii homebrew was even possible. Many of you who are complaining are simply being impatient because you want to try something that you would only complain about more until we have worked more bugs out.
We have entered a private alpha stage, and we have made many improvements/bugfixes to the emulator in the last few weeks. However, there is still a substantial amount of work to do, and a couple of us are very busy with schoolwork right now. We wonít give anyrelease dates, but we hope to be able to release a public beta as soon as possible. Please donít ask for a release date or to beta test.
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.