Xref: utzoo unix-pc.general:3531 comp.sys.att:7240
Path: utzoo!utgpu!watmath!uunet!tut.cis.ohio-state.edu!n8emr!uncle!jbm
From: jbm@uncle.UUCP (John B. Milton)
Newsgroups: unix-pc.general,comp.sys.att
Subject: Re: hardware solution for direct access to video ram
Keywords: video ram, Mgr, X, device drivers
Message-ID: <586@uncle.UUCP>
Date: 9 Aug 89 05:16:16 GMT
References: <2575@laidbak.UUCP>
Reply-To: jbm@uncle.UUCP (John B. Milton)
Organization: U.N.C.L.E.
Lines: 22

In article <2575@laidbak.UUCP> botton@laidbak.UUCP (Brian D. Botton) writes:
...
>JOHN: Why didn't you try a software (loadable device driver) approach?
I was refering to an everything in the driver aproach, where access would still
be fast, but your point is well taken. It is wonderful to be able to work on
drivers the way we can on this machine, but it's still a bitch next to regular
user level programs. The idea is begining to grow on me, which does bring up a
bit of a delema as far as how I'm going to implement the screen part of the
X server.

>	8.  I don't know if I should mention this, but I don't see any reason
>	    to hide it.  The displayable portion of the video does not use up
>	    all of the video ram.  So we also have an automatic shared memory
>	    segment at the end of video ram.  BUT, it is wide open and you're
>	    probably a fool to use it and an idiot to rely on it.

I WAS hoping you wouldn't it, but it is 32768-31320=1448 bytes...

John
-- 
John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu
(614) h:294-4823, w:785-1110; N8KSN, AMPR: 44.70.0.52; Don't FLAME, inform!