Woopsi Bugfix Bugfix; Rules of the DS DMA Hardware

A bugfix for the bugfix. I’ve rethought the locations of the DC_FlushRange() commands. It seems that you don’t need to worry about flushing the mem cache if you’re dealing with VRAM, so I’ve removed all of the the DC_FlushRange() calls from the GraphicsPort. I’ve rewritten the filled rect function to use DMA_Force() instead of DMA_Copy().

The only calls left are now limited to the SuperBitmap. One is in the SuperBitmap::draw() command, since we want to make sure that when we blit the bitmap we’re blitting the latest data. The second is in the SuperBitmap::drawFilledRect() command, as we need to be able to duplicate a value in main RAM. The last is in SuperBitmap::drawHorizLine(), for the same reason.

Here are the basic rules of the DS’ DMA hardware:

  • Always check that DMA activity has finished on a DMA channel before attempting to use that channel for something else
  • Never try to use the DMA hardware with the stack
  • If you use the DMA to copy values from main memory, ensure you call DC_FlushRange() on the region of memory you’re copying from
  • The DMA hardware works best when used with VRAM
  • The smallest data size that the DMA can work with is 16-bit, so don’t try to copy 8-bit data around unless a) you’re copying an even number of bytes, and b) the memory is aligned to the 2-byte boundary.


Jeff on 2008-02-27 at 23:01 said:

I think the restriction on the stack is actually:

>> never try to use the DMA hardware with the ITCM area of memory.

devkitpro appears to set things up such that the stack will be in the ITCM but I believe other stuff can be in there as well.

Conjecture at this point, I’d really like an expert to confirm it.