Here’s a basic overview of the code:

main.c

int main(int argc, char ** argv) 
{
    PROGRAM_STATE pState = MENU;
    touchPosition touch;
    consoleDemoInit();
    filesystem_init();

consoleDemoInit() is a libnds function that initialises the DS’ displays for console only display. filesystem_init() calls the libndsfat function fatInitDefault() to initialise the filesystem and if successful reads from a config file on the SLOT-1 device.

    for(;;)
    {
        //update input state
        scanKeys();
        touchRead(&touch);
 
        switch (pState)
        {
        case MENU:
            menu_draw();
            switch(menu_handleinput(&touch))
            {
            case 0:
                pState = CONFIG;
                break;
            case 1:
                pState = ROLLER;
                break;
            }
            break;
 
        case CONFIG:
            config_draw();
            if (config_handleinput(&touch) == -1)
                pState = MENU;
            break;
 
        case ROLLER:
            roller_draw();
            if (roller_handleinput(&touch) == -1)
                pState = MENU;
            break;
        }
        swiWaitForVBlank();
        consoleClear();
    }
    return 0;
}

The second part of the main function is the program loop. It is a simple state machine that has three states, a main menu, a configuration menu and the roller itself.
The first couple of function calls each loop are to libnds functions that update the user input state, scanKeys() for button presses and touchRead(&touch) for the touchscreen’s currently pressed coordinates. Each state then has a draw function and a handleInput function.

Finally there are another couple of calls to libnds. The first (swiWaitForVBlank()) blocks the program until the VBlank interrupt is triggered indicating that the screen has finished drawing. The second (consoleClear()) clears the console with an ANSI escape sequence.

menu.c

void menu_draw(void)
{
    int i;
    iprintf("\x1b[2;2H");
    iprintf("Welcome to DS Dice Roller\n");

This is the menu drawing function. iprintf is used rather than printf to avoid any inadvertent formatting of floats. The “\x1b[” string is the ANSI control sequence indicator and is followed by the row and the column of the desired position of the cursor.

int menu_handleinput(touchPosition * touch)
{
    int keys = keysDown();

keysDown() is a libnds function that returns an integer that is a bitwise OR of the current buttons pressed by the user. It is masked off to find the status of the buttons.

config.c

void config_numberinput(int * n, int max, Keyboard ** k)
{
    int key;
    if (!*k)
    {
        *k = keyboardDemoInit();
    }
    if (!(*k)->visible)
        keyboardShow();
 
    key = keyboardUpdate();
    if (key == '\b')
        *n /= 10;
 
    if (key >= '0' && key <= '9')
    {
        *n *= 10;
        *n += key - '0';
        if (*n > max) *n = max;
    }
 
    if (key == '\n')
    {
        keyboardHide();
        if (filesystemInitialised)
        {
            char buf[8];
            int n;
            FILE * f = fopen("diceconfig.bin", "wb");
            n = snprintf(buf, 8, "%d\n%d", num_sides, num_dice);
            if (n > 8) n = 8;
            if (f != NULL)
            {
                fwrite(buf, 1, n, f);
                fclose(f);
            }
        }
        cState = CONFIG_SELECTION;
    }
}

The only other interesting function. keyboardDemoInit() is called once to initialise the default on-screen keyboard. keyboardShow() displays the keyboard and keyboardUpdate() returns the ASCII character that represents the key pressed. As you can see, writing the results to storage is a simple matter of calling the appropriate C I/O functions.

Next on the schedule is the interesting part, actually rendering something other than text on the screen.

Up to date source code for the project can be cloned from the project site on Github or if you don’t use Git, can be downloaded from here.

Luckily for me the Nintendo DS has a fairly mature homebrew scene so back in April I bought the new DSi hoping all the eager software pirates out there would be quick to crack the firmware and enable the running of unofficial software on it. Unfortunately this hasn’t really happened but fortunately enough, a few DS SLOT-1 device manufacturers were able get versions of their devices out that would support DS homebrew on the DSi. None of the extra DSi features or power are available but it’s better than nothing.

So, on to the meat of the story. The Nintendo DS is a very capable little beast. It has two CPUs; an ARM7 clocked at 33MHz which is mainly used for interacting with the hardware; and an ARM9 clocked at 67MHz which does most of the processing grunt work. You also have 4MB of RAM to play with not including the VRAM and numerous caches. The DSi one ups all of this; doubling the clock speed of the processors and quadrupling the size of the RAM. Unfortunately this is unusable to homebrew developers at the moment as only the “DS mode” has been cracked meaning the clock speeds and available RAM are constrained to the DS’ capabilities.

Using the fantastic devkitPro toolchain I was quickly able to get a build environment up and going and through the tutorials here and here I was able to get a handle on the libnds library provided by devkit. So I’ve decided to start hacking on a dice roller. One of my loves in life is pen and paper roleplaying games and a recent game of Scion is beginning to get out of hand with the amount of 10-sided dice I am having to roll. In the interest of having something to waffle on about and impress random strangers on the internet with I am going to chronicle my attempts here (with BSD licensed source of course). Hopefully someone gets something out of this other than me.

Little did I realise until I started the relevant course at University that there is really no magic to it. Most of the concepts like memory layout and addressing, the stack, the heap and bit wrangling I’d already picked up in dealing with C. The existence of Registers and why all operations are done on them makes sense when thinking about the phsyical nature of the chip. It’s almost disappointing in a way, like a Magician revealing how he does his tricks.

While there are some good things about it compared to other countries’ equivalent laws (software decompilation for interopability purposes is allowed for example), there are still some massive shortcomings. Most Kiwis are aware of the copyright laws introduced in the days of the VCR that effectively make it illegal to shift any digital content to another format (e.g. ripping your CDs so you can play them on your portable music player). These were retarded back in the day and are even more so now. One of the things this amendment was supposed to fix and indeed what most people are fixating on, is this problem of format-shifting. While the illustrated example has been fixed in section 81A, this only applies to recorded sound. There is no such provision for digital video. Quite frankly it isn’t fucking good enough.

If I were to purchase the “right” to download a digital video on to my hard-drive (that wasn’t protected by DRM but we’ll get to that later) and convert it to a format that would play on my iRiver that has modified firmware to let it play video, I would in fact be breaking the law. Fuck you Judith Tizard.

Then we get to the clauses on Technological Protection Measures (TPMs) of which DRM is a type of. Like the DMCA it is illegal to circumvent or provide/describe methods for circumvention of TPMs. Only if the TPM is preventing rights that fall under part 3 of the original Copyright Act of 1994, which effectively just covers libraries and educational institutes, is it allowed to bypass the TPM. Cases like the recent MSN Music debacle are not covered.

As any scientist worth his salt will tell you, it is impossible to produce a perfect DRM system. Those bits have to be decrypted at some point. Unless the Recording Industry is completely fucking retarded, they have to realise this and in fact this whole business with DRM is not to stop pirates but to impose further restrictions on legitimate users. But that’s another matter.

As a content creator and consumer I say this whole amendment sucks for both sides unless you’re a large content provider in which case it will make you bucket loads of money.