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 :)
: \
I have put up a screenshot at:
http://metaphorse.com/amiga/squeak/
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.
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+...
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.
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.
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
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]
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+...
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 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.
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.
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; tim@rowledge.org; 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:
On 4-Jun-06, at 8:53 AM, Tim Johnson wrote:
On May 30, 2006, at 5:02 AM, Bert Freudenberg wrote:
[snip]
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+...
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.
- Bert -
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@rowledge.org; 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:
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@rowledge.org; http://www.rowledge.org/tim Disclaimer: Any errors in spelling, tact, or fact are transmission errors.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
vm-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
John M McIntosh -
Tim Johnson -
tim Rowledge