Jason,
The problem is that the use of the link register and pc have been
extended to determine what mode the processor should be in. By mode,
I mean THUMB or ARM (rather than supervisor etc).

So if your return address is in the middle of some thumb code and
your procedure is in ARM, then the processor state must be swapped to
thumb when you return. As far as I can work out without the docs, the
command bx changes the processor state depending on the flags in the
lr. The mov command does not. So basically you need to use bx if
you're jumping back into some code which you don't know whether it's
in thumb or arm, or if you KNOW that it's in tumb or arm and your
procedure is in arm or thumb!

This means that to do an LDMFD sp!,{r0-r12,pc} or whatever your more
complicated code is, then you need to do:

LDMFD sp!,{r0-r12,lr}
bl lr

Yes it's silly, but there you go. Hope that helps.
>>

Doh, you're right! I should have realized that it was switching back and forth,
but I didn't realize the branch instructions altered the CPU state as well.
Thought that required an explicit command, but then when I think about it
there's really no good alternative to having the state set 'automatically'.

Changing all the "mov pc,lr" instructions helps. In fact, aside from there not
being any way to test it just yet, most of the code appears to work then. I
know someone else suggested converting entirely to ARM, but I'd like to avoid
that in case of future problems, though it's an option.

Currently most things appear to work, though I'm wrangling with the main
interrupt which is giving out bad IO instructions. I wish the code was
documented. :)

If I -do- manage to get it working in -mthumb-interlink mode I should probably
send a version back to the GASS author. I've tested many of the demos and it
sounds quite nice compared to most of them.

Jason Emery
World Tree Games


[Non-text portions of this message have been removed]