Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!visdc!jiii
From: jiii@visdc.UUCP (John E Van Deusen III)
Newsgroups: comp.unix.i386
Subject: Re: How to choose a new 386 UNIX PC...
Summary: PC-based X terminals & VGA
Message-ID: <648@visdc.UUCP>
Date: 20 Sep 89 23:00:55 GMT
References: <645@visdc.UUCP> <16097@vail.ICO.ISC.COM>
Reply-To: jiii@visdc.UUCP (John E Van Deusen III)
Organization: VI Software Development, Boise, Idaho
Lines: 77

In article <16097@vail.ICO.ISC.COM> scottw@ico.ISC.COM (Scott Wiesner)
writes:
> From article <645@visdc.UUCP>, I wrote:
>> ... It has been stated several times in this newsgroup that 1024x768
>> interlaced is almost indistinguishable from 800x600 pixel SVGA.  
>
> ... I think many people will agree that even an interlaced 1024x768
> with 256 colors is better than 800x600 with 16 colors.

Judging from the currently-available X terminal products, many people
are willing to forsake ALL color for honest 1024x768 resolution.

>> What I really want to do is put together a 1024x768x16 color
>> noninterlaced X-terminal, based on a PC, that can update the entire
>> screen in less than 2 seconds.  
>
> Could you explain what you mean by "update the screen in less than 2
> seconds"?  If all you've got on your screen is a color background and
> no windows, you can certainly update in less than 2 seconds.  If
> you've got something very complex displayed, not even a SPARC or MIPS
> based machine with a very high performance display would be likely to
> update it in 2 seconds.

The operation is often called BITBLT.  It means that a block of pixels,
residing in memory, is to be transferred to the screen.  It is the
responsibility of the X terminal software to keep track of which areas
of the screen need to be updated, and presumably it can keep track of
several levels of overlapping windows if sufficient memory is available.
In the worst case, an entire screen full of pixels would have to be
transferred.  It is NOT the responsibility of the X terminal software to
convert a complex representation into pixels; that is the function of
the client software.  The client software may indeed be executing on one
or more SPARC or RISC-based computers.

> When you say "based on a PC", do you mean an XT-class PC, or a 386-
> class PC?

By PC I mean that I would like to run the application on an AT bus.
Thus a member of the 80x86 processor family would be used to feed the
VGA adaptor a byte at a time over an 8 MH bus.  This clearly doesn't
require a 33 MH 386.  The problem is with the OS.  If the software is
MSDOS-based then it is hard to access the megabytes of memory needed to
store the "underlying" areas of the screen.  If the X terminal software
is UNIX-based then a 386 is required, if only for ready access to the
latest software.

In the latter case, costs really get out of hand because of all the
licensed software that is required and not really used.  I would like to
suggest that you people at Interactive (or SCO or Bell/Intel) put
together a stand-alone X terminal software package to run on low-end
386s.  You have all the software, including drivers, sitting there; it's
simply a matter of bundling it and putting it on the price list.  The
package could easily sell for $500 a pop; since it would solve the
problem of poor X server performance on 386 machines running UNIX, and
there is nothing like it yet on the market.

>> I think that a SVGA adapter with real 16-bit latch registers should
>> be capable of something in the range of 5 to 10 seconds.
>
> ... I'm not aware of any VGA boards with 16 bit latches, or any plans
> to produce such a board.  There's certainly no existing software that
> could deal with such a board. ...  How do you arrive at your update
> time of 5 to 10 seconds for such a board?

I simply took the two fastest times from Bradley Dyck Kliewer's BITBLT
test (see BYTE, June 1989, "Debunking 16-Bit VGA"), where the blocks
were written as 16-bit words.  The colors in this case were incorrect,
because the latch registers (and others) are only 8 bits wide.  It does
give an indication of the time required, however.

> Scott Wiesner
> Interactive Systems

--
John E Van Deusen III, PO Box 9283, Boise, ID  83707, (208) 343-1865

uunet!visdc!jiii