Hello, folks!
I'm working on building a prototype of an info appliance that uses an electronic paper display for its form factor and readability.
I have a prototyping platform from eInk (http://www.eink.com/kits/index.html) that uses a Gumstix SBC to drive a specialized display driver connected to the electronic paper.
Given Squeak's exceptional portability, I'd like to use it to build a demo to run directly on the device.
I'm gearing up to port Squeak to the device starting with the existing Linux port (the Gumstix comes w/ Linux running on it). But I'm not sure how to get the VM to send output to the eInk-supplied API (source code included) to the electronic paper driver.
I've found Ian's "Squeak on Linux Framebuffer" page and think that will help. But minnow's timing out right now so I can't dig deeper into that.
Anyone else have other pointers/advice/etc?
TIA
Bob Courchaine
On 25-Nov-05, at 10:17 AM, Bob Courchaine wrote:
I have a prototyping platform from eInk (http://www.eink.com/kits/index.html) that uses a Gumstix SBC to drive a specialized display driver connected to the electronic paper.
Neat! Nice to see something becoming available at last. Ouch! $3000 !
Given Squeak's exceptional portability, I'd like to use it to build a demo to run directly on the device.
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.
I'm gearing up to port Squeak to the device starting with the existing Linux port (the Gumstix comes w/ Linux running on it). But I'm not sure how to get the VM to send output to the eInk-supplied API (source code included) to the electronic paper driver.
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.
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.
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.
It sounds like you're going to have some fun here Bob.
tim
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
Am 25.11.2005 um 20:22 schrieb Bob Courchaine:
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,
Actually, Squeak is quite happy to render to a 2 bpp display. I guess what Tim meant with "acceptably" was that the actual colors (err, gray tones) used throughout the system might not be appropriate. Like, if you just set Squeak's display depth to 1 bpp on your desktop machine, the Morphic menus are transparently dithered to complete illegibility. But you wouldn't want Morphic there anyways I guess.
Regarding endianness: BitBlt now deals fine with LSB forms, I thought. Works fine for 8 bpp at least, not sure about 2, though ...
- Bert -
Bert Freudenberg wrote:
Regarding endianness: BitBlt now deals fine with LSB forms, I thought. Works fine for 8 bpp at least, not sure about 2, though ...
Looks like it's been there since 2001, Bert. And this note implies down to 1 bpp IIRC.
(from http://lists.squeakfoundation.org/pipermail/squeak-dev/2001-May/000076.html)
3984BitBltExtensions-ar -- Andreas Raab -- 4 May 2001 The change set includes various extensions for BitBlt with the goal of migrating the useful features from FXBlt into the general BitBlt mechanisms. These include: * Handling of LSB and MSB forms: BitBlt now handles both, MSB and LSB forms (and their conversions). Only instances of Bitmap are assumed to contain big-endian pixels. All others are assumed to be little endian (reason is that we can only identify Bitmap here). Note that 'LSB' and 'MSB' refers to PIXELS, that is a 1bpp LSB form has its left most pixel in the lowest bit whereas a 1bpp MSB form has its left-most pixel in the highest bit. For pixel depths < 8 this can be different from what your OS supplies (as an example, Windows bitmaps < 8 are big-endian pixels in little-endian words; we might call them 'middle-endian'). We simply don't deal with those - forms are either big or little endian but nothing inbetween. BitBlt has got an extra combination rule for swapping pixels in the destination form. This can be used to make byte swapping much more efficient (as soon as we've got more VMs with support for it).
Am 25.11.2005 um 23:44 schrieb Bob Courchaine:
Bert Freudenberg wrote:
Regarding endianness: BitBlt now deals fine with LSB forms, I thought. Works fine for 8 bpp at least, not sure about 2, though ...
Looks like it's been there since 2001, Bert.
It's been that long already? Rats, I'm getting old ... To my defense I could say that 4 years is still rather recent compared to the 30 years BitBlt has been around in Smalltalk ;-)
At least any VM in use now should have little-endian BitBlt support.
But it still is a lesser know feature - if even Tim didn't know or remember, who would? ;-)
And this note implies down to 1 bpp IIRC.
(from http://lists.squeakfoundation.org/pipermail/squeak-dev/2001-May/ 000076.html)
3984BitBltExtensions-ar -- Andreas Raab -- 4 May 2001 The change set includes various extensions for BitBlt with the goal of migrating the useful features from FXBlt into the general BitBlt mechanisms. These include:
- Handling of LSB and MSB forms:
BitBlt now handles both, MSB and LSB forms (and their conversions). Only instances of Bitmap are assumed to contain big-endian pixels. All others are assumed to be little endian (reason is that we can only identify Bitmap here). Note that 'LSB' and 'MSB' refers to PIXELS, that is a 1bpp LSB form has its left most pixel in the lowest bit whereas a 1bpp MSB form has its left-most pixel in the highest bit. For pixel depths < 8 this can be different from what your OS supplies (as an example, Windows bitmaps < 8 are big-endian pixels in little-endian words; we might call them 'middle-endian'). We simply don't deal with those - forms are either big or little endian but nothing inbetween. BitBlt has got an extra combination rule for swapping pixels in the destination form. This can be used to make byte swapping much more efficient (as soon as we've got more VMs with support for it).
It might just work if you request -2 bpp for display:
ioHasDisplayDepth(int d) { return d == -2; }
- Bert -
On 26-Nov-05, at 2:51 AM, Bert Freudenberg wrote:
Am 25.11.2005 um 23:44 schrieb Bob Courchaine:
Bert Freudenberg wrote:
Regarding endianness: BitBlt now deals fine with LSB forms, I thought. Works fine for 8 bpp at least, not sure about 2, though ...
Looks like it's been there since 2001, Bert.
It's been that long already? Rats, I'm getting old ... To my defense I could say that 4 years is still rather recent compared to the 30 years BitBlt has been around in Smalltalk ;-)
At least any VM in use now should have little-endian BitBlt support.
But it still is a lesser know feature - if even Tim didn't know or remember, who would? ;-)
I spent quite a while trying to make use of the supposed littleendian support mentioned and it simply didn't function correctly for my RISC OS vm so I forgot about it.
To be honest, with the only interesting bigendian machines being the PPC Macs - and they're on the way out - it would make more sense to just make Squeak do littleendian pervasively.
tim
squeak-dev@lists.squeakfoundation.org