#23677 - benjamin - Sun Jul 18, 2004 7:31 pm
Are there a set of well known circumstances where DMA is called for and where it is not? I see it used in various techniques and places, but its not clear when it should and shouldn't be used..
#23679 - Abscissa - Sun Jul 18, 2004 7:37 pm
From what I gather, it shouldn't be used in most of the places that you see it used. But I have to admit, I'm a little unclear too on where it's is/isn't fast enough. I'm interested in the answer to this as well...
#23683 - poslundc - Sun Jul 18, 2004 8:13 pm
DMA is generally useful when copying medium-sized to large chunks of data. Smaller than 32 bytes or so it probably isn't worth it, on account of the setup time.
DMA is generally faster than manual copying of data because there is no overhead of looping and checking variables, but the memory access times remain the same, and the CPU is suspended while the DMA is active, so it's important to understand that while it is generally faster for large copies, it doesn't magically transfer the data instantaneously or anything.
DMA with a fixed source (for example, to fill a region of memory with a constant value) is generally slower than manual copying because the DMA has to reload the source for every copy. Consider using the CPUFastSet BIOS routine instead.
Also, because DMA halts the CPU it can interefere with your interrupts, so it's important to either make sure you aren't using the DMA when you need your interrupts to fire, or keep the transfers small enough so that they won't cause a timing problem.
Dan.
#23685 - Miked0801 - Sun Jul 18, 2004 9:09 pm
Well stated :)
#23694 - rusty - Mon Jul 19, 2004 12:55 am
So....if I wanted to transfer map data into buffers in main-RAM for a scrolling bacground larger than the virtual screen size, DMA transfers would be best used for this?
#23700 - sajiimori - Mon Jul 19, 2004 1:20 am
Why not load the map data straight from ROM, rather than using a RAM buffer? It might be a little faster to load from RAM, but the speed difference won't generally be significant compared to the RAM usage. Chances are your bottlenecks lie elsewhere.
#23703 - rusty - Mon Jul 19, 2004 3:44 am
| sajiimori wrote: |
| Why not load the map data straight from ROM, rather than using a RAM buffer? It might be a little faster to load from RAM, but the speed difference won't generally be significant compared to the RAM usage. Chances are your bottlenecks lie elsewhere. |
I'm just speculating at this point, as I'm in the process of writting my map-scroller. I'm considering using a RAM buffer because as the screen scrolls, it only replaces a column or a row of tile data at any given time.
I was just worried that the time to copy direct from ROM to VRAM would be huge compared to RAM. But I guess if it's not a big deal, that reall simplifies things for me...
#23704 - sajiimori - Mon Jul 19, 2004 4:55 am
As a rule, keep things simple until speed actually becomes a problem.
#23705 - rusty - Mon Jul 19, 2004 4:58 am
| sajiimori wrote: |
| As a rule, keep things simple until speed actually becomes a problem. |
Thanks for the advice. There were more issues that speed that I was concerned about though (I won;t go into them all here).
But I'll take your adivce and just directly from ROM.
#23712 - poslundc - Mon Jul 19, 2004 12:06 pm
One column of a text map is 40 bytes. A row is 60 bytes. Assuming you are copying only once per frame during VBlank, neither is a very big deal.
To put things in perspective, remember that for less than 32 bytes it's practically not worth using the DMA anyway just because of the time it takes to setup the three registers.
You need to start thinking through the timing logistics before implementation more when you're dealing with data amounts on the order of 40-60K, not 40-60 bytes.
Dan.