gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Announcements And Comments > devkitARM release 28 and associated libraries.

#172708 - wintermute - Fri Feb 26, 2010 12:41 am

Freshly uploaded for your development pleasure ;)

For full details see the post on the main devkitPro site http://www.devkitpro.org/devkitarm/devkitarm-release-28-and-associated-libraries/
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#172719 - ritz - Fri Feb 26, 2010 3:45 pm

Thanks for the release! I was able to upgrade my project very easily and everything worked without code changes. However, I do have an issue that I didn't have with r27: my ARM9 binary has now grown close to 60KB more. After digging around in the .map file (and comparing it to a r27 .map), I've determined that most of the libg.a stuff I'm linking in is almost double in size. Is that just because of the newlib update or new gcc stuff? Maybe debugging left in? Anyone else see this?

#172731 - headspin - Sat Feb 27, 2010 12:18 pm

Thanks for the update MW and crew. I was looking at the diff for mpu_setup.s and noticed there was a pretty serious bug fixed. A bug which has the potential to make your entire app unstable. I urge everyone to update to the latest devkitARM.

Code:
@---------------------------------------------------------------------------------
__libnds_mpu_setup:
@---------------------------------------------------------------------------------
@ turn the power on for M3
@---------------------------------------------------------------------------------
   ldr     r1, =0x8203
   mov   r0, #0x04000000 @ <-- this line was missing
   add   r0, r0, #0x304
   strh    r1, [r0]

_________________
Warhawk DS | Manic Miner: The Lost Levels | The Detective Game

#172732 - wintermute - Sat Feb 27, 2010 3:40 pm

ritz wrote:
Thanks for the release! I was able to upgrade my project very easily and everything worked without code changes. However, I do have an issue that I didn't have with r27: my ARM9 binary has now grown close to 60KB more. After digging around in the .map file (and comparing it to a r27 .map), I've determined that most of the libg.a stuff I'm linking in is almost double in size. Is that just because of the newlib update or new gcc stuff? Maybe debugging left in? Anyone else see this?


The gcc optimiser has been getting steadily more aggressive with the 4.4 series which does seem to result in larger code. I'm planning to look at building more of the libraries with dead code elimination options in the near future.

Headkaze, actually the mpu setup is called from the crt0 directly after interrupts are disabled when r0 holds the correct value. That line was simply added for clarity and to avoid problems if the call needs moved.

The actual issue that was fixed relates to when the temp stacks are set up in order to allow the bios call which detects debug memory.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#172733 - headspin - Sat Feb 27, 2010 5:04 pm

Thanks for clarifying. I do like that the bitmap sprite issue is fixed too.
_________________
Warhawk DS | Manic Miner: The Lost Levels | The Detective Game

#172736 - zelbo - Sat Feb 27, 2010 8:49 pm

i'm really excited about this in particular: "set background colors in consoleInit functions"

if that does what i hope it does, my text wont have to have a transparent backround.

except i can't figure it out. when i look at console.h (last modified 11/3/2009 10 am) i see this line:
Code:
PrintConsole* consoleInit(PrintConsole* console, int layer, BgType type, BgSize size, int mapBase, int tileBase, bool mainDisplay, bool loadGraphics);

i can't see anything there about background color.

Am i missing something? did i update wrong? i wouldn't put it past me.

#172737 - wintermute - Sat Feb 27, 2010 9:13 pm

Prior to this release the console init functions didn't set the backdrop colors in the palette, just the foreground colors. This meant that the background color was whatever was set last which led to some amusing color setup after exiting to menu with the new code.

What you hope it did isn't really possible without an awful lot of fiddling about, sorry to get you excited.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#172763 - ritz - Mon Mar 01, 2010 8:57 pm

wintermute wrote:
The gcc optimiser has been getting steadily more aggressive with the 4.4 series which does seem to result in larger code.

Thanks for the info. I noticed that the latest newlib version has had some major locale related work added to it. This looks to have contributed to the size too.

#172772 - Cearn - Tue Mar 02, 2010 3:22 pm

I've made a little project with just a single main() and a printf() call and compared the mapfiles for DKA r26, r27 and r28 (see here for an excel file with the results). It seems to be related to two things:
  • the locale stuff ritz mentioned (all sorts of extra mb, wchar, utf and more conversion routines).
  • A number of functions have increased in size by 50 to 100%, including a number of mem* routines, and very deep routines that start with two underscores. Maybe the loop-unroller and inliner have been a little overzealous?
Also, grit 0.8.5? Did I miss a version?

@zelbo
The transparency in the console is caused by having zero-pixels (pixels with value 0) in the tiles. If you want them to be opaque use a font that doesn't have them, or do a post-processing step that will un-clear those pixels. Since the console fills the text pixels with 0xF, you can just OR the whole region with, say, 0xEEEEEEEE so that the letter pixels have value 15 and the background pixels have 14. It's a bit hackish, but it works.

#173187 - wintermute - Thu Mar 25, 2010 10:01 pm

It seems that newlib ended up being compiled without optimisation which accounts for at least some of the extra size. Fixed in release 30

http://forum.gbadev.org/viewtopic.php?t=17176

I rolled a 0.8.4 release of grit with an extra error message + 0.8.5 had the build process updated to produce OSX 10.4 compatible binaries. Release 30 has your latest changes rolled in as 0.8.6 minus the static const int for sizes, that isn't a constant expression so it causes issues setting up tables at file scope.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#173416 - ritz - Mon Apr 05, 2010 10:21 pm

ritz wrote:
my ARM9 binary has now grown close to 60KB more

r30 fixed this for me, thanks
(just got back from vacation)