Larry’s Personal & Tech ramblings

I’ve been using Windows Mobile phones since the early days of the MPX-200 and have used just about every phone that was released. For software testing, I’ve had to acquire the latest WM6 devices and have used them as my daily phone for minimum of several days. Here are my observations:

1) T-Mobile Shadow
Pros:
Excellent form factor - thin and light
Large, bright display
Good ergonomic keypad
Slide-up keyboard good for answering/hanging up
Cons:
Terrible battery life
Strange keypad layout causes slower text entry
Terrible camera
So-so phone reception

2) Motorola Q9H
Pros:
Built-in GPS
Large, bright display
Good phone reception
Fast CPU
Comes with extended battery
Decent keyboard
Cons:
TERRIBLE voice quality (sounds like talking to Darth Vader through a paper towel tube)
Heavy, bulky device
GPRS/EDGE data worked slowly and unreliably
Custom USB connector requires special cable or dongle

3) HTC Vox (S710)
Pros:
Good form factor for full-keyboard+keypad device
Large, bright display
Excellent numeric keypad
Excellent slide-out keyboard
Excellent voice quality
Excellent phone reception
Good GPRS/EDGE connectivity
Decent camera
Cons:
Little rubber covers warp and stick out (USB + MicroSD)

Conclusion:
The HTC Vox wins by a landslide. The only thing that kept me holding on to the Q9H for a few extra days was experimenting with the GPS, but since the EDGE connectivity was so hit or miss, I couldn’t get Google Maps to work because it kept timing out when receiving data. I guess the next phone for me will be the 3G successor of the Vox.

I’ve been sidetracked many times while trying to finish the latest version of Virtual CE. I’ve finally released the new version which now supports all Windows Mobile devices. For those of you unfamiliar with this product, it creates a real-time display of your WM device on your Desktop PC. It’s basically VNC in reverse. Here are some screen shots of it in action:

I’ve reduced the price to $10 and simplified the feature list to make it easier to use. Please give it a try:

Virtual CE

I was told by a customer that my game emulators did not display correctly on the Motorola Q9H smartphone.  I got hold of a loaner device and discovered the problem.  For some reason, the video memory is mapped in an odd way (reminiscent of the old Apple II).  This odd RAM mapping means that many games/multimedia applications will not run correctly on the Q9H.  I’ve written a workaround for my software, but the bigger question is how many devices/programs this affects.  My best guess is that this is the fault of the new TI OMAP 2420 CPU.  This chip has many 2D/3D capabilities, so it makes sense that the designers didn’t care much about how the video memory was mapped since most software would use the advanced capabilities of the chip and not write to VRAM directly.  I’m in contact with my friend at TI and will report more information about this problem as soon as I know.

“Micro_View” is a product I created several years ago for a client.  It’s a simple imaging library for Win32 and WinCE which allows you to load BMP, GIF and JPEG images into a HBITMAP or it can display them in a window.  The code is fast and small (the Win32 lib file is 96K).  I created a stand-alone command-line driven executable which displays an image in a borderless window and a link library which has 3 functions defined:

int APIENTRY MicroView(TCHAR *filename, int iOptions);
int APIENTRY MVLoadBitmap(TCHAR *filename, HBITMAP *, HPALETTE *);
int APIENTRY MVLoadResource(HINSTANCE hInst, TCHAR *rname, HBITMAP *pBitmap, HPALETTE *pPalette);

If you need to add simple image handling to your application, it doesn’t get much easier than this.  This is something that’s been collecting dust on my harddrive for quite a while, but would probably make a pretty good retail product.  I will see if I can package this up into a reasonably priced product in the next few days.  Please email me (bitbank@pobox.com) if you’re in need of such a library.

I thought it would be useful to re-run the tests with the C version of my JPEG code. From the results it appears that memory bandwidth is the real limiting factor to the speed and the pixel colorspace conversion gets the most benefit from my optimized ARM assembly language. Also it appears that the OMAP gains more from optimized ASM than the XScale does. Here are the numbers:

C-Code:

PPC: thumbnail: 10.7 milliseconds, DC only: 968 milliseconds, full res: 3734 milliseconds.
SP: thumbnail: 25.1 milliseconds

Mixed C and ASM

PPC: thumbnail: 8.8 milliseconds, DC only: 830 milliseconds, full res: 2700 milliseconds.
SP: thumbnail: 15.1 milliseconds

The load times for the “DC only” and “full res” tests include the time taken to read 4.3MB of data from RAM through the WinCE file system.

These results make sense in that the real benefit of optimization comes from fixing the algorithms and reducing memory usage. The optimized ARM assembly code is certainly helpful in speeding things up, but won’t offer an order of magnitude improvement over what the compiler generates.

The great thing about the ARM architecture is that the more I look at a piece of code, the more ways I find to optimize it. The conditional execution, barrel shifter and optional setting of the processor flags create many opportunities for optimization. I’ve spent some more time optimizing my ARM asm JPEG code and now have some hard numbers to publish. I used a HP iPAQ h2210 Pocket PC (400Mhz PXA255) and a HTC Hurricane SmartPhone (195Mhz OMAP 850) to do the testing. I was able to load the file from RAM on the Pocket PC (to reduce file I/O delays), but not on the SmartPhone. The SmartPhone file system does not use RAM for file storage. The slow speed of reading from the miniSD card overtakes the amount of processing time in the tests, so the only test that was run on the SmartPhone was decompressing a 160×120 thumbnail image in RAM. All tests were to decompress the image to a RGB565 bitmap. The thumbnail test decompresses the 160×120 EXIF thumbnail image. The “DC only” test creates a single pixel from each MCU (the 3072 x 2304 image is loaded as 384×288). The “Full res” test decompresses every pixel of the image.

PPC: thumbnail: 8.8 milliseconds, DC only: 830 milliseconds, full res: 2700 milliseconds.
SP: thumbnail: 15.1 milliseconds

The speed difference between the two devices is to be expected considering the different processor and memory bus speeds. The “DC only” test is useful because it shows the relative speed of Huffman decoding. The file size is 4.3MB, so in 830 milliseconds the code was able to decode all of the MCUs and produce a single pixel from each one.

I’ve uploaded the sample image to my web server here: CIMG2209.JPG

The image was taken with a Casio EX-Z750 and depicts a relatively complex scene with many fine details. Like most cameras, the Elixim series saves JPEG images with 2:1 horizontal color subsampling (when set to maximum quality). It’s not unreasonable for a point-and-shoot camera like the Z750 to save images at a less than optimal compression because the image coming off the CCD isn’t that great to begin with. What irks me is that cameras like the Canon 20D do the same thing. With a good SLR lens and imager, the Canon should allow you to save full res color JPEG images.

Comments?

An odd title considering that JPEG is a cryptic image compression standard.  My idea of fun is optimizing code until there’s nothing left to improve.  I decided a few weeks ago to take the plunge and rewrite the 3 core JPEG decode routines to speed up my imaging code.  One reason was that the great majority of cell phones today are based around the TI OMAP architecture typically running at around 200Mhz.  These devices seem slow at working with images, so I thought I could help that situation by speeding things up to improve both battery usage and the user experience.

The important, “inner loop” routines of JPEG image decoding are the Huffman decoding of the MCU (minimum coded unit), the IDCT (inverse discrete cosine transform), and the output stage (turning the YCrCb pixels into RGB pixels).  All 3 routines together turned out to be only a couple hundred lines of ARM code, but the result of rewriting it from C was quite dramatic.  The original C code has been optimized and tested over a long period of time and was in good shape to begin with, but C isn’t so great at bit manipulation and squeezing the most use out of register variables.  It took several iterations to get down to the bare minimum of code, but I’m quite happy with the results.  I used ARMV5 instructions, but made sure that the code performs well on both OMAP and XScale CPUs (unlike Intel’s integrated performance primitives).  Luckily my previous performance testing of the multiply instructions helped guide me to save a few clock cycles off of several routines.  The purpose of this work is threefold:
1) I’m readying a new version of my imaging application (PQV - Pocket QuickView) for Windows Mobile and need it to be competitive with other products.  I pride myself on having the fastest viewer available.
2) I have been staring at the C code for a long time and wondering how much better it could perform if written in optimized ARM asm.
3)  I believe this code has value to anyone doing imaging or video on ARM based devices.  Web browsers, image viewers, camera applications, video players can all benefit from this code.

I’ve been searching for the past week or so for customers of this code, but the typical response is the “not invented here” attitude standing in the way of improving products.

I will post some sample images and benchmarks shortly to back up my claims of fast JPEG decoding.

Anyone interested in licensing object or source code should contact me directly (bitbank@pobox.com).

I’ve had a vested interest in Windows Mobile devices since the very beginning because of my many years of Desktop Windows programming experience. It’s definitely a big advantage for Microsoft to allow developers to leverage their programming experience from the desktop onto mobile devices. Microsoft’s design philosophy seems to have been to bring as much of the desktop operating system as possible onto battery powered devices and put a new face on it which fits the PDA/Phone paradigm. The obvious advantage to this is being able to port code easily between the desktop and mobile devices. What I’ve been discovering more lately is that the one fatal flaw in this design is a non-issue for many (like me) and a deal breaker for others.

The problem I’m talking about is application and memory management on Windows Mobile. The current scheme allows the users to run as many simultaneous applications as they like. This is usually a good thing and allows mobile devices to multi-task just like the desktop version of Windows. The bad thing is that Microsoft discourages the “close button” and “exit option” from mobile applications. Instead they claim that the system will close applications automatically when resources get low. This is the fatal flaw.

Let’s suppose that your application is about to run on a phone that’s got a bunch of other applications running. Memory is running low, but there’s enough memory to run the EXE, but not enough to allocate space for the work that the app wants to do. The application is allowed to run and then gets a failing error code when it tries to allocate memory. The automatic memory management doesn’t appear to kick in because the app did succeed in getting loaded. The application tells the user that there’s not enough memory to do the work, so the user must go through many manual steps to shut down other programs to free up some memory.

This scenario probably occurs frequently with certain users of Windows Mobile products. Those users who run various software applications and don’t shut down their phones at the end of each day. As the days pass and they run different programs, the phone gets more and more cluttered with running programs and will get slower and more problematic as resources are used up. A friend of mine clued me into this situation recently and it dawned on me that this is probably a big issue for many users. My experience with Windows Mobile devices is that the operating system and applications work excellently and I am thoroughly satisfied with my phone/pda devices (I shut them down every day). I could see how many people would criticize Windows running on phones for the reason stated above. What’s the solution? My first idea would be to encourage application developers to include a real “Close” and “Exit” option on their mobile applications. The second idea would be to educate people to shut down their devices at the end of each day when they set them to charge. I don’t think there can really be any good automatic process inside of Windows which fixes this situation. Perhaps a sentinel application which pops up when resources are getting low and gives the user the choice of shutting down some applications. Anyone have an idea?

Typically when writing code in Windows (desktop or mobile), you will encounter a strange bug in the operating system which requires a workaround.  This has been occuring since the very first version of Windows and is still happening today.  Lately I have been having odd timing problems with my games on some devices and was trying to discover the reason behind it.  On OMAP devices (both PPC + SP) the PerformanceCounter doesn’t really exist and it returns a resolution of 1ms.  Under the covers it uses the system tick counter which has a resolution of 1 millisecond.  This would be reasonable if it worked as expected, but for some reason, querying the performance counter gives stops and starts and will cause games which depend on this to go both too fast and too slow.  The solution is to check the timer frequency with QueryPerformanceFrequency() and if it comes back as 1000, then use the GetTickCount() function instead of the PerformanceCounter functions.

This week we (HanaHo Games) released Space Invaders Trilogy for the Pocket PC and SmartPhone. It is an emulator (of course) of the original “Space Invaders”, “Space Invaders Part 2″, and “Return of the Invaders” from Taito. You can try it for free (30 seconds of play). It runs on all Pocket PCs and SmartPhones which are QVGA and portrait orientation. Here are the Handango product pages:
Space Invaders Trilogy (SmartPhone)

Space Invaders Trilogy (Pocket PC)

L.B.