FIELD.BIN (exploration) thread

Cyberman · Feb 20, 2007

The complete list of field locations (ONLY) is contained starting @ 0003A5B8 of the uncompressed data. This is the LSN and size of each file IN field.bin
0003A5B8 to 0003EF80 2 pairs of uint32 (little endian) Logical Sector Number then Size. Again Field files ONLY (this does not include BCX files in other words). 2361 files total for that.

0003F08C to 0003F0DC has the BCX files indexed.
I haven't found anything else YET but that's what this thread is for what's where in it.
Anyhow looks as though the game uses this index for loading field files (Akari keep that in mind

).

Cyb

Edit 2/21/2007
FIELD.BIN is located at sector 55000 it's the first record in the \FIELD directory.
The first file listed in FIELD.BIN at offset 003A5B8 is DUMMY.DAT. The ordering of the files are thus DAT MIM then BSX. I'm not sure if this is related to the PC's ordering of the data for each field location (7 sections in the DAT + section 8 being the actual field data and section 9 being the BSX field character data or something like that). The final entry at 003EF78 is ZTRUCK.BSX. So this table covers JUST the field location files. The section from 003F08C to 003F0DC are the BCX files + the FIELD.TDB file (Texture data). This leaves 2 files not index and those are DSCHANGE.X and ENDING.X.

There are a number of uint32 numbers within the FIELD.BIN file that are suspicous when read in HEX. They appear to be offsets in the playstations memory. In addition the entire list of Opcodes are contained much like what was in the PC executable. To get to the point FIELD.BIN is likely the FIELD engine program that is loaded on top of the kernel. When porting the merged the FIELD engine section and KERNEL section into one ... conglomerate.

Micky · Nov 8, 2009

(Sorry about the thread necromancy...)
The first 4 byte of field.bin is the uncompressed size, the gzip header is at offset 8. I don't think there are multiple files in that bin, as the input buffer is empty when zlib is finished.
The file is decompressed to 0x0a0000 in memory whole. It's quite possible that it is is some kind of overlay/DLL instead of an archive. Does it exist in the PC version?

The normal table is at offset 0x3f520, which means the sine/cosine table are before that as well.

Gemini · Nov 16, 2009

The first 4 byte of field.bin is the uncompressed size, the gzip header is at offset 8.

The first 4 bytes are more like the real size of the decompressed file, while the second WORD is the gzip decompression counter. They used a double counter to save room for empty bss segments (they can be recreated by simply filling the remaining size with zeroes). Other overlays like BATTLE.X use the same trick.

Micky · Nov 22, 2009

The final entry at 003EF78 is ZTRUCK.BSX. So this table covers JUST the field location files.

I just ran a complete file table against all words in field.bin, and it looks like the final entry is 3ef80,2903,280222,('WORLD/WM.PRE', 2903, 280222). There are a few more matches, but because the file size doesn't match for them I assume they're just random.
I'll see if I can find some more free time to see if any other files contain a file table.
Code: [Select]

Code:

world.bin: 0x273e4 - 0x2752C, txz files, bot files, bsz files, map files, ev files and field.tbl.

halkun · Nov 22, 2009

Does this mean that soon we could remaster a PSX disk with updated field files?

Micky · Nov 22, 2009

Does this mean that soon we could remaster a PSX disk with updated field files?

Aren't the fan-translation teams doing that anyway? Or are they just trying to inject files into the old sector positions?
But, yes, in theory if we know all file tables then you could patch them after creating the disk layout.

Gemini · Nov 26, 2009

As long as all common files on disk share the same position (less MOVIE [in part], MINT, and SNOVA), regenerating the whole thing is very possible. Lasyan's tools rebuild the FIELD folder from scratch already.

Cyberman · Dec 1, 2009

I believe I read through field.Bin before (as noted I started the thread eons ago) and found several tables in it.

I suspect that the LBA table for the real file db is in there and I believe I found corelation to the files on the disk. I just had a system crash and it wiped all my work out is all. Have to love SIS motherboards (that's what killed my data a bad ATA interface on the board). This is the same machine with a different mother board works just fine without it

Anyhow judging that the engine uses a series of numbers internally for field files it has to use something to translate that information into a physical location. I would hazard to guess that would FIELD.BIN for the rooms (which is the majority of the game content apart from movies). Battle scenes and characters have very little in the way of scripting. The majority of the script is in the \FIELD directory. That being said everything therefore must have an index for the script system FIELD.BIN seemed (or is?) the most likely candidate for the table for that.

Cyb

Lazy Bastard · Jul 19, 2012

Apologies for resurrecting a dead thread, but I can't for the life of me seem to un-gzip (or gunzip) FIELD.BIN.

Code:
FIELD.BIN doesn't seem to make ff7dec very happy (it spits out an error stating that FIELD.BIN isn't a gzip file). I've followed the instructions and used the command:

Code: [Select]

Code:

ff7dec d field.bin

...but, no dice. I'm tempted to try it manually (destroy first 8 bytes, then treat it like a normal gzip file).

However, even after trying the "manual" method, it fails. All I get is

Code: [Select]

Code:

C:\Users\LB\Desktop\FF7 Modding Tools\ff7_gzip>ff7dec d field.binCreating file field.bin0!gunzip: field.bin0.gz: not in gzip formatCreating file field.bin1!gunzip: field.bin1.gz: not in gzip formatCreating file field.bin2!gunzip: field.bin2.gz: not in gzip formatCreating file field.bin3!gunzip: field.bin3.gz: not in gzip formatCreating file field.bin4!gunzip: field.bin4.gz: not in gzip format

I'm using ff7dec (as mentioned above), but it doesn't seem to have a version number listed anywhere. It was last modified on 5/7/2003, and is 168 KB, if that's of any use as a distinction. Is there a newer (or older yet working) version somewhere, or have I incorrectly used the program?

Any help would be appreciated.

Vehek · Jul 19, 2012

Running ff7dec doesn't sound like doing it manually to me. I always considered manual extraction to be using a regular gzip extractor on the separated gz files from the bin archive.

FIELD.bin is not like the other BIN archives. See here:

The first 4 byte of field.bin is the uncompressed size, the gzip header is at offset 8.

Compare that with the standard format. ff7dec probably fails because it wasn't designed to handle this situation.

Lazy Bastard · Jul 19, 2012

Running ff7dec doesn't sound like doing it manually to me. I always considered manual extraction to be using a regular gzip extractor on the separated gz files from the bin archive.

I attempted to use 7Zip to extract it after deleting the first 8 bytes, as mentioned earlier in THIS thread, but that failed as well.

Any advice on specifically how I should go about extracting FIELD.BIN?

Gemini · Jul 19, 2012

That's pretty much the procedure: delete 8 bytes, rename to FIELD.gz, use any decompression program capable of detecting gzip files and you're done.

Lazy Bastard · Jul 20, 2012

That's pretty much the procedure: delete 8 bytes, rename to FIELD.gz, use any decompression program capable of detecting gzip files and you're done.

Should I actually delete the first 8 bytes, or should I simply delete the values therein? In other words, should I be changing the file size here, or keeping it the same? I'd just test it right now, but I'm at work...

Gemini · Jul 20, 2012

Delete=physically removing them from the file, so you'd obtain the old file size -8. What you've probably done is replacing the first 8 bytes with zeros, which definitively doesn't help in making any codec recognize the gzip signature. Delete those extra bytes, that's all you gotta do.

Lazy Bastard · Jul 20, 2012

Delete=physically removing them from the file, so you'd obtain the old file size -8. What you've probably done is replacing the first 8 bytes with zeros, which definitively doesn't help in making any codec recognize the gzip signature. Delete those extra bytes, that's all you gotta do.

Nope, I was actually deleting the first 8 bytes (and thus changing the file size). HxD is pretty explicit about the distinction, and the file size was indeed decreased. Come to think of it, though...I may not have changed the extension to .gz, assuming that 7-Zip would detect the format automatically. I'll verify that tonight if possible (busy night).

Micky · Jul 22, 2012

I'm using this code to open field.bin:
Code: [Select]

Code:

import zlib, structdef loadBin(name):    # read compressed data    f = open(name, "rb")    buf = f.read()    f.close()        (size,) = struct.unpack_from("<I", buf, 0)    data = zlib.decompress(buf[8:], 16 | 15)    if len(data) != size: del buf del data return None    return data

It skips the first 8 byte and changes the window size.
http://docs.python.org/library/zlib.html#zlib.decompress
I'm not sure where I got the wbits value from, most likely from somebody else's document or decoder.

Lazy Bastard · Jul 22, 2012

Heh, changing the file's extension to .gz was all that was required. I can't believe 7Zip didn't auto-detect the format. It does with Zip files and various other things.

Thanks for the help.

Lazy Bastard · Jul 22, 2012

Also, to corroborate what Cyberman said many moons ago (the first post in this thread), FIELD (ungzipped) contains sector numbers referring to the FIELD files on disc. These are recorded in little-endian format (swap the bytes in each 'word'), and of course in hex. So, sector/LBA 58890 (MD1STIN.DAT) is recorded as 0AE6 (which, in big-endian, is E60A). Immediately before this in FIELD is F6E5, which in big-endian is E5F6, or decimal 58870; 58870 is the sector number/LBA for WHITEBG3.BSX, the file immediately before MD1STIN.DAT on the FF7 disc.

Jenova's Witness · Jul 22, 2012

halkun · Jul 22, 2012

What do you mean by same position? If they are the same size as they originally were, if they have the original name, and if they are in the original directory?

No "same position" means where the bytes of data are located on the psychical disk. This is not always guaranteed when you go through a filesystem. When you delete a file and make a new one, most filesystems will mark the old file as "deleted", but not remove the data. Then, if you make a new file it will create the data somewhere else and "link" the directory entry to the new location...

FF7 does not use the directories, folders, or filenames to access data. That's why they got rid of them in later games. What happens is the FF7 kernel tells PSX where to put the laser head and reads the ones and zeros directly from the media.

I'm simplifying a little, but that's what's happening in a nutshell.

FIELD.BIN (exploration) thread

Cyberman

Guest

Micky

Guest

Gemini

Guest

Micky

Guest

halkun

Guest

Micky

Guest

Gemini

Guest

Cyberman

Guest

Lazy Bastard

Guest

Vehek

Guest

Lazy Bastard

Guest

Gemini

Guest

Lazy Bastard

Guest

Gemini

Guest

Lazy Bastard

Guest

Micky

Guest

Lazy Bastard

Guest

Lazy Bastard

Guest

Jenova's Witness

Guest

halkun

Guest