Acekard 2i

I recently acquired an Acekard 2i for use with my DS Lite. I ordered the Acekard from r4i.co.uk (who are actually quite cheap for a lot of accessories) and got a 2GB microSD card for an extra £1 in the bundle. They also have other bundles with larger cards (or no card). The microSD card is needed because it's where you put all your precious files. There is meant to be a microSD reader in the bundle but I didn't receive one, I'm waiting for a response from them on that. Below is my quick guide to getting yourself up and running if you decide to get one for yourself. It's quite easy really.

Some features of the Acekard 2i in brief:

• No DS flashing or passkey/passme/passwhatever device needed.
• Supports all current DS variants (right now that's DSi, DSL, IDSL, DS and IDS).
• Supports any brand of microSD card (unlike some older devices which had timing constraints). There is a size limit, but I can't seem to find it on the site, I believe it was around 32GB.
• Older devices required software to be recompiled or patched for each different device it was run on, the Acekard handles this automatically.
• Can be used as a passkey in order to boot slot-2 flashcarts (for GBA experimentation), including the 3in1 cart. No need to worry about manually flashing your image to the slot-2 cart because the Acekard does this automatically when you boot a GBA ROM.
• Supports soft-reset, Download Play, and Wifi.

In terms of ethics, I know what you're thinking: "But Kemp, surely you don't condone playing pirated ROMs of DS games?" And no, no I don't. Sure, the Acekard has that capability, but this is one of those things I buy just to mess around with homebrew, and usually try to write a bit of my own at some point. The DS has a lot of nice features including two screens, one of which is a touchscreen, and wifi capability. Who wouldn't want to have a poke around on that? If you want help using it to play pirated games then you need to go find help somewhere else.

Setting up the Acekard 2i

The first thing you need to do is go and buy yourself a microSD card if you didn't order one along with the Acekard itself. It requires one for its own software, and you can't really do much without your own files anyway.

You should download either the official OSMenu software, or the alternative AKAIO software (which is a branch of the official software and widely regarded to be superior). This should be placed in the root of your microSD card. At this point insert the microSD into the Acekard and the Acekard into your DS, boot it, and check it works. If it hangs at the "Loading" screen then you didn't copy the software correctly.

That's basically it for the system software. Check out the options available, and make sure to change the options restricting the file types shown (you want the "All files" option).

Adding homebrew

I created a folder called "homebrew" in the root of the microSD card for this purpose. To get going you simply have to copy the .nds file for the program to this folder, boot up AKAIO, navigate to the homebrew folder, and click the file. It should be launched and (hopefully) work nicely. In general you can ignore any instructions to use DLDI to patch the software, as the Acekard handles this automatically for you.

Some nice software I've used:

• Moonshell (everyone knows this)
• DSNotes (I can't seem to find an "official" page)
• Pocket Physics

Writing homebrew

A good run-through for this is at CoderJoe.net. Surprisingly, this is one of the few times (the only time?) I've seen a cross-compiler toolchain that is easier to set up in Windows than in Linux. Well wonders never cease?

Adding Python

The good bit ;-) Download the dspython binary and copy it to your homebrew directory. This will automatically run the script at /python/main.py when it is executed, so create a "python" directory in the root of your microSD card and place a script there. As an example you can download the framebuffer demo given on the dspython site. At some point I will write a browser type script to place there that allows you to select another script to run.

There is a serious lack of documentation, but if you check out their svn tree then there are a some demos. In general though, the functions are named exactly the way they are in libnds (see above), so any documentation and demos for that should be fairly easily translatable into Python (within the constraints of what has been wrapped).

Final notes

As usual, GBATemp.net ran a good review of the device.

If anyone needs a picture for something I've mentioned then add a comment and I'll see what I can do.

Draft Code

The first writing is almost always a throw away, you should expect it and accept it, it will be significantly better the second time around. Once you build the code once, you have learned 90% of what was wrong with the design. A large rewrite at that point will pay off exponentially down the road.

Source (the jump to that post doesn't seem to work in IE, use Firefox :-)

This is very true, and my burning of an old codebase is very overdue. Damn the fact that it works just enough to not make it as a priority item... Anyway, I'm pretty sure this should be considered the coding equivalent of drafts of a document.

Perfect Code

Source.

The article linked above discusses the attitude towards coding among the team that writes the software controlling the space shuttle and how different it is to the generally accepted norm. Some choice quotes:

What makes it remarkable is how well the software works. This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats : the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors.

The group writes software this good because that's how good it has to be. Every time it fires up the shuttle, their software is controlling a $4 billion piece of equipment, the lives of a half-dozen astronauts, and the dreams of the nation. Even the smallest error in space can have enormous consequences: the orbiting space shuttle travels at 17,500 miles per hour; a bug that causes a timing problem of just two-thirds of a second puts the space shuttle three miles off course.

NASA knows how good the software has to be. Before every flight, Ted Keller, the senior technical manager of the on-board shuttle group, flies to Florida where he signs a document certifying that the software will not endanger the shuttle. If Keller can't go, a formal line of succession dictates who can sign in his place.

Bill Pate, who's worked on the space flight software over the last 22 years, says the group understands the stakes: "If the software isn't perfect, some of the people we go to meetings with might die."

Talk about pressure... And one last one:

Ten years ago the shuttle group was considered world-class. Since then, it has cut its own error rate by 90%.

They have a large enough budget to do what they need, they have formal practices in place to stop problems almost before they come into existence, and they don't get singled out and punished for mistakes (after all, if a mistake makes it through the process then other people also didn't spot it, and there must be a flaw in the process that can be fixed to prevent this happening in the future). Sounds like a perfect working environment to me :-) Now... where can I raise $35 million per year and find a crack team of coders to do my work for me?