Let's start with something simple like items. What format do you want the data in? Can you give me an example?
1. File it's found in.
2. Starting address of data.
3. Ending address of data.
4. Number of entries of data if it's 1 entry per item, otherwise describe the scheme for delimiting it.
5. Number of bytes per entry if it's a fixed number per entry, otherwise describe the delimiting scheme for it.
6. Explanations of each byte.
Example of number 6:
0x00: Item ID
0x01: Item Weight
0x02: Item Power
: Context depends on if item is weapon, armor, or shield.
: All skills that are present on this item use this byte to modify their formulas.
0x03: Strength modifier
: Signed byte.
0x04: Dexterity modifier
: Signed byte.
...
0x0C: Additional effects
: This byte determines the context of bytes 0x0D, 0x0E, and 0x0F.
: Values
0x00: null
0x01: weapon attack - 0x0D = element, 0x0E = status effect, 0x0F = critical rate
0x02: weapon healing - 0x0D = element, 0x0E = status effect, 0x0F = critical rate
0x03: Use skill 100% of time - 0x0D = upper 8 bits of skill ID, 0x0E = lower 8 bits of skill ID, 0x0F = bit 0x80 sets detroy on use, other bits unknown
You don't have to type "0x" in front of all hex values, you can just say that all numbers are hex unless prefixed by a "d", or use the $ prefix for hex or what have you. As long as it's consistent, unambiguous, and you tell me your scheme it's all good.
I'm going to reread whatever you post a dozen times as I transcribe it into a spreadsheet and double/triple check it after that, so the only possible issue is something not being answered, inconsistencies, or mistakes. If the first two are present, I will definitely notice and ask for clarification. I might notice a mistake if it doesn't jibe with the data.
If it seems that something needs to be organized in it's own way (if - god help us - several bytes have values whose context is completely unique depending on several other values), then put that stuff with the byte that determines the context and leave a note for the stuff that very rarely changes context like "... unless byte 0x0c says otherwise".
So if byte 0x0c can change the meaning of bytes 0x00, 0x01, and 0x02 in a handful of circumstances, then add "see byte 0x0c for context dependent information" to bytes 0x00, 0x01, and 00x2; then identify in byte 0x0c's entry the circumstances where it does this.
Think of it as trying to reduce the duplications of explanations so you edit as few places as possible when you find an error or update something.
I think I see what you're getting at. I haven't done much PS1 emulator hacking, but since the RAM is always the same it shouldn't be difficult to find the data. I know the entire KERNEL.BIN (where all the battle-related object data is) is always present in memory during battle so it should be in a static place each time. It can't be too hard to find it.
IIRC pSX emulator has a header 0x2b0 bytes long for it's save states, and all others have footers (so the address doesn't change). Addresses shouldn't be any different if it's a footer.
RE save states: If the data is exactly the same format for the PC versions, post the same info for them too... though you should only need to specify things that differ, like file and starting address.
If the data is a subfile in another file, is only ever accessed by doing math on the header of the file, and you can reasonably expect the change the sizes of the subfiles previous to it, then include an explanation of the header. I understand what little endian means, and have basically a sophomore++ level of CS education.
