Return to BSD News archive
Newsgroups: comp.unix.bsd.netbsd.misc
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.hawaii.edu!news.uoregon.edu!news.inc.net!novia!news.dpc.net!news.heurikon.com!daffy!uwvax!uwm.edu!cs.utexas.edu!academ!news.sesqui.net!oitnews.harvard.edu!das-news2.harvard.edu!cantaloupe.srv.cs.cmu.edu!rochester!news.csug.rochester.edu!rit!mrz5149
From: mrz5149@rit.cs.rit.edu (M. R. Zucca)
Subject: Re: NetBSD/mak68k: problems with serial overruns, X console
Message-ID: <mrz5149-1604960958180001@129.21.30.1>
Sender: news@cs.rit.edu (USENET News Admin)
Nntp-Posting-Host: ppp18
Organization: Rochester Institute Of Technology
X-Newsreader: Yet Another NewsWatcher 2.2.0b6
References: <4kk201$4gg@spool.cs.wisc.edu> <russ-1304961000570001@seismo.demon.co.uk> <3174140F.75BE@zuc.org>
Date: Tue, 16 Apr 1996 13:58:18 GMT
Lines: 62
In article <3174140F.75BE@zuc.org>, zuc@zuc.org wrote:
> now... a few questions of my own...
> I can boot BSD on my IIsi in color with no problems, but
> when I try to start X, it won't work. I'm wondering if
> maybe I would boot in color and then compile my own
> X11, would that work? would I get color? I really do not
> like monchrome X... fvwm is working fine, but it looks
> horrible in monochrome. Any NetBSD Gods, please
> help.
I'm afraid it's a little bit more complex a problem than that.
I am even considering doing such a port and have looked into the problem
but there are a few wrenches in the works:
1. I need drive space and right now the only place to get that is my EZ Drive
which won't work until Allen Briggs figures out why EZ Drives make the
Kernal puke and die.
2. While X's interface seems to be simple enough to work with I would really
enjoy finding the MacBSD hardware interface for black and white.
If anybody knows where these are please let me know!!!
The above 2 might be solved some-time soon but #3 is a real stick in the mud
3. To get color X support in 8 bits, you have to be able to manipulate the
color-card's CLUT. Right now, the screen parts of the kernal only seem
to give the base address of screen memory. Getting the base of the CLUT
from the BSD side is tricky and might even involve using the MRG to run
a driver call from the card's SResources (which may or may not be there!)
The other alternative is to pass the address when you boot. This is easy
with one monitor, just shove the address into a register like all the
other parameters, but with multiple monitors you have to store a list of
them someplace that won't get hosed between the MacOS shutting down and
the kernal loading.
Once you've got the CLUT, hopefully it's just a matter of maniuplating the
256 color registers.
The other alternative to this is to do like the Amigas are doing and do up a
16 bit X server. This has the advantage of not needing a CLUT. 16bit mode
("thousands" mode) is a direc mode so you just dump the stuff on the screen.
Alas, most of the target Macs for BSD don't do 16 bit color on their own
not to mention that moving that much data around is going to be mighty slow
for the kinds of machines that MacBSD runs on.
It seems like there should be a descently fast way of doing it since MacOS does
it but that's not always a 1:1 comparison since there's generally more going
on when UNIX is running.
Our best bet would be to try and get the base address of that damned CLUT
somehow!
Ask Allen Briggs. Doing this might be on his to-do list.
>>> ACK! I WISH I HAD MORE HD SPACE!!!!
--
______________________________________________________________________________
Michael Zucca <> mrz5149@rit.cs.rit.edu <> Rochester Institute Of Technology
"If the speed of light is not infinite, then it's awful damned fast."
- Galileo -