devkitPro

libnds 1.4.10, the default arm7 0.5.10 and libfat 1.0.9 are now available through the windows installer as usual and from the getting started page on the wiki.

libnds 1.4.10

• adds support for Tetris paddle and Guitar Hero grip controller courtesy of Zeromus.
• adds support for easy piano controller, courtesy of 0xtob.
• sdmmc support added for reading DSi internal SD card, courtesy of Blasty.
• add functions for ticks to usecs and ticks to msecs in timing macros.
• i2c communication functions added for DSi.
• keyboardInit() now defaults to hidden (which was the original intent).

default arm7 0.5.19

• recompiled with latest libnds.
• correct power button handler in DSi mode.

libfat 1.0.9

• Add support for internal SD on DSi.

note: current stable version for ogc remains 1.0.8, a 1.0.9 built with a yet to be released devkitPPC was accidentally released but this has since been corrected.

nds examples 20110201

• updated for changes in latest libnds.
• some bugs fixed in examples

With thanks to blasty, zeromus, yellows8, dovoto and Team Cyclops for their contributions to these releases.

This looks to be great step forward for the DSi. Thanks to all involved for the work they've done.

I have some questions if anyone is willing to help me understand. Being a little naive on the subject of devices/cards/interfaces, I tried to figure out why I couldn't get a nitro homebrew to work with this new code. Perhaps it isn't ready yet and I'm not aware.

I rebuilt libnds-master at home yesterday and then my little demo against it. Using sudohax I successfully started up a yesterday's-build of hbmenu renamed as /boot.nds. When I chose my demo from the menu, all I received was a white screen and hangs. My demo code calls nitroFSinit() and reads files from there.

Poking around in the new svn code, I understand things in theory as:

1. Inside nitroFSinit(), fatInitDefault() is called, which mounts the new/first-in-the-list-to-try SD:/ interface (which becomes the default, if successful).
2. nitroFSinit() returns after chdir(nitro:/)
3. Homebrew continues on...

- However, inside nitroFSinit(), there's a check for "fat:/" in ARGV. I know hbmenu provides ARGV, but is hbmenu sending along "fat:/myrom.nds" or "sd:/myrom.nds"?
- does chdir(sd:/) even work? I mean, to me it seems the "fat" layer would need to be on top of that to work.
- So, for future, would the proposed way to access files be:
a) nitro FS -> nitroFSinit(); chdir("nitro:/"); fopen("/my-nitro-file-in-the-rom");
b) fat16/32 FS -> fatInitDefault(); chdir("fat:/"); fopen("/my-file-on-fat-filesystem-on-the-sd-card");

Like I said, naive.

P.S. I have a white DSi (Nintendo's 2nd hardware rev) with a non-SDHC card inserted
P.P.S. I have to run here, didn't proof read my post yet

Fantastic!

Now that we can use the internal SD card reader, how much longer till we have a version of dslink that is able to read apps from SD, additional to the already existing WiFi loader? Or is that already included in the newest dslink release?

i tried the newest dslink and fatinitdefault fails in the downloaded nds file.

Izhido wrote: Now that we can use the internal SD card reader, how much longer till we have a version of dslink that is able to read apps from SD, additional to the already existing WiFi loader? Or is that already included in the newest dslink release?

Isn't that completely missing the point? The internal SD is only accessible when booting from sudokuhax - SVN hbmenu will work fine when used as boot.nds but I won't be releasing a binary of that until I've sorted a couple of issues with loading speed.

elhobbs wrote:i tried the newest dslink and fatinitdefault fails in the downloaded nds file.

Did this work before?

Sorry if I gave the impression that internal SD was accessible from the save game exploits, it's not.

ritz wrote: - However, inside nitroFSinit(), there's a check for "fat:/" in ARGV. I know hbmenu provides ARGV, but is hbmenu sending along "fat:/myrom.nds" or "sd:/myrom.nds"?

hbmenu will provide sd:/myrom.nds

you can add a check for sd in libfilesystem as well as fat, I tried this before the releases but it seemed to hang & I didn't really want to delay the other libraries while I looked for the issue.

It might just be that the nitrofs code is spectacularly slow using the driver for the internal SD, I don't know yet.

WinterMute wrote:Did this work before?

Sorry if I gave the impression that internal SD was accessible from the save game exploits, it's not.

no, it did not work before. I was using dslink from a save game exploit. I saw that it had been updated, so I was thinking that it would work - my bad.

Is it just me, or when I look at libnds, libfat, and defaultarm7 on sourceforge, they only show "previous" as an option? I don't develop on a Windows machine so I can't check using the Windows Installer.

Looks like the SF release system isn't quite back to normal after the recent attack. I see the files when I'm logged in but not when logged out.

These are direct links to the recent releases.

http://downloads.sf.net/devkitpro/libnds-1.4.10.tar.bz2
http://downloads.sf.net/devkitpro/libfa ... .9.tar.bz2
http://downloads.sf.net/devkitpro/defau ... 19.tar.bz2

Just a question, there are problems with the svn, I cant access at the sources, can you post the libnds sources tarball, please?