Charles Petzold

In early 1975, Bill Gates and Paul Allen were writing a BASIC interpreter for the MITS Altair 8800 computer, an early personal computer kit that had recently become available in extremely limited quantities. (Ed Roberts, the creator of the Altair, died last week and received a prestigious front-page obituary in the New York Times.) Gates and Allen didn't actually have one of the very rare Altairs to test their code; instead, they had written an emulator of the Intel 8080 microprocessor on the Harvard DEC PDP-10, and they were using that emulator to run this BASIC interpreter. On the night before Allen was flying to Albuquerque to meet with Ed Roberts and show him their work, Gates was nervous about possible flaws in their emulator: "If I got one of those opcodes wrong, this thing is just not gonna work." (Stephen Manes and Paul Andrews, Gates: How Microsoft's Mogul Reinvented an Industry — and Made Himself the Richest Man in America, Doubleday, 1993, pg. 73-74) But the BASIC interpreter booted up and ran.

A couple days ago, Apple released the iPad, and among the people very eager to buy one were programmers, many of whom had been developing their iPad applications without an actual iPad to test them on! Apple had provided an iPad simulator for the Mac, of course, but, as the New York Times reported today, many developers "were apprehensive about submitting programs [to the Apple app store] without first testing them on a real iPad." (pg. B3 in print edition) Obviously, as computers have become more focused on user interaction, only the actual hardware can provide the real test of look and feel.

Developers working with the first CTP release of the Windows Phone 7 Series programming tools can well recognize the frustration and anxiety surrounding emulation that has now spanned 35 years of the personal computer industry. The Windows Phone tools (available through the Windows Phone developer portal) come with a wonderful PC-based emulator that lets us develop phone applications today, but the emulator is not quite sufficient to finalize any but the most rudimentary applications.

Programs written for the Windows Phone 7 Series target either Silverlight or XNA; these programs receive user input mostly through three sources:

• For Silverlight applications only, the Soft Input Panel (SIP), a virtual keyboard that can have different appearances depending on the type of expected keyboard input.
• The multi-touch display.
• The accelerometer, which responds to orientation as well as other movement, such as shaking.

Certainly the fewest worries involve the SIP, which automatically pops up when a TextBox is given input focus, and which the application programmer really can't mess with.

Multi-touch, however, is a whole other story. Although the phone emulator provides some multi-touch simulation when you run it under Windows 7 on a multi-touch desktop or laptop display, it's really a poor imitation of the capacitance multi-touch capabilities of the phone. If your touch usage is light — for example, scrolling a ListBox (which is automatically provided) or responding to simple taps — you can probably get by with the emulator. For anything more intimate, you're going to need an actual device.

Not all phone applications will use the accelerometer, but some will, and those apps really can't be tested adequately on the phone emulator. Currently, the emulator provides orientation information to Silverlight applications, but that's about it.

For fine-tuning multi-touch and accelerometer code, we really need to wait for actual devices. However, if you're developing an XNA 2D program for the Windows Phone, and you want to explore the idiosyncracies of capacitance multi-touch and the accelerometer today, there is an interim solution: the Zune HD.

The Zune HD has a smaller screen that the first releases of Windows Phone devices will have, but it has the same type of multi-touch display and an accelerometer, and it runs XNA 2D programs in a kind of "programmer only" mode. You can't distribute the programs to other Zune HD users (except as source code) and the Zune HD prefers to reboot before it moves from your game to other functions, but it provides a good platform to get an early start on testing your more intimate user interface code destined for Windows Phone.

When developing for Windows Phone, you use Visual Studio 2010 RC and XNA Game Studio 4.0. When developing for the Zune HD, you use XNA Game Studio 3.1. I've only attempted to install Game Studio 3.1 under Visual Studio 2008, and I keep my Windows Phone development setup in a whole other partition from my Visual Studio 2008 installation, so I can't advise on mixing and matching. From what I've read, I'm nervous about attempting side-by-side installs of VS 2008 and VS 2010 RC with the Windows Phone tools installed.

You use XNA Game Studio Device Center to establish a link between Visual Studio and the Zune HD attached to the machine via the standard USB cable. When first connecting the Zune HD to the computer, the regular desktop Zune software will pop up. You'll want to exit that program. Sometimes connection is momentarily lost and the desktop Zune software will start running again; just exit it again.

From the New Project dialog in Visual Studio, select XNA Game Studio 3.1 on the left and Zune Game (3.1) on the right. Much of the source code you write for the Zune HD should be directly portable to the Windows Phone. Press F5 to run the program under the debugger, and the executable will download to the Zune HD and run. Stop debugging from Visual Studio to stop execution and return to editing.

I just said that XNA 2D code developed for the Zune HD should be directly portable to Windows Phone, but one of the exceptions involves accelerometer code. In XNA Game Studio 3.1 you use the Accelerometer, AccelerometerCapabilities, and AccelerometerState classes to access the device. These classes have been removed from Game Studio 4.0 — (Accelerometer class, we hardly knew ye) — and instead there's a new set of event-based classes in the Microsoft.Devices.Sensors namespace that you'll use in both Silverlight and XNA programs. Although accelerometer code won't be directly portable, converting it should be a snap because the basic information is the same: a three-dimensional vector of form (x, y, z). In the discussion below, I shall call this the "acceleration vector."

Imagine the Zune HD as a three-dimensional coordinate system: As you hold the Zune upright facing you with the screen in normal portrait mode, the X axis is horizontal with increasing values to the right, the Y is vertical with increasing values going up, and increasing values on the Z axis come out of the screen towards you. As you move the Zune HD in space, this coordinate system moves with it.

The accelerometer hardware is really just a tiny device — you can get more information about it from the entertaining Microsoft Zune HD Teardown from iFixit — that essentially measures force, which as you know from basic physics is proportional to acceleration.

When the phone is held still, the accelerometer responds to the force of gravity. The acceleration vector points towards the earth and the magnitude of the vector is 1, meaning 1 g, which is the force of gravity on the earth's surface. When holding your Zune HD in the upright position, the acceleration vector is (0, –1, 0), that is, straight down. Turn the Zune 90° counter-clockwise and the acceleration vector is (–1, 0, 0), upside down it's (0, 1, 0), and another 90° counter-clockwise turn it's (1, 0, 0). Sit the Zune down on the desk with the display facing up, and the acceleration vector is (0, 0, –1).

Of course, the acceleration vector will rarely be those exact values, and even the magnitude won't be exact. When holding my Zune HD still in different orientations, I get magnitude values ranging form 0.88 to 1.10. When you visit the Moon with your Zune HD, you can expect acceleration vector magnitudes to be in the region of 0.17.

I've been describing values of the acceleration vector when the device is still. The acceleration vector can point in other directions (and the magnitude can become larger or smaller) when the Zune HD is accelerating, that is, gaining or losing velocity. This will commonly result from shaking the device, which is another way the accelerometer can provide user input to a program. For example, if you jerk the Zune HD to the left, the acceleration vector points to the right but only when the device is gaining velocity. As the velocity stabilizes, the acceleration vector again registers only gravity. When you decelerate this jerk to the left, the acceleration vector goes to the left briefly as the device comes to a stop.

If the Zune HD is in free fall, the magnitude of the accelerometer vector should theoretically go down to zero. (Phones of the future will detect when the acceleration vector drops to zero and deploy little parachutes to glide them safely to the floor.)

I've been experimenting with ways to visualize the acceleration vector on my Zune HD. Unfortunately, you can't use 3D code for this job because the Zune HD only supports XNA 2D. I'm still not entirely satisfied with what I've done, but it's a start. Here's the display of the AccelerometerVisualization program:

(The XNA Game Studio Device Center doesn't have a whole lot of features, but a really great one is the ability to take a screen capture directly from the Zune HD.) The top line shows the current acceleration vector and its magnitude. The other two lines shows the acceleration vectors associated with the minimum and maximum magnitudes encountered since the program has been running. The little red ball in the center works opposite of the bubble in a bubble level — it sinks to the bottom to show the direction of the acceleration vector. Its location in the 2D space is governed by the X and Y components of the acceleration vector divided by the vector magnitude. If there is no Z component and the magnitude is 1, then the ball will sit right on the outer circle. The inner circle is half the radius of the outer circle.

The magnitude of the acceleration vector is reflected in the scaling factor used to display the ball. This is hard to see because the ball only gets larger or smaller when the device is acclerating! If the Z component of the acceleration vector is positive rather than negative, the ball color changes to green. Thus, all the information available from the acceleration vector is represented in the display.

Here's the source code if you want to experiment with the program on your own Zune HD.