I don't really know how to explain it, but I guess a first thing is to know what you're looking for, under which form it could appear, etc...

For example, if you're looking at an image file and trying to figure out the format, it will likely be one of the formats the console hardware supports. You can try using an emulator (with sufficient tools) to determine which format is used. A good emu/debugger would also help you find out where the data comes from and how it's read-- chances are it's compressed, and in that case, you'll have to figure that compression out. Some games will just use standard compression algorithms, others not-- Nintendo loves inventing new LZ77 variants every time for example.

This also applies to audio data.

However, things that are more high-level, like level formats or scripts, will have their own format and don't depend on any hardware, so figuring it out might be harder.

Finding blocks of data requires looking at the file in a hex editor and trying to find data patterns. You can try subtly modifying the data and seeing what happens, and from there guess what it's supposed to be. An emulator with a debugger also helps. Once you find blocks of data, you have to work out the rest of the file structure, namely, what tells where the blocks are, etc...


As an example, how I worked out SM64DS's level format back then. I knew which files contained the level's models, collision maps and minimaps, but didn't know where the level headers were. ("level headers" basically defining all sorts of parameters, like which model the course uses, where the objects are, etc)

I don't remember it well, but I was able to find a table mapping filenames to internal file IDs. From that, I had the internal IDs of some course model files. Looking for them (probably modifying desmume to log when they appear, or using the RAM search) revealed the level headers, and from there, the various object lists. All that junk is stored in overlays, interleaved with code and other data (mostly level-specific objects (yes)), making it a pain to edit.

(how does SM64DSe make it easier to work with? it cheats, it adds new overlays, moves the level data there, and modifies the game code to read from there; the old overlays are still loaded so that their junk stays usable, etc)

____________________
NSMBHD - Kafuka - Jul
melonDS the most fruity DS emulator there is

zafkflzdasd

Nintendo doesn't go out of their way to add limitations. They code what they need, and keep in mind that most of those games aren't designed to be tampered with in the first place. Nintendo is known for hardcoding things... but to be honest, every game is going to be more or less of a pile of hacks. Quality varies. Rayman Origins Wii is a mess for example, and uses weirdass formats.

In the case of NSMBDS and SM64DS, the object limitations aren't deliberately coded in. They use a system known as overlays to save RAM. The objects' code/data are organized in these overlays, and the level header indicates which overlays should be loaded through a system of banks (each bank corresponds to a RAM address, the overlays in it are those which are set to load at that address).

This way, many objects not required for a given level are just not loaded at all.

And if you try using objects not loaded, well, it doesn't work. (NSMB ignores them, SM64DS crashes)

In SM64DS, the object bank system bleeds into the level system-- some objects only appear in one level, thus they're stored in the same overlay as the level's header.


If the overlay shit is still unclear to you, I'll provide an example...



As for how data formats are cracked... again, looking at patterns, debugging, etc...

As an example, how I worked out some data formats used in SM64DS. I don't remember details well, though.

The model format used is simple (compared to the typical Nintendo model format). I started with files I knew represented simple models. From reading DS docs, I knew what packed GX command lists (defining geometry) looked like, and similar data appeared in the files. From there I knew the geometry was directly stored as GX command lists (as opposed to storing separate positions/colors/texcoords). Makes sense, the game would just have to read the command list and copy it to the GX FIFO (from which the 3D hardware would process it and render things).

Next, I had to figure out the structure of the file, where those command lists start and what points to them. Easy enough in this case, all the offsets in BMD files are absolute (some more complex files may use offsets relative to some point in the file).

Knowing the structure also allowed figuring out the rest of the data: bones, how geometry is grouped, material data, textures, all the kind of shit you can expect to find in a model file. Again, most of it is stored in a format the hardware can directly understand: transform values are encoded in the proper fixed-point formats, material colors are encoded in 15-bit BGR, textures are encoded in formats supported by the hardware...



How are the hardware formats figured out? Well, people reverse-engineering the console, SDK leaks, etc... We're reaching into a whole new world, that of console hacking. ROM hacking can't exist without console hacking, though.

How the hardware data formats are reverse-engineered, well, I don't really know, I'm not into that. I've been mostly using existing documentation to do what I've done.


"In my favor, the PSX has a ARM MIPS 3000 processor which... Yes, you guessed it, is the predecessor to MIPS 4000, used by the N64. Anything designed to disassemble N64 binaries -should- work in this case."

yup, I guess, try out

____________________
NSMBHD - Kafuka - Jul
melonDS the most fruity DS emulator there is

zafkflzdasd

in the case of the DS, yeah


but it appears the OP is working on PSX games

____________________
NSMBHD - Kafuka - Jul
melonDS the most fruity DS emulator there is

zafkflzdasd