Final Fantasy 7 > General Discussion

Where is all the data for the PS1 version of FF7 located?

<< < (2/3) > >>

nfitc1:
Item format is here: http://wiki.ffrtt.ru/index.php?title=FF7/Item_data
In fact, the first nine sections of the KERNEL.BIN entries should interest you: http://wiki.ffrtt.ru/index.php?title=FF7/Kernel/Kernel.bin
Most of that is my work so I'm the one to ask questions of on any of those sections.

The KERNEL.BIN gets unpacked into the same location in RAM each time the game is loaded. I know where the pointer to the PC values is (nine Dword values at 7BA070 point to the locations in memory where each of the sections end up), but it might not translate the same for PS1. PS1 might unload the KERNEL files into the same addresses each time.

MysticLord:

--- Quote ---Item format is here: http://wiki.ffrtt.ru/index.php?title=FF7/Item_data
--- End quote ---
Has anyone tried zeroing out the first eight dummy bytes to see if anything happens?

Where can I find a listing of names for each item in order?

I assume it's 256 items, with a dummy item for empty slot.

I assume no one has a listing of item names, and I'll have to rip them myself to prevent mistakes.
1. Are they index-addressed fixed-length, or pointer-addressed null-terminated?
2. Are they ASCII or some other weird format that lacks the standard ASCII subset?
3. If it's pointer addressed, is there any weird stuff for duplicated names or entries without names?

Found item and materia digits on GameFAQs, in a Gameshark FAQ.

The Damage Calculation page links to a detailed Damage Formula page, but there's nothing there.

I assume that the power in this page is Item byte 0x0F ?


--- Quote ---In fact, the first nine sections of the KERNEL.BIN entries should interest you: http://wiki.ffrtt.ru/index.php?title=FF7/Kernel/Kernel.bin
Most of that is my work so I'm the one to ask questions of on any of those sections.
--- End quote ---
Are there programs you recommend to extract the kernel subfiles and ungzip them?

Is there a GUI program that does one or both jobs?

If not, is there anything I can call in a python script to ungzip them and then gzip them later (I prefer to newb-proof things as much as I can)?

Has anyone written something I can reuse (open source because lol it's a python script I ain't compiling shit) to deal with gzips if the best scenario for users is making new scripts to deal with the kernel?

Cebix has tools to do this stuff, though they're python 2.7 and have some other dependencies.

https://github.com/cebix/ff7tools

--- Quote ---The tools are entirely written in Python and have the following
dependencies:

 * Python >= 2.7.6
   The tools are not compatible with Python 3.

 * Pillow >= 5.1.1 (https://pypi.python.org/pypi/Pillow/)
   Used by the 'tim2png' and 'subending' tools.

 * NumPy >= 1.8.0 (http://www.numpy.org/)
   Used by the 'subending' tool.

 * PSXImager >= 1.0 (https://github.com/cebix/psximager)
   Used by the 'fixup' tool.

Most of the tools use the included 'ff7' package which must be in the
PYTHONPATH or reside in the same directory as the tools themselves.
--- End quote ---

Shouldn't be too hard to port the code I need to Python 3, and grab whatever license he uses.


--- Quote ---The KERNEL.BIN gets unpacked into the same location in RAM each time the game is loaded. I know where the pointer to the PC values is (nine Dword values at 7BA070 point to the locations in memory where each of the sections end up), but it might not translate the same for PS1. PS1 might unload the KERNEL files into the same addresses each time.
--- End quote ---
If I were you, I'd just crack open a save state and search for the first few bytes of item data. If that doesn't work, search for a set of adjacent and very distinct bytes, first using XVI32's count function, then the search function when you get a small enough data set.

nfitc1:

--- Quote from: MysticLord on 2021-05-20 23:53:28 ---Has anyone tried zeroing out the first eight dummy bytes to see if anything happens?
--- End quote ---

Yes I have. They are actually spacer/padding values because the Item data structure is derived from Action data structure. In order to make them loadable by the same method, the first eight bytes of Action data is just dummied out. I have verified this by reversing the PC executable extensively.


--- Quote from: MysticLord on 2021-05-20 23:53:28 ---Where can I find a listing of names for each item in order?

I assume it's 256 items, with a dummy item for empty slot.

I assume no one has a listing of item names, and I'll have to rip them myself to prevent mistakes.
1. Are they index-addressed fixed-length, or pointer-addressed null-terminated?
2. Are they ASCII or some other weird format that lacks the standard ASCII subset?
3. If it's pointer addressed, is there any weird stuff for duplicated names or entries without names?

Found item and materia digits on GameFAQs, in a Gameshark FAQ.
--- End quote ---

I would have said use Wall Market, but lots of people are having problems with it because Power Packs 3 doesn't work with the current edition and it's hard to find now. :( I've removed that dependency for version 1.5, but that version is still too far from release-ready.


--- Quote from: MysticLord on 2021-05-20 23:53:28 ---The Damage Calculation page links to a detailed Damage Formula page, but there's nothing there.
--- End quote ---

The actual link is here. For some reason this wiki doesn't like altering links even if it is to the same wiki.


--- Quote from: MysticLord on 2021-05-20 23:53:28 ---I assume that the power in this page is Item byte 0x0F ?

--- End quote ---
Yes

--- Quote from: MysticLord on 2021-05-20 23:53:28 ---Are there programs you recommend to extract the kernel subfiles and ungzip them?

Is there a GUI program that does one or both jobs?

If not, is there anything I can call in a python script to ungzip them and then gzip them later (I prefer to newb-proof things as much as I can)?

Has anyone written something I can reuse (open source because lol it's a python script I ain't compiling shit) to deal with gzips if the best scenario for users is making new scripts to deal with the kernel?

Cebix has tools to do this stuff, though they're python 2.7 and have some other dependencies.

https://github.com/cebix/ff7tools
Shouldn't be too hard to port the code I need to Python 3, and grab whatever license he uses.
If I were you, I'd just crack open a save state and search for the first few bytes of item data. If that doesn't work, search for a set of adjacent and very distinct bytes, first using XVI32's count function, then the search function when you get a small enough data set.

--- End quote ---

Wall Market, but see above. :(

MysticLord:

--- Quote ---Yes I have. They are actually spacer/padding values because the Item data structure is derived from Action data structure. In order to make them loadable by the same method, the first eight bytes of Action data is just dummied out. I have verified this by reversing the PC executable extensively.
--- End quote ---
I noticed that in the other kernel.bin structures. Does it actually save enough space to justify the wasted bytes? Or is it an issue of speed?

Difference between the link that doesn't work and the one that does:
https://wiki.ffrtt.ru/index.php/DamageFormula
https://wiki.ffrtt.ru/index.php/FF7/DamageFormula

I have everything I need to do this, but I'm working on Ogre Battle MOTBQ and probably Tactics Ogre TKOL first. They don't have editors.

nfitc1:

--- Quote from: MysticLord on 2021-05-24 17:43:07 ---I noticed that in the other kernel.bin structures. Does it actually save enough space to justify the wasted bytes? Or is it an issue of speed?

--- End quote ---

I believe it's an issue of design. This is designed to work on a 32-bit environment so it likes to have sizes that can "cleanly" fit into 32-bit chunks. It can do other sizes, of course, but accessing is just easier if everything is "rounded off" to the nearest 32-bit measurement. It's a preference of the compiler, I'd imagine. By default it adds lots of padding to try to prevent memory leaks and the like.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version