| My professional interests |
|
Computing Law Education Science and research |
| My leisure interests |
|
Martial arts Heritage railways Garden railways Motorcycles DIY |
| Downloads |
|
Linux downloads Windows downloads Java downloads Perl downloads Home automation downloads |
| About me |
|
Home & family My CV |
| Site info |
|
Contact the author Download policy Keyword index |
ehci-hcd.o) for the USB2.0 low-level protocol at boot time.
I have found that 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.
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 thepilot-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
Althoughpilot-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; probablyjpilot 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/sdkYou 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-gccfrom theprctoolspackage. - 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 fromprctools). This tool produces segment files with names likecode0000.app_name.grc. - Process the resource file using
pilrc. This produces a set of.binfiles, one for each resource described. - Pack the
.binfiles and.grcfiles into a single PRC file usingbuild-prc.
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
libavclibrary, 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
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.
| Search |
| Shameless plug |
 By the author of this site. Buy on-line from Amazon USA | UK |
| Editorial |
So you want to be a university lecturer? Read this first! Speak like your boss: new developments in managerese |
| Computing features |
|
File handling in the Linux kernel: an in-depth look at how Linux handles files, filesystems, and file I/O
All sorts of Linux stuff Confused about CLASSPATH? answers are here First steps in EJB using jBoss (recently revised for jBoss 3.2) |