> I am interested in
>getting a color version of X11R6 running on *internal* video. If that seems
>a bit far off into the future, I really would like a version of dt (virtual
>console) that works with display cards set to 8-bit or 16-bit color on the
>MacOS, then booted into NetBSD.  I am interested in using some kinda of
>ANSI graphics with this machine (i.e. circ, or maybe even telnet, if that
>supports color-ansi color telnet would be awesome).
>I have heard that X11R6 works in color on some nubus video, but i really
>would like to get it running on internal video...

Ok, just to let you know, I've been working on internal video support for a
while. I own a IIvx and almost have a working kernel but there are still some
bugs involving interrupts and what-not that have to be fixed before I can
release the kernel and source. 

I'm a busy grad student so I haven't had too much time to work on it in the
last couple of months or so. However, the good news is that in about two
weeks I'm getting a week break during which I plan on polishing the code
and releasing a new intvid test kernel for the IIvx that will allow you to
run color X.

As far as ANSI/color consoles go I'm working on adding 16 bit mode to the
console code as well. I'm not adding ANSI codes to the console mostly because
it's simply not worth it. The blitter code and the overall console code isn't
all that advanced. It would be a much better idea to add color/ANSI support
to DT since DT has all the niceties you would expect out of a linux console.
The built-in console code only needs to be good enough for single user mode
and going into X or DT. There's no need to put all that complex code in
the kernel. Besides, since DT's a user process the debug turn around is
much faster. You don't have to reboot if you screw something up. :)

I really wanted to make a very much enhanced color DT port but I just have
to face the fact that graduate school is taking up all my time now.

** Other interested users:
I've recently looked at a code snippet someone passed on to me and I think
it gives me a hot lead on the Civic video chip in the Quadra AV's.

Here's how I hope to make kernel releases:
Early May - The IIvx kernel
Probably pretty dirty. No bounds checking. Stuff like that. You'll be able to
run color X. I might also make a setterm type program so you can set the
console background/foreground colors.

Later Releases - IIsi/IIci, LC's, IIvx, possibly Quadra AV's
I have enough information to make drivers for all of the above machines.
As far as other machines: Right now I have next to no information about
the DAFB controller found in most of the other machines and I have no
information about the chips found in the PowerBooks.

Even Later - "Modular" Kernel video drivers
Since grf_iv has to run many different kinds of video I'd like to pull all
the really hardware specific stuff out into separate C files. At this point
the code should be of good enough quality for the source tree. This will be
good since I can have all the hardware code I know in pre-made modules and
anybody else can just run a black and white standard module until some
kind soul figures out the video hardware for a group of machines.

_______________________________________________________________________
 Michael Zucca - mrz5149@rit.cs.rit.edu - http://www.rit.edu/~mrz5149/
 "I will choose a path that's clear. I will choose Freewill. "
  --Rush, Freewill
_______________________________________________________________________