devkitPro

dmaCopy as defined should be copying half-words, and as I understand it are 16 bit values.

I am working in the SimpleSprite example and added my own sprite array, just an array of 256 unsigned chars (output actually from PAGfx...).

Anyway, it's just a single 16 X 16 sprite named face_Sprite and I've removed gfxSub from the for loop that populates it with 1's and added this instead:

dmaCopy(face_Sprite, gfxSub, 128);

If writing in half-words, this should work, correct? This is, instead, only giving me the top half of the sprite and changing the 128 to 256 works fine... which is what is making it seem to be only writing 8bits at a time.

The same seemed to be true with dmaCopyWords... 64 in the size should have done the trick but that only gives me a quarter of the sprite.

The DMA functions I'm familiar with (PALib versions which are pretty similar) didn't work this way, but it's appearing that it's writing at the size of the source regardless of specifying word size with the function. Is this normal?

the dmaCopy* functions specify length in bytes which is truncated to the nearest 2 or 4 bytes as appropriate. This makes it much easier to work with automated output from tools such as grit not to mention making the code easier to grok.

http://libnds.devkitpro.org/a00063.html ... 22fe84245d

I really recommend not using PAGfx, grit is much more flexible. See http://forums.devkitpro.org/viewtopic.php?f=22&t=17 for a quickstart.

I will definitely give grit a try.

Lets just say I created my own unsigned char array then. If I understand your answer then the dmaCopy function should work as I believed it would and it's not.

If I have an array of 256 unsigned chars and use dmaCopy, shouldn't the size be 128?

EDIT AS I'm TYPING....

Okay wait, so it's always length in bytes? You don't need to compensate for Word or Half-Word and can just specify specific byte size? If this is the case and the amount copied is divisible by 32, wouldn't you always want to use Words?

Don't get confused between how the length is specified and how the data gets copied internally. We did it this way so that the user doesn't have to compensate for the copy size - memcpy works this way too, where source & dest are aligned properly then the copy will be in 4 byte chunks.