I've ported Squeak 2.3 to Amiga, more or less

John M McIntosh johnmci at smalltalkconsulting.com
Mon Jun 5 01:59:45 UTC 2006

The mac VM had various ways of moving data between the squeak display  
surface and the big-endian quickdraw surface.
Currently it uses quartz to do that in the 3.8.12 VM.
Earlier versions of the code move data by word/bits and bytes from  
various combinations of 1/2/4/8/16/32 to 1/2/4/8/16/32
Earlier versions of this code used code from the unix version which  
had limited bit depth mapping algorithms.

On 4-Jun-06, at 12:32 PM, tim Rowledge wrote:

> On 4-Jun-06, at 11:16 AM, Bert Freudenberg wrote:
>>> Ah, Squeak bitmaps are BIG endian, not little. The first  
>>> implementation was 68k mac based and the PPC. Us little endian  
>>> guys (ARM, x86 etc) had all sorts of fun developing efficient  
>>> Squeak 'Display' to actual glass transfer routines. You would  
>>> most likely benefit most from looking at the Mac code for this  
>>> stuff. You might need to convert the *pixel* format though since  
>>> not every platform is RGB. RISC OS is little-endian BGR for  
>>> example, some thing that took a lot of attention to resolve in  
>>> the early days of Squeak.
>> Note, though, that the recent bitblt code can deal with both,  
>> little *and* big endian RGB. While big endian is standard, little  
>> endian is indicated by negative depth values. However, I guess a  
>> 2.3 image might not have the in-image support for negative bit  
>> depths, yet, and also, it might not call the hasDisplayDepth  
>> primitive. Implementing bit shuffling for big endian still is the  
>> most compatible way.
> I never did manage to get that stuff to work on RISC OS,  
> unfortunately. It certainly doesn't cope with pixel format  
> conversions, for one thing. 2.3 doesn't have image support for it  
> and I don't think VM support went in until about 3.4 or so; could  
> be wrong.
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Disclaimer:  Any errors in spelling, tact, or fact are transmission  
> errors.

John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com

More information about the Vm-dev mailing list