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.

C/C++ > DevkitARM r8 to r18 creates an alignment problem with DMA3?

#82809 - DiscoStew - Wed May 10, 2006 8:25 am

This is probably a fault of my own with my programming, but here I go anyways...

Before, when I used an older version of devkitARM (r8 to be exact), and when I'd compile my program, everything was working as it should be. However, I switched to r18 hoping to continue with what I had with more current software, but the tilesets I was DMAing over were getting screwed up. I was using DMA_32NOW from a 16 bit array to VRAM, and the bits were off by 4 pixels. DMA_16NOW works fine though, which is why it is most likely my own fault with bad programming, but like I said, it was working before with DMA_32NOW with r8. However, does using DMA_16NOW take longer than DMA_32NOW, and if so, if I want to keep my data copying fast, I need to align my arrays to a 4 byte boundary, right? I'm kinda rusty on the alignment method though.
_________________
DS - It's all about DiscoStew

#82814 - wintermute - Wed May 10, 2006 9:39 am

If you're defining your data as arrays then use code like this :-
Code:

const u8 ArrayName[] __attribute__ ((aligned (4))) = { ...


the libgba and libnds headers define a macro
Code:
#define ALIGN(m)   __attribute__((aligned (m)))


so you can write
Code:
const u8 ArrayName[] ALIGN(4) = { ...

_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog