From hp@quasi.vmars.tuwien.ac.at  Ukn Jul  1 12:04:07 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA18591; Thu, 1 Jul 93 12:04:04 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23160; Thu, 1 Jul 93 09:02:05 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA25336; Thu, 1 Jul 93 09:01:24 -0700
Received: from quasi.vmars.tuwien.ac.at 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA22997; Thu, 1 Jul 93 09:01:23 -0700
Received: by quasi.vmars.tuwien.ac.at id AA04486
  (5.64+/IDA-1.3.4 for riscy@pyramid.com); Thu, 1 Jul 93 17:56:39 +0200
From: Peter Holzer <hp@quasi.vmars.tuwien.ac.at>
Message-Id: <9307011556.AA04486@quasi.vmars.tuwien.ac.at>
Subject: Re: video (and more)
To: riscy@pyramid.com
Date: Thu, 1 Jul 93 17:56:39 MET DST
In-Reply-To: <9307011527.AA01393@vmars.vmars.tuwien.ac.at>; from "Bill Broadley" at Jul 1, 93 11:29 am
Reply-To: hp@vmars.vmars.tuwien.ac.at
X-Mailer: ELM [version 2.3 PL5]
Status: RO
X-Status: 

You (Bill Broadley) wrote:
> 
> > What do you need the svga controller and accelerator for? I thought we
> > were going for a dumb frame buffer?
> > 
> > 	hp
> If we just put a connector on the board for vesa then we can have
> an upgradable video card while concentrating on the important stuff
> like the cpu, memory, dma etc.

This is another option we should seriously consider. It would also
solve the ISA vs. proprietary I/O bus controversy.

The mails I answered were about choosing the right chips for on board
video, however. Most people here seem to think building an on-board
frame buffer will be easier and/or faster than building a VESA
interface and using a VESA video card (or maybe it is just more
interesting). I don't know much about hardware (and less about VESA),
so I cannot comment on that. Personally I think that the MIPS CPU is
fast enough to saturate the memory bandwidth of the frame buffer, so we
won't gain much performance from an accelerator.

Just to summarize (and see if I missed something):

CPU: Seems to be settled. 3051 and 3081 have same pin layout, so
	everybody can use what he needs and can afford.

Video: Most people prefer on board dumb frame buffer. Some want a VESA
	interface. Accelerator (at least TMS 340x0) seems out.

SCSI: onboard

I/O bus: Heavy controversy between ISA-fans and people who want a
	simple 8-bit bus to build their own hardware for. Personally
	I'd like something which I can hook onto the 16-bit (18 with
	parity) FIFO of our real time computers :-)

Serial: At least one on board for early development.

Everything else: on I/O bus.

-- 
|    _  | Peter J. Holzer                       | Think of it   |
| |_|_) | Technical University Vienna           | as evolution  |
| | |   | Computer Science/Real-Time Systems    | in action!    |
| __/   | hp@vmars.tuwien.ac.at                 |     Tony Rand |

 
From berge@sierra.nl  Ukn Jul  1 12:49:51 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA21210; Thu, 1 Jul 93 12:49:49 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA01924; Thu, 1 Jul 93 09:47:48 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA01773; Thu, 1 Jul 93 09:47:39 -0700
Received: from gatekeeper.sierra.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA01920; Thu, 1 Jul 93 09:47:38 -0700
Received: from quint.sierra.nl by gatekeeper.sierra.nl (4.1/2.00)
    id AA25975; Thu, 1 Jul 93 18:22:28 +0200
Date: Thu, 1 Jul 93 18:22:28 +0200
From: berge@sierra.nl (Wim van den Berge)
Message-Id: <9307011622.AA25975@gatekeeper.sierra.nl>
To: riscy@pyramid.com
Subject: Re: video (and more)
Status: RO
X-Status: 

--- Peter J. Holzer wrote ---

> Personally I think that the MIPS CPU is
> fast enough to saturate the memory bandwidth of the frame buffer, so we
> won't gain much performance from an accelerator.

Personaly I think you're wrong, I think there is plenty to be gained from
a graphics solution which contains a hardware BITBLT and LINE DRAW engine.
If I remember correctly these two functions comprise between 50 and 85 percent
of the overhead in a non accelerated windows environment. That a lot, even for 
the fast MIPS CPU.


        Wim van den Berge
        Sierra Semiconductor B.V.
        Tel    : +31 73 408888                     (:>    \/\/i/\/\
        Fax    : +31 73 423155                    (_)
        E-mail : berge@sierra.nl           =======""======

 
From hahn@neurocog.lrdc.pitt.edu  Ukn Jul  1 16:24:02 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA00998; Thu, 1 Jul 93 16:24:01 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA13609; Thu, 1 Jul 93 13:22:04 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA04483; Thu, 1 Jul 93 13:21:55 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA13601; Thu, 1 Jul 93 13:21:57 -0700
Message-Id: <9307012021.AA13601@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA22374; Thu, 1 Jul 93 15:46:43 -0400
From: Mark Hahn <hahn@neurocog.lrdc.pitt.edu>
Subject: Re: video (and more)
To: riscy@pyramid.com
Date: Thu, 1 Jul 1993 15:46:43 -0500 (EDT)
In-Reply-To: <9307011622.AA25975@gatekeeper.sierra.nl> from "Wim van den Berge" at Jul 1, 93 06:22:28 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 598       
Status: RO
X-Status: 

Wim van den Berge said:
> Personaly I think you're wrong, I think there is plenty to be gained from
> a graphics solution which contains a hardware BITBLT and LINE DRAW engine.
> If I remember correctly these two functions comprise between 50 and 85 percent
> of the overhead in a non accelerated windows environment. That a lot, even 
> for the fast MIPS CPU.

Nope.  Read the papers; the critical path is ALWAYS memory bandwidth,
and the r3k solution will, if anything, have a better memory interface.

regards, Mark Hahn.
-- 
this space intentionally left non-blank.	hahn@neurocog.lrdc.pitt.edu

 
From caret@pyramid.com  Ukn Jul  1 16:29:12 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA01329; Thu, 1 Jul 93 16:29:11 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA14736; Thu, 1 Jul 93 13:27:22 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA05191; Thu, 1 Jul 93 13:27:14 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9307012027.AA05191@sword.eng.pyramid.com>
Subject: Re: video (and more)
To: riscy@pyramid.com
Date: Thu, 1 Jul 93 13:27:13 PDT
In-Reply-To: <9307012021.AA13601@gossip.pyramid.com>; from "Mark Hahn" at Jul 1, 93 3:46 pm
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

> Wim van den Berge said:
> > Personaly I think you're wrong, I think there is plenty to be gained from
> > a graphics solution which contains a hardware BITBLT and LINE DRAW engine.
> > If I remember correctly these two functions comprise between 50 and 85 percent
> > of the overhead in a non accelerated windows environment. That a lot, even 
> > for the fast MIPS CPU.
> 
> Nope.  Read the papers; the critical path is ALWAYS memory bandwidth,
> and the r3k solution will, if anything, have a better memory interface.
> 
> regards, Mark Hahn.

Also, there are algorithms that when combined with an instruction cache
(which our r3k's have) that will bitblt at 100% of the memory bandwidth
once the code is in the I-cache.  That is, we can easily equal the performance
of a hardware blt'er.

-- 
Neil Russell		(The wizard from OZ)
Pyramid Technology			Email:  caret@pyramid.com
3860 N. First Street			Voice:  (408) 428-7302
San Jose, CA 95134-1702			  FAX:  (408) 428-8845

 
From ronald%csunix.urc.kun.nl@kunrc1.urc.kun.nl  Ukn Jul  1 16:46:39 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA02147; Thu, 1 Jul 93 16:46:38 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17002; Thu, 1 Jul 93 13:44:42 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA07552; Thu, 1 Jul 93 13:44:28 -0700
Received: from csunix.urc.kun.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16929; Thu, 1 Jul 93 13:44:28 -0700
Received: by csunix.urc.kun.nl (5.64/1.37)
	id AA00946; Thu, 1 Jul 93 22:42:51 +0200
From: ronald%csunix.urc.kun.nl@kunrc1.urc.kun.nl (Ronald Schalk)
Message-Id: <9307012042.AA00946@csunix.urc.kun.nl>
Subject: Re: video (and more)
To: riscy@pyramid.com
Date: Thu, 1 Jul 1993 22:42:50 +0200 (CET)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1186      
Status: RO
X-Status: 

Neil said:
> > regards, Mark Hahn.
> 
> Also, there are algorithms that when combined with an instruction cache
> (which our r3k's have) that will bitblt at 100% of the memory bandwidth
> once the code is in the I-cache.  That is, we can easily equal the performance
> of a hardware blt'er.
> 
Maybe so, but in the meanwhile the processor cannot do diddly with your
programs and kernel, so IMHO it's better to have a graphics coproc to
cover the video part (that's what it's designed for) and leave the R3K do
the real job: run programs.

Ronald Schalk

 ********************************************************************
 * ing. Ronald Schalk                                               *
 * sectie COOS                                                      *
 * Universitair Centrum Informatievoorziening (UCI)                 *
 * Katholieke Universiteit Nijmegen (KUN)                           *
 * e-mail : R.Schalk@uci.kun.nl   snailmail: Geert Grooteplein 41   *
 * tel.   : +31 80 617993                    6525 GA Nijmegen       *
 * fax   :  +31 80 617979                    Nederland              *
 ********************************************************************
 

 
From caret@pyramid.com  Ukn Jul  1 17:21:03 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA03682; Thu, 1 Jul 93 17:21:01 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21076; Thu, 1 Jul 93 14:19:04 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA14146; Thu, 1 Jul 93 14:18:56 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9307012118.AA14146@sword.eng.pyramid.com>
Subject: Re: video (and more)
To: riscy@pyramid.com
Date: Thu, 1 Jul 93 14:18:55 PDT
In-Reply-To: <9307012042.AA00946@csunix.urc.kun.nl>; from "Ronald Schalk" at Jul 1, 93 10:42 pm
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

> Neil said:
> > > regards, Mark Hahn.
> > 
> > Also, there are algorithms that when combined with an instruction cache
> > (which our r3k's have) that will bitblt at 100% of the memory bandwidth
> > once the code is in the I-cache.  That is, we can easily equal the performance
> > of a hardware blt'er.
> > 
> Maybe so, but in the meanwhile the processor cannot do diddly with your
> programs and kernel, so IMHO it's better to have a graphics coproc to
> cover the video part (that's what it's designed for) and leave the R3K do
> the real job: run programs.

Unless you have a CPU doing the whole job of maintaining the display,
there is always stuff the CPU needs to do.  If you have an accelerator,
then it probably does almost every operation quickly enough to make
it pointly for the main CPU to try and do something else at the same
time.  So you goin little.  The only truely useful accelerator (IMHO)
is another CPU (3041?).


(Note:  I'm still kind of busy making money; I needed a break, and thought
I'd do some babbling...)

-- 
Neil Russell		(The wizard from OZ)
Pyramid Technology			Email:  caret@pyramid.com
3860 N. First Street			Voice:  (408) 428-7302
San Jose, CA 95134-1702			  FAX:  (408) 428-8845

 
From paul@suite.sw.oz.au  Ukn Jul  1 18:19:41 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA06170; Thu, 1 Jul 93 18:19:36 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA29572; Thu, 1 Jul 93 15:17:31 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA25987; Thu, 1 Jul 93 15:17:13 -0700
Received: from munnari.OZ.AU 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA29497; Thu, 1 Jul 93 15:17:08 -0700
Received: from suite.sw.oz.au (via basser.cs.su.oz.au) by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50)
	id AA18003; Fri, 2 Jul 1993 08:15:40 +1000 (from paul@suite.sw.oz.au)
Received: from suite.sw.oz.au by swift.sw.oz.au with SMTP
	id AA11562; Fri, 2 Jul 93 08:14:26 AES (5.59)
	(from paul@suite.sw.oz.au for riscy%pyramid.com@munnari.oz.au)
Received: by suite.sw.oz.au
	id AA27338; Fri, 2 Jul 1993 08:14:11 +1000 (5.65c/1.34)
	(from paul@suite.sw.oz.au for riscy@pyramid.com)
From: paul@suite.sw.oz.au (Paul Antoine)
Message-Id: <199307012214.AA27338@suite.sw.oz.au>
Subject: Re: video (and more)
To: riscy@pyramid.com (R3000 Mailing List)
Date: Fri, 2 Jul 1993 08:14:10 +1000 (EST)
In-Reply-To: <9307012042.AA00946@csunix.urc.kun.nl> from "Ronald Schalk" at Jul 1, 93 10:42:50 pm
Organization: Softway Pty Ltd
X-Face: 
	#INY+G.,0T9NM/sS{;MG$=(^kyV,<kN!j*1>0=\3F</{Npx7Pc=*ez6NC2^8H;!}qiqZn_X
	g'qeG^tfI~y[_DCE'LH""uWAS!/Ib`$)I?,{i_!|ZN~AO$V+Ngl)+7sZ-RF6~8JR+w=K|w6
	De.N"YT*#<5:ZEJUO-#OVu1}_-j4[v4f+>43Lypv1r~Y0u>wgATNe&>HKt`gW%dF|RCmT|
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1245      
Status: RO
X-Status: 


> > Also, there are algorithms that when combined with an instruction cache
> > (which our r3k's have) that will bitblt at 100% of the memory bandwidth
> > once the code is in the I-cache.  That is, we can easily equal the performance
> > of a hardware blt'er.
> > 
> Maybe so, but in the meanwhile the processor cannot do diddly with your
> programs and kernel, so IMHO it's better to have a graphics coproc to
> cover the video part (that's what it's designed for) and leave the R3K do
> the real job: run programs.

That's what a memory-to-memory DMA is for, no?  Of course, there's too
much overhead in setup for small blits with *either* a blitter or a
DMA channel, so they're best done with an algorithm that fits in the
cache.


Paul

------------------------------------------------------------------------------
Paul Antoine, Softway Pty Ltd			           Net: paul@sw.oz.au
PO Box 305, Strawberry Hills, NSW 2012, Australia          Tel: +61 2 698 2322
Level 2, 79 Myrtle St, Chippendale, NSW 2008, Australia    Fax: +61 2 699 9174

"Proper management technique must include checking that all staff have
 play-lunch and that there are no unfair swapsies."
------------------------------------------------------------------------------

 
From wolff@liberator.et.tudelft.nl  Ukn Jul  2 03:35:53 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA25419; Fri, 2 Jul 93 03:35:50 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA19918; Fri, 2 Jul 93 00:33:54 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA10031; Fri, 2 Jul 93 00:33:30 -0700
Received: from liberator.et.tudelft.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA19896; Fri, 2 Jul 93 00:33:29 -0700
Received: by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA07452; Fri, 2 Jul 93 09:32:06 +0200
Date: Fri, 2 Jul 93 09:32:06 +0200
From: wolff@liberator.et.tudelft.nl (Rogier Wolff)
Message-Id: <9307020732.AA07452@liberator.et.tudelft.nl>
To: riscy@pyramid.com, ronald%csunix.urc.kun.nl@kunrc1.urc.kun.nl
Subject: Re: video (and more)
Status: RO
X-Status: 


Everyone is discussing the merits of a graphics coprocessor. 
Some people argue that the R3000 will saturate the memory bandwidth anyway,
so it will be just as fast as a dedicated graphics coprocessor.
Other argue that in the time that the coprocessor is doing things, the 
R3000 would be free to do other things. 

The current tendency is that the graphics moves from dedicated graphics
processors to the main processor. This is because they can sustain the 
same graphics performance as the graphics processors. On the other hand,
if you want 150% performance (that is I estimate the "help" of the graphics
coprocessor at half the power of the main CPU.), why not invest in a 
processor that is 1.5 times faster? In this case the main processor will also 
run your applications 1.5 times faster.

					Roger.

 
From caret@pyramid.com  Ukn Jul  2 03:49:50 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA25653; Fri, 2 Jul 93 03:49:48 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20220; Fri, 2 Jul 93 00:47:56 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA10723; Fri, 2 Jul 93 00:47:48 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9307020747.AA10723@sword.eng.pyramid.com>
Subject: Re: video (and more)
To: riscy@pyramid.com
Date: Fri, 2 Jul 93 0:47:47 PDT
In-Reply-To: <9307020732.AA07452@liberator.et.tudelft.nl>; from "Rogier Wolff" at Jul 2, 93 9:32 am
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

> Everyone is discussing the merits of a graphics coprocessor. 
> Some people argue that the R3000 will saturate the memory bandwidth anyway,
> so it will be just as fast as a dedicated graphics coprocessor.
> Other argue that in the time that the coprocessor is doing things, the 
> R3000 would be free to do other things. 
> 
> The current tendency is that the graphics moves from dedicated graphics
> processors to the main processor. This is because they can sustain the 
> same graphics performance as the graphics processors. On the other hand,
> if you want 150% performance (that is I estimate the "help" of the graphics
> coprocessor at half the power of the main CPU.), why not invest in a 
> processor that is 1.5 times faster? In this case the main processor will also 
> run your applications 1.5 times faster.

Since the r3k's all have caches, they would all be able to run a bitblt
fast enough to saturate the memory bus with only data transactions (
instructions are all in cache remember).  Therefore its not the CPU speed
that determines graphics speed; its the memory.  I expect that everyone
that cares will buy the fastest memory available.  So your point it moot.

-- 
Neil Russell		(The wizard from OZ)
Pyramid Technology			Email:  caret@pyramid.com
3860 N. First Street			Voice:  (408) 428-7302
San Jose, CA 95134-1702			  FAX:  (408) 428-8845

 
From erik@trashcan.hacktic.nl  Ukn Jul  2 16:14:20 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA22977; Fri, 2 Jul 93 16:14:18 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21406; Fri, 2 Jul 93 13:13:34 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA13322; Fri, 2 Jul 93 13:13:16 -0700
Received: from xs4all.hacktic.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21359; Fri, 2 Jul 93 13:13:17 -0700
Received: from utopia.UUCP by xs4all.hacktic.nl with UUCP id AA19812
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Fri, 2 Jul 1993 22:05:03 +0200
Message-Id: <199307022005.AA19812@xs4all.hacktic.nl>
Received: by utopia.hacktic.nl (1.65/waf)
	via UUCP; Fri, 02 Jul 93 20:15:01 GMT
	for riscy@pyramid.com
Received: by trashcan.hacktic.nl (1.65/waf)
	via UUCP; Fri, 02 Jul 93 15:19:50 +0611
	for riscy@pyramid.com
From: erik@trashcan.hacktic.nl (Erik Bos)
To: riscy@pyramid.com
Subject: Re: video (and more)
Date: Fri, 02 Jul 1993 15:05:00 +0611
Status: RO
X-Status: 

>> If we just put a connector on the board for vesa then we can have
>> an upgradable video card while concentrating on the important stuff
>> like the cpu, memory, dma etc.
>
>This is another option we should seriously consider. It would also
>solve the ISA vs. proprietary I/O bus controversy.
I would also suggest a VESA slot on the board, an onboard chipset/framebuffer
might be as fast as the current ET4000, S3, or P9000 videochipsets BUT:
                                                   
1. Does everyone *needs* this accelerated high speed video ?
   
2. Did anybody ever think about 'upgrading' this mainboard ?

By choosing for a VESA slot everyone can decide for himself if he wants
to spend $25 for a cheap VGA-clone or $250 for a highend accelerated board.

--
Erik Bos (erik@trashcan.hacktic.nl)

 
