@zeld :
I would try this :
6217BC14 00000000
DB000000 023FFFFC
D3000000 00000000
B217BC14 00000000
B0000974 00000000
D8000000 00000010
D2000000 00000000
Or this (this is a new AR hack I made) :
AR hacks #5:
Data to copy is a multiple of 4
Fixed to Offset
023FE07C E4903004
023FE080 E4813004
Offset to fixed
023FE07C E4913004
023FE080 E4803004
Data to copy is less than 4
Fixed to Offset
023FE09C E4D03001
023FE0A0 E4C13001
Offset to fixed
023FE09C E4D13001
023FE0A0 E4C03001
TT hacks #5:
Fixed to Offset
088002AC E4903004
088002B0 E4813004
Offset to fixed
088002AC E4913004
088002B0 E4803004
Data to copy is less than 4
Fixed to Offset
088002C8 E4D03001
088002CC E4C13001
Offset to fixed
088002C8 E4D13001
088002CC E4C03001
And if data to copy is >4 and not a multiple of 4, use both 'less than' & 'multiple of' codes.
That would give, in your case, for the AR :
6217BC14 00000000
023FE09C E4D03001
023FE0A0 E4C13001
B217BC14 00000000
B0000974 00000000
DC000010 00000000
F23FFFFC 00000001
023FE07C E4913004
023FE080 E4803004
D2000000 00000000
Yes, it's a lot bigger than the other codes, but if you have to copy let's say 100 bytes, than should be worth it.
But, I'm wondering... Maybe the problem you have comes from the fact that you don't take in count the AR's DB code type bug (yes I know you didn't said you used that code type, but as D9 is for 32-bits and you need to copy 1 byte, maybe you meant to write DB) ?
It's all documented in the
AR doc I wrote...
Anyway, that means that if you use the DB code type like this (on the AR - the bug has been fixed on the TT) :
DBXXXXXX YYYYYYYY
Then the AR will do, after the DB code type is executed, offset=offset+YYYYYYYY.
And that's why the offset value gets screwed. So you have to use, for exemple, D3000000 00000000 after the DB code type to clear the offset (of use the hack #0 I made).