I am aware that this has been asked many many times, but i don't see a thread for this issue. I would like to know what attemps have been made to get some sort of support. I am by no means a developer, but i will try my best to get things running. Would it be something as simple as taking a a file out of a current android phone with the same specs and modding for use with a touch pro.
I'm simply curious if there is a thread or website around that discusses this and other issues in more detail.
I'm no kernel hacker, but I am...curious.
That's what i would like to know. facts about how far the development is. Maybe we could start a thread that has such progress stated. Where only the devs would be able to post, so we can have us a look.
The best you can do is read the IRC logs from #htc-linux. I think I recall reading in the logs that klinux had gotten OpenGL working on the Pro2, even with applications like Neocore (thought they're apparently slow).
You have to be a little bit more clear on what you mean by "open gl working".
I'm the developer who was working on the open gl for the klinux build. Bottom line is that open gl is working, but not with hardware acceleration. We used then nexus one drivers (adreno200) to enable things a live wallpapers. But it's so slow its not even worth it.
Now to get hardware 3d working 100%? a lot more work and testing. lol.
Well is hardware 3d working for any of the current android ports in any capacity?
Also, I'm so used to reading hardware specs in Desktop computer form. But with these phones, the only thing I know about them is the CPU manufacturer, model number, and speed.
Is there a separate chipset that handles audio graphics etc, or is it completely SoC.
I read about recent Android ports on the iPhone, and it seems they already have things like external audio working. Is this because the hardware on the iPhone similar to another HTC Android phone, more so than the hardware in the Rhodium?
awesome thread... actually informative and supportive.
i think what the OP is saying is how can us lowerscale highend users be more involved, perhaps in the debugging, data gathering... we could start a -sub group dedicated to each corresponding issues... bill gates didnt invent windows, him and his crew did. the more the merrier eh?
I have a long running reverse engineering thing going on. I have been looking for more info other than IRC. I would like to put my good skills to work w/out starting from scratch. Any info?
EDIT: I did find this, It has some helpful starting info: http://www.androidonhtc.com/wiki/Get_Involved
This is a great thread! I've been wanting to get in on some of this action. Hopefully this will reduce some of the clutter in Reefer's thread.
I meant to get hardware acceleration working. How far has this come along since i posted this??
Only Diamond / Raphael has hardware 3D enabled so far.
Very limited 3D for "low resolution" could be enabled in blackstone or other devices with workaround but that is somehow meaningless.
phh has tried different combinations of memory allocation but in vain.
so am I... given up at the moment.
mcdull said:
Only Diamond / Raphael has hardware 3D enabled so far.
Very limited 3D for "low resolution" could be enabled in blackstone or other devices with workaround but that is somehow meaningless.
phh has tried different combinations of memory allocation but in vain.
so am I... given up at the moment.
Click to expand...
Click to collapse
Phh recommended to trace down mem locations used by wince and that has been done but it still refuses to fire up once pmem.c is modified.
Recently i got the wince dmesg from my rhod in hopes that a cold boot would show as to how the 3d is being activated but that also showed no results. I get this crap when Manila is launched.
[ManilaToday](34156): ### Launching manila ###
23:20:09 [DISP] DrvEscape::HTC_SET_3D_LAUNCHING_FLAG.
I'm not sure what HTC_SET_3D_LAUNCHING_FLAG is.
The next step would be to make an android app and trace down what the hell the libgles_qcom driver is actually doing to see if it is working properly. If you load up ahi2dati.dll on winmo you can actually use the functions to show crap on the screen so i'm hoping the same can be done on android.
Not sure what else can be done at this stage.
[ACL] said:
Phh recommended to trace down mem locations used by wince and that has been done but it still refuses to fire up once pmem.c is modified.
Recently i got the wince dmesg from my rhod in hopes that a cold boot would show as to how the 3d is being activated but that also showed no results. I get this crap when Manila is launched.
[ManilaToday](34156): ### Launching manila ###
23:20:09 [DISP] DrvEscape::HTC_SET_3D_LAUNCHING_FLAG.
I'm not sure what HTC_SET_3D_LAUNCHING_FLAG is.
The next step would be to make an android app and trace down what the hell the libgles_qcom driver is actually doing to see if it is working properly. If you load up ahi2dati.dll on winmo you can actually use the functions to show crap on the screen so i'm hoping the same can be done on android.
Not sure what else can be done at this stage.
Click to expand...
Click to collapse
Ok, i would love to help out as i have never rly done anything like this b4. What exactly are you doing. How do you get HTC_SET_3D_LAUNCHING_FLAG?
How would i open a .dll, i dont think these can just be opened up to see what they are doing. I am on the dark side of the moon here. I know whats going on, but have no clue what to do to help.
garage_man said:
Ok, i would love to help out as i have never rly done anything like this b4. What exactly are you doing. How do you get HTC_SET_3D_LAUNCHING_FLAG?
How would i open a .dll, i dont think these can just be opened up to see what they are doing. I am on the dark side of the moon here. I know whats going on, but have no clue what to do to help.
Click to expand...
Click to collapse
I actually found HTC_SET_3D_LAUNCHING_FLAG on the wince dmesg. You can do this by doing a pwf dump.txt 0x16a00000 0xFFFF0 in haret. I did it after a cold boot to see if anything is done to the gpu once wince boots.
Loading the dll is easy. just make a simple win32 app and do a loadlibrary. This part works but it's not helping on android. I'm interested to see what mcdull thinks since i think he has ventured a lot into this as well. Right now if we can make a simple app in android to load the libgles_qcom.so directly and trace every step, i think that would be helpful to see where we are failing. I'm close to giving up..lol i already took 2 sick days from work to get to where i am now so i could use some help.
Here is what i got out of the chip in wince.
name: ATI HandHeld Interface
versions: 2.07.05110.34681
Revision: 0
ChipID: 1362104322
revisionid: 0
TotalMemory: 15990784
BusInterfacemode: 2
InternalmemSize: 262144
ExternalMemSize: 0
Surface info: 800x480
surface total bytes 768000
dwFrameBufferPhysical=0x14c00780 m_dwFrameBufferVirtual=0x57e00000 dwFrameBufSize=0xbb800
Most people here could probably not help with the hardcore kernel dev stuff, but I guess if you need memory locations or so (be it for opengl/sound etc) I think there a a LOT of people that are willing to run some apps that dump a txt file with debugging info & mem locations to their SD-card and send you that
I would love to help with developing, even if it means that I have to boot into winmo and android all night long and gather certain information, memory-adresses, try different versions of programs with all kinds of parameters etc.
Star-Lite said:
Most people here could probably not help with the hardcore kernel dev stuff, but I guess if you need memory locations or so (be it for opengl/sound etc) I think there a a LOT of people that are willing to run some apps that dump a txt file with debugging info & mem locations to their SD-card and send you that
I would love to help with developing, even if it means that I have to boot into winmo and android all night long and gather certain information, memory-adresses, try different versions of programs with all kinds of parameters etc.
Click to expand...
Click to collapse
We need more devs in general. I ran a trace on a basic app that runs 3d. So there is still a lot of crap to examine.
I'm willing to kill my touch pro 2 and remove the CPU to trace the JTAG locations but I only have the datasheet from the MSM7200/7500, not sure if it will be the same locations. I bet if I hooked up my Segger I could see exactly what is failing on the OpenGL and sound side since alot of hardware debugging is done this way...just sucks I dont know for sure if the pinouts are the same. I'm done it on quite a few different phones and boards over the years so its not a big deal. Omap3430 was simple to trace and the OMAP3530 had the exact pinouts.
BinaryDroid said:
I'm willing to kill my touch pro 2 and remove the CPU to trace the JTAG locations but I only have the datasheet from the MSM7200/7500, not sure if it will be the same locations. I bet if I hooked up my Segger I could see exactly what is failing on the OpenGL and sound side since alot of hardware debugging is done this way...just sucks I dont know for sure if the pinouts are the same. I'm done it on quite a few different phones and boards over the years so its not a big deal. Omap3430 was simple to trace and the OMAP3530 had the exact pinouts.
Click to expand...
Click to collapse
Sounds crazy.. i love it.
I was messing around today and made a small app to load the libgles_qcom.so directly to see if i can replicate my winmo success. Most of the ahi functions are included in the android driver as well except for AhiDispSurfGet which made it impossible for me to draw anything on screen.
The chip did pump out the same info as i posted before and it matches so thats a step in the right direction. Means we can recognize the chip with no problems and all 15.25 memory is reporting as well. If i had more documentation on those functions exported im sure i can get the chip to try to display something directly.
Interesting bit of info I read and perhaps someone can clarify this here. The Sprint Touch Pro 2 uses the Qualcomm MSM7600 processor. The AT&T Tilt2 (GSM phone) uses the MSM7201A processor. The "A" refers to the smaller 65nm die size (I believe).
From what I've read, some changes occurred on the MSM7200 -> MSM7201 due to patent infringements. The next question is, is the MSM7201A and MSM7600 essentially the same chip, just different hardware for CDMA/GSM?
I guess the "libgles_qcom.so" library is used in many other HTC Android phones, but for some reason it's failing on the touchpro2/tilt2, and we're not sure why (although logically it sounds like the library should work as it's used by other android phones with the same chipset)? I'm no kernel dev (I write .NET/c# apps which are much easier than kernel stuff), but am somewhat familiar w/ linux and perhaps can assist in development..
NewbTrader said:
Interesting bit of info I read and perhaps someone can clarify this here. The Sprint Touch Pro 2 uses the Qualcomm MSM7600 processor. The AT&T Tilt2 (GSM phone) uses the MSM7201A processor. The "A" refers to the smaller 65nm die size (I believe).
From what I've read, some changes occurred on the MSM7200 -> MSM7201 due to patent infringements. The next question is, is the MSM7201A and MSM7600 essentially the same chip, just different hardware for CDMA/GSM?
I guess the "libgles_qcom.so" library is used in many other HTC Android phones, but for some reason it's failing on the touchpro2/tilt2, and we're not sure why (although logically it sounds like the library should work as it's used by other android phones with the same chipset)? I'm no kernel dev (I write .NET/c# apps which are much easier than kernel stuff), but am somewhat familiar w/ linux and perhaps can assist in development..
Click to expand...
Click to collapse
learn haret/haretconsole and take a look a the kernel. good place to start. Feel free to come into the irc board if you have any questions
Took a look back for a few pages, and did a couple quick searches. Didn't quite find enough info.
I am wondering the best approach to take when converting a program to be compatible with and run on windows mobile.
I don't currently know any languages so, I would have to start learning from the beginning.
Thanks for any info
from the little I know about programming, the way an application (or games) works on windows is nothing similar to the way a program runs on windows mobile, so you would actually need to start from scratch... There are however some tools to make the job easier with older programs, like Dosbox... but I don't know if it's what you want.
The most amazing think for me is that, out os 61 views on this topic, the only person that bother to answer is NOT a developer (me)
Convert app? Impossible. With source code it is possible, if you adjust UI to fit the screen and get over some limitations and many other things.
Good is .NET on this, because if you install .NET CF on your PC, you can run apps built for winmo directly on your PC. Only issue is when it tries using other than normal libraries from GAC and tries using InterOp. That library would have to be recompiled for win32, rather wince-arm (back to 1st part). The same, the app has to be made that it is compatible with both file paths - remember that WinMo doesn't use C:\Windows but \Windows etc. And .NET CF is highly limited compared to desktop version.
Thanks for the replies.
I'm not looking for a simple way to convert programs as I'm sure it is impossible. I'm expecting to have to pretty much start from ground up.
I've seen some games such as Pocket Diablo(some others here http://www.jamesbeckingham.com.au/Default.aspx) as well as Starcraft that someone here was working on.
But I'm just wondering the best approach to do work like these guys. As there are some games I would like to bring to mobile.
These games work pretty much that people make the engine from scratch, with many hours in disassemblers, hexeditors etc they find out how does the engine load graphics from those huge files etc and they add it to their engine. Usually.
Its possible... but often more work than it is worth
OndraSter said:
These games work pretty much that people make the engine from scratch, with many hours in disassemblers, hexeditors etc they find out how does the engine load graphics from those huge files etc and they add it to their engine. Usually.
Click to expand...
Click to collapse
Exactly. The hours put in to "porting" these apps to windows mobile is often close to the work it would take to make the game from scratch. So if you are not familiar with coding, disassembling code is far outside your scope. However, when finished, these games have more of an original feel, but often work less effective. This is due to the translation of using mouse clicks to touch input. Games such as diablo rely heavily on having two mice buttons to click. A total remake would be less like the original but might compensate for the new control scheme.
Both ways are possible, but they are both also complicated and involve a great deal of work. Not to mention how unhappy blizzard is with people using their artwork, even if the game is absolutely free.
Sorry but, none of you are really being helpful..
I do not expect this to be easy. I am expecting it to be a long process, and telling me something that I already know over and over doesn't help me get started. I've already said that I expect to probably have to rebuild these from ground up..
I know what is ahead of me and want to do this stuff, other wise I wouldn't be asking.
So if anyone knows the process or at least where I could get started. Please let me know. Otherwise I'll just start with Java then C# until I find my own way into doing this.
From personal experience of porting a game ( http://forum.xda-developers.com/showthread.php?t=717274 ), it will take awhile. Here is the process I used when making the game:
1) Collect image resources if any are possible to be used.
2) Research what kind of engines to use. I made the mistake of trying to use the basic image function in C#.net, which was a waste of time. Then I switched to GDI+ and haven't had any problems since.
3) Make a list of things you want to do on the program. From the required things to the extra fancy features. Sounds are extra features.
4) Prototype A LOT. Find what you want to accomplish, break its parts down into basic actions, then prototype of how to do that action.
As a language to start with, I personally recommend C#.net because its easy to use. It doesn't have the speed of C++, but it does have the #region/ #endregion functions which have helped me ENORMOUSLY with writing code. The region code can be minimized. With 2000+ lines of code per class and about 20 classes, minimizing code makes moving around easier.
Check the XDA boards or search online if your lost. If you need more help on porting code or making functions to do specific actions, message me and I'll gladly help.
I've been reading the forums for two days now and have gleaned lots of useful information in the dumping/building of WP7 (emulator) ROMs. I haven't, however, come across any information on replacing modules in the WP7 context.
While reversmode generates correct-looking output, it renders the built ROM unbootable; I'm guessing it's not built correctly.
To backtrack what I did...
I used the newer dumprom.pl, which spits out better PE binaries than its predecessor
I dropped a binary into reversmode
... and gathered the imageinfo.txt + Sxxx output and dropped them into the dumped ROM\MODULES\filename folder, overwriting the originals
Any guidance would be appreciated.
// twitter: @WithinRafael
Sorry for getting everyone excited, I found the error in my ways. I wasn't aware (until now) that the binaries spit out by dumprom.pl are automatically decompressed. I used XIPPort to recompress my binaries (and fished them out of a folder relative to the executable).
Boots fine.
On a separate note, I'd like to rally everyone together and start getting better configuration management of this stuff. From what I've seen, these tools are spread out all over the damn place. Worse, the developers aren't including versioning information. I'm going to draft up some ideas on addressing the confusion and create a separate post.
WithinRafael said:
Sorry for getting everyone excited, I found the error in my ways. I wasn't aware (until now) that the binaries spit out by dumprom.pl are automatically decompressed. I used XIPPort to recompress my binaries (and fished them out of a folder relative to the executable).
Boots fine.
On a separate note, I'd like to rally everyone together and start getting better configuration management of this stuff. From what I've seen, these tools are spread out all over the damn place. Worse, the developers aren't including versioning information. I'm going to draft up some ideas on addressing the confusion and create a separate post.
Click to expand...
Click to collapse
yeah you may want to just start a thread with consolidated dumping/porting tools for these ROMs so we don't have to easter egg hunt
One thing that I seem to notice is that even though this forum may have some releases that people can use it seems to lack both information and tools to get into trying to help the community. Some people, such as me and im sure many others, have some, even if only basic, skills but the process of applying them to the field of Windows Phone. For example a while back I wanted to tinker with the Windows Phone emulator but I failed to find working tools to dump and reconstruct the ROM and sadly no documentation to look at the format to see whats going on. I once saw a tool for HTC ROM's I think but that has since disappeared. Some of the old formats are at least partially known but burried somewhere deep in this forum where it becomes a pain to find them.
Specifically I would be interested to know if there are ways to actually debug the assemblies using tools like IDA on either the emulator or an actual phone (even though they were compiled to different instr sets they still probably mostly share the same code). I am also wondering what tools could be used to atleast compile native binaries, even if they can't be executed yet.
I personally have a little reversing experience and a fair amount of coding experience yet the current barrier of lack of information seems overwhelming and deterring. I can't say I will have either the experience or time to get us all further but I wouldn't mind tinkering with my phone and/or it's operating system and isn't that the whole point of this community?
It would interest me if there are others who feel the same way and whether there are others out there who could maybe help to get others started. XDA has a wiki but it seems to be mainly "consumer" orientated.
Hello everybody,
So these days I've been interested in theming MotoBlur since I had PS skills and wanted to put them to use since being 17 and with so much free time I said it might not be THAT hard.
However, **** happened.
Finding out those pesky MotoBlur apps wasn't that hard - found it rather easily after checking up a system backup.But finding out the MotoBlur apps wasn't the problem - the problem were the apps.
This is how a simple .apk file (MotoBlur Phone app) folder looks like:
http://i279.photobucket.com/albums/kk125/secretalex125/untitled.jpg
See that little thing there? Yeah, you're seeing right - that is the Motorola FlipFlop (or how it's named) phone. But God, why?
Don't ask me; ask Motorola. This may be the reason why they ended up making a striped version of their newer phones' skin/OS updates' skin.
Not to mention these images come up with .xml files. Now, as a dumb idiot with relatively limited text editing (.xml / .ini / whatever coding files) knowledge, but still a basic one enough to know not to screw up with the position of some text, I know that checking up ALL these files would be a damn hard task. Not to mention editing them properly. However, I'm in for the images. And I'm somehow sure that some of these files are pretty much useless. So they should be deleted. But then, when you have 2 apps called "BlurContacts" and "BlurPhone" and notice both of them feature pretty much the same images in some folders, you know you're screwed.
But this is only the foreground idea. The background, the immense sea of files is what is annoying. How could someone be able to create an entirely new skin? All that comes in my mind is that he must be a masochist.
So questions pop up:
1. Did anyone else try to skin ALL the files?
2. Did anyone try to remove files?
3. I know that out there is only one more GB skin. One more. But is it any better?
4. Are there replacements? How easy is to replace these files? Would simply removing these Motoblur apps make my life easier and revert me to classic Gingerbread?
4. I think there's more on my mind, but it doesn't come up right now.
All in all, I don't like what I'm seeing.
I was able to theme almost all motoblur apps when I was on ms2ginger rom, so it was the gb version of defy. I didn't remove any of the files, but yeah it takes some time to understand where goes what.
Sent from my ICS Defy