Path: utzoo!utgpu!watmath!uunet!shelby!apple!brutus.cs.uiuc.edu!ginosko!rex!ukma!rayssd!icus!limbic!gil
From: gil@limbic.UUCP (Gil Kloepfer Jr.)
Newsgroups: unix-pc.general
Subject: More info about the vidram board
Message-ID: <574@limbic.UUCP>
Date: 26 Oct 89 05:11:20 GMT
Distribution: unix-pc
Organization: ICUS Software Systems, Islip, NY
Lines: 95
Cc: gil

Since my posting a week or so ago, I've gotten many requests for various
information about Brian's vidram board.  I'm flattered to have so many
requests for information about this when I am really only a satisfied
customer :-) .  In any event, in an effort to help answer some of the
questions being asked of me, here are the answers to some to date:

> >From apple!denwa!stb!michael  Tue Oct 24 06:36:58 1989 remote from ames
> Actually, I think I've managed to find all the security holes

Side note-- I'm sure that there's *someone* on the net who can show
you that you've missed a couple... :-)

To keep with the subject at hand...there *IS* a security risk in using
the vidram board-- A user can write a program to scribble all over
your video RAM, causing your screen to be (at worst) unreadable.
However, most UNIX-pcs I've seen have /dev/console unprotected, and
writing to that will have the same effect.  Most UNIX-pcs aren't
open to untrusted users, and thus this point should be moot for the
most part.  (Lenny still threatens to call my system and turn all my
characters upside-down, but that's another story :-)

> Bypass the window driver and talk directly to the screen. I thought
> that was the purpose of wrastop()

no, it isn't.  wrastop() allows direct access to the pixels within a
window.  It is a controlled access to the screen memory through the
window driver.  Unfortunately, the way wrastop() is implemented (as
an ioctl() to the window driver), it is slow and is written fairly
crypticly (is this a word???).

> it, you lose font support that way

See my facedisp program for the UNIX-pc (to display the FaceSaver
files).  This is a perfect example of how text and graphics can live
in the same window at the same time using wrastop() and plain write()
calls.  You don't lose font support at all with this.

> but then you also lose font support with the hardware mod if you
> clobber the screen

ALL screen support is lost with the hardware mod -- that is to say,
in order to implement any kind of window manager with the hardware
mod, it will be your own responsibility to draw characters (fonts),
do graphics, handle window boundaries, perform scrolling, etc.  This
sounds simple on the surface, until you think about the code required
to scroll a part of the screen...  It's a complex memory move.

> Is there some reason why you just can't do this by clipping one line
> on the motherboard? (somewhere is there a VIDMOD* line that indicates
> if the video is being modified?)

No.  This was discussed in the net in detail, but in summary if you
clip this line, you disable all memory protection and can scribble all
over the running kernel if you're not careful.  I, personally, would
like to be protected from that :-)

> From: ames!gatech!mcnc.org!bacchus.uucp!darren (Darren Friedlein)
> Who can I contact for info on how the X port is coming?

As I recall, John Milton and Alex Crain showed an interest at one time
in porting X to the UNIX-pc.  That line of discussion kind of fizzled
out, but I'm hoping someone starts talking about it again.  I, personally,
do not plan on getting involved in the X port simply because I have neither
the time nor the interest, but seeing the port would be neat.

If I plan on doing anything postable with the board, it will be along the
lines of a daemon-based window server (rather than a driver-based one,
as currently implemented) which will perform some functions a little
better that the current window driver (such as icon control), and
will provide compatibility with the current driver so that things like
the voice power voice editor won't break.  Before I get swamped with
comments about it being slower than the window driver, I know.  However,
watch your modem's send/receive data lights when you are doing a uucp
transfer and then see what happens when you "cat" a big file to the
screen.

> From: beau.adp.wisc.edu!davew@cs.utexas.edu (Dave Windorski)
> I didn't get to see previous postings on this and I am wondering how I can
> get this kit?

I believe that there is only a partial-kit available now.  My recommendation
is to write to Brian Botton directly at laidbak!botton or laidbak!bilbo!brian.

Most of the questions I've gotten to date are along these lines.  I hope
that these answers can be of help to someone, and if John or Alex are
out there reading, maybe they can post an update as to what's happening
with the X port, if anything.  I remember there were some real problems
with doing the port, and both of them are too busy to be spending all
their time trying to solve this problem!

Gil.
------
| Gil Kloepfer, Jr.
| ICUS Software Systems/Bowne Management Systems (depending on where I am)
| ...ames!limbic!gil