#26011 - DialogPimp - Fri Sep 03, 2004 7:10 am
Does anyone have a step-by-step guide to getting Apex and devkitarm working together ?
I'm not very comfortable with linker scripts, new crt0.s's enabling interrupts and all the other arcanery that goes on with this, so any advice would be appreciated.
#26017 - jd - Fri Sep 03, 2004 3:18 pm
I have tested AASExample under DevKitArm and there were no problems with AAS itself, although the included makefile did need some changes:
1) "CROSS" needed to be changed from "arm-agb-elf-" to "arm-elf-".
2) "-Xlinker -Map $(MAP)" needed to be removed from LDFLAGS. (I suspect this may be a bug in DevKitArm.)
Also, assuming you're using Windows, you'll need to delete the Linux version of Conv2AAS (which has a filename of "conv2aas" (as opposed to "conv2aas.exe" for the Windows version)) from the AASExample folder to stop DevKitArm from attempting to use the wrong executable.
#26033 - DialogPimp - Sat Sep 04, 2004 7:00 am
Thanks James - really appreciate your help. I got the examples compiled and working just fine. Now to get it working in my own project...
#26039 - jd - Sat Sep 04, 2004 3:02 pm
| DialogPimp wrote: |
| Thanks James - really appreciate your help. I got the examples compiled and working just fine. Now to get it working in my own project... |
No problem. Let me know if there's anything else you need help with.
#26577 - DialogPimp - Mon Sep 20, 2004 6:46 am
More makefile stuff that I don't understand ;)
If I "#include <cstdlib>" in the AAS_CPP same I get a "no such file or directory" compiler error. I've got other projects and makefiles that do work OK (although they look completely different) so I know it can build.
What am I missing with the AAS_CPP example makefile ?
#26585 - DialogPimp - Mon Sep 20, 2004 11:52 am
Err - it seems to be working on my home machine just fine. Time to check my paths and stuff between my work machine and home machine.
Edit: Still having troubles with my DMA3-based animation system, which DMAs in the new frame data into VRAM. I've replaced it with AAS_DoDMA3(), but still causing me lots of screen corruption etc.
#26592 - jd - Mon Sep 20, 2004 4:40 pm
| DialogPimp wrote: |
Edit: Still having troubles with my DMA3-based animation system, which DMAs in the new frame data into VRAM. I've replaced it with AAS_DoDMA3(), but still causing me lots of screen corruption etc. |
What kind of corruption are you getting? Could it be caused by the DMA being delayed for a few scanlines?
#26600 - DialogPimp - Mon Sep 20, 2004 11:19 pm
As a background, it's an animation system where each sprite instance has an update routine, which advances through the various frames and DMAs in the new data as needed.
I'm using the usual DMA_Copy() routine as you'd see in GBAJunkie or Pern tutorials.
Changing this (simplified):
DMA_Copy(3, (void*)pCellData, (void*)SPR_VRAM(nVRAMSlot), nDMASize, DMA_32NOW);
to:
AAS_DoDMA3((AAS_u16*)pCellData, (AAS_u16*) SPR_VRAM(nVRAMSlot), nDMASize | DMA_32NOW);
...gives me the problem. I can't post screenshots yet (at work), and I'm 100% certain the problem is in the way I'm using the DMA. It seems to trash my map data as well. Commenting out the AAS_DoDMA3() call results in the map being displayed OK.
I still need to do more work - changing nDMASize in the above call to a hardcoded value of 128 improved things, although it also seems to have highlighted problems in another area that weren't present before.
#26601 - jd - Mon Sep 20, 2004 11:30 pm
| DialogPimp wrote: |
Changing this (simplified):
DMA_Copy(3, (void*)pCellData, (void*)SPR_VRAM(nVRAMSlot), nDMASize, DMA_32NOW);
to:
AAS_DoDMA3((AAS_u16*)pCellData, (AAS_u16*) SPR_VRAM(nVRAMSlot), nDMASize | DMA_32NOW);
|
I don't know the prototype of DMA_Copy, but it looks like DMA_32NOW might be designed to be written to just the upper 16-bits of the control register - bit-shifting it should fix the problem:
| Code: |
AAS_DoDMA3((AAS_u16*)pCellData, (AAS_u16*) SPR_VRAM(nVRAMSlot), nDMASize | (DMA_32NOW<<16) );
|
#26602 - DialogPimp - Tue Sep 21, 2004 12:10 am
Thank you James - I'll give that a try tonight.
I just spent the last 1/2 an hour investigating why my code is affected when using the -O3 compiler switch. It looks like automatic "-finline-functions" does something to my OAM memory copy. With -O3, the debugger reckons theres no reference in the current context to the OAM memory area. Turning -O2 on instead works OK.
Peculiar.
#26603 - jd - Tue Sep 21, 2004 12:29 am
| DialogPimp wrote: |
I just spent the last 1/2 an hour investigating why my code is affected when using the -O3 compiler switch. It looks like automatic "-finline-functions" does something to my OAM memory copy. With -O3, the debugger reckons theres no reference in the current context to the OAM memory area. Turning -O2 on instead works OK.
|
You might have already checked this, but the most common thing that shows up with -O3 is not using "volatile" correctly.
#26610 - DialogPimp - Tue Sep 21, 2004 4:32 am
Further progress - the AAS_DoDMA calls are almost certainly working correctly as the attract mode screens are DMA'd and display correctly.
How do I get the makefile to generate a .ELF file so I can use arm-elf-gdb to see what's going on ? It's something to do with the "pCurrSprite->nDMASize" variable, but I'd like to see it in a debugger.
#26611 - jd - Tue Sep 21, 2004 6:46 am
| DialogPimp wrote: |
How do I get the makefile to generate a .ELF file so I can use arm-elf-gdb to see what's going on ? It's something to do with the "pCurrSprite->nDMASize" variable, but I'd like to see it in a debugger. |
If you're using the makefile that comes with the AAS examples, then the .tmp file is an ELF file.