Ivan V4R3 with 32MB Ramdisk - V1.2 released - MDA III, XDA III, PDA2k, 9090 Software Upgrading

I've managed to get Ivan V4R3 working with 32mb Ramdisk support using the tips in the main Ivan V4R3 thread here
http://forum.xda-developers.com/viewtopic.php?t=52546&start=50
and here
http://forum.xda-developers.com/viewtopic.php?t=52546&postdays=0&postorder=asc&start=25
(in short, hexedit unencrypted nk.nba then add buzz_lightyear's 32mb ramdisk cab).
I've also ensured that IE stores its cache files in ramdisk by fiddling with some nice reg keys that were'nt covered by the buzz_lightyear patch.
The end result is really fast and doesn't seem to get all laggy after heavy use, as Ivan tends to do when it scatters temp files around the storage disk.
I'd like to send a finished ROM out to the gang for testing but I lack the expertise to edit and recombine default.hv and boot.hv to include the buzz_lightyear and IE reg patches prior to reassmbling the ROM.
Can anyone PM me with some more info on how this can be done?
If not, then it'll be a ROM file, CAB file, reg file mix to get it into a testable package, which all seems a bit messy when we could just have a flash-and-go version.
Hope you guys can help, thanks.

send me the stuff and i'll do it.

Ah wait - I've figured it out. Just copy the default.hv from a running ROM on a device, and recombine that into the flash package.
Will churn out something tonight if I get time and see what people make of it.

nope, it a lot more complicate that that

work in progress??
Just wanted to know if you guys are still working on this project. Let me know as i am very interested. THX

Apologies, I've been AFK for a few days dealing with real life - horrible thing it is too.
The rom, ramdisk cab and a list of Registry modifications are now uploading to /uploads/for_midget_1990.
[EDIT] all files uploaded at 20:07 BST
Procedure is -
- replace the Ivan v4R3 nk.nbf with the one included
- flash, align screen etc
- install the ramdisk32 cab
- modify the registry keys as shown in reg_keys.txt
- power off, then power on to cement all reg changes
- reboot
The above config has been running on my Qtek 9090 for the last week with some pretty heavy use and it's still performing nicely with no sign of the slowdown that Ivans ROM normally suffers from after prolonged use.
Midget_1990 - if you can munge these files together into a proper release, that would be fantastic. Meanwhile I'll try to find some info on doing it myself. I'm not far off it, I just can't find much info on how to edit the registry files inside the ROM. I'm sure the info is out there if I look hard enough.

depending on how busy i am in the next few days i will try and make this into a proper flashable rom, however i am also working on upgrading Ivans rom anyway so I will definatly produce a version with the ramdisk as well as normal with future releases.
Thanks for your reaserch etc.

I was using logouts latest and it was very slow once you got a few things running on it and when enabling the wifi.
I just downloaded and installed ivans again using this method and also overclocking to 530mhz. Seems to be doing very well. i will test and report more as the week goes on.

HI all
Willpower102 - Agreed - overclocking to 530 is definitely the ideal for any wm5 rom.
I've made some progress on modding the ROM last night. I'm just having trouble finding the Internet Explorer cache directory entry in the ROM's registry files. Once I've cracked that, I'll be ready to release a flash-and-go version.
Now that I'm able to build my own ROMs, I've also been experimenting with the atihwtbl0.txt file in the \windows dir. You can see some tasty looking timing variables in there - not least the CAS timing for RAM. More on that later when I've tested it properly.
Also, I found a more up-to-date version of ace_ddi.dll a while ago and will try to include that too. I've benchmarked it with GXMark, and it's definitely faster. Original dll gets 1750 gxmarks, new one gets 1850. I've even managed 2000 gxmarks but that has been hard to reproduce. (all figures produced at 530mhz)
Lastly I can say that now I've got my hands dirty with the ROM-building tools, my respect for Tuatara, Mamaich, Buzz_Lightyear, Ivan, Midget_1990, Logout, Art, and the whole ROM-building crowd has only increased. It's a slow and fiddly process, so more than ever respect to the people who are making this possible.

rom building
Thingonaspring: mad props for all your effort!!!! I would like to educate myself and start the rom building process aswell. Before I even try to attempt this I guess I have to do a lot of research and reading (but its all worth it). I would be most grateful if you could tell me where you got your info from.....and any links would be greatly appreciated.
Hats off once again for all your hard work

the best advice i can give is read the entire wiki, including every device, twice. This will get you the background knowledge about how these devices work etc, then PM someone who currrently makes ROMs and ask (nicely) if they would mind sending you the BA ROM toolkit and if your really nice they might also explain how to use it
Good luck!

THX
Midget_1990: thanks for the heads up!!! Thats what I assumed. Reading, reading and more reading is on the agenda.

[EDIT] Found the cause - nasty lil control-code gremlins on the end of each line. Stripped the file down to ascii codes only, edited, saved as unicode and everything works.
Serious help needed here
I am attempting to rebuild default.rgu and user.rgu into default.hv and user.hv using rgucomp.
I am doing the following :-
SET _FLATRELEASEDIR=.
rgucomp -o dump\default.hv -nologo > default.txt
edit in wordpad (also tried notepad), add REGEDIT4, ensure final line is just a <CR>,
save as text with unicode encoding
When I rename default.txt to boot.rgu and do :-
rgucomp -b
I get an error :=
Failed to parse HKEY_CLASSES_ROOT\xslfile!!!
I've tried many different approaches with both default.hv and user.hv.. Always ending up with very simillar results. Usually a parse error on or close to the first line.
Can anyone help with this? I've read everything, not just on this site, but on buzzdev and a ton of weird japanese/chinese forums (no idea which, just lots of kanji characters).
It's really annoying as I only have limited time to work on this, and it's soo close.

Try this:
Rename default.rgu to boot.rgu
set _FLATRELEASEDIR=.
rgucomp.exe -b -nologo
ren boot.hv default.hv
attrib +r +h +s default.hv
And error in this k e y
HKEY_CLASSES_ROOT\xslfile!!!
Fix it

I was running SPB Software on the unit without the ramdisk and I tested the software with SBSH Software on it to find that the software you install can make a slight difference.
However, the unit seems to really get a boost in speed. I love the improvements the 32 RAMDISK does to the unit. I have had no issues with the unit since the upgrade.
I was wondering how everyone was doing with the bluetooth fix though. How has the quality been since the major changes that has been done over the past month now. There hasn't been many complaints about the bluetooth but was wondering about quality and if there has been any disconnect issues. I haven't used my bluetooth ear piece long enough to really know.

Also how has everyone's battery life been. I noticed that the software has some major drainage on the phones battery. I usually don't notice much due to the v3 extended lion battery but how about the oem battery?

Speed is unbelieveable with ramdisk on ivan's v4r3.
Problem is programs installed after the ramdisk mod don't show up on the "remove programs" list, thus can't un-install.

I myself am stuck with the registry too, due to the fact that the programs in the toolkit to do it are 16bit and not compatable with my 64bit version of windows...

OK, the ROM is finally ready.
Here :-
ftp://xda:[email protected]/Uploads/Blue Angel/IvanV4R3_Ramdisk32.zip
It includes a tweak to CAS timings (1clk instead of 2clk) and an updated ace_ddi.dll display driver. Both should improve speed, but do note that the CAS tweak means that overclocking to 590mhz, which was always pretty unstable, will now cause the device to hang. Overclocking to 530 works fine in my tests.
There's still plenty more I can try to gain a bit more speed, not least the rest of the timings in the atihwtbl0.txt file, and perhaps mounting the RAMDisk as early as possible will allow more parts of the OS to store volatile data in RAM.
If/when I come up with an updated version, I'll post it hereabouts.

Baeshin81 - I left my phone on standby last night with 100% battery at 2AM when I finally crawled into bed.
On reaching work the next day 9:15AM, the phone had used just 3% battery power.
So in short - battery seems fine. Do note that I've got an expanded 2450mah battery, not the stock one.
Keano - I too notice the remove programs problem after installing the buzzlightyear ramdisk cab. The new ROM does not use this method, I've basically stolen Logout's approach to ramdisk instead, so the add/remove problem is no longer present.
Midget_1990 - have you tried a DOS emulator like Bochs?

Related

Wizard ROM Ported to BA - Performance Improvements

I've been working with the Wizard Port which mamaich has done, and have run into the 'normal' performance issues with WM2005 which most everyone has encountered.
Since our devices have so much RAM available, IMHO it should no longer be used for storage. Instead we can utilise huge SD Cards for all storage needs. We need one for the EXTROM installation anyways, and the Batteries will drain the same whether you're using 32Mb or 128Mb of your RAM.
My main focus has therefore been to improving RAM usage for Caching and Filesystem access (StorageManager). I'm trying things out to see if there are any improvements which can be done simply through registry changes. I'd felt I was relatively successful on my Himalaya (using BuzzROM 1.60c) with this style of performance tweak, so now it was time to try it out on the new Blue Angel.
I'm primarily concerned with stability and performance, as well as usability and resources. My focus has therefore been to make extensive use of the RAM Disk for all temporary elements (why make them persistant?), to add appropriate levels of caching and to set an appropriate number of buffers for all memory and filesystem access. My goal is to use the RAM to it's full potential - 32Mb for temp/ramdisk, and as much as beneficial for Cache/Buffers/Paging/etc. leaving the remainder (64Mb+) available for applications to use.
For this I've been scanning the forums and have gleaned the 'pearls of wisdom' from many developers who have been trying to improve the performance of their devices. For everything which I've found, I've researched the origins of the registry modification, and have verified (to the best of available information) that the flags/settings/values or other parameters as I've changed them in the attached registry files below, are legal and valid.
I've geared things to be a 'workhorse' device - i.e. the initial application open/start may be slightly slower (first run), but once the application is up and running, it responds very quickly. The point is then to keep all the commonly used applications running and using the RAM, not to try to have untold Mb of RAM free. All those 'Task OK Button Close' are a real waste when using WM2005 now.
If you do have some memory intensive application, then you may need to close applications, but with 64MB+ free I couldn't think of what you might want to run (except a game or something else 'useful'). The "Memory" Control Panel is all you'd ever need for this.
Ok ... enough rambling about what I've tried to achieve ... on to the details.
Device Configuration I'm using:
- mamaich Wizard ROM v2a (unmodified)
- Model No.: PH20B
- Model Name: iMate PDA2K
- ROM Version: 5.03.02 WWE
- ROM Date: 03/02/05
- Radio Version: Radio 1.15.00
- Protocol Version: 1337.45
- CPU: Intel(R) PXA263
- Speed: 400 Mhz
- RAM Size: 96 Mb
- Flash Size: 32 Mb
- Flash Chip Type: 28F128K3
- Storage Size: 60.30 Mb
Attached below are two principal registry files: Performance.reg, and Customize.reg
Performance is specifically for improving the Performance of the device.
Customize is specifically for setting 'default' customizations, which are user/owner preferences.
These can be imported using your favourite registry editor (I'm using Resco) and you can see what (if any) difference to performance they can make.
Code:
Performance.reg Details:
[HKEY_CURRENT_USER\ControlPanel\Phone]
- Disable Phone Sleep. May help with Bluetooth disconnect issues.
[HKEY_CURRENT_USER\ControlPanel\Sounds\TTSAnnounce]
- Move Voice Command Caller Identification into RAM Disk
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders]
- Move all of IE's Temporary Files into RAM Disk
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
- Give IE More Connections
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
- Give IE More Threads
[HKEY_LOCAL_MACHINE\ControlPanel\WiFi]
- Slow down the WiFi Scanning Interval
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\QwertyKey]
- Improve Keyboard Responsiveness
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\WaveDev]
- Improve Audio Responsiveness
[HKEY_LOCAL_MACHINE\Security\Policies\Policies]
- Disable Signing
[HKEY_LOCAL_MACHINE\Software\HTC\XPanel]
- Move Volatile elements to RAM Disk
[HKEY_LOCAL_MACHINE\System\FileSys]
- Move all Temporary Items to RAM Disk
[HKEY_LOCAL_MACHINE\System\GWE]
- Disable Animation
[HKEY_LOCAL_MACHINE\System\GWE\Menu]
- Disable Animation
[HKEY_LOCAL_MACHINE\System\StorageManager\Filters\fsreplxfilt]
- Set the File & Directory Exclusions for the Filesystem Filter
[HKEY_LOCAL_MACHINE\System\StorageManager\...]
- Tweak all the StorageManager settings to improve performance
Code:
Customize.reg Details:
[HKEY_LOCAL_MACHINE\ControlPanel\AdminPassword]
- Enable Admin Password Control Panel
[HKEY_LOCAL_MACHINE\ControlPanel\GPS Settings]
- Move GPS Control Panel to Connections
[HKEY_LOCAL_MACHINE\System\GWE]
- Make THIN scroll bars (get a bit more screen space - I'm accurate with a stylus)
[HKEY_CURRENT_USER\ControlPanel\Backlight]
- Default Backlight Settings
[HKEY_CURRENT_USER\ControlPanel\Comm]
- Default USB Communications
[HKEY_CURRENT_USER\ControlPanel\Notifications\ShellOverrides]
- Set the Volume
[HKEY_CURRENT_USER\ControlPanel\PhoneExtendFunction]
- Set PAP and Class 8 (4 Receive, 1 Transmit) GPRS Settings
[HKEY_CURRENT_USER\ControlPanel\Sip]
- Set SIP Input Word Suggestion Defaults
[HKEY_CURRENT_USER\ControlPanel\SoundCategories\Ring]
- Set the Volume
[HKEY_CURRENT_USER\ControlPanel\SoundCategories\RingPreview]
- Set the Volume
[HKEY_CURRENT_USER\ControlPanel\Volume]
- Set the Volume
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
- Set some IE defaults (Google, History, Zoom, etc.)
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
- Set some IE Messages
[HKEY_LOCAL_MACHINE\ControlPanel\Phone]
- Phone Flags
[HKEY_LOCAL_MACHINE\Explorer]
- Show all Files
[HKEY_LOCAL_MACHINE\Software\HTC\Camera\AppDefSettings\P3]
- Disable Recording Time Limit
[HKEY_LOCAL_MACHINE\Software\HTC\Camera\AppDefSettings\P4]
- Enable additional Contacts Photo Mode
[HKEY_LOCAL_MACHINE\Software\Microsoft\Inbox\Svc\SMS]
- Change the SMS Text Message Confirmation
[HKEY_LOCAL_MACHINE\Software\Microsoft\Obex]
- Disable OBEX
[HKEY_LOCAL_MACHINE\Software\Microsoft\Pocket MSN]
- Permit any email address in Pocket MSN
[HKEY_LOCAL_MACHINE\Software\Microsoft\Shell\TaskBar]
- Clock in Taskbar
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
- ClearType in IE
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\AdvancedCPL]
- Enable Microphone AGC
*** NOTE: I forgot to mention to create the following directories in the RAM Disk in order to properly support things! ***
Cache
Cookies
History
Volatile
Improvements, comments, discussion and changes to these values (or adding more) is HIGHLY encouraged. We'll all benefit from faster machines, without needing to overclock them into instability. And if something is obviously WRONG in these settings, point out the mistake! 8)
Hope this helps others with their performance concerns.
Regards,
Tuatara.
*********************************************************
UPDATE: Version 2 of the Scripts: 5/Feb/2006
Performance:
1). Corrected the WaveDev Priority, and the QwertyKey Priority to values which will produce better performing results across all requirements.
2). Removed requirement for \Ram Disk32\Volatile since the \Volatile directory is NOT automatically created. This can lead to problems if the RAM gets corrupted and or is reformatted. Now all temporary (Volatile) Files have been placed in the root folder "\Ram Disk32\" instead.
NOTE: This means you DO NOT need to create any directories! All cache directories will automatically be created as required by IE on startup!
3). BufferSize has been reduced to a more 'sensible' value of 1024 buffers.
4). Added "EnableDataCacheWarm", "EnableFatCacheWarm", and "PathCacheEntries" to the filesystem specifications.
Customize:
1). Moved Key Deletion to END of registry script, since some registry imports fail to delete these keys properly. Can be done manually.
2). Changed Default Search Page to a more Mobile Friendly GOOGLE search page, which permits better searching of results.
3). Removed the /GWE elements which shrunk down the scroll bars, as I did begin to find it tiring to aim more carefully to scroll things.
4). Removed the OBEX Disable, since this would probably confuse more than help.
Filesys.exe and StorageManager Registry Settings
mamaich said:
Some registry settings regarding StorageManager profiles are read during the first stage of boot process from constant boot.hv file located in XIP section of a ROM, and not from the registry you've changed. For example all drivers that are loaded during "Bootphase" 0 or 1 may ignore all settings that are not present in boot.hv. For example you can change "MountFlags" value to anything, and it would be ignored. I also think that cache size settings for TRUEFFS_DOC and MSFlash are read from boot.hv, because setting the cache size in registry to 16Mb (you cannot allocate more than 32Mb in one chunk) does not decrease the free memory size. The same is for "XIP" and "Flags" settings. The filesystem driver may reread these settings from registry when it becomes available, but I don't think so.
The only filesystem driver that reads your changed settings is SD-Card driver. It is loaded after registry is fully functional.
By the way, it is possible to mount root directory of our device to SD-Card, similar to MPX200.
Click to expand...
Click to collapse
I've had a look into this, and from my understanding the StorageManager mounts the partitions (keeping all the flags, etc.) as from boot.hv, but once the filesystem is up and running, it appears to reload in the filesystem (not partition) registry keys from the user registry, when it mounts the portions of the user registry hive at the end of the process.
Filesys.exe Boot Process
http://msdn.microsoft.com/library/d.../wcemain4/html/cgconFilesysexeBootProcess.asp
Although I could be wrong about this ... it 'appeared' to have made a slight improvement. Very hard to say though if it is reloading the registry information.
A better answer might be to modify the boot.hv and then check the performance.
More on this shortly ...
Regards,
Tuatara
Thread Times and Quantum Theory ...
mamaich said:
Tuatara said:
...
Badly written code ... maybe ... most likely it's poor blocking / thread safety implementations which are causing the issues. Interrupt level and thread level access to the data buffers, taken from legacy 2003/SE code could be at fault here. ...
Click to expand...
Click to collapse
Occasionally I've found this page - http://blogs.msdn.com/sloh/archive/2005/05/27/422605.aspx
It has an interesting code at the bottom. I've already made a program that can hook system calls, I'll try to hook EnterCriticalSection and WaitForMultipleObjects and force them to use that code. Maybe this would reduce the occasional lockdowns.
I've also managed to find the value of default thread quantum on our device. It is 0x4b == 75 milliseconds (WinCE default is 100ms). I.e. we have about 13 task switches per second. Decreasing the value can potentially make our device more responsive, but would add some overhead.
Here is the address to patch in nk.nba (address: old_value new_value):
00207B94: 4B 20
this would set a thread quantum to 0x20 == 32 milliseconds, thread switching would be 31 times per second.
Currently I'm testing this patch, if it is efficient - i'll integrate it into newer ROMs.
Click to expand...
Click to collapse
Modifying the Quantum Times is an excellent thought. I remember when this was done for Win2K by SysInternals (tweaking Server into Workstation & vice-versa). Reducing the quantum (in theory) should improve the performance, unless there are too many 'busy' applications executing. Interrupt service requests, and thread unblocking to service them could really kill the 'Quantum Theory' if they come too 'thick and fast'.
It would mean that USB/GSM data is serviced quickly, but application responsiveness (user perception) actually goes down slightly overall.
BUT !!!! the upside of this would be that the dreaded 'lockup' events won't happen anymore, since data is ALWAYS serviced, and the application has (in effect) a lower priority timeslice in which to execute. You will never have a high-priority thread blocking for extended periods, locking the 'foreground' application while it's busy servicing the data requests.
Let me know your initial testing results - I'd then go ahead and modify my ROM if you feel there is any improvement of note. Similarly, I'd probably try to also go about modifying the boot.hv for StorageManager registry settings and see how far that can get things.
Cheers,
Tuatara
Re: Thread Times and Quantum Theory ...
Tuatara said:
mamaich said:
Tuatara said:
...
Badly written code ... maybe ... most likely it's poor blocking / thread safety implementations which are causing the issues. Interrupt level and thread level access to the data buffers, taken from legacy 2003/SE code could be at fault here. ...
Click to expand...
Click to collapse
Occasionally I've found this page - http://blogs.msdn.com/sloh/archive/2005/05/27/422605.aspx
It has an interesting code at the bottom. I've already made a program that can hook system calls, I'll try to hook EnterCriticalSection and WaitForMultipleObjects and force them to use that code. Maybe this would reduce the occasional lockdowns.
I've also managed to find the value of default thread quantum on our device. It is 0x4b == 75 milliseconds (WinCE default is 100ms). I.e. we have about 13 task switches per second. Decreasing the value can potentially make our device more responsive, but would add some overhead.
Here is the address to patch in nk.nba (address: old_value new_value):
00207B94: 4B 20
this would set a thread quantum to 0x20 == 32 milliseconds, thread switching would be 31 times per second.
Currently I'm testing this patch, if it is efficient - i'll integrate it into newer ROMs.
Click to expand...
Click to collapse
Modifying the Quantum Times is an excellent thought. I remember when this was done for Win2K by SysInternals (tweaking Server into Workstation & vice-versa). Reducing the quantum (in theory) should improve the performance, unless there are too many 'busy' applications executing. Interrupt service requests, and thread unblocking to service them could really kill the 'Quantum Theory' if they come too 'thick and fast'.
It would mean that USB/GSM data is serviced quickly, but application responsiveness (user perception) actually goes down slightly overall.
BUT !!!! the upside of this would be that the dreaded 'lockup' events won't happen anymore, since data is ALWAYS serviced, and the application has (in effect) a lower priority timeslice in which to execute. You will never have a high-priority thread blocking for extended periods, locking the 'foreground' application while it's busy servicing the data requests.
Let me know your initial testing results - I'd then go ahead and modify my ROM if you feel there is any improvement of note. Similarly, I'd probably try to also go about modifying the boot.hv for StorageManager registry settings and see how far that can get things.
Cheers,
Tuatara
Click to expand...
Click to collapse
I've done this modification on nk.nba and reflashed my device and i can't see any difference so far. Will do some more testing later.
"[HKEY_LOCAL_MACHINE\Software\Microsoft\Obex]
- Disable OBEX"
Why?
To which point are these tweaks actually noticeable?
Don't get me wrong, i appreciate greatly all the research done arround this, but last time i applied some reg settings (like cache, etc), that didn't improve wm5 speed to the point to find it usable..
I mean, time required to open tmail.exe, the lag in writing sms, lag before answering a call, wifi multitask use, and program responsiveness in general, can one say that with these tweaks the improvements are significative?
I mean, i've kind of given up on wm5 because of these things (although i've reflashed it many times, hope is last thing to die )
Will running some benchmarking software (before) and (after) the registry tweaking show any improvement?
I'm trying to find some (preferably free) benchtest software for WM5 right now. Will update this thread if I find it.
I'm using Wizard v2a on SX66 with Radio 1.15 myself.
Hmm, actually i can feel a little speed up, not much, but it is faster a bit indeed.
KTamas said:
"[HKEY_LOCAL_MACHINE\Software\Microsoft\Obex]
- Disable OBEX"
Why?
Click to expand...
Click to collapse
Ah - legacy stuff for the defaults I need here. Most of our users don't have Bluetooth Headsets, so by default it is disabled to extend battery life. I should have removed that before posting - but then again, maybe it's useful for someone.
d3vil said:
To which point are these tweaks actually noticeable?
Click to expand...
Click to collapse
As with anything which is NOT modifying the underlying issues, these registry tweaks will only produce SOME improvement in the performance. There is a limit to how much you can cache, buffer, move into RAM, or maintain available.
d3vil said:
Don't get me wrong, i appreciate greatly all the research done arround this, but last time i applied some reg settings (like cache, etc), that didn't improve wm5 speed to the point to find it usable..
Click to expand...
Click to collapse
Part of the reason for this is the abundance of mis-information about the registry tweaks. I've seen posts where for example the Flags settings for StorageManager have been specified in Hex, someone else copied them in decimal, and then these have been imported as hex again - leading to some 'random' FATFS configuration setting which would cause problems. Or other posts where the buffer sizes are set to 64Mb or larger?!!? And you would get no useful benefit from this.
d3vil said:
I mean, time required to open tmail.exe, the lag in writing sms, lag before answering a call, wifi multitask use, and program responsiveness in general, can one say that with these tweaks the improvements are significative?
Click to expand...
Click to collapse
For my expectations and usage, these tweaks do help the performance of applications. This does take into account some assumptions though - such as I do not 'Terminate' the application, but leave them running as intended. All temporary elements are placed onto the RAMDisk. All applications are attempted to be executed from RAM. etc.
d3vil said:
I mean, i've kind of given up on wm5 because of these things (although i've reflashed it many times, hope is last thing to die )
Click to expand...
Click to collapse
It all depends on your expectations. Mine are to have better Word, Excel, Outlook, and Exchange integration, incl. Push Email and ActiveSync support. Can't get that with WM2003, so I'm working with what I can, and making it run as smoothly/quickly/stably as possible.
Cheers,
Robert.
mr_ding said:
Will running some benchmarking software (before) and (after) the registry tweaking show any improvement?
Click to expand...
Click to collapse
Benchmarking software is unfortunately inherently flawed. It can only measure what it is attempting to execute - which in the majority of cases does not reflect real-life usage.
These tweaks aren't necessarily designed to speed up the first execution of an application, but are to keep that application ready and available for the next time it is needed and used.
It would be hard to design a benchmark which could replicate everyday usage. The best answer is ... if you've been using your device for a while, and have noticed a few problems ... try the registry settings and see if the issues are less pronounced, or are eliminated entirely.
mr_ding said:
I'm trying to find some (preferably free) benchtest software for WM5 right now. Will update this thread if I find it.
Click to expand...
Click to collapse
I've applied similar settings to my Himalaya and have had very good performance and results from them. I've barely needed to reset the device (maybe 5 times in as many months) and have adapted my usage, or configured my way around most of the flaws. Time to do the same for the Blue Angel Wizard v2a. (or b)
Anyways ... the next step on my list is to make a EXTROM which auto-configures the devices with all the settings and applications we need for our users. mamaich's cfg.txt makes this so easy to do. 8)
Regards,
Robert.
thank you for the work.
one little question, what do i do with the files?
and there is in the all settings the boot image ?
I'm not sure if it is mamaich's very new hexa editing in ROM or your tweaks but my problems with sound are back Will reflash the original Wizard2BA and do a hardreset i guess.
Tuatara said:
mr_ding said:
Will running some benchmarking software (before) and (after) the registry tweaking show any improvement?
Click to expand...
Click to collapse
Benchmarking software is unfortunately inherently flawed. It can only measure what it is attempting to execute - which in the majority of cases does not reflect real-life usage.
These tweaks aren't necessarily designed to speed up the first execution of an application, but are to keep that application ready and available for the next time it is needed and used.
It would be hard to design a benchmark which could replicate everyday usage. The best answer is ... if you've been using your device for a while, and have noticed a few problems ... try the registry settings and see if the issues are less pronounced, or are eliminated entirely.
mr_ding said:
I'm trying to find some (preferably free) benchtest software for WM5 right now. Will update this thread if I find it.
Click to expand...
Click to collapse
I've applied similar settings to my Himalaya and have had very good performance and results from them. I've barely needed to reset the device (maybe 5 times in as many months) and have adapted my usage, or configured my way around most of the flaws. Time to do the same for the Blue Angel Wizard v2a. (or b)
Anyways ... the next step on my list is to make a EXTROM which auto-configures the devices with all the settings and applications we need for our users. mamaich's cfg.txt makes this so easy to do. 8)
Regards,
Robert.
Click to expand...
Click to collapse
I guess you don't use the (SPB Plus) feature when pressing (x) button, it automatically closes the application, right?
I will try your tweak tonight/tomorrow and uninstall/disable SPBPlus feature on auto-closing application myself.
Typically I run Mapopolis (sometimes with BT GPS), phone, sudoku, and tcpmp (watch divx movies). Will it really be okay with all these applications running in the background without closing them?
KTamas said:
I'm not sure if it is mamaich's very new hexa editing in ROM or your tweaks but my problems with sound are back Will reflash the original Wizard2BA and do a hardreset i guess.
Click to expand...
Click to collapse
Interesting ... it could well be either at fault. The only change I've made for the Sound was to set the Audio Priority to a sensible value. You could readily change the value of Priority256 for the sound and see if that makes a difference.
Alternatively, with the quantum time for a thread being lowered, it is possible that there is not enough time for audio decoding to be performed per quantum, which will lead to stuttering as there are other waiting tasks to be serviced.
For the audio, you could try two things:
1). Change the value of Priority256 for HKEY_LOCAL_MACHINE\\Drivers\\BuiltIn\\WaveDev (lower = higher priority = serviced more often)
2). Change the quantum time to something larger (more audio processing per thread switch)
Try patching nk.nba (address: old_value new_value):
00207B94: 4B 64
This would set the thread quantum to 100 milliseconds (MS Recommended = 10 times per second)
You could even be so radical as to try 120 milliseconds (= 78, which would give you 8 1/3 switches per second)
You may find that the audio more responsive with larger processing time blocks, and higher priority. Again, it really depends on what your requirements are.
NOTE: A Hard Reset isn't required for these changes. This is only changing how things execute, not where things are executing from. There should be no need to hard reset & format.
Regards,
Tuatara.
Tuatara said:
KTamas said:
I'm not sure if it is mamaich's very new hexa editing in ROM or your tweaks but my problems with sound are back Will reflash the original Wizard2BA and do a hardreset i guess.
Click to expand...
Click to collapse
Interesting ... it could well be either at fault. The only change I've made for the Sound was to set the Audio Priority to a sensible value. You could readily change the value of Priority256 for the sound and see if that makes a difference.
...
Click to expand...
Click to collapse
I don't have sound issues. But I have Priority256 set to 0x80 (128). Tested on PocketPlayer, sound of incoming call, Toppler game (without Priority256=0x80 it had clicking sounds).
I recommend using 0x80, it is a well-tested value since GB-tweak for WM2003. In this case wavedev driver would not steal time from system services, and priority is high enough to eliminate sound pauses.
I'm still testing my patch, and had no occasional slowdowns yet. The device is responsive even when you are running CPU benchmarks. Previously it lost Activesync connection, ignored touchscreen taps, etc.
Re: Filesys.exe and StorageManager Registry Settings
Tuatara said:
I've had a look into this, and from my understanding the StorageManager mounts the partitions (keeping all the flags, etc.) as from boot.hv, but once the filesystem is up and running, it appears to reload in the filesystem (not partition) registry keys from the user registry, when it mounts the portions of the user registry hive at the end of the process.
Filesys.exe Boot Process
http://msdn.microsoft.com/library/d.../wcemain4/html/cgconFilesysexeBootProcess.asp
Click to expand...
Click to collapse
It is easy to find whether driver rereads registry or not. Just search for "SYSTEM/BOOTPHASE2" unicode string inside it. None of the drivers wait for this event, so we can assume none of them rereads registry. Only filesys.exe, devmgr.dll and pm.dll use this event.
I don't know when filesystem filters are loaded, but they may be loaded at the bootphase 2, so fsreplxfilt.dll can use your new settings. But this should be checked.
You can also try to set invalid values to some settings, so that device would have great slowdown or would not boot at all. Or you can set cache size to something near 32Mb, and check the size of used memory. If it would be decreased, or device would react on your settings (i.e. would not boot) - the driver rereads the registry.
mamaich said:
Tuatara said:
KTamas said:
I'm not sure if it is mamaich's very new hexa editing in ROM or your tweaks but my problems with sound are back Will reflash the original Wizard2BA and do a hardreset i guess.
Click to expand...
Click to collapse
Interesting ... it could well be either at fault. The only change I've made for the Sound was to set the Audio Priority to a sensible value. You could readily change the value of Priority256 for the sound and see if that makes a difference.
...
Click to expand...
Click to collapse
I don't have sound issues. But I have Priority256 set to 0x80 (128). Tested on PocketPlayer, sound of incoming call, Toppler game (without Priority256=0x80 it had clicking sounds).
I recommend using 0x80, it is a well-tested value since GB-tweak for WM2003. In this case wavedev driver would not steal time from system services, and priority is high enough to eliminate sound pauses.
Click to expand...
Click to collapse
I initially had the setting as 128 (0x80) as well, but had some occasional issues with Voice Command & pauses/delays. I increased the priority and the issue appeared to be resolved. However this is assuming short audio playback streams, not continuous ones, and I had changed things further since that issue arose. Time to retest.
Probably setting the value back to 0x80 in the registry is the best option as mamaich recommends. It would be a general solution for everyone. Similarly, I've found the keyboard better with the tweak, but this too could be reduced in priority - possibly 0xA0 (160) would be a more 'adequate' value to utilise.
Code:
Recommend to Change: Performance.reg to contain:
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\QwertyKey]
"Priority256"=dword:000000A0
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\WaveDev]
"Priority256"=dword:00000080
mamaich said:
I'm still testing my patch, and had no occasional slowdowns yet. The device is responsive even when you are running CPU benchmarks. Previously it lost Activesync connection, ignored touchscreen taps, etc.
Click to expand...
Click to collapse
Sounds good ... possibly the Priority256 setting for the WaveDevice was too high - especially with the smaller quantum value, leading to stuttering (somehow). Hopefully KTamas has some time to see which direction solves the problem in the audio.
Re: Filesys.exe and StorageManager Registry Settings
mamaich said:
Tuatara said:
I've had a look into this, and from my understanding the StorageManager mounts the partitions (keeping all the flags, etc.) as from boot.hv, but once the filesystem is up and running, it appears to reload in the filesystem (not partition) registry keys from the user registry, when it mounts the portions of the user registry hive at the end of the process.
Filesys.exe Boot Process
http://msdn.microsoft.com/library/d.../wcemain4/html/cgconFilesysexeBootProcess.asp
Click to expand...
Click to collapse
It is easy to find whether driver rereads registry or not. Just search for "SYSTEM/BOOTPHASE2" unicode string inside it. None of the drivers wait for this event, so we can assume none of them rereads registry. Only filesys.exe, devmgr.dll and pm.dll use this event.
I don't know when filesystem filters are loaded, but they may be loaded at the bootphase 2, so fsreplxfilt.dll can use your new settings. But this should be checked.
Click to expand...
Click to collapse
Haven't had the chance yet to decompose the ROM Image, but will get to that shortly - shame that MS doesn't make the process description clearer. I will try updating the boot.hv with changed settings and see what results that can bring.
mamaich said:
You can also try to set invalid values to some settings, so that device would have great slowdown or would not boot at all. Or you can set cache size to something near 32Mb, and check the size of used memory. If it would be decreased, or device would react on your settings (i.e. would not boot) - the driver rereads the registry.
Click to expand...
Click to collapse
From what I could tell in my experimenting, outlandish (or illegal) settings are limited by the driver itself. i.e. trying to set a CacheSize of 64Mb is met with an upper limit to the CacheSize of 2Mb anyways - regardless of the registry value. This is (partially) why some ridiculous values published by others still work, and additionally why increasing those values doesn't bring any further gains.
Each tweak I've done for StorageManager has increased the memory usage requirements, so I (strangely) still think that there is some mystical reloading of the registry information happening. Maybe it is solely the filters which affect this - maybe it is the loading of the filters which resets only the cache/buffer sizes (to limits), since the filesystems are already mounted.
Regardless, I will try the boot.hv, and the Quantum Time Change sometime soon.
jimp said:
This might be irrelevant, but I had most versions of wm5 on my BA (except the himalaya port). I'm having some issues with MS VoiceCommand.
The (leaked) original (slow) version worked ok.. The wizard port worked even better so did v2.. when i put v2a however (with 32M ramdrive), voice command started acting strange.
The whole device seems abit odd.. when i remove the device off its cradle its just SO SLOW.. as if its searching to sync.. anyway back to VC.
Its very wierd.. ie.. i say Call Harry .. and it matches NAT .. HOW ON EARTH!? Or I say.. call nicole.. and it matches TAXI! . This was NOT an issue with previous wm5 roms. I dont run any other software on the device so I dont know what's causing this. Could it be the ramdrive?
Note.. VC rarely gets the match right anymore.. where as before it RARELY got it wrong.
Click to expand...
Click to collapse
I'm still testing with VoiceCommand, and have had to change a few things to get suitable performance. I haven't as yet made the Quantum Timing change, but I'll evaluate that and see how it goes.
Anyways, you might wish to try the following CAB file. I can't remember who created it but I've been using it along with the RAM Disk for the CallerID Wave File Generation, and Voice Command has been working well. It makes a few registry entries, and I believe replaces some configuration elements - haven't disassembled it as yet.
jimp said:
Note2.. MP3 playback skipping like mad.. (just noticed) (and only on certain mp3s.. not all STRANGE).
Click to expand...
Click to collapse
Additionally, it would be recommended to keep the WaveDev Priority at 128, since KTamas has reported stuttering when it was set at 96 (as in the registry script in the first post)
(Time! I just need more time!!! )
Code:
[HKEY_CURRENT_USER\ControlPanel\SoundCategories\VoiceCommand1]
"AttenuationCategory"=dword:00000001
"InitVol"=dword:00000005
"Script"="p"
[HKEY_CURRENT_USER\ControlPanel\Sounds\TTSAnnounce]
"Sound"="\\RAM Disk32\\Volatile\\TTSCallerID.wav"
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\WaveDev]
"Priority256"=dword:00000080

TuMa v1.4 - BETA - WM5 ROM (RELEASED ... but has problems)

Right ... I think I'd better "pull the plug" as they say on this ROM.
There are currently too many problems apparent, which can not be directly fixed.
The problems unfortunately run deep.
Known Issues:
Pictures & Videos Fails to Start
IE can lockup (randomly) on Images
Odd ActiveSync Behaviour & non-communications
Phone Settings Page failures
Button Page (strangely?) still present
Backlight Level/Flickering
Duplicate Items (bad decision on my part)
BT Profile not appearing in Startup (Profile Bug actually)
Power Manager Bug
Battery Polling/Timing & Reporting
UPX'd Applications may be causing failures
Eval Calc continually reports "Error"
Repllog fills the event reporting
These problems most likely stem from various sources:
Optimization features to improve speed (Data issues / PIM corruption)
Interaction of AKU2 elements with AKU0 (repllog.exe Errors / ActiveSync)
UPX compressed applications (Random 'odd' behaviour)
Filesystem Respecification (standard Directories instead of PermDirs)
Possible stability issues in vBar (Phone Application Restarting)
GWES subsystem / IE extensions (Images, Pictures & Video Failure)
Application resource allocation failures (Eval Calc Failing, & other failing installs)
I will be addressing these issues over the weekend. There WILL be a new ROM at the end of this time (called v1.5) which will be either one of two possible incarnations:
1). Returning to a prior Alpha Test version which proved VERY stable, but contained a lot less of the AKU2 elements from Himalaya (incl. updated BT for reliability *sigh*)
2). Moving even MORE of the Himalaya AKU2 ROM into the current Beta (and correcting the other issues) so as to have as few as possible AKU0 elements coexisting.
Until that time I STRONGLY recommend that everyone not use this ROM - except for further BETA testing and/or bug reporting and/or suggestions for improvement (which would be VERY appreciated!)
TuMa v1.5 WILL still have the SAME feature-set, and SAME feature-rich look, but this will also be working on ENABLING CABs, instead of being a complete 'out of the box' ROM.
Wherever possible everything will still be entirely contained in the ROM to save as much Storage Space as possible and be feature complete, requiring only shortcuts, or registry entries to enable the full 'power'.
Otherwise, in it's "AU NATURELLE" state, the v1.5 ROM will functionally operate as a 'base only' ROM - which can then be used to build from.
My sincere apologies for the troubles you've encountered so far ... however it has been INVALUABLE with all the feedback, and I will be addressing as many of the issues found as quickly as possible.
I'd gotten so close ... the "race" was almost won ... but, it just 'blew up' in the final 50 meters.
____________________________________________________________
TuMa v1.4 has been released now for public BETA testing.
As with any BETA, backup your important data ... only time will tell how well everything has been edited/fixed/corrected in this ROM.
NOTE: There could still be some issues with this ROM, in that the performance has been increased to 'appease' those craving it, and also the feature set of the ROM has been updated to encompass everything requested.
There have been FAR too many changes, and FAR too many updates from v1.3 to even begin describing it. The ROM is now composed of 60% Wizard (Core), 20% Himalaya AKU2 (Updates), 10% Blue Angel (Drivers), and features taken from 5% Jasjar, 3% of Atom, 1% Acer, and 1% Custom Hex Edited Modules. 8)
Battery life should be much improved, speed should be about equal to Ivan's, bugs should be squashed.
Known BIG issues:
1). Sim Toolkit doesn't seem to work 100% for me - I get the menus up, but can't access all the data.
2). Bluetooth disconnect is still in this ROM.
3). Pictures & Videos Application is not working (fix being researched).
Otherwise ... let me know if you find anything!
Needless to say it's been a laborious process to get this done. So rather than bore you with words - here are some pictures instead ...
Download from:
ftp://xda:[email protected]/BlueAngel/BA_WM5/Shipped_Extracted_Updates/TuMa 1.4/
Remember ANY and ALL CABs which are in the EXTROM Folder are OPTIONAL to install. If you don't want that feature (MMS, Java Midlets, Camera, Intellipad Languages) ... then don't install it!
Use the SetOperator.bat file to set your operator for the ROM approproately.
NOTE: SX66 Users - use the SetOperatorSX66.bat file, and DO NOT install the Camera CAB.
EDIT MDAIIIUSer 02/05/06
Changed the ftp link
TuMa Boot Logos
Since I love my Blue Angel sooooo much. I've made a few custom Boot Logos for you to use.
Download from:
ftp://xda:[email protected]/Uploads/BlueAngel/WM5_TuMa/TuMa_Logos.rar
You can obviously also make your own one now ... just replace BootLogo.bmp in the /Windows directory with your own 8-Bit bitmap. Make sure that the file is the same size as the one there - then you know you have the right format. 8)
*** EDIT ***
Since I've had a couple of requests for the original artwork behind these Boot Screens, I've now prepared the PhotoShop Original Artwork file for ALL of these Logos. You can now readily make your own "Blue Angel" Logo, with or without the background, or using a solid colour, or just overlaying the Windows Mobile 5.0 elements overtop. I leave it entirely up to you! It's your BootLogo after all. 8)
ftp://xda:[email protected]/Uploads/BlueAngel/WM5_TuMa/TuMa_Blue_Angels.rar
Enjoy!
And last but not least ...
Some Games which can while away the time ...
Download from:
ftp://xda:[email protected]/Uploads/BlueAngel/WM5_TuMa/TuMa_Games.rar
Fun, fun, fun!
Gr8 work Tuma
Good
Flashing right now...
Will be back later with some news.
Thanks for all the amazing work!!
Nice Release Tuatara!
Going to try it on the weekend
Thanks
Great work Tuatara, thanks will be flashing tonight. And extra thanks for the Xmen Angel logo, that will be my logo from now on. Mutants Rule!
great job!
got this version on my sx66. No major issues.
quick question: is there a way someone can extract the "shutdown" plugin for today. My friend with a sprint 6700 wants it.
AGAIN, Great job ! and I wish I had half the brains you did so I could contribute some coding/hack. At least I will be able to help report any issues in this Beta, to make the release version a better experience for all...
i have instaled to this version, and for now now issues. to report (exept the bt )
thanks for this good work tuatara. :mrgreen:
OK, I've messed around with this new rom for a bit, and I've actually gotta say I prefer Tuma 1.3. The speed increase isn't significant enough to be worth adding more problems I outline below, without actually correcting any of the problems that I disliked in 1.3.
Improvements:
1) Single, fully functional WLAN Manager is nice.
2) I like the category based Program list, but your choice in some instances is well, strange. (ex. Windows Media in Office folder)
New Problems:
1) Phone settings was missing the first page (ring tone/style selection) on my first boot. Seems to be there now though. Odd.
2) Pictures & Videos (Renamed...) does not work at all. Definately a big piss off for me.
3) Internet explorer just locked up my PPC. I used it alot in 1.3, and I never experienced that. I'll see if I can reproduce it.
Dislikes:
1) Renamed Programs. I don't really like that you chose to rename the shortcuts to many Microsoft Programs. Ex: Pictures & Videos to Picture Viewer, File Explorer to Windows Explorer. Since every copy of WM5 has all these programs named the same since they are core programs, I don't think you should be renaming the shortcuts.
2) Some hefty programs. I liked that in Tuma 1.3 there was a nice balance between what was already there, and how much was left up to user discretion. By adding large programs with many alternatives such as Total Commander and vBar, I can't help feel you've crossed the line.
Further updates will come as I keep testing. Thanks for working so hard on this.
Going to flash tomorrow...
Thanks for all the precious work so far Tuatara!
Going to flash tomorrow...
Thanks for all the precious work so far Tuatara!
I am going to test this ROM. I am still wondering whether this one is better than Ivan's. Anyone who has any ideas please let me know, for the reason that I just want to bring my Blue Angel into full play.
good job!!!
flashing it right now
Thanks,I do in now
hmm.. cant get it to ActiveSync
Hiya..
Had major problems getting it to sync
Have reinstalled the Activesync twice now.. It connects (at bloody last! 3 hours and multiple soft resets later!) , goes through the new device blah blah, and then just sits at the Activesync page! Says it is connected, with LOADS of datat flowing between the device and A/S.. bot not synchronizing!
Any ideas?
Nowt has changed since TuMa 1.3 or Ivan... I had both working!
WOW.. damn.. I love this Forum...
Make a post, and low and behold the little fairies jump out of the screen, and waving their wands and throwing fairy dust on my PPC, it does a little beep and starts working!!!
WTF! Problem solved... Ask the fairies what they did if you can catch them!
TheLastOne said:
OK, I've messed around with this new rom for a bit, and I've actually gotta say I prefer Tuma 1.3. The speed increase isn't significant enough to be worth adding more problems I outline below, without actually correcting any of the problems that I disliked in 1.3.
Click to expand...
Click to collapse
Ok ... there were a few problems in v1.3 which are definately fixed in v1.4. The speed should be noticable, but isn't the biggest 'draw-card'. Stability, and integration should be ... but as always ... can't please everyone.
Improvements:
1) Single, fully functional WLAN Manager is nice.
2) I like the category based Program list, but your choice in some instances is well, strange. (ex. Windows Media in Office folder)
Click to expand...
Click to collapse
1). That was a bit of work ... required some 'artwork', 'hex-editor' and 'resource hacker' customization to achieve.
2). So, is "Windows Media Player" a "Tool" then? I couldn't decide either. Well ... in the end I wasn't quite sure 'where' to put that one ... you can move them easily y'know. Besides ... it is delibrately put into the main start menu as "Media Player" so you have direct access to it from there, but also have access through the Programs Menu.
New Problems:
1) Phone settings was missing the first page (ring tone/style selection) on my first boot. Seems to be there now though. Odd.
2) Pictures & Videos (Renamed...) does not work at all. Definately a big piss off for me.
3) Internet explorer just locked up my PPC. I used it alot in 1.3, and I never experienced that. I'll see if I can reproduce it.
Click to expand...
Click to collapse
1). Hmmm ... can't say I've ever seen that. Works fine on my device - so maybe something subtle is happening in the Radio Layer. Most of the RIL core is now from the Himalaya AKU2.
2). Now that's a BUG which MUST BE FIXED. Damn. It was working perfectly all the previous times I have tested and worked with it. I must have done something registry-wise which is now preventing load on my last build. I will find a fix/patch for this and post it as a CAB.
3). I've been using IE over WiFi for quite a lot of surfing - not one lockup to date - incl. having BT Stereo Wireless Headset playing (albeit a bit stutteringly) in the background. I will test further when I have more time.
So ... I'll add my own one ...
4). BT Wireless Stereo Profile has some (irritating) stuttering, but otherwise works quite reliably. Need to look at performance requirements and/or wave audio driver.
Dislikes:
1) Renamed Programs. I don't really like that you chose to rename the shortcuts to many Microsoft Programs. Ex: Pictures & Videos to Picture Viewer, File Explorer to Windows Explorer. Since every copy of WM5 has all these programs named the same since they are core programs, I don't think you should be renaming the shortcuts.
2) Some hefty programs. I liked that in Tuma 1.3 there was a nice balance between what was already there, and how much was left up to user discretion. By adding large programs with many alternatives such as Total Commander and vBar, I can't help feel you've crossed the line.
Click to expand...
Click to collapse
1). Well, you will notice that there are TWO copies of each of the applications you mention. FIRST in the Start Menu (for direct access - named as normal), and a SECOND time in the Programs folder. In order to NOT have naming conflicts for two shortcuts (if moved), they MUST be named differently. This is an unfortunate side-effect of how the Menu Manager works. You could just delete the copy you don't want. That's what Total Commander is for.
2). Again ... both of those apps can be readily 'hidden' if you wish. vBar can be quickly disabled (just turn it off in it's control panel), and similarly the icon for Total Commander can be removed. It costs NOTHING to have them in the ROM - all of your storage space is still 100% free for you to use however you wish, for whatever you wish.
Further updates will come as I keep testing. Thanks for working so hard on this.
Click to expand...
Click to collapse
No worries ... as said - the ROM is aimed at an audience to work "out of the box", not necessarily for the "power hacker" who needs to customize every last element.
But having said that - everything is READILY possible to disable in the ROM, either through checkboxes, or simply by removing shortcuts. Nothing is so 'entrenched' as to be necessary, and nothing is so necessary as to not be 'disabled' easily.
Anyways ... as before, this is BETA, and I welcome constructive feedback (and criticisms) such as this! I want to resolve the last few 'annoying' bugs and try to get to a robust and stable (feature-rich) ROM.
So ... speak your thoughts ... good / bad / ugly ... let me know!
great!
@Tuatara
Great job, Im using it for a couple of hours and until now everything is going very good.
I really like the idea of a custom build, with shortcuts names changed, lots of small softwares installed and a well tweaked registry.
I need to sleep a little. I will be using my device tomorrow as usual and will report in the end of the day.
Thanks again for the hard work :!: :!: :!:
Re: WOW.. damn.. I love this Forum...
Juggles said:
Make a post, and low and behold the little fairies jump out of the screen, and waving their wands and throwing fairy dust on my PPC, it does a little beep and starts working!!!
WTF! Problem solved... Ask the fairies what they did if you can catch them!
Click to expand...
Click to collapse
Hmmm ... this is a bit ODD. There shouldn't be any 'fairies' dancing around in the OS. Maybe a few "Angels" ... but no "Fairies".
Please let me know if you're experiencing any 'odd' behaviour. Such as 'Phone Panels' not appearing, 'Active Sync' not working immediately, 'WiFi' issues, or otherwise. Maybe a 'Gremlin' has snuck into my 'Frankenstein' ROM Monster.

Very Important Note To Increase The Wm5 Spped

I have noticed in all the roms coocked by Bepe Rom Kitchen there is some kind of Problem that decrease the speed of wm5 , it is the rgu and dsm files in the rom under windows folder these are the registry fles that we can exclude them from the rom after they will be saved in the rom these ara about 100 files with 1 or 2 kb size but this decrease the speed of windows folder , the way to exclude them safely coock the rom as usual first start createOS.exe it will generate the TEMP Folder then start the createROM.bat it will build the boot hive and the stopes and ask you to press any button to continue this is the time to delete the rgu and dsm files go to search and find all the rgu and dsm files and be sure to search the hidden files too because most of these files is hidden and when you finish o back to create ROM.bat and finish the rom Building and the first thing you will notice is the speed of opening the windows folder .
Note: you can exclude all the unnessery files that we dont need like the help files *.tm and the note files *.pwi and the word files *.dot etc...
Ahmedkom
That's quite interesting. I'd noted the slow performance in opening "/windows" in Total Commander and I'd often wondered if this impacted the phone. There are way too many files in there, but it was an issue on WM2003 as well and has it's root in desktop Windows. Every time the filesystem has to retrieve a file from there, it has to lookup it's information in a table. While there are ways of writing fast lookups, reducing the input set is often far better. As "/Windows" is quite possibly the busiest directory on the phone, any boost here has to be worthwhile.
Thanks ahmedkom for bringing up this interesting subject, for although there is a tremendous speed gained by mamaich's virtual page pool the Hima beats BA 3:1 when it comes to openning the /Windows dir.
This is true even if the Hima ROM compared to was prepared using Bepe's ROM cook tools. But, then again as you mentioned the BA .dsm & .rgu files are a lot more in numbers compard to the the Hima ROM.
Would you mind sharing how much speed improvement in number of wait cursor 360 degree turns was gained by eliminating those reg & .dsm files? My almost fully loaded BA displays /Windows dir & files after 4 wait cursor turns as against 1.5 turns of a similaryly loaded Hima (using Resco Explorer as File Mgr.).
Cheers!
sure, imagine how fast it's going to be if you delete all files from /windows !!
Honestly, when a 400Mhz CPU is not enough to display a listing of 100 files, something is veeeery wrong. The only reason i put up with with this, is that there's no alternatives with the big screen and gsm phone.
Anyhow, I have latest Helmi build and in calendar just going from day to day, back and forth within the same week is slow noticeably slow. It's obviously re-reading big chunks of data from flash every time, no matter how many times you go between Thur and Fri.
So, given that calendar app is so obtuse, it would be nice to have a file / disk cache on OS level -- which i believe Helmi ROM already has but somehow it aint working...
yeah i just realised Helmi's RAMdisk is just a partition for temp files in ram...

ROM dumping / extraction / kitchen building for the Rhodium platform

Hopefully this is a well known topic and I simply have not yet to locate the information - please try not to flame me too much I've been away for about a year and things have a tendancy to change real quick...
My baseline kitchen / ROM builds have always worked best off a stock OEM dumps - bloat and all. I'm hoping to come across such a gem with the new WWE 6.5 dumps coming available.
Ideally, a similar process could be done as Bepe did to the Hermes rom: Bepe's Big Storage. In this rom the extended and program memory was merged, giving it terrific space (not that I ever needed it ).
Also (and most important for ease of use), his rom dumps included the individual registry entries for each package with each folder - the file names escape me, but it made keeping the registry clean and specific very, very easy. This also makes making a personal kitchen for the masses to use much better as well.
So - has the dumping process for this rom evolved enough that we can replicate Bepe's actions (clean file/registry extraction and merging extended ROM space), do we simply use existing tools for a different platform (such as Touch Pro, Diamond, or whatnot) to extract our own, or is that no longer a driving practice with ROM building?
Thanks for schooling me on the latest ROM process - hopefully I can get one of my Naked builds together for those who perfer lean and fast, cause this bloated gadget is way too fat
Hopefully if there is enough info collected in one spot to either update the Wiki or put up a sticky for everyone to use
Here's a thread from the Raphael device, probably a good enough reference to get started - if it will work with this dump: [TUT] Sous-Chef's Guide to Aruppenthal's XIP Porting Kitchen 5.3
I just PM'd hilaireg - hopefully he has some info if there are hardware differences that would prevent the tools he'd referenced from working...
hi,
i found this thread regarding radio dump but it is for smartphone device (wings).
i haven't tried this yet.
hopefully the process can be used to our device.
edit:
also found this thread regarding rebuilding of dumped roms (raw files) from topaz.
just change the htcrt to our device config.
regards,
twisted
WB Matt!
I think things really have changed a lot from Wizard and Hermes days!
For Kaiser, I use OEM from 6.1 dump, and use 6.5 SYS files! It seems to work better for us Kaiser users.
I am not sure about old way if cooking though! New way is much easier, and real fast to switch between devices even.
But I know you have creative ideas to even make a noob cook! So I am looking forward to your contributions...
Here's hilaireg's response - he added a couple good links and info:
"Hi Matt,
I agree that the TP2 section of the forum is still somewhat sparse.
Arup's XIP porting process was tailored around PkgToolsBuildOS 5.3 which doesn't properly support WinMO 6.5 ... hence the release of Visual Kitchen by Ervius.
IMHO, I would suggest performing a dump of a TP2 official RUU's using the latest version (1.8.1) of Visual Kitchen and forgo using the old PkgToolsBuildOS.
I'm sure you've likely been following Da_G's threads on WinMO 6.5 ... just in case:
[OS][WM6.5.x] Latest Releases (23034), Porting, Tutorials, Tools, VM, etc.
http://forum.xda-developers.com/showthread.php?t=544445
There's this thread as well that may serve of use if you run into extraction issues using Visual Kitchen 1.8.1.
[APP][UTIL]nbImageTool .4 (Partition Dumper) support .nbh .nb .dio .fat .nb0 .payload
http://forum.xda-developers.com/showthread.php?t=548315
The utility may allow you to extract the portions you need (ex: XIP, .PAYLOAD,etc.) and have VK perform the SYS/OEM package extraction. From there, you may be able to piece together a "functional" kitchen from both extraction processes."
ai6908 / twisted - thanks! I did have a lot of success mixing OEM and SYS packages - but the fun was making every element of the ROM being optional, and allowing someone to build a completly empty ROM, or only adding exactly what they want. This way, they can balance bloat vs speed, and find their perfect balance. This flexibility keeps every mix clean and quick
Once I get a good grasp on what's going on, I'll redo the first post with a summary and process for this device, FYI Best way to learn
Good to see you here. I remember the pandora stuff and look forward to this.
Options around things like extendir might be good?
Things have changed quite a bit Matt. I remember your excellent tutorials and guidance from my Hermes days We don't have extended memory anymore and all packages get dumped with their corresponding dsm and rgu, it 's very easy. The newer "visual kitchen" made by bepe and erv, use app.reg and did away with dsm's. Da_G is working on a microsoft based kitchen that will enable us to update any file in the ROM without flashing the whole rom again and that will be possible by the reintroduction of DSM's in the cooking process. You can IM me if you want to chat about all this.. Top right corner
(Sorry for possible silly questions, but I'm still at Andrews for a couple more days and am without a PC )
Interesting... editing/deleting files in a live rom... gonna have to chew on that concept for a while. Wonder how this will effect page file settings. Wow...!
The .dsm/.rgu extraction being clean is good news - trying to break out the individual registry elements is a big pain.
Good as well is the lack of extended memory, but do we recover unused space if not used for the "program" - in that this space is usable to load apps into?
I'll still need to research more, but if we're using app.reg, will the compiler still add .rgu entries into the compiled hive? This will be important to keep package selection clean in a multiple selection kitchen, unless I am unaware of the new kitchen capabilities and this won't be an issue.
I do have some ideas, and a whole lot more programming under my belt than before. Can't wait to get home and get started
Please consider looking at the issue of activating MSVC with the bluetooth headset button if you can. I am not sure if this is fixed in 6.5 but cannot make it work in 6.1. The TP2 usues a different BT stack so I am told. This is allegedly a business phone and this is a mjor feature espcially with the current laws around mobile phones and driving in the UK.
Cheers, and looking forward to whatever you release.
Matt my old friend, I'm sorry for taking a while but i have successfully converted my hermes, kaiser, fuze kitchen to rhodium for you... i'll upload shortly when i get home and you can do what you want with it has all stock extracted rhodium and if you have questions buzz me and i'll answer
Also matt, add me to messenger, it would be an honor to help you with this. get you up to speed
mattk_r said:
(Sorry for possible silly questions, but I'm still at Andrews for a couple more days and am without a PC )
Interesting... editing/deleting files in a live rom... gonna have to chew on that concept for a while. Wonder how this will effect page file settings. Wow...!
The .dsm/.rgu extraction being clean is good news - trying to break out the individual registry elements is a big pain.
Good as well is the lack of extended memory, but do we recover unused space if not used for the "program" - in that this space is usable to load apps into?
I'll still need to research more, but if we're using app.reg, will the compiler still add .rgu entries into the compiled hive? This will be important to keep package selection clean in a multiple selection kitchen, unless I am unaware of the new kitchen capabilities and this won't be an issue.
I do have some ideas, and a whole lot more programming under my belt than before. Can't wait to get home and get started
Click to expand...
Click to collapse
if the rgu entries are in the OEM or sys folder sections of the new rom kitchen it will be added to hive.. App.reg is looked at in EXT folder of the kitchen now.

[PRJ] SYS Builds: What's the Difference?

I'm putting up this thread because there is a good bit of questions that get asked about the difference between the SYS builds. While Microsoft and its partners don't give us a real breakdown of them, we can at least get results on which one is faster than the other. That is the purpose of this thread. If you have any relevant information for me to add to this, let me know. If I add your suggestion, I will, of course, credit you. This is relevant to pretty much all WM6 devices, but I'm making this specific to the Rhodium as that is the only device I plan to support with benchmark results. I'm following the same pattern from the benchmark thread that was started HERE by daeron.be.
To start off, Da_G, a1d2catz, and Cotulla originally posted about the different builds. OndraSter posted to elaborate on a couple of the builds.
Branches of WM Development: Here is what all these different version numbers relate to, and a summary of their features.
212xx = AKU1, all builds leading up to and including WM 6.5
213xx = MOT motorola
214xx = ???
215xx = SAM samsung
216xx = HTC htc
217xx = COM1, continuing dev of 6.5.0.1 - 6.5.0.40
218xx = COM2, continuing dev of 6.5.0.50
219xx = MD, feature test branch, pretty much dead now. (unstable features are added here, this tree is based on COM1, so older base OS code, but the UI/UX code is newer)
22xxx = SEMC sony ericsson
*230xx = COM3, continuing development
*234xx = COM4, appears to be abandoned.
*235xx = COM5, more GUI changes here. New Outlook Interface.
*236xx = LG Electronics Branch
*24xxx = Possible HTC branch
*25xxx = SEMC - Sony Ericsson
*280xx, 282xx = WMD. This is a continuation of com3 from 23090. Most of the changes appear to be with IE
235xx is the only branch that has threaded email natively
290xx = Unknown branch
There was 219xx about half year ago, with numbers ending about 21936 (or maybe 45 or about that). It was test branch, where new features (like... supernew, something like previous 230xx where appeared huge softkeybar etc) were added. This branch was dead, just as looks 234xx now.
But, there was also COM2, with numbers 218xx. Well it reached its maximum, 21899. But instead of making new number line, MS/HTC chose to use already used 219xx. Here is where the mess comes from
The WM version numbers are as follows:
216xx = 6.5.3
219xx = 6.5.0
220xx = 6.5.3
231xx = 6.5.3
235xx = 6.5.5
236xx = 6.5.3
246xx = 6.5.3
250xx = 6.5.3
282xx = 6.5.3
290xx = 6.5.3
Click to expand...
Click to collapse
Updates:
14 March 2011: Finished benchmarks on 21689, 28245, 29011, 29013.
09 March 2011: New builds have begun rolling out. Testing begins tonight on 21687, 29008, and 29009.
...trimmed every month...
Results
I based these blank uncompressed ROMs on the latest shipped T-Mobile 6.5 ROM (1.91.531.4), disabled all ext packages, and swapped builds. I've listed all of the builds that I currently have. If you have one for me to test that's not on the list, send it my way as long as it's WVGA.
SYS builds tested:
216xx: 21659, 21661, 21663, 21665, 21671, 21674, 21677, 21679, 21680, 21681, 21682, 21683, 21684, 21685, 21686, 21687
219xx: 21904, 21905, 21907, 21908, 21909, 21911, 21914, 21916
220xx: 22013, 22018, 22019, 22021, 22022, 22024, 22027, 22031, 22036, 22037, 22038, 22040, 22041, 22042, 22044, 22046, 22047
231xx: 23120, 23121, 23129, 23130, 23132, 23133, 23134, 23135, 23136, 23138, 23139, 23140, 23142, 23144, 23145, 23146, 23148, 23149, 23150, 23151, 23152
235xx: 23569
236xx: 23651, 23654, 23656, 23658, 23659, 23662, 23664, 23667, 23670, 23676, 23678, 23680, 23683, 23686, 23688, 23689, 23690, 23691, 23694, 23697, 23698, 23699
246xx: 24609, 24610, 24611, 24614, 24618, 24619, 24620, 24626, 24627, 24628, 24630, 24631, 24635
250xx: 25018, 25024, 25026, 25027, 25028
282xx: 28233, 28236, 28237, 28238, 28240, 28242, 28243, 28244
290xx: 29002, 29003, 29005, 29007, 29008, 29009
Custom ROMs tested so far:
NRGZ28 Energy: 21916, 21684, 28244, 23148, 23699 - Update coming soon!
Ondraster LBFAR: 21899, 23569
dotcompt DeepShining: Coming soon!
Problem builds:
These are builds I was either unable to import into my kitchen, or cook for various reasons:
22016, 21664, 23123, 23125, 23126, 23127, 23566, 23694
Method and relevant information
If you are planning to send me results or anything, be sure to include the version numbers of the programs you used. SPBBenchmark and Test OpenGL are both freeware. Coreplayer Mobile costs around $30.
Benchmark programs used:
1. SPBBenchmark 1.6
2. Test OpenGL 18.01.2010
3. CorePlayer Mobile 1.2.5
Test Method for blank builds:
1. task29 then flash the ROM without the SIM card.
2. The storage card is left in to install the benchmark cabs.
3. Go into airplane mode.
4. Disable switching screen off and turning the device off.
5. Install benchmarking apps
6. Soft Reset
7. Run SPBbenchmark and disable the following:
Built-in applications (whole category)
Arkaball frames per second
Copy 1 MB using memcpy
8. Run TestOpenGL for about 3 cycles of benchmarks (each cycle is 4 benchmarks) and then turn it off
9. Run three Avatar trailers, note down the results (%). Use default Coreplayer settings and run benchmark immediately after files are loaded.
Trailer found HERE. Note that trailers ARE copyrighted material and are NOT subject to fair use. The link provided is to show what I am using. I own the BluRay disk and ripped it from there. The link is also 720p. My original clip was 1080p. Each exported trailer was set to 800x480 resolution.
One trailer was converted to 25fps, 768 kbps - XHQ
One trailer was converted to 23.976fps, 512 kbps - HQ
One trailer was converted to 20fps, 384 kbps -MED
I wasn't able to determine the original qualities from daeron.be's thread, so I made my own. If you know more about it, please let me know for more accurate results.
10. Run Video Flash benchmark with PIE using a downloaded version of the animation found HERE. If you plan on doing this yourself, download it to your device and run it with IE. Just put it in a root dictionary (\) and then input \benchmark.swf address in IE. On some ROMs you might have to wait a while before the flash starts (there won't be any signs of loading). Run the benchmark (if you want your result to be compatible with mine you MUST run it with flash file in full screen).
11. Collect results
Test Method for Custom ROMs:
Same as above with three exceptions.
1. Run SPB Benchmark with ONLY "Built-in applications (whole category)" test disabled. Leave everything else on.
2. Connect the device to the PC after running the SPB Benchmark test. You may have to go to Start > Settings > Connections > USBtoPC and untick the "Enable faster data synchronization" box to get it to work.
3. Copy the "Spb Benchmark Results.xml" from \My Documents to the PC and grab the results from there with the decimals. I use every decimal in the file. I then trim the trailing zeros in the Excel results file.
I figure since some people will probably use this as a guide of which ROMs are "best" or "fastest," that the results should be as accurate as possible, which is why I'm including the decimals in the custom ROM results, but not in the blank builds.
FAQ
When posting to this thread, please use proper English only, and do not use profanity.
You should not type like a high school girl, either. Leave the "plz," "sum1," and "u" back on the playground.
Ask for help like an adult and be treated like one.
1. What are these benchmarks for?
Basically this is just a measure of performance on different SYS builds to see which one is the fastest. These tests do not indicate which build is really “the best.” It is a measurement of speed on the process of copying files, reading directories, and playing video. To truly “test” a ROM, you need to spend a few days with it.
2. Which radio version are you using?
To the best of my knowledge, this has no affect on the results. However, my current radio version can be found in my sig. I do not change it for these tests.
3. Does a task29 before each flashing affect the results?
There are problems with "ghosting" in ROMs where residual data is left over from a previous ROM. To avoid this, I perform a task29 first. If you want to know more about task29, then visit that thread.
4. Are those benchmarks accurate?
I test the ROMs with SPBBenchmark once as it averages the results of 13 tests each. I use three rounds of OpenGL and use those results as it takes the highest result from there, which is what we want. An average in that category is useless as we want to know what the best result is for this, not the average. I run each Avatar trailer three times and take that average. Flash is pretty straightforward and kind of just for fun, so I only do one test. All of this means that the results may vary by a very small margin. If you don't believe my findings, you are always welcome to test yourself. Anything within a 1% margin of error is acceptable.
5. Why do you disable "Built-in applications (whole category)," "Arkaball frames per second," and "Copy 1 MB using memcpy" for SPB Benchmark on the blank builds?
They don't make a noticeable difference in the results. I could grab the *.xml results file from \My Documents, but it's not that big of a deal in the blank builds as they are just a stepping stone for chefs to see what they like and don't like. If you want to see the results, test them. I use them for custom ROMs because it makes sense to do so. People will interpret these results loosely, and it is better to be more accurate with them.
6. Why aren't you using Linpack?
Great question! I would if this were Android as there are current programs for it. The only one available for use on the WinCE platform is almost three years old at this point. Also, SPBBenchmark measures MFlops, so I don't really need it, do I?
7. Why don't you test battery life?
Battery life testing takes too long, plain and simple. When you flash a new ROM, getting the battery set properly takes about two or three cycles (drained to 10% and then charged to 100%) before it "settles." Even if I did nothing but play movies with the backlight and sound at max while downloading files via wifi and using Bluetooth file transfer, it would still take about an hour or so to drain the battery enough to charge it back again. You would need to drain and then charge AT LEAST once, preferably twice, before running a battery meter to test. This means I would be stuck on one ROM for hours before moving to the next one. My current set up allows for about 30-45 minutes per ROM to test. This is much more reasonable than 4 hours each, don't you think? If you decide to do test it yourself and want to share, then be my guest.
8. I didn't see you use xxxxx version of a build. Why is that?
I either don't have access to that build, or it isn't a WVGA build. If it is a WVGA build and I don't have it listed, send me a link, and I'll test it out.
9. Can I test the ROMs too?
Sure, why not? I won't use your results, though. There was a massive flame war in the aforementioned original thread that was partly fueled by other users posting results. I don't plan to start any nonsense here.
10. Would you mind testing a custom ROM for me?
YOU MUST GET THE CHEF'S PERMISSION FOR THEIR ROM'S RESULTS TO BE POSTED. I need them to PM me with an ok. I basically want it in writing. NOTE: Once a chef says it's ok to test, I will not remove them from the tests; make sure they understand this.
11. Why am I getting different results?
There are several little nuances that can influence the results in minor ways. If you're getting significantly different results than I am, then I'll look into it again. Keep in mind that using a different device than I am may affect the results as well. However, I will not use any other users' results without verifying them myself.
12. Some of this material looks familiar. Did you steal this?
Yes, basically I did. I figured I'd restart something similar for reasons I've mentioned as well as making it more Rhodium specific. Besides, the original poster, daeron.be, hasn't even logged on in a long time. His thread hasn't been updated since September of 2009 as well. I'm going to use most of their formatting and previous material to build on. If someone has a legitimate problem with this, then PM me.
13. I don't believe that you got "X" results with "X" ROM! I think it's WAY better than all the rest!
I don't care what you think. That isn't a question anyhow. I'm doing this for myself and sharing with you all. Either take it for what it's worth or do it yourself.
14. You didn't respond to my post. What gives?!
I have a life. I'm on XDA way more than I should be as it is. I will generally respond to questions and the like. If you just post to say "Good job" or "Thanks, man," don't expect me to respond. I might, just don't expect it. Just consider this answer here as a general "Thanks" and "You're welcome."
15. You're from New Orleans? What's it like?
People are wonderful; food is amazing; Mardi Gras rocks. Let's keep the thread on topic, please.
Requests
If someone wants to change the BG colors of the spreadsheet to something they like better, be my guest. If I like the colors, I'll keep it.
Please take the poll at the top of the page. If enough people use this thread with other devices, then I will consider moving it to the Chef's Central forum.
I am slowly adding custom ROMs to the results. I need a few people to notify me when the ROMs you're using are updated. This includes Energy, Simplicity, DeepShining, Core Cell, and other popular ROMs.
Custom ROM testing
Ask your chef if he/she would mind having their ROM(s) tested and compared in my results. See below for rules:
All custom ROMs would be separate of the clean builds, but compared all together.
Understand that once permission is given, it cannot be taken away. (I don't want anyone trying to revoke permission after results are posted to take advantage of my system.)
Have the chef PM me with the green light if they want it included.
All results will either be performed by me, or verified by me.
I will not measure battery performance. See FAQ.
These results are not conclusive to picking a "good" ROM. It's a jumping off point. Test yourself and see which one works for you. This tests certain factors of the ROMs. This doesn't test for stability or feel of the ROM. Do that yourself.
Chefs are allowed to "pick and choose" which ROMs they want tested. If they cook multiple flavors or builds, they can decline to have certain ones excluded from results.
If you have a problem with my methods, you are welcome to do them yourself. I am doing my best to ensure that this is as objective as possible.
Contact
If you feel like contacting me or need to request info or whatever, you may PM, e-mail, or message me on Twitter.
Donate
Coffee keeps me cranking out results. DONATE to keep the caffeine flowing. If I see that you've donated, I will probably take a bit more care in listening to your problem/suggestion/comment. Make sure that you include your XDA user name so I can give you credit.
beautiful... cant wait to see results
Subscribed.
Imho you should test blank WM builds. Or at last be sure that the EXT/XIP packages are same. However the idea of testing different builds fits me.
Shame that usually the fastest builds leak memory like hell.
Jackos said:
Subscribed.
Imho you should test blank WM builds. Or at last be sure that the EXT/XIP packages are same. However the idea of testing different builds fits me.
Shame that usually the fastest builds leak memory like hell.
Click to expand...
Click to collapse
I used to believe that until we started seeing the 21680 and 21681 builds come out. They really are quite faster than most of the others. When NRG was using the 23xxx builds, that was the case where the faster they ran the more memory was "spirited away," so to speak. I'm finding a much more stable experience with the 21680 and 21681 builds than most that I've seen.
In any case, the results will speak for themselves. The first three should be posted in a few hours or so.
For anyone who missed it, I've posted the first test file. I only did a single test for each one. In the future I will do an average of three results per test. I only did a single one due to time constraints mostly. That being said, this first file is just a test both for me and for anyone viewing to get a feel for what it's going to look like.
Any questions; let me know.
cajunflavoredbob said:
Requests
The first thing I could use help with to speed up my testing is for someone to point me to the reg key that disables Sense. This would make it easier for me to just drop it into XDA_UC to have the changes made automatically.
[..]
Click to expand...
Click to collapse
This isn't a reg key, but I think there are mortscripts that disable Sense. Maybe this might help?
http://forum.xda-developers.com/showthread.php?p=8684203
I think JVH3 talked about scripts that disable sense too, so perhaps he might be able to help you out there too?
Great work, this is really interesting!
Using mortscript you can do this:
Code:
RegWriteDword("HKLM","\Software\Microsoft\Today\Items\" & ManilaName,"Enabled","0")
RedrawToday
Sleep(5000)
ManilaName is usually HTC Sense, I think. The sleep can probably be shortened. Nice thread!
why not just build a rom free of all ext packages?
just sys and oem packages.
that way it is a better comparsion of sys builds.
no?
sh4d0w86.
cajunflavoredbob said:
The first thing I could use help with to speed up my testing is for someone to point me to the reg key that disables Sense. This would make it easier for me to just drop it into XDA_UC to have the changes made automatically.
I could also use the reg key that sets the device into flight mode for the same reasons.
Click to expand...
Click to collapse
Disable Sense:
Code:
[HKEY_LOCAL_MACHINE\Software\Microsoft\Today\Items\HTC Sense]
"Enabled"=dword:0
Flight mode on boot:
Code:
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Power\State]
"Phone"=dword:00000000
[HKEY_LOCAL_MACHINE\Software\Microsoft\RIL]
"LastEquipmentState"=dword:00000001
[HKEY_LOCAL_MACHINE\System\State\Phone]
"Status"=dword:00400030
"Radio Ready State"=dword:00000000
Random offtopic: I believe that all roms should have the radio turned off by default.
Jackos said:
Random offtopic: I believe that all roms should have the radio turned off by default.
Click to expand...
Click to collapse
I'm curious, why?
seeM_ZA said:
I'm curious, why?
Click to expand...
Click to collapse
Because not anyone wants to run the Connection setup after rom upgrade? Not anyone wants to get all those sms messages right after flash. It's just more convenient then taking the sim card out and putting it back into the device when you're ready (not healthy for the card too).
Not to mention the CDMA phones without simcard, having the radio enabled by default in ROM must be a pain in the ass if you flash several times or hardreset to test different software!
Excellent work on this, cajunflavoredbob!
I look forward to reviewing the results that you come up with on your comparisons.
I am already interested in some of the results that you found in the first tests and will watch that pretty closely.
One thing that I noticed - when I first opened the spreadsheet the colors pretty much come on like a freight train - can those be toned down a tad? These old eyes finally adjusted to them but a lighter shade of colors may be more aesthetic...
Thanks for this contribution!
sh4d0w86 said:
why not just build a rom free of all ext packages?
just sys and oem packages.
that way it is a better comparsion of sys builds.
no?
sh4d0w86.
Click to expand...
Click to collapse
If you read the first two posts, I addressed this twice. That's what I plan to do. I need to get a feel for this myself and find ways of doing it quickly before I move on to the kitchen.
Jackos said:
Disable Sense:
Code:
[HKEY_LOCAL_MACHINE\Software\Microsoft\Today\Items\HTC Sense]
"Enabled"=dword:0
Flight mode on boot:
Code:
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Power\State]
"Phone"=dword:00000000
[HKEY_LOCAL_MACHINE\Software\Microsoft\RIL]
"LastEquipmentState"=dword:00000001
[HKEY_LOCAL_MACHINE\System\State\Phone]
"Status"=dword:00400030
"Radio Ready State"=dword:00000000
Random offtopic: I believe that all roms should have the radio turned off by default.
Click to expand...
Click to collapse
Wonderful! Thanks. This will save some time! I agree with you on the radio being off by default. With the number of times I flash my device during the week, it would really help not to hear the alerts going off twenty times when I start up. I use NRG's ROMs by day, backup with Sprite Backup, and then toy with my personal ROM at night normally. Now, of course, I'm going to be flashing even more than that with this new project.
toucan said:
Excellent work on this, cajunflavoredbob!
I look forward to reviewing the results that you come up with on your comparisons.
I am already interested in some of the results that you found in the first tests and will watch that pretty closely.
One thing that I noticed - when I first opened the spreadsheet the colors pretty much come on like a freight train - can those be toned down a tad? These old eyes finally adjusted to them but a lighter shade of colors may be more aesthetic...
Thanks for this contribution!
Click to expand...
Click to collapse
I can't promise you that I'll get to it, but I'll put it on my to-do list. I basically stole the formatted speadsheet from the other thread. I was about 2/3 of the way through with making my own, when it dawned on me that there was probably one already made. Their formulas covered some things I hadn't yet thought of, so I'm going to be using this for a while.
In other news, I'll be working on this again today, so check for updates tonight. I'll post any updates in the second post.
cajunflavoredbob said:
To-Do List
Change crazy background colors on spreadsheet.
Build clean ROM based on latest T-Mobile shipped ROM
Clean up first post.
Finish learning Italian.
Click to expand...
Click to collapse
One down (see attached).
piaqt said:
One down (see attached).
Click to expand...
Click to collapse
Thanks, but I still need the backgrounds. It helps me find the fields more easily. I'm going to experiment with different colors soon. This isn't my top priority, though. I think, lighter, not brighter colors would do better. We'll see what happens. I'm working on cooking the new ROM right now. Well, not right now, but I'll be starting soon. Hopefully I can get this completed within the week. I can only flash/work at night on this as I need a functioning device during the day.
cajunflavoredbob said:
Thanks, but I still need the backgrounds. It helps me find the fields more easily. I'm going to experiment with different colors soon. This isn't my top priority, though. I think, lighter, not brighter colors would do better. We'll see what happens. I'm working on cooking the new ROM right now. Well, not right now, but I'll be starting soon. Hopefully I can get this completed within the week. I can only flash/work at night on this as I need a functioning device during the day.
Click to expand...
Click to collapse
Haha... I wholeheartedly agree - it is absolutely necessary to have the colors - but perhaps not so bright!

Categories

Resources