#22466 - DiscoStew - Tue Jun 22, 2004 6:35 am
Would DMA copying be faster if I am continually using it in a group of operations than between long pieces of code?
I've been thinking of making an array that consists of a bunch of addresses and operations for use with DMA so that I am continually using DMA. My thought would be to increment pointers to the array for each source, destination, etc. each time a DMA operation was done until it reaches the end of the list. Would that be a good idea? Or does it not matter?
_________________
DS - It's all about DiscoStew
#22467 - tepples - Tue Jun 22, 2004 6:57 am
Remember that DMA halts the CPU. If you're trying to fit a bunch of DMAs into vblank time, such as if you're loading sprite cel data, then your transfer queue idea might work.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#22470 - DiscoStew - Tue Jun 22, 2004 9:39 am
You really do seem to know what I'm working with, huh tepples? I've been working on my sprite handler for so long, that people immediately know what my current topics are related to.
Then again, it could have been a lucky guess, since DMA questions are usually related to image data transfering...
| tepples wrote: |
Remember that DMA halts the CPU
|
I'm getting the feeling that since this is the case, my idea of a continual stream of data being copied through DMA to different places in memory may not work out for the better (in terms of speed I thought I could gain). Now I don't know what happens when the GBA switches between the CPU and DMA, but since I would have use the CPU to increment the pointer that points to the array in between DMAs (since there is no other way that I know of), it seems kinda pointless to do this compared to what I currently have, which is immediate DMAing instead of making a list and doing all DMAs in a row. The DMA registers are capable of incrementing to the next address in memory, but not incrementing a pointer to an address.
If anyone has any thoughts/ideas on the subject that may help, please post. thx.
_________________
DS - It's all about DiscoStew
#22474 - sgeos - Tue Jun 22, 2004 11:43 am
You might be able to have a more productive vblank if you do things like this: | Code: |
setup_for_first_frame();
fade_in();
while (not_done) {
wait_for_vblank();
execute_dma_queue();
setup_for_next_frame();
do_non_time_critical_stuff();
} |
| gbatek wrote: |
| After changing the Enable bit [in DMAxCNT_H] from 0 to 1, wait 2 clock cycles before accessing any DMA related registers. |
Would this have any bearing on a DMA queue?
-Brendan
#22481 - tepples - Tue Jun 22, 2004 8:30 pm
| sgeos wrote: |
| gbatek wrote: | | After changing the Enable bit [in DMAxCNT_H] from 0 to 1, wait 2 clock cycles before accessing any DMA related registers. |
Would this have any bearing on a DMA queue? |
Probably not. If you put your actual DMA copy in a separate function that's not inlined, the 'bx lr' at the end of the function should cover those 2 cycles nicely.
And of course, if you're using serial communication, use BIOS CpuFastSet() instead of big monolithic uninterruptible DMA transfers.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#22482 - dagamer34 - Tue Jun 22, 2004 8:31 pm
| sgeos wrote: |
| gbatek wrote: | | After changing the Enable bit [in DMAxCNT_H] from 0 to 1, wait 2 clock cycles before accessing any DMA related registers. |
Would this have any bearing on a DMA queue?
-Brendan |
The waiting 1-2 cycles bit is for assembly programmers.
_________________
Little kids and Playstation 2's don't mix. :(
#22491 - sgeos - Tue Jun 22, 2004 11:48 pm
| tepples wrote: |
| And of course, if you're using serial communication, use BIOS CpuFastSet() instead of big monolithic uninterruptible DMA transfers. |
If using serial communication, could CpuFastSet() be used to fill the sound FIFOs in a reliable manner?
-Brendan
#22497 - poslundc - Wed Jun 23, 2004 3:09 am
You would have better luck using an interrupt and just loading and storing the data out of memory yourself. One of my earlier mixers used such a technique, but it is rather wasteful.
Better to use the DMA, since it's designed for that purpose. As for difficulty with serial communication, has anyone ever really run into a problem there? I've not done any link programming so I can't say, but I would think the 8 cycles or so the DMAs would halt the CPU for stereo sound wouldn't create too much of a problem.
Dan.
#22499 - tepples - Wed Jun 23, 2004 3:20 am
| sgeos wrote: |
| If using serial communication, could CpuFastSet() be used to fill the sound FIFOs in a reliable manner? |
I don't think anybody has tried CpuFastSet in any mode other than DMA_COPYNOW. And I agree with poslundc that FIFO filling wouldn't reasonably delay FIFO filling, as the gap between FIFO fetches (once every 4 samples) is at least on the order of 2500 to 5000 cycles for typical GBA PCM playback rates.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.