Re: VSTa update

On Thu, 9 Mar 2000, Andy Valencia wrote:

> Hello,
>
> Just a little update on stuff I'm doing on VSTa. FAT32 is looking good;
> I'm on hold for GNU GRUB to release a version with some critical fixes for
> *their* FAT32 support, after which I can test a fully native system and
> check in my work.
>
sounds nice, keep up the good work :)

 
> I'm still thinking about a port of Squeak to VSTa. In preparation for that,
> I've done an implementation of select(), and have that working as of
> yesterday evening. It looks like a server which supports select() will need
> to add around 50 lines of code, plus I had to implement a "selfs" server to
> manage all the common state. The good news is that the underlying message
> model required no changes, so select() required no kernel modifications, and
> will work over distributed messaging just fine. Viva microkernels!
>
personally I would prefer a port of Berlin to VSTa instead, as it seems to
be a very promising windowing system that is language independent and
extensible. (http://www.berlin-consortium.org) It is at the moment in a
very early state and a lot of other stuff would need to be ported first,
(Mesa, libGGI, OmniORB). That's just my opinion but check it out anyway, I
think it seems to have a lot better architecture than Squeak.

> I'm still looking for a good graphics library to control video hardware.
> When I port Squeak, it's easy enough to support one of the base SVGA modes
> (I'll just copy the code from my MGR port). But it'd be nice to support the
> extended resolution (and hardware blit support) of modern video cards. I
> was told a while ago that libsvga was dead, but I seem to see a lot of
> activity with respect to it on the Linux lists. It's the closes thing,
> philosophically, to what I'd like to use. Can anybody with a deeper
> understanding give me some guidance?
>
wouldn't it be nice to code graphics servers that provide a bitblt file
like in plan 9? I could try to code a vga one if you others think it's a
good idea. But should the protocol then be the same as in plan 9? I think
that it would be better to put the font support in some sort of library.
And the plan 9 bitblt protocol doesn't seem to be able to adjust to
multihead systems very well, if one is designed now it's best to include
support for that from ground up. The best way to accomplish that would
probaly be to have some sort of display manager server that takes control
of all the bitblt files and then gives one out to the applications.
I'm from the Amiga community and I think that it should include an amiga
style screen switcher instead of unix style one. for you that doesn't know
how it works on amiga. The virtual screens are put in a list and
applications can open new ones and close their screens and there is always
the "default screen", instead of the unix way where it is a fixed number
and can neither be increased or decreased by applications. but that might
be something for the window system to take care of, but I think it would
be nice to have it on the virtual consoles so that you just start with one
console and then if you want new ones you type "newcons" or something like
that and then when they exit they close their screens. And also the amiga
switches between the screen by shifting to the next one in the list with
one key combination and switching to the first one with one key
combination. And all screens can have different resolutions.

> Thanks,
> Andy Valencia
>

/Erik
Received on Fri Mar 10 00:49:56 2000