ehci-hcd behaves badly when the Treo is
plugged in, and I find it helpful to unload the module before using
the Treo].
The gadget
The Treo 600 is a PDA phone which runs the PalmOS 5.2 operating system. It's
available in two phone flavours: the GSM version, which works more-or-less
anywhere, and a CDMA version which is mostly useful only in North
America. In fact, GSM coverage is fairly good in North America as well
now, so there's little reason to buy a CDMA version unless you're with a
network operator that only supports CDMA. At present, prices range from
about £150 for a Treo that's tied to an expensive service contract
with a particular network operator,
to about £500 for a network-independent GSM version.
[Update 11/05 -- the Treo 600 has stopped shipping in favour of the
new Treo 650. You can still get an unlocked 600 on eBay for about £100].
I understand
that it's relatively easy to overcome the operator-locking used on
this device (partly because the firmware is user-upgradeable),
so in principle you could buy one with a modest service contract
and remove the operator lock when the contract expires.
The Treo packs a lot of features into a small physical space but,
inevitably, some things have been left out. There is, for example,
no built-in bluetooth or wireless networking (IEE802.11) support.
There is some doubt whether this version of the Treo will ever support these
forms of connectivity. In theory, the SD expansion slot is
SDIO-ready, which means that it should be possible to plug in
SDIO peripherals. It is certainly possible to obtain SDIO
bluetooth and wireless adapters, but the uncertainty is whether
the Treo expansion slot can supply enough current to drive them.
In short, the limitation may be in the hardware, rather than the
software. There are rumours that the next Treo model will have
built-in bluetooth [Update 11/05 -- it does. In addition, Enforma
have released a wireless `sled' for both 600 and 650. This slides onto
the back of the case. Still on bluetooth for the 600, so far as I can tell].
The Treo has a Qwerty keypad, but the keys are incredibly small, and
only suitable for thumb operation (but an external keyboard is
available). There is full IrDA support, but many users
will wonder why this was included while bluetooth was not. The
Treo has a built-in camera, which takes relatively poor-quality
pictures.
But
for people who really want to exploit the device as a computer,
the Treo has the overwhelming advantage of offering a standard
SD memory expansion slot, with no limitation on the size of
memory that can be installed. This is a
huge improvement over, for example, the P800, which takes the
apallingly-priced `Duo' memory sticks, and is limited to 128 Mb.
A 512Mb SD card -- which costs less than £100 these days --
will store perhaps 40 hours of MP3 audio, or 8 hours of video
(at compression levels commensurate with a device of this type).
The screen on the Treo is a bit of disappointment after, for example,
the Zaurus SL-5500. The resolution is only
160x160 pixels -- one third the pixels of the Zaurus screen, in
an area not much different in size. Text on the screen does look
somewhat like it did on the Sinclair ZX-80. However, this relatively
low resolution means that you can encode videos to consume minimal
storage while still being watchable. What's more, the screen is
incredibly bright, and has excellent contrast.
Although this is nothing to do with Linux, I thought it might be helpful
to point out a little quirk in the Treo's audio system. The only audio
connector is a 2.5mm jack with three contacts;
this jack serves both as a hands-free headset connector
and a stereo audio output. Three contacts will give you two channels (assuming
that one contact is the ground return). Now, audio output is stereo, and both
channels must be outputs. The handset, however, has one input (microphone)
and one output (earpiece).
So how does the device know whether you're using stereo headphones, or
a headset? It appears that it measures the electrical resistance
between the microphone contact and the ground return contact. If this
is high (more than 1 kilohm or so) it assumes that a microphone
is connected, and treats the contact as an input. If the resistance
is lower than this, it assumes it is connected to a headphone, and
treats it as an output.
If the Treo detects that a headset is connected, it disables the internal
audio system, and only allows the headset to be used for phone calls.
You don't even get audio in the headset earpiece, even monaural audio.
The Treo, presumably, assumes that no-one would listen to music through
a headset earpiece, and shuts it off completely. Amazingly, however,
if you push the talk button on the headset, the audio system springs
into life! This is because the talk button short-circuits the microphone
to ground, which the Treo interprets as the connection of headphones.
Of course, as soon as you release the button the audio will stop.
You may be wondering why this digression into electrical engineering
is important; well, it's important because if you connect your
Treo 600 to an ordinary stereo amplifier it won't work!.
It doesn't matter whether it's a hi-fi system or the powered speakers
people use with their PCs; in all cases the input resistance of the
amplifier will be greater than a kilohm, and the Treo will think
that a hands-free headset is connected, and thus disable the audio.
You may also find that if you have noise-cancelling headphones, or
any other kind of headphone with built-in amplification, they
won't work with the Treo, for the same reason. Ordinary stereo
headphones or earbuds work fine, but of course you'll need to get an
adapter to connect the 2.5mm jack to whatever your headphones have.
[Update 11/05 -- an application called `Freedom' is now available
for managing the routing of audio on the Treo. It worked fine for me
when I tried it, but there are mixed reports of its efficacy.]
What is this PalmOS thing anyway?
For better or worse, PalmOS is overwhelmingly the most popular
operating platform for handheld devices. I understand that more
PalmOS devices are sold than all other handheld types put together.
For operating system purists, PalmOS is strikingly unsophisticated.
For example, it is only relatively recently that PalmOS
has acquired a concept
of filesystem -- earlier versions did not allow any sort of file
organization. Even now, a great deal of PalmOS software cannot
cope at all with arbitrary file types or with directories,
even if the operating
system can. In traditional PalmOS there are only two sorts of
file: program (PRC) files and database (PDB) files.
Even a text editor, for example, would
expect its text to be wrapped up inside a PDB file. The Treo
supports SD memory cards of unlimited size, and it makes little sense to
treat the card as one huge unstructured directory. Nevertheless, with
a great deal of PalmOS software this is exactly what is required. Only the
most modern applications will allow data to be manipulated in directories,
and outside of a PDB file. The Treo 600 allows arbitrary files and
directories to exist on a memory expansion card (it has to, to allow
the card to be manipulated by, say, a desktop PC), but the internal
RAM can only accept PRC and PDB files.
The concept of a `process' or `task' is also more-or-less absent from
PalmOS. There has been a long-running debate about whether PalmOS supports
multitasking at all; clearly it does at some level, although the mechanism
for using such a facility is not exposed to developers through the
published API. In fact, PalmOS instructs an application to exit
whenever a new application is launched; applications do not run
`in the background', and only one user-level application can be
executing at a given time. To be sure, there are PalmOS applications
that do give the illusion of background operation (PocketTunes is a
good example), but they are not daemon processes in the Unix sense, but
bits of code hooked into the operating system.
This is all a million miles away from, say, OpenZaurus, which is a full
Linux implementation for handheld devices. However, PalmOS does have the
advantage of being designed from the very start for resource-constrained
machines. It is not a cut-down version of a desktop operating system like
Windows CE (or a server operating system like OpenZaurus!) Its
simplicity means that the operating system consumes relatively little
of the system's resources for its own internal housekeeping. It just
takes a bit of getting used to, that's all.
For a Linux user (and even more for a Linux developer) a striking feature of
PalmOS is that it is tied to a specific architecture, in the same way that,
say, MS-DOS only runs on Intel x86 machines. This is very different from
Linux, which can be compiled for almost any hardware platform. Until recently,
all PalmOS versions ran on an architecture based on the Motorola 68000-series
CPUs (called `m68k' in PalmOS jargon). More recently, Palm has switched its
efforts to the ARM chip; the Treo is based on ARM, not m68k, which has striking
implications for people who wish to develop in C/C++ for the Treo. More on this
later.
Linux file transfer using pilot-link
For most people, the main method for exchanging files between the
Treo 600 and a Linux will be the pilot-link package.
This package contains command-line utilities to copy files to and
from the handheld, list installed files, and manipulate Palm PDB and
PRC files in Linux.
Even if you don't need the command-line utilities in pilot-link,
most other applications that synchronize to Palm devices (e.g., Evolution)
use it internally. pilot-link has been around for a long
time -- I can remember using it with the first PalmPilot devices
five years or more ago. It now seems to be relatively stable, even when
using USB, which is a relatively new feature. To communicate with the
Treo over USB, you'll need to load (and possibly compile)
the visor kernel module. This module provides a serial
communications protocol over USB, which mirrors the protocol used
by the serial interface cable. Thus the pilot-link
utilities themselves don't care whether you're using a serial
interface or USB -- the data exchanged is identical. When
visor is loaded, it creates two new USB serial ports,
typically /dev/ttyUSB0 and /dev/ttyUSB1.
Only one of these is useful for synchronization, and there doesn't
seem to be any obvious way to figure out which it is for a given
Palm device. On the Treo, it appears that the second device, ttyUSB1, is the one you want.
To copy files to and from the Treo, you can use the pilot-xfer
utility. This can copy single files, or backup and restore a whole
system. However, as far as I am aware pilot-link provides
no way to read or write data stored on the memory expansion card.
Very possibly the Palm protocol does not even expose these files to
the wire.
Linux file transfer using a card reader
Although pilot-link does a reasonable job of transferring files
over USB to the Treo, it isn't particularly fast (several minutes per
megabyte). A much faster method of data transfer is to use an SD card and a
compatible card reader. My laptop has an SD card slot built in, and it can fill
a 512 Mb card in about five minutes. If you want ultimately to keep the data on
the card, not in the Treo's internal memory, you'll have to do this anyway,
because (as far as I know) the memory card is not accessible over the wire. If
you do want to get files from the card to the internal memory, or
vice-versa, there are a number of Palm utilities (e.g.,
FileZ) that will allow you to do this. This is
subject, of course, to the restriction
that the internal memory only accepts PRC and PDB files. However, there is
a utility called par which can wrap any kind of file inside a
PDB file, and thereby allow it to be installed in internal RAM. This is
only helpful if you have (or are developing) applications that can read
files packed in such a way.
Linux PIM synchronization
As well as transferring files in bulk between your Linux machine and
the Treo, you may want to synchronize PIM data (contacts, appointments,
memos, etc) with a Linux-based PIM application.
There are two main ways to do this. First, you can use
a general Linux PIM application that supports Palm synchronization.
Probably Ximian Evolution is the best-known and highly developed of
these applications. However, Evolution is something of a heavyweight if you
don't need its e-mail features. An alternative is to use one of the
Palm-specific Linux PIM applications. There are a number of these; probably
jpilot is the best known. Synchronizing with jpilot
is as simple as clicking the `sync' button in the application, then hitting
the HotSync button on the USB cable. So far this has worked very well
for me. This synchronization is two-way -- data entered in the Linux
application will be reflected in the Treo, and vice-versa.
I have read a number of reports of this synchronization not working for
some Linux users, but for me it worked first time with absolutely
no effort at all. Maybe I'm just lucky. It is worth bearing in mind that
all these PIM utilities use pilot-link libraries, so you need
to ensure that pilot-link is working for basic file transfers
before trying anything more sophisticated. It's also worth remembering
that the Palm Database format does not time-stamp the individual records,
so perfect synchronization is impossible even in principle, never mind
in practice.
The Treo 600 also supports SyncML, so it should be possible to
synchronize over-the-air with any web-based PIM application that
supports the SyncML protocol. I haven't tried this yet, so I can't
really comment on its effectiveness.
Using the Treo as a modem under Linux
I have not really had much opportunity to play with this (undocumented)
feature, so I'm unsure about whether, and in what circumstances,
it works. The USB port on the Treo normally carries synchronization
data. However, there is an undocumented `tethered' mode which connects
the USB serial channel directly to the internal modem. You should then
be able to set up a PPP channel -- using RedHat's network configuration
utility, for example -- pointing at /dev/ttyUSB1 as the modem.
To enable tethered mode, you need to dial #*83843733 (for GSM models)
or #*83843733 (CDMA models). In case you're wondering, on a phone with
letters as well as numbers on the dialer, the number
`83843733' corresponds to dialing the word `tethered'. In tethered mode,
you should be able to enter AT modem commands as for any other GPRS
modem. The telephone number you need to dial to establish an outgoing
connection depends on the network operator; for GPRS most UK provider use
a code of the form `#99*'. Alternatively you might be able to dial out
through another ISP. As I said, I haven't chance to try this yet, as I'm
quite happy to use the Treo itself for the kinds of Internet access I
use when I'm travelling.
Software development under Linux
If you want to develop applications for the Treo using Linux as
your development platform, you have a huge selection of languages and
tools available. None, in my opinion, is perfect for Linux users,
for reasons I will
discuss later.
Scripting languages
There are PalmOS implementations of a number of popular scripting
(interpretative) languages,
including Python, Tcl, Lisp, BASIC, and Lua. Development using these
languages is
not specific to Linux -- any platform that has the ability to edit the
source code and transfer it to the device will be usable. No sophisticated
tools are required on the development workstation. The problem with
all of them is that a relatively large runtime system must be installed
on the handheld. They are not particularly fast, either.
Java
Java has really taken off in the mobile computing world. The great advantage
(in principle) of working in Java is that it should be relatively easy
to support a large range of different hardware platforms. However,
Java support for the Treo is rather disappointing. That's not to say that
Java virtual machines (JVMs) aren't available for the Treo: in fact
many different
JVMs are available. The problem rather is that, at present, there is no
standards-based JVM available that will allow full exploitation
of the device.
The most common standards-based JVMs for mobile devices are those
supporting the CLDC and MIDP specifications. You can get CLCD/MIDP
JVMs for almost any handheld device, from a pager right up to, well,
a Treo. IBM, for example, produce such a JVM for PalmOS machines,
as do Sun Microsystems.
Many mobile devices (e.g., the P800/900) have a CLDC/MIDP
JVM built into firmware, so the user doesn't have to download anything
to run Java applications apart from the applications themselves.
All this sounds marvellous but, in fact, CLDC/MIDP is hugely underspecified
for the Treo and similar devices. In reality, CLDC/MIDP is really used
commercially only for games (MIDP2.0 even has a `game API'). CLDC/MIDP
applications can't read or write files, can't make native method calls,
can't interact with hardware except in very limited ways, can't create
or destroy other processes, and have a very restrictive user interface
model. The user interface supports only a handful of basic
elements. In practise, MIDP development is similar to Java
applet development, in that the code runs in a highly constrained
`sandbox' environment. While this may be appropriate for games, especially when
downloaded from the public Internet, it is not at all suitable for
business or scientific applications.
Of course, the great advantage of working with CLDC/MIDP is that, if you
take a bit of trouble, the code you write should work on almost any
mobile device with little or no modification. CLDC/MIDP is well suited
to the PalmOS operating system in general (even if not to the Treo
in particular), and there's a good reason for this: the MIDP platform
was essentially designed with PalmOS in mind. Consider, for example, how a MIDP application has to store and manage data. It can't read or write files,
but it can read or write arbitrary string data from `record
stores'. Each MIDP application can manage any number of record stores,
the structure and content of which are meaningful only to that application.
A MIDP record store is suspiciously similar to a PalmOS PDB database, and
this is no coincidence. For all that, for applications more weighty than
games, MIDP is far too limited. Moreover, the API available to the application
developer has little in common with that provided by desktop
Java implementation. This means even
an experienced Java developer will have a load of new stuff to learn
when starting on MIDP development.
The next size up in standards-based JVMs is CDC/PersonalProfile. This is
very similar to the old (now obsolete) PersonalJava specification
(which is supported out-of-the-box by the Ericsson P800/900, and by
the Zaurus, among others). The user interface is based on the AWT model which,
for all its problems, is at least familiar to many developers. This
JVM does allow access to specific files and directories, and supports
a greater range
of networking operations. I was dismayed to find that there is no
implementation of CDC/PersonalProfile or PersonalJava for PalmOS
[Update 11/05 -- regrettably, this appears still to be the case].
There are more sophisticated JVMs than CLDC/MIDP available for PalmOS.
The most well-known example is probably SuperWaba. SuperWaba is
optimized for the more advanced mobile devices, and includes APIs for
hardware access (including IP networking, IrDA, and bluetooth). Applications
can
do file I/O, and make native method calls. The problem is that
SuperWaba is not standards-based. Its API is entirely proprietory, and
exists only as part of SuperWaba itself. Consequently a SuperWaba
application will only run on the SuperWaba JVM, or something that
emulates it. Not only is the API different from any of the standards-based
JVMs, SuperWaba isn't 100% compatible with standard Java syntax. For example,
there is no synchronized keyword in the language. However,
SuperWaba applications should run on any mobile device that can run
the SuperWaba JVM, and this includes Windows CE devices, as well as
desktop systems. So there is cross-platform compatibility to a degree.
Another interesting Java platform, currently in beta, is jump.
This is a Java bytecode compiler for PalmOS. What it does is to
turn compiled bytecode (that is, .class files) into m68k assembler, which
can then be assembled to native machine code using Pila
(see below). Jump also includes a compiled version of the SuperWaba
runtime environment, so you can compile SuperWaba applications all
the way to native machine code. You'll still have to monitor a non-standard
API and, to be brutally honest, compiling Java to machine code throws away
one of its primary advantages -- cross-platform compatibility at the bytecode
level. However, the jump strategy benefits from producing a
stand-alone executable; users don't need to install a separate JVM to run
jump applications.
In summary, SuperWaba seems to offer the most flexible approach to
developing Java applications for the Treo, provided you don't mind the
fact that you're working to a completely proprietary, non-standards-based
Java API. Even if an implementation of CDC/PersonalProfile were available
SuperWaba might still be preferable, on the basis that it supports
bluetooth, USB, IrDA, and other hardware facilities that CDC is unlikely
to support.
C/C++
Most PalmOS applications are developed in C or C++. In order to make
sense of the development options available in C/C++, it is necessary
to know something about the history and architecture of the PalmOS
platform. Until quite recently, all PalmOS devices were based on
a Motorola 68000-derived CPU (`m68k'). m68k is getting a bit long
in the tooth, so the Palm guys decided that with the latest generation
of devices, it was time to move to a more modern CPU: ARM. So
PalmOS 5.0 and later (Treo runs 5.2 as delivered) is an operating
system that supports ARM.
It's worth thinking for a minute about how radical this decision is:
it's as if Microsoft were to decide that the next generation of its
Windows OS
would run on Sun Sparc hardware rather than Intel hardware.
The problem, of course, is that legacy
m68k applications have to continue to run on PalmOS 5.2 and ARM
architecture. m68k and ARM are about as different as any two
CPUs can possibly be: different instruction sets, different registers,
different byte ordering (`endianness'), different everything. So,
PalmOS 5.x contains a compatibility engine that emulates m68k operations
on the ARM. In fact, legacy m68k applications work perfectly well
on the Treo: you'd hardly know they were being emulated. Of course,
they are being emulated, so the full power of the CPU is not
apparent.
The odd thing (which is where developers are going to have most
trouble) is that most of the PalmOS core software itself is not
ARM code: it is m68k code. That's right: PalmOS is an m68k application
running itself on its own compatibility engine. It appears that only
the most fundamental OS operations are done in native code on PalmOS
5.x. There are (at least) two good reasons for doing things this
way. First, by keeping the PalmOS code as m68k, it is much easier
to support legacy applications. It is unnecessary to reorganize
a load of data and stack every time an application calls into the
PalmOS APIs, for example, if the APIs are based on m68k callers.
Second, it is, presumably, a major undertaking to reimplement the
whole PalmOS system in ARM code, although it has been suggested
that this will be done for PalmOS 6.0.
The practical upshot of all this is that if you were hoping to
write a C/C++ application, then compile it on your workstation
using an ARM cross-compiler for deployment on the Treo (or any recent
PalmOS device), you're right out of luck. The PalmOS application
launcher can only launch m68k apps, even on the ARM platform!
If you want to run ARM code, you've got to compile it into
a separate library, and call it from an m68k wrapper. In addition,
you will have to take care of byte-order swapping of data passed
from the m68k wrapper to the ARM code, and vice-versa, and
mangling the stack frame for calls into the PalmOS APIs.
What this means in practise is that most developers who target
ARM-based PalmOS are actually compiling most of the code,
and all of the code that interacts directly with the PalmOS core,
for m68k, and allowing it to run under emulation. If this seems
horribly inefficient, well it probably is. However, for most
PalmOS apps speed is not really an issue. Very often the overall
speed of the application is limited to how quickly the user can
manipulate the stylus. It's really only games and media players
where there are significant gains to be made by using the
ARM CPU directly.
So, in short, for most PalmOS developers, the process of
application development for PalmOS 5.x on ARM is exactly
the same as for m68k. They're producing the same kind of
code, making the same kind of API calls. The linking
and post-processing steps are exactly the same too. If
you want to use ARM code directly, you'll need an ARM
cross-compiler for the ARM modules, but you'll still need
at least part, perhaps most, of the application to be
m68k-compatible. There is a very good argument for making
all the application m68k, which is that it will work
on earlier PalmOS devices as well, provided you're careful
about the API calls you use.
To develop for the Treo on Linux, you'll need the following
tools. They are all available from the PalmOS developer web
site, although most are not actually associated with the Palm
organization.
First, you'll need an m68k cross-compiler. As I said, you'll need
this even if you plan to target the ARM chip; in that case you'll
need an ARM cross-compiler too. The prctools project
has ports of gcc that produce both m68k and ARM code.
On my Redhat 9 system I installed both compiler versions from the RPM
packages available from the developer site, and they worked fine
(with a bit of tweaking, as explained below). The prctools
compilers can link as well as compile, so you don't need a separate
linker.
Although the prctools compilers will compile well-formed
C to ARM and m68k, they don't know anything about the specific PalmOS
API. So the second thing you'll need is the PalmOS (version 5)
SDK from the Palm developer site.
It requires registration to get this, but it doesn't cost anything.
The SDK contains header files, libraries and documentation. You can
unpack the SDK anywhere you like, but you'll need to configure
prctools so that it knows where the default headers
and libraries are. The utility palmdev-prep does this:
palmdev-prep /path/to/sdk
You will need the SDK even for the most trivial applications, as it
defines data types of the right size for the PalmOS APIs. For
example, most API calls that take an integer argument expect data
of type UInt16, not unsigned int.
Since the data passed to the APIs must be of the right
size, and the different platforms running the C compiler may have
different data sizes, using the PalmOS-defined types ensures that
the correct size is generated on all platforms. Of course the SDK
also defines the API calls themselves, of which there are now
many hundreds.
The third thing you will need, unless your application is really
trivial, or works at a very low level, is a PalmOS resource compiler.
This takes a textual definition of the menus, screen layouts, fonts,
and text strings in your application, and compiles them into
binary format. If you've ever done any Microsoft Windows development,
you'll note that the resource file format is almost the same as on
Windows, which is in turn almost the same as that on Apple MacOS,
which is almost the same as in the GEM system, going back to the dawn
of time. There is a Linux application, available from the same place
as everything else, called pilrc that serves as
the resource compiler.
Finally, you may need an emulator. At present the best-maintained
PalmOS emulator for Linux is probably pose. Please note
that pose has a dependency on the Fast light toolkit (FLTK),
and that the most recent versions of FLTK (after version 1.1.0) don't seem
to work. I am running pose version 3.5 with FLTK
version 1.1.0 on Redhat 9, and this combination seems to work fine.
Note that pose does not include any PalmOS firmware: you'll
need to obtain this from somewhere. Don't be tempted to download it
from the Treo, as PalmOS 5.x contains ARM code, and pose
only emulates m68k. In fact, so far as I am aware there is no
emulator for PalmOS 5.x for Linux, so if you want to develop ARM
code you'll need to test it on the device, or resort to Windows.
You can get PalmOS 4.x-series firmware from the Palm developer site,
again by enrolment in the company's developer program. Of course, you
won't be able to use the emulator to test code that uses API calls new
to PalmOS 5.x.
The process of building an m68k PalmOS app (and remember: all
PalmOS app are m68k apps, even on ARM devices), is well documented,
so I won't go into details here. This is just a brief summary so you
can get the general idea.
- Compile the C/C++ source files to COFF objects, using
m68k-palmos-gcc from the prctools package.
- Link the source files with any libraries you need (again using the same
utility).
- Split the linked executable into PalmOS-friendly segments using
m68k-palmos-obj-res (also from prctools).
This tool produces segment files
with names like code0000.app_name.grc.
- Process the resource file using
pilrc. This produces
a set of .bin files, one for each resource described.
- Pack the
.bin files and .grc files
into a single PRC file using build-prc.
It's relatively straightforward to wrap up this set of steps into
a Makefile, and the build process then consists for running
make.
Palm's preferred development environment is (or, at least, was)
MetroWerks Code Warrior. Palm produces plug-ins
for this environment for doing things like object splitting and
PRC packing. Note that the format of the resource definition file
used by the Code Warrior plug-in is not identical to that used by
pilrc; so if you're looking at code that's been
developed using Code Warrior, don't expect it to look exactly the
same with Linux tools.
Other languages and tools
For the die-hard hacker, Pila is a m68k cross-assembler
for Linux. Even if you aren't sufficiently masochistic to program
in assembler, Pila is interesting because some other tools output
Pila source, which can then be assembled into
native machine code executables.
This is the approach taken by jump, for example.
There are also a couple of relatively complete implementations of
FORTH for PalmOS.
Video encoding under Linux
A number of video players are available for the Treo; these include
MMPlayer, TealMovie, and Kinoma. Of these, so far as I can tell MMPlayer
is the only one which can play native DIVX and MPEG video streams --
the others use proprietary formats. The software for converting ordinary
video into these proprietary formats is invariably for Windows, so
if you don't want to use Windows, your only sensible choice is MMPlayer
[Update 11/05 -- since I wrote the last sentence, a new open-source
media player has arisen: TCPMP. I haven't really tested this yet, but
it looks very interesting].
MMPlayer is commercial, but reasonably priced. A demo version is available,
which works like the real thing but displays a logo across the picture.
At least the demo is capable of telling you whether purchase of the full
product is likely to be money well spent. It's worth bearing in mind
that MMPlayer has only supported the Treo 600 for a few months (at the time
of writing) and, when I tried it, it wasn't entirely stable. No doubt
this situation will improve with time [Update 11/05 -- it has].
To use MMPlayer you need to encode your movies as MPEG4 (e.g., DIVX), which
gives a reasonable compromise between picture quality and
file size. The resolution of the Treo screen is only 160x160 pixels,
so there's no point encoding with particularly high quality, even
if your source material is a DVD. The MMPlayer developers suggest
aiming for video throughput rates of about 128 kbits/sec, but in
my experience the quality is not markedly worse at 70 kbits/sec,
and the files are half as large. In addition, the Treo's audio system
does not really reward high-quality audio encoding; for movies a bitrate
of 32kbits/sec and 24 kHz is probably more than adequate, and you probably
don't need to encode in stereo if the source is, say, a TV show.
With these settings, I find that I can
get about an hour of video into 100 Mb.
There are two widely-used encoding tools available for Linux:
mencoder and transcode. I normally use transcode for this sort of
thing, but I found that however much time I spent on it, I could
not get transcode to produce DIVX files that MMPlayer could play
at all. So I had to settle for mencoder. To get the settings
described above, I use the following command line:
mencoder -srate 24000 -oac mp3lame -lameopts br=32:cbr:vol=6:mode=3 \
-ovc lavc -lavcopts vcodec=mpeg4:vhq:vbitrate=64:keyint=300 \
-vop scale=160:120 {outfile}.avi {infile}
Obvious, isn't it? The interpretation of these switches is as follows:
-srate 24000: audio sampling rate of 24 000 samples per second
-oac mp3lame -lameopts br=32:cbr:vol=6:mode=3: output audio codec `mp3lame', with settings of 32 kBits/sec, constant bit-rate, output level 6/10, monaural
- -ovc lavc vcodec=mpeg4:vhq:vbitrate=64:keyint=300: video output through the
libavc library, codec MPEG4, with multi-pass encoding (vhq), target bitrate 64 kbites/sec, 1 keyframe every 300 frames (the minimum that will work!)
-vop scale=160:120: scale down to 160x120 pixels
You might have to adjust the output pixel dimensions if the aspect ratio
of the source is not 4:3.
The previous command should work on any file that mencoder is about to
understand, but most binary distributions of mencoder won't
directly process DVD VOB files if they are encrypted.
To get this to work, you'll need to compile mencoder yourself with
CSS support (which is a pain). However, the tccat utility
which is part of transcode can decode VOBs into MPEG files, and
the binary distributions of this utility do usually include
CSS support. So, to extract a DVD title to MPEG, do:
tccat -i /dev/dvd -T {title_number},-1 > outfile.mpg
Be aware that this generates about 1 Gb of data for each hour of
video.
Applications
This section describes some PalmOS applications that may be of particular
interest to Linux users.
Plucker
There are various e-book formats supported by Palm applications. I generally
use Plucker, which supports hyperlinks, rudimdentary formatting,
and images. A freeware Plucker viewer is
widely available for the Palm platform. In my view, the best Linux
application for producing Plucker-format documents is Sunrise
(formerly called JPluck or JPlucker). This is a Java application, so you'll
need a Java run-time installed to use it. Sunrise produces Plucker documents
from sets of HTML or plain text documents.
Recent PalmOS Plucker viewers have VFS support, and will read documents
from a memory card under the directory /PALM/ebooks, so
you can get Plucker documents to your Treo under Linux simply by copying
them a memory card.
GNU Keyring
Keyring is an open-source secure data manager, useful for managing
bank details, log-in credentials, etc. Keyring isn't the only program
of this type that the Treo will run, but it has great advantage for
Linux users -- jPilot will view, edit, and synchronize Keyring data.
Pilot-DB
Pilot-DB is a general-purpose database application for PalmOS. What makes
it interesting for a Linux user is that there is a Java application,
which will run on Linux, for viewing and editing Pilot-DB data without
any intermediate format conversion.
©1994-2006 Kevin Boone, all rights reserved