gcc
85adc: e4913004 ldr r3, [r1], #4
85ae0: e48e3004 str r3, [lr], #4
85ae4: e4912004 ldr r2, [r1], #4
85ae8: e48e2004 str r2, [lr], #4
85aec: e4913004 ldr r3, [r1], #4
85af0: e48e3004 str r3, [lr], #4


arm ads
0x00083c7c: 28b15018 .P.( LDMCSIA r1!,{r3,r4,r12,r14}
0x00083c80: 28a05018 .P.( STMCSIA r0!,{r3,r4,r12,r14}
0x00083c84: 28b15018 .P.( LDMCSIA r1!,{r3,r4,r12,r14}
0x00083c88: 28a05018 .P.( STMCSIA r0!,{r3,r4,r12,r14}

They are at least doing word transfers for the bulk of the copy, I would
make sure that both the source and destination are word aligned and your
transfers are in multiples of words....

Better yet write your own memcpy using LDM/STM pairs...

David



At 03:54 PM 7/1/2002 +0200, you wrote:
>
>
>j> Could someone tell me why memcpy and DMA 3 transfer should result in
>j> different processor behaviors, other than speed? When I replace my
>j> DMA copies with memcpy for transfering const data to the VRAM in mode
>j> 4, 1/2 the images are fine and 1/2 are chuncky looking - all on the
>j> same screen. I was suprised that this worked at all as mode4 requires
>j> u16 writes and memcpy is u8 writes.
>
>memcpy optimizes copying if possible - if source and destination address
>have proper alignment.
>
>
>
> bye, porneL
>
>
>--
>Nobody expects the Spanish Inquisition! [ http://pornel.plj.pl ]
>
>1200 603/200 040/25 64M 8.6G 4X 3.1 AGA, GG 989217