Very Computer

Howdy,
  I've got X and pppd running on my IIvx running generic MacBSD 1.1, but
I'm having a few minor difficulties:

1) I keep getting serial overruns, even with a minimal processor load.
   Lowering the port speed from 38400 to 19200 didn't seem to help any.
   I'll try 9600, but I'm wondering if there's something else I should
   be doing.  After all, the same machine running MacOS can handle speeds
   of 38400 and higher without any trouble.  Is there a process I can
   renice to a higher priority, maybe?  (note: The modem-to-modem speed
   is only 9600, not counting the v.42bis compression.)

2) Console messages mess up the X screen.  No biggie since an 'xrefresh'
   cleans everything up, but I'm getting so many serial overruns (which
   generate console messages) that I'm having to do this often enough
   that it's annoying.  (It also happens when I 'su root'.)  If I run
   'xconsole' I see the messages there, but it still messes up the sceen.

3) 'xconsole' and 'xload' (from the puma ftp site) don't work unless I'm
   root.  If I'm not root xconsole says "Couldn't open console", and
   xload says "cannot get access to kernel address space getValue".
   Ok, it makes sense, but I don't know what to do to get around it.
   (I don't know anything about setuid executables, but is this maybe
   why they exist?)

thanks,
brian

PS.  I asked before if the macbsd mailing list is archived anywhere (or if
     there is any way to read the goings on there without cluttering my
     mailbox) but noone has answered me.  Should I take that as a "no"?
--
~~~~~~~~~~~~~~~~~  _______    _____  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Brian A. Cole    |_   _  |  |  ___|    Visit Brian's Repository of
 U. Wisconsin       | | | |__| |___      Macintosh Information at

I'm still a newcomer to MacBSD myself, but as I run a IIvi (with FPU), my
machine is identical with yours except for even slower clock speed, and
I don't get this problem except at 57600, it seems unlikely that this is
some inherent problem.  Which version of the kernel are you using?  I think
I'm still using GENERIC52; perhaps yours is older (e.g. straight out of the
1.1 distribution).  There are more up-to-date kernels (ADBTEST family)
which avoid the ROM glue problems, and are reported to give better
performance.  

Quote:> 2) Console messages mess up the X screen.  No biggie since an 'xrefresh'
>    cleans everything up, but I'm getting so many serial overruns (which
>    generate console messages) that I'm having to do this often enough
>    that it's annoying.  (It also happens when I 'su root'.)  If I run
>    'xconsole' I see the messages there, but it still messes up the sceen.

You can turn console logging off in /etc/syslogd.conf (or is it syslog.conf?)
Not exactly recommended, but as a quick fix ... just don't forget to turn
it back on when the problem's solved.

Quote:> 3) 'xconsole' and 'xload' (from the puma ftp site) don't work unless I'm
>    root.  If I'm not root xconsole says "Couldn't open console", and
>    xload says "cannot get access to kernel address space getValue".
>    Ok, it makes sense, but I don't know what to do to get around it.
>    (I don't know anything about setuid executables, but is this maybe
>    why they exist?)

That sounds like a sensible solution.  Do 'man chmod' for details.

Quote:> PS.  I asked before if the macbsd mailing list is archived anywhere (or if
>      there is any way to read the goings on there without cluttering my
>      mailbox) but noone has answered me.  Should I take that as a "no"?

They definitely are archived, and very neatly, too.  I scan the mail
messages but throw them away, and occasionally download updates to the
archive.  IIRC, it's beneath the NetBSD www site.

All remarks subject to my opening proviso!

Russ

ok, I have solved all of those problems....
the serial port overrun thing is fixed in GENERIC52, I
haven't seen a single error since I updated.

when you start x, type the following line:

startx & ; exit

this will log you out of the shell to prevent the annoying
screen problem when your login shell gets talked. The
console messages can be captured by a Console Xterm...
to get one of those su to root in your default Xterm and
type, "xterm -C" <capital C> this will intercept all the
console messages and log them in the window. then use
that console xterm to login to your own system with your
account so when you are talked, it comes up in that
window also. Now all your screen problems are solved. I
hope this helps.

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.
Thank you!
-androo

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.

Quote:>>> ACK! I WISH I HAD MORE HD SPACE!!!!

--
______________________________________________________________________________

     "If the speed of light is not infinite, then it's awful damned fast."
                                  - Galileo -

Currently, Xmacbsd does NOT run in color.  See:
http://puma.bevd.blacksburg.va.us/macbsd/macbsd-docs/index.html

] Our best bet would be to try and get the base address of that damned CLUT
] somehow!

No, the best way is to download the video driver off the ROM and
access the hardware through it.  It's actually been done recently.
There's an on-going effort to write a color X server which takes
advantage of the new grf driver, too.  It won't be much longer until
there's color X support.  Be patient, please.

] Ask Allen Briggs. Doing this might be on his to-do list.

No, I'm almost sure it's not on his list.  At least not near the top
of it.  Besides, swamping his (or anyone else's) mailbox doesn't get
things done any faster.

ken
--
Ken Nakata  . . . . Cook College, Rutgers - The State University of New Jersey
http://remus.rutgers.edu/~kenn/, ftp://remus.rutgers.edu/pub/NetBSD/index.html
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
"He who refuses to do arithmetic is doomed to talk nonsense." -- John McCarthy

It's the first I've heard of it. It's so hard to get news on this stuff!
First off, it would be nice if there was a pointer to the XMacBSD hardware
source for the X Server. It should be with the rest of the X Stuff at the
XFree86 site that is pointed to from ftp.netbsd.org.

I checked into using the ROMs. While it's a nice idea, what do you do about
something like IIvx video? If you look closely, the Apple_Video_Brazil
driver is loaded by the system and is not contained in the ROMs. In addtion,
the IIvx's slot information for the video is not reliable even if it was
independant (consider the IIvx video base address hack). In the case of the
IIvx and possibly IIci internal video, you need the CLUT's base address.

Quote:> No, I'm almost sure it's not on his list.  At least not near the top
> of it.  Besides, swamping his (or anyone else's) mailbox doesn't get
> things done any faster.

Sorry, I had not intention for people to flood Allen Brigg's mailbox.
A little query can't hurt, especially considering the size of the MacBSD
community.

BTW, since you seem to know alot about what's new could you fill those of us
in who would like to know or give us a pointer to something with *fresh*
information.

--
______________________________________________________________________________

     "If the speed of light is not infinite, then it's awful damned fast."
                                  - Galileo -

] > No, the best way is to download the video driver off the ROM and
] > access the hardware through it.  It's actually been done recently.
] > There's an on-going effort to write a color X server which takes
] > advantage of the new grf driver, too.

] It's the first I've heard of it. It's so hard to get news on this stuff!

I'm not surprised since I don't remember seeing you on the port-mac68k
mailing list ;-)

] First off, it would be nice if there was a pointer to the XMacBSD hardware
] source for the X Server.

Uh... yeah, I'll make it available for the general public once I
finished the color server.

] It should be with the rest of the X Stuff at the
] XFree86 site that is pointed to from ftp.netbsd.org.

I'm not so sure about this.  Our port has nothing (besides XFree86
team's fixes to the main xc source tree) to do with XFree86.  XFree86
is for i386 Unices, you know?

] I checked into using the ROMs. While it's a nice idea, what do you do about
] something like IIvx video? If you look closely, the Apple_Video_Brazil
] driver is loaded by the system and is not contained in the ROMs. In addtion,
] the IIvx's slot information for the video is not reliable even if it was
] independant (consider the IIvx video base address hack). In the case of the
] IIvx and possibly IIci internal video, you need the CLUT's base address.

Hmm, the internal video's color support has to be done separately from
the NuBus (or PDS) video's color support, then.  I haven't really
thought of it.  Is there an elegant way to accommodate all the
internal video models? (IIci, IIsi, IIvx, etc.)

] BTW, since you seem to know alot about what's new could you fill those of us
] in who would like to know or give us a pointer to something with *fresh*
] information.

You should subscribe to the port-mac68k list since it's the place
where people exchange their ideas about improving NetBSD/mac68k (see
Chris Demetriou's periodical posting "NetBSD mailing lists FAQ" on
comp.unix.bsd.netbsd.announce) and information about how to use it.

ken
--
Ken Nakata  . . . . Cook College, Rutgers - The State University of New Jersey
http://remus.rutgers.edu/~kenn/, ftp://remus.rutgers.edu/pub/NetBSD/index.html
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
"He who refuses to do arithmetic is doomed to talk nonsense." -- John McCarthy

That sounds a little odd. Isn't it *Net*BSD? Wouldn't you like to have help
with the project? Why would you want to keep code like that tucked away
when other people could be working on improvements too?

Quote:> I'm not so sure about this.  Our port has nothing (besides XFree86
> team's fixes to the main xc source tree) to do with XFree86.  XFree86
> is for i386 Unices, you know?

In my quest for source code I check ftp.netbsd.org and their code points
at the XFree86 site's source which also includes hw source for quite a few
platforms including such strangeties as A/UX but, alas, there was no MacBSD
source.

Quote:> Hmm, the internal video's color support has to be done separately from
> the NuBus (or PDS) video's color support, then.  I haven't really
> thought of it.  Is there an elegant way to accommodate all the
> internal video models? (IIci, IIsi, IIvx, etc.)

If you're just looking to do something like change the CLUT, then the easiest
way is just to pass the base address at startup. If you've got NuBus stuff
working separately then there can only be one Slot 0 internal video to worry
about. If you want to talk about changing modes...that's a whole other story.

I'll have a look at what the Apple_Video_Brazil driver does on my IIvx.
It may or may not be similar to the code for the IIci/IIsi.

Quote:> You should subscribe to the port-mac68k list since it's the place
> where people exchange their ideas about improving NetBSD/mac68k (see
> Chris Demetriou's periodical posting "NetBSD mailing lists FAQ" on
> comp.unix.bsd.netbsd.announce) and information about how to use it.

Thanks, I'll check it out.

--
______________________________________________________________________________

     "If the speed of light is not infinite, then it's awful damned fast."
                                  - Galileo -