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.

Coding > CPUFastSet (swi 12)

#8584 - abilyk - Tue Jul 15, 2003 8:34 pm

Greetings.

I've been trying to test the speeds of several data copy methods (so far, memcpy & CPUFastSet) to find out the best way to implement a dynamic background-loading engine.

Memcpy certainly didn't give me any problems, but I'm having difficulty with CPUFastSet. I believe I have the asm code set up correctly, but whenever I attempt a copy, it doesn't work. (Note: I've tried using both "swi 0x0C" and "swi 0x0C0000." One doesn't do anything, and the other seems to freeze the system. Though I'm not sure which to use, I do know that there's something else wrong)

I was initially trying to copy from ROM to VRAM. After hours of struggle, it hit me that the registers (r0 and r1) that hold the source and destination addresses are only 32 bit, and because of that the complete address of each wouldn't be able to fit. Hopeful, I then tried to copy from EWRAM to VRAM, and after that, VRAM to VRAM. But neither of these worked.

Could someone more experience help me out? Is it possible to copy from any address to any address with this method, or must they be within a certain distance from each other? Following is the related code I've been using:

// function
void CPUFastSet(void *source, void *dest, u32 length_mode)
{
asm volatile
(
"mov r0, %0\nmov r1, %1\nmov r2, %2\nswi 0x0C0000\n": // asm code
: // function output (none)
"r" (source), "r" (dest), "r" (length_mode) : // function input
"r0", "r1", "r2" //registers destroyed
);
}

// map declaration
const u16 map0[320] __attribute__ ((section(".ewram"))) = {0x0094,0x0094, etc.... )

// function call
CPUFastSet((u32*)map0, VideoBuffer, (u32)20);


Thanks,
Andrew P. Bilyk


P.S. Also, some of you might suggest to just leave the SWI calls alone and use DMA. The reason I'm shying from that is the fact that I'm planning on using the Krawall sound library with my games, and I don't want my DMA use to interfere with Krawall's. Is this a valid concern?

#8585 - ampz - Tue Jul 15, 2003 9:00 pm

There should be no problem using DMA... There are several DMA channels. Two are reserved for audio.
There is a general purpose DMA channel... I think it is channel 3. It should not interfere with anything.

And yes, you should leave swi's and software memcpy's alone and use DMA :)
However, one very neat way to do it is to setup your memcpy to use DMA. It makes the code more portable too.

#8593 - DekuTree64 - Wed Jul 16, 2003 12:01 am

I think the problem is you have the size set to 20, it has to be a multiple of 8, since the length is in words, and it copies 8 of them (32 bytes) at a time.

#8607 - Lupin - Wed Jul 16, 2003 12:43 pm

Why does the GBA even have this swi instruction? Why doesn't it use DMA for all data transfers? I wonder where's the use of this instruction...

#8610 - Quirky - Wed Jul 16, 2003 2:01 pm

Lupin wrote:
Why does the GBA even have this swi instruction? Why doesn't it use DMA for all data transfers? I wonder where's the use of this instruction...


DMA stops the cpu, so perhaps this routine is used for when the transfer needs to be interruptable? e.g. when you have multi-player code in your game, which is very sensitive to timings. Of course if the bios routines are not interruptable then that would be a load of rubbish.