Related
\HKLM\SOFTWARE\HTC\ATDbgLog
Enable=1
writes more or less familiar ATDBG log files to \Storage
\HKLM\SOFTWARE\HTC\XPanel
Enable=1
has all sorts of interesting options to write 'RadioTrace'
Reading a .pco file with???
does anyone know why the atdbglog does not always work?
especially after the logfiles reach their maximum size ( about 2M ), then after deleting them, it takes days before the logging starts again.
and I have no clue why. coldbooting also does not help.
looking at the .pco file, this is the raw trace output from the gsm.
this information can also be found in a memory buffer at 0x97d63000
( this is probably the serial port's buffer )
see the 'multi-channel-protocol' described on this page:
http://www.xs4all.nl/~itsme/projects/xda/serial-protocols.html
Hi folks,
In the course of making my own ROM (something I admit to being new at) I found it rather tedious to individually compress exes with the upx utility and batches included with HyperCore kitchen. I've made a batch job that will look through all files in an input folder and compress all the exes (so you can just copy your entire SYS and OEM folder out of your kitchen, compress their contents and copy back). Perhaps something to do this already exists, but if so I couldn't find it. I've also included a more recent version of upx with this than was in HyperCore.
Hopefully this will save someone a little time.
To use:
1. Copy/Move folders containing exes (I suggest just copying the whole SYS and OEM folders) into the input folder.
2. Run compress.bat
3. Copy folders in output back to your kitchen.
While UPX is good for compressing PE files (which results in a smaller output file), one should point out, that it's a tradeoff. You get a smaller file, but a higher startup latency, and sometimes a tad larger memory footprint. So UPXing is not good for responsivenes of a device.
UPXing small .exe files may then be beside the point. You'll gain for eg. 5KB but you'll loose a second every time you load the file.
UPXing usually makes sence on executable files larger then 200-400 KB, and smaller then 15MB.
You can google for UPX performance for more information.
Just my 5 cents, and I think it's important for cookers.
NIXin said:
but a higher startup latency
Click to expand...
Click to collapse
mehehehe.
heh. it was not really good text, imo(maybe it is, on e-105..but even omap have VERY fast decrunch speed).
4 cents are ok, in general...
my one cent:
test EVERY upxed dll, EVERY upxed exe, some things will be broken after operation(isilo - i.e.).
very good idea is to pack office pack exes(much space for useful soft while cooking).
.net apps CANNOT be uxped for now.
imo, batch upxer is just NOT good idea...
Good input from both of you, particularly in regard to testing the executables. There is an option to force byte-identical decompression, perhaps it would be a good idea to enable this? I am aware that there is a trade-off in performance with compression, but reading the readme on upx one notes that decompression is very fast. Even assuming our ppcs are 10 times slower than the Pentium 133 decompression would still be 1MB/sec, and most of our exes are much smaller than that.
Just curious if this case where files don't work after compression is a common one (noting I'm not compressing dlls as they are unable to share data when compressed; this is noted in the upx documentation, where they comment it's probably only a good idea to compress things like plugin dlls). Perhaps someone with more experience can comment on this?
caeci11ius said:
Good input from both of you, particularly in regard to testing the executables. There is an option to force byte-identical decompression, perhaps it would be a good idea to enable this? I am aware that there is a trade-off in performance with compression, but reading the readme on upx one notes that decompression is very fast. Even assuming our ppcs are 10 times slower than the Pentium 133 decompression would still be 1MB/sec, and most of our exes are much smaller than that.
Just curious if this case where files don't work after compression is a common one (noting I'm not compressing dlls as they are unable to share data when compressed; this is noted in the upx documentation, where they comment it's probably only a good idea to compress things like plugin dlls). Perhaps someone with more experience can comment on this?
Click to expand...
Click to collapse
While compression is necessary to fit some things in it really ought to be a last resort. I recall the author stating that a 100k program compressed to 50k requires 150k of memory to expand and run and it doesn't free up all of the extra memory needed...so there has to be a balance or you are going to be using up all your memory to save storage....if the app HAS to be installed to phone storage then upx is something to consider but I wouldn't recommend globally upx'ing all your apps on your minisd for instance.
.net apps CANNOT be uxped for now.
Click to expand...
Click to collapse
Because .NET files don't have the standard PE header. It's a requirement for UPX (or any other executable file packer) (PL: pozatym witam )
Mr. famewolf just confirmed what I have said and even added some more. It's perfectly okay for PCs, where you don't notice the difference, but PPC's are just way to slow and the gain is too little (if any). Batch method is not the way to go, unless you wan't to "cripple" your PPC.
Hi everyone.
I own a HTC Polaris with IBM J9 Midlet Manager.
Does anybody notice strange behaviours while loading Image data from filesystem and/or resources in JAR files?
It seems to me that images whose size >= ~5KB, no matter if they are in PNG or JPEG format, cannot be loaded into an Image object.
I can load plenty of small images (summing over 5KB total size) but I cannot load, say, a 200x100 image and this is quite strange. The same JAR works fine on a Nokia 6111.
Increasing the heap size (-Xm? options) seems not working, too.
Is it a problem with J9 ? I must use this manager, since I need Bluetooth and Filesystem APIs.
Thanks in advance.
Today I've figured out that it is not the size of the image, but its shape
In fact, I can use SQUARE images up to screen width, but not RECTANGULAR ones!
Does anybody confirm this?
Perhaps a useful detail: I'm using 8-bit indexed PNG files.
hello fellow chefs
i whas looking for a way to gain more speed in my rom
i whas thinking it all are graphics so if i made the size smaller the rom wil be faster
now i found a program wich works with commands so it automaticly does a entire folder i set the files in
now i whas wondering if i search all png files from the kitchen and convert them
they will be put in one map
if i rename that map to zzzz_resized png files it will overwrite in the kitchen but will i end up with the small size png or the big size png when the rom is flashed to my phone?
i have read that overwritten files take up more memory thats why i am aksing
thansk in advance for any ideas
chris
It will just over-write the files during the rom build-you won't end up with duplicate files in rom. And you'll end up with the files that are processed last during the build (should be the zzz-ones). So, yeah, it will do what you want. That's a safer method than just replacing the old files with the new ones in the original packages, because you may find that the new ones suck, and then it could be difficult to recover the old setup. It's also faster to do. Just check you build log to see that the proper files are being over-written.
Farmer Ted said:
It will just over-write the files during the rom build-you won't end up with duplicate files in rom. And you'll end up with the files that are processed last during the build (should be the zzz-ones). So, yeah, it will do what you want. That's a safer method than just replacing the old files with the new ones in the original packages, because you may find that the new ones suck, and then it could be difficult to recover the old setup. It's also faster to do. Just check you build log to see that the proper files are being over-written.
Click to expand...
Click to collapse
thanks farmer ted for youre thought about it
in the meantime i thought i just needed to try it and see how it would end up
well a little bit of strange thing has happend:S
when i go into taskmanager>menu>view>processes
i see gwes.exe his size is cut in half:-o(verry nice result)
but filesys.exe is raised with approx 2 mb:-o
any idea how that possible?
The filesys size mostly depends on the cache sizes in my experience; did you change any of those? I may need to start compressing png files-it would be nice to have a smaller gwes tax.
hmmm nope i didnt change anything
when i check taskamanager it has lower ram% so i will leave it as it is
just wanted to check as i have read somewhere files being overwritten ended up loading in the ram instead o the place where it usually ends up
on a side note
you want the progrma i used?
you can put all the iles in one map and you can do them all at once
took me like 5 minutes to do my whole kitchen
all the png files though(a little over 2000 files)
i also want to do bmp and its possible with that program
maybe i did it the wrong way though
all the png files where bpp32 and i changed them to 16bpp wich saved me about hal the size of gwes
when i want to do it for bmp files wich are 12 bpp and i change them to 8bpp the files get blurred:s
can you share how you are planning to the bmp files?
I'm not good at graphics editting at all, lol. I have no clue how to edit a .bmp, although I did save 1.5 MB from my rom by just leaving out the two .bmp skin files for quick qps. Yeah, I'd definitely like to know what you're using on the .png's, that sounds easy (my level).
Task managers aren't the best at figuring out how much memory a process is using in my experience. As an example, here's my gwes.exe usage (right now) with different task managers:
dotfred: 26,295 kb
XTask: 5.08 MB
SK Tools: 5,414,912 bytes ; heap size = 63,619,664 bytes !!!! (Seriously, WTF?!?)
Microsoft TM: 5.16 MB
Ishi TM: 60,289 KB (Again, WTF?!?)
If I look at the gwes slot with virtualmemory.exe, it looks like it's around 6 MB of virtual memory (I guess that's the same as RAM, but who freaking knows). So, it seems like the task managers that put the usage at ~5 MB are more accurate. I run virtualmemory.exe whenever I really want to see if something weird is happening. Clearly, dotfred's can't be right. I've seen it have gwes at 30 MB before, which has got to be impossible (never mind the TM's that have it at 60 MB, lol).
hi mini,
can you post the program for resizing the graphics.
i have tried a lot but non of them working well.
you must do it manually one by one ( which means a lot of work)
thx
gonna send you booth a pm as its a warez program
Warez discussion is strictly prohibited on XDA.
Thread locked, I would suggest not sending that PM.
Hello , this is info and question in the same time so excuse me please.
Can somebody be so kind to say something about heap size on galaxy 10.1 on new Kitekat , or how to change build prop list to make larger heap size than 256mb.
That is maximum allowed memory acces for application on galaxy. Because of that I can not run properly Photo Mate R2 which is essential for me.
Small heap size prevents application to save raw files after editing so it is useless that way. App shows heaap size of 256mb in system info and needs at least 512mb preferablly more for bigger files from say nikon d800.
Is that issue solved in kitekat update or someone know how to make it bigger on 4.1.2. By changing build prop list like someone said before?
It is painfull that majority of phones have bigger heap than galaxy tablet, which make simple toy of it instead production tool that could be.
Thanks