|$7E0200||544 bytes||Misc.||OAM table - handles all sprite tiles that are on screen. Each OAM slot contains 4 bytes of data: [XXXXXXXX YYYYYYYY TTTTTTTT yxppccct]:|
XXXXXXXX and YYYYYYYY bits are the on-screen coordinates from the top-left corner, TTTTTTTT is the tile number, and yxppccct is the tile properties. Each OAM slot are ordered from high priority (in front of other sprite tiles) to low priority.
therefore there are 136 OAM slots. If the slot is free, then the Y position is #$F0.
$7E:0310-$7E:0313 is for the player's upper half, $7E:0314-$7E:0317 for the player's lower half, and $7E:0318-$7E:031B is for the player's hand. Various tiles are documented here.
Note that $7E:0400-$7E:041F handles high bit of X position and tile size. It is not usable, since it is overwritten each frame and pretty painful to work with. Use $7E:0420-$7E:049F instead.
(Mods, this is an update, please replace the old version and not have duplicates)
(edit: please remove the other one, I forgot to mention about the priority)
Factually incorrect; the added information actually contradicts what's still there. The OAM is split up into two parts - a low table and a high table. The low table is 512 bytes (from $7E0200-$7E03FF) and contains 4 bytes per sprite tile in the format you've correctly described. The high table is 32 bytes (from $7E0400-$7E041F) and contains 2 bits per sprite tile (the low bit is the ninth bit of the X position, while the high bit is the tile's size). Thus, there are only 128 OAM slots (512 bytes in the low table with 4 bytes per slot is 128; 256 bits in the high table with 2 bits per slot is also 128), not 136 as mentioned in your description.
I think a better option here would be to just submit the low and the high OAM table as two separate addresses, making sure to keep the note about $7E0420 intact.