We've just rolled a rather large update for both devkitPPC and devkitARM which brings the newlib patches much closer for the two toolchains. In preparation for 64 bit we've had to update the libsysbase devoptab interface to use pointers instead of ints for the file descriptor. If you're using your own devices it's just a matter of changing the file descriptor from int to void * & recompiling.

Binaries available through the Automated Installer/Updater as usual. Use the exe for windows, the perl scripts for other platforms.

devkitARM release 46

• updated to gcc 6.3.0.
• updated binutils to 2.27.
• updated newlib to 2.5.0.
• updated gdb to 7.12.
• ndstool can now output dsiware compatible nds files, complete with dsi mode binaries.
• *.twl.* source files now compiled into DSi sections.
• picasso updated to 2.5.0.
• bug fixes in 3dsxtool.

libnds 1.6.0

• DSi specific code moved to DSi sections.
• Macros added to mark code/data/bss for DSi sections.
• DSi nand access exposed.
• Fixed touchscreen in DSi mode on 3DS.
• Updated for libsysbase changes.

dswifi 0.4.0

• bugfixes and stability improvements based on feedback from Martin Korth.

devkitPPC release 29

• updated to gcc 6.3.0.
• updated newlib to 2.5.0.

libfat 1.1.0

• Updated for libsysbase changes.
• errno corrections.
• Don't attempt to mount DSi SD in DS mode.

libctru 1.2.0 - see changelog @ https://github.com/smealum/ctrulib/blob ... angelog.md

citro3d 1.2.0

• Major revamp of the 3D math library with many contributions from mtheall and tommai78101, including support for quaternion math.
• Added C3D_ImmDrawRestartPrim and C3D_GetCmdBufUsage.
• Added renderqueue-safe versions of GX commands.
• Miscellaneous bug fixes.

Other libraries not mentioned have been updated for libsysbase changes and/or recompiled for latest tools and libraries.

TODO

• recompile portlibs with latest tools.
• [strike]merge and tag libraries in git repos.[/strike]

We recommend that all libraries in use are recompiled from scratch.

Congratulations on release :D

I'm curious to know if hbmenu will be updated to handle homebrew compiled to use DSi Extended binaries as I'm sure there's no homebrew out there right now that handles them at the moment. Nice to finally see devkitarm embracing the "standard" SRL header layout. The old way created some issues if you wanted to run the homebrew from Home Menu on 3DS. Mostly an issue for those who have CFW. Not so much for DSi/DS.

That was done a few days ago & released this morning.

https://github.com/devkitPro/nds-hb-men ... tag/v0.6.0

Any DS homebrew compiled with latest tools/libs will now be automatically hybrid complete with extra DSi binaries.



We even made a cia to boot hbmenu (or indeed any homebrew named boot.nds on the root of SD card)

It's rather annoying to have to waste 15K of header and 2K of binary just to get it installed as DSiWare though :/

Yeah a good portion of that header space is for security stuff that homebrew don't need like hashes for the arm binaries and what not. NTR headers though seemed unnessecerly large. Untill TWL SDK came out, NTR headers had mostly dead space/nothing after the logo region in the header. Maybe related to how their NTR carts work. but yeah so much empty space between their header and where the game's binaries begin way out at 0x4000. So much wasted space.

TWL_FIRM is unfortunately pretty picky with what you do with the header so until this update to devkitarm came out, we've had to move things around post compile. Also, unlike the DS and perhaps the DSi, the arm7 code/ram entry addresses were limited by what I think must be a security thing in TWL_FIRM. You can't use the addresses that homebrew use (and many older flashcarts which also use those same addresses) else TWL_FIRM displays an error has occurred screen and doesn't even bother to launch the embedded devlauncher in twlBg, so what ever that is might be being blocked by process9. But that's just a guess as I lack reverse engineering skills.

Early on we just used a tiny payload at the start of arm7 to "move" arm7 back to the address homebrew wants to use. While not convenient I guess maybe that ended up being a tiny bit cleaner then how it was done after where the ld files were messed with to result in homebrew compiling to use the right addresses to start out with. But perhaps there was some flaws with that as I've seen from what you pointed out to Ahezard over on github.

Hi,

After intstalling the newest update (via Windows updater) a couple of issues encountered:

1. The deployed grit binary crashes at launch (grit files are valid). The source seems to be ok cause after checking out the newest sources (https://github.com/devkitPro/grit) and compiling the executable myself it works again.

2. NitroFS is not working anymore, neither in no$gba nor on a real ds-lite (using nds-hb-menu).

If I start the sample ("examples\nds\filesystem\nitrofs\nitrodir") in no$gba, ftell() always returns -1. I was able to get it to work in the emulator by using fstat() to retrieve the filesize instead of ftell(). On the real ds-lite, fopen() always fails (returns a null pointer).

3. "Textured_Cube" ("examples\nds\Graphics\3D\Textured_Cube") sample crashes in no$gba

It works if i replace the following lines within the while loop:



with this code:


My vague suspicion is that it has something to do with the matrix stack.

Cheers...

I've tested this on a fresh install with windows 10 and windows 7 without crashes. What version of windows are you running? Do you have any of FreeImage.dll, libgcc_s_sjlj-1.dll, libgcc_s_sjlj-1.dll and/or libstdc++-6.dll in your path from anywhere other than the devkitARM bin folder?



This has been tested with no$ 2.8 and 2.8d, on DS using hbmenu from gbamp, on DSi using hbmenu via sudukohax and in DSi mode on 3DS using the hbmenu bootstrap CIA. It works under all of those.

Are you using latest no$ and latest hbmenu?



This works on hardware. "Fixing" code for emulators isn't a good idea.

WinterMute, I know there is two revisions of devkitPPC release 29:
http://download.sourceforge.net/devkitp ... ux.tar.bz2
http://download.sourceforge.net/devkitp ... ux.tar.bz2

There problem is that devkitPPC_r29-1 seems to contain Windows files instead of Linux as expected by the name linux.tar.bz2

The one without the -1 seems OK, but the problem is that the ini file uses the wrong one:


Thank you.

Sorry, minor packaging issue. Got it sorted a couple of days ago, as you know from IRC

Wiimc recompiled and everything works fine