Update November 11, 2009
CFC and CFC GUI have been updated to 0.60 and 0.60.35 respectively. CFC runtime files have been updated. This thread has also been update to add information about the new file formats.
Changes:
- (CFC GUI) Support for new filenames (and categories) used in TF3D v2.5+
- Support for new file formats (read only, "replace" write is always in old format) used in TF3D v2.5+
- Support for new compressed formats that correspond to the new formats mentioned above
- (CFC GUI) If you are using this with 2.5, please do read the 2.5 specific notes (in the CFC GUI thread).
- At this time I STRONLY recommend patching Manila files manually instead of using the auto-patching! See the tech thread referenced below.
Update June 5, 2009
CFC and CFC GUI have been updated to 0.55 and 0.55.25 respectively. The CFC runtime files have not been updated. Changes:
- Better compression ratio (backwards compatible with old runtime)
- UltraHQ en/de-coding support (CFC)
- "Patch Manila on device" function has been improved to work-around the issue of Manila no longer starting that some people have (CFC-GUI)
Update April 20, 2009
CFC and CFC GUI have been updated. Many changes! For the changelog see the CFC GUI thead. The CFC runtime has also been updated to v0.50, so there is a new libgles_mn file required. See the cfc-support-dll zip attached a few posts down.
Update Feb 26, 2009
CFC and CFC GUI have been updated to 0.46.15. Fixed an issue with PNGs without alpha channel.
Update Jan 15, 2009
CFC Live Patch 0.45.01 has been released. You can run this tool on your phone to make your current Manila installation compatible with CFC compression.
See this post.
Update Jan 14, 2009
CFC GUI 0.45.15 released. No changes to CFC core, only GUI stuff. Attached download updated.
CFC GUI thread: http://forum.xda-developers.com/showthread.php?t=470798
Changelog: http://forum.xda-developers.com/showpost.php?p=3164604&postcount=3
Update Jan 13, 2009
CFC 0.45 and CFC GUI 0.45.12 released.
CFC (core) changes:
- Heavily modified encoding algorithm. It is often slower but the quality should be much better. Please read this post!
CFC GUI changes:
- No longer freaks out if the wrong file attributes are set on some files
- Added background color selection
- Added tool to patch a complete Manila package for CFC compatibility and optimization
Also, non-technical discussion of CFC GUI (only) should go to this thread:
http://forum.xda-developers.com/showthread.php?t=470798
Update Jan 12, 2009
Yes I know, too many updates today!
CFC 0.42 attached. Was something weird going on with the encoding sometimes. Furthermore it seems like the encoding works great on the original files, but it drops the ball here and there with other files. Going to look into that ASAP and finetune the encoding algorithm!
Most important about this update is, CFC now also comes with a GUI!
Update Jan 12, 2009
CFC has been updated to version 0.4. Added features are:
- QTC -> PNG (+- 30% faster than 0.4b2)
- PNG -> QTC
- CFC -> QTC (finally)
- QTC padding
- QTC trimming
With QTC <-> PNG conversion now available from CFC, it seems the Compressonator is no longer needed!
Further EDIT: All posts updated.
Further EDIT: 0.41 added... There was a small bug in CFC compression in 0.4, it didn't always set PayloadSize correctly, which could create errors with padding/trimming.
Update Jan 8, 2009
CFC has been updated to version 0.3. It can now fully handle the RGB format as well. CFC compression has been slightly optimized. QTC and ATC headers are now completely written correctly.
This now also allows for larger than original images
Also lots of info in the first 6 posts has been updated to reflect these changes and add information.
Update Jan 7, 2009
Thanks to myself and D-MAN666, it seems the QTC format is now completely known!
Also today brings CFC compression for (W)VGA devices, if chefs choose to implement it. The needed stuff is here.
The CFC tool itself still needs an update (0.3 ?) to handle QTC/ATC_RGB conversion to ATC/ATC_RGB conversion (and back) and to decompress the CFC files. Donor headers won't be needed anymore then either in some cases (but they will remain handy in others!), and with that some parts of the first 5 posts will have to be rewritten as well (sigh...)
Note that some other parts of the first few posts are marked with changes. Look for the red letters.
- end of updates -
Intro
As some of you may have seen, me, djboo, pcarvalho, "he who shall not be named" and several other enthousiasts have ported TouchFlo3D (to be specific, the version that came on my Raphael) to QVGA. A large part of this effort involved hacking into Manila/Mode9 and even OpenGL ES itself to get it operating decently, but after that, a lot of effort went into optimizing, which was largely done by scaling the images. While working on this, I encovered a lot of information and wrote quite a bit of code to 'get it done'. As always, a lot of it ultimately redundant, but we did pull it off! (barring some issues that are driver related).
Acknowledgements
Before continuing, people need to be acknowledged for their parts in this. I could hardly have done it alone. A lot of these credits go out to people involved in the TF3D QVGA porting, but also drivers porting, they all had a hand in this information being 'discovered', and hence are mentioned here.
- djboo Keeping all this stuff going. I looked at this stuff once when herg did an attempt, never really got involved, but because of him did get involved this time around. As he seems to be forgotten in the credits here and there, he's #1 in this thread!
- pcarvalho A bit of competition that led to great stuff. In the end, our intended methods of porting complement eachother nicely - 'my' part got it going, but the QVGA port didn't really shine 'til we did the other things 'his way' as well.
- "he who shall not be named" The anonymous HTC-CA hacker, about whom probably everybody knows who he is (it aint me ) Did some cracking work on this too.
- The P3D Team A bunch of them did a lot of testing
- D-MAN666 Mentioned last but certiainly not least! Cracked the file format first, and generally found out and published a hell of a lot of information. Also the author of Manila Editor.
Requirements
For all this, you will need and/or want the following:
- "The Compressonator", image conversion/compression/viewer tool by ATI/AMD. You may need to sign up at the AMD website, but it is free of charge and I haven't received any spam from them yet. Update: The version of Compressonator on AMD's site is no longer able to do ATC. The correct version of Compressonator is attached to this post. Update: The Compressonator is now no longer strictly needed due to CFC being able to do the QTC en/decoding.
- "Manila Editor", Manila image editor. You will not be using this for the actual good stuff, but you may be using this for testing things quickly, and you will definitely want to use it for finding the files you actually want to replace. Update: no longer needed, use the CFC GUI instead!
- CFC, (attached), tool by yours truely to convert between QTC, ATC, CFC and PNG formats
- Knowledge of the Windows command line - Though CFC now comes with a GUI as well, yay!
- The files attached to this post. These are all the images from Manila (the version that came with my Raphael) converted to PNG by "The Compressonator". It's kind of a ***** to do, so if you want to save yourself some trouble, just see that post. VGA as well as (rescaled using Lanczos3) QVGA images are attached to that post. Update: this image packs need to be updated, will do some time
CFC download
Notice: you do not need the compressonator files to use CFC. They are just here in case you want to do things the old-school way
( < 0.60 : 3408 downloads )
Textures, ATC, CTES, QTC, CFC (tech background)
The imageon 3D chip in our devices support texture compression, and Manila (Mode9) uses this. The format used is a special format created by AMD/ATI for low size and lower power use on mobile devices, called ATC (ATI Texture Compression).
There are three ATC formats:
- ATC_RGB: 4 bits per pixel (4 bits RGB)
- ATC_RGBA_EXPLICIT_ALPHA: 8 bits per pixel (4 bits RGB + 4 bits Alpha)
- ATC_RGBA_INTERPOLATED_ALPHA: 8 bits per pixel (not sure on the format)
Almost all images used in Manila are of the 'ATC_RBGA_EXPLICIT_ALPHA' variant, and this article will focus on these. ATC_RGB is also used for a small number of images, though I have not further investigated its format.
The image data for these formats are stored in one of the following file formats:
- ATC: The file format generally used by AMD/ATI
- CTES: ATC related, some weirdness, see below. Seems to be forward compatible with ATC, but not backwards.
- QTC: Qualcomm adapted version of ATC, used by Manila/Mode9
The formats are very similar, though we will focus only on ATC/QTC, that's all we need.
Image data (ATC_RGBA_EXPLICIT_ALPHA) - Updated January 12, 2009
A lot of the original information comes from D-MAN666's posts here.
I will skip over the headers (32 bytes), they are listed below for ATC and QTC specifically. This is about the actual image.
The image is divided into blocks of 4x4 pixels. An 8x8 image would be stored like this: (A, B, C and D are 'pixel blocks')
AAAABBBB
AAAABBBB
AAAABBBB
AAAABBBB
CCCCDDDD
CCCCDDDD
CCCCDDDD
CCCCDDDD
A 4x4 pixel block is 16 pixels and 16 bytes. So in effect, you can see it as 8 bits per pixel. An image is always stored using these 4x4 pixel blocks. A 5x5 images would thus use 4 blocks!
bytes 0-7 are alpha values for each pixel, 4 bits per pixel (4 bits * 16 = 64 bits = 8 bytes) - this is not present for the ATC_RGB format. Scale these to the 0..255 range by multiplying each alpha value by 17.
bytes 8-11 are color keys, there are two keys of 16 bits (2 bytes). The keys are stored like this:
word 1: XRRRRRGG GGGBBBBB (1-bit method, 5-bit R, G, B)
word 2: RRRRRGGG GGGBBBBB (5-bit R, 6-bit G, 5-bit B)
Where X is the decoding method to use, there are two.
bytes 12-15 are mixdown values, 2 bits per pixel (2 bits * 16 = 32 bits = 4 bytes). The per-pixel mixdown value, combined with the color keys mentioned above determine the actual color that is outputted. You must scale the scolor keys to the 0..255 range and apply a formula to them.
Code:
if HasAlpha then begin // skip for ATC_RGB
sIn.Read(dw, 4); // read dword
for i := 0 to 7 do begin
alpha[i] := (dw and $F) * 17;
dw := dw shr 4;
end;
sIn.Read(dw, 4); // read dword
for i := 8 to 15 do begin
alpha[i] := (dw and $F) * 17;
dw := dw shr 4;
end;
// alpha[0..15] now contain the scaled 4x4 pixel block alpha values
end;
sIn.Read(w, 2); // read a word, key1
Method := (w shr 15);
Keys[iR, 0] := ((w and $7C00) shr 10) * (255/31);
Keys[iG, 0] := ((w and $03E0) shr 5) * (255/31);
Keys[iB, 0] := (w and $001F) * (255/31);
sIn.Read(w, 2); // read a word, key2
Keys[iR, 1] := ((w and $F800) shr 11) * (255/31);
Keys[iG, 1] := ((w and $07E0) shr 5) * (255/63);
Keys[iB, 1] := (w and $001F) * (255/31);
sIn.Read(mixdown, 4); // read a dword, mixdown values
for i := 0 to 15 do begin
pixels[i] := (mixdown and $3);
mixdown := mixdown shr 2;
end;
// pixels[0..15] now contain the still-encoded 4x4 pixel block mixdown values
When thinking about the color keys and mixdown values, think of the keys as a color-range start and end value. The mixdown values decide which value to pick inside the range. (for each R,G,B)
For example, let's take a key1 of 10 and a key2 of 40 for Green. Then the decoded Green values would be:
Code:
mixdown 00 01 02 03
value 10 20 30 40
This is only true, however, when the 'method' bit (X) is 0. Full decoding of both methods:
Code:
for i := 0 to 15 do begin
a := alpha[i];
if (method = 0) then begin
r := Round( Keys[iR, 0] + ((pixels[i] / 3) * (Keys[iR, 1] - Keys[iR, 0])) );
g := Round( Keys[iG, 0] + ((pixels[i] / 3) * (Keys[iG, 1] - Keys[iG, 0])) );
b := Round( Keys[iB, 0] + ((pixels[i] / 3) * (Keys[iB, 1] - Keys[iB, 0])) );
end else begin
case pixels[i] of
0: begin
r := 0;
g := 0;
b := 0;
end;
1: begin
r := Round( Keys[iR, 0] - ((1/4) * Keys[iR, 1]) );
g := Round( Keys[iG, 0] - ((1/4) * Keys[iG, 1]) );
b := Round( Keys[iB, 0] - ((1/4) * Keys[iB, 1]) );
end;
2: begin
r := Round( Keys[iR, 0] );
g := Round( Keys[iG, 0] );
b := Round( Keys[iB, 0] );
end;
3: begin
r := Round( Keys[iR, 1] );
g := Round( Keys[iG, 1] );
b := Round( Keys[iB, 1] );
end;
end;
end;
end;
Both methods have various way of formulating them. I thought the ways I have chosen here are clearest for how it works.
Update Jan 7, 2009
Image data (ATC_RGB)
The image data here is exactly the same as ATC_RGBA_EXPLICIT_ALPHA, except that the alpha bits aren't includes. So, each 16-pixel block becomes 8 bytes instead of 16, as bytes 0-7 from ATC_RGBA_EXPLICIT_ALPHA are not there. This means 4 bits per pixel.
- end of update -
ATC, CTES, QTC
This image data seems to be the same across all formats - and it should be, as this data is sent directly to the 3D chip. You would not want to have to process it first.
Let's first pick out CTES, as I have very little to say about it. It seems to be nearly the same as ATC and QTC, however, for some reason, "The Compressonator" will output CTES files we can use as ATC, but will not read our own Manila-based ATC's in CTES mode (only in ATC mode). What's up with that? I don't know. Perhaps one of you will figure it out.
QTC header
Code:
Magic: DWORD; // 0x31435451 : "QTC1"
Magic2: DWORD; // always 1 ?
Width: DWORD;
Height: DWORD;
Format: DWORD; // 0x14, 0x15
Dummy1: DWORD; // formerly known as Unknown1, may be 0 - Jan 7, 2009
PayloadSize: DWORD; // formerly known as Unknown2 - Jan 7, 2009
Dummy3: DWORD; // formerly known as Unknown3, may be 0 - Jan 7, 2009
The meaning of the unknowns has not been deciphered yet. Setting them to weird values does muck-up the decoding of the images, however, they do not seem to be actually sent to the 3D chip. Or perhaps I just have not found where and when!
For format, 0x14 is used for ATC_RGB_EXPLICIT_ALPHA. The small number of images that use 0x15, I suspect, are ATC_RGB. Either way, they do not decode using the ATC_RGB_EXPLICIT_ALPHA method and I know ATC_RGB is used some places, so it would make some sense to make this assumption.
Update Jan 7, 2009
Unknown2 has been replaced by PayloadSize, thanks to myself, D-MAN666 and eidolen.
The PayloadSize is the number of bytes after the header that contain content.
For images of type 0x14 (ATC_RGB_EXPLICIT_ALPHA) this is: Width * Height, where both Width and Height are multiples of 4, due to how the format itself works, in other words: (RoundUp(Width / 4) * 4) * (RoundUp(Height / 4) * 4).
For images of type 0x15 (ATC_RGB) this is half of type 0x14, because ATC_RGB uses 4 bits per pixel instead of 8. The multiples of 4 rule still stands, so the PayloadSize is: Round(((RoundUp(Width / 4) * 4) * (RoundUp(Height / 4) * 4)) / 2)
Note that all Manila image files (at least the ones I have) are padded to be a multiple of 512 bytes in size. This is probably a speed optimization for when these files are cooked into a ROM.
Dummy1 and Dummy3 (aptly renamed from Unknown1 and Unknown3) seem to be irrelevant. After we figured out how PayloadSize (Unknown2) was relevant, we tried blanking out Dummy1 and Dummy3 with 0's, and TF3D still works without a hitch. The original values do not seem to be related to the dimensions nor the payload size, and they are not sent to the graphics chip either.
- end of update -
Update November 6, 2009
Manila 2.5 uses 4 additional file formats:
0x01 - 8888 RGBA, 32bpp
0x02 - 888 RGB, 24bpp (I have not encountered an actual image in this format, so processing may be faulty by CFC and CFC GUI)
0x03 - 565 RGB, 16bpp
0x05 - 4444 RGBA, 16bpp
- end of update -
ATC header
Updated 08/Jan/2009
Code:
Magic: DWORD; // 0xCCC40002
Width: DWORD;
Height: DWORD;
Format: DWORD; // ATC_FORMAT, 0x01 for RGB, 0x02 for RGBA_EXPLICIT_ALPHA, 08/Jan/2009
Magic3: DWORD; // 0x20 ... mucks up colors... not clear?
Magic4: DWORD; // 0x01, 08/Jan/2009
Magic5: DWORD; // 0x01, 08/Jan/2009
FormatMagic: DWORD; // 0x8C92 for RGB, 0x8C93 for RGBA_EXPLICIT_ALPHA, 08/Jan/2009
- end of updated content -
CFC format + historic Compressonator editing
CFC format
I use the CFC format (yes, that's why the tool is called CFC) for the Manila QVGA port. It saves a lot of space and even seems to improve performance a bit. It uses standard gzip/zlib compression on the QTC image data (which compresses to about 20% on average) and hides the compressed data inside the QTC file itself. Decompression of this is over 5 MB/s on our devices, but images are only a few KB each. The proxy libgles_cm is what actually decodes this and sends the decompressed data to the 3D chip.
CFC adjusts the QTC header to the proper values. Beware when doing this yourself that Mode9 uses these values internally as well). The image data ('payload') is replaced as follows:
Code:
Magic: DWORD; // 0x31434643 : 'CFC1'
Format: DWORD; // CFC_FORMAT...
Width: DWORD;
Height: DWORD;
CompressedSize: DWORD;
UnCompressedSize: DWORD;
... compressed data ...
Format can be one of the following:
Code:
CFC_FORMAT_COMPRESSED_QTC_RGBA_EXPLICIT_ALPHA = 0x3001; // 0x14 from QTC
CFC_FORMAT_COMPRESSED_QTC_RGB = 0x3002; // 0x15 from QTC - used since CFC 0.3
CFC_FORMAT_COMPRESSED_RGBA = 0x3101; // April 20, 2009 - RGBA format - used since CFC 0.5
CFC_FORMAT_COMPRESSED_RGB = 0x3102; // April 20, 2009 - RGB format - used since CFC 0.5
Width and height are included for historic reasons, and it also opens up the possibility to do some weird mods. RGBA format is included for possibly allowing use of uncompressed textures for Manila support on non-HTC/Qualcomm/ATI/AMD based devices.
Update April 20, 2009
(A)RGB formats are gzip/zlib compressed just as QTC/CFC variants and require the CFC 0.50 runtime files. The uncompressed data is actually stored as (height x width x) BGR(A) (from x86 viewpoint) as this is the format the graphics chip can handle.
Update November 6, 2009
The following formats have been added to CFC. Note that the QTC header always says RGB or RGBA_EXPLICIT_ALPHA. This actually allows the new formats to be used on older Manila versions that do not directly support them, if you are using CFC 0.60 runtimes.
Code:
// CFC 0.60 additional formats
CFC_FORMAT_COMPRESSED_QTC_8_8_8_8 = 0x3003;
CFC_FORMAT_COMPRESSED_QTC_X_8_8_8 = 0x3004;
CFC_FORMAT_COMPRESSED_QTC_5_6_5 = 0x3005;
CFC_FORMAT_COMPRESSED_QTC_4_4_4_4 = 0x3007;
Notice: the text below in this post is here for historic reasons. It is no longer completely relevant
Right, well I did tell you to get "The Compressonator" from AMD's site, right? You should have done this by now. You should also have the CFC tool attached to the first post of this thread.
Say we want to manipulate an image from Manila. First we need to find out which image it is. Easiest way to find them is to use Manila Editor (also linked in first post), so you get the 'magic' filename.
You may want to ask why we dont simply use Manila Editor for doing these things, simply put, the image quality from The Compressonator is better than the current version of Manila Editor. Also, we can do stuff in batch in The Compressonator.
Manila to PNG (single)
Now, say this image is 7d3f1247_manila (the globe on the internet page), we use the CFC tool to convert it to ATC format:
Code:
cfc -qa 7d3f1247_manila 7d3f1247_manila.atc
You can open this file in The Compressonator. It may look a bit weird, because alpha is not displayed. Right click on the image and select "Show RGBA", there, that looks better.
Something you will not directly notice with the globe image, but you will with other images, is that the image is UPSIDE DOWN. You will need to flip the image over if you want to put it back into Manila. For some reason I haven't figured out yet, decoding goes upside down, but encoding needs to be the correct side up.
Now we may wish to edit this file, so we save it as PNG: File -> Save Original.
Open it in photoshop, flip it vertically, and save it.
Manila to PNG (batch)
We will need to use batch mode to convert back to Manila anyways, so lets just start using it for converting it to PNG as well (for some reason doing it non-batch doesn't work right).
This will assume you have a bunch of .atc files in a directory. Batch converting Manila (QTC) files to ATC files is also possible with CFC:
Code:
cfc -qaf orgfiles atcfiles
Assuming you have your original Manila files in the folder 'orgfiles' and created a new empty directory 'atcfiles'.
Open The Compressonator, and go to File -> Batch Compress (or press F4). Navigate to your folder containing all the ATC files, set the "Files of type" box to "ATC Textures (*.ATC...)". set the "Output File Format" to PNG and "Output Format" to "ARGB8888". Punch the "Compress All" button and wait a bit.
Note that some files will not decompress correctly and crash The Compressonator. You will have to look at the crash dump to find out which file was the culprit and remove it from your batch directory. IIRC, there are about 10 files that have this issue, so be prepared for 10 minutes of infuriating work.
You MUST set "Output directory" to "Use Input Directory", or you will not be able to decompress more than one file!
In the end, you will have a large bunch of PNG files. Note that these PNG files are also available already done for you, see the link in the first post of this thread.
Files known to crash The Compressonator: 08/Jan/2009
Code:
00ad7edb_manila.atc
056e5c7f_manila.atc
063f5858_manila.atc
0c175082_manila.atc
2255b55f_manila.atc
24720929_manila.atc
39064485_manila.atc
4a209508_manila.atc
PNG to Manila (single + batch)
Even for single files, we are using the batch function, as there seems to be an issue with doing this in The Compressonator normally.
The operation is exactly the same, but for single you select the file and press "Compress", and for many files you do not select a file and press "Compress All".
Note that as previously mentioned, decoding ATC to PNG files results in the PNG's being upside down, but to make ATC files from PNG files the correct side needs to be up!
This time around we set "Files of type" to "PNG Textures" (duh) and "Output File Format" to "CTES Textures". As previously mentioned CTES is compatible with ATC, but ATC is not compatible with CTES. You won't notice this though.
The magic is the "Output Format" setting. Set it to "CTES Texture Compression" and hit the "Options" button. In the "Compress Texture" dialog that pops up, select "ATC RGBA Explicit Alpha (8 bits per pixel)", or "ATC RGB (4 bits per pixel)", depending on which format you want, hit OK, and you're there. Hit "Compress" or "Compress All", and wait 'til it's done.
You MUST set "Output directory" to "Use Input Directory", or you will not be able to decompress more than one file!
Now we want to convert these CTES/ATC files back to Manila files, and for this, again, we use the CFC tool:
Code:
cfc -aqf atcfolder qtcfolder orgfolder
You can also use -aq instead of -aqf for a single file. Note that the CFC tool does NOT change filenames, so you have some renaming to do.
Update 08/Jan/2009
With CFC 0.3, donor headers are not longer necessary, and have become an optional parameter.
- end of update -
Rescaling to QVGA
Converting Manila images to QVGA is pretty simple. Just use the techniques described above.
What you want to do is scale ONLY images 32x32 and larger, and you will want to divide the width and height exactly by two. That's all there is to it.
If you have a bunch of PNG files you want to scale, the CFC tool can even do this for you, including the needed vertical flip:
Code:
cfc -nsf vgapngfolder qvgapngfolder
This will rescale using the Lanczos3 algorithm.
CFC Compression
The QVGA port supports the CFC format as mentioned above. This can save a lot of space and is the preferred way of using textures for the QVGA port.
To compress your QVGA QTC files to CFC:
Code:
cfc -cf qvgaqtcfolder qvgacfcfolder
CFC tool (commandline)
As CFC offers a lot of options, many of them related to the pre-0.4 way of converting images, I'll take a very short time to explain the most relevant CFC options, what they do, and when/why you should use them. Most of these are available in the GUI as well.
Convert QTCs to PNGs
Code:
cfc -qp in-filename out-filename
cfc -qpf in-folder out-folder
Since CFC 0.4 this should be the preferred way to convert Manila's QTC files to PNG's (it's pretty fast and saves a lot of steps and trouble compared to using other CFC options and the Compressonator). These images come out with correct side up, so no longer is there a need to flip them manually with CFC or Photoshop or whatever.
Note: This does not handle CFC compressed QTC's, you will have to decompress those first!
Convert PNGs to QTCs
Code:
cfc -pq in-filename out-filename
cfc -pqf in-folder out-folder
Obviously if you want to convert QTCs to PNGs there's a good chance you also wish to do the reverse. Introduced in CFC 0.4b2. CFC will automatically detect if RGBA_EXPLICIT_ALPHA or RGB is the most optimal QTC format to use.
Quality rivals the Compressonator, but CFC is quite a bit slower (though the saved number of steps save you more time).
Note: The output are not CFC compressed, you will have to do that manually.
Compress QTCs to CFCs
Code:
cfc -c in-filename out-filename
cfc -cf in-folder out-folder
Compressed QTCs (CFCs) are usually much smaller than the original QTCs, and provide a performance boost as well. However, you will need a patched Manila to be able to use CFCs. The QVGA port is patched to do this, and instructions on how to other Manila versions can be patched are included a few posts below this one.
Decompress CFCs to QTCs
Code:
cfc -d in-filename out-filename
cfc -df in-folder out-folder
This should speak for itself
Trim QTCs
Code:
cfc -t in-filename out-filename
cfc -tf in-folder out-folder
Saves some space on your hard-disk, removes unnecessary data from the QTC files (also works on CFCs).
Pad QTCs
Code:
cfc -p in-filename out-filename
cfc -pf in-folder out-folder
This makes the QTCs (and CFCs) a multiple of 512 in bytes in size. HTC originally did this with all their images. It seems to improve performance when Manila is cooked in.
Scale PNGs VGA->QVGA
Code:
cfc -ps in-filename out-filename
cfc -psf in-folder out-folder
For the theme and Manila porters. Note that Manila in QVGA can handle VGA textures (and vice versa) just fine, however, using the correct image size for the Manila resolution does improve performance quite a bit.
Complete QVGA port example
Updated 13/Jan/2009
You can now do this whole thing with a single push of a button in the CFC GUI: Tools, Scale QVGA -> VGA
- end of update -
Updated 12/Jan/2009
The text below has been updated to reflect changes with CFC 0.4
- end of update -
This is the complete rundown of how I converted all the VGA images from Manila to QVGA images, the same method can be applied to themes and what not.
First, create a directory somewhere, and put the CFC.exe in it. Then go to the command line and change directory to this new directory.
We will want to create a bunch of directories:
1) Setup
Code:
mkdir org png pngscale qtc cfc out
Dump all your original manila files in org (in this case, the entire manila, but you could just dump your theme in there instead)
2) Convert QTC to PNG
Code:
cfc -qpf org png
3) Scale PNG images from VGA to QVGA
Because CFC will not scale very small images, we need to make sure the output folder (pngscale) has all the images we want first. The ones that are scaled will be overwritten by CFC:
Code:
copy png\*.png pngscale\*.png /y
Do the scaling:
Code:
cfc -psf png pngscale
4) Convert PNG back to QTC
Code:
cfc -pqf pngscale qtc
5) Convert QTC to CFC (optional)
Code:
cfc -cf qtc cfc
6) Pad QTC/CFC (optional, for cooking)
Code:
cfc -pf cfc out
2-6 in one go:
Note that this does not include making the directory and placing your Manila in the org folder.
Code:
cfc -qpf org png
copy png\*.png pngscale\*.png /y
cfc -psf png pngscale
cfc -pqf pngscale qtc
cfc -cf qtc cfc
cfc -pf cfc out
--
Et voila, most of our images have now been rescaled to QVGA, are compressed for optimum filesize, and located in the qtc, cfc, or out folder, depending on which steps you skipped.
Also note we retouched some images by hand for the QVGA version.
CFC for VGA and WVGA
!IMPORTANT! Updated 11.11.2009: CFC GUI updated. Support DLLs updated to CFC 0.60!
!IMPORTANT! Updated April 20, 2009: CFC Live Patch discontinued!
I have recompiled the libgles proxy file originally made for QVGA to a version that only handles the CFC compression, and should work on any 'normal' Manila 3D version, like the ones found on the Touch Diamond, Pro and HD.
If you cooks/chefs/whomever implement this, you can reduce TF3D's size footprint by half (7 mb smaller in my test). This also makes a positive performance difference, as the on-the-fly decompression of the images is actually faster than the flashdisk access.
Patching TF3D to be able to use CFC compression also allows theme makers to make faster and smaller themes.
Instructions to modify TF3D VGA/WVGA - for users NEW!:
FOR v2.5 AND NEWER PATCH MANUALLY!
- Get CFC GUI, attached to the first post of this topic.
- Connect your device using ActiveSync
- Use the "Device->Patch Manila on device" feature
Instructions to modify TF3D VGA/WVGA - for chefs:
FOR v2.5 AND NEWER PATCH MANUALLY!
- Get CFC GUI, attached to the first post of this topic.
- Run CFC GUI and select the folder where your Manila package is stored
- Make sure you got a backup of said folder
- Go to Tools -> Patch Manila
The following things will be done to your Manila package:
- All image files will be CFC compressed (lossless, faster)
- All image files will be padded to be a multiple of 512 bytes in size (faster)
- All image files will be set to System/Hidden/Archive file attributes
- Manila.exe will be patched to use libgles_mn.dll
- Manil2.exe will be patched to use libgles_mn.dll (depending on Manila version)
- Mode9.dll will be patched to use libgles_mn.dll
- libgles_mn.dll will be placed in the package
- zlib_mn.dll will be placed in the package
If no errors occur, there is nothing else you need to do, aside from cooking the package
Instructions to modify TF3D VGA/WVGA - by hand
Attached is a zip file (cfc-support-dlls) with the two DLLs you need: libgles_mn.dll and zlib_mn.dll . These must be placed in your \Windows folder.
Next, hex edit Manila.exe, Manil2.exe and Mode9.dll to use libgles_mn.dll instead of libgles_cm.dll. Just search for "libgles_cm.dll" in the files and replace it with "libgles_mn.dll". These values may appear multiple times in the file! Make sure to search and replace for both ANSI and UNICODE variants! Your Manila version may not have both Manila and Manil2, or only one of them may contain the "libgles_cm.dll" string. This is normal.
You should also modify HKLM\Software\OEM\MASD\Manila and append _CFC to the version string. This so people can recognize if their installation supports CFC.
This will only add support for CFC to your Manila install, it will not make images and such actually use CFC. But you can now support themes that do use CFC.
Note to people who used an older version of this patch
You don't have to do it again, but the automated tool makes sure everything is done right. If you still have zlib1.dll from the old patch on your device, do not remove it unless you want to break the "Teeter" game.
You can run the automated tool over a package you used the older patch on - it will clean it up.
Wow. I can't wait. So is it possible then to run TF3D on an older VGA device? Or is this to help us decode the themes. Isn't james making a image converter from vga to qvga?
Kraize92 said:
Wow. I can't wait. So is it possible then to run TF3D on an older VGA device? Or is this to help us decode the themes. Isn't james making a image converter from vga to qvga?
Click to expand...
Click to collapse
everything has been converted to qvga
CraZyLiLbOy said:
everything has been converted to qvga
Click to expand...
Click to collapse
True, but a tool would still be nice because the skins of tf3d are all in vga. If we had a converter, I could apply the theme and everything, and then convert it to qvga.
Kraize92 said:
True, but a tool would still be nice because the skins of tf3d are all in vga. If we had a converter, I could apply the theme and everything, and then convert it to qvga.
Click to expand...
Click to collapse
You don't have to convert anything to qvga. All touchflo 3d themes work on our qvga devices. You are using touchflo 3d interface from the diamond. You can apply any themes you want for the touchflo 3d. I know the diamond is a vga device but it still works. I'm saying this because I've tried it and it works, mark my words
The QVGA port was made specifically in mind with that VGA stuff will just work - and they will. However, when I finish this guide and you have read it, you will understand exactly how you can significantly optimize the QVGA version - and make the VGA version better
I don't know man but I think I fall in love with the touchflo 3d. Thanks to Chainfire and djboo.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Great TUT very interesting. thanks for sharing your tools
yesssss thank you for your great tuto,
2Chainfire
Didn't understand how to convert single PNG to manila's VGA file
Could u give me more examples?
any progress???
Any progress... on what? This tutorial is finished. TF3D-QVGA is finished. All we're waiting for is a new driver release that fixes the power issues.
i dont mean to sound like a complete idiot, but will this ever be in cab form?
i have no idea what most of what you are talking about means in this tutorial, I am just legitimately curious if it is even possible.
also if that is not possible, wouldnt the old touchflo3d porting-to-qvga cab be necessary along with this tutorial? maybe i am just seriously confused and have no idea what is going on
disregard if this is too much ignorance in one post!
thanks
htctoucher
htctoucher said:
i dont mean to sound like a complete idiot, but will this ever be in cab form?
i have no idea what most of what you are talking about means in this tutorial, I am just legitimately curious if it is even possible.
also if that is not possible, wouldnt the old touchflo3d porting-to-qvga cab be necessary along with this tutorial? maybe i am just seriously confused and have no idea what is going on
disregard if this is too much ignorance in one post!
thanks
htctoucher
Click to expand...
Click to collapse
I'm not quite sure what you are after with this CAB you ask for. If you are looking for TF3D for QVGA, a CAB is available (but there are still some issues with the required 3D drivers for the QVGA devices).
The modifed TF3D executable files work fine on QVGA with the original graphics. This thread however explains the method to do pixel-perfect TF3D image manipulation (for themers, porters, etc) in general, which was up until the documentation of this thread impossible (read: unknown). Methods like using Manila Editor work, but degrade image quality significantly more than the method described here.
However, this thread also documents converting the (originally) VGA TF3D images to the corresponding QVGA sizes, and even adding an extra 5x compression to them. This is not necessary to do if you have the modified TF3D executables for QVGA (it will use the VGA graphics files just fine), however, it certainly makes TF3D a hell of a lot faster and significantly reduces the size it requires on disk and the memory use (both of which are more limited on the QVGA devices compared to the VGA ones). It includes this information because this method was 'discovered' in the process of porting TF3D to run on QVGA devices. Similarly, porting existing TF3D VGA themes to QVGA resolutions will increase the speed of TF3D on QVGA devices over using the original theme's VGA graphics files.
Note that the TF3D-QVGA CAB ( http://www.htcclassaction.org/download/TF3D-QVGA.cab ) already includes the optimized QVGA graphics, and some of them were even retouched by hand (not mentioned in this threaD).
I hope this explains what you want to know
Hi I have managed to convert a manila file to ATC format using cfc.exe but now I cant open it using The Compressonator. If I go to open (there is no ATC file type listed in 'Files of type' drop down menu), select All Files (*.*) and try to open the converted .atc file, it does not load. I am using The Compressonator 1.50 which seems to have been updated recently (18-12-08) so it might be an issue with the new version. If it is that can you please upload or direct me to the old version or else if I am doing something wrong, please help.
Thank you
AF241
Related
Could you explain please (very short description) how you modified the xip chain for rom kitchen?
All I can see is the following:
- no length (0)
- no RSA1 signature
- only file entries
What I want to know:
- how to find phys. (ROM) position (do you use unused holes in rom?)
- is 0 length for ROM = autolength
- how to choose the RAM position
- why can length of RAM be 0
Please help. (I need this info for a smartphone project)
I did not bother setting the length, only the 'pvAddr' field is used.
I only make fileentries, because I have yet to implement the generation of modules. ( if I ever do ).
yes, I use unused holes in the rom.
actually, if you don't care about xip updates of other sections, you
may use addresses anywhere in the rom, where your data fits.
It does not nescesarily have to be contigous.
I just copied the ram setting from the other xip entries.
Thank you for the information.
Why don't you take romimage.exe from platformbuilder to generate a XIP block. You only have to write a little .bib file for it. This tool can handle modules and compression as well.
John
P.S. Source code for romimage.exe is available in PB 4.2 private build tree.
I hadn't found that tool yet when I wrote makexip, and then we couldn't have made the romkitchen with it, since romimage.exe runs only under windows.
Don't waste your time with this crap tool (romimage.exe). Some needed files are missing (e.g. bin2xip.exe).
How can I be sure to choose a good phys. addr.? There might be some memory mapped devices...
I have one additional difficult question:
Modules are relocated when embedded into XIP's. Even there seems to be a modification to the import table of the module (e.g. references to coredll.dll will be checked/updated?)
If I extract a module (e.g. a *.dll) from a XIP of an other phone do I have to re-relocate it / modify it's import section even if I place it in a FILES section?
Thanks
John
converting bin to xip is not that difficult. see http://www.xs4all.nl/~itsme/projects/xda/wince-flashfile-formats.html
do you mean the 'physfirst' field in the romheader? that is just the startaddress in the rom.
since the relocation information is not stored in rom, the only way to really
recover it, is to disassemble the file, and find the offsets to stuff that
needs to be reallocated.
so that is a lot of work. and dumprom only extracts nonrelocatable .exe and .dll modules.
if your extracted dll is fixed to a memory location that overlaps with an already existing dll, you will have a problem I think.
I am not even sure, if an extracted dll works at all, I only use them for reverse engineering.
Yes, I mean phys first field. But how can I be sure to choose a valid address for the new XIP block?. My idea is to use address space between existing XIP blocks. Or can I simply choose a very high address (e.g. 8F000000) and hope not to use a region where memory mapped devices are located?
Since I used (your?) dumprom to extract the *.dll files do you think they are "nonrelocated"?
John
I ask so much because I crashed my lovely smartphone a week ago. :-(
My new XIP seems to be invalid... so it doesn't boot anymore. Unfortunately I've killed the bootloader too...
When I try next time (I've ordered a new one) this must not happen!
I am sure they are nonrelocated, fixed to run from a specific memory location.
( just wrote another post about this )
maybe even the module loader does not allow non-xip modules to be loaded in xip reserved memory.
THANK YOU VERY MUCH
I've got it. My Smartphone now have a new XIP block with some files in it...
Only thing left is to rewrite some *.dll files (only resource dlls with no function exports) to extend the language of the MIO 8380.
Are you familiar with languages on smartphone? There are multiple .mui files (resource dlls containing all the dialogs and strings). I've exported all resources and (re)created the dll's as resource only. Unfortunately they don't work ... yet ...
Are there some other files for language extension? What about "wince.nls" or "mxip_lang.vol" ?
Thanks again for your great tools. I will setup a site containing detailed information about this hack soon.
John Smith
cool, I am always interested to see how things work out that I haven't actually tried myself yet.
is this how you create resource only dll's:
http://www.xs4all.nl/~itsme/projects/programming/icondll.html
Currently I'am a little bit confused. PB 4.2 docu says MUIs are resource only .dlls and sample in smartphone sdk adds a dllmain...
I will have to investigate this things a little bit more...
John
O.K.
I've tried anything. The only thing left is that the new resource dlls are not XIPed as modules...
The sample mui app works fine (regardless of resource only / normal dll).
John
P.S. I've successfully changed all other settings some things already appear in the new language. Only poutlook, homescreen and control panel will not change!
Now after some more testing (included a dllmain into the mui file which logs the loading/unloading to file) it seems that my mui.dll is never loaded by system (if I load it manually with LoadLibrary the log is written).
Here is my question:
I've looked a little bit deeper into the dumped mui.dll and found a pointer in security section (pe header) which points to nowhere (just after the [virtual] end [rva] of all of the e32/o32 sections).
Could it be, that I've missed something? Does dumprom fill in this values correctly?
One other interesting idea could be to exchange only the data section of the module (since I want to patch resource only .dlls). But since english is a very short term language all other files will be bigger...
John
>>> I've got it <<<
the new (mui-language) modules have to be REAL xip modules...
So I've build a custom.bib file and used RomImage from CE3.0 Platformbuilder. Even compression is possible now.
Note: romimage.exe does the same thing as makexip.pl
To share my results here is the content of the .bib file I've used:
Code:
MEMORY
; Name Address Size Type
MYXIP 81f00000 0013f000 RAMIMAGE
RAM 8c020000 00fe0000 RAM
CONFIG
COMPRESSION = ON
PROFILE = OFF
ROMFLAGS = 2
ROMSTART=81f00000
ROMSIZE=13f000
ROMWIDTH=32
DLLHIGHADDR=00b00000
MODULES
; Name Path Memory Type
; ------------------------- ------------------------------- ------ ----
outres.dll.0407.mui input\outres.dll.0407.mui MYXIP SHU
syncres.dll.0407.mui input\syncres.dll.0407.mui MYXIP SHU
tapres.dll.0407.mui input\tapres.dll.0407.mui MYXIP SHU
tshres.dll.0407.mui input\tshres.dll.0407.mui MYXIP SHU
wmplayer.exe.0407.mui input\wmplayer.exe.0407.mui MYXIP SHU
FILES
; Name Path Memory Type
; ------------------------- ------------------------------- ------ ----
Busy.0407.mid input\Busy.0407.mid MYXIP
mxip_lang_799.rgu input\mxip_lang_799.rgu MYXIP
ms_splash.gif input\ms_splash.gif MYXIP
carrier_splash.gif input\carrier_splash.gif MYXIP
- The MYXIP region in MEMORY section is a hole in the ROM I've found with calcgaps.pl.
- The RAM region is copied from the other sections (they all use the same)
- ROMSTART and ROMSIZE have to be the same values as defined in MYXIP
- DLLHIGHADDR has to be the !!!lowest!!! loading address found with dumprom (header: dlls=...-... ).
Example: If the lowest address found is "header: dlls=00b00000-00c90000 ..." then DLLHIGHADDR has to be 00b00000
Don't care about the warning the warning "Unable to do imports from ... to COREDLL.dll - will late bind". Thats because coredll is in another XIP.
John
P.S. Thanks a lot for all of your support.
DETAILED INFORMATION ABOUT THIS HACK CAN BE FOUND HERE:
http://smartphonerom.tripod.com (only download the "detailed information")
Special Thanks
Abusalza (for the most initial start off guide)
Cmonex (for the “MOST” important finishing touches)
!Aman! (for all the testing and Hex edit helping)
Noonski (for being the inspiration to keep going )
Ervius (for developing the kitchen tool to perform all the operations)
In this forum there are many many tools from experts and likes for porting XIP, rebuilding dumped ROMs etc. This threads aims at showing or sharing what goes in the background of these automated tools and also aims at answering all the many unanswered questions about various factors of ROM cooking / editing I have come across in this forum
Suggestions / comments always welcome to make these tutorials even better
Index of Tutorials
Manual XIP Porting Guide: CLICK HERE
XIP Porting Updates from members: CLICK HERE
XIP Porting for Himalaya devices & others (Nokser): CLICK HERE
Misc XIP Updates: CLICK HERE
PagePool Changing Guide (for Diamond & Raphael): CLICK HERE
Gain More Storage Memory (Increase imgfs size) Guide: CLICK HERE
ULDR Partition Size Reduction Guide: CLICK HERE
MBR and MSFLSH50 Regions Screenshots: CLICK HERE
Gain More Storage Memory (compress imgfs) with LZX algorithm: CLICK HERE
Get High File System Index (!Aman!): CLICK HERE
Ervius's GUI kitchen thread to perform all operations, Noonski's amazing RunCC & AutoRun & SDAutorun tutorial thread
Ervius's post on patching nk.exe to change the EndRam address for more available RAM in device (original credits to cmonex )
Da_G's amazing new initiative to utilise the ULDR partition to upgrade ROM without re-flash
All the above guides and updates are compiled in pdf file also for offline reading, attached in this post as All Guides.zip
The imgfs Gain.zip is actually the 5th guide with pictorial seperatly put up for members who would want to refer only to that process
The Pictorial.zip is the 7th picture reference for offline reading
Donations for this hard work and research are much appreciated. Below are the links whom you may choose to provide those to
Donation to Abusalza, Donation to Cmonex, Donation to !Aman!, Donation to Ameet
Index of Threads (Manila related)
Ameet's Mode9 script editing ideas thread
l3v5y's tutorial thread for editing Manila files
NisseDILLIGAF's Manila Hash tool
Manual Full XIP Porting
Tools you need: (attached the tools in this thread for easy access)
HEX Calculator (recommended – HEX workshop (Not Free)), suggested Windows Calculator
XIPPort.exe
M’Reloc.exe
NBMerge.exe
Insert.exe
OS.nb.payload from 19965 build (shipped ROM)
Cup of nice strong Coffee (A Must)
Brief:
There are many different ways to port the XIP. Few mention of using the 723*.dsm for the build number, few others mention of using the coredll.dll module to have the latest build numbers. As my friends, Noonski and !Aman! always say “Only numbers are just eye wash, core system is what matters the most” Based on this as inspiration, I am posting this guide for manual XIP porting. A few places you may find colors in this guide, these are to visually link the data for easy understanding
The only files removed from the ported XIP are (these are removed to keep the new XIP within the original size):
osaxst0.dll + osaxst0.dll.imageinfo.txt
hd.dll + hd.dll.imageinfo.txt
bmui.nb0 + bmui.nb0.imageinfo.txt
Process:
Prepare OEMXip base
Dump your original XIP.bin (from 19965 build) with XIPPort.exe, and click “write maps” to get MAP.txt in the OUT folder
Open the MAP.txt and go through what you will need to achieve for a full port. I advice to keep this MAP.txt as a backup, just in case
Click “make pkgs” to get “OEMXipKernel” and “MSXipKernel” folders inside \Files and \Modules
Delete MSXipKernel folders from \Files and \Modules both
Now our base OUT folder is ready with OEMXipKernel
Prepare MSXip donor
Dump your donor XIP.bin (from 20758 build) with XIPPort.exe, and click “make pkgs” to get “MSXipKernel” folder inside \Files and \Modules
Delete osaxst0.dll + osaxst0.dll.imageinfo.txt, hd.dll + hd.dll.imageinfo.txt and bmui.nb0 + bmui.nb0.imageinfo.txt to get the new XIP within the original RAM size. If you don’t wish to delete these files, then you will need to increase the “physlast” in ROMHDR.txt. Process of which is not covered under this guide
Copy the MSXipKernel folders from \Files and \Modules both to the \Files and \Modules in the base OUT folder
Now our OUT folder is ready to be ported with the OEMXipKernel and MSXipKernel
Now to proceed with the reallocing you need to re open the packages which have been created. Open XIPPort.exe and click "undo" then click “realloc P” to re calculate the reallocation addresses. Then click “write maps” to get the new MAP.txt file
Open this MAP.txt and look in the o32_realaddr and e32_vbase addresses. Busenum.dll must be the last entry in both tables. Here you may find overlaps of the modules in a few or most places (seen as !!!!!!!!!!!!!!!!!!)
These are the overlaps which need to be taken care of by reallocating the modules in Initialized Data and Virtual Base addresses
You need to work our way up from the bottom of the list since the busenum.dll is reallocated at the last address of the memory
For example:
03f4c000 03fe3000 L00097000 Virtual base address of coredll.dll
03fe2000 03fe3000 L00001000 !!!!!!!!!!!!!!!!!!
03fe2000 03ff0000 L0000e000 Virtual base address of certmod.dll
03ff0000 03ffb000 L0000b000 Virtual base address of cachefilt.dll
03ffa000 03ffb000 L00001000 !!!!!!!!!!!!!!!!!!
03ffa000 04000000 L00006000 Virtual base address of busenum.dll
Meaning, e32_vbase address of cachefilt.dll is overlapping that of busenum.dll by 1000 (L00001000) Similarly e32_vbase address of coredll.dll is overlapping that of certmod.dll by 1000 (L00001000)
I recommend you use M’Reloc.exe for reallocating the addresses in imageinfo.bin and Notepad to reallocate the addresses in the corresponding imageinfo.txt files. Since the binaries (S000, S001...) must actually be relocated using M'Reloc, it is not enough to just adjust the values in the imageinfo.txt files
To calculate the revised addresses (in below example, the e32_vbase) of the overlapping module, open Hex Calculator. To do that you will need to know the e32_vsize of the overlapped module. To find that out open overlapped module (for e.g. cachefilt.dll) in M’Reloc.exe and see the e32_vsize (0000B000)
Now to correct the e32_vbase of cachefilt.dll, follow this calculation as a base (e32_vbase busenum.dll - e32_vsize cachefilt.dll = e32_vbase cachefilt.dll)
Meaning, (03FFA000 – B000 = 03FEF000) hence the correct e32_vbase address is 03FEF000
03ff0000 03ffb000 L0000b000 Virtual base address of cachefilt.dll
03ffa000 03ffb000 L00001000 !!!!!!!!!!!!!!!!!!
03ffa000 04000000 L00006000 Virtual base address of busenum.dll
Now since the cachefilt.dll is reallocated using the above calculation, the modules next in line above that will also have to be reallocated. Namely, certmod.dll (although not overlapping yet above the cachefilt.dll). To calculate the e32_vbase of certmod.dll you will need the revised e32_vbase address of cachefilt.dll which you got just now
I recommend writing down the e32_vbase, e32_vsize, o32_realaddr and o32_vsize of each module so it will be easier to calculate the correct addresses for reallocation)
Remember, you need to work our way up from the bottom of the list since the busenum.dll is reallocated at the last address of the memory
To reallocate the addresses for o32_realaddr, follow the above calculation, only this time replace the e32_vbase busenum.dll with o32_realaddr and e32_vsize with o32_vsize
Now open the corresponding imageinfo.txt file for each module and change the e32_vbase and o32_realaddr address values in the txt file of the values mentioned with V= and D=, seen for e.g. like this
Module name: cachefilt.dll
e32_vbase: V=03FEF000
o32[1].o32_realaddr: D=01FFE000
You will notice that the FLASHDRV.DLL module has the realaddr at 2 regions. Although I have not found a way to calculate the difference between both regions but I change the values as per Abusalza’s MAP.txt
o32[1].o32_realaddr: D=01FCC000
o32[3].o32_realaddr: D=01FD4000
Since the OEMXipKernel modules never change, I only correct values of the ported MSXipKernel modules
This is helpful if the MSXipKernel modules ported from donor ROMs are similar in the sizes. If not then you will need to do the calculation and correction of values
Once through with the address reallocation, open XIPPort.exe and click “realloc P” to re calculate the addresses for writing maps. It will show you errors regarding some regions, ignore those and click “write maps”. Open the new MAP.txt and recheck for (!!!!!!!!!!!!!!!!!!) If none found that means the XIP has been ported well
Now click “build xip_out.bin” to create the resulting XIP to be inserted into the ROM .payload file. Use this command for inserting the xip_out.bin into the .payload (presuming you already have the shipped OS.nb.payload file in the same working folder
insert.exe -i xip_out.bin -o OS.nb.payload -d 0x00320000 -s 0x004C0000
Check these values with your device imgfs since in Diamond the XIP starts at 0x00320000 and the imgfs starts at 0x007A0000, but for some reason the imgfs signature in Diamond is at 0x007E0000
Build OS.nb for use in the ROM folder from the .payload you just updated with the new XIP. Please note these commands are for Diamond device. Please check with your device on the same before building
nbmerge.exe –kaiser OS.nb
Now put this OS.nb file in the ROM, put the boot.rgu from 19965 (shipped ROM) into the \ROM\XIP folder and do not include any of the OEMXipKernel or MSXipKernel folders in OEM & SYS folder while cooking. I observed for some reason, WinCeNls_WWE folder cannot be taken out of XIP and included in SYS. Device wont boot, so keep that in XIP (found a working solution by spocky12: Here (last quote)
Please note the insertion of xip_out.bin can also be done through XIPPort.exe directly
Before clicking “write xip_out.bin to:” replace the name “nk.nb” with “OS.nb.payload” and the address to “00320000” all without quotes
IMP: There may be chances that although the XIP is working fine, but the windows are seen as QVGA versions. The solution to that is either of the below
XIP & SYS of the same builds or
XIP and the OS\Gwes.exe from same build
Cook the new ROM with your favorite kitchen (whichever doesn’t do anything with the XIP) and use this OS.nb file as base template for the ROM with the new XIP
With this note, I hope this guide will serve many as a guiding light and answer many questions on manual full XIP porting. Happy porting
Members Porting Updates
This is where we showcase the updates on XIP porting provided by our kind forum members
Original quote - Cmonex
Code:
[COLOR=royalblue][B]Quote=ababrekar[/B] - Busenum.dll must be the last entry in both tables[/COLOR]
Actually the values are arbitary, even though Microsoft decided to place coredll.dll as the last entry, i.e. at the highest memory address, it doesn't really matter. So, the values are arbitrary, but of course only within limits: the addresses must be divisible by 0x1000 (pagesize of the platform), and they must be inside the memory range reserved for XIP. part of that is the dllfirst and dlllast values in ROMHDR.txt. The other part (the higher addresses, 0x03xxxxxx) are determined by the following way: IMGFS .VM tells you the limits for IMGFS memory range, and XIP is beyond that range. So, if your OS doesn't want to boot, you can check if IMGFS .VM is overlapping with XIP memory range as per your MAP.txt for xip and dump_memorymap.txt (or .VM folder, etc) for IMGFS.
For example if IMGFS ends at 0x03DE0000, then the higher part of your XIP must start later than 0x03DE0000. You can of course modify this to make more space for XIP
If xipport crashes on writing maps it means you definitely have some overlaps left in. So yes, best to work with the maps from the original XIPs and only use the final XIP map to verify you got everything right
[COLOR=red]Btw, XIPPort's insertion function was found buggy on one device once, but cannot remember the details. It wasn't my device, so just posting this as a possible warning[/COLOR]
Oh, same applies to ROMMaster.exe, it is buggy when you try to use that to extract the XIP some ROMs
[COLOR=royalblue][B]Quote=ababrekar[/B] - Few mention of using the 723*.dsm for the build number, few others mention of using the coredll.dll module to have the latest build numbers[/COLOR]
Btw, coredll.dll replacement only works for that pre-WM6.1
And a last tip for [B]debugging [/B]if your OS doesn't want to boot: if you already checked that the maps are all ok and IMGFS doesn't overlap, etc., then if you have a new enough HTC device (for example HTC Athena and later is new enough), then go to SPL using mtty or putty or qmat and there the "task 37" command (without the quotes) will show KITL log, with lots of debug messages, that can be very helpful. (first you must issue "task 32", for "task 37" to work) - this doesn't appear to work on some Raphaels
Original quote - cruzzmz
Code:
If porting for [B][COLOR=teal]Zinc[/COLOR][/B]. After finish with all the MReloc, you need to Hex the S000 of nk.exe in the MODULES folder. The value can be found in MAP.TXT under the Modules
[COLOR=royalblue][B]Quote=ababrekar[/B] - 802FAA9C - 802faaf0 L00000054 rom_00 header: dlls=01f901fd-02000000 phys=80180000-803dc4fa, 24 modules, 10 files, 2 copyentries ext=8018265c ram=803dd000-83c00000 cputype=000001c2[/COLOR]
Open S000 in ur fav hex editor, then go to [B]Offset 1658[/B]
Change the original value i.e: [COLOR=red][B]802FAA9C [/B][/COLOR]and Hex edit it to [COLOR=blue][B]9CAA2F80[/B][/COLOR]
Original quote - DupinBJK
Code:
The addresses on the 80xxxxxx range should be on a [B]WORD [/B]boundary - Divisible by [B]4[/B]
Original quote - spocky12 (how to move wincenls to IMGF from XIP)
Code:
This is related to BootPhase key in boot.rgu. [URL="http://msdn.microsoft.com/en-us/library/ms885267.aspx"]According to Microsoft[/URL]
If this value is 0, then related filesystem is loaded prior to initialization of locale. But for this to work, the filesystem has to be loaded in Autoload key, like this :
[B][COLOR=red][HKEY_LOCAL_MACHINE\System\StorageManager\AutoLoad\FLASHDRV][/COLOR][/B]
[B][COLOR=red] "DriverPath"="Drivers\\BuiltIn\\FLASHDRV"[/COLOR][/B]
[B][COLOR=red] "LoadFlags"=dword:1[/COLOR][/B]
[B][COLOR=red] "Order"=dword:0[/COLOR][/B]
[B][COLOR=red] "MountAsRoot"=dword:1[/COLOR][/B]
[B][COLOR=red] "MountAsBootable"=dword:1[/COLOR][/B]
[B][COLOR=red] "BootPhase"=dword:0[/COLOR][/B]
With this, autoload will regsiter access to the imgfs filesystem before wince.nls is loaded. Then, when it'll be required, if it's not present in xip, it should be found in imgfs
Here is where we showcase miscellanous updates on XIP porting / MBR / MSFLSH50 which doesnt fall under the above categories. These are the updates which are not harming the system in any ways if left as is. Yet just a know how or just in case
Removing modules from XIP: Original quote - Cmonex
Code:
You can always remove osaxst0.dll, osaxst1.dll, hd.dll, kd.dll, and also bmui.nb0 - the latter is just a SplashScreen saying your OS can't boot and reflash or something (I forget the exact text)
The other files are Kernel debuggers and similar, best to remove them, because it just takes up space and can also cause problems if you somehow manage to use the wrong versions of them. They are mapped directly to the Kernel memory space, and if your device uses a different range (i.e. you didn't keep your original debugger dlls), it will prevent the rom from booting
Also I found it's ok to remove (m)encfilt.dll and cachefilt (put them in IMGFS if you want them)
[I][B]Physlast [/B][/I]can be changed up to [I]ulramstart [/I]value without problems (of course not if you don't have enough space in the flash, but that's not really a real life possibility). Of course that also assumes we are not talking about some older devices that have the xip mapped to a different memory range than [I]ulramstart[/I]
You can move [I]ulramstart/ulramfree [/I]too if you relocate nk.exe data section (usually S002) with M'Reloc-nk. Also relocation is needed for any other modules (such as giisr.dll, on some non HTC devices) that have mappings similar to nk.exe (so they have a data section in the map that points into [I]ulramstart/ulramfree [/I]range). on HTC devices I didn't really see such modules so not a real problem usually
Increasing the free RAM (Part 1): Detailed explanation here by DupinBJK
Simple explaination for easy understanding: (the below values are from a sample MAP.txt and dump_memoryMaps.txt (View attachment Examples.zip)) for trying to explain what comes from where and the actual values may differ from your files
Code:
8019e9a4 - 8019e9f8 L00000054 rom_00 header: dlls=[COLOR=red]01f801fc[/COLOR]-[COLOR=black]02000000[/COLOR] phys=[COLOR=black]80000000[/COLOR]-[COLOR=blue]8030c7b3[/COLOR], 28 modules, 10 files, 1 copyentries ext=80002b4c ram=8030d000-83000000 cputype=000001c2
[COLOR=blue]8030c7b3 [/COLOR]- 8030c7b3 L00000000 End: highest physical address
The blue value that mentioned is the physlast value. In the dump_memoryMaps.txt, you will find:
Code:
01F7F000 - 01F7FFFF (4095 bytes): bthasplugin.dll
after which the dllfirst starts in MAP.txt with a difference of 1FD length and
Code:
03D66000 - 03D6FFFF (40959 bytes): bthasplugin.dll
after which the e32_vbase starts (03dcb000 - 03dd4000 L00009000 Virtual base address of wce_rex.DLL) in MAP.txt with a difference of 5B001 length
Increasing the free RAM (Part 2): by Ameet
Changed the size of ROM in G'Reloc from 83000000 to 83400000 and increased the ulRAMEnd to the same value (83400000) getting free RAM space of L0306C000 (I dont know how to translate this into the actual size in % or in bytes) but with the original of 83000000 the RAM space was L02C6C000
Having done this, I get about 62% free memory without TF3D and approx 54% free memory with TF3D at system start
Extracting the XIP from any ROM: Detailed explanation here by boggsie
More explaination about XIP processes & editing OS version on 1st splash screen: by FormerPalmOS
Code:
[B][COLOR=red]1) [/COLOR][/B]The Initial Program Loader copies the XIP partition from the FLASH to SRAM - in Diamond and Touch Pro there is a custom Samsung chip that includes both NAND FLASH and SRAM. The overall physical RAM space where this is loaded is also hard-coded - see below. The amount of RAM used is variable - this info comes from a header in the XIP section - basically how much RAM does the XIP need? What's left is what you get for program memory.
[B][COLOR=red]2) [/COLOR][/B]IPL executes a jump to a hard-coded address within the SRAM - this should be busenum.dll, which is why busenum.dll has to be at a specific physical and virtual memory location.
[COLOR=red][B]3) [/B][/COLOR]busenum.dll does its thing (not sure entirely what) but eventually calls nk.exe. nk.exe is the kernel. nk.exe loads the other modules, initializes the hardware (that's why nk.exe is device-specific), and initializes the filesystem and basic device drivers (again why those are device-specific).
[COLOR=red][B]4) [/B][/COLOR]Once this process has completed, the filesystem proceeds to load the imgfs filesystem and turn control over to the full OS.
The virtual memory map for WM consists of a number of slots. The memory management unit in the CPU translates virtual memory references into physical memory addresses. Every loaded dll or exe must occupy a portion of virtual memory for its code and will likely also use some of the available RAM for its data. The location within virtual memory where the code for a dll or exe is loaded is determined at load time unless the dll or exe is a module (everything in the XIP is a module) in which case the virtual memory location is specified during cooking. In the XIP, the location of the RAM used is also specified - the process of relocating a module in the XIP specifies the virtual memory location for the code and and data in the case of nk.exe, the physical RAM location.
There are four VM sections we care about (note - I'm taking some liberty here - these don't exactly correspond with what Microsoft refers to as a VM slot). Slot 0 runs from 0x00000000 to 0x01FC0000 (in the CDMA Touch Pro). The end of slot 0 is a function of the number of and size of the data regions for the DLL modules in the XIP. This number plus 0x1FC is stored in the ROM header (and can be examined in ROMHRD.txt) - it is referred to as dllfirst. This is also the slot 0 you see when you do G'Reloc.exe (the value in G'Reloc.exe is the last address of slot 0 plus one). These two must match!!! What the XIP uses must not overlap with what your ROM uses.
The next slot is the XIP DLL initialized data. This runs from dllfirst to dlllast. dlllast is fixed (in the Touch pro) at 0x02000000. The XIP DLL data sections are loaded starting at 0x02000000 and working backwards.
The next slot is again available for the OS and runs from dlllast to wherever the code in the XIP starts. You can see this in your XIP memory map - this again must match (the end of slot 1 in G'reloc.exe must match the first DLL virtual base address in your XIP - in mine this is 0x03DC0000). The XIP DLL and EXE code occupies from this virtual memory address to 0x03FFFFFF.
The OS will load DLLs and EXEs (other than XIP) into this slot starting at 0x03DC0000 and working backwards, then will move to the slot below 0x01FC0000. Recall, I'm using my numbers here. Any modules in the ROM will have their virtual memory slot and address pre-assigned. Any non-module DLL or EXE will be relocated to an available slot and VM address at load (this is why modules load quicker).
So in summary, my VM map looks like this:
0x00000000 - 0x01FC0000 - OS available (G'Reloc.exe slot 0)
0x01FC0000 - 0x01FFFFFF - XIP data
0x02000000 - 0x03DC0000 - OS available (G'Reloc.exe slot 1)
0x03DC0000 - 0x3FFFFFFF - XIP modules code
The actual physical XIP RAM address starts at 0x80000000 in the Touch Pro (this is physfirst in the ROMHDR.txt) and ends at 0x83400000 (in the Verizon Touch Pro - this is ulRAMEnd). The XIP is copied from the NAND flash starting here with the ROM header occupying 0x80000000 - 0x80001000. Then come the various XIP components, hopefully none of which overlap. The XIP should end at or before a ROMHDR.txt value called physlast. Thus physlast - physfirst is the size your XIP has to fit into.
Following physlast comes ulRAMStart - this is where the RAM required for nk.exe is located. This RAM ends at ulRAMFree. What remains after ulRAMFree until ulRAMEnd is available for your OS. Shrinking your XIP and relocating nk.exe will allow you to recover wasted space and give you more program memory, but it buys you nothing to move a module out of the XIP if it is required by the system. Only things that aren't required (like debuggers and hard drive drivers) should be removed.
Also, the least significant 16 bits must be zero (lower four hex digits) of the end of vm slot 0 and slot 1 in G'reloc.exe and in your ROMHDR.txt. The least significant 14 bits must be zero (the lower four digits can only be 0000, 4000, 8000 or C000) of the RAM address (ulRAMStart and ulRAMFree).
Code:
Hex edit the S000 file in the nk.exe module folder and search for the revision string. You can find it by doing a search for the unicode string "[B][COLOR=red]Kernel Built[/COLOR][/B]" (Hex String [B][COLOR=red]4B 00 65 00 72 00 6E 00 65 00 6C 00 20 00 42 00 75 00 69 00 6C 00 74 00[/COLOR][/B]). Shortly after that will be the revision that is displayed on the phase 1 boot screen (small red letters in the lower right corner of the device on CDMA Touch Pro). Change that (make sure to overwrite, not to insert, and limit it to 12 characters in unicode format.
When you rebuild your xip.bin and cook with it, you should see this value on the screen during phase 1 boot. The only other way would be to insert a marker into the boot registry
Change PagePool through Hex editing (for Diamond & Raphael)
I'm putting this up here so to answer one more unanswered question about this especially for Diamond & Raphael ROMs
To change PP of Diamond ROMs:
Open the OS.nb in Hex editing software
1. Go to offset 0x37AD68 to find 03 25 A0 E3 03 15 A0 E3 00 20 83 E5 hex string (If this string is not found at the 37AD68 offset, then search for this hex string)
Replace the string with 20 83 E5 with 00 A0 E1
This will make the string NOP (No Operation) meaning, the ROM wont set the PP to default 12MB but will allow the change in below offset
2. Now go to offset 0x3A7F94 to find E0 E2 04 80 00 00 60 00 hex string
again, if this hex string not found at the 3A7F94 offset, then search for the hex string. Just as a hint, this string is after the second NKKD8 (search for text string)
60 is the size of PP that you can now modify to suit your liking
e.g. I made mine 00 to get 0MB PP. Or change it to 80 to get 8MB PP, so forth and so on
With changing the first hex string and making the Kernel NOP, you can also use the tool to change PagePool and it does work
Also to make it a permanent change you can hex edit the first mentioned string in S000 of nk.exe module in XIP and then modify the PP with the program or by hex on OS.nb
To change PP of Raphael ROMs:
Search for hex string: 03 15 A0 03 02 15 A0 13 00 10 82 E5 and change the last 4 bytes to 03 15 A0 03 02 15 A0 13 00 00 A0 E1 then the normal PP Changer tool will work
This is the 2nd string, ignore the 1st one coz that's in ULDR
Gain more Storage Memory (increase imgfs size)
There are 4 partitions in Diamond ROMs
part00 – ULDR
part01 – XIP
part02 – IMGFS
part03 – FAT (This partition exists only on few devices)
We all port XIP from different devices to exclude few modules to gain space and to upgrade the kernel and make the XIP partition smaller in size. Although the new XIP is smaller in size but because of the insertion addresses of XIP & imgfs, there is a gap of wasted space filled with FF between end of XIP & start of imgfs. Although there is no way we can include this space into XIP as free RAM but make use of this space in imgfs and gain whatever storage space we can
Files used as example for this tutorial
xip_out.bin: My own ported XIP of size (30CA12 in Hex, 3195154 in bytes)
os.nb.payload: My own cooked payload (since I also wanted the final ROM to be a cleaner ROM)
imgfs start: in my payload at 0x7A0000 (unedited)
XIP start: in my payload at 0x320000 (unedited)
Before we move into hex editing, let me give an overall outlook of the MBR & MSFLSH regions of the ROM
MBR is the Master Boot Record of the ROM (512 bytes) from 0x0 to 0x1FF. The infomation of partitions types Flags in hex offsets are called from the registry entry mentioned in boot.rgu below
The starting block (LBA) and number of sectors for each partition are defined as shown below
part00. 1C6 – 1C9 (starting block) 1CA – 1CD (number of sectors)
part01. 1D6 – 1D9 (starting block) 1DA – 1DD (number of sectors)
part02. 1E6 – 1E9 (starting block) 1EA – 1ED (number of sectors)
part03. 1F6 – 1F9 (starting block) 1FA – 1FD (number of sectors)
[HKEY_LOCAL_MACHINE\System\StorageManager\PartitionTable]
"04"="FATFS" ; (hex: 1F2)
"20"="BOOT" ; (hex: 1C2)
"23"="RAWFS" ; (hex: 1D2)
"25"="IMGFS" ; (hex: 1E2)
MSFLSH50 is the Flash region of imgfs from 0x800 (see post #8 for screenshots, shown here is for Diamond) to 0xFFF. The starting block of imgfs is located in MSFLSH at 81C
e.g. if your device ROM's sector size is 200 then the MSFLSH50 region will starts at 0x200 and so on
Moving into the hex editing mode for making use of the wasted space between the actual XIP end & start of imgfs partitions
The new xip_out.bin is 30CA12 in total size (check your actual xip_out.bin size, shown here is just example) starting at 0x320000 (check you device XIP start, shown here is for Diamond) and ideally should end at 62CA12. But since the starting block of imgfs must be divisible by 20000 (see post #8 for screenshots, shown here is for Diamond) the imgfs needs to start at 640000. So the new XIP will have to be inserted into the payload at 0x320000 till 0x640000 with XIP size of 320000 and reduced wastage of 135EE bytes
The imgfs can also start at 630000 since this is directly after the XIP and also divisible by 20000, used here is 640000 as expansion for future xip_out.bin
Open the existing os.nb.payload in hex editor. Delete everything from 0x640000 till 0x79FFFF. This will move the imgfs from 0x7A0000 to 0x640000. Since we are now moving the imgfs partition next to new XIP, the number of sectors in new XIP and new LBA of imgfs needs to be edited to the revised value in the MBR region
To calculate the new starting block of imgfs partition we need the number of sectors in new XIP. To calculate that, use the following method
In Hex calc
Number of sectors = size of partition / sector size
e.g. (new XIP) 320000 (shown above) / 800 (see post #8 for screenshots, shown here is for Diamond) = 0640
since the coding is in little endian, we have to reverse these values to 40 06 00 00
Go to offset 0x1DA and change the values to 40 06 till 1DB and then 00 00
Now realloc the LBA of imgfs since we revised the number of sectors in XIP and to calculate that, use this method
In Hex calc
Logical Block Address (LBA) = Previous Partition LBA + Previous Partition number of sectors
e.g. (XIP LBA) 0640 + (XIP no of sectors) 0640 = 0C80
since the coding is in little endian, we have to reverse these values to 80 0C 00 00
Go to offset 0x1E6 and change the values to 80 0C till 1E7 and then 00 00
Logical Block Address (LBA) should be equal to (Previous Partition LBA + Previous Partition number of sectors * Sector Size)
e.g. (XIP LBA) 0640 + (XIP no of sectors) 0640 * 800 (see post #8 for screenshots, shown here is for Diamond) = 640000 (size of imgfs partition)
Similarly to imgfs calculate and change the LBA of FAT at 1F6 and 1F7 using the default imgfs no of sectors (use these since the cooking tools will change these as per actual size)
We have changed the LBA and number of sectors in MBR, but the OS needs to know the block address of imgfs in MSFLSH50 region
To calculate that, use this method
In Hex calc
MSFLSH50 Block Address = imgfs partition starting address / 20000 (see post #8 for screenshots, shown here is for Diamond)
e.g. (imgfs starting address) 640000 (shown above) / 20000 = 32
Go to offset 0x81C and change the value to 32
Save and close the os.nb.payload file in hex editor. Insert the new XIP into this file using this command
“insert.exe -i xip_out.bin -o OS.nb.payload -d 0x00320000 -s 0x00320000” (check your insert start address, shown here is for Diamond)
To calculate the size of XIP from MBR, use this method
In Hex calc
Size of XIP = Number of Sectors * Sector Size
e.g. (if the no of sectors in little endian) 0640 (shown above) * 800 (see post #8 for screenshots, shown here is for Diamond) = 320000 (sector size for diamonds)
This value shall be the "-s" while using insert.exe tool and to calculate the start of the XIP, use this method
In Hex calc
XIP Start = imgfs Start + "-s"
Reduce ULDR Partition Size
“ULDR” stands for “Update Loader”, and is part of the Image Update system. This system allows deployed devices to be updated with new software after they ship. The Update Loader reads a configuration stored in persistent memory and downloads and installs new versions of operating system or OEM files
Also known as part00 in the ROM, is something we all wish to get rid of and use the space as additional storage memory. This tutorial currently aims at reducing the size of this partition by 3.0 MB
Tools you need
NBSplit.exe
NBMerge.exe
Hex editor
Ervius's Payload Reducer
IMPORTANT NOTES
The template OS.nb used is the same OS.nb in which the XIP is inserted at 320000 and of size 320000
For best results use Ervius's Payload Reducer to reduce the size of payload from shipped ROM use nbmerge.exe to cook OS.nb as template for further cooking
This ROM is assumed to be from Diamond and check your device values as per the guide below
The hex offsets of (L)ogical (B)lock (A)ddress and number of sectors and imgfs block address are mentioned in tutorial above or in the post #8 below
Process
Extract OS.nb.payload from the OS.nb (nbsplit.exe –kaiser (check your device) OS.nb)
Run the OS.nb.payload through Ervius's Payload Reducer tool to remove all files from the imgfs and keep only the partition headers
Open this OS.nb.payload in your hex editor. We need to change LBA values of the partitions and number of sectors of ULDR partition since we are reducing the size
In the MBR region (partition Flag 20) LBA of ULDR partition remains same since we are not moving it anywhere. The existing number of sectors of ULDR is 3E 06 from little endian it will be 063E. We are removing 0600 sectors from this partition (0600 * 800 (size of sector, see post #8 for screenshots) = 300000) so, 063E – 0600 = 00 3E. Write it in little endian at hex offset 1CA and 1CB to 3E 00
To physically reduce the partition, remove all data between hex offsets 0x20000 till 0x31FFFF. This will make the XIP start from hex offset 0x20000 till 0x33FFFF and the imgfs partition start at 0x340000
Now since we have reduced the size of ULDR partition, the LBA values of XIP and imgfs partitions will have to be changed in the MBR region
Now change the LBA of XIP. To calculate that, use this method
In Hex calc
Logical Block Address (LBA) = Previous Partition LBA + Previous Partition number of sectors
e.g. (ULDR LBA) 00 00 00 02 + (ULDR no of sectors) 00 00 00 3E = 00 00 00 40
since the coding is in little endian, we have to reverse these values to 40 00 00 00
Go to offset 0x1D6 and change the values to 40 00 00 00 till 1D9
Now change the LBA of imgfs. To calculate that, use this method
In Hex calc
Logical Block Address (LBA) = Previous Partition LBA + Previous Partition number of sectors
e.g. (XIP LBA) 00 00 00 40 + (XIP no of sectors) 00 00 06 40 = 00 00 06 80
since the coding is in little endian, we have to reverse these values to 80 06 00 00
Go to offset 0x1E6 and change the values to 80 06 00 00 till 1E9
We have changed the LBA and number of sectors in MBR, but the OS needs to know the block address of imgfs in MSFLSH50 region
To calculate that, use this method
In Hex calc
MSFLSH50 Block Address = imgfs partition starting address / 20000 (see post #8 for screenshots, shown here is for Diamond)
e.g. (imgfs starting address) 340000 (shown above) / 20000 = 1A
Go to offset 0x81C and change the value to 1A
Save and close the os.nb.payload file in hex editor. Insert the new XIP into this file using this command
“insert.exe -i xip_out.bin -o OS.nb.payload -d 0x00020000 -s 0x00320000” (check your insert start address, shown here is for Diamond) (ignore this if the XIP is already inserted and shifted to this location with this size)
The value (02) seen at hex offset 0x1BF should not be changed or touched since that value tells the OS that first partition starts from the third Sector of the ROM (0x800 (sector size) + 0x800 = hex offset 0x1000) Currently the reduced ULDR partition starts from third sector
Now create the OS.nb from the edited OS.nb.payload to be used as template for cooking using this command
“nbmerge.exe –kaiser (check your device) OS.nb” (without -conservative switch)
NOTE
For best results directly use the OS.nb.payload as template for cooking without merging it into OS.nb. For this you will need to edit the CreateROM.bat
Note the change in red and delete the blue lines from this bat file
copy ROM\OS.nb.payload temp\OS.nb.payload
..\TOOLS\NBSplit -kaiser OS.nb
Rem rename os.nb.extra os-new.nb.extra
!Aman!'s awesome tutorial on removing ULDR partition from devices which don't have the FAT partition (part03) can be refered here: http://forum.xda-developers.com/showthread.php?t=446506
Screenshots of MBR and MSFLSH50 Regions
MBR Region
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
MSFLSH50 Region
Attached these images in Pictorial.zip with post #1 for offline reference
Gain more Storage Space with LZX compression
Thanks to:
spocky12 for cecompr_nt.dll (attached)
ivanmmj for cecompr.dll (attached) This module supports LZX compression as well as the default XPR algorithm
Replace the cecompr.dll found in the OEMXipKernel (or whichever folder you have your XIP modules) with the attached cecompr.dll module that supports LZX compression
The LZX compression takes a load of your RAM while cooking which makes the continuing IMGFSFromDump tool crash. To avoid that replace the attached cecompr_nt.dll file found in “Tools/IMGFS” folder of your kitchen
Pause your kitchen process right after it extracts the IMGFS.bin and before it inserts the files into it. (A simple “PAUSE” in the batch file will suffice). Then open up your IMGFS.bin in hex editor of your choice and search for the string "XPR". Replace the FIRST one, FIRST & ONLY ONE with "LZX". Close the hex editor, save the file and let your kitchen continue with the cooking
After flashing the ROM cooked with this module should give you approx. 10MB more space in the storage memory
Original Posts:
ivanmmj: http://forum.xda-developers.com/showpost.php?p=3678382&postcount=877
spocky12: http://forum.xda-developers.com/showpost.php?p=3690996&postcount=904
Space for Donors
High value real estate space for donors for all my work on XDA
Special Thanks
Piranha1 $5
Vippie $5
Steven Ellis $10
Guitarguy $5
Ckpv5 $5
Letama $10
!Aman! $5
LoriInWa $10
Noonski $15
Kevin $5
Dogmale $1
Nazaliyah $1
Miscellanous uploads related to XIP porting
Kitchen Files
I use "DiamondKitchen_v0.4" kitchen to cook Diamond ROMs. The XIPInsert file is something that I made to automate the insertion and nbmerge process (well, something automatic is better than complete manual )
If you select to use the XIPInsert batch file then you must have DiamondKitchen_v0.4\XIP\xip_out.bin and DiamondKitchen_v0.4\XIP\OS.nb.payload to use this option, else the existing OS.nb file in \ROM folder will get deleted
Note: The insert values used in the batch file is for Diamond ROMs. Please check and edit these as per your devices
Code:
[B][U][I]!COOK.cmd[/I][/U][/B]
Modified to provide options to include the below batch file or to continue without it
Also included necessary warning
Code:
[B][U][I]8a.XIPInsert.bat[/I][/U][/B]
@echo off
cd [COLOR=green]XIP[/COLOR]
..\TOOLS\insert.exe -i [COLOR=green]xip_out.bin[/COLOR] -o [COLOR=green]OS.nb.payload[/COLOR] -d 0x00320000 -s 0x004C0000
..\TOOLS\nbmerge -kaiser OS.nb
copy OS.nb ..\ROM\OS.nb
del OS.nb
del *.payload
del *out.bin
exit
Deprotecting ROMs: My friend, Ervius has made a small tool to "deprotect" a protected ROM , here: http://forum.xda-developers.com/showthread.php?t=465642
First to say THANKS
Cheers
and second to say this is real hard work...but u have done it bro..
congrats
another amazing work by the XIP Master
Thanks for sharing the info, ababrekar! I'm sure this will help out many people (myself included ).
Bite Down and Don't Give Up.
Sounds like someone i know from.... hey, it is you!
Good Job,
ababrekar said:
Use this command for inserting the xip_out.bin into the .payload (presuming you already have the shipped OS.nb.payload file in the same working folder
insert.exe -i xip_out.bin -o OS.nb.payload -d 0x00320000 -s 0x004C0000
Check these values with your device imgfs since in Diamond the XIP starts at 0x00320000 and the imgfs starts at 0x007A0000, but for some reason the imgfs signature in Diamond is at 0x007E0000
Click to expand...
Click to collapse
just to make it more clear, the value for "-s"= (starting offset of imgfs - starting offset of XIP)
PS: wonderful job writing this guide brother
Ouch - too much like work, but it is nice to know how to do it.
Thanks for your effort!
Best regards,
-boggsie
So, how does one get hooked into the flow of new releases?
Perhaps would be a good idea to use one of your reserved posts as a repository of good XIP.BIN files with versions and info about the ROM extracted, so all we can use in our ROMs... only a tought...
jcespi2005 said:
Perhaps would be a good idea to use one of your reserved posts as a repository of good XIP.BIN files with versions and info about the ROM extracted, so all we can use in our ROMs... only a tought...
Click to expand...
Click to collapse
That is a good idea but I'll do that for posting the unedited XIP.bin files from dumped ROMs since the xip_out.bin I build would be for my device. People wont want to ruin their ROMs with someone else's ported XIP, right?
6Fg8 proudly presents:
m9editor
development discontinued
m9editor is your little helper when it comes to editing manila files. It lets you edit nearly all aspects of a mode9 file. Additionally it will assist you with graphics, allowing import, export and CFC compression. And It includes a directory viewer with information specific to manila files.
requirements:
m9editor is written in .net, so .netCF3.5 (currently SP1) must be installed (usually its already there). It has been developed and tested using Windows XP x64, but should run on any Windows platform.
usage:
see the manual contained in the download package (PDF)
making of / credits:
thanks to: D-MAN666, sztupy, nixx-X1, Chainfire, pcarvalho, showaco, guap, 12aon, xboxmod, NisseDILLIGAF, smotrs, for contributing knowledge, ideas, testing. Thank you guys (& gals of course) !
version history:
2009-03-10 - v3.3.0.1
BUGFIX: crashed when using selections
2009-03-09 - v3.3.0.0
- LuaConv is now included in the m9editor download package
- CHG: all sourcecode related functions use ".lua" as default extension
- NEW: compile and import function for lua script sourcefiles:
for mode9 files (embedded scripts):
m9editor remembers the filename of the source on a per-node basis and lets you subsequently edit the recently used file from the particular node. You may also attach/detach such a link manually. If a link is established, you may edit the sourcefile (check if you set the "SourceCodeViewer" option in m9editor.cfg) and recompile/import in a single step. When saving the mode9 file the links are saved too (mode9file.ann) and reloaded on next open.
for standalone scripts:
m9editor checks if a correspondig xxxxxxxx_manila.lua exists in the script directory. If yes, you are offered edit and compile options.
- NEW: editor context menu: view source for embedded scripts
- NEW: search previous button
- FIX: editing characterreference threw exception
- NEW: dirviewer context menu for mode9 files: compare with: compare two mode9 files without loading it first
- NEW: dirviewer context menu for all files: hex compare with: compare two files with hexview.
Only available if AptDiff is installed. Edit m9editor.cfg and insert the following line (use the path on your system):
AptDiffPath=c:\Program Files (x86)\Brother Technology\AptDiff 1.5\aptdiff.exe
If AptDiff is installed and configured in m9editor.cfg, text compares are done with AptDiff instead of ExamDiff
WARNING:
during directory analyze, if a lua script is found, m9editor checks for existence of <filename>.luac.lua. If its found it will be renamed to <filename>.lua. In directory viewer the line will be shown blue colored to indicate the presence of a sourcecode file.
during mode9 file load, if a embedded script is found, m9editor checks for existence of <filename>_<bytepos>.luac.lua. If its found it will be renamed to <filename>_<bytepos>.lua. In mode9 editor you will notice the link to the script sourcecode. Dont forget to save the mode9 file to make the link permanent (otherwise if you modify the structure, links might be lost due to changing byteposition).
WARNING2:
The pdf attached doesnt reflect the latest changes to m9editor, update follows.
2009-02-22 - v3.2.0.1
- fixed definitions for weather.mode9 and landscape.mode9 which rendered them unusable after modifying
2009-02-22
I removed the QtcConv and LuaConv tools because they lack of syntactical checks and the same functionality is available in m9editor.
EDIT: added the old LuaConv again, seems to work not that bad i thought it would
2009-02-21 - v3.2.0.0
- font changes for various fields to avoid overlapping
- if "manila files dir" is changed in settings, directoryview will be reloaded
- new: directory viewer context menu option for mode9 files: "extract embedded scripts", writes them to script directory
- changed interpretation of UV property (16.16 instead of INT32)
- picture view: new "save as PNG" and "save as QTC" buttons will save your graphic to a selectable directory
2009-02-19 - v3.1.0.1
bugfix for "save tree to file" function
2009-02-19 - v3.1.0.0
time for a new version
- m9editor now remembers last window/splitter positions and restores them on start and returning from minimize
- HOT compare feature: if a mode9 file is loaded, rightclick on the toplevel node to compare with another mode9 file, or save the treeview as a textfile. Compares are done with a freeware tool named "ExamDiff" from PrestoSoft.
2009-02-18 - v3.0.5.0
new context menu functions in directory viewer: delete, copy to
2009-02-17 - v3.0.4.0
content of XML, HTML displayed in lower right panel
evaluation of XML locales in directory viewer
manual is complete, and now a part of the package
2009-02-16 - v3.0.3.1
annotations now work for new tags as well, and will be copied between instances (+corrected a few flaws during display)
new: search within decompiled lua scripts
new: copy annotations between instances of m9editor
2009-02-11 - v3.0.2.0
bugfix: empty value crash
minor improvements
2009-02-10 - v3.0.1.0
some little improvements:
- sourcecode of embedded scripts and .luac files is shown whenever possible
- zoom percentage display for graphics display
2009-02-09 - v3.0.0.0
I've made a lot of changes to improve m9editor. The most important are:
- integration with sztupy's luadec (thanks and credits to sztupy for great decompiler and permission to use, and of course once again to D-MAN666 for providing knowledge)
- import of compiled lua scripts (ANSI or Unicode, autodetected)
- UI reworked: editor, directory viewer, image viewer combined in one window
planned for next releases of m9editor:
- copy files to/from PDA if connected via ActiveSync
- smart-select referenced graphic files in a mode9 file
- selfcheck for consistent mode9 writing
- analysis of lua script "require"'s for valid manila names
download stats:
v.3.2.0.1: 1554 views (wow! impressed!)
Guess I'll have to try that, seems great !
Your editor seems (as you describe it) only able to change values, but not the structure of the mode9 file, do you intend to change that ?
I have an ongoing project of mode9/xml converter in C, if I can be of some help, don't hesitate to ask
Hi Ximoon,
guess you belong to the "intended audience"
At the moment only changing values is allowed, correct. The main reason for this is that i'm unable to interpret and understand the complete structure, and to make sure that writing of m9 files produces valid files. If there's more info on that i could build it into the editor of course.
What i could imagine is a more generic approach, e.g. allow insertion/deletion of tags based on hex-values. I'll give that a thought.
Do you have any detailed info about the tag-structure? It can be seen in the tagfile but as hexvalues. Ive been able to interpret some of them, but the meaning of many others is unknown to me. So m9editor filters most of them for better reading.
Anyway, there's more to come with m9editor. I already built routines to disassemble lua scripts which run fine, but as its output is only relevant to p-code its pretty useless at this time. Also planned is a tool to allow image replacement. That could go to a point where we have a complete workbench for TF3D, including preview and the like. But thats far beyound my current scope.
Nice anyway !
I have no more information than you do, all I got is from the manilla thread where you posted earlier
But in the end, names of the tags doesn't really matter.
For LUA, I found some decompiler on the web, so I guess a tool to convert lua-unicode to lua-ascii and reverse could work to use those tools.
I guess I'll go on with my editor and see what I could do in the end, for two different approches could be constructive !
Must have been ChunkSpy, right? I found many more but mostly outdated and not working for Lua 5.1.
The Lua routines i've already written allow converting unicode to ascii, and save the scripts in ascii respectively. I'll have to recode them in .net as the first quick approach has been VB
Nice start, man
I was waiting for so long since somebody starts public Manila DevKit since i posted specs i reversed
Drop me a PM if you have any questions
Can't wait to use those lua tools
yeah, right D-MAN, most of that thing is based on your findings, my respect m8.
I'll PM you later, gotta go shopping now for newyears eve
6Fg8 said:
yeah, right D-MAN, most of that thing is based on your findings, my respect m8.
I'll PM you later, gotta go shopping now for newyears eve
Click to expand...
Click to collapse
Yah, sure, after NY eve when my hangover is over
oh oh, nice tool thank you
new version has been released, details here
got ean error if i want to open a file..
System.UnauthorizedAccessException: Der Zugriff auf den Pfad C:\Dokumente und Einstellungen\Administrator\Desktop\HTC\tf3d\2c684cd8_manila wurde verweigert.
bei System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
bei System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
bei System.IO.FileStream..ctor(String path, FileMode mode)
bei m9editor.m9efunctions.readm9(String fname, Boolean writedebug)
bei m9editor.m9editor.fileopen_Click(Object sender, EventArgs e)
bei System.Windows.Forms.Control.OnClick(EventArgs e)
bei System.Windows.Forms.Button.OnClick(EventArgs e)
bei System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
bei System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
bei System.Windows.Forms.Control.WndProc(Message& m)
bei System.Windows.Forms.ButtonBase.WndProc(Message& m)
bei System.Windows.Forms.Button.WndProc(Message& m)
bei System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
bei System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Click to expand...
Click to collapse
edit: i was write protected.....
schreda said:
got ean error if i want to open a file..
System.UnauthorizedAccessException: Der Zugriff auf den Pfad C:\Dokumente und Einstellungen\Administrator\Desktop\HTC\tf3d\2c684 cd8_manila wurde verweigert.
Click to expand...
Click to collapse
sorry, i dont have that file on my touch HD, cannot test. Are you sure its a mode9 file? Can you upload it here?
schreda said:
edit: i was write protected.....
Click to expand...
Click to collapse
that explains something
hmm.. i'm trying to port the analog clock from the Diamond to the HD.. i must change the Resolution i think but i got a bad result if i change the size var... ( i took the original file from the Hd to compare it
schreda said:
hmm.. i'm trying to port the analog clock from the Diamond to the HD.. i must change the Resolution i think but i got a bad result if i change the size var... ( i took the original file from the Hd to compare it
Click to expand...
Click to collapse
great idea, i'd appreciate to see a analog clock on the HD
new version has been released, details here
wow! finally someone is doing it
thanks and keep up the good work!!!
what i show in screenshot, is it portion of unparsed data?
can one edit them? i tried and failed cause i dont know what to change...
i'm missing: RectF, X, Y, Width, Height
pcarvalho said:
wow! finally someone is doing it
thanks and keep up the good work!!!
what i show in screenshot, is it portion of unparsed data?
can one edit them? i tried and failed cause i dont know what to change...
i'm missing: RectF, X, Y, Width, Height
Click to expand...
Click to collapse
its the value of the tag above, "Viewport". Currently i dont know how to parse that, as its binary and i dont understand the meaning. Could be 8 x Int16, or 4x Int32, or a mixture of that, and even then i wouldnt understand what these values mean. Obviously parameters for Viewport.
Yes, you can edit that, simply overwrite the hexvalues and press enter, it will be written.
Can you shed light into the purpose of these values? I'll be glad to parse them right.
BTW there is a baaad bug in v1.0.2.0 when writing m9, i'm currently correcting that.
6Fg8 said:
its the value of the tag above, "Viewport". Currently i dont know how to parse that, as its binary and i dont understand the meaning. Could be 8 x Int16, or 4x Int32, or a mixture of that, and even then i wouldnt understand what these values mean. Obviously parameters for Viewport.
Yes, you can edit that, simply overwrite the hexvalues and press enter, it will be written.
Can you shed light into the purpose of these values? I'll be glad to parse them right.
BTW there is a baaad bug in v1.0.2.0 when writing m9, i'm currently correcting that.
Click to expand...
Click to collapse
take your time my friend
those ones for Viewport i only know that they are:
<Property Name="Viewport" Type="RectF" X="0" Y="0" Width="31457280" Height="35127296" Animated="False"/>
cause i used D-MAN666's mode9parser, talk with him cause he might help, i hope
I'm hoping this will be helpful to anyone looking to modify Manila.
Manila 2.5 has all new file paths so the file lists from older versions don't apply. I searched the forums but couldn't find any info on new file names, so I decided to try to put together a new list and this is the result.
This should be a solid base, and I hope that we can build up from here. Anyone who finds new file names please post your findings so we can get a more complete general reference as well as keep it up to date in case of any later changes to Manila.
[APP] Manila Name Finder:
This started out as just some scripts to help me search for names, but has evolved into a proper little program. It can search decompiled mode9 and lua scripts for manila names as well as reconstruct names from localization xmls.
It's not really the most user friendly thing, but it works. The included ReadMe.txt has some basic instructions for use. This tool is also included as part of this Manila Kitchen and that really is the best and easiest way to use it.
I'm also posting the source code. If a future version of Manila breaks the naming scheme again like Manila 2.5, this finder will need to be updated. I'll probably update it but in case I'm MIA someone will hopefully find this source code useful.
Download:
Manila Name Finder v1.0
MNF v1.0 source code (C++)
[REFERENCE] NAME LISTS: Manila 2.5 and 2.1: (a bit outdate right now - will update soon)
You can just paste the lists into m9editor's m9editor.names.txt to get the manila names displayed in m9editor or any manila kitchen which uses on the same m9editor.names.txt for manila names.
Note: Only the file list in the lower left corner of m9editor is affected by adding the new names to the list. The hashed names that appear when you mouse over a file in the editor window aren't affected by this. See the guide below to learn how to get hashed manila names from mode9 files.
Current status of Manila 2.5 list (stats based on Manila 2.5 from Duttys Leo R1 ROM)
Code:
mode9: 69 of 69 ....100.00%
luac: 297 of 318 .....93.39%
qtc: 925 of 1216 .....76.06%
xml: 1220 of 1239 .....98.46%
Current status of Manila 2.1 list (stats based on Manila 2.1.38680)
Code:
mode9: 51 of 51 ....100.00%
luac: 225 of 234 .....96.15%
qtc: 711 of 813 .....87.45%
xml: 1076 of 1081 .....99.57%
Note: Both name lists actually have more files then the stats show. The stats only count the names that translate to valid *_manila names.
Download:
Manila 2.5 Name List (8-Aug-09)
Manila 2.1 Name List
[GUIDE]: Manila 2.5 file names - what changed compared to 2.1 and earlier
The hash algorithm that was used in earlier Manila versions is unchanged in Manila 2.5. What has changed is the directory structure.
In Manila 2.1 all the mode9 files were located in \windows\htc\ (e.g. \windows\htc\home.mode9, \windows\htc\email.mode9), all the images in \windows\hts\assets\images and lua scripts in \windows\htc\scripts.
Manila 2.5 changes this by breaking it up into subdirectories. So home.mode9 is now located in \windows\htc\home\home.mode9. The same \windows\htc\home\ directory is shared by related mode9 files, such as citypicker.mode9 and worldclock.mode9 (full paths: \windows\htc\home\citypicker.mode9, \windows\htc\home\worldclock.mode9). Other mode9 files have different subdirectories e.g. calender.mode9 and calendar_picker.mode9 are located in \windows\htc\calendar\, while email.mode9 is \windows\htc\email\email.mode9 etc.
Now, any files referenced in the mode9 (images and scripts) are also in the same subdirectories. Because Manila uses relative paths, you'll see something like .\assets\images\%imagefilename%.qtc in a mode9 files.
The ".\" is the current directory. If you're editing \windows\htc\home\citypicker.mode9 then the current directory is \windows\htc\home\, so the full path of the image is \windows\htc\home\assets\images\%imagefilename%.qtc.
You might also see this: ..\common\assets\images\%imagefilename%.qtc. "..\" is up one directory. So again if you're editing \windows\htc\home\citypicker.mode9 up one dir from there is \windows\htc\, and the full image path becomes: \windows\htc\common\assets\images\%imagefilename%.qtc
Now that you have the full path you can use this small tool by NisseDILLIGAF to get the hashed name: http://forum.xda-developers.com/show...&postcount=271
2.5 vs. 2.1 compared - example:
Manila 2.1: \windows\htc\email.mode9
Manila 2.5: \windows\htc\email\email.mode9
In both versions the mode9 has a reference to .\Assets\Images\Email\envelopeback.qtc, but the current directory ".\" is different between 2.5 and 2.1, so that:
Manila 2.1 .\ = \windows\htc\
Manila 2.5 .\ = \windows\htc\email\
So the full file names are:
Manila 2.1: \windows\htc\Assets\Images\Email\envelopeback.qtc
Manila 2.5: \windows\htc\Email\Assets\Images\Email\envelopebac k.qtc
And after the hash:
2.1: 77FB7FAD_manila
2.5: 5C5B9C11_manila
You probably have a lot of these already but you never know,
http://rapidshare.com/files/261745557/m9editor.names.txt
I'm curious what you been by an automated way of naming? What method do you use do find the names? Anyway hope this helps, 12
Thanks 12aon, there are 57 new luac files that I didn't have. I'll update the first post.
To find the names I converted all the mode9 files to xml (using sztupy's kitchen) and then wrote a script for UltraEdit to find and copy any paths ending with .luac or .qtc from the mode9.xmls.
I've attached the script below if anyone needs it (only works with UltraEdit).
The process needs some manual intervention in that all collected paths start with ".\" or "..\". The "..\" is always "\windows\htc", but the ".\" is variable - e.g. for all paths found in "\windows\htc\home\%anyfile%.mode9" the .\ needs to be replaced with "\windows \htc\home\" while for "\windows\htc\people\%anyfile%.mode9" the .\ should be "\windows\htc\people\" etc.
I'm trying to do something similar to get the names from lua files.
EDIT: find_in_mode9.zip was attached here. It's redundant. See MNF in first post instead.
Very savvy! Smart, I went the long manual way and though, screw that!
Just finished searching the lua scripts: got 297 valid luac file names. First post updated.
I attached the UltraEdit script I used for the search, in case anyone might need it.
Funny thing is the search turned up more results (322 total) but they couldn't all be matched to manila files. Not sure if this is due to the pre-release state of Manila 2.5 or some bugs in my search script.
Anyway, 93.39% of lua scripts accounted for so I'm happy with that
EDIT: find_in_lua.zip was attached here. It's redundant. See MNF in first post instead.
you should run these on the 2.1 manila also there are a couple of names still missing there too, 12
Just went through the Manila 2.1 files. Got about 190 new names. Everything is attached in first post.
Also, I think I have a good way to reconstuct the Manila 2.5 xml names. Should have the script done soon.
thanks a lot cookiemonster
was looking for a way to fix pixellated backgrounds in leo roms
u r simply great !!
keep up the good work
what i do!
i found that adding a .\home for any file in the home,mode9 files gives the right name..so also in internet.. .\internet
same in others.
i open my files in m9editor add them manually and make my mods.
so the files i s ok then
Got 1220 xmls named. New list up.
As before the UltraEdit script I used is attached below. This one is a little different then the last two. Because the xmls aren't named specifically in any file, the script reconstructs the name from within the xml and then gets the path from a list of mode9 files. These scripts really aren't as refined as they should be, but they got the job done.
The qtc files are still missing quite a few names, but I think that this is mostly because Manila 2.5 i still in development i.e. most of the artwork is created but not yet implemented.
EDIT: reconstruct_xml.zip was attached here. It's redundant. See MNF in first post instead.
GREAT WORK!!!!... I have been looking for something like this. It is wonderful to see it here... and hopefully it will be turned into a wiki or somethin'.
Great Work,
SoBBie
does anyone know where to get the actual 2.5 oem packages for manila? I am playing with the beta from the XOR ROM.
OK Found a Leo Update with a manila version. dont think it is 2.6 but it is at least 2.5. I was tryingt o go through and convert all the paths to manila names in an excel (I would be happy to share if someone wants it, it is not complete yet) but I noticed that there are MANY MANY VGA files already there. even luac files like \windows\htc\Weather\Scripts\Weather\WeatherGizmo_VGA.luac
Does this mean that HTC anticipated this being ported to VGA and gave us a head start? That would be GREAT!!!!!!!!!!... Anyway any answer to this would be great... I am going to start by looking through the VGA stuff. I do not see a home_VGA file but not sure yet.
Thanks,
SoBBie
supersobbie said:
OK Found a Leo Update with a manila version. dont think it is 2.6 but it is at least 2.5. I was tryingt o go through and convert all the paths to manila names in an excel (I would be happy to share if someone wants it, it is not complete yet) but I noticed that there are MANY MANY VGA files already there. even luac files like \windows\htc\Weather\Scripts\Weather\WeatherGizmo_VGA.luac
Does this mean that HTC anticipated this being ported to VGA and gave us a head start? That would be GREAT!!!!!!!!!!... Anyway any answer to this would be great... I am going to start by looking through the VGA stuff. I do not see a home_VGA file but not sure yet.
Thanks,
SoBBie
Click to expand...
Click to collapse
I've noticed a lot of lua scripts in both Manila 2.5 and 2.1 that have some form of the following:
Code:
if _application.Store:GetStringValue(Lifetime_Permanent, "VGAManila") == "true" then
VGALayout()
About 90 lua scripts in Manila 2.1.38680 contain "VGAManila", and about 80 have it in Manila 2.5.duttysLeoR1.
HTC is making a new VGA device (Tachi) so that's probably the reason. Should make porting to VGA as easy as switching "VGAManila" to "true".
Co0kieMonster said:
I've noticed a lot of lua scripts in both Manila 2.5 and 2.1 that have some form of the following:
Code:
if _application.Store:GetStringValue(Lifetime_Permanent, "VGAManila") == "true" then
VGALayout()
About 90 lua scripts in Manila 2.1.38680 contain "VGAManila", and about 80 have it in Manila 2.5.duttysLeoR1.
HTC is making a new VGA device (Tachi) so that's probably the reason. Should make porting to VGA as easy as switching "VGAManila" to "true".
Click to expand...
Click to collapse
Co0kieMonster GreatNews!!!!!!!! There are now 2 people that love you in my household! of course one is a 2 yr old ;P Thanks I think I can take a look at some of those to see if I can port some of this to 2.1 maybe :\ it has been tough.
Thanks,
SoBBie
EDIT:
OK Now on to actually decompiling.... The people in this thread seem to be some of the best decompilers so I thought I would as the question here. I am trying to play with the AgendaView lua File 1ECF3290_manila. I downloaded the latest kitchen from 12 (3.00.06). I copy that file to the Tools folder and run the following two commands:
luadec 1ECF3290_manila > 1ECF3290_manila.lua
compare 1ECF3290_manila 1ECF3290_manila.lua 1>1ECF3290_manila.log.txt 2>1ECF3290_manila.error.txt
I end up with an empty error text and a log file that ends with:
Opcodes in original: 30
Same lines in both files: 0 0%
Same opcodes in files: 0 0%
Different
Global:
Opcodes in original: 1527
Same lines in both files: 0 0%
Same opcodes in files: 0 0%
How? does the luadec not work with 2.5 yet? am I doing somethin wrong? I, for some reason can not use the 01_Decompile.cmd (which is a separate conversation) so I took the actual commands from there and ran them manually. I could understand a few but EVERYTHING is different? Any help would be greatly appreciate. if this is the wrong place to have the discussion then please pm me.
Co0kieMonster said:
I've noticed a lot of lua scripts in both Manila 2.5 and 2.1 that have some form of the following:
Code:
if _application.Store:GetStringValue(Lifetime_Permanent, "VGAManila") == "true" then
VGALayout()
About 90 lua scripts in Manila 2.1.38680 contain "VGAManila", and about 80 have it in Manila 2.5.duttysLeoR1.
HTC is making a new VGA device (Tachi) so that's probably the reason. Should make porting to VGA as easy as switching "VGAManila" to "true".
Click to expand...
Click to collapse
Yes a tachi with landscapemode will be released but I don't if it's going to be 2.1 or 2.5/6. In the tachi files the code to switch between VGA and WVGA were two register entries, might be the same for the leo files.
supersobbie said:
Co0kieMonster GreatNews!!!!!!!! There are now 2 people that love you in my household! of course one is a 2 yr old ;P Thanks I think I can take a look at some of those to see if I can port some of this to 2.1 maybe :\ it has been tough.
Thanks,
SoBBie
EDIT:
OK Now on to actually decompiling.... The people in this thread seem to be some of the best decompilers so I thought I would as the question here. I am trying to play with the AgendaView lua File 1ECF3290_manila. I downloaded the latest kitchen from 12 (3.00.06). I copy that file to the Tools folder and run the following two commands:
luadec 1ECF3290_manila > 1ECF3290_manila.lua
compare 1ECF3290_manila 1ECF3290_manila.lua 1>1ECF3290_manila.log.txt 2>1ECF3290_manila.error.txt
I end up with an empty error text and a log file that ends with:
Opcodes in original: 30
Same lines in both files: 0 0%
Same opcodes in files: 0 0%
Different
Global:
Opcodes in original: 1527
Same lines in both files: 0 0%
Same opcodes in files: 0 0%
How? does the luadec not work with 2.5 yet? am I doing somethin wrong? I, for some reason can not use the 01_Decompile.cmd (which is a separate conversation) so I took the actual commands from there and ran them manually. I could understand a few but EVERYTHING is different? Any help would be greatly appreciate. if this is the wrong place to have the discussion then please pm me.
Click to expand...
Click to collapse
No I think you overlooked something, are you using my kitchen? In my kitchen there should be an error log that has a line that compare.exe can't get passed. Sometimes it's as easy as just removing a double end statement and sometimes you gotta dig into the disassembly output to see what the function in the script is actually trying to do. Worst case you'll be up against conditional statements. You just gave me a new idea to simplify my kitchen I'll give the output files after decompiling in my kitchen a number that identifies the order in which to handle them, good luck, 12
This should make searching for new names a bit easier
See first post for download.
[APP] Manila Name Finder:
This started out as just some scripts to help me search for names, but has evolved into a proper little program. It can search decompiled mode9 and lua scripts for manila names as well as reconstruct names from localization xmls.
It's not really the most user friendly thing, but it works. The included ReadMe.txt has some basic instructions for use. This tool is also included as part of this Manila Kitchen and that really is the best and easiest way to use it.
I'm also posting the source code. If a future version of Manila breaks the naming scheme again like Manila 2.5, this finder will need to be updated. I'll probably update it but in case I'm MIA someone will hopefully find this source code useful.
thanku very much!
Quick question:
Does the actual filename of the xxxxxxxx_manila relate to the name too? i.e. the xxxxxxxx number is a hexadecimal HASH of the internal name?
I'm asking because I'm writing some manila editing tutorials and at some point I will be creating manila files and I'd like to name them correctly (also without using another name already in use elsewhere).
EDIT: Ok the aptly named manilaHASH tool answered that nicely for me when I tried it. \windows\iamafish -> 557FE52A_manila
Thanks. Excellent work by the way.
and what about names started with " .\..\" or "..\..\" ?
Think I may have found something. I've been trying to port the MyFaves Page from Sense 2.1 to Sense 2.5. Been having problems because of the whole renaming issue. So, I edited the 26948339_manila & ManilaFull.xml to use the old Mode9 filepaths for the Page & it's icon. It loaded but the icon was missing. So i copied in the images from Sense 2.1 & it used them. I think the whole renaming thing is linked to those xml's if you use the old Mode9 filepaths, it looks for the old image files paths as well.
example:
When I used;
Code:
<Page Order="1" Name="myfaves.page" PackageName="HTC" Title="MyFaves" >
<ComponentReference Name="page" Mode9Path="[COLOR="#ff0000"]HTC\Myfaves\MyFaves.mode9[/COLOR]" Component="GizmoRoot" SmartComponent="true" />
<ComponentReference Name="icon_normal" Mode9Path="[COLOR="#ff0000"]HTC\Manila\myfavesicon.mode9[/COLOR]" Component="MyFaves_Off" />
<ComponentReference Name="icon_selected" Mode9Path="[COLOR="#ff0000"]HTC\Manila\myfavesicon.mode9[/COLOR]" Component="MyFaves_On" />
<ComponentReference Name="icon_preview" Mode9Path="[COLOR="Red"]HTC\Manila\myfavesicon.mode9[/COLOR]" Component="MyFaves_Preview" />
</Page>
it used the new Filepath Hashnames (\Windows\HTC\MyFaves\Assets\Images\MyFaves\VGA\"ImageName".qtc).
But, if I use;
Code:
<Page Order="1" Name="myfaves.page" PackageName="HTC" Title="MyFaves" >
<ComponentReference Name="page" Mode9Path="[COLOR="#ff0000"]HTC\MyFaves.mode9[/COLOR]" Component="GizmoRoot" SmartComponent="true" />
<ComponentReference Name="icon_normal" Mode9Path="[COLOR="#ff0000"]HTC\myfavesicon.mode9[/COLOR]" Component="MyFaves_Off" />
<ComponentReference Name="icon_selected" Mode9Path="[COLOR="#ff0000"]HTC\myfavesicon.mode9[/COLOR]" Component="MyFaves_On" />
<ComponentReference Name="icon_preview" Mode9Path="[COLOR="#ff0000"]HTC\myfavesicon.mode9[/COLOR]" Component="MyFaves_Preview" />
</Page>
It used the old Sense 2.1 Filepath Hashnames (\Windows\HTC\Assets\Images\MyFaves\VGA\"ImageName".qtc).
What this all basically means is, ".\" didn't change meaning. It means from the Mode9's filepath. So if Mode9 is in "\Windows\htc\", than ".\" = "\Windows\htc\". If the mode9 is in "\Windows\htc\Myfaves\", than ".\" means "\Windows\htc\Myfaves\".
EDIT: This does NOT seem to effect Script Filepaths...
Intro:
This is an all-in-one tool for decompiling, compiling and comparing lua scripts found in Manila (TouchFLO 3D / Sense).
All this is a continuation of sztupy's original work: Lua 5.1 tools.
General:
LuaTool consists of 4 parts: Lua decompiler, Lua compiler, Lua compare utility and a Manila file type detection utility.
LuaDec 3.2 - Lua decompiler
Notes on latest version:
Major overhaul of the local finding algorithm. Most lua scripts can now be fully decompiled without a problem.
Manila 2.5.1921 has a total of 703 scripts (including embedded scripts). LuaDec can fully decompile 663 files. That's a success rate of 94.31%.
General notes:
LuaDec automatically checks if the output file was decompiled successfully.
If it wasn't, LuaDec will also output the disassembly and compare file.
In case the decompile was 100% good, LuaDec will only output the standard .lua file as before.
LuaC 1.2 - Lua compiler
Binary function replacement:
LuaC can directly replace functions in compiled luac files. This can be useful if the luac file can't be fully decompiled, but only a small part of the file needs to be edited. Some more info on function replacement.
Continue statement:
The "continue" statement has been added to the Lua Compiler.
Lua doesn't officially support continue statements, but it looks like HTC added it for their needs, so I'm following their lead.
Usage and versions:
Code:
LuaTool 1.2 by Co0kieMonster
Usage: LuaTool <task_select> [task_options] <task_input>
Tasks:
/decompile (or /d) -- Lua Decompiler
/compile (or /c) -- Lua Compiler
/compare (or /cr) -- Lua Compare utility
/detect (or /dt) -- Manila file type detect utility
LuaDec 3.2
Usage: LuaTool /decompile [options] <inputfile>
Available Options:
-o <filename> specify output file name
-dis don't decompile, just disassemble
-f <number> decompile/disassemble only function number (0 = global block)
LuaC 1.2
Usage: LuaTool /compile [options] <inputfile>
Available Options:
-o <filename> specify output file name
-s strip debug information
-r <n> <luac_file> replace function <n> in <luac_file> with <inputfile>
LuaCompare 1.2.1
Usage: LuaTool /compare [options] <original.luac> <newfile.lua(c)>
Available Options:
-o <filename> specify output file name
-s side by side file comparison
-du disable underline
ManilaDetect
Usage: LuaTool /detect <inputfile>
LuaTool changelog:
# LuaTool v1.2
-updated LuaDec to v3.2, LuaC to v1.2 and LuaCompare to v1.2.1
# LuaTool v1.1
-updated LuaDec to v3.1, LuaC to v1.1 and LuaCompare to v1.2
LuaDec changelog:
# LuaDec v3.2
-Local guesser improvements
---major overhaul - gives much better results
-Conditionals handling improvements
---fixed elseif not being recognised in some cases
---added partial support for complex inline boolean assingment
-General improvements
---fixed single function decompile
---fixed table assignments where there are more then 16 values
---better error handling
# LuaDec v3.1
-Conditionals handling improvements
---wrote a brand new algorithm for handling complex logic expressions
---fixed falsely detected generic for loops
---fixed misplaced if end, because of end-to-break optimization
-Local guesser improvements
---declarations at CALL before RETURN
-General improvements
---fixed indents not behaving properly in some cases
---fixed LOADNIL assignments where the destinations are local variables
---decompiler now displays success rate after decompile
---added SETLIST handling
# LuaDec v3.0.4
-General improvements:
---added back error messages
---fixed variable arguments handling
---fixed multiple inline assignments
---fixed a rare if ending misplacement
-Local guesser improvements at:
---inline bool assignments
---table in table situations
---TAILCALLs
---CALLs which return multiple results
---locals declared just before TEST ops
---SETTABLE where b isn't a constant
# LuaDec v3.0
-core rewrite and cleanup
-more accurate especially with conditionals and loops
-some miscellaneous accuracy improvements
-added extra info to script header (date, time, file name and manila name)
-LuaCompare updated to v1.0.1 (compatibility)
# LuaDec v2.1
- Less crashing:
--- added a failsafe for crashing on bad registers
--- fixed crash on SETUPVAL
--- fixed crash on SETLIST
- Better conditional handling:
--- fixed handling of deeper nested else and elseif
--- fixed handling of empty if-end and else-end blocks
--- added break handling
- Better table handling:
--- fixed inline table assignments
--- fixed handling of numerically indexed tables
- Adjustments to local guesser:
--- fixed guessing for inline table assignments
--- fixed guessing for SETGLOBAL and SETUPVAL at PC 1
LuaC changelog:
# LuaC v1.2
-added binary function replacement
# LuaC v1.1
-added "continue" statement
LuaCompare changelog:
# LuaCompare v1.2.1
-small change to support single function decompile
# LuaCompare v1.2
-pre-compare disassembly is now done internally instead of writing to disk and reading
-added a console message with match percentage
# LuaCompare v1.1
-initial version integrated in LuaTool
Go co0kiemonster! You da man!
boy oh boy ... cant believe that, thanks
time to get back to the keyboard and do some hack0r's stuff
see you guys
I like the new compare output a lot! Saves some lines in the manilatool.cmd as well. Do you plan on updating all the ruby tools or just the compare?
Muchos gracias
12aon said:
Do you plan on updating all the ruby tools or just the compare?
Click to expand...
Click to collapse
Probably all (except luadecguess, which is redundant because luadec has an internal guesser since version 2.0). But I hadn't planned on doing it any time soon - right now, luadec is keeping me pretty busy. I'm doing a semi-rewrite of it in order to inject some OOP love (port to C++) and then hopefully make a proper conditionals and loops engine.
I don't mind OOP love . Hey I somebody came with this idea about luadec but as it turned out I misunderstood him. He was actually talking about the m9editor. Nevertheless the idea is good. You tell me if it's doable.
Wouldn't it be a good idea to include the full manila name in the lines of code as well (If known). Going a bit further might it not be an even better idea to include some more diagnostic info there.
Thing I can think of are manila version (although I can't imagine a foolproof method), date, full manila path name maybe some diagnostics.
You know I'm going to keep you occupied right?
12aon said:
Wouldn't it be a good idea to include the full manila name in the lines of code as well (If known). Going a bit further might it not be an even better idea to include some more diagnostic info there.
Thing I can think of are manila version (although I can't imagine a foolproof method), date, full manila path name maybe some diagnostics.
Click to expand...
Click to collapse
Full manila name and date aren't a problem. I'll add them in the next release.
Manila version would have to be set by the user so that's a bit problematic. But it would be great to have. I'll try to think of good way to add it.
As for diagnostics: Did you mean adding something other than the "-- DECOMPILER ERROR: ... " lines, or just making those lines a bit more useful?
12aon said:
You know I'm going to keep you occupied right?
Click to expand...
Click to collapse
I'm counting on it
Co0kieMonster said:
Full manila name and date aren't a problem. I'll add them in the next release.
Manila version would have to be set by the user so that's a bit problematic. But it would be great to have. I'll try to think of good way to add it.
As for diagnostics: Did you mean adding something other than the "-- DECOMPILER ERROR: ... " lines, or just making those lines a bit more useful?
I'm counting on it
Click to expand...
Click to collapse
The version number can be found in a package here:
Code:
[HKEY_LOCAL_MACHINE\Software\HTC\Manila]
"Version"="2.1.19193517.0"
That's either the .reg or .rgu file
It can also sometimes be found in the package name. But these things are very unpredictable. In that sense it could only be used as an extra. I don't know if any of the exe's in the package hold the info.
By diagnostics I was referring to my lack to come up with anything else. I hoped your developer instincts would lead you to add in the rest for me. But now that I think of it maybe something amount of errors in the script or amount of opcodes, maybe the number of functions. I don't know why, or how it would be useful so probably just leave out that part. Unless you disagree of course,
12
12aon said:
You know I'm going to keep you occupied right?
Click to expand...
Click to collapse
LOL 12 has a new toy!
I guess it would be dumb to ask if you intend to use this in your Manila kitchen! LOL
Asphyx said:
LOL 12 has a new toy!
I guess it would be dumb to ask if you intend to use this in your Manila kitchen! LOL
Click to expand...
Click to collapse
It is already part of the kitchen , co0kie has been helping us for a while now. He is the one who added the lua scheme to notepad2
Ive been trying to use this on the lua files in the sprint hero but no matter what i try i get the error "Bad header in precompiled chunk"
Any thoughts/ideas?
You sure hero's got lua files? Would you mind sharing them?
12
pentace said:
Ive been trying to use this on the lua files in the sprint hero but no matter what i try i get the error "Bad header in precompiled chunk"
Any thoughts/ideas?
Click to expand...
Click to collapse
Might be a different encoding.
Can you upload a few of the files so I can check it out?
Version 3.0 is up
Some info:
Version 3.0 is a complete rewrite of LuaDec. It's more accurate then 2.1, especially when large loops are involved. It might just need a little bit more tweaking but conditional and loop handling is almost perfect. The next big thing to tackle is local guessing, and that will come in a later version.
LuaDec has also generally been cleaned up, so no more obsolete command line switches or memory leaks.
It can also retrieve the full manila name and add it to the file header. E.g.: if you decompile 0bd9db81_manila, LuaDec will add \windows\htc\people\scripts\people\peoplegroupdeta il.luac to the decompiled script header for better reference. For this to work you need to have the m9editor.names.txt file in the same folder as LuaDec.
Now that I've done this rewrite I should be able to accelerate development. And there are some cool new feature coming in future versions.
Decompile Luaplugins for lightroom
Hi,
I just wondering if it is possible to use this to decompile any lua files, the one i'm looking for is decompiling lightroom plugins
skrollster said:
Hi,
I just wondering if it is possible to use this to decompile any lua files, the one i'm looking for is decompiling lightroom plugins
Click to expand...
Click to collapse
LuaDec has been tuned specifically to HTC's Lua variant. Theoretically it should decompile any Lua 5.1 scripts, but it might be incompatible with the character and number encodings of non-HTC scripts. I'm not sure about the specifics, since those adaptation were done before my development efforts - see here for some of the details: http://forum.xda-developers.com/showpost.php?p=3466886&postcount=249
You can always give it a try and see what happens. It can't hurt
Co0kieMonster said:
LuaDec has been tuned specifically to HTC's Lua variant. Theoretically it should decompile any Lua 5.1 scripts, but it might be incompatible with the character and number encodings of non-HTC scripts. I'm not sure about the specifics, since those adaptation were done before my development efforts - see here for some of the details: http://forum.xda-developers.com/showpost.php?p=3466886&postcount=249
You can always give it a try and see what happens. It can't hurt
Click to expand...
Click to collapse
It just gave me an almost blank file, the only thing in it was some stuff i guess you add to all files
skrollster said:
It just gave me an almost blank file, the only thing in it was some stuff i guess you add to all files
Click to expand...
Click to collapse
Yeah, that's definitely because of the different encodings. Sorry, but I guess it's not going to work.
Too bad really, is it possible to create a decompiler for the encoding used for adobes applications? if so, is it much work to change it?
I'm not sure. Upload one or two lua files so I can take a look.