About kernel.bin file and 6 bytes header

[Squall78]

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]

AE 05 00 0E 01 00
05AE is the length of the section, but what are 00 0E 01 00 ?

[mav]

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.

[Squall78]

Arf... I'm so stupid, I've looked at only "kernel.bin page" -_-
Thanks for your help M4v3R

Hojo will be released soon

[Squall78]

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 ?

[Cyberman]

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

[Squall78]

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

[mav]

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.

[Cyberman]

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

[Squall78]

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

[kruci]

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=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)

[Squall78]

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.

[mav]

So, how's your Hojo program doing?

[Squall78]

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