Didn't do the models for it but did do a script and partial sprite dump some time back for somebody else. Includes a decompression script and some info on some file formats.http://www.mediafire.com/download/pc9vp88wxjhvh8h/Harvest.7z
A filelist, with some stuff already named:http://pastebin.com/ziqPHN0U
Microcode looks like F3DEX2. Have a sub-optimal basic parsing script for some common things for reference here:http://pastebin.com/ynkH9sft
Note microcode can also be used to get the RSP to do sprite layout so if you see a bunch of "texrect" commands that's probably just sprites or the HUD. Why lay them out yourself when a co-processor can do it for you?
Commands are 8 bytes long. The first byte is the command type. Many commands can be ignored (such as the syncs) if you're just interested in basic geometry dumping. Also, you can probably ignore more complicated things like the combiner since you're just extracting the basic objects for another purpose.
0xDF (endDL) ends a display list. Any time you read DF000000 00000000 it stops this display list group and returns to whatever called it. If nothing called it, you're done.
0xDE (DL) jumps and links another display list. Continue reading that one until you hit the endDL. It will be in the format DE000000 xxxxxxxx, where the x is a pointer or offset to the other display list. Pointers start 80xxxxxx and will be an rdram address, offsets will have a different leader byte.
Vertices are loaded using the 0x01 command. It loads a number of vertices from a given location into an internal buffer, and this buffer is used for the tri commands. This one is bitpacked:
FF000000 00000000 command (01)
00FE0000 00000000 starting offset for putting these in the vtx table. Usually 0.
0001FC00 00000000 number of vertices to load
000003FF 00000000 number of DWs to load (<< 3 for actual bytesize)
00000000 FFFFFFFF offset or pointer to vertices
A command like 01004008 0A000000 would load 4 vertices (0x40 of data) from offset 0 in bank 10 (wherever that happens to be).
The two basic tri commands are 05 and 06, tri1 and tri 2 respectively. The vertex indicies are drawn from the internal buffer filled by the 01 command above. They have the same format:
FF000000 00000000 command
00FE0000 00000000 vertex 1
0000FE00 00000000 vertex 2
000000FE 00000000 vertex 3
00000000 00FE0000 vertex 1 (06 only)
00000000 0000FE00 vertex 2 (06 only)
00000000 000000FE vertex 3 (06 only)
07 is a quad type, though you probably won't see it at all. Pretty sure it goes x1, y1, x2, y2.
FF000000 00000000 command (07)
00000000 FE000000 vertex 1
00000000 00FE0000 vertex 2
00000000 0000FE00 vertex 3
00000000 000000FE vertex 4
To throw a monkey-wrench in things, there's a modifyvtx command. It's command 02, and it changes a word at an offset in the vertex buffer to a new value. Read the note in that script about this, since it's a tad bit complicated how it changes texture coordinates. Basically, it changes the vertices after
they've already been modified, but it also doesn't affect anything that has already used that vertex.
FF000000 00000000 command (02)
00FF0000 00000000 modification; 0x14 for ST
0000FFFE 00000000 vertex number
00000000 FFFFFFFF value
Command 0xD7 is Texture. It turns textures on and off and can set the ST when a specific tile is used. The most important flag, and probably only one you need to catch, is 00000001 00000000. If set, textures are applied to geometry that follows.
Commands FA and FB change the foreground and background color--in other words, white and black. You probably won't run into this, but if you do the lower word is an RGBA value. These can also change the color of intensity and ia images.
Texrect is a multiple-command one. It doesn't use vertices. There's a normal and reverse version, and it's common to all microcodes. They're 0xE4 and 0xE5. They're going to be used almost exclusively for sprites and text though, so probably won't need it.
Then the ones for images. Thing about images is the RSP will load them initially into memory, unconcerned about the image type, just so it can preprocess them. Then it loads it again with final settings before pushing to the RDP.
The other thing is they can be loaded in one of two ways. First is just as a block of data; and the second row-by-row, aligning each row properly automatically with optional subdivision for referencing subimages.
(I'm going to simplify the image stuff a little bit since you probably won't need to manage a virtual tmem or know how tile layouts or mipmaps work.)
Most import is 0xFD. It sets a source for image data. This data is copied into tmem using other commands, which is a buffer for the working images similar to the buffer for vertices. Fair warning, it's also possible to load palette data this way, and the type cast here isn't necessarily going to be the final image type.
FF000000 00000000 command (0xFD)
00E00000 00000000 color type
1 yuv (don't use; requires RSP translation to RGB colorspace!)
2 color-indexed (paletted)
3 intensity+alpha (black+white w/ alpha)
4 intensity (black+white)
00180000 00000000 color depth
00000FFF 00000000 width-1
00000000 FFFFFFFF offset or pointer to image data
Images can be loaded into tmem as either a block (0xF3, the loadblock command) or as one or more tiles (0xF4, loadtile). The difference is how the data is copied. A block is just copied as-is and assumes that you padded it properly. A tile copies each row of an image in, pads it, then continues. They read the image starting at a given ST and ending at a given ST, but these values are actually a fixed point 6.2 value. Both have the same format:
FF000000 00000000 command
00FFF000 00000000 upper left S
00000FFF 00000000 upper left T
00000000 00FFF000 lower right S
00000000 00000FFF lower right T
When subdividing into tiles, such as with a font, the divisions are assumed to be aligned. This is done with the F2 command, which outside the tile value is the same format as the two above. You probably won't encounter it.
Palettes, or texture lookup tables, are always 16bit rgba or ia. Admittantly you won't come across the ia version much. It's the same format as the commands above.
Finally, the F5 settile command sets how an image should be interpreted. It also sets attributes like mirroring, clamping, and shifting.
FF000000 00000000 command (0xF5)
00E00000 00000000 format; same as 0xFD type
00180000 00000000 size; same as 0xFD type
0003FE00 00000000 line, used with the tile commands to split image
000001FF 00000000 offset in tmem to load image data to; << 4 for actual
00000000 07000000 tile, which you don't need to mess with
00000000 00F00000 palette, when applicable
00000000 00080000 clamp T if set
00000000 00040000 mirror T if set
00000000 0003C000 mask for T when tiling; ANDs offsets with this, so tile height
00000000 00003C00 shift for T when tiling, like an offset
00000000 00000200 clamp S if set
00000000 00000100 mirror S if set
00000000 000000F0 mask for S when tiling; ANDs offsets with this, so tile width
00000000 0000000F shift for S when tiling, like an offset