Section info for PSX Field files. (Yes, I'm stupid.)

[Micky]

After a long time of not hacking FF7 and even deleting the folder with the disks I fired up the hex editor again.
The first seven 32 bit values are the address of each section after loading the file into PSX memory. So you can subtract the address of the first section, add 28 and you've got the address of each section in the PSX file. Groan.
Section 3 seems to be the background tile information. The first word in Section 3 is the offset to the map for layer 0.
I'm now going to compare this with the info that Kero found.
(Sorry if I missed anyone else mentioning this.)

 

[Cyberman]

After a long time of not hacking FF7 and even deleting the folder with the disks I fired up the hex editor again.
The first seven 32 bit values are the address of each section after loading the file into PSX memory. So you can subtract the address of the first section, add 28 and you've got the address of each section in the PSX file. Groan.
Section 3 seems to be the background tile information. The first word in Section 3 is the offset to the map for layer 0.
I'm now going to compare this with the info that Kero found.
(Sorry if I missed anyone else mentioning this.)

Ack I thought I had tried that!
That explains why the first one was always 0 though Hmmmm.
Ok something I'll have to check out for me for certain. (I've been doing a lot of other things ).  I'll post a background image if this is correct information (woo?).  

Cyb

 

[Cyberman]

Hey Micky I might have some interesting information for you.
The 7 numbers I think are locations in the playstations memory actually.
for example
4SBWY_1.DAT
Code: [Select]

80115000801175448011767480117ECC80117EF4801181D880118208

4SBWY_2.DAT
Code: [Select]

8011500080117330801174DB80117F8C80117FB480118298801182C8

The reason I recognize these as PSX memory locations is because the playstation one has user memory from 80010000 to 801FFFFF. It does however indicate where they are located in memory when it's loaded however!  And I believe it's useful information because I can acertain the begining and size of each section of the DAT file.  I think they did this to save time in computing addresses for the field files. It's a very fast way to do things.  Basically read the first 28 bytes and load in the data following at 80115000.  The 28 bytes of data are the index table for the sections needed for the field location.  I believe this helped in managing the memory.

Cyb

 

[Micky]

Yes, that's what I meant with the second paragraph of the post.
They have a fixed target address for the field data, so they just do a block read to the target address. If they would malloc() the buffer for the field they'd need to fix the pointers manually. Of course, as it is only 7 values it isn't a terribly big win.
By the way, I already have a viewer for the first layer, I still need to decode some attributes and the sprites but maybe I can release some sourcecode soon!
(Beware of the double-post police, btw! )

 

[Cyberman]

Yes, that's what I meant with the second paragraph of the post.
They have a fixed target address for the field data, so they just do a block read to the target address. If they would malloc() the buffer for the field they'd need to fix the pointers manually. Of course, as it is only 7 values it isn't a terribly big win.
By the way, I already have a viewer for the first layer, I still need to decode some attributes and the sprites but maybe I can release some sourcecode soon!
(Beware of the double-post police, btw! )

Well I suppose I could have edited the prior post
Section 1 we all know what is.
Section 2 appears to be almost identical to section 3 in information format.
Section 3 is background sprite data
Section 4 is always 40 bytes in size
Section 5 is always 740 bytes in size
Section 6 is always 48 bytes in size
Section 7 varies no clue to what it could be though.

 

[Micky]

Section 2 seems to be some kind of vertex list + primitive data, but I'm not sure if it is the walkmap.

 

[halkun]

Here's a tip.
When you do a save state with EPSXE, it saves the 1 meg of video memory, two meg of RAM, and the register states as one gzipped file in the /sstates diretory. You can gunzip the savestate file and load it into a hex editor while the game is running in the emu. There you can edit the save state and save it after changing the data you wish to alter. Epsxe can load uncompressed save state files, so you don't need to compress it again. If you make another save state from EPSXE, it will be compressed again.

This is what I do.

1) Run the game in epsxe.
2) save state
3) Gunzip the savestate with the emu still running
4) load the uncompressed save state into a hex editor with the emu still running
5) save changes to memory while the emu is still running
6) load the altered save state to see what you changed.
7) because you have the save state loaded in the hex editor still, you can change data in the hex editor, save, and reload the save state without having to reset the game or the emu. It;s like hacking the game while it's still running.

You have the memory addresses now, That should make picking though the save state really easy.

Just some pointers.

 

[Micky]

Screenshot
A quick screenshot of the current state. Some tiles are wrong, and I'm not sure if I do the calculation of the palette correctly...
(Thanks to Mirex for his trashbin)

 

[Cyberman]

Here's a tip.
When you do a save state with EPSXE, it saves the 1 meg of video memory, two meg of RAM, and the register states as one gzipped file in the /sstates diretory. You can gunzip the savestate file and load it into a hex editor while the game is running in the emu. There you can edit the save state and save it after changing the data you wish to alter. Epsxe can load uncompressed save state files, so you don't need to compress it again. If you make another save state from EPSXE, it will be compressed again.

This is what I do.

1) Run the game in epsxe.
2) save state
3) Gunzip the savestate with the emu still running
4) load the uncompressed save state into a hex editor with the emu still running
5) save changes to memory while the emu is still running
6) load the altered save state to see what you changed.
7) because you have the save state loaded in the hex editor still, you can change data in the hex editor, save, and reload the save state without having to reset the game or the emu. It;s like hacking the game while it's still running.

You have the memory addresses now, That should make picking though the save state really easy.

Just some pointers.

This reminds me, I can use PEC to directly modify memory locations in the game while it's running, or use the debugging version of PCSX with the GUI I made for it.  time to PEC at it some I guess

Cyb