Proper USB Storage and SD(HC) Handling in C for Wii Homebrew

Handling File IO is another popular topic in Wii Hombrew for obvious reasons and one that I've spent a significant amount of time on. I'm going to use this post demonstrate proper initialization and deinitialization of SD(HC) and USB devices in C. There are in fact quite a few different ways to do it but I've refined my personal methodology over years of carefully tweaking it and testing it in many apps.

How I Debug Wii Homebrew Crashes

I get a lot of e-mails from people asking me how I debug Wii crashes in my Wii homebrew. After just responding to yet another one I figured it was time for a brief writeup. Before beginning though I want to make it clear that there are many methods that can be used to debug your Wii homebrew. Depending on the situation mine may not be the best for you. Mine is only useful for finding the cause of a crash.

I have a really poor TV that I can't clearly read crashes off of. In order to counter this I use a USB Gecko device which outputs crash information to a serial connection I form with it. This way I'm not doing any guesswork and I know my results will be accurate. However, if you have a TV which you can read text clearly off of, a USB Gecko is not required to debug homebrew using my methodology.

Heretic Wii 0.5 Released

I've been so busy lately that I missed posting the first release of Heretic Wii on my blog. I'll make up for it by extending this post a bit to talk about the project as well as a few other projects I'm working on.

When everyone first saw the Wii, one of the first things that came to mind was playing first person shooter games with it. Developers have given us great games such as Metroid Prime Trilogy and Call of Duty Modern Warfare Reflex which have shown that a first person shooter game on the Wii can in fact be superior (at least as far as the controls go) to the first person shooter games on other consoles. With Wii homebrew, this door of opportunity is opened even wider as homebrew developers such as myself are able to take old first person shooter games that everyone loves and modify their source code so that they can be played on Wii. Ports of Quake, DOOM, Wolfenstein 3D, and others have now shown us that the Wii controls are so precise that they can actually rival the keyboard and mouse. Furthermore, by playing these old games on a video-game console, users also find them easier to install and generally play them on a bigger screen with a better sound system.

To this end, Wii homebrew developers should take it upon themselves to bring every open-source first person shooter that they can to the Wii. I personally decided to contribute to this endeavor by porting Raven Software's Hexen to the Wii. Unfortunately, I got stuck while porting it and Hermes beat me to it. Using Hermes code to solve the problem I had, I was able to quickly port Raven Software's other popular shooter, Heretic, to Wii.

Since the initial port of Heretic to the Wii I have continued to add many features to it (all of which are not present in Hermes port of Hexen) that make up this new 0.5 release: Full USB Support, Classic Controller Support, GC Controller Support, and a Wiimote and Nunchuk control scheme which uses the Wiimotes IR.

My port of Heretic to Wii is now fully featured and truly a 'complete' port. In upcoming releases, I will expand the game by adding a cheat menu which allows enable and disable a variety of different cheats for the games. However, I am going to take a break from working on this project for a bit in order to pursue other projects. Right now I am looking into both doing an original port of the HHexen engine to Wii (I hate Hermes sound engine and control scheme) and porting an entirely new first person shooter to the Wii. But first, I have to give DOP-Mii a little attention to address some recent (non-harmful) complaints with it and expand it with more features (more on this later).

Download Heretic Wii 0.5: Google Code
Get the source code to Heretic Wii 0.5: Google Code
IRC Channel: #arikadosblog on EFNET
Follow my Twitter: http://twitter.com/OArikadoO

If you'd like to donate money to me, please use the ChipIn widget on the upper right hand corner of this blog or follow this link: http://arikado.chipin.com/college-fund . Donations are used to help get me through college and are used to fund new projects. By adding a message to your donation, I promise to spend significant time working on whatever your message asks me to do.

General Update - Priority Readjustment

I'm not meant to be a hacking "scene" news reporter, I just don't have the time. So I'll be closing http://1ntrusion.com in October when the hosting runs out due to a lack of time on my part to maintain the site and due to a lack of user activity. A general hacking site as an alternative to profit-hungry, unmoderated, and incompetent GBAFail is a great idea and one that I fully support. I just don't have the time to do anymore than that. http://www.gc-forever.com and http://rvlution.net and http://pdroms.de are all great sites for general "scene" hacking and cover tons of news and new ideas. I'd like to maybe one day pitch in and help one of these sites, but I am in no way inclined to ever be able to run one.

I'm changing the purpose of my IRC channel, #arikadosblog on EFNET from a chill anything goes channel to a channel dedicated primarily to DOP-Mii, DeSmuME Wii, and libwiisprite support. Of course I'll gladly help people out with their Dingoos, general Wii hacking, and offer support for all my other projects. But those projects will be my main three which will be discussed in the channel. We usually have about 30 members in the channel, so I strongly encourage everyone reading this to stop by. News is usually broken in there before anywhere else ;-)

Regarding DOP-Mii, Lunatik is now the primary developer of that application. I'm taking more of an advising role. Lunatik is extremely talented, hard working, and dedicated and he will take the project to great new heights. I have a few things left I want to add myself (like savegame support functions) but the project is no longer a priority for me.

Regarding DeSmuME Wii, scanff and Dancingninja are rewriting our renderer in GX. It's already mostly completed and games are seeing a 20% (or more) speed boost from it. When they're done, I will work on expanding the emulator with a proper GUI (finally) and finish giving it the 0.9.6 DeSmuME core update (which means another big speed boost). With that in mind, DeSmuME Wii is still one of my top priorities, but, I'm taking a little time off while the other devs work on it so I can do other cool things ;-)

Regarding libwiisprite, I've had an e-mail to chaosteil sitting in my draft box for about a month now discussing the finer points of the changes I hope to add to the library. libwiisprite development is probably my top priority right now and you will all hear more about it very soon.

Some of you may know that I've been working on porting RealityBoy (virtual boy emulator) over to Wii. It's an extremely difficult task to say the least. Since it's written in ALLEGRO, almost every line of the emulator must be completely rewritten. Development is slow and frustrating but I hope to have a first release no later than this Christmas. Yes, that's a bit far down the line, but it will be worth the wait.

I'm still working on porting Hexen to Wii too. Despite some comments I've made claiming otherwise, I'm going to try to rewrite a ton of the engine using the WiiDOOM port. Speaking of WiiDOOM, as I've been playing with the source, I've made a ton of improvements to the app. I'm going to try and contact the authors to see if I can push my changes into their repository. If I can't (I've heard they no longer answer their e-mails) I might branch the project under a new name. I still have a bit of work left to do before either of these outcomes anyways.

Lastly, let's talk about donations. I think it's safe to say there's no way I'll meet my Chip-In goal of $45,000 USD for a chance to go a better school. However, I'm leaving it up since I can't accept PayPal donations any other way (since I'm only 17, I have a student account). Each and every donation is greatly appreciated and will most likely be used to get me through my local college (books are super expensive).

That's all for now. Hope everyone likes the new directions I'm taking :3

libwiisprite 0.3.0d Released

I love libwiisprite. I really do. In my personal opinion, it's the only developer library geared exclusively towards game development. It's focus on game development makes it extremely simple to use with a very small learning curve. With libwiisprite, your most complex code will be generated by you, the author. Not by a spaghetti mess of library function calls. No other library can compare to that (of course, no other library is geared exclusively toward game development either).

libwiisprite's grown old though. Recent updates in libogc and libpng have caused it stop working. I took it upon myself to fix these problems and libwiisprite now looks and works as good as it ever did. Since I was rewriting a handful of it to compensate for the compatibility issues, I also fixed a bug in the layer manager and made a few minor "under the hood" improvements to improve the performance of the library.

I showed chaosteil my work and asked him if I could become an official maintainer of the library and he very warmly granted my request.

I am now continuing to work on and improve libwiisprite. I have a handful of ideas including a sound manager that I'm discussing with chaosteil that I'd like to add to the library. libwiisprite is only going to continue to get better and better. I believe that loyal users of the popular library such as myself are going to be thrilled.

Download libwiisprite 0.3.0d: Mediafire
Get the source to libwiisprite 0.3.0d: Mediafire
IRC Channel: #arikadosblog on EFNET
Follow my Twitter: http://twitter.com/OArikadoO

If you'd like to donate to me, please use the ChipIn widget on the upper right hand corner of this blog or follow this link: http://arikado.chipin.com/college-fund

A thorough explanation of IOS and cIOS for everyone

We all remember when we first hacked our Wii. It was a fairly straightforward process. Crash your Wii, run some magic code (called a boot.elf) and install a magic channel that will let you run any and as much code as you want (homebrew applications or apps).

Eventually, we began reading more and more about the cool Wii homebrew applications and we began to read about these things they used called IOSs and cIOSs. Often we would see, "You must have a cIOS 249 installed to use this app" or "You must have an IOS that accepts fakesigning", and most common recently, "No vulnerable IOS found. For security reasons, we will not use an IOS that accepts fakesigning."

This post is intended to be a thorough explanation of what IOSs are, how they work, and what a cIOS is. Anyone, at any experience level (except for the hackmii l33t) should learn something here.

I feel the best way to start explaining IOSs is to take a trip through Wii homebrew history. Back when Hackmii developed the twilight hack, coders and users alike suddenly had the ability to create and run unsigned (or unofficial, ie: "homebrew") code on their Nintendo Wiis. However, it was undoubtedly very inconvenient to have to run The Legend of Zelda: Twlight Princess and crash it every single time you wanted to run one piece of code on your Wii. So Hackmii went to work creating a channel that you could access right from your Wii and run homebrew code with. In fact, this channel would even be able to run multiple pieces of code in a single use.

To install a channel, Hackmii went to work figuring out channels were installed naturally by the Wii. It was discovered that the Wii relies on an underlying system called IOS to do just that and more. The Wii contains multiple IOSs inside of it which are used for different purposes, but contain the same basic functions. In fact there is room in the Wii for 255 different IOSs. There is one IOS for the system menu, another IOS for games to use, and yet even another IOS for some channels to use. However, no more than IOS is ever running at once.

It was determined shortly afteraward that each IOS is made up of a set of low level functions, or code routines. Wii programs (games, channels, the system menu, etc.) called on the functions inside IOS to do things. If this reminds of you Linux kernels, you're thinking along the right path. IOSs basically are here to perform the same role for Wii that kernels perform for Linux.

One of the functions of IOSs is the ability to install content. This installable content, of course, included channels. In order to install a channel you needed two security keys.
The first key, the common key, was hidden inside each Wii on a ROM next to the starlet coprocessor. The common key is the same in each Nintendo Wii. In order to obtain it, Hackmii used a pair of tweezers in a tweezer attack (this is where the name team twiizers comes from) to complete a circuit, creating a serial line of communication to sniff (view the contents of) the RAM where the common key is stored while it is being used. And so, the firs tof two keys, the common key, was discovered: EBE42A225E8593E448D9C5457381AAF7 (base 16)

The second key, the private key, is stored only on Nintendo's servers. There is literally no way to obtain it from our client end except to attempt to bruteforce it (guess it again and again until we guess right). However, after staring at disassembles of IOSs for countless hours, hackmii realized that each IOS had a bug in their security. To check for the presence of the private key, the IOSs used strncmp(). strncmp() is a C function which checks to see if two strings are the same. If a null byte is detected, it is assumed that the strings are the same. So, in order to install a piece of content, we pass the common key and a null byte into IOSs content installation function. The method of installing content using a null byte instead of the private key is called fakesigning. The bug found in IOS (the usage of strncmp() as opposed to, say, memcmp() ) is called the trucha bug.

To summarize so far: In order to install content onto the Wii, the IOS you have running in the background must contain the trucha bug.

Later down the line, Nintendo would begin updating IOSs by fixing the trucha bug. Most likely, they did so by replacing the strncmp() check with a check like memcmp() which wouldn't terminate after the discovery of a null byte. Hackmii came up with a piece of code called patchmii to download the new IOSs and install the trucha bug into them. IOSs that have had the trucha bug patched into them are called cIOSs.

tona was the first programmer to release an application which downloaded an IOS (IOS 36 actually), patched it (making it a cIOS), and installed it as a different IOS (IOS 249 actually). Thus, cIOS 249 was created.

Other programmers have since replicated the feat. Waninkoko in conjunction with WiiGator have a cIOS installer which applies the trucha bug and other patches to an IOS (IOS 36 I believe) and install it as IOS 249. The patches in the cIOS beyond the inclusion of the trucha bug are patches to allow pirated games to be played. This has made cIOS 249 the "warez IOS" and is Nintendo's primary concern. I could give a you spiel about how this IOS appears to be inflated with inefficient code and how a lot of what's in it doesn't actually work like it claims to, but that's for another post.

So now I've walked you through what IOSs and cIOSs are by showing you the history of them. Hopefully, you should fully understand their purpose and be able to better understand what homebrew is talking about when it references them.

If you have any questions regarding the content of this post, feel free to leave a comment, join me in #arikadosblog on EFNET, post in our forums, tweet to me, or send me an e-mail at castlevania7689@yahoo.com

Libwiisprite compiled under devkitPPC r19

For anyone interested, I just recompiled the wii homebrew libwiisprite game programming under devkitPPC r19.

You can grab it here: http://www.mediafire.com/download.php?n2mjnqmymbh

Porting DeSmuME to Wii - Part 5 -

When we last left off, we only needed to get OGLRender to compile and then the core of the emulator would be completely (and hopefully successfully) ported.

OGLRender outputs (or renders) video from the emulation using the library OpenGL. OpenGL is ported for just about every major computer operating system out there, so the developers chose it to keep the core of their emulator platform independent. Unfortunately, there is not a version (port) of OpenGL for Wii, but the devkitPPC toolchain does have GX; a graphics rendering library for Wii extremely similiar to OpenGL.

The initial attempt by me and profetylen to port OGLRender was to rewrite all of the OpenGL code as GX code. Since DeSmuME uses all of the major features of OpenGL (shaders, textures, polygons, 2D rendering, 3D rendering, etc.) this was a very daunting task that could potentially take months to complete.

However, profetylen found a project called gl2gx which is a wrapper for GX that looks exactly like OpenGL (so, in some sense, it is a port of OpenGL). I compiled gl2gx, and then profetylen and I compiled OGLRender under gl2gx. There were minimal errors after doing this.

First, GL/glx.h was missing. Actually it's not, it's just named GL/glext.h.

Second, glXGetProcAddress was being used out of scope. The easiest way to fix this was just to redefine glXGetProcAddress:
#define glXGetProcAddress(x)((const GLubyte*)x)

Lastly, glActiveTexture() isn't in gl2gx, so we have to write it ourselves. Profetylen came up with the following code for it:
void glActiveTexture(GLenum texture){
texture = GL_ACTIVE_TEXTURE_ARB;
return;
}

So, now we have the entire core of DeSmuME compiled under libogc. The next step is to write original code that uses the core to emulate ROMs on Wii.

You can grab the latest source revision here: Mediafire

Programming with the Balance Board

This post covers how to program with the balance board via devkitPRO's libogc.

But before we program the Wii Balance Board, we should understand how the board itself works. The balance board has four sensors in it which can detect pressure applied to them. The sensors will be referred to in this post as the top left sensor, the bottom left sensor, the top right sensor, and the bottom right sensor. Unlike Wiimotes which can be set to one of four channels, the balance board is always automatically set to a fifth channel.

devkitPRO reads the data from this board initially as raw interpolated data from each sensor. To the untrained eye, this data looks like a bunch of random numbers. devkitPRO then applies a formula to the raw interpolated data and can determine the approximate amount of pressure applied to any of the four sensors. devkitPRO also calculates an X and Y coordinate based on the difference in data between all of the sensors. As programmer's, we have access to all of this data at any time we wish.

So now that we have a basic overview of how the balance board works and how devkitPRO interprets the data read from it, let's get straight to the actual programming:

First, include the balance board code from devkitPRO:
#include (wiiuse/wpad.h)//replace "(" with "<" and ")" with ">"

Initialize the balance board:
struct expansion_t exp;
exp.type = WPAD_EXP_WIIBOARD;

For every turn of a loop that needs to access data from the balance board, be sure to have the computer read the data coming from the balance board:
WPAD_ScanPads();
WPAD_Expansion(WPAD_BALANCE_BOARD, &exp);

You'll then have access to the following values from the expansion_t struct exp:

• exp.wb.tl - The approximate pressure on the top left sensor
• exp.wb.tr - The approximate pressure on the top right sensor
• exp.wb.bl - The approximate pressure on the bottom left sensor
• exp.wb.br - The approximate pressure on the bottom right sensor
• exp.wb.rtl - The raw data from the top left sensor
• exp.wb.rtr - The raw data from the top right sensor
• exp.wb.rbl - The raw data from the bottom left sensor
• exp.wb.rbr - The raw data from the bottom right sensor
• exp.wb.x - The calculated X value
• exp.wb.y - The calculated Y value

How you use these values is entirely up to you. I highly reccomend basing the majority of your code around the X and Y values if possible. I'd now like to elaborate on how these values are used:

• If X is less than 0, then there is more pressure on the left half of the board
• If X is greater than 0, then there is more pressure on the right half of the board
• If Y is less than 0, then there is more pressre on the top half of the board
• If Y is greater than 0, then there is more pressure on the bottom half of the board

Hopefully this post gave you a good introduction on how to program with the Wii Balance Board. Finding the right way to use the values from the balance board is mostly up to how you interpret the specific needs of your program.

Kudos to Ave who originally wrote a patch that implemented the balance board in libogc. Without you, this tutorial wouldn't exist.

Porting DeSmuME to Wii - Part 4 -

Now when we last left off, we needed to port over OGLRender.cpp to continue porting the core. And we're going to leave it off for a little while longer, so bare with me as I explain compiling the rest of the emulator under libogc. If you're following the compilation along with these blog posts, just move OGLRender.cpp and OGLRender.h out of the way for now.

Now, everything will compile fine up until commandline.cpp and it's friend commendline.h The commandline set of code is used to define paths used to load files and implements a very simple debugger which helps users and developers diagnose problems with the emulator. Commandline is powered by something called "GLib" (I couldn't find this library anywhere on the internet, so if you have any information on the library, please share it in comments). Since we don't have access to GLib, I used my commenting skills to basically render commandline useless. In code comments, the original authors strongly recommend NOT doing this, however, I plan to re-implement a debugger of my own in the form of printfs and if statements and the loading paths will initially be completely predefined (and then eventually there will be a GUI which is used to define them). Yes, I'm not entirely happy about killing the commandline, I'd really like to keep it implemented if possible. But for now, let's just keep moving, shall we?

Now everything else will compile fine until we get to ctrlssdl.cpp and ctrlssdl.h These two files use SDL to handle input into the emulator. If you install the SDL port of the SDL library, these files will compile just fine... But they will not work at runtime. Why? Look at the Joypad configuration. Most of those numbers don't have a corresponding Wii Button. Since the classic controller looks exactly like the DSs input nterface (minus the touch screen of course) I rewrote the JoyPad configuration to work with the classic controller. Now, moving on...

More perfect compilations up until fs-windows.cpp This file is simple to fix, just get rid of it. I'm pretty sure the Wii doesn't have use for the Windows file system (fs) ;-) (It probably doesn't have use for the linux file system either, but since it compiles, we'll leave it alone)

Now we got some errors in movie.h and movie.cpp I thought I had taken care of these before, but apparaently not. It's wstring acting up again. Just change std::wstring to std::string everywhere it appears to take care of these issues. It's not the most elegent solution, but since libogc lacks wstring support, it's the only option we have. I don't think we'll be needing the features of movie.cpp and movie.h anyways unless anyone here wants extremely laggy gameplay of course ;-)

The emulator uses SDL to output sound, so if you have the Wii port of SDL installed, the sound output portion of DeSMuME will compile just fine.

And now if we continue our compilation, the rest of the emulator's core will compile just fine up to a problem with the emulators addons. Since we're initially disabling addons in the emulator anyway, I just commented out 4 lines of code to get the addons compiled.

And now... Hey, look! The rest of the emulator's core compiled perfectly!!! But wait... We still need to compensate for OGLRender (I excluded it from compilation in beginning of the post, remember?) Perhaps it's best for me to explain things if I explain them this way:

The current state of the emulator: Except for OGLRender, the entire core of the emulator has compiled perfectly under libogc. To get the emulator launching NDS ROMs on the Wii, we need to first finish porting/rewriting OGLRender and then rewrite the GUI of the emulator (the GUI should be pretty simple to do). While it doesn't seem like much (and in reality, it's really not) we still have a bit of a way left to go before we get ROMs emulating with our DeSmuME port.

Profetylen and I would love a hand with OGLRender, so please contact either of us some way if you think you can help. Available below for download is the latest source revision for our port of DeSmuME (excluding our current state of OGLRender -- The included in the download below is the original OGLRender).
Download

Click here to read the previous part of the port.

Porting DeSmuME to Wii - Part 3 -

First a progress update: I'm still working really hard on porting over the OpenGL to GX and rewriting portions of OGLRender.cpp to work on Wii. Profetlyn has been helping me a great deal. Hopefully, "part 4" of this port will be up within a week or so explaining how we ported the OpenGL dependent code.

Now onto the content of this post:

In this post, I'd like to explain how the emulator works. No, this isn't a post about how emulation in general works, but instead about how the DeSmuME itself works. Let's get started shall Wii?

There are two main parts of DeSmuME; The core and the GUI.

The core of DeSmuME is essentially a library of functions that when used together properly can emulate a ROM. Each function plays a specific role in the emulation such as one to apply shading to objects and one to output a part of the sound. The source files in the "src" folder are the core of the emulator.

The GUI (GUI = Graphical User Interface) properly uses the core to emulate a ROM. The GUI selects which ROM to emulate, handles the loading of saves/savestates, the application of cheats, and maintains all of the information used by emulator in the RAM. Once the GUI for DeSmuME has selceted a ROM, it calls all of the ncessary functions (in threads of loops of course) to run that ROM. The GUI is inside the "Windows" folder inside the "src" folder. Eventually, it will need to be completely rewritten. The folders "cocoa", "gtk", and "gtk-glade" are ports of the Windows folder used for other platforms (linux, mac, etc.)

Also, for the record, there's an "addons" folder which contains experimental code used to emulate some features of Nintendo DS extensions like the rumble pack and the GBA Slot. Initially, this experimental code will probably not be included in the port to Wii.

For rendering, the emulator uses OpenGL. This will be converted into GX during the ported process. For sound, the emulator uses SDL. There is already a great SDL port for Wii (thanks Tantric :) ), so we will use this port output sound.

To port the emulator, we must first port the emulator's core so that it may be properly used to emulate a ROM on Wii. We must then port (actually, probably rewrite from scratch) the GUI so that we can actually emulate a ROM. Initially, the ported/rewritten GUI will be much simpler than DeSmuME's, but should eventually become fully featured.

profetlyn and I are still looking for some additional coders with a little more knowledge then us to work with us and help us with this port so it goes a little more quickly and accurately. Please contact either of us if you think you can help out.

Click here to read the next part of the port.

Click here to read the previous part of porting DeSmuME.

Porting DeSmuME to Wii - Part 2 -

This post has been updated since it was originally posted and a new source revision is available for download at the bottom of the post.

So now that we're set up to compile under libogc, let's get to porting the main (or "core") part of DeSmuME.

If we just make, a few of the files will compile fine and then we'll get an error that 'PATH_MAX' is not defined. To take care of this error, go into types.h and comment out or remove the following code:
#ifdef __GNUC__
#include
#define MAX_PATH PATH_MAX
#endif

Then, in NDSSystem.h, add the following line of code:
#define MAX_PATH 200

MAX_PATH represents the maximum number of characters that can be in a path (a path is a location such as sd:/apps/myapp/boot.dol). Because we don't have access to the library that defines PATH_MAX, we need to define MAX_PATH on our own. I'm using the number 200 for now for simplicity, but we could extend that to something that allows for paths with a much higher character count.

So now a few more files will compile fine... And then we'll get errors in MMU.h that std::wstring doesn't exist. We can correct this with the following line of code in movie.h:
#define wstring basic_string

We must do this because libogc lacks proper wstring support.

Now a few more files will compile fine (remember, we can ignore warnings)... Until we get to problems with OGLRender.cpp and OGLRender.h To correct these errors, we'll have to replace the OpenGL dependent code with code dependent on libogc's GX. This shouldn't be particularly difficult since most of the GX code looks strikingly similiar to OpenGL. We may have to switch up some parameters though, and of course, we'll have to properly link in GX.

So, at this point about 1/4th of the "core" of the emulator has been successfully ported to the Wii. I hope other people will take a stab at this (so I can come home from work tonight and see someone has already ported the OpenGL code ;) ) so we can get DeSmuME up and running on the Wii sooner.

You can download the latest revision of the source code of my port of DeSmuME to Wii by clicking here.

Click here to read the next part of the port.
Click here to read the previous part of porting DeSmuME.

Porting DeSmuME to Wii - Part 1 -

One of the most highly requested Wii Homebrew applications is a Nintendo DS Emulator. And why not? The Wii is certainly capable of handling the task with it's PowerPC processor more than ten times faster than the DS's ARM processor. The Wii also has more than ten times the amount of RAM then the DS. So I honestly don't see why this isn't possible to do. I'm almost certain we could get most (if not all) games running at full speed using just a basic interpreter emulator.

So I decided to do a bit of more research on the topic and looked through all of the open-source Nintendo DS Emulators available. The best (by far) was DeSmuME. It's been hailed as the best working Nintendo DS Emulator and many hackers have used it to test homebrew because the source for it is relatively simple (so modifications can be easily made).

So I downloaded the source to the latest release 0.9.4 and will be working on porting it as much as I can. Readers beware: I may never finish this port or just give up on it sometime in the process of porting - this is really complex stuff (far harder than anything I've ever done before). I'll be releasing the source code (and a detailed blog post on what I've done so far) every step of the way.

The first thing to do when porting anything to the Wii is to set up the project so that it compiles under libogc. I'll be using the Programmer's Notepad (PNP) IDE, so I've set up my enviroment to compensate for PNP with the proper .pnroj and .pnps files. I've made a makefile that starts at the src folder in DeSmuME - so that way I'm not tasking myself with doing any major rearranging of directories at all.

So, I now have DeSmuME set-up to be compiling under libogc. The first few files actually compile fine, and then of course there are some errors that pop up of things that need to be compensated for. None of the errors are really "bad" so far and I've already worked through quite a few of them already (this work is not present in the download at the bottom of the page).

So now that the DeSmuME is setup to be compiling under libogc, we just need to actually sit down and port the thing so that it does compile and then work. I'm expecting this won't be too bad as I've read through all of the source before even setting up for libogc and there's nothing that complex that needs to be seriously rewritten. I'm looking for collaborators on this project, and I will consider setting up an svn (on google) if I can find some people who would truly commit to working on this with me. I may not (and don't be surprised if this happens - it most likely will) be able to complete this project on my own. I will continue to keep my blog updated on the status of this project.

You can download the latest source code so far for my port of DeSmuME to Wii by clicking here.

Click here to read the next part of the port.

How to Output Text from Fonts with libwiisprite

Every good programmer knows that they can make their programs look better than they really are ( ;-) ) by printing their text using a High Quality Font. It's even better when you can change the color of that font on demand. Changing the font size on demand can produce some beautiful artistic designs too. All of this can be used to make a higher quality, more "polished" program.

Unfortunately, libwiisprite is the only of the three major libraries (the other two being GRRLIB and libwiigui) that can't output, or print, text using characters taken from a font. And while libwiisprite can't do this by itself, it doesn't mean we can't combine a few additional libraries to our program to do it ourself. This post will show you step-by-step how to get your programs that use libwiisprite to output text from a font.

The first thing we need to do is set up our enviroment. First lets go here and download and set up the FreeTypeGX Library. Carefully follow the instructions on the page to set up the library. Once you have FreeTypeGX set up and installed, go here and download the ftimage library. You can install it by placing the .h files in devkitPRO's "include" directory (or 'folder' for those of you that prefer Windows terminology) and the .a file in devkitPRO's "libs" directory.

Now let's set up the directory that the program we're making is set up in. (The path is probably something like C:/projects/wii/nameofyourproject In the directory for your program, you should have a directory named "data". If not, make one now. In "data" we will place the font that we want to use. Any font will do as long as it is in .ttf or .otf format.

Now, let's set up the makefile of our prgoram. First, add -lfreetype and -lftimage under LIBS: Then, add a rule for compiling your font. If you're using the .ttf font format, your rule will look like this:

#---------------------------------------------------------------------------------
# This rule links in binary data with the .ttf extension
#---------------------------------------------------------------------------------
%.ttf.o : %.ttf
#---------------------------------------------------------------------------------
@echo $(notdir $<) $(bin2o) -include $(DEPENDS)

Finally, let's get to writing the meat of the program. First, include these two lines of code wherever necessary:
#include "ftImage.h" //The ftimage library
#include "namefthefontinthedatafolder_ttf.h" //Font being used (you have it in the data folder)

Now, wherever appropriate, declare these two objects:
ftImage print(640, 480); //This will store the string of text we print
Sprite Text; //This Sprite will be used to render the ftImage member print

Now, this little snippet of code is all we need to prepare our objects to store and render text:
print.setFont(fthenameofthefontinthedatafolder_ttf, thenameofthefontinthedatafolder_ttf_size);//Set the font we are using
print.setSize(32);//Set the size of the font (should be a multiple of 4)
print.setColor(Color::Color(255,40,40));//Set the color of the font in RGB format
Text.SetPosition(100, 50);//Set the position of the starting point of the text we will print
Text.SetImage(&print);//Append print as the image stored by Text

You do not need to use the above code in the order that I did. You can also feel free to change the values used by it at anytime during the course of your program.

And finally, here's how we render text:
print.printf(" Hellow World!\n");//Set the string of text to be rendered (escape characters can be use to render more than one line)
print.flush();//Tell the computer that the string of text is ready
Text.Draw();//Render the text
print.clear();//Clear the stored string of text
print.reset();//Bring us back to the render starting point (defined by Text.SetPosisition())

You'll want to use all of that above code in every loop that render text. If you render text without calling clear() and reset(), the next time you render text; you will render the same text as last time plus the new text you want to render.

Because I love pastie.org so much, For your convenience I have pastied all of the code used in this post for you to view here since blogger doesn't format everything perfectly.

Thanks to ArminTamazarian for whom without FreeTypeGX, this guide would never have been possible. Thanks to my good friend Ave for whom without ftimage, this guide would also never have been possible. Thanks Ave, for also being a good friend and helping me with tons of stuff at the drop of a hat. I'd never be where I am today without you.

How to play external MP3 Files with libogc's MP3Player

It's hard for me to get into detailing the subject of this post without me providing a little preface detailing my experiences so far with libogc's MP3Player. This way, you'll know where I stand and why it takes such a complex method to play externally loaded .mp3s. Also, be aware that I've spent at least a good 15 hours working with the MP3Player over the course of my Wii Homebrew developments.

Libogc's MP3Player is nice in that it allows the programmer to play MP3 files loaded externally from the SD Card, or loaded internally from the RAM as a buffer. While I've always had surefire success with the latter method, the former has been hit or miss. When I have gotten it to work, I've always been unable to get the .mp3s to play on a loop. Any calls relating to the FILE holding the .mp3's freezes the Wii forcing me to physically get up from my chair and unplug the Wii. To that end, it's quite a conundrum to have such a wonderful MP3Player_PlayBuffer() function and such an unstable MP3Player_PlayFile() function.

However, to this day, I still haven't given up trying to play externally loaded MP3 files with libogc's MP3 Player. And today, I'm pleased to post on my blog that I've finally found a very stable, working, solution. The solution is, to put it plainly, to load an external MP3 file, turn it into a buffer, and then play the buffer with the MP3 Player. The rest of this post will detail the exact the code I used to get this to work.

First, in your makefile, under LIBS:, include the libasnd.a libmad.a libraries:
-lasnd -lmad


Now, wherever necessary, include asnd and the libogc MP3Player: 
#include (asndlib.h)
#include (mp3player.h)

And of course, initialize asnd and the libogc MP3Player before you do anything with them:
ASND_Init();
MP3Player_Init();

Let's declare all of the variables we're going to use:
FILE *BGM = 0;//This will store an MP3 on the SD Card
long lSize;//This will store the size of the FILE BGM
char * buffer;//This is our buffer that will take the place of the external MP3
size_t result;//This is the size of the buffer
bool mp3isready = false;//This keeps the music from trying to loop before the buffer is made

And now prototype a simple function that will keep the MP3 looping:
void LoopTheMP3();

Now let's load an MP3 file:
mp3isready = false;//Keeps LoopTheMP3() from working before the buffer is ready

BGM = fopen("sd:/MUSIC/bgm.mp3", "rb");

Let's obtain the size of said file:
fseek (BGM , 0 , SEEK_END);
lSize = ftell (BGM);
rewind (BGM);//Return to the beginning of the MP3 for good measure

Create the Buffer:
buffer = (char*) malloc (sizeof(char)*lSize);//Allocate memory to contain the whole file
result = fread (buffer,1,lSize,BGM);//Copy the file into the buffer

Play the Buffer:
fclose(BGM);//Since we no longer need BGM, get rid of it
MP3Player_PlayBuffer(buffer, lSize, NULL);//Play the buffer
mp3isready = true;//Let LoopTheMP3() know it can start working

If you're going to change songs, be sure to clear the buffer beforehand:
free(buffer);

Lastly, heres the code for our function to keep the MP3 Playing continuously:
void LoopTheMP3(){

if(mp3isready && !MP3Player_IsPlaying())
MP3Player_PlayBuffer(buffer, lSize, NULL);

}

As is the nature of programming, this code will probably need to be adapted and changed a bit to suit the flow of your program. However, I assure you that it does work and is the most stable way I've encountered yet to play externally loaded MP3 files. I have pastied the exact code I am using in Wii Shooting Gallery here to show you an example of that. I have another app (with source of course) made just to demonstrate the functionality here.

Special thanks go out to scanff who, without his support, I would've given up on libogc's MP3Player before ever even trying a buffer (that means there would've been no sound in WiiBreaker without his help :-O). Thanks to him, I've managed to continually expand my knowledge and bring you the solution I found; detailed in this post.

Coding Section

This post is an archive documenting all posts related to coding or computer programming.

General Programming Tutorials

• How to set-up and SVN on Googlecode and how to use Tortoise
  

C++ Tutorials

• What are C and C++?
• Setting up for C++
• Analysis of the Hello World program
• Comments with C++
• Variables with C++
• C++ Keyword: typedef
• The least you need to know about scopes with C++
• C++ Keyword: using and a little on Namespaces
• if ... then statements with C/C++
• Writing a sequential bruteforce attack in C/C++
• Writing a randomized bruteforce attack in C/C++
  

Wii Homebrew Development

• How to play external MP3 files with libogc's MP3Player
• How to output text from fonts with libwiisprite
• How to program with the balance board
  

My developments tools

• My ALLEGRO Sprite Class
• gl2gx Compilation
• libwiisprite devkitPROr19 recompilation
  

Insight

• Why I'm developing with ALLEGRO
• The bruteforce attack  
  
• More effective bruteforcing
  

Editorial

• Why Windows is the best target development platform for computers

Special: Porting DeSmuME to Wii

• Part 1
• Part 2
• Part 3
• Part 4
• Part 5