Smalltalk on ARM Devices

It is fairly straightforward to compile GNU Smalltalk for an ARM device running Linux. I have done this for the Archos PMA430. You need to install a suitable cross-compiler first. The Archos website contains an SDK and build utilities for this. You will end up with an environment under /opt/Qtopia containing headers and libraries and /usr/local/arm with the cross-compilation tools.

It is useful to compile and install the readline library first (don't forget to install it on your device, too!). This makes interactive use of smalltalk much easier. Then, get version 2.2 of GNU Smalltalk from the GNU FTP site. Configure using a command like:

LDFLAGS=-L/opt/Qtopia/sharp/lib CPPFLAGS=-I/opt/Qtopia/sharp/include
   CC=arm-linux-gcc ./configure --host=arm-archos-linux-gnu --prefix=/media/Unix

(Though make sure the command is all on one line - the newline here is for clarity.)

If you want readline support (and you do, trust me), check that HAVE_READLINE has been determined in your config.log. If it hasn't (I had problems with this), try commenting out line 21996 of the configure script and run the above configure script again. This line is (in case your version is slightly different):

      test $cross_compiling = no && test $ok = yes && (./conftest; exit) || ok=no

(If you don't see this line, search for "readline.h" in the file and look at the section just after the code sample there for the above line.)

This line just doesn't work on my system and always makes the script think I don't have readline available when I do. Removing this line sorts it out.

You may want to change the installation prefix. I use a "Unix" directory on my device to hold everything I've built for it and create links from the /opt area as necessary. This then keeps everything together on the hard disk and you don't have problems with the limited space in the program area. You can create links in the program area to the /media/Unix area to persist across reboots.

Perform an install of this on your build machine. This will give you /media/Unix/share/smalltalk and /media/Unix/bin/gst which must both be copied to your device.

This will get you a standard GNU Smalltalk environment. The first time you run it, you may need to re-build the image file. Do this by running:

gst -iQ /dev/null

NOTE: Don't run the gst command from in a directory containing any standard system class files (such as under /media/Unix/share/smalltalk) as this will try reloading classes and get you in a mess. You can always reset the image file by running the above command from another directory.

I have been working on accessing the framebuffer. I haven't managed to get dynamic library linking working on the Archos, so I have patched in the functions I need to the source. Apply the following patch and recompile:

gst-arm-fb-patch.tar.gz (1k) - patch to add access to the framebuffer

To apply this patch, save this file to the directory containing your unpacked smalltalk-2.2 directory. Unpack it using:

gunzip gst-arm-fb-patch.tar.gz
tar xvf gst-arm-fb-patch.tar

Then change directory to the smalltalk-2.2 directory and run:

patch -p1 < ../gst-arm-fb-patch

This will update the file libgst/cint.c with my framebuffer support files. You will then need to recompile and re-install the binary.

To see that this works, try the following example:

FrameBuffer.st (7k) - example framebuffer access

Copy this file onto your device. You can then run this using:

gst Framebuffer.st

You should see output like the following:

ID: DM270_OSD, len: 77824
Framebuffer type 0: packed pixels
Framebuffer visual 3: pseudo colour
line len: 320, accel: 0
xres: 320, yres: 240, xoff: 0, yoff: 0
bits per pixel: 8
       Offset  Length  MSBR
red          0       8  0
green        0       8  0
blue         0       8  0
transp       0       0  0
screen size: 76800

For different devices, you may well get some different values. This is a port to Smalltalk of an application I wrote to get the same information:

fbinfo.c (3k) - display framebuffer info

The smalltalk version shows examples of defining classes to represent C structures, calling functions using them (note that if a function will write to such a structure, it must already be a new instance of the appropriate class before the call) and accessing elements from the structure. Notice in particular that, although Smalltalk arrays start at 1, access to C arrays start at 0...

Next: to access the colourmap, map the framebuffer into memory and start manipulating the display! :-)