About kernel.bin file and 6 bytes header

  • Thread starter Thread starter Squall78
  • Start date Start date
Status
Not open for further replies.
S

Squall78

Guest
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 :

Code: [Select]
Code: 
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. 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 if you want to look at my implementation.
 
Last edited:
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 ?
Click to expand...
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
 
Last edited:
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:
https://www.ff7catalog.com/posts/50719/
https://www.ff7catalog.com/posts/56789/

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)
Click to expand...
 
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.
 
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 :)
 
Status
Not open for further replies.
Back
Top