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:
     0xd3 -> Despite being a command that is technically skipped over, it has a unique branch to a part of the routine. it checks if the weapon sheath byte is 1, and if it is, queues the next command. however if it is 1, then it will do the same funky command repeating that 0xd6 does, with the third byte.
     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 (Animation finishing?). arbitrarily set to a value of 2, however this command continues to check every frame that the animation is finishing, (until it's no longer called). based on the value of the third byte, this frame command repeats the last few commands of the animation, until it returns that the weapon is being sheathed, then it calls that. Weapon Sheath check?
     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 -> saves the value in the third byte to weapon rotation byte (misc unit data). Save rotation ##?
     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 loads weapon animation from WEP1 data (rather than r22). 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 -> saves information regarding the current animation to WEP1 data (Misc unit data) and then overrides the animation with the value in the third byte. 'Override animation: ##'
     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 -> 4bytes long (?), saves a new spin on the Y axis into WEP1 sprite, byte 3 is in the lower byte, and byte 4 is in the upper byte. after saving this value, skips ahead 5 commands. Save Y Spin ####?
     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 -> resets to 0, and prepares weapon, effect, or unit ($$) graphics for frame 1 of their appropriate animation (##). 'queue $$ animation ##' - 0x00 is unit (also branched over), 0x01 is WEP, and 0x02 is EFF
     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 -> 4 bytes long, seems to save various values depending on the value of byte 0x16 in WEP1 data:
          0x00 -> override 0x16th byte with 4th command byte, then branches to a command, relative to the start of this command, with the value of byte 3.
          0x01 -> subtracts 1 from 0x16th byte, and engage next command.
          0x02 -> subtracts 1 from 0x16th byte, then branches to a command, relative to the start of this command, with the value of byte 3. 
     0xfd -> identical secondary effects to d6, however the effects are guaranteed, and do not need the sheathe check. repeats last few commands of attack animation. Hold weapon?
     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. 

if the lead byte is NOT 0xff, then it performs a basic 2 byte command that loads and saves weapon graphic information.
Lead byte -> Added to weapon rotation for this frame. values that are too high may start spilling into erroneous data.
second byte -> Skipped over if byte interpretation has already happened on this frame. added to frame delay for that frame.

Potential psuedo commands?
   0x$$## -> Load rotation $$ and wait ##
   0xffd3## -> (dummied) Weapon sheath check
   0xffd6## -> Weapon sheath check
   0xffd8## -> Save rotation ##
   0xffd9#### -> Queue Throw Animation ####
   0xffdc -> Jump to previous animation
   0xffdd## -> Override Animation: ##
   0xffe5#### -> Save Y Spin ####
   0xfff202## -> queue $$ animation ##
   0xfffd## -> Hold Weapon