Under The Hood: Pilot
Earlier this year, the Palm Computing Division of U.S. Robotics
introduced the Pilot, a small, lightweight, handheld computer. The Pilot has been selling
briskly for several reasons:
- It's very small:4.7 (12) x 3.2 (8.1) x .7 (1.8) inches (cm), and readily fits in a shirt
- It's very light:5.7 ounces (162 grams), including two AAA cells
- It's inexpensive:about US$300
- It's very fast
- It has long battery life: 8 to 12 weeks
The first two characteristics are due to clever hardware engineering. The latter three
are possible because of some of the choices the Pilot software engineers made.
Lean and mean applications
The Palm engineering group had several basic design goals for the Pilot Operating System
(OS). One was to make the OS as small and fast as possible, by eliminating all superfluous
services, features, and capabilities. A second goal, to do all heavy-duty processing on
the desktop, was based on the assumption that a typical Pilot user has a desktop computer.
Move as much critical functionality as possible from the Pilot to the desktop.
These result of these two goals is that the Pilot operating system has modest memory
requirements. Written in C++, the entire system and the built-in applications fit into
less than 500K ROM. Out of that 500K of ROM space, about 300K is for the operating system,
display and serial drivers, the user interface tool box, and all the system services.
There are no printer drivers, no communications applications, minimal help, only a handful
of user-interface resources (more about that later), and simple serial communications
Unlike the Newton OS or Magic Cap, which both try to do everything for everyone right out
of the box, the Pilot OS has a modest set of features. The Personal Information Management
(PIM) programs that come with the Pilot: the Date Book, Address List, the Memo Pad, and To
Do List, are not best-of-breed applications. They have a minimal, but very functional set
of features that are more than adequate for many people, but may leave power users
dissatisfied, at least initially.
When I first got my Pilot, I lamented the lack of linking between applications; being able
to, for instance, have an appointment point right to a person's name in the Address Book.
Lately, I find that feature less important. The Pilot's universal Find button, and the
device's speed are an adequate substitution for data linking.
All the built-in Pilot applications are Execute in Place (XIP), meaning they run directly
out of ROM. The system uses only 32K of RAM (additional memory is used for data storage
and third-party applications). Also, the built-in applications are small, letting Palm
keep the ROM small. Just to give you an idea of a typical program size, here are the ROM
sizes of the four largest built-in programs: Date Book - 54K; Memo Pad - 14K; To Do
program - 26K; and Address List - 36K. Typical shareware and game programs use between six
and 15K of RAM. Expect serious application programs to use as much as 30-40K of RAM.
Memory, price, and popularity
The small memory requirements of both the Pilot OS and the built-in applications means
that Pilots cost less than comparable devices. Memory is the most expensive component of a
handheld computer. A MessagePad 130 has 4 MB of ROM and 2 MB of RAM. Sony's PIC-2000 Magic
Cap device has similar memory requirements. A Pilot 5000, on the other hand, has 512K of
ROM and 512K of RAM, or almost 85% less memory.
Even with today's plunging memory prices, that still translates into a significant cost
difference, and a more-than 50% retail price difference. A Pilot sells for less than half
the price of a Newton. Consequently, more people buy them. Over time, that means that more
developers will create products for the Pilot, more third-party companies will make add-on
peripherals, and a strong infrastructure will develop around the Pilot, making life easier
for consumers of Pilot products.
I don't mean to imply that people aren't buying Newtons or PIC-2000s. Simply stated; all
other things being equal, a lower price usually means a longer life in the marketplace and
better consumer acceptance.
Event driven, not object oriented
The Pilot's speed is determined to a certain extent by the choice of processor, the speed
at which that processor runs, and other hardware factors. To speed things up even more,
Palm chose to make the Pilot's OS simpler than the Newton and Magic Cap operating systems.
Simpler means less overhead for any single function. When you add up thousands of
functions per second, a simpler operating system translates into faster programs.
Newton and Magic Cap were created by software engineers practicing at the edge of the
envelope in operating system design. That edge is called object-oriented (OO) programming.
OO programming advocates claim that OO programming has quite a few benefits: Most notably,
it makes it easier to build complex, yet more robust applications than with other
programming techniques. From a programmer's perspective, that's usually true.
Unfortunately, OO programs tend to run slower that non OO programs, because the system has
to do a lot more work per function, and OO programs tend to need more memory.
Palm chose to stick with a programming methodology, called event-driven programming, that
has been around a bit longer. Both Windows and the Macintosh Operating System are based on
an event-driven programming model. Event-driven programming requires programmers to do
more work, and makes it tougher for them to create good software, but it's generally
faster and less memory intensive than OO programming. For example, the original Macintosh
had only 128K of RAM, and Windows used to run on a 640K IBM PC.
Palm's choice of system design was market driven. A faster architecture that fits into
less memory translates into faster devices and lower prices, both good for consumers. The
Newton and Magic Cap systems development efforts were much more engineering driven.
Leading-edge engineers want to work with leading edge technologies, market consequences be
damned. (Actually, most engineers are quite good at rationalizing their desires to fit
some fairly vague market need that probably doesn't exist). I don't mean to minimize the
efforts of the Newton and Magic Cap teams. They did some remarkable work that will have an
impact on handheld systems for years. They just didn't emphasize size or speed.
One definite disadvantage of the lean-and-mean OS approach is that the built-in
applications object structures and executable code are not available. This makes it
impossible to tweak the internal programs by overriding some of their behaviors. Unlike on
the Newton, you can't patch the existing applications, only replace them. If you want a
different type of Pilot address book, for example, a good programmer has to create one
from scratch. The good news is that the architecture is straightforward, the libraries
have a modest number of functions and procedures, and the development tools are
reasonable, so it's relatively easy to build Pilot applications.
A typical Pilot application
A Pilot program is relatively straightforward. First, it consists of a set of GUI
(graphical-user-interface) components, called resources. These include such things as menu
bars, menus, pictures, buttons, and check boxes all the things that a user interacts with
when running a Pilot program. When creating a program, the programmer has to first decide
what resources comprise the user interface.
In addition to basic GUI components, the Pilot has some remarkably sophisticated types of
resources, making life easier for programmers. For instance, there is a list resource,
which is used in the list views for all the built-in applications. All a programmer has to
do is tell the Pilot OS what items are in the list, and the Pilot takes care of scrolling
up and down as you press the scroll buttons and arrows.
In an event-driven architecture, a program basically sits there doing nothing until a user
initiates an event by, say, tapping on a resource like a button on the Pilot's screen or
scribbling in the Graffiti input area. Once an event happens, the operating system first
looks at that event and decides if it is supposed to do something about it. If not, it
passes it on to the currently running program, giving it a chance to do something. For
instance, if you enter a character using Graffiti, the system first determines what the
character is and then passes its value on to the active program. The program may decide
it's an appropriate character, and place it in the currently active input field on the
screen. If the program can't do anything legitimate with the event, it ignores it.
Here's a specific example. When you tap the Pilot's menu button, the operating system gets
a pen tap event from the hardware. It figures out the screen location of the pen tap and
recognizes it as taking place on the menu button. It knows to search the currently running
program for a menu. If it finds one, it displays it. If not, it ignores the event.
If a menu appears, you most likely tap on one of the commands in the menu. Again, the
operating system receives the pen tap event and realizes that you just tapped on the menu.
It makes the menu disappear, but then creates a menu event and passes it on to the
The program, which has been sitting there waiting for an event, receives it, and
identifies it as a menu event. It has to figure out from the event's data which menu
command you selected, and do whatever that command requires. In the course of executing
the command, the program may initiate other events. For instance, if you tap an
"About" command, the program (indirectly) generates an event to display the
"About" window for the current program and waits for you to tap on the OK
button. When you tap the OK button, the window is erased, and everyone goes back to
waiting for you to do something.
Advanced power management
The Pilot operating system has some fairly advanced features designed specifically for
low-powered, handheld devices. For instance, there are sophisticated power management
features. The Pilot has three power modes: sleep, doze, and running. Whenever the Pilot
appears to be turned off, it is actually sleeping, but still running. The system puts as
many peripherals and other parts of the hardware to sleep as possible, to minimize power
consumption, and then monitors the hardware keys and the real-time clock for any activity.
If a key such as the on-off key is pressed, the CPU wakes everything back up again, ready
to run. A Pilot can sit for months in sleep mode.
Sleep mode isn't remarkable. Most handheld computers have an equivalent operating mode.
Doze mode, on the other hand, is quite clever. The Pilot processor actually stops running,
but peripherals like the screen stay awake, so that the system can respond quickly, in a
fraction of a second, to an event like a pen tap. Whenever the Pilot appears to be
running, but nothing is happening, it's probably in doze mode. The Pilot actually dozes in
between your pen actions, even when you are entering characters on the Graffiti pad or
using the on-screen keyboard. It just looks asleep, and wakes up very fast, so fast, you
don't even know it's sleeping.
This is the most efficient way to consume as little power as possible. It's the reason a
Pilot can go for weeks on a single set of batteries.
There are many other hardware and operating system features that make the Pilot one of the
most popular handheld computers to debut in a long time. While designing the Pilot
operating system, Jeff Hawkins and his engineers had to make some serious decisions about
the nature of the OS architecture, the amount of RAM they wanted to include in the device,
the power management, and hundreds of smaller details. They made a lot of good decisions,
leaving the Pilot with some significant advantages over its competitors. I hope they keep
up the good work.
- Steve Mann
Steve Mann is publisher and editor of PDA Developers magazine, author of The handheld
System Integrator Directory, and producer of the PDA Developers series of technical