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

Am 30.05.2006 um 08:02 schrieb Tim Johnson:

> Hello all,
>
> What a lovely weekend!   I have spent the majority of it indoors,  
> porting Squeak 2.3 to the Amiga!

One weekend? Nice :)

Oh I guess every VM hacker has seen this :) You might just copy the  
bit depth conversion routines from another VM.

> You may wonder why I used 2.3 ... It seemed to be the best choice  
> for a simple, well-documented, starting-from-scratch VM-building  
> scheme, with little-to-no dependence on plug-ins.  I am scared of  
> VMMaker (it seems to be designed to create/tweak a VM for an  
> already-existing platform, versus a new one?), plus there is  
> already much documentation on Interpreter>>translate.  Of course, I  
> am ignorant.

I think you're the first one porting Squeak to a new platform after  
VMMaker. So there might be indeed some overly helpful features in there.

Or is it not VMMaker, but rather that the VM got more complicated  
because we rely a lot on modules nowadays? I'm not quite sure what we  
actually need for a minimal functioning Squeak port.

> Overall, this has been a pretty fun pastime.  I can continue  
> posting progress reports to the list if anyone is interested.  I  
> have to figure out this PixMap -> BitMap thing, but I also have to  
> get to work in the morning... ;)

Sure, please, keep us posted!

And, to get the attention of most people interested in the VM (even  
those who do not follow squeak-dev closely) you should post to the vm-
dev list, too:

        http://discuss.squeakfoundation.org/cgi-bin/ezmlm-browse?list=vm-dev

- Bert -

On May 30, 2006, at 5:02 AM, Bert Freudenberg wrote:

>> What a lovely weekend!   I have spent the majority of it indoors,
>> porting Squeak 2.3 to the Amiga!
>
> One weekend? Nice :)

I must give credit to the VM documenters -- it really is as easy as
they say it is.  Plus, the SAS/C compiler on the Amiga is really nice,
and ANSI-compliant, and I have the printed documentation for it, which
helps a lot.

>> I am obviously having some trouble with graphics (specifically,
>> ioShowDisplay), but the screenshot is recognizably showing Squeak
>> asking for its .changes file.  To an outsider, though, it may look as
>> if something is *broken*... ;)
>
> Oh I guess every VM hacker has seen this :) You might just copy the
> bit depth conversion routines from another VM.

Yes.  I am working on this.  I think the main issue is Squeak's PixMaps
/ BitMaps being little-endian, and the Amiga being big-endian.  I am
looking at the UNIX-VM source for tips (I found a function there for
8-bit depth to 8-bit depth blits).  What's strange is the Squeak 2.3 VM
seems to not use ioHasDisplayDepth(), so if I want to implement
16-bit/32-bit display depths on my Amiga VM I might have to move up to
2.4+...

It seems to be both of these are the issue for me.  It is much easier
to get the VM up-and-running when I don't have to worry about compiling
dynamic libraries and making sure they mesh with the Squeak modules
system.  The Amiga has great support for dynamic libraries, but I am no
whiz with them.

Done.

Thanks,
Tim

On 4-Jun-06, at 8:53 AM, Tim Johnson wrote:

>
> On May 30, 2006, at 5:02 AM, Bert Freudenberg wrote:
[snip]
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.

You don't need to worry about any dynamic library stuff yet. Take a  
look at the code in the vmmaker C code tree in platforms/Cross/vm/
sqNamedPrims.c which uses functions in platforms/{various platforms}/
vm/sq{blah-blah}ExternalPrims.c. Now see about implementing the  
latter functions as nulls, returning 0 or false or whatever is  
appropriate. For example for ioFindExternalFunction(char*, void*),  
return (void*)NULL to say "I know nothing about this". Similarly for  
ioLoadModule.  I think ioFreeMOdule can just return 0.

Then you use VMMaker to assemble all the generated files with all  
plugins *internal*. That means that all their entry points are stored  
in an internal array of pointers and there is no use whatsoever of  
any external dynamic lib flummery. Simple.

All in all, VMMaker was designed to try to make it really simple to  
keep control of your port and to make it uniform and portable. One of  
the original aims was a scriptable app that would allow us to have a  
single machine generate the code for all platforms to suitable places  
and then have them compile each night automagically. It's certainly  
trivially scriptable (look up the swiki page about VMMaker as opposed  
to VMMakerTool) but I never did quite finish the cross-generating  
stuff, though I do have a changeset sitting around awaiting  
integration that is claimed to fix even that.

Good luck.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Life by Norman Rockwell, but screenplay by  
Stephen King.

Am 04.06.2006 um 19:36 schrieb tim Rowledge:

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.

- Bert -

On 4-Jun-06, at 11:16 AM, Bert Freudenberg wrote:
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; [hidden email]; http://www.rowledge.org/tim
Disclaimer:  Any errors in spelling, tact, or fact are transmission  
errors.

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:

--
========================================================================
===
John M. McIntosh <[hidden email]> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===