Path: utzoo!attcan!uunet!ginosko!ctrsol!cica!tut.cis.ohio-state.edu!att!laidbak!botton
From: botton@laidbak.UUCP (Brian D. Botton)
Newsgroups: unix-pc.general
Subject: Re: hardware solution for direct access to video ram
Keywords: video ram, X, daughter board
Message-ID: <2546@laidbak.UUCP>
Date: 29 Jul 89 02:20:30 GMT
References: <2538@laidbak.UUCP> <2434@itivax.iti.org>
Reply-To: botton@laidbak.UUCP (Brian D. Botton)
Distribution: unix-pc.general,comp.sys.att
Organization: Interactive Systems Corporation, Naperville, IL
Lines: 65

In article <2434@itivax.iti.org> scs@itivax.iti.org (Steve Simmons) writes:
>botton@laidbak.UUCP (Brian D. Botton) writes:
>
>>  Hi netlanders.
>
>Hi yourself.  Nice introductory article.
>

Thank you, ;-).

>							 . . . He's talking
>about direct access to the video ram (wouldn't this be easier and safer
>with an appropriate new device driver for fb?

  I'm afraid not, that requires a system call trap which has a fair amount
of overhead.  Just to write one 16 bit word to memory requires setting up
the stack, trapping to the kernel, finally doing the write, return from the
trap, and cleaning up the stack.
  If you want speed, forget about using a device driver.  Most high speed
graphics devices allow you to map the video memory into your process space,
but unfortunately the 3B1 doesn't allow this.  If you look on page 16 of the
cpu schematic, you'll see that A12-A21 go into the page table ram chips, and
MA12-MA21 come out.  Therefore there is no way to modify the page table entry
to address > 0x3fffff.  The really tragic thing here is that there are 3
unused bits in the page table, so A22 and A23 COULD have been added to the
virtual memory space, and given us 16Meg process size, :-).  I think I could
come up with a way to do this in hardware, but there would have to be a major
amount of work done to the software, i.e. kernel, shared libraries, etc.
  On a side note, the page tables are big enough for only ONE process at a
time.  That means a context switch has to swap out the table to run another
process, I can hear my disk thrashing now!.  Sure would have been nice if they
had used a little larger ram chips, even one additional process worth of ram
would have made a big difference.

> 		. . .  But it's clear he's found and removed one bottleneck
>to addressing >4MB!

  Yes, but there are problems with that.  If you aren't careful you could
allow access to ANY area in memory with disasterous results.  That's why I
went to the trouble of decoding the address.  In fact, I originally tried
to include address lines 20 & 21 in the decode logic.  Unfortunately that
generated too many terms for the pal and I was lucky to discover that that
they weren't needed.  In addition, this method does open up the addresses to
ALL processes.  While the paranoid won't like the security problems, there
isn't any way to hurt the system.

>Using a similar scheme is it possible put >4M in the Unix-PC?

  Not unless you go above the 16 Meg mark.  As I mentioned in my original
posting, the video ram has alias addresses at 0x52XXXX, 0x62XXXX, and 0x72XXXX.
If you take a look at the way other addresses are decoded above 0x3fffff, you
will see that most of them are aliased in a similar manner.
  How do you get above the 16 Meg mark? Not with a 68010, but I've had dreams
of a 68020 and 68881 . . . .

>Steve Simmons		          scs@vax3.iti.org

  Thanks for the comments Steve.  I wasn't sure how this would be received,
especially being as long as it was.

-- 
     ...     ___
   _][_n_n___i_i ________		Brian D. Botton
  (____________I I______I		laidbak!botton
  /ooOOOO OOOOoo  oo oooo