tim Rowledge wrote:
Jon Hylands has already shown that the gumstix can run Squeak, though I think he went for headless. So the basics of finding the right library/option settings should be easy to copy.
Yep! Got Jon's pages bookmarked as well, Tim! And you're right, he only runs headless for his robotics.
Is the display set up as a framebuffer, or as some sort of external interface you have to copy pixels to? Either can be handled but personally I prefer a frame buffer mapped into main memory space for prototyping stuff like this. Until and unless there is some sort of useful graphics acceleration it is much easier to use plain old memory. Hopefully you will find some decent support library provided with the kit (at $3k I'd damn well hope so) to provide the metrics of base address, width, height, stride, etc.
Their API doesn't use the framebuffer but there's been mention on the kit owner's forum about the merit of building an intermediary to push bitmaps from the fb to the device. At first blush it seems like it's extra work if something like the Squeak VM can be cajoled to talk directly to the board's API. But your point about using system memory makes sense.
Display metrics, etc should be in the forth-coming documentation. It's in the source but reading C gives me a headache! 8^)
A few years ago I did a quick port rather like this for the DEC Itsy prototype (which was pretty much the mother of the iPaq line) which was very similar to a gumstix with a fb screen. Tricky bits were the screen handling and cursor displaying since at that point nobody had written any sort of abstraction for them. I was lucky to be on loan for a couple of weeks to DEC WRL and sharing an office with the guys that built it which makes getting a library written so much simpler.
I bet! The community of kit owners is very small right now (I've got serial number 0013!) and we've got a forum that the driver board API developers are running so at least I can pick their brain that way. One downside is that they're leaning toward eBook applications and I'm not sure how much time they'll have for someone using the kit in a non-typical way.
You will have to copy from the Squeak display bitmap to the actual screen memory and convert from Squeak's big endian pixels to little endian - probably. Although technically ARMs can do bigendian I've never actually met one that was setup that way. You might have some work to do to make a 4bpp display mode work acceptably in recent images since I doubt anybody has used such for a while and bitrot may well have set in. You might be able to use an 8bpp Squeak dispaly and compress during the copy-to-paper (I was going to say glass, but it isn't, is it!) operation.
Hmm-
If 4bpp is going to be tough, I bet 2bpp is going to be even more work, which is what the driver expects to pass along to the display:
(from a kit owner forum thread)
------------------------------snip------------------------------
Hi Thomson,
The basic method is as follows, using the function prototypes in apollo.h :
send_command(FC); // sets global refresh, for best picture quality send_command(A0); // load image command send_data(<image_data>); // image data is 2 bits per pixel, packed 4 pixels ... // per byte. Data should be sent in landscape ... // mode. Complete 600 x 800 image is sent one ... // byte at a time. send_command(A2); // causes the controller to display the // newly-uploaded image
If you want to display a PNG or JPEG image, you will need to process it into a 2 bit per pixel bitmap, either on-board at display time, or off-board (with a preprocessor or by hand). The processing will consist of:
-- decoding the source file into a bitmap -- mapping from color to B/W -- dithering and mapping onto the 4 gray levels of the display (0x00, 0x55, 0xAA, 0xFF in RGB space).
Right now, we don't have software on the Gumstix that does this; this is an excellent area for users to make contributions.
------------------------------snip-----------------------------
It sounds like you're going to have some fun here Bob.
I think you're right, Tim! Thanks!
Bob