View Single Post
  #873  
Old 8th July 2014, 11:59 PM
bsmiles32 bsmiles32 is offline
Junior Member
 
Join Date: Jun 2013
Posts: 10
Default

Just for information, most of audio ucodes fit within the 4k of IMEM, so dumping IMEM content before starting rsp execution will give you the full ucode listing. Note that usually ucodes aren't exactly 4k but smaller, that's why you get some junk bytes at the end.

For ucodes that are longer that 4k (and cannot fit entirely within IMEM), they usually explicitely DMA the missing parts of ucodes as needed. This happen for instance to load the mp3 ucode for PerfectDark or ConkerBadFurDay audio tasks, or for the later version of MusyX (IndianaJones and BattleForNaboo). And this is quite common for GFX tasks.

What I used personally to study ucodes, is to dump them from DRAM before starting RSP execution. You get the starting DRAM address of the ucode by reading DMEM[0xfd0-0x0fd3]. (For games that don't use the traditional boot ucode, use DMEM[0xfc8-0xfcb]). Once you have a binary dump of the ucode, just use a disassembler on that (I use https://bitbucket.org/ottehr/rsp-tools, but you can use whatever you like).

I highly recommend you to have a good reference (ie source code) on RSP vector instructions nearby when you look at disassemblies, otherwise you'll get confused really quickly.

I know that you really want to work on GFX ucode specifically, but those are the most difficult to reverse engineer because the code flow is really messy, and they are bigger than other tasks.
For starters, and to get the feeling of what it takes to reverse engineer ucode, I would rather suggest you to try the jpeg tasks, which are easier (code flow is not very convoluted, they actually implement a known algorithm, and they are fully reverse engineered), yet not trivial.
If you want something shorter, just try to undertand the boot ucode.

When studying a ucode, you should identify:
-where are the ending point(s)
-where are the DMA functions, do they load things to IMEM (and therefore can modify the ucode...) or DMEM.
-if you can spot functions (starting, ending addresses and parameters)
...
Then try to build a map of DMEM to identify the purpose of each addresses
(is this a constant ? what size is this data ? ... ).

This list of tips is of course not exhaustive, but should give you a starting point.

Quote:
I did more checking and it appears to be split up in the rom. For instance in SSB64, the beginning of the RSP for what I assume is for Audio, begins at offset 0xB70 in the rom. Then I checked where the code at address _04001100 in IMEM would be, and found it at offset 0x3A340.
Indeed, ucodes are usually splitted in 2 parts: the "boot" ucode, and the "real" ucode. The only purpose of the "boot" ucode is to load the "real" ucode into IMEM, load its data into DMEM and then jump to "real" ucode entrypoint (0x1080).
There are some exceptions to this description, with games doing some anti piracy tricks in the boot_ucode (those who uses CIC 6105 for instance), and some that don't use boot ucode at all.
Reply With Quote