To reiterate from a message at least a year ago (lost in the sands of the Squeak
mailing list :-) here's the memory model on a PalmOS device:
1. All of RAM, no matter how large it is, except for 96 KB is allocated for Palm
databases.
2. You can define your own record structure at the bit level for your own
private Palm database, but:
    a. Each record is limited in size to a max of 64KB.
    b. PalmOS manages your records for you, puts hidden and undocumented info
around each record, and may move the records around in memory (the unlocked
handle problem), even interspersing your records with records from other
databases.
    c. You can read byte-by-byte from your records, but you CANNOT WRITE to your
records without going through the Palm database API (which does bounds checking,
etc.) so that you don't corrupt anything but your own database :-)
3. Of the 96KB on non-DB RAM, most is used for the execution stack, TCP/IP
buffers, etc., leaving at max 32 KB of application heap (what most C programmers
would consider to be "real memory").

The most useful way of thinking about Palm devices and the PalmOS is as a
handheld collection of databases (which can easily be synchronized with the
desktop) and SMALL(!), simple browser apps for those databases.  It's definitely
not a general purpose application platform like the Mac or Windows (or Win-CE,
for good or for ill, sigh...).

The above numbers might be slightly off (within 2x) and are worse for Pilots
before PalmOS 3.0.  The net effect is that it's very difficult to directly
implement the Squeak memory model of a single, large, contiguous heap that
Squeak manages, and which collaborates in any reasonable way with Palm
synchronization with the desktop.  The approaches we considered included:
1. Hiding a bunch of (most?) RAM from PalmOS and using it privately for the
Squeak heap.  This would require hacking PalmOS internally and you'd have to
find a non-standard way to synchronize the Squeak heap with the desktop.
2. Dividing the Squeak heap up into "pages", each one of which would be stored
as a legal PalmOS record.  This would automatically solve the desktop
synchronization problem.  But to write to objects in memory (with any
efficiency), you have to turn off the database write protection (with an
undocumented system call).  You also have to rewrite the low-level object memory
management in Squeak.  Large objects (e.g., a 1 MB digitized sound) are a
problem.  In fact, you probably want to go "way(!!!) back to the future" of the
original Smalltalk implementations which used a handle-based, paged memory
architecture, rather than the direct pointer approach adopted by Squeak.

All in all, this seemed to be too much work for a marginal implementation -- the
current crop of Pilots are only 16 MHz Dragonball processors.  Given the
more-or-less dismal performance people seem to be seeing on 80 MHz Win-CE
platforms, I dispair of being able to do a zippy Morphic demo on my Palm III :-)
I've downloaded the Handspring SDK, but haven't had a chance to look at it
closely yet.  The idea of a plugin Springboard module is attractive (e.g., I
could put Squeak's VM in ROM in a module -- maybe), but the other problems
remain.

Now where is that $100 handheld with a 200 MHz StrongARM processor, 64 MB RAM,
IBM 340 MB microdrive, color LCD display, Bluetooth wireless LAN, speech reco,
running Linux?........  (I've already got the microdrive :-)

Mike Wirth
Manager, USER Software
IBM Almaden Research Center, 650 Harry Road, NWE/B2, San Jose, CA  95120-6099
Email: wirth at almaden.ibm.com    Ph: 408-927-1898