Larry’s Personal & Tech ramblings

Let me start by saying that I’m not a big fan of Apple. Through the years I have always felt that they extracted a few too many dollars from their customers and left them with a few too few options. I’m glad Apple released the iPhone because it will stir up the mobile market a little and inject a few new ideas into the mix. The truth is that the iPhone is very much a 1.0 release - missing several important features and designed to be more of an improved iPod than a good phone.

1) As a music player it falls short of being usable; 8GB of memory is not enough to store even a fraction of most people’s music collections.

2) As a phone, using a touchscreen is a mistake. A phone shouldn’t require 2 hands to operate nor require your eyes to be focused on it to make a simple call. Get ready for iPhone-related car accidents.

3) Choosing AT&T was a big mistake if you’re touting your device as a great wireless web browser. EDGE network speeds can be OK, but they’re never great.

4) Most of today’s expensive smartphones come with a much more reasonable price tag when you’re roped into a high priced data plan for a minimum of 2 years. For the rate plans that the iPhone offers, it should be free with the 2-year contract.

5) Apple fanboys will drink the kool-aid as always and flaunt their wondertoy.

Even though HTC won’t admit they released the “Touch” as a response to the iPhone, I think we can see through the smoke. The Touch is a nice little Pocket PC, but it has the same issues as the iPhone; in other words, I would never carry one around as my main phone.

For me, the HTC S710 (Vox) is the epitome of SmartPhone design. It’s small, light, tough (no touchscreen) and has a convenient slide out keyboard. This is the phone I’ve been waiting for since Microsoft released the “SmartPhone” platform.

Let the flaming begin…

I have always typed better on the old “clicky” IBM/Lexmark keyboards. There is probably some combination of tactile and auditory feedback that helps me type my fastest. I bought a bunch of broken ones from a liquidator around 1993 and managed to put several complete, working ones together. I’ve tried to keep them functioning and moving them forward with me as I’ve upgraded my work computer (and luckily it still has a PS/2 port). Along the way I’ve always wondered how long they would last (the switches and the controller). Well, last week I got a partial answer. My computer booted up with the dreaded “keyboard error” message. I figured that the cable had worked its way loose, but that wasn’t the case. Apparently the controller board had died. It’s not worth spending the time to determine if it was the 6805 or some discrete component. Impressive is not quite a strong enough word to describe its service record. In today’s disposable society, it’s simply astounding that a piece of consumer electronic equipment could work continuously for 8-16 hours a day for 14 years. Luckily I had a spare controller board and brought it back to life for a few more years

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?