From drew@nagina.cs.Colorado.EDU  Ukn Jun 29 02:41:18 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA00237; Tue, 29 Jun 93 02:41:17 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15056; Mon, 28 Jun 93 23:38:33 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA26755; Mon, 28 Jun 93 23:38:03 -0700
Received: from nagina.cs.colorado.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15048; Mon, 28 Jun 93 23:37:57 -0700
Received: from localhost by nagina.cs.Colorado.EDU with SMTP id AA02769
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Tue, 29 Jun 1993 00:37:54 -0600
Message-Id: <199306290637.AA02769@nagina.cs.Colorado.EDU>
To: riscy@pyramid.com, paul@suite.sw.oz.au (Paul Antoine)
Subject: Re: My thoughts on the MB design... 
In-Reply-To: Your message of "Tue, 29 Jun 1993 09:35:34 MDT."
             <199306282335.AA03311@suite.sw.oz.au> 
Date: Tue, 29 Jun 1993 00:37:49 -0600
From: Drew Eckhardt <drew@nagina.cs.Colorado.EDU>
Status: RO
X-Status: 





    Hello people,
    
    	My original thoughts included putting single-chip ethernet and
    	SCSI ports on the board, as these would give 32 bit IO in the
    	critical areas, though I worry at being able to get them in
    	something other than PQFP.

IMHO, sticking SCSI / Ethernet on the local CPU bus is overkill
and then some.  We need 1M/sec for the ethernet, 5 or 10M/sec
(With external SCSI cables, I often see problems doing SCSI
faster than 8Mhz) at the most for SCSI.

If we clock a 16 bit bus at 10Mhz, 0 wait states, we have 20M/sec 
split between 5M/sec or 10M/sec SCSI and 1M/sec ethernet,
more than enough. 

Running the SCSI and ethernet and a lower speed lets us use slower,
cheaper chips that come in smaller non-SMT packages.
    
    	The ISA bus could be used for floppy/serial/parallel, as these
    	cards are plentiful and	cheap, whereas a similar amount of 4
    	or 6 layer motherboard space is expensive.

The cost of motherboard space is a valid consideration.  In comparison,
how much space do we loose to the 62 pin and 36 pin card edge connectors
needed for ISA cards?   I've got my 386 case open right now, and they're
about the size of 4 SIMM slots side by side and end to end.

Like one of the other posters sugested, I'd like to reraise
the issue of building a propriety I/O bus, say 16 bits wide 
since that's what your popular, affordable chips are, clocked
at some reasonable speed like 10Mhz (ie, CPU speed / 4).

I'd also like to recommend that we move the low-bandwidth I/O
off the system board (keeping it on a 10Mhz bus of the 3070
or whatever) to these slots, since 

1.  There isn't a real difference between running a trace to
	something on the mainboard and taking a chip select out
	to a connector.

2.  As people have stated, realestate on a 4-6 layer board is 
	expensive.  Since these smaller peripherials aren't
	in massive PGA packages requiring separate ground and
	power planes, and hideous numbers of traces, we can 
	get away with cheap double sided boards.

3.  Many of the people who want a MIPS board have different needs.  
	One user remarked gimme at least for serial ports for terminals.  
	Some may find a dual-homed machine useful while others are netless.  
	Offering the ethernet circuit, extra serial ports, etc. 
	would mean that users could mix and match.

	We'd have more people wanting a mainboard so we have less
	of a chance of missing the lots-of-100 pricing since people
	can get their whizzy MIPS board without coughing up for 
	the ether board they'll never use.

	There would probably be enough  people wanting feature X to do 
	the subboard they're interested in lots of 25 or 100 so they 
	aren't stuck with sample quantity pricing.

Arguable, this does the same things that an ISA bus does.  However,
I suggest that it could easily replace the ISA bus

- ISA needs two big, fat edge connectors on board - a 62 pin and 
	36 pin.  

        We can get away with something that takes far less
	realestate, and circuitry, like a 40 pin (ie IDE) or 
	50 pin connector (say +/- 5,12 V, ground, 16 data, 
	DMA REQ/ACK, read/write, wait state insertion, clk, with the 
	remainder going to address lines.

- Since we put the address decode on the main board, have a 
	reasonabel DMA chip (I assume that the DMA chip handles
	scatter/gather?  Motorola runs DMA through the MMU so
	this is handled automagically, PC's broke it so anything
	with performance needs bus mastering $$$) our "boards"
	will be much less complicated to fabricate, easier to
	program (Look at the SCSI code in the Linux kernel - 
	every driver has different programming to deal
	with their own unique brand of scatter/gathering 
	busmastering DMA) and cheaper than ISA boards carrying this
	burden with them (since we aren't looking to get rich
	off this, and the boards will be simpler).


    VIDEO
    	The ISA expansion bus could readily be made VESA local bus,

Nasty timing problems.  

    	thus giving access to a very broad range of video cards, where
    	the VLB versions give full 32 bit access and acceleration.

All of the cheap video boards I've seen (say this side of $300)
have used DRAM, and you aren't going to write squat to the video
when you're competing with the video serializers (45M/sec 
for 1Kx768 at 60 hz, the "minimum" workstation resolution. Multiply
by an appropriate factor if you're one of those winers who can't 
live with less than 72Hz or 1280x1024 :-) ).

We would use VRAM (Some one suggested MAC VRAM SIMMs), which 
you'll have no problems writing to at speeds approaching 
50M/sec since it is inherently dual ported.

With that sort of bandwidth, and more processing power than 
any S3 board or TIGA, you're going to have *no problems*
getting excellent video performance.

As far as getting the S3 to bitblt, etc, you can do the same
thing if you have a DMA chip on the motherboard (Do the IDT 
chips snoop?)

    	As for the 34010: there is no way that we can compete on
    	performance, price etc. for FAST video hardware with the
    	mass-produced VGA/SVGA cards.

Since we've been told about the 34076 / NS RAMDAC / timing 
generator, I don't think the 34010 is the best route to 
go in terms of either cost or performance.

As far as comparing it to ISA / VESA / PC crap : 
We've timed Tseng ET4000 boards at 6M/sec, it's not too 
hard to compete with that sort of performance :-)  Please 
read the paper on "smart framebuffers". 

As far as price : 

We're all guilty of wild speculation on this. 

So, why doesn't everybody pick their favorite chip (I called the 
NS distributor about the 16552, and will do the same with
the NCR 53c90 series of SCSI chips), call their favorite
distributor, and get pricing in sample quantities and lots 
of 100?

    	I have no great objection to a SIMPLE video interface such as
    	the DMA-driven one Neil mentioned

I agree.  It's an elegant solution, that should give admirable 
performance at the same time.

         though I think most people
    	have VGA/SVGA video cards they could (and would rather) use.

I have a Trident board, and quite frankly it sucks rocks in anything
but monochrome.  I've used TSENG ET4000's, and they don't stack
up to our i960 based Xterminals that use a dumb frame buffer.  I've
used midrange S3 boards, and they don't stack up.  I've  seen
high end S3 boards, but for $500 they damm well better perform!
    
    Expansion
    	As mentioned above, the main way of doing this is through the
    	ISA/VESA bus, as it gives us access to sound cards,
    	floppy/serial/parallel cards and a myriad others.

Which means you're paying for DMA on each board, which means 
you are paying for the relestate it takes for four SIMM slots
for every ISA slot you put in it, etc.
    
    	There's also nothing stopping you putting space for a 'native R3000
    	local bus' connector for those that want to design their own
    	I/O cards of course [or those addicted to speed :-]
 
Local bus makes lots of sense for video, but in a low-mid range 
system you just don't need the bandwidth for I/O, especially
with the added complexity involved in the design.
    

 
From SMACKINLA@cc.curtin.edu.au  Ukn Jun 29 08:40:56 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA11986; Tue, 29 Jun 93 08:40:53 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA08726; Tue, 29 Jun 93 05:37:19 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA05891; Tue, 29 Jun 93 05:37:20 -0700
Received: from cc.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA08722; Tue, 29 Jun 93 05:37:08 -0700
Received: from cc.curtin.edu.au by cc.curtin.edu.au (PMDF #3256 ) id
 <01GZYKX2D608FUMLVJ@cc.curtin.edu.au>; Tue, 29 Jun 1993 20:36:48 +0800
Date: 29 Jun 1993 20:36:48 +0800
From: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Subject: Re: My thoughts on the MB design...
To: drew@nagina.cs.Colorado.EDU
Cc: riscy@pyramid.com
Message-Id: <01GZYKX2D60AFUMLVJ@cc.curtin.edu.au>
X-Envelope-To: riscy@pyramid.com
X-Vms-To: IN%"drew@nagina.cs.Colorado.EDU"
X-Vms-Cc: R3KPC,SMACKINLA
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
Status: RO
X-Status: 


>I'd also like to recommend that we move the low-bandwidth I/O
>off the system board (keeping it on a 10Mhz bus of the 3070
>or whatever) to these slots, since 

[...list of good reasons deleted...]

It seems the most strident opposition to this is actually coming from Neil. 
It looks to me like Steve, Drew and myself are all for the "proprietry" 
slow I/O bus rather than attempting to do an ISA bus. Basically, the only 
device that really _has_ to have high bandwidth is the video system, so 
that _must_ end up on the motherboard. All other devices, including SCSI 
and Ethernet, would do very well on a little custom I/O bus. Sure, we have 
to make cards for it, but I don't think there'll be a huge price difference 
between doing this and buying the equivalent "off the shelf".

>Since we've been told about the 34076 / NS RAMDAC / timing 
>generator, I don't think the 34010 is the best route to 
>go in terms of either cost or performance.

Right. At the moment, Steve's suggestion of the 34076 + NSC thingy is the 
best option, in my mind. This gives us high performance, minimal 
complexity and ease of programming. We _really_ need some prices and details
on the availability of these chips. Steve?

>We're all guilty of wild speculation on this. [pricing]

Yeah. It's pretty hard for me to get any decent pricing information down 
here in Australia. I think this is pretty much going to have to be done by 
you Yanks... <grin>

>    	I have no great objection to a SIMPLE video interface such as
>    	the DMA-driven one Neil mentioned

>I agree.  It's an elegant solution, that should give admirable 
>performance at the same time.

I think there's a bit of misunderstanding here. Essentially, we _either_ 
use the 3730's special DMA stuff for video from DRAM (obviously a bad 
choice for our requirements), or we use VRAM and the 34076. I think we've 
pretty much settled on the second of these, haven't we? If so, then the 
special "video DMA" stuff on the 3730 will be unused.

Here's another attempt at a summary of what I think we're looking at:

* CPU: I think (hope) we've settled this one. We'll decide on the specific 
model of IDT R30xx when the time comes.

* Expansion: There are two opposing camps here. Some people want an ISA bus 
while others (including myself) think a "custom" 16 bit bus clocked at 
something like 10MHz would be better. The advantages of the ISA bus are all 
to do with the availability of boards. The potential advantages of a custom 
bus is that it can be made smaller and simpler, and can be targetted to our 
system more directly. I really think we stand to gain a lot more by using 
our own bus design than by making a "cut-down" version of the ISA bus. 
There are not really that many ISA cards that would be useful, in any case, 
and the ones that are are fairly easy to do ourselves with minimal effort 
(ie: floppy, parallel, more serial ports etc.).

* Video: To me, the best option at the moment is a dumb framebuffer. The 
video image would be stored in VRAM (possibly Mac VRAM SIMMs?). A 34076 
would be responsible for extracting pixel data from the VRAM and pushing it 
through the DAC/palette system to produce analog RGB signals. The NSC chip 
(can't remember the damn number) mentioned by Steve would be responsible 
for producing monitor sync and blanking signals.

* SCSI: I think we're going to be pretty much ok with either the NCR53C94 
or the 53CF94. I'm suggesting that we logically attach it to our "low 
speed" I/O bus, but physically place it on the motherboard. SCSI is not a 
problem as far as bandwidth goes, but I think it's a critical enough 
component that it deserves a place on the motherboard.

* Ethernet: I don't think anyone's come up with a convincing argument as to 
why this needs to be on the motherboard, so I think it should be placed on 
a card also. If there is a good reason for it to go onboard, it should 
still be logically attached to the I/O bus.

* DRAM: At the moment, the best option for DRAM control looks like the 
3730. As for the number of SIMM sockets used, I'd go for 16, mainly to 
reduce board space (and cost).

* Serial: The NS16552 looks like it might be a good choice here. Again, I'd 
suggest that we logically attach it to the I/O bus, but physically place it 
on the motherboard. Doing this will allow us to expand the serial 
capabilities of the machine fairly easily by adding another card with 
perhaps a 4 or 8 port chip, but without increasing board complexity or 
space.

* Keyboard: It still looks like a pre-programmed 8041 is the ticket here. 
I'm starting to think that it's actually not an essential component, 
however, and would do quite well on an expansion card (initial development 
will be over a serial port).

* RTC and NVRAM: No one's suggested anything here yet, but again - although 
they're essential from an OS perspective, they're not fundamental to the 
operation of the hardware. I suggest putting the keyboard controller, RTC 
and NVRAM all on one expansion card.

* Floppy and parallel: I think this would be best left to an expansion 
card. These will not be essential components during the initial development 
phases, and would be much better off being physically placed on a card 
(possibly along with the above mentioned keyboard/RTC/NVRAM).

* Sound and other junk: Again, other "frilly" devices don't really deserve 
a place on the system board. We need to keep the main board down to 
essentials as much as possible.

Here's an ASCII "picture" of my ideas:

    +------+   +-------------+   +------+
    |      |   | CPU + DRAM  |   |      |
    | DRAM +---+ control and +---+ VRAM |
    |      |   | I/O control |   |      |
    +------+   +------+------+   +--+---+
                      |             |
                      |      +------+-------+
                      |      | Video system |
                      |      +------+-------+
(I/O bus)             |             |
    ---+-----------+--+----------+--+--- - - - ---+---
       |           |             |                |
    +--+---+   +---+----+   +----+-----+     +----+----+
    | SCSI |   | Serial |   | Ethernet |     |  Other  |
    +------+   +--------+   +----------+     | devices |
                                             +---------+

BTW: I think all the I/O devices can be easily handled by the CPU, without 
the need for a second CPU (re: Steve's 3041 idea). I much prefer the idea 
of using a dedicated I/O chip like the 3730 over introducing another CPU 
and all the problems that go along with that.

Pat -- "There's only one thing left to do Mama, I got to ding a ding dang
	my dang a long ling long" (Jesus Built My Hotrod -- Ministry)
GCS d* -p+ c++ l++ m--- s+/- !g w- t- r

 
From jcallen@Think.COM  Ukn Jun 29 11:08:00 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA19573; Tue, 29 Jun 93 11:07:59 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA25255; Tue, 29 Jun 93 08:03:25 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA20430; Tue, 29 Jun 93 08:03:26 -0700
Received: from Mail.Think.COM 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA25247; Tue, 29 Jun 93 08:03:18 -0700
Received: from Luna.Think.COM by mail.think.com; Tue, 29 Jun 93 11:02:02 -0400
From: Jerry Callen <jcallen@Think.COM>
Received: by luna.think.com (4.1/Think-1.2)
	id AA13225; Tue, 29 Jun 93 11:02:01 EDT
Date: Tue, 29 Jun 93 11:02:01 EDT
Message-Id: <9306291502.AA13225@luna.think.com>
To: drew@nagina.cs.Colorado.EDU
Cc: riscy@pyramid.com, jcallen@Think.COM
Subject: My thoughts on the MB design... 
Status: RO
X-Status: 

   Date: Tue, 29 Jun 1993 00:37:49 -0600
   From: Drew Eckhardt <drew@nagina.cs.Colorado.EDU>

   If we clock a 16 bit bus at 10Mhz, 0 wait states, we have 20M/sec 
   split between 5M/sec or 10M/sec SCSI and 1M/sec ethernet,
   more than enough. 

No, you DON'T have 20MB/sec, because there's a lot more to a bus
transaction than data transfer. If you can burst, you may get close to that
for brief periods, but doing word-at-time DMA you lose cycles to bus
arbitration/address cycles/other goo.

Sitting down with timing diagrams and working through bandwidth
calculations is a useful, if dull, exercise. It certainly gave me respect
for George's design of the pc532.

-- Jerry Callen
   jcallen@world.std.com           (preferred)
   jcallen@think.com               (OK, too)
   {uunet,harvard}!think!jcallen   (if you must)

 
From paul@suite.sw.oz.au  Ukn Jun 29 00:23:07 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA24003; Tue, 29 Jun 93 00:23:06 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23964; Mon, 28 Jun 93 21:20:15 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA10168; Mon, 28 Jun 93 21:19:22 -0700
Received: from munnari.OZ.AU 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23832; Mon, 28 Jun 93 21:18:30 -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 AA09015; Tue, 29 Jun 1993 14:16:52 +1000 (from paul@suite.sw.oz.au)
Received: from suite.sw.oz.au by swift.sw.oz.au with SMTP
	id AA09741; Tue, 29 Jun 93 09:35:56 AES (5.59)
	(from paul@suite.sw.oz.au for )
Received: by suite.sw.oz.au
	id AA03311; Tue, 29 Jun 1993 09:35:34 +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: <199306282335.AA03311@suite.sw.oz.au>
Subject: My thoughts on the MB design...
To: riscy@pyramid.com (R3000 Mailing List)
Date: Tue, 29 Jun 1993 09:35:34 +1000 (EST)
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: 2842      
Status: RO
X-Status: 

Hello people,

This mailing list is the result of long trans-pacific telephone calls
between Neil and myself.  :-) Now that we've settled on a motherboard
as the basis for the design, and I've had a chance to listen to some
of the discussion, I'd like to outline some of my original design
thoughts...

CPU
	Neil's suggestion of using the R30x1E range is great - we can
	do the prototyping with the cheaper 3051 to prove the design,
	and do some of the initial porting, and then those who need
	the FPU can simply pop in a 3081, as they're pin compatible.

RAM
	Here's where I differ from most: my belief is that 8 or at
	most 16 SIMM sockets is plenty, as 16MB of memory will run
	things nicely, and 32 or 64MB would be enough for most people.

IO
	Neil's suggestion for the RAM/IO/DMA controller (3070??) means
	that implementing most of the IO is trivial (it provides 8 and
	16 bit busses for low-end IO chips).

	My original thoughts included putting single-chip ethernet and
	SCSI ports on the board, as these would give 32 bit IO in the
	critical areas, though I worry at being able to get them in
	something other than PQFP.

	The ISA bus could be used for floppy/serial/parallel, as these
	cards are plentiful and	cheap, whereas a similar amount of 4
	or 6 layer motherboard space is expensive.

VIDEO
	The ISA expansion bus could readily be made VESA local bus,
	thus giving access to a very broad range of video cards, where
	the VLB versions give full 32 bit access and acceleration.

	As for the 34010: there is no way that we can compete on
	performance, price etc. for FAST video hardware with the
	mass-produced VGA/SVGA cards.

	I have no great objection to a SIMPLE video interface such as
	the DMA-driven one Neil mentioned, though I think most people
	have VGA/SVGA video cards they could (and would rather) use.

Keyboard
	This is probably best done with a 8041 microcontroller (or
	some other - what about a PIC?), as it reduces main CPU
	overhead.

Expansion
	As mentioned above, the main way of doing this is through the
	ISA/VESA bus, as it gives us access to sound cards,
	floppy/serial/parallel cards and a myriad others.

	There's also nothing stopping you putting space for a 'native R3000
	local bus' connector for those that want to design their own
	I/O cards of course [or those addicted to speed :-]

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 drew@nagina.cs.Colorado.EDU  Ukn Jun 29 02:41:18 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA00237; Tue, 29 Jun 93 02:41:17 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15056; Mon, 28 Jun 93 23:38:33 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA26755; Mon, 28 Jun 93 23:38:03 -0700
Received: from nagina.cs.colorado.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15048; Mon, 28 Jun 93 23:37:57 -0700
Received: from localhost by nagina.cs.Colorado.EDU with SMTP id AA02769
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Tue, 29 Jun 1993 00:37:54 -0600
Message-Id: <199306290637.AA02769@nagina.cs.Colorado.EDU>
To: riscy@pyramid.com, paul@suite.sw.oz.au (Paul Antoine)
Subject: Re: My thoughts on the MB design... 
In-Reply-To: Your message of "Tue, 29 Jun 1993 09:35:34 MDT."
             <199306282335.AA03311@suite.sw.oz.au> 
Date: Tue, 29 Jun 1993 00:37:49 -0600
From: Drew Eckhardt <drew@nagina.cs.Colorado.EDU>
Status: RO
X-Status: 





    Hello people,
    
    	My original thoughts included putting single-chip ethernet and
    	SCSI ports on the board, as these would give 32 bit IO in the
    	critical areas, though I worry at being able to get them in
    	something other than PQFP.

IMHO, sticking SCSI / Ethernet on the local CPU bus is overkill
and then some.  We need 1M/sec for the ethernet, 5 or 10M/sec
(With external SCSI cables, I often see problems doing SCSI
faster than 8Mhz) at the most for SCSI.

If we clock a 16 bit bus at 10Mhz, 0 wait states, we have 20M/sec 
split between 5M/sec or 10M/sec SCSI and 1M/sec ethernet,
more than enough. 

Running the SCSI and ethernet and a lower speed lets us use slower,
cheaper chips that come in smaller non-SMT packages.
    
    	The ISA bus could be used for floppy/serial/parallel, as these
    	cards are plentiful and	cheap, whereas a similar amount of 4
    	or 6 layer motherboard space is expensive.

The cost of motherboard space is a valid consideration.  In comparison,
how much space do we loose to the 62 pin and 36 pin card edge connectors
needed for ISA cards?   I've got my 386 case open right now, and they're
about the size of 4 SIMM slots side by side and end to end.

Like one of the other posters sugested, I'd like to reraise
the issue of building a propriety I/O bus, say 16 bits wide 
since that's what your popular, affordable chips are, clocked
at some reasonable speed like 10Mhz (ie, CPU speed / 4).

I'd also like to recommend that we move the low-bandwidth I/O
off the system board (keeping it on a 10Mhz bus of the 3070
or whatever) to these slots, since 

1.  There isn't a real difference between running a trace to
	something on the mainboard and taking a chip select out
	to a connector.

2.  As people have stated, realestate on a 4-6 layer board is 
	expensive.  Since these smaller peripherials aren't
	in massive PGA packages requiring separate ground and
	power planes, and hideous numbers of traces, we can 
	get away with cheap double sided boards.

3.  Many of the people who want a MIPS board have different needs.  
	One user remarked gimme at least for serial ports for terminals.  
	Some may find a dual-homed machine useful while others are netless.  
	Offering the ethernet circuit, extra serial ports, etc. 
	would mean that users could mix and match.

	We'd have more people wanting a mainboard so we have less
	of a chance of missing the lots-of-100 pricing since people
	can get their whizzy MIPS board without coughing up for 
	the ether board they'll never use.

	There would probably be enough  people wanting feature X to do 
	the subboard they're interested in lots of 25 or 100 so they 
	aren't stuck with sample quantity pricing.

Arguable, this does the same things that an ISA bus does.  However,
I suggest that it could easily replace the ISA bus

- ISA needs two big, fat edge connectors on board - a 62 pin and 
	36 pin.  

        We can get away with something that takes far less
	realestate, and circuitry, like a 40 pin (ie IDE) or 
	50 pin connector (say +/- 5,12 V, ground, 16 data, 
	DMA REQ/ACK, read/write, wait state insertion, clk, with the 
	remainder going to address lines.

- Since we put the address decode on the main board, have a 
	reasonabel DMA chip (I assume that the DMA chip handles
	scatter/gather?  Motorola runs DMA through the MMU so
	this is handled automagically, PC's broke it so anything
	with performance needs bus mastering $$$) our "boards"
	will be much less complicated to fabricate, easier to
	program (Look at the SCSI code in the Linux kernel - 
	every driver has different programming to deal
	with their own unique brand of scatter/gathering 
	busmastering DMA) and cheaper than ISA boards carrying this
	burden with them (since we aren't looking to get rich
	off this, and the boards will be simpler).


    VIDEO
    	The ISA expansion bus could readily be made VESA local bus,

Nasty timing problems.  

    	thus giving access to a very broad range of video cards, where
    	the VLB versions give full 32 bit access and acceleration.

All of the cheap video boards I've seen (say this side of $300)
have used DRAM, and you aren't going to write squat to the video
when you're competing with the video serializers (45M/sec 
for 1Kx768 at 60 hz, the "minimum" workstation resolution. Multiply
by an appropriate factor if you're one of those winers who can't 
live with less than 72Hz or 1280x1024 :-) ).

We would use VRAM (Some one suggested MAC VRAM SIMMs), which 
you'll have no problems writing to at speeds approaching 
50M/sec since it is inherently dual ported.

With that sort of bandwidth, and more processing power than 
any S3 board or TIGA, you're going to have *no problems*
getting excellent video performance.

As far as getting the S3 to bitblt, etc, you can do the same
thing if you have a DMA chip on the motherboard (Do the IDT 
chips snoop?)

    	As for the 34010: there is no way that we can compete on
    	performance, price etc. for FAST video hardware with the
    	mass-produced VGA/SVGA cards.

Since we've been told about the 34076 / NS RAMDAC / timing 
generator, I don't think the 34010 is the best route to 
go in terms of either cost or performance.

As far as comparing it to ISA / VESA / PC crap : 
We've timed Tseng ET4000 boards at 6M/sec, it's not too 
hard to compete with that sort of performance :-)  Please 
read the paper on "smart framebuffers". 

As far as price : 

We're all guilty of wild speculation on this. 

So, why doesn't everybody pick their favorite chip (I called the 
NS distributor about the 16552, and will do the same with
the NCR 53c90 series of SCSI chips), call their favorite
distributor, and get pricing in sample quantities and lots 
of 100?

    	I have no great objection to a SIMPLE video interface such as
    	the DMA-driven one Neil mentioned

I agree.  It's an elegant solution, that should give admirable 
performance at the same time.

         though I think most people
    	have VGA/SVGA video cards they could (and would rather) use.

I have a Trident board, and quite frankly it sucks rocks in anything
but monochrome.  I've used TSENG ET4000's, and they don't stack
up to our i960 based Xterminals that use a dumb frame buffer.  I've
used midrange S3 boards, and they don't stack up.  I've  seen
high end S3 boards, but for $500 they damm well better perform!
    
    Expansion
    	As mentioned above, the main way of doing this is through the
    	ISA/VESA bus, as it gives us access to sound cards,
    	floppy/serial/parallel cards and a myriad others.

Which means you're paying for DMA on each board, which means 
you are paying for the relestate it takes for four SIMM slots
for every ISA slot you put in it, etc.
    
    	There's also nothing stopping you putting space for a 'native R3000
    	local bus' connector for those that want to design their own
    	I/O cards of course [or those addicted to speed :-]
 
Local bus makes lots of sense for video, but in a low-mid range 
system you just don't need the bandwidth for I/O, especially
with the added complexity involved in the design.
    

 
