Sunday, June 28, 2009

EZ Flash Vi and libnds 1.3.6

The version of libnds and the default ARM7 core that was released as part of devkitpro last week (24 June 2009) has a problem with the NDS touch screen controls on the EZ Flash Vi cartridge.

The symptom is seen best if you run the nds-example "touch_test.nds" from the devkitpro distribution. The keys shows 00002000 in the top right, as if you were holding down the stylus, but in fact no touches are registered. Until an official fix is released by the ezflash coders, the workaround is to use devkitpro's own homebrew menu application. It's GPL code so there's no real conspiracy going on here! In fact it'd be nice to see this menu become the defacto standard in the homebrew world, but it is very rudimentary and only shows a textual listing of the files on your card.

So on to the instructions to get the latest homebrew working. I'll assume that right now you've downloaded and installed all the latest devkitPro stuff and you're sat there wondering why your touch screen controls don't work.

First download the latest EZ Flash DLDI driver from You'll have to download the "Kernel 1.90" zip file, extract it and find the Ez5s.dldi file. Now you have to download the Homebrew Menu code. This is only available in the devkitPro Subversion repository.

svn co
cd HomebrewMenu

Once that is compiled, you have to patch it with the previously extracted Ez5s.dldi file (if you use a high capacity SD card, use the Ez5sdhc.dldi instead). Do that using the dlditool in $DEVKITARM/bin:

$DEVKITARM/bin/dlditool /path/to/ez5190ob11/moonshell/Ez5s.dldi HomebrewMenu.nds

Now copy that file onto your card, but copy it as the ez5sys.bin file. This means that when the card boots up, it will boot our HomebrewMenu instead of the regular EZ Flash/Moonshell executable.

Hopefully the next release of libnds will fix the issue so that homebrew written with it is compatible with all cartridges out of the box. Even better would be if the Homebrew Menu started to see regular updates and became a really cool and useful file browser.

Monday, June 15, 2009

Lint and CMake

I've just updated my cmake-lint project with version 1.2. This fixed a bug that I introduced when I added in the ability to specify defaults in a .cmakelintrc file. This was one of those silly errors that using a compiled language would have caught, but in the end better unit tests would have caught it too. I'm not really a rabid TDD-weenie but automated tests that check for basic breakage are really handy. Python makes it dead easy to mock out unwanted and unrelated code too. Unit testing C++ is hellish in comparison.

As I was saying, cmake-lint is a really basic lint tool to root out common bad practices in CMake files and suggest some better practices. It also comes with some handy Vim plugins for working with CMake. One is a better version of the omni completion code I previously posted. The other is a :CMakeHelp command that helps you learn what all the CMake commands mean. There's no documentation for these plugins, but it should be obvious how they work. In Vim, type :CMakeHelp followed by the name of a command, or partial name and tab to complete. When you edit a CMakeLists.txt file, type CTRL-X CTRL-O to start up the omni completion.

I wrote these Vim scripts because CMake is a pretty good build system but there aren't that many IDE tools available. Actually, CMake is about my favourite build system ATM, it's quite a close call with Waf though. CMake's cross-compiling is probably what just pips Waf for any new stuff I do.

CMake lets you set up a regular build that compiles for the PC, and just by passing in the name of a file that describes a different compiler via the command line you can compile the same code for the DS. With Waf you have to faff about writing more code, cloning environments, fiddling with variants... That gets a bit messy and it's all manual, especially if you want to compile with debug flags too.

Waf does ease the pain of integrating multiple modules inside the same source tree though, and it doesn't compile templates down to Make (which seems slightly crazy). Although gyp also does similar craziness for Google Chrome, but converts python templates to Makefiles, SCons input files (!) or proprietary IDE project files. Makes you wonder why they didn't just go with CMake and add to it. I would have liked to have seen a CMake generator that spat out SConstructs, for example.