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.