From mackinla@cs.curtin.edu.au Tue Jun 22 17:35:52 1993
Return-Path: <mackinla@cs.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA03640; Tue, 22 Jun 93 17:35:47 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23874; Tue, 22 Jun 93 08:37:19 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA01794; Tue, 22 Jun 93 08:34:22 -0700
Received: from marsh.cs.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23860; Tue, 22 Jun 93 08:37:09 -0700
Received: from vincent.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA11020
  (5.67a/IDA-1.4.4 for <riscy@pyramid.com>); Tue, 22 Jun 1993 23:32:50 +0800
Received: by vincent.cs.curtin.edu.au id AA14659
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Tue, 22 Jun 1993 23:32:45 +0800
From: Patrick Mackinlay <mackinla@cs.curtin.edu.au>
Message-Id: <199306221532.AA14659@vincent.cs.curtin.edu.au>
Subject: Re: MIPS R3000 tasks available; volunteers?
To: riscy@pyramid.com
Date: Tue, 22 Jun 1993 23:32:44 +0800 (WST)
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 3631      
Status: RO
X-Status: 


[...Sorry to those who might have seen this twice. I didn't see it
come back to my site, so I'm mailing it again...]

>Most correspondence should be directed at the mailing list:
>
>	riscy@pyramid.com

May I suggest getting your mailing list software to include a "Reply-to:"
field? Makes following up a little easier.

>*  CPU, peripheral controller and memory
>		Allocated to: caret@pyramid.com
>	of what memory controller is available.  At this stage I am aiming
>	at using the IDT 79R3730.  To this end I am calling IDT to attempt

Just a comment here: having been in the same boat before waiting for IDT
to produce the R372x series of chips, I'd have to say that this chip is
going to be the most critical one in the whole design. Hopefully they
will produce this and make it available as planned...

>*  Keyboard controller / NV-RAM / RTC

I might just try and take this up. You mentioned the 8051 in your
previous mail, but I have a little further info. The original PC and XT
used the 8051, but all machines since have used the 8041. I know that
AMI (the BIOS people) make them pre-programmed with their PC BIOS (ie:
it's an EPROM as well), and think that this would make a nifty device
if we could get hold of it. It would obviously require re-burning the
EPROM, but I think it might be a good way to cut down on a couple of
chips. As for the NV-RAM and RTC, everything I've ever heard points to
Dallas Semi. Unfortunately, I've also heard that they advertise lots of
stuff that they never actually make. I'll look into both of these, and
see what I can come up with.

>*  SCSI bus
>		Allocated to: <no-one>
>	The SCSI bus would probably be done with something like a
>	NEC 53C94 SCSI controller.  Research needs to be done on this
>	and other available SCSI chips.  

Ok, I'm probably one of the people who pushed for this. The other SCSI
chips I've had a look at include: NCR53C7xx series (SMT and _big_),
NCR538x series (pretty dumb) and the WD33C98(?) (very buggy). One
advantage of the '94 is that it's second sourced by Emulex, NCR and
Motorola, so it should be pretty easy to get hold of. You should also
note that there's a 53CF94 which is the same device but does FAST SCSI.
Again, there are '96 chips which do wide SCSI (I think). I've been
unable to get any hard data down here though...

>*  Serial port

Might I suggest a Zilog SCC? I've had good experiences with these,
and they give you the ability to use AppleTalk (physically, anyhow)
at some stage. IMHO, we should have one SCC (or something) chip on
the motherboard itself, and use an ISA card for more "regular"
serial chips. Comments?

>*  Ethernet port
>		Allocated to: <no-one>
>	It has been suggested that we use an Am7990 (Lance) Ethernet

I probably suggested this too, but again - I don't know much about
it. I think there's an alternative in the NSC 8390(?) used on a lot
of PC ethernet cards. As I said, I'm not qualified to give an
opinion here.

>*  Video

Ok, I've accepted this idea <grin>. Anyone know if the 6845 is up
to it? What sort of a range does it have on sync signals?

>*  Diagnostics / monitor code

I'd be very interested in doing this. Obviously (I think), we'd want
some sort of an assembler for this step. See below.

>*  Cross assembler/compiler system

I've looked at this before and I think it's relatively trivial. Getting
GAS to produce R3k binaries is going to be the most important first
step, as we'll need that for the boot/debug ROM.

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 pat@ucc.gu.uwa.edu.au Mon Jun 28 10:09:15 1993
Return-Path: <pat@ucc.gu.uwa.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA24756; Mon, 28 Jun 93 10:09:10 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18874; Mon, 28 Jun 93 01:09:04 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA20651; Mon, 28 Jun 93 01:08:45 -0700
Received: from mackerel.gu.uwa.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18691; Mon, 28 Jun 93 01:08:33 -0700
Received: by ucc.gu.uwa.edu.au id AA03883
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Mon, 28 Jun 1993 16:00:59 +0800
From: Pat Mackinlay <pat@ucc.gu.uwa.edu.au>
Message-Id: <199306280800.AA03883@ucc.gu.uwa.edu.au>
Subject: SIMM sockets...
To: riscy@pyramid.com
Date: Mon, 28 Jun 1993 16:00:55 +0800 (WST)
X-Mailer: ELM [version 2.4 PL11]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 739       
Status: RO
X-Status: 


Neil, are you still planning on using 32 SIMM sockets? I've been looking,
and I just can't see how you plan to fit that many on the board if you
plan to do an ISA bus as well. 32 sounds a little excessive in any case.
I think we might do better to think about 8, possibly 16. More than 4
sockets is going to mean external memory drivers anyhow, so there's no
real difference between 8 and 16 apart from board space. Perhaps we can
allow 16M SIMMS to be used? With 8 x 16M SIMMS, we get the same 128M
maximum, perfectly reasonable from my point of view <grin>.

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 tor@tss.no Mon Jun 28 12:32:06 1993
Return-Path: <tor@tss.no>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25077; Mon, 28 Jun 93 12:31:58 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09849; Mon, 28 Jun 93 03:31:51 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA09116; Mon, 28 Jun 93 03:31:44 -0700
Received: from benoni.Uit.No 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09841; Mon, 28 Jun 93 03:31:42 -0700
Received: from benoni by ppenoni.uit.no with SMTP (PP) 
          id <20400-0@ppenoni.uit.no>; Mon, 28 Jun 1993 12:31:38 +0000
Received: from unas.tss.no 
          by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) 
          id AAbenoni20396; Mon, 28 Jun 1993 12:31:36 +0200
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA00338;
          Mon, 28 Jun 93 12:26:03 +0200
Message-Id: <9306281026.AA00338@unas.tss.no>
From: tor@tss.no (Tor Arntsen)
Date: Mon, 28 Jun 1993 12:26:01 +0200
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: riscy@pyramid.com
Subject: Re: Things ...
Status: RO
X-Status: 

>> Rather more personal preference than anything else: Don't you just _love_ 
>> the idea of the X server running on its own CPU? It'd be the equivalent of 
>> having your own X terminal on board <grin>. No, it probably won't compete 
>> for speed with a well-designed framebuffer, but I think it's a very elegant 
>> solution.

Can't say I love it actually.. The Tandberg TDV 6230 runs an X-server
on the 34010 in 1024x768x1 (or x4), and it's slower than a 486+et4000 for
almost anything.  The only thing that is slower on the PC is scrolling.
The TDV 6230 is certainly much slower than a 486 + S3.
Of course, the X-response on the PC gets real bad when compiling the
kernel at the same time! :-)

>The 34010 will be around half the speed at doing bitblt's than the r3k;
>the 34k can probably do other things faster (lines, circles) but they
>don't matter.  As Pat says though, the 34k will take the load off the
>r3k.

Tor



 
From tor@tss.no Mon Jun 28 13:33:11 1993
Return-Path: <tor@tss.no>
Received: from liberator.et.tudelft.nl by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25195; Mon, 28 Jun 93 13:33:08 +0200
Received: from benoni.Uit.No by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA05089; Mon, 28 Jun 93 13:33:03 +0200
Received: from benoni by ppenoni.uit.no with SMTP (PP) 
          id <20798-0@ppenoni.uit.no>; Mon, 28 Jun 1993 13:32:53 +0000
Received: from unas.tss.no 
          by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) 
          id AAbenoni20794; Mon, 28 Jun 1993 13:32:51 +0200
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA01034;
          Mon, 28 Jun 93 13:27:18 +0200
Message-Id: <9306281127.AA01034@unas.tss.no>
From: tor@tss.no (Tor Arntsen)
Date: Mon, 28 Jun 1993 13:27:16 +0200
In-Reply-To: wolff@liberator.et.tudelft.nl (Rogier Wolff) "Re: Video subsystem..." (Jun 28, 1:24pm)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: wolff@dutecai.et.tudelft.nl (Rogier Wolff)
Subject: Re: Video subsystem...
Status: RO
X-Status: 

On Jun 28,  1:24pm, Rogier Wolff wrote:
>>  HP X-terms (pa-based I think) are much much
>faster.
>
>Nope. They use Intel 960 processors.....
>
>					Rogier.

Yeah, I've got a couple of mails already correcting me on that point.
I've also got some good advice on how to fix those really *bad* looking
cheap displays..

Thanks,
Tor	(tor@tss.no)



 
From caret@pyramid.com Tue Jun 22 05:49:16 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA00241; Tue, 22 Jun 93 05:49:13 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18736; Mon, 21 Jun 93 20:52:02 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15731; Mon, 21 Jun 93 20:49:02 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306220349.AA15731@sword.eng.pyramid.com>
Subject: MIPS R3000 mailing list
To: riscy@pyramid.com
Date: Mon, 21 Jun 93 20:49:02 PDT
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

Welcome to the MIPS R3000 board project mailing list.

This mailing list has been formed for the discussion of the design of
the MIPS R3000 board that has been under recent discussion in
comp.os.linux.  You have been added automatically to this list because
you expressed some interest in helping design this device.

Requests to be added or deleted from this list should be directed to
'riscy-request@pyramid.com'.  Mail sent to 'riscy@pyramid.com' will
be forwarded to all other members of the list.

I intended this list to hardware issues and software issues relating
directly to the board.  Discussion about the porting of various
operating systems should be directed to another as yet undefined
mailing list.

-- 
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 mackinla@cs.curtin.edu.au Tue Jun 22 17:35:52 1993
Return-Path: <mackinla@cs.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA03640; Tue, 22 Jun 93 17:35:47 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23874; Tue, 22 Jun 93 08:37:19 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA01794; Tue, 22 Jun 93 08:34:22 -0700
Received: from marsh.cs.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23860; Tue, 22 Jun 93 08:37:09 -0700
Received: from vincent.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA11020
  (5.67a/IDA-1.4.4 for <riscy@pyramid.com>); Tue, 22 Jun 1993 23:32:50 +0800
Received: by vincent.cs.curtin.edu.au id AA14659
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Tue, 22 Jun 1993 23:32:45 +0800
From: Patrick Mackinlay <mackinla@cs.curtin.edu.au>
Message-Id: <199306221532.AA14659@vincent.cs.curtin.edu.au>
Subject: Re: MIPS R3000 tasks available; volunteers?
To: riscy@pyramid.com
Date: Tue, 22 Jun 1993 23:32:44 +0800 (WST)
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 3631      
Status: RO
X-Status: 


[...Sorry to those who might have seen this twice. I didn't see it
come back to my site, so I'm mailing it again...]

>Most correspondence should be directed at the mailing list:
>
>	riscy@pyramid.com

May I suggest getting your mailing list software to include a "Reply-to:"
field? Makes following up a little easier.

>*  CPU, peripheral controller and memory
>		Allocated to: caret@pyramid.com
>	of what memory controller is available.  At this stage I am aiming
>	at using the IDT 79R3730.  To this end I am calling IDT to attempt

Just a comment here: having been in the same boat before waiting for IDT
to produce the R372x series of chips, I'd have to say that this chip is
going to be the most critical one in the whole design. Hopefully they
will produce this and make it available as planned...

>*  Keyboard controller / NV-RAM / RTC

I might just try and take this up. You mentioned the 8051 in your
previous mail, but I have a little further info. The original PC and XT
used the 8051, but all machines since have used the 8041. I know that
AMI (the BIOS people) make them pre-programmed with their PC BIOS (ie:
it's an EPROM as well), and think that this would make a nifty device
if we could get hold of it. It would obviously require re-burning the
EPROM, but I think it might be a good way to cut down on a couple of
chips. As for the NV-RAM and RTC, everything I've ever heard points to
Dallas Semi. Unfortunately, I've also heard that they advertise lots of
stuff that they never actually make. I'll look into both of these, and
see what I can come up with.

>*  SCSI bus
>		Allocated to: <no-one>
>	The SCSI bus would probably be done with something like a
>	NEC 53C94 SCSI controller.  Research needs to be done on this
>	and other available SCSI chips.  

Ok, I'm probably one of the people who pushed for this. The other SCSI
chips I've had a look at include: NCR53C7xx series (SMT and _big_),
NCR538x series (pretty dumb) and the WD33C98(?) (very buggy). One
advantage of the '94 is that it's second sourced by Emulex, NCR and
Motorola, so it should be pretty easy to get hold of. You should also
note that there's a 53CF94 which is the same device but does FAST SCSI.
Again, there are '96 chips which do wide SCSI (I think). I've been
unable to get any hard data down here though...

>*  Serial port

Might I suggest a Zilog SCC? I've had good experiences with these,
and they give you the ability to use AppleTalk (physically, anyhow)
at some stage. IMHO, we should have one SCC (or something) chip on
the motherboard itself, and use an ISA card for more "regular"
serial chips. Comments?

>*  Ethernet port
>		Allocated to: <no-one>
>	It has been suggested that we use an Am7990 (Lance) Ethernet

I probably suggested this too, but again - I don't know much about
it. I think there's an alternative in the NSC 8390(?) used on a lot
of PC ethernet cards. As I said, I'm not qualified to give an
opinion here.

>*  Video

Ok, I've accepted this idea <grin>. Anyone know if the 6845 is up
to it? What sort of a range does it have on sync signals?

>*  Diagnostics / monitor code

I'd be very interested in doing this. Obviously (I think), we'd want
some sort of an assembler for this step. See below.

>*  Cross assembler/compiler system

I've looked at this before and I think it's relatively trivial. Getting
GAS to produce R3k binaries is going to be the most important first
step, as we'll need that for the boot/debug ROM.

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 pat@ucc.gu.uwa.edu.au Mon Jun 28 10:09:15 1993
Return-Path: <pat@ucc.gu.uwa.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA24756; Mon, 28 Jun 93 10:09:10 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18874; Mon, 28 Jun 93 01:09:04 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA20651; Mon, 28 Jun 93 01:08:45 -0700
Received: from mackerel.gu.uwa.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18691; Mon, 28 Jun 93 01:08:33 -0700
Received: by ucc.gu.uwa.edu.au id AA03883
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Mon, 28 Jun 1993 16:00:59 +0800
From: Pat Mackinlay <pat@ucc.gu.uwa.edu.au>
Message-Id: <199306280800.AA03883@ucc.gu.uwa.edu.au>
Subject: SIMM sockets...
To: riscy@pyramid.com
Date: Mon, 28 Jun 1993 16:00:55 +0800 (WST)
X-Mailer: ELM [version 2.4 PL11]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 739       
Status: RO
X-Status: 


Neil, are you still planning on using 32 SIMM sockets? I've been looking,
and I just can't see how you plan to fit that many on the board if you
plan to do an ISA bus as well. 32 sounds a little excessive in any case.
I think we might do better to think about 8, possibly 16. More than 4
sockets is going to mean external memory drivers anyhow, so there's no
real difference between 8 and 16 apart from board space. Perhaps we can
allow 16M SIMMS to be used? With 8 x 16M SIMMS, we get the same 128M
maximum, perfectly reasonable from my point of view <grin>.

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 tor@tss.no Mon Jun 28 10:09:19 1993
Return-Path: <tor@tss.no>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA24757; Mon, 28 Jun 93 10:09:16 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18883; Mon, 28 Jun 93 01:09:08 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA20654; Mon, 28 Jun 93 01:08:55 -0700
Received: from benoni.Uit.No 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18861; Mon, 28 Jun 93 01:08:52 -0700
Received: from benoni by ppenoni.uit.no with SMTP (PP) 
          id <19523-0@ppenoni.uit.no>; Mon, 28 Jun 1993 10:08:42 +0000
Received: from unas.tss.no 
          by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) 
          id AAbenoni19519; Mon, 28 Jun 1993 10:08:40 +0200
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA29682;
          Mon, 28 Jun 93 10:03:07 +0200
Message-Id: <9306280803.AA29682@unas.tss.no>
From: tor@tss.no (Tor Arntsen)
Date: Mon, 28 Jun 1993 10:03:06 +0200
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: riscy@pyramid.com
Subject: Re: Things ...
Status: RO
X-Status: 

>> Rather more personal preference than anything else: Don't you just _love_ 
>> the idea of the X server running on its own CPU? It'd be the equivalent of 
>> having your own X terminal on board <grin>. No, it probably won't compete 
>> for speed with a well-designed framebuffer, but I think it's a very elegant 
>> solution.

Can't say I love it actually.. The Tandberg TDV 6230 runs an X-server
on the 34010 in 1024x768x1 (or x4), and it's slower than a 486+et4000 for
almost anything.  The only thing that is slower on the PC is scrolling.
The TDV 6230 is certainly much slower than a 486 + S3.
Of course, the X-response on the PC gets real bad when compiling the
kernel at the same time! :-)

>The 34010 will be around half the speed at doing bitblt's than the r3k;
>the 34k can probably do other things faster (lines, circles) but they
>don't matter.  As Pat says though, the 34k will take the load off the
>r3k.


Tor

 
From berge@sierra.nl Mon Jun 28 11:27:05 1993
Return-Path: <berge@sierra.nl>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA24987; Mon, 28 Jun 93 11:27:00 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA01314; Mon, 28 Jun 93 02:26:52 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02951; Mon, 28 Jun 93 02:26:35 -0700
Received: from gatekeeper.sierra.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA01306; Mon, 28 Jun 93 02:26:30 -0700
Received: from quint.sierra.nl by gatekeeper.sierra.nl (4.1/2.00)
    id AA10302; Mon, 28 Jun 93 11:25:09 +0200
Date: Mon, 28 Jun 93 11:25:09 +0200
From: berge@sierra.nl (Wim van den Berge)
Message-Id: <9306280925.AA10302@gatekeeper.sierra.nl>
To: riscy@pyramid.com
Subject: help
Status: RO
X-Status: 

help

 
From hodgen@informatik.uni-koblenz.de Mon Jun 28 11:47:35 1993
Return-Path: <hodgen@informatik.uni-koblenz.de>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25019; Mon, 28 Jun 93 11:47:14 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04128; Mon, 28 Jun 93 02:47:05 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA05190; Mon, 28 Jun 93 02:46:53 -0700
Received: from mailhost.uni-koblenz.de 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04120; Mon, 28 Jun 93 02:46:29 -0700
From: hodgen@informatik.uni-koblenz.de
Received: from ozzy by uniko.uni-koblenz.de with smtp
	(Smail3.1.28.1) id m0oAFmg-0001pGC; Mon, 28 Jun 93 11:45 MDT
Message-Id: <m0oAFmg-0001pGC@uniko.uni-koblenz.de>
Received: by ozzy (4.1/KO-2.0)
	id AA22025; Mon, 28 Jun 93 11:16:19 +0200
Subject: My 2 cents worth
To: riscy@pyramid.com
Date: Mon, 28 Jun 93 11:16:18 MET DST
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 


I've been following the discussion with great interest and feel it is now time
for me to say something.

a) I want an FPU. For me the 3051 is uninteresting. I do lots of raytracing/
   graphics work and am mostly interested in getting my sticky paws on a
   MIPS FPU to use at home.

b) Floppy MUST be available. Whether on the motherboard or using an ISA card 
   is irrelevant. Floppys (DOS format) are *the* standard way to get data
   from one machine to another. How many machines do you know that can't
   read DOS diskettes?

c) Sound must be available. Either stereo DAC's on board (at least 16kHz 8bit)
   or a PC soundcard per ISA (a Gravis Ultrasound for example).	

d) A parallel port for the printer, either ISA or on the motherboard, is
   a must. I'm not going to buy a new printer (with a serial port) just to
   run of this board! And then have it go slower!

e) The video solution being dicussed isn't going to be very fast. There's
   no point penny pinching to keep under some arbitrary limit and get a
   great board with X response worse than a 486+et4000. I'm prepared to
   pay for snappy windows and I think others are too.

Before this project started I was saving for a Pentium board. Why? 'Cos it's
faster than my 486 and I can take all my ISA boards out and plug them straight
into the new one. Now I'm saving to buy one of your boards IF IT'S FAST
ENOUGH. If the X performance isn't at least as good as S3 you can forget it.
I am willing to pay $1000 to $1200 for this board, IF IT'S GOOD ENOUGH. Please
don't save so much money making the board "cheap" that no-one wants it anymore.

Keep up the good work Guys!

-- 
Wayne Hodgen  | hodgen@infko.uni-koblenz.de | Opinions (c) Me 1991   | Intel SX
Uni Koblenz,  | (..!unido!infko!hodgen)     | Keeper of the Scrolls, |  Just
Rheinau 3-4,  | Voice: +49 261 9119-645     | Defender of the Net,   |   say
5400 Koblenz. | Fax:   +49 261 9119-499     | His name is "root".    |    NO!!!

 
From broadley@neurocog.lrdc.pitt.edu Mon Jun 28 11:58:44 1993
Return-Path: <broadley@neurocog.lrdc.pitt.edu>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25032; Mon, 28 Jun 93 11:58:38 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05733; Mon, 28 Jun 93 02:58:26 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06403; Mon, 28 Jun 93 02:58:19 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05725; Mon, 28 Jun 93 02:58:18 -0700
Message-Id: <9306280958.AA05725@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA20748; Mon, 28 Jun 93 05:57:46 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Post to comp.arch?
To: riscy@pyramid.com (Mips 3000)
Date: Mon, 28 Jun 1993 05:57:46 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1094      
Status: RO
X-Status: 

I was thinging of posting a "best cpu for under $300" to comp.arch
to see what they say outlining our needs:
	cheap in quantity	
	easy of integration
	nice price/performance

And mentioning they riscy mailing list, I think we have reached a small
percentage of the people that would be interested in the design/purchase
of a mips3000 motherboard to run a free unix.

Things might change alot of we had more people.  

I was going to just post but figured I'd ask the list (not to mention
the overhead for Neil to subscribe.)

I just wasn't sure how much distance I should put between the mailing list/
project and the post.

Would be kinda cool for comp.arch to pick it as a pet project.

Kinda of like the Usenet Serial Card II which I have and am very 
happy with.  It came out of a unfullfilled need for a good 4 port
16550 based card with source code for the card and it's PAL's.

-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok


 
From broadley@neurocog.lrdc.pitt.edu Mon Jun 28 12:29:32 1993
Return-Path: <broadley@neurocog.lrdc.pitt.edu>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25068; Mon, 28 Jun 93 12:29:29 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09784; Mon, 28 Jun 93 03:29:24 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA09072; Mon, 28 Jun 93 03:29:05 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09759; Mon, 28 Jun 93 03:29:03 -0700
Message-Id: <9306281029.AA09759@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA20804; Mon, 28 Jun 93 06:28:32 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Proposed to comp.arch
To: riscy@pyramid.com (Mips 3000)
Date: Mon, 28 Jun 1993 06:28:32 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1451      
Status: RO
X-Status: 

I was thinking of posting this with 2 goals: Explore any other options for
cpu, and get more people interested in design, and purchase of the board.
------------------------------------------------------------------------
Subject: Best cpu under $300

I'm looking for the best cpu to put in a motherboard to be designed for a 
small quantity production run (say between 25-100) to run a free unix port.  

Mandatory considerations: 
   Maximum to memory cpu speed 40 Mhz (for ease of design)
   Must run gcc (for easy of porting a free unix).
   Around $300 or less in quantity of 25-100  (going for a < $700 motherboard)

How do I define best?  
	Maximizing speed (specint, specfp) 
	minimizing cost/complexity of the implementation.  
	Cleaness of design/architecture.
	Ease of programming.

Optional floating point would be great for those who can't afford it.
 
So this probably rules out any Mips 4000, Alpha, Pentium chips on cost alone.

I've heard that the i860 and i960 are tough to program, and I don't like the 
design of the 486.

Post or email.
-----------------------------------------------------------------------
Optionally:

If you interested in the design of the motherboard send a subscribe to 
riscy-request@pyramid.com

-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok


 
From tor@tss.no Mon Jun 28 12:32:06 1993
Return-Path: <tor@tss.no>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25077; Mon, 28 Jun 93 12:31:58 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09849; Mon, 28 Jun 93 03:31:51 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA09116; Mon, 28 Jun 93 03:31:44 -0700
Received: from benoni.Uit.No 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09841; Mon, 28 Jun 93 03:31:42 -0700
Received: from benoni by ppenoni.uit.no with SMTP (PP) 
          id <20400-0@ppenoni.uit.no>; Mon, 28 Jun 1993 12:31:38 +0000
Received: from unas.tss.no 
          by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) 
          id AAbenoni20396; Mon, 28 Jun 1993 12:31:36 +0200
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA00338;
          Mon, 28 Jun 93 12:26:03 +0200
Message-Id: <9306281026.AA00338@unas.tss.no>
From: tor@tss.no (Tor Arntsen)
Date: Mon, 28 Jun 1993 12:26:01 +0200
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: riscy@pyramid.com
Subject: Re: Things ...
Status: RO
X-Status: 

>> Rather more personal preference than anything else: Don't you just _love_ 
>> the idea of the X server running on its own CPU? It'd be the equivalent of 
>> having your own X terminal on board <grin>. No, it probably won't compete 
>> for speed with a well-designed framebuffer, but I think it's a very elegant 
>> solution.

Can't say I love it actually.. The Tandberg TDV 6230 runs an X-server
on the 34010 in 1024x768x1 (or x4), and it's slower than a 486+et4000 for
almost anything.  The only thing that is slower on the PC is scrolling.
The TDV 6230 is certainly much slower than a 486 + S3.
Of course, the X-response on the PC gets real bad when compiling the
kernel at the same time! :-)

>The 34010 will be around half the speed at doing bitblt's than the r3k;
>the 34k can probably do other things faster (lines, circles) but they
>don't matter.  As Pat says though, the 34k will take the load off the
>r3k.

Tor



 
From tor@tss.no Mon Jun 28 13:33:11 1993
Return-Path: <tor@tss.no>
Received: from liberator.et.tudelft.nl by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25195; Mon, 28 Jun 93 13:33:08 +0200
Received: from benoni.Uit.No by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA05089; Mon, 28 Jun 93 13:33:03 +0200
Received: from benoni by ppenoni.uit.no with SMTP (PP) 
          id <20798-0@ppenoni.uit.no>; Mon, 28 Jun 1993 13:32:53 +0000
Received: from unas.tss.no 
          by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) 
          id AAbenoni20794; Mon, 28 Jun 1993 13:32:51 +0200
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA01034;
          Mon, 28 Jun 93 13:27:18 +0200
Message-Id: <9306281127.AA01034@unas.tss.no>
From: tor@tss.no (Tor Arntsen)
Date: Mon, 28 Jun 1993 13:27:16 +0200
In-Reply-To: wolff@liberator.et.tudelft.nl (Rogier Wolff) "Re: Video subsystem..." (Jun 28, 1:24pm)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: wolff@dutecai.et.tudelft.nl (Rogier Wolff)
Subject: Re: Video subsystem...
Status: RO
X-Status: 

On Jun 28,  1:24pm, Rogier Wolff wrote:
>>  HP X-terms (pa-based I think) are much much
>faster.
>
>Nope. They use Intel 960 processors.....
>
>					Rogier.

Yeah, I've got a couple of mails already correcting me on that point.
I've also got some good advice on how to fix those really *bad* looking
cheap displays..

Thanks,
Tor	(tor@tss.no)



 
From SMACKINLA@cc.curtin.edu.au Mon Jun 28 13:38:44 1993
Return-Path: <SMACKINLA@cc.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25240; Mon, 28 Jun 93 13:38:37 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20484; Mon, 28 Jun 93 04:38:30 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16447; Mon, 28 Jun 93 04:37:46 -0700
Received: from cc.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20435; Mon, 28 Jun 93 04:37:40 -0700
Received: from cc.curtin.edu.au by cc.curtin.edu.au (PMDF #3256 ) id
 <01GZX7Y264G6FUMLVJ@cc.curtin.edu.au>; Mon, 28 Jun 1993 19:36:44 +0800
Date: 28 Jun 1993 19:36:44 +0800
From: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Subject: Re: Things ...
To: tor@tss.no
Cc: riscy@pyramid.com
Message-Id: <01GZX7Y26E3CFUMLVJ@cc.curtin.edu.au>
X-Envelope-To: riscy@pyramid.com
X-Vms-To: IN%"tor@tss.no"
X-Vms-Cc: R3KPC,SMACKINLA
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
Status: RO
X-Status: 


(Tor, this message is not specifically targetted at you, I'm just getting 
a little exasperated. Please don't take anything personally.)

>on the 34010 in 1024x768x1 (or x4), and it's slower than a 486+et4000 for
>almost anything.  The only thing that is slower on the PC is scrolling.
>The TDV 6230 is certainly much slower than a 486 + S3.

Am I talking to a brick wall? I _KNOW_ the 34k is slower - I thought 
I made that plain. If you can come up with a design that costs the same 
amount and gives better performance, go right ahead: I'm not hooked on the 
idea of using the 34010.

>Of course, the X-response on the PC gets real bad when compiling the
>kernel at the same time! :-)

I think that this is one small advantage of the "separate processor" 
approach, but not the most important for our particular application. 
Further on this point, I think that people will complain less about 
"graphics performance" when the main CPU is still free to run programs. 
The "two processor" approach should also make the machine more appealing to 
people who want to use the box as a server because users on the console 
will have less impact on the system performance. I suspect that most 
programs would run quite acceptably on the 34k - perhaps not benchmarking 
as fast as a dumb framebuffer solution, but certainly fast enough to be 
useful.

Side note: For those people who do use systems with 34010's, where 
exactly are the performance problems? Do you actually see the chip 
"painting" the screen, or is it just a general sluggishness? I suspect some 
of the performance problems could actually be due to the fact that X 
terminals are usually diskless, and the I/O overhead dominates the actual 
graphics performance. This would not be an issue with a "local" 
implementation.

People: _PLEASE_, if you can come up with a practical alternative for a 
video system (I know you're out there Steve <grin>), speak up now. It 
_would_ be much better to use a dumb framebuffer attached to the CPU, but I 
fear that the extra logic required to generate monitor signals and clock 
the data out of the VRAM at the right speed would be a 

To try and summarize my opinion, I'd just like to say that most programs 
(that I deal with) are not limited by the speed of the X server. Usually, 
the limitations are on the system I/O performance. I think that using a 
separate CPU to do graphics will make our system less complex (ie: cheaper) 
while still providing perfectly acceptable graphics performance. Not only 
that, but it makes the system a bit more "interesting", from a hobbiest's 
perspective (I mean, what's the point of doing it if it's not going to be 
interesting <grin>). If someone comes up with a cheap and simple 
alternative to the 34k solution, I'd be very happy to use it, but so far,
no one has, and the 34k is the best choice in my mind.

As for the guy that said he'd be willing to pay $1200 for the system, I 
can't agree. In my mind, once you get over the US$800 mark, you'll be much 
better off with a fully "commercial" system. As Neil mentioned before: if 
all you want is a faster PC, by all means, go and buy one. I know it looks 
like I'm harping on the point, but the price and complexity of this system 
are the factors which will decide its fate.

Again, I hope we've seen the end of the integer vs FP argument: that can be 
sorted out when the time comes. It's much more important to fill in the 
other parts of the system right now. Please don't bring it up again.

[...At the risk of repeating myself (again): If you're going to "knock" the 
34k solution, please make sure you have a viable alternative...]

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 wolff@dutecai.et.tudelft.nl Tue Jun 22 17:41:22 1993
Return-Path: <wolff@dutecai.et.tudelft.nl>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA03653; Tue, 22 Jun 93 17:41:18 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA24610; Tue, 22 Jun 93 08:43:44 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02800; Tue, 22 Jun 93 08:40:48 -0700
Received: from liberator.et.tudelft.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA24597; Tue, 22 Jun 93 08:43:37 -0700
Received: by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA03031; Tue, 22 Jun 93 17:39:15 +0200
Date: Tue, 22 Jun 93 17:39:15 +0200
From: wolff@dutecai.et.tudelft.nl (Rogier Wolff)
Message-Id: <9306221539.AA03031@liberator.et.tudelft.nl>
To: riscy@pyramid.com
Subject: Boot rom  and other useless junk.
Status: RO
X-Status: 



Hi everyone,

After reading the "preliminary specs" I have the following suggestions:

>* Boot EPROM
>        Because of the 3730, we can get away with just one EPROM.
>        Maybe two just for kicks.  Access to this is slow, so if
>        speed were are problem, then code could be copied to RAM.

I'd suggest using the approach that we've used for a design here. What
we do is we have the x86 CPU control the reset line of the "bigger" cpu.
The x86 also has access to (at least some of) the RAM of the R3000.
This will enable the x86 to place the boot code into the RAM before
releasing the RESET of the R3000.

Instant saving: 1 eprom per board, Development costs (reburning EPROMS all 
the time....)

>*  Keyboard controller
>        This should certainly handle IBM compatible style keyboards.
>        The only way I know to do this is to use the 8051(?) micro-
>        controller to drive the keyboard exactly the same way as
>        every mother-board I've seen does.  This circuit should
>        connect easily to the 8-bit bus of the 3730.

See below, near "serial port".

>*  Non-Volatile-RAM and Real-Time-Clock
>        This should be looked into.  The clock is almost a requirement
>        but the NV-RAM could be replaced with the feature selector.

Why do you need a NV RAM? Why do you  need a RTC? You do need an
interrupt every 10ms. You can initialize from the RTC on the PC.
(ok. ok. Those are crummy, but you can live with it....)

>*  Serial port
>        Because of the ISA bus, serial is always possible.  It might
>        be a good idea, if just for debugging to have some serial
>        ports on the mother-board.  If this is the case, they should
>        be at least as good as 16550's.

My suggestion is to have a shared memory interface that looks like a 
serial line:

        struct combuf {
                int hd,tl;
                char buf[BUFSIZE];
                }
        
        out_char (struct combuf *cb,ch)
        {
        int hd = cb->hd;
        cb->buf[hd] = ch;
        inc (hd);
        while (hd == cb->tl)
                sleep_a_little_while ();
        cb->hd = hd;
        }

        in_char (struct combuf *cb)
        {
        int tl = cb->tl;
        int ch;

        while (tl == cb->head)
                sleep_a_little_while ();
        ch = cb->buf[tl];
        inc (tl);
        cb->tl = tl;
        }
        

Both sides (on the PC and on the R3000) use this interface (with different
cb pointers). To both sides this looks more or less like a serial stream 
of data.

To make this work in an multitasking environment it would be nice
to have an interrupt too.

                                Roger.


 
From SMACKINLA@cc.curtin.edu.au Mon Jun 28 13:39:43 1993
Return-Path: <SMACKINLA@cc.curtin.edu.au>
Received: from liberator.et.tudelft.nl by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25250; Mon, 28 Jun 93 13:39:33 +0200
Received: from CC.CURTIN.EDU.AU by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA05099; Mon, 28 Jun 93 13:39:01 +0200
Received: from cc.curtin.edu.au by cc.curtin.edu.au (PMDF #3256 ) id
 <01GZX905ZGNIFUMLVJ@cc.curtin.edu.au>; Mon, 28 Jun 1993 19:38:30 +0800
Date: 28 Jun 1993 19:38:30 +0800
From: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Subject: Re: Archive....
To: wolff@dutecai.et.tudelft.nl
Message-Id: <01GZX905ZGN4FUMLVJ@cc.curtin.edu.au>
X-Envelope-To: wolff@liberator.et.tudelft.nl
X-Vms-To: IN%"wolff@liberator.et.tudelft.nl"
X-Vms-Cc: SMACKINLA
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
Status: RO
X-Status: 


>I've dunked about everything I got so far into a file.... Here it comes:

Thanks for sending that. Much appreciated.

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 tor@tss.no Mon Jun 28 14:04:52 1993
Return-Path: <tor@tss.no>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25298; Mon, 28 Jun 93 14:04:48 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA25086; Mon, 28 Jun 93 05:04:39 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA18904; Mon, 28 Jun 93 05:04:29 -0700
Received: from benoni.Uit.No 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA24974; Mon, 28 Jun 93 05:04:27 -0700
Received: from benoni by ppenoni.uit.no with SMTP (PP) 
          id <20989-0@ppenoni.uit.no>; Mon, 28 Jun 1993 14:04:05 +0000
Received: from unas.tss.no 
          by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) 
          id AAbenoni20985; Mon, 28 Jun 1993 14:04:00 +0200
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA01676;
          Mon, 28 Jun 93 13:58:27 +0200
Message-Id: <9306281158.AA01676@unas.tss.no>
From: tor@tss.no (Tor Arntsen)
Date: Mon, 28 Jun 1993 13:58:25 +0200
In-Reply-To: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au> "Re: Things ..." (Jun 28, 7:36pm)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Subject: Re: Things ...
Cc: riscy@pyramid.com
Status: RO
X-Status: 

Pat Mackinlay wrote:
>(Tor, this message is not specifically targetted at you, I'm just getting 
>a little exasperated. Please don't take anything personally.)
No problem.. :-)

[a lot deleted]
>Side note: For those people who do use systems with 34010's, where 
>exactly are the performance problems? Do you actually see the chip 
>"painting" the screen, or is it just a general sluggishness? I suspect some 
>of the performance problems could actually be due to the fact that X 
>terminals are usually diskless, and the I/O overhead dominates the actual 
>graphics performance. This would not be an issue with a "local" 
>implementation.

Good point.  If I get the time I will fire up that system to see if I can
make better conclusions.  But don't let that put you on hold guys :-)

[more deleted]
>[...At the risk of repeating myself (again): If you're going to "knock" the 
>34k solution, please make sure you have a viable alternative...]
                                           ^^^^^^^^^^^^^^^^^^
Well, I don't have any!  I will probably not have any time available for a 
long time to dig into it either, so please just take those postings from me
as 'user reports', I certainly don't want to make any claims of how it
shall be done.

I still think this board will be fun..
Tor	(tor@tss.no)


 
From hodgen@informatik.uni-koblenz.de Mon Jun 28 14:16:23 1993
Return-Path: <hodgen@informatik.uni-koblenz.de>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25316; Mon, 28 Jun 93 14:16:15 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA27607; Mon, 28 Jun 93 05:16:09 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA19507; Mon, 28 Jun 93 05:15:56 -0700
Received: from mailhost.uni-koblenz.de 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA27522; Mon, 28 Jun 93 05:15:46 -0700
From: hodgen@informatik.uni-koblenz.de
Received: from ozzy by uniko.uni-koblenz.de with smtp
	(Smail3.1.28.1) id m0oAHu8-0001vyC; Mon, 28 Jun 93 14:01 MDT
Message-Id: <m0oAHu8-0001vyC@uniko.uni-koblenz.de>
Received: by ozzy (4.1/KO-2.0)
	id AA22861; Mon, 28 Jun 93 14:01:59 +0200
Subject: Re: Things
To: riscy@pyramid.com
Date: Mon, 28 Jun 93 14:01:57 MET DST
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

 Pat Mackinlay said	
>As for the guy that said he'd be willing to pay $1200 for the system, I 
>can't agree. In my mind, once you get over the US$800 mark, you'll be much 
>better off with a fully "commercial" system. As Neil mentioned before: if 
>all you want is a faster PC, by all means, go and buy one. I know it looks 
>like I'm harping on the point, but the price and complexity of this system 
>are the factors which will decide its fate.

Thats the point. I don't just want a faster PC, thats why I'm willing to wait
and pay more for something worth having.

-- 
Wayne Hodgen  | hodgen@infko.uni-koblenz.de | Opinions (c) Me 1991   | Intel SX
Uni Koblenz,  | (..!unido!infko!hodgen)     | Keeper of the Scrolls, |  Just
Rheinau 3-4,  | Voice: +49 261 9119-645     | Defender of the Net,   |   say
5400 Koblenz. | Fax:   +49 261 9119-499     | His name is "root".    |    NO!!!

 
From andy@resi.waldorf-gmbh.de Mon Jun 28 14:32:14 1993
Return-Path: <andy@resi.waldorf-gmbh.de>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25338; Mon, 28 Jun 93 14:32:11 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA00247; Mon, 28 Jun 93 05:32:04 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA20928; Mon, 28 Jun 93 05:31:54 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA29799; Mon, 28 Jun 93 05:31:52 -0700
Received: by mail.Germany.EU.net(EUnetD-2.2.6.c) via EUnet
	id PA14007; Mon, 28 Jun 1993 14:28:58 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for unido
	id AA07233; Mon, 28 Jun 93 14:14:54 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Mon, 28 Jun 93 14:13:23 +0200
Message-Id: <9306281213.AA13316@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA13316; Mon, 28 Jun 93 14:13:23 +0200
To: riscy@pyramid.com
Subject: UARTS & FDC's
Status: RO
X-Status: 

Hi Mipsers !

Looks like we are coming nearer to our final spec-sheet.

I have seen there was (or is?) a discussion about
floppys ot not and what UARTS.

I found something new:

SMC FDC37C651/2

It includes:

a 765-compatible FDC,
two 16450 compatible UARTs
a parallel port
and, for poor people, an IDE Interface...

What's about that ?

-------------------------------------------------------------------------------
Waldorf Electronics GmbH, R&D Department
c/o Andreas Busse
Neustrasse 9-12
D-5481 Waldorf
Phone:  +49 (0)2636-80294
Fax:    +49 (0)2636-80188
e-mail: andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------

 
From broadley@neurocog.lrdc.pitt.edu Mon Jun 28 14:56:59 1993
Return-Path: <broadley@neurocog.lrdc.pitt.edu>
Received: from liberator.et.tudelft.nl by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25522; Mon, 28 Jun 93 14:56:56 +0200
Received: from neurocog.lrdc.pitt.edu by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA05251; Mon, 28 Jun 93 14:56:50 +0200
Message-Id: <9306281256.AA05251@liberator.et.tudelft.nl>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA21160; Mon, 28 Jun 93 08:56:14 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Re: Proposed to comp.arch
To: wolff@dutecai.et.tudelft.nl (Rogier Wolff)
Date: Mon, 28 Jun 1993 08:56:14 -0500 (EDT)
In-Reply-To: <9306281241.AA05161@liberator.et.tudelft.nl> from "Rogier Wolff" at Jun 28, 93 02:41:04 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 804       
Status: RO
X-Status: 

> 
> Your post to Comp.arch mentioned the I960 as "hard to program".
> This is not true. The 960 has a clean architecture, and has a GCC 
> port.
> 
> 				Roger.

Hmmm I heard several things that make it unattractive for programming
in unix.  (which I kinda believe because nobody uses it for unix).

Does it do context switching well?  I have heard things like mult a,b,c
Multiplies a*b and puts the answer from 3 multiplies ago in c.

It's supposed to be very fast (at least in fp) but very hard to
extract that performance.  Any info would be appreciated.

There's an i860 port for gcc also.

-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok

 
From Steven.D.Ligett@Dartmouth.EDU Mon Jun 28 15:04:58 1993
Return-Path: <Steven.D.Ligett@Dartmouth.EDU>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25607; Mon, 28 Jun 93 15:04:48 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04563; Mon, 28 Jun 93 06:04:43 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA24887; Mon, 28 Jun 93 06:04:27 -0700
Received: from dartvax.dartmouth.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04444; Mon, 28 Jun 93 06:04:25 -0700
Received: from prancer.dartmouth.edu by dartvax.dartmouth.edu (5.65+D5/4.5HUB)
	id AA21049; Mon, 28 Jun 93 09:03:06 -0400
Message-Id: <5283630@prancer.Dartmouth.EDU>
Date: 28 Jun 93 09:03:03 EDT
From: Steven.D.Ligett@Dartmouth.EDU (Steven D. Ligett)
Subject: Re: SIMM sockets...
To: riscy@pyramid.com
Status: RO
X-Status: 

--- Pat Mackinlay wrote:
Neil, are you still planning on using 32 SIMM sockets? I've been looking, and
I just can't see how you plan to fit that many on the board if you plan to do
an ISA bus as well.... Perhaps we can allow 16M SIMMS to be used? With 8 x
16M SIMMS, we get the same 128M maximum, perfectly reasonable from my point
of view <grin>.
--- end of quoted material ---
I think that the problem is the plan to use the glue chip that only supports
1MB and 4MB chips.  (If I understand what's been said about the 7370 (?).)  
A typically shortsighted chip design, I'd say.

Let's take a quick look at the costs of the board and sockets for these 32
SIMMs.  Ignore the space and cost of the memory drivers that will be needed.

For a 6-layer board, $1.50 per square inch for the PCB.  Each socket is about
0.3" by 4".

board cost = $1.50 * 32 * 0.3" * 4" = $57.60  
just for the board space.

socket cost = $1.95 * 32 = $62.40
for the sockets.

$120 to put 32 empty SIMM sockets on the board.  Assume that I'm
misremembering the socket cost, and that we go with a 4-layer board, and that
goes down to $100.  Still too much.

 
From af4@ukc.ac.uk Mon Jun 28 15:09:42 1993
Return-Path: <af4@ukc.ac.uk>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25614; Mon, 28 Jun 93 15:09:39 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05228; Mon, 28 Jun 93 06:09:29 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA26212; Mon, 28 Jun 93 06:09:22 -0700
Received: from mercury.ukc.ac.uk 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05220; Mon, 28 Jun 93 06:09:20 -0700
Message-Id: <9306281309.AA05220@gossip.pyramid.com>
Received: from eagle by mercury.ukc.ac.uk   with UKC POP3+  id aa23470;
          28 Jun 93 14:08 BST
Date: Mon, 28 Jun 93 13:56:19 +0100
From: af4@ukc.ac.uk
To: riscy@pyramid.com
Subject: Things & Stuff
Status: RO
X-Status: 


There has been lots of noise about 34010 versus dumb frame buffers. Whilst I'm
in favour of the 34010 solution, I though I'd mention the 34076 Video Systems
Controller. The 34076 generates all the control and timing signals for a
raster scan video system, you just add a blob of VRAM, and a DAC (Inmos make
some nice ones, BTW), and Bob's yer aunty - instant dumb frame buffer.

While I'm at it, don't go leaving the parallel printer port off of the
motherboard. The cost of the necessary TTL octal latch is peanuts, so please
do your penny pinching elsewhere!

 
From SMACKINLA@cc.curtin.edu.au Mon Jun 28 15:22:56 1993
Return-Path: <SMACKINLA@cc.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25670; Mon, 28 Jun 93 15:22:19 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06468; Mon, 28 Jun 93 06:22:10 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA26897; Mon, 28 Jun 93 06:21:55 -0700
Received: from cc.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06460; Mon, 28 Jun 93 06:21:50 -0700
Received: from cc.curtin.edu.au by cc.curtin.edu.au (PMDF #3256 ) id
 <01GZXCG1MRDSFUMLVJ@cc.curtin.edu.au>; Mon, 28 Jun 1993 21:21:04 +0800
Date: 28 Jun 1993 21:21:04 +0800
From: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Subject: Re: Things & Stuff
To: af4@ukc.ac.uk
Cc: riscy@pyramid.com
Message-Id: <01GZXCG1N10YFUMLVJ@cc.curtin.edu.au>
X-Envelope-To: riscy@pyramid.com
X-Vms-To: IN%"af4@ukc.ac.uk"
X-Vms-Cc: R3KPC,SMACKINLA
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
Status: RO
X-Status: 


>There has been lots of noise about 34010 versus dumb frame buffers. Whilst I'm
>in favour of the 34010 solution, I though I'd mention the 34076 Video Systems
>Controller. The 34076 generates all the control and timing signals for a
>raster scan video system, you just add a blob of VRAM, and a DAC (Inmos make
>some nice ones, BTW), and Bob's yer aunty - instant dumb frame buffer.

Ok, this is what I was looking for. Any ideas on pricing? I hope TI still 
makes the thing. Does anyone know of any other chips that will provide 
similar stuff? While we're at it, perhaps you could let me (us) know why 
you do favour a 34010 solution? I personally would go for the dumb 
framebuffer if it were possible to do it cheaply enough...

>While I'm at it, don't go leaving the parallel printer port off of the
>motherboard. The cost of the necessary TTL octal latch is peanuts, so please
>do your penny pinching elsewhere!

Hmmm... My feelings here are that if we're going to put a parallel port and 
an FDC on the motherboard, it should only be done at the expense of the ISA 
(or other) I/O bus. A card with a parallel port and other junk costs 
virtually nothing. Putting a "real" parallel port (ie: bidirectional) on 
the motherboard would be a waste of board space and effort (IMHO).

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 wolff@dutecai.et.tudelft.nl Mon Jun 28 15:26:16 1993
Return-Path: <wolff@dutecai.et.tudelft.nl>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25697; Mon, 28 Jun 93 15:26:13 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06845; Mon, 28 Jun 93 06:25:58 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA27196; Mon, 28 Jun 93 06:25:47 -0700
Received: from liberator.et.tudelft.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06819; Mon, 28 Jun 93 06:25:36 -0700
Received: by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA05424; Mon, 28 Jun 93 15:24:12 +0200
Date: Mon, 28 Jun 93 15:24:12 +0200
From: wolff@dutecai.et.tudelft.nl (Rogier Wolff)
Message-Id: <9306281324.AA05424@liberator.et.tudelft.nl>
To: riscy@pyramid.com
Subject: Graphics implementation.
Status: RO
X-Status: 



Hi everyone,

> People: _PLEASE_, if you can come up with a practical alternative for a 
> video system (I know you're out there Steve <grin>), speak up now. It 
> _would_ be much better to use a dumb framebuffer attached to the CPU, but I 
> fear that the extra logic required to generate monitor signals and clock 
> the data out of the VRAM at the right speed would be a 

I've "posted" this before, but we have a solution using a SGS-Thompson
G335. It has a hook to the system bus on one side, and a video
bus on the other side. The video memory is simply mapped in the
processors memory address space (like normal DRAM). The G335 will
perform a DMA cycle every 1024*4 pixels (at 4 pixels / word).

The G335 has onboard 8 bit DACs, so you don't have to buy a separate
RAMDAC. Simple single chip solution. Also runs upto 1280x1024 at 70Hz.....

Disadvantages: costs around $100, is an SMD.

Since it is a single chip you can save a lot on extra "small glue" components
and assembly costs. (these add up you know). About the SMD: With a little
care and patience, you can solder one on a board in a few hours (I know,
I've done it.....).

I agree: you don't want to do 30 of them. You'll be fed up with doing this
after a few of them. On the other hand, you might get a little more 
experience, and speed things up a lot.

					Roger.


 
From ewt@SunSITE.unc.edu Mon Jun 28 17:37:47 1993
Return-Path: <ewt@SunSITE.unc.edu>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA26136; Mon, 28 Jun 93 17:37:41 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA22765; Mon, 28 Jun 93 08:37:30 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA10379; Mon, 28 Jun 93 08:36:20 -0700
Received: from SunSite.unc.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA22542; Mon, 28 Jun 93 08:36:18 -0700
Received: by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA01523; Mon, 28 Jun 93 11:35:06 EDT
Date: Mon, 28 Jun 1993 11:35:05 -0400 (EDT)
From: Erik Troan <ewt@SunSite.unc.edu>
Subject: 34010 X compiler, mailing lists
To: riscy@pyramid.com
Message-Id: <Pine.2.4.53.9306281125.A1445@calypso>
Status: RO
X-Status: 


On xxx, 27 Jun 1993, Pat Mackinlay wrote:

[lots of good stuff about 34010's deleted becuase we've all read it already

> BTW: I wouldn't expect that using a 34010 would make the graphics
> system outperform any of the VGAs out there, but it'd be quite
> interesting, and would leave the main CPU free to do some "real"
> work. It might even be practical to run PEX stuff <grin>

If we do decide on the 34010 path, I agree with Pat that a gcc port would
be a huge problem. I'm willing to write a small C compiler for the chip
from scratch. I'm not offering to port gcc, as I think that such an effort
is unnecessary. If the chip is going to be driving graphics, code doesn't
have to be written often, so I think we can live with putting the 
optimizations in the code instead of the compiler.

By small I mean I'm not going to write a floating point library (though
I'd be happy to integrate with one written by someone else), generate
anything but straight object code for the 34010 (we don't need dll's,
etc for a graphics processor), or even acknowledge C++'s existence any
further then allowing // for comments. Let me know if this is worth
my time.

> [...if there is no archive site, would someone be willing to mail me
> the last day or two of messages? I don't like having to repeat questions
> that people have already answered...]

If there is an archive site, would someone please let me know. If not, I'd
like to set one up on sunsite.unc.edu. /pub/Riscy maybe? Seems like we
should start thinking about an ftp site anyhow.

Erik

 
From caret@pyramid.com Tue Jun 22 05:49:16 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA00241; Tue, 22 Jun 93 05:49:13 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18736; Mon, 21 Jun 93 20:52:02 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15731; Mon, 21 Jun 93 20:49:02 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306220349.AA15731@sword.eng.pyramid.com>
Subject: MIPS R3000 mailing list
To: riscy@pyramid.com
Date: Mon, 21 Jun 93 20:49:02 PDT
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

Welcome to the MIPS R3000 board project mailing list.

This mailing list has been formed for the discussion of the design of
the MIPS R3000 board that has been under recent discussion in
comp.os.linux.  You have been added automatically to this list because
you expressed some interest in helping design this device.

Requests to be added or deleted from this list should be directed to
'riscy-request@pyramid.com'.  Mail sent to 'riscy@pyramid.com' will
be forwarded to all other members of the list.

I intended this list to hardware issues and software issues relating
directly to the board.  Discussion about the porting of various
operating systems should be directed to another as yet undefined
mailing list.

-- 
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 mackinla@cs.curtin.edu.au Tue Jun 22 17:35:52 1993
Return-Path: <mackinla@cs.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA03640; Tue, 22 Jun 93 17:35:47 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23874; Tue, 22 Jun 93 08:37:19 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA01794; Tue, 22 Jun 93 08:34:22 -0700
Received: from marsh.cs.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23860; Tue, 22 Jun 93 08:37:09 -0700
Received: from vincent.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA11020
  (5.67a/IDA-1.4.4 for <riscy@pyramid.com>); Tue, 22 Jun 1993 23:32:50 +0800
Received: by vincent.cs.curtin.edu.au id AA14659
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Tue, 22 Jun 1993 23:32:45 +0800
From: Patrick Mackinlay <mackinla@cs.curtin.edu.au>
Message-Id: <199306221532.AA14659@vincent.cs.curtin.edu.au>
Subject: Re: MIPS R3000 tasks available; volunteers?
To: riscy@pyramid.com
Date: Tue, 22 Jun 1993 23:32:44 +0800 (WST)
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 3631      
Status: RO
X-Status: 


[...Sorry to those who might have seen this twice. I didn't see it
come back to my site, so I'm mailing it again...]

>Most correspondence should be directed at the mailing list:
>
>	riscy@pyramid.com

May I suggest getting your mailing list software to include a "Reply-to:"
field? Makes following up a little easier.

>*  CPU, peripheral controller and memory
>		Allocated to: caret@pyramid.com
>	of what memory controller is available.  At this stage I am aiming
>	at using the IDT 79R3730.  To this end I am calling IDT to attempt

Just a comment here: having been in the same boat before waiting for IDT
to produce the R372x series of chips, I'd have to say that this chip is
going to be the most critical one in the whole design. Hopefully they
will produce this and make it available as planned...

>*  Keyboard controller / NV-RAM / RTC

I might just try and take this up. You mentioned the 8051 in your
previous mail, but I have a little further info. The original PC and XT
used the 8051, but all machines since have used the 8041. I know that
AMI (the BIOS people) make them pre-programmed with their PC BIOS (ie:
it's an EPROM as well), and think that this would make a nifty device
if we could get hold of it. It would obviously require re-burning the
EPROM, but I think it might be a good way to cut down on a couple of
chips. As for the NV-RAM and RTC, everything I've ever heard points to
Dallas Semi. Unfortunately, I've also heard that they advertise lots of
stuff that they never actually make. I'll look into both of these, and
see what I can come up with.

>*  SCSI bus
>		Allocated to: <no-one>
>	The SCSI bus would probably be done with something like a
>	NEC 53C94 SCSI controller.  Research needs to be done on this
>	and other available SCSI chips.  

Ok, I'm probably one of the people who pushed for this. The other SCSI
chips I've had a look at include: NCR53C7xx series (SMT and _big_),
NCR538x series (pretty dumb) and the WD33C98(?) (very buggy). One
advantage of the '94 is that it's second sourced by Emulex, NCR and
Motorola, so it should be pretty easy to get hold of. You should also
note that there's a 53CF94 which is the same device but does FAST SCSI.
Again, there are '96 chips which do wide SCSI (I think). I've been
unable to get any hard data down here though...

>*  Serial port

Might I suggest a Zilog SCC? I've had good experiences with these,
and they give you the ability to use AppleTalk (physically, anyhow)
at some stage. IMHO, we should have one SCC (or something) chip on
the motherboard itself, and use an ISA card for more "regular"
serial chips. Comments?

>*  Ethernet port
>		Allocated to: <no-one>
>	It has been suggested that we use an Am7990 (Lance) Ethernet

I probably suggested this too, but again - I don't know much about
it. I think there's an alternative in the NSC 8390(?) used on a lot
of PC ethernet cards. As I said, I'm not qualified to give an
opinion here.

>*  Video

Ok, I've accepted this idea <grin>. Anyone know if the 6845 is up
to it? What sort of a range does it have on sync signals?

>*  Diagnostics / monitor code

I'd be very interested in doing this. Obviously (I think), we'd want
some sort of an assembler for this step. See below.

>*  Cross assembler/compiler system

I've looked at this before and I think it's relatively trivial. Getting
GAS to produce R3k binaries is going to be the most important first
step, as we'll need that for the boot/debug ROM.

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 pat@ucc.gu.uwa.edu.au Mon Jun 28 10:09:15 1993
Return-Path: <pat@ucc.gu.uwa.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA24756; Mon, 28 Jun 93 10:09:10 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18874; Mon, 28 Jun 93 01:09:04 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA20651; Mon, 28 Jun 93 01:08:45 -0700
Received: from mackerel.gu.uwa.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18691; Mon, 28 Jun 93 01:08:33 -0700
Received: by ucc.gu.uwa.edu.au id AA03883
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Mon, 28 Jun 1993 16:00:59 +0800
From: Pat Mackinlay <pat@ucc.gu.uwa.edu.au>
Message-Id: <199306280800.AA03883@ucc.gu.uwa.edu.au>
Subject: SIMM sockets...
To: riscy@pyramid.com
Date: Mon, 28 Jun 1993 16:00:55 +0800 (WST)
X-Mailer: ELM [version 2.4 PL11]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 739       
Status: RO
X-Status: 


Neil, are you still planning on using 32 SIMM sockets? I've been looking,
and I just can't see how you plan to fit that many on the board if you
plan to do an ISA bus as well. 32 sounds a little excessive in any case.
I think we might do better to think about 8, possibly 16. More than 4
sockets is going to mean external memory drivers anyhow, so there's no
real difference between 8 and 16 apart from board space. Perhaps we can
allow 16M SIMMS to be used? With 8 x 16M SIMMS, we get the same 128M
maximum, perfectly reasonable from my point of view <grin>.

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 tor@tss.no Mon Jun 28 12:32:06 1993
Return-Path: <tor@tss.no>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25077; Mon, 28 Jun 93 12:31:58 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09849; Mon, 28 Jun 93 03:31:51 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA09116; Mon, 28 Jun 93 03:31:44 -0700
Received: from benoni.Uit.No 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09841; Mon, 28 Jun 93 03:31:42 -0700
Received: from benoni by ppenoni.uit.no with SMTP (PP) 
          id <20400-0@ppenoni.uit.no>; Mon, 28 Jun 1993 12:31:38 +0000
Received: from unas.tss.no 
          by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) 
          id AAbenoni20396; Mon, 28 Jun 1993 12:31:36 +0200
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA00338;
          Mon, 28 Jun 93 12:26:03 +0200
Message-Id: <9306281026.AA00338@unas.tss.no>
From: tor@tss.no (Tor Arntsen)
Date: Mon, 28 Jun 1993 12:26:01 +0200
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: riscy@pyramid.com
Subject: Re: Things ...
Status: RO
X-Status: 

>> Rather more personal preference than anything else: Don't you just _love_ 
>> the idea of the X server running on its own CPU? It'd be the equivalent of 
>> having your own X terminal on board <grin>. No, it probably won't compete 
>> for speed with a well-designed framebuffer, but I think it's a very elegant 
>> solution.

Can't say I love it actually.. The Tandberg TDV 6230 runs an X-server
on the 34010 in 1024x768x1 (or x4), and it's slower than a 486+et4000 for
almost anything.  The only thing that is slower on the PC is scrolling.
The TDV 6230 is certainly much slower than a 486 + S3.
Of course, the X-response on the PC gets real bad when compiling the
kernel at the same time! :-)

>The 34010 will be around half the speed at doing bitblt's than the r3k;
>the 34k can probably do other things faster (lines, circles) but they
>don't matter.  As Pat says though, the 34k will take the load off the
>r3k.

Tor



 
From SMACKINLA@cc.curtin.edu.au Mon Jun 28 15:22:56 1993
Return-Path: <SMACKINLA@cc.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25670; Mon, 28 Jun 93 15:22:19 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06468; Mon, 28 Jun 93 06:22:10 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA26897; Mon, 28 Jun 93 06:21:55 -0700
Received: from cc.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06460; Mon, 28 Jun 93 06:21:50 -0700
Received: from cc.curtin.edu.au by cc.curtin.edu.au (PMDF #3256 ) id
 <01GZXCG1MRDSFUMLVJ@cc.curtin.edu.au>; Mon, 28 Jun 1993 21:21:04 +0800
Date: 28 Jun 1993 21:21:04 +0800
From: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Subject: Re: Things & Stuff
To: af4@ukc.ac.uk
Cc: riscy@pyramid.com
Message-Id: <01GZXCG1N10YFUMLVJ@cc.curtin.edu.au>
X-Envelope-To: riscy@pyramid.com
X-Vms-To: IN%"af4@ukc.ac.uk"
X-Vms-Cc: R3KPC,SMACKINLA
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
Status: RO
X-Status: 


>There has been lots of noise about 34010 versus dumb frame buffers. Whilst I'm
>in favour of the 34010 solution, I though I'd mention the 34076 Video Systems
>Controller. The 34076 generates all the control and timing signals for a
>raster scan video system, you just add a blob of VRAM, and a DAC (Inmos make
>some nice ones, BTW), and Bob's yer aunty - instant dumb frame buffer.

Ok, this is what I was looking for. Any ideas on pricing? I hope TI still 
makes the thing. Does anyone know of any other chips that will provide 
similar stuff? While we're at it, perhaps you could let me (us) know why 
you do favour a 34010 solution? I personally would go for the dumb 
framebuffer if it were possible to do it cheaply enough...

>While I'm at it, don't go leaving the parallel printer port off of the
>motherboard. The cost of the necessary TTL octal latch is peanuts, so please
>do your penny pinching elsewhere!

Hmmm... My feelings here are that if we're going to put a parallel port and 
an FDC on the motherboard, it should only be done at the expense of the ISA 
(or other) I/O bus. A card with a parallel port and other junk costs 
virtually nothing. Putting a "real" parallel port (ie: bidirectional) on 
the motherboard would be a waste of board space and effort (IMHO).

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 caret@pyramid.com Tue Jun 22 05:49:16 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA00241; Tue, 22 Jun 93 05:49:13 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18736; Mon, 21 Jun 93 20:52:02 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15731; Mon, 21 Jun 93 20:49:02 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306220349.AA15731@sword.eng.pyramid.com>
Subject: MIPS R3000 mailing list
To: riscy@pyramid.com
Date: Mon, 21 Jun 93 20:49:02 PDT
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

Welcome to the MIPS R3000 board project mailing list.

This mailing list has been formed for the discussion of the design of
the MIPS R3000 board that has been under recent discussion in
comp.os.linux.  You have been added automatically to this list because
you expressed some interest in helping design this device.

Requests to be added or deleted from this list should be directed to
'riscy-request@pyramid.com'.  Mail sent to 'riscy@pyramid.com' will
be forwarded to all other members of the list.

I intended this list to hardware issues and software issues relating
directly to the board.  Discussion about the porting of various
operating systems should be directed to another as yet undefined
mailing list.

-- 
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 mackinla@cs.curtin.edu.au Tue Jun 22 17:35:52 1993
Return-Path: <mackinla@cs.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA03640; Tue, 22 Jun 93 17:35:47 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23874; Tue, 22 Jun 93 08:37:19 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA01794; Tue, 22 Jun 93 08:34:22 -0700
Received: from marsh.cs.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23860; Tue, 22 Jun 93 08:37:09 -0700
Received: from vincent.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA11020
  (5.67a/IDA-1.4.4 for <riscy@pyramid.com>); Tue, 22 Jun 1993 23:32:50 +0800
Received: by vincent.cs.curtin.edu.au id AA14659
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Tue, 22 Jun 1993 23:32:45 +0800
From: Patrick Mackinlay <mackinla@cs.curtin.edu.au>
Message-Id: <199306221532.AA14659@vincent.cs.curtin.edu.au>
Subject: Re: MIPS R3000 tasks available; volunteers?
To: riscy@pyramid.com
Date: Tue, 22 Jun 1993 23:32:44 +0800 (WST)
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 3631      
Status: RO
X-Status: 


[...Sorry to those who might have seen this twice. I didn't see it
come back to my site, so I'm mailing it again...]

>Most correspondence should be directed at the mailing list:
>
>	riscy@pyramid.com

May I suggest getting your mailing list software to include a "Reply-to:"
field? Makes following up a little easier.

>*  CPU, peripheral controller and memory
>		Allocated to: caret@pyramid.com
>	of what memory controller is available.  At this stage I am aiming
>	at using the IDT 79R3730.  To this end I am calling IDT to attempt

Just a comment here: having been in the same boat before waiting for IDT
to produce the R372x series of chips, I'd have to say that this chip is
going to be the most critical one in the whole design. Hopefully they
will produce this and make it available as planned...

>*  Keyboard controller / NV-RAM / RTC

I might just try and take this up. You mentioned the 8051 in your
previous mail, but I have a little further info. The original PC and XT
used the 8051, but all machines since have used the 8041. I know that
AMI (the BIOS people) make them pre-programmed with their PC BIOS (ie:
it's an EPROM as well), and think that this would make a nifty device
if we could get hold of it. It would obviously require re-burning the
EPROM, but I think it might be a good way to cut down on a couple of
chips. As for the NV-RAM and RTC, everything I've ever heard points to
Dallas Semi. Unfortunately, I've also heard that they advertise lots of
stuff that they never actually make. I'll look into both of these, and
see what I can come up with.

>*  SCSI bus
>		Allocated to: <no-one>
>	The SCSI bus would probably be done with something like a
>	NEC 53C94 SCSI controller.  Research needs to be done on this
>	and other available SCSI chips.  

Ok, I'm probably one of the people who pushed for this. The other SCSI
chips I've had a look at include: NCR53C7xx series (SMT and _big_),
NCR538x series (pretty dumb) and the WD33C98(?) (very buggy). One
advantage of the '94 is that it's second sourced by Emulex, NCR and
Motorola, so it should be pretty easy to get hold of. You should also
note that there's a 53CF94 which is the same device but does FAST SCSI.
Again, there are '96 chips which do wide SCSI (I think). I've been
unable to get any hard data down here though...

>*  Serial port

Might I suggest a Zilog SCC? I've had good experiences with these,
and they give you the ability to use AppleTalk (physically, anyhow)
at some stage. IMHO, we should have one SCC (or something) chip on
the motherboard itself, and use an ISA card for more "regular"
serial chips. Comments?

>*  Ethernet port
>		Allocated to: <no-one>
>	It has been suggested that we use an Am7990 (Lance) Ethernet

I probably suggested this too, but again - I don't know much about
it. I think there's an alternative in the NSC 8390(?) used on a lot
of PC ethernet cards. As I said, I'm not qualified to give an
opinion here.

>*  Video

Ok, I've accepted this idea <grin>. Anyone know if the 6845 is up
to it? What sort of a range does it have on sync signals?

>*  Diagnostics / monitor code

I'd be very interested in doing this. Obviously (I think), we'd want
some sort of an assembler for this step. See below.

>*  Cross assembler/compiler system

I've looked at this before and I think it's relatively trivial. Getting
GAS to produce R3k binaries is going to be the most important first
step, as we'll need that for the boot/debug ROM.

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 broadley@neurocog.lrdc.pitt.edu Mon Jun 28 09:21:20 1993
Return-Path: <broadley@neurocog.lrdc.pitt.edu>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA24656; Mon, 28 Jun 93 09:21:17 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA11993; Mon, 28 Jun 93 00:21:03 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA18186; Mon, 28 Jun 93 00:20:52 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA11807; Mon, 28 Jun 93 00:20:49 -0700
Message-Id: <9306280720.AA11807@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA20212; Mon, 28 Jun 93 03:20:16 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: framebuffer/tiga
To: riscy@pyramid.com (Mips 3000)
Date: Mon, 28 Jun 1993 03:20:16 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 477       
Status: RO
X-Status: 

Hmm while I wrote my last message two new ones came in discussing it...

Apparently the mips ram to tiga vram doesn't work as I suspected (or as
fast).  Does 6 MB/sec sounds right?

How about tiga vram to tiga vram?

BTW most tiga boards I've seen have ram and dram.

-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok


 
From pat@ucc.gu.uwa.edu.au Mon Jun 28 10:09:15 1993
Return-Path: <pat@ucc.gu.uwa.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA24756; Mon, 28 Jun 93 10:09:10 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18874; Mon, 28 Jun 93 01:09:04 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA20651; Mon, 28 Jun 93 01:08:45 -0700
Received: from mackerel.gu.uwa.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18691; Mon, 28 Jun 93 01:08:33 -0700
Received: by ucc.gu.uwa.edu.au id AA03883
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Mon, 28 Jun 1993 16:00:59 +0800
From: Pat Mackinlay <pat@ucc.gu.uwa.edu.au>
Message-Id: <199306280800.AA03883@ucc.gu.uwa.edu.au>
Subject: SIMM sockets...
To: riscy@pyramid.com
Date: Mon, 28 Jun 1993 16:00:55 +0800 (WST)
X-Mailer: ELM [version 2.4 PL11]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 739       
Status: RO
X-Status: 


Neil, are you still planning on using 32 SIMM sockets? I've been looking,
and I just can't see how you plan to fit that many on the board if you
plan to do an ISA bus as well. 32 sounds a little excessive in any case.
I think we might do better to think about 8, possibly 16. More than 4
sockets is going to mean external memory drivers anyhow, so there's no
real difference between 8 and 16 apart from board space. Perhaps we can
allow 16M SIMMS to be used? With 8 x 16M SIMMS, we get the same 128M
maximum, perfectly reasonable from my point of view <grin>.

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 tor@tss.no Mon Jun 28 10:09:19 1993
Return-Path: <tor@tss.no>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA24757; Mon, 28 Jun 93 10:09:16 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18883; Mon, 28 Jun 93 01:09:08 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA20654; Mon, 28 Jun 93 01:08:55 -0700
Received: from benoni.Uit.No 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18861; Mon, 28 Jun 93 01:08:52 -0700
Received: from benoni by ppenoni.uit.no with SMTP (PP) 
          id <19523-0@ppenoni.uit.no>; Mon, 28 Jun 1993 10:08:42 +0000
Received: from unas.tss.no 
          by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) 
          id AAbenoni19519; Mon, 28 Jun 1993 10:08:40 +0200
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA29682;
          Mon, 28 Jun 93 10:03:07 +0200
Message-Id: <9306280803.AA29682@unas.tss.no>
From: tor@tss.no (Tor Arntsen)
Date: Mon, 28 Jun 1993 10:03:06 +0200
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: riscy@pyramid.com
Subject: Re: Things ...
Status: RO
X-Status: 

>> Rather more personal preference than anything else: Don't you just _love_ 
>> the idea of the X server running on its own CPU? It'd be the equivalent of 
>> having your own X terminal on board <grin>. No, it probably won't compete 
>> for speed with a well-designed framebuffer, but I think it's a very elegant 
>> solution.

Can't say I love it actually.. The Tandberg TDV 6230 runs an X-server
on the 34010 in 1024x768x1 (or x4), and it's slower than a 486+et4000 for
almost anything.  The only thing that is slower on the PC is scrolling.
The TDV 6230 is certainly much slower than a 486 + S3.
Of course, the X-response on the PC gets real bad when compiling the
kernel at the same time! :-)

>The 34010 will be around half the speed at doing bitblt's than the r3k;
>the 34k can probably do other things faster (lines, circles) but they
>don't matter.  As Pat says though, the 34k will take the load off the
>r3k.


Tor

 
From berge@sierra.nl Mon Jun 28 11:27:05 1993
Return-Path: <berge@sierra.nl>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA24987; Mon, 28 Jun 93 11:27:00 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA01314; Mon, 28 Jun 93 02:26:52 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02951; Mon, 28 Jun 93 02:26:35 -0700
Received: from gatekeeper.sierra.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA01306; Mon, 28 Jun 93 02:26:30 -0700
Received: from quint.sierra.nl by gatekeeper.sierra.nl (4.1/2.00)
    id AA10302; Mon, 28 Jun 93 11:25:09 +0200
Date: Mon, 28 Jun 93 11:25:09 +0200
From: berge@sierra.nl (Wim van den Berge)
Message-Id: <9306280925.AA10302@gatekeeper.sierra.nl>
To: riscy@pyramid.com
Subject: help
Status: RO
X-Status: 

help

 
From hodgen@informatik.uni-koblenz.de Mon Jun 28 11:47:35 1993
Return-Path: <hodgen@informatik.uni-koblenz.de>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25019; Mon, 28 Jun 93 11:47:14 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04128; Mon, 28 Jun 93 02:47:05 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA05190; Mon, 28 Jun 93 02:46:53 -0700
Received: from mailhost.uni-koblenz.de 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04120; Mon, 28 Jun 93 02:46:29 -0700
From: hodgen@informatik.uni-koblenz.de
Received: from ozzy by uniko.uni-koblenz.de with smtp
	(Smail3.1.28.1) id m0oAFmg-0001pGC; Mon, 28 Jun 93 11:45 MDT
Message-Id: <m0oAFmg-0001pGC@uniko.uni-koblenz.de>
Received: by ozzy (4.1/KO-2.0)
	id AA22025; Mon, 28 Jun 93 11:16:19 +0200
Subject: My 2 cents worth
To: riscy@pyramid.com
Date: Mon, 28 Jun 93 11:16:18 MET DST
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 


I've been following the discussion with great interest and feel it is now time
for me to say something.

a) I want an FPU. For me the 3051 is uninteresting. I do lots of raytracing/
   graphics work and am mostly interested in getting my sticky paws on a
   MIPS FPU to use at home.

b) Floppy MUST be available. Whether on the motherboard or using an ISA card 
   is irrelevant. Floppys (DOS format) are *the* standard way to get data
   from one machine to another. How many machines do you know that can't
   read DOS diskettes?

c) Sound must be available. Either stereo DAC's on board (at least 16kHz 8bit)
   or a PC soundcard per ISA (a Gravis Ultrasound for example).	

d) A parallel port for the printer, either ISA or on the motherboard, is
   a must. I'm not going to buy a new printer (with a serial port) just to
   run of this board! And then have it go slower!

e) The video solution being dicussed isn't going to be very fast. There's
   no point penny pinching to keep under some arbitrary limit and get a
   great board with X response worse than a 486+et4000. I'm prepared to
   pay for snappy windows and I think others are too.

Before this project started I was saving for a Pentium board. Why? 'Cos it's
faster than my 486 and I can take all my ISA boards out and plug them straight
into the new one. Now I'm saving to buy one of your boards IF IT'S FAST
ENOUGH. If the X performance isn't at least as good as S3 you can forget it.
I am willing to pay $1000 to $1200 for this board, IF IT'S GOOD ENOUGH. Please
don't save so much money making the board "cheap" that no-one wants it anymore.

Keep up the good work Guys!

-- 
Wayne Hodgen  | hodgen@infko.uni-koblenz.de | Opinions (c) Me 1991   | Intel SX
Uni Koblenz,  | (..!unido!infko!hodgen)     | Keeper of the Scrolls, |  Just
Rheinau 3-4,  | Voice: +49 261 9119-645     | Defender of the Net,   |   say
5400 Koblenz. | Fax:   +49 261 9119-499     | His name is "root".    |    NO!!!

 
From broadley@neurocog.lrdc.pitt.edu Mon Jun 28 11:58:44 1993
Return-Path: <broadley@neurocog.lrdc.pitt.edu>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25032; Mon, 28 Jun 93 11:58:38 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05733; Mon, 28 Jun 93 02:58:26 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06403; Mon, 28 Jun 93 02:58:19 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05725; Mon, 28 Jun 93 02:58:18 -0700
Message-Id: <9306280958.AA05725@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA20748; Mon, 28 Jun 93 05:57:46 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Post to comp.arch?
To: riscy@pyramid.com (Mips 3000)
Date: Mon, 28 Jun 1993 05:57:46 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1094      
Status: RO
X-Status: 

I was thinging of posting a "best cpu for under $300" to comp.arch
to see what they say outlining our needs:
	cheap in quantity	
	easy of integration
	nice price/performance

And mentioning they riscy mailing list, I think we have reached a small
percentage of the people that would be interested in the design/purchase
of a mips3000 motherboard to run a free unix.

Things might change alot of we had more people.  

I was going to just post but figured I'd ask the list (not to mention
the overhead for Neil to subscribe.)

I just wasn't sure how much distance I should put between the mailing list/
project and the post.

Would be kinda cool for comp.arch to pick it as a pet project.

Kinda of like the Usenet Serial Card II which I have and am very 
happy with.  It came out of a unfullfilled need for a good 4 port
16550 based card with source code for the card and it's PAL's.

-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok


 
From broadley@neurocog.lrdc.pitt.edu Mon Jun 28 12:29:32 1993
Return-Path: <broadley@neurocog.lrdc.pitt.edu>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25068; Mon, 28 Jun 93 12:29:29 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09784; Mon, 28 Jun 93 03:29:24 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA09072; Mon, 28 Jun 93 03:29:05 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09759; Mon, 28 Jun 93 03:29:03 -0700
Message-Id: <9306281029.AA09759@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA20804; Mon, 28 Jun 93 06:28:32 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Proposed to comp.arch
To: riscy@pyramid.com (Mips 3000)
Date: Mon, 28 Jun 1993 06:28:32 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1451      
Status: RO
X-Status: 

I was thinking of posting this with 2 goals: Explore any other options for
cpu, and get more people interested in design, and purchase of the board.
------------------------------------------------------------------------
Subject: Best cpu under $300

I'm looking for the best cpu to put in a motherboard to be designed for a 
small quantity production run (say between 25-100) to run a free unix port.  

Mandatory considerations: 
   Maximum to memory cpu speed 40 Mhz (for ease of design)
   Must run gcc (for easy of porting a free unix).
   Around $300 or less in quantity of 25-100  (going for a < $700 motherboard)

How do I define best?  
	Maximizing speed (specint, specfp) 
	minimizing cost/complexity of the implementation.  
	Cleaness of design/architecture.
	Ease of programming.

Optional floating point would be great for those who can't afford it.
 
So this probably rules out any Mips 4000, Alpha, Pentium chips on cost alone.

I've heard that the i860 and i960 are tough to program, and I don't like the 
design of the 486.

Post or email.
-----------------------------------------------------------------------
Optionally:

If you interested in the design of the motherboard send a subscribe to 
riscy-request@pyramid.com

-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok


 
From tor@tss.no Mon Jun 28 12:32:06 1993
Return-Path: <tor@tss.no>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25077; Mon, 28 Jun 93 12:31:58 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09849; Mon, 28 Jun 93 03:31:51 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA09116; Mon, 28 Jun 93 03:31:44 -0700
Received: from benoni.Uit.No 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09841; Mon, 28 Jun 93 03:31:42 -0700
Received: from benoni by ppenoni.uit.no with SMTP (PP) 
          id <20400-0@ppenoni.uit.no>; Mon, 28 Jun 1993 12:31:38 +0000
Received: from unas.tss.no 
          by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) 
          id AAbenoni20396; Mon, 28 Jun 1993 12:31:36 +0200
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA00338;
          Mon, 28 Jun 93 12:26:03 +0200
Message-Id: <9306281026.AA00338@unas.tss.no>
From: tor@tss.no (Tor Arntsen)
Date: Mon, 28 Jun 1993 12:26:01 +0200
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: riscy@pyramid.com
Subject: Re: Things ...
Status: RO
X-Status: 

>> Rather more personal preference than anything else: Don't you just _love_ 
>> the idea of the X server running on its own CPU? It'd be the equivalent of 
>> having your own X terminal on board <grin>. No, it probably won't compete 
>> for speed with a well-designed framebuffer, but I think it's a very elegant 
>> solution.

Can't say I love it actually.. The Tandberg TDV 6230 runs an X-server
on the 34010 in 1024x768x1 (or x4), and it's slower than a 486+et4000 for
almost anything.  The only thing that is slower on the PC is scrolling.
The TDV 6230 is certainly much slower than a 486 + S3.
Of course, the X-response on the PC gets real bad when compiling the
kernel at the same time! :-)

>The 34010 will be around half the speed at doing bitblt's than the r3k;
>the 34k can probably do other things faster (lines, circles) but they
>don't matter.  As Pat says though, the 34k will take the load off the
>r3k.

Tor



 
From SMACKINLA@cc.curtin.edu.au Mon Jun 28 13:38:44 1993
Return-Path: <SMACKINLA@cc.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25240; Mon, 28 Jun 93 13:38:37 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20484; Mon, 28 Jun 93 04:38:30 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16447; Mon, 28 Jun 93 04:37:46 -0700
Received: from cc.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20435; Mon, 28 Jun 93 04:37:40 -0700
Received: from cc.curtin.edu.au by cc.curtin.edu.au (PMDF #3256 ) id
 <01GZX7Y264G6FUMLVJ@cc.curtin.edu.au>; Mon, 28 Jun 1993 19:36:44 +0800
Date: 28 Jun 1993 19:36:44 +0800
From: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Subject: Re: Things ...
To: tor@tss.no
Cc: riscy@pyramid.com
Message-Id: <01GZX7Y26E3CFUMLVJ@cc.curtin.edu.au>
X-Envelope-To: riscy@pyramid.com
X-Vms-To: IN%"tor@tss.no"
X-Vms-Cc: R3KPC,SMACKINLA
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
Status: RO
X-Status: 


(Tor, this message is not specifically targetted at you, I'm just getting 
a little exasperated. Please don't take anything personally.)

>on the 34010 in 1024x768x1 (or x4), and it's slower than a 486+et4000 for
>almost anything.  The only thing that is slower on the PC is scrolling.
>The TDV 6230 is certainly much slower than a 486 + S3.

Am I talking to a brick wall? I _KNOW_ the 34k is slower - I thought 
I made that plain. If you can come up with a design that costs the same 
amount and gives better performance, go right ahead: I'm not hooked on the 
idea of using the 34010.

>Of course, the X-response on the PC gets real bad when compiling the
>kernel at the same time! :-)

I think that this is one small advantage of the "separate processor" 
approach, but not the most important for our particular application. 
Further on this point, I think that people will complain less about 
"graphics performance" when the main CPU is still free to run programs. 
The "two processor" approach should also make the machine more appealing to 
people who want to use the box as a server because users on the console 
will have less impact on the system performance. I suspect that most 
programs would run quite acceptably on the 34k - perhaps not benchmarking 
as fast as a dumb framebuffer solution, but certainly fast enough to be 
useful.

Side note: For those people who do use systems with 34010's, where 
exactly are the performance problems? Do you actually see the chip 
"painting" the screen, or is it just a general sluggishness? I suspect some 
of the performance problems could actually be due to the fact that X 
terminals are usually diskless, and the I/O overhead dominates the actual 
graphics performance. This would not be an issue with a "local" 
implementation.

People: _PLEASE_, if you can come up with a practical alternative for a 
video system (I know you're out there Steve <grin>), speak up now. It 
_would_ be much better to use a dumb framebuffer attached to the CPU, but I 
fear that the extra logic required to generate monitor signals and clock 
the data out of the VRAM at the right speed would be a 

To try and summarize my opinion, I'd just like to say that most programs 
(that I deal with) are not limited by the speed of the X server. Usually, 
the limitations are on the system I/O performance. I think that using a 
separate CPU to do graphics will make our system less complex (ie: cheaper) 
while still providing perfectly acceptable graphics performance. Not only 
that, but it makes the system a bit more "interesting", from a hobbiest's 
perspective (I mean, what's the point of doing it if it's not going to be 
interesting <grin>). If someone comes up with a cheap and simple 
alternative to the 34k solution, I'd be very happy to use it, but so far,
no one has, and the 34k is the best choice in my mind.

As for the guy that said he'd be willing to pay $1200 for the system, I 
can't agree. In my mind, once you get over the US$800 mark, you'll be much 
better off with a fully "commercial" system. As Neil mentioned before: if 
all you want is a faster PC, by all means, go and buy one. I know it looks 
like I'm harping on the point, but the price and complexity of this system 
are the factors which will decide its fate.

Again, I hope we've seen the end of the integer vs FP argument: that can be 
sorted out when the time comes. It's much more important to fill in the 
other parts of the system right now. Please don't bring it up again.

[...At the risk of repeating myself (again): If you're going to "knock" the 
34k solution, please make sure you have a viable alternative...]

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 wolff@dutecai.et.tudelft.nl Tue Jun 22 17:41:22 1993
Return-Path: <wolff@dutecai.et.tudelft.nl>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA03653; Tue, 22 Jun 93 17:41:18 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA24610; Tue, 22 Jun 93 08:43:44 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02800; Tue, 22 Jun 93 08:40:48 -0700
Received: from liberator.et.tudelft.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA24597; Tue, 22 Jun 93 08:43:37 -0700
Received: by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA03031; Tue, 22 Jun 93 17:39:15 +0200
Date: Tue, 22 Jun 93 17:39:15 +0200
From: wolff@dutecai.et.tudelft.nl (Rogier Wolff)
Message-Id: <9306221539.AA03031@liberator.et.tudelft.nl>
To: riscy@pyramid.com
Subject: Boot rom  and other useless junk.
Status: RO
X-Status: 



Hi everyone,

After reading the "preliminary specs" I have the following suggestions:

>* Boot EPROM
>        Because of the 3730, we can get away with just one EPROM.
>        Maybe two just for kicks.  Access to this is slow, so if
>        speed were are problem, then code could be copied to RAM.

I'd suggest using the approach that we've used for a design here. What
we do is we have the x86 CPU control the reset line of the "bigger" cpu.
The x86 also has access to (at least some of) the RAM of the R3000.
This will enable the x86 to place the boot code into the RAM before
releasing the RESET of the R3000.

Instant saving: 1 eprom per board, Development costs (reburning EPROMS all 
the time....)

>*  Keyboard controller
>        This should certainly handle IBM compatible style keyboards.
>        The only way I know to do this is to use the 8051(?) micro-
>        controller to drive the keyboard exactly the same way as
>        every mother-board I've seen does.  This circuit should
>        connect easily to the 8-bit bus of the 3730.

See below, near "serial port".

>*  Non-Volatile-RAM and Real-Time-Clock
>        This should be looked into.  The clock is almost a requirement
>        but the NV-RAM could be replaced with the feature selector.

Why do you need a NV RAM? Why do you  need a RTC? You do need an
interrupt every 10ms. You can initialize from the RTC on the PC.
(ok. ok. Those are crummy, but you can live with it....)

>*  Serial port
>        Because of the ISA bus, serial is always possible.  It might
>        be a good idea, if just for debugging to have some serial
>        ports on the mother-board.  If this is the case, they should
>        be at least as good as 16550's.

My suggestion is to have a shared memory interface that looks like a 
serial line:

        struct combuf {
                int hd,tl;
                char buf[BUFSIZE];
                }
        
        out_char (struct combuf *cb,ch)
        {
        int hd = cb->hd;
        cb->buf[hd] = ch;
        inc (hd);
        while (hd == cb->tl)
                sleep_a_little_while ();
        cb->hd = hd;
        }

        in_char (struct combuf *cb)
        {
        int tl = cb->tl;
        int ch;

        while (tl == cb->head)
                sleep_a_little_while ();
        ch = cb->buf[tl];
        inc (tl);
        cb->tl = tl;
        }
        

Both sides (on the PC and on the R3000) use this interface (with different
cb pointers). To both sides this looks more or less like a serial stream 
of data.

To make this work in an multitasking environment it would be nice
to have an interrupt too.

                                Roger.


 
From af4@ukc.ac.uk Mon Jun 28 15:09:42 1993
Return-Path: <af4@ukc.ac.uk>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25614; Mon, 28 Jun 93 15:09:39 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05228; Mon, 28 Jun 93 06:09:29 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA26212; Mon, 28 Jun 93 06:09:22 -0700
Received: from mercury.ukc.ac.uk 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05220; Mon, 28 Jun 93 06:09:20 -0700
Message-Id: <9306281309.AA05220@gossip.pyramid.com>
Received: from eagle by mercury.ukc.ac.uk   with UKC POP3+  id aa23470;
          28 Jun 93 14:08 BST
Date: Mon, 28 Jun 93 13:56:19 +0100
From: af4@ukc.ac.uk
To: riscy@pyramid.com
Subject: Things & Stuff
Status: RO
X-Status: 


There has been lots of noise about 34010 versus dumb frame buffers. Whilst I'm
in favour of the 34010 solution, I though I'd mention the 34076 Video Systems
Controller. The 34076 generates all the control and timing signals for a
raster scan video system, you just add a blob of VRAM, and a DAC (Inmos make
some nice ones, BTW), and Bob's yer aunty - instant dumb frame buffer.

While I'm at it, don't go leaving the parallel printer port off of the
motherboard. The cost of the necessary TTL octal latch is peanuts, so please
do your penny pinching elsewhere!

 
From broadley@neurocog.lrdc.pitt.edu Mon Jun 28 15:55:06 1993
Return-Path: <broadley@neurocog.lrdc.pitt.edu>
Received: from liberator.et.tudelft.nl by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25792; Mon, 28 Jun 93 15:55:03 +0200
Received: from neurocog.lrdc.pitt.edu by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA05586; Mon, 28 Jun 93 15:54:58 +0200
Message-Id: <9306281354.AA05586@liberator.et.tudelft.nl>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA21329; Mon, 28 Jun 93 09:54:27 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Re: Proposed to comp.arch
To: wolff@dutecai.et.tudelft.nl (Rogier Wolff)
Date: Mon, 28 Jun 1993 09:54:27 -0500 (EDT)
In-Reply-To: <9306281332.AA05485@liberator.et.tudelft.nl> from "Rogier Wolff" at Jun 28, 93 03:32:11 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 800       
Status: RO
X-Status: 

> 
> The pipeline in software (mul a,b,c -> result from two multiplies back in
> c) is an '860 "feature".
Ahh I guess I got confused...

> 
> The '960 is inattractive for a Unix implementation. In that you are right.
> 
Well thats definitely the target, I change the wording thanks.

> The different versions of the '960 have either a MMU, FP or a Super Scalar
> version. No two of these go together (I think... I use the Super Scalar
> version: the I960 CA). For Unix you need all three. (The military
> is able to get two of them.....)
> 
I'd guess FP and Superscaler.  No need for MMU.


-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok


 
From Steven.D.Ligett@Dartmouth.EDU Mon Jun 28 16:16:41 1993
Return-Path: <Steven.D.Ligett@Dartmouth.EDU>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25858; Mon, 28 Jun 93 16:16:33 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA10605; Mon, 28 Jun 93 07:16:28 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA29163; Mon, 28 Jun 93 07:16:16 -0700
Received: from dartvax.dartmouth.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA10441; Mon, 28 Jun 93 07:16:06 -0700
Received: from prancer.dartmouth.edu by dartvax.dartmouth.edu (5.65+D5/4.5HUB)
	id AA26383; Mon, 28 Jun 93 10:14:25 -0400
Message-Id: <5285326@prancer.Dartmouth.EDU>
Date: 28 Jun 93 10:14:18 EDT
From: Steven.D.Ligett@Dartmouth.EDU (Steven D. Ligett)
Subject: Re: Things & Stuff
To: SMACKINLA@cc.curtin.edu.au, jcallen@world.std.com
Cc: riscy@pyramid.com
Status: RO
X-Status: 

--- Pat Mackinlay wrote:
Ok, this is what I was looking for. Any ideas on pricing? I hope TI still
makes the thing.
--- end of quoted material ---
HEY!  oh never mind.  no one listens.

the 34076 plus the nsc 1882 to generate the syncs is what I SAID.

jeez.

 
From caret@pyramid.com Tue Jun 22 05:49:16 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA00241; Tue, 22 Jun 93 05:49:13 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18736; Mon, 21 Jun 93 20:52:02 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15731; Mon, 21 Jun 93 20:49:02 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306220349.AA15731@sword.eng.pyramid.com>
Subject: MIPS R3000 mailing list
To: riscy@pyramid.com
Date: Mon, 21 Jun 93 20:49:02 PDT
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

Welcome to the MIPS R3000 board project mailing list.

This mailing list has been formed for the discussion of the design of
the MIPS R3000 board that has been under recent discussion in
comp.os.linux.  You have been added automatically to this list because
you expressed some interest in helping design this device.

Requests to be added or deleted from this list should be directed to
'riscy-request@pyramid.com'.  Mail sent to 'riscy@pyramid.com' will
be forwarded to all other members of the list.

I intended this list to hardware issues and software issues relating
directly to the board.  Discussion about the porting of various
operating systems should be directed to another as yet undefined
mailing list.

-- 
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 mackinla@cs.curtin.edu.au Tue Jun 22 17:35:52 1993
Return-Path: <mackinla@cs.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA03640; Tue, 22 Jun 93 17:35:47 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23874; Tue, 22 Jun 93 08:37:19 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA01794; Tue, 22 Jun 93 08:34:22 -0700
Received: from marsh.cs.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23860; Tue, 22 Jun 93 08:37:09 -0700
Received: from vincent.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA11020
  (5.67a/IDA-1.4.4 for <riscy@pyramid.com>); Tue, 22 Jun 1993 23:32:50 +0800
Received: by vincent.cs.curtin.edu.au id AA14659
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Tue, 22 Jun 1993 23:32:45 +0800
From: Patrick Mackinlay <mackinla@cs.curtin.edu.au>
Message-Id: <199306221532.AA14659@vincent.cs.curtin.edu.au>
Subject: Re: MIPS R3000 tasks available; volunteers?
To: riscy@pyramid.com
Date: Tue, 22 Jun 1993 23:32:44 +0800 (WST)
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 3631      
Status: RO
X-Status: 


[...Sorry to those who might have seen this twice. I didn't see it
come back to my site, so I'm mailing it again...]

>Most correspondence should be directed at the mailing list:
>
>	riscy@pyramid.com

May I suggest getting your mailing list software to include a "Reply-to:"
field? Makes following up a little easier.

>*  CPU, peripheral controller and memory
>		Allocated to: caret@pyramid.com
>	of what memory controller is available.  At this stage I am aiming
>	at using the IDT 79R3730.  To this end I am calling IDT to attempt

Just a comment here: having been in the same boat before waiting for IDT
to produce the R372x series of chips, I'd have to say that this chip is
going to be the most critical one in the whole design. Hopefully they
will produce this and make it available as planned...

>*  Keyboard controller / NV-RAM / RTC

I might just try and take this up. You mentioned the 8051 in your
previous mail, but I have a little further info. The original PC and XT
used the 8051, but all machines since have used the 8041. I know that
AMI (the BIOS people) make them pre-programmed with their PC BIOS (ie:
it's an EPROM as well), and think that this would make a nifty device
if we could get hold of it. It would obviously require re-burning the
EPROM, but I think it might be a good way to cut down on a couple of
chips. As for the NV-RAM and RTC, everything I've ever heard points to
Dallas Semi. Unfortunately, I've also heard that they advertise lots of
stuff that they never actually make. I'll look into both of these, and
see what I can come up with.

>*  SCSI bus
>		Allocated to: <no-one>
>	The SCSI bus would probably be done with something like a
>	NEC 53C94 SCSI controller.  Research needs to be done on this
>	and other available SCSI chips.  

Ok, I'm probably one of the people who pushed for this. The other SCSI
chips I've had a look at include: NCR53C7xx series (SMT and _big_),
NCR538x series (pretty dumb) and the WD33C98(?) (very buggy). One
advantage of the '94 is that it's second sourced by Emulex, NCR and
Motorola, so it should be pretty easy to get hold of. You should also
note that there's a 53CF94 which is the same device but does FAST SCSI.
Again, there are '96 chips which do wide SCSI (I think). I've been
unable to get any hard data down here though...

>*  Serial port

Might I suggest a Zilog SCC? I've had good experiences with these,
and they give you the ability to use AppleTalk (physically, anyhow)
at some stage. IMHO, we should have one SCC (or something) chip on
the motherboard itself, and use an ISA card for more "regular"
serial chips. Comments?

>*  Ethernet port
>		Allocated to: <no-one>
>	It has been suggested that we use an Am7990 (Lance) Ethernet

I probably suggested this too, but again - I don't know much about
it. I think there's an alternative in the NSC 8390(?) used on a lot
of PC ethernet cards. As I said, I'm not qualified to give an
opinion here.

>*  Video

Ok, I've accepted this idea <grin>. Anyone know if the 6845 is up
to it? What sort of a range does it have on sync signals?

>*  Diagnostics / monitor code

I'd be very interested in doing this. Obviously (I think), we'd want
some sort of an assembler for this step. See below.

>*  Cross assembler/compiler system

I've looked at this before and I think it's relatively trivial. Getting
GAS to produce R3k binaries is going to be the most important first
step, as we'll need that for the boot/debug ROM.

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 broadley@neurocog.lrdc.pitt.edu Mon Jun 28 09:21:20 1993
Return-Path: <broadley@neurocog.lrdc.pitt.edu>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA24656; Mon, 28 Jun 93 09:21:17 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA11993; Mon, 28 Jun 93 00:21:03 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA18186; Mon, 28 Jun 93 00:20:52 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA11807; Mon, 28 Jun 93 00:20:49 -0700
Message-Id: <9306280720.AA11807@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA20212; Mon, 28 Jun 93 03:20:16 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: framebuffer/tiga
To: riscy@pyramid.com (Mips 3000)
Date: Mon, 28 Jun 1993 03:20:16 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 477       
Status: RO
X-Status: 

Hmm while I wrote my last message two new ones came in discussing it...

Apparently the mips ram to tiga vram doesn't work as I suspected (or as
fast).  Does 6 MB/sec sounds right?

How about tiga vram to tiga vram?

BTW most tiga boards I've seen have ram and dram.

-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok


 
From pat@ucc.gu.uwa.edu.au Mon Jun 28 10:09:15 1993
Return-Path: <pat@ucc.gu.uwa.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA24756; Mon, 28 Jun 93 10:09:10 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18874; Mon, 28 Jun 93 01:09:04 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA20651; Mon, 28 Jun 93 01:08:45 -0700
Received: from mackerel.gu.uwa.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18691; Mon, 28 Jun 93 01:08:33 -0700
Received: by ucc.gu.uwa.edu.au id AA03883
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Mon, 28 Jun 1993 16:00:59 +0800
From: Pat Mackinlay <pat@ucc.gu.uwa.edu.au>
Message-Id: <199306280800.AA03883@ucc.gu.uwa.edu.au>
Subject: SIMM sockets...
To: riscy@pyramid.com
Date: Mon, 28 Jun 1993 16:00:55 +0800 (WST)
X-Mailer: ELM [version 2.4 PL11]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 739       
Status: RO
X-Status: 


Neil, are you still planning on using 32 SIMM sockets? I've been looking,
and I just can't see how you plan to fit that many on the board if you
plan to do an ISA bus as well. 32 sounds a little excessive in any case.
I think we might do better to think about 8, possibly 16. More than 4
sockets is going to mean external memory drivers anyhow, so there's no
real difference between 8 and 16 apart from board space. Perhaps we can
allow 16M SIMMS to be used? With 8 x 16M SIMMS, we get the same 128M
maximum, perfectly reasonable from my point of view <grin>.

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 tor@tss.no Mon Jun 28 10:09:19 1993
Return-Path: <tor@tss.no>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA24757; Mon, 28 Jun 93 10:09:16 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18883; Mon, 28 Jun 93 01:09:08 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA20654; Mon, 28 Jun 93 01:08:55 -0700
Received: from benoni.Uit.No 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18861; Mon, 28 Jun 93 01:08:52 -0700
Received: from benoni by ppenoni.uit.no with SMTP (PP) 
          id <19523-0@ppenoni.uit.no>; Mon, 28 Jun 1993 10:08:42 +0000
Received: from unas.tss.no 
          by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) 
          id AAbenoni19519; Mon, 28 Jun 1993 10:08:40 +0200
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA29682;
          Mon, 28 Jun 93 10:03:07 +0200
Message-Id: <9306280803.AA29682@unas.tss.no>
From: tor@tss.no (Tor Arntsen)
Date: Mon, 28 Jun 1993 10:03:06 +0200
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: riscy@pyramid.com
Subject: Re: Things ...
Status: RO
X-Status: 

>> Rather more personal preference than anything else: Don't you just _love_ 
>> the idea of the X server running on its own CPU? It'd be the equivalent of 
>> having your own X terminal on board <grin>. No, it probably won't compete 
>> for speed with a well-designed framebuffer, but I think it's a very elegant 
>> solution.

Can't say I love it actually.. The Tandberg TDV 6230 runs an X-server
on the 34010 in 1024x768x1 (or x4), and it's slower than a 486+et4000 for
almost anything.  The only thing that is slower on the PC is scrolling.
The TDV 6230 is certainly much slower than a 486 + S3.
Of course, the X-response on the PC gets real bad when compiling the
kernel at the same time! :-)

>The 34010 will be around half the speed at doing bitblt's than the r3k;
>the 34k can probably do other things faster (lines, circles) but they
>don't matter.  As Pat says though, the 34k will take the load off the
>r3k.


Tor

 
From berge@sierra.nl Mon Jun 28 11:27:05 1993
Return-Path: <berge@sierra.nl>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA24987; Mon, 28 Jun 93 11:27:00 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA01314; Mon, 28 Jun 93 02:26:52 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02951; Mon, 28 Jun 93 02:26:35 -0700
Received: from gatekeeper.sierra.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA01306; Mon, 28 Jun 93 02:26:30 -0700
Received: from quint.sierra.nl by gatekeeper.sierra.nl (4.1/2.00)
    id AA10302; Mon, 28 Jun 93 11:25:09 +0200
Date: Mon, 28 Jun 93 11:25:09 +0200
From: berge@sierra.nl (Wim van den Berge)
Message-Id: <9306280925.AA10302@gatekeeper.sierra.nl>
To: riscy@pyramid.com
Subject: help
Status: RO
X-Status: 

help

 
From hodgen@informatik.uni-koblenz.de Mon Jun 28 11:47:35 1993
Return-Path: <hodgen@informatik.uni-koblenz.de>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25019; Mon, 28 Jun 93 11:47:14 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04128; Mon, 28 Jun 93 02:47:05 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA05190; Mon, 28 Jun 93 02:46:53 -0700
Received: from mailhost.uni-koblenz.de 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04120; Mon, 28 Jun 93 02:46:29 -0700
From: hodgen@informatik.uni-koblenz.de
Received: from ozzy by uniko.uni-koblenz.de with smtp
	(Smail3.1.28.1) id m0oAFmg-0001pGC; Mon, 28 Jun 93 11:45 MDT
Message-Id: <m0oAFmg-0001pGC@uniko.uni-koblenz.de>
Received: by ozzy (4.1/KO-2.0)
	id AA22025; Mon, 28 Jun 93 11:16:19 +0200
Subject: My 2 cents worth
To: riscy@pyramid.com
Date: Mon, 28 Jun 93 11:16:18 MET DST
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 


I've been following the discussion with great interest and feel it is now time
for me to say something.

a) I want an FPU. For me the 3051 is uninteresting. I do lots of raytracing/
   graphics work and am mostly interested in getting my sticky paws on a
   MIPS FPU to use at home.

b) Floppy MUST be available. Whether on the motherboard or using an ISA card 
   is irrelevant. Floppys (DOS format) are *the* standard way to get data
   from one machine to another. How many machines do you know that can't
   read DOS diskettes?

c) Sound must be available. Either stereo DAC's on board (at least 16kHz 8bit)
   or a PC soundcard per ISA (a Gravis Ultrasound for example).	

d) A parallel port for the printer, either ISA or on the motherboard, is
   a must. I'm not going to buy a new printer (with a serial port) just to
   run of this board! And then have it go slower!

e) The video solution being dicussed isn't going to be very fast. There's
   no point penny pinching to keep under some arbitrary limit and get a
   great board with X response worse than a 486+et4000. I'm prepared to
   pay for snappy windows and I think others are too.

Before this project started I was saving for a Pentium board. Why? 'Cos it's
faster than my 486 and I can take all my ISA boards out and plug them straight
into the new one. Now I'm saving to buy one of your boards IF IT'S FAST
ENOUGH. If the X performance isn't at least as good as S3 you can forget it.
I am willing to pay $1000 to $1200 for this board, IF IT'S GOOD ENOUGH. Please
don't save so much money making the board "cheap" that no-one wants it anymore.

Keep up the good work Guys!

-- 
Wayne Hodgen  | hodgen@infko.uni-koblenz.de | Opinions (c) Me 1991   | Intel SX
Uni Koblenz,  | (..!unido!infko!hodgen)     | Keeper of the Scrolls, |  Just
Rheinau 3-4,  | Voice: +49 261 9119-645     | Defender of the Net,   |   say
5400 Koblenz. | Fax:   +49 261 9119-499     | His name is "root".    |    NO!!!

 
From broadley@neurocog.lrdc.pitt.edu Mon Jun 28 11:58:44 1993
Return-Path: <broadley@neurocog.lrdc.pitt.edu>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25032; Mon, 28 Jun 93 11:58:38 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05733; Mon, 28 Jun 93 02:58:26 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06403; Mon, 28 Jun 93 02:58:19 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05725; Mon, 28 Jun 93 02:58:18 -0700
Message-Id: <9306280958.AA05725@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA20748; Mon, 28 Jun 93 05:57:46 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Post to comp.arch?
To: riscy@pyramid.com (Mips 3000)
Date: Mon, 28 Jun 1993 05:57:46 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1094      
Status: RO
X-Status: 

I was thinging of posting a "best cpu for under $300" to comp.arch
to see what they say outlining our needs:
	cheap in quantity	
	easy of integration
	nice price/performance

And mentioning they riscy mailing list, I think we have reached a small
percentage of the people that would be interested in the design/purchase
of a mips3000 motherboard to run a free unix.

Things might change alot of we had more people.  

I was going to just post but figured I'd ask the list (not to mention
the overhead for Neil to subscribe.)

I just wasn't sure how much distance I should put between the mailing list/
project and the post.

Would be kinda cool for comp.arch to pick it as a pet project.

Kinda of like the Usenet Serial Card II which I have and am very 
happy with.  It came out of a unfullfilled need for a good 4 port
16550 based card with source code for the card and it's PAL's.

-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok


 
From broadley@neurocog.lrdc.pitt.edu Mon Jun 28 12:29:32 1993
Return-Path: <broadley@neurocog.lrdc.pitt.edu>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25068; Mon, 28 Jun 93 12:29:29 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09784; Mon, 28 Jun 93 03:29:24 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA09072; Mon, 28 Jun 93 03:29:05 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09759; Mon, 28 Jun 93 03:29:03 -0700
Message-Id: <9306281029.AA09759@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA20804; Mon, 28 Jun 93 06:28:32 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Proposed to comp.arch
To: riscy@pyramid.com (Mips 3000)
Date: Mon, 28 Jun 1993 06:28:32 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1451      
Status: RO
X-Status: 

I was thinking of posting this with 2 goals: Explore any other options for
cpu, and get more people interested in design, and purchase of the board.
------------------------------------------------------------------------
Subject: Best cpu under $300

I'm looking for the best cpu to put in a motherboard to be designed for a 
small quantity production run (say between 25-100) to run a free unix port.  

Mandatory considerations: 
   Maximum to memory cpu speed 40 Mhz (for ease of design)
   Must run gcc (for easy of porting a free unix).
   Around $300 or less in quantity of 25-100  (going for a < $700 motherboard)

How do I define best?  
	Maximizing speed (specint, specfp) 
	minimizing cost/complexity of the implementation.  
	Cleaness of design/architecture.
	Ease of programming.

Optional floating point would be great for those who can't afford it.
 
So this probably rules out any Mips 4000, Alpha, Pentium chips on cost alone.

I've heard that the i860 and i960 are tough to program, and I don't like the 
design of the 486.

Post or email.
-----------------------------------------------------------------------
Optionally:

If you interested in the design of the motherboard send a subscribe to 
riscy-request@pyramid.com

-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok


 
From tor@tss.no Mon Jun 28 12:32:06 1993
Return-Path: <tor@tss.no>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25077; Mon, 28 Jun 93 12:31:58 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09849; Mon, 28 Jun 93 03:31:51 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA09116; Mon, 28 Jun 93 03:31:44 -0700
Received: from benoni.Uit.No 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09841; Mon, 28 Jun 93 03:31:42 -0700
Received: from benoni by ppenoni.uit.no with SMTP (PP) 
          id <20400-0@ppenoni.uit.no>; Mon, 28 Jun 1993 12:31:38 +0000
Received: from unas.tss.no 
          by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) 
          id AAbenoni20396; Mon, 28 Jun 1993 12:31:36 +0200
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA00338;
          Mon, 28 Jun 93 12:26:03 +0200
Message-Id: <9306281026.AA00338@unas.tss.no>
From: tor@tss.no (Tor Arntsen)
Date: Mon, 28 Jun 1993 12:26:01 +0200
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: riscy@pyramid.com
Subject: Re: Things ...
Status: RO
X-Status: 

>> Rather more personal preference than anything else: Don't you just _love_ 
>> the idea of the X server running on its own CPU? It'd be the equivalent of 
>> having your own X terminal on board <grin>. No, it probably won't compete 
>> for speed with a well-designed framebuffer, but I think it's a very elegant 
>> solution.

Can't say I love it actually.. The Tandberg TDV 6230 runs an X-server
on the 34010 in 1024x768x1 (or x4), and it's slower than a 486+et4000 for
almost anything.  The only thing that is slower on the PC is scrolling.
The TDV 6230 is certainly much slower than a 486 + S3.
Of course, the X-response on the PC gets real bad when compiling the
kernel at the same time! :-)

>The 34010 will be around half the speed at doing bitblt's than the r3k;
>the 34k can probably do other things faster (lines, circles) but they
>don't matter.  As Pat says though, the 34k will take the load off the
>r3k.

Tor



 
From tor@tss.no Mon Jun 28 13:33:11 1993
Return-Path: <tor@tss.no>
Received: from liberator.et.tudelft.nl by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25195; Mon, 28 Jun 93 13:33:08 +0200
Received: from benoni.Uit.No by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA05089; Mon, 28 Jun 93 13:33:03 +0200
Received: from benoni by ppenoni.uit.no with SMTP (PP) 
          id <20798-0@ppenoni.uit.no>; Mon, 28 Jun 1993 13:32:53 +0000
Received: from unas.tss.no 
          by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) 
          id AAbenoni20794; Mon, 28 Jun 1993 13:32:51 +0200
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA01034;
          Mon, 28 Jun 93 13:27:18 +0200
Message-Id: <9306281127.AA01034@unas.tss.no>
From: tor@tss.no (Tor Arntsen)
Date: Mon, 28 Jun 1993 13:27:16 +0200
In-Reply-To: wolff@liberator.et.tudelft.nl (Rogier Wolff) "Re: Video subsystem..." (Jun 28, 1:24pm)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: wolff@dutecai.et.tudelft.nl (Rogier Wolff)
Subject: Re: Video subsystem...
Status: RO
X-Status: 

On Jun 28,  1:24pm, Rogier Wolff wrote:
>>  HP X-terms (pa-based I think) are much much
>faster.
>
>Nope. They use Intel 960 processors.....
>
>					Rogier.

Yeah, I've got a couple of mails already correcting me on that point.
I've also got some good advice on how to fix those really *bad* looking
cheap displays..

Thanks,
Tor	(tor@tss.no)



 
From SMACKINLA@cc.curtin.edu.au Mon Jun 28 13:38:44 1993
Return-Path: <SMACKINLA@cc.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25240; Mon, 28 Jun 93 13:38:37 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20484; Mon, 28 Jun 93 04:38:30 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16447; Mon, 28 Jun 93 04:37:46 -0700
Received: from cc.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20435; Mon, 28 Jun 93 04:37:40 -0700
Received: from cc.curtin.edu.au by cc.curtin.edu.au (PMDF #3256 ) id
 <01GZX7Y264G6FUMLVJ@cc.curtin.edu.au>; Mon, 28 Jun 1993 19:36:44 +0800
Date: 28 Jun 1993 19:36:44 +0800
From: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Subject: Re: Things ...
To: tor@tss.no
Cc: riscy@pyramid.com
Message-Id: <01GZX7Y26E3CFUMLVJ@cc.curtin.edu.au>
X-Envelope-To: riscy@pyramid.com
X-Vms-To: IN%"tor@tss.no"
X-Vms-Cc: R3KPC,SMACKINLA
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
Status: RO
X-Status: 


(Tor, this message is not specifically targetted at you, I'm just getting 
a little exasperated. Please don't take anything personally.)

>on the 34010 in 1024x768x1 (or x4), and it's slower than a 486+et4000 for
>almost anything.  The only thing that is slower on the PC is scrolling.
>The TDV 6230 is certainly much slower than a 486 + S3.

Am I talking to a brick wall? I _KNOW_ the 34k is slower - I thought 
I made that plain. If you can come up with a design that costs the same 
amount and gives better performance, go right ahead: I'm not hooked on the 
idea of using the 34010.

>Of course, the X-response on the PC gets real bad when compiling the
>kernel at the same time! :-)

I think that this is one small advantage of the "separate processor" 
approach, but not the most important for our particular application. 
Further on this point, I think that people will complain less about 
"graphics performance" when the main CPU is still free to run programs. 
The "two processor" approach should also make the machine more appealing to 
people who want to use the box as a server because users on the console 
will have less impact on the system performance. I suspect that most 
programs would run quite acceptably on the 34k - perhaps not benchmarking 
as fast as a dumb framebuffer solution, but certainly fast enough to be 
useful.

Side note: For those people who do use systems with 34010's, where 
exactly are the performance problems? Do you actually see the chip 
"painting" the screen, or is it just a general sluggishness? I suspect some 
of the performance problems could actually be due to the fact that X 
terminals are usually diskless, and the I/O overhead dominates the actual 
graphics performance. This would not be an issue with a "local" 
implementation.

People: _PLEASE_, if you can come up with a practical alternative for a 
video system (I know you're out there Steve <grin>), speak up now. It 
_would_ be much better to use a dumb framebuffer attached to the CPU, but I 
fear that the extra logic required to generate monitor signals and clock 
the data out of the VRAM at the right speed would be a 

To try and summarize my opinion, I'd just like to say that most programs 
(that I deal with) are not limited by the speed of the X server. Usually, 
the limitations are on the system I/O performance. I think that using a 
separate CPU to do graphics will make our system less complex (ie: cheaper) 
while still providing perfectly acceptable graphics performance. Not only 
that, but it makes the system a bit more "interesting", from a hobbiest's 
perspective (I mean, what's the point of doing it if it's not going to be 
interesting <grin>). If someone comes up with a cheap and simple 
alternative to the 34k solution, I'd be very happy to use it, but so far,
no one has, and the 34k is the best choice in my mind.

As for the guy that said he'd be willing to pay $1200 for the system, I 
can't agree. In my mind, once you get over the US$800 mark, you'll be much 
better off with a fully "commercial" system. As Neil mentioned before: if 
all you want is a faster PC, by all means, go and buy one. I know it looks 
like I'm harping on the point, but the price and complexity of this system 
are the factors which will decide its fate.

Again, I hope we've seen the end of the integer vs FP argument: that can be 
sorted out when the time comes. It's much more important to fill in the 
other parts of the system right now. Please don't bring it up again.

[...At the risk of repeating myself (again): If you're going to "knock" the 
34k solution, please make sure you have a viable alternative...]

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 wolff@dutecai.et.tudelft.nl Tue Jun 22 17:41:22 1993
Return-Path: <wolff@dutecai.et.tudelft.nl>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA03653; Tue, 22 Jun 93 17:41:18 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA24610; Tue, 22 Jun 93 08:43:44 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02800; Tue, 22 Jun 93 08:40:48 -0700
Received: from liberator.et.tudelft.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA24597; Tue, 22 Jun 93 08:43:37 -0700
Received: by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA03031; Tue, 22 Jun 93 17:39:15 +0200
Date: Tue, 22 Jun 93 17:39:15 +0200
From: wolff@dutecai.et.tudelft.nl (Rogier Wolff)
Message-Id: <9306221539.AA03031@liberator.et.tudelft.nl>
To: riscy@pyramid.com
Subject: Boot rom  and other useless junk.
Status: RO
X-Status: 



Hi everyone,

After reading the "preliminary specs" I have the following suggestions:

>* Boot EPROM
>        Because of the 3730, we can get away with just one EPROM.
>        Maybe two just for kicks.  Access to this is slow, so if
>        speed were are problem, then code could be copied to RAM.

I'd suggest using the approach that we've used for a design here. What
we do is we have the x86 CPU control the reset line of the "bigger" cpu.
The x86 also has access to (at least some of) the RAM of the R3000.
This will enable the x86 to place the boot code into the RAM before
releasing the RESET of the R3000.

Instant saving: 1 eprom per board, Development costs (reburning EPROMS all 
the time....)

>*  Keyboard controller
>        This should certainly handle IBM compatible style keyboards.
>        The only way I know to do this is to use the 8051(?) micro-
>        controller to drive the keyboard exactly the same way as
>        every mother-board I've seen does.  This circuit should
>        connect easily to the 8-bit bus of the 3730.

See below, near "serial port".

>*  Non-Volatile-RAM and Real-Time-Clock
>        This should be looked into.  The clock is almost a requirement
>        but the NV-RAM could be replaced with the feature selector.

Why do you need a NV RAM? Why do you  need a RTC? You do need an
interrupt every 10ms. You can initialize from the RTC on the PC.
(ok. ok. Those are crummy, but you can live with it....)

>*  Serial port
>        Because of the ISA bus, serial is always possible.  It might
>        be a good idea, if just for debugging to have some serial
>        ports on the mother-board.  If this is the case, they should
>        be at least as good as 16550's.

My suggestion is to have a shared memory interface that looks like a 
serial line:

        struct combuf {
                int hd,tl;
                char buf[BUFSIZE];
                }
        
        out_char (struct combuf *cb,ch)
        {
        int hd = cb->hd;
        cb->buf[hd] = ch;
        inc (hd);
        while (hd == cb->tl)
                sleep_a_little_while ();
        cb->hd = hd;
        }

        in_char (struct combuf *cb)
        {
        int tl = cb->tl;
        int ch;

        while (tl == cb->head)
                sleep_a_little_while ();
        ch = cb->buf[tl];
        inc (tl);
        cb->tl = tl;
        }
        

Both sides (on the PC and on the R3000) use this interface (with different
cb pointers). To both sides this looks more or less like a serial stream 
of data.

To make this work in an multitasking environment it would be nice
to have an interrupt too.

                                Roger.


 
From SMACKINLA@cc.curtin.edu.au Mon Jun 28 13:39:43 1993
Return-Path: <SMACKINLA@cc.curtin.edu.au>
Received: from liberator.et.tudelft.nl by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25250; Mon, 28 Jun 93 13:39:33 +0200
Received: from CC.CURTIN.EDU.AU by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA05099; Mon, 28 Jun 93 13:39:01 +0200
Received: from cc.curtin.edu.au by cc.curtin.edu.au (PMDF #3256 ) id
 <01GZX905ZGNIFUMLVJ@cc.curtin.edu.au>; Mon, 28 Jun 1993 19:38:30 +0800
Date: 28 Jun 1993 19:38:30 +0800
From: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Subject: Re: Archive....
To: wolff@dutecai.et.tudelft.nl
Message-Id: <01GZX905ZGN4FUMLVJ@cc.curtin.edu.au>
X-Envelope-To: wolff@liberator.et.tudelft.nl
X-Vms-To: IN%"wolff@liberator.et.tudelft.nl"
X-Vms-Cc: SMACKINLA
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
Status: RO
X-Status: 


>I've dunked about everything I got so far into a file.... Here it comes:

Thanks for sending that. Much appreciated.

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 tor@tss.no Mon Jun 28 14:04:52 1993
Return-Path: <tor@tss.no>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25298; Mon, 28 Jun 93 14:04:48 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA25086; Mon, 28 Jun 93 05:04:39 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA18904; Mon, 28 Jun 93 05:04:29 -0700
Received: from benoni.Uit.No 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA24974; Mon, 28 Jun 93 05:04:27 -0700
Received: from benoni by ppenoni.uit.no with SMTP (PP) 
          id <20989-0@ppenoni.uit.no>; Mon, 28 Jun 1993 14:04:05 +0000
Received: from unas.tss.no 
          by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) 
          id AAbenoni20985; Mon, 28 Jun 1993 14:04:00 +0200
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA01676;
          Mon, 28 Jun 93 13:58:27 +0200
Message-Id: <9306281158.AA01676@unas.tss.no>
From: tor@tss.no (Tor Arntsen)
Date: Mon, 28 Jun 1993 13:58:25 +0200
In-Reply-To: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au> "Re: Things ..." (Jun 28, 7:36pm)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Subject: Re: Things ...
Cc: riscy@pyramid.com
Status: RO
X-Status: 

Pat Mackinlay wrote:
>(Tor, this message is not specifically targetted at you, I'm just getting 
>a little exasperated. Please don't take anything personally.)
No problem.. :-)

[a lot deleted]
>Side note: For those people who do use systems with 34010's, where 
>exactly are the performance problems? Do you actually see the chip 
>"painting" the screen, or is it just a general sluggishness? I suspect some 
>of the performance problems could actually be due to the fact that X 
>terminals are usually diskless, and the I/O overhead dominates the actual 
>graphics performance. This would not be an issue with a "local" 
>implementation.

Good point.  If I get the time I will fire up that system to see if I can
make better conclusions.  But don't let that put you on hold guys :-)

[more deleted]
>[...At the risk of repeating myself (again): If you're going to "knock" the 
>34k solution, please make sure you have a viable alternative...]
                                           ^^^^^^^^^^^^^^^^^^
Well, I don't have any!  I will probably not have any time available for a 
long time to dig into it either, so please just take those postings from me
as 'user reports', I certainly don't want to make any claims of how it
shall be done.

I still think this board will be fun..
Tor	(tor@tss.no)


 
From hodgen@informatik.uni-koblenz.de Mon Jun 28 14:16:23 1993
Return-Path: <hodgen@informatik.uni-koblenz.de>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25316; Mon, 28 Jun 93 14:16:15 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA27607; Mon, 28 Jun 93 05:16:09 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA19507; Mon, 28 Jun 93 05:15:56 -0700
Received: from mailhost.uni-koblenz.de 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA27522; Mon, 28 Jun 93 05:15:46 -0700
From: hodgen@informatik.uni-koblenz.de
Received: from ozzy by uniko.uni-koblenz.de with smtp
	(Smail3.1.28.1) id m0oAHu8-0001vyC; Mon, 28 Jun 93 14:01 MDT
Message-Id: <m0oAHu8-0001vyC@uniko.uni-koblenz.de>
Received: by ozzy (4.1/KO-2.0)
	id AA22861; Mon, 28 Jun 93 14:01:59 +0200
Subject: Re: Things
To: riscy@pyramid.com
Date: Mon, 28 Jun 93 14:01:57 MET DST
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

 Pat Mackinlay said	
>As for the guy that said he'd be willing to pay $1200 for the system, I 
>can't agree. In my mind, once you get over the US$800 mark, you'll be much 
>better off with a fully "commercial" system. As Neil mentioned before: if 
>all you want is a faster PC, by all means, go and buy one. I know it looks 
>like I'm harping on the point, but the price and complexity of this system 
>are the factors which will decide its fate.

Thats the point. I don't just want a faster PC, thats why I'm willing to wait
and pay more for something worth having.

-- 
Wayne Hodgen  | hodgen@infko.uni-koblenz.de | Opinions (c) Me 1991   | Intel SX
Uni Koblenz,  | (..!unido!infko!hodgen)     | Keeper of the Scrolls, |  Just
Rheinau 3-4,  | Voice: +49 261 9119-645     | Defender of the Net,   |   say
5400 Koblenz. | Fax:   +49 261 9119-499     | His name is "root".    |    NO!!!

 
From andy@resi.waldorf-gmbh.de Mon Jun 28 14:32:14 1993
Return-Path: <andy@resi.waldorf-gmbh.de>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25338; Mon, 28 Jun 93 14:32:11 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA00247; Mon, 28 Jun 93 05:32:04 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA20928; Mon, 28 Jun 93 05:31:54 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA29799; Mon, 28 Jun 93 05:31:52 -0700
Received: by mail.Germany.EU.net(EUnetD-2.2.6.c) via EUnet
	id PA14007; Mon, 28 Jun 1993 14:28:58 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for unido
	id AA07233; Mon, 28 Jun 93 14:14:54 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Mon, 28 Jun 93 14:13:23 +0200
Message-Id: <9306281213.AA13316@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA13316; Mon, 28 Jun 93 14:13:23 +0200
To: riscy@pyramid.com
Subject: UARTS & FDC's
Status: RO
X-Status: 

Hi Mipsers !

Looks like we are coming nearer to our final spec-sheet.

I have seen there was (or is?) a discussion about
floppys ot not and what UARTS.

I found something new:

SMC FDC37C651/2

It includes:

a 765-compatible FDC,
two 16450 compatible UARTs
a parallel port
and, for poor people, an IDE Interface...

What's about that ?

-------------------------------------------------------------------------------
Waldorf Electronics GmbH, R&D Department
c/o Andreas Busse
Neustrasse 9-12
D-5481 Waldorf
Phone:  +49 (0)2636-80294
Fax:    +49 (0)2636-80188
e-mail: andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------

 
From broadley@neurocog.lrdc.pitt.edu Mon Jun 28 14:56:59 1993
Return-Path: <broadley@neurocog.lrdc.pitt.edu>
Received: from liberator.et.tudelft.nl by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25522; Mon, 28 Jun 93 14:56:56 +0200
Received: from neurocog.lrdc.pitt.edu by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA05251; Mon, 28 Jun 93 14:56:50 +0200
Message-Id: <9306281256.AA05251@liberator.et.tudelft.nl>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA21160; Mon, 28 Jun 93 08:56:14 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Re: Proposed to comp.arch
To: wolff@dutecai.et.tudelft.nl (Rogier Wolff)
Date: Mon, 28 Jun 1993 08:56:14 -0500 (EDT)
In-Reply-To: <9306281241.AA05161@liberator.et.tudelft.nl> from "Rogier Wolff" at Jun 28, 93 02:41:04 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 804       
Status: RO
X-Status: 

> 
> Your post to Comp.arch mentioned the I960 as "hard to program".
> This is not true. The 960 has a clean architecture, and has a GCC 
> port.
> 
> 				Roger.

Hmmm I heard several things that make it unattractive for programming
in unix.  (which I kinda believe because nobody uses it for unix).

Does it do context switching well?  I have heard things like mult a,b,c
Multiplies a*b and puts the answer from 3 multiplies ago in c.

It's supposed to be very fast (at least in fp) but very hard to
extract that performance.  Any info would be appreciated.

There's an i860 port for gcc also.

-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok

 
From Steven.D.Ligett@Dartmouth.EDU Mon Jun 28 15:04:58 1993
Return-Path: <Steven.D.Ligett@Dartmouth.EDU>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25607; Mon, 28 Jun 93 15:04:48 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04563; Mon, 28 Jun 93 06:04:43 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA24887; Mon, 28 Jun 93 06:04:27 -0700
Received: from dartvax.dartmouth.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04444; Mon, 28 Jun 93 06:04:25 -0700
Received: from prancer.dartmouth.edu by dartvax.dartmouth.edu (5.65+D5/4.5HUB)
	id AA21049; Mon, 28 Jun 93 09:03:06 -0400
Message-Id: <5283630@prancer.Dartmouth.EDU>
Date: 28 Jun 93 09:03:03 EDT
From: Steven.D.Ligett@Dartmouth.EDU (Steven D. Ligett)
Subject: Re: SIMM sockets...
To: riscy@pyramid.com
Status: RO
X-Status: 

--- Pat Mackinlay wrote:
Neil, are you still planning on using 32 SIMM sockets? I've been looking, and
I just can't see how you plan to fit that many on the board if you plan to do
an ISA bus as well.... Perhaps we can allow 16M SIMMS to be used? With 8 x
16M SIMMS, we get the same 128M maximum, perfectly reasonable from my point
of view <grin>.
--- end of quoted material ---
I think that the problem is the plan to use the glue chip that only supports
1MB and 4MB chips.  (If I understand what's been said about the 7370 (?).)  
A typically shortsighted chip design, I'd say.

Let's take a quick look at the costs of the board and sockets for these 32
SIMMs.  Ignore the space and cost of the memory drivers that will be needed.

For a 6-layer board, $1.50 per square inch for the PCB.  Each socket is about
0.3" by 4".

board cost = $1.50 * 32 * 0.3" * 4" = $57.60  
just for the board space.

socket cost = $1.95 * 32 = $62.40
for the sockets.

$120 to put 32 empty SIMM sockets on the board.  Assume that I'm
misremembering the socket cost, and that we go with a 4-layer board, and that
goes down to $100.  Still too much.

 
From af4@ukc.ac.uk Mon Jun 28 15:09:42 1993
Return-Path: <af4@ukc.ac.uk>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25614; Mon, 28 Jun 93 15:09:39 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05228; Mon, 28 Jun 93 06:09:29 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA26212; Mon, 28 Jun 93 06:09:22 -0700
Received: from mercury.ukc.ac.uk 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05220; Mon, 28 Jun 93 06:09:20 -0700
Message-Id: <9306281309.AA05220@gossip.pyramid.com>
Received: from eagle by mercury.ukc.ac.uk   with UKC POP3+  id aa23470;
          28 Jun 93 14:08 BST
Date: Mon, 28 Jun 93 13:56:19 +0100
From: af4@ukc.ac.uk
To: riscy@pyramid.com
Subject: Things & Stuff
Status: RO
X-Status: 


There has been lots of noise about 34010 versus dumb frame buffers. Whilst I'm
in favour of the 34010 solution, I though I'd mention the 34076 Video Systems
Controller. The 34076 generates all the control and timing signals for a
raster scan video system, you just add a blob of VRAM, and a DAC (Inmos make
some nice ones, BTW), and Bob's yer aunty - instant dumb frame buffer.

While I'm at it, don't go leaving the parallel printer port off of the
motherboard. The cost of the necessary TTL octal latch is peanuts, so please
do your penny pinching elsewhere!

 
From Steven.D.Ligett@Dartmouth.EDU Mon Jun 28 15:14:35 1993
Return-Path: <Steven.D.Ligett@Dartmouth.EDU>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25631; Mon, 28 Jun 93 15:14:15 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05829; Mon, 28 Jun 93 06:14:04 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA26532; Mon, 28 Jun 93 06:13:55 -0700
Received: from dartvax.dartmouth.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05821; Mon, 28 Jun 93 06:13:52 -0700
Received: from prancer.dartmouth.edu by dartvax.dartmouth.edu (5.65+D5/4.5HUB)
	id AA21491; Mon, 28 Jun 93 09:12:13 -0400
Message-Id: <5283806@prancer.Dartmouth.EDU>
Date: 28 Jun 93 09:12:10 EDT
From: Steven.D.Ligett@Dartmouth.EDU (Steven D. Ligett)
Subject: Re: Fast Video [was: More ramblings...]
To: riscy@pyramid.com
Status: RO
X-Status: 

--- Tommy Thorn wrote:
The 34010 might be good if it simplifies the design and helps bring the price
down, but I worry over the affect on video performens (and complexity of the
software). One can do quite well with a dumb frame buffer with high
bandwidth. Joel McCormack's article ("Writing Fast X Servers for Dumb Color
Frame Buffers. Software: Practice and Experience 20(S2):83-108, October 1990)
shows this (using a R3000 BTW).
--- end of quoted material ---
I suggest reading this article before going off the deep end.  It is
available as PostScript from DECWRL.  Here's info on how to get to the DECWRL
server, and an index of articles.  The mentioned article is # 91/1.

Date: Fri, 9 Apr 93 07:19:03 -0700
Subject: How to use the WRL Tech Report Service
From: WRL Tech Report Service <wrl-techreports@pa.dec.com>
In-Reply-To: message from steven.d.ligett@dartmouth.edu (steven d. ligett)
To: steven.d.ligett@Dartmouth.EDU (steven d. ligett)

This message comes to you from the WRL Tech Report Service,
wrl-techreports@decwrl.dec.com.  It received a message from you asking
for help.

The technical reports server is a mail-response program.  That means
that you mail it a request, and it mails back the response.

The server is a very dumb program.  It does not have much error
checking.  If you don't send it the commands that it understands, it
will just answer "I don't understand you".

The server has 7 commands.  Each command must be the first word on a
line.  The server reads your entire message before it does anything,
so you can have several different commands in a single message.  The
server treats the "Subject:" header line just like any other line of
the message.  You can use any combination of upper and lower case
letters in the commands.

The technical reports are organized into a series of directories and
subdirectories (Abstracts, PS, Status). 

Technical notes are for rapid distribution of technical material.
Usually this represents work in progress.  Our technical reports may
include large portions of prior technical notes.

Network notes are a new addition to the server.  They are for rapid
distribution of network related material.  Network notes are usually a
means of sharing network expertise and experience.

---------------------------------------------------------------------------
If you are bored with reading documentation and just want to try
something, then send the server a message containing the line

	send index

When you get the index back, it will give you the names of all of the
Tech-notes and Net-notes in the archive; send the server another
message asking it to send you the abstracts that you want:

	send abstracts 86/3 87/4 prospectus.87

If you are using a mailer that understands "@" notation, send to
wrl-techreports@decwrl.dec.com.  If your mailer deals in "!" notation,
try sending to {someplace}!decwrl!wrl-techreports, e.g.
ihnp4!decwrl!wrl-techreports.  If your mailer deals in "::" notations,
try sending to decwrl::wrl-techreports.  For other mailers, you're on
your own.
---------------------------------------------------------------------------

Here is some more documentation.  The server has 7 commands:


"help"	command: The command "help" or "send help" causes the server to
	send you the help file.  You already know this, of course,
	because you are reading the help file.  No other commands are
	honored in a message that asks for help (the server figures
	that you had better read the help message before you do
	anything else).

"index" command: if your message contains a line whose first word is
	"index", then the server will send you the index of the
	contents of the archive.

	You can then send back another message to the server, using a
	"send" command (see below) to ask it to send you the files
	whose name you learned from that list.

	If your message has an "index" or a "send index" command, then
	all other "send" commands will be ignored.  This means that you
	cannot get an index and data in the same request.  This is so
	that index requests can be given high priority.)

"send"	command: if your message contains a line whose first word is
	"send", then the server will send you the item(s) named on the
	rest of the line.  To name an item, you give its directory and
	its name.  For example

		send abstract 87/5

	or

		send postscript 87/3

	Once you have named a category, you can put as many names as
	you like on the rest of the line; they will all be taken from
	that category.  For example:

		send abstract 86/3 86/4 87/1 87/2

	Each "send" command can reference only one directory.   If you
	would like to get one abstract and one postscript file, you
	must use two "send" commands, one beginning "send abstract"
	and the other beginning "send postscript".

	You may put as many "send" commands as you like into one
	message to the server, but the more you ask for, the longer it
	will take to receive.  See "FAIRNESS", below, for an
	explanation.  Actually, it's not strictly true that you can put
	as many "send" commands as you want into one message.  If the
	server must use uucp mail to send your files, then it cannot
	send more than 100K bytes in one message.  If you ask for more
	than it can send, then it will send as much as it can and
	ignore the rest.

"add"	command: if you are not already on the mailing list, send a
	message with the line

		add

	in the body of your message, followed by your mailing address.
	Human intervention is required to add someone to the mailing
	list, so this will take a little while.  When you've been
	added, you'll get an acknowledgement message back, and you'll
	receive future announcements of new technical reports as they
	become available.

"order" command: while we make PostScript source for many of our
	technical reports available, most are larger than you might
	like to send through the electronic mails.  We expect most
	people would like hard copy, and the order command allows you
	to do that.

	Send a line of the form

		order Prospectus.87

	or

		order 86/4 87/3

	and the server will queue an order request.  The
	acknowledgement message will contain an ID number that
	identifies the order; you can use the "status" command to
	inquire into what's taking so long.

	Orders are filled by hand as quickly as possible, but
	sometimes there are delays.  If several of the reports that
	you've ordered are out of print, we'll hold the order until we
	can ship everything.  The "status" category of the "send"
	command is available to let you find out about which orders
	are out of print.

	We find your address in a database that's keyed by your name
	as it appears in our mailing list; if that doesn't
	automatically appear somwehere in the header of your message,
	please include it somewhere in the body. If you're not on our
	mailing list yet, include your entire postal address.

"status" command: once you have an order ID in hand, you can find out
	how it's progressing through the mill.  Send the server a line
	like

		status 573350661.19909

	and the server will respond with what's been done so far with
	the order.

	If you don't know the order number, just send

		status

	and the server will tell you about all pending orders from you.

"path"	command: The "path" command exists to help in case you do not
	get responses from the server when you mail to it.

	Sometimes the server is unable to return mail over the
	incoming path.  There are dozens of reasons why this might
	happen, and if you are a true wizard, you already know what
	those reasons are.  If you are an apprentice wizard, you might
	not know all the reasons but you might know a way to
	circumvent them.

	If you put in a "path" command, then everything that the
	server mails to you will be mailed to that address, rather
	than to the return address on your mail.  For example, if you
	say

	    path pyramid!rutgers!zakkaroo!jj

	then all mail sent by the server will be sent to that address.
	Note: decwrl does NOT have a uucp link to seismo.  A command
	like

	    path seismo!someplace!name

	will guarantee that you do not receive the response.  We do
	have a link to seismo.css.gov (and all other Internet sites),
	permitting

	    path seismo.css.gov!someplace!name

	If you would like the server to determine a uucp path for you,
	using the most recent pathalias data, then put in a "path"
	command with yourname@site.uucp, e.g.:

	    path person@place.uucp

	As you probably know, the pathalias data is sometimes wrong,
	but it is often right.

EXAMPLES:

1) Find out the list of reports that are in the archive.  Send this message:

	To: wrl-techreports@decwrl.dec.com
	Subject: hi there

	send index

2) Get the abstracts of reports about networking from the server (you have
   learned their file names from the list that was sent to you in step 1).

	To: wrl-techreports@decwrl.dec.com

	send abstracts 87/2 87/3 
	send abstracts 87/4 87/7

3) Order the compiler reports, and send the responses over the best 
   path to my site:

	To: seismo.css.gov!decwrl!wrl-techreports

	path myname@site.uucp
	order 86/3 87/1 87/5

NOTES:

The server acknowledges every request by return mail.  If you don't get
a message back in a day or two (depending on how close you are to
decwrl on the network) you should assume that something is going
wrong, and perhaps try a "path" command.  If you aren't getting
anywhere and you don't know a wizard to help you, try putting

	path myname@site.uucp

in your message, where "myname" is your mailbox name and "site" is the
uucp name of your machine.

The delays in sending out large items from the archives are
intentional, to make it difficult to get copies of everything in the
archives.  If you are new to the network and would like to get all
back issues of everything, you should use order instead of send.

Don't send mail with long lines.  If you want to ask for 10 reports in
one request, you don't need to put all 10 of them in one "send"
command.  The server is quite able to handle long lines, but before
your mail message is received by the server it might pass through
relay computers that will choke on long lines.

The server does not respond to requests from users named "root",
"system", "daemon", or "mailer".  This is to prevent mail loops.  If
your name is "Bruce Root" or "Joe Daemon", and you can document this,
I will happily rewrite the server to remove this restriction.  Yes, I
know about Norman Mailer and Waverley Root.  Norman doesn't use
netmail and Waverley is dead.


FAIRNESS:

The server contains many safeguards to ensure that it is not
monopolized by people asking for large amounts of data.  The mailer is
set up so that it will send no more than a fixed amount of data each
day.  If the work queue contains more requests than the day's quota,
then the unsent files will not be processed until the next day.
Whenever the mailer is run to send its day's quota, it sends the
requests out shortest-first.

If you have a request waiting in the work queue and you send in
another request, the new request is added to the old one (thereby
increasing its size) rather than being filed anew.  This prevents you
from being able to send in a large number of small requests as a way
of beating the system.  If you request 10 reports together, you will
get substantially higher priority than if you make 10 requests for 1
report each.

The reason for all of these quotas and limitations is that the
delivery resources are finite, and there are many people who would
like to make use of the server.



Date: Fri, 9 Apr 93 08:19:04 -0700
Subject: INDEX - per your request
From: WRL Tech Report Service <wrl-techreports@pa.dec.com>
In-Reply-To: message from steven.d.ligett@dartmouth.edu (steven d. ligett)
To: steven.d.ligett@Dartmouth.EDU (steven d. ligett)

Index of top level from WRL Tech Report Service (updated Apr 2 17:15)
-----------------------------------------------------------------
	      === TECHNICAL REPORTS ===
Key	Author(s)	Size (KB)*	Title
=======================================================================
Prospectus.87           36      WRL Prospectus 87-88
86/1    Nielsen         497     Titan System Manual
86/3    Wall            136     Global Register Allocation at Link Time
86/4    Hamburgen       279     Optimal Finned Heat Sinks
87/1    Wall/Powell     126     The Mahler Experience: Using an Intermediate
                                Language as the Machine Description
87/2    Mogul et al.    161     The Packet Filter: An Efficient Mechanism for
                                User-level Network Code
87/3    Kent/Mogul      137     Fragmentation Considered Harmful
87/4    Kent            544     Cache Coherence in Distributed Systems
87/5    Wall            129     Register Windows vs. Register Allocation
87/6    Asente                  Editing Graphical Objects using Procedural
                                Representations
87/7    Reid            103     The USENET Cookbook: and Experiment in
                                Electronic Publication
88/1    Dion                    Fast Printed Circuit Board Routing
88/2    Bartlett        220     Compacting Garbage Collection with Ambiguous
                                Roots
88/3    Mogul           64      The Experimental Literature of The Internet:
                                An Annotated Bibliography
88/4    Boggs et al.    596     Measured Capacity of an Ethernet: Myth and
                                Reality
88/5    Estrin, Mogul,  264     Visa Protocols for Controlling Inter-
        Tsudik, Anand           Organizational Datagram Flow: Extended
                                Description
89/1    Bartlett        115     SCHEME->C  A Portable Scheme-to-C Compiler
89/2    Turrini         755     Optimal Group Distribution in Carry-Skip
Adders
89/3    Hamburgen       244     Precise Robotic Paste Dot Dispensing
89/4    Mogul           133     Simple and Flexible Datagram Access Controls
                                for Unix-based Gateways
89/5    Srinivasan,     419     Spritely NFS:  Implementation and Performance
        Mogul                   of Cache-Consistency Protocols
89/7    Jouppi, Wall    220     Available Instruction-Level Parallelism for
                                Superscalar and Superpipelined Machines
89/8    Jouppi, et al.  146     A Unified Vector/Scalar Floating-Point
                                Architecture
89/9    Jouppi          164     Architectural and Organizational Tradeoffs in
                                the Design of the MultiTitan CPU
89/10   Jouppi          62      Integration and Packaging Plateaus of
Processor
                                Performance
89/11   Jouppi, Tang    757     A 20-MIPS Sustained 32-bit CMOS
Microprocessor
                                with High Ratio of Sustained to Peak
                                Performance
89/13   Jouppi          323     The Distribution of Instruction-Level and
                                Machine Parallelism and Its Effect on
                                Performance
89/14   Borg, et al.    924     Long Address Traces from RISC Machines:
                                Generation and Analysis
89/17   Wall            113     Link-Time Code Modification
90/1    Tang,Yang       528     Noise Issues in the ECL Circuit Family
90/2    Larrabee        568     Efficient Generation of Test Patterns Using
                                Boolean Satisfiability
90/3    Larrabee                Two Papers on Test Pattern Generation
90/4    Nelson          131     Virtual Memory vs. The File System
90/5    Mogul           273     Efficient Use of Workstations for Passive
                                Monitoring of Local Area Networks
90/6    Fitch           135     A One-Dimensional Thermal Model for
                                the VAX 9000 Multi Chip Units
90/7    Mayo, et al.            1990 DECWRL/Livermore Magic Release
90/9    McGillis et al. 282     Pool Boiling Enhancement Techniques for Water
                                at Low Pressure
91/1    McCormack       286     Writing Fast X Servers for Dumb Color Frame
                                Buffers
91/3    Stark           144     Analysis of Power Supply Networks in VLSI
                                Circuits
91/4    Boggs           248     TurboChannel T1 Adapter
91/5    McFarling       203     Procedure Merging with Instruction Caches
91/6    Bartlett        739     Don't Fidget with Widgets, Draw!
91/7    McGillis et al. 543     Pool Boiling on Small Heat Dissipating
Elements
                                in Water at Subatmospheric Pressure
91/8    Yip             608     Incremental, Generational Mostly-Copying
                                Garbage Collection in Uncooperative
Environments
91/9    Hamburgen       119     Interleaved Fin Thermal Connectors for
Multichip
                                Modules
91/10   Wall            509     Experience with a Software-Defined Machine
                                Architecture
91/11   Mogul          	        Network Locality at the Scale of Processes
91/12   Jouppi          382     Cache Write Policies and Performance
92/1   Hamburgen et al. 244     Packaging a 150W Bipolar ECL Microprocessor
92/2    Mogul           725     Observing TCP Dynamics in Real Networks
92/3    Wall            163     Systems for Late Code Modification
92/5    Kao            1719     Piecewise Linear Models for Switch-Level
Simulation
92/6  Srivastava, Wall  183     A Practical System for Intermodule Code
Optimization
                                at Link-Time
93/1   McCormack et al. 303     A Smart Frame Buffer

		       === TECHNICAL NOTES ===
Key     Author(s)       Size(KB)*	Title
=======================================================================
TN-4    Reid, Kent      65      TCP/IP PrintServer: Print Server Protocol
TN-7    Kent            88      TCP/IP PrintServer: Server Architecture and
                                Implementation
TN-9    McCormack       227     Smart Code, Stupid Memory  A Fast X Server
                                for a Dumb Color Frame Memory
TN-11   Ousterhout      64      Why Aren't Operating Systems Getting Faster
                                As Fast As Hardware?
TN-12   Bartlett        81      Mostly-Copying Garbage Collection Picks Up
                                Generations and C++
TN-15   Wall            353     Limits of Instruction-Level Parallelism
TN-16   Mogul, Borg     227     The Effect of Context Switches on Cache
                                Performance
TN-17   Goldberg        198     MTOOL: A Method For Detecting Memory
                                Bottlenecks
TN-18   Wall            184     Predicting Program Behavior Using Real or
                                Estimated Profiles
TN-19   Wall            129     Systems for Late Code Modification
TN-21   Srivastava      98      Unreachable Procedures in Object-oriented
                                Programming
TN-22   McFarling       152     Cache Replacement with Dynamic Exclusion
TN-23   McGillis, et al 542     Boiling Binary Mixtures at Subatmospheric
                                Pressures
TN-24   Fitch           61      A Comparison of Acoustic and Infrared
                                Inspection Techniques for Die Attach
TN-26   Boggs           119     TurboChannel Versatec Adapter
TN-27   Mogul           119     A Recovery Protocol for Spritely NFS
TN-29	Boyle			Electrical Evaluation Of The BIPS-0 Package
TN-30   Bartlett        336     Transparent Controls for Interactive Graphics
TN-32   Dion, Monier    265     Design Tools for BIPS-0

*(NOTE: Not all of the above reports and notes are available in
Postscript form.  Only, those with a size listed are available in
Postscript.)

Technical notes are for rapid distribution of technical material.  Usually 
this represents work in progress.  Our technical reports may include large 
portions of prior technical notes. 

To see the abstract for any report or note, send the server a message saying 
"send abstract 90/4" or "send abstracts 91/3 TN-7 NN-2", etc. Capitalization
does not matter.

To retrieve the PostScript for any report or note, send the server a message 
saying "send postscript 90/4" or "send postscript 91/3 TN-7 NN-2", etc. 
Capitalization does not matter.

Send server requests to wrl-techreports@decwrl.dec.com, or
{ihnp4,decvax,ucbvax,hplabs,allegra}!decwrl!wrl-techreports,
or DECWRL::WRL-TECHREPORTS.



 
From SMACKINLA@cc.curtin.edu.au Mon Jun 28 15:22:56 1993
Return-Path: <SMACKINLA@cc.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25670; Mon, 28 Jun 93 15:22:19 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06468; Mon, 28 Jun 93 06:22:10 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA26897; Mon, 28 Jun 93 06:21:55 -0700
Received: from cc.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06460; Mon, 28 Jun 93 06:21:50 -0700
Received: from cc.curtin.edu.au by cc.curtin.edu.au (PMDF #3256 ) id
 <01GZXCG1MRDSFUMLVJ@cc.curtin.edu.au>; Mon, 28 Jun 1993 21:21:04 +0800
Date: 28 Jun 1993 21:21:04 +0800
From: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Subject: Re: Things & Stuff
To: af4@ukc.ac.uk
Cc: riscy@pyramid.com
Message-Id: <01GZXCG1N10YFUMLVJ@cc.curtin.edu.au>
X-Envelope-To: riscy@pyramid.com
X-Vms-To: IN%"af4@ukc.ac.uk"
X-Vms-Cc: R3KPC,SMACKINLA
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
Status: RO
X-Status: 


>There has been lots of noise about 34010 versus dumb frame buffers. Whilst I'm
>in favour of the 34010 solution, I though I'd mention the 34076 Video Systems
>Controller. The 34076 generates all the control and timing signals for a
>raster scan video system, you just add a blob of VRAM, and a DAC (Inmos make
>some nice ones, BTW), and Bob's yer aunty - instant dumb frame buffer.

Ok, this is what I was looking for. Any ideas on pricing? I hope TI still 
makes the thing. Does anyone know of any other chips that will provide 
similar stuff? While we're at it, perhaps you could let me (us) know why 
you do favour a 34010 solution? I personally would go for the dumb 
framebuffer if it were possible to do it cheaply enough...

>While I'm at it, don't go leaving the parallel printer port off of the
>motherboard. The cost of the necessary TTL octal latch is peanuts, so please
>do your penny pinching elsewhere!

Hmmm... My feelings here are that if we're going to put a parallel port and 
an FDC on the motherboard, it should only be done at the expense of the ISA 
(or other) I/O bus. A card with a parallel port and other junk costs 
virtually nothing. Putting a "real" parallel port (ie: bidirectional) on 
the motherboard would be a waste of board space and effort (IMHO).

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 wolff@dutecai.et.tudelft.nl Mon Jun 28 15:26:16 1993
Return-Path: <wolff@dutecai.et.tudelft.nl>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25697; Mon, 28 Jun 93 15:26:13 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06845; Mon, 28 Jun 93 06:25:58 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA27196; Mon, 28 Jun 93 06:25:47 -0700
Received: from liberator.et.tudelft.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06819; Mon, 28 Jun 93 06:25:36 -0700
Received: by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA05424; Mon, 28 Jun 93 15:24:12 +0200
Date: Mon, 28 Jun 93 15:24:12 +0200
From: wolff@dutecai.et.tudelft.nl (Rogier Wolff)
Message-Id: <9306281324.AA05424@liberator.et.tudelft.nl>
To: riscy@pyramid.com
Subject: Graphics implementation.
Status: RO
X-Status: 



Hi everyone,

> People: _PLEASE_, if you can come up with a practical alternative for a 
> video system (I know you're out there Steve <grin>), speak up now. It 
> _would_ be much better to use a dumb framebuffer attached to the CPU, but I 
> fear that the extra logic required to generate monitor signals and clock 
> the data out of the VRAM at the right speed would be a 

I've "posted" this before, but we have a solution using a SGS-Thompson
G335. It has a hook to the system bus on one side, and a video
bus on the other side. The video memory is simply mapped in the
processors memory address space (like normal DRAM). The G335 will
perform a DMA cycle every 1024*4 pixels (at 4 pixels / word).

The G335 has onboard 8 bit DACs, so you don't have to buy a separate
RAMDAC. Simple single chip solution. Also runs upto 1280x1024 at 70Hz.....

Disadvantages: costs around $100, is an SMD.

Since it is a single chip you can save a lot on extra "small glue" components
and assembly costs. (these add up you know). About the SMD: With a little
care and patience, you can solder one on a board in a few hours (I know,
I've done it.....).

I agree: you don't want to do 30 of them. You'll be fed up with doing this
after a few of them. On the other hand, you might get a little more 
experience, and speed things up a lot.

					Roger.


 
From mackinla@cs.curtin.edu.au Tue Jun 22 17:45:24 1993
Return-Path: <mackinla@cs.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA03701; Tue, 22 Jun 93 17:45:17 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA25250; Tue, 22 Jun 93 08:48:01 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA03132; Tue, 22 Jun 93 08:45:03 -0700
Received: from marsh.cs.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA25234; Tue, 22 Jun 93 08:47:52 -0700
Received: from vincent.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA11135
  (5.67a/IDA-1.4.4 for <riscy@pyramid.com>); Tue, 22 Jun 1993 23:43:35 +0800
Received: by vincent.cs.curtin.edu.au id AA14749
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Tue, 22 Jun 1993 23:43:24 +0800
From: Patrick Mackinlay <mackinla@cs.curtin.edu.au>
Message-Id: <199306221543.AA14749@vincent.cs.curtin.edu.au>
Subject: Re: Monitor code...
To: riscy@pyramid.com
Date: Tue, 22 Jun 1993 23:43:23 +0800 (WST)
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1808      
Status: RO
X-Status: 


>*  Serial port
>
>How about using one of the 8 port chips. They come in a 68 lead PLCC.

Is this really necessary? This will probably get under Steve's (and
Jerry's) skin <grin>, but I think _one_ serial port on the motherboard
would be adequate. Remember, more can always be added with the ISA
bus... I mean seriously, the _CPU_ is only an 84 lead PLCC! <grin>

>*  Ethernet port
>
>I designed a card using the 7990, and I guess I could do it again.
>But, the 7990 was around in 1985, and there are better chips now.

Ok, so at least we have someone with enet experience on board. I
don't suppose you could tell me if there are any particular problems
with using an ISA card to do the networking? This could cut the
cost of the board a lot, while not necessarily reducing performance,
and make enet optional in the bargain. Are there any obvious
difficulties/problems doing it this way? Are PC enet cards particularly
obnoxious?

>*  Diagnostics / monitor code
>
>What fun. I bet we will have to fight over who does this one.

Are you serious!? I'd _love_ to do this part! The problem for me is
going to be getting ROMs burned, although I think I can twist a
few arms around here...

BTW: I suggest we do a few introductions here. I'm Pat Mackinlay,
a 3rd year CS student down here in Australia. I've been working on
a similar kind of a project (on and off) with Steve Ligett and
Jerry Callen (both on this list now, I think). I'm in this to see
a viable alternative to the current PC i386/486 boards, hopefully
running Linux or something like that, with an eventual goal of
seeing the GNU Hurd up and running...

Next? <grin>

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 broadley@neurocog.lrdc.pitt.edu Mon Jun 28 15:55:06 1993
Return-Path: <broadley@neurocog.lrdc.pitt.edu>
Received: from liberator.et.tudelft.nl by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25792; Mon, 28 Jun 93 15:55:03 +0200
Received: from neurocog.lrdc.pitt.edu by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA05586; Mon, 28 Jun 93 15:54:58 +0200
Message-Id: <9306281354.AA05586@liberator.et.tudelft.nl>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA21329; Mon, 28 Jun 93 09:54:27 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Re: Proposed to comp.arch
To: wolff@dutecai.et.tudelft.nl (Rogier Wolff)
Date: Mon, 28 Jun 1993 09:54:27 -0500 (EDT)
In-Reply-To: <9306281332.AA05485@liberator.et.tudelft.nl> from "Rogier Wolff" at Jun 28, 93 03:32:11 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 800       
Status: RO
X-Status: 

> 
> The pipeline in software (mul a,b,c -> result from two multiplies back in
> c) is an '860 "feature".
Ahh I guess I got confused...

> 
> The '960 is inattractive for a Unix implementation. In that you are right.
> 
Well thats definitely the target, I change the wording thanks.

> The different versions of the '960 have either a MMU, FP or a Super Scalar
> version. No two of these go together (I think... I use the Super Scalar
> version: the I960 CA). For Unix you need all three. (The military
> is able to get two of them.....)
> 
I'd guess FP and Superscaler.  No need for MMU.


-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok


 
From Steven.D.Ligett@Dartmouth.EDU Mon Jun 28 16:16:41 1993
Return-Path: <Steven.D.Ligett@Dartmouth.EDU>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25858; Mon, 28 Jun 93 16:16:33 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA10605; Mon, 28 Jun 93 07:16:28 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA29163; Mon, 28 Jun 93 07:16:16 -0700
Received: from dartvax.dartmouth.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA10441; Mon, 28 Jun 93 07:16:06 -0700
Received: from prancer.dartmouth.edu by dartvax.dartmouth.edu (5.65+D5/4.5HUB)
	id AA26383; Mon, 28 Jun 93 10:14:25 -0400
Message-Id: <5285326@prancer.Dartmouth.EDU>
Date: 28 Jun 93 10:14:18 EDT
From: Steven.D.Ligett@Dartmouth.EDU (Steven D. Ligett)
Subject: Re: Things & Stuff
To: SMACKINLA@cc.curtin.edu.au, jcallen@world.std.com
Cc: riscy@pyramid.com
Status: RO
X-Status: 

--- Pat Mackinlay wrote:
Ok, this is what I was looking for. Any ideas on pricing? I hope TI still
makes the thing.
--- end of quoted material ---
HEY!  oh never mind.  no one listens.

the 34076 plus the nsc 1882 to generate the syncs is what I SAID.

jeez.

 
From Steven.D.Ligett@Dartmouth.EDU Mon Jun 28 16:19:44 1993
Return-Path: <Steven.D.Ligett@Dartmouth.EDU>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25875; Mon, 28 Jun 93 16:19:37 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA11347; Mon, 28 Jun 93 07:19:27 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA29487; Mon, 28 Jun 93 07:19:19 -0700
Received: from dartvax.dartmouth.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA11312; Mon, 28 Jun 93 07:19:17 -0700
Received: from prancer.dartmouth.edu by dartvax.dartmouth.edu (5.65+D5/4.5HUB)
	id AA26594; Mon, 28 Jun 93 10:17:48 -0400
Message-Id: <5285405@prancer.Dartmouth.EDU>
Date: 28 Jun 93 10:17:44 EDT
From: Steven.D.Ligett@Dartmouth.EDU (Steven D. Ligett)
Subject: Re: Things & Stuff
To: riscy@pyramid.com
Status: RO
X-Status: 

--- af4@ukc.ac.uk wrote:
There has been lots of noise about 34010 versus dumb frame buffers. Whilst
I'm in favour of the 34010 solution, I though I'd mention the 34076 Video
Systems Controller. The 34076 generates all the control and timing signals
for a raster scan video system, you just add a blob of VRAM, and a DAC (Inmos
make some nice ones, BTW), and Bob's yer aunty - instant dumb frame buffer.
--- end of quoted material ---
Yes, perhaps my post didn't get out.  The design I've been working on would
use the 34076, and the NSC LM1882 to generate the syncs.  The 34076 HAS the
DACs on it -- It's a RAMDAC.  It doesn't generate the Vsync, Hsync, nor the
blanking.  The 1882 does that.

Bag the 34010 -- put another 3041 on the board if you want smarts to drive
the graphics.  All your software tools for the 3081 work just as well for its
little brother.

 
From SMACKINLA@cc.curtin.edu.au Mon Jun 28 16:42:34 1993
Return-Path: <SMACKINLA@cc.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25987; Mon, 28 Jun 93 16:42:27 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15267; Mon, 28 Jun 93 07:42:20 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02056; Mon, 28 Jun 93 07:42:10 -0700
Received: from cc.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15259; Mon, 28 Jun 93 07:42:04 -0700
Received: from cc.curtin.edu.au by cc.curtin.edu.au (PMDF #3256 ) id
 <01GZXF9VZCSGFUMLVJ@cc.curtin.edu.au>; Mon, 28 Jun 1993 22:41:40 +0800
Date: 28 Jun 1993 22:41:40 +0800
From: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Subject: Re: Things & Stuff
To: Steven.D.Ligett@Dartmouth.EDU
Cc: riscy@pyramid.com
Message-Id: <01GZXF9VZCSIFUMLVJ@cc.curtin.edu.au>
X-Envelope-To: riscy@pyramid.com
X-Vms-To: IN%"Steven.D.Ligett@Dartmouth.EDU"
X-Vms-Cc: R3KPC,SMACKINLA
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
Status: RO
X-Status: 


>Yes, perhaps my post didn't get out.  The design I've been working on would
>use the 34076, and the NSC LM1882 to generate the syncs.  The 34076 HAS the
>DACs on it -- It's a RAMDAC.  It doesn't generate the Vsync, Hsync, nor the
>blanking.  The 1882 does that.

I must apologize to Steve here - I suspect that his message referring to 
this idea got lost in my "great mail screwup" and I didn't manage to see 
it. Ok, the next thing to look at is pricing and availability.

>Bag the 34010 -- put another 3041 on the board if you want smarts to drive
>the graphics.  All your software tools for the 3081 work just as well for its
>little brother.

Agree. Presuming that the 34076 and 1882 are cheap enough (and readily 
available), it looks like we have a video system <grin>.

(Still like the idea of the 34010 though <grumble>).

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 ewt@SunSITE.unc.edu Mon Jun 28 17:37:47 1993
Return-Path: <ewt@SunSITE.unc.edu>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA26136; Mon, 28 Jun 93 17:37:41 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA22765; Mon, 28 Jun 93 08:37:30 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA10379; Mon, 28 Jun 93 08:36:20 -0700
Received: from SunSite.unc.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA22542; Mon, 28 Jun 93 08:36:18 -0700
Received: by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA01523; Mon, 28 Jun 93 11:35:06 EDT
Date: Mon, 28 Jun 1993 11:35:05 -0400 (EDT)
From: Erik Troan <ewt@SunSite.unc.edu>
Subject: 34010 X compiler, mailing lists
To: riscy@pyramid.com
Message-Id: <Pine.2.4.53.9306281125.A1445@calypso>
Status: RO
X-Status: 


On xxx, 27 Jun 1993, Pat Mackinlay wrote:

[lots of good stuff about 34010's deleted becuase we've all read it already

> BTW: I wouldn't expect that using a 34010 would make the graphics
> system outperform any of the VGAs out there, but it'd be quite
> interesting, and would leave the main CPU free to do some "real"
> work. It might even be practical to run PEX stuff <grin>

If we do decide on the 34010 path, I agree with Pat that a gcc port would
be a huge problem. I'm willing to write a small C compiler for the chip
from scratch. I'm not offering to port gcc, as I think that such an effort
is unnecessary. If the chip is going to be driving graphics, code doesn't
have to be written often, so I think we can live with putting the 
optimizations in the code instead of the compiler.

By small I mean I'm not going to write a floating point library (though
I'd be happy to integrate with one written by someone else), generate
anything but straight object code for the 34010 (we don't need dll's,
etc for a graphics processor), or even acknowledge C++'s existence any
further then allowing // for comments. Let me know if this is worth
my time.

> [...if there is no archive site, would someone be willing to mail me
> the last day or two of messages? I don't like having to repeat questions
> that people have already answered...]

If there is an archive site, would someone please let me know. If not, I'd
like to set one up on sunsite.unc.edu. /pub/Riscy maybe? Seems like we
should start thinking about an ftp site anyhow.

Erik

 
From wolff@dutecai.et.tudelft.nl Mon Jun 28 17:41:48 1993
Return-Path: <wolff@dutecai.et.tudelft.nl>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA26149; Mon, 28 Jun 93 17:41:44 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23395; Mon, 28 Jun 93 08:41:36 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA10946; Mon, 28 Jun 93 08:40:29 -0700
Received: from liberator.et.tudelft.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23194; Mon, 28 Jun 93 08:40:20 -0700
Received: by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA05785; Mon, 28 Jun 93 17:39:00 +0200
Date: Mon, 28 Jun 93 17:39:00 +0200
From: wolff@dutecai.et.tudelft.nl (Rogier Wolff)
Message-Id: <9306281539.AA05785@liberator.et.tudelft.nl>
To: riscy@pyramid.com
Subject: Moving this mailinglist?
Status: RO
X-Status: 


Hi everyone,


At the moment this mailinglist is moving at around 20 or more mailmessages
a day. This is more like the volume that goes around in a newsgroup.
Also newsreaders are more adapted to selective reading. 

Wouldn't it  be a good idea to move this mailinglist into a newsgroup?
(This would allow my mailbox to go back to normal: a few messages a day)
Disadvantage is a slower turnaround time of a few days between posting and
that everyone has it. Another disadvantage would be that we might attract
a lot of "noise" if EVERYONE reading news would get a message "do you want
to subscribe to the group alt.desinging.our.own.R3000.motherboard?". If we
think that this would attract too much noise we could go for the
nondescriptive name trick: alt.linux.is.great :-)

					Roger.

 
From broadley@neurocog.lrdc.pitt.edu Mon Jun 28 18:16:07 1993
Return-Path: <broadley@neurocog.lrdc.pitt.edu>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA26218; Mon, 28 Jun 93 18:16:03 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA27852; Mon, 28 Jun 93 09:15:57 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA14960; Mon, 28 Jun 93 09:14:49 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA27593; Mon, 28 Jun 93 09:14:47 -0700
Message-Id: <9306281614.AA27593@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA22161; Mon, 28 Jun 93 12:14:16 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: TIGA chip/docs
To: riscy@pyramid.com (Mips 3000)
Date: Mon, 28 Jun 1993 12:14:16 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 783       
Status: RO
X-Status: 

I havea really cool tiga interface users guide, which seems to be a full
c library for dos to use the tiga chip (Not sure if source is available).

Also of interest TMS340 Family code generation tools users guide literature
number SPVU020.
        Describes the c compiler, assembler, linker, and archiver for the
ths340X0 graphics system processors.

So apparently they already have the c compiler (I think it's free).

Ti has been very generous with the documentation (we got it free)
which is a big win.

I tried to call for prices but I didn't have any parts numbers.


-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok


 
From mackinla@cs.curtin.edu.au Tue Jun 22 17:49:00 1993
Return-Path: <mackinla@cs.curtin.edu.au>
Received: from liberator.et.tudelft.nl by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA03711; Tue, 22 Jun 93 17:48:55 +0200
Received: from marsh.cs.curtin.edu.au by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA03041; Tue, 22 Jun 93 17:48:42 +0200
Received: from vincent.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA11182
  (5.67a/IDA-1.4.4 for <wolff@liberator.et.tudelft.nl>); Tue, 22 Jun 1993 23:47:57 +0800
Received: by vincent.cs.curtin.edu.au id AA14768
  (5.65c/IDA-1.4.4 for wolff@liberator.et.tudelft.nl); Tue, 22 Jun 1993 23:47:56 +0800
From: Patrick Mackinlay <mackinla@cs.curtin.edu.au>
Message-Id: <199306221547.AA14768@vincent.cs.curtin.edu.au>
Subject: Re: Boot rom  and other useless junk.
To: wolff@dutecai.et.tudelft.nl (Rogier Wolff)
Date: Tue, 22 Jun 1993 23:47:56 +0800 (WST)
In-Reply-To: <9306221539.AA03031@liberator.et.tudelft.nl> from "Rogier Wolff" at Jun 22, 93 05:39:15 pm
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 707       
Status: RO
X-Status: 


>I'd suggest using the approach that we've used for a design here. What
>we do is we have the x86 CPU control the reset line of the "bigger" cpu.

[...other suggestions deleted...]

Actually, we're working on the premise that the board is independant
of any other machine. The proposed board is a complete replacement
motherboard, no x86 involved. I think the majority of people have
kinda agreed that this is the best way to go. It makes the machine
a bit more expensive, but also more useful, as it can outgrow the
"host" PC.

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 wolff@dutecai.et.tudelft.nl Tue Jun 22 17:57:22 1993
Return-Path: <wolff@dutecai.et.tudelft.nl>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA03721; Tue, 22 Jun 93 17:57:18 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA26857; Tue, 22 Jun 93 09:00:04 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA04840; Tue, 22 Jun 93 08:57:01 -0700
Received: from zen.et.tudelft.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA26827; Tue, 22 Jun 93 08:59:50 -0700
Received: by zen.et.tudelft.nl (4.1/1.34JP)
          id AA04463; Tue, 22 Jun 93 17:55:21 +0200
Date: Tue, 22 Jun 93 17:55:21 +0200
From: wolff@dutecai.et.tudelft.nl (Rogier Wolff)
Message-Id: <9306221555.AA04463@zen.et.tudelft.nl>
To: riscy@pyramid.com
Subject: Re: Bootrom and other useless stuff.
Status: RO
X-Status: 


Hi again.

I think I may have made a mistake. It seems that this group is talking about
a new motherboard. I thought we were talking about an accellerator card
like thing. This may make the "bootrom" less "useless".

Take my previous mail with a grain of salt...... Sorry about the trouble....

					Roger.

P.S. Introductions:

   I'm Roger Wolff, I graduated 1.5 years ago, I am currently involved in
   getting a real time application running on a x86 add-on card.. 
   (image processing). The card has one or two Intel 960CA processors.
   These run at 33 Mhz, and two instructions per cycle on optimized code.
   (66 MIPS). However I advise using them for a workstation like environment:
   No FPU, No MMU.



 
From mackinla@cs.curtin.edu.au Tue Jun 22 08:16:27 1993
Return-Path: <mackinla@cs.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA02249; Tue, 22 Jun 93 08:16:17 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA13224; Mon, 21 Jun 93 23:19:05 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA04729; Mon, 21 Jun 93 23:16:08 -0700
Received: from marsh.cs.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA13220; Mon, 21 Jun 93 23:18:43 -0700
Received: from vincent.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA04216
  (5.67a/IDA-1.4.4 for <riscy@pyramid.com>); Tue, 22 Jun 1993 14:14:14 +0800
Received: by vincent.cs.curtin.edu.au id AA12143
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Tue, 22 Jun 1993 14:14:07 +0800
From: Patrick Mackinlay <mackinla@cs.curtin.edu.au>
Message-Id: <199306220614.AA12143@vincent.cs.curtin.edu.au>
Subject: Re: MIPS R3000 tasks available; volunteers?
To: riscy@pyramid.com
Date: Tue, 22 Jun 1993 14:14:06 +0800 (WST)
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 3513      
Status: RO
X-Status: 


>Most correspondence should be directed at the mailing list:
>
>	riscy@pyramid.com

May I suggest getting your mailing list software to include a "Reply-to:"
field? Makes following up a little easier.

>*  CPU, peripheral controller and memory
>		Allocated to: caret@pyramid.com
>	of what memory controller is available.  At this stage I am aiming
>	at using the IDT 79R3730.  To this end I am calling IDT to attempt

Just a comment here: having been in the same boat before waiting for IDT
to produce the R372x series of chips, I'd have to say that this chip is
going to be the most critical one in the whole design. Hopefully they
will produce this and make it available as planned...

>*  Keyboard controller / NV-RAM / RTC

I might just try and take this up. You mentioned the 8051 in your
previous mail, but I have a little further info. The original PC and XT
used the 8051, but all machines since have used the 8041. I know that
AMI (the BIOS people) make them pre-programmed with their PC BIOS (ie:
it's an EPROM as well), and think that this would make a nifty device
if we could get hold of it. It would obviously require re-burning the
EPROM, but I think it might be a good way to cut down on a couple of
chips. As for the NV-RAM and RTC, everything I've ever heard points to
Dallas Semi. Unfortunately, I've also heard that they advertise lots of
stuff that they never actually make. I'll look into both of these, and
see what I can come up with.

>*  SCSI bus
>		Allocated to: <no-one>
>	The SCSI bus would probably be done with something like a
>	NEC 53C94 SCSI controller.  Research needs to be done on this
>	and other available SCSI chips.  

Ok, I'm probably one of the people who pushed for this. The other SCSI
chips I've had a look at include: NCR53C7xx series (SMT and _big_),
NCR538x series (pretty dumb) and the WD33C98(?) (very buggy). One
advantage of the '94 is that it's second sourced by Emulex, NCR and
Motorola, so it should be pretty easy to get hold of. You should also
note that there's a 53CF94 which is the same device but does FAST SCSI.
Again, there are '96 chips which do wide SCSI (I think). I've been
unable to get any hard data down here though...

>*  Serial port

Might I suggest a Zilog SCC? I've had good experiences with these,
and they give you the ability to use AppleTalk (physically, anyhow)
at some stage. IMHO, we should have one SCC (or something) chip on
the motherboard itself, and use an ISA card for more "regular"
serial chips. Comments?

>*  Ethernet port
>		Allocated to: <no-one>
>	It has been suggested that we use an Am7990 (Lance) Ethernet

I probably suggested this too, but again - I don't know much about
it. I think there's an alternative in the NSC 8390(?) used on a lot
of PC ethernet cards. As I said, I'm not qualified to give an
opinion here.

>*  Video

Ok, I've accepted this idea <grin>. Anyone know if the 6845 is up
to it? What sort of a range does it have on sync signals?

>*  Diagnostics / monitor code

I'd be very interested in doing this. Obviously (I think), we'd want
some sort of an assembler for this step. See below.

>*  Cross assembler/compiler system

I've looked at this before and I think it's relatively trivial. Getting
GAS to produce R3k binaries is going to be the most important first
step, as we'll need that for the boot/debug ROM.

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 mackinla@cs.curtin.edu.au Tue Jun 22 08:17:09 1993
Return-Path: <mackinla@cs.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA02253; Tue, 22 Jun 93 08:17:01 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA13236; Mon, 21 Jun 93 23:19:50 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA04748; Mon, 21 Jun 93 23:16:52 -0700
Received: from marsh.cs.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA13230; Mon, 21 Jun 93 23:19:34 -0700
Received: from vincent.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA04216
  (5.67a/IDA-1.4.4 for <riscy@pyramid.com>); Tue, 22 Jun 1993 14:14:14 +0800
Received: by vincent.cs.curtin.edu.au id AA12143
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Tue, 22 Jun 1993 14:14:07 +0800
From: Patrick Mackinlay <mackinla@cs.curtin.edu.au>
Message-Id: <199306220614.AA12143@vincent.cs.curtin.edu.au>
Subject: Re: MIPS R3000 tasks available; volunteers?
To: riscy@pyramid.com
Date: Tue, 22 Jun 1993 14:14:06 +0800 (WST)
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 3513      
Status: RO
X-Status: 


>Most correspondence should be directed at the mailing list:
>
>	riscy@pyramid.com

May I suggest getting your mailing list software to include a "Reply-to:"
field? Makes following up a little easier.

>*  CPU, peripheral controller and memory
>		Allocated to: caret@pyramid.com
>	of what memory controller is available.  At this stage I am aiming
>	at using the IDT 79R3730.  To this end I am calling IDT to attempt

Just a comment here: having been in the same boat before waiting for IDT
to produce the R372x series of chips, I'd have to say that this chip is
going to be the most critical one in the whole design. Hopefully they
will produce this and make it available as planned...

>*  Keyboard controller / NV-RAM / RTC

I might just try and take this up. You mentioned the 8051 in your
previous mail, but I have a little further info. The original PC and XT
used the 8051, but all machines since have used the 8041. I know that
AMI (the BIOS people) make them pre-programmed with their PC BIOS (ie:
it's an EPROM as well), and think that this would make a nifty device
if we could get hold of it. It would obviously require re-burning the
EPROM, but I think it might be a good way to cut down on a couple of
chips. As for the NV-RAM and RTC, everything I've ever heard points to
Dallas Semi. Unfortunately, I've also heard that they advertise lots of
stuff that they never actually make. I'll look into both of these, and
see what I can come up with.

>*  SCSI bus
>		Allocated to: <no-one>
>	The SCSI bus would probably be done with something like a
>	NEC 53C94 SCSI controller.  Research needs to be done on this
>	and other available SCSI chips.  

Ok, I'm probably one of the people who pushed for this. The other SCSI
chips I've had a look at include: NCR53C7xx series (SMT and _big_),
NCR538x series (pretty dumb) and the WD33C98(?) (very buggy). One
advantage of the '94 is that it's second sourced by Emulex, NCR and
Motorola, so it should be pretty easy to get hold of. You should also
note that there's a 53CF94 which is the same device but does FAST SCSI.
Again, there are '96 chips which do wide SCSI (I think). I've been
unable to get any hard data down here though...

>*  Serial port

Might I suggest a Zilog SCC? I've had good experiences with these,
and they give you the ability to use AppleTalk (physically, anyhow)
at some stage. IMHO, we should have one SCC (or something) chip on
the motherboard itself, and use an ISA card for more "regular"
serial chips. Comments?

>*  Ethernet port
>		Allocated to: <no-one>
>	It has been suggested that we use an Am7990 (Lance) Ethernet

I probably suggested this too, but again - I don't know much about
it. I think there's an alternative in the NSC 8390(?) used on a lot
of PC ethernet cards. As I said, I'm not qualified to give an
opinion here.

>*  Video

Ok, I've accepted this idea <grin>. Anyone know if the 6845 is up
to it? What sort of a range does it have on sync signals?

>*  Diagnostics / monitor code

I'd be very interested in doing this. Obviously (I think), we'd want
some sort of an assembler for this step. See below.

>*  Cross assembler/compiler system

I've looked at this before and I think it's relatively trivial. Getting
GAS to produce R3k binaries is going to be the most important first
step, as we'll need that for the boot/debug ROM.

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 caret@pyramid.com Wed Jun 23 07:40:09 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA06001; Wed, 23 Jun 93 07:40:03 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06679; Tue, 22 Jun 93 22:39:56 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA03697; Tue, 22 Jun 93 22:39:41 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306230539.AA03697@sword.eng.pyramid.com>
Subject: Introductions
To: riscy@pyramid.com
Date: Tue, 22 Jun 93 22:39:41 PDT
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 


Welcome to the new subscribers of this list.

This list is intended for discussion of the hardware design and some
related software issues.   Discussion about the porting of various
operating systems should be directed to another as yet undefined
mailing list.

Following is a re-post of the current proposed specification and a list
of tasks available for work.  You are encorreaged to select tasks that
you think that you may want to do, or just supply crititsism to the
design we have.

For those of you that received it before, the spec is unchanged, however
the tasks have some changes.

This board design is intended to be covered by something similar (or
maybe the same) as the GNU Public Licence.  Until I check on the
legal's of this, it is Copyright Neil Russell with distribution in the
spirit of the GPL.  There is no tie with this project to Pyramid
Technology other than their support of the mailing list.  Pyramid is
interested in much larger systems and would not be interested in this.


Some introductions:

I'm Neil Russell, a Senior Software Engineer at Pyramid Technology in
San Jose, California.  I have many years of experience in UNIX kernel
programming and a longer but more sporadic life of digital hardware
design.  I'm not really sure why I'm organising this effort; probably
just for fun.

-- 
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 caret@pyramid.com Wed Jun 23 07:42:22 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA06007; Wed, 23 Jun 93 07:42:13 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA07897; Tue, 22 Jun 93 22:42:08 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA04363; Tue, 22 Jun 93 22:42:05 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306230542.AA04363@sword.eng.pyramid.com>
Subject: MIPS R3000 hardware design specification revision 1
To: riscy@pyramid.com
Date: Tue, 22 Jun 93 22:42:05 PDT
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

This is the first of a series of specifications for this board.
As the specification becomes more detailed and complete, it will
be re-mailed to the list.  Occasionally it will be summarized and
sent to comp.os.linux.

-----

*  Mechanical details

	The finished board must fit in a standard IBM compatible case,
	and should if possible fit in a mini-case.  The CPU may need
	one of those 486 "chip fans" or something like that in this
	case; this needs investigation.

	Because of the cost of assembly, the board should not have any
	Surface Mount Devices at all (J-lead components that can be
	socketed are ok).  Hand assembly of SMD boards is *very*
	difficult in all cases except maybe prototyping.  The cost
	of setting up and having boards assembled automatically is
	not cost effective until you get into the thousands.  I expect
	to be hand assembling the first few production runs of this
	board to save costs.

*  CPU
	IDT 79R3051E or IDT 79R3081E running at 20, 25, 33 or 40 MHz
	(probably 40MHz).

	The choice of CPU is based on price, flexibility (hardware wise)
	suitability for the project, and of course, availability.
	My preference is for the 3051E-40.  I have a price from one
	distributor for us$155 in units of 100.

	There is some difficulty in designing hardware to run at 40MHz,
	however, this will be mitigated by the use of the  IDT 79R3730
	(see below).

*  Peripheral controller
	IDT is just about to release the IDT 79R3730.  This is titled
	"Raster Image Processor".  It features:
		*  DRAM controller:
			- can drive some reasonable numbers of RAM chips;
			- can interleave banks;
			- can generate burst mode accesses;
			- can handle different sized DRAM dynamically;
			- can check parity;
		*  Has two separate buses (aside from the main bus) that
		   can handle talking to slower devices without holding
		   up the main bus.  This happens by use of a DMA controller,
		   bus sizer and FIFO's.  Each bus can have several DMA
		   running concurrently and still allow access to other
		   peripherals on the same bus;
		*  DMA logic to read and then rasterize data.  This is
		   intended for printer engines, but could easily be
		   adapted to a CRT;
		*  Individually programmable I/O pins (some of which
		   get used for parity checking);
		*  PGA, PLCC or MQUAD packages;
		*  Handles reading 8-bit EPROMS 4 bytes at a time
		   to allow the use of a single boot ROM.

	The CPU needs only to talk to the 3730 and one set of buffers
	for the RAM.  This will make a big difference to how hard it is
	to design the high speed stuff, making 40MHz probable.

	The problem is that IDT aren't going to release it until some
	time around September.  I'm working on them to get some advance
	samples and a more complete data sheet.  Until then the latest
	IDT CPU data book contains advance information.

*  32 SIMMS sockets
	The IDT 79R3730 allows the use of DRAM up to 4MB in size.
	32 SIMM sockets allows 128MBytes of RAM.  If more than one
	bank is installed, then they can be interleaved giving almost
	double the bandwidth to the memory (it reduces every 2nd
	cycle to a single cycle).  I'm guessing that using 70ns
	SIMMs that we would need 3 wait states per access.

	The SIMM sockets should handle the standard 30 pin IBM
	compatible SIMMs, for price reasons.

*  Boot EPROM
	Because of the 3730, we can get away with just one EPROM.
	Maybe two just for kicks.  Access to this is slow, so if
	speed were are problem, then code could be copied to RAM.

*  Feature selector
	Some of the I/O pins on the IDT 79R3730 should be used for
	a "feature selector".  This could allow setting things like:
		- use of parity;
		- big endian/little endian;
		- use of video;
		- diagnostic mode;
		- etc.

	This part of the design is trivial.  I expect it to just
	fall into place when the time is right.

*  Keyboard controller
	This should certainly handle IBM compatible style keyboards.
	The only way I know to do this is to use the 8051(?) micro-
	controller to drive the keyboard exactly the same way as
	every mother-board I've seen does.  This circuit should
	connect easily to the 8-bit bus of the 3730.

*  Non-Volatile-RAM and Real-Time-Clock
	This should be looked into.  The clock is almost a requirement
	but the NV-RAM could be replaced with the feature selector.

*  Serial port
	Because of the ISA bus, serial is always possible.  It might
	be a good idea, if just for debugging to have some serial
	ports on the mother-board.  If this is the case, they should
	be at least as good as 16550's.

*  ISA bus
	This is probably the hardest part, but necessary.  There are
	plenty of ASIC's out there that can handle the whole ISA spec,
	however, they are designed to interface to x86 CPU's and are
	usually surface mount.  With the possible exception of the
	-MASTER signal, the ISA spec could be implemented using not
	too much glue logic.  Remember that in the quantities that
	we would be buying in it may be cheaper to buy a handful
	of PALs than one ASIC and a few PALs to interface to the
	R3000.

	If the -MASTER signal was not implemented, no ISA device that
	does first party DMA would work (read Adaptec SCSI controllers).
	Other than Adaptec, I know of no other devices that use
	-MASTER.  Anyhow, we have a SCSI controller on the mother-board
	that can replace the Adaptec.

*  SCSI port
	It has been suggested that we use a NCR 53C94 SCSI controller
	chip.  I know nothing about this chip.  I expect that it could
	be connected to the 8-bit or 8/16-bit bus of the 3730.

*  Ethernet port
	It has been suggested that we use an Am7990 (Lance) Ethernet
	controller.  I know nothing about this chip.  I expect that it
	could be connected to the 8-bit or 8/16-bit bus of the 3730.

*  Video
	The IDT 79R3730 handles the DMA of rasters from DRAM and the
	serialization into 1, 2 or 4 bits per pixel.  This could be
	buffered to form 8-bits per pixel then fed into a suitable
	colour palette.  Then all that remains is to generate the
	pixel clock and the appropriate sync signals.  The sync stuff
	could come from a motorola 6845 or the like.  Because of the
	3730, this section should be real cheap.  If it doesn't turn out
	that way, then we should abandon this for some video controller
	on the ISA bus.  Resolutions up to 1280x1024x256 should be
	supported.

*  Floppy
	Floppy disks are not high bandwidth items.  They can and should
	be supported by some floppy only controller on the ISA bus.
	Using some cheap IDE controller with floppy connectors might
	be an even cheap solution.

	Note that this machine doesn't do DOS, so a floppy is probably
	optional in lue of a SCSI tape drive.

-- 
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 caret@pyramid.com Wed Jun 23 07:55:56 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA06025; Wed, 23 Jun 93 07:55:49 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA11251; Tue, 22 Jun 93 22:55:46 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06006; Tue, 22 Jun 93 22:55:43 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306230555.AA06006@sword.eng.pyramid.com>
Subject: MIPS R3000 tasks available; volunteers?
To: riscy@pyramid.com
Date: Tue, 22 Jun 93 22:55:42 PDT
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

We need volunteers to design various part of the hardware.  Below is a
list of tasks that need doing.  Just because some is allocated a task
doesn't mean that will still couldn't use help.  If you think you have
something to offer, feel free to assist.

Most correspondence should be directed at the mailing list:

	riscy@pyramid.com

Anything is open for discussion including the choice of CPU.

-----

*  CPU, peripheral controller and memory
		Allocated to: caret@pyramid.com
	There is no problem getting CPUs.  The memory design is a function
	of what memory controller is available.  At this stage I am aiming
	at using the IDT 79R3730.  To this end I am calling IDT to attempt
	to get advance information and samples.  When I get better information,
	most other developers will get the data sheet from me to allow design
	of their respective interfaces to this chip.

*  Keyboard controller / NV-RAM / RTC
		Allocated to: mackinla@cs.curtin.edu.au
	Research needs to be done on what is available, its cost and
	then the design of the appropriate circuit.  These devices would
	be connected to the 8-bit bus of the 3730; they would be selected
	with a chip-select and possible several address bits.

*  ISA bus
		Allocated to: <no-one>
	This one is hard.  An interface from probably the B bus of the
	3730 to the ISA backplane needs to be researched and designed.
	I figure that an ASIC for doing this such as found on any
	motherboard these days, along with the associated interface
	logic to convert R3000 control signals to x86 signals would
	be more complicated and more expensive than doing the whole
	thing in discrete logic.  Silicon Graphics Inc have information
	available on how to do this though and should be contacted.

*  SCSI bus
		Allocated to: <no-one>
	The SCSI bus would probably be done with something like a
	NEC 53C94 SCSI controller.  Research needs to be done on this
	and other available SCSI chips.  

*  Serial port
		Allocated to: <no-one>
	Some sort of serial ports should be investigated to be connected
	to the A bus of the 3730.  NS16550's would be appropriate
	but other ideas might be looked into.

*  Ethernet port
		Allocated to: <no-one>
	It has been suggested that we use an Am7990 (Lance) Ethernet
	controller.  I know nothing about this chip.  I expect that it
	could be connected to the 8-bit or 8/16-bit bus of the 3730.

*  Video
		Allocated to: <no-one>
	The IDT 79R3730 handles the DMA of rasters from DRAM and the
	serialization into 1, 2 or 4 bits per pixel.  This could be
	buffered to form 8-bits per pixel then fed into a suitable
	colour palette.  Then all that remains is to generate the
	pixel clock and the appropriate sync signals.  The sync stuff
	could come from a motorola 6845 or the like.  Because of the
	3730, this section should be real cheap.  If it doesn't turn out
	that way, then we should abandon this for some video controller
	on the ISA bus.  Resolutions up to 1280x1024x256 should be
	supported.

*  Diagnostics / monitor code
		Allocated to: caret@pyramid.com, mackinla@cs.curtin.edu.au,
				and <someone else?>
	Some initial code needs to be written to test the board and
	load the operating system.

*  Cross assembler/compiler system
		Allocated to: <no-one>
	Someone needs to compile GCC/GAS/GLD on a x86 system to cross
	compile code for the R3000.

*  Organize the schematics from the various designers.
		Allocate to: caret@pyramid.com
	This one is an interesting one.  What we need is a free CAD
	system to do schematic capture.  Someone what to write one
	by next week? :-)  My alternative suggestion is to use something
	like xfig or even to hand write them and send them to me.
	Alternatively, I use Protel; if anyone has that, then just
	send the schematic files.

*  Printed Circuit Board design
		Allocated to: <no-one>
	I will be happy to design the board.  As I mentioned above,
	I use Protel.  If someone has better, then are certainly welcome
	to design the board.

*  Investigate Copyright Issues
		Allocated to: caret@pyramid.com ???
	The GNU Public License is intended for software.  How can it
	apply to hardware?  Will the GNU guys mind us using their
	Copyright?

-- 
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 caret@pyramid.com Tue Jun 22 05:50:30 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA00287; Tue, 22 Jun 93 05:50:21 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18959; Mon, 21 Jun 93 20:52:40 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15758; Mon, 21 Jun 93 20:49:43 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306220349.AA15758@sword.eng.pyramid.com>
Subject: MIPS R3000 hardware design specification revision 1
To: riscy@pyramid.com
Date: Mon, 21 Jun 93 20:49:43 PDT
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

This is the first of a series of specifications for this board.
As the specification becomes more detailed and complete, it will
be re-mailed to the list.  Occasionally it will be summarized and
sent to comp.os.linux.

-----

*  Mechanical details

	The finished board must fit in a standard IBM compatible case,
	and should if possible fit in a mini-case.  The CPU may need
	one of those 486 "chip fans" or something like that in this
	case; this needs investigation.

	Because of the cost of assembly, the board should not have any
	Surface Mount Devices at all (J-lead components that can be
	socketed are ok).  Hand assembly of SMD boards is *very*
	difficult in all cases except maybe prototyping.  The cost
	of setting up and having boards assembled automatically is
	not cost effective until you get into the thousands.  I expect
	to be hand assembling the first few production runs of this
	board to save costs.

*  CPU
	IDT 79R3051E or IDT 79R3081E running at 20, 25, 33 or 40 MHz
	(probably 40MHz).

	The choice of CPU is based on price, flexibility (hardware wise)
	suitability for the project, and of course, availability.
	My preference is for the 3051E-40.  I have a price from one
	distributor for us$155 in units of 100.

	There is some difficulty in designing hardware to run at 40MHz,
	however, this will be mitigated by the use of the  IDT 79R3730
	(see below).

*  Peripheral controller
	IDT is just about to release the IDT 79R3730.  This is titled
	"Raster Image Processor".  It features:
		*  DRAM controller:
			- can drive some reasonable numbers of RAM chips;
			- can interleave banks;
			- can generate burst mode accesses;
			- can handle different sized DRAM dynamically;
			- can check parity;
		*  Has two separate buses (aside from the main bus) that
		   can handle talking to slower devices without holding
		   up the main bus.  This happens by use of a DMA controller,
		   bus sizer and FIFO's.  Each bus can have several DMA
		   running concurrently and still allow access to other
		   peripherals on the same bus;
		*  DMA logic to read and then rasterize data.  This is
		   intended for printer engines, but could easily be
		   adapted to a CRT;
		*  Individually programmable I/O pins (some of which
		   get used for parity checking);
		*  PGA, PLCC or MQUAD packages;
		*  Handles reading 8-bit EPROMS 4 bytes at a time
		   to allow the use of a single boot ROM.

	The CPU needs only to talk to the 3730 and one set of buffers
	for the RAM.  This will make a big difference to how hard it is
	to design the high speed stuff, making 40MHz probable.

	The problem is that IDT aren't going to release it until some
	time around September.  I'm working on them to get some advance
	samples and a more complete data sheet.  Until then the latest
	IDT CPU data book contains advance information.

*  32 SIMMS sockets
	The IDT 79R3730 allows the use of DRAM up to 4MB in size.
	32 SIMM sockets allows 128MBytes of RAM.  If more than one
	bank is installed, then they can be interleaved giving almost
	double the bandwidth to the memory (it reduces every 2nd
	cycle to a single cycle).  I'm guessing that using 70ns
	SIMMs that we would need 3 wait states per access.

	The SIMM sockets should handle the standard 30 pin IBM
	compatible SIMMs, for price reasons.

*  Boot EPROM
	Because of the 3730, we can get away with just one EPROM.
	Maybe two just for kicks.  Access to this is slow, so if
	speed were are problem, then code could be copied to RAM.

*  Feature selector
	Some of the I/O pins on the IDT 79R3730 should be used for
	a "feature selector".  This could allow setting things like:
		- use of parity;
		- big endian/little endian;
		- use of video;
		- diagnostic mode;
		- etc.

	This part of the design is trivial.  I expect it to just
	fall into place when the time is right.

*  Keyboard controller
	This should certainly handle IBM compatible style keyboards.
	The only way I know to do this is to use the 8051(?) micro-
	controller to drive the keyboard exactly the same way as
	every mother-board I've seen does.  This circuit should
	connect easily to the 8-bit bus of the 3730.

*  Non-Volatile-RAM and Real-Time-Clock
	This should be looked into.  The clock is almost a requirement
	but the NV-RAM could be replaced with the feature selector.

*  Serial port
	Because of the ISA bus, serial is always possible.  It might
	be a good idea, if just for debugging to have some serial
	ports on the mother-board.  If this is the case, they should
	be at least as good as 16550's.

*  ISA bus
	This is probably the hardest part, but necessary.  There are
	plenty of ASIC's out there that can handle the whole ISA spec,
	however, they are designed to interface to x86 CPU's and are
	usually surface mount.  With the possible exception of the
	-MASTER signal, the ISA spec could be implemented using not
	too much glue logic.  Remember that in the quantities that
	we would be buying in it may be cheaper to buy a handful
	of PALs than one ASIC and a few PALs to interface to the
	R3000.

	If the -MASTER signal was not implemented, no ISA device that
	does first party DMA would work (read Adaptec SCSI controllers).
	Other than Adaptec, I know of no other devices that use
	-MASTER.  Anyhow, we have a SCSI controller on the mother-board
	that can replace the Adaptec.

*  SCSI port
	It has been suggested that we use a NCR 53C94 SCSI controller
	chip.  I know nothing about this chip.  I expect that it could
	be connected to the 8-bit or 8/16-bit bus of the 3730.

*  Ethernet port
	It has been suggested that we use an Am7990 (Lance) Ethernet
	controller.  I know nothing about this chip.  I expect that it
	could be connected to the 8-bit or 8/16-bit bus of the 3730.

*  Video
	The IDT 79R3730 handles the DMA of rasters from DRAM and the
	serialization into 1, 2 or 4 bits per pixel.  This could be
	buffered to form 8-bits per pixel then fed into a suitable
	colour palette.  Then all that remains is to generate the
	pixel clock and the appropriate sync signals.  The sync stuff
	could come from a motorola 6845 or the like.  Because of the
	3730, this section should be real cheap.  If it doesn't turn out
	that way, then we should abandon this for some video controller
	on the ISA bus.  Resolutions up to 1280x1024x256 should be
	supported.

*  Floppy
	Floppy disks are not high bandwidth items.  They can and should
	be supported by some floppy only controller on the ISA bus.
	Using some cheap IDE controller with floppy connectors might
	be an even cheap solution.

	Note that this machine doesn't do DOS, so a floppy is probably
	optional in lue of a SCSI tape drive.

-- 
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 broadley@neurocog.lrdc.pitt.edu Wed Jun 23 08:01:45 1993
Return-Path: <broadley@neurocog.lrdc.pitt.edu>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA06046; Wed, 23 Jun 93 08:01:41 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA13738; Tue, 22 Jun 93 23:01:37 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06627; Tue, 22 Jun 93 23:01:35 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA13716; Tue, 22 Jun 93 23:01:33 -0700
Message-Id: <9306230601.AA13716@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA25704; Wed, 23 Jun 93 02:01:16 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Mips 3000 vs 486 (int and fp)
To: riscy@pyramid.com
Date: Wed, 23 Jun 1993 02:01:16 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 4318      
Status: RO
X-Status: 


Okay I'm baised I want cheap mflops at home here's my reasons:

I think the fpu version of the mips 3000 should be used.  While the mips
is an attractive architecture it will have less software available for it.
So it needs an advantage over say just buying a 486 motherboard. 

Including a fpu would:  Prevents re-implementing a floating point math 
library is c-code (which could be WELL spent in other areas), gives the 
board a BIG advantage over 486's (mainly fp), decrease price for people that 
need fpu (could buy in volume, and not have a useless fpu-less mips 3000 
laying around).

Added cost??  Not sure on this one, doesn't the fpu version also include a 
bigger cache?  (this is a BIG win if we don't have a second level cache.)

Theres a bunch of benchmarks at marlin.nosc.mil in pub/aburto, I like them
because normal people compile them with normal compilers as opposed to
"published" benchmarks:

Here's a few samples:  (notice that slower mips 3000's are adjusted for)

Heres a bunch of benchmarks (summary fp on mips 5 times faster, int
performance is similiar for a 486-66 and a mips 3000 at 40 Mhz)

Flops:  A good summmary of FP.  Mips 3000 by a factor of 4.9
	A integrated mips 3000+fpu might be faster then 3000+3010
	
System           OS, Compiler                CPU/FPU    FPU  MFLOPS(1)  REF
                                                       (MHz)               
---------------- ------------------------- ----------- ----- --------- ----
SGI 4D/420       one processor, cc -O1     R3000/R3010  40.0   18.1572    3
Gateway DX2-66   NOTE 041, LINUX 0.99      80486DX2-66  66.7    3.7000   72

Drystone mips:   An int benchmark adjusting for Mhz (33 to 40) mips 1.13 faster
    System                  OS              CPU     (MHz)  V1.1   V2.1  REF
--- ---------------------- ------------ ----------- ----- ------ ------ ---
025 Gateway DX2-66         LINUX 0.99   80486DX2     66.7    0.0   30.9   2
026 DECstation 5000/133    Ultrix 4.3   R3000        33.    31.6   29.0  11

Towers of Hanoi Puzzle Test Results. MIPS 1.70 faster
                                                        CPU   Moves in
System                OS, Compiler               CPU   (MHz)   25 usec ref
--------------------- ----------------------- -------- ------ -------- ---
SGI Indigo            NOTE 012, Irix 4.0.1A   R3000A     33.3   26.999   3
80486/50              NOTE 022                80486DX    50.0   19.056  12

Heapsort:   Mips 1.04 faster
Results as of 05 Mar 1993:                                       HIGH
                                                          CPU    HEAP
System                 OS, Compiler               CPU    (MHz)   MIPS  REF
---------------------- ------------------------ -------- ----- ------- ---
DEC DECstation 5K/240  Ultrix4.2A,cc -DUNIX -O2 R3000     40.0   22.75   9
AMI 80486DX2/66, EISA  NOTE B11, MS DOS 5.0     80486DX2  66.7   21.82  19

Nsieve: mips 1.5 times faster (for low mips)
                                                     CPU    High  Low
System           Compiler                    CPU    (MHz)   MIPS  MIPS  REF
---------------- ------------------------- ------- ------ ------ ----- ----
SGI Iris 4D/35   Irix 4.0.5, cc -DUNIX -O3 R3000     36.0   28.4  22.8   33
Gateway DX2-66   NOTE 011, LINUX 0.99      486DX2    66.7   19.3  16.9   36

Not sure if I believe the below Intel plays some strange games to
get HIGH performance (53 mips for a 486-66???? I never saw more then 30), 
but here it is... IMHO these numbers are unrealistic.  I'm sure SGI
spent less time getting those numbers then Intel did.

Specint:  486-66 1.24 times faster then mips 3000 at 40 Mhz. (adjusted)
    System                      CPU     CPU    GCC   ESP    LI   EQN  SPEC
                                       (MHz)                         int89
--- ----------------------- -------- ------- ----- ----- ----- ----- -----
005 Intel 486 66DX2         80486DX2   66.67  30.5  31.5  48.4  28.8  34.0
011 SGI 4D/320S                R3000   33.00  21.5  23.6  25.5  20.0  22.6

I'm not a hardware guy but I plan to help this project anyway I can.

-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok


 
From broadley@neurocog.lrdc.pitt.edu Wed Jun 23 08:10:37 1993
Return-Path: <broadley@neurocog.lrdc.pitt.edu>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA06070; Wed, 23 Jun 93 08:10:35 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17123; Tue, 22 Jun 93 23:10:32 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA07235; Tue, 22 Jun 93 23:10:29 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17111; Tue, 22 Jun 93 23:10:27 -0700
Message-Id: <9306230610.AA17111@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA25726; Wed, 23 Jun 93 02:10:01 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: cost of fpu?  EISA?
To: riscy@pyramid.com
Date: Wed, 23 Jun 1993 02:10:01 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 520       
Status: RO
X-Status: 

Anyone have the price of the mips chips?  A summary with price, cache, and fpu
would be great.  I'm especially interested if the FPU and non FPU chips
are identical (aside from the fpu) and what the price difference is.  

I've heard rumors about cheap EISA support chipsets anyone know how much
it would add?

-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok


 
From mackinla@cs.curtin.edu.au Wed Jun 23 09:28:27 1993
Return-Path: <mackinla@cs.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA06172; Wed, 23 Jun 93 09:28:20 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA03041; Wed, 23 Jun 93 00:28:17 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15275; Wed, 23 Jun 93 00:28:13 -0700
Received: from marsh.cs.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA03037; Wed, 23 Jun 93 00:28:00 -0700
Received: from vincent.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA20445
  (5.67a/IDA-1.4.4 for <riscy@pyramid.com>); Wed, 23 Jun 1993 15:26:04 +0800
Received: by vincent.cs.curtin.edu.au id AA16652
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Wed, 23 Jun 1993 15:25:40 +0800
From: Patrick Mackinlay <mackinla@cs.curtin.edu.au>
Message-Id: <199306230725.AA16652@vincent.cs.curtin.edu.au>
Subject: Re: Mips 3000 vs 486 (int and fp)
To: riscy@pyramid.com (R3000 PC Mailing List)
Date: Wed, 23 Jun 1993 15:25:40 +0800 (WST)
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1035      
Status: RO
X-Status: 


>Added cost??  Not sure on this one, doesn't the fpu version also include a 
>bigger cache?  (this is a BIG win if we don't have a second level cache.)

I believe it does include a larger cache.

[...lots of benchmarks deleted...]

Looking at some old mail from Steve, I see numbers of US$180 for the
40MHz '51 versus US$450 for the 40MHz '81. Obviously, the numbers have
probably changed since then, but the big gap is probably still there.
Seeing as we have a US$500 "cap" on the board, using the '81 would
severely limit the design...

On the general topic of benchmarking 486dx66's versus R3Ks: one thing
to remember is that the R3K is the _old_ MIPS architecture - equivalent
to the 386 in x86 terms. MIPS has most definitely moved onto the R4K
now, which offers >Pentium performance. Also note that the R4K _can_
execute the older 32 bit R3K code...

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 andy@resi.waldorf-gmbh.de Wed Jun 23 09:30:51 1993
Return-Path: <andy@resi.waldorf-gmbh.de>
Received: from zen.et.tudelft.nl by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA06181; Wed, 23 Jun 93 09:30:48 +0200
Received: from mail.Germany.EU.net by zen.et.tudelft.nl (4.1/1.34JP)
          id AA05471; Wed, 23 Jun 93 09:30:43 +0200
Received: by mail.Germany.EU.net(EUnetD-2.2.6.c) via EUnet
	id IB28385; Wed, 23 Jun 1993 09:29:04 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for unido
	id AA09244; Wed, 23 Jun 93 09:29:43 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Wed, 23 Jun 93 09:28:06 +0200
Message-Id: <9306230728.AA05987@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA05987; Wed, 23 Jun 93 09:28:06 +0200
To: riscy@pyramid.com, wolff@dutecai.et.tudelft.nl
Subject: Re: Bootrom and other useless stuff.
Cc: andy@resi.waldorf-gmbh.de
Status: RO
X-Status: 

Hello !

> I think I may have made a mistake. It seems that this group is talking about
> a new motherboard. I thought we were talking about an accellerator card
> like thing. This may make the "bootrom" less "useless".

Yes, it looks like that we are talking about an accellerator card.
The x86 motherboards acts as a "big cpu-controlled power supply" :-)
Nevertheless, there should be a boot prom. I just have finished
a design where slave cpus load their code from a shared ram.
I will *never* do this again !

Andy

P.S.: I might have to introduce myself too...
Please excuse my rather bad English. I'm a german, working
for Waldorf Electronics. We build high-end synthesizers and
other music stuff.
My job is hardware design and low-level programming,
mostly assembler code for 68K. I have experience with Mips-CPU's
too. We are using mips-machines for development, and I wrote
an R3000-Assembler for a 68k-based development system.



-------------------------------------------------------------------------------
Waldorf Electronics GmbH, R&D Department
c/o Andreas Busse
Neustrasse 9-12
D-5481 Waldorf
Phone:  +49 (0)2636-80294
Fax:    +49 (0)2636-80188
e-mail: andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------

 
From andy@resi.waldorf-gmbh.de Wed Jun 23 09:32:08 1993
Return-Path: <andy@resi.waldorf-gmbh.de>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA06229; Wed, 23 Jun 93 09:32:06 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA03389; Wed, 23 Jun 93 00:32:04 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15329; Wed, 23 Jun 93 00:32:01 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA03385; Wed, 23 Jun 93 00:31:57 -0700
Received: by mail.Germany.EU.net(EUnetD-2.2.6.c) via EUnet
	id IB28384; Wed, 23 Jun 1993 09:29:04 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for unido
	id AA09210; Wed, 23 Jun 93 09:16:30 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Wed, 23 Jun 93 09:14:47 +0200
Message-Id: <9306230714.AA05944@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA05944; Wed, 23 Jun 93 09:14:47 +0200
To: riscy@pyramid.com
Subject: Re: MIPS R3000 tasks available; volunteers?
Cc: andy@resi.waldorf-gmbh.de
Status: RO
X-Status: 


>*  Keyboard controller / NV-RAM / RTC
>*  Serial port
>*  Ethernet port
>*  Video

That could *ALL* be done by a single chip. Contact Chips & Technologies
and ask for the 82C512 Peripheral Controller.

Qouted from the preliminary spec sheet (of 92/4/2):

-Local Bus Interface
-Boot Prom I/F
-DRAM/VRAM Controller
-Interrupt Controller
-Ethernet Controller
-Video Timing Generator
-UART
-Parallel I/O
-Keyboard I/F
-Mouse I/F
-3 Timers
-General I/O I/F
-Speaker I/F
-Power down Logic

And it's designed to use with a IDT3051/2, 81/2 up to 40 MHz.

I believe that's what we are looking for !

Any comments ?

Cheers,
Andy
-------------------------------------------------------------------------------
Waldorf Electronics GmbH, R&D Department
c/o Andreas Busse
Neustrasse 9-12
D-5481 Waldorf
Phone:  +49 (0)2636-80294
Fax:    +49 (0)2636-80188
e-mail: andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------

 
From mackinla@cs.curtin.edu.au Wed Jun 23 09:41:47 1993
Return-Path: <mackinla@cs.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA06292; Wed, 23 Jun 93 09:41:39 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA03713; Wed, 23 Jun 93 00:41:36 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15890; Wed, 23 Jun 93 00:41:33 -0700
Received: from marsh.cs.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA03709; Wed, 23 Jun 93 00:41:22 -0700
Received: from vincent.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA20707
  (5.67a/IDA-1.4.4 for <riscy@pyramid.com>); Wed, 23 Jun 1993 15:39:21 +0800
Received: by vincent.cs.curtin.edu.au id AA16723
  (5.65c/IDA-1.4.4); Wed, 23 Jun 1993 15:39:08 +0800
From: Patrick Mackinlay <mackinla@cs.curtin.edu.au>
Message-Id: <199306230739.AA16723@vincent.cs.curtin.edu.au>
Subject: Re: MIPS R3000 tasks available; volunteers?
To: riscy@pyramid.com (R3000 PC Mailing List)
Date: Wed, 23 Jun 1993 15:39:08 +0800 (WST)
Cc: andy@resi.waldorf-gmbh.de
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 589       
Status: RO
X-Status: 


>That could *ALL* be done by a single chip. Contact Chips & Technologies
>and ask for the 82C512 Peripheral Controller.

Hmmm... C&T were supposed to make the IDT79R372x series of chips too,
and they didn't end up making the I/O controller (the most useful chip
in the series). If they did, in fact, make this chip, it'd be worth
looking at as an alternative to the 3730...

Any ideas on pricing/availability?

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 andy@resi.waldorf-gmbh.de Wed Jun 23 09:52:55 1993
Return-Path: <andy@resi.waldorf-gmbh.de>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA06355; Wed, 23 Jun 93 09:52:51 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04111; Wed, 23 Jun 93 00:52:48 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16839; Wed, 23 Jun 93 00:52:45 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04107; Wed, 23 Jun 93 00:52:42 -0700
Received: by mail.Germany.EU.net(EUnetD-2.2.6.c) via EUnet
	id IC29073; Wed, 23 Jun 1993 09:49:49 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for unido
	id AA09303; Wed, 23 Jun 93 09:41:11 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Wed, 23 Jun 93 09:39:32 +0200
Message-Id: <9306230739.AA06056@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA06056; Wed, 23 Jun 93 09:39:32 +0200
To: <broadley@neurocog.lrdc.pitt.edu>, <riscy@pyramid.com>
Subject: Re:  Mips 3000 vs 486 (int and fp)
Status: RO
X-Status: 


Hi there !

> Not sure if I believe the below Intel plays some strange games to
> get HIGH performance (53 mips for a 486-66???? I never saw more then 30), 
> but here it is... IMHO these numbers are unrealistic.  I'm sure SGI
> spent less time getting those numbers then Intel did.

I think you're right. I have seen benchmarks (from Intel, of course :-))
where an i486/33 were faster than an R3000... Have they measured nops ?

Anyway, the FPU-version of the R3051/2 called R3081 doesn't have more
cache, so far I know. And I don't think that it's faster than
a R3000/3010 combination with the same clock. The architecture is
exactly the same, only on a single die.

Andy
-------------------------------------------------------------------------------
Waldorf Electronics GmbH, R&D Department
c/o Andreas Busse
Neustrasse 9-12
D-5481 Waldorf
Phone:  +49 (0)2636-80294
Fax:    +49 (0)2636-80188
e-mail: andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------

 
From mackinla@cs.curtin.edu.au Mon Jun 21 18:24:23 1993
Return-Path: <mackinla@cs.curtin.edu.au>
Received: from liberator.et.tudelft.nl by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25560; Mon, 21 Jun 93 18:24:15 +0200
Received: from marsh.cs.curtin.edu.au by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA02692; Mon, 21 Jun 93 18:23:48 +0200
Received: from vincent.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA24953
  (5.67a/IDA-1.4.4 for <wolff@liberator.et.tudelft.nl>); Tue, 22 Jun 1993 00:23:28 +0800
Received: by vincent.cs.curtin.edu.au id AA11052
  (5.65c/IDA-1.4.4 for wolff@liberator.et.tudelft.nl); Tue, 22 Jun 1993 00:23:23 +0800
From: Patrick Mackinlay <mackinla@cs.curtin.edu.au>
Message-Id: <199306211623.AA11052@vincent.cs.curtin.edu.au>
Subject: Re: G335
To: wolff@dutecai.et.tudelft.nl (Rogier Wolff)
Date: Tue, 22 Jun 1993 00:23:23 +0800 (WST)
In-Reply-To: <9306211555.AA02671@liberator.et.tudelft.nl> from "Rogier Wolff" at Jun 21, 93 05:55:02 pm
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 689       
Status: RO
X-Status: 


>We currently have a PLASTIC chip package. I don't think that the flame
>will do it any good.....

No, the paint stripping gun is just used to heat up the hot plate...

[...lots of tips deleted...]

Sounds like you had a great time! <grin> Can't wait...

>Another thing to be careful for is that you NEED a working AVDD and Iref.
>If you have something wrong in those circuits, you'll find a way of smoking
>the chip.... :-)

I plan to smoke a couple <grin>. Its bound to happen, so why worry about
it? <grin>

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 donaldc@ug.cs.dal.ca Mon Jun 21 19:21:37 1993
Return-Path: <donaldc@ug.cs.dal.ca>
Received: from liberator.et.tudelft.nl by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25837; Mon, 21 Jun 93 19:21:34 +0200
Received: from ug.cs.dal.ca by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA02697; Mon, 21 Jun 93 19:21:31 +0200
Received: by ug.cs.dal.ca id <59>; Mon, 21 Jun 1993 14:21:22 -0300
Subject: Re: How to get a *free* Pentium poster!
From: Donald Chisholm <donaldc@ug.cs.dal.ca>
To: wolff@dutecai.et.tudelft.nl (Rogier Wolff)
Date: 	Mon, 21 Jun 1993 14:21:11 -0300
In-Reply-To: <9306211607.AA02678@liberator.et.tudelft.nl>; from "Rogier Wolff" at Jun 21, 93 1:07 pm
X-Mailer: ELM [version 2.3 PL11]
Message-Id: <93Jun21.142122adt.59@ug.cs.dal.ca>
Status: RO
X-Status: 

> In article <C8rxsG.JvG@cs.dal.ca> you wrote:
> It's not that Intel refuses to send you a poster when you're out of the
> country, but people outside the -1- country code, (you know when you'r
> abroad you dial [int access-code]-1-[your home number]) This goes for
> US and canada. They're both -1- This is why you can dial free numbers in
> the US.... 
> 
> I guess that the companies operating toll-free numbers don't want to pay 
> for satelite calls from the pacific oceans,  therefore no calls from abroad.

If you want to send me your address I'll try and get intel to send you the
package.

Don

p.s. Send me the 1-800-num as well...I can't seem to find it.

-- 
Donald Chisholm
Department of Computing Science
Dalhousie University
Halifax, Nova Scotia
Canada
--

 
From caret@pyramid.com Tue Jun 22 05:49:16 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA00241; Tue, 22 Jun 93 05:49:13 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18736; Mon, 21 Jun 93 20:52:02 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15731; Mon, 21 Jun 93 20:49:02 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306220349.AA15731@sword.eng.pyramid.com>
Subject: MIPS R3000 mailing list
To: riscy@pyramid.com
Date: Mon, 21 Jun 93 20:49:02 PDT
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

Welcome to the MIPS R3000 board project mailing list.

This mailing list has been formed for the discussion of the design of
the MIPS R3000 board that has been under recent discussion in
comp.os.linux.  You have been added automatically to this list because
you expressed some interest in helping design this device.

Requests to be added or deleted from this list should be directed to
'riscy-request@pyramid.com'.  Mail sent to 'riscy@pyramid.com' will
be forwarded to all other members of the list.

I intended this list to hardware issues and software issues relating
directly to the board.  Discussion about the porting of various
operating systems should be directed to another as yet undefined
mailing list.

-- 
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 caret@pyramid.com Tue Jun 22 05:50:42 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA00291; Tue, 22 Jun 93 05:50:33 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA19248; Mon, 21 Jun 93 20:53:23 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15787; Mon, 21 Jun 93 20:50:26 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306220350.AA15787@sword.eng.pyramid.com>
Subject: MIPS R3000 tasks available; volunteers?
To: riscy@pyramid.com
Date: Mon, 21 Jun 93 20:50:25 PDT
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

We need volunteers to design various part of the hardware.  Below is a list
of tasks that need doing.

Most correspondence should be directed at the mailing list:

	riscy@pyramid.com

Anything is open for discussion including the choice of CPU.

-----

*  CPU, peripheral controller and memory
		Allocated to: caret@pyramid.com
	There is no problem getting CPUs.  The memory design is a function
	of what memory controller is available.  At this stage I am aiming
	at using the IDT 79R3730.  To this end I am calling IDT to attempt
	to get advance information and samples.  When I get better information,
	most other developers will get the data sheet from me to allow design
	of their respective interfaces to this chip.

*  Keyboard controller / NV-RAM / RTC
		Allocated to: <no-one>
	Research needs to be done on what is available, its cost and
	then the design of the appropriate circuit.  These devices would
	be connected to the 8-bit bus of the 3730; they would be selected
	with a chip-select and possible several address bits.

*  ISA bus
		Allocated to: <no-one>
	This one is hard.  An interface from probably the B bus of the
	3730 to the ISA backplane needs to be researched and designed.
	I figure that an ASIC for doing this such as found on any
	motherboard these days, along with the associated interface
	logic to convert R3000 control signals to x86 signals would
	be more complicated and more expensive than doing the whole
	thing in discrete logic.  Silicon Graphics Inc have information
	available on how to do this though and should be contacted.

*  SCSI bus
		Allocated to: <no-one>
	The SCSI bus would probably be done with something like a
	NEC 53C94 SCSI controller.  Research needs to be done on this
	and other available SCSI chips.  

*  Serial port
		Allocated to: <no-one>
	Some sort of serial ports should be investigated to be connected
	to the A bus of the 3730.  NS16550's would be appropriate
	but other ideas might be looked into.

*  Ethernet port
		Allocated to: <no-one>
	It has been suggested that we use an Am7990 (Lance) Ethernet
	controller.  I know nothing about this chip.  I expect that it
	could be connected to the 8-bit or 8/16-bit bus of the 3730.

*  Video
		Allocated to: <no-one>
	The IDT 79R3730 handles the DMA of rasters from DRAM and the
	serialization into 1, 2 or 4 bits per pixel.  This could be
	buffered to form 8-bits per pixel then fed into a suitable
	colour palette.  Then all that remains is to generate the
	pixel clock and the appropriate sync signals.  The sync stuff
	could come from a motorola 6845 or the like.  Because of the
	3730, this section should be real cheap.  If it doesn't turn out
	that way, then we should abandon this for some video controller
	on the ISA bus.  Resolutions up to 1280x1024x256 should be
	supported.

*  Diagnostics / monitor code
		Allocated to: caret@pyramid.com and <someone else>
	Some initial code needs to be written to test the board and
	load the operating system.

*  Cross assembler/compiler system
		Allocated to: <no-one>
	Someone needs to compile GCC/GAS/GLD on a x86 system to cross
	compile code for the R3000.

*  Organize the schematics from the various designers.
		Allocate to: caret@pyramid.com
	This one is an interesting one.  What we need is a free CAD
	system to do schematic capture.  Someone what to write one
	by next week? :-)  My alternative suggestion is to use something
	like xfig or even to hand write them and send them to me.
	Alternatively, I use Protel; if anyone has that, then just
	send the schematic files.

*  Printed Circuit Board design
		Allocated to: <no-one>
	I will be happy to design the board.  As I mentioned above,
	I use Protel.  If someone has better, then are certainly welcome
	to design the board.

-- 
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 caret@pyramid.com Tue Jun 22 05:50:42 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA00291; Tue, 22 Jun 93 05:50:33 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA19248; Mon, 21 Jun 93 20:53:23 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15787; Mon, 21 Jun 93 20:50:26 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306220350.AA15787@sword.eng.pyramid.com>
Subject: MIPS R3000 tasks available; volunteers?
To: riscy@pyramid.com
Date: Mon, 21 Jun 93 20:50:25 PDT
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

We need volunteers to design various part of the hardware.  Below is a list
of tasks that need doing.

Most correspondence should be directed at the mailing list:

	riscy@pyramid.com

Anything is open for discussion including the choice of CPU.

-----

*  CPU, peripheral controller and memory
		Allocated to: caret@pyramid.com
	There is no problem getting CPUs.  The memory design is a function
	of what memory controller is available.  At this stage I am aiming
	at using the IDT 79R3730.  To this end I am calling IDT to attempt
	to get advance information and samples.  When I get better information,
	most other developers will get the data sheet from me to allow design
	of their respective interfaces to this chip.

*  Keyboard controller / NV-RAM / RTC
		Allocated to: <no-one>
	Research needs to be done on what is available, its cost and
	then the design of the appropriate circuit.  These devices would
	be connected to the 8-bit bus of the 3730; they would be selected
	with a chip-select and possible several address bits.

*  ISA bus
		Allocated to: <no-one>
	This one is hard.  An interface from probably the B bus of the
	3730 to the ISA backplane needs to be researched and designed.
	I figure that an ASIC for doing this such as found on any
	motherboard these days, along with the associated interface
	logic to convert R3000 control signals to x86 signals would
	be more complicated and more expensive than doing the whole
	thing in discrete logic.  Silicon Graphics Inc have information
	available on how to do this though and should be contacted.

*  SCSI bus
		Allocated to: <no-one>
	The SCSI bus would probably be done with something like a
	NEC 53C94 SCSI controller.  Research needs to be done on this
	and other available SCSI chips.  

*  Serial port
		Allocated to: <no-one>
	Some sort of serial ports should be investigated to be connected
	to the A bus of the 3730.  NS16550's would be appropriate
	but other ideas might be looked into.

*  Ethernet port
		Allocated to: <no-one>
	It has been suggested that we use an Am7990 (Lance) Ethernet
	controller.  I know nothing about this chip.  I expect that it
	could be connected to the 8-bit or 8/16-bit bus of the 3730.

*  Video
		Allocated to: <no-one>
	The IDT 79R3730 handles the DMA of rasters from DRAM and the
	serialization into 1, 2 or 4 bits per pixel.  This could be
	buffered to form 8-bits per pixel then fed into a suitable
	colour palette.  Then all that remains is to generate the
	pixel clock and the appropriate sync signals.  The sync stuff
	could come from a motorola 6845 or the like.  Because of the
	3730, this section should be real cheap.  If it doesn't turn out
	that way, then we should abandon this for some video controller
	on the ISA bus.  Resolutions up to 1280x1024x256 should be
	supported.

*  Diagnostics / monitor code
		Allocated to: caret@pyramid.com and <someone else>
	Some initial code needs to be written to test the board and
	load the operating system.

*  Cross assembler/compiler system
		Allocated to: <no-one>
	Someone needs to compile GCC/GAS/GLD on a x86 system to cross
	compile code for the R3000.

*  Organize the schematics from the various designers.
		Allocate to: caret@pyramid.com
	This one is an interesting one.  What we need is a free CAD
	system to do schematic capture.  Someone what to write one
	by next week? :-)  My alternative suggestion is to use something
	like xfig or even to hand write them and send them to me.
	Alternatively, I use Protel; if anyone has that, then just
	send the schematic files.

*  Printed Circuit Board design
		Allocated to: <no-one>
	I will be happy to design the board.  As I mentioned above,
	I use Protel.  If someone has better, then are certainly welcome
	to design the board.

-- 
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 jeremy@sour.sw.oz.au Wed Jun 23 11:45:42 1993
Return-Path: <jeremy@sour.sw.oz.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA06665; Wed, 23 Jun 93 11:45:30 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA19104; Wed, 23 Jun 93 02:45:27 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA01824; Wed, 23 Jun 93 02:44:23 -0700
Received: from munnari.OZ.AU 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18763; Wed, 23 Jun 93 02:42:42 -0700
Received: from sour.sw.oz.au (via basser.cs.su.oz.au) by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50)
	id AA19896; Wed, 23 Jun 1993 19:39:33 +1000 (from jeremy@sour.sw.oz.au)
Received: from sour.sw.oz.au by swift.sw.oz.au with SMTP
	id AA03979; Wed, 23 Jun 93 19:17:49 AES (5.59)
	(from jeremy@sour.sw.oz.au for riscy%pyramid.com@munnari.oz.au)
Received: by sour.sw.oz.au
	id AA05932; Wed, 23 Jun 1993 19:17:43 +1000 (5.65c/1.34)
	(from jeremy@sour.sw.oz.au for riscy@pyramid.com)
Date: Wed, 23 Jun 1993 19:17:43 +1000
From: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge)
Message-Id: <199306230917.AA05932@sour.sw.oz.au>
To: riscy@pyramid.com
Subject: MIPS R3000 - 2nd update
Status: RO
X-Status: 

Neil Russell says on comp.os.linux:
> *  I have decided that the IDT 79R3051E (the non FPU version) should be
>    used.  Since getting good pricing is hard unless quantities are high
>    I wish to stick to one type of CPU.  The board will be able to
>    accommodate the IDT 79R3081E (with the FPU and more cache) if the
>    user wishes to replace the CPU.  This would mean that full floating
>    point support routines need to be written; ho-hum.

I suspect the existing FPU emulator can form the core of a IEEE
FPU emulator.  The hard part would be replacing the 387 front end
with a mips one, assuming that the mips compiler uses a similar
subset of IEEE FPU as the 386 one.  Since they are both gcc, this
is probably the case.  Another guess: Mips FPU instructions are
not going to be as hard to interpret as 387 ones.

> *  The R3000 is able to be a little endian or a big endian machine.
>    Most operating systems that I've seen use the big endian mode, but
>    since linux runs on the 386, little endian may be more appropriate.

I don't know if it will make that much difference, but I suppose
little-endian is easiest.  Big endian will probably make talking to
ISA IO boards quite tricky.

What's your current thoughts on on-board IO?

	J

 
From drew@nag.cs.Colorado.EDU Wed Jun 23 13:27:19 1993
Return-Path: <drew@nag.cs.Colorado.EDU>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA06919; Wed, 23 Jun 93 13:27:09 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA03482; Wed, 23 Jun 93 04:27:00 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA11935; Wed, 23 Jun 93 04:26:53 -0700
Received: from nag.cs.colorado.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA03478; Wed, 23 Jun 93 04:26:51 -0700
Received: from localhost by nag.cs.Colorado.EDU with SMTP id AA21307
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Wed, 23 Jun 1993 05:26:50 -0600
Message-Id: <199306231126.AA21307@nag.cs.Colorado.EDU>
To: riscy@pyramid.com, jeremy@sour.sw.oz.au (Jeremy Fitzhardinge)
Subject: Re: MIPS R3000 - 2nd update 
In-Reply-To: Your message of "Wed, 23 Jun 1993 19:17:43 MDT."
             <199306230917.AA05932@sour.sw.oz.au> 
Date: Wed, 23 Jun 1993 05:26:50 -0600
From: Drew Eckhardt <drew@nag.cs.Colorado.EDU>
Status: RO
X-Status: 


--------

    Neil Russell says on comp.os.linux:
    > *  I have decided that the IDT 79R3051E (the non FPU version) should be
    >    used.  Since getting good pricing is hard unless quantities are high
    >    I wish to stick to one type of CPU.  The board will be able to
    >    accommodate the IDT 79R3081E (with the FPU and more cache) if the
    >    user wishes to replace the CPU.  This would mean that full floating
    >    point support routines need to be written; ho-hum.

IEEE floating point isn't *that* bad, I implemented normalization, addition,
and subtraction inside of 45 minutes for an assembler programming class, 
fast multiply and divide algorithms are well documented, and we allready
have 386 assembler source for a lot of things and 'C' source for the 
transcendental functions.
    
    I suspect the existing FPU emulator can form the core of a IEEE
    FPU emulator.  The hard part would be replacing the 387 front end
    with a mips one

Instruction decoding is trivial, it's just a matter of looking at 
the right bit fields.  The "hard part" will be translating the i386 
assembler routines for rounding, division, addition, multiplication, 
normalization, etc.

I guess this brings up an important issue : 

Software for the board, most noteably an X server and device 
drivers.  If it doesn't run Linux and X, it's an expensive paper 
weight.

We need to set some finite time deadline for the board component
specs (ie what chips, etc) so us software hackers can get started 
writing SCSI drivers, VM code, etc that our code will be done and
ready for debugging once the hardware is ready.

    > *  The R3000 is able to be a little endian or a big endian machine.
    >    Most operating systems that I've seen use the big endian mode, but
    >    since linux runs on the 386, little endian may be more appropriate.
    
    I don't know if it will make that much difference, but I suppose
    little-endian is easiest.  Big endian will probably make talking to
    ISA IO boards quite tricky.


Since this is a hardware project, we're free to wire 
up the ISA bus so bytes on 16 bit transfers are automagically rearanged,
and as long as you don't splat a short to an 8 bit address or an int
to an 8 or 16 bit address and expect the bytes to come out in a given 
order, there aren't any problems.

IMHO, software compatability should be a more important issue, ie 
with commercial shrink wrap.  If people want to consider Ultrix 
binary compatability, little endian SPIM is the only way to go. 
If there's a SYSV MIPS ABI, we should comply with the endianness
of that.

    What's your current thoughts on on-board IO?

I wouldn't be at all interested in a board that bore the burden
of abysmal ISA video performance, since I want a *useable* 
system that's more than a number cruncher.

A lot of cheap boards are avaible for ISA - ROM burners, 
internal modems, etc.  However, the question becomes : is it cheaper 
to buy Unix-capable (ie 16550 equipped serial boards) hardware on
the ISA bus where it's practical (ie, no video, SCSI, network),
or on the mainboard?

I priced serial boards with 16550AFN UARTs preinstalled, and came up
with $60-$80 for a four port board.  For a reasonable, non-busmastering
SCSI you're looking at $80 when reasonable SCSI chips that will interface
to the native DMA controller start at $5...

Serial : 

1.  2 and 4 port versions of the National Semiconductor 16550AF 
	are available from various sources (My NS databook only 
	shows the two port version, but its dated 1990), come
	in PLCC packages so they take a minimal amount of realestate,
	and the sockets are available in "normal" (ie, through
	the board and not surface mount) connectors (the 
	16550AFV on my modem is mounted like this).

2.  The 16550 has DMA interfacing signals on board, perhaps
	with modems like the World Blazer having > 20K bps raw data 
	rates and > 70K after compression, it might be a good 
	idea to take advantage of this.

3.  What *other* uarts are out there?  In microlab, we used 
	a nice DUART (same vintage as the 8250's) that was 
	buffered.

Ethernet : 

I don't know about the lance chip - using FTP, with 
LANCE equipped Decstations I can't seem to get over 
450K/sec sustained, good reason to use something else.

My old LANCE equipped HP's show similar throughput.

The HP Snakes use an Intel 82596, IBM RS6000's an Intel 82586,
and these things blaze (as in I can sustain close to 1000K/sec).

I don't have access to any reasonable NS 8390 equipped hardware,
does anyone know what these chips will do?

Something else to consider : if there were expansion slots
in these boxes (ie, there was also a native bus available) 
they might make reasonable gateway machines that didn't 
cost a whole lot of money.

Many vendors consider card slots a *server* only option.  This 
makes building gateway machines, etc somewhat expensive.  
If we have non-ISA slots (not necessarily CPU "local" bus slots, 
maybe something that works at wire-wrap compatable speeds (how 
fast *can* you go with wirewrap?)) to plug in peripherials in like a 
second ethernet port board, etc these boards would make great 
gateways.

SCSI :

What about the NCR53c700 series of chips?  FAST-SCSI,
inteligent controller using "scripts", blazingly fast.

Video :

What are S3 chips running cost wise, are they available in a PGA rather
than surface mount package, and what sort of glue would we 
need to make one work?  Opaque moves are tolerable with the 
S3, 24 bit graphics are possible, it will work at the resolutions
we want, and we could easily springboard off the work done on XS3.

--------


 
From mackinla@cs.curtin.edu.au Wed Jun 23 17:50:27 1993
Return-Path: <mackinla@cs.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA07880; Wed, 23 Jun 93 17:50:19 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA08427; Wed, 23 Jun 93 08:50:16 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08282; Wed, 23 Jun 93 08:50:09 -0700
Received: from marsh.cs.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA08394; Wed, 23 Jun 93 08:50:02 -0700
Received: from vincent.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA26539
  (5.67a/IDA-1.4.4 for <riscy@pyramid.com>); Wed, 23 Jun 1993 23:48:37 +0800
Received: by vincent.cs.curtin.edu.au id AA17783
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Wed, 23 Jun 1993 23:48:30 +0800
From: Patrick Mackinlay <mackinla@cs.curtin.edu.au>
Message-Id: <199306231548.AA17783@vincent.cs.curtin.edu.au>
Subject: Re: MIPS R3000 - 2nd update
To: riscy@pyramid.com (R3000 PC Mailing List)
Date: Wed, 23 Jun 1993 23:48:29 +0800 (WST)
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 3502      
Status: RO
X-Status: 


>IEEE floating point isn't *that* bad, I implemented normalization, addition,
>and subtraction inside of 45 minutes for an assembler programming class, 

I'm glad there are idiots out there that like FP <grin>. That means
I don't have to write the FP emulator <bigger grin>. More seriously,
I also think the idea to leverage as much i386 maths emulator code
as possible has a lot of merit.

>We need to set some finite time deadline for the board component
>specs (ie what chips, etc) so us software hackers can get started 
>writing SCSI drivers, VM code, etc that our code will be done and
>ready for debugging once the hardware is ready.

IMHO, the boot ROM is going to take the most time. What do we want
from it, a complete machine test/configuration system? I'd like to
spend a bit of time on this part of the machine, as it's quite
important to everyone... Perhaps we need two major revisions - one
version of the ROM that will let people read an image from disk and
execute it, and another, later, much more fancy one? Comments?

>IMHO, software compatability should be a more important issue, ie 
>with commercial shrink wrap.  If people want to consider Ultrix 
>binary compatability, little endian SPIM is the only way to go. 
>If there's a SYSV MIPS ABI, we should comply with the endianness
>of that.

I'll ask about this on comp.sys.mips if no one's beaten me to it.
If I remember right, both SGIs and DECStations are little-endian,
but I could be wrong. Also, seeing as the chips are switchable,
it's a pretty easy thing to allow both configurations with a little
bit of logic (although this causes obvious software problems).
Neil, what happens with the boot PROM interface: can it be set
to feed the CPU with either byte order?

>3.  What *other* uarts are out there?  In microlab, we used 
>	a nice DUART (same vintage as the 8250's) that was 
>	buffered.

Steve has been looking at these for a while. I believe he'd
gotten close to the "best" serial port he could find. Steve?

>The HP Snakes use an Intel 82596, IBM RS6000's an Intel 82586,
>and these things blaze (as in I can sustain close to 1000K/sec).

As far as I know, this Intel thingo is SMT, and it also runs
at 50MHz...

>maybe something that works at wire-wrap compatable speeds (how 
>fast *can* you go with wirewrap?)) to plug in peripherials in like a 

About 16MHz is the practical limit. I know, I've tried <grin>.

>What about the NCR53c700 series of chips?  FAST-SCSI,
>inteligent controller using "scripts", blazingly fast.

Again, SMT. They're expensive too. This seems to be the trend with
any of the faster chips. Believe me, the chips currently on the
design are pretty much the best you can do for this machine. They're
all relatively cheap and fairly easy to get hold of. I've said before,
I don't know much about Enet chips, so I'm open to advice here, but
I think the SCSI is pretty much right...

>What are S3 chips running cost wise, are they available in a PGA rather
>than surface mount package, and what sort of glue would we 

All the S3 chips that I managed to find out about are SMT. They _don't_
plan to make PGA versions. Again, Steve's got some opinions about VGA
chips, and I think he's right. I think we'd do well to stay away from
complicated stuff like these things, and just shoot for a straight
framebuffer.

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 calica@cae.wisc.edu Wed Jun 23 17:50:40 1993
Return-Path: <calica@cae.wisc.edu>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA07884; Wed, 23 Jun 93 17:50:33 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA08435; Wed, 23 Jun 93 08:50:30 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08368; Wed, 23 Jun 93 08:50:27 -0700
Received: from serv0.cae.wisc.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA08431; Wed, 23 Jun 93 08:50:24 -0700
Received: from hprisc-25.cae.wisc.edu by serv0.cae.wisc.edu (4.1/25)
	id AA15008; Wed, 23 Jun 93 10:49:11 CDT
Received: by hprisc-25.cae.wisc.edu (16.8/client-1.3)
	id AA10590; Wed, 23 Jun 93 10:51:47 -0500
From: Carlo J. Calica <calica@cae.wisc.edu>
Message-Id: <9306231551.AA10590@hprisc-25.cae.wisc.edu>
Subject: Re: NEW 64-bit RISC PC CPUs forsale, 1yr warranty (fwd)
To: riscy@pyramid.com
Date: Wed, 23 Jun 93 10:51:47 CDT
Mailer: Elm [revision: 66.36.1.2]
Status: RO
X-Status: 

Ok, what follows is an ad the a MIPS R4x00 board.  Thought you guys may
find it interesting.  Hopefully the cost will be a bit less.


> 
>                          Stephen Gaudet
>                               InCo
>                     102 Tide Mill Rd Suite 6
>                         Hampton, NH 03842
>                          ph:603-926-0300
>                         fax:603-926-0301
> 
> 
> 
> Hello, 
> 
> 
> 
> 
>      I would like to tell you about the Carrera R4x00, the first
> RISC based PC motherboard.  The Carrera R4x00 is a leading edge
> product from Carrera Computers.  The Carrera motherboard uses the
> latest in a continuing series of high performance CPU's from MIPs
> Technologies.  The CPU is the industry's first 64-bit RISC
> microprocessor and is compatible with popular PC, as well as UNIX,
> application and operating system software.  The Carrera R4x00 is
> the choice platform to run Microsoft's Windows NT, as well as USL's
> UNIX.  All this power to in a standard AT sized motherboard or
> "baby AT" the VIPER R4000PC-50!  The Mips series of processors are
> capable of running at clock speeds from 50 MHz to 200 MHz, with
> all generations of the R4x00PC microprocessors guaranteed pin
> compatible.
>      The Carrera R4x00 has several ports embedded for easy
> integration.  For example, we have included an industry standard
> SCSI-2 interface to allow access to a wide variety SCSI peripherals
> such as magnetic disk drives, CD-ROMs, tape drives, etc...  If you
> prefer to use the Carrera R4x00 as a workstation or a file server,
> an Ethernet port has been designed in to allow network
> connectivity.  We have also included common serial/parallel ports,
> keyboard/mouse ports and floppy disk controller to make integration
> a snap!  
> 
>                   Pentium vs. RISC Architecture
> 
>                          Pentium        R4x00
> 
> Data bus                 64-bit         64-bit
> Address bus              32-bit         64-bit
> Speed(MHz)               60-100         100-200
> Transistors(millions)    3.2            1.8
> Registers                32-bit         64-bit
> Memory architecture      Segmented      Linear
> Instruction type         CISC           RISC
> Cache                    2x8K           2x8K
> 2x16K
> Power                    5V             3.3V
> 
> Available Now            NO             YES
> 
> 
>                   Pentium vs. R4000 performance
> 
>           Dhrystones | SPECint92 | SPECfp92 | PowerMeter 2.0
> Pentium-66   101.2      65           57         46.4
> R4000-100    92.2       62           63         56
> R4400-150    135.9      82           86         78.9
> 
> 
>                R4000, VIPER R4000 & R4400 Features
> 
>      Processor:     64-bit MIPs R4000PC-50, 16K internal cache
>                     64-bit MIPs R4400PC-50, 32K internal cache
>      Memory Bus:    128-bit
>      Processor Bus: 64-bit
>      I/O Bus:       32-bit
>      Main Memory:   16MB-256MB (R4x00 8 mem exp slots)
>                     16MB-128MB (VIPER 4 mem exp slots)
>      EISAbus Slots: Four (R4x00)
>                     Two  (VIPER)
> 
>                       Embedded Controllers
> 
>      SCSI-2         Transfers up to 10MBs/sec
>      Ethernet       Transfers up to 10Mbs/sec
>      Video          1280 x 1024 with 256 colors
>      Serial         (2) RS-232C Compatible
>      Parallel       Centronics Compatible
>      Keyboard       IBM PS/2 Compatible
>      Mouse          IBM Compatible
>      Floppy         IBM Compatible
> 
>                         Operating Systems
> 
>      Mircosoft Windows NT
>      UNIX Systems Labs System VR4
> 
> 
>      At the heart of any powerful "Windowing" computer is the video
> subsystem.  The CHEETAH "local bus" video accelerator delivers
> astounding speed at 9,000,000 pixels per second (unaligned bitbit)
> without waiting around.  However, our JAGUAR VXL 485 "local bus"
> video accelerator is unlike any other video controller.  The JAGUAR
> is a 64-bit design and takes full advantage of the COBRA's 64-bit
> MIPs R4x00 RISC processor and 64-bit data bus.  System resources
> are managed effectively and efficiently.  The on-board processor
> enable the JAGUAR to preform graphics intensive operations as much
> as ten times faster than typical 32-bit graphics cards.  Most local
> bus based systems simply put the controller next to the processor. 
> The JAGUAR, is placed near the main memory so that other
> input/output devices also gain access to the processor.  This is
> critical for graphics based Windows NT applications.  Video
> operations can take place while other input/output processors occur
> simultaneously, without penalty!  This allows you to have both an
> operating system software AND hardware, that are truly
> multitasking!
> 
>              JAGUAR VXL 485A Features (ARCset Type)
>      
> Resolutions:   640 x 480, 256 colors, 65,536 colors & 16,777,216
>                colors
>                800 x 600, 256 colors, 65,536 colors & 16,777,216
>                colors
>                1024 x 768, 256 colors & 65,536 colors
>                1152 x 900, 256 colors & 65,536 colors
>                1280 x 1024, 256 colors
> Graphics Chipset: 64-bit JAGUAR ASIC
> RAM:              2Mbytes, expandable to 4 Mbytes, VRAM, 80ns
> RAMDAC:           Brooktree DT485KPJ110
> Test scroll rate: 100,000 lines per second
> Unaligned BitBit: 45,000,000 pixels per second
> 
> 
>                              Pricing
> 
> Cobra R4000PC-50         $4,595.00 
> * Motherboard Set                  
> 
> Cobra R4400PC-50         $5,295.00
> * Motherboard Set
> 
> Viper R4000PC-50         $2,995.00
> Motherboard
> 
> Viper R4400PC-50         $3,495.00
> Motherboard
> 
> GX Jaguar Video Board    $1,995.00
> 
>      * Mother bd set include the Cheetah color color bd, if you
> want the Jaguar add $600. to the total cost.
> 
>      Trade-ins will be evaluated.  College discounts are also
> available.  Special pricing for OEM/VARs.
> 
>      InCo is very proud to be the Master Distributor of Carrera's
> full line of products.  If you have any questions please call or
> contact me.
> 
> Thank you,
> 
> Stephen Gaudet      ph:603-926-0300     fax:603-926-0301
> InCo                          e-mail:sjg@world.std.com
> 102 Tide Mill Rd Suite 6
> 
> 
> 


--
 /------------------------------+--------------------------------------\
| Carlo J. Calica               | Linux:  Choice of the GNU Generation  |
|     calica@cae.wisc.edu       | Dittos from the People's              | 
 \ University of Wisconsin      | Republic of Madison                  / 

 
From tor@tss.no Wed Jun 23 18:40:33 1993
Return-Path: <tor@tss.no>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA07957; Wed, 23 Jun 93 18:40:30 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15713; Wed, 23 Jun 93 09:40:27 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA13982; Wed, 23 Jun 93 09:40:23 -0700
Received: from benoni.Uit.No 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15677; Wed, 23 Jun 93 09:40:22 -0700
Received: from benoni by ppenoni.uit.no with SMTP (PP) 
          id <16468-0@ppenoni.uit.no>; Wed, 23 Jun 1993 18:40:17 +0000
Received: from unas.tss.no 
          by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) 
          id AAbenoni16464; Wed, 23 Jun 1993 18:40:15 +0200
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA07275;
          Wed, 23 Jun 93 18:34:46 +0200
Message-Id: <9306231634.AA07275@unas.tss.no>
From: tor@tss.no (Tor Arntsen)
Date: Wed, 23 Jun 1993 18:34:45 +0200
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: riscy@pyramid.com
Subject: Re: MIPS R3000 - 2nd update
Status: RO
X-Status: 

On Jun 23, 11:48pm, Patrick Mackinlay wrote:
[...]
> I'll ask about this on comp.sys.mips if no one's beaten me to it.
> If I remember right, both SGIs and DECStations are little-endian,
> but I could be wrong. Also, seeing as the chips are switchable,
> it's a pretty easy thing to allow both configurations with a little
> bit of logic (although this causes obvious software problems).
> Neil, what happens with the boot PROM interface: can it be set
> to feed the CPU with either byte order?

SGI is big-endian.

Tor

 
From pham@pX4.stfx.ca Wed Jun 23 20:33:55 1993
Return-Path: <pham@pX4.stfx.ca>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA08148; Wed, 23 Jun 93 20:33:49 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA02624; Wed, 23 Jun 93 11:33:44 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02598; Wed, 23 Jun 93 11:33:37 -0700
Received: from pX4.StFX.CA 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA02620; Wed, 23 Jun 93 11:33:34 -0700
Received: by pX4.stfx.ca (5.65/DEC-Ultrix/4.3)
	id AA12585; Wed, 23 Jun 1993 15:33:31 -0300
Message-Id: <9306231833.AA12585@pX4.stfx.ca>
From: Hai Pham <pham@pX4.stfx.ca>
Date: Wed, 23 Jun 1993 15:33:29 -0300
To: riscy@pyramid.com
Subject: Re: cost of fpu?  EISA?
Status: RO
X-Status: 

On Jun 23,  2:10, Bill Broadley <broadley@neurocog.lrdc.pitt.edu> wrote:
>
>I've heard rumors about cheap EISA support chipsets anyone know how much
>it would add?
>

If we are going to build this mother board, I was thinking that it might
be wise to have a slot or two (sort of like a local bus or a Mac's CPU
slot) which allows high speed access to memory and the CPU.  We may
eventually want to build upgrade CPU cards, or co-processor(s), or
whatever.  The point is, from past experience, no matter how well designed
a mother board is initially, someone will find a need to add faster
components to it later on and having to do that thru an ISA slot will be a
real liability.  So I think if having such a thing doesn't add too much to
the complexity and/or cost of the mother board, we should give it serious
thought.

hai
pham@px1.stfx.ca



 
From caret@pyramid.com Wed Jun 23 23:09:34 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA08601; Wed, 23 Jun 93 23:09:31 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA29347; Wed, 23 Jun 93 14:09:29 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA27952; Wed, 23 Jun 93 14:09:21 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306232109.AA27952@sword.eng.pyramid.com>
Subject: Re: cost of fpu?  EISA?
To: riscy@pyramid.com
Date: Wed, 23 Jun 93 14:09:21 PDT
In-Reply-To: <9306230610.AA17111@gossip.pyramid.com>; from "Bill Broadley" at Jun 23, 93 2:10 am
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

> Anyone have the price of the mips chips?  A summary with price, cache, and fpu
> would be great.  I'm especially interested if the FPU and non FPU chips
> are identical (aside from the fpu) and what the price difference is.  

Going from memory (I'm at USENIX and my notes are at home):
	79R3051E-20	$79	(non-FPU, 4k I-cache, 8k D-cache)
	79R3051E-40	$155	(non-FPU, 4k I-cache, 8k D-cache)
	79R3081E-40	$297	(FPU, 8k I-cache, 16k D-cache)
I have prices for all of the various speeds and packages but that's all
I can remember.

-- 
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 @serv0.cae.wisc.edu:hprisc-12!caret@pyramid.com Wed Jun 23 23:24:08 1993
Return-Path: <@serv0.cae.wisc.edu:hprisc-12!caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA08665; Wed, 23 Jun 93 23:23:51 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA01436; Wed, 23 Jun 93 14:23:48 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA00440; Wed, 23 Jun 93 14:23:46 -0700
Received: from serv0.cae.wisc.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA01432; Wed, 23 Jun 93 14:23:44 -0700
Received: from hprisc-12.cae.wisc.edu by serv0.cae.wisc.edu (4.1/25)
	id AA21283; Wed, 23 Jun 93 16:22:31 CDT
Received: by hprisc-12.cae.wisc.edu (16.8/client-1.3)
	id AA20388; Wed, 23 Jun 93 16:25:07 -0500
Received: from hprisc-12 with uucp; Wed, 23 Jun 93 16:19:37
Received: from gossip.pyramid.com by serv0.cae.wisc.edu (4.1/25)
	id AA21255; Wed, 23 Jun 93 16:19:35 CDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA29347; Wed, 23 Jun 93 14:09:29 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA27952; Wed, 23 Jun 93 14:09:21 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306232109.AA27952@sword.eng.pyramid.com>
Subject: Re: cost of fpu?  EISA?
To: riscy@pyramid.com
Date: Wed, 23 Jun 93 14:09:21 PDT
In-Reply-To: <9306230610.AA17111@gossip.pyramid.com>; from "Bill Broadley" at Jun 23, 93 2:10 am
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

> Anyone have the price of the mips chips?  A summary with price, cache, and fpu
> would be great.  I'm especially interested if the FPU and non FPU chips
> are identical (aside from the fpu) and what the price difference is.  

Going from memory (I'm at USENIX and my notes are at home):
	79R3051E-20	$79	(non-FPU, 4k I-cache, 8k D-cache)
	79R3051E-40	$155	(non-FPU, 4k I-cache, 8k D-cache)
	79R3081E-40	$297	(FPU, 8k I-cache, 16k D-cache)
I have prices for all of the various speeds and packages but that's all
I can remember.

-- 
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 calica@cae.wisc.edu Wed Jun 23 23:30:23 1993
Return-Path: <calica@cae.wisc.edu>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA08680; Wed, 23 Jun 93 23:30:19 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA03220; Wed, 23 Jun 93 14:30:16 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA01651; Wed, 23 Jun 93 14:30:14 -0700
Received: from serv0.cae.wisc.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA03150; Wed, 23 Jun 93 14:30:12 -0700
Received: from hprisc-12.cae.wisc.edu by serv0.cae.wisc.edu (4.1/25)
	id AA21421; Wed, 23 Jun 93 16:29:00 CDT
Received: by hprisc-12.cae.wisc.edu (16.8/client-1.3)
	id AA20444; Wed, 23 Jun 93 16:31:36 -0500
From: Carlo J. Calica <calica@cae.wisc.edu>
Message-Id: <9306232131.AA20444@hprisc-12.cae.wisc.edu>
Subject: Re: cost of fpu?  EISA?
To: riscy@pyramid.com
Date: Wed, 23 Jun 93 16:31:36 CDT
Mailer: Elm [revision: 66.36.1.2]
Status: RO
X-Status: 

> Going from memory (I'm at USENIX and my notes are at home):
> 	79R3051E-20	$79	(non-FPU, 4k I-cache, 8k D-cache)
> 	79R3051E-40	$155	(non-FPU, 4k I-cache, 8k D-cache)
> 	79R3081E-40	$297	(FPU, 8k I-cache, 16k D-cache)
> I have prices for all of the various speeds and packages but that's all
> I can remember.
> 
So we're looking at a $150 price difference.  But it also doubles the cache.
Personally I'm in favor of dropping Ethernet and video for the FPU.  If we
keep the ISA video we retain the ability to use a somewhat modified XFree
rather than rewriting it.  I also have no use for Ethernet either.  SCSI
should be kept though.  Where else can we cut cost a little to get the FPU?
Or should we increase the cap to <$600 with the FPU. 

--
 /------------------------------+--------------------------------------\
| Carlo J. Calica               | Linux:  Choice of the GNU Generation  |
|     calica@cae.wisc.edu       | Dittos from the People's              | 
 \ University of Wisconsin      | Republic of Madison                  / 

 
From mackinla@cs.curtin.edu.au Tue Jun 22 08:16:27 1993
Return-Path: <mackinla@cs.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA02249; Tue, 22 Jun 93 08:16:17 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA13224; Mon, 21 Jun 93 23:19:05 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA04729; Mon, 21 Jun 93 23:16:08 -0700
Received: from marsh.cs.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA13220; Mon, 21 Jun 93 23:18:43 -0700
Received: from vincent.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA04216
  (5.67a/IDA-1.4.4 for <riscy@pyramid.com>); Tue, 22 Jun 1993 14:14:14 +0800
Received: by vincent.cs.curtin.edu.au id AA12143
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Tue, 22 Jun 1993 14:14:07 +0800
From: Patrick Mackinlay <mackinla@cs.curtin.edu.au>
Message-Id: <199306220614.AA12143@vincent.cs.curtin.edu.au>
Subject: Re: MIPS R3000 tasks available; volunteers?
To: riscy@pyramid.com
Date: Tue, 22 Jun 1993 14:14:06 +0800 (WST)
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 3513      
Status: RO
X-Status: 


>Most correspondence should be directed at the mailing list:
>
>	riscy@pyramid.com

May I suggest getting your mailing list software to include a "Reply-to:"
field? Makes following up a little easier.

>*  CPU, peripheral controller and memory
>		Allocated to: caret@pyramid.com
>	of what memory controller is available.  At this stage I am aiming
>	at using the IDT 79R3730.  To this end I am calling IDT to attempt

Just a comment here: having been in the same boat before waiting for IDT
to produce the R372x series of chips, I'd have to say that this chip is
going to be the most critical one in the whole design. Hopefully they
will produce this and make it available as planned...

>*  Keyboard controller / NV-RAM / RTC

I might just try and take this up. You mentioned the 8051 in your
previous mail, but I have a little further info. The original PC and XT
used the 8051, but all machines since have used the 8041. I know that
AMI (the BIOS people) make them pre-programmed with their PC BIOS (ie:
it's an EPROM as well), and think that this would make a nifty device
if we could get hold of it. It would obviously require re-burning the
EPROM, but I think it might be a good way to cut down on a couple of
chips. As for the NV-RAM and RTC, everything I've ever heard points to
Dallas Semi. Unfortunately, I've also heard that they advertise lots of
stuff that they never actually make. I'll look into both of these, and
see what I can come up with.

>*  SCSI bus
>		Allocated to: <no-one>
>	The SCSI bus would probably be done with something like a
>	NEC 53C94 SCSI controller.  Research needs to be done on this
>	and other available SCSI chips.  

Ok, I'm probably one of the people who pushed for this. The other SCSI
chips I've had a look at include: NCR53C7xx series (SMT and _big_),
NCR538x series (pretty dumb) and the WD33C98(?) (very buggy). One
advantage of the '94 is that it's second sourced by Emulex, NCR and
Motorola, so it should be pretty easy to get hold of. You should also
note that there's a 53CF94 which is the same device but does FAST SCSI.
Again, there are '96 chips which do wide SCSI (I think). I've been
unable to get any hard data down here though...

>*  Serial port

Might I suggest a Zilog SCC? I've had good experiences with these,
and they give you the ability to use AppleTalk (physically, anyhow)
at some stage. IMHO, we should have one SCC (or something) chip on
the motherboard itself, and use an ISA card for more "regular"
serial chips. Comments?

>*  Ethernet port
>		Allocated to: <no-one>
>	It has been suggested that we use an Am7990 (Lance) Ethernet

I probably suggested this too, but again - I don't know much about
it. I think there's an alternative in the NSC 8390(?) used on a lot
of PC ethernet cards. As I said, I'm not qualified to give an
opinion here.

>*  Video

Ok, I've accepted this idea <grin>. Anyone know if the 6845 is up
to it? What sort of a range does it have on sync signals?

>*  Diagnostics / monitor code

I'd be very interested in doing this. Obviously (I think), we'd want
some sort of an assembler for this step. See below.

>*  Cross assembler/compiler system

I've looked at this before and I think it's relatively trivial. Getting
GAS to produce R3k binaries is going to be the most important first
step, as we'll need that for the boot/debug ROM.

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 caret@pyramid.com Wed Jun 23 23:34:55 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA08687; Wed, 23 Jun 93 23:34:47 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA03985; Wed, 23 Jun 93 14:34:45 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02392; Wed, 23 Jun 93 14:34:42 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306232134.AA02392@sword.eng.pyramid.com>
Subject: Re: MIPS R3000 - 2nd update
To: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge)
Date: Wed, 23 Jun 93 14:34:41 PDT
Cc: riscy@pyramid.com
In-Reply-To: <199306230917.AA05932@sour.sw.oz.au>; from "Jeremy Fitzhardinge" at Jun 23, 93 7:17 pm
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

> Neil Russell says on comp.os.linux:
> > *  I have decided that the IDT 79R3051E (the non FPU version) should be
> >    used.  Since getting good pricing is hard unless quantities are high
> >    I wish to stick to one type of CPU.  The board will be able to
> >    accommodate the IDT 79R3081E (with the FPU and more cache) if the
> >    user wishes to replace the CPU.  This would mean that full floating
> >    point support routines need to be written; ho-hum.
> 
> I suspect the existing FPU emulator can form the core of a IEEE
> FPU emulator.  The hard part would be replacing the 387 front end
> with a mips one, assuming that the mips compiler uses a similar
> subset of IEEE FPU as the 386 one.  Since they are both gcc, this
> is probably the case.  Another guess: Mips FPU instructions are
> not going to be as hard to interpret as 387 ones.

FPU code is not that hard to write; I've done it before.  There seems to
be a fairly large amount of people wanting the FPU though.  That decision
doesn't need to be made until we do purchasing.

> > *  The R3000 is able to be a little endian or a big endian machine.
> >    Most operating systems that I've seen use the big endian mode, but
> >    since linux runs on the 386, little endian may be more appropriate.
> 
> I don't know if it will make that much difference, but I suppose
> little-endian is easiest.  Big endian will probably make talking to
> ISA IO boards quite tricky.

I don't like the idea of hardware swapping the bits, so this favours
little endian, however, RISCos is big endian and has a few ISA bus
slots; so the software must swap the bytes itself; Mmmm, this is the
RISC way, after all...


-- 
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 caret@pyramid.com Wed Jun 23 23:50:48 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA08714; Wed, 23 Jun 93 23:50:41 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06887; Wed, 23 Jun 93 14:50:37 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA04704; Wed, 23 Jun 93 14:50:34 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306232150.AA04704@sword.eng.pyramid.com>
Subject: Re: MIPS R3000 - 2nd update
To: riscy@pyramid.com
Date: Wed, 23 Jun 93 14:50:34 PDT
In-Reply-To: <199306231126.AA21307@nag.cs.Colorado.EDU>; from "Drew Eckhardt" at Jun 23, 93 5:26 am
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

> Software for the board, most noteably an X server and device 
> drivers.  If it doesn't run Linux and X, it's an expensive paper 
> weight.
> 
> We need to set some finite time deadline for the board component
> specs (ie what chips, etc) so us software hackers can get started 
> writing SCSI drivers, VM code, etc that our code will be done and
> ready for debugging once the hardware is ready.

That is kind of difficult right now.  We still have no-one interested in
doing one of the harder tasks on the board, notable the ISA interface.
Once there are people allocated to all the tasks, the design shouldn't
take long.  I figure we a looking at about October for the first
batch of boards.

> Since this is a hardware project, we're free to wire 
> up the ISA bus so bytes on 16 bit transfers are automagically rearanged,
> and as long as you don't splat a short to an 8 bit address or an int
> to an 8 or 16 bit address and expect the bytes to come out in a given 
> order, there aren't any problems.

I'm not in favour of doing this kind of byte swapping.  If this issue
really matters, then we should definately run the OS in little
endian mode.  If the OS must run in big endian mode then the software
would have to byte swap for 16 bit accesses; this is the RISC way after
all...  BTW, to stop any possible mis-interpretations before they
start, the CPU must be placed in either big or little endian mode
when its reset.  It cannot be changed later.

> IMHO, software compatability should be a more important issue, ie 
> with commercial shrink wrap.  If people want to consider Ultrix 
> binary compatability, little endian SPIM is the only way to go. 
> If there's a SYSV MIPS ABI, we should comply with the endianness
> of that.

Agreed.

> I wouldn't be at all interested in a board that bore the burden
> of abysmal ISA video performance, since I want a *useable* 
> system that's more than a number cruncher.

Video, SCSI and ethernet are things that I'm not going to give up
on easily.

-- 
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 caret@pyramid.com Thu Jun 24 00:03:03 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA08779; Thu, 24 Jun 93 00:02:55 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA08166; Wed, 23 Jun 93 15:02:50 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA07359; Wed, 23 Jun 93 15:02:45 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306232202.AA07359@sword.eng.pyramid.com>
Subject: Re: MIPS R3000 hardware design specification revision 1
To: drew@nag.cs.Colorado.EDU (Drew Eckhardt)
Date: Wed, 23 Jun 93 15:02:45 PDT
Cc: riscy@pyramid.com
In-Reply-To: <199306231347.AA00538@nag.cs.Colorado.EDU>; from "Drew Eckhardt" at Jun 23, 93 7:47 am
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

Drew Eckhardt writes:

> Assuming that "average" users will be using something like 1024x768x256
> at 60hz, you'll be DMAing  45M a second.  Some people have problems at 
> < 72hz, which is 54M bytes a second.  Up the resolution to 1280x1024x256
> and you're looking at 90M/sec.
> 
> With 70ns DRAM, assuming that we are 2-way interleaved we can't get more
> than about 100M/sec.  So, we'd loose between 50 and 90 percent of our 
> memory bandwidth, our biggest performance bottleneck, if we put main
> memory on the same bus.

This is a good point; this certainly points to using VRAM.  At present there
are far too many unknowns about the video section to really address this
issue.  Someone needs to do some research as to what cheap video stuff
there is.  Using the S3 chip (as some one suggested) may be a good idea,
if we can get it in a J-lead or PGA package.  (See comments on surface
mount in the spec).

> Can the IDT 79R3730 handle DRAM on one of the other busses?  

Yes, but what I expect that your thinking is to put DRAM on another
bus to releive contention on the main bus.  That is not possible.
We should use VRAM for that.

> How expensive is VRAM?  Since it's inherently dual ported, you get 
> a lot more CPU->video memory bandwidth than you do when you're trying
> to share DRAM with video serializers that want 45-90M/sec, making 
> bitblits (ie, text drawing, the moving of windows, etc). 

I think its 3-4 times the cost of DRAM; once again I'm guessing...

-- 
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 caret@pyramid.com Thu Jun 24 00:15:24 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA08799; Thu, 24 Jun 93 00:15:22 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA10148; Wed, 23 Jun 93 15:15:07 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08576; Wed, 23 Jun 93 15:15:00 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306232215.AA08576@sword.eng.pyramid.com>
Subject: Re: MIPS R3000 - 2nd update
To: riscy@pyramid.com
Date: Wed, 23 Jun 93 15:15:00 PDT
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

> Neil, what happens with the boot PROM interface: can it be set
> to feed the CPU with either byte order?

Duno.  I'll check.  I'd be surprised if the 3730 didn't just take
care of it.

> >3.  What *other* uarts are out there?  In microlab, we used 
> >	a nice DUART (same vintage as the 8250's) that was 
> >	buffered.
> 
> Steve has been looking at these for a while. I believe he'd
> gotten close to the "best" serial port he could find. Steve?

The best I've seen is the Motorola MC68302, which has 3 serial ports
capable of some very good speed.  However, this guy may be a little
too expensive, since its also has a 68000 CPU core in it.

> All the S3 chips that I managed to find out about are SMT. They _don't_
> plan to make PGA versions. Again, Steve's got some opinions about VGA
> chips, and I think he's right. I think we'd do well to stay away from
> complicated stuff like these things, and just shoot for a straight
> framebuffer.

If the required video bandwidth is going to his the main bus hard
(which I think t will) we will need something extra to run the
VRAM.  There are plenty of chips that can do this, but they are
mostly too expensive, or are SMT.  The only exception that comes
to mind is the TMS 34010, which can be has for us$20 in small quantities
and does come in J-lead.  This issue really needs some serious
investigation.

-- 
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 caret@pyramid.com Thu Jun 24 00:26:33 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA08812; Thu, 24 Jun 93 00:26:26 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA12418; Wed, 23 Jun 93 15:26:15 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA10208; Wed, 23 Jun 93 15:26:12 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306232226.AA10208@sword.eng.pyramid.com>
Subject: Re: cost of fpu?  EISA?
To: riscy@pyramid.com
Date: Wed, 23 Jun 93 15:26:11 PDT
In-Reply-To: <9306231833.AA12585@pX4.stfx.ca>; from "Hai Pham" at Jun 23, 93 3:33 pm
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

> >I've heard rumors about cheap EISA support chipsets anyone know how much
> >it would add?
> >
> 
> If we are going to build this mother board, I was thinking that it might
> be wise to have a slot or two (sort of like a local bus or a Mac's CPU
> slot) which allows high speed access to memory and the CPU.  We may
> eventually want to build upgrade CPU cards, or co-processor(s), or
> whatever.  The point is, from past experience, no matter how well designed
> a mother board is initially, someone will find a need to add faster
> components to it later on and having to do that thru an ISA slot will be a
> real liability.  So I think if having such a thing doesn't add too much to
> the complexity and/or cost of the mother board, we should give it serious
> thought.

Adding a high speed bus like many have proposed adds to the complexity.
Reliable high speed bus design could be considered an art.  I'm waiting
to see how the main bus stuff panes out before looking into that.

-- 
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 caret@pyramid.com Thu Jun 24 00:32:02 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA08821; Thu, 24 Jun 93 00:31:54 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA13853; Wed, 23 Jun 93 15:31:46 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA11461; Wed, 23 Jun 93 15:31:41 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306232231.AA11461@sword.eng.pyramid.com>
Subject: Re: cost of fpu?  EISA?
To: riscy@pyramid.com
Date: Wed, 23 Jun 93 15:31:40 PDT
In-Reply-To: <9306232131.AA20444@hprisc-12.cae.wisc.edu>; from "Carlo J. Calica" at Jun 23, 93 4:31 pm
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

> > Going from memory (I'm at USENIX and my notes are at home):
> > 	79R3051E-20	$79	(non-FPU, 4k I-cache, 8k D-cache)
> > 	79R3051E-40	$155	(non-FPU, 4k I-cache, 8k D-cache)
> > 	79R3081E-40	$297	(FPU, 8k I-cache, 16k D-cache)
> > I have prices for all of the various speeds and packages but that's all
> > I can remember.
> > 
> So we're looking at a $150 price difference.  But it also doubles the cache.
> Personally I'm in favor of dropping Ethernet and video for the FPU.  If we
> keep the ISA video we retain the ability to use a somewhat modified XFree
> rather than rewriting it.  I also have no use for Ethernet either.  SCSI
> should be kept though.  Where else can we cut cost a little to get the FPU?
> Or should we increase the cap to <$600 with the FPU. 

At the moment I'm figuring <$700.  Cost cutting like this is pointless
until we have the likely costs of the various other components in
the system.  From what I'm guessing though, doing it all for less than
the target price is a definate possible.

-- 
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 drew@nagina.cs.Colorado.EDU Thu Jun 24 00:46:28 1993
Return-Path: <drew@nagina.cs.Colorado.EDU>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA08840; Thu, 24 Jun 93 00:46:25 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16531; Wed, 23 Jun 93 15:46:17 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA14326; Wed, 23 Jun 93 15:46:12 -0700
Received: from nagina.cs.colorado.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16523; Wed, 23 Jun 93 15:46:07 -0700
Received: from localhost by nagina.cs.Colorado.EDU with SMTP id AA01411
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Wed, 23 Jun 1993 16:46:07 -0600
Message-Id: <199306232246.AA01411@nagina.cs.Colorado.EDU>
To: riscy@pyramid.com
Subject: UARTs, was : Re 2nd update
In-Reply-To: Your message of "Wed, 23 Jun 1993 15:15:00 MDT."
             <9306232215.AA08576@sword.eng.pyramid.com> 
Date: Wed, 23 Jun 1993 16:46:03 -0600
From: Drew Eckhardt <drew@nagina.cs.Colorado.EDU>
Status: RO
X-Status: 


    > >3.  What *other* uarts are out there?  In microlab, we used 
    > >	a nice DUART (same vintage as the 8250's) that was 
    > >	buffered.
    > 
    > Steve has been looking at these for a while. I believe he'd
    > gotten close to the "best" serial port he could find. Steve?
    
    The best I've seen is the Motorola MC68302, which has 3 serial ports
    capable of some very good speed.  However, this guy may be a little
    too expensive, since its also has a 68000 CPU core in it.

Add to cost the added complexity of programming, etc.  If our goal
is resonable, standard RS232 performance, which maxes out at 115.2
Kbaud, we're more than covered by the National Semi UARTS rated at 
1.5M baud. 

I just called the local national semi office and distributor : 

1.  National Semi doesn't make a four UART version of the 16550

2.  Here are the stats on the 2-port version : 

National Semi NS16C552V dual 16550 UART

Pricing :

Lots of 100 : $13.10
Sample quantities : $16.50

Package :  44 Lead Plastic Chip Carrier, about .65" X .65"

 
From caret@pyramid.com Thu Jun 24 03:06:51 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA09001; Thu, 24 Jun 93 03:06:49 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09260; Wed, 23 Jun 93 18:06:43 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA09258; Wed, 23 Jun 93 18:06:34 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306240106.AA09258@sword.eng.pyramid.com>
Subject: Re: UARTs, was : Re 2nd update
To: riscy@pyramid.com
Date: Wed, 23 Jun 93 18:06:33 PDT
In-Reply-To: <199306232246.AA01411@nagina.cs.Colorado.EDU>; from "Drew Eckhardt" at Jun 23, 93 4:46 pm
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

> Add to cost the added complexity of programming, etc.  If our goal
> is resonable, standard RS232 performance, which maxes out at 115.2
> Kbaud, we're more than covered by the National Semi UARTS rated at 
> 1.5M baud. 
> 
> I just called the local national semi office and distributor : 
> 
> 1.  National Semi doesn't make a four UART version of the 16550
> 
> 2.  Here are the stats on the 2-port version : 
> 
> National Semi NS16C552V dual 16550 UART
> 
> Pricing :
> 
> Lots of 100 : $13.10
> Sample quantities : $16.50
> 
> Package :  44 Lead Plastic Chip Carrier, about .65" X .65"
> 

Sounds like we have our serial chip...


-- 
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 calica@cae.wisc.edu Thu Jun 24 05:04:53 1993
Return-Path: <calica@cae.wisc.edu>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA09233; Thu, 24 Jun 93 05:04:51 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20912; Wed, 23 Jun 93 20:04:44 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA20928; Wed, 23 Jun 93 20:04:35 -0700
Received: from serv0.cae.wisc.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20836; Wed, 23 Jun 93 20:04:34 -0700
Received: from hprisc-25.cae.wisc.edu by serv0.cae.wisc.edu (4.1/25)
	id AA24947; Wed, 23 Jun 93 22:03:21 CDT
Received: by hprisc-25.cae.wisc.edu (16.8/client-1.3)
	id AA00861; Wed, 23 Jun 93 22:05:56 -0500
From: Carlo J. Calica <calica@cae.wisc.edu>
Message-Id: <9306240305.AA00861@hprisc-25.cae.wisc.edu>
Subject: Re: MIPS R3000 - 2nd update
To: riscy@pyramid.com
Date: Wed, 23 Jun 93 22:05:56 CDT
Mailer: Elm [revision: 66.36.1.2]
Status: RO
X-Status: 

> The best I've seen is the Motorola MC68302, which has 3 serial ports
> capable of some very good speed.  However, this guy may be a little
> too expensive, since its also has a 68000 CPU core in it.
> 
Well if we do use this 'extra' CPU could we use it for something?  Maybe
sound?  In any case sound is something to think about.  If we do add it
would it be a simple DAC or something more complicated?  If set up properly,
the 68000 (or something more specialized) could combine various waves forms
to two DACs.  That would be all digital and sound better than most anything
for the PC.


--
 /------------------------------+--------------------------------------\
| Carlo J. Calica               | Linux:  Choice of the GNU Generation  |
|     calica@cae.wisc.edu       | Dittos from the People's              | 
 \ University of Wisconsin      | Republic of Madison                  / 

 
From calica@cae.wisc.edu Thu Jun 24 05:13:47 1993
Return-Path: <calica@cae.wisc.edu>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA09243; Thu, 24 Jun 93 05:13:44 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA22222; Wed, 23 Jun 93 20:13:34 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA22466; Wed, 23 Jun 93 20:13:29 -0700
Received: from serv0.cae.wisc.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA22214; Wed, 23 Jun 93 20:13:28 -0700
Received: from hprisc-25.cae.wisc.edu by serv0.cae.wisc.edu (4.1/25)
	id AA25050; Wed, 23 Jun 93 22:12:16 CDT
Received: by hprisc-25.cae.wisc.edu (16.8/client-1.3)
	id AA00907; Wed, 23 Jun 93 22:14:51 -0500
From: Carlo J. Calica <calica@cae.wisc.edu>
Message-Id: <9306240314.AA00907@hprisc-25.cae.wisc.edu>
Subject: Re: UARTs, was : Re 2nd update
To: riscy@pyramid.com
Date: Wed, 23 Jun 93 22:14:51 CDT
Mailer: Elm [revision: 66.36.1.2]
Status: RO
X-Status: 

> > I just called the local national semi office and distributor : 
> > 
> > 1.  National Semi doesn't make a four UART version of the 16550
> > 
> > 2.  Here are the stats on the 2-port version : 
> > 
> > National Semi NS16C552V dual 16550 UART
> > 
> > Lots of 100 : $13.10
> 
> Sounds like we have our serial chip...
> 
Please be sure to use two for a total of 4 UARTs.  I'd like as many as
possible to hang terminals off of.

--
 /------------------------------+--------------------------------------\
| Carlo J. Calica               | Linux:  Choice of the GNU Generation  |
|     calica@cae.wisc.edu       | Dittos from the People's              | 
 \ University of Wisconsin      | Republic of Madison                  / 

 
From mackinla@cs.curtin.edu.au Tue Jun 22 08:17:09 1993
Return-Path: <mackinla@cs.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA02253; Tue, 22 Jun 93 08:17:01 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA13236; Mon, 21 Jun 93 23:19:50 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA04748; Mon, 21 Jun 93 23:16:52 -0700
Received: from marsh.cs.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA13230; Mon, 21 Jun 93 23:19:34 -0700
Received: from vincent.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA04216
  (5.67a/IDA-1.4.4 for <riscy@pyramid.com>); Tue, 22 Jun 1993 14:14:14 +0800
Received: by vincent.cs.curtin.edu.au id AA12143
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Tue, 22 Jun 1993 14:14:07 +0800
From: Patrick Mackinlay <mackinla@cs.curtin.edu.au>
Message-Id: <199306220614.AA12143@vincent.cs.curtin.edu.au>
Subject: Re: MIPS R3000 tasks available; volunteers?
To: riscy@pyramid.com
Date: Tue, 22 Jun 1993 14:14:06 +0800 (WST)
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 3513      
Status: RO
X-Status: 


>Most correspondence should be directed at the mailing list:
>
>	riscy@pyramid.com

May I suggest getting your mailing list software to include a "Reply-to:"
field? Makes following up a little easier.

>*  CPU, peripheral controller and memory
>		Allocated to: caret@pyramid.com
>	of what memory controller is available.  At this stage I am aiming
>	at using the IDT 79R3730.  To this end I am calling IDT to attempt

Just a comment here: having been in the same boat before waiting for IDT
to produce the R372x series of chips, I'd have to say that this chip is
going to be the most critical one in the whole design. Hopefully they
will produce this and make it available as planned...

>*  Keyboard controller / NV-RAM / RTC

I might just try and take this up. You mentioned the 8051 in your
previous mail, but I have a little further info. The original PC and XT
used the 8051, but all machines since have used the 8041. I know that
AMI (the BIOS people) make them pre-programmed with their PC BIOS (ie:
it's an EPROM as well), and think that this would make a nifty device
if we could get hold of it. It would obviously require re-burning the
EPROM, but I think it might be a good way to cut down on a couple of
chips. As for the NV-RAM and RTC, everything I've ever heard points to
Dallas Semi. Unfortunately, I've also heard that they advertise lots of
stuff that they never actually make. I'll look into both of these, and
see what I can come up with.

>*  SCSI bus
>		Allocated to: <no-one>
>	The SCSI bus would probably be done with something like a
>	NEC 53C94 SCSI controller.  Research needs to be done on this
>	and other available SCSI chips.  

Ok, I'm probably one of the people who pushed for this. The other SCSI
chips I've had a look at include: NCR53C7xx series (SMT and _big_),
NCR538x series (pretty dumb) and the WD33C98(?) (very buggy). One
advantage of the '94 is that it's second sourced by Emulex, NCR and
Motorola, so it should be pretty easy to get hold of. You should also
note that there's a 53CF94 which is the same device but does FAST SCSI.
Again, there are '96 chips which do wide SCSI (I think). I've been
unable to get any hard data down here though...

>*  Serial port

Might I suggest a Zilog SCC? I've had good experiences with these,
and they give you the ability to use AppleTalk (physically, anyhow)
at some stage. IMHO, we should have one SCC (or something) chip on
the motherboard itself, and use an ISA card for more "regular"
serial chips. Comments?

>*  Ethernet port
>		Allocated to: <no-one>
>	It has been suggested that we use an Am7990 (Lance) Ethernet

I probably suggested this too, but again - I don't know much about
it. I think there's an alternative in the NSC 8390(?) used on a lot
of PC ethernet cards. As I said, I'm not qualified to give an
opinion here.

>*  Video

Ok, I've accepted this idea <grin>. Anyone know if the 6845 is up
to it? What sort of a range does it have on sync signals?

>*  Diagnostics / monitor code

I'd be very interested in doing this. Obviously (I think), we'd want
some sort of an assembler for this step. See below.

>*  Cross assembler/compiler system

I've looked at this before and I think it's relatively trivial. Getting
GAS to produce R3k binaries is going to be the most important first
step, as we'll need that for the boot/debug ROM.

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 andy@resi.waldorf-gmbh.de Thu Jun 24 09:13:14 1993
Return-Path: <andy@resi.waldorf-gmbh.de>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA10627; Thu, 24 Jun 93 09:13:08 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09578; Thu, 24 Jun 93 00:12:50 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA22870; Thu, 24 Jun 93 00:12:20 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09126; Thu, 24 Jun 93 00:12:15 -0700
Received: by mail.Germany.EU.net(EUnetD-2.2.6.c) via EUnet
	id JL26502; Thu, 24 Jun 1993 09:09:22 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for unido
	id AA14767; Thu, 24 Jun 93 09:06:20 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Thu, 24 Jun 93 09:04:43 +0200
Message-Id: <9306240704.AA07601@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA07601; Thu, 24 Jun 93 09:04:43 +0200
To: caret@pyramid.com, riscy@pyramid.com
Subject: Re: MIPS R3000 - 2nd update
Cc: andy@resi.waldorf-gmbh.de
Status: RO
X-Status: 


> IMHO, software compatability should be a more important issue, ie 
> with commercial shrink wrap.  If people want to consider Ultrix 
> binary compatability, little endian SPIM is the only way to go. 
> If there's a SYSV MIPS ABI, we should comply with the endianness
> of that.

There is a MIPS SYSV ABI and it is big-endian. SGI is big-endian too.
So far I know is a Mips Magnum 3000 one of the reference platforms
for Mips-RiscOS 5.01, Irix SVR4 and Sony News. The Magnum 3000
is big-endian. It does not support switching to little-endian.

Andy
-------------------------------------------------------------------------------
Waldorf Electronics GmbH, R&D Department
c/o Andreas Busse
Neustrasse 9-12
D-5481 Waldorf
Phone:  +49 (0)2636-80294
Fax:    +49 (0)2636-80188
e-mail: andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------

 
From wolff@dutecai.et.tudelft.nl Thu Jun 24 10:28:26 1993
Return-Path: <wolff@dutecai.et.tudelft.nl>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA10803; Thu, 24 Jun 93 10:28:24 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17094; Thu, 24 Jun 93 01:28:16 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA28728; Thu, 24 Jun 93 01:27:58 -0700
Received: from liberator.et.tudelft.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16966; Thu, 24 Jun 93 01:27:51 -0700
Received: by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA03662; Thu, 24 Jun 93 10:26:28 +0200
Date: Thu, 24 Jun 93 10:26:28 +0200
From: wolff@dutecai.et.tudelft.nl (Rogier Wolff)
Message-Id: <9306240826.AA03662@liberator.et.tudelft.nl>
To: riscy@pyramid.com
Subject: Wire wrap max speed.
Status: RO
X-Status: 



mackinla@cs.curtin.edu.au writes:

>>maybe something that works at wire-wrap compatable speeds (how 
>>fast *can* you go with wirewrap?)) to plug in peripherials in like a 
>
>About 16MHz is the practical limit. I know, I've tried <grin>.

We've got a wire wrapped board here, running TWO I960 CPU's at 33 Mhz.
Within a few weeks we'll have a 50Mhz board up and running (with a different
processor).

In a way, wire wrapping is easier: you've got less routing problems, and
can take the shortest way from A to B. On the other side you need a
board that has good power and ground planes.


					Roger.

 
From @cs.vu.nl:wfkonij@keg.cs.vu.nl Thu Jun 24 11:06:38 1993
Return-Path: <@cs.vu.nl:wfkonij@keg.cs.vu.nl>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA10862; Thu, 24 Jun 93 11:06:34 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA22366; Thu, 24 Jun 93 02:06:23 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA07072; Thu, 24 Jun 93 02:06:15 -0700
Received: from top.cs.vu.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA22357; Thu, 24 Jun 93 02:06:13 -0700
Received: from keg.cs.vu.nl by top.cs.vu.nl id aa11200; 24 Jun 93 11:05 MET DST
Received: from localhost by keg.cs.vu.nl id aa22796; 24 Jun 93 11:05 MET DST
To: riscy@pyramid.com
Subject: Re: UARTs, was : Re 2nd update 
In-Reply-To: Your message of "Wed, 23 Jun 93 22:14:51 CDT."
             <9306240314.AA00907@hprisc-25.cae.wisc.edu> 
Date: Thu, 24 Jun 93 11:05:50 +0200
From: Willy Konijnenberg <wfkonij@keg.cs.vu.nl>
Message-Id:  <9306241105.aa22796@keg.cs.vu.nl>
Status: RO
X-Status: 

You wrote:
> > > National Semi NS16C552V dual 16550 UART
> > 
> > Sounds like we have our serial chip...
> > 
> Please be sure to use two for a total of 4 UARTs.  I'd like as many as
> possible to hang terminals off of.

Why would you want to put UARTs on the motherboard?  They don't consume
enough I/O bandwidth to justify hooking them up to the local bus.
If you include too many fancies, the board gets more complicated and
more expensive than it needs to be.
Better stick to things that need the bandwidth, like SCSI, ethernet, video.
If you want 16552 UARTs, build a simple ISA board with 4 sockets for them.

Not that my views are relevant, of course, as I am not going to design
the board, and very possibly won't even buy one.


-- 
	Willy Konijnenberg <wfkonij@cs.vu.nl>
	Department of Mathematics & Computer Science,
	Vrije Universiteit, Amsterdam, The Netherlands
 "You don't want to get locked into open systems" -- IBM

 
From tor@tss.no Thu Jun 24 11:08:27 1993
Return-Path: <tor@tss.no>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA10874; Thu, 24 Jun 93 11:08:23 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA22482; Thu, 24 Jun 93 02:08:13 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA07349; Thu, 24 Jun 93 02:08:07 -0700
Received: from benoni.Uit.No 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA22424; Thu, 24 Jun 93 02:08:03 -0700
Received: from benoni by ppenoni.uit.no with SMTP (PP) 
          id <21503-0@ppenoni.uit.no>; Thu, 24 Jun 1993 11:07:55 +0000
Received: from unas.tss.no 
          by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) 
          id AAbenoni21499; Thu, 24 Jun 1993 11:07:51 +0200
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA09427;
          Thu, 24 Jun 93 11:02:22 +0200
Message-Id: <9306240902.AA09427@unas.tss.no>
From: tor@tss.no (Tor Arntsen)
Date: Thu, 24 Jun 1993 11:02:20 +0200
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: riscy@pyramid.com
Subject: big/little endian
Status: RO
X-Status: 

>>>>>On Jun 23,  2:34pm, Neil Russell wrote:
[...]
>> > *  The R3000 is able to be a little endian or a big endian machine.
>> >    Most operating systems that I've seen use the big endian mode, but
>> >    since linux runs on the 386, little endian may be more appropriate.
>> 
>> I don't know if it will make that much difference, but I suppose
>> little-endian is easiest.  Big endian will probably make talking to
>> ISA IO boards quite tricky.
>
>I don't like the idea of hardware swapping the bits, so this favours
>little endian, however, RISCos is big endian and has a few ISA bus
>slots; so the software must swap the bytes itself; Mmmm, this is the
>RISC way, after all...

I would prefer big endian, but I have no strong objections (that means, I will
buy the board anyway) if it ends up the other way (the DEC/Intel way vs. 
the rest of the world.. :-) :-)

Tor


 
From jeremy@sw.oz.au Thu Jun 24 13:16:31 1993
Return-Path: <jeremy@sw.oz.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA11140; Thu, 24 Jun 93 13:16:22 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA12516; Thu, 24 Jun 93 04:16:01 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA19854; Thu, 24 Jun 93 04:15:47 -0700
Received: from munnari.OZ.AU 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA12419; Thu, 24 Jun 93 04:15:38 -0700
Received: from sw.oz.au (via basser.cs.su.oz.au) by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50)
	id AA02448; Thu, 24 Jun 1993 21:14:08 +1000 (from jeremy@sw.oz.au)
Received: from chao.sw.oz.au by swift.sw.oz.au with SMTP
	id AA01241; Thu, 24 Jun 93 21:12:34 AES (5.59)
	(from jeremy@sw.oz.au for tor%tss.no@munnari.oz.au)
Received: by chao.sw.oz.au (4.1/SMI-4.1)
	id AA23007; Thu, 24 Jun 93 21:13:17 EST
From: jeremy@sw.oz.au (Jeremy Fitzhardinge)
Message-Id: <9306241113.AA23007@chao.sw.oz.au>
Subject: Re: big/little endian
To: tor@tss.no (Tor Arntsen)
Date: Thu, 24 Jun 1993 21:13:16 +1000 (EST)
Cc: riscy@pyramid.com
In-Reply-To: <9306240902.AA09427@unas.tss.no> from "Tor Arntsen" at Jun 24, 93 11:02:20 am
Organization: Softway Pty Ltd
X-Face: 
	 '6U=%Tv\k1<Ek%ql%PN^v`Db4bakr[v~y]\u7"GbO#I=]N{l1=#P,glz$9q>l-:?\$C[D@G
	 7(vl~w8&y}!f\bh#w<Y*S~bEBTI:s&.QR>L#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb
	 l[EC}c=;uc%x'}uh3E91p&oE<q$w1r&U0yw.Sb3V&uw
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 3227      
Status: RO
X-Status: 

Tor Arntsen bubbles:

> I would prefer big endian, but I have no strong objections (that means, I will
> buy the board anyway) if it ends up the other way (the DEC/Intel way vs. 
> the rest of the world.. :-) :-)

Given a free hand, I would prefer big endian.  However, I think there
are a few compelling reasons to go little endian -- all to do with
compatability with the Intel version.  Choosing bigendian wouldn't
make it impossible, but it does offer a whole pile extra places for
things to go wrong.  If we can make code like this work without
problems, wrong as it is, it would be helpful:

#ifdef linux	/* linux runs on intel only */
#define little_endian
#endif

There are a number of places where it would be good to keep the same format
to the bit level on all Linux architectures:
	Executable/Object files
		Obviously there are going to be CPU related differences,
		but programs should be able to manipulate files from any
		type of host.  Plan 9 handles this by keeping a strict
		byte order regardless of the native one.  ELF does it
		by storing the byte order in the file.	Either way,
		conversion has to be done explicitly if its wrong.  With
		luck we can expect ELF to be quite standard in linux soon,
		and it will make the multiple CPU type problem easier to
		deal with.  Gcc copes with cross compilation quite well.
	Filesystem meta-data
		It would be really good to be able to take filesystems and
		use them on any type of machine.  It would be doubly good
		if the filesystem code doesn't have to do much to do it.
	Network data
		This is universally big-endian.  Little endian machines
		just have to cope.  It is not a large overhead generally.

There are other data representation issues other than byte sex, like
alignment constraints.  This would probably be a more subtle problem
for programs that just write structures into files expecting them to
be read back in again.

I think it is important to make linux run on both intel and mips chips
with as much compatability as possible, rather than taking the approach
of getting the intel source as a base and forking the development at
that point.  The porting effort should find all the intel specific bits
and isolate them, making sure that gets into Linus' base source.
There are always going to be many more people using and hacking intel
linux boxes over any other, and we want to make sure that kernel changes
are as widely useful as possible.  We should be able to also get a higher
level of source compatability (near 100%).

Mips ABI compliance doesn't seem very important to me.  There isn't
much commercial stuff being distributed for mipsen in binary form,
so far as I know.  Certainly a package we use here is not being
distributed for the Mips machines (get a Sparc or Intel they say...).

Intel ABI compliance may be possible later.  It would probably involve
interpreting the main code body, and catching syscalls and library
calls for the interface.  Could be a simple matter of programming,
could be non-trivial.  Little endianess would certainly help.

Also, it would be nice to get the experiences of those doing 68k ports.
I'm told they exist, but I have no references.  Does anyone have names
or addresses?

Gotta rush,
	J

 
From tor@tss.no Thu Jun 24 15:30:45 1993
Return-Path: <tor@tss.no>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA11412; Thu, 24 Jun 93 15:30:37 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA02237; Thu, 24 Jun 93 06:30:21 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA03216; Thu, 24 Jun 93 06:30:11 -0700
Received: from benoni.Uit.No 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA02229; Thu, 24 Jun 93 06:30:07 -0700
Received: from benoni by ppenoni.uit.no with SMTP (PP) 
          id <23488-0@ppenoni.uit.no>; Thu, 24 Jun 1993 15:29:04 +0000
Received: from unas.tss.no 
          by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) 
          id AAbenoni23484; Thu, 24 Jun 1993 15:29:02 +0200
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA11724;
          Thu, 24 Jun 93 15:23:32 +0200
Message-Id: <9306241323.AA11724@unas.tss.no>
From: tor@tss.no (Tor Arntsen)
Date: Thu, 24 Jun 1993 15:23:30 +0200
In-Reply-To: jeremy@sw.oz.au (Jeremy Fitzhardinge) "Re: big/little endian" (Jun 24, 9:13pm)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: jeremy@sw.oz.au (Jeremy Fitzhardinge)
Subject: Re: big/little endian
Cc: riscy@pyramid.com
Status: RO
X-Status: 

Jeremy Fitzhardinge:
> 
> Tor Arntsen bubbles:
> 
> > I would prefer big endian, but I have no strong objections (that means, I will
> > buy the board anyway) if it ends up the other way (the DEC/Intel way vs. 
> > the rest of the world.. :-) :-)
> 
> Given a free hand, I would prefer big endian.  However, I think there
> are a few compelling reasons to go little endian -- all to do with
> compatability with the Intel version.  Choosing bigendian wouldn't
> make it impossible, but it does offer a whole pile extra places for
> things to go wrong.  If we can make code like this work without
> problems, wrong as it is, it would be helpful:
> 
> #ifdef linux	/* linux runs on intel only */
> #define little_endian
> #endif
> 
> There are a number of places where it would be good to keep the same format
> to the bit level on all Linux architectures:
[deleted]
> Also, it would be nice to get the experiences of those doing 68k ports.
> I'm told they exist, but I have no references.  Does anyone have names
> or addresses?
> 
> Gotta rush,
> 	J

I'm 'lurking' on the 680X0 mailing list, they seem to be going forward.
Hamish (H.I.) Macdonald (hamish@bnr.ca) is the Amiga coordinator and
central source manager.  He has done most of the kernel porting I think.

Arno Griffioen (arno@usn.nl) is a general coordinator (coordinating who's
doing what etc.)

They certainly have to face the big/little endian problem up front..

Tor


 
From Steven.D.Ligett@Dartmouth.EDU Thu Jun 24 20:50:35 1993
Return-Path: <Steven.D.Ligett@Dartmouth.EDU>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA12009; Thu, 24 Jun 93 20:50:33 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21661; Thu, 24 Jun 93 11:50:26 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA18821; Thu, 24 Jun 93 11:49:34 -0700
Received: from dartvax.dartmouth.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21641; Thu, 24 Jun 93 11:49:32 -0700
Received: from prancer.dartmouth.edu by dartvax.dartmouth.edu (5.65+D5/4.5HUB)
	id AA07966; Thu, 24 Jun 93 14:47:37 -0400
Message-Id: <5257491@prancer.Dartmouth.EDU>
Date: 24 Jun 93 14:47:35 EDT
From: Steven.D.Ligett@Dartmouth.EDU (Steven D. Ligett)
Subject: cost of 3081
To: riscy@pyramid.com
Status: RO
X-Status: 

Prices of the 3081 have come down this quarter.  For the 79r3081e-40mj, the
prices are:

$385 for 1 to 24
$340.50 for 25 to 99
$296 for 100 ...

If you are going to have a group of 25 or more, the 3081 w FPU will cost
about $200 more than the 3051.  The 3052 is in between.  At this point, I
don't see that a decision has to be made -- except for clocking issues, and a
few pullups for configuration, you can put any of them in the same socket. 
Prices should be better in the next quarter, anyway.  Once you've got a
memory system designed, and choose the clock speed, then buy whatever CPU you
can afford.

 
From caperkin@ursa11.law.utah.edu Thu Jun 24 21:35:31 1993
Return-Path: <caperkin@ursa11.law.utah.edu>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA12072; Thu, 24 Jun 93 21:35:20 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28727; Thu, 24 Jun 93 12:35:10 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA28613; Thu, 24 Jun 93 12:35:04 -0700
Received: from cs.utah.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28714; Thu, 24 Jun 93 12:35:02 -0700
Received: from ursa11.law.utah.edu by cs.utah.edu (5.65/utah-2.21-cs)
	id AA07251; Thu, 24 Jun 93 13:34:59 -0600
Received: by ursa11.law.utah.edu (5.65/utah-2.11sun-leaf)
	id AA15076; Thu, 24 Jun 93 13:39:15 -0600
Date: Thu, 24 Jun 93 13:39:15 -0600
From: caperkin@ursa11.law.utah.edu (Charles Perkins)
Message-Id: <9306241939.AA15076@ursa11.law.utah.edu>
To: riscy@pyramid.com
Subject: endian
Status: RO
X-Status: 


Tests great!  Less swapping!  Tests great!  Less swapping!

um...

I favor big endian for the mips project for two reasons:

1. Binary compatibility hacks with other Mips systems will be
   impossible or incredibly difficult otherwise.

2. It would be a very good idea to leverege off the architectural independence
   work of the 68000 port.  I am not talking about a port of their port, rather
   that we work in tandem with them in building a portable linux source tree.
   And the neat thing is, they're allready dealing with the little-big-endian 
   issue.

3. I like big-endian.  (Not a reason.  A bias.)

The problem I see is with interfacing with the ISA bus.  The software will have to know how to
deal with the endianness, or there will have to be a hardware swap.
Does the nifty bus controller already deal with that?
How much more difficult would this make writing device drivers?

If SCSI, ethernet and video are on the motherboard, I think that we don't need to invent
another super-nifty multi-cool expansion slot system. 

a) that is hard
b) we probably wouldn't get it right the first time
c) most of the fast stuff is already on the motherboard

I agree that an ISA bus would be neat and allow us to put lots of 
clone cards in the system, but I could live even without this.

However, I feel that we should run every line going to the cpu also
to some sort of connector.  Just one.  A bunch of other signals can
go to/come from this slot, but the important thing is to allow
someone else, later, to put a daughter card there that perhaps 
can do the nifty bus stuff, or whatever.  Perhaps someone
would like to make an AXP daughtercard.  Or a 486 card to allow
running of Linux binaries.  Make it simple.  Don't worry about
how others might use it.  And the great thing is, it is just
the cost of a (perhaps very big) connector.  Cheap.  Which I 
appreciate.


 
From gt8134b@prism.gatech.edu Fri Jun 25 03:29:58 1993
Return-Path: <gt8134b@prism.gatech.edu>
Received: from liberator.et.tudelft.nl by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA12534; Fri, 25 Jun 93 03:29:55 +0200
Received: from hydra.gatech.edu by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA04121; Fri, 25 Jun 93 03:29:51 +0200
Received: by hydra.gatech.edu (5.67a/3.1)
	id AA22149; Thu, 24 Jun 1993 21:29:44 -0400
Date: Thu, 24 Jun 1993 21:29:44 -0400
From: gt8134b@prism.gatech.edu (Howlin' Bob)
Message-Id: <199306250129.AA22149@prism.gatech.edu>
To: wolff@dutecai.et.tudelft.nl
Subject: Re: Why have I lost 12MB to lost+found ?
Newsgroups: comp.os.linux
References: <C91ALs.G54.1@cs.cmu.edu> <209e83INNg07@news.u.washington.edu> <1993Jun24.160914.9999@donau.et.tudelft.nl>
Status: RO
X-Status: 

In comp.os.linux you write:

>Jay I Choe (choe@hipress.phys.washington.edu) wrote:

>Let me throw in a "bug report". We tried making a file system on 
>a new SCSI disk. It was slightly larger than what I'm used to, when working
>with Linux: It was 425Mb. It seems that it was also larger than what mke2fs
>was used to.... It crashed with an "out of memory" error. It seems
>that mke2fs builds up some datastructures in memory before writing everything
>to disk. 

I think that the 0.3 release of the ext2fs programs significantly reduced
memory usage in mke2fs.  Make sure you have those.  If you do, then write
Stephen Tweedie and Remy Card and beg for s dispensation :-)

Robert

---
Robert Sanders
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt8134b
Internet: gt8134b@prism.gatech.edu

 
From mackinla@cs.curtin.edu.au Fri Jun 25 03:34:45 1993
Return-Path: <mackinla@cs.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA12546; Fri, 25 Jun 93 03:34:34 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23473; Thu, 24 Jun 93 18:34:26 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA17699; Thu, 24 Jun 93 18:34:03 -0700
Received: from marsh.cs.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23447; Thu, 24 Jun 93 18:33:53 -0700
Received: from vincent.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA19260
  (5.67a/IDA-1.4.4 for <riscy@pyramid.com>); Fri, 25 Jun 1993 09:32:16 +0800
Received: by vincent.cs.curtin.edu.au id AA23532
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Fri, 25 Jun 1993 09:32:03 +0800
From: Patrick Mackinlay <mackinla@cs.curtin.edu.au>
Message-Id: <199306250132.AA23532@vincent.cs.curtin.edu.au>
Subject: Re: cost of fpu?  EISA?
To: riscy@pyramid.com (R3000 PC Mailing List)
Date: Fri, 25 Jun 1993 09:32:02 +0800 (WST)
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 860       
Status: RO
X-Status: 


>	79R3051E-20	$79	(non-FPU, 4k I-cache, 8k D-cache)
>	79R3051E-40	$155	(non-FPU, 4k I-cache, 8k D-cache)
>	79R3081E-40	$297	(FPU, 8k I-cache, 16k D-cache)

This is a bit late, but I believe the cache sizes above are wrong. As
far as I'm aware, the '51 has 4k i-cache + 2k d-cache. The '52 has 8k
i-cache + 2k d-cache. The '81 I'm not so sure about, but I suspect it's
16k i-cache + 8k d-cache, not as indicated above. Anyone have a book
with the '81 spec?

I suspect there's not much of a price difference between the '51 and
the '52 either - perhaps we'd do well by going for the '52 when the
time comes? As Steve mentioned, we don't really have to worry about
this yet anyhow...

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 gregg@netcom.com Tue Jun 22 17:09:38 1993
Return-Path: <gregg@netcom.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA03600; Tue, 22 Jun 93 17:09:26 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20144; Tue, 22 Jun 93 08:12:14 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA29144; Tue, 22 Jun 93 08:09:16 -0700
Received: from netcom2.netcom.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20104; Tue, 22 Jun 93 08:12:11 -0700
Received: by netcom2.netcom.com (5.65/SMI-4.1/Netcom)
	id AA23960; Tue, 22 Jun 93 08:08:29 -0700
From: gregg@netcom.com (gregg weber)
Message-Id: <9306221508.AA23960@netcom2.netcom.com>
Subject: MIPS R3000 tasks , ethernet
To: riscy@pyramid.com
Date: Tue, 22 Jun 93 8:08:28 PDT
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 


*  Serial port
		Allocated to: <no-one>
	Some sort of serial ports should be investigated to be connected
	to the A bus of the 3730.  NS16550's would be appropriate
	but other ideas might be looked into.

How about using one of the 8 port chips. They come in a 68 lead PLCC.

*  Ethernet port
		Allocated to: <no-one>
	It has been suggested that we use an Am7990 (Lance) Ethernet
	controller.  I know nothing about this chip.  I expect that it
	could be connected to the 8-bit or 8/16-bit bus of the 3730.

I designed a card using the 7990, and I guess I could do it again.
But, the 7990 was around in 1985, and there are better chips now.
THe 7990 is 16 bit data bus. The 79C00 is 32 bits, and has a buiolt
in transciever. Intel 82596 is 32 bits, and does all MAC functions
on chip (according to the data book). Last time I worked with it, there
were the usual number of Intel bugs in the part. But it was usable.


*  Diagnostics / monitor code
		Allocated to: caret@pyramid.com and <someone else>
	Some initial code needs to be written to test the board and
	load the operating system.

What fun. I bet we will have to fight over who does this one.

-- 

 
From a080700@hp750a.csc.cuhk.hk Fri Jun 25 04:07:46 1993
Return-Path: <a080700@hp750a.csc.cuhk.hk>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA12580; Fri, 25 Jun 93 04:07:38 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA24871; Thu, 24 Jun 93 19:07:32 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA21610; Thu, 24 Jun 93 19:07:25 -0700
Received: from hp750a.csc.cuhk.hk 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA24863; Thu, 24 Jun 93 19:07:13 -0700
Message-Id: <9306250207.AA24863@gossip.pyramid.com>
Received: by hp750a.csc.cuhk.hk
	(16.8/16.2) id AA11721; Fri, 25 Jun 93 10:05:20 +0800
From: Stephen Siu-ming Wong <a080700@hp750a.csc.cuhk.hk>
Subject: Re: cost of fpu?  EISA?
To: mackinla@cs.curtin.edu.au (Patrick Mackinlay)
Date: Fri, 25 Jun 93 10:05:19 HKT
Cc: riscy@pyramid.com
In-Reply-To: <199306250132.AA23532@vincent.cs.curtin.edu.au>; from "Patrick Mackinlay" at Jun 25, 93 9:32 am
Mailer: Elm [revision: 70.30]
Status: RO
X-Status: 

Hi Risciers,

>>      79R3051E-20     $79     (non-FPU, 4k I-cache, 8k D-cache)
>>      79R3051E-40     $155    (non-FPU, 4k I-cache, 8k D-cache)
>>      79R3081E-40     $297    (FPU, 8k I-cache, 16k D-cache)
>
>This is a bit late, but I believe the cache sizes above are wrong. As
>far as I'm aware, the '51 has 4k i-cache + 2k d-cache. The '52 has 8k
>i-cache + 2k d-cache. The '81 I'm not so sure about, but I suspect it's
>16k i-cache + 8k d-cache, not as indicated above. Anyone have a book
>with the '81 spec?
>
>I suspect there's not much of a price difference between the '51 and
>the '52 either - perhaps we'd do well by going for the '52 when the
>time comes? As Steve mentioned, we don't really have to worry about
>this yet anyhow...

Do you guys and gals have benchmark results for '51, '52, and '81?  As
long as all the above CPUs are pin compatible (really?) why should we
argue the choice of CPU?  We can make a board without CPU and everyone
can put in his/her affordable CPU on the board!  Any other special
issue for this setup despite we have to deal with floating point
emulator in software if the hardware doesn't have one?

I think we have to decide (are we already said 40MHz?) the CPU clock
frequency and go on to other tricky part, such as ISA bus, ethernet,
video, etc.

*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*
v Stephen Wong Siu-ming    v internet: stephenwong@cuhk.hk  v
^ Computer Services Center ^ bitnet  : a080700@cucsc.bitnet ^
* Chinese University of    * phone   : (852) 609-8904       *
v Hong Kong                v fax     : (852) 603-5001       v
*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*

 
From mackinla@cs.curtin.edu.au Fri Jun 25 04:33:08 1993
Return-Path: <mackinla@cs.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA12621; Fri, 25 Jun 93 04:32:56 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA27987; Thu, 24 Jun 93 19:32:50 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA24959; Thu, 24 Jun 93 19:32:45 -0700
Received: from marsh.cs.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA27873; Thu, 24 Jun 93 19:32:34 -0700
Received: from vincent.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA20096
  (5.67a/IDA-1.4.4 for <riscy@pyramid.com>); Fri, 25 Jun 1993 10:30:57 +0800
Received: by vincent.cs.curtin.edu.au id AA24202
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Fri, 25 Jun 1993 10:30:49 +0800
From: Patrick Mackinlay <mackinla@cs.curtin.edu.au>
Message-Id: <199306250230.AA24202@vincent.cs.curtin.edu.au>
Subject: SPIM...
To: riscy@pyramid.com (R3000 PC Mailing List)
Date: Fri, 25 Jun 1993 10:30:48 +0800 (WST)
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1351      
Status: RO
X-Status: 


I just thought I'd let everyone know about a software tool that could
come in extremely handy during initial development. The program is
called spim (or xspim) and is a MIPS R3k CPU simulator. The program
compiles under Linux with a bit of fiddling, and seems to perform
pretty well.

There are a couple of different versions of the program in the source
distribution:

	spim: assembly-level simulator (text mode)
	xspim: assembly-level simulator (runs under X)
	cl-spim: cycle-level simulator (text mode)
	cl-xspim: cycle-level simulator (runs under X)

I haven't looked at either of the cycle-level simulators yet, but I'd
have to assume they worked ok. There are a few BSDisms in the code that
can be fixed by modifying some #include <whatever.h> to the appropriate
#include <bsd/whatever.h> and by linking with -lbsd.

I don't actually remember where the source is archived, but I think
archie can find it ok. If there's a need for it, I guess I can put
my binaries up somewhere, but I hope we're all capable of "compiling
our own" <grin>. I probably will put the patches I did up somewhere
when I get around to it.

Anyhow, I think it could be quite a useful tool...

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 andy@resi.waldorf-gmbh.de Fri Jun 25 10:13:36 1993
Return-Path: <andy@resi.waldorf-gmbh.de>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA14261; Fri, 25 Jun 93 10:13:33 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15496; Fri, 25 Jun 93 01:13:15 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA04517; Fri, 25 Jun 93 01:12:07 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15019; Fri, 25 Jun 93 01:12:01 -0700
Received: by mail.Germany.EU.net(EUnetD-2.2.6.c) via EUnet
	id KX20917; Fri, 25 Jun 1993 10:09:06 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for unido
	id AA21722; Fri, 25 Jun 93 08:57:59 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Fri, 25 Jun 93 08:56:24 +0200
Message-Id: <9306250656.AA09144@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA09144; Fri, 25 Jun 93 08:56:24 +0200
To: caperkin@ursa11.law.utah.edu, riscy@pyramid.com
Subject: Re:  endian
Status: RO
X-Status: 


> I favor big endian for the mips project for two reasons:
>
> 1. Binary compatibility hacks with other Mips systems will be
>    impossible or incredibly difficult otherwise.
> 
> 2. It would be a very good idea to leverege off the architectural independence
>    work of the 68000 port.  I am not talking about a port of their port, rather
>    that we work in tandem with them in building a portable linux source tree.
>    And the neat thing is, they're allready dealing with the little-big-endian 
>    issue.
> 
> 3. I like big-endian.  (Not a reason.  A bias.)

I totally agree !

> The problem I see is with interfacing with the ISA bus.  The software will have to know how to
> deal with the endianness, or there will have to be a hardware swap.
> Does the nifty bus controller already deal with that?
> How much more difficult would this make writing device drivers?

What ISA-bus-cards do we need ? Perhaps some more serial lines,
a fax-modem or the like. Most of them are 8-bit, so where is the
byte-swapping problem ?

> If SCSI, ethernet and video are on the motherboard, I think that we don't need to invent
> another super-nifty multi-cool expansion slot system. 

Right.

> a) that is hard
> b) we probably wouldn't get it right the first time
> c) most of the fast stuff is already on the motherboard

> I agree that an ISA bus would be neat and allow us to put lots of 
> clone cards in the system, but I could live even without this.

Right too.

> However, I feel that we should run every line going to the cpu also
> to some sort of connector.  Just one.  A bunch of other signals can
> go to/come from this slot, but the important thing is to allow
> someone else, later, to put a daughter card there that perhaps 
> can do the nifty bus stuff, or whatever.

That might lead us into heavy-duty timing problems. I would not
do that since nobody knows what kind of daughterboards we might need.

> Perhaps someone would like to make an AXP daughtercard.  Or a 486 card to allow
> running of Linux binaries.  Make it simple.  Don't worry about
> how others might use it.  And the great thing is, it is just
> the cost of a (perhaps very big) connector.  Cheap.  Which I 
> appreciate.

Too much overhead. And big connectors aren't cheap !
We would have to guarantee timings, signal delays, driver fan outs
and so on, or third-party add-on cards may run on one one board
but not on others.
What do we want to have ? A low-cost/high-speed workstation or a
multi-cpu/multi-architecture dinosaur ?

Bye,
Andy




-------------------------------------------------------------------------------
Waldorf Electronics GmbH, R&D Department
c/o Andreas Busse
Neustrasse 9-12
D-5481 Waldorf
Phone:  +49 (0)2636-80294
Fax:    +49 (0)2636-80188
e-mail: andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------

 
From PET@informatik.ee.edag.de Fri Jun 25 10:14:32 1993
Return-Path: <PET@informatik.ee.edag.de>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA14267; Fri, 25 Jun 93 10:14:27 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15611; Fri, 25 Jun 93 01:14:15 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA04674; Fri, 25 Jun 93 01:14:05 -0700
Received: from iraun1.ira.uka.de 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15601; Fri, 25 Jun 93 01:13:56 -0700
Received: from xlink1.xlink.net by iraun1.ira.uka.de with SMTP (PP) 
          id <01673-0@iraun1.ira.uka.de>; Fri, 25 Jun 1993 10:13:29 +0200
Received: from edfd by xlink1.xlink.net id aa08382; 25 Jun 93 10:13 MET DST
Received: from charon (informatik) by edfd.edag.de with SMTP 
          id AA06954 (5.65c/IDA-1.5 for <riscy@pyramid.com>);
          Fri, 25 Jun 1993 09:16:49 +0200
Received: From INFORMATIK/WORKQUEUE by charon via Charon-4.0A-VROOM with IPX 
          id 100.930625091234.256; 25 Jun 93 09:08:53 +0100
Message-Id: <MAILQUEUE-101.930625091156.448@informatik.ee.edag.de>
To: pyramid.com!riscy@informatik.ee.edag.de
From: peter katzmann <PET@informatik.ee.edag.de>
Date: 25 Jun 93 09:11:56 CET
Subject: Support processor in the design
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: RO
X-Status: 

High,
what is about to think of a communication and support processor. Some
people mentioned about several serial I/O's a other one would have
added sound support and we have also to handle a keyboard and
probably scsi and ethernet.
Normaly you could handle all from the CPU or get some smarter parts
which handle more themselve. But one possible solution could be to
add a common cheap 8 Bit processor like the 6809 and let him work as
a kind of communication processor.
Also what I prever is an little bit intelligent video subsystem. It
shouldn't be much but something like drawing line and Raster Op
should be possible, to decrease the heavy graphical work load of the
system.

p. katzmann
----

EDAG-Fulda | P. Katzmann | E-Planung | Steinauer Str.| 6400 Fulda
tel. 0661/6000-454/464 | W. Germany | in: pet@informatik.ee.edag.de

 
From broadley@neurocog.lrdc.pitt.edu Fri Jun 25 10:48:38 1993
Return-Path: <broadley@neurocog.lrdc.pitt.edu>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA14307; Fri, 25 Jun 93 10:48:33 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21249; Fri, 25 Jun 93 01:48:17 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA10891; Fri, 25 Jun 93 01:48:11 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21198; Fri, 25 Jun 93 01:48:09 -0700
Message-Id: <9306250848.AA21198@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA23229; Fri, 25 Jun 93 04:47:57 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Long ramblings about project design
To: riscy@pyramid.com (Mips 3000)
Date: Fri, 25 Jun 1993 04:47:56 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 5264      
Status: RO
X-Status: 


Just more random thoughts on the project from my hardware naive view:

The goal of the project seems to be to have fun building/designing a
new motherboard that is fast, clean, low parts count, with a nice cpu on it.

Kinda of a poor man's workstation that doesn't benefit microsoft or intel.

Since most of us can't spend $700 or so on a whim we would consider it
quite an investment. (I'd sell my maxed out 386-40+387 for one)

The minimal cost solution would a cpu+ram on a ISA slow, but this seems of 
little utility and would be quite ISA limited.  I'd guess the cost would 
be around $150-$200 above the cost of the cpu?

Despite ISA's bad reputation it handles up to 4-5 MB a second which, despite 
the advertising, is enough for most users bus needs with the possible exception
of high resolution video.  Not many people need more then 4 MB/sec for disk 
bandwidth etc.

So if you add video support on board you have greatly reduced your
load for the ISA bus at the cost of 1 MB vram + support chips ($60-$75)?

I believe that VESA support is almost free (simple bus) is this true?
Are non-surface mounted chips available?  A fairly high end VESA local
bus S3 805 can be had for less then $200 (+ cost of supporting vesa).
I see VESA as the only possibility for future expansion, because EISA
is to expensive ??  Vesa nicely  maxes out at 40 Mhz to ;-)

I'd say if we can get half the performance for less then half the price
and forget VESA bus, otherwise it's an option (somebody posted a do it 
all chip that supported vesa, haven't heard of availability yet).

Apparently the TI34020 is a fairly powerful chip (used in xterminals from 
tektronics, and high end (> $1k) video cards.  I know of no free drivers and 
I suspect that they would be quite involved to write them (I believe I've seen 
entire X11 servers running on them, which would be WAY cool.)  I am suprised 
they are cheap and would volunter to attempt an X11 driver for that chip.  
But writing a X11 server for a TMS34020 is beyond me, as oppsed to a driver 
which I think I could get to work.  Am I thinking of the correct chip here?

As an interesting side note Tektronics gave up on there xterminals with
68030's at 20 Mhz and TI 34020 chips at 40 Mhz because they were to slow
they switched to mips 3000's.  Wonder if tektronics would release there
tiga drivers ;-)

Apparently a SCSI buss is pretty cheap (Did I hear $5.00?) I'd suggest
SCSI-II 5 MB/sec as a minimum (scsi-II is supposed to be "defined" then
scsi-I so hopefully less compatibility problems).  No need for more
speed really (most drives can handle max 1.0-1.5 MB/sec real world).
It's a BIG win if it's as cheap as I thought I heard.

By this time it's probably better to go with a motherboard as opposed to
a ISA card, we have already gotten rid of the 2 biggest bus users.  

How many people who want a mips have ethernet?  I don't. Why not 
standardize on say a WD8013? It has a 32 k cache or so and ethernet is a 
MAX 10 megabit, or 1.25 MB which the ISA should handle fine (especially since 
we have fast int cpu).  Remeber disk, and video are already on a different bus.
(Either VESA or native) Is it cheaper to do it on board? 

If you don't put ethernet on ISA why bother with ISA? You really want a sound 
blaster (remeber ya got to write the drivers) almost any magic ISA video card 
will be slower then VESA/NATIVE cards.  Serial is easy, parallel isn't that 
used (by me anyways 8-) ), and floppies can run on SCSI (granted not cheaply).

I know it hurts to have a board without slots, but the ISA is limiting enough 
so anything new and hot won't be happy in a ISA slot anyways. thats why we 
are not producing a ISA card right?

So My perfect machine would be 3081 (I want fp as you probably heard ;-) )
either on board frame buffer (side note: dec has a good paper on smart frame 
buffers), or VESA slot, SCSI-II, and either ISA, or ethernet. 

Oh yeah why so many sim slots?  I have hit the limit at 8 slots
(with 8 MB) and then upgraded to 16 MB in 4 slots.  I can see 16 slots
but why more? 16 MB is around $400 anyone planning to spend more then
$1600/64 MB for a mips machine running a linux derivative without a second
level cache?

Anyone have any idea how much money/board design is saved by the "integration"
of the 3051/3052 and 3081?  I.e. how much hard would it be to put in a chip 
that lacks such integration?  I.e. say I call motorolla tomorrow any they say 
we will ship some prerelease derated 40 Mhz (from 50 Mhz) powerpc chips for $200
a piece.  What would the cost of using a standard nonintegrated chip over a 
integrated/embedded chip?  I believe the price of the powerpc is expected
to be $320 or so for 50 Mhz (to fast but would probably work at 40), and
$400 at 66 Mhz.

Hmm another bossibiliy is a cheap non fpu processor that has bus snooping,
I think the 486 sx fits the description.  This probably isn't feaible 
and besides it's a INTEL chip (yuck)

I post if detailed summary of the powerpc if anyone wants.  Okay enough
rambling from the sleep deprived....

-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok


 
From drew@caesar.cs.Colorado.EDU Fri Jun 25 12:33:34 1993
Return-Path: <drew@caesar.cs.Colorado.EDU>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA14541; Fri, 25 Jun 93 12:33:30 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06032; Fri, 25 Jun 93 03:33:17 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA22506; Fri, 25 Jun 93 03:33:02 -0700
Received: from caesar.cs.colorado.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06019; Fri, 25 Jun 93 03:32:51 -0700
Received: from localhost by caesar.cs.Colorado.EDU with SMTP id AA13175
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Fri, 25 Jun 1993 04:32:38 -0600
Message-Id: <199306251032.AA13175@caesar.cs.Colorado.EDU>
To: riscy@pyramid.com, Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Re: Long ramblings about project design 
In-Reply-To: Your message of "Fri, 25 Jun 1993 04:47:56 CDT."
             <9306250848.AA21198@gossip.pyramid.com> 
Date: Fri, 25 Jun 1993 04:32:37 -0600
From: Drew Eckhardt <drew@caesar.cs.Colorado.EDU>
Status: RO
X-Status: 


    The minimal cost solution would a cpu+ram on a ISA slow, but this seems of 
    little utility and would be quite ISA limited.  I'd guess the cost would 
    be around $150-$200 above the cost of the cpu?

Might not be possible - there isn't a lot of realestate available on an 
ISA board.

    Despite ISA's bad reputation it handles up to 4-5 MB a second which, despit
   e 
    the advertising, is enough for most users bus needs with the possible excep
   tion
    of high resolution video.  

Possible isn't quite strong enough.

    I believe that VESA support is almost free (simple bus) is this true?
    Are non-surface mounted chips available?  A fairly high end VESA local
    bus S3 805 can be had for less then $200 (+ cost of supporting vesa).

Another poster suggested that  TI32010 can be had for $20, add
cost of the RAMDAC + either DRAM (about $20/meg) or VRAM (two-three times 
DRAM price).

    I see VESA as the only possibility for future expansion, because EISA
    is to expensive ??  Vesa nicely  maxes out at 40 Mhz to ;-)

Nasty timing problems acompany any high speed bus, and since we aren't 
Pee-Cee compatable VESA might not be that easy.
    
    Apparently the TI34020 is a fairly powerful chip (used in xterminals from 
    tektronics, and high end (> $1k) video cards.  I know of no free drivers an
   d 
    I suspect that they would be quite involved to write them (I believe I've s
   een 
    entire X11 servers running on them, which would be WAY cool.)  I am suprise
   d 
    they are cheap and would volunter to attempt an X11 driver for that chip.  

    But writing a X11 server for a TMS34020 is beyond me, as oppsed to a driver
    
    which I think I could get to work.  Am I thinking of the correct chip here?

You can allways use just a minimal amount of intelligence, ie treating
it as a dumb frame buffer if possible, or just doing bitblts with it until 
you get arround to doing a "propper" driver..
    
    Apparently a SCSI buss is pretty cheap (Did I hear $5.00?) 

That's where your SCSI chips start at.  

    I'd suggest SCSI-II 5 MB/sec as a minimum

With the exception of arbitration, it's entirely a software 
issue (and most SCSI-I systems implement arbitration).$

 (scsi-II is supposed to be "defined" then
    scsi-I so hopefully less compatibility problems).  No need for more
    speed really (most drives can handle max 1.0-1.5 MB/sec real world).

Most new drives are some what faster than this - if we assume 64 
sectors/track (not atypical), and a rotational speed of 3600RPM - 
that's 1920K/sec.  Better drives will spin at 5400 RPM, which
would be 2880K/sec.  

However, there's nothing stopping you from having multiple 
nexuses established to multiple devices at the same time,
in which case every device needs to be able to burst at 
a speed greater than the combined total of their sustained
transfer rates.  Add in command overhead when data isn't 
being transfered and it adds up quickly..
    
    How many people who want a mips have ethernet?  I don't. Why not 
    standardize on say a WD8013? It has a 32 k cache or so and ethernet is a 
    MAX 10 megabit, or 1.25 MB which the ISA should handle fine (especially sin
   ce 
    we have fast int cpu).  

   Remeber disk, and video are already on a different 
   bus.
    (Either VESA or native) Is it cheaper to do it on board? 

Yes, since this is a non-profit project, and your-not-top-of-the-line
ether, video, etc chips are cheap, your address decoding is on the same 
PAL as something else on the motherboard, and the price of your glue is 
negligible.

I'll call the national semi distributor again and get the pricing on
the 8390 (this is what the 8013 uses, unlike the proposed ~450K/sec 
AMD lance, it is allegedly a 1M/sec chip, and it is available in a 
PLCC package), and 8391 (transciever) (thinnet).

    I know it hurts to have a board without slots, but the ISA is limiting enou
   gh 
    so anything new and hot won't be happy in a ISA slot anyways. 

I'm begining to wonder about the need for the ISA bus - 

Pros : we can put nifty things like ROM burners in the ISA slots, and
	parallel printer/floppy controllers.

Cons :  the ISA slots take up lots of realestate (not just 
	for the connector - we could have clearance problems with 
	heat sinked chipps and SIMMs)

	Interfacing the ISA bus to the MIPs could be complicated,
	since the existing bus interface chips are designed to 
	mate up with x86 CPUs, etc.

How hard would it be to put a floppy controller and parallel port on
the mainboard compared to putting in a full ISA bus?
    
    Oh yeah why so many sim slots?  I have hit the limit at 8 slots
    (with 8 MB) and then upgraded to 16 MB in 4 slots.  I can see 16 slots
    but why more? 16 MB is around $400 anyone planning to spend more then
    $1600/64 MB for a mips machine running a linux derivative without a second
    level cache?

Memory interleaving.  You use more, smaller chips so that you can 
interleave memory accesses to them, cutting wait states by a factor 
of two for two-way for sequential accesses on a cache miss, four 
by four-way.  In order two take advantage of interleaving,
you need to fill two or four banks at a time.  

Hmm - I know our chipset supports 2-way interleave, does it support 
way?  And what about page mode?  
    
    Anyone have any idea how much money/board design is saved by the "integrati
   on"
    of the 3051/3052 and 3081?  I.e. how much hard would it be to put in a chip
    
    that lacks such integration?  I.e. say I call motorolla tomorrow any they s
   ay 
    we will ship some prerelease derated 40 Mhz (from 50 Mhz) powerpc chips for
    $200
    a piece.  What would the cost of using a standard nonintegrated chip over a
    
    integrated/embedded chip?  I believe the price of the powerpc is expected
    to be $320 or so for 50 Mhz (to fast but would probably work at 40), and
    $400 at 66 Mhz.

Wow! a volunteer to do the GNU ports of GCC and GDB to the PowerPC =8^)

We'd also need support chips (availability and cost?), and would have to
work arround hardware bugs in the chip (ie, early 386's that didn't 
run in protected mode, the 68040 with broken transcendental functions,
etc).

Since we have the tools, the SPARC might be worth looking at.
    
    Hmm another bossibiliy is a cheap non fpu processor that has bus snooping,
    I think the 486 sx fits the description.  This probably isn't feaible 
    and besides it's a INTEL chip (yuck)

The solution we're looking at right now would be competitive with a 
486DX2-66 in terms of both price (I can get a 486DX2-66/64K secondary 
cache VESA local bus mainboard for $610 (Of course, this doesn't include 
video (say $150), SCSI (say $200), ethernet ($80), 16550's, etc)) and 
performance (integer performance is very comparable, floating point 
is as much as 5X as much).  

I really like it, especially now that I've quit DOS!
    
--------


 
From tor@tss.no Fri Jun 25 13:27:56 1993
Return-Path: <tor@tss.no>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA14718; Fri, 25 Jun 93 13:27:52 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA13639; Fri, 25 Jun 93 04:27:40 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA28407; Fri, 25 Jun 93 04:27:34 -0700
Received: from benoni.Uit.No 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA13630; Fri, 25 Jun 93 04:27:32 -0700
Received: from benoni by ppenoni.uit.no with SMTP (PP) 
          id <00558-0@ppenoni.uit.no>; Fri, 25 Jun 1993 13:27:20 +0000
Received: from unas.tss.no 
          by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) 
          id AAbenoni00554; Fri, 25 Jun 1993 13:27:15 +0200
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA15449;
          Fri, 25 Jun 93 13:21:45 +0200
Message-Id: <9306251121.AA15449@unas.tss.no>
From: tor@tss.no (Tor Arntsen)
Date: Fri, 25 Jun 1993 13:21:43 +0200
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: riscy@pyramid.com
Subject: ISA or not? (Was: Re: Long ramblings about project design)
Status: RO
X-Status: 

Drew Eckhardt wrote:
[...] 
} I'm begining to wonder about the need for the ISA bus - 
I'm beginning to wonder as well.. 

} 
} Pros : we can put nifty things like ROM burners in the ISA slots, and
} 	parallel printer/floppy controllers.
What about RS-232 ROM burners?  I have to admit I haven't used ROM burners 
since when one could only get serial versions.  Are ISA versions more useful?

} Cons :  the ISA slots take up lots of realestate (not just 
} 	for the connector - we could have clearance problems with 
} 	heat sinked chipps and SIMMs)
} 
} 	Interfacing the ISA bus to the MIPs could be complicated,
} 	since the existing bus interface chips are designed to 
} 	mate up with x86 CPUs, etc.
 
I need Video, Ethernet, SCSI, serial (in that order of preference :-)
Seems like it could be done without ISA.
With Ethernet and serial one can have access to most anything.

(OK, many people don't have a net (ethernet or slip) to connect to,
 but even then the Ethernet connector may serve as an expansion interface.
 There are a lot of devices (terminal servers comes to mind) that can be
 connected using Ethernet & tcp/ip))

} How hard would it be to put a floppy controller and parallel port on
} the mainboard compared to putting in a full ISA bus?
[...]

Floppy is useful.
Is a parallel port really necessary?  Serial printers should do, no?

BTW, what about second level cache?  Will it be difficult to add support
for it?  Just came to think about how badly many 486 boards perform when
running without cache enabled, or when one try to put more than 16 MB into
some of the boards with only 64 KB external cache.  (Oops, I hope I don't
initiate another cache flame war :-)

Regards,
Tor	(tor@tss.no)

 
From Steven.D.Ligett@Dartmouth.EDU Fri Jun 25 15:19:14 1993
Return-Path: <Steven.D.Ligett@Dartmouth.EDU>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA15060; Fri, 25 Jun 93 15:19:09 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA00416; Fri, 25 Jun 93 06:18:57 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA10031; Fri, 25 Jun 93 06:18:48 -0700
Received: from dartvax.dartmouth.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA00328; Fri, 25 Jun 93 06:18:42 -0700
Received: from prancer.dartmouth.edu by dartvax.dartmouth.edu (5.65+D5/4.5HUB)
	id AA20365; Fri, 25 Jun 93 09:17:19 -0400
Message-Id: <5264379@prancer.Dartmouth.EDU>
Date: 25 Jun 93 09:17:15 EDT
From: Steven.D.Ligett@Dartmouth.EDU (Steven D. Ligett)
Subject: The MIPs design I've been working on
To: riscy@pyramid.com (Mips 3000)
Status: RO
X-Status: 

I've been noodling along on a design for a MIPS box based on the IDT chips
for the past two years.  Some folks ideas here have been along the same
lines, what with serial I/O processors, etc., so I'll outline where my design
is.  Any details are subject to change, of course.  Let me first draw a
simple picture.

   +-----+     +-----+     +-----+
   | 3081|     | RAM |     |     |     
   | or  |<--->| and |<--->| 3041|     
   | 3051|     | VRAM|     |     |
   +-----+     +-----+     +-----+
                  |           |
               +-----+     +-----+
               |RAM- |     | I/O |     
               | DAC |     | and |     
               |     |     |EPROM|
               +-----+     +-----+

The main cpu is a 3051 @ 20 mhz or a 3081 @ 40 mhz.  The main cpu is
connected ONLY to the RAM and VRAM.  Three 72-pin SIMMs for the RAM (up to 96
MB, if you can afford 32 MB SIMMs).  VRAM composed of Mac compatible SIMMs;
either 512 KB or 1 MB.

All the I/O goes through the 3041 @ 20 mhz.  Basically, the 3041 is a smart
DMA controller for the 3081.  There's a 53c94 SCSI chip on a 16-bit bus, some
26c94 quad uarts on an 8-bit bus, one boot eprom on the 8-bit bus, and some
slots.  The slots are a simple 8-bit bus, 36 pins, giving up to about
10MB/sec off the 3041.  The 3041 invisibly (to the software) handles 8, 16,
and 32 bits tranfers.

The RAMDAC is in the TI 34076 family, which cost from $15 on up, depending on
speed, features, etc.  Timing is handled by a NSC chip whose number escapes
me at the moment.

 
From calica@cae.wisc.edu Fri Jun 25 16:42:21 1993
Return-Path: <calica@cae.wisc.edu>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA15196; Fri, 25 Jun 93 16:42:15 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09401; Fri, 25 Jun 93 07:42:01 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15818; Fri, 25 Jun 93 07:41:46 -0700
Received: from serv0.cae.wisc.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09393; Fri, 25 Jun 93 07:41:45 -0700
Received: from hprisc-26.cae.wisc.edu by serv0.cae.wisc.edu (4.1/25)
	id AA22297; Fri, 25 Jun 93 09:40:22 CDT
Received: by hprisc-26.cae.wisc.edu (16.8/client-1.3)
	id AA05495; Fri, 25 Jun 93 09:37:31 -0500
From: Carlo J. Calica <calica@cae.wisc.edu>
Message-Id: <9306251437.AA05495@hprisc-26.cae.wisc.edu>
Subject: SPIM...
To: riscy@pyramid.com
Date: Fri, 25 Jun 93 9:37:31 CDT
Mailer: Elm [revision: 66.36.1.2]
Status: RO
X-Status: 

> 
> I just thought I'd let everyone know about a software tool that could
> come in extremely handy during initial development. The program is
> called spim (or xspim) and is a MIPS R3k CPU simulator. The program
> compiles under Linux with a bit of fiddling, and seems to perform
> pretty well.
> 
> There are a couple of different versions of the program in the source
> distribution:
> 
> 	spim: assembly-level simulator (text mode)
> 	xspim: assembly-level simulator (runs under X)
> 
> I haven't looked at either of the cycle-level simulators yet, but I'd
> have to assume they worked ok. There are a few BSDisms in the code that
> can be fixed by modifying some #include <whatever.h> to the appropriate
> #include <bsd/whatever.h> and by linking with -lbsd.
> 
> Anyhow, I think it could be quite a useful tool...
> 
SPIM is pretty useful.  I used it in an intro to assembly class here at the
UW.  The binaries ARE available on sunsite under emulators.  The xspim has
a nice interface.  It allows you to step through code.  The emulator reads
in the source at text levels and also takes the a.out files of a compiler.

--
 /------------------------------+--------------------------------------\
| Carlo J. Calica               | Linux:  Choice of the GNU Generation  |
|     calica@cae.wisc.edu       | Dittos from the People's              | 
 \ University of Wisconsin      | Republic of Madison                  / 

 
From drew@caesar.cs.Colorado.EDU Fri Jun 25 16:49:42 1993
Return-Path: <drew@caesar.cs.Colorado.EDU>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA15207; Fri, 25 Jun 93 16:49:32 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA10390; Fri, 25 Jun 93 07:49:24 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16767; Fri, 25 Jun 93 07:49:19 -0700
Received: from caesar.cs.colorado.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA10379; Fri, 25 Jun 93 07:49:16 -0700
Received: from localhost by caesar.cs.Colorado.EDU with SMTP id AA15244
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Fri, 25 Jun 1993 08:48:37 -0600
Message-Id: <199306251448.AA15244@caesar.cs.Colorado.EDU>
To: riscy@pyramid.com, Steven.D.Ligett@dartmouth.edu (Steven D. Ligett)
Subject: Re: The MIPs design I've been working on 
In-Reply-To: Your message of "25 Jun 1993 09:17:15 EDT."
             <5264379@prancer.Dartmouth.EDU> 
Date: Fri, 25 Jun 1993 08:48:32 -0600
From: Drew Eckhardt <drew@caesar.cs.Colorado.EDU>
Status: RO
X-Status: 



    I've been noodling along on a design for a MIPS box based on the IDT chips
    for the past two years.  Some folks ideas here have been along the same
    lines, what with serial I/O processors, etc., so I'll outline where my desi
   gn
    is.  Any details are subject to change, of course.  Let me first draw a
    simple picture.
    
       +-----+     +-----+     +-----+
       | 3081|     | RAM |     |     |     
       | or  |<--->| and |<--->| 3041|     
       | 3051|     | VRAM|     |     |
       +-----+     +-----+     +-----+
                      |           |
                   +-----+     +-----+
                   |RAM- |     | I/O |     
                   | DAC |     | and |     
                   |     |     |EPROM|
                   +-----+     +-----+
    
    The main cpu is a 3051 @ 20 mhz or a 3081 @ 40 mhz.  The main cpu is
    connected ONLY to the RAM and VRAM.  Three 72-pin SIMMs for the RAM (up to 
   96
    MB, if you can afford 32 MB SIMMs).  

Since normal humans can't afford the 25ns memory to run 0ws, 
we need to run with wait states (which kill performance) =8^)
Interleaving can cut the number of waitstates, but we can't do it 
if our memory is all on a single 32 bit SIMM. 

    VRAM composed of Mac compatible SIMMs;
    either 512 KB or 1 MB.

Are you talking VRAM, or DRAM?  The former is inherently dual 
ported, and keeps the video hardware from eating over half our memory
bandwidth.  If we're using the later, how have you isolated it from the 
main bus? 
    
    All the I/O goes through the 3041 @ 20 mhz.  Basically, the 3041 is a smart
    DMA controller for the 3081.  There's a 53c94 SCSI chip on a 16-bit bus, so
   me
    26c94 quad uarts on an 8-bit bus

I'm not familiar with this chip.  How big are the buffers (very important
if it's entirely interrupt driven),  and will it interface with a DMA 
controller?

  one boot eprom on the 8-bit bus, and some
    slots.  The slots are a simple 8-bit bus, 36 pins, giving up to about
    10MB/sec off the 3041.  

A propriety 8-bit bus is a neat idea - we get some breathing room for 
second ethernet boards, etc, but don't have to jump through hoops doing
ISA compatability.

Along these lines, another thing that may be worth considering to satisfy
the anti-ethernet/uart/etc minimalists would be including sockets, address
decoding, and glue for these parts but leaving the sockets empty on one 
set of boards.
    
    The RAMDAC is in the TI 34076 family, which cost from $15 on up, depending 
   on
    speed, features, etc.  Timing is handled by a NSC chip whose number escapes
    me at the moment.

Is the TI 34076 whatever a CRT controller and a RAM DAC (ie pallette chip)?
If it's the later, what are you driving it with?

--------


 
From kender@super.org Tue Jun 22 14:36:36 1993
Return-Path: <kender@super.org>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA03129; Tue, 22 Jun 93 14:36:28 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA03029; Tue, 22 Jun 93 05:39:08 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA14073; Tue, 22 Jun 93 05:36:10 -0700
Received: from super.super.org 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA02976; Tue, 22 Jun 93 05:39:03 -0700
Received: from bart.super.org by super (4.1/SMI-4.1)
	id AA25686; Tue, 22 Jun 93 08:34:46 EDT
Received: from localhost.super.org by bart.super.org (4.1/SMI-4.1)
	id AA07837; Tue, 22 Jun 93 08:34:45 EDT
Message-Id: <9306221234.AA07837@bart.super.org>
To: riscy@pyramid.com
Subject: r3000 PC
Date: Tue, 22 Jun 93 08:34:44 -0400
From: ----------------+-------------------------------|The views represented here are  <kender@super.org>
Status: RO
X-Status: 

I would love to help right now - however, i don't have access to my own 
PC (yet ;).  Hopefully, within another month, i'll be able to do a little bit
more.  However, I was quite interested in doing some porting (namely, of linux;)

One quick question - my experience with r3ks is very limited (we have 
DECstation 2100's at school, but very little tech stuff that i had access to),
if anyone could suggest any materials i could review (net or paper bound), i'd
appreciate it.

D

-------------------------------------------------------------------------------
Daniel Garcia  	| Supercomputing Research Center|	
Kender@super.org| 17100 Science Drive		|  This space for rent
(301)-805-7320	| Bowie, Maryland 20715-4300	|

 
From mackinla@cs.curtin.edu.au Fri Jun 25 16:50:12 1993
Return-Path: <mackinla@cs.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA15211; Fri, 25 Jun 93 16:50:07 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA10402; Fri, 25 Jun 93 07:49:56 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16780; Fri, 25 Jun 93 07:49:51 -0700
Received: from marsh.cs.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA10394; Fri, 25 Jun 93 07:49:40 -0700
Received: from vincent.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA00923
  (5.67a/IDA-1.5 for <riscy@pyramid.com>); Fri, 25 Jun 1993 22:48:04 +0800
Received: by vincent.cs.curtin.edu.au id AA26313
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Fri, 25 Jun 1993 22:47:52 +0800
From: Patrick Mackinlay <mackinla@cs.curtin.edu.au>
Message-Id: <199306251447.AA26313@vincent.cs.curtin.edu.au>
Subject: Video subsystem...
To: riscy@pyramid.com (R3000 PC Mailing List)
Date: Fri, 25 Jun 1993 22:47:52 +0800 (WST)
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2164      
Status: RO
X-Status: 


>[...comments from Drew about video bandwidth deleted...]
>
>This is a good point; this certainly points to using VRAM.  At present there
>are far too many unknowns about the video section to really address this
>issue.  Someone needs to do some research as to what cheap video stuff
>there is.  Using the S3 chip (as some one suggested) may be a good idea,

When I asked about S3 chips, I was told that they were all SMT with no
plans to do PGA or other packages. The other suggestion was to use the
6845 and the 3730's video stuff to do a very simple framebuffer solution.
As Drew points out, this would seem to suck up a lot of the available
memory bandwidth. There are a couple of other suggestions that might be
worth looking at. Firstly, to do the dumb framebuffer option, but use
VRAM. This would require a (relatively simple) bit of logic to clock
dots out of the VRAM at the right rate, and I don't think the 6845 is
capable of doing this.

The other option that I think has some merit is to use the TMS34010.
This chip used to be pretty expensive, but I think it's dropped a lot
since the last time I looked. The advantage with this chip is not so
much speed, but simplification of the overall design. Depending on
the price of the actual device, I think it could be one way to make
the video section pretty cheap. I've been told by some other guys
that it's quite easy to deal with as far as integration with the main
CPU is concerned (that's what it's designed for, after all!). I have
a few concerns that it might mean putting another ROM on the board,
but that might be cheaper and easier than other solutions (I think
it's got dynamic bus sizing stuff on-board in any case).

Any comments on this? Anyone have pricing info on the 34010?

BTW: There's a possibility the ET4000 or other VGA chips come in
non-SMT versions, but I'd personally prefer to stay away from them.
As far as I can see, the best way to slow a video system down is
to stuff it through a VGA chip...

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 mackinla@cs.curtin.edu.au Fri Jun 25 17:17:22 1993
Return-Path: <mackinla@cs.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA15295; Fri, 25 Jun 93 17:17:14 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA14171; Fri, 25 Jun 93 08:17:04 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA20497; Fri, 25 Jun 93 08:16:59 -0700
Received: from marsh.cs.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA14161; Fri, 25 Jun 93 08:16:50 -0700
Received: from vincent.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA01275
  (5.67a/IDA-1.5 for <riscy@pyramid.com>); Fri, 25 Jun 1993 23:15:23 +0800
Received: by vincent.cs.curtin.edu.au id AA26348
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Fri, 25 Jun 1993 23:15:19 +0800
From: Patrick Mackinlay <mackinla@cs.curtin.edu.au>
Message-Id: <199306251515.AA26348@vincent.cs.curtin.edu.au>
Subject: Re: Endianness..
To: riscy@pyramid.com (R3000 PC Mailing List)
Date: Fri, 25 Jun 1993 23:15:19 +0800 (WST)
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1517      
Status: RO
X-Status: 


>I favor big endian for the mips project for two reasons:

Count me as another vote for big endian. I'd like a hardware configuration
option too though (just in case <grin>).

>I agree that an ISA bus would be neat and allow us to put lots of 
>clone cards in the system, but I could live even without this.

I used to think that we could do without any sort of I/O expansion bus,
but it does mean that you have to put _everything_ on the motherboard,
including disgusting things like floppy controllers. If we can do an
ISA interface (anyone have any ideas on how to do this yet?) without
affecting the overall price too much, I'd say go for it. If not, rip
it off and use Steve's simpler design. This will mean that we have to
make our own cards, but they won't be difficult, and it will keep the
cost of the whole machine down.

Basically, assuming we have video, SCSI and Ethernet on the motherboard,
the only things needed on the expansion bus will be a floppy interface,
more serial ports (?), a sound chip and anything else anyone decides
they want. I actually think Steve's I/O bus is a better way to go at
this stage, and will probably continue to think so until someone comes
up with a reasonable solution to doing a cheap ISA bus. Steve, perhaps
you could mail your bus spec to the list? Feel confident enough about
it <grin>?

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 Steven.D.Ligett@Dartmouth.EDU Fri Jun 25 17:21:18 1993
Return-Path: <Steven.D.Ligett@Dartmouth.EDU>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA15302; Fri, 25 Jun 93 17:21:13 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA14805; Fri, 25 Jun 93 08:21:04 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA21006; Fri, 25 Jun 93 08:20:59 -0700
Received: from dartvax.dartmouth.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA14795; Fri, 25 Jun 93 08:20:57 -0700
Received: from prancer.dartmouth.edu by dartvax.dartmouth.edu (5.65+D5/4.5HUB)
	id AA29828; Fri, 25 Jun 93 11:19:37 -0400
Message-Id: <5266472@prancer.Dartmouth.EDU>
Date: 25 Jun 93 11:19:32 EDT
From: Steven.D.Ligett@Dartmouth.EDU (Steven D. Ligett)
Subject: Re: The MIPs design I've been working on 
To: riscy@pyramid.com
Status: RO
X-Status: 

Drew Eckhardt asked some questions about the simple explanation of the design
I threw out:

(on memory system design)
1) Since normal humans can't afford the 25ns memory to run 0ws, 
we need to run with wait states (which kill performance) =8^)
Interleaving can cut the number of waitstates, but we can't do it 
if our memory is all on a single 32 bit SIMM. 

My goal is cheap.  The memory is not interleaved.  Both cpus share the ram,
but the 3041 is expected to run its little DMA code out of cache most of the
time.  Also, the Vram is on the same bus.  cheap.

(really Vram?)
2) Are you talking VRAM, or DRAM?  The former is inherently dual 
ported, and keeps the video hardware from eating over half our memory
bandwidth.  If we're using the later, how have you isolated it from the 
main bus? 

Vram SIMMs.  All current Macs use them - giving us low cost, and availability
due to volume, and availability.  cheap.

(on the Philips (signetics) Uart)
3) I'm not familiar with this chip.  How big are the buffers (very important
if it's entirely interrupt driven),  and will it interface with a DMA 
controller?

Quad uart.  52 pin plcc.  8 byte fifos for each channel's receive and xmit
channels.  I mean, 8 for each receive, and 8 for each xmit.  Programmable
fifo interrupt thresholds.  (One instruction on the 3041 will read/write 4
bytes.)  Four pins per channel for modem controls.  Biggest lack - arbitrary
baud rates.  There are six sets of baud rates, and pairs of channels share
sets of rates.  Within a pair, any xmitter or xrcvr can have any rate from
the set.  $24.  cheap.

(on the I/O bus)
4) A propriety 8-bit bus is a neat idea - we get some breathing room for 
second ethernet boards, etc, but don't have to jump through hoops doing
ISA compatability.

Along these lines, another thing that may be worth considering to satisfy
the anti-ethernet/uart/etc minimalists would be including sockets, address
decoding, and glue for these parts but leaving the sockets empty on one 
set of boards.

Aside from the scsi, and one or two quad uarts, I don't see putting much I/O
on the board.  An RTC/eeprom.  I'd have to be convinced that ethernet needs
to be on the motherboard.  The I/O bus is JUST for I/O I don't have my notes
with me, but it's 8 data lines, a small number of address lines, +12, +5,
-12, grounds, clock, and some handshake lines.  Each slot is decoded into a
separate address block.  That is, the handshake lines aren't bussed - they're
decoded.

(on the video)
5) Is the TI 34076 whatever a CRT controller and a RAM DAC (ie pallette
chip)?
If it's the later, what are you driving it with?

It's a ramdac - the NSC timing chip controls - well, it controls the timing! 
:-)  An 80 mhz clock would drive the pixels (1024x768), and provide the
processor clocks as well.  Would have space for other oscillators on the
board.  I'll dig up the NSC chip info.  The 34076 does the ordinary 1, 2, 4,
or 8 to 24 bit table lookups.


 
From caret@pyramid.com Fri Jun 25 18:31:03 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA15422; Fri, 25 Jun 93 18:30:58 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA01819; Fri, 25 Jun 93 09:30:48 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA29204; Fri, 25 Jun 93 09:29:42 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306251629.AA29204@sword.eng.pyramid.com>
Subject: MC68302 & sound
To: riscy@pyramid.com
Date: Fri, 25 Jun 93 9:29:41 PDT
In-Reply-To: <9306240305.AA00861@hprisc-25.cae.wisc.edu>; from "Carlo J. Calica" at Jun 23, 93 10:05 pm
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

> > The best I've seen is the Motorola MC68302, which has 3 serial ports
> > capable of some very good speed.  However, this guy may be a little
> > too expensive, since its also has a 68000 CPU core in it.
> > 
> Well if we do use this 'extra' CPU could we use it for something?  Maybe
> sound?  In any case sound is something to think about.  If we do add it
> would it be a simple DAC or something more complicated?  If set up properly,
> the 68000 (or something more specialized) could combine various waves forms
> to two DACs.  That would be all digital and sound better than most anything
> for the PC.

The 68302 is not that likely.  If I remember rightly it will cost most
of $100 (I should check that).

As for sound, I was thinking of that, but something that could be somewhat
useful to the DSP guys.  This would mean at least a 30KHz variable sample
rate DAC with a variable filter;  This is starting to smell of creeping
featurism.

-- 
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 caret@pyramid.com Fri Jun 25 18:36:13 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA15438; Fri, 25 Jun 93 18:36:02 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA02900; Fri, 25 Jun 93 09:35:51 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA00380; Fri, 25 Jun 93 09:35:43 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306251635.AA00380@sword.eng.pyramid.com>
Subject: Re: UARTs
To: riscy@pyramid.com
Date: Fri, 25 Jun 93 9:35:42 PDT
In-Reply-To: <9306240314.AA00907@hprisc-25.cae.wisc.edu>; from "Carlo J. Calica" at Jun 23, 93 10:14 pm
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

> Please be sure to use two for a total of 4 UARTs.  I'd like as many as
> possible to hang terminals off of.

I'm figuring on two ports.  One is required to aid debugging of the board
and the operating system, the second is almost free.  But more than that
would turn the board into one of the world's most intelegent multi-port
serial cards.    (Mind you, it would be cheaper that a lot of other
multi-port cards ;-) ).  This is not to say that we can't provide
for more than two ports; adding extra pads to the board for extra serial
chips would be simple.

-- 
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 caret@pyramid.com Fri Jun 25 18:44:35 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA15448; Fri, 25 Jun 93 18:44:31 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04249; Fri, 25 Jun 93 09:44:23 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA01557; Fri, 25 Jun 93 09:44:18 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306251644.AA01557@sword.eng.pyramid.com>
Subject: Re: UARTs, was : Re 2nd update
To: riscy@pyramid.com
Date: Fri, 25 Jun 93 9:44:18 PDT
In-Reply-To:  <9306241105.aa22796@keg.cs.vu.nl>; from "Willy Konijnenberg" at Jun 24, 93 11:05 am
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

> Why would you want to put UARTs on the motherboard?  They don't consume
> enough I/O bandwidth to justify hooking them up to the local bus.
> If you include too many fancies, the board gets more complicated and
> more expensive than it needs to be.
> Better stick to things that need the bandwidth, like SCSI, ethernet, video.
> If you want 16552 UARTs, build a simple ISA board with 4 sockets for them.

Yup, but its much easier to debug the ISA bus hardware when you can
talk to the CPU.  Also, almost everyone will use at least one serial port
with this (for a mouse for X); I think it's justified.

-- 
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 wolff@dutecai.et.tudelft.nl Fri Jun 25 18:45:08 1993
Return-Path: <wolff@dutecai.et.tudelft.nl>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA15452; Fri, 25 Jun 93 18:45:04 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04419; Fri, 25 Jun 93 09:44:55 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA01625; Fri, 25 Jun 93 09:44:50 -0700
Received: from liberator.et.tudelft.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04335; Fri, 25 Jun 93 09:44:36 -0700
Received: by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA04637; Fri, 25 Jun 93 18:43:12 +0200
Date: Fri, 25 Jun 93 18:43:12 +0200
From: wolff@dutecai.et.tudelft.nl (Rogier Wolff)
Message-Id: <9306251643.AA04637@liberator.et.tudelft.nl>
To: caret@pyramid.com, riscy@pyramid.com
Subject: Re:  MC68302 & sound
Status: RO
X-Status: 



How about the DATEL 305 for a AD converter? It costs $25 a piece, and will
digitize upto 20M samples per second. With something giving it the right
clock, it off course will also sample audio frequencies.

Pro: 1)"unlimited" bandwidth, 2) cheap.
Con: 1) I don't need AD, 2) Expensive.

DA is usually less expensive. 

I'd pay money for something that would "out-of-the-box" be able to digitize
whatever I'd feed it.

Usually AD converters that sample more than 1M samples per second are more 
than $100, what's the trick? The trick is that it contains 3 fourbit AD 
converters. The first one does a course digitization (1 clock), Next
the other two toggle, and take two clocks to determine the lower 4 bits.
Result is that you have a 2.5 clock delay between sample point and
digital result.... This implementation requires only 48 comparators 
and resistors in ladder arrangement, instead of 256.

					Roger.


 
From caret@pyramid.com Fri Jun 25 18:47:12 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA15458; Fri, 25 Jun 93 18:47:07 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04467; Fri, 25 Jun 93 09:46:52 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02004; Fri, 25 Jun 93 09:46:47 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306251646.AA02004@sword.eng.pyramid.com>
Subject: Re: big/little endian
To: riscy@pyramid.com
Date: Fri, 25 Jun 93 9:46:47 PDT
In-Reply-To: <9306240902.AA09427@unas.tss.no>; from "Tor Arntsen" at Jun 24, 93 11:02 am
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

> I would prefer big endian, but I have no strong objections (that means, I will
> buy the board anyway) if it ends up the other way (the DEC/Intel way vs. 
> the rest of the world.. :-) :-)

It's a matter of adding a single jumper to select what endian.  This board
will come configurable for either endian.  This is more a software issue,
and a debate as to whether this ISA bus should do byte swapping.

-- 
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 caret@pyramid.com Fri Jun 25 19:05:58 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA15498; Fri, 25 Jun 93 19:05:52 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA07714; Fri, 25 Jun 93 10:05:42 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA05604; Fri, 25 Jun 93 10:05:37 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306251705.AA05604@sword.eng.pyramid.com>
Subject: Re: Support processor in the design
To: riscy@pyramid.com
Date: Fri, 25 Jun 93 10:05:36 PDT
In-Reply-To: <MAILQUEUE-101.930625091156.448@informatik.ee.edag.de>; from "peter katzmann" at Jun 25, 93 9:11 am
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

> High,
> what is about to think of a communication and support processor. Some
> people mentioned about several serial I/O's a other one would have
> added sound support and we have also to handle a keyboard and
> probably scsi and ethernet.
> Normaly you could handle all from the CPU or get some smarter parts
> which handle more themselve. But one possible solution could be to
> add a common cheap 8 Bit processor like the 6809 and let him work as
> a kind of communication processor.
> Also what I prever is an little bit intelligent video subsystem. It
> shouldn't be much but something like drawing line and Raster Op
> should be possible, to decrease the heavy graphical work load of the
> system.

Hi,
  Making the I/O co-processor a requirement could quickly make the
price of the board sky-rocket, if we're not careful.  It is nice to
consider these options in the hope that we could find something that
would be cheaper to add.  I don't think that a 6809 would fit this
bill.  Consider that we could add a R3041 (R300 for real cheap) to
do this for us$15 (plus the glue), but what is the justification?

An idea, one chip that could cover both of the above requests could
be the TI34010 graphics CPU.  Last I checked you could get them at
around us$30 (that was a year ago).

-- 
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 caret@pyramid.com Fri Jun 25 20:40:25 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA15708; Fri, 25 Jun 93 20:40:21 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23902; Fri, 25 Jun 93 11:40:07 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA19807; Fri, 25 Jun 93 11:39:44 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306251839.AA19807@sword.eng.pyramid.com>
Subject: Re: Long ramblings about project design
To: riscy@pyramid.com
Date: Fri, 25 Jun 93 11:39:44 PDT
In-Reply-To: <199306251032.AA13175@caesar.cs.Colorado.EDU>; from "Drew Eckhardt" at Jun 25, 93 4:32 am
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

> From drew@caesar.cs.Colorado.EDU Fri Jun 25 03:33:16 1993
> Received: from goss.pyramid.com
> 	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
> 	id AA22506; Fri, 25 Jun 93 03:33:02 -0700
> Received: from caesar.cs.colorado.edu 
> 	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
> 	id AA06019; Fri, 25 Jun 93 03:32:51 -0700
> Received: from localhost by caesar.cs.Colorado.EDU with SMTP id AA13175
>   (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Fri, 25 Jun 1993 04:32:38 -0600
> Message-Id: <199306251032.AA13175@caesar.cs.Colorado.EDU>
> To: riscy@pyramid.com, Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
> Subject: Re: Long ramblings about project design 
> In-Reply-To: Your message of "Fri, 25 Jun 1993 04:47:56 CDT."
>              <9306250848.AA21198@gossip.pyramid.com> 
> Date: Fri, 25 Jun 1993 04:32:37 -0600
> From: Drew Eckhardt <drew@caesar.cs.Colorado.EDU>
> 
> 
>     The minimal cost solution would a cpu+ram on a ISA slow, but this seems of 
>     little utility and would be quite ISA limited.  I'd guess the cost would 
>     be around $150-$200 above the cost of the cpu?
> 
> Might not be possible - there isn't a lot of realestate available on an 
> ISA board.

Actually, I had already designed this for the most part.  There was rom
for about 16 SIMM sockets, CPU and support logic, with soom to spare.

>     I believe that VESA support is almost free (simple bus) is this true?
>     Are non-surface mounted chips available?  A fairly high end VESA local
>     bus S3 805 can be had for less then $200 (+ cost of supporting vesa).
> 
> Another poster suggested that  TI32010 can be had for $20, add
> cost of the RAMDAC + either DRAM (about $20/meg) or VRAM (two-three times 
> DRAM price).

That's TI 34010.  If that's the way we went for video, you must use
VRAM and require a RAMDAC of some sort.  Some very rough guesses would
give $25 for the 34010, 20 for the RAMDAC and $80 for the VRAM.  This
is a little more expensive than what I wanted but still well below
the cost of a similar plug in card.

> Nasty timing problems acompany any high speed bus, and since we aren't 
> Pee-Cee compatable VESA might not be that easy.

At the moment I can't see much justification for such a bus;  doing the videooo
ourselves seems like a much easier and surer path.

>     Apparently the TI34020 is a fairly powerful chip (used in xterminals from 
>     tektronics, and high end (> $1k) video cards.  I know of no free drivers an

Just for the record, the TI34020 is much more expensive than the TI34010.
Both are software compaible (fr the most part).  The TI34020 is also
much harder too interface with than the TI34010.  The only thing the new
chip ooffers is extra speed.

> You can allways use just a minimal amount of intelligence, ie treating
> it as a dumb frame buffer if possible, or just doing bitblts with it until 
> you get arround to doing a "propper" driver..

Yup; Also, no one says that you have to use TIGA.  There are C compilers
that can you can get t handle this chip.  BTW, there have been attempts
t port GCC too the TI340?0 without much success; the TI340?0 are bit-
adressable machines; GCC makes tooo many assumptions that its compiling
for a byte addressable machine.

>     How many people who want a mips have ethernet?  I don't. Why not 
>     standardize on say a WD8013? It has a 32 k cache or so and ethernet is a 
>     MAX 10 megabit, or 1.25 MB which the ISA should handle fine (especially sin
>    ce 
>     we have fast int cpu).  

I'm almst sure that ethernet will cost us about half of an ISA card.
I certainly do want ethernet, and figure that more than half of us
do also.  When we have some more concrete figures we can make better
judgements.

> I'm begining to wonder about the need for the ISA bus - 

If we don't have an extension bus of some sort then haven't we
painted ourselves into a corner?  What about the guy who needs just
that extra serial port, or has a printer that can handle 10 times
the speed using parallel (me), other small buletin board service
that needs those 16 modem contrlled, dumb serial ports?

> Pros : we can put nifty things like ROM burners in the ISA slots, and
> 	parallel printer/floppy controllers.
> 
> Cons :  the ISA slots take up lots of realestate (not just 
> 	for the connector - we could have clearance problems with 
> 	heat sinked chipps and SIMMs)

There are few useful ISA cards that require the full length of the box.
The boards I mentioned above are all short boards.  In any case
I think we could deal with that problem, maybe by increasing the size
of the board too get that suff away from there.  How many people
think that a mini-case is a requirement?

> How hard would it be to put a floppy controller and parallel port on
> the mainboard compared to putting in a full ISA bus?

Probably not hard, but there is no cost justification, when there is
an ISA bus.

>     Oh yeah why so many sim slots?  I have hit the limit at 8 slots
>     (with 8 MB) and then upgraded to 16 MB in 4 slots.  I can see 16 slots
>     but why more? 16 MB is around $400 anyone planning to spend more then
>     $1600/64 MB for a mips machine running a linux derivative without a second
>     level cache?
> 
> Memory interleaving.  You use more, smaller chips so that you can 
> interleave memory accesses to them, cutting wait states by a factor 
> of two for two-way for sequential accesses on a cache miss, four 
> by four-way.  In order two take advantage of interleaving,
> you need to fill two or four banks at a time.  
> 
> Hmm - I know our chipset supports 2-way interleave, does it support 
> way?  And what about page mode?  

It nly does 2-way interleaving.  Yes it does page mode.  But the main
reason for the extra SIMM sockets is expansability.  Remember that
MIPS binaries are *large*.  Als, since this is a fast machine with reasonably
good I/O, there is a good chance that it could get used for a many
user machine.  If those users run X, then 128M becomes small.

>     integrated/embedded chip?  I believe the price of the powerpc is expected
>     to be $320 or so for 50 Mhz (to fast but would probably work at 40), and
>     $400 at 66 Mhz.
> 
> Wow! a volunteer to do the GNU ports of GCC and GDB to the PowerPC =8^)
> 
> We'd also need support chips (availability and cost?), and would have to
> work arround hardware bugs in the chip (ie, early 386's that didn't 
> run in protected mode, the 68040 with broken transcendental functions,
> etc).

He has a point.  At least the chips we are currently planning to use
have had good field testing.

> Since we have the tools, the SPARC might be worth looking at.

I figured that the MIPS was just that little bit cleaner than the SPARC.
It may be worth looking that though; they seem to be going for similar
markets.  On the other hand I'd prefer to deal with IDT than Sun.

>     Hmm another bossibiliy is a cheap non fpu processor that has bus snooping,
>     I think the 486 sx fits the description.  This probably isn't feaible 
>     and besides it's a INTEL chip (yuck)
> 
> The solution we're looking at right now would be competitive with a 
> 486DX2-66 in terms of both price (I can get a 486DX2-66/64K secondary 
> cache VESA local bus mainboard for $610 (Of course, this doesn't include 
> video (say $150), SCSI (say $200), ethernet ($80), 16550's, etc)) and 
> performance (integer performance is very comparable, floating point 
> is as much as 5X as much).  

If everyone just want's anther x86 motherboard, I'll give up right now.
Apart from the purely asthetic arguments, there are cooompanies that
can do x86's at *much* better prices than we could ever hope to match.

-- 
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 pham@pX4.stfx.ca Tue Jun 22 14:54:56 1993
Return-Path: <pham@pX4.stfx.ca>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA03171; Tue, 22 Jun 93 14:54:43 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05566; Tue, 22 Jun 93 05:57:15 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15917; Tue, 22 Jun 93 05:54:18 -0700
Received: from pX4.StFX.CA 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05562; Tue, 22 Jun 93 05:57:11 -0700
Received: by pX4.stfx.ca (5.65/DEC-Ultrix/4.3)
	id AA09211; Tue, 22 Jun 1993 09:54:11 -0300
Message-Id: <9306221254.AA09211@pX4.stfx.ca>
From: Hai Pham <pham@pX4.stfx.ca>
Date: Tue, 22 Jun 1993 09:54:10 -0300
To: riscy@pyramid.com
Subject: Motherboard manufacturing
Status: RO
X-Status: 

On Jun 21, 20:49, caret@pyramid.com (Neil Russell) wrote:
Subject: MIPS R3000 hardware design specification revision 1

>
>	Because of the cost of assembly, the board should not have any
>	Surface Mount Devices at all (J-lead components that can be
>	socketed are ok).  Hand assembly of SMD boards is *very*
>	difficult in all cases except maybe prototyping.  The cost
>	of setting up and having boards assembled automatically is
>	not cost effective until you get into the thousands.  I expect
>	to be hand assembling the first few production runs of this
>	board to save costs.
>

Just a thought:  I think most of us on this list are probably pretty
competent with a soldering iron.  Why don't you offer the motherboard as a
kit as well?  All we'd need is the PC board and components with some sort
of schematic.  We'd save a bit on the cost of assembling, and get to learn
about how our own machines are put together in the process.  I for one
would consider it a bargan, even if I run the risk for blowing up
something. :-)

hai
pham@px1.stfx.ca

ps. I know next to nothing about MIPS architecture, nor about anything
else that was mentioned in the hardware design specs.  (The most
complicated thing that we managed to learn about in undergrad physics are
op-amps.)  Could someone point me to a reading list some where?  Some tips
about where and how to get reading material would be nice too. 


 
From rei2!tsprad@uunet.UU.NET Fri Jun 25 21:31:27 1993
Return-Path: <rei2!tsprad@uunet.UU.NET>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA15790; Fri, 25 Jun 93 21:31:24 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA00292; Fri, 25 Jun 93 12:31:11 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA04362; Fri, 25 Jun 93 12:30:41 -0700
Received: from relay1.UU.NET 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA00276; Fri, 25 Jun 93 12:30:40 -0700
Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA10931; Fri, 25 Jun 93 15:29:10 -0400
Received: from rei2.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 152237.4498; Fri, 25 Jun 1993 15:22:37 EDT
Received: by rei.com (5.4/5.40/1.0)
	id AA11083; Fri, 25 Jun 1993 14:13:16 -0500
From: rei2!tsprad@uunet.UU.NET (6692)
Message-Id: <9306251913.AA11083@rei.com>
Subject: Re: your mail
To: uunet!pyramid.com!riscy@uunet.UU.NET
Date: Fri, 25 Jun 1993 14:13:15 -0500 (CDT)
In-Reply-To: <9306251522.AA10360@rei.com> from "UUCP Login" at Jun 25, 93 10:22:41 am
X-Mailer: ELM [version 2.4 PL13]
Content-Type: text
Content-Length: 994       
Status: RO
X-Status: 

Someone said:
> 
> >I agree that an ISA bus would be neat and allow us to put lots of 
> >clone cards in the system, but I could live even without this.
> 
> I used to think that we could do without any sort of I/O expansion bus,
> but it does mean that you have to put _everything_ on the motherboard,
> including disgusting things like floppy controllers. If we can do an
> ISA interface (anyone have any ideas on how to do this yet?) without
> affecting the overall price too much, I'd say go for it. If not, rip
> it off and use Steve's simpler design. This will mean that we have to
> make our own cards, but they won't be difficult, and it will keep the
> cost of the whole machine down.
> 
Generally I agree.  How about, as a completely separate project, a
SCSI <=> ISA bus translator?  If SCSI is fast enough for a tape
drive it's plenty fast enough for anything I'd want to buy an
ISA-bus board for.  Would this be feasible?  Anything with a SCSI
bus (e.g., Mac, SUN-3) could use it.


 
From rei2!tsprad@uunet.UU.NET Fri Jun 25 22:27:26 1993
Return-Path: <rei2!tsprad@uunet.UU.NET>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA15858; Fri, 25 Jun 93 22:27:23 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06122; Fri, 25 Jun 93 13:27:08 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA09421; Fri, 25 Jun 93 13:26:55 -0700
Received: from relay2.UU.NET 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06102; Fri, 25 Jun 93 13:26:53 -0700
Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA24432; Fri, 25 Jun 93 16:24:29 -0400
Received: from rei2.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 162232.22739; Fri, 25 Jun 1993 16:22:32 EDT
Received: by rei.com (5.4/5.40/1.0)
	id AA11316; Fri, 25 Jun 1993 14:50:48 -0500
From: rei2!tsprad@uunet.UU.NET (6692)
Message-Id: <9306251950.AA11316@rei.com>
Subject: Re: your mail
To: uunet!pyramid.com!riscy@uunet.UU.NET
Date: Fri, 25 Jun 1993 14:50:47 -0500 (CDT)
In-Reply-To: <9306250821.AA08327@rei.com> from "UUCP Login" at Jun 25, 93 03:21:32 am
X-Mailer: ELM [version 2.4 PL13]
Content-Type: text
Content-Length: 1595      
Status: RO
X-Status: 

> 
> What ISA-bus-cards do we need ?
> 
> > If SCSI, ethernet and video are on the motherboard, ...
> 
> Right.
> 
> > I agree that an ISA bus would be neat and allow us to put lots of 
> > clone cards in the system, but I could live even without this.
> 
> Right too.

Me too.  If the going gets tough, SCSI is expansion bus enough for
me!  Card edge connectors are big, expensive, and a major source of
headaches.
> 
> > However, I feel that we should run every line going to the cpu also
> > to some sort of connector.  ...
> 
> That might lead us into heavy-duty timing problems. ...
> 
> Too much overhead. And big connectors aren't cheap !
> We would have to guarantee timings, signal delays, driver fan outs
> and so on, or third-party add-on cards may run on one one board
> but not on others.
> What do we want to have ? A low-cost/high-speed workstation or a
> multi-cpu/multi-architecture dinosaur ?
> 
Me too, again.  Connectors are nothing but problems, and we've
already got a Medusa's head:

    15-pin D-shell for Video
    DIN for Keyboard
    BNC for Ethernet
    50-pin header for SCSI
    9-pin D-shell or mini-DIN for mouse
    9-pin D-shell for modem
    Might be nice to have a third serial port for a terminal while
	    debugging graphics programs...

The point of the project is that it's distributed in source form!
If you want to expand it to add on your whizz-bang high-tech
whatever, go back to the sources, make your changes, help yourself.
Of course, you'll have to find somebody to make your new boards, but
that's the difference between software and hardware.


 
From a080700@hp750a.csc.cuhk.hk Sat Jun 26 08:45:07 1993
Return-Path: <a080700@hp750a.csc.cuhk.hk>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA18097; Sat, 26 Jun 93 08:44:51 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16266; Fri, 25 Jun 93 23:44:36 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA14548; Fri, 25 Jun 93 23:44:09 -0700
Received: from hp750a.csc.cuhk.hk 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15745; Fri, 25 Jun 93 23:43:39 -0700
Message-Id: <9306260643.AA15745@gossip.pyramid.com>
Received: by hp750a.csc.cuhk.hk
	(16.8/16.2) id AA25238; Sat, 26 Jun 93 14:41:47 +0800
From: Stephen Siu-ming Wong <a080700@hp750a.csc.cuhk.hk>
Subject: Re: Video subsystem...
To: mackinla@cs.curtin.edu.au
Date: Sat, 26 Jun 93 14:41:46 HKT
Cc: riscy@pyramid.com
In-Reply-To: <199306251447.AA26313@vincent.cs.curtin.edu.au>; from "Patrick Mackinlay" at Jun 25, 93 10:47 pm
Mailer: Elm [revision: 70.30]
Status: RO
X-Status: 

Hi Risciers,

>The other option that I think has some merit is to use the TMS34010.
>This chip used to be pretty expensive, but I think it's dropped a lot
>since the last time I looked. The advantage with this chip is not so
>much speed, but simplification of the overall design. Depending on
>the price of the actual device, I think it could be one way to make
>the video section pretty cheap. I've been told by some other guys
>that it's quite easy to deal with as far as integration with the main
>CPU is concerned (that's what it's designed for, after all!). I have
>a few concerns that it might mean putting another ROM on the board,
>but that might be cheaper and easier than other solutions (I think
>it's got dynamic bus sizing stuff on-board in any case).

I strongly opt for TMS34010/020 solution, as they are CPU and any
one of them will greatly enhance the performance of X.  There
shouldn't be an extra ROM, every thing should be boot strap from
the main CPU, just add some extra object code file on the main
CPU EPROM, and let the main CPU to initial load the TMS CPU.  The
initial TMS code shouldn't be very complicated, it should handle
the most basic text mode only, and let linux (or whatever OS) to
put some still advanced (and large) code on the TMS CPU.

Moreover, VRAM solution should give the best performance (Video
wise and system wise).  2-4MB should be enough for TMS code +
cache (font/pixel/etc) + frame buffer (assume 1024x768x256).

I don't mind if opt for less cost, choose TMS34010, although it is
not the best performer, but it is really cheap.  Of course, it will
be the best to be able to swap in a TMS34020 by users.

>BTW: There's a possibility the ET4000 or other VGA chips come in
>non-SMT versions, but I'd personally prefer to stay away from them.
>As far as I can see, the best way to slow a video system down is
>to stuff it through a VGA chip...

Please, DON"T consider ET4000 chip or TVGA or whatever VGA chips, they
are brain damage.  They are designed for the limited ISA bus and Intel
segment architecture!  If we want on-board video, why should we deal
with such inferior technology!  I want a real (and fast) video system!

--
*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*
v Stephen Wong Siu-ming    v internet: stephenwong@cuhk.hk  v
^ Computer Services Center ^ bitnet  : a080700@cucsc.bitnet ^
* Chinese University of    * phone   : (852) 609-8904       *
v Hong Kong                v fax     : (852) 603-5001       v
*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*

 
From broadley@neurocog.lrdc.pitt.edu Sat Jun 26 19:11:53 1993
Return-Path: <broadley@neurocog.lrdc.pitt.edu>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA18771; Sat, 26 Jun 93 19:11:48 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA03188; Sat, 26 Jun 93 10:11:31 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08130; Sat, 26 Jun 93 10:11:08 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA07600; Sat, 26 Jun 93 02:36:11 -0700
Message-Id: <9306260936.AA07600@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA12498; Sat, 26 Jun 93 05:34:59 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Tiga chip
To: riscy@pyramid.com (Mips 3000)
Date: Sat, 26 Jun 1993 05:34:59 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 690       
Status: RO
X-Status: 

I have a TIGA card at work:  (off the box)
-60 Mhz TMS34010 graphics processor.  7.5 Mips 32 bit general pupose and 
	graphics processor.
-1024x768 non interlaced resolution with 256 of 16.7 million colors.
	maxmimum 1 MB dual ported VRAM and 1 MB DRAM

Not sure if those limited are the boards' of the cpu's.

Would this be better/more cost effective then say a mips chip?

I volunteer to try to get a driver written for this card, I think
we may even have documentation around.

-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok


 
From SMACKINLA@cc.curtin.edu.au Sat Jun 26 19:35:45 1993
Return-Path: <SMACKINLA@cc.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA18796; Sat, 26 Jun 93 19:35:35 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06299; Sat, 26 Jun 93 10:35:26 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA10411; Sat, 26 Jun 93 10:35:19 -0700
Received: from cc.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06291; Sat, 26 Jun 93 10:35:10 -0700
Received: from cc.curtin.edu.au by cc.curtin.edu.au (PMDF #3256 ) id
 <01GZUS9VW67KFUMJ82@cc.curtin.edu.au>; Sun, 27 Jun 1993 01:34:45 +0800
Date: 27 Jun 1993 01:34:45 +0800
From: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Subject: Re: Tiga chip
To: riscy@pyramid.com
Message-Id: <01GZUS9VWFUQFUMJ82@cc.curtin.edu.au>
X-Envelope-To: riscy@pyramid.com
X-Vms-To: IN%"riscy@pyramid.com"
X-Vms-Cc: SMACKINLA
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
Status: RO
X-Status: 


[...sorry if I repeat something already mentioned here, I had a stupid
sysadmin stuff up my mail and I've only just fixed it. Is this list
being archived anywhere?...]

>-60 Mhz TMS34010 graphics processor.  7.5 Mips 32 bit general pupose and 
>	graphics processor.
>-1024x768 non interlaced resolution with 256 of 16.7 million colors.
>	maxmimum 1 MB dual ported VRAM and 1 MB DRAM

>Not sure if those limited are the boards' of the cpu's.

The performance I think is pretty much a limit on the chip. As far as
I remember, you can get 40, 50 or 60 MHz versions of the 34010, but it's
_not_ a fast chip. The actual display I'm not so sure on. If I remember
right, the '10 supports up to 16 bit pixels, while it's big brother,
the 34020 supports full 32 bit pixels. In any case, I think the size
of the screen is purely limited by the amount of video memory you
attach to it. Again, I could be wrong, but I think the '10 has a 24 bit
address bus, meaning you'd be "limited" to 16 meg of RAM.

>Would this be better/more cost effective then say a mips chip?

It won't be faster than using a dedicated MIPS chip to do graphics,
but I _know_ it will be cheaper. The big cost savings are that it
generates _all_ the signals required to drive a monitor, and it
integrates very smoothly with the host CPU.

>I volunteer to try to get a driver written for this card, I think
>we may even have documentation around.

I don't think using a Tiga video card would be a very wise idea
personally, they cost quite a deal of money. I think we can do quite
well if we can stick a 34010 + VRAM on the motherboard - writing a
driver for the chip won't be easy, but surely not too much more
difficult than for a dumb frame buffer. I think the big problem as
far as code goes is that GNU C (for example) doesn't support the
chip, and getting tools that do could be quite a challenge...

I promise to go and do some reading on the chip, and I should have
some more concrete info soon. Can someone find out pricing info from
TI in the States? Hopefully, the chip will only be about US$40 or
$50, making it a pretty good candidate for the system. Oh yeah, and
if someone _does_ ring them, you might ask them about the 34020 and
the floating point unit for the chip (forget the number). I'm not
suggesting that we should worry about either of these two chips, I'm
just a little curious.

BTW: I wouldn't expect that using a 34010 would make the graphics
system outperform any of the VGAs out there, but it'd be quite
interesting, and would leave the main CPU free to do some "real"
work. It might even be practical to run PEX stuff <grin>

[...if there is no archive site, would someone be willing to mail me
the last day or two of messages? I don't like having to repeat questions
that people have already answered...]

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 trashcan!erik@utopia.hacktic.nl Sat Jun 26 21:32:21 1993
Return-Path: <trashcan!erik@utopia.hacktic.nl>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA18909; Sat, 26 Jun 93 21:32:18 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21405; Sat, 26 Jun 93 12:31:56 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA21556; Sat, 26 Jun 93 12:31:29 -0700
Received: from xs4all.hacktic.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21393; Sat, 26 Jun 93 12:31:26 -0700
Received: from utopia.UUCP by xs4all.hacktic.nl with UUCP id AA07661
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Sat, 26 Jun 1993 21:23:30 +0200
Message-Id: <199306261923.AA07661@xs4all.hacktic.nl>
Received: by utopia.hacktic.nl (1.65/waf)
	via UUCP; Sat, 26 Jun 93 20:05:06 GMT
	for riscy@pyramid.com
Received: by trashcan.hacktic.nl (1.65/waf)
	via UUCP; Sat, 26 Jun 93 16:17:55 +0611
	for caret@pyramid.com
From: erik@trashcan.hacktic.nl (Erik Bos)
To: riscy@pyramid.com
Subject: Re: UARTs, was : Re 2nd update
Date: Sat, 26 Jun 1993 16:12:00 +0611
X-Mailer: Rnf 0.75b
Status: RO
X-Status: 

caret@pyramid.com (Neil Russell) writes:

>> Why would you want to put UARTs on the motherboard?  They don't consume
>> enough I/O bandwidth to justify hooking them up to the local bus.
>> If you include too many fancies, the board gets more complicated and
>> more expensive than it needs to be.
>> Better stick to things that need the bandwidth, like SCSI, ethernet, video.
>> If you want 16552 UARTs, build a simple ISA board with 4 sockets for them.
>
>Yup, but its much easier to debug the ISA bus hardware when you can
>talk to the CPU.  Also, almost everyone will use at least one serial port
>with this (for a mouse for X); I think it's justified.
I agree, a serial for debugging would be very useful, Afterwards when you
don't need the uart for debugging anymore, it could be used for a mouse and
a modem.

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

 
From SMACKINLA@cc.curtin.edu.au Sun Jun 27 10:34:39 1993
Return-Path: <SMACKINLA@cc.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA21138; Sun, 27 Jun 93 10:34:35 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05347; Sun, 27 Jun 93 01:34:23 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA04719; Sun, 27 Jun 93 01:33:01 -0700
Received: from cc.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05332; Sun, 27 Jun 93 01:32:55 -0700
Received: from cc.curtin.edu.au by cc.curtin.edu.au (PMDF #3256 ) id
 <01GZVM88DN3CFUMJ82@cc.curtin.edu.au>; Sun, 27 Jun 1993 16:32:40 +0800
Date: 27 Jun 1993 16:32:40 +0800
From: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Subject: More ramblings...
To: riscy@pyramid.com
Message-Id: <01GZVM88DN3EFUMJ82@cc.curtin.edu.au>
X-Envelope-To: riscy@pyramid.com
X-Vms-To: R3KPC
X-Vms-Cc: SMACKINLA
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
Status: RO
X-Status: 


Ok, there's been lots of talking and I think we're getting closer to what 
is going to be practical for the final system. Although this isn't in any 
way final, what I think looks best at the moment is the following.

* IDT R3051/52 CPU at 40MHz: I think we're pretty much hooked on the CPU 
_type_ now, there are good reasons for using this one, and none of the 
other potential devices are really cheap enough when you include the cost 
of support chips. Obviously, we could use the '81 if the whole board cost 
ends up ok.

* IDT 3730 I/O controller: I like the sound of this chip, even if we're not 
going to make use of it's fancy "video DMA" hardware. Perhaps this feature 
could be used to drive a DAC?

* Dual or quad UART: gives us important motherboard-based serial ports for 
mouse/terminal/modem.

* Keyboard controller: I haven't actually been able to locate much info on 
these even after looking quite hard. The chip used in the PC is a simple 
8051 while the AT used an i8041/2 microcontroller. Could someone in the US 
give AMI a call about these? I know they manufacture them, but have no data 
or pricing info on them. I suspect they'd be pretty easy to interface to 
the 3730 I/O bus.

* Video controller: I'm still for a TMS34010-based solution. Here, the 
problem is mainly software. I think using this chip would help to cut total 
system costs quite remarkably. Steve's probably going to flame me about the 
NSC chip, but I think I prefer this one.

* Ethernet controller: Providing it's cheap enough, it looks like the NSC 
8390 and it's interface chip might be the right way to go here. If the 
devices are expensive, I'm in favour of leaving this section of the board 
unpopulated.

* SCSI controller: I think we've pretty much settled on the 53c94? Again, I 
don't have pricing info, but I think it's reasonable. This chip is pretty 
vital to the whole system, and I personally think the 53c94 is the best 
chip for the system.

* Boot EPROM: This is pretty straightforward. How much are we shooting for? 
I'd suggest 64k or 128k - I don't think we can really use much more than 
that. I'd like to have a complete system configuration/testing program in 
this along with the code necessary to read a boot image from SCSI, Ethernet 
and serial interfaces. I am willing to spend quite a lot of time on this to 
make it right <grin>.

* RTC + NVRAM: Don't know much about these. Can someone call Dallas Semi. 
and find out what they have available? I guess we're looking for about 1 or 
2k of NVRAM and some reasonable RTC.

* I/O bus: I have personally given up on the idea of an ISA bus. No one 
seems to have come up with an easy and cheap solution to implement one. I 
do like Steve's simple/proprietry 8 bit I/O bus, but I'd prefer not to have 
to have the 3041. I think this interface could be stuck onto the 3730 
relatively easily, and think it would serve all our needs as far as simple 
expansion goes. I really can't think of an ISA-based I/O device that anyone 
would want to add to this system that couldn't also be done with the 
proprietry interface. Again, I'd vote for leaving the I/O connectors 
"unpopulated" if they are a significant cost.

Does this sum up the current thinking ok? I'll listen to arguments about 
the video system, but I think the 34010 is really the best option at this 
stage, having the necessary attributes: low cost and low complexity. I 
think having our own 8 bit I/O bus is the best option, but I think it would 
be better to drive it with the 3730 than the 3041, reducing the complexity 
in the memory mapping and bus structure. The other parts are pretty much 
fixed, as far as I can see...

For the moment, the devices I can see being put on the I/O bus are: more 
serial ports, a DAC for sound, a parallel port and a floppy drive 
controller. I think that would pretty much cover everything, and having 
seen Steve's design before, I'd have to say it would be pretty easy to 
design and build the necessary cards. I really can't see the point of an 
ISA bus at this stage...

Comments?

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 a080700@hp750a.csc.cuhk.hk Sun Jun 27 16:10:40 1993
Return-Path: <a080700@hp750a.csc.cuhk.hk>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA21576; Sun, 27 Jun 93 16:10:29 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16623; Sun, 27 Jun 93 07:10:16 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08036; Sun, 27 Jun 93 07:09:09 -0700
Received: from hp750a.csc.cuhk.hk 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16615; Sun, 27 Jun 93 07:08:55 -0700
Message-Id: <9306271408.AA16615@gossip.pyramid.com>
Received: by hp750a.csc.cuhk.hk
	(16.8/16.2) id AA07032; Sun, 27 Jun 93 22:07:01 +0800
From: Stephen Siu-ming Wong <a080700@hp750a.csc.cuhk.hk>
Subject: Re: More ramblings...
To: SMACKINLA@cc.curtin.edu.au (Pat Mackinlay)
Date: Sun, 27 Jun 93 22:07:00 HKT
Cc: riscy@pyramid.com
In-Reply-To: <01GZVM88DN3EFUMJ82@cc.curtin.edu.au>; from "Pat Mackinlay" at Jun 27, 93 4:32 pm
Mailer: Elm [revision: 70.30]
Status: RO
X-Status: 

Hi Risciers,

>* Dual or quad UART: gives us important motherboard-based serial ports for 
>mouse/terminal/modem.

I heard it once, and would like to bring it out again, will the Zilog SSC
be a better choice?  As I remember, it is a dual USART chip, and capable
to do sync and async.

>* Video controller: I'm still for a TMS34010-based solution. Here, the 
>problem is mainly software. I think using this chip would help to cut total 
>system costs quite remarkably. Steve's probably going to flame me about the 
>NSC chip, but I think I prefer this one.

Good enough, but still better to use VRAM as frame buffer for TMS and a
24-bit RAMDAC.

>* Ethernet controller: Providing it's cheap enough, it looks like the NSC 
>8390 and it's interface chip might be the right way to go here. If the 
>devices are expensive, I'm in favour of leaving this section of the board 
>unpopulated.

If we are not going to implement ISA bus, 8390 may NOT be the best choice,
some new LANCE chip should have a much better performance than 8390.
Moreover, 8390 is a rather dumb device, why not using a better chip?

One point I would like to raise, since we aim at PC board form factor,
does anyone think about how to put the ethernet connector on the mother
board and still accessible from a normal PC case?  There's a hole near
the rear right hand side for keyboard connector, but no other convenient
opening, how to deal with it, drill a hole on the case?

>* SCSI controller: I think we've pretty much settled on the 53c94? Again, I 
>don't have pricing info, but I think it's reasonable. This chip is pretty 
>vital to the whole system, and I personally think the 53c94 is the best 
>chip for the system.

Is it SCSI-2?

>* Boot EPROM: This is pretty straightforward. How much are we shooting for? 
>I'd suggest 64k or 128k - I don't think we can really use much more than 
>that. I'd like to have a complete system configuration/testing program in 
>this along with the code necessary to read a boot image from SCSI, Ethernet 
>and serial interfaces. I am willing to spend quite a lot of time on this to 
>make it right <grin>.

Do you mean boot from SCSI device (disk AND tape), Ethernet (bootp and tftp)
and some proprietry serial booting interface?

>* I/O bus: I have personally given up on the idea of an ISA bus. No one 
>seems to have come up with an easy and cheap solution to implement one. I 
>do like Steve's simple/proprietry 8 bit I/O bus, but I'd prefer not to have 
>to have the 3041. I think this interface could be stuck onto the 3730 
>relatively easily, and think it would serve all our needs as far as simple 
>expansion goes. I really can't think of an ISA-based I/O device that anyone 
>would want to add to this system that couldn't also be done with the 
>proprietry interface. Again, I'd vote for leaving the I/O connectors 
>"unpopulated" if they are a significant cost.

If no ISA bus, then we have to adjust our minimal device list on board,
such as floppy disk controller (much much cheaper than SCSI floppy),
bi-directional parallel port (almost a must), sound support (like 16-bit
stereo AD/DA, FM, PCM).

--
*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*
v Stephen Wong Siu-ming    v internet: stephenwong@cuhk.hk  v
^ Computer Services Center ^ bitnet  : a080700@cucsc.bitnet ^
* Chinese University of    * phone   : (852) 609-8904       *
v Hong Kong                v fax     : (852) 603-5001       v
*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*

 
From SMACKINLA@cc.curtin.edu.au Sun Jun 27 16:33:14 1993
Return-Path: <SMACKINLA@cc.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA21635; Sun, 27 Jun 93 16:33:10 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA19738; Sun, 27 Jun 93 07:33:00 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA09731; Sun, 27 Jun 93 07:32:52 -0700
Received: from cc.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA19692; Sun, 27 Jun 93 07:32:46 -0700
Received: from cc.curtin.edu.au by cc.curtin.edu.au (PMDF #3256 ) id
 <01GZW092D0ACFUMLVJ@cc.curtin.edu.au>; Sun, 27 Jun 1993 22:32:29 +0800
Date: 27 Jun 1993 22:32:29 +0800
From: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Subject: Re: More ramblings...
To: a080700@hp750a.csc.cuhk.hk
Cc: riscy@pyramid.com
Message-Id: <01GZW092D0AEFUMLVJ@cc.curtin.edu.au>
X-Envelope-To: riscy@pyramid.com
X-Vms-To: IN%"a080700@hp750a.csc.cuhk.hk"
X-Vms-Cc: R3KPC,SMACKINLA
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
Status: RO
X-Status: 


>>* Video controller: I'm still for a TMS34010-based solution. Here, the 

>Good enough, but still better to use VRAM as frame buffer for TMS and a
>24-bit RAMDAC.

I was assuming this. I've since found out a bit more about the 34k. 
Basically, the chip has access to one memory bank. This bank may be either 
DRAM or VRAM, and is used to store both the chip's code and the video 
image. The host has access to all of this memory through an 8 or 16 bit 
"host access port" - so it can essentially "write through" the 34k and into 
the RAM on the other side. I think this would attach to the 3730 quite 
nicely. I'm assuming TI makes a neat little DAC/palette chip intended for 
use with the 34k, and if it's cheap enough, it'll be a neat solution.

I have some other good news: a mate of mine has C source to an assembler 
for the 34010, so we have _some_ software. I can't imagine writing an X 
server totally in assembler though <grin>.

>>* Ethernet controller: Providing it's cheap enough, it looks like the NSC 

>If we are not going to implement ISA bus, 8390 may NOT be the best choice,
>some new LANCE chip should have a much better performance than 8390.
>Moreover, 8390 is a rather dumb device, why not using a better chip?

Because we're more worried about price than performance (to a certain 
extent). One of the faster devices, the Intel thingo, is both quite 
expensive and SMT, making it unsuitable for our design. If you can give us 
some numbers on the new Lance, I'm sure it will be given due consideration.

>does anyone think about how to put the ethernet connector on the mother
>board and still accessible from a normal PC case?  There's a hole near

This is a good point. Perhaps on a little "extension cord" going up to a 
"slot filler" (those little metal strips on the back)?

>>* SCSI controller: I think we've pretty much settled on the 53c94? Again, I 

>Is it SCSI-2?

It's been said before, and I'll say it again - being "SCSI-2" is largely a 
_software_ issue, not a hardware one. Perhaps you mean "Can it do FAST 
SCSI?" If so, then the answer is no. There is a version of the chip that 
_can_, however, and I suggest this is the one to go for: the 53cf94.

>>* Boot EPROM: This is pretty straightforward. How much are we shooting for? 

>Do you mean boot from SCSI device (disk AND tape), Ethernet (bootp and tftp)
>and some proprietry serial booting interface?

Yes. The serial boot idea is mainly intended for use during very early 
kernel development (serial ports are usually the most trouble-free devices 
to get working reliably).

>>* I/O bus: I have personally given up on the idea of an ISA bus. No one 

>If no ISA bus, then we have to adjust our minimal device list on board,
>such as floppy disk controller (much much cheaper than SCSI floppy),
>bi-directional parallel port (almost a must), sound support (like 16-bit
>stereo AD/DA, FM, PCM).

You didn't read what I wrote. The idea is that we use the I/O bus for 
allowing this kind of expansion. There will still be an I/O expansion bus, 
the only difference is that it will be Steve's proprietry design rather 
than the ISA bus.

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 tthorn@daimi.aau.dk Sun Jun 27 20:37:28 1993
Return-Path: <tthorn@daimi.aau.dk>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA21925; Sun, 27 Jun 93 20:37:25 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23227; Sun, 27 Jun 93 11:37:14 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA03399; Sun, 27 Jun 93 11:36:53 -0700
Received: from avignon.daimi.aau.dk 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23211; Sun, 27 Jun 93 11:36:51 -0700
Received: by avignon.daimi.aau.dk id AA01345
  (5.65c8/IDA-1.4.4 for riscy@pyramid.com); Sun, 27 Jun 1993 20:36:46 +0200
Date: Sun, 27 Jun 1993 20:36:46 +0200
From: Tommy Thorn <tthorn@daimi.aau.dk>
Message-Id: <199306271836.AA01345@avignon.daimi.aau.dk>
To: riscy@pyramid.com
Subject: Fast Video [was: More ramblings...]
References: <01GZW092D0AEFUMLVJ@cc.curtin.edu.au>
Reply-To: Tommy.Thorn@daimi.aau.dk
Status: RO
X-Status: 

Pat Mackinlay writes:
 > 
 > >>* Video controller: I'm still for a TMS34010-based solution. Here, the 
 > 
 > >Good enough, but still better to use VRAM as frame buffer for TMS and a
 > >24-bit RAMDAC.
 > 
 > I was assuming this. I've since found out a bit more about the 34k. 
 > Basically, the chip has access to one memory bank. This bank may be either 
 > DRAM or VRAM, and is used to store both the chip's code and the video 
 > image. The host has access to all of this memory through an 8 or 16 bit 
 > "host access port" - so it can essentially "write through" the 34k and into 
 > the RAM on the other side. I think this would attach to the 3730 quite 
 > nicely. I'm assuming TI makes a neat little DAC/palette chip intended for 
 > use with the 34k, and if it's cheap enough, it'll be a neat solution.

The 34010 might be good if it simplifies the design and helps bring
the price down, but I worry over the affect on video performens (and
complexity of the software). One can do quite well with a dumb
frame buffer with high bandwidth. Joel McCormack's article ("Writing
Fast X Servers for Dumb Color Frame Buffers. Software: Practice and
Experience 20(S2):83-108, October 1990) shows this (using a R3000 BTW).

What memory bandwidth can one expect using the 34010 as a dumb frame
buffer?

 
From mackinla@cs.curtin.edu.au Tue Jun 22 15:25:06 1993
Return-Path: <mackinla@cs.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA03344; Tue, 22 Jun 93 15:25:02 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA08756; Tue, 22 Jun 93 06:27:47 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA19920; Tue, 22 Jun 93 06:24:49 -0700
Received: from marsh.cs.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA08750; Tue, 22 Jun 93 06:27:39 -0700
Received: from vincent.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA09632
  (5.67a/IDA-1.4.4 for <riscy@pyramid.com>); Tue, 22 Jun 1993 21:23:22 +0800
Received: by vincent.cs.curtin.edu.au id AA13739
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Tue, 22 Jun 1993 21:23:18 +0800
From: Patrick Mackinlay <mackinla@cs.curtin.edu.au>
Message-Id: <199306221323.AA13739@vincent.cs.curtin.edu.au>
Subject: Re: Motherboard manufacturing
To: riscy@pyramid.com
Date: Tue, 22 Jun 1993 21:23:17 +0800 (WST)
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2109      
Status: RO
X-Status: 


>Just a thought:  I think most of us on this list are probably pretty
>competent with a soldering iron.  Why don't you offer the motherboard as a
>kit as well?  All we'd need is the PC board and components with some sort

This is probably true enough. One point is that the board will have to
be offered in _both_ kit and "complete" form, otherwise you won't have
as big a target audience (a critical factor with "projects" like this).

I do like the idea of being able to put my own board together, and it
would take some of the load off Neil to start with. Any other comments?
Neil, how would you feel about "shipping" PCBs + components to the
very early board testers? Is it too much trouble from your perspective?
Perhaps some people could even do assembly for you?

>ps. I know next to nothing about MIPS architecture, nor about anything
>else that was mentioned in the hardware design specs.  (The most

As for the MIPS architecture, the book to look for is called "mips RISC
Architecture" by Jerry Kane. I forget the publisher etc, but any good
bookshop aught to be able to get it for you. This book tells you pretty
much all you need to know from the architectural perspective. Believe
me, programming one of these things is _fun_ compared to the 386 <grin>.

>complicated thing that we managed to learn about in undergrad physics are
>op-amps.)  Could someone point me to a reading list some where?  Some tips
>about where and how to get reading material would be nice too. 

I don't have much knowledge of electronics theory either, but it's pretty
simple to put things together and learn about how it all works. Digital
electronics is pretty much "connect the dots" these days. The hard parts
are in getting parts (ie: quantity/price/package tradeoffs) and in writing
the software at the end. If you can understand the basics of how a
computer works, it's not too hard to work out how it all fits together
logically...

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 jeremy@sw.oz.au Mon Jun 28 04:51:40 1993
Return-Path: <jeremy@sw.oz.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA22728; Mon, 28 Jun 93 04:51:34 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23765; Sun, 27 Jun 93 19:51:24 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA18721; Sun, 27 Jun 93 19:51:03 -0700
Received: from munnari.OZ.AU 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23648; Sun, 27 Jun 93 19:50:47 -0700
Received: from sw.oz.au (via basser.cs.su.oz.au) by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50)
	id AA09165; Mon, 28 Jun 1993 12:49:13 +1000 (from jeremy@sw.oz.au)
Received: from chao.sw.oz.au by swift.sw.oz.au with SMTP
	id AA17799; Mon, 28 Jun 93 12:48:14 AES (5.59)
	(from jeremy@sw.oz.au for tor%tss.no@munnari.oz.au)
Received: by chao.sw.oz.au (4.1/SMI-4.1)
	id AA09413; Mon, 28 Jun 93 12:48:54 EST
From: jeremy@sw.oz.au (Jeremy Fitzhardinge)
Message-Id: <9306280248.AA09413@chao.sw.oz.au>
Subject: Re: ISA or not? (Was: Re: Long ramblings about project design)
To: tor@tss.no (Tor Arntsen)
Date: Mon, 28 Jun 1993 12:48:53 +1000 (EST)
Cc: riscy@pyramid.com
In-Reply-To: <9306251121.AA15449@unas.tss.no> from "Tor Arntsen" at Jun 25, 93 01:21:43 pm
Organization: Softway Pty Ltd
X-Face: 
	 '6U=%Tv\k1<Ek%ql%PN^v`Db4bakr[v~y]\u7"GbO#I=]N{l1=#P,glz$9q>l-:?\$C[D@G
	 7(vl~w8&y}!f\bh#w<Y*S~bEBTI:s&.QR>L#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb
	 l[EC}c=;uc%x'}uh3E91p&oE<q$w1r&U0yw.Sb3V&uw
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1180      
Status: RO
X-Status: 

Tor Arntsen bubbles:

> Drew Eckhardt wrote:
> [...] 
> } I'm begining to wonder about the need for the ISA bus - 
> I'm beginning to wonder as well.. 

> } 
> } Pros : we can put nifty things like ROM burners in the ISA slots, and
> } 	parallel printer/floppy controllers.
> What about RS-232 ROM burners?  I have to admit I haven't used ROM burners 
> since when one could only get serial versions.  Are ISA versions more useful?

Having ISA slots makes the board much more appealing to those with an
existing investment in ISA cards.  This is important.  If someone asks
"can I plug my soundblaster in to it?", its better to say "sure, you need
to write a driver though" rather than, "nope, design a scsi version".
More importantly, things like multiport serial/parallel boards aren't
things you want to clutter up a motherboard with, but are dirt cheap to
get in ISA form.

> Floppy is useful.
> Is a parallel port really necessary?  Serial printers should do, no?

Parallel is important.  There is nothing more useful than being able to
flash LEDs when nothing else works (either cause something is very broken
or because you're in the early stages of writing monitor code).

 
From jeremy@sw.oz.au Mon Jun 28 05:03:05 1993
Return-Path: <jeremy@sw.oz.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA22749; Mon, 28 Jun 93 05:03:00 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA25700; Sun, 27 Jun 93 20:02:51 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA20477; Sun, 27 Jun 93 20:02:44 -0700
Received: from munnari.OZ.AU 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA25692; Sun, 27 Jun 93 20:02:30 -0700
Received: from sw.oz.au (via basser.cs.su.oz.au) by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50)
	id AA09515; Mon, 28 Jun 1993 13:01:03 +1000 (from jeremy@sw.oz.au)
Received: from chao.sw.oz.au by swift.sw.oz.au with SMTP
	id AA18081; Mon, 28 Jun 93 13:00:03 AES (5.59)
	(from jeremy@sw.oz.au for mackinla%cs.curtin.edu.au@munnari.oz.au)
Received: by chao.sw.oz.au (4.1/SMI-4.1)
	id AA09462; Mon, 28 Jun 93 13:00:40 EST
From: jeremy@sw.oz.au (Jeremy Fitzhardinge)
Message-Id: <9306280300.AA09462@chao.sw.oz.au>
Subject: Re: Video subsystem...
To: mackinla@cs.curtin.edu.au (Patrick Mackinlay)
Date: Mon, 28 Jun 1993 13:00:38 +1000 (EST)
Cc: riscy@pyramid.com
In-Reply-To: <199306251447.AA26313@vincent.cs.curtin.edu.au> from "Patrick Mackinlay" at Jun 25, 93 10:47:52 pm
Organization: Softway Pty Ltd
X-Face: 
	 '6U=%Tv\k1<Ek%ql%PN^v`Db4bakr[v~y]\u7"GbO#I=]N{l1=#P,glz$9q>l-:?\$C[D@G
	 7(vl~w8&y}!f\bh#w<Y*S~bEBTI:s&.QR>L#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb
	 l[EC}c=;uc%x'}uh3E91p&oE<q$w1r&U0yw.Sb3V&uw
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1285      
Status: RO
X-Status: 

Patrick Mackinlay bubbles:

Just a comment:  My preference for onboard video would be a simple frame
buffer using vram.  It would be nice if we could get the chip described
in the "the interesting dec paper" (the thesis was that smart video chips
are an anachonism, and are effectivly useless when tied to a fast risc
chip -- mainly because they are always a generation of speed behind
the cpu, and the cpu can saturate the memory bandwidth anyway).

In any case, it is much more important to have the video memory directly
and completely accessable by the CPU than have limited access and have a
"smart" chip.

> Any comments on this? Anyone have pricing info on the 34010?

The TMS34010 is *slow*.  It only has a 16 bit memory data bus, which has
a max transfer of about 6MB/s at 40MHz.  This is because it is a very
CISCy chip, with a not particularly fast memory interface (partly because
all addressess are bit addresses, and the hardware is more complex).
The 34020 is 32bit and probably much faster, but I think it is an
unnecessary complication.  It would make the video inaccessable from
the cpu (unless you want shared memory, ugh), making it much harder
to program.  Neil almost certainly has his own views on this :-).

Neither chip would require another rom on the board.

 
From jeremy@sw.oz.au Mon Jun 28 05:09:37 1993
Return-Path: <jeremy@sw.oz.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA22758; Mon, 28 Jun 93 05:09:32 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA27082; Sun, 27 Jun 93 20:09:20 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA22081; Sun, 27 Jun 93 20:09:13 -0700
Received: from munnari.OZ.AU 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA27029; Sun, 27 Jun 93 20:09:02 -0700
Received: from sw.oz.au (via basser.cs.su.oz.au) by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50)
	id AA09725; Mon, 28 Jun 1993 13:07:32 +1000 (from jeremy@sw.oz.au)
Received: from chao.sw.oz.au by swift.sw.oz.au with SMTP
	id AA18144; Mon, 28 Jun 93 13:06:01 AES (5.59)
	(from jeremy@sw.oz.au for caret%pyramid.com@munnari.oz.au)
Received: by chao.sw.oz.au (4.1/SMI-4.1)
	id AA09518; Mon, 28 Jun 93 13:06:42 EST
From: jeremy@sw.oz.au (Jeremy Fitzhardinge)
Message-Id: <9306280306.AA09518@chao.sw.oz.au>
Subject: Re: MC68302 & sound
To: caret@pyramid.com (Neil Russell)
Date: Mon, 28 Jun 1993 13:06:41 +1000 (EST)
Cc: riscy@pyramid.com
In-Reply-To: <9306251629.AA29204@sword.eng.pyramid.com> from "Neil Russell" at Jun 25, 93 09:29:41 am
Organization: Softway Pty Ltd
X-Face: 
	 '6U=%Tv\k1<Ek%ql%PN^v`Db4bakr[v~y]\u7"GbO#I=]N{l1=#P,glz$9q>l-:?\$C[D@G
	 7(vl~w8&y}!f\bh#w<Y*S~bEBTI:s&.QR>L#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb
	 l[EC}c=;uc%x'}uh3E91p&oE<q$w1r&U0yw.Sb3V&uw
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 444       
Status: RO
X-Status: 

Neil Russell bubbles:

> As for sound, I was thinking of that, but something that could be somewhat
> useful to the DSP guys.  This would mean at least a 30KHz variable sample
> rate DAC with a variable filter;  This is starting to smell of creeping
> featurism.

Optional sound would be nice, but only if no sound is zero cost.  I'd still
push for ISA slots for that kind of thing.  How hard can it be -- the Mips
machines have ISA slots.

	J

 
From tor@tss.no Mon Jun 28 05:19:49 1993
Return-Path: <tor@tss.no>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA22771; Mon, 28 Jun 93 05:19:46 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28676; Sun, 27 Jun 93 20:19:33 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA22658; Sun, 27 Jun 93 20:19:27 -0700
Received: from benoni.Uit.No 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28664; Sun, 27 Jun 93 20:19:25 -0700
Received: from benoni by ppenoni.uit.no with SMTP (PP) 
          id <18396-0@ppenoni.uit.no>; Mon, 28 Jun 1993 05:19:21 +0000
Received: from unas.tss.no 
          by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) 
          id AAbenoni18392; Mon, 28 Jun 1993 05:19:19 +0200
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA28182;
          Mon, 28 Jun 93 05:13:46 +0200
Message-Id: <9306280313.AA28182@unas.tss.no>
From: tor@tss.no (Tor Arntsen)
Date: Mon, 28 Jun 1993 05:13:45 +0200
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: riscy@pyramid.com
Subject: Re: Video subsystem...
Status: RO
X-Status: 

Jeremy Fitzhardinge wrote:
[...]
>
>The TMS34010 is *slow*.  It only has a 16 bit memory data bus, which has
>a max transfer of about 6MB/s at 40MHz.  This is because it is a very
>CISCy chip, with a not particularly fast memory interface (partly because
>all addressess are bit addresses, and the hardware is more complex).
>The 34020 is 32bit and probably much faster, but I think it is an
>unnecessary complication.  It would make the video inaccessable from
>the cpu (unless you want shared memory, ugh), making it much harder
>to program.  Neil almost certainly has his own views on this :-).
>
>Neither chip would require another rom on the board.

I've been using a TMS34010-based X-terminal.  I must agree that it is not
very fast, but it is not as slow as e.g. cheap NCD-terminals (I have no
idea what's inside those).  The TMS-based one is kind of middle of the road.
A Sun SLC running X is faster, HP X-terms (pa-based I think) are much much
faster.

Tor



 
From tor@tss.no Mon Jun 28 05:31:15 1993
Return-Path: <tor@tss.no>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA22786; Mon, 28 Jun 93 05:31:13 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA00434; Sun, 27 Jun 93 20:31:03 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA23788; Sun, 27 Jun 93 20:30:52 -0700
Received: from benoni.Uit.No 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA00426; Sun, 27 Jun 93 20:30:50 -0700
Received: from benoni by ppenoni.uit.no with SMTP (PP) 
          id <18520-0@ppenoni.uit.no>; Mon, 28 Jun 1993 05:30:46 +0000
Received: from unas.tss.no 
          by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) 
          id AAbenoni18516; Mon, 28 Jun 1993 05:30:44 +0200
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA28214;
          Mon, 28 Jun 93 05:25:12 +0200
Message-Id: <9306280325.AA28214@unas.tss.no>
From: tor@tss.no (Tor Arntsen)
Date: Mon, 28 Jun 1993 05:25:10 +0200
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: riscy@pyramid.com
Subject: Re: Video subsystem...
Status: RO
X-Status: 

I wrote:
[...]
>I've been using a TMS34010-based X-terminal.  I must agree that it is not
>very fast, 
Maybe I'm a bit unfair here, that terminal is also running the X-server
in the 34010.

>but it is not as slow as e.g. cheap NCD-terminals (I have no
>idea what's inside those).  The TMS-based one is kind of middle of the road.
>A Sun SLC running X is faster, HP X-terms (pa-based I think) are much much
>faster.
But I think the HP X-terms do the equivalent, i.e. I think they use the
pa-chip to do both the video and the X-server.  I may be on thin ice here.

Tor


 
From caret@pyramid.com Mon Jun 28 07:32:34 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA24148; Mon, 28 Jun 93 07:32:26 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20718; Sun, 27 Jun 93 22:31:45 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA07240; Sun, 27 Jun 93 22:31:20 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306280531.AA07240@sword.eng.pyramid.com>
Subject: Things ...
To: riscy@pyramid.com
Date: Sun, 27 Jun 93 22:31:20 PDT
Cc: paul@sw.oz.au
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

Lots of people think that the ISA bus should disappear.  True there seems
to be a lack of chips that could help us here, however, I think that we
could implement an ISA bus interface on one of the 3730 ports with a
handfull of PALs and buffers.  The only thing that I can think of that
would be hard (if not impossible) is implementing the -MASTER signal.
My current guess is about $20 worth of components plus the cost of the
ISA sockets.  The big loose here is the relatively large amount of
time required to design it.

Some people suggested adding an ISA bus at the end of a SCSI cable.
While this has merit, maybe as another product, I don't think its
suitable here.  Note the about price guess.  Also, whatever the cost of
somplementing ISA, it will be more to do it this way.

As for implementing another new an improved slow peripheral bus,
what's the point?  There would be nothing to connect to it.
A partial ISA bus could be done just as easily.

The TI340?0 video solution:  From what I have read of the TI340?0, it
does its pixel stuff at the speed of its memory; that is, the speed
of bitblt is the bandwidth of its memory.  In any windowing environment.
the speed of bitblt is the major determining factor in how fast it goes.
So, given this, the TI34020 is exactly twice the speed of the TI34010.

The video sub-system must include memory, something to read it and encode
it into a serial bit stream, a Digital-to-Analog converter (RAMDAC),
and something to generate timing signals.  Memory is easy.  The RAMDAC
is easy.  The stuff to tie this together is to topic of discussion.
If we were to connect the VRAM (we should use VRAM rather than my
original suggestion) to the R3000, then we still have to generate
the cycles on the main bus to load the VRAM serial registers, and
have something generate the video sync signals.

While the TI34010 doesn't allow direct access to the VRAM from the
R3000, it does give us everything else.  Unless we can get another
solution that does this with the VRAM connected to the R3000, then
I opt for this.

Also note that the TI34010 is a CPU in its own right, and it does have
access to the VRAM.  Also note that I may be able to get binaries
for a C compiler system for the TI34010 to run on linux for a small
fee.

The TI34020 is probably not a viable option for two reasons: i)
Cost.  Last I checked it was >$100; ii) Its interface to the host
CPU is now *much* more complicated.

As for performance, the TI34010 probably competes fairly well with
things like the S3 chipsets, especially since some if not all of
the X-server can run on the TI34010.

Someone suggested using the Zilog SCC chips for serial.  I agree in
principal.  They have the problem that they are much more difficult
to program right because of various bugs, but they allow a much
richer set of options for serial format (can to various SYNC modes).

Little vs Big endian mode:  The R3000 CPU can do both.  The selection
is done at reset time and cannot be changed later.  As for implementing
logic to allow the OS to reset just to change endian mode, I think this
is unwise; apart from the extra logic, how long does a reset take
in comparison to a system call?

Keyboard controller:  The format of the keyboard interface is fairly
well defined.  I know of one implementation of a peripheral that
read the keyboard using two PALs.  Problem with that implementation
is that it didn't ahndle all of the AT keyboard stuff (such as the
CAP/NUM/SCROLL LEDs).  We can always program our own 8041/8051.
Downloading code to these though is probably not an option.  I will
call AMI.

The issue of how to mount the extra connectors (ehternet, SCSI, etc).
SCSI is easy:  we provide a 50-pin header on the motheroard; that is:
no external access provided by default.  Video and ethernet are
problems.  Personally I would mount the video in one the 25-pin
serial holes provided on most boxes (a hack) and mount the ethernet
connector in a similar way (also a hack).  Another solution is
to get a bracket made to handle both of these and screw it into
an unused slot opening.  I am thinking that we should only provide
about 4 ISA connectors anyhow.  In this thinking I have not
thought of having more than one type of ethernet connector.

Pat says:
> I was assuming this. I've since found out a bit more about the 34k. 
> Basically, the chip has access to one memory bank. This bank may be either 
> DRAM or VRAM, and is used to store both the chip's code and the video 
> image. The host has access to all of this memory through an 8 or 16 bit 

This is not true.  Its fairly easy to attach different memory types
to the 34010.

Jeremy Gurgles:
> Parallel is important.  There is nothing more useful than being able to
> flash LEDs when nothing else works (either cause something is very broken
> or because you're in the early stages of writing monitor code).

I also think its important, though with simple enough serial ports
it may not be needed in the way you suggest.  I'd just be happy to
plug a parallel card into the ISA bus.  Addingeasy access LEDs is a
good plan though.  I think PALs have enough omf to drive them, and
there should be at least one output left on a PAL...

Sound?  Truly simple sound is to use the IBM method.  Not quite as
simple sound is the MAC method.  Maybe a handfull of resistors for
the DAC and a few resisters and capacitors for a simple filter
should be enough; we are not trying to compete with SoundBlasters
after all.  Anyone done this kind of DAC?  Isn't it text book stuff?

I'm back from Usenix.  I'll be spending this week getting information
from manufacturers about all these chips people are suggesting.
-- 
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 SMACKINLA@cc.curtin.edu.au Mon Jun 28 08:23:23 1993
Return-Path: <SMACKINLA@cc.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA24226; Mon, 28 Jun 93 08:23:12 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA29974; Sun, 27 Jun 93 23:22:27 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA11990; Sun, 27 Jun 93 23:22:19 -0700
Received: from cc.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA29962; Sun, 27 Jun 93 23:22:03 -0700
Received: from cc.curtin.edu.au by cc.curtin.edu.au (PMDF #3256 ) id
 <01GZWX8I5RHMFUMLVJ@cc.curtin.edu.au>; Mon, 28 Jun 1993 14:20:25 +0800
Date: 28 Jun 1993 14:20:25 +0800
From: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Subject: Re: Things ...
To: caret@pyramid.com
Cc: riscy@pyramid.com
Message-Id: <01GZWX8I5RHOFUMLVJ@cc.curtin.edu.au>
X-Envelope-To: caret@pyramid.com, riscy@pyramid.com
X-Vms-To: IN%"caret@pyramid.com"
X-Vms-Cc: R3KPC,SMACKINLA
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
Status: RO
X-Status: 


>Lots of people think that the ISA bus should disappear.  True there seems
>to be a lack of chips that could help us here, however, I think that we
>could implement an ISA bus interface on one of the 3730 ports with a
>handfull of PALs and buffers.  The only thing that I can think of that

Ok, if you think this can be done as cheaply as you suggest, then it's 
probably the right thing to aim for.

>While the TI34010 doesn't allow direct access to the VRAM from the
>R3000, it does give us everything else.  Unless we can get another

I don't think this is quite right. The R3k _will_ be able to access the 
34010's memory "directly" - through its host bus. In this mode of 
operation, the host processor can write "through" the 34010 and access the 
VRAM (and/or DRAM) attached to the 34010. This is how the host puts code 
into the 34k's memory. It will also allow us to use the video memory as a 
dumb framebuffer during the initial software stages. Yes, it _will_ be slow 
(the host bus is only 16 bit), but see my further comments below.

>This is not true.  Its fairly easy to attach different memory types
>to the 34010.

Ok, sorry, that wasn't what I really meant. What I was trying to say was 
that the 34010's memory (of whatever type) is used to hold _both_ its code 
_and_ its video data. What that would mean is that we could stick (say) 2M 
of VRAM on the chip, 1M for the video image, and 1M for code. Obviously, if 
at all possible, it would be better to use DRAM for code because its 
cheaper...

I read Jeremy's comments, but I'd have to say that I still support the idea 
of the 34010 as the graphics chip. The main advantage it buys us is that 
it's a very simple (and cheap) solution to the whole video system. You 
won't get any decent performance until the X server is residing on the 34k 
itself, but as I pointed out above, you _can_ treat it as a (slow) 
framebuffer until that point.

Jeremy is arguing that it would be faster to implement a straight 
framebuffer as the r3k is able to saturate memory bandwidth anyhow. This is 
true, and a straight framebuffer _would_ be faster - I'm not arguing that. 
What I'm saying is that a framebuffer is going to be harder and more 
expensive to implement than a 34k-based solution. If someone (Steve, 
where're the details on that NSC chip? <grin>) can come up with a chip that 
can generate the appropriate monitor timing signals and the "VRAM to DAC" 
transfers that is price competitive with the 34k solution, I'd say go for 
it, but for the moment, the 34k looks very attractive.

Rather more personal preference than anything else: Don't you just _love_ 
the idea of the X server running on its own CPU? It'd be the equivalent of 
having your own X terminal on board <grin>. No, it probably won't compete 
for speed with a well-designed framebuffer, but I think it's a very elegant 
solution.

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 caret@pyramid.com Mon Jun 28 08:53:31 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA24525; Mon, 28 Jun 93 08:53:19 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06141; Sun, 27 Jun 93 23:52:46 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15136; Sun, 27 Jun 93 23:52:30 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306280652.AA15136@sword.eng.pyramid.com>
Subject: Re: Things ...
To: riscy@pyramid.com
Date: Sun, 27 Jun 93 23:52:30 PDT
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 


 
From caret Sun Jun 27 23:50:42 1993
Subject: Re: Things ...
To: SMACKINLA@cc.curtin.edu.au (Pat Mackinlay)
Date: Sun, 27 Jun 93 23:50:42 PDT
In-Reply-To: <01GZWX8I5RHOFUMLVJ@cc.curtin.edu.au>; from "Pat Mackinlay" at Jun 28, 93 2:20 pm
X-Mailer: ELM [version 2.3 PL11]
Status: O
X-Status: 

> >While the TI34010 doesn't allow direct access to the VRAM from the
> >R3000, it does give us everything else.  Unless we can get another
> 
> I don't think this is quite right. The R3k _will_ be able to access the 
> 34010's memory "directly" - through its host bus. In this mode of 
> operation, the host processor can write "through" the 34010 and access the 
> VRAM (and/or DRAM) attached to the 34010. This is how the host puts code 
> into the 34k's memory. It will also allow us to use the video memory as a 
> dumb framebuffer during the initial software stages. Yes, it _will_ be slow 
> (the host bus is only 16 bit), but see my further comments below.

Yeah, you can get access to any location in the 34k's address space
(including its own registers).  However, its not part of the R3k's
address space.  The 34k implements 4 locations in the r3k's address
space:  two are address registers, one is status, and the other is
data.  To copy a block of memory you place the start address in the
address register and then copy the data from/to the data register.
Doing a bitblt this way would be a pain, to say the least.

> Rather more personal preference than anything else: Don't you just _love_ 
> the idea of the X server running on its own CPU? It'd be the equivalent of 
> having your own X terminal on board <grin>. No, it probably won't compete 
> for speed with a well-designed framebuffer, but I think it's a very elegant 
> solution.

The 34010 will be around half the speed at doing bitblt's than the r3k;
the 34k can probably do other things faster (lines, circles) but they
don't matter.  As Pat says though, the 34k will take the load off the
r3k.

-- 
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 broadley@neurocog.lrdc.pitt.edu Mon Jun 28 09:17:49 1993
Return-Path: <broadley@neurocog.lrdc.pitt.edu>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA24607; Mon, 28 Jun 93 09:17:45 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA11445; Mon, 28 Jun 93 00:16:57 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA17906; Mon, 28 Jun 93 00:16:48 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA11397; Mon, 28 Jun 93 00:16:46 -0700
Message-Id: <9306280716.AA11397@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA20200; Mon, 28 Jun 93 03:16:15 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Graphics 
To: riscy@pyramid.com (Mips 3000)
Date: Mon, 28 Jun 1993 03:16:14 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 3444      
Status: RO
X-Status: 

The newest HP xterminals which were by far the fastest when they were announced
are based in i960 chip (I believe 22.5 Mhz).  I can peek inside ours if people 
are interested in the other chips inside.  As a reaction to this tektronics 
dropped the there 68030 at 20 Mhz+ 34020 at 40 Mhz (might of been the 34010) 
and used a mips 3000 + support chips.  I believe ncd dropped whatevery they 
had and went with an 88100(I think).  I think tektronics had problems getting 
both processors to work well together.  There engineers stopped out and tried
to figure out why the HP was winning by such large numbers on our benchmark.

Both the "How to write a fast xserver for a dumb frame buffer" and
"The Design of a Smart frame buffer" are good reading for those who 
are into Hardware+xserver design.

From a previus message I heard that at 40 Mhz you would get about 6 MB 
a second, where do these number come from?  Did somebody also say
that the mips could write through the tiga chip for 16 bit access to
vram?

Couldn't a TIGA chip write from vram memory to vram memory at 16 bytes every 
other cycle right? (16 bit access read, 16 bit access write).  So at 40 mhz 
they would be 20 million * 2 bytes or 40 million pixels a second no?  

Updating screen from the mips ram would be the same right? (16 bit read on
the mips, 16 bit write on tiga) a 1024x768 screen updated more then 40 times 
a second sounds great to me.  Am I missing something??? Or can the mips
not support a 32 bit read from ram every 4 th cycle (with a 16 bit
write to tiga every other cycle?)

With a C compiler for the tiga chip I think we would be able to get the
tiga working as a dumb frame buffer then gradually move more and more
of the server onto the tiga chip which would shrink the mips ram
usage, shrink the usage of mips cpu cycles, shrink the usage of mips/
Tiga memory bandwidth etc.   I'd say we would need a minimum of 512
dram on the tiga chip to make it smarter then a dumb frame buffer.

Without the TIGA chip anyone care to speculate what percentage of the
cpu would be used under different conditions?

I know of no support for any free xserver to run on the TIGA chip, I heard of
a few that were sold, but none free.  The c compiler for a reasonable cost 
seems like a great idea (I'd chip in).  I have heard of $1500 tiga boards
for pc's that run the xserver on the tiga chip.  I have a couple tiga 
boards and none of the have Xservers (if they are free where??)

I've heard bad things about alot of buffered serial chips, and that
the National Semiconductors 16550 afn was reliable.  If the NS16552 (the 2 
port version) gets good review (i.e. has few bugs) it sounds good to put 
one on everybody's motherboard.  I like this much better then a everyone 
stick whatever they have on the ISA bus.  How much more do we want
out of a serial chip then a wide range of speeds and a 12 character
buffer? (well 16 but it generates a interrupt at 12).  The more hardware
in common between mips motherboards the better remember we have a
much smaller number of people writing software in support of the mips
then the linux community has.  Maybe we should donate a motherboard
to linus !! 8-)  (I'll pitch in $40-$50 towards a linus ported linux)

-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok


 
From hobbes@spacemanspiff.den.mmc.com  Ukn Jun 29 00:26:14 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA24104; Tue, 29 Jun 93 00:26:12 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA24474; Mon, 28 Jun 93 21:23:44 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA10635; Mon, 28 Jun 93 21:23:21 -0700
Received: from spacemanspiff.den.mmc.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA24466; Mon, 28 Jun 93 21:23:13 -0700
Received: by spacemanspiff.den.mmc.com (920330.SGI/1.34.a)
	id AA02966; Mon, 28 Jun 93 22:27:02 -0600
From: hobbes@spacemanspiff.den.mmc.com (Stephen Camp)
Message-Id: <9306290427.AA02966@spacemanspiff.den.mmc.com>
Subject: Re: TIGA chip/docs
To: riscy@pyramid.com
Date: Mon, 28 Jun 1993 22:27:01 -0700 (MDT)
In-Reply-To: <9306281614.AA27593@gossip.pyramid.com> from "Bill Broadley" at Jun 28, 93 12:14:16 pm
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 4086      
Status: RO
X-Status: 

> 
> I havea really cool tiga interface users guide, which seems to be a full
> c library for dos to use the tiga chip (Not sure if source is available).
> 
> Also of interest TMS340 Family code generation tools users guide literature
> number SPVU020.
>         Describes the c compiler, assembler, linker, and archiver for the
> ths340X0 graphics system processors.
> 
> So apparently they already have the c compiler (I think it's free).
> 
> Ti has been very generous with the documentation (we got it free)
> which is a big win.
> 
> I tried to call for prices but I didn't have any parts numbers.


I hate to rain on Bill's parade, BUT... the TI SDK (Software Developer's
Kit) for TIGA boards (340x0), costs ~ $1500 (US).  The Tiga DDK's (Driver
Developer's Kits) are free.  They have the Tiga library that you can down-
load onto the TIGA board (i.e. they are 340x0 executables), and you then
send commands from the CPU to the 340x0 to execute such and such a Tiga
routine.  If you want to write native code for the 340x0, you have to have
the SDK ($1500 US), and if you want to "extend" the tiga library by writing
your own routines and linking them into the tiga library, you have to 
get the SDK.

NOTE, the SDK is only available for DOS (80x86 arch) :-(.  I think someone
ported it to UNIX (80x86), but I don't think it's for sale.  MetroLink,
they do a lot of Xservers, has a TIGA product, but I think they ran the 
SDK under VP/ix under 386 Unix (I think) to do their development work.  They
do not recommend 340x0 boards for X.  However, as best I can tell, the X
server is not running completely on the 340x0 board, they only download
the TIGA library, and then make graphics calls to the 340x0, so the host
CPU has to still do a lot of work.

BY contrast, I have a Hercules GraphicStation Card (60Mhz 34010, 1MB VRAM,
2MB DRAM - for data / code) and I have run the Xoftware Xserver by AGElogic
on it.  AGElogic wrote the Xserver in native 340x0 code.  They DID NOT USE
TIGA!  As a result, the entire Xserver was offloaded to the 34010.  My 
impressions of it's performance:  

	raw speed - slower than an ATI Graphics Ultra
	usable speed - faster than an ATI Graphics Ultra
		     - the 'feel' of window operations - opening icons,
			closing icons, moving windows, resizing windows,
			scrolling, etc - was 'on the order of' a Sparc 1-2,
			and a Personal Iris.  NOTE: this was the feel
			of window operations, not raw graphics speed -
			line drawing speed, arcs etc was slower, sometimes
			much slower.

	caveat:  machine is a 386/25mhz w/ 64K cache, 8Mb ram.  This machine
		is slow - similar to a sun 260.  However, it was much more
		usable with the 34010 card and the offloaded Xserver, than
		it is now with a Graphics Ultra.  I could have 6-12 windows
		open, have kaleid or psycho running, plus running a a couple
		emacs, and doing one or two compiles, and the graphics was
		still usable - on a 25Mhz 386!!!

	However, as it has been noted, TI is abandoning TIGA.  I don't know
how much support TI would give us in the future.  Plus the SDK is $1500!
Would they donate it to us?  I have no clue.

	What about the Weitek Power9000 (the GX in the Sun GX graphics)?  It's
available.  It's very fast.  If not, I'd recommend either an S3 chip (801 or
928), or the ATI Mach32.  Matrox has just come out with a 3D piece of Silicon.
They are claiming an absurd amount of Winmarks (>60000?).  It supports a 
Z buffer etc.  Yeah, maybe it's pie in the sky, and yes, maybe it makes things
hard as hell... I'm just thinking out loud here.

I'm told there will be PC (ISA/EISA/PCI/VESA) 3D cards <$1000 this coming year)
- the next 6 months maybe?... So, would it be worth it to put a bus on this
thing and let users get their favorite card?

Another idea - let the R3k do all the graphics stuff... but make it possible
to put a DSP on the board ... people are starting to do all sorts of nifty
3D stuff with DSPs.  If there was a dumb frame buffer for video, that the
R3k and the DSP could both access... just a thought.

-steve camp
hobbes@spacemanspiff.den.mmc.com



 
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 aki@akix.cts.com  Ukn Jun 29 02:56:42 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA00797; Tue, 29 Jun 93 02:56:40 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17316; Mon, 28 Jun 93 23:54:18 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA28381; Mon, 28 Jun 93 23:54:18 -0700
Received: from crash.cts.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17312; Mon, 28 Jun 93 23:54:12 -0700
Received: from akix by crash.cts.com with uucp
	(Smail3.1.28.1 #15) id m0oAZZl-0000kRC; Mon, 28 Jun 93 23:53 PDT
Received: by akix.uucp (/\==/\ Smail3.1.21.1 #21.2)
	id <m0oAZI3-0002ELC@akix.uucp>; Mon, 28 Jun 93 23:35 PDT
Message-Id: <m0oAZI3-0002ELC@akix.uucp>
Date: Mon, 28 Jun 93 23:35 PDT
From: aki@akix.cts.com (Aki Atoji)
To: riscy@pyramid.com
Subject: Re: Things ...
In-Reply-To: <9306280531.AA07240@sword.eng.pyramid.com>
References: <9306280531.AA07240@sword.eng.pyramid.com>
Status: RO
X-Status: 


>> The TI340?0 video solution:  From what I have read of the TI340?0, it
>> does its pixel stuff at the speed of its memory; that is, the speed
>> of bitblt is the bandwidth of its memory.  In any windowing environment.
>> the speed of bitblt is the major determining factor in how fast it goes.
>> So, given this, the TI34020 is exactly twice the speed of the TI34010.

I've done a fair amount of 34010 software/hardware work in the past,
and this is from my (part fuzzy) memory, data book and experiences:

The 34010 Bitblt (or PIXBLT as they call it) cycles vary depending on
source/destination alignments and the BLT operation.  For example, a
688x500 pixel BLT (approx size of my xterm) with PIXBLT XY, XY using
replace operation takes roughly 86000 machine cycles with best case
source and destination alignment.  This translates to 57000 uSec or
57mS using 60MHz 34010, which isn't spectacular at all.

There are a few things with 34010 to note as well.  34010 doesn't do
fast page mode, so you can't really call the above 'at memory speed'.
34010 isn't that fast of a chip as far as clock speed goes.
Internally, every machine cycle is 1/4 of the clock, so it's actually
a heavy duty CISC chip that runs at 15MHz maximum.  Also, there is a
limitation of 'power of 2' rule on the X-Y size of the bitmap area.
i.e, if a viewable screen is 640x480, you have to tell GSP to use
entire 1024x512 (closest power of 2 figures) worth of VRAM for
display.  The un-viewable area cannot be used for code, since these
are little chunks along linear memory map.

On the other hand, this chip is really great for driving video with,
and everything is so nicely integrated.  The completely programmable
video sync outputs, transparent (to programmers) VRAM transfer cycle
generation and built-in DRAM interface including refresh makes this
chip a really good choice to drive video with using VRAM.

Now, I'm fairly new to this mailing list, so please excuse me if I
missed some part of the thread.  But getting 34010 to boot up from
scratch and make the code work reliably is a fair amount of work.
Since the chip hangs off of another CPU in this case, the 'host' CPU
has to support a lot of functionality such as downloading code to
34010 (essential for development), handle debug trace from 34010
(gotta have them printf's go somewhere) and so on.  Personally, I've
had experiences of spending long, long, long LONG hours of trying to
debug 34010 code that crashes after certain combinations of
proprietary display list processing or font cache operation, and I
wouldn't recommend it to anyone.

Also, the real strength of 34010 comes from compact graphics specific
assembly code that can only be fully utilized by getting down to the
nitty gritty and writing the straight assembly.  And gobs and gobs of
it if it was going to be X server running on it with decent speed.
It's not hard, since the chip handles a lot of things for you (such as
clipping, alignment and so on), and also since the address is counted
in bits and not bytes which sort of gives you the right perspective in
graphics programming.  Even then, it may not compete well against late
model VGA's or accel chips with fast X server.  The chip is just
getting outdated these days....  (and so is my expertise with this
chip, I suppose).


>>  If we were to connect the VRAM (we should use VRAM rather than my
>>  original suggestion) to the R3000, then we still have to generate
>>  the cycles on the main bus to load the VRAM serial registers, and
>>  have something generate the video sync signals.

Well, the transfer cycles wouldn't be generated on main bus, since it
is almost like a normal DRAM access cycle except that TR signal will
be applied before RAS* goes low.  You can generate this after/inside
the DRAM (VRAM) interface rather than on the main bus.


>>   While the TI34010 doesn't allow direct access to the VRAM from the
>>   R3000, it does give us everything else.  Unless we can get another
>>   solution that does this with the VRAM connected to the R3000, then
>>   I opt for this.

34010 allows host to access any part of it's local memory through it's
host control registers.  This is really slow bandwidth, however.
Also, you can always have shared memory that hatls or waits 34010
during access by host (but with a lot of parts).

>>   As for performance, the TI34010 probably competes fairly well with
>>   things like the S3 chipsets, especially since some if not all of
>>   the X-server can run on the TI34010.

I'm not too sure about that.  I think its days are getting near the
end, especially with all the accel chips coming out.



---------------------------------------------------------------------------
Aki Atoji              Unix, X, Networking and Embedded Realtime Consulting
           aki@akix.cts.com                   crash!akix!aki@trout.nosc.mil
---------------------------------------------------------------------------

 
From andy@resi.waldorf-gmbh.de  Ukn Jun 29 03:15:40 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA01147; Tue, 29 Jun 93 03:15:39 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA19959; Tue, 29 Jun 93 00:12:11 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA01029; Tue, 29 Jun 93 00:12:06 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA19870; Tue, 29 Jun 93 00:11:59 -0700
Received: by mail.Germany.EU.net(EUnetD-2.2.6.c) via EUnet
	id QA14248; Tue, 29 Jun 1993 09:09:02 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for unido
	id AA11465; Tue, 29 Jun 93 08:58:10 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Tue, 29 Jun 93 08:56:40 +0200
Message-Id: <9306290656.AA14588@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA14588; Tue, 29 Jun 93 08:56:40 +0200
To: riscy@pyramid.com, wolff@liberator.et.tudelft.nl
Subject: Re:  Moving this mailinglist?
Status: RO
X-Status: 

Hi everyone,

> At the moment this mailinglist is moving at around 20 or more mailmessages
> a day. This is more like the volume that goes around in a newsgroup.
> Also newsreaders are more adapted to selective reading. 

> Wouldn't it  be a good idea to move this mailinglist into a newsgroup?
> (This would allow my mailbox to go back to normal: a few messages a day)
> Disadvantage is a slower turnaround time of a few days between posting and
> that everyone has it. Another disadvantage would be that we might attract
> a lot of "noise" if EVERYONE reading news would get a message "do you want
> to subscribe to the group alt.desinging.our.own.R3000.motherboard?". If we
> think that this would attract too much noise we could go for the
> nondescriptive name trick: alt.linux.is.great :-)

NO, PLEASE DON'T DO THAT !!!

Within a few weeks hundreds of people will join to that list,
each one with different wishes and ideas. We will NEVER finish
that design, we just will spend years with talking about how
it should look like !

Andy

 
From andy@resi.waldorf-gmbh.de  Ukn Jun 29 03:55:43 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA02186; Tue, 29 Jun 93 03:55:42 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23982; Tue, 29 Jun 93 00:52:14 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA03089; Tue, 29 Jun 93 00:52:10 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23978; Tue, 29 Jun 93 00:52:02 -0700
Received: by mail.Germany.EU.net(EUnetD-2.2.6.c) via EUnet
	id QA16154; Tue, 29 Jun 1993 09:48:55 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for unido
	id AA11738; Tue, 29 Jun 93 09:37:26 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Tue, 29 Jun 93 09:35:53 +0200
Message-Id: <9306290735.AA14808@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA14808; Tue, 29 Jun 93 09:35:53 +0200
To: adyer@zarniwoop, riscy@pyramid.com
Subject: Re:  [caret@pyramid.com: Things ...]
Status: RO
X-Status: 


>> Sound?  Truly simple sound is to use the IBM method.  Not quite as
>> simple sound is the MAC method.  Maybe a handfull of resistors for
>> the DAC and a few resisters and capacitors for a simple filter
>> should be enough; we are not trying to compete with SoundBlasters
>> after all.  Anyone done this kind of DAC?  Isn't it text book stuff?

Why not trying the Analog Devices AD1849 "SoundPort".
It offers:

two-channel 16 bit independent A/D and D/A,
prorammable gain/attenuation,
16bit linar, 8bit u-law and a-law codings,
sample rates from 8 KHz to 48 kHz,
microphone input and
headphone output.

There's a second source too: Crystal CS4215.

This part is used in my Mips Magnum 4000. It's not
really high-end, but it is absolutely ok for a workstation.
I'll try to figure out the price and let you know.


Andy
-------------------------------------------------------------------------------
Waldorf Electronics GmbH, R&D Department
c/o Andreas Busse
Neustrasse 9-12
D-5481 Waldorf
Phone:  +49 (0)2636-80294
Fax:    +49 (0)2636-80188
e-mail: andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------

 
From PET@informatik.ee.edag.de  Ukn Jun 29 04:13:57 1993
Received: from iraun1.ira.uka.de by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA02759; Tue, 29 Jun 93 04:13:52 EDT
Received: from xlink1.xlink.net by iraun1.ira.uka.de with SMTP (PP) 
          id <21535-0@iraun1.ira.uka.de>; Tue, 29 Jun 1993 10:13:10 +0200
Received: from edfd by xlink1.xlink.net id aa21561; 29 Jun 93 10:12 MET DST
Received: from charon (informatik) by edfd.edag.de with SMTP 
          id AA22077 (5.65c/IDA-1.5 for <ewt@SunSite.unc.edu>);
          Tue, 29 Jun 1993 09:04:15 +0200
Received: From INFORMATIK/WORKQUEUE by charon via Charon-4.0A-VROOM with IPX 
          id 100.930629085953.448; 29 Jun 93 08:54:41 +0100
Message-Id: <MAILQUEUE-101.930629085950.416@informatik.ee.edag.de>
To: SunSite.unc.edu!ewt@informatik.ee.edag.de,
        pyramid.com!riscy@informatik.ee.edag.de
From: peter katzmann <PET@informatik.ee.edag.de>
Date: 29 Jun 93 08:59:50 CET
Subject: Re: 34010 X compiler, mailing lists
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: RO
X-Status: 

>
> On xxx, 27 Jun 1993, Pat Mackinlay wrote:
>
> [lots of good stuff about 34010's deleted becuase we've all read it already
>
> > BTW: I wouldn't expect that using a 34010 would make the graphics
> > system outperform any of the VGAs out there, but it'd be quite
> > interesting, and would leave the main CPU free to do some "real"
> > work. It might even be practical to run PEX stuff <grin>
It will be faster then the normal VGA solution's. We wrote a CAD
package for an PC with TIGA or VGA and the TIGA outperformes the VGA
of about 70% and it wasn't the bist design.
>
> If we do decide on the 34010 path, I agree with Pat that a gcc port would
> be a huge problem. I'm willing to write a small C compiler for the chip
> from scratch. I'm not offering to port gcc, as I think that such an effort
> is unnecessary. If the chip is going to be driving graphics, code doesn't
> have to be written often, so I think we can live with putting the
> optimizations in the code instead of the compiler.
>
You don't have to wrote the Compiler from the scratch. There's ans
old C projekt from Dr Dobb's when i'm think right. I have the source
code here for K&R or Turbo C. Several company's rewrote the generator
part for their different single Chip CPU's.

> By small I mean I'm not going to write a floating point library (though
> I'd be happy to integrate with one written by someone else), generate
> anything but straight object code for the 34010 (we don't need dll's,
> etc for a graphics processor), or even acknowledge C++'s existence any
> further then allowing // for comments. Let me know if this is worth
> my time.
If it's necessary i could do it, but not one that's IEEE conform.


----

EDAG-Fulda | P. Katzmann | E-Planung | Steinauer Str.| 6400 Fulda
tel. 0661/6000-454/464 | W. Germany | in: pet@informatik.ee.edag.de

 
From Hannu.Savolainen@cs.Helsinki.FI  Ukn Jun 29 04:14:30 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA02797; Tue, 29 Jun 93 04:14:29 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA26958; Tue, 29 Jun 93 01:10:13 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA03917; Tue, 29 Jun 93 01:10:13 -0700
Received: from hydra.Helsinki.FI 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA26921; Tue, 29 Jun 93 01:10:06 -0700
Received: from kypros (kypros.Helsinki.FI) by hydra.Helsinki.FI (4.1/SMI-4.1/39)
	id AA09897; Tue, 29 Jun 93 11:08:36 +0300
From: Hannu.Savolainen@cs.Helsinki.FI (Hannu Savolainen)
Message-Id: <9306290808.AA09897@hydra.Helsinki.FI>
Subject: Re: Response to lots of mail
To: riscy@pyramid.com
Date: Tue, 29 Jun 93 11:08:36 EET DST
In-Reply-To: <9306290156.AA26387@sword.eng.pyramid.com>; from "Neil Russell" at Jun 28, 93 6:56 pm
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

> I don't think that we need to spend much money on sound.  I am currently
> figuring on a bunch of resistors to make a real cheap DAC.  Having an
> ISA bus sovles the problem for guys that want better sound.
A cheap DAC without DMA capability is not a solution. The driver for it
will have to serve 8000 to 44100 interrupts per second with almost zero
interrupt latency (Linux/486/50 can't do this).
I think the ISA bus based solution is best if we want sound
capabilities. Designing a DAC suitable for sound output is not as simple
as it looks. An almost unmeasureable break in the data flow produces an
annoying click. It's better just to drop the sound capabilities if we
don't have the ISA bus or to desing a GNU soundcard as a separate
project.

Hannu


 
From PET@informatik.ee.edag.de  Ukn Jun 29 04:19:50 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA03078; Tue, 29 Jun 93 04:19:49 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28774; Tue, 29 Jun 93 01:14:40 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA04515; Tue, 29 Jun 93 01:14:40 -0700
Received: from iraun1.ira.uka.de 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28770; Tue, 29 Jun 93 01:14:31 -0700
Received: from xlink1.xlink.net by iraun1.ira.uka.de with SMTP (PP) 
          id <21537-0@iraun1.ira.uka.de>; Tue, 29 Jun 1993 10:13:10 +0200
Received: from edfd by xlink1.xlink.net id aa21566; 29 Jun 93 10:12 MET DST
Received: from charon (informatik) by edfd.edag.de with SMTP 
          id AA22077 (5.65c/IDA-1.5 for <riscy@pyramid.com>);
          Tue, 29 Jun 1993 09:04:15 +0200
Received: From INFORMATIK/WORKQUEUE by charon via Charon-4.0A-VROOM with IPX 
          id 100.930629085953.448; 29 Jun 93 08:54:41 +0100
Message-Id: <MAILQUEUE-101.930629085950.416@informatik.ee.edag.de>
To: SunSite.unc.edu!ewt@informatik.ee.edag.de,
        pyramid.com!riscy@informatik.ee.edag.de
From: peter katzmann <PET@informatik.ee.edag.de>
Date: 29 Jun 93 08:59:50 CET
Subject: Re: 34010 X compiler, mailing lists
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: RO
X-Status: 

>
> On xxx, 27 Jun 1993, Pat Mackinlay wrote:
>
> [lots of good stuff about 34010's deleted becuase we've all read it already
>
> > BTW: I wouldn't expect that using a 34010 would make the graphics
> > system outperform any of the VGAs out there, but it'd be quite
> > interesting, and would leave the main CPU free to do some "real"
> > work. It might even be practical to run PEX stuff <grin>
It will be faster then the normal VGA solution's. We wrote a CAD
package for an PC with TIGA or VGA and the TIGA outperformes the VGA
of about 70% and it wasn't the bist design.
>
> If we do decide on the 34010 path, I agree with Pat that a gcc port would
> be a huge problem. I'm willing to write a small C compiler for the chip
> from scratch. I'm not offering to port gcc, as I think that such an effort
> is unnecessary. If the chip is going to be driving graphics, code doesn't
> have to be written often, so I think we can live with putting the
> optimizations in the code instead of the compiler.
>
You don't have to wrote the Compiler from the scratch. There's ans
old C projekt from Dr Dobb's when i'm think right. I have the source
code here for K&R or Turbo C. Several company's rewrote the generator
part for their different single Chip CPU's.

> By small I mean I'm not going to write a floating point library (though
> I'd be happy to integrate with one written by someone else), generate
> anything but straight object code for the 34010 (we don't need dll's,
> etc for a graphics processor), or even acknowledge C++'s existence any
> further then allowing // for comments. Let me know if this is worth
> my time.
If it's necessary i could do it, but not one that's IEEE conform.


----

EDAG-Fulda | P. Katzmann | E-Planung | Steinauer Str.| 6400 Fulda
tel. 0661/6000-454/464 | W. Germany | in: pet@informatik.ee.edag.de

 
From broadley@neurocog.lrdc.pitt.edu  Ukn Jun 29 07:51:10 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA09763; Tue, 29 Jun 93 07:51:08 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA01280; Tue, 29 Jun 93 04:46:21 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA01440; Tue, 29 Jun 93 04:44:40 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA01010; Tue, 29 Jun 93 04:44:10 -0700
Message-Id: <9306291144.AA01010@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA27874; Tue, 29 Jun 93 07:43:30 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Radical Video Idea
To: riscy@pyramid.com (Mips 3000)
Date: Tue, 29 Jun 1993 07:43:29 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 2606      
Status: RO
X-Status: 

I was trying to get a feel for how fast a mips 3081/51 + 3041 would be as a X11
machine.  What clock speed was the proposed 3041 as a video driver?  I'll call 
the 3041 cpu speed for the frame buffer X Mhz.

I looked around and found out that the decstation 3100 (16 Mhz mips 2000) has
a dumb frame buffer directly hooked up to the cpu.  If your interested in the 
setup/xserver check out "Writing Fast X Servers for Dumb Color Frame buffers."
A dec 3100 is a fairly fast xserver (for it's age anyways), I'd say better 
then an ET4000+linux anyways.  This should scale directly from 16.67 Mhz to
X Mhz.  I can run any benchmarks on the 3100 that people want.

In the "Smart Frame buffer" paper a 5200 (mips 3000 at 25 Mhz) with the frame 
buffer on the turbochannel is listed as having a max bandwidth of 30 MB/sec 
(writing big rectangles), or 15 MB/s for copying.   I'd expect more then this 
because it was on the turbo channel bus.  So our speed should scale as 
X Mhz/(25 Mhz * (1- % of turbochannel overhead)).

So the performance of a 3041 to drive the dumb frame buffer seems pretty good.  

Is it a reasonable thing to ask of a 3041 to generate a signal for horizontal
and vertical retrace?  For 1024x768 at 70 hz you need to generate 53,761 
retrace signals per second all that have to be accurate within a minimum of 1/
(1024*768*70) = 1/55,050,240 of a second.  Which gives you one pixel accuracy

Isn't that an easy thing to do directly?  I think using a second 3041 just
for an Xserver is a great idea.  Handling keyboard I/O, serial I/O seems
fairly direct.  Handling time critical video retraces sounds like it's 
not but then I'm in software..... 

This would make better use of the main's cpu ram, cache, cycles, context
swiches, memory bandwidth for running linux or applications.  The secondary 
processor would worry about I/O and running the Xserver.   I'd say of
all those things we are shortest on cache (most comprable machines have
128 k cache).

If this become impracticle maybe we should add a 256 k cache instead.

This way we get the advantages of an X11 specialized accelerator (directly
implements all of the Xprotocol) without the disadvantage of porting
X11 to a unsupported chipset.  You only need to learn one chip instead of 
two.  X11 should compile fine on a mips chip, as well as gcc.

Basically if the hardware guys can put it together it should be great.

--
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok


 
From andy@resi.waldorf-gmbh.de  Ukn Jun 29 08:16:04 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA10579; Tue, 29 Jun 93 08:16:03 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05399; Tue, 29 Jun 93 05:12:57 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA03666; Tue, 29 Jun 93 05:12:28 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05162; Tue, 29 Jun 93 05:12:12 -0700
Received: by mail.Germany.EU.net(EUnetD-2.2.6.c) via EUnet
	id QH28103; Tue, 29 Jun 1993 14:09:07 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for unido
	id AA13952; Tue, 29 Jun 93 14:07:17 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Tue, 29 Jun 93 14:05:47 +0200
Message-Id: <9306291205.AA15272@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA15272; Tue, 29 Jun 93 14:05:47 +0200
To: riscy@pyramid.com
Subject: Prices
Status: RO
X-Status: 


Half an hour ago I got new prices from the german IDT distributor.
I think we were a wrong with the 3081 price.

R3051/40:  $164
R3051E/40: $182
R3081/40:  $317
R3041/20:  $45

Evaluation board for 3051/81: $1170

all excl. TAX, cpu's in quantities > 100

The parts are perhaps less expensive in USA...

Andy

 
From toz!cyberman@acsu.buffalo.edu  Ukn Jun 29 08:26:57 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA11266; Tue, 29 Jun 93 08:26:55 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06611; Tue, 29 Jun 93 05:23:50 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA04548; Tue, 29 Jun 93 05:23:51 -0700
Received: from eerie.acsu.buffalo.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06607; Tue, 29 Jun 93 05:23:44 -0700
Received: from toz.UUCP by acsu.buffalo.edu (4.1/1.35)
	id AA06731 for riscy@pyramid.com; Tue, 29 Jun 93 08:22:25 EDT
Received: by toz.buffalo.ny.us (1.65/waf)
	via UUCP; Tue, 29 Jun 93 01:28:30 EDT
	for riscy@pyramid.com
To: riscy@pyramid.com
Subject: TMS340X0 - TI will no longer manufacture
From: toz!cyberman@acsu.buffalo.edu (Cyberman)
Comments:             
Message-Id: <NT5V6B1w165w@toz.buffalo.ny.us>
Date: Tue, 29 Jun 93 01:23:22 EDT
Organization: The Tower of Zot - (716)8338-616
Status: RO
X-Status: 

I'm sure some of you know this BUT just in case.
TI has anounced it will be droping the 34k series graphcs processors in 
favor of a set that is less pixe oriented and more raster ops oreinted.
They said they would support the 34k but that they are phasing them out 
into a more "windows" style acelerator.  At this point I suggest the real 
place to look for graphics acelerators et al would be some of the new 
chip sets tthat are being offered.  Cirrus is offering several FAST 
acelerated chip sets.  

I think using a "smart" controler is a nice idea but dumb ones are EASIER 
to program for.  (Just my experience at least).  One can boost 
performance other ways, than just using a graphics coprocessor.  (DMA for 
pixels would be one).

Cyberman

 "Everything is vanity ..."
"Even a fool looks wise if he keeps his mouth shut"
"A man to his own, is a person left to his own devices"
"Bewary of thinking you are always right, Hitler did"

Cyberman - this is mysig 
#include <std_disclaimer.h>
#include <explained.h>
main(int argc, char **argv) { FILE *mess; mess = fopen("life.doc"r); 

 
From adyer@zarniwoop  Ukn Jun 29 00:26:36 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA24125; Tue, 29 Jun 93 00:26:35 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA24637; Mon, 28 Jun 93 21:24:19 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA10776; Mon, 28 Jun 93 21:24:17 -0700
Received: from ddsw1.mcs.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA24575; Mon, 28 Jun 93 21:24:11 -0700
Received: by genesis.mcs.com (/\==/\ Smail3.1.28.1 #28.2)
	id <m0oAX3t-000MUmC@genesis.mcs.com>; Mon, 28 Jun 93 23:12 CDT
Received: by chinet (/\==/\ Smail3.1.28.1 #28.1{chinet})
	id <m0oAWqe-0008hMC@chinet>; Mon, 28 Jun 93 22:59 CDT
Received: by zarniwoop.uucp (/\==/\ Smail3.1.24.1 #24.2)
	id <m0oAY38-00039LC@zarniwoop.uucp>; Mon, 28 Jun 93 22:16 PDT
Message-Id: <m0oAY38-00039LC@zarniwoop.uucp>
Date: Mon, 28 Jun 93 22:16 PDT
From: adyer@zarniwoop (Andrew Dyer)
To: riscy@pyramid.com
Subject: comments on today's batch o mail
Status: RO
X-Status: 


Several things bundled into one - here goes
-------------------------------------------------------
Re: Frame buffers - some performance numbers for dedicated X-terminals

on a 1280x1024 8bpp display with VRAM and a 33 MHz IDT 3051 we got
approx. 45K Xstones (intermediate demo H/W)

on a 1280 x1024 8bpp display with VRAM, a 64bit bit-blitter unit and a
33MHz 3051 we got approx. 125K Xstones (Pagine C2000)

on a 1280x1024 mono display with VRAM and a 33MHz IDT 3051 we got 105K
Xstones. (Pagine M2000)

A HP i960 based 8 bp 1280x1024 terminal clocked in at about 90K Xstones.
(700/RX?)

Most 680x0 based systems (with or without 34010) seem to get
somewhere between 25 and 60K Xstones.

I would like to see the dumb frame buffer, because I think you could
do most of what a 34010 can do for less.  I think an FPGA with
download capability could be just the ticket.  Download a config file
for whatever video h/w you want, and away she goes!  This could handle
generating xfer addresses, syncs, shift clocks and all those nasty
'glue logic' functions for the video system.  Have video RAM use the
same controller as the DRAM and have the video controller do DMA to
reload the off half of the VRAM shift register.  Remember that a high
res frame buffer usually uses ECL oscillators and some ECL logic, so
don't forget those in the comparison. (You gotta get the 125MHZ
somewhere :-)

a 33Mhz 3051 with a single bank of 32 bit VRAM can access 16 bytes in
13 clocks, with interleaving the number goes down to 11 clocks.
(These are from memory so there is a possibility I am off by a clock)
This gives 40Mbyes/sec memory bandwidth (peak) for a non-interleaved
system, and a 48Mbyte/sec bandwidth (peak) for an interleaved system.

The main problems with the 34010 is the 16 bit host port and trying to
synchonize the X drawing code with the rest of the system. (Not to mention 
trying to split that code out of the base system).

-----------
re floppy and hard drive interfaces:

You should be able to find a combo chip that does all things, and just
put it on it's own little slow bus (or the ISA bus :-)) and use a fast
SCSI on a tighter coupled bus for real disk performance.

-----------
re other processors:

For true 32 bit CPUS market share says i960(KA/CA/CF). 29K is usually
listed second, next Sparc, and then MIPS.  (but noone else comes in
the 84 PLCC as far as I know)

One thought that occured to me (while I stopped to wash dishes) is
that one of the LSI logic MIPS derivatives might be interesting
because of the higher integration that they have - Especially the
LR33020 which is really meant to be a X-terminal on a chip (on chip
VRAM control, on-chip bit-blit, programmable chip selects, bus sizing)
About the only thing it doesn't have would be the FPU - and there is
probably a way to add that externally.  Comes in CPGA package cost was in
the low $100 range in volume a while ago.

---------------
Legalities:

Is there anything like a GPL for hardware?  We should stop to consider
how this thing we are talking about should be made available and under
what terms.

---------------
Final topic:
This thing needs a cool code-name.  How about a few suggestions?
Perhaps something recursive?

 
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 bosse@snoddas.ericsson.se  Ukn Jun 29 08:43:22 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA12093; Tue, 29 Jun 93 08:43:20 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA08742; Tue, 29 Jun 93 05:39:11 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06041; Tue, 29 Jun 93 05:39:09 -0700
Received: from mailgate.ericsson.se 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA08738; Tue, 29 Jun 93 05:38:56 -0700
Received: from snoddas.ericsson.se by mailgate.ericsson.se (4.1/SMI-4.1-MAILGATE1.14)
	id AA11142; Tue, 29 Jun 93 14:37:28 +0200
Received: by snoddas.ericsson.se (4.1/SMI-4.1-LME1.6)
	id AA08082; Tue, 29 Jun 93 14:37:23 +0200
Date: Tue, 29 Jun 93 14:37:23 +0200
From: bosse@snoddas.ericsson.se (Bo-Erik Sandholm)
Message-Id: <9306291237.AA08082@snoddas.ericsson.se>
To: riscy@pyramid.com
Subject: How I would configure the Board :-)
Status: RO
X-Status: 


This is a unsolicted tip on how i would configure a 
board.
I am a member of a computer club and we discussed 
how to build a CPU board based on a 68K processor for a unix box
but I imagine that the needs a much the same for another CPU.
We did not build it due to the low prices on 486 PC boards.

If the idea is to build a mother bord then I would put on it in order of
priority

1. 8 sockets for 72 bit SIMM's 4MB or 16MB, 33 or 36 bit simms. the same ones
 used in Sun IPX.
2. 256 Kb EEPROM for a boot rom monitor
3. Realtime clock chip suitable for unix, there are several out on the market.
4. SCSI controller.
5. UART with 2 serial ports and 1 Parallell.
6. Floppy controller.
7. Onboard ethernet.
8. Advanced Videocontroller with 1 or 2 MB vram on board.

This is the vish list, the problem is that for small production runs
even if you don't charge for your own time.
It's probably going to cost a lot mor than a Taiwanese mother board for a
50MHz 486. the only thing you might win is the price on the CPU.

Whats needed for a decent price is extreamly good connection with
componet suppliers and somebody making the production of the board
below cost or just charging you the same price as they would charge per
card in a large production run.

Sorry to be so pessismistic, I wish you good luck.

Bo-Erik Sandholm
Bosse@ericom.ericsson.se



 
From Steven.D.Ligett@Dartmouth.EDU  Ukn Jun 29 08:43:35 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA12107; Tue, 29 Jun 93 08:43:33 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09347; Tue, 29 Jun 93 05:40:48 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06352; Tue, 29 Jun 93 05:40:45 -0700
Received: from dartvax.dartmouth.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09282; Tue, 29 Jun 93 05:40:37 -0700
Received: from prancer.dartmouth.edu by dartvax.dartmouth.edu (5.65+D5/4.5HUB)
	id AA25867; Tue, 29 Jun 93 08:39:20 -0400
Message-Id: <5297629@prancer.Dartmouth.EDU>
Date: 29 Jun 93 08:39:16 EDT
From: Steven.D.Ligett@Dartmouth.EDU (Steven D. Ligett)
Subject: Re: Prices
To: riscy@pyramid.com
Status: RO
X-Status: 

--- Andreas Busse wrote:
R3051/40:  $164
R3051E/40: $182
R3081/40:  $317
R3041/20:  $45
--- end of quoted material ---
Are these prices for single pieces?  It was last week that I got a price of
$385 for 1 3081e-40mj.  Is there perhaps a cheaper package now??  Or should
we order from Germany??

Also, IDT's ad continue to say the 3051 family is multisourced.  Does anyone
know of another vendor that is producing the parts??  I haven't seen any
announcements.

 
From broadley@neurocog.lrdc.pitt.edu  Ukn Jun 29 08:43:38 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA12113; Tue, 29 Jun 93 08:43:37 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09373; Tue, 29 Jun 93 05:40:58 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06357; Tue, 29 Jun 93 05:40:59 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09363; Tue, 29 Jun 93 05:40:52 -0700
Message-Id: <9306291240.AA09363@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA28219; Tue, 29 Jun 93 08:40:23 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Sims, bus
To: riscy@pyramid.com (Mips 3000)
Date: Tue, 29 Jun 1993 08:40:23 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1355      
Status: RO
X-Status: 

We have a gateway with 36 pin sims, and 4 sim slots, it handles 8 MB, 
16 MB, 32 MB, 40 MB, and 64 Mb I believe.  Is handling 16 Mb sims expensive?
I suspect this isn't possible with the IDT 79R3730.

Was does 2 way interleave mean?  I need 4 simms of the same size, or 8 to take 
advantage of it.   Will it work with less without 2 way interleave? How much of
a performance penalty?

Seems like the IDT79R3730 can support 2 seperate dma channels for slower 
devices.  What's the benefit with going with a 10 Mhz 16 bit proprietary bus?  
Especially if we have to make all the cards that fit it ourselves, and we won't
be bandwidth limited by ISA anyways?   I realize it will be less complex (with 
less functionality), and take up less board space (not critical)

I think a motherboard with 16 sims slots, 4-5 isa slots, scsi and video on 
board would provide a balanced expandable system.  Net people would by a net 
card (maybe serial/parallel/floppy also), modem people would buy a 2 or 4 port 
card with parallel and floppy.

The motherboard would be as small and simple as possible while not sacrificing 
any performance or expandability.

-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok


 
From tthorn@daimi.aau.dk  Ukn Jun 29 09:43:01 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA14436; Tue, 29 Jun 93 09:42:57 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15050; Tue, 29 Jun 93 06:37:32 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA12045; Tue, 29 Jun 93 06:37:15 -0700
Received: from avignon.daimi.aau.dk 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15040; Tue, 29 Jun 93 06:37:04 -0700
Received: by avignon.daimi.aau.dk id AA21662
  (5.65c8/IDA-1.4.4 for riscy@pyramid.com); Tue, 29 Jun 1993 15:36:59 +0200
Date: Tue, 29 Jun 1993 15:36:59 +0200
From: Tommy Thorn <tthorn@daimi.aau.dk>
Message-Id: <199306291336.AA21662@avignon.daimi.aau.dk>
To: riscy@pyramid.com
Subject: ISA or not [Was: My thoughts on the MB design...]
References: <01GZYKX2D60AFUMLVJ@cc.curtin.edu.au>
Reply-To: Tommy.Thorn@daimi.aau.dk
Status: RO
X-Status: 

Pat Mackinlay writes:

 > >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 
 > 
 > It seems the most strident opposition to this is actually coming from Neil. 

How do you arrive at this conclusion? For several of the posters, including
myself, ISA is a must. Without ISA, the cost of going MIPS now has
to include the price for new boards like IDE, parallel, sound, ISDN..

 > 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".

Well, what if some planned *not* to by it "off the shelf", but had the
parts already.

What I really hope to see is an ISA capable motherboard with video,
and if nessesary, optional SCSI and Ethernet onboard.

I accept of course that my view may carry little weight, as I'm
more a software kind of guy.

 
From broadley@neurocog.lrdc.pitt.edu  Ukn Jun 29 09:51:42 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA14902; Tue, 29 Jun 93 09:51:41 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15388; Tue, 29 Jun 93 06:48:19 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA12689; Tue, 29 Jun 93 06:48:13 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15384; Tue, 29 Jun 93 06:48:06 -0700
Message-Id: <9306291348.AA15384@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA28423; Tue, 29 Jun 93 09:47:32 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Operating system
To: riscy@pyramid.com (Mips 3000)
Date: Tue, 29 Jun 1993 09:47:32 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1316      
Status: RO
X-Status: 

I heard that Mach + HURD can be rather resource intensive, but...


     Mach.  Mach is a free message-passing kernel being developed at CMU.
     The Hurd servers, working with the GNU C Library, will provide Unix-like
     functionality.  Together with Mach they are the last major components
     necessary for a complete GNU system.  Currently there are free ports of
     the Mach kernel to the 386 PC and the DEC PMAX workstation.  (The PMAX
     is one kind of MIPS-based DECstation.)  Other free ports of Mach are in
     progress.  Contact CMU for more information if you want to help with one
     of those or start your own.  Porting the GNU Hurd and GNU C Library is
     easy (easier than porting GNU Emacs, certainly easier than porting GCC)
     once a Mach port to a particular kind of hardware exists.


Just though we should keep it in mind.  (I think mach would handle MIPS cpu+
mips video real well 8-) )

I think BSD 4.4 still has some AT&T but I think a version runs on
the decstations (again mips).

Linux of course is 100% free but probably the least portable (it pains
me to say).

-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok


 
From PET@informatik.ee.edag.de  Ukn Jun 29 10:15:13 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA16130; Tue, 29 Jun 93 10:15:07 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17159; Tue, 29 Jun 93 07:12:22 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA13354; Tue, 29 Jun 93 07:12:13 -0700
Received: from iraun1.ira.uka.de 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17010; Tue, 29 Jun 93 07:12:02 -0700
Received: from xlink1.xlink.net by iraun1.ira.uka.de with SMTP (PP) 
          id <03065-0@iraun1.ira.uka.de>; Tue, 29 Jun 1993 16:11:19 +0200
Received: from edfd by xlink1.xlink.net id aa27700; 29 Jun 93 16:11 MET DST
Received: from charon (informatik) by edfd.edag.de with SMTP 
          id AA23566 (5.65c/IDA-1.5 for <riscy@pyramid.com>);
          Tue, 29 Jun 1993 15:58:45 +0200
Received: From INFORMATIK/WORKQUEUE by charon via Charon-4.0A-VROOM with IPX 
          id 100.930629155423.384; 29 Jun 93 15:49:00 +0100
Message-Id: <MAILQUEUE-101.930629155323.352@informatik.ee.edag.de>
To: pyramid.com!riscy@informatik.ee.edag.de
From: peter katzmann <PET@informatik.ee.edag.de>
Date: Tue, 29 Jun 1993 15:53:24 CET
Subject: Re: Radical Video Idea
Reply-To: pet@informatik.ee.edag.de
Priority: normal
X-Mailer: WinPMail v1.0 (R1)
Status: RO
X-Status: 

> Is it a reasonable thing to ask of a 3041 to generate a signal for 
horizontal
> and vertical retrace?  For 1024x768 at 70 hz you need to generate 
53,761 
> retrace signals per second all that have to be accurate within a 
minimum of 1/
> (1024*768*70) = 1/55,050,240 of a second.  Which gives you one 
pixel accuracy
> 
> Isn't that an easy thing to do directly?  I think using a second 3041 
just
> for an Xserver is a great idea.  Handling keyboard I/O, serial I/O 
seems
> fairly direct.  Handling time critical video retraces sounds like it's 
> not but then I'm in software..... 
> 
> This would make better use of the main's cpu ram, cache, cycles, 
context
> swiches, memory bandwidth for running linux or applications.  The 
secondary 
> processor would worry about I/O and running the Xserver.   I'd say 
of
> all those things we are shortest on cache (most comprable 
machines have
> 128 k cache).
> 
> If this become impracticle maybe we should add a 256 k cache 
instead.
> 
> This way we get the advantages of an X11 specialized accelerator 
(directly
> implements all of the Xprotocol) without the disadvantage of porting
> X11 to a unsupported chipset.  You only need to learn one chip 
instead of 
> two.  X11 should compile fine on a mips chip, as well as gcc.
> 
> Basically if the hardware guys can put it together it should be great.
> 
I like the Idea, but what about the cost's. You have to add over $100 
for the second CPU. 
I don't like the Idea to make the timing signals from the CPU. it's to 
critical, and i don't think it will bring us a big boost. In this cas better 
lets look about an MIPS 2000 for Graphics acceleartion and i/o and a 
simple design for the video control hardware

peter

----

EDAG-Fulda | P. Katzmann | E-Planung | Steinauer Str.| 6400 Fulda
tel. 0661/6000-454/464 | W. Germany | in: pet@informatik.ee.edag.de

 
From SMACKINLA@cc.curtin.edu.au  Ukn Jun 29 10:17:39 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA16261; Tue, 29 Jun 93 10:17:35 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17603; Tue, 29 Jun 93 07:14:38 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA13440; Tue, 29 Jun 93 07:14:40 -0700
Received: from cc.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17599; Tue, 29 Jun 93 07:14:29 -0700
Received: from cc.curtin.edu.au by cc.curtin.edu.au (PMDF #3256 ) id
 <01GZYSLY84GSFUMLVJ@cc.curtin.edu.au>; Tue, 29 Jun 1993 22:14:06 +0800
Date: 29 Jun 1993 22:14:06 +0800
From: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Subject: Re: Operating system
To: broadley@neurocog.lrdc.pitt.edu
Cc: riscy@pyramid.com
Message-Id: <01GZYSLY84GUFUMLVJ@cc.curtin.edu.au>
X-Envelope-To: riscy@pyramid.com
X-Vms-To: IN%"broadley@neurocog.lrdc.pitt.edu"
X-Vms-Cc: R3KPC,SMACKINLA
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
Status: RO
X-Status: 


>Just though we should keep it in mind.  (I think mach would handle MIPS cpu+
>mips video real well 8-) )

The system is certainly capable, but there are still a few obstacles to 
getting Mach running. The major one is the fact that Mach kernel 
development is still very much tied to CMU. The source is made available, 
but there's a fairly long wait between releases and I doesn't compare well 
to the speed of Linux development. I'm not knocking Mach, but I really
think Linux is a better option at this stage... We can take another look 
once the hardware's here I guess <grin>.

>Linux of course is 100% free but probably the least portable (it pains
>me to say).

At least it's fairly small. The Mach source is pretty big, and there is 
lots of message passing semantics to learn if you really want to understand 
it all. Not only that, but then you've got to understand (and debug) the 
servers you're trying to run. Really, I think Linux would be an 
easier/quicker port... (sound strange, doesn't it <grin>).

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 tor@tss.no  Ukn Jun 29 10:21:10 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA16427; Tue, 29 Jun 93 10:21:06 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18017; Tue, 29 Jun 93 07:17:09 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA13490; Tue, 29 Jun 93 07:17:12 -0700
Received: from benoni.Uit.No 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18007; Tue, 29 Jun 93 07:17:04 -0700
Received: from benoni by ppenoni.uit.no with SMTP (PP) 
          id <29457-0@ppenoni.uit.no>; Tue, 29 Jun 1993 16:16:52 +0000
Received: from unas.tss.no 
          by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) 
          id AAbenoni29453; Tue, 29 Jun 1993 16:16:49 +0200
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA10746;
          Tue, 29 Jun 93 16:11:15 +0200
Message-Id: <9306291411.AA10746@unas.tss.no>
From: tor@tss.no (Tor Arntsen)
Date: Tue, 29 Jun 1993 16:11:14 +0200
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: riscy@pyramid.com
Subject: My wishlist..
Status: RO
X-Status: 

Ok, as everyone now comes up with their wishes, here are my quick ones:

* I want to be able to keep the board for a while, by that I feel that
  some expandability is mandatory.
  The CPU will be limited from the start to a 3081 at best, nothing to
  do here.  But I feel that limiting memory to 64MB max is not a good
  idea.  That means 32 SIMM sockets, right?  Even 128MB may be too
  little after a while, it's sad that the 3730 does not support > 4MB DRAM.
  But I think I can live with the thought of max 128MB.

* If there will be ISA then DMA devices should be on the main board because
  of the 16MB addressing limit of the ISA bus, i.e. SCSI should be
  on the main board (but almost everyone has settled on this anyway?).
  This is just because I feel it is a pity to have to do a CPU copy
  operation after the DMA, that's what DMA was invented for; to avoid
  loading the CPU with the I/O. (I know a memcopy goes quite quick with
  newer CPUs, and I can live with doing this for devices using DMA for
  small small buffers :-)

Just my 0.02 whatever..
Tor (tor@tss.no)

 
From jcallen@Think.COM  Ukn Jun 29 10:52:37 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA18903; Tue, 29 Jun 93 10:52:36 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA22833; Tue, 29 Jun 93 07:47:59 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16605; Tue, 29 Jun 93 07:47:53 -0700
Received: from Mail.Think.COM 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA22829; Tue, 29 Jun 93 07:47:41 -0700
Received: from Luna.Think.COM by mail.think.com; Tue, 29 Jun 93 10:46:25 -0400
From: Jerry Callen <jcallen@Think.COM>
Received: by luna.think.com (4.1/Think-1.2)
	id AA12910; Tue, 29 Jun 93 10:46:25 EDT
Date: Tue, 29 Jun 93 10:46:25 EDT
Message-Id: <9306291446.AA12910@luna.think.com>
To: caret@pyramid.com
Cc: riscy@pyramid.com
In-Reply-To: Neil Russell's message of Mon, 28 Jun 93 18:56:36 PDT <9306290156.AA26387@sword.eng.pyramid.com>
Subject: Response to lots of mail
Status: RO
X-Status: 

   From: caret@pyramid.com (Neil Russell)
   Date: Mon, 28 Jun 93 18:56:36 PDT

   Pat says:
   > Neil, are you still planning on using 32 SIMM sockets?

   I'd very much like this many SIMM sockets there.  Code for the R3000 is
   fairly large; the same program on the R3000 is about 40% (a guess)
   larger than on a x86.  Given that this system could handle more users
   than a x86 (mostly because of the SCSI thing I beleive) you want more
   memory.  Imagine 20 odd users all with X-terminals hanging off this
   thing.           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

OK, I'll stop lurking.

Frankly, I can't POSSIBLY imagine 20 odd users all with X-terminals hanging
off this thing. I don't have 20 life forms, including plants, in my entire
house.

What ARE the goals for this project? I think there are people with vastly
varying agendas out there.

Personally, I'd like a cheap, compact system that runs some Unix variant
and has a simple expansion bus that I can build toys for. I'm mostly a
programmer, but I like to build silly little toys in my attic.  For MY
goals, Steve's proposal makes sense:

   > cpu
   > ram
   > rom
   > video
   > scsi
   > leds
   > i/o bus
   > serial i/o
   > nvram & clock

The FPU is a non-issue, since the 3051 and 3081 are pin compatible.

A 40MHz clock makes sense; that way the same board can take a cheap, 20MHz
3051, a less cheap 20MHz 3081, or a gold-plated 40MHz 3081. Builder
decides. No changes.

More SIMMs means more money for sockets, more real estate, and (if you want
to play it safe) more nasty, power-hungry driver chips. It also complicates
life if you want to implement a memory system with better page mode logic
than you get with the default 30x1 scheme using WRNEAR. For MY goals, one
bank of SIMMs that accepts 1/4/16Mb parts gives me enough flexibility.

As Steve's pointed out, he and I've been kicking this around for a while.
We've looked at an AMAZING spectrum of Rube Goldberg configurations, and we
keep coming back to: make it simple; make it cheap; don't use hard to get
or work with parts; don't get too ambitious. That way lies madness.

Steve> My I/O bus is just 8 data lines, 8 or more address lines, power, clock, and
     > 3051 family specific handshake signals.  It takes about 36 pins.  The
     > connector is like the one Apple used in the Classic for memory addon - you
     > don't need any gold fingers.  You CAN use a ribbon cable to connect to a slot
     > for prototyping.  The burst rate approaches 20MB/sec.

Neil> I still maintain that having a new I/O bus that no-one has peripherals 
    > for is totally useless.

Don't forget that Steve's proposal includes a SCSI port. You can get a lot
of weird devices for SCSI these days.

It is incredibly easy to hook peripherals to Steve's bus. You can add a
floppy controller (my pet project) with essentially no glue except the
decoding. Ditto a parallel port. We're not talking rocket science to build
add-in boards. The hardware AND software are easy. This is ideal for
someone like me who wants to play with weird little toys like motor
controllers. Again, it gets back to goals.

Now you all know what _I_ am interested in. What about the rest of you?

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

 
From jeremy@sw.oz.au  Ukn Jun 29 00:33:04 1993
Received: from munnari.oz.au by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA24381; Tue, 29 Jun 93 00:32:37 EDT
Received: from sw.oz.au (via basser.cs.su.oz.au) by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50)
	id AA09884; Tue, 29 Jun 1993 14:32:07 +1000 (from jeremy@sw.oz.au)
Received: from chao.sw.oz.au by swift.sw.oz.au with SMTP
	id AA00541; Tue, 29 Jun 93 14:09:39 AES (5.59)
	(from jeremy@sw.oz.au for ewt%SunSite.unc.edu@munnari.oz.au)
Received: by chao.sw.oz.au (4.1/SMI-4.1)
	id AA14493; Tue, 29 Jun 93 14:09:59 EST
From: jeremy@sw.oz.au (Jeremy Fitzhardinge)
Message-Id: <9306290409.AA14493@chao.sw.oz.au>
Subject: Re: 34010 X compiler, mailing lists
To: ewt@SunSite.unc.edu (Erik Troan)
Date: Tue, 29 Jun 1993 14:09:58 +1000 (EST)
In-Reply-To: <Pine.2.4.53.9306281125.A1445@calypso> from "Erik Troan" at Jun 28, 93 11:35:05 am
Organization: Softway Pty Ltd
X-Face: 
	 '6U=%Tv\k1<Ek%ql%PN^v`Db4bakr[v~y]\u7"GbO#I=]N{l1=#P,glz$9q>l-:?\$C[D@G
	 7(vl~w8&y}!f\bh#w<Y*S~bEBTI:s&.QR>L#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb
	 l[EC}c=;uc%x'}uh3E91p&oE<q$w1r&U0yw.Sb3V&uw
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1570      
Status: RO
X-Status: 

Erik Troan bubbles:

> On xxx, 27 Jun 1993, Pat Mackinlay wrote:

> [lots of good stuff about 34010's deleted becuase we've all read it already

> > BTW: I wouldn't expect that using a 34010 would make the graphics
> > system outperform any of the VGAs out there, but it'd be quite
> > interesting, and would leave the main CPU free to do some "real"
> > work. It might even be practical to run PEX stuff <grin>

> If we do decide on the 34010 path, I agree with Pat that a gcc port would
> be a huge problem. I'm willing to write a small C compiler for the chip
> from scratch. I'm not offering to port gcc, as I think that such an effort
> is unnecessary. If the chip is going to be driving graphics, code doesn't
> have to be written often, so I think we can live with putting the 
> optimizations in the code instead of the compiler.

> By small I mean I'm not going to write a floating point library (though
> I'd be happy to integrate with one written by someone else), generate
> anything but straight object code for the 34010 (we don't need dll's,
> etc for a graphics processor), or even acknowledge C++'s existence any
> further then allowing // for comments. Let me know if this is worth
> my time.

There are at least 2 cheap or free 34k C compilers I know of.  One was
written by a friend of mind.  If people get really keen about a 34010
(curse the day), I'll ask him for terms.  It is adapted from a 68k
compiler, and it has a number of simple machine independant optimisations.
It generates assembly output.  I can also get an assembler and linker.

	J

 
From broadley@neurocog.lrdc.pitt.edu  Ukn Jun 29 10:54:01 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA18954; Tue, 29 Jun 93 10:53:59 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23439; Tue, 29 Jun 93 07:49:45 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16813; Tue, 29 Jun 93 07:49:34 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23190; Tue, 29 Jun 93 07:49:25 -0700
Message-Id: <9306291449.AA23190@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA28781; Tue, 29 Jun 93 10:48:53 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: cpu's (short)
To: riscy@pyramid.com (Mips 3000)
Date: Tue, 29 Jun 1993 10:48:53 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1294      
Status: RO
X-Status: 

I was thinking of trying to sell people on the up and coming powerpc 601.
Especially since the IDT 79R3730 isn't released yet.

50 Mhz price is $280, will probably work at 40 Mhz, Motorolla just joined 
the GCC consortium so I assume gcc will work very soon (if aix gcc doesn't 
port trivally).  It has alot of nice features including a nice 32k on chip 
cache. (and I bought the manual, anyone have projected availability?) 

But then I looked at the performance numbers:
                Specint92   Specfp92
Dec 5240        27.3        29.9   <-  similiar to planned 3081 I hope
Powerpc 40      30.30       48.48 adjusted to 40 Mhz, not much better $280
Powerpc 66      50          80	  $400
Pentium 66      64.5        56.9  $1000

Considering the increased design problems, hardware and software support
it doesn't seem worth it for the small performance jump.  (No non-fp either)

It was worth a try.  Hmm maybe the powerpc 66 at $400 and run it to the memory
at 33 Mhz.... (again probably to expensive).

I was surprised at how close the powerpc at 40Mhz is to the 3081 at 40Mhz
-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok


 
From ronald%csunix.urc.kun.nl@kunrc1.urc.kun.nl  Ukn Jun 29 11:07:24 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA19548; Tue, 29 Jun 93 11:07:22 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA25253; Tue, 29 Jun 93 08:03:24 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA20428; Tue, 29 Jun 93 08:03:26 -0700
Received: from csunix.urc.kun.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA24510; Tue, 29 Jun 93 07:59:17 -0700
Received: by csunix.urc.kun.nl (5.64/1.37)
	id AA25710; Tue, 29 Jun 93 16:52:08 +0200
From: ronald%csunix.urc.kun.nl@kunrc1.urc.kun.nl (Ronald Schalk)
Message-Id: <9306291452.AA25710@csunix.urc.kun.nl>
Subject: Video hardware for r3K project
To: riscy@pyramid.com (project riscy)
Date: Tue, 29 Jun 1993 16:52:00 +0200 (CET)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1143      
Status: RO
X-Status: 

Wouldn't it be possible to use a graphics coprocessor in a "dumb" way?
e.g. I have a diamond speedstar 24x with a wd90c31 processor. This
is an enhanced wd90c30 with bitblt & linedrawing (I believe??). But
in most systems it's used as a dumb wd90c30, maybe there are more of 
these processors. This way you could write in a short time a driver
for the dumb way, and when everything works ok, it's possible to
write an optimised driver for the hardware.

Just hinting, I'm not a hardware person.

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 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 jcallen@Think.COM  Ukn Jun 29 11:24:40 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA20309; Tue, 29 Jun 93 11:24:38 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA27737; Tue, 29 Jun 93 08:20:40 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA21847; Tue, 29 Jun 93 08:20:39 -0700
Received: from Mail.Think.COM 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA27672; Tue, 29 Jun 93 08:20:30 -0700
Received: from Luna.Think.COM by mail.think.com; Tue, 29 Jun 93 11:19:10 -0400
From: Jerry Callen <jcallen@Think.COM>
Received: by luna.think.com (4.1/Think-1.2)
	id AA13550; Tue, 29 Jun 93 11:19:09 EDT
Date: Tue, 29 Jun 93 11:19:09 EDT
Message-Id: <9306291519.AA13550@luna.think.com>
To: tor@tss.no
Cc: riscy@pyramid.com
Subject: My wishlist..
Status: RO
X-Status: 

I wrote:

   I presume that people are bearing in mind the COST of this much memory? If
   I could get 4MB SIMMs for, say, $100 a pop (which I can't), 64 megabytes
   would be $6400.

Clearly I hadn't had coffee yet. It's "only" $1600.

My point stands, though.

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



 
From broadley@neurocog.lrdc.pitt.edu  Ukn Jun 29 11:28:09 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA20521; Tue, 29 Jun 93 11:28:08 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28207; Tue, 29 Jun 93 08:24:17 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA22404; Tue, 29 Jun 93 08:24:20 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28164; Tue, 29 Jun 93 08:24:11 -0700
Message-Id: <9306291524.AA28164@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA29168; Tue, 29 Jun 93 11:23:29 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Wishlist (ram)
To: riscy@pyramid.com (Mips 3000)
Date: Tue, 29 Jun 1993 11:23:29 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 702       
Status: RO
X-Status: 

>I presume that people are bearing in mind the COST of this much memory? If
>I could get 4MB SIMMs for, say, $100 a pop (which I can't), 64 megabytes
.would be $6400.

>By the time memory prices fall to a point where _I_ could afford 64MB, the
>CPU will look like a Z8 does now and I'll want to trash it anyway.

Not to mention having that much memory with only the what 24k? (3081) of cache
seems a bit off.

Dec 3100's (mips 2000's) at 16.67 mhz have 128 k cache and a max ram of 
24 MB.  

-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok


 
From SMACKINLA@cc.curtin.edu.au  Ukn Jun 29 11:47:13 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA21436; Tue, 29 Jun 93 11:47:10 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA01057; Tue, 29 Jun 93 08:40:46 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA24447; Tue, 29 Jun 93 08:40:48 -0700
Received: from cc.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA00955; Tue, 29 Jun 93 08:40:34 -0700
Received: from cc.curtin.edu.au by cc.curtin.edu.au (PMDF #3256 ) id
 <01GZYVHBMIE2FUMLVJ@cc.curtin.edu.au>; Tue, 29 Jun 1993 23:40:05 +0800
Date: 29 Jun 1993 23:40:05 +0800
From: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Subject: Re: Response to lots of mail
To: jcallen@Think.COM
Cc: riscy@pyramid.com
Message-Id: <01GZYVHBMS18FUMLVJ@cc.curtin.edu.au>
X-Envelope-To: riscy@pyramid.com
X-Vms-To: IN%"jcallen@Think.COM"
X-Vms-Cc: R3KPC,SMACKINLA
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
Status: RO
X-Status: 


>OK, I'll stop lurking.

Welcome to the party line Jerry <grin>.

>Personally, I'd like a cheap, compact system that runs some Unix variant
>and has a simple expansion bus that I can build toys for. I'm mostly a
>programmer, but I like to build silly little toys in my attic.  For MY
>goals, Steve's proposal makes sense:

Agree. This is pretty much what I'm after too. Personally, the previous 
design we had was pretty close, but I like the idea of using the 3730 
rather than a 3041. If we can get the dedicated chip, it will make the 
board considerably less complex (there's that word again <grin>).

>than you get with the default 30x1 scheme using WRNEAR. For MY goals, one
>bank of SIMMs that accepts 1/4/16Mb parts gives me enough flexibility.

This is reasonable in my mind, but I think going to two banks is a 
worthwhile investment if interleaving is available (ie: we use a 3730). 
Again, if we do use the 3730, it can't handle 16M SIMMs, so the two bank 
option is pretty essential I think...

>Now you all know what _I_ am interested in. What about the rest of you?

I like this general direction, and if you've read my previous message, 
I think you'll find that it's pretty close. Personally, I want a little 
system that's capable of running a Unix variant, has 486ish performance and 
it architecturally "nice". I also want to be able to make toys. I think 
that puts Steve, Jerry and myself on the same wavelength?

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 timd@extro.ucc.su.OZ.AU  Ukn Jun 29 12:03:20 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA22377; Tue, 29 Jun 93 12:03:17 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA07180; Tue, 29 Jun 93 08:59:15 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA26422; Tue, 29 Jun 93 08:58:59 -0700
Received: from extra.ucc.su.OZ.AU 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06979; Tue, 29 Jun 93 08:58:47 -0700
Received: from extro.ucc.su.OZ.AU by extra.ucc.su.OZ.AU with SMTP id AA02191
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Wed, 30 Jun 1993 01:57:25 +1000
From: Tim Docker <timd@extro.ucc.su.OZ.AU>
Message-Id: <199306291557.AA02191@extra.ucc.su.OZ.AU>
Subject: VRAM looks like ??
To: riscy@pyramid.com (Mips digest address)
Date: Wed, 30 Jun 93 1:57:25 EST
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

A lurker awakes!

I deduce from previous context that VRAM is dual ported RAM with
normal DRAM accesses on one side, and some sort of serial accessibility on
the other. Is this the case?

I am interested in knowing what sort of control these devices need, particularly
on the Video side (eg how they are addressed). Does someone who knows have
ten minutes to draw an ASCII picture of one of these?

My (very) brief opinions on current topics:

1) Go ISA rather than a custom bus. I feel that the added complexity (for
presumably less perfomance) pays off when it comes to plugging the sort of
weirdo boards I may want to play with. Of course there will always be software
drivers to be written, but fancy sound boards, idsn terminal adaptors etc etc
will never exist on a custom bus with such a limited user base.

2) Can the TIGA stuff. Whilst generally a fan of coprocessors and the like,
video performance for me is critical. Everyone talks X performance, but
I like the idea of this board as a low end virtual reality engine, with
graphics straight into the buffer and no windowing (two motherboards, I guess
if you want an image for each eye!). The biggest advantage a board such as this
could have over a 486 PC clone is a RISC CPU with a closely coupled frame
buffer.

3) Neil's idea regarding a second, lower end MIPS device for IO is a good one
but I'm not at all sure (as were others) that the video sync signals could be
generated with the required accuracy in software. Also how would this IO/video
processor be coupled to the main CPU - shared memory? Simulated ethenet/SCSI ?
It sounds complicated.

I do like the concept of migrating hardware into software on a secondary CPU,
but will this actually reduce the complexity ? If not, what are the benefits?

Tim

-------------------------------------------------------------------------------
Tim Docker
timd@extro.ucc.su.oz.au

 
From PET@informatik.ee.edag.de  Ukn Jun 29 12:48:15 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA24622; Tue, 29 Jun 93 12:48:13 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15457; Tue, 29 Jun 93 09:44:11 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02690; Tue, 29 Jun 93 09:44:02 -0700
Received: from iraun1.ira.uka.de 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15303; Tue, 29 Jun 93 09:43:51 -0700
Received: from xlink1.xlink.net by iraun1.ira.uka.de with SMTP (PP) 
          id <07129-0@iraun1.ira.uka.de>; Tue, 29 Jun 1993 18:43:12 +0200
Received: from edfd by xlink1.xlink.net id aa01729; 29 Jun 93 18:42 MET DST
Received: from charon (informatik) by edfd.edag.de with SMTP 
          id AA24015 (5.65c/IDA-1.5 for <riscy@pyramid.com>);
          Tue, 29 Jun 1993 17:45:47 +0200
Received: From INFORMATIK/WORKQUEUE by charon via Charon-4.0A-VROOM with IPX 
          id 100.930629174126.288; 29 Jun 93 17:36:01 +0100
Message-Id: <MAILQUEUE-101.930629174058.256@informatik.ee.edag.de>
To: pyramid.com!riscy@informatik.ee.edag.de
From: peter katzmann <PET@informatik.ee.edag.de>
Date: 29 Jun 93 17:40:58 CET
Subject: Re: Prices
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Status: RO
X-Status: 

> --- Andreas Busse wrote:
> R3051/40:  $164
> R3051E/40: $182
> R3081/40:  $317
> R3041/20:  $45
> --- end of quoted material ---
This was for 100 quantities
> Are these prices for single pieces?  It was last week that I got a price of
> $385 for 1 3081e-40mj.  Is there perhaps a cheaper package now??  Or should
> we order from Germany??
>
> Also, IDT's ad continue to say the 3051 family is multisourced.  Does anyone
> know of another vendor that is producing the parts??  I haven't seen any
> announcements.

There are two i know it's SIEMENS and when im think right Toshiba
(probably Hitachi, but one of the Big Japanese)

peter
----

EDAG-Fulda | P. Katzmann | E-Planung | Steinauer Str.| 6400 Fulda
tel. 0661/6000-454/464 | W. Germany | in: pet@informatik.ee.edag.de

 
From rohrer@fncrd8.fnal.gov  Ukn Jun 29 12:50:28 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA24767; Tue, 29 Jun 93 12:50:27 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16217; Tue, 29 Jun 93 09:45:53 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02920; Tue, 29 Jun 93 09:45:55 -0700
Received: from fngate.fnal.gov 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16193; Tue, 29 Jun 93 09:45:46 -0700
Received: by fngate.fnal.gov (5.57/Ultrix3.0-C)
	id AA03656; Tue, 29 Jun 93 11:44:27 -0500
Received: by fncrdh.fnal.gov (920330.SGI/890607.SGI)
	(for ) id AA22265; Tue, 29 Jun 93 11:41:10 -0500
From: rohrer@fncrd8.fnal.gov (Keith Rohrer)
Message-Id: <9306291641.AA22265@fncrdh.fnal.gov>
Subject: isa wishlist
To: riscy@pyramid.com
Date: Tue, 29 Jun 1993 11:41:09 -0600 (CDT)
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 339       
Status: RO
X-Status: 

Since we more or less need an ISA bus on this puppy, can we also put in a
jumper between (I'd guess) 8 MHz and 10 MHz (assuming 40 MHz for the
processor, that's a divide-by-5 and a divide-by-4)?  I don't think that
would be too much trouble, and a relatively large number of things will
successfully deal with a 10 MHz ISA bus...

	Keith



 
From wolff@tardis.et.tudelft.nl  Ukn Jun 29 12:59:35 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA25634; Tue, 29 Jun 93 12:59:30 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18239; Tue, 29 Jun 93 09:55:33 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA04734; Tue, 29 Jun 93 09:55:15 -0700
Received: from tardis.et.tudelft.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18147; Tue, 29 Jun 93 09:54:59 -0700
Received: by tardis.et.tudelft.nl (4.1/1.34JP)
          id AA00972; Tue, 29 Jun 93 18:53:30 +0200
Date: Tue, 29 Jun 93 18:53:30 +0200
From: wolff@tardis.et.tudelft.nl (Rogier Wolff)
Message-Id: <9306291653.AA00972@tardis.et.tudelft.nl>
To: riscy@pyramid.com, rohrer@fncrd8.fnal.gov
Subject: Re:  isa wishlist
Status: RO
X-Status: 

> jumper between (I'd guess) 8 MHz and 10 MHz (assuming 40 MHz for the

I'd rather not put an "arbritrary" limit on such things. Why not a 
"divide-by-N" counter? This way you'd be able to choose between
40, 20, 13, 10 and 8 (and maybe even less). This way if I happen to
have only a card that happily runs on a 40Mhz ISA bus, I can use it at
that speed...... Ok. Not that many cards will run at 40Mhz, but who 
knows......

					Roger.

 
From jeremy@sw.oz.au  Ukn Jun 29 00:37:01 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA24536; Tue, 29 Jun 93 00:36:59 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA26129; Mon, 28 Jun 93 21:34:44 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA11835; Mon, 28 Jun 93 21:34:43 -0700
Received: from munnari.OZ.AU 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA26125; Mon, 28 Jun 93 21:34:32 -0700
Received: from sw.oz.au (via basser.cs.su.oz.au) by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50)
	id AA09918; Tue, 29 Jun 1993 14:32:53 +1000 (from jeremy@sw.oz.au)
Received: from chao.sw.oz.au by swift.sw.oz.au with SMTP
	id AA00653; Tue, 29 Jun 93 14:12:37 AES (5.59)
	(from jeremy@sw.oz.au for broadley%neurocog.lrdc.pitt.edu@munnari.oz.au)
Received: by chao.sw.oz.au (4.1/SMI-4.1)
	id AA14528; Tue, 29 Jun 93 14:13:19 EST
From: jeremy@sw.oz.au (Jeremy Fitzhardinge)
Message-Id: <9306290413.AA14528@chao.sw.oz.au>
Subject: Re: TIGA chip/docs
To: broadley@neurocog.lrdc.pitt.edu (Bill Broadley)
Date: Tue, 29 Jun 1993 14:13:18 +1000 (EST)
Cc: riscy@pyramid.com
In-Reply-To: <9306281614.AA27593@gossip.pyramid.com> from "Bill Broadley" at Jun 28, 93 12:14:16 pm
Organization: Softway Pty Ltd
X-Face: 
	 '6U=%Tv\k1<Ek%ql%PN^v`Db4bakr[v~y]\u7"GbO#I=]N{l1=#P,glz$9q>l-:?\$C[D@G
	 7(vl~w8&y}!f\bh#w<Y*S~bEBTI:s&.QR>L#n,TGKh>T.c7eT5-y)Hl'i;A1z$9?*lD.k}yqshddFb
	 l[EC}c=;uc%x'}uh3E91p&oE<q$w1r&U0yw.Sb3V&uw
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 887       
Status: RO
X-Status: 

Bill Broadley bubbles:

> I havea really cool tiga interface users guide, which seems to be a full
> c library for dos to use the tiga chip (Not sure if source is available).

> Also of interest TMS340 Family code generation tools users guide literature
> number SPVU020.
>         Describes the c compiler, assembler, linker, and archiver for the
> ths340X0 graphics system processors.

> So apparently they already have the c compiler (I think it's free).

> Ti has been very generous with the documentation (we got it free)
> which is a big win.

> I tried to call for prices but I didn't have any parts numbers.

A few years ago, TI were charging A$1-2k for a PC development system
binaries.  It was pretty bad, so a friend of mind wrote a C compiler,
assembler and linker for the 34k.  If necessary I can ask him if
we can have at least binary distribution for linux for ~free.

	J

 
From Steven.D.Ligett@Dartmouth.EDU  Ukn Jun 29 14:02:09 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA29154; Tue, 29 Jun 93 14:02:07 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06782; Tue, 29 Jun 93 10:57:31 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA17399; Tue, 29 Jun 93 10:57:07 -0700
Received: from dartvax.dartmouth.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06457; Tue, 29 Jun 93 10:56:57 -0700
Received: from prancer.dartmouth.edu by dartvax.dartmouth.edu (5.65+D5/4.5HUB)
	id AA18372; Tue, 29 Jun 93 13:55:39 -0400
Message-Id: <5303644@prancer.Dartmouth.EDU>
Date: 29 Jun 93 13:55:35 EDT
From: Steven.D.Ligett@Dartmouth.EDU (Steven D. Ligett)
Subject: simple ISA question
To: riscy@pyramid.com
Status: RO
X-Status: 

All these ISA boards everyone has -- are they 16 or 8 bit?  Doing the little
8-bit bus would be simpler.

I had this idea of doing a simple 16-bit 3051 I/O bus, with a daughterboard
that converted to ISA for those who want it.  The ISA cards would plug in
sideways.  Several computers do such a thing.  Getting a box with sideways
cutouts would then be the hard task!

 
From Steven.D.Ligett@Dartmouth.EDU  Ukn Jun 29 14:22:13 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA00757; Tue, 29 Jun 93 14:22:07 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA14219; Tue, 29 Jun 93 11:17:47 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA19499; Tue, 29 Jun 93 11:17:43 -0700
Received: from dartvax.dartmouth.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA14215; Tue, 29 Jun 93 11:17:31 -0700
Received: from prancer.dartmouth.edu by dartvax.dartmouth.edu (5.65+D5/4.5HUB)
	id AA19814; Tue, 29 Jun 93 14:16:09 -0400
Message-Id: <5304101@prancer.Dartmouth.EDU>
Date: 29 Jun 93 14:16:03 EDT
From: Steven.D.Ligett@Dartmouth.EDU (Steven D. Ligett)
Subject: Re: Radical video idea
To: riscy@pyramid.com
Status: RO
X-Status: 

First -- there are too many ideas zooming by for me to sort through them all. 
For now, I'll concentrate on video.  Other facets later.

I think that the idea of having a 3041 generate the video syncs IS too
radical, but is the kind of thinking needed to come up with clever designs. 
Let me expand a little on the video system I was thinking about.  Here is the
list of parts needed for the video system:

2 Mac-compatible 512K VRAM SIMMS  $30/ea
1 TI tlc34076 RAMDAC              $32/ea
1 NSC LM1882 Video sync generator  $8/ea
                                 ----
total                            $100

VRAM appears to the processor as DRAM.  No differences, really.  However, you
can't easily find 60 ns VRAM, and I can get 8MB 60 ns DRAM SIMMs for <$300
any day of the week.  Which is a long way of saying that the VRAM bank(s)
will have different timing from the DRAM bank(s).

The 34076 handles 1, 2, 4, 8, 16, and 24 bits per pixel.  1, 2, 4, and 8 are
translated by a table into 24-bit pixels.  The 34076 completely handles the
serial (video) side of the VRAMs, having only to be set up once to tell it
exactly what to do.  The 34076 does not generate hsync, vsync, blank.

The 1882 generates hsync, vsync, and blank.  Just tell it once what the
timing is to be.

Once the registers in the 34076 and 1882 are set up, the processor(s) just
read and write the VRAM.

For rock-steady video, drive it from a crystal oscillator.  I expect that
there will be a 80 mhz oscillator on the board, so use that.  Giving 1024 x
768 pixels at 72 fps.  Leave space at the 34076 for other oscillators so
folks can use other resolutions - the 34076 can handle 5.

 
From rohrer@fncrd8.fnal.gov  Ukn Jun 29 14:41:22 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA02323; Tue, 29 Jun 93 14:41:20 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18493; Tue, 29 Jun 93 11:36:35 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA22405; Tue, 29 Jun 93 11:36:39 -0700
Received: from fngate.fnal.gov 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18016; Tue, 29 Jun 93 11:35:52 -0700
Received: by fngate.fnal.gov (5.57/Ultrix3.0-C)
	id AA03742; Tue, 29 Jun 93 13:34:32 -0500
Received: by fncrdh.fnal.gov (920330.SGI/890607.SGI)
	(for ) id AA22839; Tue, 29 Jun 93 13:33:38 -0500
From: rohrer@fncrd8.fnal.gov (Keith Rohrer)
Message-Id: <9306291833.AA22839@fncrdh.fnal.gov>
Subject: Re: simple ISA question
To: Steven.D.Ligett@dartmouth.edu (Steven D. Ligett)
Date: Tue, 29 Jun 1993 13:33:37 -0600 (CDT)
Cc: riscy@pyramid.com
In-Reply-To: <5303644@prancer.Dartmouth.EDU> from "Steven D. Ligett" at Jun 29, 93 01:55:35 pm
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 802       
Status: RO
X-Status: 

> All these ISA boards everyone has -- are they 16 or 8 bit?  Doing the little
> 8-bit bus would be simpler.
Well, then you'll need to put IDE on the motherboard.
 
> I had this idea of doing a simple 16-bit 3051 I/O bus, with a daughterboard
> that converted to ISA for those who want it.  The ISA cards would plug in
> sideways.  Several computers do such a thing.  Getting a box with sideways
> cutouts would then be the hard task!
Yup, there goes the standard PC case, so anyone who wants to use their PC
components has to pay another $100 for a non-PC case.  This just sounds
outright dumb.  And knowing how reluctant some ISA cards have been to seat
themselves properly, I see lots of breakage on the edge connector between
the motherboard and the ISA card.  Lots and lots of breakage.

	Keith 



 
From caret@pyramid.com  Ukn Jun 29 16:23:35 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA09241; Tue, 29 Jun 93 16:23:33 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA19139; Tue, 29 Jun 93 13:18:59 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06047; Tue, 29 Jun 93 13:17:44 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306292017.AA06047@sword.eng.pyramid.com>
Subject: Chips & Tech 82C512
To: riscy@pyramid.com
Date: Tue, 29 Jun 93 13:17:43 PDT
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

Chips & Tech never went to production with this guy.  It is no longer
a product.  I've asked the sales person to send info on what they have
that may be useful.  Back to the IDT3730...

-- 
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 caret@pyramid.com  Ukn Jun 29 16:31:02 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA09678; Tue, 29 Jun 93 16:31:00 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21495; Tue, 29 Jun 93 13:24:30 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06863; Tue, 29 Jun 93 13:24:34 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306292024.AA06863@sword.eng.pyramid.com>
Subject: Aproximate quote for the board
To: riscy@pyramid.com
Date: Tue, 29 Jun 93 13:24:34 PDT
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

I got Paragon (a printed circuit board manufacturer) to give me a
rough quote on a board.  I told them 12x16 inches and 2000 holes.
They told me $95 each.  Their prices seem fairly typical of Silicon
Valley as far as I can tell.  In the quantities that we are talking
about, I'd probably use them.
-- 
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 SMACKINLA@cc.curtin.edu.au  Ukn Jun 30 11:50:01 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA03205; Wed, 30 Jun 93 11:49:45 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16972; Wed, 30 Jun 93 08:47:33 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA28072; Wed, 30 Jun 93 08:46:37 -0700
Received: from cc.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16467; Wed, 30 Jun 93 08:46:19 -0700
Received: from cc.curtin.edu.au by cc.curtin.edu.au (PMDF #3256 ) id
 <01H00A83NWNMFUMLVJ@cc.curtin.edu.au>; Wed, 30 Jun 1993 23:45:49 +0800
Date: 30 Jun 1993 23:45:49 +0800
From: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Subject: Test?
To: riscy@pyramid.com
Message-Id: <01H00A83NWNOFUMLVJ@cc.curtin.edu.au>
X-Envelope-To: riscy@pyramid.com
X-Vms-To: R3KPC
X-Vms-Cc: SMACKINLA
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
Status: RO
X-Status: 


Just testing - no mail seems to have come through since early this morning 
here (GMT+8).

ObJoke: What's DNA stand for?
	National Dyslexics Association.

<hehehe>

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 caret@pyramid.com  Ukn Jun 30 18:14:48 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA24707; Wed, 30 Jun 93 18:14:46 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20424; Wed, 30 Jun 93 15:12:50 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA09340; Wed, 30 Jun 93 15:12:06 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306302212.AA09340@sword.eng.pyramid.com>
Subject: Test message - please ignore
To: riscy@pyramid.com
Date: Wed, 30 Jun 93 15:12:06 PDT
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

Someone says that they can't get though.  Lets see if they are right...
-- 
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 mackinla@cs.curtin.edu.au  Ukn Jun 24 22:40:28 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA21262; Thu, 24 Jun 93 22:40:23 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA27983; Thu, 24 Jun 93 19:32:48 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA24959; Thu, 24 Jun 93 19:32:45 -0700
Received: from marsh.cs.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA27873; Thu, 24 Jun 93 19:32:34 -0700
Received: from vincent.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA20096
  (5.67a/IDA-1.4.4 for <riscy@pyramid.com>); Fri, 25 Jun 1993 10:30:57 +0800
Received: by vincent.cs.curtin.edu.au id AA24202
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Fri, 25 Jun 1993 10:30:49 +0800
From: Patrick Mackinlay <mackinla@cs.curtin.edu.au>
Message-Id: <199306250230.AA24202@vincent.cs.curtin.edu.au>
Subject: SPIM...
To: riscy@pyramid.com (R3000 PC Mailing List)
Date: Fri, 25 Jun 1993 10:30:48 +0800 (WST)
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1351      
Status: RO
X-Status: 


I just thought I'd let everyone know about a software tool that could
come in extremely handy during initial development. The program is
called spim (or xspim) and is a MIPS R3k CPU simulator. The program
compiles under Linux with a bit of fiddling, and seems to perform
pretty well.

There are a couple of different versions of the program in the source
distribution:

	spim: assembly-level simulator (text mode)
	xspim: assembly-level simulator (runs under X)
	cl-spim: cycle-level simulator (text mode)
	cl-xspim: cycle-level simulator (runs under X)

I haven't looked at either of the cycle-level simulators yet, but I'd
have to assume they worked ok. There are a few BSDisms in the code that
can be fixed by modifying some #include <whatever.h> to the appropriate
#include <bsd/whatever.h> and by linking with -lbsd.

I don't actually remember where the source is archived, but I think
archie can find it ok. If there's a need for it, I guess I can put
my binaries up somewhere, but I hope we're all capable of "compiling
our own" <grin>. I probably will put the patches I did up somewhere
when I get around to it.

Anyhow, I think it could be quite a useful tool...

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 kilroy@ms.uky.edu  Ukn Jun 30 19:53:56 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA27900; Wed, 30 Jun 93 19:53:54 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06767; Wed, 30 Jun 93 16:52:01 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA00915; Wed, 30 Jun 93 16:51:41 -0700
Received: from mozart.ms.uky.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06727; Wed, 30 Jun 93 16:51:40 -0700
Received: from s.ms.uky.edu by mozart.ms.uky.edu id aa19885; 30 Jun 93 19:18 EDT
From: Paul Kilroy <kilroy@ms.uky.edu>
Date: Wed, 30 Jun 1993 19:18:04 EDT
X-Mailer: Mail User's Shell (7.1.2 7/11/90)
To: riscy@pyramid.com
Subject: call for documentation
Message-Id:  <9306302318.aa08025@s.s.ms.uky.edu>
Status: RO
X-Status: 

Hi all,

	I think it would be cool to spread around the information 
    about the mips chip, and relavent other information such
    as similar architectures. (book titles and articles too).
	Also, I maintain an ftp site for linux. (f.ms.uky.edu
    in /pub3/linux/) and could archive parts of this list if
    people are interested.


paul


-- 
                       -Paul   (kilroy@ms.uky.edu)

 
From caret@pyramid.com  Ukn Jun 30 19:57:41 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA27959; Wed, 30 Jun 93 19:57:39 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA07114; Wed, 30 Jun 93 16:55:50 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA01499; Wed, 30 Jun 93 16:55:44 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306302355.AA01499@sword.eng.pyramid.com>
Subject: Short delay
To: riscy@pyramid.com
Date: Wed, 30 Jun 93 16:55:44 PDT
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

I have become swamped with work, and since they are paying me for
it I feel a little obligated to get some of it done.  As a result
I have not being paying as much attention to the project that it
needs.  I will get back to this in a few days.

Sorry guys.
-- 
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 calica@cae.wisc.edu  Ukn Jun 29 01:31:21 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA28017; Tue, 29 Jun 93 01:31:20 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05197; Mon, 28 Jun 93 22:29:13 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA19344; Mon, 28 Jun 93 22:28:43 -0700
Received: from serv0.cae.wisc.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05072; Mon, 28 Jun 93 22:28:38 -0700
Received: from hprisc-25.cae.wisc.edu by serv0.cae.wisc.edu (4.1/25)
	id AA09441; Tue, 29 Jun 93 00:27:20 CDT
Received: by hprisc-25.cae.wisc.edu (16.8/client-1.3)
	id AA15210; Tue, 29 Jun 93 00:29:58 -0500
From: Carlo J. Calica <calica@cae.wisc.edu>
Message-Id: <9306290529.AA15210@hprisc-25.cae.wisc.edu>
Subject: Sound, IDE drives, and ISA slots
To: riscy@pyramid.com
Date: Tue, 29 Jun 93 0:29:58 CDT
Mailer: Elm [revision: 66.36.1.2]
Status: RO
X-Status: 

First off sound.  I really wonder is putting a real DAC is more expensive
than a resistor network.  Especially if performance is taken into acct.

IDE drive support would be great.  I have yet to make the switch to SCSI.
Having both would be a great advantage.  If possible support IDE.

ISA is a must.  Allows the stringing of more serial ports and such.
Without expandability the system is fixed and could quickly become
obsolete.

--
 /------------------------------+--------------------------------------\
| Carlo J. Calica               | Linux:  Choice of the GNU Generation  |
|     calica@cae.wisc.edu       | Dittos from the People's              | 
 \ University of Wisconsin      | Republic of Madison                  / 

 
From broadley@neurocog.lrdc.pitt.edu  Ukn Jun 30 22:41:30 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA01832; Wed, 30 Jun 93 22:41:27 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA27221; Wed, 30 Jun 93 19:36:47 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA18163; Wed, 30 Jun 93 19:36:41 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA27217; Wed, 30 Jun 93 19:36:41 -0700
Message-Id: <9307010236.AA27217@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA14680; Wed, 30 Jun 93 22:36:09 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Last message (mail server)
To: riscy@pyramid.com
Date: Wed, 30 Jun 1993 22:36:09 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 336       
Status: RO
X-Status: 

Ooops, not awake yet......

That last message  was to go to Neil who had mentioned he has to 
handsubscribe people....

Sorry.
-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok


 
From broadley@neurocog.lrdc.pitt.edu  Ukn Jun 30 22:41:42 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA01836; Wed, 30 Jun 93 22:41:34 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA25980; Wed, 30 Jun 93 19:34:23 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA17695; Wed, 30 Jun 93 19:33:48 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA25973; Wed, 30 Jun 93 19:33:36 -0700
Message-Id: <9307010233.AA25973@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA14672; Wed, 30 Jun 93 22:33:09 -0400
Date: Wed, 30 Jun 93 22:33:09 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
To: riscy@pyramid.com
Subject: (fwd) MailServ 1.1.0
Newsgroups: alt.sources
Organization: Learning Research and Development Center at University of Pittsburgh
Status: RO
X-Status: 



FYI, get lots of work done.  The mailing list we be there on your return ;-)

Version 1.1.0 -- Changes
Wed Jun 30 15:03:04 MDT 1993

- Now checks for relevant info in Info file.  If anything is missing
	that it needs, it announces it (to stderr and the logfile, if
	possible) and dies.  This fixes most of the segfault problems.
- Fixed a couple of memory allocation bugs in utils.c and info.c.
- Made the "usage" function a little more helpful.
- Tracked down a couple of other segfault bugs.

----------------------------------------------------------------------

	MailServ  --  by Dave DeBry <debry@peruvian.cs.utah.edu>
	Version 1.1.0

	A mailing list, mail request server, digest server, etc., all
in one tiny little program.  Wheee!

----------------------------------------------------------------------

	This is a mailing list program that I wrote, because I wasn't
to excited about all the other packages that I found floating on the
net.  I'm currently using it to run two digests, five self-running
reflector mailing lists, and two invitation-only mailing lists
(there's no request address for those, they're private).

	MailServ:

	o allows for as many users as you want per list,

	o users can be mailed to "quietly" (ie: their name won't
		be found anywhere in the mailing... good for 
		nosy sysadmins at other sites),

	o has a request server so users can get any files you make
		available for them,

	o handles subscribes and unsubscribes without bothering you,

	o can archive off reflector mailing list posts,

	o can announce to all list readers when someone subscribes
		or unsubscribes,

	o can be set to let people request a list of readers,

	o does all the digest handling work for you,

	o can upload (via ftp) each days digest to a given site for
		archiving,

	o can backup the userlist to a different disk/area/whatever,

	o can post a FAQ to USENET periodically,

	o announces when a message has been taken from USENET, so
		people don't get that horrible deja vu feeling
		while reading their mail,

	o sends you a log of all the day's activities every night,

	o lets you toggle all of these things for complete 
		customization,

	o and much, much more!  (I should be an announcer for those
		Remco ads, I know it.)

----------------------------------------------------------------------

	MailServ isn't for the weak at heart.  It's not pretty, and
I'm releasing it to the net because several people have asked for
copies, and I'd like to know what changes are made to it.  If you
don't know much about UNIX or mail, I wouldn't suggest using MailServ
until it gets a little bit nicer.

----------------------------------------------------------------------

	A lot of the digest code was vulture coded from David A.
Curry's (davy@intrepid.ecn.purdue.edu) digest program.  I've included
his code in here as well so you can put back in the stuff that I've
ripped out if you wish.

----------------------------------------------------------------------

	Feel free to distribute and edit this code as you want.  My
only requests are:

	1] Keep my name and Mr. Curry's name intact -- credit where
credit is due, and all that jazz.

	2] Let me know of any modifications you make.  Chances are
I'll want to incorporate them into my working copy.  Not only that,
but it would be nice if we had one "real" version of the program out
there that people could grab.

----------------------------------------------------------------------

	I don't guarantee anything about this code.  I've only truly
tested it well on a MIPS based box.  However, it builds well under
GCC, and executes only the most standard of UNIX programs (cp, rm,
sendmail, etc.).  It should be fine, but don't blame me for any
problems.  (That should be enough disclaimer to ward off the lawyers,
don't you think?)

#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#		"End of shell archive."
# Contents:  MailServ MailServ/Changes MailServ/InfoDir
#   MailServ/Install MailServ/Readme MailServ/aliases MailServ/backup
#   MailServ/bin MailServ/crontab MailServ/fakedigest
#   MailServ/fakelist MailServ/src MailServ/backup/fakedigest
#   MailServ/backup/fakelist MailServ/bin/GenInfo MailServ/bin/fndusr
#   MailServ/bin/nightly MailServ/bin/rarely MailServ/fakedigest/Info
#   MailServ/fakedigest/counter MailServ/fakedigest/files
#   MailServ/fakedigest/head MailServ/fakedigest/help
#   MailServ/fakedigest/index MailServ/fakedigest/input
#   MailServ/fakedigest/netrc MailServ/fakedigest/nounsub
#   MailServ/fakedigest/output MailServ/fakedigest/sub
#   MailServ/fakedigest/tail MailServ/fakedigest/unsub
#   MailServ/fakedigest/users MailServ/fakelist/Info
#   MailServ/fakelist/archive MailServ/fakelist/help
#   MailServ/fakelist/nounsub MailServ/fakelist/sub
#   MailServ/fakelist/unsub MailServ/fakelist/users
#   MailServ/src/Makefile MailServ/src/digest.c MailServ/src/info.c
#   MailServ/src/inmsg.c MailServ/src/mailserv.c
#   MailServ/src/mailserv.h MailServ/src/orig-dig
#   MailServ/src/outmsg.c MailServ/src/request.c MailServ/src/utils.c
#   MailServ/fakedigest/files/UNDIGEST.C
#   MailServ/src/orig-dig/Makefile MailServ/src/orig-dig/digest.c
#   MailServ/src/orig-dig/undigest.c
# Wrapped by ddebry@ren on Wed Jun 30 15:52:49 1993
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test ! -d 'MailServ' ; then
    echo shar: Creating directory \"'MailServ'\"
    mkdir 'MailServ'
fi
if test -f 'MailServ/Changes' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/Changes'\"
else
echo shar: Extracting \"'MailServ/Changes'\" \(405 characters\)
sed "s/^X//" >'MailServ/Changes' <<'END_OF_FILE'
XVersion 1.1.0
XWed Jun 30 15:03:04 MDT 1993
X
X- Now checks for relevant info in Info file.  If anything is missing
X	that it needs, it announces it (to stderr and the logfile, if
X	possible) and dies.  This fixes most of the segfault problems.
X- Fixed a couple of memory allocation bugs in utils.c and info.c.
X- Made the "usage" function a little more helpful.
X- Tracked down a couple of other segfault bugs.
END_OF_FILE
if test 405 -ne `wc -c <'MailServ/Changes'`; then
    echo shar: \"'MailServ/Changes'\" unpacked with wrong size!
fi
# end of 'MailServ/Changes'
fi
if test -f 'MailServ/InfoDir' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/InfoDir'\"
else
echo shar: Extracting \"'MailServ/InfoDir'\" \(4163 characters\)
sed "s/^X//" >'MailServ/InfoDir' <<'END_OF_FILE'
XHere's a rundown of the elements of the Info file:
X
Xerrorsto	Where the mail bounces will go to. (1)
Xreplyto		Where user replies will go to. (1)
Xuserfile	List of users.  (3)
Xlogfile		Log file, cleared daily. (2)
Xdelay		Delay between messagesm in seconds.  Even on very
X		fast machines, it's easy to overload them with mail
X		(especially if you've got a slower link to the net).
X		I'd suggest *at least* a 5 second delay.  8-10 is
X		probably optimal.
Xfrom		Address for the request line.  Also will be on the
X		"From" line for messages.
Xsubscribefile	The file that users will be sent when they subscribe. (2) 
Xunsubscribefile	The file that users will be sent when they 
X		unsubscribe. (2)
Xnounsubfile	The file that users will be sent when they can't be
X		unsubscribed. (2)
Xhelpfile	The file that users will be sent when MailServ can't
X		figure out what they want. (2)
Xfiles		Set if you have files that can be requested. (4)
Xindexfile	Index file for requestable files.  Will not be mailed
X		out, for MailServ use only. (2)
Xkeep		Set if you want reflector posts archived. (4)
Xarchivefile	File where reflector posts will be archived. (2)
Xannounce	Set if you want all users told when someone subscribes
X		or unsubscribes. (4)
Xdigest		Set if this list is a digest (as opposed to a
X		reflector).  (4)
Xdigestinput	File where input to digest will go.  (2)
Xdigestoutput	File for latest digest. (2)
Xdigestcounterfile	File to keep track of which issue and volume
X			of digest you are on.  On the first day of
X			every month, MailServ will increment the
X			volume counter and set the issue counter
X			back to 1.  (Unlike Mr. Curry's version
X			of 'digest', the counter sets the issue
X			to be tomorrow's digest number, instead
X			of yesterday's.  That way, restarting a
X			digest means setting the issue to 1, not
X			0). (2)
Xdigestname	Name of the digest.
Xdigesthead	File to be prepended to the digest. (2)
Xdigesttail	File to be appended to the digest. (2)
Xftp		Set if the digest is to be uploaded to an ftp site.
Xftpdir		Directory on the ftp site where the digest should go.
X		MailServ will go to that directory and write to the
X		file 'vol-X/Y', where X is the volume number and Y
X		is the issue number.  It will then ALSO write the same
X		digest into the file 'daily'.  That way people can 
X		always download the latest issue with ease.
Xftpsite		Site to ftp to.
Xnetrcfile	A netrc file.  Must be read/writeable ONLY by mailserv.
X		Put the account name and password of the account to
X		ftp to on ftpsite here.  This file will be copied to
X		~MailServ/.netrc when the ftp is started.  As soon as
X		it is over, ~MailServ/.netrc will be deleted.  It will
X		only work if the permissions are correct.  For the
X		netrc format, see the man page on ftp. (2)
Xbackup		Set if you want your userlist backed up somewhere. (4)
Xbackupdir	Directory to back up the userlist to.  MailServ will
X		keep the past 7 days worth of backups in this directory.
X		The name of the files will be the date of the backup. 
X		I currently have this pointing to ~MailServ/backup/list,
X		but if you want it to do any good I'd suggest pointing
X		it to a different physical disk.  (2)
Xfaq		Set if the list has a FAQ that is to be posted to 
X		USENET. (4)
Xfaqfile		The FAQ in question.  All the USENET headers must already
X		be in place in this file. (2)
X
X	Here's what the footnotes mean:
X
X	(1) This is a mail address.  Treat it as such.
X
X	(2) This is a file or directory.  If the file doesn't start
Xwith '/' or '.', then MailServ will assume that you mean
X'~Mailserv/*list*/*file*', where *list* is the name of the list (like
Xfakelist or fakedigest), and *file* is the string you have entered.
X
X	(3) This is a userlist.  One address to a line, one line to
Xan address.  If you start a line with an asterisk ("*"), then that
Xuser will be mailed to "quietly".  This means that their name will not
Xbe found anywhere in the mailing.
X
X	(4) This is a boolean variable.  Proper settings are "yes" and
X"no".
X
X	Any line starting with a "#" will be considered a comment and
Xignored.  This goes for any file MailServ reads as a data file
X(userlist, indexlist, Info, etc.), but not files that are going to be
Xmailed to a user.
END_OF_FILE
if test 4163 -ne `wc -c <'MailServ/InfoDir'`; then
    echo shar: \"'MailServ/InfoDir'\" unpacked with wrong size!
fi
# end of 'MailServ/InfoDir'
fi
if test -f 'MailServ/Install' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/Install'\"
else
echo shar: Extracting \"'MailServ/Install'\" \(5447 characters\)
sed "s/^X//" >'MailServ/Install' <<'END_OF_FILE'
X
X	First priority is to get an account for this program.  Yes,
XMailServ needs its own account and directory.  I'm assuming the
Xusername is 'mailserv', and the directory is '/usr/people/MailServ'.
XYou're also going to need to edit the /usr/lib/aliases (or
X/etc/aliases, depending on your system), so if you don't have root
Xaccess, or a good friend with root access, you're probably out of
Xluck.
X
X	Anyway, the account.  Go make it.  Now, unshar or untar this
Xpackage into that area.  (Do it from /usr/people, the package assumes
Xdirectory 'MailServ' is in the current working directory.)  Now become
Xmailserv.
X
X	Make a .forward file, and point it to YOUR account.  Not
Xmailserv (we don't want mail loops), YOU.  In real life.
X
X	Now go into the src directory.  With that in mind, edit the
Xmailserv.h file to fit your system.  As you add new lists, you
Xshouldn't have to rebuild the program; there are no references to the
Xlists in the executable.  Go ahead and 'make' it.
X
X	Ok, that's done.  Now you'll want to create your lists.  I've
Xmade a couple of demo lists: fakelist and fakedigest.  Follow the lead
Xof the files in there.  Most important is the Info file.  THIS FILE
XMUST BE THERE.  There's a list of elements for the Info file in a file
Xcalled "InfoDir" which you should have received with this release.
X
X	Now edit the ~MailServ/aliases file to reflect your new list.
XExamples of how to do this are already in the file.  NOTE:  There is a
X"notreal" alias in the file.  LEAVE IT THERE.  This must be there for
Xquiet mailing to work correctly.
X
X	Edit the ~Mailserv/bin/GenInfo file to show what lists exist,
Xwhere they are, etc.  GenInfo and aliases are the only files to need
Xto edit when you add or remove lists (besides the list's files, of
Xcourse).
X
X	Using your root powers, insert the ~MailServ/aliases file into
Xthe /usr/lib/aliases (or /etc/aliases) file.  Do a 'newaliases' to
Xrebuild the hash table.  You need to do this everytime you edit your
Xaliases file.
X
X	Edit the crontab to set when you want the nightly maintenance
Xand bi-weekly maintenance to occur.  Here's what happens at each time:
X
X	Nightly:
X
X	o Mailserv will sort the userlist and eliminate duplicate
X		entries.	
X	o If the list is supposed to have its userlist backed
X		up, MailServ will do that.
X	o If the list is a digest, MailServ builds the digest,
X		and mails it out to the readers.  It will also
X		upload the digest to an FTP site if necessary.
X	o Mailserv will dump the daily log into a tempfile.  When
X		all the lists have dumped their logs (ewww), Mailserv
X		will mail this meta-log to itself.  Since its forward
X		file is pointing at you, you will get it.
X
X	Biweekly ("rarely"):
X
X	o If your list has a FAQ that is to be posted to USENET,
X		MailServ will do that.
X
X	The crontab is currently set to run nightly maintenance at
X12:07am everyday.  Rare maintenance happens at 12:01am on the 5th and
X20th of every month.
X
X	Make sure you are still using the mailserv account, and do a
X'crontab crontab'.
X
X	The two shell scripts in the bin directory are the ones that
Xare run by the crontab.  I wanted to not use any shell scripts at all,
Xbut then I would have had to let the mailserv program know about every
Xlist, and I didn't want to do that.  Maybe that should change; at
Xleast then you wouldn't need a GenInfo file.  Comments?
X
X	There seems to be a little confusion over where you should
Xtell the users to mail their requests and messages to:
X
X	Requests to a list: listname-request@site
X	Messages to a list: listname@site
X	Human owner of list: listname-owner@site
X
X	There have also been some problems in running the program.
XThe correct way to run mailserv (as now explained if you do it wrong)
Xis like this:
X
X% mailserv listname command < mailfile
X
X	Where...
X
X	- "listname" is the name of the directory in the ~Mailserv
Xarea of a given list.  With the example lists, this would either be
Xfakedigest or fakelist.
X
X	- "command" tells mailserv what kind of a message is coming
Xin, and what you want to do with it.  Generally, "request" should only
Xbe used on request addresses, "message" should only be used on normal
Xaddresses, and "nightly" and "rare" should only be run by cron.
XHere's the list of commands:
X		request         mail from request address
X		message         mail from message address
X		nightly         do nightly maintenance
X		rare            do infrequent maintenance
X
X	- "mailfile" is the mail that mailserv is to process.
XObviously, this can be done like this as well:
X
X	% cat mailfile | mailserv listname command
X
X	In fact, that's how you *have* to do it in the aliases file.	
X
X	One last thing: MAKE SURE EVERY FILE (except the netrc files)
XAND DIRECTORY IN THE MailServ DIRECTORY IS READABLE AND WRITABLE BY
XEVERYONE!!!  This is *very* important.  When the aliases file invokes
Xthe 'mailserv' program, it won't run it as mailserv.  It will run it
Xas a user named 'halt', probably.  (Hmm... maybe we should setuid the
Xmailserv program... comments?)
X
X	BTW:  The fndusr program in the bin directory is very helpful
Xwhen you are running a lot of lists, and you have the same people on
Xmultiple lists.  It will list all the lists that a given user is on.
XMake the string it's searching for long enough that it doesn't throw
Xfits, though.  For instance:
X
XThis is good:
X% fndusr debry
X
XThis is not:
X% fndusr edu
X
X	That should do it.  Enjoy... I hope this program doesn't give
Xyou too many headaches.
X
X					- Dave DeBry
X					  debry@peruvian.cs.utah.edu
END_OF_FILE
if test 5447 -ne `wc -c <'MailServ/Install'`; then
    echo shar: \"'MailServ/Install'\" unpacked with wrong size!
fi
# end of 'MailServ/Install'
fi
if test -f 'MailServ/Readme' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/Readme'\"
else
echo shar: Extracting \"'MailServ/Readme'\" \(3248 characters\)
sed "s/^X//" >'MailServ/Readme' <<'END_OF_FILE'
X
X	MailServ  --  by Dave DeBry <debry@peruvian.cs.utah.edu>
X	Version 1.1.0
X
X	A mailing list, mail request server, digest server, etc., all
Xin one tiny little program.  Wheee!
X
X----------------------------------------------------------------------
X
X	This is a mailing list program that I wrote, because I wasn't
Xto excited about all the other packages that I found floating on the
Xnet.  I'm currently using it to run two digests, five self-running
Xreflector mailing lists, and two invitation-only mailing lists
X(there's no request address for those, they're private).
X
X	MailServ:
X
X	o allows for as many users as you want per list,
X
X	o users can be mailed to "quietly" (ie: their name won't
X		be found anywhere in the mailing... good for 
X		nosy sysadmins at other sites),
X
X	o has a request server so users can get any files you make
X		available for them,
X
X	o handles subscribes and unsubscribes without bothering you,
X
X	o can archive off reflector mailing list posts,
X
X	o can announce to all list readers when someone subscribes
X		or unsubscribes,
X
X	o can be set to let people request a list of readers,
X
X	o does all the digest handling work for you,
X
X	o can upload (via ftp) each days digest to a given site for
X		archiving,
X
X	o can backup the userlist to a different disk/area/whatever,
X
X	o can post a FAQ to USENET periodically,
X
X	o announces when a message has been taken from USENET, so
X		people don't get that horrible deja vu feeling
X		while reading their mail,
X
X	o sends you a log of all the day's activities every night,
X
X	o lets you toggle all of these things for complete 
X		customization,
X
X	o and much, much more!  (I should be an announcer for those
X		Remco ads, I know it.)
X
X----------------------------------------------------------------------
X
X	MailServ isn't for the weak at heart.  It's not pretty, and
XI'm releasing it to the net because several people have asked for
Xcopies, and I'd like to know what changes are made to it.  If you
Xdon't know much about UNIX or mail, I wouldn't suggest using MailServ
Xuntil it gets a little bit nicer.
X
X----------------------------------------------------------------------
X
X	A lot of the digest code was vulture coded from David A.
XCurry's (davy@intrepid.ecn.purdue.edu) digest program.  I've included
Xhis code in here as well so you can put back in the stuff that I've
Xripped out if you wish.
X
X----------------------------------------------------------------------
X
X	Feel free to distribute and edit this code as you want.  My
Xonly requests are:
X
X	1] Keep my name and Mr. Curry's name intact -- credit where
Xcredit is due, and all that jazz.
X
X	2] Let me know of any modifications you make.  Chances are
XI'll want to incorporate them into my working copy.  Not only that,
Xbut it would be nice if we had one "real" version of the program out
Xthere that people could grab.
X
X----------------------------------------------------------------------
X
X	I don't guarantee anything about this code.  I've only truly
Xtested it well on a MIPS based box.  However, it builds well under
XGCC, and executes only the most standard of UNIX programs (cp, rm,
Xsendmail, etc.).  It should be fine, but don't blame me for any
Xproblems.  (That should be enough disclaimer to ward off the lawyers,
Xdon't you think?)
X
END_OF_FILE
if test 3248 -ne `wc -c <'MailServ/Readme'`; then
    echo shar: \"'MailServ/Readme'\" unpacked with wrong size!
fi
# end of 'MailServ/Readme'
fi
if test -f 'MailServ/aliases' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/aliases'\"
else
echo shar: Extracting \"'MailServ/aliases'\" \(367 characters\)
sed "s/^X//" >'MailServ/aliases' <<'END_OF_FILE'
Xnotreal: "| cat > /dev/null"
X
Xfakelist: "| /usr/people/MailServ/bin/mailserv fakelist message"
Xfakelist-request: "| /usr/people/MailServ/bin/mailserv fakelist request"
Xfakelist-owner: mailserv
X
Xfakedigest: "| /usr/people/MailServ/bin/mailserv fakedigest message"
Xfakedigest-request: "| /usr/people/MailServ/bin/mailserv fakedigest request"
Xfakedigest-owner: mailserv
END_OF_FILE
if test 367 -ne `wc -c <'MailServ/aliases'`; then
    echo shar: \"'MailServ/aliases'\" unpacked with wrong size!
fi
# end of 'MailServ/aliases'
fi
if test ! -d 'MailServ/backup' ; then
    echo shar: Creating directory \"'MailServ/backup'\"
    mkdir 'MailServ/backup'
fi
if test ! -d 'MailServ/bin' ; then
    echo shar: Creating directory \"'MailServ/bin'\"
    mkdir 'MailServ/bin'
fi
if test -f 'MailServ/crontab' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/crontab'\"
else
echo shar: Extracting \"'MailServ/crontab'\" \(88 characters\)
sed "s/^X//" >'MailServ/crontab' <<'END_OF_FILE'
X7 0 * * * /usr/people/MailServ/bin/nightly
X1 0 5,20 * * /usr/people/MailServ/bin/rarely
END_OF_FILE
if test 88 -ne `wc -c <'MailServ/crontab'`; then
    echo shar: \"'MailServ/crontab'\" unpacked with wrong size!
fi
# end of 'MailServ/crontab'
fi
if test ! -d 'MailServ/fakedigest' ; then
    echo shar: Creating directory \"'MailServ/fakedigest'\"
    mkdir 'MailServ/fakedigest'
fi
if test ! -d 'MailServ/fakelist' ; then
    echo shar: Creating directory \"'MailServ/fakelist'\"
    mkdir 'MailServ/fakelist'
fi
if test ! -d 'MailServ/src' ; then
    echo shar: Creating directory \"'MailServ/src'\"
    mkdir 'MailServ/src'
fi
if test ! -d 'MailServ/backup/fakedigest' ; then
    echo shar: Creating directory \"'MailServ/backup/fakedigest'\"
    mkdir 'MailServ/backup/fakedigest'
fi
if test ! -d 'MailServ/backup/fakelist' ; then
    echo shar: Creating directory \"'MailServ/backup/fakelist'\"
    mkdir 'MailServ/backup/fakelist'
fi
if test -f 'MailServ/bin/GenInfo' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/bin/GenInfo'\"
else
echo shar: Extracting \"'MailServ/bin/GenInfo'\" \(153 characters\)
sed "s/^X//" >'MailServ/bin/GenInfo' <<'END_OF_FILE'
X
Xset lhome = /usr/people/MailServ
Xset path = ( $lhome/bin /usr/ucb /bin /usr/lib /usr/new /usr/local/bin )
X
Xumask 000
X
Xset lists = "fakedigest fakelist"
END_OF_FILE
if test 153 -ne `wc -c <'MailServ/bin/GenInfo'`; then
    echo shar: \"'MailServ/bin/GenInfo'\" unpacked with wrong size!
fi
# end of 'MailServ/bin/GenInfo'
fi
if test -f 'MailServ/bin/fndusr' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/bin/fndusr'\"
else
echo shar: Extracting \"'MailServ/bin/fndusr'\" \(280 characters\)
sed "s/^X//" >'MailServ/bin/fndusr' <<'END_OF_FILE'
X#!/bin/csh
X
Xsource ~mailserv/bin/GenInfo
X
Xforeach h ($lists)
X	set file = `grep userfile $lhome/$h/Info | awk '{print $3}'`
X	set foo = `grep -i $argv[1] $lhome/$h/$file`
X	if ("$foo" != "") then
X		echo "*** $h : $file ***"
X		grep -n -i $argv[1] $lhome/$h/$file
X		echo ""
X	endif
Xend
END_OF_FILE
if test 280 -ne `wc -c <'MailServ/bin/fndusr'`; then
    echo shar: \"'MailServ/bin/fndusr'\" unpacked with wrong size!
fi
chmod +x 'MailServ/bin/fndusr'
# end of 'MailServ/bin/fndusr'
fi
if test -f 'MailServ/bin/nightly' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/bin/nightly'\"
else
echo shar: Extracting \"'MailServ/bin/nightly'\" \(191 characters\)
sed "s/^X//" >'MailServ/bin/nightly' <<'END_OF_FILE'
X#!/bin/csh -f
X
Xsource ~mailserv/bin/GenInfo
X
Xforeach h ($lists)
X	mailserv $h nightly >> /tmp/daily.log
Xend
X
Xcat /tmp/daily.log | mail -s "Mail Server Daily Log" mailserv
Xrm -f /tmp/daily.log
END_OF_FILE
if test 191 -ne `wc -c <'MailServ/bin/nightly'`; then
    echo shar: \"'MailServ/bin/nightly'\" unpacked with wrong size!
fi
chmod +x 'MailServ/bin/nightly'
# end of 'MailServ/bin/nightly'
fi
if test -f 'MailServ/bin/rarely' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/bin/rarely'\"
else
echo shar: Extracting \"'MailServ/bin/rarely'\" \(86 characters\)
sed "s/^X//" >'MailServ/bin/rarely' <<'END_OF_FILE'
X#!/bin/csh -f
X
Xsource ~mailserv/bin/GenInfo
X
Xforeach h ($lists)
X	mailserv $h rare
Xend
END_OF_FILE
if test 86 -ne `wc -c <'MailServ/bin/rarely'`; then
    echo shar: \"'MailServ/bin/rarely'\" unpacked with wrong size!
fi
chmod +x 'MailServ/bin/rarely'
# end of 'MailServ/bin/rarely'
fi
if test -f 'MailServ/fakedigest/Info' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/fakedigest/Info'\"
else
echo shar: Extracting \"'MailServ/fakedigest/Info'\" \(1952 characters\)
sed "s/^X//" >'MailServ/fakedigest/Info' <<'END_OF_FILE'
X#
X# Addresses for list that MUST be defined.
X#
Xreplyto = fakedigest@fakesite.org (Fake Mailing List)
Xerrorsto = fakedigest-owner@fakesite.org (Fake List Owner)
X
X#
X# Files that MUST be defined for the list.
X#
Xuserfile = users
Xlogfile = log
Xdelay = 8
X
X#
X# Files and addresses that need only be defined if this list has a
X# request line.
X#
Xfrom = fakedigest-request@fakesite.org (Fake List Server)
Xsubscribefile = sub
Xunsubscribefile = unsub
Xnounsubfile = nounsub
Xhelpfile = help
X
X#
X# If the request line allows you to request files, set 'files' to 'yes',
X# otherwise to 'no'.  If 'files' is 'yes', 'indexfile' must be defined.
X# 
Xfiles = yes
Xindexfile = index
X
X#
X# Set 'keep' to 'yes' if you want reflector posts archived, 'no'
X# otherwise.  'archivefile' must be defined if 'keep' is yes.
X#
Xkeep = no
X# archivefile = archive
X
X#
X# Set 'announce' to 'yes' if you want all users notified when someone
X# (un)subscribes.  Otherwise, set it to 'no'.
X#
Xannounce = no
X
X#
X# Set 'digest' to 'yes' if the list is a digest, not a reflector.  All
X# other 'digest*' variables must be defined if 'digest' is set to 'yes'.
X#
Xdigest = yes
Xdigestinput = input
Xdigestoutput = output
Xdigestcounterfile = counter
Xdigestname = Fake List Daily
Xdigesthead = head
Xdigesttail = tail
X
X#
X# If the list is a digest, and you'd like the digest to be FTP'ed to an
X# archive site every night, set 'ftp' to 'yes'.  All 'ftp*' variables
X# and 'netrcfile' must be defined if 'ftp' is 'yes'.
X#
Xftp = yes
Xftpdir = /pub/fakedigest/digest
Xftpsite = ftp.fakesite.org
Xnetrcfile = netrc
X
X#
X# Set 'backup' to yes if you want the userlist backed up every night to
X# a different area.  7 days worth of backups are kept. 'backupdir' must
X# be defined if 'backup' is set to 'yes'.
X#
Xbackup = yes
Xbackupdir = /usr/people/MailServ/backup/fakedigest
X
X#
X# If there is a FAQ that is to be posted to news, set 'faq' to 'yes'.
X# 'faqfile' must be defined if 'faq' is 'yes'.
X#
Xfaq = no
X# faqfile = files/FAQ
X
END_OF_FILE
if test 1952 -ne `wc -c <'MailServ/fakedigest/Info'`; then
    echo shar: \"'MailServ/fakedigest/Info'\" unpacked with wrong size!
fi
# end of 'MailServ/fakedigest/Info'
fi
if test -f 'MailServ/fakedigest/counter' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/fakedigest/counter'\"
else
echo shar: Extracting \"'MailServ/fakedigest/counter'\" \(4 characters\)
sed "s/^X//" >'MailServ/fakedigest/counter' <<'END_OF_FILE'
X1 1
END_OF_FILE
if test 4 -ne `wc -c <'MailServ/fakedigest/counter'`; then
    echo shar: \"'MailServ/fakedigest/counter'\" unpacked with wrong size!
fi
# end of 'MailServ/fakedigest/counter'
fi
if test ! -d 'MailServ/fakedigest/files' ; then
    echo shar: Creating directory \"'MailServ/fakedigest/files'\"
    mkdir 'MailServ/fakedigest/files'
fi
if test -f 'MailServ/fakedigest/head' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/fakedigest/head'\"
else
echo shar: Extracting \"'MailServ/fakedigest/head'\" \(110 characters\)
sed "s/^X//" >'MailServ/fakedigest/head' <<'END_OF_FILE'
X
X	This file will be inserted at the head of a digest, between
Xthe table of contents and the actual messages.
X
END_OF_FILE
if test 110 -ne `wc -c <'MailServ/fakedigest/head'`; then
    echo shar: \"'MailServ/fakedigest/head'\" unpacked with wrong size!
fi
# end of 'MailServ/fakedigest/head'
fi
if test -f 'MailServ/fakedigest/help' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/fakedigest/help'\"
else
echo shar: Extracting \"'MailServ/fakedigest/help'\" \(966 characters\)
sed "s/^X//" >'MailServ/fakedigest/help' <<'END_OF_FILE'
X
X	This is the help file that MailServe will send to a user when
Xit can't understand the user's command.  You should explain how to use
Xthe server, and what options are available.  For instance:
X
X------------------------------------------------------------------------
X
XUsage:
X
X	To use the server, just put your command in the subject line of
Xyour message.  Don't put anything else in your message, and only one
Xcommand per mail request.  Here's an example:
X
X> From: Joe User <joe-user@ceili.com>
X> To: fakelist-request@fakesite.org
X> Subject: subscribe
X>
X>
X
X	That's all you need in your mail to be subscribed to the list!
X
X------------------------------------------------------------------------
X
XCommands:	
X
X	subscribe    		Add your name to the mailing list.
X
X	unsubscribe		Remove your name from the mailing list.
X
X	(other files as listed in the index file)
X
X------------------------------------------------------------------------
X
XAddresses:
X
X	blah blah blah...
X
END_OF_FILE
if test 966 -ne `wc -c <'MailServ/fakedigest/help'`; then
    echo shar: \"'MailServ/fakedigest/help'\" unpacked with wrong size!
fi
# end of 'MailServ/fakedigest/help'
fi
if test -f 'MailServ/fakedigest/index' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/fakedigest/index'\"
else
echo shar: Extracting \"'MailServ/fakedigest/index'\" \(60 characters\)
sed "s/^X//" >'MailServ/fakedigest/index' <<'END_OF_FILE'
X#
X# command		file to be sent
X#
Xundigest.c		files/UNDIGEST.C
END_OF_FILE
if test 60 -ne `wc -c <'MailServ/fakedigest/index'`; then
    echo shar: \"'MailServ/fakedigest/index'\" unpacked with wrong size!
fi
# end of 'MailServ/fakedigest/index'
fi
if test -f 'MailServ/fakedigest/input' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/fakedigest/input'\"
else
echo shar: Extracting \"'MailServ/fakedigest/input'\" \(0 characters\)
sed "s/^X//" >'MailServ/fakedigest/input' <<'END_OF_FILE'
END_OF_FILE
if test 0 -ne `wc -c <'MailServ/fakedigest/input'`; then
    echo shar: \"'MailServ/fakedigest/input'\" unpacked with wrong size!
fi
# end of 'MailServ/fakedigest/input'
fi
if test -f 'MailServ/fakedigest/netrc' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/fakedigest/netrc'\"
else
echo shar: Extracting \"'MailServ/fakedigest/netrc'\" \(159 characters\)
sed "s/^X//" >'MailServ/fakedigest/netrc' <<'END_OF_FILE'
XSee the man page for the format for .netrc files.  This netrc file
Xwill be copied to ~MailServ/.netrc for the FTP, and deleted when the
Xtransfer has finished.
END_OF_FILE
if test 159 -ne `wc -c <'MailServ/fakedigest/netrc'`; then
    echo shar: \"'MailServ/fakedigest/netrc'\" unpacked with wrong size!
fi
# end of 'MailServ/fakedigest/netrc'
fi
if test -f 'MailServ/fakedigest/nounsub' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/fakedigest/nounsub'\"
else
echo shar: Extracting \"'MailServ/fakedigest/nounsub'\" \(317 characters\)
sed "s/^X//" >'MailServ/fakedigest/nounsub' <<'END_OF_FILE'
X
X	This file will be sent to the user if they tried to
Xunsubscribe, but MailServe couldn't find their name in the list.  This
Xcan happen for several reasons:
X
X	1] They weren't subscribed in the first place.
X
X	2] They are unsubscribing from a different machine than they
Xsubscribed from or their sitename has changed.
X
END_OF_FILE
if test 317 -ne `wc -c <'MailServ/fakedigest/nounsub'`; then
    echo shar: \"'MailServ/fakedigest/nounsub'\" unpacked with wrong size!
fi
# end of 'MailServ/fakedigest/nounsub'
fi
if test -f 'MailServ/fakedigest/output' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/fakedigest/output'\"
else
echo shar: Extracting \"'MailServ/fakedigest/output'\" \(0 characters\)
sed "s/^X//" >'MailServ/fakedigest/output' <<'END_OF_FILE'
END_OF_FILE
if test 0 -ne `wc -c <'MailServ/fakedigest/output'`; then
    echo shar: \"'MailServ/fakedigest/output'\" unpacked with wrong size!
fi
# end of 'MailServ/fakedigest/output'
fi
if test -f 'MailServ/fakedigest/sub' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/fakedigest/sub'\"
else
echo shar: Extracting \"'MailServ/fakedigest/sub'\" \(89 characters\)
sed "s/^X//" >'MailServ/fakedigest/sub' <<'END_OF_FILE'
X
X	This file will be sent to the user when they have sucessfully
Xsubscribed to the list.
X
END_OF_FILE
if test 89 -ne `wc -c <'MailServ/fakedigest/sub'`; then
    echo shar: \"'MailServ/fakedigest/sub'\" unpacked with wrong size!
fi
# end of 'MailServ/fakedigest/sub'
fi
if test -f 'MailServ/fakedigest/tail' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/fakedigest/tail'\"
else
echo shar: Extracting \"'MailServ/fakedigest/tail'\" \(54 characters\)
sed "s/^X//" >'MailServ/fakedigest/tail' <<'END_OF_FILE'
X
X	This file will be appended to the end of a digest.
X
END_OF_FILE
if test 54 -ne `wc -c <'MailServ/fakedigest/tail'`; then
    echo shar: \"'MailServ/fakedigest/tail'\" unpacked with wrong size!
fi
# end of 'MailServ/fakedigest/tail'
fi
if test -f 'MailServ/fakedigest/unsub' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/fakedigest/unsub'\"
else
echo shar: Extracting \"'MailServ/fakedigest/unsub'\" \(91 characters\)
sed "s/^X//" >'MailServ/fakedigest/unsub' <<'END_OF_FILE'
X
X	This file will be sent to a user when they have sucessfully
Xunsubscribed from the list.
X
END_OF_FILE
if test 91 -ne `wc -c <'MailServ/fakedigest/unsub'`; then
    echo shar: \"'MailServ/fakedigest/unsub'\" unpacked with wrong size!
fi
# end of 'MailServ/fakedigest/unsub'
fi
if test -f 'MailServ/fakedigest/users' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/fakedigest/users'\"
else
echo shar: Extracting \"'MailServ/fakedigest/users'\" \(87 characters\)
sed "s/^X//" >'MailServ/fakedigest/users' <<'END_OF_FILE'
Xfakeguy@fakesite.org
Xfakegirl@fakesite.org
X* hideme@fakesite.org
Xmorefake@fakesite.org
END_OF_FILE
if test 87 -ne `wc -c <'MailServ/fakedigest/users'`; then
    echo shar: \"'MailServ/fakedigest/users'\" unpacked with wrong size!
fi
# end of 'MailServ/fakedigest/users'
fi
if test -f 'MailServ/fakelist/Info' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/fakelist/Info'\"
else
echo shar: Extracting \"'MailServ/fakelist/Info'\" \(1958 characters\)
sed "s/^X//" >'MailServ/fakelist/Info' <<'END_OF_FILE'
X#
X# Addresses for list that MUST be defined.
X#
Xerrorsto = fakelist-owner@fakesite.org (Fake List Owner)
Xreplyto = fakelist@fakesite.org (Fake Mailing List)
X
X#
X# Files that MUST be defined for the list.
X#
Xuserfile = users
Xlogfile = log
Xdelay = 8
X
X#
X# Files and addresses that need only be defined if this list has a
X# request line.
X#
Xfrom = fakelist-request@fakesite.org (Fake List Server)
Xsubscribefile = sub
Xunsubscribefile = unsub
Xnounsubfile = nounsub
Xhelpfile = help
X
X#
X# If the request line allows you to request files, set 'files' to 'yes',
X# otherwise to 'no'.  If 'files' is 'yes', 'indexfile' must be defined.
X# 
Xfiles = no
X# indexfile = index
X
X#
X# Set 'keep' to 'yes' if you want reflector posts archived, 'no'
X# otherwise.  'archivefile' must be defined if 'keep' is yes.
X#
Xkeep = yes
Xarchivefile = archive
X
X#
X# Set 'announce' to 'yes' if you want all users notified when someone
X# (un)subscribes.  Otherwise, set it to 'no'.
X#
Xannounce = no
X
X#
X# Set 'digest' to 'yes' if the list is a digest, not a reflector.  All
X# other 'digest*' variables must be defined if 'digest' is set to 'yes'.
X#
Xdigest = no
X# digestinput = input
X# digestoutput = output
X# digestcounterfile = counter
X# digestname = Fake List Daily
X# digesthead = head
X# digesttail = tail
X
X#
X# If the list is a digest, and you'd like the digest to be FTP'ed to an
X# archive site every night, set 'ftp' to 'yes'.  All 'ftp*' variables
X# and 'netrcfile' must be defined if 'ftp' is 'yes'.
X#
Xftp = no
X# ftpdir = /pub/fakelist/digest
X# ftpsite = ftp.fakesite.org
X# netrcfile = netrc
X
X#
X# Set 'backup' to yes if you want the userlist backed up every night to
X# a different area.  7 days worth of backups are kept. 'backupdir' must
X# be defined if 'backup' is set to 'yes'.
X#
Xbackup = yes
Xbackupdir = /usr/people/MailServ/backups/fakelist
X
X#
X# If there is a FAQ that is to be posted to news, set 'faq' to 'yes'.
X# 'faqfile' must be defined if 'faq' is 'yes'.
X#
Xfaq = no
X# faqfile = files/FAQ
END_OF_FILE
if test 1958 -ne `wc -c <'MailServ/fakelist/Info'`; then
    echo shar: \"'MailServ/fakelist/Info'\" unpacked with wrong size!
fi
# end of 'MailServ/fakelist/Info'
fi
if test -f 'MailServ/fakelist/archive' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/fakelist/archive'\"
else
echo shar: Extracting \"'MailServ/fakelist/archive'\" \(0 characters\)
sed "s/^X//" >'MailServ/fakelist/archive' <<'END_OF_FILE'
END_OF_FILE
if test 0 -ne `wc -c <'MailServ/fakelist/archive'`; then
    echo shar: \"'MailServ/fakelist/archive'\" unpacked with wrong size!
fi
# end of 'MailServ/fakelist/archive'
fi
if test -f 'MailServ/fakelist/help' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/fakelist/help'\"
else
echo shar: Extracting \"'MailServ/fakelist/help'\" \(966 characters\)
sed "s/^X//" >'MailServ/fakelist/help' <<'END_OF_FILE'
X
X	This is the help file that MailServe will send to a user when
Xit can't understand the user's command.  You should explain how to use
Xthe server, and what options are available.  For instance:
X
X------------------------------------------------------------------------
X
XUsage:
X
X	To use the server, just put your command in the subject line of
Xyour message.  Don't put anything else in your message, and only one
Xcommand per mail request.  Here's an example:
X
X> From: Joe User <joe-user@ceili.com>
X> To: fakelist-request@fakesite.org
X> Subject: subscribe
X>
X>
X
X	That's all you need in your mail to be subscribed to the list!
X
X------------------------------------------------------------------------
X
XCommands:	
X
X	subscribe    		Add your name to the mailing list.
X
X	unsubscribe		Remove your name from the mailing list.
X
X	(other files as listed in the index file)
X
X------------------------------------------------------------------------
X
XAddresses:
X
X	blah blah blah...
X
END_OF_FILE
if test 966 -ne `wc -c <'MailServ/fakelist/help'`; then
    echo shar: \"'MailServ/fakelist/help'\" unpacked with wrong size!
fi
# end of 'MailServ/fakelist/help'
fi
if test -f 'MailServ/fakelist/nounsub' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/fakelist/nounsub'\"
else
echo shar: Extracting \"'MailServ/fakelist/nounsub'\" \(317 characters\)
sed "s/^X//" >'MailServ/fakelist/nounsub' <<'END_OF_FILE'
X
X	This file will be sent to the user if they tried to
Xunsubscribe, but MailServe couldn't find their name in the list.  This
Xcan happen for several reasons:
X
X	1] They weren't subscribed in the first place.
X
X	2] They are unsubscribing from a different machine than they
Xsubscribed from or their sitename has changed.
X
END_OF_FILE
if test 317 -ne `wc -c <'MailServ/fakelist/nounsub'`; then
    echo shar: \"'MailServ/fakelist/nounsub'\" unpacked with wrong size!
fi
# end of 'MailServ/fakelist/nounsub'
fi
if test -f 'MailServ/fakelist/sub' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/fakelist/sub'\"
else
echo shar: Extracting \"'MailServ/fakelist/sub'\" \(89 characters\)
sed "s/^X//" >'MailServ/fakelist/sub' <<'END_OF_FILE'
X
X	This file will be sent to the user when they have sucessfully
Xsubscribed to the list.
X
END_OF_FILE
if test 89 -ne `wc -c <'MailServ/fakelist/sub'`; then
    echo shar: \"'MailServ/fakelist/sub'\" unpacked with wrong size!
fi
# end of 'MailServ/fakelist/sub'
fi
if test -f 'MailServ/fakelist/unsub' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/fakelist/unsub'\"
else
echo shar: Extracting \"'MailServ/fakelist/unsub'\" \(91 characters\)
sed "s/^X//" >'MailServ/fakelist/unsub' <<'END_OF_FILE'
X
X	This file will be sent to a user when they have sucessfully
Xunsubscribed from the list.
X
END_OF_FILE
if test 91 -ne `wc -c <'MailServ/fakelist/unsub'`; then
    echo shar: \"'MailServ/fakelist/unsub'\" unpacked with wrong size!
fi
# end of 'MailServ/fakelist/unsub'
fi
if test -f 'MailServ/fakelist/users' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/fakelist/users'\"
else
echo shar: Extracting \"'MailServ/fakelist/users'\" \(87 characters\)
sed "s/^X//" >'MailServ/fakelist/users' <<'END_OF_FILE'
Xfakeguy@fakesite.org
Xfakegirl@fakesite.org
X* hideme@fakesite.org
Xmorefake@fakesite.org
END_OF_FILE
if test 87 -ne `wc -c <'MailServ/fakelist/users'`; then
    echo shar: \"'MailServ/fakelist/users'\" unpacked with wrong size!
fi
# end of 'MailServ/fakelist/users'
fi
if test -f 'MailServ/src/Makefile' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/src/Makefile'\"
else
echo shar: Extracting \"'MailServ/src/Makefile'\" \(424 characters\)
sed "s/^X//" >'MailServ/src/Makefile' <<'END_OF_FILE'
X
XCC 	= gcc
XCFLAGS	= -g
X
XHDRS    = mailserv.h
XSRC     = digest.c info.c inmsg.c mailserv.c outmsg.c request.c utils.c
XOBJ     = $(SRC:.c=.o)
XFIN     = mailserv
X
XMHOME	= ..
XINSTDIR	= $(MHOME)/bin
X
X# ----------------------------------------------------------------------
X
Xall:	$(FIN)
X
X$(FIN):	$(OBJ)
X	$(CC) $(OBJ) $(CFLAGS) -o $(FIN)
X	cp $(FIN) ../bin
X
Xclean:	
X	@ rm -f $(OBJ) *~ core
X
Xpristine:
X	@ rm -f $(OBJ) *~ core $(FIN)
END_OF_FILE
if test 424 -ne `wc -c <'MailServ/src/Makefile'`; then
    echo shar: \"'MailServ/src/Makefile'\" unpacked with wrong size!
fi
# end of 'MailServ/src/Makefile'
fi
if test -f 'MailServ/src/digest.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/src/digest.c'\"
else
echo shar: Extracting \"'MailServ/src/digest.c'\" \(15383 characters\)
sed "s/^X//" >'MailServ/src/digest.c' <<'END_OF_FILE'
X
X#include "mailserv.h"
X
X#define HEAD1		27		/* Field width of first third	*/
X#define HEAD2		20		/* Field width of second third	*/
X#define HEAD3		21		/* Field width of last third	*/
X#define DATELEN		16		/* Amount of date to put in hdr	*/
X#define LINELEN		70		/* Length of an average line	*/
X#define MAXMSGS		64		/* Maximum number of msgs/digest*/
X#define LINESIZE	256		/* Maximum line size		*/
X
Xstruct message 
X{
X    char *Date;
X    char *From;
X    char *Subject;
X    char *MessageID;
X    char *ReprintFrom;
X    char *sortstring;
X    long messageaddr;
X    long messagelength;
X    int  use_re;
X} messages[MAXMSGS];
X
XFILE *input;
XFILE *output;
X
Xint digestsize = 0;
Xint nmessages = 0;
X
Xchar *safter(), *nospace(), *getline();
Xchar digestsubject[100];
X
X/*****************************************************************************
X * vol_issue_out
X */
Xvoid
X    vol_issue_out ()
X{
X    FILE *voliss;
X
X    voliss = fopen (listinfo.digestcounterfile, "w");
X    fprintf (voliss, "%d %d\n", listinfo.volume, (listinfo.issue)+1);
X    fclose (voliss);
X}
X
X/*****************************************************************************
X * vol_issue_info
X */
Xvoid
X    vol_issue_info()
X{
X    char templine[100];
X    FILE *voliss;
X    
X    voliss = fopen (listinfo.digestcounterfile, "r");
X    fscanf (voliss, "%d %d\n", &listinfo.volume, &listinfo.issue);
X    fclose (voliss);
X
X    if ((listinfo.datestr[8] == '1') &&
X	(listinfo.datestr[9] == ' '))
X    {
X	listinfo.volume += 1;
X	listinfo.issue = 1;
X    }
X
X    sprintf (templine, "Volume %d: Issue %3d",
X	     listinfo.volume, listinfo.issue);
X    listinfo.volline = strdup (templine);
X}
X
X/*****************************************************************************
X * distribute_digest
X */
Xvoid
X    distribute_digest()
X{
X    char cmdstr[120];
X    int i;
X
X    for (i=0; i<readercount; i++)
X    {
X	sprintf (cmdstr, "%s %s < %s",
X		 SendMail, readers[i], listinfo.digestoutput);
X	system (cmdstr);
X	sleep (listinfo.delay);
X    }
X}
X
X/*****************************************************************************
X * make_digest
X */
Xvoid
X    make_digest()
X{
X    char cmdline[200];
X
X    sprintf (cmdline, "%s %s %s.prev", Copy,
X	     listinfo.digestinput, listinfo.digestinput);
X    system (cmdline);
X
X    vol_issue_info();
X    vol_issue_out();
X    
X    fprintf(thelogfile, 
X	    "Assembling %s Digest %s (%.*s)\n", 
X	    listinfo.digestname, listinfo.volline, DATELEN, 
X	    listinfo.datestr);
X    fprintf(thelogfile, "Scanning and sorting messages for topic lines.\n");
X
X    scan_messages();
X
X    if (nmessages == 0)
X    {
X	listinfo.issue -= 1;
X	vol_issue_out();
X	fprintf (thelogfile, "Zero length digest, not mailing.\n");
X	listinfo.ftp = False;
X	listinfo.keep = False;
X	return;
X    }
X
X    sort_messages();
X    
X    fprintf (thelogfile, "Writing %s Digest to \"%s\"\n",
X	     listinfo.digestname, listinfo.digestoutput);
X    
X    do_digest_header();
X    read_messages();
X    
X    fprintf (thelogfile, "The digest is %d characters long in %d messages.\n",
X	     digestsize, nmessages);
X
X    distribute_digest();
X}
X
X/*****************************************************************************
X * getline
X */
Xchar *getline(fp)
XFILE *fp;
X{
X    register int c;
X    register char *str, *str_begin;
X    
X    if ((str = malloc(LINESIZE)) == NULL) 
X    {
X	fprintf (thelogfile, "digest: out of memory.\n");
X	Exit(1);
X    }
X    
X    str_begin = str;
X    
X    while (((str - str_begin) < (LINESIZE - 1)) &&
X	   ((c = getc(fp)) != '\n') && (c != EOF))
X	*str++ = c;
X
X    *str++ = NULL;
X    
X    if (c == EOF)
X	return(NULL);
X    
X    return(str_begin);
X}
X
X/*****************************************************************************
X * scan_messages
X */
Xscan_messages()
X{
X    register long n;
X    register char *s;
X    
X    if ((input = fopen(listinfo.digestinput, "r")) == NULL) 
X    {
X	fprintf (thelogfile, "digest: cannot open \"%s\" for reading.\n",
X		 listinfo.digestinput);
X	Exit(1);
X    }
X    
X    /*
X     * We break out of this from inside.
X     */
X    for (;;) 
X    {
X	if (nmessages >= MAXMSGS) 
X	{
X	    fprintf (thelogfile, "digest: too many messages.\n");
X	    Exit(1);
X	}
X	
X	/*
X	 * Find the start of the next message.
X	 */
X	do {
X	    /*
X	     * If we hit EOF, mark the length of the
X	     * previous message and go back.
X	     */
X	    if ((s = getline(input)) == NULL) {
X		n = ftell(input);
X		n = n - messages[nmessages - 1].messageaddr;
X		messages[nmessages - 1].messagelength = n;
X		return;
X	    }
X	} while (strncmp(s, "From ", 5) != 0);
X	
X	/*
X	 * If we have found another message, mark the
X	 * length of the previous message.
X	 */
X	if (nmessages) {
X	    n = ftell(input);
X	    n = n - (strlen(s) + 1);
X	    n = n - messages[nmessages - 1].messageaddr;
X	    messages[nmessages - 1].messagelength = n;
X	}
X	
X	/*
X	 * Read in the headers.
X	 */
X	for (;;) {
X	    /*
X	     * We shouldn't hit EOF here, we should
X	     * at least finish the headers first.
X	     */
X	    if ((s = getline(input)) == NULL) {
X		fprintf (thelogfile, "digest: \"%s\": unexpected EOF.\n",
X			 listinfo.digestinput);
X		Exit(1);
X	    }
X	    
X	    /*
X	     * Blank line terminates headers.
X	     */
X	    if (*s == NULL)
X		break;
X	    
X	    /*
X	     * Save certain headers.  We strip the
X	     * header name and leading whitespace.
X	     */
X	    if (strncmp(s, "Message-ID:", 11) == 0) {
X		messages[nmessages].MessageID = 
X		    nospace(safter(s, "Message-ID:"));
X	    }
X	    else if (strncmp(s, "Message-Id:", 11) == 0) {
X		messages[nmessages].MessageID = 
X		    nospace(safter(s, "Message-Id:"));
X	    }
X	    else if (strncmp(s, "From:", 5) == 0) {
X		messages[nmessages].From = 
X		    nospace(safter(s, "From:"));
X	    }
X	    else if (strncmp(s, "Newsgroups:", 11) == 0) {
X		messages[nmessages].ReprintFrom = 
X		    nospace(safter(s, "Newsgroups:"));
X	    }
X	    else if (strncmp(s, "Date:", 5) == 0) {
X		messages[nmessages].Date = 
X		    nospace(safter(s, "Date:"));
X	    }
X	    else if (strncmp(s, "Subject:", 8) == 0) {
X		s = nospace(safter(s, "Subject:"));
X		
X		/*
X		 * We don't need the "Re:" stuff.
X		 */
X		messages[nmessages].use_re = 0;
X		while ((strncmp(s, "re:", 3) == 0) || 
X		       (strncmp(s, "Re:", 3) == 0) ||
X		       (strncmp(s, "RE:", 3) == 0) || 
X		       (strncmp(s, "rE:", 3) == 0)) 
X		{
X		    messages[nmessages].use_re = 1;
X		    s += 3;
X		    s = nospace(s);
X		}
X		
X		messages[nmessages].Subject = s;
X	    }
X	    else {
X		/*
X		 * If we aren't saving this line,
X		 * give the memory back.
X		 */
X		free(s);
X	    }
X	}
X	
X	/*
X	 * The message starts after the header.
X	 */
X	messages[nmessages].messageaddr = ftell(input);
X	nmessages++;
X    }
X}
X
X/*****************************************************************************
X * sort_messages
X */
Xsort_messages()
X{
X    register int i;
X    extern int comp();
X    register char *s, *t;
X    
X    for (i=0; i < nmessages; i++) {
X	/*
X	 * Skip messages with no subject.
X	 */
X	if (messages[i].Subject == NULL)
X	    continue;
X	
X	s = messages[i].Subject;
X	
X	if ((t = malloc(strlen(s)+1)) == NULL) {
X	    fprintf (thelogfile, "digest: out of memory.\n");
X	    Exit(1);
X	}
X	
X	messages[i].sortstring = t;
X	
X	/*
X	 * Zap leading whitespace.
X	 */
X	s = nospace(s);
X	
X	/*
X	 * Copy the subject string into sortstring
X	 * converting upper case to lower case and
X	 * ignoring whitespace.
X	 */
X	while (*s) {
X	    if ((*s == ' ') || (*s == '\t')) {
X		s++;
X		continue;
X	    }
X	    
X	    if (isupper(*s))
X		*t++ = tolower(*s);
X	    else
X		*t++ = *s;
X	    
X	    s++;
X	}
X	
X	*t = NULL;
X    }
X    
X    /*
X     * Sort 'em.
X     */
X    qsort(messages, nmessages, sizeof(struct message), comp);
X}
X
X/*****************************************************************************
X * comp
X */
Xcomp(m1, m2)
Xregister struct message *m1, *m2;
X{
X    int admin1, admin2;
X    
X    if (m1->sortstring == NULL) {
X	if (m2->sortstring == NULL)
X	    return(0);
X	return(1);		/* no subject messages to end */
X    }
X    
X    if (m2->sortstring == NULL)
X	return(-1);		/* no subject messages to end */
X    
X    admin1 = strncmp(m1->sortstring, "administrivia", 13);
X    admin2 = strncmp(m2->sortstring, "administrivia", 13);
X    
X    if (admin1 == 0) {
X	if (admin2 == 0)
X	    return(0);
X	return(-1);		/* administrivia to beginning */
X    }
X    
X    if (admin2 == 0)
X	return(1);		/* administrivia to beginning */
X    
X    return(strcmp(m1->sortstring, m2->sortstring));
X}
X
X/*****************************************************************************
X * do_digest_header
X */
Xdo_digest_header()
X{
X    FILE *fp;
X    char *laststr;
X    char buf[BUFSIZ];
X    char tmp[LINESIZE];
X    extern int comp2();
X    register int i, j, length;
X    char *c;
X    
X    if ((output = fopen(listinfo.digestoutput, "w")) == NULL) {
X	fprintf (thelogfile, "digest: cannot create \"%s\"\n",
X		 listinfo.digestoutput);
X	Exit(1);
X    }
X    
X    digestsize = 0;
X    
X    /*
X     * Mailer headers.
X     */
X    sprintf (buf, "Precedence: Bulk\n", listinfo.datestr);
X    digestsize += strlen (buf);
X    fputs(buf, output);
X
X    sprintf(buf, "Date: %s\n", listinfo.datestr);
X    digestsize += strlen(buf);
X    fputs(buf, output);
X    
X    sprintf(buf, "Errors-To: %s\n", listinfo.errorsto);
X    digestsize += strlen(buf);
X    fputs(buf, output);
X    
X    sprintf(buf, "From: %s\n", listinfo.from);
X    digestsize += strlen(buf);
X    fputs(buf, output);
X    
X    sprintf(buf, "Reply-To: %s\n", listinfo.replyto);
X    digestsize += strlen(buf);
X    fputs(buf, output);
X    
X    strcpy (tmp, listinfo.volline);
X    for (c = tmp; *c != 0 && *c != ':'; c++) ;
X
X    do 
X    { *c-- = 0; } 
X    while (c >= tmp && *c == ' ');
X    
X    do 
X    { c--; } 
X    while (c >= tmp && *c != ' ');
X
X    c++;
X    digestsize += 9; fputs ("Subject: ", output);
X    sprintf(digestsubject, "%s Digest V%s #%d",
X	    listinfo.digestname, c, listinfo.issue);
X    digestsize += strlen(digestsubject);
X    fputs(digestsubject, output);
X    digestsize++, putc ('\n', output);
X    
X    /*
X     * The digest header.
X     */
X    sprintf(tmp, "%s Digest", listinfo.digestname);
X    sprintf(buf, "\n\n%-*.*s %-*.*s %-*.*s\n\n",
X	    HEAD1, HEAD1, tmp,
X	    HEAD2, DATELEN, listinfo.datestr,
X	    HEAD3, HEAD3, listinfo.volline);
X    digestsize += strlen(buf);
X    fputs(buf, output);
X    
X    sprintf(buf, "Today's Topics:\n");
X    digestsize += strlen(buf);
X    fputs(buf, output);
X    
X    /*
X     * Do today's topics lines.
X     */
X    laststr = "";
X    for (i=0; i < nmessages; i++) {
X	/*
X	 * No topic.
X	 */
X	if (messages[i].Subject == NULL)
X	    continue;
X	
X	laststr = messages[i].sortstring;
X	
X	/*
X	 * Count the number of messages with this topic.
X	 */
X	j = 1;
X	while (((i + j) < nmessages)
X	       && (messages[i+j].sortstring != NULL)
X	       && (strcmp(laststr, messages[i+j].sortstring) == 0))
X	    j++;
X	
X	/*
X	 * Print the topic centered on the line.
X	 */
X	if (j > 1) {
X	    sprintf(tmp, "%s (%d msgs)", messages[i].Subject, j);
X	    length = (LINELEN / 2) + (strlen(tmp) / 2);
X	    sprintf(buf, "%*s\n", length, tmp);
X	    
X	    /*
X	     * Sort messages with same topic into their
X	     * original arrival order.
X	     */
X	    qsort(&messages[i], j, sizeof(struct message), comp2);
X	    i += (j - 1);
X	}
X	else {
X	    length = (LINELEN / 2) + (strlen(messages[i].Subject) / 2);
X	    sprintf(buf, "%*s\n", length, messages[i].Subject);
X	}
X	
X	digestsize += strlen(buf);
X	fputs(buf, output);
X    }
X    
X    /*
X     * Read the listinfo.digesthead file, if there is one.
X     */
X    if ((fp = fopen(listinfo.digesthead, "r")) != NULL) {
X	putc('\n', output);
X	digestsize++;
X	
X	while (fgets(buf, BUFSIZ, fp) != NULL) {
X	    digestsize += strlen(buf);
X	    fputs(buf, output);
X	}
X	
X	fclose(fp);
X	putc('\n', output);
X    }
X    
X    /*
X     * Print a line of dashes.
X     */
X    for (i=0; i < LINELEN; i++) {
X	putc('-', output);
X	digestsize++;
X    }
X    
X    fputs("\n\n", output);
X    digestsize += 2;
X}
X
X/*****************************************************************************
X * comp2
X */
Xcomp2(m1, m2)
Xregister struct message *m1, *m2;
X{
X    return(m1->messageaddr - m2->messageaddr);
X}
X
X/*****************************************************************************
X * read_messages
X */
Xread_messages()
X{
X    FILE *fp;
X    char buf[BUFSIZ];
X    register char *s, *t;
X    register int i, length;
X    int linestart;
X    
X    for (i=0; i < nmessages; i++) {
X	/*
X	 * Just in case.
X	 */
X	clearerr(input);
X	
X	/*
X	 * Put the message's headers back in.
X	 */
X	sprintf(buf, "Date: %s\n", messages[i].Date);
X	digestsize += strlen(buf);
X	fputs(buf, output);
X	
X	sprintf(buf, "From: %s\n", messages[i].From);
X	digestsize += strlen(buf);
X	fputs(buf, output);
X	
X	if (messages[i].Subject != NULL) {
X	    sprintf(buf, "Subject: %s%s\n",
X		    (messages[i].use_re ? "Re: " : ""),
X		    messages[i].Subject);
X	    digestsize += strlen(buf);
X	    fputs(buf, output);
X	}
X	
X	if (messages[i].MessageID != NULL) {
X	    sprintf(buf, "Message-ID: %s\n", messages[i].MessageID);
X	    digestsize += strlen(buf);
X	    fputs(buf, output);
X	}
X	
X	if (messages[i].ReprintFrom != NULL) {
X	    sprintf (buf, "\nReprintFrom: %s\n", messages[i].ReprintFrom);
X	    digestsize += strlen(buf);
X	    fputs (buf, output);
X	}
X	
X	putc ('\n', output); digestsize++;
X	
X	/*
X	 * Read the message into memory.  This is
X	 * so we can zap extra blank lines.
X	 */
X	fseek(input, messages[i].messageaddr, 0);
X	length = messages[i].messagelength;
X	
X	if ((s = malloc(length+1)) == NULL) {
X	    fprintf (thelogfile, "digest: out of memory.\n");
X	    Exit(1);
X	}
X	
X	fread(s, 1, length, input);
X	
X	/*
X	 * Zap trailing newlines.
X	 */
X	t = s + length;
X	while (length > 0 && *--t == '\n')
X	    length--;
X	*++t = NULL;
X	
X	/*
X	 * Zap leading newlines.
X	 */
X	t = s;
X	while (*t++ == '\n')
X	    length--;
X	t--;
X	
X	/*
X	 * Write the message.
X	 *
X	 * In any line which begins with 30 or more hyphens,
X	 * change the first hyphen to a space, to avoid a clash
X	 * with the message separator string.
X	 */
X	digestsize += length;
X	/* fwrite(t, 1, length, output); */
X	linestart = 1;
X	while (length-- > 0) {
X	    if (linestart &&
X		strncmp(t,"------------------------------",30) == 0)
X		linestart = 0, t++, putc (' ', output);
X	    else {
X		linestart = (*t == '\n');
X		putc (*t++, output);
X	    }
X	}
X	
X	sprintf(buf, "\n\n------------------------------\n\n");
X	digestsize += strlen(buf);
X	fputs(buf, output);
X	free(s);
X    }
X    
X    /*
X     * All done.
X     */
X    sprintf(buf, "End of %s\n******************************",
X	    digestsubject);
X    digestsize += strlen(buf);
X    fputs(buf, output);
X    for (i = strlen (digestsubject) + 7; i > 30; i--)
X	digestsize++, putc ('*', output);
X    digestsize++, putc ('\n', output);
X
X    if ((fp = fopen(listinfo.digesttail, "r")) != NULL) {
X	putc('\n', output);
X	digestsize++;
X	
X	while (fgets(buf, BUFSIZ, fp) != NULL) {
X	    digestsize += strlen(buf);
X	    fputs(buf, output);
X	}
X	
X	fclose(fp);
X	putc('\n', output);
X    }
X
X    fclose(output);
X    fclose(input);
X
X    input = fopen (listinfo.digestinput, "w");
X    fclose (input);
X}
X
X/*
X * safter - return a pointer to the position in str which follows pat.
X */
Xchar *safter(str, pat)
Xregister char *str, *pat;
X{
X    register int len;
X    
X    len = strlen(pat);
X    
X    while (*str) {
X	if (strncmp(str, pat, len) == 0) {
X	    str += len;
X	    return(str);
X	}
X	
X	str++;
X    }
X    
X    return(NULL);
X}
X
X/*
X * nospace - advance s over leading whitespace, return new value.
X */
Xchar *nospace(s)
Xregister char *s;
X{
X    while ((*s != NULL) && ((*s == ' ') || (*s == '\t')))
X	s++;
X    
X    return(s);
X}
X
END_OF_FILE
if test 15383 -ne `wc -c <'MailServ/src/digest.c'`; then
    echo shar: \"'MailServ/src/digest.c'\" unpacked with wrong size!
fi
# end of 'MailServ/src/digest.c'
fi
if test -f 'MailServ/src/info.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/src/info.c'\"
else
echo shar: Extracting \"'MailServ/src/info.c'\" \(8664 characters\)
sed "s/^X//" >'MailServ/src/info.c' <<'END_OF_FILE'
X
X#include "mailserv.h"
X
X/*****************************************************************************
X * expand_path
X */
Xchar
X    *expand_path (fname)
Xchar *fname;
X{
X    char *carp;
X
X    if ((fname[0] != '/') && (fname[0] != '.'))
X    {
X	carp = (char *) malloc (strlen (ListHome) + strlen (listinfo.name) +
X				strlen (fname) + 5);
X	sprintf (carp, "%s/%s/%s", ListHome, listinfo.name, fname);
X	return (carp);
X    }
X
X    return (strdup (fname));
X}
X
X/*****************************************************************************
X * boolean_info_line
X */
Xint
X    boolean_info_line (chptr)
Xchar *chptr;
X{
X    char cmdword[20], flag[5], *carp;
X
X    sscanf (chptr, "%s = %s", &cmdword, &flag);
X    if (carp = strstr (flag, "y"))
X	return (True);
X    else
X	return (False);
X}
X
X/*****************************************************************************
X * val_info_line
X */
Xint
X    val_info_line (chptr)
Xchar *chptr;
X{
X    char cmdword[20], value[5];
X
X    sscanf (chptr, "%s = %s", &cmdword, &value);
X    return (atoi (value));
X}
X
X/*****************************************************************************
X * str_info_line
X */
Xchar
X    *str_info_line (chptr)
Xchar *chptr;
X{
X    return (cleanup_string (strstr (chptr, "=") + 1));
X}
X
X/*****************************************************************************
X * file_info_line
X */
Xchar
X    *file_info_line (chptr)
Xchar *chptr;
X{
X    char *carp1, *carp2;
X
X    carp1 = str_info_line (chptr);
X    carp2 = expand_path (carp1);
X    free (carp1);
X    return (carp2);
X}
X
X/*****************************************************************************
X * get_list_info
X */
Xvoid
X    get_list_info (argc, argv)
Xint argc;
Xchar **argv;
X{
X    char filepath[100], templine[100], *carp;
X    int lnum = 0;
X    FILE *infofile;
X
X    if (argc != 3)
X    {
X	usage ();
X    }
X
X    listinfo.name = strdup (argv[1]);
X    listinfo.sub = strdup (argv[2]);
X
X    sprintf (filepath, "%s/%s/%s", ListHome, listinfo.name, InfoFile);
X
X    infofile = fopen (filepath, "r");
X
X    while (fgets (templine, 100, infofile) != NULL)
X    {
X	lnum ++;
X	if ((templine[0] != '#') && (strlen (templine)) > 3)
X	{
X	    /*
X	     * Booleans
X	     */
X	    if ((carp = strstr (templine, "keep ")) && (carp == templine))
X		listinfo.keep = boolean_info_line (carp);
X
X	    else if ((carp = strstr (templine, "announce ")) && (carp == templine))
X		listinfo.announce = boolean_info_line (carp);
X
X	    else if ((carp = strstr (templine, "files ")) && (carp == templine))
X		listinfo.files = boolean_info_line (carp);
X
X	    else if ((carp = strstr (templine, "digest ")) && (carp == templine))
X		listinfo.digest = boolean_info_line (carp);
X
X	    else if ((carp = strstr (templine, "backup ")) && (carp == templine))
X		listinfo.backup = boolean_info_line (carp);
X
X	    else if ((carp = strstr (templine, "faq ")) && (carp == templine))
X		listinfo.faq = boolean_info_line (carp);
X
X	    else if ((carp = strstr (templine, "ftp ")) && (carp == templine))
X		listinfo.ftp = boolean_info_line (carp);
X
X	    /* 
X	     * Values
X	     */
X	    else if ((carp = strstr (templine, "delay ")) && (carp == templine))
X		listinfo.delay = val_info_line (carp);
X
X	    /* 
X	     * Strings - general
X	     */
X	    else if ((carp = strstr (templine, "replyto ")) && (carp == templine))
X		listinfo.replyto = (char *) str_info_line (carp);
X
X	    else if ((carp = strstr (templine, "errorsto ")) && (carp == templine))
X		listinfo.errorsto = (char *) str_info_line (carp);
X
X	    else if ((carp = strstr (templine, "from ")) && (carp == templine))
X		listinfo.from = (char *) str_info_line (carp);
X
X	    else if ((carp = strstr (templine, "ftpsite ")) && (carp == templine))
X		listinfo.ftpsite = (char *) str_info_line (carp);
X
X	    else if ((carp = strstr (templine, "ftpdir ")) && (carp == templine))
X		listinfo.ftpdir = (char *) str_info_line (carp);
X
X	    else if ((carp = strstr (templine, "digestname ")) && (carp == templine))
X		listinfo.digestname = (char *) str_info_line (carp);
X
X	    /* 
X	     * Strings - filenames/paths
X	     */
X	    else if ((carp = strstr (templine, "archivefile ")) && (carp == templine))
X		listinfo.archivefile = (char *) file_info_line (carp);
X
X	    else if ((carp = strstr (templine, "userfile ")) && (carp == templine))
X		listinfo.userfile = (char *) file_info_line (carp);
X
X	    else if ((carp = strstr (templine, "logfile ")) && (carp == templine))
X		listinfo.logfile = (char *) file_info_line (carp);
X
X	    else if ((carp = strstr (templine, "indexfile ")) && (carp == templine))
X		listinfo.indexfile = (char *) file_info_line (carp);
X
X	    else if ((carp = strstr (templine, "backupdir")) && (carp == templine))
X		listinfo.backupdir = (char *) file_info_line (carp);
X
X	    else if ((carp = strstr (templine, "subscribefile ")) && (carp == templine))
X		listinfo.subscribefile = (char *) file_info_line (carp);
X
X	    else if ((carp = strstr (templine, "unsubscribefile ")) && (carp == templine))
X		listinfo.unsubscribefile = (char *) file_info_line (carp);
X
X	    else if ((carp = strstr (templine, "nounsubfile ")) && (carp == templine))
X		listinfo.nounsubfile = (char *) file_info_line (carp);
X
X	    else if ((carp = strstr (templine, "helpfile ")) && (carp == templine))
X		listinfo.helpfile = (char *) file_info_line (carp);
X
X	    else if ((carp = strstr (templine, "faqfile ")) && (carp == templine))
X		listinfo.faqfile = (char *) file_info_line (carp);
X
X	    else if ((carp = strstr (templine, "netrcfile ")) && (carp == templine))
X		listinfo.netrcfile = (char *) file_info_line (carp);
X
X	    else if ((carp = strstr (templine, "digestinput ")) && (carp == templine))
X		listinfo.digestinput = (char *) file_info_line (carp);
X
X	    else if ((carp = strstr (templine, "digestoutput ")) && (carp == templine))
X		listinfo.digestoutput = (char *) file_info_line (carp);
X
X	    else if ((carp = strstr (templine, "digestcounterfile ")) && (carp == templine))
X		listinfo.digestcounterfile = (char *) file_info_line (carp);
X
X	    else if ((carp = strstr (templine, "digesthead ")) && (carp == templine))
X		listinfo.digesthead = (char *) file_info_line (carp);
X
X	    else if ((carp = strstr (templine, "digesttail ")) && (carp == templine))
X		listinfo.digesttail = (char *) file_info_line (carp);
X
X	    else
X	    {
X		fprintf (stderr, "Error on line %d of %s\n",
X			 lnum, filepath);
X		fprintf (thelogfile, "Error on line %d of %s @ %s\n",
X			 lnum, filepath, listinfo.datestr);
X		Exit (1);
X	    }
X	}
X    }
X
X    fclose (infofile);
X}
X
Xint okinfo;
X
X/*****************************************************************************
X * badinfo
X */
Xvoid
X    badinfo (carp)
Xchar *carp;
X{
X    fprintf (stderr, "Error in Info file: %s not defined\n", carp);
X    fprintf (thelogfile, "Error in Info file: %s not defined\n", carp);
X    okinfo = False;
X}
X
X/*****************************************************************************
X * verify_info
X */
Xvoid
X    verify_info ()
X{
X    okinfo = True;
X
X    if (listinfo.logfile == NULL)
X    {
X	fprintf (stderr, "Error in Info file: logfile not defined\n");
X	fflush (stderr);
X	exit (1);
X    }
X    thelogfile = fopen (listinfo.logfile, "a");
X
X    if (listinfo.replyto == NULL)
X	badinfo ("replyto");
X    if (listinfo.errorsto == NULL)
X	badinfo ("errorsto");
X    if (listinfo.userfile == NULL)
X	badinfo ("userfile");
X    if (listinfo.delay == NULL)
X	badinfo ("delay");
X
X    if (listinfo.from != NULL)
X    {
X	if (listinfo.subscribefile == NULL)
X	    badinfo ("subscribefile");
X	if (listinfo.unsubscribefile == NULL)
X	    badinfo ("unsubscribefile");
X	if (listinfo.nounsubfile == NULL)
X	    badinfo ("nounsubfile");
X	if (listinfo.helpfile == NULL)
X	    badinfo ("helpfile");
X    }
X
X    if (listinfo.files)
X    {
X	if (listinfo.indexfile == NULL)
X	    badinfo ("indexfile");
X    }
X
X    if (listinfo.keep)
X    {
X	if (listinfo.archivefile == NULL)
X	    badinfo ("archivefile");
X    }
X
X    if (listinfo.digest)
X    {
X	if (listinfo.digestinput == NULL)
X	    badinfo ("digestinput");
X	if (listinfo.digestoutput == NULL)
X	    badinfo ("digestoutput");
X	if (listinfo.digestcounterfile == NULL)
X	    badinfo ("digestcounterfile");
X	if (listinfo.digestname == NULL)
X	    badinfo ("digestname");
X	if (listinfo.digesthead == NULL)
X	    badinfo ("digesthead");
X	if (listinfo.digesttail == NULL)
X	    badinfo ("digesttail");
X
X	if (listinfo.ftp)
X	{
X	    if (listinfo.ftpdir == NULL)
X		badinfo ("ftpdir");
X	    if (listinfo.ftpsite == NULL)
X		badinfo ("ftpsite");
X	    if (listinfo.netrcfile == NULL)
X		badinfo ("netrcfile");
X	}
X    }
X
X    if (listinfo.backup)
X    {
X	if (listinfo.backupdir == NULL)
X	    badinfo ("backupdir");
X    }
X
X    if (listinfo.faq)
X    {
X	if (listinfo.faqfile == NULL)
X	    badinfo ("backupdir");
X    }
X
X    if (!okinfo)
X	Exit (1);
X}
X
END_OF_FILE
if test 8664 -ne `wc -c <'MailServ/src/info.c'`; then
    echo shar: \"'MailServ/src/info.c'\" unpacked with wrong size!
fi
# end of 'MailServ/src/info.c'
fi
if test -f 'MailServ/src/inmsg.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/src/inmsg.c'\"
else
echo shar: Extracting \"'MailServ/src/inmsg.c'\" \(3900 characters\)
sed "s/^X//" >'MailServ/src/inmsg.c' <<'END_OF_FILE'
X
X#include "mailserv.h"
X
X/*****************************************************************************
X * get_raw_msg
X */
Xvoid
X    get_raw_msg()
X{
X    char templine[1000];
X    
X    msglines = 0;
X    while (fgets (templine, 1000, stdin))
X    {
X	if (msglines >= MAXLINES)
X	    fprintf (thelogfile, "WARNING: message truncated @ %s\n",
X		     listinfo.datestr);
X	else
X	    rawmsg[msglines] = strdup(templine);
X
X	msglines ++;
X    }
X}
X
X/*****************************************************************************
X * handle_alt_hdr
X */
Xint
X    handle_alt_hdr (line)
Xchar *line;
X{
X    if (outmsg.ahlcnt >= MAXALTHDR)
X    {
X	fprintf (thelogfile, 
X		 "Warning: Alternate header buffer overflowed @ %s\n",
X		 listinfo.datestr);
X	return (False);
X    }
X
X    outmsg.althdr[outmsg.ahlcnt++] = rm_tail_cr (line);
X    return (True);
X}
X
X/*****************************************************************************
X * process_raw_msg
X */
Xvoid
X    process_raw_msg()
X{
X    int hdrflag = True;
X    int pls = True;
X    char *carp;
X    int i;
X
X    for (i=0; i<msglines; i++)
X    {
X	if (!(hdrflag))
X	{
X	    outmsg.msgbody[outmsg.mblcnt] = strdup (rawmsg[i]);
X	    outmsg.mblcnt ++;
X	    pls = True;
X	    continue;
X	}
X
X	if (strlen (rawmsg[i]) == 1)
X	{
X	    hdrflag = False;
X	    pls = True;
X	    continue;
X	}
X
X	if (isspace (rawmsg[i][0]))
X	{
X	    if (pls)
X	    {
X		pls = handle_alt_hdr (rawmsg[i]);
X		continue;
X	    }
X	    else
X	    {
X		pls = False;
X		continue;
X	    }
X	}
X
X	if ((carp = strstr (rawmsg[i], "Reply-To:")) &&
X	    (!(strstr (rawmsg[i], "In-Reply-To:"))) &&
X	    (carp == rawmsg[i]))
X	{
X	    char *tlfrom;
X
X	    outmsg.from = get_return_address (rawmsg[i]);
X	    tlfrom = get_long_return_address (rawmsg[i]);
X
X	    if (outmsg.longfrom)
X	    {
X		if (strlen (outmsg.longfrom) <= strlen (tlfrom))
X		{
X		    free (outmsg.longfrom);
X		    outmsg.longfrom = tlfrom;
X		}
X	    }
X	    else
X	    {
X		outmsg.longfrom = tlfrom;
X	    }
X
X	    pls = True;
X	    continue;
X	}
X
X	if ((carp = strstr (rawmsg[i], "From:")) &&
X	    (carp == rawmsg[i]))
X	{
X	    char *tlfrom;
X
X	    tlfrom = get_long_return_address (rawmsg[i]);
X	    if (!(outmsg.from))
X		outmsg.from = get_return_address (rawmsg[i]);
X
X	    if (outmsg.longfrom)
X	    {
X		if (strlen (outmsg.longfrom) <= strlen (tlfrom))
X		{
X		    free (outmsg.longfrom);
X		    outmsg.longfrom = tlfrom;
X		}
X	    }
X	    else
X	    {
X		outmsg.longfrom = tlfrom;
X	    }
X	    
X	    pls = True;
X	    continue;
X	}
X
X	if ((carp = strstr (rawmsg[i], "Subject:")) &&
X	    (carp == rawmsg[i]))
X	{
X	    outmsg.subj = cleanup_string (carp + 9);
X	    pls = True;
X	    continue;
X	}
X
X	if ((carp = strstr (rawmsg[i], "Newsgroups:")) &&
X	    (carp == rawmsg[i]))
X	{
X	    outmsg.newsgroup = cleanup_string (carp + 12);
X	    pls = True;
X	    continue;
X	}
X
X	if ((carp = strstr (rawmsg[i], "Apparently")) ||
X	    (carp = strstr (rawmsg[i], "Cc")) ||
X	    (carp = strstr (rawmsg[i], "Content")) ||
X	    (carp = strstr (rawmsg[i], "Date")) ||
X	    (carp = strstr (rawmsg[i], "Errors")) ||
X	    (carp = strstr (rawmsg[i], "From ")) ||
X	    (carp = strstr (rawmsg[i], "In-Reply-To")) ||
X	    (carp = strstr (rawmsg[i], "Message-Id")) ||
X	    (carp = strstr (rawmsg[i], "Mime")) ||
X	    (carp = strstr (rawmsg[i], "Nntp")) ||
X	    (carp = strstr (rawmsg[i], "Path")) ||
X	    (carp = strstr (rawmsg[i], "Precedence")) ||
X	    (carp = strstr (rawmsg[i], "Received")) ||
X	    (carp = strstr (rawmsg[i], "References")) ||
X	    (carp = strstr (rawmsg[i], "Reply-To")) ||
X	    (carp = strstr (rawmsg[i], "Return-Path")) ||
X	    (carp = strstr (rawmsg[i], "Sender")) ||
X	    (carp = strstr (rawmsg[i], "Status")) ||
X	    (carp = strstr (rawmsg[i], "To:")) ||
X	    (carp = strstr (rawmsg[i], "X-")))
X	{
X	    if (carp == rawmsg[i])
X	    {
X		pls = False;
X		continue;
X	    }
X	}
X
X	pls = handle_alt_hdr (rawmsg[i]);
X    }
X
X    outmsg.replyto = strdup (listinfo.replyto);
X    outmsg.errorsto = strdup (listinfo.errorsto);
X}
X
END_OF_FILE
if test 3900 -ne `wc -c <'MailServ/src/inmsg.c'`; then
    echo shar: \"'MailServ/src/inmsg.c'\" unpacked with wrong size!
fi
# end of 'MailServ/src/inmsg.c'
fi
if test -f 'MailServ/src/mailserv.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/src/mailserv.c'\"
else
echo shar: Extracting \"'MailServ/src/mailserv.c'\" \(2081 characters\)
sed "s/^X//" >'MailServ/src/mailserv.c' <<'END_OF_FILE'
X
X#define MAIN
X#include "mailserv.h"
X
X/*****************************************************************************
X * usage
X */
Xvoid
X    usage()
X{
X    fprintf (stderr, "Usage: mailserv listname command < mailfile\n\n");
X    fprintf (stderr, "Commands:\n");
X    fprintf (stderr, "\trequest\t\tmail from request address\n");
X    fprintf (stderr, "\tmessage\t\tmail from message address\n");
X    fprintf (stderr, "\tnightly\t\tdo nightly maintenance\n");
X    fprintf (stderr, "\trare\t\tdo infrequent maintenance\n");
X    Exit (1);
X}
X
X/*****************************************************************************
X * msgdate
X */
Xchar *msgdate()
X{
X    long t;
X
X    t = time(0);
X    return (cleanup_string (ctime (&t)));
X}
X
X/*****************************************************************************
X * init_globals
X */
Xvoid
X    init_globals ()
X{
X    listinfo.datestr = msgdate();
X
X    listinfo.delay = 5;
X
X    listinfo.replyto = NULL;
X    listinfo.errorsto = NULL;
X
X    listinfo.keep = False;
X    listinfo.announce = False;
X    listinfo.files = False;
X    listinfo.digest = False;
X    listinfo.backup = True;
X    listinfo.faq = False;
X    listinfo.ftp = False;
X
X    outmsg.longfrom = NULL;
X}
X
X/*****************************************************************************
X * main
X */
Xint
X    main (argc, argv)
Xint argc;
Xchar **argv;
X{
X    init_globals ();
X    get_list_info (argc, argv);
X    verify_info ();
X    get_user_list ();
X
X    if (strstr (listinfo.sub, "request"))
X    {
X	get_raw_msg ();
X	process_raw_msg ();
X	handle_request ();
X    }
X    else if (strstr (listinfo.sub, "message"))
X    {
X	get_raw_msg ();
X	process_raw_msg ();
X	distribute_message ();
X    }
X    else if (strstr (listinfo.sub, "nightly"))
X    {
X	if (listinfo.backup)
X	    backup_user_list ();
X
X	if (listinfo.digest)
X	{
X	    make_digest ();
X
X	    if (listinfo.ftp)
X		ftp_digest ();
X	}
X
X	dump_log ();
X    }
X    else if (strstr (listinfo.sub, "rare"))
X    {
X	if (listinfo.faq)
X	    post_faq ();
X    }
X    else
X    {
X	fprintf (stderr, "Illegal sublist type: %s\n", listinfo.sub);
X	Exit(1);
X    }
X
X    Exit (0);
X}
END_OF_FILE
if test 2081 -ne `wc -c <'MailServ/src/mailserv.c'`; then
    echo shar: \"'MailServ/src/mailserv.c'\" unpacked with wrong size!
fi
# end of 'MailServ/src/mailserv.c'
fi
if test -f 'MailServ/src/mailserv.h' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/src/mailserv.h'\"
else
echo shar: Extracting \"'MailServ/src/mailserv.h'\" \(2781 characters\)
sed "s/^X//" >'MailServ/src/mailserv.h' <<'END_OF_FILE'
X
X#ifndef MAILSERV
X#define MAILSERV
X
X/*****************************************************************************
X * Header files
X */
X#include <stdio.h>
X#include <stdlib.h>
X#include <string.h>
X#include <time.h>
X#include <sys/types.h>
X#include <ctype.h>
X
X/*****************************************************************************
X * Constants
X */
X#define True       1
X#define False      0
X#define MAXLINES   10000
X#define MAXALTHDR  10
X#define BADADDR    "Bad_Address"
X
X/* File names & locations */
X#define ListHome   "/itchy1/MailServ/"
X#define InfoFile   "Info"
X
X/* Shell Commands */
X#define SendMail   "/usr/lib/sendmail"
X#define Sort       "/bin/sort"
X#define Copy       "/bin/cp"
X#define Rm         "/bin/rm -f"
X#define Inews      "/usr/local/bin/inews"
X#define Ftp        "/usr/ucb/ftp"
X
X/* Fake address for Quiet mailings */
X#define FakeAddr   "notreal%itchy@dsd.es.com"
X
X/*****************************************************************************
X * Type definitions
X */
Xtypedef struct
X{
X    char *name, *sub;
X    char *replyto, *errorsto, *from;
X    char *archivefile, *userfile, *logfile, *indexfile, *backupdir;
X    char *subscribefile, *unsubscribefile, *nounsubfile, *helpfile;
X    char *digestinput, *digestoutput, *digestcounterfile;
X    char *digestname, *digesthead, *digesttail;
X    char *datestr, *volline;
X    char *faqfile;
X    char *ftpdir, *ftpsite, *netrcfile;
X
X    int volume, issue;
X    int delay;
X
X    unsigned announce : 1;
X    unsigned backup : 1;
X    unsigned digest : 1;
X    unsigned faq : 1;
X    unsigned files : 1;
X    unsigned ftp : 1;
X    unsigned keep : 1;
X}
XListInfo;
X
Xtypedef struct
X{
X    char *replyto;
X    char *errorsto;
X    char *from, *longfrom;
X    char *subj;
X    char *newsgroup;
X
X    char *althdr[MAXALTHDR];
X    int ahlcnt;
X
X    char *msgbody[MAXLINES];
X    int mblcnt;
X}
XMessage;
X
Xtypedef struct
X{
X    char *request;
X    char *filename;
X}
XReqFile;
X	
X
X/*****************************************************************************
X * Global variables
X */
X#ifdef MAIN
X#define SCOPE
X#else
X#define SCOPE extern
X#endif
X
XSCOPE char *rawmsg[MAXLINES];
XSCOPE int msglines;
X
XSCOPE ListInfo listinfo;
XSCOPE Message outmsg;
X
XSCOPE char *readers[MAXLINES];
XSCOPE int readercount;
X
XSCOPE ReqFile reqtable[MAXLINES];
XSCOPE int reqcount;
X
XSCOPE FILE *thelogfile;
X
X#endif /* #ifndef MAILSERV... */
X
X/*****************************************************************************
X * Functions predefs, for utils
X */
Xchar *first_word (char *);
Xchar *rest_of_line (char *);
Xchar *rm_tail_cr (char *);
Xchar *rm_head_space (char *);
Xchar *cleanup_string (char *);
Xchar *get_return_address (char *);
Xchar *get_long_return_address (char *);
Xvoid send_file (char *, char *, char *);
Xvoid get_user_list ();
Xvoid backup_user_list ();
Xvoid post_faq ();
END_OF_FILE
if test 2781 -ne `wc -c <'MailServ/src/mailserv.h'`; then
    echo shar: \"'MailServ/src/mailserv.h'\" unpacked with wrong size!
fi
# end of 'MailServ/src/mailserv.h'
fi
if test ! -d 'MailServ/src/orig-dig' ; then
    echo shar: Creating directory \"'MailServ/src/orig-dig'\"
    mkdir 'MailServ/src/orig-dig'
fi
if test -f 'MailServ/src/outmsg.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/src/outmsg.c'\"
else
echo shar: Extracting \"'MailServ/src/outmsg.c'\" \(5758 characters\)
sed "s/^X//" >'MailServ/src/outmsg.c' <<'END_OF_FILE'
X
X#include "mailserv.h"
X
X/*****************************************************************************
X * dump_clean_message
X */
Xvoid
X    dump_clean_message(fileid)
XFILE *fileid;
X{
X    int i;
X
X    if (fileid)
X    {
X	fprintf (fileid, "Errors-To: %s\n", outmsg.errorsto);
X	fprintf (fileid, "Reply-To: %s\n", outmsg.replyto);
X	fflush (fileid);
X    }
X    else
X    {
X	printf ("Errors-To: %s\n", outmsg.errorsto);
X	printf ("Reply-To: %s\n", outmsg.replyto);
X	fflush (stdout);
X    }
X
X    if (outmsg.longfrom)
X    {
X	if (fileid)
X	{
X	    fprintf (fileid, "From: %s\n", outmsg.longfrom);
X	    fflush (fileid);
X	}
X	else
X	{
X	    printf ("From: %s\n", outmsg.longfrom);
X	    fflush (stdout);
X	}
X    }
X
X    if (outmsg.subj)
X    {
X	if (fileid)
X	{
X	    fprintf (fileid, "Subject: %s\n", outmsg.subj);
X	    fflush (fileid);
X	}
X	else
X	{
X	    printf ("Subject: %s\n", outmsg.subj);
X	    fflush (stdout);
X	}
X    }
X
X    for (i=0; i<outmsg.ahlcnt; i++)
X    {
X	if (fileid)
X	{
X	    fprintf (fileid, "%s\n", outmsg.althdr[i]);
X	    fflush (fileid);
X	}
X	else
X	{
X	    printf ("%s\n", outmsg.althdr[i]);
X	    fflush (stdout);
X	}
X    }
X
X    if (fileid)
X    {
X	fprintf (fileid, "List-Name: %s\n", listinfo.name);
X	fprintf (fileid, "Precedence: Bulk\n");
X	fprintf (fileid, "\n");
X	fflush (fileid);
X    }
X    else
X    {
X	printf ("List-name: %s\n", listinfo.name);
X	printf ("Precedence: Bulk\n");
X	printf ("\n");
X	fflush (stdout);
X    }
X
X    if (outmsg.newsgroup)
X    {
X	if (fileid)
X	{
X	    fprintf (fileid, "Newsgroups: %s\n", outmsg.newsgroup);
X	    fflush (fileid);
X	}
X	else
X	{
X	    printf ("Newsgroups: %s\n", outmsg.newsgroup);
X	    fflush (stdout);
X	}
X    }
X
X    for (i=0; i<outmsg.mblcnt; i++)
X    {
X	if (fileid)
X	{
X	    fprintf (fileid, "%s", outmsg.msgbody[i]);
X	    fflush (fileid);
X	}
X	else
X	{
X	    printf ("%s", outmsg.msgbody[i]);
X	    fflush (stdout);
X	}
X    }
X}
X
X/*****************************************************************************
X * dump_quiet_clean_message
X */
Xvoid
X    dump_quiet_clean_message(fileid, qto)
XFILE *fileid;
Xchar *qto;
X{
X    int i;
X
X    if (fileid)
X    {
X	fprintf (fileid, "Errors-To: %s\n", outmsg.errorsto);
X	fprintf (fileid, "Reply-To: %s\n", outmsg.replyto);
X	fprintf (fileid, "Bcc: %s\n", qto);
X	fflush (fileid);
X    }
X    else
X    {
X	printf ("Errors-To: %s\n", outmsg.errorsto);
X	printf ("Reply-To: %s\n", outmsg.replyto);
X	printf ("Bcc: %s\n", qto);
X	fflush (stdout);
X    }
X
X    if (outmsg.longfrom)
X    {
X	if (fileid)
X	{
X	    fprintf (fileid, "From: %s\n", outmsg.longfrom);
X	    fflush (fileid);
X	}
X	else
X	{
X	    printf ("From: %s\n", outmsg.longfrom);
X	    fflush (stdout);
X	}
X    }
X
X    if (outmsg.subj)
X    {
X	if (fileid)
X	{
X	    fprintf (fileid, "Subject: %s\n", outmsg.subj);
X	    fflush (fileid);
X	}
X	else
X	{
X	    printf ("Subject: %s\n", outmsg.subj);
X	    fflush (stdout);
X	}
X    }
X
X    for (i=0; i<outmsg.ahlcnt; i++)
X    {
X	if (fileid)
X	{
X	    fprintf (fileid, "%s\n", outmsg.althdr[i]);
X	    fflush (fileid);
X	}
X	else
X	{
X	    printf ("%s\n", outmsg.althdr[i]);
X	    fflush (stdout);
X	}
X    }
X
X    if (fileid)
X    {
X	fprintf (fileid, "List-Name: %s\n", listinfo.name);
X	fprintf (fileid, "Precedence: Bulk\n");
X	fprintf (fileid, "\n");
X	fflush (fileid);
X    }
X    else
X    {
X	printf ("List-name: %s\n", listinfo.name);
X	printf ("Precedence: Bulk\n");
X	printf ("\n");
X	fflush (stdout);
X    }
X
X    if (outmsg.newsgroup)
X    {
X	if (fileid)
X	{
X	    fprintf (fileid, "Newsgroups: %s\n", outmsg.newsgroup);
X	    fflush (fileid);
X	}
X	else
X	{
X	    printf ("Newsgroups: %s\n", outmsg.newsgroup);
X	    fflush (stdout);
X	}
X    }
X
X    for (i=0; i<outmsg.mblcnt; i++)
X    {
X	if (fileid)
X	{
X	    fprintf (fileid, "%s", outmsg.msgbody[i]);
X	    fflush (fileid);
X	}
X	else
X	{
X	    printf ("%s", outmsg.msgbody[i]);
X	    fflush (stdout);
X	}
X    }
X}
X
X/*****************************************************************************
X * dump_raw_msg
X */
Xvoid
X    dump_raw_msg(fileid)
XFILE *fileid;
X{
X    int i;
X
X    for (i=0; i<msglines; i++)
X    {
X	if (fileid)
X	{
X	    fputs (rawmsg[i], fileid);
X	    fflush (fileid);
X	}
X	else
X	{
X	    fputs (rawmsg[i], stdin);
X	    fflush (stdout);
X	}
X    }
X}   
X
X/*****************************************************************************
X * send_to_digest
X */
Xvoid
X    send_to_digest()
X{
X    FILE *digestfile;
X
X    digestfile = fopen (listinfo.digestinput, "a");
X    dump_raw_msg (digestfile);
X    fclose (digestfile);
X}
X
X/*****************************************************************************
X * send_to_users
X */
Xvoid
X    send_to_users()
X{
X    FILE *outfile;
X    char cmdstr[120], *carp;
X    int i;
X
X    for (i=0; i<readercount; i++)
X    {
X	if (readers[i][0] == '*')
X	{
X	    sprintf (cmdstr, "%s %s", SendMail, FakeAddr);
X	    outfile = popen (cmdstr, "w");
X	    carp = rest_of_line (readers[i]);
X	    dump_quiet_clean_message (outfile, carp);
X	}
X	else
X	{
X	    sprintf (cmdstr, "%s %s", SendMail, readers[i]);
X	    outfile = popen (cmdstr, "w");
X	    dump_clean_message (outfile);
X	}
X
X	pclose (outfile);
X	sleep (listinfo.delay);
X    }
X}
X
X/*****************************************************************************
X * archive_message
X */
Xvoid
X    archive_message()
X{
X    FILE *outfile;
X
X    outfile = fopen (listinfo.archivefile, "a");
X    dump_clean_message (outfile);
X    fclose (outfile);
X}
X
X/*****************************************************************************
X * distribute_message
X */
Xvoid
X    distribute_message()
X{
X    fprintf (thelogfile, "Message: %s @ %s\n",
X	     outmsg.from, listinfo.datestr);
X    fprintf (thelogfile, "     Subj: %s\n",
X	     outmsg.subj);
X
X    if (outmsg.newsgroup)
X	fprintf (thelogfile, "     News: %s\n", outmsg.newsgroup);
X
X    if (listinfo.digest)
X    {
X	send_to_digest();
X	return;
X    }
X
X    send_to_users();
X
X    if (listinfo.keep)
X	archive_message();
X
X}
END_OF_FILE
if test 5758 -ne `wc -c <'MailServ/src/outmsg.c'`; then
    echo shar: \"'MailServ/src/outmsg.c'\" unpacked with wrong size!
fi
# end of 'MailServ/src/outmsg.c'
fi
if test -f 'MailServ/src/request.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/src/request.c'\"
else
echo shar: Extracting \"'MailServ/src/request.c'\" \(7555 characters\)
sed "s/^X//" >'MailServ/src/request.c' <<'END_OF_FILE'
X
X#include "mailserv.h"
X
X/*****************************************************************************
X * std_req_hdr
X */
Xvoid
X    std_req_hdr (fileid)
XFILE *fileid;
X{
X    if (fileid)
X    {
X        fprintf (fileid, "Errors-To: %s\n", outmsg.errorsto);
X        fprintf (fileid, "Reply-To: %s\n", listinfo.from);
X	fprintf (fileid, "From: %s\n", listinfo.from);
X        fprintf (fileid, "List-Name: %s\n", listinfo.name);
X        fprintf (fileid, "Precedence: Bulk\n\n");
X	fflush (fileid);
X    }
X    else
X    {
X        printf ("Errors-To: %s\n", outmsg.errorsto);
X        printf ("Reply-To: %s\n", listinfo.from);
X	printf ("From: %s\n", listinfo.from);
X	printf ("List-name: %s\n", listinfo.name);
X        printf ("Precedence: Bulk\n\n");
X	fflush (stdout);
X    }
X}
X
X/*****************************************************************************
X * quiet_req_hdr
X */
Xvoid
X    quiet_req_hdr (fileid, qto)
XFILE *fileid;
Xchar *qto;
X{
X    if (fileid)
X    {
X        fprintf (fileid, "Errors-To: %s\n", outmsg.errorsto);
X        fprintf (fileid, "Reply-To: %s\n", listinfo.from);
X	fprintf (fileid, "From: %s\n", listinfo.from);
X	fprintf (fileid, "Bcc: %s\n", qto);
X        fprintf (fileid, "Precedence: Bulk\n\n");
X	fflush (fileid);
X    }
X    else
X    {
X        printf ("Errors-To: %s\n", outmsg.errorsto);
X        printf ("Reply-To: %s\n", listinfo.from);
X	printf ("From: %s\n", listinfo.from);
X	printf ("Bcc: %s\n", qto);
X        printf ("Precedence: Bulk\n\n");
X	fflush (stdout);
X    }
X}
X
X/*****************************************************************************
X * handle_bad_address
X */
Xvoid
X    handle_bad_address()
X{
X    FILE *cmdstream;
X    char cmdstr[100];
X
X    sprintf (cmdstr, "%s %s-owner", SendMail, listinfo.name);
X    cmdstream = popen (cmdstr, "w");
X
X    sprintf (cmdstr, "Subject: BAD ADDRESS in %s\n", listinfo.name);
X    fputs (cmdstream, cmdstr);
X    std_req_hdr (cmdstream);
X
X    dump_raw_msg (cmdstream);
X    pclose (cmdstream);
X}
X
X/*****************************************************************************
X * make_request_table
X */
Xvoid
X    make_request_table ()
X{
X    char templine[100], *carp;
X    char request[40], thefile[40];
X    FILE *reqfile;
X    
X    reqfile = fopen (listinfo.indexfile, "r");
X
X    while (fgets (templine, 100, reqfile) != NULL)
X    {
X	carp = cleanup_string (templine);
X
X        if (carp[0] != '#')
X	{
X	    int i;
X
X	    reqtable[reqcount].request = (char *)
X		cleanup_string (first_word (carp));
X	    reqtable[reqcount].filename = (char *)
X		cleanup_string (rest_of_line (carp));
X	    for (i=0; i<strlen(reqtable[reqcount].request); i++)
X		if (isupper (reqtable[reqcount].request[i]))
X		    request[i] = tolower(reqtable[reqcount].request[i]);
X	    reqcount++;
X	}
X    }
X
X    fclose (reqfile);
X}
X
X/*****************************************************************************
X * announce
X */
Xvoid
X    announce (annstring)
Xchar *annstring;
X{
X    FILE *cmdstream;
X    char cmdstr[100];
X
X    sprintf (cmdstr, "%s %s", SendMail, listinfo.name);
X    cmdstream = popen (cmdstr, "w");
X
X    fprintf (cmdstream, "Subject: %s", annstring);
X    std_req_hdr (cmdstream);
X    fprintf (cmdstream, "%s\n", annstring);
X	
X    pclose (cmdstream);
X}
X
X/*****************************************************************************
X * handle_subscribe
X */
Xvoid
X    handle_subscribe ()
X{
X    char filepath[100];
X    FILE *fileptr;
X
X    fileptr = fopen (listinfo.userfile, "a");
X    fprintf (fileptr, "%s\n", outmsg.from);
X    fclose (fileptr);
X
X    send_file (outmsg.from, listinfo.subscribefile, "Subscribed");
X
X    fprintf (thelogfile, "Subscribed: %s @ %s\n",
X	     outmsg.from, listinfo.datestr);
X    fprintf (thelogfile, "     Subj: %s\n", outmsg.subj);
X
X    if (listinfo.announce)
X    {
X	sprintf (filepath, "Adding %s to the %s list.\n",
X		 outmsg.from, listinfo.name);
X	announce (filepath);
X    }
X
X    if (listinfo.digest)
X	send_file (outmsg.from, listinfo.digestoutput, "Previous Digest");
X}
X
X/*****************************************************************************
X * handle_unsubscribe
X */
Xvoid
X    handle_unsubscribe ()
X{
X    int i, ok = False, thisuser=0;
X    char filepath[100], *carp;
X    FILE *fileptr;
X
X    for (i=0; i<readercount; i++)
X    {
X	if ((carp = strstr (readers[i], outmsg.from)) &&
X	    (carp == readers[i]))
X	{
X	    thisuser = i;
X	    ok = True;
X	    break;
X	}
X	else if ((carp = strstr (readers[i], outmsg.from)) &&
X		 (carp == (readers[i]) + 2) &&
X		 (readers[i][0] == '*'))
X	{
X	    thisuser = i;
X	    ok = True;
X	    break;
X	}
X
X    }
X
X    if (ok)
X    {
X	fileptr = fopen (listinfo.userfile, "w");
X
X	for (i=0; i<readercount; i++)
X	{
X	    if (i != thisuser)
X		fprintf (fileptr, "%s\n", readers[i]);
X	    fflush (fileptr);
X	}
X	fclose (fileptr);
X
X	send_file (outmsg.from, listinfo.unsubscribefile, "Unsubscribed");
X
X	fprintf (thelogfile, "Unsubscribed: %s @ %s\n",
X		 outmsg.from, listinfo.datestr);
X	fprintf (thelogfile, "     Subj: %s\n", outmsg.subj);
X
X	if (listinfo.announce)
X	{
X	    sprintf (filepath, "Removing %s from the %s list.\n",
X		     outmsg.from, listinfo.name);
X	    announce (filepath);
X	}
X    }
X    else
X    {
X	send_file (outmsg.from, listinfo.nounsubfile, "Unsubscribe FAILED");
X
X	fprintf (thelogfile, "Didn't unsub %s @ %s\n", 
X		 outmsg.from, listinfo.datestr);
X	fprintf (thelogfile, "     Subj: %s\n", outmsg.subj);
X    }
X}		    
X
X/*****************************************************************************
X * handle_show_list
X */
Xvoid
X    handle_show_list ()
X{
X    char filepath[100];
X
X    send_file (outmsg.from, listinfo.userfile, "User List");
X
X    fprintf (thelogfile, "Sent userlist to: %s @ %s\n", 
X	     outmsg.from, listinfo.datestr);
X    fprintf (thelogfile, "     Subj: %s\n", outmsg.subj);
X}
X
X/*****************************************************************************
X * handle_file_request
X */
Xvoid
X    handle_file_request (filenum)
Xint filenum;
X{
X    send_file (outmsg.from, reqtable[filenum].filename,
X	       reqtable[filenum].request);
X
X    fprintf (thelogfile, "Sent %s to: %s @ %s\n", 
X	     reqtable[filenum].filename, outmsg.from, listinfo.datestr);
X    fprintf (thelogfile, "     Subj: %s\n", outmsg.subj);
X}
X
X/*****************************************************************************
X * handle_help
X */
Xvoid
X    handle_help ()
X{
X    send_file (outmsg.from, listinfo.helpfile, "Help");
X
X    fprintf (thelogfile, "Helping: %s @ %s\n", 
X	     outmsg.from, listinfo.datestr);
X    fprintf (thelogfile, "     Subj: %s\n", outmsg.subj);
X}
X
X/*****************************************************************************
X * handle_request
X */
Xvoid
X    handle_request()
X{
X    char *request, *carp;
X    int i;
X
X    if (strstr (outmsg.from, BADADDR))
X	handle_bad_address();
X
X    if (listinfo.files)
X	make_request_table();
X
X    if (outmsg.subj == NULL)
X    {
X	handle_help();
X	return;
X    }
X
X    request = strdup (outmsg.subj);
X    for (i=0; i<strlen(request); i++)
X	if (isupper (request[i]))
X	    request[i] = tolower(request[i]);
X
X    if ((carp = strstr (request, "unsubscribe")) &&
X	(carp == request))
X    {
X	handle_unsubscribe();
X	return;
X    }
X
X    if ((carp = strstr (request, "subscribe")) &&
X	(carp == request))
X    {
X	handle_subscribe();
X	return;
X    }
X
X    if ((carp = strstr (request, "show-list")) &&
X	(carp == request))
X    {
X	if (listinfo.announce)
X	    handle_show_list ();
X	else
X	    handle_help ();
X
X	return;
X    }
X
X    if (listinfo.files)
X    {
X	for (i=0; i<reqcount; i++)
X	{
X	    if ((carp = strstr (request, reqtable[i].request)) &&
X		(carp == request))
X	    {
X		handle_file_request (i);
X		return;
X	    }
X	}
X    }
X
X    handle_help ();
X
X}
END_OF_FILE
if test 7555 -ne `wc -c <'MailServ/src/request.c'`; then
    echo shar: \"'MailServ/src/request.c'\" unpacked with wrong size!
fi
# end of 'MailServ/src/request.c'
fi
if test -f 'MailServ/src/utils.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/src/utils.c'\"
else
echo shar: Extracting \"'MailServ/src/utils.c'\" \(6921 characters\)
sed "s/^X//" >'MailServ/src/utils.c' <<'END_OF_FILE'
X
X#include "mailserv.h"
X
X/*****************************************************************************
X * first_word
X */
Xchar
X    *first_word (line)
Xchar *line;
X{
X    char *tcp, tc;
X    int i=0;
X
X    while (i < strlen(line))
X    {
X	if (isspace (line[i]))
X	{
X	    tc = line[i];
X	    line[i] = '\0';
X	    tcp = strdup (line);
X	    line[i] = tc;
X	    return (tcp);
X	}
X	i++;
X    }
X
X    return (strdup (line));
X}
X
X/*****************************************************************************
X * rest_of_line
X */
Xchar
X    *rest_of_line (line)
Xchar *line;
X{
X    int i=0;
X
X    while (i < strlen(line))
X    {
X	if (isspace (line[i]))
X	{
X	    return (strdup ( &(line[i+1]) ));
X	    break;
X	}
X	i++;
X    }
X
X    return (NULL);
X}
X
X
X/*****************************************************************************
X * rm_tail_cr
X */
Xchar
X    *rm_tail_cr (line)
Xchar *line;
X{
X    char *carp, *tcp;
X    char cr[2];
X
X    sprintf (cr, "\n");
X
X    tcp = strdup (line);
X    if (carp = strstr (tcp, cr))
X	*carp = '\0';
X
X    return (tcp);
X}
X
X/*****************************************************************************
X * rm_head_space
X */
Xchar
X    *rm_head_space (line)
Xchar *line;
X{
X    int flag = True;
X    char *tcp, *carp1, *carp2;
X
X    carp1 = tcp = strdup (line);
X
X    while (flag)
X    {
X	if (isspace (*carp1))
X	    carp1++;
X	else
X	    flag = False;
X    }
X
X    carp2 = strdup (carp1);
X    free (tcp);
X
X    return (carp2);
X}
X
X/*****************************************************************************
X * cleanup_string
X */
Xchar
X    *cleanup_string (line)
Xchar *line;
X{
X    char *tc1, *tc2;
X
X    tc1 = rm_tail_cr (line);
X    tc2 = rm_head_space (tc1);
X    free (tc1);
X    return (tc2);
X}
X
X/*****************************************************************************
X * get_return_address
X */
Xchar
X    *get_return_address (line)
Xchar *line;
X{
X    char *first, *rest, *full;
X    char *carp, *tcp;
X    int cleanloop = True, i, m;
X
X    full = strdup (line);
X
X    while (full)
X    {
X	first = first_word (full);
X	rest = rest_of_line (full);
X	free (full);
X
X	if (strstr (first, "@"))
X	{
X	    free (rest);
X	    break;
X	}
X
X	full = rest;
X	free (first);
X	first = NULL;
X    }
X
X    if (first == NULL)
X	return (strdup (BADADDR));
X
X    carp = first;
X
X    while (cleanloop)
X    {
X	if (carp[0] == '[')
X	{
X	    carp++;
X	    tcp = strstr(carp, "]");
X	    *tcp = '\0';
X	    continue;
X	}
X
X	if (carp[0] == '(')
X	{
X	    carp++;
X	    tcp = strstr(carp, ")");
X	    *tcp = '\0';
X	    continue;
X	}
X
X	if (carp[0] == '<')
X	{
X	    carp++;
X	    tcp = strstr(carp, ">");
X	    *tcp = '\0';
X	    continue;
X	}
X
X	cleanloop = False;
X    }
X
X    m = strlen (carp);
X
X    for (i=0; i<m; i++)
X    {
X	if (isupper (carp[i]))
X	    carp[i] = tolower (carp[i]);
X    }
X
X    tcp = cleanup_string (carp);
X    free (first);
X    return (tcp);
X}
X
X/*****************************************************************************
X * get_long_return_address
X */
Xchar
X    *get_long_return_address (line)
Xchar *line;
X{
X    char *tc1, *tc2;
X
X    tc1 = rest_of_line (line);
X    tc2 = cleanup_string (tc1);
X    free (tc1);
X    return (tc2);
X}
X
X/*****************************************************************************
X * send_file
X */
Xvoid
X    send_file (name, filepath, subj)
Xchar *name, *filepath, *subj;
X{
X    FILE *cmdstream, *datafile;
X    char cmdstr[100];
X
X    if (filepath[0] == '/')
X	sprintf (cmdstr, "%s", filepath);
X    else
X	sprintf (cmdstr, "%s/%s/%s", ListHome, listinfo.name, filepath);
X
X    if ((datafile = fopen (cmdstr, "r")) == NULL)
X    {
X	fprintf (thelogfile, "Error sending file %s: %s @ %s\n", 
X		 filepath, outmsg.from, listinfo.datestr);
X	fprintf (thelogfile, "     Subj: %s\n", outmsg.subj);
X	return;
X    }
X
X    sprintf (cmdstr, "%s %s", SendMail, name);
X    cmdstream = popen (cmdstr, "w");
X
X    fprintf (cmdstream, "Subject: %s\n", subj);
X    std_req_hdr (cmdstream);
X
X    while (fgets (cmdstr, 100, datafile) != NULL)
X    {
X	fputs (cmdstr, cmdstream);
X	fflush (cmdstream);
X    }
X
X    pclose (cmdstream);
X    fclose (datafile);
X}
X
X/*****************************************************************************
X * get_user_list
X */
Xvoid
X    get_user_list()
X{
X    char templine[100], *carp;
X    FILE *userfile;
X
X    readercount = 0;
X    userfile = fopen (listinfo.userfile, "r");
X    while (fgets (templine, 100, userfile) != NULL)
X    {
X	if (templine[0] != '#')
X	{
X	    if (readercount > MAXLINES)
X	    {
X		fprintf (stderr, "Warning: User list overflow.\n");
X		fprintf (thelogfile, "Warning: User list overflow @ %s\n",
X			 listinfo.datestr);
X		break;
X	    }
X
X	    readers[readercount++] = cleanup_string (templine);
X	}
X    }
X}
X
X/*****************************************************************************
X * backup_user_list
X */
Xvoid
X    backup_user_list()
X{
X    char tl[200];
X    int d;
X
X    d = atoi (&(listinfo.datestr[8]));
X
X    if (listinfo.backup)
X    {
X	sprintf (tl, "%s -u -o %s %s", Sort,
X		 listinfo.userfile, listinfo.userfile);
X	system (tl);
X
X	sprintf (tl, "%s %s %s/%d", Copy, listinfo.userfile,
X		 listinfo.backupdir, d);
X	system (tl);
X
X	d = (d + 31 - 7) % 31;
X	sprintf (tl, "%s -f %s/%d", Rm, listinfo.backupdir, d);
X	system (tl);
X    }
X}
X
X/*****************************************************************************
X * dump_log
X */
Xvoid
X    dump_log ()
X{
X    char templine[200];
X
X    fclose (thelogfile);
X    thelogfile = fopen (listinfo.logfile, "r");
X
X    printf ("==================================\n");
X    printf ("List Log: %s    (%d users)\n\n", listinfo.name, readercount);
X
X    while (fgets (templine, 200, thelogfile))
X	fputs (templine, stdout);
X
X    fclose (thelogfile);
X    printf ("\n");
X    thelogfile = fopen (listinfo.logfile, "w");
X}
X
X/*****************************************************************************
X * post_faq
X */
Xvoid
X    post_faq ()
X{
X    char cmdstr[100];
X
X    sprintf (cmdstr, "%s %s", Inews, listinfo.faqfile);
X    system (cmdstr);
X}
X
X/*****************************************************************************
X * ftp_digest
X */
Xvoid
X    ftp_digest ()
X{
X    char cmd[200];
X    FILE *cmdstream;
X
X    sprintf (cmd, "%s %s %s/.netrc", Copy, listinfo.netrcfile, ListHome);
X    system (cmd);
X
X    sprintf (cmd, "%s %s", Ftp, listinfo.ftpsite);
X    cmdstream = popen (cmd, "w");
X    sleep (15);
X
X    fprintf (cmdstream, "bin\n");
X    sleep (10);
X
X    fprintf (cmdstream, "prompt\n");
X    sleep (10);
X
X    fprintf (cmdstream, "put %s  %s/daily\n", 
X	     listinfo.digestoutput, listinfo.ftpdir);
X    sleep (10);
X
X    fprintf (cmdstream, "put %s  %s/vol-%d/%d\n",
X	     listinfo.digestoutput, listinfo.ftpdir, 
X	     listinfo.volume, listinfo.issue);
X    sleep (10);
X    
X    fprintf (cmdstream, "quit\n");
X    sleep (100);
X
X    sprintf (cmd, "%s %s/.netrc", Rm, ListHome);
X    system (cmd);
X
X    pclose (cmdstream);
X}
X
X/*****************************************************************************
X * Exit
X */
Xvoid
X    Exit (state)
Xint state;
X{
X    fflush (stderr);
X    fclose (thelogfile);
X    exit (state);
X}
END_OF_FILE
if test 6921 -ne `wc -c <'MailServ/src/utils.c'`; then
    echo shar: \"'MailServ/src/utils.c'\" unpacked with wrong size!
fi
# end of 'MailServ/src/utils.c'
fi
if test -f 'MailServ/fakedigest/files/UNDIGEST.C' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/fakedigest/files/UNDIGEST.C'\"
else
echo shar: Extracting \"'MailServ/fakedigest/files/UNDIGEST.C'\" \(5155 characters\)
sed "s/^X//" >'MailServ/fakedigest/files/UNDIGEST.C' <<'END_OF_FILE'
X/*
X	Modified 11/16/90 to fix use of an uninitialized variable
X	(could cause a run time error on some machines)
X	and a variable set but not used to eliminate the warnings
X	from the Apollo c compiler.  jdb
X
X	Modified 1/27/88 to handle more types of digests and
X	a compile-time option added (LONGNAME) which will cause
X	the default output file name to be <digest-name>.VOL.NUM
X	rather than the VOL.NUM form described below.
X
X	This has been tested with the Info-IBM, Info-Kermit, and
X	Info-CPM Digest formats.
X
X	This program should be called 'UNDIGEST' rather than 'DIGEST'
X	as it is below since there is a companion program in the
X	Simtel20 PD2:<UNIX.MAIL> directory (digest.c) that
X	creates a Digest file from individual messages.
X
X	The original documentation below has NOT been modified to
X	reflect these changes.
X
X					David Brown
X					jdb@email.ncsc.navy.mil
X*/
X/*
XDIGEST:  (version 3) November, 1984
X
XNAME: 
X	Digest  - reformats the ailist digest for use with "mail -f"
X
XSYNOPSIS:
X	digest file [file] 
X
XDESCRIPTION:
X
Xdigest takes the file name  given  in  first  argument  and  places  the
Xreformatted  file  in  the  second argument, if given. If no output file
X(2nd argument) is given, the output will be placed into a  default  file
Xwhose  name  is of the form VOL.NUM where VOL and NUM are the volume and
Xnumber of the ailist digest fed in (e.g. 2.144,etc.).
X
XA few notes:
X	(1) if only one argument is given, it is assumed to be the
X	    input file.  If no args are given, you get prompted for
X	    for the input file, and the output is sent to the default
X	    file construction.
X
X	(2) This has been tested only for use with the specific ailist/human-
X	    nets format now in use.  I will soon get around to adding
X	    code to this program to handle other formats.  When I do,
X	    I will send it along.
X
X	(3) The input to this program must be A SINGLE AILIST 
X	    OR HUMAN-NETS DIGEST.  If you have been stuffing all 
X	    your ailist digests into a single file, running this pgm 
X	    on that file will yield  incorrect and unpredictable results.  
X	    The pgm is best  used to manage the incoming stuff.
X
X	(4) the input file is left untouched (i.e. is not removed)
X
X	(5) digest does not work with piped input (a bug, sorry).
X	    This has meant for me that I stick the day's ailist digest
X	    into a temp file when I receive it over "mail", and then
X	    later "digest" this temp file to get it into a suitable
X	    form for "mail -f".
X
XBUGS:
X	If there are ailist sub-entries which do not have a DATE:
X	field in the header, they will be appended to the entry
X	prior.  
X
XAny questions, suggestions or problems, etc. should be sent to 
X
Xdouglas stumberger
Xdepartment of computer science
X111 Cumington Street
Xboston, ma. 02215
X
Xcsnet: des@bostonu
Xbitnet: csc10304@bostonu
X
X*/
X
X#include <stdio.h>
X
Xmain(argc,argv)
X	int argc; char *argv[] ;
X{
X	FILE *fpr, *fpw ;
X	char *lead, *fromline, temp[81], fname[81] ,
X		digest[81],vol[50],num[5] ;
X	register int done=0, gl ;
X	
X	if (argc > 3) {
X		printf("Usage: %s file [file]\n",argv[0]) ;
X		exit(0);
X	}
X	if (argc == 1) { 
X		printf("What file is the digest in? > ") ;
X		scanf("%s",fname) ;
X	}
X	else 
X		strcpy(fname,argv[1]) ;
X	
X	if ((fpr = fopen(fname,"r")) == NULL) {
X		printf("%s: No such file\n",fname) ;
X		exit(0) ;
X	}
X
X#ifdef DEBUG
X	printf(" input file name is <%s>\n",fname) ;
X#endif
X
X	lead = (char *) calloc(90,sizeof(char)) ;  
X
X	get_line(fpr,lead) ;		/* get the first line of file */
X
X	fromline = (char *) malloc(strlen(lead)+1) ;
X	strcpy(fromline,lead) ;
X
X	if (argc != 3) {   /* no output file given - 
X				find out vol/num for filename */
X
X		while ((lead[0] != '-') && (!done)) {
X#ifdef DEBUG
Xprintf("Scanning:%s",lead);
X#endif
X			sscanf(lead,"%s %s",digest,temp) ;
X			if (!strcmp(temp,"Digest")) {
X#ifdef DEBUG
Xprintf("\nFound a match\n");
X#endif
X	               sscanf(lead,"%*s %*s %*s %*s %*s %*s %*s %s %*c %*s %s",
X		   		vol,num) ;
X		   	done++ ;
X			}
X			get_line(fpr,lead) ;
X		}
X
X		strcat(digest,".") ;		
X#ifndef LONGNAME
X		digest[0]='\0';
X#endif
X		strcat(digest,vol) ;
X		strcat(digest,".") ;
X		strcat(digest,num) ;
X	}
X	else 
X		strcpy(digest,argv[2]) ;	/* output filename is third argument */
X
X
X#ifdef DEBUG
X		printf("output file is <%s>",digest) ;
X#endif
X
X	fclose(fpr) ;			
X
X#ifdef DEBUG
X		printf(" input file is <%s>\n",fname) ;
X#endif
X
X	if ((fpr = fopen(fname,"r")) == NULL) {
X		printf("\nERROR: File will not rewind\n") ;
X		exit(0) ;
X	}
X
X	if ((fpw = fopen(digest,"w")) == NULL) {
X		printf("\nERROR: Output File will not open\n") ;
X		exit(0) ;
X	}
X
X	get_line(fpr,lead) ;		/* copy the ailist header */
X
X	while (lead[0] != '-') {	/* i.e.  Law's message of the topics */
X		fprintf(fpw,"%s",lead) ;
X		get_line(fpr,lead) ;
X	}
X
X	gl = get_line(fpr,lead) ;	/* do the body of the digest */
X	while (gl != EOF) {
X		sscanf(lead,"%s",temp) ;
X		if (!strcmp (temp,"Date:"))
X			fprintf(fpw,"%s",fromline) ;
X		fprintf(fpw,"%s",lead) ;
X		gl = get_line(fpr,lead) ;
X	}
X
X	printf("Re-formatted digest now in file <%s>\n",digest) ;
X	}	
X
X
Xget_line (fp,s)
X	FILE *fp;	char *s;
X{
X	register int c=0,i=0 ;
X
X	while ((c != '\n') && (c != EOF)) {
X		c = getc(fp) ;
X		*(s+i++) = c ;
X	}
X	*(s+i) = '\0' ;
X	return(c) ;
X}
X
END_OF_FILE
if test 5155 -ne `wc -c <'MailServ/fakedigest/files/UNDIGEST.C'`; then
    echo shar: \"'MailServ/fakedigest/files/UNDIGEST.C'\" unpacked with wrong size!
fi
chmod +x 'MailServ/fakedigest/files/UNDIGEST.C'
# end of 'MailServ/fakedigest/files/UNDIGEST.C'
fi
if test -f 'MailServ/src/orig-dig/Makefile' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/src/orig-dig/Makefile'\"
else
echo shar: Extracting \"'MailServ/src/orig-dig/Makefile'\" \(204 characters\)
sed "s/^X//" >'MailServ/src/orig-dig/Makefile' <<'END_OF_FILE'
X
XSRC =	digest.c
X
XOBJ =	digest.o
X
Xdigest-test:
X	cc -c digest.o -g $(SRC)
X	cc -o digestify-test -g $(OBJ)
X	rm digest.o
X
Xdigest-final:
X	cc -c digest.o -O -s $(SRC)
X	cc -o digestify -O -s $(OBJ)
X	rm digest.o
END_OF_FILE
if test 204 -ne `wc -c <'MailServ/src/orig-dig/Makefile'`; then
    echo shar: \"'MailServ/src/orig-dig/Makefile'\" unpacked with wrong size!
fi
# end of 'MailServ/src/orig-dig/Makefile'
fi
if test -f 'MailServ/src/orig-dig/digest.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/src/orig-dig/digest.c'\"
else
echo shar: Extracting \"'MailServ/src/orig-dig/digest.c'\" \(20528 characters\)
sed "s/^X//" >'MailServ/src/orig-dig/digest.c' <<'END_OF_FILE'
X/*
X * digest - create digests of mail messages
X *
X * This program uses the file "digest.info" to figure out what issue
X * of the digest it is making.  The format of this file is:
X *
X *	Name of the List		# leave out the word "digest"
X *	Host				# the host where the digest lives
X *	From				# who sends the digest out
X *	To				# who the list is sent to
X *	Volume				# Volume XX : Issue XXX
X *	Date				# Day, dd Mon yy hh:mm:ss ZZZ
X *
X * As an example:
X *
X *	Foobar
X *	intrepid.ecn.purdue.edu
X *	Dave Curry (The Moderator) <Foobar-Digest@intrepid.ecn.purdue.edu>
X *	Foobar-List@intrepid.ecn.purdue.edu
X *	Volume 1 : Issue 0
X *	Mon,  4 Jan 88 20:15:33 EST
X *
X * Make sure the "From" line includes a legitimate RFC 822 mail address.
X * Make sure the issue number starts at zero; it gets incremented BEFORE
X * generating each digest.  Volume numbers must be incremented by hand.
X * The "digest.info" file gets modified by the program after generation
X * of each digest.
X *
X * The contents of the file "digest.head", if it exists, will be placed
X * between the list of today's topics and the top of the digest.  This
X * can be used to put information about where to FTP archives from, etc.
X *
X * The file "digest.input" should contain a set of mail messages in the
X * format of a UNIX mailbox.  These messages will be read into memory,
X * and a list of "Today's Topics" generated from the subject lines.  The
X * messages will then be sorted so that all the messages on the same topic
X * come out together in the digest.  Any message whost first word in the
X * subject line is "Administrivia" will be guaranteed to come out first
X * in the digest.
X *
X * The digest will be left in the file "digest.output".  You can send it
X * using the command "/usr/lib/sendmail -t < digest.output".
X *
X * I suggest creating the following mail aliases in /usr/lib/aliases:
X *
X *	1. Foobar-Digest:/path/to/the/digest.input/file
X *		This file must be world-writable for sendmail to modify it.
X *		This is the address to publish for people to send digest
X *		submissions to.
X *	2. Foobar-Digest-Request:yourlogin
X *		This is the address for people to use to ask to be added
X *		or deleted from the list.
X *	3. Foobar-List: :include:/path/to/list/of/recipients
X *		This is the list of people who receive the digest.  It should
X *		be a list of addresses of the format:
X *
X *			name, name, name, name,
X *				name, name, name
X *
X *		Continuation lines should start with whitespace.
X *
X * There is one problem with the sorting of messages by subject line to get
X * all the same topic together.  The code handles elimination of "Re:"
X * strings, but if someone changes the subject on you, then things get ugly.
X * This shouldn't happen too often, though.
X *
X * Special thanks to Jon Solomon who sent me his TELECOM digest generating
X * program.  I swiped a lot of ideas from it in writing this one.
X *
X * David A. Curry
X * davy@intrepid.ecn.purdue.edu
X */
X#include <sys/types.h>
X#include <sys/timeb.h>
X#include <sys/time.h>
X#include <ctype.h>
X#include <stdio.h>
X
X#define HEAD1		27		/* Field width of first third	*/
X#define HEAD2		20		/* Field width of second third	*/
X#define HEAD3		21		/* Field width of last third	*/
X#define DATELEN		16		/* Amount of date to put in hdr	*/
X#define LINELEN		70		/* Length of an average line	*/
X#define MAXMSGS		64		/* Maximum number of msgs/digest*/
X#define LINESIZE	256		/* Maximum line size		*/
X#define LISTINFO	"digest.info"	/* Information file name	*/
X#define LISTHEAD	"digest.head"	/* Header for top of digest	*/
X#define LISTINPUT	"digest.input"	/* Input file name		*/
X#define LISTOUTPUT	"digest.output"	/* Output file name		*/
X
X/*
X * Message structure.  We read through the input file and fill one of
X * these in for each message.  The To, Cc, From, Date, and Subject
X * point to the fields of the same names from the message.  The
X * "sortstring" is a copy of the subject string with all whitespace
X * deleted and all letters in lower case.  The messageaddr is the
X * seek position in the file where the message body starts, and
X * messagelength is how long the message is.
X */
Xstruct message {
X	char *Date;
X	char *From;
X	char *Subject;
X	char *MessageID;
X	char *ReprintFrom;
X	char *sortstring;
X	long messageaddr;
X	long messagelength;
X	int  use_re;
X} messages[MAXMSGS];
X
X/*
X * List structure.  Contains the information from the LISTINFO file.
X */
Xstruct listinfo {
X	char *Title;
X	char *Host;
X	char *From;
X	char *To;
X	char *Volline;
X	char *Dateline;
X} listinfo;
X
XFILE *input;
XFILE *output;
X
Xint issue_number;			/* The number of this issue	*/
Xint nmessages = 0;			/* Number of messages		*/
Xint digestsize = 0;			/* Size of digest in bytes	*/
X
Xchar digestsubject[100];
X
Xchar *index(), *malloc(), *safter(), *nospace(), *getline();
X
Xmain()
X{
X	/*
X	 * Read the list information file and update the
X	 * issue number and date strings.
X	 */
X	get_list_info();
X	inc_volume_and_date();
X
X	printf("Assembling %s Digest %s (%.*s)\n", listinfo.Title, listinfo.Volline, DATELEN, listinfo.Dateline);
X	printf("Scanning and sorting messages for topic lines.\n");
X
X	/*
X	 * Scan the message file for subject strings and
X	 * sort the messages to get all the messages for
X	 * each topic next to each other.
X	 */
X	scan_messages();
X	sort_messages();
X
X	printf("Writing %s Digest to \"%s\"\n", listinfo.Title, LISTOUTPUT);
X
X	/*
X	 * Print the digest header, put the messages
X	 * in the digest.
X	 */
X	do_digest_header();
X	read_messages();
X
X	printf("The digest is %d characters long in %d messages.\n", digestsize, nmessages);
X
X	/*
X	 * Put out the new list information.
X	 */
X	put_list_info();
X}
X
X/*
X * get_list_info - reads in the LISTINFO file.
X */
Xget_list_info()
X{
X	FILE *fp;
X	int incomplete;
X
X	if ((fp = fopen(LISTINFO, "r")) == NULL) {
X		printf("digest: cannot open \"%s\" for reading.\n", LISTINFO);
X		exit(1);
X	}
X
X	incomplete = 0;
X
X	if ((listinfo.Title = getline(fp)) == NULL)
X		incomplete++;
X	if ((listinfo.Host = getline(fp)) == NULL)
X		incomplete++;
X	if ((listinfo.From = getline(fp)) == NULL)
X		incomplete++;
X	if ((listinfo.To = getline(fp)) == NULL)
X		incomplete++;
X	if ((listinfo.Volline = getline(fp)) == NULL)
X		incomplete++;
X	if ((listinfo.Dateline = getline(fp)) == NULL)
X		incomplete++;
X
X	fclose(fp);
X
X	/*
X	 * Error-check.  Not too sophisicated, but then you're
X	 * supposed to know what you're doing anyway.
X	 */
X	if (incomplete) {
X		printf("digest: incomplete or badly formatted \"%s\" file.\n", LISTINFO);
X		printf("Proper format:\n");
X		printf("\tTitle\n\tHost\n\tFrom\n\tTo\n\tVolline\n\tDateline\n");
X		exit(1);
X	}
X}
X
X/*
X * inc_volume_and_date - update the volume/issue string and get a new date.
X */
Xinc_volume_and_date()
X{
X	char *msgdate();
X	register char *volline, *colon;
X
X	if ((volline = malloc(strlen(listinfo.Volline)+5)) == NULL) {
X		printf("digest: out of memory.\n");
X		exit(1);
X	}
X
X	/*
X	 * Volume numbers get changed by hand.
X	 */
X	issue_number = atoi(safter(listinfo.Volline, " Issue ")) + 1;
X
X	if ((colon = index(listinfo.Volline, ':')) != NULL)
X		*colon = NULL;
X
X	sprintf(volline, "%s: Issue %3d", listinfo.Volline, issue_number);
X	strcpy(listinfo.Volline, volline);
X
X	/*
X	 * Get a new date.
X	 */
X	listinfo.Dateline = msgdate();
X
X	free(volline);
X}
X
X/*
X * msgdate - produce a new date string.  Format is
X *
X *		Day, dd Mon yy hh:mm:ss tzn
X */
Xchar *msgdate()
X{
X	char *timezone();
X	struct timeb tbuf;
X	register struct tm *t;
X	struct tm *localtime();
X	static char datebuf[64];
X	char *days = "SunMonTueWedThuFriSat";
X	char *months = "JanFebMarAprMayJunJulAugSepOctNovDec";
X	int n; char tzsign; int tzhours, tzmins;
X
X	ftime(&tbuf);
X	t = localtime(&(tbuf.time));
X
X	n = tbuf.timezone; if (t->tm_isdst) n -= 60;
X	if (n > 0) tzsign = '-';
X	else       tzsign = '+', n = -n;
X	tzhours = n / 60; tzmins  = n % 60;
X
X	sprintf(datebuf,
X		"%3.3s, %2d %3.3s %04d %02d:%02d:%02d %c%02d%02d (%3.3s)",
X		&days[3 * t->tm_wday], t->tm_mday,
X		&months[3 * t->tm_mon],	t->tm_year + 1900,
X		t->tm_hour, t->tm_min, t->tm_sec,
X		tzsign, tzhours, tzmins,
X		timezone(tbuf.timezone, t->tm_isdst));
X
X	/* remove space if day of the month is between 1 and 9 */
X	if (datebuf[5] == ' ')
X	    strcpy (datebuf+5, datebuf+6);
X
X	return(datebuf);
X}
X
X/*
X * getline - read a line into a dynamically allocated buffer.
X */
Xchar *getline(fp)
XFILE *fp;
X{
X	register int c;
X	register char *str, *str_begin;
X
X	if ((str = malloc(LINESIZE)) == NULL) {
X		printf("digest: out of memory.\n");
X		exit(1);
X	}
X
X	str_begin = str;
X
X	while (((str - str_begin) < (LINESIZE - 1)) &&
X	       ((c = getc(fp)) != '\n') && (c != EOF))
X		*str++ = c;
X	*str++ = NULL;
X
X	if (c == EOF)
X		return(NULL);
X
X	return(str_begin);
X}
X
X/*
X * scan_messages - scans through LISTINPUT reading in header fields
X *		   and marking the beginning and ending of messages.
X *
X * NOTE: some of the code here depends on the UNIX mail header format.
X *       This format simply guarantees that the first line of a message's
X *	 header will be "From blah-blah-blah".  Note there is no colon
X *	 (`:') on the "From", the real "From:" line is farther down in
X *	 the headers.
X */
Xscan_messages()
X{
X	register long n;
X	register char *s;
X
X	if ((input = fopen(LISTINPUT, "r")) == NULL) {
X		printf("digest: cannot open \"%s\" for reading.\n", LISTINPUT);
X		exit(1);
X	}
X
X	/*
X	 * We break out of this from inside.
X	 */
X	for (;;) {
X		if (nmessages >= MAXMSGS) {
X			printf("digest: too many messages.\n");
X			exit(1);
X		}
X
X		/*
X		 * Find the start of the next message.
X		 */
X		do {
X			/*
X			 * If we hit EOF, mark the length of the
X			 * previous message and go back.
X			 */
X			if ((s = getline(input)) == NULL) {
X				n = ftell(input);
X				n = n - messages[nmessages - 1].messageaddr;
X				messages[nmessages - 1].messagelength = n;
X				return;
X			}
X		} while (strncmp(s, "From ", 5) != 0);
X
X		/*
X		 * If we have found another message, mark the
X		 * length of the previous message.
X		 */
X		if (nmessages) {
X			n = ftell(input);
X			n = n - (strlen(s) + 1);
X			n = n - messages[nmessages - 1].messageaddr;
X			messages[nmessages - 1].messagelength = n;
X		}
X
X		/*
X		 * Read in the headers.
X		 */
X		for (;;) {
X			/*
X			 * We shouldn't hit EOF here, we should
X			 * at least finish the headers first.
X			 */
X			if ((s = getline(input)) == NULL) {
X				printf("digest: \"%s\": unexpected EOF.\n", LISTINPUT);
X				exit(1);
X			}
X
X			/*
X			 * Blank line terminates headers.
X			 */
X			if (*s == NULL)
X				break;
X
X			/*
X			 * Save certain headers.  We strip the
X			 * header name and leading whitespace.
X			 */
X			if (strncmp(s, "Message-ID:", 11) == 0) {
X				messages[nmessages].MessageID = nospace(safter(s, "Message-ID:"));
X			}
X			else if (strncmp(s, "Message-Id:", 11) == 0) {
X				messages[nmessages].MessageID = nospace(safter(s, "Message-Id:"));
X			}
X			else if (strncmp(s, "From:", 5) == 0) {
X				messages[nmessages].From = nospace(safter(s, "From:"));
X			}
X			else if (strncmp(s, "Newsgroups:", 11) == 0) {
X				messages[nmessages].ReprintFrom = nospace(safter(s, "Newsgroups:"));
X			}
X			else if (strncmp(s, "Date:", 5) == 0) {
X				messages[nmessages].Date = nospace(safter(s, "Date:"));
X			}
X			else if (strncmp(s, "Subject:", 8) == 0) {
X				s = nospace(safter(s, "Subject:"));
X
X				/*
X				 * We don't need the "Re:" stuff.
X				 */
X				messages[nmessages].use_re = 0;
X				while ((strncmp(s, "re:", 3) == 0) || (strncmp(s, "Re:", 3) == 0) ||
X				       (strncmp(s, "RE:", 3) == 0) || (strncmp(s, "rE:", 3) == 0)) {
X					messages[nmessages].use_re = 1;
X				    	s += 3;
X					s = nospace(s);
X				}
X
X				messages[nmessages].Subject = s;
X			}
X			else {
X				/*
X				 * If we aren't saving this line,
X				 * give the memory back.
X				 */
X				free(s);
X			}
X		}
X
X		/*
X		 * The message starts after the header.
X		 */
X		messages[nmessages].messageaddr = ftell(input);
X		nmessages++;
X	}
X}
X
X/*
X * sort_messages - convert each message's subject line to a string
X *		   all in lower case with no whitespace.  Then sort
X *		   the messages on this string.  This will group
X *		   all the messages on the same subject together.
X */
Xsort_messages()
X{
X	register int i;
X	extern int comp();
X	register char *s, *t;
X
X	for (i=0; i < nmessages; i++) {
X		/*
X		 * Skip messages with no subject.
X		 */
X		if (messages[i].Subject == NULL)
X			continue;
X
X		s = messages[i].Subject;
X
X		if ((t = malloc(strlen(s)+1)) == NULL) {
X			printf("digest: out of memory.\n");
X			exit(1);
X		}
X
X		messages[i].sortstring = t;
X
X		/*
X		 * Zap leading whitespace.
X		 */
X		s = nospace(s);
X
X		/*
X		 * Copy the subject string into sortstring
X		 * converting upper case to lower case and
X		 * ignoring whitespace.
X		 */
X		while (*s) {
X			if ((*s == ' ') || (*s == '\t')) {
X				s++;
X				continue;
X			}
X
X			if (isupper(*s))
X				*t++ = tolower(*s);
X			else
X				*t++ = *s;
X
X			s++;
X		}
X
X		*t = NULL;
X	}
X
X	/*
X	 * Sort 'em.
X	 */
X	qsort(messages, nmessages, sizeof(struct message), comp);
X}
X
X/*
X * comp - comparison routine for qsort.  Meassges with no subject go
X *	  at the end of the digest, messages with "administrivia" as
X *	  the subject go to the top of the digest.
X */
Xcomp(m1, m2)
Xregister struct message *m1, *m2;
X{
X	int admin1, admin2;
X
X	if (m1->sortstring == NULL) {
X		if (m2->sortstring == NULL)
X			return(0);
X		return(1);		/* no subject messages to end */
X	}
X
X	if (m2->sortstring == NULL)
X		return(-1);		/* no subject messages to end */
X
X	admin1 = strncmp(m1->sortstring, "administrivia", 13);
X	admin2 = strncmp(m2->sortstring, "administrivia", 13);
X
X	if (admin1 == 0) {
X		if (admin2 == 0)
X			return(0);
X		return(-1);		/* administrivia to beginning */
X	}
X
X	if (admin2 == 0)
X		return(1);		/* administrivia to beginning */
X
X	return(strcmp(m1->sortstring, m2->sortstring));
X}
X
X/*
X * do_digest_header - prints the digest header and mailer headers.
X */
Xdo_digest_header()
X{
X	FILE *fp;
X	char *laststr;
X	char buf[BUFSIZ];
X	char tmp[LINESIZE];
X	extern int comp2();
X	register int i, j, length;
X	char *c;
X
X	if ((output = fopen(LISTOUTPUT, "w")) == NULL) {
X		printf("digest: cannot create \"%s\"\n", LISTOUTPUT);
X		exit(1);
X	}
X
X	digestsize = 0;
X
X	/*
X	 * Mailer headers.
X	 */
X	sprintf(buf, "Date: %s\n", listinfo.Dateline);
X	digestsize += strlen(buf);
X	fputs(buf, output);
X
X	sprintf(buf, "From: %s\n", listinfo.From);
X	digestsize += strlen(buf);
X	fputs(buf, output);
X
X	sprintf(buf, "Reply-To: %s@%s\n", listinfo.Title, listinfo.Host);
X	digestsize += strlen(buf);
X	fputs(buf, output);
X
X	strcpy (tmp, listinfo.Volline);
X	for (c = tmp; *c != 0 && *c != ':'; c++) ;
X	do { *c-- = 0; } while (c >= tmp && *c == ' ');
X	do { c--; } while (c >= tmp && *c != ' ');
X	c++;
X	digestsize += 9; fputs ("Subject: ", output);
X	sprintf(digestsubject, "%s Digest V%s #%d",
X		listinfo.Title, c, issue_number);
X	digestsize += strlen(digestsubject);
X	fputs(digestsubject, output);
X	digestsize++, putc ('\n', output);
X
X	sprintf(buf, "To: %s\n", listinfo.To);
X	digestsize += strlen(buf);
X	fputs(buf, output);
X
X	/*
X	 * The digest header.
X	 */
X	sprintf(tmp, "%s Digest", listinfo.Title);
X	sprintf(buf, "\n\n%-*.*s %-*.*s %-*.*s\n\n",
X				HEAD1, HEAD1, tmp,
X				HEAD2, DATELEN, listinfo.Dateline,
X				HEAD3, HEAD3, listinfo.Volline);
X	digestsize += strlen(buf);
X	fputs(buf, output);
X
X	sprintf(buf, "Today's Topics:\n");
X	digestsize += strlen(buf);
X	fputs(buf, output);
X
X	/*
X	 * Do today's topics lines.
X	 */
X	laststr = "";
X	for (i=0; i < nmessages; i++) {
X		/*
X		 * No topic.
X		 */
X		if (messages[i].Subject == NULL)
X			continue;
X
X		laststr = messages[i].sortstring;
X
X		/*
X		 * Count the number of messages with this topic.
X		 */
X		j = 1;
X		while (((i + j) < nmessages)
X			&& (messages[i+j].sortstring != NULL)
X			&& (strcmp(laststr, messages[i+j].sortstring) == 0))
X			j++;
X
X		/*
X		 * Print the topic centered on the line.
X		 */
X		if (j > 1) {
X			sprintf(tmp, "%s (%d msgs)", messages[i].Subject, j);
X			length = (LINELEN / 2) + (strlen(tmp) / 2);
X			sprintf(buf, "%*s\n", length, tmp);
X
X			/*
X			 * Sort messages with same topic into their
X			 * original arrival order.
X			 */
X			qsort(&messages[i], j, sizeof(struct message), comp2);
X			i += (j - 1);
X		}
X		else {
X			length = (LINELEN / 2) + (strlen(messages[i].Subject) / 2);
X			sprintf(buf, "%*s\n", length, messages[i].Subject);
X		}
X
X		digestsize += strlen(buf);
X		fputs(buf, output);
X	}
X
X	/*
X	 * Read the LISTHEAD file, if there is one.
X	 */
X	if ((fp = fopen(LISTHEAD, "r")) != NULL) {
X		putc('\n', output);
X		digestsize++;
X
X		while (fgets(buf, BUFSIZ, fp) != NULL) {
X			digestsize += strlen(buf);
X			fputs(buf, output);
X		}
X
X		fclose(fp);
X		putc('\n', output);
X	}
X
X	/*
X	 * Print a line of dashes.
X	 */
X	for (i=0; i < LINELEN; i++) {
X		putc('-', output);
X		digestsize++;
X	}
X
X	fputs("\n\n", output);
X	digestsize += 2;
X}
X
X/*
X * comp2 - comparison routine for second qsort.  This one simply compares
X *	   messages addresses in the input file, so that we can sort the
X *	   messages with the same topic back into the order they arrived.
X */
Xcomp2(m1, m2)
Xregister struct message *m1, *m2;
X{
X	return(m1->messageaddr - m2->messageaddr);
X}
X
X/*
X * read_messages - reads in the message texts and puts them in the
X *		   digest with their headers.
X */
Xread_messages()
X{
X	char buf[BUFSIZ];
X	register char *s, *t;
X	register int i, length;
X	int linestart;
X
X	for (i=0; i < nmessages; i++) {
X		/*
X		 * Just in case.
X		 */
X		clearerr(input);
X
X		/*
X		 * Put the message's headers back in.
X		 */
X		sprintf(buf, "Date: %s\n", messages[i].Date);
X		digestsize += strlen(buf);
X		fputs(buf, output);
X
X		sprintf(buf, "From: %s\n", messages[i].From);
X		digestsize += strlen(buf);
X		fputs(buf, output);
X
X		if (messages[i].Subject != NULL) {
X			sprintf(buf, "Subject: %s%s\n",
X				(messages[i].use_re ? "Re: " : ""),
X				messages[i].Subject);
X			digestsize += strlen(buf);
X			fputs(buf, output);
X		}
X
X		if (messages[i].MessageID != NULL) {
X			sprintf(buf, "Message-ID: %s\n", messages[i].MessageID);
X			digestsize += strlen(buf);
X			fputs(buf, output);
X		}
X
X		if (messages[i].ReprintFrom != NULL) {
X		    sprintf (buf, "\nReprintFrom: %s\n", messages[i].ReprintFrom);
X		    digestsize += strlen(buf);
X		    fputs (buf, output);
X		}
X
X		putc ('\n', output); digestsize++;
X
X		/*
X		 * Read the message into memory.  This is
X		 * so we can zap extra blank lines.
X		 */
X		fseek(input, messages[i].messageaddr, 0);
X		length = messages[i].messagelength;
X
X		if ((s = malloc(length+1)) == NULL) {
X			printf("digest: out of memory.\n");
X			exit(1);
X		}
X
X		fread(s, 1, length, input);
X
X		/*
X		 * Zap trailing newlines.
X		 */
X		t = s + length;
X		while (length > 0 && *--t == '\n')
X			length--;
X		*++t = NULL;
X		
X		/*
X		 * Zap leading newlines.
X		 */
X		t = s;
X		while (*t++ == '\n')
X			length--;
X		t--;
X
X		/*
X		 * Write the message.
X		 *
X		 * In any line which begins with 30 or more hyphens,
X		 * change the first hyphen to a space, to avoid a clash
X		 * with the message separator string.
X		 */
X		digestsize += length;
X		/* fwrite(t, 1, length, output); */
X		linestart = 1;
X		while (length-- > 0) {
X			if (linestart &&
X			    strncmp(t,"------------------------------",30) == 0)
X				linestart = 0, t++, putc (' ', output);
X			else {
X				linestart = (*t == '\n');
X				putc (*t++, output);
X			}
X		}
X
X		sprintf(buf, "\n\n------------------------------\n\n");
X		digestsize += strlen(buf);
X		fputs(buf, output);
X		free(s);
X	}
X
X	/*
X	 * All done.
X	 */
X	sprintf(buf, "End of %s\n******************************",
X		digestsubject);
X	digestsize += strlen(buf);
X	fputs(buf, output);
X	for (i = strlen (digestsubject) + 7; i > 30; i--)
X	    digestsize++, putc ('*', output);
X	digestsize++, putc ('\n', output);
X	fclose(output);
X	fclose(input);
X}
X
X/*
X * put_list_info - rewrite the LISTINFO file with the new data.
X */
Xput_list_info()
X{
X	FILE *fp;
X	char tmp[LINESIZE];
X
X	sprintf(tmp, "%s.old", LISTINFO);
X
X	if (rename(LISTINFO, tmp) < 0) {
X		printf("digest: cannot move old \"%s\" file, today's data lost.\n", LISTINFO);
X		return;
X	}
X
X	if ((fp = fopen(LISTINFO, "w")) == NULL) {
X		printf("digest: cannot create \"%s\", today's data lost.\n", LISTINFO);
X		return;
X	}
X
X	fprintf(fp, "%s\n", listinfo.Title);
X	fprintf(fp, "%s\n", listinfo.Host);
X	fprintf(fp, "%s\n", listinfo.From);
X	fprintf(fp, "%s\n", listinfo.To);
X	fprintf(fp, "%s\n", listinfo.Volline);
X	fprintf(fp, "%s\n", listinfo.Dateline);
X
X	fclose(fp);
X	unlink(tmp);
X}
X
X/*
X * safter - return a pointer to the position in str which follows pat.
X */
Xchar *safter(str, pat)
Xregister char *str, *pat;
X{
X	register int len;
X
X	len = strlen(pat);
X
X	while (*str) {
X		if (strncmp(str, pat, len) == 0) {
X			str += len;
X			return(str);
X		}
X
X		str++;
X	}
X
X	return(NULL);
X}
X
X/*
X * nospace - advance s over leading whitespace, return new value.
X */
Xchar *nospace(s)
Xregister char *s;
X{
X	while ((*s != NULL) && ((*s == ' ') || (*s == '\t')))
X		s++;
X
X	return(s);
X}
X
END_OF_FILE
if test 20528 -ne `wc -c <'MailServ/src/orig-dig/digest.c'`; then
    echo shar: \"'MailServ/src/orig-dig/digest.c'\" unpacked with wrong size!
fi
# end of 'MailServ/src/orig-dig/digest.c'
fi
if test -f 'MailServ/src/orig-dig/undigest.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'MailServ/src/orig-dig/undigest.c'\"
else
echo shar: Extracting \"'MailServ/src/orig-dig/undigest.c'\" \(10974 characters\)
sed "s/^X//" >'MailServ/src/orig-dig/undigest.c' <<'END_OF_FILE'
X/*
X * UNDIGEST
X *
X *     A filter program to split "digest" messages (formatted according
X *     to the de-facto standard, RFC 1153) into their component parts.
X *
X *     (C) Copyright 1991, 1992 Richard B. Wales.  All Rights Reserved.
X *     Permission is granted to use this program for any purpose, so
X *     long as this copyright notice is retained intact, this original
X *     source code (or a modified source with the changes clearly indi-
X *     cated as such) is included as part of any distribution, and no
X *     fee (other than a nominal communications charge) is assessed.
X *
X * DESCRIPTION
X *
X *     This program reads the standard input and writes to the standard
X *     output.  Or, when invoked with a "-d" flag and a user name, it
X *     reads from the standard input and appends its output to the
X *     user's incoming mailbox file in /usr/spool/mail.
X *
X *     The input is expected to be in the UNIX-style mailbox format
X *     (with a "From " line at the start of every message).  Messages
X *     which are not in "digest" format are copied to the standard
X *     output without change.  Digests are split into their component
X *     messages on the standard output.
X *
X *     The "From " line delimiter from the original digest message is
X *     copied unchanged to the start of each component message.  Also,
X *     any "Status:" line in the original header is copied unchanged to
X *     each component message -- replacing any "Status:" line which may
X *     already exist in a component message.
X *
X *     The "To:" line from the original digest message is added to each
X *     component message.  No attempt is made to delete an existing
X *     "To:" line in a component (though ordinarily there will be none).
X *
X *     An "X-Digest:" header line is added to each component message.
X *     This line repeats the "Subject:" information from the digest
X *     header.
X *
X *     When invoked with the "-d" option, the standard UNIX mailbox
X *     locking and "comsat" (asynchronous mail notification) procedures
X *     are adhered to.  Thus, this program may safely be used as a mail
X *     filter in a user's ".forward" file.  For example, the author's
X *     ".forward" file looks like this:
X *
X *                 "| /valeria/wales/bin/undigest -d wales"
X *
X *     This program has been successfully compiled and tested under the
X *     SunOS 4.1.1 operating system and "cc" compiler.  It may require
X *     modification to work in other environments.
X *
X * THINGS TO DO
X *
X *     Extra blank lines seem to get added to the ends of the component
X *     messages within a digest.  It would be nice to fix this.
X *
X *     The user interface could (should?) be changed to make delivery
X *     ("-d username") mode the default.
X */
X
X#include <stdio.h>
X#include <sys/file.h>
X#include <sys/errno.h>
X#include <sys/types.h>
X#include <sys/socket.h>
X#include <netinet/in.h>
X
X/*
X * Digest header info, to be inserted into component messages.
X */
X#define LINELEN 1024			/* hopefully adequate */
Xchar	D_unixfrom[LINELEN];		/* "From " line */
Xchar	D_to[LINELEN];			/* "To:" line */
Xchar	D_xdigest[LINELEN];		/* "X-Digest:" line */
Xchar	D_status[LINELEN];		/* "Status:" line */
X
X/*
X * Digest processing status flag.
X */
X#define FIRST_LINE	0		/* first line of input */
X#define NON_DIGEST_HDR	1		/* non-digest (header) */
X#define NON_DIGEST_BODY 2		/* non-digest (body) */
X#define DIGEST_PREAMBLE 3		/* digest (preamble) */
X#define END_PREAMBLE	4		/* end of preamble seen */
X#define COMPONENT_HDR	5		/* component message (header) */
X#define COMPONENT_BODY	6		/* component message (body) */
X#define END_COMPONENT	7		/* end of component seen */
Xint	state;
X
X
X/*
X * Read a line of up to "len-1" characters into a buffer.  The newline
X * character at the end of the line is discarded, and the line is ter-
X * minated by a null character.
X *
X * This routine will end up inserting extra newlines if the incoming
X * text contains null characters or overly long lines.
X */
Xint
Xgetline (buf, len)
X    register char *buf;
X    register int len;
X{   register int ch;
X
X    if ((ch = getchar ()) == EOF) return -1;
X    while (--len > 0 && ch != '\n' && ch != EOF && ch != 0)
X    {	*buf++ = ch;
X	ch = getchar ();
X    }
X    if (len <= 0) ungetc (ch, stdin);
X    *buf = 0;
X    return 0;
X}
X
X
X/*
X * Compare two strings in case-independent fashion.
X * Same as "strncasecmp", which doesn't seem to exist on the Suns.
X */
Xint
Xcstrncmp (s1, s2, len)
X    register char *s1, *s2;
X    register int len;
X{   register int n1, n2;
X
X    while (len-- > 0)
X    {	n1 = *s1++; n2 = *s2++;
X	if (n1 == 0 && n2 == 0) return 0;
X	if (n1 >= 'A' && n1 <= 'Z') n1 -= 'A' - 'a';
X	if (n2 >= 'A' && n2 <= 'Z') n2 -= 'A' - 'a';
X	if (n1 != n2) return n1 - n2;
X    }
X    return 0;
X}
X
X/*
X * Output a null-terminated line, plus a newline.
X */
Xputline (buf)
X    register char *buf;
X{   register int ch;
X
X    while ((ch = *buf++) != 0) putchar (ch);
X    putchar ('\n');
X}
X
X/*
X * Send a message to the "comsat" daemon (asynchronous notification of
X * new mail).  This routine was copied intact from /bin/mail.
X */
Xnotifybiff (msg)
X	register char *msg;
X{   static struct sockaddr_in addr;
X    static int f = -1;
X
X    if (addr.sin_family == 0)
X    {	addr.sin_family = AF_INET;
X	addr.sin_addr.s_addr = INADDR_ANY;
X	addr.sin_port = htons(IPPORT_BIFFUDP);
X    }
X    if (f < 0)
X	f = socket(AF_INET, SOCK_DGRAM, 0);
X    sendto (f, msg, strlen (msg)+1, 0, &addr, sizeof (addr));
X}
X
X
Xmain (argc, argv)
X    int argc;
X    char **argv;
X{   register int n;
X    register char *c;
X    static char buffer[LINELEN];
X    char biffinfo[20];
X    int delivery;
X
X    /* Initialization. */
X    state         = NON_DIGEST_HDR;
X    D_unixfrom[0] = 0;
X    D_to[0]       = 0;
X    D_xdigest[0]  = 0;
X    D_status[0]   = 0;
X    delivery      = 0;
X    biffinfo[0]   = 0;
X
X    /*
X     * See if there is a "-d" flag (delivery mode).
X     * An additional argument after "-d" gives the output file name;
X     * or, if it doesn't begin with a slash, the name of the recipient
X     * (with an output file in the directory "/usr/spool/mail").
X     */
X    if (argc >= 2 && strcmp (argv[1], "-d") == 0)
X    {	delivery = 1;
X	state = FIRST_LINE;
X	if (argc >= 3)
X	{   if (argv[2][0] != '/')
X	    {	strcpy (buffer, "/usr/spool/mail/");
X		strcat (buffer, argv[2]);
X		strncpy (biffinfo, argv[2], 8);
X		biffinfo[8] = 0;
X		argv[2] = buffer;
X	    }
X	    freopen (argv[2], "a", stdout);
X	    while (flock (1, LOCK_EX) == EWOULDBLOCK) sleep (5);
X	    fseek (stdout, 0L, 2);
X    }	}
X
X    /*
X     * Save the necessary information so the user can be notified of
X     * the new mail's arrival later on via the "comsat" mechanism.
X     */
X    if (biffinfo[0] != 0)
X	sprintf (biffinfo + strlen (biffinfo),
X		 "@%ld\n", ftell (stdout));
X
X    /* Process the input. */
X    while (getline (buffer, sizeof buffer) == 0)
X    {	/*
X	 * A UNIX-style "From " line signals a new message.  Save a
X	 * copy of the line for possible use before component messages
X	 * of a digest.  In "delivery" mode, conceal a "From " line in
X	 * the body of the message by prepending a ">" to the line.
X	 */
X	if (strncmp (buffer, "From ", 5) == 0)
X	{   if (!delivery || state == FIRST_LINE)
X	    {	strcpy (D_unixfrom, buffer);
X		putline (buffer);
X		D_to[0] = 0;
X		D_xdigest[0] = 0;
X		D_status[0] = 0;
X		state = NON_DIGEST_HDR;
X	    }
X	    else
X	    {	putchar ('>');
X		putline (buffer);
X	    }
X	    continue;
X	}
X
X	/*
X	 * In "delivery" mode, if a line begins with one or more ">"s
X	 * followed by "From ", prepend another ">".
X	 */
X	if (delivery && buffer[0] == '>')
X	{   for (c = buffer; *c == '>'; c++) ;
X	    if (strncmp (c, "From ", 5) == 0)
X	    {	putchar ('>');
X		putline (buffer);
X		continue;
X	}   }
X
X	/*
X	 * An empty line -- or a line beginning with asterisks or the
X	 * words "End of" -- is ignored at the end of a digest preamble
X	 * or a component of a digest.  Any other kind of line signals
X	 * the start of a new digest component.
X	 */
X	if (state == END_PREAMBLE || state == END_COMPONENT)
X	{   if (buffer[0] == 0
X		|| cstrncmp (buffer, "End of ", 7) == 0
X		|| strncmp (buffer, "*******", 7) == 0)
X		continue;
X	    state = COMPONENT_HDR;
X	    putchar ('\n');
X	    putline (D_unixfrom);
X	    /* keep going -- no "continue;" here */
X	}
X
X	/*
X	 * A "Subject:", "To:", or "Status:" line in the header is
X	 * saved for possible future use in splitting up a digest.  In
X	 * the case of the "Subject:" line, the keyword is replaced
X	 * with the new keyword "X-Digest:".
X	 *
X	 * An empty line signals the end of the header; and the subject
X	 * line is examined to see if this is a digest.
X	 */
X	if (state == NON_DIGEST_HDR)
X	{   if (cstrncmp (buffer, "Subject:", 8) == 0)
X	    {	for (c = buffer+8; *c == ' ' || *c == '\t'; c++) ;
X		/* note that new keyword is longer than old one */
X		buffer[sizeof buffer - 3] = 0;
X		strcpy (D_xdigest, "X-Digest: ");
X		strcpy (D_xdigest + 10, c);
X	    }
X	    else if (cstrncmp (buffer, "To:", 3) == 0)
X	    {	strcpy (D_to, buffer);
X	    }
X	    else if (cstrncmp (buffer, "Status:", 7) == 0)
X	    {	strcpy (D_status, buffer);
X	    }
X	    else if (buffer[0] == 0)
X	    {	/* is the second word in the line "Digest"? */
X		c = D_xdigest + 10;
X		while (*c == ' ' || *c == '\t') c++;
X		while (*c != 0 && *c != ' ' && *c != '\t') c++;
X		while (*c == ' ' || *c == '\t') c++;
X		if (cstrncmp (c, "Digest ", 7) == 0)
X		     state = DIGEST_PREAMBLE;
X		else state = NON_DIGEST_BODY;
X	    }
X	    putline (buffer);
X	    continue;
X	}
X
X	/*
X	 * The body of a non-digest message is simply passed through.
X	 */
X	if (state == NON_DIGEST_BODY)
X	{   putline (buffer);
X	    continue;
X	}
X
X	/*
X	 * The digest preamble is passed through, until it is ended by
X	 * a line consisting of exactly 70 hyphens.
X	 */
X	if (state == DIGEST_PREAMBLE)
X	{   for (n = 70, c = buffer; n > 0 && *c == '-'; n--, c++) ;
X	    if (n != 0 || *c != 0) putline (buffer);
X	    else                   state = END_PREAMBLE;
X	    continue;
X	}
X
X	/*
X	 * A header line in a digest component is passed through,
X	 * except that any "Status:" line is deleted.  After the
X	 * end of the component header, a "To:", "X-Digest:", and
X	 * "Status:" line are added.
X	 */
X	if (state == COMPONENT_HDR)
X	{   if (buffer[0] == 0)
X	    {	if (D_to[0] != 0) putline (D_to);
X		putline (D_xdigest);
X		if (D_status[0] != 0) putline (D_status);
X		putchar ('\n');
X		state = COMPONENT_BODY;
X	    }
X	    else if (cstrncmp (buffer, "Status:", 7) != 0)
X		putline (buffer);
X	    continue;
X	}
X
X	/*
X	 * The component body is passed through, until it is ended by
X	 * a line consisting of exactly 30 hyphens.
X	 */
X	if (state == COMPONENT_BODY)
X	{   for (n = 30, c = buffer; n > 0 && *c == '-'; n--, c++) ;
X	    if (n != 0 || *c != 0) putline (buffer);
X	    else                   state = END_COMPONENT;
X	    continue;
X	}
X
X	/*NOTREACHED*/
X    }
X
X    /* Windup. */
X    if (delivery) putchar ('\n');	/* just to be sure */
X
X    /* Use the "comsat" facility to notify the mail's recipient. */
X    notifybiff (biffinfo);
X
X    /* All done. */
X    exit (0);
X}
END_OF_FILE
if test 10974 -ne `wc -c <'MailServ/src/orig-dig/undigest.c'`; then
    echo shar: \"'MailServ/src/orig-dig/undigest.c'\" unpacked with wrong size!
fi
# end of 'MailServ/src/orig-dig/undigest.c'
fi
echo shar: End of shell archive.
exit 0

-- 
Dave  ddebry@ debry@   \ "All right.  I'll get your money for you.  But
DeBry dsd.    peruvian. | if you don't get the President of the United
      es.     cs.utah.  | States on the phone, you're going to have to
      com     edu      /  answer to the Coca-Cola company."

--
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok


 
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 adyer@zarniwoop  Ukn Jun 29 00:26:11 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA24105; Tue, 29 Jun 93 00:26:10 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA24476; Mon, 28 Jun 93 21:23:45 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA10637; Mon, 28 Jun 93 21:23:35 -0700
Received: from ddsw1.mcs.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA24470; Mon, 28 Jun 93 21:23:29 -0700
Received: by genesis.mcs.com (/\==/\ Smail3.1.28.1 #28.2)
	id <m0oAX3u-000MVhC@genesis.mcs.com>; Mon, 28 Jun 93 23:12 CDT
Received: by chinet (/\==/\ Smail3.1.28.1 #28.1{chinet})
	id <m0oAWqg-0008j6C@chinet>; Mon, 28 Jun 93 22:59 CDT
Received: by zarniwoop.uucp (/\==/\ Smail3.1.24.1 #24.2)
	id <m0oAYEb-00039LC@zarniwoop.uucp>; Mon, 28 Jun 93 22:28 PDT
Message-Id: <m0oAYEb-00039LC@zarniwoop.uucp>
Date: Mon, 28 Jun 93 22:28 PDT
From: adyer@zarniwoop (Andrew Dyer)
To: riscy@pyramid.com
Subject: comments on today's batch o mail
Status: RO
X-Status: 


Several things bundled into one - here goes
-------------------------------------------------------
Re: Frame buffers - some performance numbers for dedicated X-terminals

on a 1280x1024 8bpp display with VRAM and a 33 MHz IDT 3051 we got
approx. 45K Xstones (intermediate demo H/W)

on a 1280 x1024 8bpp display with VRAM, a 64bit bit-blitter unit and a
33MHz 3051 we got approx. 125K Xstones (Pagine C2000)

on a 1280x1024 mono display with VRAM and a 33MHz IDT 3051 we got 105K
Xstones. (Pagine M2000)

A HP i960 based 8 bp 1280x1024 terminal clocked in at about 90K Xstones.
(700/RX?)

Most 680x0 based systems (with or without 34010) seem to get
somewhere between 25 and 60K Xstones.

I would like to see the dumb frame buffer, because I think you could
do most of what a 34010 can do for less.  I think an FPGA with
download capability could be just the ticket.  Download a config file
for whatever video h/w you want, and away she goes!  This could handle
generating xfer addresses, syncs, shift clocks and all those nasty
'glue logic' functions for the video system.  Have video RAM use the
same controller as the DRAM and have the video controller do DMA to
reload the off half of the VRAM shift register.  Remember that a high
res frame buffer usually uses ECL oscillators and some ECL logic, so
don't forget those in the comparison. (You gotta get the 125MHZ
somewhere :-)

a 33Mhz 3051 with a single bank of 32 bit VRAM can access 16 bytes in
13 clocks, with interleaving the number goes down to 11 clocks.
(These are from memory so there is a possibility I am off by a clock)
This gives 40Mbyes/sec memory bandwidth (peak) for a non-interleaved
system, and a 48Mbyte/sec bandwidth (peak) for an interleaved system.

The main problems with the 34010 is the 16 bit host port and trying to
synchonize the X drawing code with the rest of the system. (Not to mention 
trying to split that code out of the base system).

-----------
re floppy and hard drive interfaces:

You should be able to find a combo chip that does all things, and just
put it on it's own little slow bus (or the ISA bus :-)) and use a fast
SCSI on a tighter coupled bus for real disk performance.

-----------
re other processors:

For true 32 bit CPUS market share says i960(KA/CA/CF). 29K is usually
listed second, next Sparc, and then MIPS.  (but noone else comes in
the 84 PLCC as far as I know)

One thought that occured to me (while I stopped to wash dishes) is
that one of the LSI logic MIPS derivatives might be interesting
because of the higher integration that they have - Especially the
LR33020 which is really meant to be a X-terminal on a chip (on chip
VRAM control, on-chip bit-blit, programmable chip selects, bus sizing)
About the only thing it doesn't have would be the FPU - and there is
probably a way to add that externally.  Comes in CPGA package cost was in
the low $100 range in volume a while ago.

---------------
Legalities:

Is there anything like a GPL for hardware?  We should stop to consider
how this thing we are talking about should be made available and under
what terms.

---------------
Final topic:
This thing needs a cool code-name.  How about a few suggestions?
Perhaps something recursive?

 
From SMACKINLA@cc.curtin.edu.au  Ukn Jun 29 01:31:30 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA28019; Tue, 29 Jun 93 01:31:21 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05196; Mon, 28 Jun 93 22:29:12 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA19342; Mon, 28 Jun 93 22:28:41 -0700
Received: from cc.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04730; Mon, 28 Jun 93 22:28:23 -0700
Received: from cc.curtin.edu.au by cc.curtin.edu.au (PMDF #3256 ) id
 <01GZYA7K3RMOFUMLVJ@cc.curtin.edu.au>; Tue, 29 Jun 1993 13:27:20 +0800
Date: 29 Jun 1993 13:27:19 +0800
From: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Subject: Re: Radical video idea
To: caret@pyramid.com
Cc: riscy@pyramid.com
Message-Id: <01GZYA7K419UFUMLVJ@cc.curtin.edu.au>
X-Envelope-To: caret@pyramid.com, riscy@pyramid.com
X-Vms-To: IN%"caret@pyramid.com"
X-Vms-Cc: R3KPC,SMACKINLA
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
Status: RO
X-Status: 


>If we add a 3041 as Steve has been suggesting, why not have it
>generate all the timing signals for the video itself?  This CPU

I have only one thing to say about this idea: yuk! <grin> I would also have 
to say that personally, I wouldn't want to write the various interrupt 
handlers. Can you imagine what would happen when the thing crashed?

>For that matter, why not have it deal with the keyboard directly
>also?  The hard thing about the IBM style keybaords is that they

I think it might be better to use (if absolutely necessary) a PIC to handle 
the keyboard. It would be better to use an 8041, as in the AT, but I have 
no idea about prices.

>If the software is going to be so real time as we suggest, then
>maybe it could also do the necessary cycles to refresh DRAM.

This is getting worse and worse <grin>. Again, what happens when the 3041 
crashes? I shudder to think... Interrupt latency takes on a whole new 
meaning...

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 SMACKINLA@cc.curtin.edu.au  Ukn Jun 29 01:51:13 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA28895; Tue, 29 Jun 93 01:51:00 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA08161; Mon, 28 Jun 93 22:48:37 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA22655; Mon, 28 Jun 93 22:48:24 -0700
Received: from cc.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA07979; Mon, 28 Jun 93 22:48:08 -0700
Received: from cc.curtin.edu.au by cc.curtin.edu.au (PMDF #3256 ) id
 <01GZYAET7OMEFUMLVJ@cc.curtin.edu.au>; Tue, 29 Jun 1993 13:46:49 +0800
Date: 29 Jun 1993 13:46:48 +0800
From: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Subject: Re: What goes on a Motherboard?
To: Steven.D.Ligett@Dartmouth.EDU
Cc: riscy@pyramid.com
Message-Id: <01GZYAET7Y9KFUMLVJ@cc.curtin.edu.au>
X-Envelope-To: riscy@pyramid.com
X-Vms-To: IN%"Steven.D.Ligett@Dartmouth.EDU"
X-Vms-Cc: R3KPC,SMACKINLA
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
Status: RO
X-Status: 


>Let's assume that we're designing a motherboard that will have some sort of
>I/O bus.  Then, I think that we want to put as little on the motherboard as
>we can, so it'll be cheaper and easier to design.  What HAS to go on the
>motherboard?  High-bandwidth things.  Low latency things.  Things to make it
>easier to get the motherboard going.  Just enough to make the board useful. 
>Little else.  The more things we leave off, the better.  My list has

I personally agree with Steve's list here.

>Some would argue that the last two aren't needed on the motherboard.  Some
>would argue that ethernet is needed.  Ethernet doesn't need much bandwidth.

Again, I agree with this. To me, Ethernet isn't really a big deal. I think 
we would be better off attaching any Ethernet devices to whatever I/O bus 
we use - as Steve says, Ethernet isn't a high bandwidth device, and doesn't 
really "deserve" to be on the motherboard.

>I thought that a 3041 (a little 3051 w multiple bus width support) should run
>the I/O bus.  The 3041 could also be the graphics accelerator.

This is my only real gripe with Steve's suggestion - I'd prefer to use a 
"dedicated" I/O chip like the 3730 (or possibly the C&T thing?) to drive 
the slower I/O devices. Seeing as we have to have a DRAM controller anyhow, 
I think it'd be better to use a single device to handle both DRAM and I/O. 

A second processor will bring a couple of its own problems into the deal, 
and I don't really think the payoff is worth it. I think the main CPU will 
be perfectly capable of dealing with the interrupt latency and bandwidth 
requirements of the I/O chips - it _is_ a 35 MIPS chip...

I would much rather see a more "conventional" design, using one of the I/O 
chips that have been suggested, the 3730 or the C&T thing (the one Neil's 
looking at). Because they're specifically targetted at this type of system, 
they will be pretty easy to use and integrate, I'd imagine, and think they 
would be the most cost-effective way of doing I/O. The other important 
point is that these chips have DRAM control as well, which has to be 
implemented somewhere. One other advantage is that they're going to take up 
very little board space and reduce the time needed to design the board.

Steve: think "toaster"... <grin>

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 broadley@neurocog.lrdc.pitt.edu  Ukn Jun 29 01:55:34 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA29043; Tue, 29 Jun 93 01:55:32 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA08884; Mon, 28 Jun 93 22:53:18 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA23215; Mon, 28 Jun 93 22:53:13 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA08880; Mon, 28 Jun 93 22:53:08 -0700
Message-Id: <9306290553.AA08880@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA26843; Tue, 29 Jun 93 01:52:38 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Design Criteria for motherboard
To: riscy@pyramid.com (Mips 3000)
Date: Tue, 29 Jun 1993 01:52:38 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 4227      
Status: RO
X-Status: 

In the design of the motherboards we have to consider that we have a finite
amount of engineering talent, money, board space, and time.  Complexity
had a direct effect on all of the above.

To maximize (performance+reliability)/price for the motherboard we should 
minimize chip counts, board surface area, and things that would be cheaper 
in volumes we can't produce.  

I think the inadequacies of the average 486 motherboard are driving this
project.   The most important of these being the cpu (we are replacing),
and the ISA bus (which we are augmenting).

I believe that way to much is making it onto the board.  The only things
that should make it should satisfy one of three requirements:  
	High enough bandwidth to me limited by ISA (appoximate 5 Mb/sec ?). 
	Need to address memory over 16 MB (isa can't)
	Much cheaper to put on the motherboard then on a ISA card.
	Necessary to debug/boot the card.

The reason that NOTHING else should be one the is because we have limited
resources:
	Board space is expensive and finite.  
	For each thing we add to the motherboard adds to: cost, design time,
assembly time, debugging time, probability of errors.   
	We aren't paying for an engineer's time (thanks!!!), but they have a 
finite amount of time.  I'd rather see the big things get all the attention 
rather then serial ports, sounds, parallel, Dsp's, etc.  The integrations
of all the possible features sounds non-trivial to me.

	I consider designing a integrated cpu+memory system+isa+scsi+
video quite an achievement under our budget/manpower.  Entire corperations
make there living on just video or scsi.  Maybe I have a misconception on
how hard it it to make an accelerated video card.

	If we put every thing that doesn't meet the above on isa cards
we protect ourselves against bugs, make the design simpler and get the
boards quicker, cheaper, and maybe use isa cards we already have (GASP).

	I want the best designed, bug free, reliable motherboard as possible.
	
	On a micromint 8088 (BEFORE the ibm pc was a standard) we had to
buy an ISA card to support a IBM pc compatible keyboard. (It's wasn't a pc
compatible when I built it.)

	There are tons of IDE+floppy+2 serial+parallel isa cards out there
probably going for around $25.00 a piece (you can turn off ide if you wish)

	Wouldn't the above add more cost if integrated into motherboard? At 
what advantage? Take a non-trival amount of engineering time?  

	Maybe a secondard project to put a keyboard controller, 16552,
parallel, floppy on a ISA card would be useful (so we can get all we want
on a single isa card.)  

My interpretation of the above. 
	Video on board, video bandwidth could easily swamp ISA bus, not to
mention I wouldn't want it eating up 2 MB or so of the addressable 16 MB
of ISA address space.
	SCSI on board, disk bandwidth can easily be a large fraction of 
ISA bandwidth (if not 100%), it's cheap to add relative to ISA card.

The above 2 leave the ISA very free, so it can do the slower things well
like it was designed to.

	Ethernet on ISA, not trivial to design (there's alot of bad ones out 
there right?), we have C source to support commercial ISA ethernet cards, max
bandwidth is around 25 % of the almost empty ISA bus.  Not everyone needs
one (ok I'm biased I don't need one).  In a year or so ISDN or FDDI may
become more popular.  

	Parallel, serial, keyboard, dsp, sounds: Easily done on isa, fairly low
bandwidth.  Exceptions it maybe impractical to debug/boot a board without
a serial port/keyboard.

	Especially with the increasing completity of the video subsystem
think we should minimize the motherboard to cpu+video+scsi.  Maybe we can find 
a cheap vesa driver and just buy $200 S3 805 cards, and then put more into
the motherboard.

	I don't think we should maximize features for $700, I think
we should minimize the performance of a mips 3000 for the minimum price.  
Even $50 cheaper (reuse your ide supercard) and 1 month sooner could
make a big difference to prospective customers.

-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok


 
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.
    

 
