Qhimm.com Forums
Miscellaneous Forums => Scripting and Reverse Engineering => Topic started by: Squall78 on 2007-11-02 23:05:49
-
Hi there !
I've almost completed my monster editor called Hojo !
I've just to implement the kernel.bin file fixer. But I've a question about this file.
On QhimmWiki it's written that each section begins by a 6 bytes header. I've seen that 2 first bytes (maybe more ?) represent the length of the gzipped section. But what are the next bytes ?
For example, for the section 2 there is :
AE 05 00 0E 01 00
05AE is the length of the section, but what are 00 0E 01 00 ?
-
It is written on the wiki (http://wiki.qhimm.com/FF7/Kernel/Low_level_libraries#BIN-GZIP_Type_Archives). First 6 bytes of each file is as follows:
2 bytes: File length compressed
2 bytes: File length uncompressed
2 bytes: File ID (in kernel.bin it's an incremental number from 0 to 9), it must be untouched for the game to work.
You can check source of my FF7 SceneFix program (http://www.subfan.pl/ff7pl/ff7scenefix_src.zip) if you want to look at my implementation.
-
Arf... I'm so stupid, I've looked at only "kernel.bin page" -_-
Thanks for your help M4v3R :)
Hojo will be released soon :)
-
I've a last little question.
In the look-up table, number of files are written on 1 byte. But the last value should be 256 while a byte reach 255. By examining the original kernel.bin file, I suppose the last value (256) must be "changed" to 255. Isn't it ?
-
I've a last little question.
In the look-up table, number of files are written on 1 byte. But the last value should be 256 while a byte reach 255. By examining the original kernel.bin file, I suppose the last value (256) must be "changed" to 255. Isn't it ?
Ummm I'm not sure what you are talking about. Why would the last value be 256? Are you assuming the file ID's are 1 to 256? They might be 0 to 255 why is there a restriction of one byte? Are you looking at Q-gears source? I'm not certain what the 1 byte is about.
What are you making the look up table for?
Cyb
-
Well, let's see this example :
Scene file :
Section 1 : 11 files
Section 2 : 7 files
Section 3 : 3 files
So in the kernel file there will be :
0x00
0x0B (0x00 + 0x0B)
0x12 (0x0B + 0x07)
0x15 (0x12 + 0x03)
but in scene file there is 256 files, so the last bytes of the look up table should be 0x100 isn't it ?
Edit : by observing the source code from M4v3R, I see it does not write the last byte... so instead of 0x100 there is 0xFF
-
The last byte should be 0xFF, because you also count 0'th file ;). But yes, You can just leave it untouched as in my source.
-
Ok now I see. Let me explains something real quick. There are 256 values represented by a byte. Instead of 1 - 256 it's 0 - 255 none the less there are 256 values. So it will be FF. Remember 0 is a number :)
Cyb
-
Ho ok :) - Here 0 represents 1 file... I tought 0 meant 0 file and 1 meant 1 file. So if 0 means 1 file I understand that 255 represents 256 files. Thanks a lot for your explanations :)
-
Yeas, last Byte should be 256.
But we dont know how its computed...
1.0xFF can mean some stop char
2.or they skip 256th file
Tech info:
http://forums.qhimm.com/index.php?topic=5759.msg74232#msg74232 (http://forums.qhimm.com/index.php?topic=5759.msg74232#msg74232)
http://forums.qhimm.com/index.php?topic=6391.msg80497#msg80497 (http://forums.qhimm.com/index.php?topic=6391.msg80497#msg80497)
technical update:
in original scene.bin last block has 11files
in original 3rd file of kernel.bin is for last block F5h-FFh
but this mean according to links above FF minus F5=10files or F5 to FE files (10files)
(FF minus 0 = 255files, files from 0 to FE = 255files, but scene.bin has 256files)
so last is FFh instead of "100h".
last file of scene.bin(256th file) contain only FFh chars.(5,251-256 are same)
-
Yes, we can also suppose this :
kernel file reads number of files in each section by making a substraction between a byte and the previous byte, but the current byte is FF, kernel knows that files are from previous byte and until the end of the scene file.
Well, it's just a supposition among others.
-
So, how's your Hojo program doing? :)
-
Hojo will do just like your kernel.bin fixer. It will write number of files until the last section but one, and will write 0xFF for the last section. :)
Note : Hojo is finished but I will wait one week to release it in order to optimize code and fix bugs :)