well there ishttp://nocash.emubase.de/gbatek.htm
are also worth a look.
I prattled on a tiny bit in my GBA/DS docs though it is probably not quite so useful in your position (it was mainly aimed at those new to assembly)http://www.romhacking.net/forum/index.php?topic=14708.0
Otherwise it is ARM7 TDMI assembly --
Unlike X86 you need to use dedicated instructions to pull from or go into memory (there is DMA as well -- http://drunkencoders.com/files/2013/03/unequivocal-answer.html
There is no divide instruction. Various BIOS commands (arctan, square root and various divides are available as well as decompression, a memory transfer and some graphics related stuff are available in the BIOS) or on the DS the maths coprocessor can be used instead. Nothing stopping a dev from setting up log tables either and the "code it to multiply instead" option is always present.
No floating point worth speaking of. BCD, various types of fixed point or software floating point are your main options. You can get a remainder and play with that if you want though.
It is a RISC processor so everything is quite basic and there is no 40 cycle SIMD stuff to contend with. On the flip side if you did want the niceties afforded by the 40 cycle SIMD stuff you will now have to spend 200 cycles and do it one by one.
No 3d worth speaking of beyond the mode 7 a like stuff the graphics system has.
Immediates can not be the full 32 bits so shifts are common. (getting FFFF FFFF in a register might involve something like mov FFFF into R? and then shift r? by 16 bits then adding FFFF into R?). Edit -- see later comments. All high bits is not the best example.
There is THUMB mode which is broadly speaking a 16 mode with 32 bit registers (albeit fewer than ARM mode) that makes for faster code in a lot of cases (I would not be surprised to see games spend upwards of 90% of their time in THUMB mode and certainly a lot of the main loops/functions in a game)
Piplining is limited to a 2 instruction read ahead, no branch prediction or anything like that. The only real time this matters if you try to read the program counter which will be 2 instructions ahead by the time it has it in memory. Rather than try to be flash with hooks there just branch.
Though you could run code from the memory it is quite small and the memory mapped cart uses fast enough memory that it can do it so most games do not do this. Typically this is 08000000 through 09FFFFFF in memory but there are mirrors at different waitstates (which can be changed to be faster or slower if you really want).
If you already have IDA you have a great disassembler. There should be some GBA plugins but I am not sure what goes there right nowhttp://www.romhacking.net/documents/361/
covers basic tracing with VBA-SDL-H and http://labmaster.bios.net.nz/vba-sdl-h/
covers much of the usage with it.
I also suggest a quick scan throughhttp://www.romhacking.net/documents/337/
What you want may be subtly different to graphics but setting breakpoints and reverse engineering reads/codes are roughly the same anywhere, I would check to see if there are any cheats that can do things like this as they are great places to get ideas on how to set about things. Likewise it might not boil down to assembly hack to implement it -- the game could read a value from memory instead (in my experience pokemon games actually do the database/crude database lookup thing quite well, for the DS but http://www.pipian.com/ierukana/hacking/ds_evos.html
The final quick trick is the finding the binary in the GBA ROM trick. The GBA ROM is self contained without a filesystem in almost all cases. However the GBA binary is easy to find save perhaps for two games ( http://doc.kodewerx.org/hacking_gba.html#psc
The idea runs the first command is the first byte and it jumps to the end of the header usually. This then sets up the basic IO which would have bored you in most assembly tutorials (save perhaps Art of Assembly) and then the first reference to something in the 08XXXXXX range is the first proper instruction.
Finally and perhaps more important than some other stuff I already mentioned is that ARM publish manuals for their chipshttp://infocenter.arm.com/help/topic/com.arm.doc.ddi0210c/index.htmlhttp://infocenter.arm.com/help/topic/com.arm.doc.ddi0201d/
Other nice linkshttp://www.scss.tcd.ie/~waldroj/3d1/arm_arm.pdfhttp://quirkygba.blogspot.com/2008/12/things-you-never-wanted-to-know-about.htmlhttp://imrannazar.com/ARM-Opcode-Map
For the others reading there is no real programming tutorials with reference to ARM assembly that I have seen, X86 has a few though and http://stuff.pypt.lt/ggt80x86a/asm1.htm
are two of the nicer ones.