I worked on a Squeak port to Palm OS about 1999 (coming at it as a very 
experienced Palm OS programmer and a newbie Squeaker), and am very 
familiar with the issues involved:

The Palm OS is split into the dynamic heap and the storage heap (which 
is write-protected, and requires an API to write). It isn't practical 
to run an image directly from the storage heap.  Either every write to 
the image requires an API call (DmWrite), or you've got to use the 
undocumented (and dangerous) MemSemaphoreReserve, which turns off 
write-protection.

At the time I was working, there were no devices with a large enough 
dynamic heap to hold an image.  I looked at two different ways of 
running the image from the storage heap:
	Storing the image in separate 64K chunks, and using a macro to 
determine the actual memory address to use to read from/write to
	Storing the image in a large storage heap chunk (allocated using 
FtrPtrNew).  When the app opened, it'd copy the image from the database 
to the large chunk. On close, it'd write it back out.

Another alternative to storing the image would be as a file on an SD 
card.  You use VFS calls to open/close/read/write.

If I were approaching it today, I'd target the couple of devices that 
have a large enough dynamic heap to be useful:
	
  Tungsten C   12MB 
  Tungsten T3  11MB 
  Zire 72      5MB   

I think the Tungsten C or T3 would be a very workable Squeak device.


When the app opened, I'd allocate a large dynamic memory chunk (using 
MemChunkNew with the memNewChunkFlagAllowLarge flag to allow a larger 
than 64K allocation).


Warnings:
	One large problem is code size: no code resource can be larger than 
64K (shades of old Mac programming).  The VM source code needs to be 
segmented:
	If you're using CodeWarrior, you need to add #pragma segment 
directives before every function. If you're using GCC, you need to 
specify function segmentation in .h files.  When I did this work, I 
added the segmentation by hand.  Were I to do it again, I'd try to 
change the source generate to specify the segment directives.

Unfortunately, I'm no longer able to find the work I'd done (I'd gotten 
as far as displaying and evaluation 3 + 4).  A much easier port would 
be to the Cobalt OS: simple memory map, no 64K limit on code resources.

If anyone wants any help on a port, I'd be happy to provide technical 
guidance,


Neil

On Feb 17, 2005, at 3:23 PM, Ned Konz wrote:

> On Thursday 17 February 2005 10:20 am, Blake wrote:
>> Anyone done Squeak on the Zire?
>
> No, and it's unlikely that anyone would want to unless they were a 
> masochist.
>
> However, I heard a rumor that IBM Almaden Labs did a Squeak port for 
> the Palm
> OS (3?) a while ago. Anyone know more about this?
>
> I'd love to have such a thing, as would a number of other people I 
> know. Steve
> just got a Tapwave Zodiac, and Dan just got a Treo 650.
>
> The memory "management" is ... interesting ... there's no guarantee 
> that you
> can get a single block of database memory that's big enough for a 
> Squeak
> image. In fact, I believe (could be wrong here) that the max size of a
> database record is just less than 64K in size. Squeak assumes a single
> contiguous chunk of memory in which it can put 32-bit pointers that 
> will
> remain valid through a session. There are also "resource" chunks, but 
> it
> doesn't seem to make much sense to copy the entire Squeak image from 
> RAM
> (database) into RAM (resource) just to run it.
>
> Also, the ARM-based Palms are actually emulating 68K processors much 
> of the
> time when running 3rd-party code, though you can make individual 
> native ARM
> code subroutines ("ARMlets") that you can call via a thunk of some 
> kind.
> interpret() and friends would be a candidate for this treatment.
>
> Anyone know more about Palm OS 4 or 5 memory management?
>
> -- 
> Ned Konz
> http://bike-nomad.com/squeak/
>
>
--
Neil Rhodes
Calliope Enterprises, Inc.
1328 Clock Avenue
Redlands, CA  92374
(909) 793-5995
neil at pobox.com