On Tue, Mar 26, 2002 at 11:17:26PM +0530, Mayuresh Kathe wrote:

I was wondering about framebuffer because, then we can build low costing, solid state computers running Squeak (for schools).

Absolutely! Plus, I like the novelty of running without X as well. :)

BTW, where did you get the framebuffer version of Squeak? How big was it (other than the image)

~Mayuresh

Well, I don't believe there is an official framebuffer-enabled squeak to be found anywhere...I hacked my own code up from bits and pieces of other people's code, primarily the Helio and Itsy code (you'll probably find references to at least one of them on http://minnow.cc.gatech.edu/squeak). I wasn't really successful with it, not having a very good grasp of the framebuffer (or even the orignial Xlib code).

It's been over a year since I tried, but I believe the resultant VM executable was notably smaller than the X11-linked one (and this was an unoptimized ARM executable). Sorry, I don't remember specific file sizes. :) There are others on this list that have better experience with the framebuffer that probably know, however.

On the other hand, the people at handhelds.org have some good arguments for keeping X (specifically Jim Gettys)...the framebuffer X server they use on the iPaq is remarkably small and lightweight. They've done some marvellous work weeding out the old unused bits and slimming XFree86 down...keep in mind that this runs on low-memory handhelds (16 meg ram, typically, with lots of space left over for other applications). The advantages of continuing to use X is the application base, of course.

If you look at the configuration options for building Xfree86, you can really streamline the executable.

...

From: Kevin Fisher kgf@golden.net Reply-To: squeak-dev@lists.squeakfoundation.org Date: Tue, 26 Mar 2002 12:43:21 -0500 To: squeak-dev@lists.squeakfoundation.org Subject: Re: Squeak on framebuffer?

Framebuffer would be neat, but I think a better idea would be an SDL-enabled Squeak...that way we could support any graphical target, whether it be X11, framebuffer or OpenGL (not to mention the different sound output targets SDL knows about).

I once tried to get framebuffer Squeak running on my iPaq, but not being very graphics-saavy, I didn't get very far (I did get the Morphic interface to draw on the screen, but the colours were screwed up, and no pen/mouse input). I pieced together some framebuffer code from various sources to make it work...I think the bulk of it was a modified version of the Helio framebuffer code. Eventually I just gave up on it. :)

On Tue, Mar 26, 2002 at 10:57:58PM +0530, Mayuresh Kathe wrote:

...

Hi,

Does anyone have an idea about how to get Squeak running on raw framebuffer?

That way we can really do away with the (sic) X Windowing System...

~Mayuresh

Cool, I wondered about that...I remembered about a year ago someone wrote to the list about SDL, but I may have missed the code.

:)

So, in theory, if this code can be rolled into a recent VM, it should be able to write directly to the framebuffer (for those of us who desire it)...not sure if SDL handles mouse events as well, though.

On Sat, Mar 30, 2002 at 08:46:28PM -0400, Lex Spoon wrote:

Kevin Fisher kgf@golden.net wrote:

...

Framebuffer would be neat, but I think a better idea would be an SDL-enabled Squeak...that way we could support any graphical target, whether it be X11, framebuffer or OpenGL (not to mention the different sound output targets SDL knows about).

SDL support been implemented:

http://www.zipcon.net/~adamf/software/squeak/sdl-squeak.shtml

If anyone wants to try to fold it back in with the main Squeak release that would be awesome.

-Lex

There are important details however, like handling the pixel endianness & RGB layout right. With extra trickery one can also save memory by making the screen buffer memory actually be part of the Display form bitmap - like I do on the Acorn port.

Well, actually the itsy days are long gone - these days all you need is a little bit of support through the surface manager in order to make your own FB display. Just for the heck of it, I've written a little FB driver plugin which is attached. Note that these days we don't even have to worry about endianess and colors - this has been fixed over time and BitBlt is quite capable of handling almost everything correctly[*] (the test case uses a 16bpp little endian display with red and green bits swapped ;-)

[*] Under the assumption that pixel words go left-right and top-down which is apparently _not_ true on all hardware (like PDAs).

The ST side is pretty trivial and the C part self-explanatory (I hope). If anyone is really interested in this stuff let me know.

Cheers, - Andreas

Hi,

I am *mighty* interested :) Seriously...

Well, just let me know how it goes. There's lots of stuff I left out of my little demo to keep it simple yet complete.

Only problem, I don't have direct access to a Linux machine. And the one I do have to doesn't have Framebuffer support (stupid i810)

Well, you might be interested in http://sourceforge.net/projects/i810fb/

Cheers, - Andreas