On Mar 5, 2005, at 05:02, Alan Grimes wrote:

> 1. The current SVM source of the VM can't be configured on unix, the 
> error messages are:
>
> acplugins.m4:9: error: m4_defn: undefined macro: _m4_divert_diversion

Cannot reproduce.  FWIW, m4_divert does not occur anywhere in my 
acplugins.m4 -- so I figure it must come from expanding an 
auto{conf,make} macro somewhere and maybe you should double-check that 
your autoconf/automake are installed correctly, working and of 
compatible versions.

> 2. My current unix squeak VM, while operable in the framebuffer mode 
> only supports 640x480x8(bit) (I'm not sure about the last but it is 
> definitely not more than 8).
>
> It really needs a method for controlling screen resolutions....

The fbdev driver should use whatever depth (8, 15, 16, 24) it finds the 
console in when the VM starts.  Try changing it with 'vidmode' before 
running Squeak.

> 3. I currently have two monitors, it would be very nice to be able to 
> open the second fb as well. =)

Not trivial.

> 4. To address 2 and 3, I wanted to try out different display libraries 
> such as ggi, SDL, and DirectFB. Unfortunately even though the coding 
> style is vastly improved over 3.4, the interface between the VM and 
> its display plugins is COMPLETELY UNDOCUMENTED.

The interface is basically the same as it always was: the traditional 
bunch of ioFooBar() functions that deal with the keyboard, mouse and 
screen.  To make pluggable drivers I just put them inside a structure 
and called them indirectly.  (Think of this like a 'display proxy' for 
calling the display driver, in exactly the same way that plugins use an 
'interpreter proxy' to call functions inside the VM.)  The functions 
themselves haven't changed significantly in years; certainly not since 
they were documented in the New Blue Book (modulo events, which I think 
weren't quite ready by the time it went to press), and the names 
haven't changed at all since then.  The only additional thing is that 
each driver exports a function that returns a pointer to its local 
interface structure, through which all display-related calls are 
subsequently made (similar in operation to the 
'getInterpreterProxy()').

You're easiest route would be to copy vm-display-null (which contains 
stubs for all the io functions, plus a working 'contract' to supply an 
interface structure to the VM) and then fill out the implementation of 
each stub according to the display device you're driving.

You can mostly ignore the second half of the display interface 
structure whose functions are related to OpenGL.  Simply failing the 
primitives should work.

Ian