Database Users

Fix your ATI ImageON woes with this patch!

So, after a day with my AKU3.3 equipped 8525, Platform Builder, IDA Pro and HexCmp, I believe I've finally gotten to the bottom of the ATI ImageON acceleration bug. This is the bug that causes the screen to "tear" during accelerated video playback using CorePlayer, TCPMP or other players that take advantage of the ImageON hardware acceleration. Once this bug is occuring, the entire screen is unreadable until you somehow exit from the video player.
Note that even after this patch is applied there will still remain some "pixelation" artifacts. However, there's a great thread on CoreCodec.com that can be found here. The thread explains how to resolve most of these. Consider that thread "extra credit" though since all in all, this patch alone resolved about 90% of the ATI issues with my AKU2.3 test device (running the South African 1.35 TyTN ROM).
It was a buffer problem you see....
I've attached a cab which modifies the ATI DDI setup file to the AKU3.3 parameters. I've experienced great results with CorePlayer when using this on an AKU2.3 hermes. I only had to check all the boxes in CorePlayer's ATI IMAGEON setup page. By Default, 2 aren't checked:
"Green Tint" bug compensation
Keep ATI driver active (just test)
I believe it is the second parameter that corrects an out of memory crash when a clip is played in full screen mode the second time.
The above settings are workarounds however since the full benefits of this fix will only be available if the setup file is used in conjunction with the latest versions of the ATI drivers. Unfortunately, these drivers must be "baked" into a ROM. Do not try to install these drivers! You will brick your device if you do and a hard reset will be necessary to fix. Install the attached cab file instead and wait for the chefs here to build the new drivers into their next ROM release.
ROM Chefs: you can find the files that make up the release here
Delete the old versions and bake all three files in the zip into the /windows directory.
Now to the Technical.
ATI released 3 files as part of their DDI update: ace_ddi.dll, ahioem.dll and a hidden little configuration file named atihwtbl0.txt. It's this little text file that contains the magic since ace_ddi.dll uses it to configure several settings at startup. I haven't fully analyzed the changes yet and am in the process of doing this now but at first glance they appear to either move or increase the size of several video buffers in memory. It almost looks like there was an overlap issue with audio buffers
Anyway, enjoy this little patch!
As always, while I'm pretty sure that this patch will rock your ATI world, I take no responsibility for any "undocumented features" that may crop up. I've only done minimal testing on the TyTN 1.35 ROM so far. It must be right though... there weren't any syntax errors.
Installation instructions:
Download the attached CAB file
tap to install (it will ask to reset your device)
note: you must install this to your device. The patch won't work if you install it to a storage card.
If you experience side effects, removal is simple. From Settings->System->Remove Programs just remove "Sleuth's ATIFix". Be sure to reset your device after the uninstall finishes.
edit:
It's important to read the TyTN thread located on the CoreCodec forum. Here is the link to that thread. There's a lot of good information concerning the scope of this patch (which takes the form of AKU3.3 experiences) and what still remains to be done. In this thread, schriss does a good job benchmarking the ATI playback and also has some good suggestions, some of which I'm hoping will be implemented in future versions of CorePlayer (such as allowing a YV12 option for the ATI decoder). Also, as the thread points out, DivX decoding using the ImageON remains a challenge (like I said, my patch alone solves about 90% of the issues). Hopefully more will now be able to focus on this once the Hermes DDI setting modifications encompassed by my patch become ubiquitous.

i see you been busy to! thanks man.

Thanks Sleuth,
WMXL v0.30 will incorporate this fix.

Just tried, works perfectly! thanks!
(installed on WMXL.1)

Nice to hear Your post reminds me of something else:
Those of you running WMXL .2 already have the driver portion of the fix baked in. Installing this patch will give you full functionality.

Sleuth255 said:
Those of you running WMXL .2 already have the driver portion of the fix baked in. Installing this patch will give you full functionality.
Click to expand...
Click to collapse
since this patch also appears to be working with the older set of ATI DLL's, what's the "full functionality" what you're talking about? what functions are missing now? I didn't really see any differences playing with TCPMP with AKU3.3 and now with this patch on WM6.......

I experienced intermittent crashes on AKU2.3 when running full screen video if the driver wasn't set to remain active. This problem didn't crop up in my WM6 build that had the new drivers.
The problem appeared to be completely resolved in TCPMP/CorePlayer by simply checking all the boxes in the ATI IMAGEON setup screen however.
However, being a purist, I like to see the config file along with its matching driver running.

Lovely Jubbly! and Sleuth, thank you for all your time and hard work with this
Mike

WMXL extras updated sir. Bloody brilliant work!!

Heimiko said:
since this patch also appears to be working with the older set of ATI DLL's, what's the "full functionality" what you're talking about? what functions are missing now? I didn't really see any differences playing with TCPMP with AKU3.3 and now with this patch on WM6.......
Click to expand...
Click to collapse
Same here but as Sleuth said it was more for fixing crashes in a sense, my cingular device running a wm5 rom without the new drivers now don't crash when using this patch, though ofcourse I still get garbled boxes when playing divx files when I enable acceleration, while x.264 plays perfect when set up right with or without acceleration enabled.
My softbank tytn running xdalive .20 runs good as well as before my device froze at times when using ati video with and without acceleration enabled playing fullscreen. I get a good 20% increase now being able to use it compared to DirectDraw. Thanks for the fix

thanks man...
we were all waiting for this to come

I installed the .cab to the device and checked the two default unchecked boxes on the ATI page in TCPMP.
I opened a divx file and the audio and video were off. I performed a soft reset and everything is now perfect. This is a great find.

Advanced encoders: check out the link to corecodec on post 1. There's a lot there regarding how to optimize encoding for the accelerator (plus a few odd quirks too).

Thanks man. I will test ASAP (now my TyTN is in the hands of my wife that is playing "Ladybugs" game. Nobody in the world is dare enought to even think in ask her for a five minutes check)

Admins do you think this is worthy of a sticky?? Im still trying to root around in the coreplayer forums to find a recommended bitrate/codec etc... to encode our vids into.

I just went through the coreplayer thread again. Perhaps you might want to pm schriss for his opinion on the corecodec forum. At any rate, it looks like DivX is still a problem for the ImageON so I would avoid encoding with codec that fttb . I don't know if its Coreplayer or Hardware though (suspect the former however).

I try to install that CAB on my DOPOD U1000, after reset never can boot up again need to hard reset the device, someone can help to fix this problem?
Thanks!

That's an HTC Athena simdao! This patch is Hermes specific. As you have determined, "Undefined results" can occur if you install this patch on a different device.
Slightly OT here, but does your Athena suffer from ATI based DivX rendering issues? What other ATI ImageON issues do you have with it?

Sleuth255 said:
I just went through the coreplayer thread again. Perhaps you might want to pm schriss for his opinion on the corecodec forum. At any rate, it looks like DivX is still a problem for the ImageON so I would avoid encoding with codec that fttb . I don't know if its Coreplayer or Hardware though (suspect the former however).
Click to expand...
Click to collapse
The videos i have encoded using AutoGK, its good because i can just queu up the videos to encode and leave it running. Depending on the program i am encoding i set the filesize accordingly:
60mb for a cartoony show (family guy, futurama, simpsons etc...) approximatly 25 mins (so 2.4mb per min?)
120mb for a filmed program (friends, mythbusters etc...) again approximatly 25 mins (so 4.8mb per min?)
128kbps VBR MP3 for audio (fine for all movies)
fixed width of 320 (the program adjusts for the aspec ratio of the source)
XVid Mpeg4 (2 pass)
I used this encoding method since having success with TCPMP on one of the early iMate roms, since the South Africa HTC rom arrived all the roms since have played back on TCPMP/Coreplayer no problem with the rawframebuffer setting. Since the AKU3.3 test rom i have been using ATi Imageon setting instead and get MINIMAL artifacts onscreen with my files.
Worth a go???

Following mrvanx advice on this and another thread...
I used AutoGK and set parameters as follows:
fixed width 320
Predefined filesize 400mb
128VBR mp3
XviD Mpeg4 (2pass)
This was done on a DVD quality divx file, and produced a 400mb file which played back near flawlessly on the hermes, minimal artifacting, and much better quality than even my ipod! Great stuff
Thanks,
J

3D Viewer

Hello pipl !
Someone know if exist a 3d file viewer for WM5 - WM6?
I need to view mainly stl format, better if iges and step too.
I know something about 2d cad, but found nuthin' about 3d.

This probably isn't quite what you're looking for but Blender for pocket PC will import some files and it's free.

Thanx, little bit difficult, lot of commands, something easier?

Yah i wouldnt mind 3dsmax on my touch.
I was going to try blender but it says something about using one tool and you will have to do a hard reset.My memory is bad so i know i would hit it.

http://pocketpccentral.net/software/cad.htm
prob only does cad file types though

Rudegar said:
http://pocketpccentral.net/software/cad.htm
prob only does cad file types though
Click to expand...
Click to collapse
Thanx, but I found only 2D support

Here's one! Only stl files.
R2V3DMobile
http://www.real2virtual.com/downloads.htm

has anyone had any luck with blender on a cdma touch pro?
I have the 3d version installed but the font is almost too tiny to even see with a magnifying glass even though it seems scaled for a much larger screen.... ie.... many of the tiny fonts over-lap or cut off others
and it is very very sluggish
so far I've not been able to have it open the font and language settings under preferences.
Also doesn't seem to want to close by merely pressing "quit blender" under the file menu.
The one I loaded is about 8 or 9 megs

oh. old thread to bring back on top. aware that the prew post is 10 months old are you?

2D Driver Development Project - HTC-CA & Team P3D go 2D!

*** PLEASE READ CAREFULLY BEFORE INSTALLING OR FLASHING ANY SOFTWARE POSTED IN THIS THREAD ***
The software posted here is for TESTING purposes only, Team P3D or any of the posters of software, or links to software on this thread take absolutely no responsibility or liability for damage caused by the result of installing or flashing software or links to software found on this thread - correctly or otherwise, you do so on the sole understanding that you do so at your own risk.
---------------------------------------------------------------------------------------------------------------------------------------------------------------
Project Name: Polaris 2D Driver Project
Driver Name: P3D 2D Driver (Working title)
Development and Testing Team: SEE Post #2
---------------------------------------------------------------------------------------------------------------------------------------------------------------
ANNOUNCEMENT:
The P3D team would like to extend an OPEN INVITATION to all developers and programmers from all forums of EVERY device to come forward and help us create the 2D driver which, as it is being developed from scratch will require much development work with many dll files created from scratch.
If you are interested in helping, please post your interest in this forum and we will add your name to the developers list. If you would like to help but own a different device to which the 3D driver is yet to be ported to, we would also like to hear from you and hopefully assist you with the knowledge we have gained in return for your efforts here. (actually we'll help you anyway but.. we do want your help! )
---------------------------------------------------------------------------------------------------------------------------------------------------------------
11/10 - BigKVak successfully dumped the G810 rom and work has started in analyzing its content
---------------------------------------------------------------------------------------------------------------------------------------------------------------

P3D 2D Driver Development Team:
Administration/Testing:
Support and Testing:
Bally3
NikMel
Neos2007
BigKvak
Imfloflo
Developers: (TBC)
Rogro82
NuShrike
Chainfire
Monkeyass
maqui01

It started with a few simple questions:
"Can the Polaris be hardware accelerated?"
"Why doesnt the CA Kaiser 3D driver work on the Polaris?"
That was a month ago..since then, thanks to the help and support of NikMel, NeoS2007, Rogro82 and NuShrike to name a few, we now have a working 3D driver which is currently in a version 1 state and with the release of the cab version through CA last night, we can now concentrate on improving speed and compatibility to make better use of the graphic chips capabilities.
My intention then was never to start a 2D driver or work on a 2D driver until I was satisfied no more could be done to improve it and a "final" release was in the cards, but through my own testing and various posts and conversations, I now find myself wondering whether the improvements with 3D is linked to the 2D driver?
From day 1, before we released the 3d driver and after, users have expressed faster speeds in 2d as well as 3d - though many have explained it to be a "placebo" effect, we naturally attributed this to the gpu sharing the workload with the cpu which makes sense in a common sense way - itje posted a humorous answer on his thread explaining this very thing as worth a read just to put a smile on your face, but on a serious note a question has to be asked - Does improvement on 3D really effect 2D and if that is the case, would a 2D driver help improve the 3D drivers perfornance?
So why start a 2D thread when the 3D driver still needs refining?
Well, apart from the question above, the overwhelming requests for 2D support on both Polaris and Kaiser forums (it should work on both in theory), we now have a dump of the long awaited Toshiba G810 rom to get us started- A BIG THANK YOU TO BIGKVAK - welcome to the team!
Originally Posted by BigKvak
I have dumped ROM from Toshiba, here the link http://rapidshare.com/files/152085600/dump.rar.html
Click to expand...
Click to collapse
It is inevitable then that work needs to start on this project. We also need to preserve the 3D thread for future 3D driver developments and defer 2D driver related posts from it, for these reasons, this new thread has been opened for all to start working with the P3D team in bringing 2D greatness to our devices.
Lets share our knowledge and have fun doing it like we did with the 3D driver!
PS: Although I have named the project Polaris 3D driver project, I would like to extend an invitation to users of all devices that could benefit from the 2D drivers creation, after all through CA Kaiser development, we have now ported the 3D driver to the Polaris AND the NIKE and hopefully to many more devices
Let our devices not make us divisive - whats is the point?
It is common knowledge that files from newer devices are used to help create the drivers we need for our devices - so why should we gloat and mock other less supported devices, should we not help them and share our knowledge and in the words of a good friend here "Pay it Forward?"
This is not the spirit of XDA Developers and it is certainly not the ethos of Team P3D - We have and pledge tol share all knowledge with users of all devices.
Besides, its so much more fun when we all work together!

It appears that HTC-CA were already in the process of

Reserved for p3d 4

Reserved for p3d 5

Reserved for p3d 6

Reserved for p3d 7

Reserved for p3d 8

Reserved for p3d 9

Reserved for p3d 10

I found this link on microsoft MSDN: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1214862&SiteID=1
It's a guy asking for a 2d driver library. Maybe we can look into that?

I have dumped ROM from Toshiba, here the link http://rapidshare.com/files/152085600/dump.rar.html
Click to expand...
Click to collapse
To move the discussion of 2d in here..

Windows Mobile 2D and 3D explained on MSDN
I believe this: http://msdn.microsoft.com/en-us/library/aa911096.aspx will be out first place to look. It's mostly there: 2D AND 3D info.
Here's what functions there are:
AlphaBlend API
Provides information about adding support for the AlphaBlend function to your OS design.
Direct3D Mobile
Provide information about adding 3-D graphics support to your OS design and creating applications that use the API.
DirectDraw
Provide information about adding 2-D graphics support to your OS design and creating applications that use the API.
Gradient Fill Support
Provides information about adding support for the GradientFill function to your OS design.
Imaging
Provide information about adding support for compressed still images to your OS design and reference information for the API.
Multiple Screens
Provide information about adding support for multiple displays to your OS design and creating applications to support them.

NeoS2007 said:
I believe this: http://msdn.microsoft.com/en-us/library/aa911096.aspx will be out first place to look. It's mostly there: 2D AND 3D info.
Click to expand...
Click to collapse
reading it now.. some of it we know.. let see what we can learn..

http://msdn.microsoft.com/en-us/library/aa925824.aspx
Here we go:
"Applications direct output to a specified device by creating a device context for the device. The device context is a GDI-managed structure containing information about the device. An application creates a device context by calling device context functions. GDI returns a device context handle used to identify the device.
Applications can direct output to a physical device, such as a display or printer, or to a logical device, such as a memory device.
A device context also contains attributes that determine how GDI functions interact with a device. These attributes eliminate the need to specify every piece of information Windows Embedded CE requires to display an object on a device. If you want to change an attribute, you can use attribute functions to change current device settings and operating modes. Operating modes include text and background colors and the mixing mode that specifies how colors in a pen or brush combine with colors already on a display surface."
GDI is the source of 2D on our devices. Maybe we need to look out for GDI tweaks in the registry?

BPP (Bits Per Pixel) explained
I also found this blog about the colors used on a mobile device. It's said that if you have a colordepth of 18 instead of the usual 8, 16, 32 bits, it's more cpu intensive. Isn't there a registry key for colordepth?
http://blogs.msdn.com/windowsmobile/archive/2005/09/07/462187.aspx
"The next thing to understand is how the bits turn into colors on the screen. Say you've got a typical PocketPC with a resolution of 240x320 and 65536 colors. That means you've got 320 rows of 240 pixels (dots), each of which has 16 bits of data representing its color. All of that information is stored in a chunk of memory known as the "Frame Buffer." The LCD hardware takes whatever is in the Frame Buffer and converts it directly to what's on the screen. Want to change what's on the screen? Change what's in the Frame Buffer and the screen will update.
Okay, so we need 16 bits for every pixel, and we've got 240 times 320 dots. 16 bits is two bytes, so that's a total of 153600 bytes, or 150K of RAM used to hold what's on the screen."

Maybe a good thing to mention: we're hoping that the Toshiba g810 Portege has the files we need to develop a 2D driver. We're currently trying to extract a dump we got. Anyone have experience in extracting Toshiba's .Bin files?

Direct Draw explained
On MSDN:
"The DirectDraw® API provides support for hardware-accelerated 2-D graphics. It offers fast access to display hardware while retaining compatibility with the Windows graphics device interface (GDI). DirectDraw is a specialized memory manager for both system and display device memory and uses hardware acceleration where available. With DirectDraw, you can allocate and manipulate both system and graphics memory, including transfers between the two.
DirectDraw for Windows Embedded CE is adapted from DirectDraw for Windows-based desktop operating systems. Some capabilities from the desktop version have been extended and others have been curtailed to better suit embedded devices.
DirectDraw supports the following effects:
Bit-block transfers (blits)
Page flipping and multiple back buffers
Overlays, which is placing one image surface over another on the video display
Alpha source over destination blending, which is blending two surfaces using the source alpha image component
Video YUV pixel formats and color conversion
Direct video access to the frame buffer
What if we compare our HKLM\system\DDRAW\ keys in the registry with other devices? I see the values in ALL keys there are empty.

Yes.. I've noticed that and played around with them.. no difference.
I've tried the LG KS520, Diamond and HD ddraw.dll files.. none work out of the box. Maybe the G810 one might make a difference?
We need to find out what calls are made and to what other dll files. If you remember the problem we had with the 3.13 ddi? it could be similar situation in that theirs a dependencies issue.

Render-To-Texture with HTC Diamond 2

Hi everyone,
I have a small technical problem to solve and hopefully someone knows an answer for it. Someone gave me a HTC Diamond 2 (very nice toy I think). I don’t know which hardware is exactly inside the phone but I assume it’s an ATI ImageOn 2300 which fully supports OpenGL ES 1.0 + Extension Pack (that’s what GL_EXTENSION is saying). And all of these extensions are doing fine. As everyone knows HTC is not providing a D3D driver for their phones and all other drivers I have seen are just a wrapper around OpenGL ES. So using D3D is currently not an option.
I have to write an application which requires some render-to-texture functionality in realtime and here my problems are starting to grow.
[1] glCopyTexImage2D:
I recognized that glCopyTexImage2D() is very slow. My framerate is dropping dramatically from >100 frames down to ~20 frames. Somehow this is done in software by the driver and not hardware- accelerated. glCopyTexSubImage2D() is even more slow (down to ~10 frames per second), but both functions are working. I tried to move it into a different thread, but the driver is not supporting shared contexts. Also it’s not supporting two bound contexts at the same time with two different windows and threads. So this can’t be improved or I’m doing something wrong.
[2]PBuffers:
PBuffer are working fine. But PBuffers which can be bound to a texture are not supported by OpenGL ES 1.0. And that’s what happens also on this ATI card.
[3]GL_OES_framebuffer_object:
This was my preferred choice. But framebuffers are not officially supported by the installed OpenGL driver. But the libgles_cm.dll on the HTC is exporting these functions so I tried them and recognized that they are not working correctly. Somehow the vertex pipeline is allowing only triangles in the center of the viewport. All others will be discarded. When I turn it off it renders correct. Using glDrawTexiOES() will be ignored while using framebuffers. I assume that either the current implementation of the framebuffers is just waste of some development guys or the functionality is locked in some way.
[4]D3D:
Normally D3DM is supporting to switch between different rendertargets. But we are all know the D3D problem. I tested some other D3D drivers but they are not usable. Also I can’t imagine how render-to-texture will be implemented in these drivers while it’s not working in OpenGL.
I’m wondering what TouchFlow3D is using internally, whether they are using render-to-texture or not. The only thing I know is that they are using OpenGL ES and some extensions. But Manila.exe is querying the functions of libgles_cm.dll during runtime. So I have to write a few proxy dlls first and need to hook into the system to track what they are doing. And I don’t want to spend time on this.
Does someone knows an alternative to do some render-to-texture on the ATI or knows some secrets of the libgles_cm.dll which I don’t know? There are a lot of private functions inside but can’t find some documentation about it. Also ATI and Qualcomm are not very helpful to me.
Thanks.

Maybe, glReadPixels and then glTexSubImage2D (what probably glCopyTexImage2D is doing)?
(I know that this goes two times over the graphics bus, but you never know...)
What kind of scene (number of triangles, lights, textures) are you rendering with > 100fps?

glReadPixels() + glTexImage2D() is even more slow than glCopyTexImage2D...
Also this can't be parallized. I thought using AHI2DATI.dll instead to do the same thing, but I don't know how to get a surface handle from a OpenGL texture id.
>>>What kind of scene?
A very simple scene yet. Only a few depth sorted + material sorted objects (via VBO) with some textures (backed lighting) on it. Textures are compressed. Currently no lighting, no skinning or other things. While the render thread is waiting for glFinish() to return, a second thread prepares the next frame. Also the rendering thread is not redrawing the entire viewport each time.

The OpenGL texture id is the handle. There's nothing more you can do with it. PBuffers or framebuffer objects are the only way I know for doing performant render to texture in OpenGL.

No...I mean the surface handle of the AHI2DATI library. Here you have access to the raw data of the surface. Somehow the libgles_cm.dll uses these surfaces for it own buffers and/or textures or not?!
But this is not really useful unless someone tells us whats going on inside libgles_cm.dll.
See:http://greengalaxy.wordpress.com/2009/04/18/ati-direct-access-to-hardware/

Hi jeansmsixer, I don't think there is no efficient way to do it. Have you tried eglCopyBuffers?
Aren't all textures stored in system memory? - they surely have to be because the device reports no available video mem.
Even if you get a pointer to the color buffer, it's impossible to wrap the memory in a HBITMAP to select onto a HDC and use GDI fonts for instance. (which is what I need to do).
If you do write the proxy dll like you were suggesting, can you please let me know what TF3D does for fonts? Are they textures or have they somehow mixed 3D with GDI?

Hi jeansmsixer, something else you could try is what is described here:
http://brewforums.qualcomm.com/showthread.php?t=10668
Looking on glbenchmark.com it looks like HTC devices support the extension. You should be able to get a pointer directly to the color buffer (which I presume is in normal system memory) so you could copy off pixels fairly efficiently with your own memcpy(). However, you will need to eglWaitGL() etc to ensure 3d stuff is complete before attempting to access it.
I love the irony of the only helpful information for WM opengl being found on a brew site for symbian. If WM7 is as terrible as the current mess, then I'm moving to iPhone.

[WORKING] Running Windows 7 on HD2

Hello! Sorry that I'm not replied immediately, but I was busy.
First I recommend to remove all unnecessary stuff from installation iso, or download a "light" Windows.
You need basically two programs - Power ISO and HEX EDITOR NEO.
First open Iso file with Power ISO, and find winsetup.dll, which is located in folder sources. Copy Winsetup.dll and paste it to a temp folder, if you want to save the original file.
Then open winsetup.dll with HEX EDITOR NEO, find a 77 3D 07 78 01 and replace with E9 04 00 00 00.
Save the file and convert to img image.
That it - that allows you to install windows on a computers with little RAM.
After you are ready with the file, you need a QEMU Emulator for WinMo. You can find it here - http://4pda.info/news/11054/. Use google translate, if you don't read russian
More info about QEMU project - read here http://wiki.qemu.org/Main_Page
Hopefully you succeed. Although no great practical use. It is Slow and ifficult to handle small buttons, etc. - there are many shortcomings, but is made for the experiment.

Images? A video perhaps? Would be cool to see

wow
very interesting indeed, will defo be looking into later on today, thanks mitchellvink

Extraordinary claims require extraordinary evidence...

JoonatanO said:
Extraordinary claims require extraordinary evidence...
Click to expand...
Click to collapse
If you don't believe it, try it!
He/she doesn't have to "proove" anything by producing evidence... He/she is providing clear instructions on what has to be done, so you can test yourself if it is a correct claim!

i reading something about the first selfmade Windows 7 HTC Tablet with 4,3" in this Thread, great work. going to take a look on it, sounds interesting, but some screenshots/video would be great

I really can;t believe i'm going to type this because you have all been taken for fools.
YOU CAN NOT INSTALL WINDOWS 7 FOR A PC ON A MOBILE PHONE. MODDED DLL FILES OR NOT.
the reason for this that windows 7, vista, xp or mother%^£?ing windows 95 will not fit on to the nvram chip. None of the above operating systems even support the hardware in a mobile phone past knowning what to do when one is connected to them.
[highlight]MOD Edit: No need to be rude to the OP[/highlight]

the reason for this that windows 7, vista, xp or mother%^£?ing windows 95 will not fit on to the nvram chip. None of the above operating systems even support the hardware in a mobile phone past knowning what to do when one is connected to them.
Don't be a bunch of douche bags and don't fall for this crap
Click to expand...
Click to collapse
... aaaand breathe...

Yeah yeah .. pictures or it did not happen.

i tired it many times
even with WES7 i maked 300mb iso
and didnt success so proove will be good
i got always the error of acpi

MAMeingast said:
If you don't believe it, try it!
He/she doesn't have to "proove" anything by producing evidence... He/she is providing clear instructions on what has to be done, so you can test yourself if it is a correct claim!
Click to expand...
Click to collapse
I don't think you know how "science" works...

M3PH said:
I really can;t believe i'm going to type this because you have all been taken for fools.
YOU CAN NOT INSTALL WINDOWS 7 FOR A PC ON A MOBILE PHONE. MODDED DLL FILES OR NOT.
the reason for this that windows 7, vista, xp or mother%^£?ing windows 95 will not fit on to the nvram chip. None of the above operating systems even support the hardware in a mobile phone past knowning what to do when one is connected to them.
Edited...
Click to expand...
Click to collapse
Windows 95 and 98 works great on HD2 (98 is a bit slow to use).
It seems you don't know what is Qemu. So go out and learn.
Maybe it works but it should be frickin damn slow when I see how slow is XP. Absolutely unusable so absolutely useless. You're better to use 95. Plays Starcraft perfectly <3
Go here and try by yourself before posting such BS mate.
http://forum.xda-developers.com/showthread.php?t=637889

apallohadas said:
I don't think you know how "science" works...
Click to expand...
Click to collapse
And you don't seem to know what science is... We're on xda-developers! What does this have to do with science!?

It's more than possible, seeing how qemu's an emulator, so at the very least we'd be able to see how win phone 7 would look on the hd2 even though it'd be missing most of the feature set.

Moon2 said:
It's more than possible, seeing how qemu's an emulator, so at the very least we'd be able to see how win phone 7 would look on the hd2 even though it'd be missing most of the feature set.
Click to expand...
Click to collapse
Are you confusing Windows Phone 7 with Windows 7?

Ti3noU said:
Windows 95 and 98 works great on HD2 (98 is a bit slow to use).
It seems you don't know what is Qemu. So go out and learn.
Maybe it works but it should be frickin damn slow when I see how slow is XP. Absolutely unusable so absolutely useless. You're better to use 95. Plays Starcraft perfectly <3
Go here and try by yourself before posting such BS mate.
http://forum.xda-developers.com/showthread.php?t=637889
Click to expand...
Click to collapse
@M3PH,
Read the quoted post. While it cannot be natively run on the device, an OS can be emulated to run. 95 and 98 do work quite well on Qemu on other much older devices like the Himalaya and even the Blue Angel. Also, next time try to be less vocal about things. There was no reason to say things like that in your post.

MAMeingast said:
Are you confusing Windows Phone 7 with Windows 7?
Click to expand...
Click to collapse
No, he meant Windows 7.

MAMeingast said:
Are you confusing Windows Phone 7 with Windows 7?
Click to expand...
Click to collapse
Yh, sry, meant Windows 7, with the latest buzz about win phone 7, got the two mixed up.

mitchellvink said:
Then open winsetup.dll with HEX EDITOR NEO, find a 77 3D 07 78 01 and replace with E9 04 00 00 00.
Click to expand...
Click to collapse
'pattern not found' when searching winsetup.dll for 77 3D 07 78 01
what code line is it on roughly? Did you use any specific version of win 7?
EDIT - ok, three hours spent and I cant even get qemu to see theres an .img file, (not that i expected it to work, cos i couldnt find teh memory size reference in winsetup.dll to change.), i give up, life's too short, and teh qemu documentation too fragmented for me.