SEQ & Animation info page

The routine: Load WEP graphic from WEP1 Sheet references this table to load a series of commands (otherwise named 'frame commands') that vary in width depending on various inputs - but they seem mostly independent as commands. This page is an attempt to catalogue their effects. The pointer to these commands is located in SEQ Data, at address 0x800be74c + Weapon animation * 4.

Leading Byte:
0xff -> this byte seems to indicate that the operand of this command is an extra byte long? it pairs with the following secondary bytes to jump to other positions in the WEP graphic loading routine:
     0xd4 & 0xda -> some kind of checking operand? will clear 0x8004C6C4 regardless of inputs, then loads the next command, ignoring the next byte.
     0xd5 -> currently unsure
     0xd6 -> Queues a check of the value at 0x8009612c. if this value is not 0, subtracts 2 from r17 (the register locating the byte to-be-read of the command) and then adds an additional amount based on the third byte of the command (if the command byte is 0x80 or higher, performs a subtraction of the conjugate. otherwise performs addition). appears to act as the graphic loading equivalent of the 'b' command to another command.
     0xd7, 0xe3, 0xe4, 0xe9, 0xed, 0xee, 0xef, 0xf0, 0xf1, 0xf3, 0xf4, 0xf5 -> increments r17 by 1. no other known effect. continues next command without considering third byte.
     0xd8 -> Currently unsure
     0xd9 -> jumps directly to Set evade type data, item and throw stone hardcoding, and continues next command from the top. Hence I can probably conclude that command 0xffd9## is 'Queue-throw animation'
     0xdb -> currently unsure
     0xdc -> This forces r17 to be the value at the byte 0x10 from the start of WEP Sprite data, and r3, instead of being weapon animation * 4, is the value at 0xe(r19) * 4. Queues the next command in the list. this is probably related to a hardcoded weapon animation slot, and less specifically a specific weapon animation. acts as a kind of jump, I guess.
     0xdd -> currently unsure
     0xde, 0xe0, 0xe1 -> cuts command 1 byte short, and queues the next command without consideration of a third byte.
     0xdf -> clears ? Display data. no other known effect. continues next command without considering a third byte.
     0xe2 -> currently unsure
     0xe5 -> currently unsure
     0xe6, 0xe7, 0xe8, 0xea, 0xf8, 0xfb -> skips third byte of command, queues next command. no other known effect.
     0xeb -> I'm inclined to say this is some kind of direction check? there's an XORI in there and those are hard to think of immediate uses for. they mostly come around in brief periods of inspiration.
     0xec -> same deal here, but the value's changed for the command. instead of xori 0x4, is xori 0x2.
     0xf2 -> clears a bunch of frame/animation information with an offset based from the third byte of the frame command.
          0x00 -> Save second byte of frame command to current animation (don't do this, it will probably break something if the animation is suddenly 0xf2), clears several unknown values and sprite activation flag.
          0x01 -> saves 0xf2 to ???? (I guessed maybe it was animation frame# or palette, but I know that's bullocks), clears current weapon animation, clears r17 save position, clears a bunch of unknown data
          0x02 -> clears more unknown shit etc. etc. etc.,
     0xf6 -> currently unsure
     0xf7, 0xfa -> increments r17 by 3, skipping over a whole command's worth of bytes. other effects are unknown.
     0xf9 -> currently unsure
     0xfc -> currently unsure
     0xfd -> identical effects to d6, however the effects are guaranteed, and do not need the value check. 
     0xfe -> clears some values from WEP sprite data, and then leaves the routine, without processing another frame command.
     0xff -> clears exactly 1 less value than above command. other effects appear the same. 

Potential psuedo commands? 0xffd6## -> Branch 0xffd9## -> Queue Throw Animation 0xffdc## -> Jump