#15115 - gbawiz - Sat Jan 17, 2004 3:40 pm
Hello all,
I have reached the point where I want to use GBA interrupts. I am using the devkit advance compiler and am having difficulty.
Until now i have been using a batch file to compile my programs as follows:
-------------------------------------------
set path=C:\devkitadv\bin;%path%
gcc -o main.elf main.c -lm
objcopy -O binary main.elf main.gba
pause
------------------------------------------
I know that in order to use interrupts then I will have to use my own vertsion of crto.s (crto.o bin)with the interrupts enabled as the devkit's own crto.o has them disabled.
I used the '-nostartfiles' option and added the crtbegin.o crtend.o and crto.o files to my directory as well as in the command line options.
as a test I used the crto.o from the devkit advance and compiled my old programs in this new way. (i.e tried disabling startfiles and then refering to them in my command line).
They compile but dont seem to work.
If i cant get my old programs working on this new method then I cant get my new interrupt enabled programs working when i include my own crto.s
can anyone help?
Many thanks
GbaWIZ
#15120 - tepples - Sat Jan 17, 2004 4:54 pm
| gbawiz wrote: |
| I know that in order to use interrupts then I will have to use my own vertsion of crto.s (crto.o bin)with the interrupts enabled as the devkit's own crto.o has them disabled. |
No you don't. You can write your own ISR, compile it to ARM code, stick it in IWRAM, and handle interrupts from that. See the CowBite spec for more information on what an ISR needs to do.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#15125 - poslundc - Sat Jan 17, 2004 5:23 pm
Or you can just enable interrupts in the crt0.S that comes with devkitadvance.
Just open the file in a text editor - the comments expain everything.
(But tepples is correct that interrupts are not something that need to be associated with crt0.S, it's just done that way for convenience's sake in DKA.)
Dan.
#15190 - gbawiz - Sun Jan 18, 2004 8:07 pm
| tepples wrote: |
| gbawiz wrote: | | I know that in order to use interrupts then I will have to use my own vertsion of crto.s (crto.o bin)with the interrupts enabled as the devkit's own crto.o has them disabled. |
No you don't. You can write your own ISR, compile it to ARM code, stick it in IWRAM, and handle interrupts from that. See the CowBite spec for more information on what an ISR needs to do. |
Thanks for replying,
I have done some reading and found that when any interrupt occurs then the CPU will branch to the address 0x3007FFC then read the contents of that location as an address, then jump to that address which contains the start of the Interrupt service routine.
Is that correct?
Also you mentioned IWRAM for storing the ISR, why not ROM cartridge?
Do you have an ISR example which i can use for testing.
Another thing i was curious about is what instruction is used to indicate that the ISR has finished and should return to main program?
Thanks again :)
GbaWIZ
#15194 - tepples - Sun Jan 18, 2004 8:50 pm
| gbawiz wrote: |
| I have done some reading and found that when any interrupt occurs then the CPU will branch to the address 0x3007FFC then read the contents of that location as an address, then jump to that address which contains the start of the Interrupt service routine. |
Right.
| Quote: |
| Also you mentioned IWRAM for storing the ISR, why not ROM cartridge? |
Two reasons:- IWRAM is faster to access, and speed is critical in an ISR.
- ROM will not be present if a "cart removed" interrupt has occurred.
| Quote: |
| Do you have an ISR example which i can use for testing. |
No warranty that you'll understand it, but Tetanus On Drugs has an ISR.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#15206 - gbawiz - Mon Jan 19, 2004 1:58 am
Thanks for the advice,
I had a look at the program you mentioned with the ISR and have noticed that there is an ISR function created in C and there is a pointer to that function created and stored in the address 0x03007FFC mentioned earlier.
The pointer shows that the ISR function is stored at address 0x020060C8 which is in the onboard WRAM.
How is it possible to tell the program to place the ISR code into this address in the WRAM as I cant find any routine which copies the routine into that specific address 0x020060C8.
I assume that the routine is copied from rom into the WRAM at this address somehow which is not stated in the source code.
#15209 - tepples - Mon Jan 19, 2004 3:02 am
For one thing, TOD is a multiboot program, which automatically gets copied into 0x02000000 (EWRAM) either before it runs (if you're running it from PogoShell, Multiboot Menu, or over a cable) or first thing (if you're running it by itself or from a typical flash cart loader). DevKit Advance's standard crt0 startup code, based on Jeff F's, then proceeds to copy an audio mixer into IWRAM for speed.
I now notice that I did leave TOD's ISR in EWRAM. But for speed's sake, you will probably want your ISR to be in IWRAM. See the relevant section of Jeff F's GBA Dev FAQ to see how to do this. I may have made a mistake in neglecting to do this in TOD; I probably didn't notice it because it only ever uses one interrupt (VBlank).
Under DKA R5 beta 3 (the latest version, which does work well for me), you should compile an ISR like so:
gcc -Wall -O3 -marm -mthumb-interwork -c isr.c -o isr.iwram.o
Key points: -marm instead of -mthumb and an object file name that ends in .iwram.o, which the linker picks up as a cue to schedule it for copying to IWRAM once crt0 gets control. The -mthumb-interwork is strictly necessary only for an ISR that long-calls back to Thumb code in ROM, but in any case, it has little to no effect on the performance of leaf procedures such as many ISRs, and it helps keep the linker from female dogging about an interworking mismatch. You can replace -O3 by -Os (optimize for size) should you start to run low on IWRAM.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.