From owner-riscy@pyramid.com  Sun Aug  1 10:42:39 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA08228; Sun, 1 Aug 93 10:42:39 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23660; Sun, 1 Aug 93 07:41:56 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA07145; Sun, 1 Aug 93 07:39:07 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA07135; Sun, 1 Aug 93 07:39:01 -0700
Received: from dutecai.et.tudelft.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23359; Sun, 1 Aug 93 07:39:42 -0700
Received: by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA12612; Sun, 1 Aug 93 16:37:26 +0200
Date: Sun, 1 Aug 93 16:37:26 +0200
From: wolff@dutecai.et.tudelft.nl (Rogier Wolff)
Message-Id: <9308011437.AA12612@dutecai.et.tudelft.nl>
To: riscy@pyramid.com
Subject: Re:  [tim@ubitrex.mb.ca: Re: Mips Chips from NEC]
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

adyer@zarniwoop.chi.il.us
suggested to use intel 80960CA/CF chips. 
I work in a project that uses andI960 chip, thus I should know what
I am talking about. 

      DO NOT USE I960's FOR A UNIX PORT!

There are several reasons:

    the I960CA doesnt have an MMU.
    the I960CA doesn't have an FPU.

The CF adds a data cache to the CA design, but is otherwise compatible.

(Sorry if this is late, or if others have already reacted, I'm back in the
civilized world with internet for just a day or two in the middle of my 
vacation)

					Roger.
 
From owner-riscy@pyramid.com  Mon Aug  2 05:17:45 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA10992; Mon, 2 Aug 93 05:17:45 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17872; Mon, 2 Aug 93 02:14:42 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA13039; Mon, 2 Aug 93 02:13:15 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA13032; Mon, 2 Aug 93 02:13:13 -0700
Received: from genesis.mcs.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17852; Mon, 2 Aug 93 02:14:03 -0700
Received: by genesis.mcs.com (/\==/\ Smail3.1.28.1 #28.8)
	id <m0oMvt3-000ZCkC@genesis.mcs.com>; Mon, 2 Aug 93 04:08 CDT
Received: by chinet (/\==/\ Smail3.1.28.1 #28.1{chinet})
	id <m0oMvbQ-000D7CC@chinet>; Mon, 2 Aug 93 03:50 CDT
Received: by zarniwoop.chi.il.us (/\==/\ Smail3.1.24.1 #24.3)
	id <m0oMnwh-00039LC@zarniwoop.chi.il.us>; Sun, 1 Aug 93 17:40 PDT
Message-Id: <m0oMnwh-00039LC@zarniwoop.chi.il.us>
Date: Sun, 1 Aug 93 17:40 PDT
From: adyer@zarniwoop.chi.il.us (Andrew Dyer)
To: riscy@pyramid.com
Subject: i960 joke
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

>adyer@zarniwoop.chi.il.us
>suggested to use intel 80960CA/CF chips. 
>I work in a project that uses andI960 chip, thus I should know what
>I am talking about. 
>
>      DO NOT USE I960's FOR A UNIX PORT!

;-)

The suggestion was mostly a joke.  The point was that perhaps there
might be a way to craft a more desirable piece of CPU silicon into a
486 local bus mode to leverage off of the availablility of
motherboards.  It might be cool to have a daughterboard that acts like
a 486, so you could buy an existing PC motherboard sans CPU, add the
daughterboard, a few VESA cards, and voila! Instant upgrade.
Depending on the CPU this could range from impossible to merely
annoying.  Obviously this will not give top performance, nor will it
be 100% 486 compatible, but it might be feasible.  Sorry to alarm you
all...

 
From owner-riscy@pyramid.com  Tue Aug  3 02:54:17 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA27815; Tue, 3 Aug 93 02:54:17 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA29775; Mon, 2 Aug 93 23:26:46 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA19733; Mon, 2 Aug 93 23:22:59 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA19725; Mon, 2 Aug 93 23:22:56 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA29387; Mon, 2 Aug 93 23:23:47 -0700
Message-Id: <9308030623.AA29387@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA21843; Tue, 3 Aug 93 02:22:09 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Mips project Go or Wait?
To: riscy@pyramid.com (Mips 3000)
Date: Tue, 3 Aug 1993 02:22:09 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1292      
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

Seems like all we need to decide on what to do about the project is
the price of the 4000 PC and the 4200 PC to decide on which cpu to use,
and the price of parts for the arc 100/150 kits.

I heard the the approximate price of the 4000 PC is about $300.  But I don't
have any distributor contacts to check on a price.

Assuming us and Waldorf can get 50 board purchases together seems like a
good guess would be.  

$100		$5000 for the production kits, cpu's, and plans / 50 boards
		(can we get the gerber files for free as mentioned on the list?)
$300		mips 4000 PC or less for a 4200
$100		appropiate size motherboard, drilled etc.
$300		vram, sims slots, support chips (MCT-ADR, 2*MCT-DP), scsi
		support, video support, etc.
----------------------------------
$800  for 64 bit 50 Mhz external 100 Mhz internal workstation on a board.

Hopefully it could be alot cheaper.

If we can pin these numbers down we can make a decision an send our checks
to Neil, or Waldorf ,and start the process of getting the boards.

I hate seeing no discusion on the list, I'd hate to see it die.

-- 
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 owner-riscy@pyramid.com  Tue Aug  3 04:08:34 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA29640; Tue, 3 Aug 93 04:08:34 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA11858; Tue, 3 Aug 93 01:07:30 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA27126; Tue, 3 Aug 93 01:06:19 -0700
Received: from bert.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA27118; Tue, 3 Aug 93 01:06:15 -0700
Received: from mail.Germany.EU.net 
	by bertha.pyramid.com (5.67/OSx5.1a Pyramid-Internet-Gateway)
	id AA00783; Tue, 3 Aug 93 08:06:06 GMT
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id gE17096; Tue, 3 Aug 1993 10:01:37 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA07295; Tue, 3 Aug 93 09:54:08 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA24346; Tue, 3 Aug 93 09:56:35 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Tue, 3 Aug 93 09:55:37 +0200
Message-Id: <9308030755.AA04886@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA04886; Tue, 3 Aug 93 09:55:37 +0200
To: riscy@pyramid.com
Subject: Re:  Mips project Go or Wait?
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


> Seems like all we need to decide on what to do about the project is
> the price of the 4000 PC and the 4200 PC to decide on which cpu to use,
> and the price of parts for the arc 100/150 kits.

Yes, that's right, but it seems to be *very* difficult. I never had
problems to get prices from IDT, but dealing with NEC is a hard, hard,
hard job. I have still no answer to my question wether a production kit
is available now or not, nor could they tell me prices. All I know is that
NEC works on an application note, which is currently available in japanese
only. However, I'm working on getting more informations, and it would be
very helpful if someone can tell me from where the information about the
production kit came. The more information *I* have, the more I can make
the NEC people work for me !

> I heard the the approximate price of the 4000 PC is about $300.  But I don't
> have any distributor contacts to check on a price.

I think this price is a bit too optimistic, at least for now. A few weeks
ago I got a price of around us$600 for a R4000PC, but this *will* change
as soon the Orion and the R4200/VRX is available and well-known.
IDT suggested me to use the Orion, because it's pin-compatibel with
the R4000PC. That means that we could start the development with R4000 CPUs
and later plug in the Orion. Assuming that it will take some months
to get the hardware working, this might be worth a discussion. Only
a few people would need to pay for the R4000, and all others can (or will)
wait for the Orion.
However, the NEC VRX might be good choice too, but we need more informations.

> Assuming us and Waldorf can get 50 board purchases together seems like a
> good guess would be.  

Here's the corrected guess.

$100		$5000 for the production kits, cpu's, and plans / 50 boards
 		(can we get the gerber files for free as mentioned on the list?)
$600		mips 4000 PC or less for a 4200
$100		appropiate size motherboard, drilled etc.
$300		vram, sims slots, support chips (MCT-ADR, 2*MCT-DP), scsi
 		support, video support, etc.
----------------------------------
$1100  for 64 bit 50 Mhz external 100 Mhz internal workstation on a board.

or
$700   for a NEC VRX solution (estimated VRX price: $200)
or
$700   for an IDT Orion solution (estimated Orion price: $200)

> Hopefully it could be alot cheaper.

Hmm. I don't think that we can make it cheaper than $700.
That would be a miracle :-)

> If we can pin these numbers down we can make a decision an send our checks
> to Neil, or Waldorf ,and start the process of getting the boards.

> I hate seeing no discusion on the list, I'd hate to see it die.

Yes, this is what I feel. I understand that people are confused by
the discussion about what Mips-CPU we should use. But I have the
feeling that we come closer to a decision. We have currently three
choices:

- R3081/R3041
- NEC R4200 and ARCset
- IDT Orion and ARCset

I hope the discussion will awake again !

Bye,
Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Tue Aug  3 04:44:41 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA00663; Tue, 3 Aug 93 04:44:41 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16718; Tue, 3 Aug 93 01:43:39 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA01789; Tue, 3 Aug 93 01:42:32 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA01722; Tue, 3 Aug 93 01:42:24 -0700
Received: from hp750a.csc.cuhk.hk 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16655; Tue, 3 Aug 93 01:42:44 -0700
Message-Id: <9308030842.AA16655@gossip.pyramid.com>
Received: by hp750a.csc.cuhk.hk
	(16.8/16.2) id AA22371; Tue, 3 Aug 93 16:40:55 +0800
From: Stephen S M Wong <a080700@hp750a.csc.cuhk.hk>
Subject: Re:  Mips project Go or Wait?
To: riscy@pyramid.com
Date: Tue, 3 Aug 93 16:40:54 HKT
In-Reply-To: <9308030755.AA04886@resi.waldorf-gmbh.de>; from "Andreas Busse" at Aug 3, 93 9:55 am
Mailer: Elm [revision: 70.30]
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

Hi risciers,

>- R3081/R3041
>- NEC R4200 and ARCset
>- IDT Orion and ARCset

My personal preference is IDT Orion, since

1) It is R4000PC pin compatible.

2) The price of Orion will be similar to NEC R4200, and R4000PC will
   out perform R4200, can we deduce that Orion will out perform R4200?

3) Even point 2) may not hold, a superior upgrade path exists if we
   use Orion, ie. replace the CPU on the to be made board by a R4000PC, 
   and get better (at least better than R4200) performance.  WITH THE
   SAME PRICE (on CPU), why not opt for better upgrade path!

--
*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*
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 owner-riscy@pyramid.com  Tue Aug  3 08:35:13 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA06850; Tue, 3 Aug 93 08:35:13 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15659; Tue, 3 Aug 93 05:33:39 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA21083; Tue, 3 Aug 93 05:32:26 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA21076; Tue, 3 Aug 93 05:32:23 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15644; Tue, 3 Aug 93 05:33:13 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id gM29669; Tue, 3 Aug 1993 14:29:06 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA09205; Tue, 3 Aug 93 14:22:25 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA25564; Tue, 3 Aug 93 14:22:24 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Tue, 3 Aug 93 14:21:23 +0200
Message-Id: <9308031221.AA05562@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA05562; Tue, 3 Aug 93 14:21:23 +0200
To: riscy@pyramid.com
Subject: Re:  Mips project Go or Wait?
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


> >- R3081/R3041
> >- NEC R4200 and ARCset
> >- IDT Orion and ARCset
>
> My personal preference is IDT Orion, since
>
> 1) It is R4000PC pin compatible.
> 
> 2) The price of Orion will be similar to NEC R4200, and R4000PC will
>    out perform R4200, can we deduce that Orion will out perform R4200?
>
> 3) Even point 2) may not hold, a superior upgrade path exists if we
>    use Orion, ie. replace the CPU on the to be made board by a R4000PC, 
>    and get better (at least better than R4200) performance.  WITH THE
>    SAME PRICE (on CPU), why not opt for better upgrade path!

Ok, we *can* decide not to go with the R3081/3041 solution, but
we *cannot* decide now between R4200 and Orion, because we don't
know enough.
I would prefer the Orion too, but it won't be available until
end of the year. That means (I said that already), that only few
of us can start with the expensive R4000PC.

We should try tro decide between R3xxx and R4xxx solutions. If
we all agree over a R4xxx machine things will be clearer.
When we have enough information about the different flavours
of R4xxx CPUs we can decide which one to use.

Agreed ?

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Tue Aug  3 09:55:39 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA10526; Tue, 3 Aug 93 09:55:39 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA22050; Tue, 3 Aug 93 06:52:44 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA24715; Tue, 3 Aug 93 06:50:49 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA24697; Tue, 3 Aug 93 06:50:47 -0700
Received: from benoni.Uit.No 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21976; Tue, 3 Aug 93 06:51:38 -0700
Received: from benoni by ppenoni.uit.no with SMTP (PP) 
          id <18242-0@ppenoni.uit.no>; Tue, 3 Aug 1993 15:50:35 +0000
Received: from unas.tss.no 
          by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) 
          id AAbenoni18238; Tue, 3 Aug 1993 15:50:31 +0200
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA06121;
          Tue, 3 Aug 93 15:43:56 +0200
Message-Id: <9308031343.AA06121@unas.tss.no>
From: tor@tss.no (Tor Arntsen)
Date: Tue, 3 Aug 1993 15:43:54 +0200
In-Reply-To: Andreas Busse <andy@resi.waldorf-gmbh.de> "Re: Mips project Go or Wait?" (Aug 3, 2:21pm)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: riscy@pyramid.com
Subject: Re: Mips project Go or Wait?
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

On Aug 3,  2:21pm, Andreas Busse wrote:

>We should try tro decide between R3xxx and R4xxx solutions. If
>we all agree over a R4xxx machine things will be clearer.
>When we have enough information about the different flavours
>of R4xxx CPUs we can decide which one to use.
>
>Agreed ?

I would vote for R4xxx.

Tor (tor@tss.no)

(I have been on vacation for a while (still am), not following the 
 discussions.  I guess others are as well, causing the quietness on the list..)


 
From owner-riscy@pyramid.com  Tue Aug  3 10:51:35 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA13453; Tue, 3 Aug 93 10:51:35 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA29985; Tue, 3 Aug 93 07:48:35 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA27881; Tue, 3 Aug 93 07:47:21 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA27870; Tue, 3 Aug 93 07:47:19 -0700
Received: from giverny.daimi.aau.dk 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA29785; Tue, 3 Aug 93 07:48:09 -0700
Received: by giverny.daimi.aau.dk id AA10224
  (5.65c8/IDA-1.4.4 for riscy@pyramid.com); Tue, 3 Aug 1993 16:47:08 +0200
Date: Tue, 3 Aug 1993 16:47:08 +0200
From: Tommy Thorn <tthorn@daimi.aau.dk>
Message-Id: <199308031447.AA10224@giverny.daimi.aau.dk>
To: riscy@pyramid.com
Subject: Re:  Mips project Go or Wait?
References: <9308031221.AA05562@resi.waldorf-gmbh.de>
Reply-To: Tommy.Thorn@daimi.aau.dk
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

Andreas Busse writes:
 > Ok, we *can* decide not to go with the R3081/3041 solution, but
 > we *cannot* decide now between R4200 and Orion, because we don't
 > know enough.
 > I would prefer the Orion too, but it won't be available until
 > end of the year. That means (I said that already), that only few
 > of us can start with the expensive R4000PC.

With the goal of a fast and (fairly) cheap MIPS based workstation,
I'd prefer the Orion chip + ARCset too, even though it might not
arrive soon.

 > We should try tro decide between R3xxx and R4xxx solutions. If
 > we all agree over a R4xxx machine things will be clearer.
 > When we have enough information about the different flavours
 > of R4xxx CPUs we can decide which one to use.
 > 
 > Agreed ?

A design based on R3xxx is going to be obsolete soon, so let
concentrate on R4xxx.

/Tommy Thorn
 
From owner-riscy@pyramid.com  Wed Aug  4 08:24:53 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA00663; Wed, 4 Aug 93 08:24:53 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA11045; Wed, 4 Aug 93 05:24:16 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08481; Wed, 4 Aug 93 05:23:08 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08474; Wed, 4 Aug 93 05:23:06 -0700
Received: from [128.6.21.9] 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA10885; Wed, 4 Aug 93 05:24:00 -0700
Received: from eerie.acsu.buffalo.edu by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) 
	id AA12737; Wed, 4 Aug 93 08:21:41 EDT
Received: from uucp@localhost by eerie (8.5/8.1)
	 via UUCP. id IAA28285; Wed, 4 Aug 1993 08:21:38 -0400
Received: by toz.buffalo.ny.us (1.65/waf)
	via UUCP; Tue, 03 Aug 93 23:47:00 EDT
	for eerie!pyramid.com!riscy
To: riscy@pyramid.com
Subject: Re:  Mips project Go or Wait?
From: cyberman@toz.buffalo.ny.us (Cyberman)
Comments:             
Message-Id: <X0Nq8B1w165w@toz.buffalo.ny.us>
Date: Tue, 03 Aug 93 23:45:08 EDT
In-Reply-To: <9308030842.AA16655@gossip.pyramid.com>
Organization: The Tower of Zot - (716)8338-616
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

Stephen S M Wong <eerie!hp750a.csc.cuhk.hk!a080700> writes:
> 1) It is R4000PC pin compatible.
> 
> 2) The price of Orion will be similar to NEC R4200, and R4000PC will
>    out perform R4200, can we deduce that Orion will out perform R4200?
> 
> 3) Even point 2) may not hold, a superior upgrade path exists if we
>    use Orion, ie. replace the CPU on the to be made board by a R4000PC, 
>    and get better (at least better than R4200) performance.  WITH THE
>    SAME PRICE (on CPU), why not opt for better upgrade path!

These are all valid reasons.  I suggest  we determine if the "price" is 
right.  $700 is NOT bad for what one would be getting however there is
always Something that one misses :)

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 owner-riscy@pyramid.com  Wed Aug  4 08:37:52 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA01225; Wed, 4 Aug 93 08:37:52 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA02664; Wed, 4 Aug 93 03:38:35 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02944; Wed, 4 Aug 93 03:37:30 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02935; Wed, 4 Aug 93 03:37:28 -0700
Received: from boulder.Colorado.EDU 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA02652; Wed, 4 Aug 93 03:38:22 -0700
Received: from agua.Colorado.EDU by boulder.Colorado.EDU with SMTP id AA02294
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Wed, 4 Aug 1993 04:36:09 -0600
Received: by agua.colorado.edu (cu.generic.890828)
Date: Wed, 4 Aug 93 04:33:26 MDT
From: Alan Krantz <atk@agua.Colorado.EDU>
Message-Id: <9308041033.AA24379@agua.colorado.edu>
To: riscy@pyramid.com
Subject: Re: Mips project Go or Wait?
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

I'm just a customer and not a designer but i would vote for an R4200. The
other chips mainly enhance floating point and cost significantly more.
 
From owner-riscy@pyramid.com  Wed Aug  4 08:38:01 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA01255; Wed, 4 Aug 93 08:38:01 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA02994; Wed, 4 Aug 93 03:42:14 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA03198; Wed, 4 Aug 93 03:41:09 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA03191; Wed, 4 Aug 93 03:41:06 -0700
Received: from sun2.nsfnet-relay.ac.uk 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA02982; Wed, 4 Aug 93 03:41:59 -0700
Via: uk.ac.oxford.prg; Wed, 4 Aug 1993 11:40:27 +0100
Received: from ecs.oxford.ac.uk (ecs.ecs) by prg.oxford.ac.uk id AA20759;
          Wed, 4 Aug 93 11:40:16 +0100
Received: from ecs.ox.ac.uk (booth6.ecs) by ecs.oxford.ac.uk (4.1/ecs.1) 
          id AA15380; Wed, 4 Aug 93 11:41:22 BST
Received: by ecs.ox.ac.uk (4.1/ecs2.0) id AA02649; Wed, 4 Aug 93 11:41:27 BST
From: m92mjb@ecs.oxford.ac.uk
Message-Id: <9308041041.AA02649@booth6.ecs.ox.ac.uk>
Subject: UNSUBCRIBE
To: riscy@pyramid.com
Date: Wed, 4 Aug 93 11:41:27 BST
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

Please unsubcribe me from this mailing list.

m92mjb@ecs.ox.ac.uk
 
From owner-riscy@pyramid.com  Wed Aug  4 08:38:03 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA01273; Wed, 4 Aug 93 08:38:03 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05531; Wed, 4 Aug 93 04:15:27 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA05754; Wed, 4 Aug 93 04:14:19 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA05747; Wed, 4 Aug 93 04:14:16 -0700
Received: from rrzs1.rz.uni-regensburg.de 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05506; Wed, 4 Aug 93 04:15:09 -0700
Received: from rrzc1.rz.uni-regensburg.de (rrzc3.rz.uni-regensburg.de) by rrzs1.rz.uni-regensburg.de (4.1/URRZ-relay (1.3))
	id AA18878; Wed, 4 Aug 93 13:12:46 +0200
Received: by rrzc1.rz.uni-regensburg.de (4.1/URRZ-sub (1.3))
	id AA20220; Wed, 4 Aug 93 13:13:06 +0200
Date: Wed, 4 Aug 93 13:13:06 +0200
From: Jens Decker <c5093@rrzc1.rz.uni-regensburg.de>
Message-Id: <9308041113.AA20220@rrzc1.rz.uni-regensburg.de>
To: riscy@pyramid.com
Subject: Re: Mips project Go or Wait?
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

IMHO enhanced floating point performance is the main reason for such a 
project.

Jens Decker, University of Regensburg

 
From owner-riscy@pyramid.com  Wed Aug  4 08:38:07 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA01303; Wed, 4 Aug 93 08:38:07 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28774; Wed, 4 Aug 93 02:49:13 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA28769; Wed, 4 Aug 93 02:47:31 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA28759; Wed, 4 Aug 93 02:47:24 -0700
Received: from cs.huji.ac.il 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28515; Wed, 4 Aug 93 02:48:04 -0700
Received: from picton.cs.huji.ac.il by cs.huji.ac.il with SMTP id AA19542
  (5.65b/HUJI 4.114); Wed, 4 Aug 93 12:45:43 +0300
Received: from localhost by picton.cs.huji.ac.il with SMTP id AA13170
  (5.65c/HUJI 4.121 for <riscy@pyramid.com>); Wed, 4 Aug 1993 12:46:47 +0300
Message-Id: <199308040946.AA13170@picton.cs.huji.ac.il>
To: riscy@pyramid.com
Subject: Re: Mips project Go or Wait? 
In-Reply-To: Your message of Tue, 3 Aug 93 14:21:23 +0200 .
             <9308031221.AA05562@resi.waldorf-gmbh.de> 
From: Amos Shapira <amoss@cs.huji.ac.il>
Date: Wed, 04 Aug 1993 12:46:44 +0300
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

In message <9308031221.AA05562@resi.waldorf-gmbh.de> you write:
|We should try tro decide between R3xxx and R4xxx solutions. If
|we all agree over a R4xxx machine things will be clearer.
|When we have enough information about the different flavours
|of R4xxx CPUs we can decide which one to use.
|
|Agreed ?

You allready had my vote for an R4xxx solution and from what I read since then
I might even support the Orion too.  Certainly not the R3xxx as it seems quite
clear that it is going to be "out" soon.

Cheers,

--Amos

--Amos Shapira (Jumper Extraordinaire) |  "It is true that power corrupts,
C.S. System Group, Hebrew University,  |   but absolute power is better!"
Jerusalem 91904, ISRAEL                |
amoss@cs.huji.ac.il                    |          -- the Demon to his son
 
From owner-riscy@pyramid.com  Wed Aug  4 09:52:26 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA04866; Wed, 4 Aug 93 09:52:26 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15704; Wed, 4 Aug 93 06:51:38 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA12779; Wed, 4 Aug 93 06:50:13 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA12772; Wed, 4 Aug 93 06:50:11 -0700
Received: from eos03a.eos.ncsu.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15686; Wed, 4 Aug 93 06:51:05 -0700
Received: from homer.ece.ncsu.edu by eos03a.eos.ncsu.edu (5.65b/Eos/S-U-09Jun93)
	id AA04992; Wed, 4 Aug 93 09:50:03 -0400
Posted-Date: Wed, 04 Aug 93 09:50:00 EDT
Received: by homer.eos.ncsu.edu (5.57/eos-client.920428)
	id AA06273; Wed, 4 Aug 93 09:50:02 -0400
From: jlnance@eos.ncsu.edu
Message-Id: <9308041350.AA06273@homer.eos.ncsu.edu>
To: riscy@pyramid.com
Subject: Re:  Mips project Go or Wait?
Date: Wed, 04 Aug 93 09:50:00 EDT
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

Hello,
     I wanted to throw out some thoughs about this project and see what
people thought.  It seems to me that two things are certain:

	1) The price/performance ratio of RISC processors will only get
	   better in the future.
	
	2) It will take a (fairly) long to design and debug this thing.

I know that it would be difficult, but given the above, I believe that it
would be good to try to predict how long it will take to design the board
and its operating system, and to try to predict what the cost of the components
will be at that time, and design on the basis of that.  I realize that this
approach is full of risks, and would be difficult to do, but I am afraid that
if this approach is not taken, the board my be obsolete by the time it is
usable.

Jim Nance
 
From owner-riscy@pyramid.com  Wed Aug  4 10:54:24 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA08190; Wed, 4 Aug 93 10:54:24 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20491; Wed, 4 Aug 93 07:53:32 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16042; Wed, 4 Aug 93 07:52:22 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16003; Wed, 4 Aug 93 07:52:20 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20473; Wed, 4 Aug 93 07:53:09 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id iA19182; Wed, 4 Aug 1993 16:48:54 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA18307; Wed, 4 Aug 93 16:46:58 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA00674; Wed, 4 Aug 93 16:46:48 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Wed, 4 Aug 93 16:45:47 +0200
Message-Id: <9308041445.AA08844@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA08844; Wed, 4 Aug 93 16:45:47 +0200
To: riscy@pyramid.com
Subject: Re:  Mips project Go or Wait?
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


> Hello,
>      I wanted to throw out some thoughs about this project and see what
> people thought.  It seems to me that two things are certain:
> 
> 	1) The price/performance ratio of RISC processors will only get
> 	   better in the future.

Correct. Although nobody can pay the latest developments.
Look at the R4000PC. Only *one* year ago it was around $2000,
now it's at about $600...

>	2) It will take a (fairly) long to design and debug this thing.

Don't know. This depends on how complete the NEC ARCset is. So far I
know solves it most of our problems. In case it is true that the
ARCset is a *complete* design, we would only have to make some
changes to satisfy the requirement of the group. Perhaps we have to
make no changes at all !

> I know that it would be difficult, but given the above, I believe that it
> would be good to try to predict how long it will take to design the board
> and its operating system, and to try to predict what the cost of the components
> will be at that time, and design on the basis of that.  I realize that this
> approach is full of risks, and would be difficult to do, but I am afraid that
> if this approach is not taken, the board my be obsolete by the time it is
> usable.

Neil made the assumption that it will take a bit more than half a man-year
to port the kernel and drivers. This depends on how many filesystems we will
support. For me, ext2fs and the ISO fs would be enough.
Everything else *should* compile out of the box, except the X11-server stuff.
That sounds not too bad, isn't it ?

I can't say how long it takes to make the hardware working, because it
depends on what we want.

Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Wed Aug  4 14:40:49 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA21168; Wed, 4 Aug 93 14:40:49 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21563; Wed, 4 Aug 93 11:40:25 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA10143; Wed, 4 Aug 93 11:39:06 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA10108; Wed, 4 Aug 93 11:39:00 -0700
Received: from hydra.Helsinki.FI 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21337; Wed, 4 Aug 93 11:39:54 -0700
Received: from kypros (kypros.Helsinki.FI) by hydra.Helsinki.FI (4.1/SMI-4.1/39)
	id AA01138; Wed, 4 Aug 93 21:37:40 +0300
From: Hannu.Savolainen@cs.Helsinki.FI (Hannu Savolainen)
Message-Id: <9308041837.AA01138@hydra.Helsinki.FI>
Subject: Re:  Mips project Go or Wait?
To: riscy@pyramid.com
Date: Wed, 4 Aug 93 21:37:39 EET DST
In-Reply-To: <9308041445.AA08844@resi.waldorf-gmbh.de>; from "Andreas Busse" at Aug 4, 93 4:45 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> Neil made the assumption that it will take a bit more than half a man-year
> to port the kernel and drivers. This depends on how many filesystems we will
> support. For me, ext2fs and the ISO fs would be enough.
> Everything else *should* compile out of the box, except the X11-server stuff.
> That sounds not too bad, isn't it ?
It should not be difficult to port the filesystems since they don't
access hardware. Also most of the SCSI driver code should be easy to
port since we have to write just a low level driver for one SCSI
chip/host adapter. If we have the ISA bus, porting the ISA device
drivers could be possible by just rewriting the inline assembler macros
used by the drivers. A well written device driver is not CPU dependent.
There could be some problems if the new CPU is big endian.

Hannu
 
From owner-riscy@pyramid.com  Wed Aug  4 16:02:53 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA26015; Wed, 4 Aug 93 16:02:53 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04580; Wed, 4 Aug 93 13:01:51 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA19006; Wed, 4 Aug 93 13:00:28 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA18994; Wed, 4 Aug 93 13:00:25 -0700
Received: from relay1.UU.NET 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04488; Wed, 4 Aug 93 13:01:19 -0700
Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA26169; Wed, 4 Aug 93 15:59:04 -0400
Received: from rei2.UUCP by uucp3.uu.net with UUCP/RMAIL
	(queueing-rmail) id 155731.25934; Wed, 4 Aug 1993 15:57:31 EDT
Received: by rei.com (5.4/5.40/1.0)
	id AA11141; Wed, 4 Aug 1993 13:36:27 -0500
From: rei2!tsprad@uunet.UU.NET (6692)
Message-Id: <9308041836.AA11141@rei.com>
Subject: Re: Mips project Go or Wait?
To: riscy@pyramid.com
Date: Wed, 4 Aug 1993 13:36:25 -0500 (CDT)
In-Reply-To: <9308041421.AA04255@rei.com> from "UUCP Login" at Aug 4, 93 09:21:39 am
X-Mailer: ELM [version 2.4 PL13]
Content-Type: text
Content-Length: 3954      
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> ... good to try to predict how long it will take to design the board and
> its operating system, and to try to predict what the cost of the components
> will be at that time, and design on the basis of that.  I realize that this
> approach is full of risks, and would be difficult to do, but I am afraid that
> if this approach is not taken, the board my be obsolete by the time it is
> usable.
> 
> Jim Nance

Hear, Hear!  Not to be a wet blanket, but it might also be enlightening
to try to predict what the cost of competitive products will be at that
time.  I understand that DEC Alphas are already available for ~US$5K,
at least to selected WindowsNT developers.  And that's complete, with
memory, tube, keyboard, mouse, disk, and CD-ROM drive.

> Personal computer firms plan to use the RISC chips in personal 
> computers when Microsoft's Japanese Windows NT begins to 
> gain popularity. Taiwan's Acer is planning to ship a PC 
> based on the VR4400 as early as this fall.

How much do you think this Taiwanese machine will be selling for by
the time our board is able to boot Linux?  Particularly when the
prediction of that time has to be adjusted for time spent bickering
about fundamental design decisions, like 'dumb frame buffer vs. VESA
local bus connector' and 'IDT R3051 vs. IDT R3081 vs. NEC VR4000PC
vs. NEC VR4200' and 'complete complement of I/O on board vs. ISA
expansion bus'.

I was really disappointed when the IDT 3730 didn't materialize.  I
think that probably set the timetable back _several_ months.  And it
looks to me like we're even more caught up in pursuing Vaporware (tm)
chips now, rather than accepting the lesson of the 3730 and
designing with parts that are available (in small quantities) now.

What I mean about quantities is that we could probably have the 3730
in three months if we could convince IDT that we'll be buying 50K
per month in 1994 and 1995.  On the other hand, it's entirely
possible that the PowerPC will really take off and the VR4200, even
the whole MIPS 4000 line, will be abandoned because there's no
market.

At the risk of repeating myself, let me say again that I don't think
that this project will lead to a state-of-the-art workstation at a
bargain price.  We just can't compete with the large-volume
manufacturers.  But I still think it's worth doing, and I still
think there's a (small) chance there could eventually be many
thousands, even tens of thousands of the things built over the next
several years.

Does anyone have any usable estimates of how many
Linux/386BSD/NetBSD  machines there are?  A month or so ago Bill
Jollitz was throwing around the number 'a million' for 386BSD alone
(but of course I take that with a grain of salt).  But say there's
something on the order of a million of Linux & 386BSD & NetBSD
combined, worldwide.  Obviously, all of these people are adventurous
tinkers, or they would stick with 'supported' software.  Do you
think that 1% of those people might buy our board, if they could get
system software that boots up and basically runs, and if they knew
they could get compatible motherboards from at least two or three
manufacturers around the world, and all their other hardware needs
from their local discount computer retailer, and all the 'support'
they could possibly want from net news and mailing lists?

One percent of a million is ten thousand.  Even if I'm off by an
order of magnitude it's still one thousand to one hundred thousand.
Enough to support a pretty active news group.  And if every one of
them has the 'sources' of the hardware design, enough to deal
compatibly with obsolete components for a long, long time.

-- 
Ted Spradley   Recognition International, Inc.  Opinions are mine, not theirs.
2701 E Grauwyler Rd. |Your productivity is not enhanced when you're staring
Irving TX 75061      |at that thing.  Your productivity is enhanced when
214-579-6692         |the computer is working and you're doing something else.
 
From owner-riscy@pyramid.com  Wed Aug  4 18:12:31 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA02852; Wed, 4 Aug 93 18:12:31 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA19725; Wed, 4 Aug 93 15:11:54 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA04234; Wed, 4 Aug 93 15:09:34 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA04214; Wed, 4 Aug 93 15:09:31 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA19698; Wed, 4 Aug 93 15:10:25 -0700
Message-Id: <9308042210.AA19698@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA03943; Wed, 4 Aug 93 18:08:43 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Re: Mips project Go or Wait?
To: riscy@pyramid.com
Date: Wed, 4 Aug 1993 18:08:43 -0500 (EDT)
In-Reply-To: <9308041836.AA11141@rei.com> from "6692" at Aug 4, 93 01:36:25 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 4730      
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

>> ... good to try to predict how long it will take to design the board and
>> its operating system, and to try to predict what the cost of the components
>> will be at that time, and design on the basis of that.  I realize that this
>> approach is full of risks, and would be difficult to do, but I am afraid that
>> if this approach is not taken, the board my be obsolete by the time it is
>> usable.

Well current state of the art in the pc world is a 486/66 (32.4 specint 16.1 fp)
In six months the 66 Mhz pentium will be state of the art (64.5 specint 56.9 fp)
and a good motherboard like micronices VESA is over $1000 with a 486 66 in it.
Last year a 486/50 ISA was over $1000.  Don't forget that the 486 motherboard 
doesn't have video, ethernet or scsi.

So if we can get the 4200 (55int/30 fp) 4000 (62int/63fp) going it seems
that even in 6 months we would be competitive if it's under $1000.
If we use the arc 100 chipset we have nothing to design, all we 
have to do is order the parts, and contract out the design of the motherboards.
Oh yeah and port linux ;-)

> Hear, Hear!  Not to be a wet blanket, but it might also be enlightening
> to try to predict what the cost of competitive products will be at that
> time.  I understand that DEC Alphas are already available for ~US$5K,
> at least to selected WindowsNT developers.  And that's complete, with
> memory, tube, keyboard, mouse, disk, and CD-ROM drive.

Well I don't expect anyone to sell 486 motherboard ugprade over the next
6 months because of problems with software/integrations/hardware compatibility.
Complete systems will compete with complete pentium/486 systems, but I don't
expect any direct competition with 486 motherboards.

> How much do you think this Taiwanese machine will be selling for by
> the time our board is able to boot Linux?  

ACER isn't selling mothebroards, and ACER needs to make a profit, and
ACER's machine won't run linux.  

> Particularly when the
> prediction of that time has to be adjusted for time spent bickering
> about fundamental design decisions, like 'dumb frame buffer vs. VESA
> local bus connector' and 'IDT R3051 vs. IDT R3081 vs. NEC VR4000PC
> vs. NEC VR4200' and 'complete complement of I/O on board vs. ISA
> expansion bus'.

Well hopefully everyone will agree the arc 100 design is better and we
will have to do NO design, just use the NEC design. 

> I was really disappointed when the IDT 3730 didn't materialize.  I
> think that probably set the timetable back _several_ months.  And it

Well the arc 100/150 look even better. (MCT-ADR MCT-DP)

> possible that the PowerPC will really take off and the VR4200, even
> the whole MIPS 4000 line, will be abandoned because there's no
> market.

Well I personally prefer the powerpc.  It run's gcc, gets more done per Mhz,
very elegant, reasonably priced, and has the largest onchip cache.  But the 
simple fact that there exists a mips 4000 board design outweighs any 
advantages the powerpc has over the mips 4000 series.  Unless we find
a ready to use powerpc motherboard design of course.

I'd really doubt the mips chips will have any problems, they are faster
then the pentium, run windows nt, and have SGI/MIPS and various pc companies
supporting them.

> At the risk of repeating myself, let me say again that I don't think
> that this project will lead to a state-of-the-art workstation at a
> bargain price.  We just can't compete with the large-volume
> manufacturers.  But I still think it's worth doing, and I still
> think there's a (small) chance there could eventually be many
> thousands, even tens of thousands of the things built over the next
> several years.

Well the 486 is an ugly architecture, and is slow especially in fp.  (not
to mention I'd bet that the 486 specmarks are more optimized then anyone elses.)
If I can get better price/performance on a riscy motherboard with everything
on board, then I can get with a 486 motherboard+video+scsi I'll buy it.

[ deleted long speculation on the number of free unix users and extrapolating
market for the riscy board]

There are no doubt that there are MANY free unix users, but MANY of those
are running with <= 4 MB ram, <= 386-33, IDE disks, tident or tseng video
cards, etc.

Most free unix users are college age or so, and don't have the better part
of $1000 to upgrade there system that doesn't run winNT or dos software.

But I hate the 486/586 design, and microsoft software, and hope to
get a riscy motherboard to run linux.  So I can have a workstation at home.

-- 
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 owner-riscy@pyramid.com  Wed Aug  4 18:27:14 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA03512; Wed, 4 Aug 93 18:27:14 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21089; Wed, 4 Aug 93 15:26:35 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA05589; Wed, 4 Aug 93 15:25:26 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA05581; Wed, 4 Aug 93 15:25:22 -0700
Received: from relay2.UU.NET 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21074; Wed, 4 Aug 93 15:26:17 -0700
Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA22406; Wed, 4 Aug 93 18:24:02 -0400
Received: from rei2.UUCP by uucp2.uu.net with UUCP/RMAIL
	(queueing-rmail) id 182239.11763; Wed, 4 Aug 1993 18:22:39 EDT
Received: by rei.com (5.4/5.40/1.0)
	id AA12976; Wed, 4 Aug 1993 17:18:17 -0500
From: rei2!tsprad@uunet.UU.NET (6692)
Message-Id: <9308042218.AA12976@rei.com>
Subject: 
To: riscy@pyramid.com
Date: Wed, 4 Aug 1993 17:18:15 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL13]
Content-Type: text
Content-Length: 1294      
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> I can't say how long it takes to make the hardware working, because it
> depends on what we want.
> 
> Andy
 
We want the World and we want it NOW!  :-)

Turn the question around.  What would make you NOT want to
manufacture it?  How about a server sort of configuration:  no
video, no keyboard, just SCSI, Ethernet, and serial ports?  Or the
bare bone that some have suggested, processor, memory, and ISA
expansion bus?  How about R3051 instead of R4000?

The rest of you, too.  What would make you NOT want it?

As for me (while I'm on the soap box), I don't want an add-in board
to plug into a PeeCee, I want a single-board computer.  I'd buy it
if it had R3051E, memory, and that multi-I/O chip (what was it,
82C665?) with IDE, floppy, two serial and one parallel, but SCSI and
Ethernet would sure be nice.  Other folks will, I'm sure, demand a
keyboard port and video.  A truly open board design would have
some vacant real estate where the true hacker could add his own....

-- 
Ted Spradley   Recognition International, Inc.  Opinions are mine, not theirs.
2701 E Grauwyler Rd. |Your productivity is not enhanced when you're staring
Irving TX 75061      |at that thing.  Your productivity is enhanced when
214-579-6692         |the computer is working and you're doing something else.
 
From owner-riscy@pyramid.com  Wed Aug  4 19:17:52 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA04934; Wed, 4 Aug 93 19:17:52 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA25334; Wed, 4 Aug 93 16:17:01 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA13945; Wed, 4 Aug 93 16:15:51 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA13906; Wed, 4 Aug 93 16:15:47 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA25315; Wed, 4 Aug 93 16:16:42 -0700
Message-Id: <9308042316.AA25315@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA04410; Wed, 4 Aug 93 19:15:01 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Minimum requirements
To: riscy@pyramid.com
Date: Wed, 4 Aug 1993 19:15:00 -0500 (EDT)
In-Reply-To: <9308042218.AA12976@rei.com> from "6692" at Aug 4, 93 05:18:15 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 744       
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> The rest of you, too.  What would make you NOT want it?

I want significantly better real world int AND fp price/performance then a 
486/66.  I want 32 bit wide access to 1024x768x8 video at 72 hz, either via on 
board, or VESA.  Anything else necessary should be available on board or ISA.

To get the real world performance better then a 486/66 with 256k cache may mean
a second level cache.

This may sounds tough but if I'm going to give up the world of pc
software (including the latest linux) I want something to show for it.

-- 
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 owner-riscy@pyramid.com  Wed Aug  4 20:03:10 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA06663; Wed, 4 Aug 93 20:03:10 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA29035; Wed, 4 Aug 93 17:02:35 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA20122; Wed, 4 Aug 93 17:01:22 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA20107; Wed, 4 Aug 93 17:01:16 -0700
Received: from kinglear.cs.colorado.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA29023; Wed, 4 Aug 93 17:02:10 -0700
Received: from localhost by kinglear.cs.Colorado.EDU with SMTP id AA10724
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Wed, 4 Aug 1993 18:01:09 -0600
Message-Id: <199308050001.AA10724@kinglear.cs.Colorado.EDU>
To: riscy@pyramid.com
Subject: Re: Mips project Go or Wait? 
In-Reply-To: Your message of "Wed, 04 Aug 1993 16:45:47 +0200."
             <9308041445.AA08844@resi.waldorf-gmbh.de> 
Date: Wed, 04 Aug 1993 18:01:08 -0600
From: Drew Eckhardt <drew@kinglear.cs.Colorado.EDU>
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

    > would be good to try to predict how long it will take to design the board
    > and its operating system, and to try to predict what the cost of the comp
   onents
    > will be at that time, and design on the basis of that.  I realize that th
   is
    > approach is full of risks, and would be difficult to do, but I am afraid 
   that
    > if this approach is not taken, the board my be obsolete by the time it is
    > usable.
    
    Neil made the assumption that it will take a bit more than half a man-year
    to port the kernel and drivers. This depends on how many filesystems we wil
   l
    support. For me, ext2fs and the ISO fs would be enough.

It has little to do with how many filesystems we support, as the filesystems 
should be devoid of any system dependant code.  Endianess is pretty easy to 
deal with where we need binary compatability with existing filesystems (ie
MSDOS since you may want to read DOS floppies). 

As far as how long device drivers take :

IDE, serial, parallel, etc. where we've got the same parts as in the PC - 
we simply add appropriate #ifdef LINUX_MIPS or whatever to the kernel sources
around code that does memory mapped I/O instead of using the port commands.

SCSI - it looks like the SCSI driver I'm writing right now (NCR5380) 
will have taken about 20 man-hours (including me reading the NCR5380 
databook, designing the driver architecture, writing the code, etc) by 
the time it goes into ALPHA test.  The 5390's are even easier to program. 

Ie : device drivers are not a significant problem.

I think the hard parts will be taking care of the major 386isms, ie the 
scheduler and VM which is really prone to race conditions.  Since people have 
access to other MIPS architecture machines (ie, Decstations) and sample MIPS 
code to work with (BSD4.4 runs on the Decstations) this can happen in parallel 
with the hardware development.

    Everything else *should* compile out of the box, except the X11-server stuf
   f.
    That sounds not too bad, isn't it ?

I don't think there will be any significant technical problems getting 
the software up. 

Speaking of kernel development for the MIPS : we need to start a discussion
on how to best make the kernel sources multi-architecture, so that one 
release of Linux runs on MIPS, Intel, and Motorola platforms.

The AMIGA people didn't bother to do this, so they need a different 
kernel distribution and can never take advantage of new features 
when they're added.
 
From owner-riscy@pyramid.com  Wed Aug  4 23:30:35 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA12789; Wed, 4 Aug 93 23:30:35 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17925; Wed, 4 Aug 93 20:29:22 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA09352; Wed, 4 Aug 93 20:27:14 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA09345; Wed, 4 Aug 93 20:27:11 -0700
Received: from munnari.OZ.AU 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17465; Wed, 4 Aug 93 20:27:52 -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 AA15177; Thu, 5 Aug 1993 13:24:07 +1000 (from jeremy@sw.oz.au)
Received: from chao.sw.oz.au by swift.sw.oz.au with SMTP
	id AA06649; Thu, 5 Aug 93 13:19:59 AES (5.59)
	(from jeremy@sw.oz.au for riscy%pyramid.com@munnari.oz.au)
Received: by chao.sw.oz.au (4.1/SMI-4.1)
	id AA18703; Thu, 5 Aug 93 13:19:45 EST
From: jeremy@sw.oz.au (Jeremy Fitzhardinge)
Message-Id: <9308050319.AA18703@chao.sw.oz.au>
Subject: Re: Mips project Go or Wait?
To: riscy@pyramid.com
Date: Thu, 5 Aug 1993 13:19:44 +1000 (EST)
In-Reply-To: <9308041445.AA08844@resi.waldorf-gmbh.de> from "Andreas Busse" at Aug 4, 93 04:45:47 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: 2550      
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

Andreas Busse bubbles:

> Neil made the assumption that it will take a bit more than half a man-year
> to port the kernel and drivers. This depends on how many filesystems we will
> support. For me, ext2fs and the ISO fs would be enough.

The filesystems are entirely in the machine-independant code.
I don't think many changes at all will be needed for porting all of
the filesystems.  The MMU, DMA, interrupt handling and simplest device
drivers (console, serial, naif SCSI/ether) will probably be the longest to
get going because the machine is useless until they do.

> Everything else *should* compile out of the box, except the X11-server stuff.
> That sounds not too bad, isn't it ?

With a dumb frame buffer there will be very little work getting X11 going.
There's already lots of support in the MIT code for 8 bit deep dumb
frame buffers.  It'll just be a matter of reading the keyboard and mouse
properly (I think - I could be completely wrong).

Libraries could be a challenge to port.  Not because its very difficult
or machine dependant, but all kinds of correct decisions need to be made.
For example, if I were to port linux to an 4000, should off_t etc be
64 bit?  If so, should the library and compile environment have support
for a 32 bit environment and a 64 bit one (by having the 32 bit syscall
lib functions convert their args and returns to 64 bit).

> I can't say how long it takes to make the hardware working, because it
> depends on what we want.

Bearing in mind that 4000 based commercial machines are becoming available
*now* at reasonable or nearly reasonable prices.  For example, a brocure
from a company called "Tangent" turned up here selling an R4000 based
machine (can't remember which variant) running at 100MHz, 16MB ram,
16k cache (cannot sure if its I+D combined or 16k each), 200MB disk, hi
res graphics (~1000x1000x8) with 64 bit path to CPU + S3 accellerator,
E?ISA slots, monitor and Windows NT (SVR4 port available) for $4000 US.
That was the base machine with others up to 150MHz, more cache and memory
and so on.  A similar machine is $10000 here, but that's predictable.
Whether or not thay can actually deliver is another question.  Its also
possible that they'd sell motherboards alone.

I'm not cash starved and I'm keen to port linux to a Mips machine
(I've started already, mainly by looking at the i386 kernel for machine
dependancies and isolating them), so this kind of thing is an option
for me.  It also means there's some chance of a Mips kernel waiting for
any board that gets built.

	J
 
From owner-riscy@pyramid.com  Wed Aug  4 23:38:53 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA13097; Wed, 4 Aug 93 23:38:53 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18567; Wed, 4 Aug 93 20:38:01 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA10103; Wed, 4 Aug 93 20:35:55 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA10095; Wed, 4 Aug 93 20:35:52 -0700
Received: from kinglear.cs.colorado.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18552; Wed, 4 Aug 93 20:36:47 -0700
Received: from localhost by kinglear.cs.Colorado.EDU with SMTP id AA13729
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Wed, 4 Aug 1993 21:35:45 -0600
Message-Id: <199308050335.AA13729@kinglear.cs.Colorado.EDU>
To: riscy@pyramid.com
Subject: Re: Mips project Go or Wait? 
In-Reply-To: Your message of "Thu, 05 Aug 1993 13:19:44 +1000."
             <9308050319.AA18703@chao.sw.oz.au> 
Date: Wed, 04 Aug 1993 21:35:43 -0600
From: Drew Eckhardt <drew@kinglear.cs.Colorado.EDU>
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

    With a dumb frame buffer there will be very little work getting X11 going.
    There's already lots of support in the MIT code for 8 bit deep dumb
    frame buffers.  It'll just be a matter of reading the keyboard and mouse
    properly (I think - I could be completely wrong).

There's also 32 bit server code (from DEC) in the contrib hierchy.
    
    Libraries could be a challenge to port.  Not because its very difficult
    or machine dependant, but all kinds of correct decisions need to be made.
    For example, if I were to port linux to an 4000, should off_t etc be
    64 bit?  If so, should the library and compile environment have support
    for a 32 bit environment and a 64 bit one (by having the 32 bit syscall
    lib functions convert their args and returns to 64 bit).

Take a look at the various papers from Convex ('92 Winter USENIX proceedings),
BSD CSRG, etc. on supporting Big Files.
    
 
From owner-riscy@pyramid.com  Thu Aug  5 02:16:27 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA17252; Thu, 5 Aug 93 02:16:27 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09042; Wed, 4 Aug 93 23:15:25 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA25037; Wed, 4 Aug 93 23:13:40 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA25030; Wed, 4 Aug 93 23:13:37 -0700
Received: from munnari.OZ.AU 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09018; Wed, 4 Aug 93 23:13:42 -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 AA21983; Thu, 5 Aug 1993 16:09:22 +1000 (from jeremy@sw.oz.au)
Received: from chao.sw.oz.au by swift.sw.oz.au with SMTP
	id AA09677; Thu, 5 Aug 93 15:48:30 AES (5.59)
	(from jeremy@sw.oz.au for riscy%pyramid.com@munnari.oz.au)
Received: by chao.sw.oz.au (4.1/SMI-4.1)
	id AA00638; Thu, 5 Aug 93 15:48:22 EST
From: jeremy@sw.oz.au (Jeremy Fitzhardinge)
Message-Id: <9308050548.AA00638@chao.sw.oz.au>
Subject: Re: Mips project Go or Wait?
To: riscy@pyramid.com
Date: Thu, 5 Aug 1993 15:48:21 +1000 (EST)
In-Reply-To: <199308050001.AA10724@kinglear.cs.Colorado.EDU> from "Drew Eckhardt" at Aug 4, 93 06:01:08 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: 2879      
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

Drew Eckhardt bubbles:

> Speaking of kernel development for the MIPS : we need to start a discussion
> on how to best make the kernel sources multi-architecture, so that one 
> release of Linux runs on MIPS, Intel, and Motorola platforms.

I've already started this.  I have the root source dir.  Under it is
common/ with everything that's machine independant (filesystems, most
syscalls, etc).  There's another tree with cpu/arch, eg, i386/isa,
m68k/common, m68k/amiga, mips/common, mips/riscy, mips/idt and so on.
Currently I have a i386/isa with all the obviously intel specific stuff
in it (most things with __asm__(), dma, interrupt device drivers and so
on), and common with everything else.  It almost compiles, but I haven't
upgraded it to pl11.  Once it compiles, I want to try and move some
of the more gratuitous dependancies into portable code (like the asm()
in printf for doing a divide).

The include dir is also split, with the machine dependant stuff being
looked at before the common.  Of course, common code will include machine
dependancies from headers.

I think the port should avoid unnecessary changes to linux itself - it
should be a port and nothing more.  That doesn't exclude architecture
specific optimisations, but they are not necessary for the initial port.
Once its done, then other changes can happen.  This means that there
should be as much shared code as possible (which is why each cpu has a
common directory).  Also, the port will be for little endian mips, and
the tlb stuff will look like the intel mmu, because its easy to do so,
and there's no efficiency problems from doing so.  Using this approach
there can be a maximum of sharing with the intel linux.

I'm mostly interested in coordinating the initial port; that is getting
core of linux running on a mips chip.  I think it should be done by a very
small number of people in close communication, with a strong direction.
After that, it's easy to get more people working at once on porting device
drivers, essential usermode stuff (libraries), and so on.  From there,
it's everyone go.

I'd like to get a mips platform to start porting with before any hardware
is built, so there is something solid to start with -- there's little
enough time to make this compeditive as it is.

> The AMIGA people didn't bother to do this, so they need a different 
> kernel distribution and can never take advantage of new features 
> when they're added.

Yes, I was dissapointed by this.  The whole port looked a quite hackish.
It wasn't even very useful to find out where they had found intel
specific stuff, because they didn't localize it but just replaced it
with Moto things.  But it does work, I gather, and that's a start.
Perhaps when we have a good multi-architecture tree the moto stuff will
slot in easily.  I notice that they are trying to make it work on the
Amiga, ST and Mac.

	J
 
From owner-riscy@pyramid.com  Thu Aug  5 03:13:43 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA18773; Thu, 5 Aug 93 03:13:43 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18953; Thu, 5 Aug 93 00:13:01 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA01987; Thu, 5 Aug 93 00:11:52 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA01980; Thu, 5 Aug 93 00:11:50 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18839; Thu, 5 Aug 93 00:12:40 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id AX25910; Thu, 5 Aug 1993 09:08:27 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA25294; Thu, 5 Aug 93 09:01:45 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA03220; Thu, 5 Aug 93 09:01:18 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Thu, 5 Aug 93 09:00:22 +0200
Message-Id: <9308050700.AA09895@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA09895; Thu, 5 Aug 93 09:00:22 +0200
To: riscy@pyramid.com
Subject: Re: Mips project Go or Wait?
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> [lots of stuff deleted]
>
> Speaking of kernel development for the MIPS : we need to start a discussion
> on how to best make the kernel sources multi-architecture, so that one 
> release of Linux runs on MIPS, Intel, and Motorola platforms.
> 
> The AMIGA people didn't bother to do this, so they need a different 
> kernel distribution and can never take advantage of new features 
> when they're added.

Yes, this is right and I was already thinking about. The simplest
way would be a lot of #ifdef's, but that would make the code really
ugly. We should talk to Linus if it's possible to separate the
CPU-dependent stuff into several files, so that the CPU decision
can be made by compiling and linking different files. I'm sure
this is not always possible, but at least for things like the kernel boot
code it should not make any problem (and is necessary there).

Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Thu Aug  5 03:24:31 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA19187; Thu, 5 Aug 93 03:24:31 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20475; Thu, 5 Aug 93 00:23:47 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02162; Thu, 5 Aug 93 00:22:34 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02155; Thu, 5 Aug 93 00:22:31 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20411; Thu, 5 Aug 93 00:23:26 -0700
Message-Id: <9308050723.AA20411@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA06397; Thu, 5 Aug 93 03:21:34 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Re: Mips project Go or Wait?
To: riscy@pyramid.com
Date: Thu, 5 Aug 1993 03:21:33 -0500 (EDT)
In-Reply-To: <9308050319.AA18703@chao.sw.oz.au> from "Jeremy Fitzhardinge" at Aug 5, 93 01:19:44 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1220      
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> Bearing in mind that 4000 based commercial machines are becoming available
> *now* at reasonable or nearly reasonable prices.  For example, a brocure
> from a company called "Tangent" turned up here selling an R4000 based
> machine (can't remember which variant) running at 100MHz, 16MB ram,
> 16k cache (cannot sure if its I+D combined or 16k each), 200MB disk, hi
> res graphics (~1000x1000x8) with 64 bit path to CPU + S3 accellerator,
> E?ISA slots, monitor and Windows NT (SVR4 port available) for $4000 US.
> That was the base machine with others up to 150MHz, more cache and memory
> and so on.  A similar machine is $10000 here, but that's predictable.
> Whether or not thay can actually deliver is another question.  Its also
> possible that they'd sell motherboards alone.

Well 16 MB ram is about $400, 340 MB IDE disk is around $298.  Sounds like
they are charging $3300 for a motherboard+video+case+monitor sounds alot
more then the planned under $1k for video+scsi+ethernet+motherboard to me.


-- 
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 owner-riscy@pyramid.com  Thu Aug  5 05:01:00 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA21991; Thu, 5 Aug 93 05:01:00 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA00596; Thu, 5 Aug 93 02:00:16 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08814; Thu, 5 Aug 93 01:58:58 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08807; Thu, 5 Aug 93 01:58:55 -0700
Received: from svin02.info.win.tue.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA00551; Thu, 5 Aug 93 01:59:50 -0700
Received: from wsinis01.info.win.tue.nl by svin02.info.win.tue.nl (4.1/1.45)
    id AA29423; Thu, 5 Aug 93 10:57:32 +0200
Received: by wsinis01.info.win.tue.nl (4.1/1.45)
    id AA26878; Thu, 5 Aug 93 10:57:29 +0200
From: monty@info.win.tue.nl (Guido Leenders)
Message-Id: <9308050857.AA26878@wsinis01.info.win.tue.nl>
Subject: Re: Mips project Go or Wait?
To: riscy@pyramid.com
Date: Thu, 5 Aug 93 10:57:24 MET DST
In-Reply-To: <9308050548.AA00638@chao.sw.oz.au>; from "Jeremy Fitzhardinge" at Aug 5, 93 3:48 pm
Organization: The Timewasters
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> 
> I've already started this.  I have the root source dir.  Under it is
> common/ with everything that's machine independant (filesystems, most
> syscalls, etc).  There's another tree with cpu/arch, eg, i386/isa,
> m68k/common, m68k/amiga, mips/common, mips/riscy, mips/idt and so on.
> Currently I have a i386/isa with all the obviously intel specific stuff
> in it (most things with __asm__(), dma, interrupt device drivers and so
> on), and common with everything else.  It almost compiles, but I haven't
> upgraded it to pl11.  Once it compiles, I want to try and move some
> of the more gratuitous dependancies into portable code (like the asm()
> in printf for doing a divide).
> 

That was a great idea. I just want to make two suggestions:

1. Maybe you could contact Linus about this. You might try to
   convince him to incorporate this source tree into the official
   releases, so we don't have to catch up with new releases 
   all the time.
   Of course it's not at all totally sure that this project will
   ever get done, but it's a general good thing, since maybe
   someone in the future will try to make a port to (say) Alpha.
2. Maybe you could move the common-directory, to get more object-oriented,
   e.g.
	  i386  (common i386-stuff)
		 --- isa (isa-specific)
	  m68k  (common 68000-stuff)
		 --- amiga
		 --- mac
		 --- atari


Just a few thoughts.

Guido

--
Guido Leenders
monty@win.tue.nl
Eindhoven University of Technology
the Netherlands
 
From owner-riscy@pyramid.com  Thu Aug  5 12:40:18 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA08916; Thu, 5 Aug 93 12:40:18 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09818; Thu, 5 Aug 93 09:39:44 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08054; Thu, 5 Aug 93 09:37:51 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08047; Thu, 5 Aug 93 09:37:49 -0700
Received: from avignon.daimi.aau.dk 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09621; Thu, 5 Aug 93 09:38:44 -0700
Received: by avignon.daimi.aau.dk id AA22134
  (5.65c8/IDA-1.4.4 for riscy@pyramid.com); Thu, 5 Aug 1993 18:37:40 +0200
Date: Thu, 5 Aug 1993 18:37:40 +0200
From: Tommy Thorn <tthorn@daimi.aau.dk>
Message-Id: <199308051637.AA22134@avignon.daimi.aau.dk>
To: riscy@pyramid.com
Subject: Re: Mips project Go or Wait?
Reply-To: Tommy.Thorn@daimi.aau.dk
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

   From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
   Date: Wed, 4 Aug 1993 18:08:43 -0500 (EDT)
   Sender: owner-riscy@pyramid.com

   Well I personally prefer the powerpc.  It run's gcc, gets more done per Mhz,
   very elegant, reasonably priced, and has the largest onchip cache.  But the 
   simple fact that there exists a mips 4000 board design outweighs any 
   advantages the powerpc has over the mips 4000 series.  Unless we find
   a ready to use powerpc motherboard design of course.

My *personal* *taste* for the processors ranks Alpha, R4000, and
PowerPC, in this order, but that irrelevant of course. Why do you keep
pointing out that gcc exits for the powerpc, when the same is the case
for the mips?

In fact setting up a gas+binutils+gcc cross compilation enviroment +
spim (mips 3000 simulator) makes it possible to experiment with the
mips architechure already today.

I've tried to get information on the R4000 series the last two days,
but to no avail. Whats the difference from a R3000 (from a programming
view, and yes, I know it's 64 bit ;^)? Can anyone point me to
documentation?

Tommy.Thorn@daimi.aau.dk | If you use a PC consider upgrading to a real OS.
------------------------ | Linux is Posix (Unix). It has GCC,Emacs,X11,TCP,NFS,
*L*I*N*U*X* Fanatic (tm) | Doc,Interviews,Prolog...(you name it) and it's free!
 
From owner-riscy@pyramid.com  Thu Aug  5 18:35:44 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA26063; Thu, 5 Aug 93 18:35:44 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA10380; Thu, 5 Aug 93 15:35:20 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA19591; Thu, 5 Aug 93 15:33:58 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA19584; Thu, 5 Aug 93 15:33:55 -0700
Received: from ubiserver.ubitrex.mb.ca 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA10363; Thu, 5 Aug 93 15:34:29 -0700
Received: from ska.ubitrex.mb.ca ([192.75.16.23]) by ubitrex.mb.ca (4.1/SMI-4.1)
	id AA26476; Thu, 5 Aug 93 17:32:05 CDT
Date: Thu, 5 Aug 93 17:32:05 CDT
From: tim@ubitrex.mb.ca (Tim Braun)
Message-Id: <9308052232.AA26476@ubitrex.mb.ca>
To: riscy@pyramid.com
Subject: Re: Mips project Go or Wait?
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

My personal opinion is Go, and that means R3081.

It strikes me that if you are saturating a bus with
i/o, it doesn't matter if the CPU is doing it or if
it's DMA, you are bus limited.  So I suggest considering
non-dma IDE and floppy interfaces.  The existing IDE
driver uses cpu controlled transfers, which are to
a sector buffer that can be accessed at full speed.

Consider:
  R3081 CPU                               $80.00
  MOM memory/video/keyboard i/f           $30.00
  smc37c652 floppy/serial/ide/parallel    $20.00

  dual-port ram ethernet (8390) _or_ bus-master ethernet (79900) $20.00
  bus-master SCSI (53cf90) _or_ how big is the fifo on these?    $25.00

  Board $100.00
  Misc  $100.00

  total $375.00

They (IDT) say 35 MIPS, 11 MFlops.  I believe that's on the
order of a 486dx2-66.  Sytem performance would be (because of
the local bus peripherals) on the same order. Correct me if I'm 
wrong.
________________________________________________________________
Tim Braun                          |
Ubitrex Corporation                | Voice: 204-942-2992 ext 228
1900-155 Carlton St                | FAX:   204-942-3001
Winnipeg, Manitoba, Canada R3C 3H8 | Email: tim@ubitrex.mb.ca
 
From owner-riscy@pyramid.com  Thu Aug  5 20:25:47 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA29299; Thu, 5 Aug 93 20:25:47 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA19262; Thu, 5 Aug 93 17:25:35 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA09681; Thu, 5 Aug 93 17:24:19 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA09656; Thu, 5 Aug 93 17:24:16 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA19254; Thu, 5 Aug 93 17:25:12 -0700
Message-Id: <9308060025.AA19254@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA16879; Thu, 5 Aug 93 20:23:35 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Re: Mips project Go or Wait?
To: riscy@pyramid.com
Date: Thu, 5 Aug 1993 20:23:35 -0500 (EDT)
In-Reply-To: <9308052232.AA26476@ubitrex.mb.ca> from "Tim Braun" at Aug 5, 93 05:32:05 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1002      
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> Consider:
>   R3081 CPU                               $80.00

Last I heard this was over $300.

>   MOM memory/video/keyboard i/f           $30.00
Really this cheap?

I seem to remember adding ISA+VESA+SCSI+ethernet on the single available
DMA channel on the mom chip would be difficult.

>   smc37c652 floppy/serial/ide/parallel    $20.00
> 
>   dual-port ram ethernet (8390) _or_ bus-master ethernet (79900) $20.00
>   bus-master SCSI (53cf90) _or_ how big is the fifo on these?    $25.00
> 
>   Board $100.00
>   Misc  $100.00
> 
>   total $375.00

So this is off at least $220.00

> 
> They (IDT) say 35 MIPS, 11 MFlops.  I believe that's on the
> order of a 486dx2-66.  Sytem performance would be (because of
> the local bus peripherals) on the same order. Correct me if I'm 
> wrong.

-- 
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 owner-riscy@pyramid.com  Thu Aug  5 20:35:08 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA29602; Thu, 5 Aug 93 20:35:08 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20322; Thu, 5 Aug 93 17:34:48 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA11230; Thu, 5 Aug 93 17:33:41 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA11222; Thu, 5 Aug 93 17:33:39 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20266; Thu, 5 Aug 93 17:34:31 -0700
Message-Id: <9308060034.AA20266@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA16980; Thu, 5 Aug 93 20:32:49 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Decision
To: riscy@pyramid.com (Mips 3000)
Date: Thu, 5 Aug 1993 20:32:48 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 641       
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

IMHO we should build the ARC 100 mips 4000 PC or IDT orion.

But then again I, as a software person,  have nothing to offer the hardware 
project in the way of expertise/services. 

I think those that do should make a decision and go for it.  Make a decision
and see how many of us will follow.   That means you Andy, and Neil.

Each of us has there own agenda, the design by committee doesn't seem to be
working particlarly well.

-- 
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 owner-riscy@pyramid.com  Fri Aug  6 04:42:12 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA12629; Fri, 6 Aug 93 04:42:12 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA02707; Fri, 6 Aug 93 01:42:03 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02361; Fri, 6 Aug 93 01:40:11 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02349; Fri, 6 Aug 93 01:40:08 -0700
Received: from kinglear.cs.colorado.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA02696; Fri, 6 Aug 93 01:41:05 -0700
Received: from localhost by kinglear.cs.Colorado.EDU with SMTP id AA15047
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Fri, 6 Aug 1993 02:40:02 -0600
Message-Id: <199308060840.AA15047@kinglear.cs.Colorado.EDU>
To: riscy@pyramid.com
Subject: Re: Mips project Go or Wait? 
In-Reply-To: Your message of "Thu, 05 Aug 1993 17:32:05 CDT."
             <9308052232.AA26476@ubitrex.mb.ca> 
Date: Fri, 06 Aug 1993 02:40:01 -0600
From: Drew Eckhardt <drew@kinglear.cs.Colorado.EDU>
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


    My personal opinion is Go, and that means R3081.

The 4200, which is both cheaper and faster than the 3081 
is also shipping, albeit NEC is only making 10K 4000PC's and
4200's in a month.
    
    It strikes me that if you are saturating a bus with
    i/o, it doesn't matter if the CPU is doing it or if
    it's DMA, you are bus limited.  So I suggest considering
    non-dma IDE and floppy interfaces.  

You aren't saturating the bus.

You really want a DMA floppy interface (ie, wire the floppy
controller up as a slave device as it was intended to be) because
without it you have to sit in a loop while you read the track 
(ie, 160ms) and can't be doing other things.

DMA transfers will move the same amount of data, but you can
do other things while the actual transfer (9K over 1/6th of a second
for a 1:1 interleaved 1.44M floppy) happens.

The IDE drives do have a sector buffer so it's not as critical,
but you could still gain something since IDE drives use a 16 bit
bus that (if standard) runs 8Mhz, 1 wait.
    
    The existing IDE
    driver uses cpu controlled transfers, which are to
    a sector buffer that can be accessed at full speed.

Full ISA bus speed.
    
    Consider:
      R3081 CPU                               $80.00

Wrong.  All of the quotes we have on the R3081 in quantities
we can use are at least $300, NEC press releases have said $70
for the 4200 but no one has talked to a real distributor who sets
prices for small quantities.

Low quotes on the R3051 (ie, no floating point) were in the 
$120 range.

FYI, I talked to NEC today and they refered me to the local 
distributor for their parts

Compass Marketing +1 (303) 721-9663

I didn't get a chance to call during business hours and there's nothing
to say the distributor will be able to give us prices / parts given the
low (10K/month) production rate at this point, but I finally have a number
and can try tomorrow.

      MOM memory/video/keyboard i/f           $30.00

The MOM really doesn't do what we want - no variable bus sizing for the 
peripherials, no slave mode DMA for the SCSI / ethernet, the bus master
has to have 3051 / 3081 / 3041 compatable signals (ie Mux'd address/data),
etc.  In other words : the simplest way to do it hardware is with something
other than the MOM (ie, arc), the external hardware needed on the MOM makes
life difficult.

The simplest MOM solution (hardware) may be to use a 3041 running real 
time software in the sample design in place of the ILAC ethernet busmaster 
device, which in turn acts as a slave mode DMA controller, etc. but software 
would be tricky.

      smc37c652 floppy/serial/ide/parallel    $20.00
    
      dual-port ram ethernet (8390) _or_ bus-master ethernet (79900) $20.00

Do you have actual quotes on this, or is it an estimate?  If it's the 
former, does it include the price of the memory, arbiter PAL (or some
fraction of some other PAL we use) for the shared memory, tranciever,
etc (ie, everything in the NS app. note).

      bus-master SCSI (53cf90) _or_ how big is the fifo on these?    $25.00

The 53cf90 is *not* a busmaster, it's a slave dma/pio device with a 16 byte 
FIFO.  However, as I have stated in the past, with a *sane* architecture
(ie, the m68k which runs all DMA through the MMU) you get scatter gather
for slave mode devices and you don't need to bus-master.  For the 
typical SCSI command using this chip we'll service *at most* four 
interrupts where we can transmit data immediately without sitting in a busy 
loop of any sort.

      Board $100.00
      Misc  $100.00
    
      total $375.00
    
    They (IDT) say 35 MIPS, 11 MFlops.  I believe that's on the
    order of a 486dx2-66.  
    
    Sytem performance would be (because of the local bus peripherals) on the 
    same order. Correct me if I'm wrong.

It really depends - 

The interleaved VRAM (ie, 64 bit access) will allow far more video 
bandwidth than with the DRAM used on cheap localbus video boards (where
you loose 45-90M/sec to the serializers if you can run at that resolution)
and the 40Mhz R3000 will do graphics primitaves faster than an S3.

While the 486 looks OK under some benchmarks (SpecFP), real 
world and other benchmarks are more favorable towards the R2000/R3000
FPU's even at a much lower clock speeds (not the 40/66 to 100/66 ratios
we'd have with the various proposed solutions).

In the 486's favor is the second level cache, which may have a significant
effect on it's relative performance in real world software.

The various MIPS chips have at least double the internal cache,
separate I & D so locality is maintained better, but you're going
to loose something without having a second level cache like 
the 486 boards have.  How much cache is the important issue here,
since there are diminishing returns and the hit rate depends on the 
design (set associative vs. direct mapped).  Some one needs to 
*research* the issue.

IMHO : there are probably more chips out there than the 
IDT3081/MOM combination, ie the 4200 or 4000PC and NEC ARC chipset,
that should be considered before a design of any kind happens.

Also, there are design issues that *need* resolving which will have 
a very significant effect on the final cost, market size,
and performance of the system.

IMHO the decision to provide an expansion path beyond the local bus
connector for Waldorf's board, memory, and pin-compatable chips, 
second level cache, and use of the NEC manufacturing kit rather than
our own design built arround the ARC chipset are the most significant
of these issues.

 
From owner-riscy@pyramid.com  Fri Aug  6 04:48:13 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA12742; Fri, 6 Aug 93 04:48:13 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA03099; Fri, 6 Aug 93 01:48:04 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02641; Fri, 6 Aug 93 01:46:58 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02634; Fri, 6 Aug 93 01:46:56 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA03035; Fri, 6 Aug 93 01:47:51 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id CE18360; Fri, 6 Aug 1993 10:43:37 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA01467; Fri, 6 Aug 93 10:39:32 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA09061; Fri, 6 Aug 93 10:40:34 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Fri, 6 Aug 93 10:39:37 +0200
Message-Id: <9308060839.AA14797@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA14797; Fri, 6 Aug 93 10:39:37 +0200
To: riscy@pyramid.com
Subject: Re:  Decision
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


> IMHO we should build the ARC 100 mips 4000 PC or IDT orion.

That's what I think too.

> But then again I, as a software person,  have nothing to offer the hardware 
> project in the way of expertise/services. 

In case we can get that ARC design, we hopefully don't need that much
expertise and service.

> I think those that do should make a decision and go for it.  Make a decision
> and see how many of us will follow.   That means you Andy, and Neil.

It's not that simple. Waldorf is not interested to produce a board
which nobody will buy. Waldorf is not a computer manufacturer. We would
produce the riscy-board only if we see a chance that there will be a user
base large enough to support Linux for Mips. More exactly spoken:
Waldorf would produce the board to force a Linux port, not to make money.
That means that we can't decide to use a R4400/75Mhz only because it's
nice and fast. We would rather use a R4200 *although* it's not that fast
but will be accepted by the riscy group because it's cheap enough.

> Each of us has there own agenda, the design by committee doesn't seem to be
> working particlarly well.

That's unfortunally true. So I make a suggestion:

1. We skip all R3x00 solutions. No matter how good, they will be
   obsolete by end of the year.

2. We should verify the NEC ARCset solution. If everything is fine
   and it isn't vaporware, it should be our choice.
   Verifying the ARCset means:
   - get *official* statements about price and availability
   - analyze it
   - buy it

3. We can then decide which CPU to use. Either NEC R4200 or
   IDT Orion. This depends on the price/power relations as
   well as on the availability. 

4. If 2. fails for whatever reasons, we have to wait.
   I'm absolutely sure that there *will* be solutions
   around the various R4x00 CPUs. If not now, then later.
   I'm sure because of the growing Windows NT market.

Can we go this way ?

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Fri Aug  6 05:45:06 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA13915; Fri, 6 Aug 93 05:45:06 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA07720; Fri, 6 Aug 93 02:45:07 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA07280; Fri, 6 Aug 93 02:43:56 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA07273; Fri, 6 Aug 93 02:43:53 -0700
Received: from boulder.Colorado.EDU 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA07710; Fri, 6 Aug 93 02:44:50 -0700
Received: from agua.Colorado.EDU by boulder.Colorado.EDU with SMTP id AA03044
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Fri, 6 Aug 1993 03:42:35 -0600
Received: by agua.colorado.edu (cu.generic.890828)
Date: Fri, 6 Aug 93 03:40:13 MDT
From: Alan Krantz <atk@agua.Colorado.EDU>
Message-Id: <9308060940.AA01976@agua.colorado.edu>
To: riscy@pyramid.com
Subject: Re:  Decision
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

  From owner-riscy@pyramid.com Fri Aug  6 02:45:17 1993
  Subject: Re:  Decision


  3. We can then decide which CPU to use. Either NEC R4200 or
     IDT Orion. This depends on the price/power relations as
     well as on the availability. 

How does the performance/price of the Orion compare to the R4200?
As I understand it if you go with the IDT then people who wish to spend
more can go with the R4000pc (i.,e they are pin compat). While personally
I find the R4200 to have a very  attractive price/performance we might
want to consider the above. (Of course it's likely a R4200 pin compat chip 
with hardware fpu will be avail. in the future).

atk

 
From owner-riscy@pyramid.com  Fri Aug  6 05:50:46 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA14038; Fri, 6 Aug 93 05:50:46 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA08045; Fri, 6 Aug 93 02:50:40 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA07619; Fri, 6 Aug 93 02:49:34 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA07612; Fri, 6 Aug 93 02:49:31 -0700
Received: from kinglear.cs.colorado.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA08035; Fri, 6 Aug 93 02:50:28 -0700
Received: from localhost by kinglear.cs.Colorado.EDU with SMTP id AA15429
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Fri, 6 Aug 1993 03:49:26 -0600
Message-Id: <199308060949.AA15429@kinglear.cs.Colorado.EDU>
To: riscy@pyramid.com
Subject: Re: Decision 
In-Reply-To: Your message of "Fri, 06 Aug 1993 10:39:37 +0200."
             <9308060839.AA14797@resi.waldorf-gmbh.de> 
Date: Fri, 06 Aug 1993 03:49:25 -0600
From: Drew Eckhardt <drew@kinglear.cs.Colorado.EDU>
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


    1. We skip all R3x00 solutions. No matter how good, they will be
       obsolete by end of the year.

Agreed, especially given the technical issues (we probably have 
a suitable, integrated 4000 series chipset now, the same thing for
the 3051 family isn't shipping), performance inssues, and pricing
although this hasn't been formally verified.
    
    2. We should verify the NEC ARCset solution. If everything is fine
       and it isn't vaporware, it should be our choice.
       Verifying the ARCset means:
       - get *official* statements about price and availability
       - analyze it
       - buy it

IMHO, this is the most viable solution that we've seen that's actually
shipping.
    
    3. We can then decide which CPU to use. Either NEC R4200 or
       IDT Orion. This depends on the price/power relations as
       well as on the availability. 

Agreed, the -design- will be essentially the same for the 
4200 and 4000PC/Orion (when available).

    4. If 2. fails for whatever reasons, we have to wait.
       I'm absolutely sure that there *will* be solutions
       around the various R4x00 CPUs. If not now, then later.
       I'm sure because of the growing Windows NT market.

Agreed, doing all of the support stuff ourselves would be too 
sloppy and the only other chips we've seen are 3051 family and 
either not shipping or unsuitable.
    
    Can we go this way ?

IMHO, definately.
    
 
From owner-riscy@pyramid.com  Fri Aug  6 06:25:11 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA14829; Fri, 6 Aug 93 06:25:11 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA10881; Fri, 6 Aug 93 03:25:13 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08563; Fri, 6 Aug 93 03:24:06 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08556; Fri, 6 Aug 93 03:24:04 -0700
Received: from RUTGERS.EDU 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA10865; Fri, 6 Aug 93 03:25:01 -0700
Received: from eerie.acsu.buffalo.edu by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) 
	id AA10003; Fri, 6 Aug 93 06:22:44 EDT
Received: from uucp@localhost by eerie (8.5/8.1)
	 via UUCP. id GAA27018; Fri, 6 Aug 1993 06:22:37 -0400
Received: by toz.buffalo.ny.us (1.65/waf)
	via UUCP; Thu, 05 Aug 93 16:36:25 EDT
	for eerie!pyramid.com!riscy
To: riscy@pyramid.com
Subject: Re: Mips project Go or Wait? 
From: cyberman@toz.buffalo.ny.us (Cyberman)
Comments:             
Message-Id: <PiTT8B1w165w@toz.buffalo.ny.us>
Date: Thu, 05 Aug 93 16:31:12 EDT
In-Reply-To: <199308050001.AA10724@kinglear.cs.Colorado.EDU>
Organization: The Tower of Zot - (716)839-0431
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

Drew Eckhardt <eerie!kinglear.cs.Colorado.EDU!drew> writes:
> I don't think there will be any significant technical problems getting 
> the software up. 
> 
> Speaking of kernel development for the MIPS : we need to start a discussion
> on how to best make the kernel sources multi-architecture, so that one 
> release of Linux runs on MIPS, Intel, and Motorola platforms.
> 
> The AMIGA people didn't bother to do this, so they need a different 
> kernel distribution and can never take advantage of new features 
> when they're added.

WELL one way to do this is too do what the people who made nethack did.
Have people submit additions and patches and let them corelate 
modifications.  Also they when for system independance by using the
ussual conditional compiling.  They had one config.h for selecting the
OS options and one OS specific config.  In linux case perhaps a general
purpose config.h and a processor specific config and then a machine 
specific configuration.  The only problem I've had compiling nethack 
under this strategy are unimplemented system functions like stty gtty and 
lock.  I hate having to work around such things (grin).  

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"

Computer Engineer - hopeing to get employement
 
From owner-riscy@pyramid.com  Fri Aug  6 11:14:06 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA25786; Fri, 6 Aug 93 11:14:06 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04477; Fri, 6 Aug 93 08:14:01 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA20905; Fri, 6 Aug 93 08:12:31 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA20898; Fri, 6 Aug 93 08:12:29 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04465; Fri, 6 Aug 93 08:13:22 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id CP06856; Fri, 6 Aug 1993 17:09:07 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA03582; Fri, 6 Aug 93 17:05:58 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA11279; Fri, 6 Aug 93 17:05:55 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Fri, 6 Aug 93 17:04:58 +0200
Message-Id: <9308061504.AA16039@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA16039; Fri, 6 Aug 93 17:04:58 +0200
To: riscy@pyramid.com
Subject: Re:  Decision
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

>  3. We can then decide which CPU to use. Either NEC R4200 or
>     IDT Orion. This depends on the price/power relations as
>     well as on the availability. 
>
> How does the performance/price of the Orion compare to the R4200?
> As I understand it if you go with the IDT then people who wish to spend
> more can go with the R4000pc (i.,e they are pin compat). While personally
> I find the R4200 to have a very  attractive price/performance we might
> want to consider the above. (Of course it's likely a R4200 pin compat chip 
> with hardware fpu will be avail. in the future).

Yes, the Orion will be pin-compatible with the R4000PC and the R4400PC. 
Price/power relation means "how many specmark per dollar" too,
but the migration path is more important, I believe.
In case the Orion is available in near future, what we have to find
out, and it's not much more expensive than the R4200, then it might
be a better choice.
The most important thing is availability. The Orion is surely a very
interesting thing, but I would take the CPU which I can *really* buy
when I need it.

Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Mon Aug  9 10:57:46 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA04974; Mon, 9 Aug 93 10:57:46 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA14529; Mon, 9 Aug 93 07:56:01 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA25017; Mon, 9 Aug 93 07:54:04 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA25010; Mon, 9 Aug 93 07:54:02 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA14466; Mon, 9 Aug 93 07:54:56 -0700
Message-Id: <9308091454.AA14466@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA04093; Mon, 9 Aug 93 10:52:43 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Second level cache?
To: riscy@pyramid.com (Mips 3000)
Date: Mon, 9 Aug 1993 10:52:43 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 950       
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

Somebody mentioned that some research needs to be done on how a second level 
cache will effect performance.  Any suggestions on how to do this?

Based on observation it seems that a cache is worth it, SGI mips 4000 SC is
around 35/34 and the mips 4000 PC is around 60/58 specint/specfp.

Adding the decreased locality of Unix+X11 over dos, the higher (100 Mhz
internal) clock rate, and mips binaries being bigger then 486 it would
seem that a large secondary cache would be necessary.  Based on a 486's
secondary cache being useful.

Any suggestions on how to get some numbers experimentally?

I have a decstation 3100 running Ultrix, and a 486/66 running linux
available for any attempts to quantify the advantages of second level
cache'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 owner-riscy@pyramid.com  Mon Aug  9 11:18:51 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA06214; Mon, 9 Aug 93 11:18:51 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17032; Mon, 9 Aug 93 08:18:48 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA28631; Mon, 9 Aug 93 08:17:20 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA28624; Mon, 9 Aug 93 08:17:18 -0700
Received: from boulder.Colorado.EDU 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16951; Mon, 9 Aug 93 08:18:20 -0700
Received: from agua.Colorado.EDU by boulder.Colorado.EDU with SMTP id AA16600
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Mon, 9 Aug 1993 09:16:00 -0600
Received: by agua.colorado.edu (cu.generic.890828)
Date: Mon, 9 Aug 93 09:13:39 MDT
From: Alan Krantz <atk@agua.Colorado.EDU>
Message-Id: <9308091513.AA10979@agua.colorado.edu>
To: riscy@pyramid.com
Subject: Re:  Second level cache?
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

  > From owner-riscy@pyramid.com Mon Aug  9 08:53:13 1993
  > Status: R

  > Somebody mentioned that some research needs to be done on how a second level 
  > cache will effect performance.  Any suggestions on how to do this?

  > Based on observation it seems that a cache is worth it, SGI mips 4000 SC is
  > around 35/34 and the mips 4000 PC is around 60/58 specint/specfp.

  > Adding the decreased locality of Unix+X11 over dos, the higher (100 Mhz
  > internal) clock rate, and mips binaries being bigger then 486 it would
  > seem that a large secondary cache would be necessary.  Based on a 486's
  > secondary cache being useful.

The subject isn't that simple. For example the usefulness of the cache 
greately depends on how the memory is interleaved (the R4xxx has an external
64 bit path way). Also there is an issue of the internal cache size. An
internal cache on a 486 is 16k (I think 8k each for I&D) (but writethrough not
write back). The R4xxxx has a larger internal cache.

  > Any suggestions on how to get some numbers experimentally?

Yea build an R4000 system with the desired level of interleaving; one with
and one without secondary cache. Then run both systems :)


 
From owner-riscy@pyramid.com  Mon Aug  9 11:23:55 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA06832; Mon, 9 Aug 93 11:23:55 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17679; Mon, 9 Aug 93 08:23:50 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA29178; Mon, 9 Aug 93 08:22:38 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA29171; Mon, 9 Aug 93 08:22:36 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17671; Mon, 9 Aug 93 08:23:35 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id GO10729; Mon, 9 Aug 1993 17:19:15 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA25027; Mon, 9 Aug 93 17:20:23 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA00925; Mon, 9 Aug 93 17:20:14 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Mon, 9 Aug 93 17:19:20 +0200
Message-Id: <9308091519.AA19828@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA19828; Mon, 9 Aug 93 17:19:20 +0200
To: riscy@pyramid.com
Subject: Re:  Second level cache?
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


> Somebody mentioned that some research needs to be done on how a second level 
> cache will effect performance.  Any suggestions on how to do this?
> 
> Based on observation it seems that a cache is worth it, SGI mips 4000 SC is
> around 35/34 and the mips 4000 PC is around 60/58 specint/specfp.

Yes, although these numbers seem to mixed-up, a secondary cache *would*
improve performance. But: Neither the R4200 nor the Orion will have
secondary cache support. We should better forget about that, otherwise
we'll try to build a high-end thing, which is probably not what we
want...

Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Mon Aug  9 11:25:28 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA06948; Mon, 9 Aug 93 11:25:28 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17990; Mon, 9 Aug 93 08:25:26 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA29320; Mon, 9 Aug 93 08:24:14 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA29300; Mon, 9 Aug 93 08:24:12 -0700
Received: from bernina.ethz.ch 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17982; Mon, 9 Aug 93 08:25:14 -0700
Received: from neptune by bernina.ethz.ch with SMTP inbound id <3627-0@bernina.ethz.ch>; Mon, 9 Aug 1993 17:24:02 +0200
Message-Id: <9308091523.AA13831@neptune>
Received: from tau.inf.ethz.ch by neptune id AA13831; Mon, 9 Aug 93 17:23:58 +0200
To: riscy@pyramid.com
Subject: Re: Second level cache? 
In-Reply-To: Your message of "Mon, 09 Aug 93 09:13:39 MDT."
	     <9308091513.AA10979@agua.colorado.edu> 
Date: Mon, 09 Aug 93 17:23:56 +0200
From: weingart@inf.ethz.ch
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

You write: 
Sie schreiben: 


>   > Any suggestions on how to get some numbers experimentally?
> 
> Yea build an R4000 system with the desired level of interleaving; one with
> and one without secondary cache. Then run both systems :)

Ok, I'll throw in my ballot for the cache one...

Can I "test-drive" for free?  ;-)


I don't know much about hardware design, but could you design the thing
in such a way that you can plug in cache, when you need it.  IE: if you
don't have the money, the board will run without the SC, and if you do,
you just buy some SRAM, and plug 'er in...

Or will this cause the logic to go beserk?

--Toby.
--------------------------------------------------------------
|Tobias Weingartner  |    PGP2.x Public Key available at     |
| +41'01'254'7205    |   'finger weingart@tau.inf.ethz.ch'   |
--------------------------------------------------------------
%SYSTEM-F-ANARCHISM, the operating system has been overthrown
 
From owner-riscy@pyramid.com  Mon Aug  9 23:58:52 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA11911; Mon, 9 Aug 93 23:58:52 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA26931; Mon, 9 Aug 93 20:58:38 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA05236; Mon, 9 Aug 93 20:57:13 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA05215; Mon, 9 Aug 93 20:57:09 -0700
Received: from romeo.cs.colorado.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA26923; Mon, 9 Aug 93 20:58:12 -0700
Received: from localhost by romeo.cs.Colorado.EDU with SMTP id AA14495
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Mon, 9 Aug 1993 21:56:58 -0600
Message-Id: <199308100356.AA14495@romeo.cs.Colorado.EDU>
To: riscy@pyramid.com
Subject: Re: Second level cache? 
In-Reply-To: Your message of "Mon, 09 Aug 1993 09:13:39 MDT."
             <9308091513.AA10979@agua.colorado.edu> 
Date: Mon, 09 Aug 1993 21:56:57 -0600
From: Drew Eckhardt <drew@romeo.cs.Colorado.EDU>
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


    
      > Adding the decreased locality of Unix+X11 over dos, the higher (100 Mhz
      > internal) clock rate, and mips binaries being bigger then 486 it would
      > seem that a large secondary cache would be necessary.  Based on a 486's
      > secondary cache being useful.
    
    The subject isn't that simple. For example the usefulness of the cache 
    greately depends on how the memory is interleaved 

Yes.  2-way interleaving can cut the wait states in half in the 
average case with a cache-miss, 4-way in half again, etc.  However,
the 4000, 4200, and 4400 are all 64 bit chips meaning you need 
a 128 bit wide memory subsystem for 2-way, 256 for 4-way.
    
    Also there is an issue of the internal cache size. An
    internal cache on a 486 is 16k 

No.  The internal cache on an Intel 486 is 8K combined I&D, although
IBM is building it's own 486's that may have a larger internal cache.

    but writethrough not write back. 

Yes.  This is very significant.  Also important are cache interleave,
line size, etc.  

    The R4xxxx has a larger internal cache.

R4000 : 8K I, 8K D
R4400 : 16K I, 16K D

The maximum imposed by the R4000 architecture is 32K each for the primary
cache.  I don't know about the 4200 since I don't have a data book in front
of me like I do for the NEC Vr4000 and Vr4400, PC, SC, and MC variants :-)
    
      > Any suggestions on how to get some numbers experimentally?
    
    Yea build an R4000 system with the desired level of interleaving; one with
    and one without secondary cache. Then run both systems :)

Yep.
    
--------

 
From owner-riscy@pyramid.com  Tue Aug 10 00:10:08 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA12495; Tue, 10 Aug 93 00:10:08 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28420; Mon, 9 Aug 93 21:09:44 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06063; Mon, 9 Aug 93 21:08:31 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06056; Mon, 9 Aug 93 21:08:29 -0700
Received: from romeo.cs.colorado.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28412; Mon, 9 Aug 93 21:09:31 -0700
Received: from localhost by romeo.cs.Colorado.EDU with SMTP id AA14595
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Mon, 9 Aug 1993 22:08:22 -0600
Message-Id: <199308100408.AA14595@romeo.cs.Colorado.EDU>
To: riscy@pyramid.com
Subject: Re: Second level cache? 
In-Reply-To: Your message of "Mon, 09 Aug 1993 17:23:56 +0200."
             <9308091523.AA13831@neptune> 
Date: Mon, 09 Aug 1993 22:08:21 -0600
From: Drew Eckhardt <drew@romeo.cs.Colorado.EDU>
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


    I don't know much about hardware design, but could you design the thing
    in such a way that you can plug in cache, when you need it.  IE: if you
    don't have the money, the board will run without the SC, and if you do,
    you just buy some SRAM, and plug 'er in...
    
    Or will this cause the logic to go beserk?

It could be configurable (ie, my i386 uses jumpers), the question is 
can a second level cache be done within the constraints of our
cost design goal.

R4x00 SC and MC chips include support for a second level cache, ie you 
throw enough SRAM on for tag, tag ECC, data, and data ECC with a 
few PALs for address decode and have it.  However, preliminary reports 
indicate the 4000SC has a ~$600 price tag rather than ~$300 for the 
4000PC, meaning using an SC is not practical in our design entirely
because of the cost constraint.

The question becomes : can we meet our cost target by having 
a second level cache *external* to the processor, with low
cost boards shipped with 0K SRAM.

--------

 
From owner-riscy@pyramid.com  Tue Aug 10 00:14:15 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA12651; Tue, 10 Aug 93 00:14:15 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28789; Mon, 9 Aug 93 21:13:34 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06394; Mon, 9 Aug 93 21:12:21 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06387; Mon, 9 Aug 93 21:12:19 -0700
Received: from vanbc.wimsey.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28778; Mon, 9 Aug 93 21:13:01 -0700
Received: by vanbc.wimsey.com (Smail3.1.28.1)
	id m0oPl3U-0000PZC; Mon, 9 Aug 93 21:11 PDT
Message-Id: <m0oPl3U-0000PZC@vanbc.wimsey.com>
From: bhenning@wimsey.com (Bill Henning)
Subject: Re: Second level cache?
To: riscy@pyramid.com
Date: Mon, 9 Aug 1993 21:11:23 -0700 (PDT)
In-Reply-To: <9308091454.AA14466@gossip.pyramid.com> from "Bill Broadley" at Aug 9, 93 10:52:43 am
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1439      
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> Somebody mentioned that some research needs to be done on how a second level 
> cache will effect performance.  Any suggestions on how to do this?

One data point: 486DX2/66, IBM's CSet/2 compiler, 16Mb ram, 256k L2 cache
compile time is aprox. 2.5x faster with the L2 cache than without.

> Based on observation it seems that a cache is worth it, SGI mips 4000 SC is
> around 35/34 and the mips 4000 PC is around 60/58 specint/specfp.

Agreed.

> Adding the decreased locality of Unix+X11 over dos, the higher (100 Mhz
> internal) clock rate, and mips binaries being bigger then 486 it would
> seem that a large secondary cache would be necessary.  Based on a 486's
> secondary cache being useful.

I would suggest 256k expandable to 1Mb. Maybe someone could run some apps
on the MIPS simulator, and instrument the emulator to record the saved cycles
for caches of different sizes.

> Any suggestions on how to get some numbers experimentally?

See above.

> I have a decstation 3100 running Ultrix, and a 486/66 running linux
> available for any attempts to quantify the advantages of second level
> cache's.

Can you turn its L2 cache off under software/hardware control?
If you can, you might want to try the following with the L2 cache enabled/
disabled, and if you do, please post both sets of numbers:

- recompiling gcc
- cross compiling the Linux kernal
- x11perf
- a database test of some sort
- the Byte unix benchmarks

Bill
 
From owner-riscy@pyramid.com  Tue Aug 10 03:01:55 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA16491; Tue, 10 Aug 93 03:01:55 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17596; Tue, 10 Aug 93 00:01:46 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA27483; Tue, 10 Aug 93 00:00:27 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA27476; Tue, 10 Aug 93 00:00:21 -0700
Received: from erasmus.et.tudelft.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17525; Tue, 10 Aug 93 00:01:23 -0700
Received: by erasmus.et.tudelft.nl (1.37.109.4/1.34JP)
          id AA22443; Tue, 10 Aug 93 09:00:03 +0200
Date: Tue, 10 Aug 93 09:00:03 +0200
From: wolff@erasmus.et.tudelft.nl (Rogier Wolff)
Message-Id: <9308100700.AA22443@erasmus.et.tudelft.nl>
To: riscy@pyramid.com
Subject: R4xxx Cache size.
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


>    The R4xxxx has a larger internal cache.
>
>R4000 : 8K I, 8K D
>R4400 : 16K I, 16K D
>
>The maximum imposed by the R4000 architecture is 32K each for the primary
>cache.  I don't know about the 4200 since I don't have a data book in front
>of me like I do for the NEC Vr4000 and Vr4400, PC, SC, and MC variants :-)
    
Huh? Does that mean that the ARCHITECTURE defines a maximum CACHE size?
According to current definitions here at the computer architecture group,
cache size is an implementation aspect, and shouldn't be visible at the
architectural level.

-----
This means that the R4xxx has a bad design: the design mixes implementation 
with architectural features. The R4000 isn't as clean as we thought. This
means that we can't use the R4000 as the processor.... :-)
-----

				Roger.


 
From owner-riscy@pyramid.com  Tue Aug 10 03:31:11 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA17818; Tue, 10 Aug 93 03:31:11 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21864; Tue, 10 Aug 93 00:31:12 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA00614; Tue, 10 Aug 93 00:29:59 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA00607; Tue, 10 Aug 93 00:29:56 -0700
Received: from bernina.ethz.ch 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21856; Tue, 10 Aug 93 00:30:58 -0700
Received: from neptune by bernina.ethz.ch with SMTP inbound id <17043-0@bernina.ethz.ch>; Tue, 10 Aug 1993 09:29:43 +0200
Message-Id: <9308100729.AA24344@neptune>
Received: from tau.inf.ethz.ch by neptune id AA24344; Tue, 10 Aug 93 09:29:39 +0200
To: riscy@pyramid.com
Subject: Re: Second level cache? 
In-Reply-To: Your message of "Mon, 09 Aug 93 22:08:21 MDT."
	     <199308100408.AA14595@romeo.cs.Colorado.EDU> 
Date: Tue, 10 Aug 93 09:29:38 +0200
From: weingart@inf.ethz.ch
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

You write: 
Sie schreiben: 

> It could be configurable (ie, my i386 uses jumpers), the question is 
> can a second level cache be done within the constraints of our
> cost design goal.

What is our cost design goal?  $2000 US?  Less?  More?


> R4x00 SC and MC chips include support for a second level cache, ie you 
> throw enough SRAM on for tag, tag ECC, data, and data ECC with a 
> few PALs for address decode and have it.  However, preliminary reports 
> indicate the 4000SC has a ~$600 price tag rather than ~$300 for the 
> 4000PC, meaning using an SC is not practical in our design entirely
> because of the cost constraint.

For low cost, I would not think about the SC/MC chips.  They have
400+ pins, and that will be a nightmare to make a cheap board out of.

I was more thinking along the lines of a 4000PC, with an external
cache controller.  I don't know if it's possible, but that would
take our pin count down to ~180 pins...

--Toby.
--------------------------------------------------------------
|Tobias Weingartner  |    PGP2.x Public Key available at     |
| +41'01'254'7205    |   'finger weingart@tau.inf.ethz.ch'   |
--------------------------------------------------------------
%SYSTEM-F-ANARCHISM, the operating system has been overthrown
 
From owner-riscy@pyramid.com  Tue Aug 10 04:48:07 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA19719; Tue, 10 Aug 93 04:48:07 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28292; Tue, 10 Aug 93 01:47:50 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08392; Tue, 10 Aug 93 01:46:26 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08384; Tue, 10 Aug 93 01:46:24 -0700
Received: from romeo.cs.colorado.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28237; Tue, 10 Aug 93 01:47:21 -0700
Received: from localhost by romeo.cs.Colorado.EDU with SMTP id AA16911
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Tue, 10 Aug 1993 02:46:08 -0600
Message-Id: <199308100846.AA16911@romeo.cs.Colorado.EDU>
To: riscy@pyramid.com
Subject: Re: R4xxx Cache size, pedantic ramblings
In-Reply-To: Your message of "Tue, 10 Aug 1993 09:00:03 +0200."
             <9308100700.AA22443@erasmus.et.tudelft.nl> 
Date: Tue, 10 Aug 1993 02:46:06 -0600
From: Drew Eckhardt <drew@romeo.cs.Colorado.EDU>
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


    >
    >R4000 : 8K I, 8K D
    >R4400 : 16K I, 16K D
    >
    >The maximum imposed by the R4000 architecture is 32K each for the primary
    >cache.  I don't know about the 4200 since I don't have a data book in fron
   t
    >of me like I do for the NEC Vr4000 and Vr4400, PC, SC, and MC variants :-)
        
    Huh? Does that mean that the ARCHITECTURE defines a maximum CACHE size?

    According to current definitions here at the computer architecture group,
    cache size is an implementation aspect, and shouldn't be visible at the
    architectural level.

Other people or groups, have different definitions.  Many software 
people consider architecture to be a given combination of machine,
cpu, and operating system.  Some vendors consider it to be their
register and instruction set definitions, including bit fields
(BTW, if this were the case the limit would have been stated as
512K each for the primary caches), others consider it to be their 
implementation (NEC's data book seems to use this definition since 
it's not using one of the others)


According to 

_MIPS R4000 USER'S MANUAL_

by Joseph Heinrich

which happens to be what NEC is calling their 

VR4000-SERIES(tm)ARCHITECTURE
		 ^^^^^^^^^^^^
INCLUDING VR4400(tm)
USER'S MANUAL

under the "Processor General Features" heading of page 6 

"Cache Control,  The R4000 primary instruction and data caches reside on-chip, 
and can each hold 8K bytes.  In the R4400 processor, the primary caches can 
each hold 16K bytes.  Architecturally, each primary cache can be increased to
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
hold up to 32K bytes.  An off-chip secondary cache (R4000SC and R4000MC
^^^^^^^^^^^^^^^^^^^^
processors only) can hold from 128 Kbytes  to 4 Mbytes.  All processor
cache control logic, including the secondary cache control logic, is on
chip"

Their usage of "architecture" seems to indicate a usage refering 
to their implementation as perfectly acceptable.  What does it matter?  As 
long as the chip does what we want, I don't care what their definition of 
architecture is.

    -----
    This means that the R4xxx has a bad design: the design mixes implementation
    
    with architectural features. The R4000 isn't as clean as we thought. This
    means that we can't use the R4000 as the processor.... :-)

    -----

For those who care about the facts and not what definition of "architecture"
was used,  here are a few interesting factoids that would affect relative 
cache hit rates of an i486 (baseline) and our system...

1.  Primary I/D caches are separate.

2.  The 4000PC has 8K I/D caches, the biggest R4000 series chips SHIPPING have 
	16K I/D caches.

3.  The caches are direct mapped.

4.  Line size is user-configurable to either 16 or 32 bytes wide.

5.  The data cache can be write-back.

6.  All instructions are 32 bits.

Compare to the i486 if you want : 

1.  There is a single cache.

2.  The i486 has an 8K cache.

3.  The primary cache is set associative (I think  4-way).

4.  Primary cache line size is 16 bytes

5.  The primary cache is write-through.

6.  Some instructions are one byte, many are two-byte, 16 bit 
	accesses require a prefix in a 32 bit mode task, 
	other things require prefixes.

 
From owner-riscy@pyramid.com  Tue Aug 10 05:15:58 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA20335; Tue, 10 Aug 93 05:15:58 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA00273; Tue, 10 Aug 93 02:03:57 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA11429; Tue, 10 Aug 93 02:02:40 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA11370; Tue, 10 Aug 93 02:02:37 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA00265; Tue, 10 Aug 93 02:03:39 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id HN11329; Tue, 10 Aug 1993 10:59:18 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA30144; Tue, 10 Aug 93 10:59:43 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA06015; Tue, 10 Aug 93 10:59:39 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Tue, 10 Aug 93 10:58:48 +0200
Message-Id: <9308100858.AA20798@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA20798; Tue, 10 Aug 93 10:58:48 +0200
To: riscy@pyramid.com
Subject: Re:  R4xxx Cache size.
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> >    The R4xxxx has a larger internal cache.
> >
> >R4000 : 8K I, 8K D
> >R4400 : 16K I, 16K D
> >
> >The maximum imposed by the R4000 architecture is 32K each for the primary
> >cache.  I don't know about the 4200 since I don't have a data book in front
> >of me like I do for the NEC Vr4000 and Vr4400, PC, SC, and MC variants :-)
>     
> Huh? Does that mean that the ARCHITECTURE defines a maximum CACHE size?
> According to current definitions here at the computer architecture group,
> cache size is an implementation aspect, and shouldn't be visible at the
> architectural level.
> 
> -----
> This means that the R4xxx has a bad design: the design mixes implementation 
> with architectural features. The R4000 isn't as clean as we thought. This
> means that we can't use the R4000 as the processor.... :-)
> -----

Oh, please stop that noise. I don't know who told you that the
cache size of a R4000 is limited to 32+32k. Can you tell me how it
would then be possible to add a secondary cache ????
The limitation, if there is one, is given by the chip size, not
by any architectural problem !
If you would take a look at the R4200 layout, you would see that
more than 70 percent of the chip space is used by rams !

Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Tue Aug 10 05:16:10 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA20362; Tue, 10 Aug 93 05:16:10 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA01197; Tue, 10 Aug 93 02:12:30 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA12586; Tue, 10 Aug 93 02:10:28 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA12575; Tue, 10 Aug 93 02:10:25 -0700
Received: from liberator.et.tudelft.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA00947; Tue, 10 Aug 93 02:11:21 -0700
Received: by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA09361; Tue, 10 Aug 93 11:08:48 +0200
Date: Tue, 10 Aug 93 11:08:48 +0200
From: wolff@liberator.et.tudelft.nl (Rogier Wolff)
Message-Id: <9308100908.AA09361@liberator.et.tudelft.nl>
To: 1@liberator.et.tudelft.nl, 11@liberator.et.tudelft.nl, riscy@pyramid.com
Subject: Re: R4xxx Cache size, pedantic ramblings
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

	According to 

	_MIPS R4000 USER'S MANUAL_

	by Joseph Heinrich

	which happens to be what NEC is calling their 

	VR4000-SERIES(tm)ARCHITECTURE
			 ^^^^^^^^^^^^
	INCLUDING VR4400(tm)
	USER'S MANUAL

This agrees with "our" definition of architecture: architecture is
what the user will see of a processor. The cache size should be 
more or less transparent. A specialized timing program might figure
it out, the user manual might mention that the current chips have
a such-and-such cache size, but users shouldn't be able to poke
around at the cache such that they need to be aware of the cache
size. 

It seems that the R4xxxx designers found a reason
that requires the OS or the Users access to (part of) the cache,
and have limited an address field to 15 bits. This isn't really critical.

The '486 has : 

	1.  There is a single cache.
	2.  The i486 has an 8K cache.
	3.  The primary cache is set associative (I think  4-way).
	4.  Primary cache line size is 16 bytes
	5.  The primary cache is write-through.

Compare to R4000:
	1.  Primary I/D caches are separate.
This is an advantage: If one of the caches starts thrashing, the other
might still function properly. Thrashing is when a cache is completely
uneffective, because the program almost never references an element in
the cache.
	2.  The 4000PC has 8K I/D caches, the biggest R4000 series chips 
		SHIPPING have 16K I/D caches.
Ok. Larger caches are better.
	3.  The caches are direct mapped.
This is an disadvantage. Set associative is better (but the difference 
might on the average be neglectable).
Lets assume a cache size of 4000 bytes. Both caches can cache elements
at address 0, 1000, 2000 and 3000 at the same time. However should
a program reference 0, 4000, 8000 and 16000 at the same time, the set
associative cache will be able to cache them all four, whereas the 
direct mapped cache can only hold one of them.
	4.  Line size is user-configurable to either 16 or 32 bytes wide.
Depending on the speed of the page-mode, having a larger line size
will be worse or better.
	5.  The data cache can be write-back.
Depending on the application this is an advantage. Fact is that OS's
can do very little to optimize the use of this bit. You run a benchmark,
decide which setting of the bit is best, and leave it that way.
(Intel probably did this before releasing the chip..... :-)
	6.  All instructions are 32 bits.
This has nothing to do with caches.


				Roger.

 
From owner-riscy@pyramid.com  Tue Aug 10 05:26:02 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA20860; Tue, 10 Aug 93 05:26:02 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA02325; Tue, 10 Aug 93 02:25:49 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA13914; Tue, 10 Aug 93 02:24:37 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA13907; Tue, 10 Aug 93 02:24:34 -0700
Received: from ganymede.inmos.co.uk 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA02313; Tue, 10 Aug 93 02:25:35 -0700
Received: from eagle.inmos.co.uk by ganymede.inmos.co.uk; Tue, 10 Aug 93 10:23:05 BST
From: Bob Green <bob@inmos.co.uk>
Message-Id: <3864.9308100922@eagle.inmos.co.uk>
Subject: Please remove me from the list
To: riscy@pyramid.com
Date: Tue, 10 Aug 1993 10:22:46 +0100 (BST)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 23        
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

See the subject.

-Bob
 
From owner-riscy@pyramid.com  Tue Aug 10 05:41:18 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA21264; Tue, 10 Aug 93 05:41:18 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA03652; Tue, 10 Aug 93 02:40:49 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15525; Tue, 10 Aug 93 02:39:36 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15516; Tue, 10 Aug 93 02:39:34 -0700
Received: from romeo.cs.colorado.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA03626; Tue, 10 Aug 93 02:40:37 -0700
Received: from localhost by romeo.cs.Colorado.EDU with SMTP id AA17308
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Tue, 10 Aug 1993 03:39:25 -0600
Message-Id: <199308100939.AA17308@romeo.cs.Colorado.EDU>
To: riscy@pyramid.com
Subject: Re: R4xxx Cache size. 
In-Reply-To: Your message of "Tue, 10 Aug 1993 10:58:48 +0200."
             <9308100858.AA20798@resi.waldorf-gmbh.de> 
Date: Tue, 10 Aug 1993 03:39:21 -0600
From: Drew Eckhardt <drew@romeo.cs.Colorado.EDU>
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


    
    Oh, please stop that noise. I don't know who told you that the
    cache size of a R4000 is limited to 32+32k. 

Like I said, what NEC is passing out as one of their data books. Generally,
these things are technically accurate, although I'm begining to have my 
doubts.

After reading a few more chapters of the data book including the 
one on caching, nothing beyond the number of virtual address bits 
used as a cache index in the author's examples seems to back this 
up.  In hindsight, the statement I summarized from the data book
doesn't really sanity check, in school you quickly learn that in
many (most?) classes you get reasonable grades by blindly reciting 
the text book contents and telling the instructors what they want
to hear :-(

    Can you tell me how it would then be possible to add a secondary cache ????

Again, I said *primary* cache size, which has nothing to do with 
the (presumably off chip) second level cache.

    If you would take a look at the R4200 layout, you would see that
    more than 70 percent of the chip space is used by rams !

I'd take a look at the R4200 layout, but the local NEC distributor
didn't get anything on the 4000 series chips until Friday, and still
won't say anything about pricing or the 4200 :-(
 
From owner-riscy@pyramid.com  Tue Aug 10 05:52:48 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA21474; Tue, 10 Aug 93 05:52:48 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04591; Tue, 10 Aug 93 02:52:49 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16782; Tue, 10 Aug 93 02:51:34 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16775; Tue, 10 Aug 93 02:51:31 -0700
Received: from romeo.cs.colorado.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04543; Tue, 10 Aug 93 02:52:34 -0700
Received: from localhost by romeo.cs.Colorado.EDU with SMTP id AA17424
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Tue, 10 Aug 1993 03:51:25 -0600
Message-Id: <199308100951.AA17424@romeo.cs.Colorado.EDU>
To: riscy@pyramid.com
Subject: Re: R4xxx Cache size, pedantic ramblings 
In-Reply-To: Your message of "Tue, 10 Aug 1993 11:08:48 +0200."
             <9308100908.AA09361@liberator.et.tudelft.nl> 
Date: Tue, 10 Aug 1993 03:51:24 -0600
From: Drew Eckhardt <drew@romeo.cs.Colorado.EDU>
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


--------

    Compare to R4000:
    	6.  All instructions are 32 bits.
    This has nothing to do with caches.

Indirectly, it does.

I should have been more specific here : specifically, I was 
getting at the lack of variable sized instructions forcing the 
instructions to be bigger (ie, 32 bits for the R4000 vs. 8,16, etc. 
for the i486) meaning the R4000 will have larger code and will 
therefore require a larger cache to maintain the same hit-rate.

I should have generalized more and said 

"RISC chips have bigger code than CISC chips, and therefore will
need larger caches to have the same hit rate"

--------

 
From owner-riscy@pyramid.com  Tue Aug 10 07:08:09 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA23134; Tue, 10 Aug 93 07:08:09 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA10074; Tue, 10 Aug 93 04:08:02 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA25199; Tue, 10 Aug 93 04:06:44 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA25192; Tue, 10 Aug 93 04:06:41 -0700
Received: from romeo.cs.colorado.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA10023; Tue, 10 Aug 93 04:07:43 -0700
Received: from localhost by romeo.cs.Colorado.EDU with SMTP id AA17966
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Tue, 10 Aug 1993 05:06:33 -0600
Message-Id: <199308101106.AA17966@romeo.cs.Colorado.EDU>
To: riscy@pyramid.com
Subject: Re: Second level cache? 
In-Reply-To: Your message of "Tue, 10 Aug 1993 09:29:38 +0200."
             <9308100729.AA24344@neptune> 
Date: Tue, 10 Aug 1993 05:06:32 -0600
From: Drew Eckhardt <drew@romeo.cs.Colorado.EDU>
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


    > It could be configurable (ie, my i386 uses jumpers), the question is 
    > can a second level cache be done within the constraints of our
    > cost design goal.
    
    What is our cost design goal?  $2000 US?  Less?  More?

From what I remember, discussions on the mailing list have placed this 
somewhere between $600 and $800 for a mainboard with dumb frame 
buffer (using MAC VRAM SIMMs), SCSI, serial ports, parallel
ports, IDE, and ethernet onboard, where some unpopular 
features (ethernet has been named as the first thing to
go in the base configuration) may be designed in but the 
sockets left empty to facilitate meeting this goal.
    
    > R4x00 SC and MC chips include support for a second level cache, ie you 
    > throw enough SRAM on for tag, tag ECC, data, and data ECC with a 
    > few PALs for address decode and have it.  However, preliminary reports 
    > indicate the 4000SC has a ~$600 price tag rather than ~$300 for the 
    > 4000PC, meaning using an SC is not practical in our design entirely
    > because of the cost constraint.
    
    For low cost, I would not think about the SC/MC chips.  They have
    400+ pins, and that will be a nightmare to make a cheap board out of.

That's about what I was getting at.
    
    I was more thinking along the lines of a 4000PC, with an external
    cache controller.  I don't know if it's possible, but that would
    take our pin count down to ~180 pins...

I had been thinking along the same lines, but don't know 
how practical it would be.

Existing cache sets aren't likely to directly support the r4000 system
interface, (64 bit A/D bus + 8 bit parity / ECC + 9 bit command 
bus +  1 bit parity + handshaking signals) since this is a departure
from other systems, the chips are new, and the high end chips that
will be using external caches allready support them.

Weather we can force something existing to do what we want is 
another issue - you can ignore the high 32 bits of the address, you 
can disable parity/ECC checking, can mangle various read and write 
commands to look like what the external cache controller expects,
the 4000 chips flag the last read/write in a burst transfer so bursts
could be handled with counter latched when the address was specified, 
incrementing on each read/write handshake, etc. but the external logic to 
do all of this will increase propogation delays which might make it 
impossible with the parts when can afford.

Another alternative would be be having what passes as a memory
controller in the talk to some other cache/memory controller
instead of DRAM, again, you can't say that it will work until
you see what the timing looks like.

IMHO : a lot of things would be "neat," ie the second level
cache, but no one has suggested chips that would be useful, with 
pricing for said chips to determine weather they work for 
us.

Waiting for an initial lead on these chips to drop out of thin air
(as was the case with the 4200 with someone stumbling across a MIPS 
press on the net, other people following up on NEC second sourcing
them, and people on the list finally ending up with more solid data
some time later) will take a random, potentially infinite amount
of time :-)

IMHO : We need to get parts and prices so their feasibility can be studied
before a design is done, or we need to go ahead with a design so us
software people have something to play with.
































    
    --Toby.
    --------------------------------------------------------------
    |Tobias Weingartner  |    PGP2.x Public Key available at     |
    | +41'01'254'7205    |   'finger weingart@tau.inf.ethz.ch'   |
    --------------------------------------------------------------
    %SYSTEM-F-ANARCHISM, the operating system has been overthrown

--------

 
From owner-riscy@pyramid.com  Tue Aug 10 09:08:11 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA26721; Tue, 10 Aug 93 09:08:11 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20140; Tue, 10 Aug 93 06:07:16 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06938; Tue, 10 Aug 93 06:05:47 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06931; Tue, 10 Aug 93 06:05:44 -0700
Received: from bernina.ethz.ch 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20124; Tue, 10 Aug 93 06:06:47 -0700
Received: from neptune by bernina.ethz.ch with SMTP inbound id <800-0@bernina.ethz.ch>; Tue, 10 Aug 1993 15:05:27 +0200
Message-Id: <9308101305.AA27360@neptune>
Received: from tau.inf.ethz.ch by neptune id AA27360; Tue, 10 Aug 93 15:05:23 +0200
To: riscy@pyramid.com
Subject: Re: Second level cache? 
In-Reply-To: Your message of "Tue, 10 Aug 93 05:06:32 MDT."
	     <199308101106.AA17966@romeo.cs.Colorado.EDU> 
Date: Tue, 10 Aug 93 15:05:22 +0200
From: weingart@inf.ethz.ch
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

You write: 
Sie schreiben: 

>     What is our cost design goal?  $2000 US?  Less?  More?
> 
> From what I remember, discussions on the mailing list have placed this 
> somewhere between $600 and $800 for a mainboard with dumb frame 
> buffer (using MAC VRAM SIMMs), SCSI, serial ports, parallel
> ports, IDE, and ethernet onboard, where some unpopular 
> features (ethernet has been named as the first thing to
> go in the base configuration) may be designed in but the 
> sockets left empty to facilitate meeting this goal.

Ok, junk the IDE.  I realize that you can get cheap IDE drives, etc,
but SCSI is getting pretty cheap too, and fast SCSI would be pleanty fast
for a *personal* machine.  Then again, if it only costs a cent or two,
why not keep it in.  Make the PC dudes happy.

I'd definitely want to be able to use ethernet.  Wether that will be add
on, or not is a money issue (I persume).  The machine becomes next to
unusable to me if I have to resort to SLIP over a slow link...

(What type of ethernet connector would this be?)


> Existing cache sets aren't likely to directly support the r4000 system
> interface, (64 bit A/D bus + 8 bit parity / ECC + 9 bit command 
> bus +  1 bit parity + handshaking signals) since this is a departure
> from other systems, the chips are new, and the high end chips that
> will be using external caches allready support them.

What sort of bandwidth does the R4kPC need?  How about some real
figures, using from 1 - N waitstates, from 0 - 100 MHz, etc.  I don't
have a databook handy, so can someone look them up?


> Weather we can force something existing to do what we want is 
> another issue - you can ignore the high 32 bits of the address, you 
> can disable parity/ECC checking, can mangle various read and write 
> commands to look like what the external cache controller expects,
> the 4000 chips flag the last read/write in a burst transfer so bursts
> could be handled with counter latched when the address was specified, 
> incrementing on each read/write handshake, etc. but the external logic to 
> do all of this will increase propogation delays which might make it 
> impossible with the parts when can afford.

Hmm, does MIPS (or an alternative manufacturer) offer a DRAM controller
that directly interfaces to the R4kPC?  That might be the cheapest
(maybe fastest too) way to go.

Maybe a more cost effective alternative (already mentioned once) would be
to just interleave the DRAM.  Not as "neat" as a cache, but if we need to
keep cost down below US$800...


> IMHO : We need to get parts and prices so their feasibility can be studied
> before a design is done, or we need to go ahead with a design so us
> software people have something to play with.

I agree with the first version of this.  This way the design will not change
once it is laid down.  That way the software does not have to be kludged to
fit later.  From working on PC systems, I find a lack of percise (sp?) and
clear documentation to be the biggest stumbling block.  IE: How can you port
an OS, if you don't have the specs to the machine?


--Toby.
--------------------------------------------------------------
|Tobias Weingartner  |    PGP2.x Public Key available at     |
| +41'01'254'7205    |   'finger weingart@tau.inf.ethz.ch'   |
--------------------------------------------------------------
%SYSTEM-F-ANARCHISM, the operating system has been overthrown
 
From owner-riscy@pyramid.com  Tue Aug 10 09:14:27 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA26976; Tue, 10 Aug 93 09:14:27 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20819; Tue, 10 Aug 93 06:13:50 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08119; Tue, 10 Aug 93 06:12:37 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08112; Tue, 10 Aug 93 06:12:35 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20811; Tue, 10 Aug 93 06:13:38 -0700
Message-Id: <9308101313.AA20811@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA21525; Tue, 10 Aug 93 09:11:25 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Mips chips/performance
To: riscy@pyramid.com (Mips 3000)
Date: Tue, 10 Aug 1993 09:11:25 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1380      
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

Here's a little performance table:
	SpecINT Spec FP92 	Mhz	Cache
Mips 3000 27.3  29.3    40      0+128k	    Dec 5240 numbers
486/66	  32	16 	33/66	8k	    Intel announcement*
4000PC	  35	34	50/100	8k+8k	    Sgi periodic chart
4200	  55	30	40/80	8k+16k?	    Nec Broshure (no details)*
4000SC	  60	58	50/100  8k+8k+1MB   SGI periodic chart
Powerpc   60+	80+	66	32k	    Motorolla ad *
Pentium   64.5	56.9	66	8k+8k	    Intel announcement * 
R4400SC	  97	88	75/150	16k+16k+1MB SGI periodic chart.

* = Spec numbers are probably obtained using an unmentioned 2nd level cache.

IMHO anything at the 4200 performance level or above looks great to me.

Question is how does the 4200 get it's speed?  It running 20% slower then the
mips 4000PC, and supposedly has longer pipelines, and less fp support.

Is it possible it supports a second level cache? Or it it just above a very
important 1st level cache threshold that gives it twice the perfomance of the
4200 for this benchmark? (I.e. in real world not faster then the 4000PC)

Or was the 4200 paired with some custom memory subsystem that implemented
a seperate cache controller for the 2nd level cache? 

Speculation welcome.
-- 
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 owner-riscy@pyramid.com  Tue Aug 10 09:39:15 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA28045; Tue, 10 Aug 93 09:39:15 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21563; Tue, 10 Aug 93 06:39:02 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA09404; Tue, 10 Aug 93 06:37:49 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA09397; Tue, 10 Aug 93 06:37:47 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21555; Tue, 10 Aug 93 06:38:46 -0700
Message-Id: <9308101338.AA21555@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA21712; Tue, 10 Aug 93 09:36:31 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: arc100/150 kits
To: riscy@pyramid.com (Mips 3000)
Date: Tue, 10 Aug 1993 09:36:31 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1136      
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

Sorry no new info just a few CLOSE looks at the 1 page description.

I believe they are simply 50 Mhz motherboards, with 5 ISA slots, and 8
simm slots.  

Also included are designs for 3 boards Ethernet/serial, Audio/mouse, video.

This kinda/sorta implies scsi is on the motherboard.

I'm not sure how making 3 boards instead of 1 effects price, or if this is at 
all accurate, but the pictures certainly look this way.

I suspect the video/audio/mouse/ethernet are included so that firmware
is compatible with WIndows NT, which this board seems to support.

Sorry I don't have more info.  The slot's pictured are definitely NOT VESA,
do EISA connectors look just like ISA or do they have an additional
connector like VESA does?  In any case the slots look like 1 piece 16 bit
ISA connectors.

So maybe there boards aren't the magic answer I hoped for, but the chips
on the board (MCT-ADR and MCT-DP) still look very useful.

-- 
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 owner-riscy@pyramid.com  Tue Aug 10 09:52:23 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA28609; Tue, 10 Aug 93 09:52:23 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21783; Tue, 10 Aug 93 06:52:10 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA10252; Tue, 10 Aug 93 06:50:57 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA10245; Tue, 10 Aug 93 06:50:55 -0700
Received: from fngate.fnal.gov 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21772; Tue, 10 Aug 93 06:51:58 -0700
Received: by fngate.fnal.gov (5.57/Ultrix3.0-C)
	id AA06101; Tue, 10 Aug 93 08:50:47 -0500
Received: by fncrdg.fnal.gov (920330.SGI/890607.SGI)
	(for ) id AA22261; Tue, 10 Aug 93 08:48:24 -0500
From: rohrer@fncrd8.fnal.gov (Keith Rohrer)
Message-Id: <9308101348.AA22261@fncrdg.fnal.gov>
Subject: Re: Second level cache?
To: riscy@pyramid.com
Date: Tue, 10 Aug 1993 08:48:23 -0600 (CDT)
In-Reply-To: <9308101305.AA27360@neptune> from "weingart@inf.ethz.ch" at Aug 10, 93 03:05:22 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: 1228      
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

[as elm fries attributions]
> >     What is our cost design goal?  $2000 US?  Less?  More?
> > From what I remember, discussions on the mailing list have placed this 
> > somewhere between $600 and $800 for a mainboard with dumb frame 
> > buffer (using MAC VRAM SIMMs), SCSI, serial ports, parallel
> > ports, IDE, and ethernet onboard, where some unpopular 
> > features (ethernet has been named as the first thing to
> > go in the base configuration) may be designed in but the 
> > sockets left empty to facilitate meeting this goal.
> 
> Ok, junk the IDE.  I realize that you can get cheap IDE drives, etc,
Junk IDE as built-in to the mainboard, but don't forget the ISA bus!
Unless, as is said later, the IDE-on-the-motherboard is dirt cheap,
nobody really needs it; on the other hand, for expansion, lots of
us want or need ISA...

> but SCSI is getting pretty cheap too, and fast SCSI would be pleanty fast
For me, the cost of SCSI would be the cost of replacing ~450 megabytes of
hard drive.  Not happening.  Sorry.
> for a *personal* machine.  Then again, if it only costs a cent or two,
> why not keep it in.  Make the PC dudes happy.
You mean, don't invalidate some people's current investment?

[deletia]
 
	Keith


 
From owner-riscy@pyramid.com  Tue Aug 10 10:19:11 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA29755; Tue, 10 Aug 93 10:19:11 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23696; Tue, 10 Aug 93 07:19:00 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA11081; Tue, 10 Aug 93 07:16:38 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA11074; Tue, 10 Aug 93 07:16:35 -0700
Received: from frisbee.cs.colorado.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23682; Tue, 10 Aug 93 07:17:38 -0700
Received: from localhost by frisbee.cs.Colorado.EDU with SMTP id AA25613
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Tue, 10 Aug 1993 08:16:26 -0600
Message-Id: <199308101416.AA25613@frisbee.cs.Colorado.EDU>
To: riscy@pyramid.com
Subject: Re: Mips chips/performance 
In-Reply-To: Your message of "Tue, 10 Aug 1993 09:11:25 CDT."
             <9308101313.AA20811@gossip.pyramid.com> 
Date: Tue, 10 Aug 1993 08:16:14 -0600
From: Drew Eckhardt <drew@frisbee.cs.Colorado.EDU>
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


--------

    Here's a little performance table:
    	SpecINT Spec FP92 	Mhz	Cache
    Mips 3000 27.3  29.3    40      0+128k	    Dec 5240 numbers
    486/66	  32	16 	33/66	8k	    Intel announcement*
    4000PC	  35	34	50/100	8k+8k	    Sgi periodic chart
    4200	  55	30	40/80	8k+16k?	    Nec Broshure (no details)*
    4000SC	  60	58	50/100  8k+8k+1MB   SGI periodic chart
    Powerpc   60+	80+	66	32k	    Motorolla ad *
    Pentium   64.5	56.9	66	8k+8k	    Intel announcement * 
    R4400SC	  97	88	75/150	16k+16k+1MB SGI periodic chart.
    
    
    IMHO anything at the 4200 performance level or above looks great to me.
    
    Question is how does the 4200 get it's speed?  It running 20% slower then t
   he
    mips 4000PC, and supposedly has longer pipelines, and less fp support.

Posibilities are 

- longer pipelines

- bigger on-chip cache

- different process, since it is a low power 3.3V part

- different 'C' compiler used for marketing purposes

- extern second level caches

    Is it possible it supports a second level cache? 

At the 4200's price, and the PC's price, I rather doubt that it has built in 
support for a second level cache.  

    Or it it just above a very
    important 1st level cache threshold that gives it twice the perfomance of t
   he
    4200 for this benchmark? (I.e. in real world not faster then the 4000PC)

Could be.
    
    Or was the 4200 paired with some custom memory subsystem that implemented
    a seperate cache controller for the 2nd level cache? 

Could be.
    
--------

 
From owner-riscy@pyramid.com  Tue Aug 10 11:38:03 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA03796; Tue, 10 Aug 93 11:38:03 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05020; Tue, 10 Aug 93 08:37:17 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA20724; Tue, 10 Aug 93 08:35:29 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA20682; Tue, 10 Aug 93 08:35:27 -0700
Received: from dartvax.dartmouth.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04876; Tue, 10 Aug 93 08:36:29 -0700
Received: from prancer.dartmouth.edu by dartvax.dartmouth.edu (5.65+D5/4.5HUB)
	id AA25956; Tue, 10 Aug 93 11:34:04 -0400
Message-Id: <5751994@prancer.Dartmouth.EDU>
Date: 10 Aug 93 11:33:59 EDT
From: Steven.D.Ligett@Dartmouth.EDU (Steven D. Ligett)
Subject: Re: R4200
To: riscy@pyramid.com
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

--- Drew Eckhardt wrote:
I'd take a look at the R4200 layout, but the local NEC distributor didn't get
anything on the 4000 series chips until Friday, and still won't say anything
about pricing or the 4200 :-(
--- end of quoted material ---
My distributor says that samples of the r4200 will be available by year end. 
Production will be by the end of the first quarter, 1994.  Small quantity
pricing will be around $289.  All of this is subject to change.  

It sounds like an interesting chip.
 
From owner-riscy@pyramid.com  Tue Aug 10 14:18:21 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA12289; Tue, 10 Aug 93 14:18:21 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04308; Tue, 10 Aug 93 11:17:53 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16542; Tue, 10 Aug 93 11:16:29 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16534; Tue, 10 Aug 93 11:16:26 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9308101816.AA16534@sword.eng.pyramid.com>
Subject: Re: Second level cache?
To: riscy@pyramid.com
Date: Tue, 10 Aug 93 11:16:25 PDT
In-Reply-To: <199308101106.AA17966@romeo.cs.Colorado.EDU>; from "Drew Eckhardt" at Aug 10, 93 5:06 am
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> Another alternative would be be having what passes as a memory
> controller in the talk to some other cache/memory controller
> instead of DRAM, again, you can't say that it will work until
> you see what the timing looks like.

What I understand is that the ARC chipset supports a secondary cache
similar to the way it does for the 486.  It is not necessary to use
the cache support signals from the R4k to have a secondary cache, although
it may mean that this cache will take two cycles to access data where
the R4000SC cache would take one.  This may not be great, but it is still
better than the cycles required to get data from DRAM.

Note that I am guessing about the timing issue; it may be that the ARC
chipset's cache logic can handle one cycle access.

With the ARC chipset's arangement, it is possible to add cache the same
as you would with a 486 MB; probably using the same cache chips.

BTW, Pyramid has a R4000MC machine, which uses the maximum 4Mbytes of
secondary cache.  I will ask if anyone has done some serious benchmarks
on how well this works.

> Waiting for an initial lead on these chips to drop out of thin air
> (as was the case with the 4200 with someone stumbling across a MIPS 
> press on the net, other people following up on NEC second sourcing
> them, and people on the list finally ending up with more solid data
> some time later) will take a random, potentially infinite amount
> of time :-)
> 
> IMHO : We need to get parts and prices so their feasibility can be studied
> before a design is done, or we need to go ahead with a design so us
> software people have something to play with.

I, like quite a few others on this list, am hassling a distributor about
the NEC r4k.  I am having just as much joy as everyone else - none... ;-(
My personal opinion is that the R4k + ARC is the best solution that we
have.  Unfortunately, we cannot do anything without that information.
Stay tuned; when the manufacturers are forthcomming with the data,
we will be forthcomming with a 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 owner-riscy@pyramid.com  Tue Aug 10 16:19:37 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA20185; Tue, 10 Aug 93 16:19:37 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15149; Tue, 10 Aug 93 13:18:26 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02475; Tue, 10 Aug 93 13:16:54 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02461; Tue, 10 Aug 93 13:16:51 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9308102016.AA02461@sword.eng.pyramid.com>
Subject: Re: Second level cache?
To: riscy@sword.eng.pyramid.com
Date: Tue, 10 Aug 93 13:16:51 PDT
In-Reply-To: <9308101415.AA14388@cbfsb.cb.att.com>; from "Stephen P Hill +1 708 979 0366" at Aug 10, 93 2:12 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

Stephen P Hill writes:

> My $0.02:
> 
> A second level cache would be really, really nice.  But it sounds 
> like it will be out of our price range.  Unless it proves 
> (somehow) to be cheep to have an unpopulated 2nd level cache 
> on the board, it is time to forget it.

From what I understand, the ARC chipset provides secondary cache
support.  So we could easily end up with unpopulated 2nd level
cache sockets for very small additional cost.

-- 
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 owner-riscy@pyramid.com  Tue Aug 10 21:24:09 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA03689; Tue, 10 Aug 93 21:24:09 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20948; Tue, 10 Aug 93 18:23:49 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA19142; Tue, 10 Aug 93 18:22:29 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA19135; Tue, 10 Aug 93 18:22:25 -0700
Received: from SunSite.unc.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20940; Tue, 10 Aug 93 18:23:29 -0700
Received: from localhost.oit.unc.edu by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA03615; Tue, 10 Aug 93 21:21:41 EDT
Message-Id: <9308110121.AA03615@SunSITE.unc.edu>
To: riscy@pyramid.com
Reply-To: johnsonm@sunsite.unc.edu
Subject: My thoughts.
Date: Tue, 10 Aug 93 21:21:41 -0400
From: ""Michael K. Johnson"" <johnsonm@SunSite.unc.edu>
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


I'm new to this channel, but I have scanned the last month and a half
of mail (it took hours), so I'm not as uninformed as I might appear to
be at first glance.

I originally heard about the riscy project earlier in the summer, and
thought, "Oh, that's nice.  How the heck are they going to get this
thing *built* for a reasonable price?  Who has the necessary tools?"
That question having been answered in probably the most satisfactory
way possible, I'd like to put forword my suggestions.  Take them with
a grain of salt, as I have done very little digital design...

I would prefer a mips4k cpu.  I think that it will be a better
long-term solution.  About 3 years ago, I bought a 386sx16.  It was
all I could afford, but I now know that I would have been better off
to wait a little longer and get a real 386.  I'm still using the sx16,
as linux makes it useable, but I'm looking for a step up that will not
feel completely obsolete in a year, and I'm willing to pay a little
extra for it, if necessary.  It's not clear to me that it would
actually cost more for a mips4k solution than a mips3k solution by the
time this board gets made.  I don't think we know enough about prices
yet to know.

I would also like to make a general comment about integrated
functionality.  This board has to be fairly flexible, since there are
not a really large number of us buying this.  It has to cover the
needs of several different kinds of users.  Therefore, where any
improvement that is significantly popular (i.e. IDE controller) and
costs little ( oh, say, < $5 ) to add to the current design, I think
that it ought to be added.  This strategy will probably make the whole
design cost $25-$50 (or more) more than it might if we tried to hold
down the costs of everything, but I think the returns for that
investment in terms of user base will be substantial and useful.

For instance, as it appears that a controller for 2 '550 uarts, 2.88
FDC, IDE, EPC Parallel, and a few other things that skip my mind at
the moment is available, and that that controller will cost less than
$10 more than a very minimal version of that part, and will provide
several very useful features that might not otherwise be included (EPC
Parallel, IDE, and '550 uarts in addition to some uart capacity and
some FDC capacity), it makes the most sense to use this part.  (Sorry,
I read the part number at about 3 am this morning, and don't recall it
offhand.)

Adding most of the parts people want when those parts are cheap is
probably the most economically viable option, not only for us hackers,
but also for Waldorf.  The more MB's they sell, the less they cost for
the features added, and the more hackers they have working on linux.

Consider this: By making the motherboard *too* bare-bones, the number
of people who want to purchase one could drop enough that the
price/piece could rise to just as much as if a few extra chips were
added.  Leveraging the $5000 setup cost across significantly more
purchasers could literally pay for itself, by making the cost/piece
drop by as much as the extra pieces on the board, and then we could
all be happy.

I know that the preceeding paragraph is speculation, but I can't say
anything more without taking a cumbersome and inaccurate vote.  I
tried to get a feeling for what people wanted to buy as I read the
archives, but since many people kept changing their minds (reasonably
so, as this is a design discussion), it is hard to tell just how many
more people would buy a well-populated board than a sparsely-populated
board, and what a general consensus on what well vs. sparse population
is.

In short, I want to buy one, but only if it is going to have all the
functionality that I want on the motherboard, and only if the
performance will be reasonable, not only now, but for at least a few
years to come.

I'm sorry to have rambled so long; I didn't mean to.  I hope that it
is worth it, and I'd like to help.  I am a linux kernel hacker, so I
think I can be of at least some help to this project.

michaelkjohnson
 
From owner-riscy@pyramid.com  Wed Aug 11 03:45:40 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA14983; Wed, 11 Aug 93 03:45:40 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA02922; Wed, 11 Aug 93 00:44:42 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA00315; Wed, 11 Aug 93 00:43:18 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA00308; Wed, 11 Aug 93 00:43:15 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA02906; Wed, 11 Aug 93 00:44:16 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id IV25649; Wed, 11 Aug 1993 09:39:54 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA04346; Wed, 11 Aug 93 09:35:46 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA13392; Wed, 11 Aug 93 09:36:14 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Wed, 11 Aug 93 09:35:20 +0200
Message-Id: <9308110735.AA22202@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA22202; Wed, 11 Aug 93 09:35:20 +0200
To: riscy@pyramid.com
Subject: Re:  Mips chips/performance
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> Here's a little performance table:
>	SpecINT Spec FP92 	Mhz	Cache
> Mips 3000 	27.3  	29.3    40      0+128k	    Dec 5240 numbers
> 486/66	32	16 	33/66	8k	    Intel announcement*
> 4000PC	35	34	50/100	8k+8k	    Sgi periodic chart
> 4200	  	55	30	40/80	8k+16k?	    Nec Broshure (no details)*
> 4000SC	60	58	50/100  8k+8k+1MB   SGI periodic chart
> Powerpc   	60+	80+	66	32k	    Motorolla ad *
> Pentium   	64.5	56.9	66	8k+8k	    Intel announcement * 
> R4400SC	97	88	75/150	16k+16k+1MB SGI periodic chart.
> 
> * = Spec numbers are probably obtained using an unmentioned 2nd level cache.
> 
> IMHO anything at the 4200 performance level or above looks great to me.
> 
> Question is how does the 4200 get it's speed?  It running 20% slower then the
> mips 4000PC, and supposedly has longer pipelines, and less fp support.
> 
> Is it possible it supports a second level cache? Or it it just above a very
> important 1st level cache threshold that gives it twice the perfomance of the
> 4200 for this benchmark? (I.e. in real world not faster then the 4000PC)
> 
> Or was the 4200 paired with some custom memory subsystem that implemented
> a seperate cache controller for the 2nd level cache? 

1. The specs for the R4200 are probably *estimates*. I'm sure they are
   a bit too high, but not much. The speed of the R4200 must be in
   between a R3000/40 and a R4000PC/50, simply because
   - it has 10 MHz clock less than the R4000PC/50 and
   - it has 64bit wide bus and logic, which makes it faster than a R3000/40.

2. The FP92 specs of the R4200 are so good because most floating point
   instructions have the same execution time as a real R4000 FPU has,
   only MUL and DIV are slower.

3. The pipeline is the same as a R3000 has. No reason to be slower
   than a R3000.

4. The R4200 has a larger primary cache (16k I + 8k D) than the R4000
   (8k I + 8k D). I mentioned already that the MIPS R4000 machine I
   am working on is sometimes 3 (!!) times slower than the R3000 machine
   with 32+32k cache we have here too.
   Although I don't believe that those 8k more speeds up the R4200
   by nearly factor 2 (in comparison to the R4000PC), I'm sure that
   the larger I cache results in a noticeable sustained speed up.

5. The R4200 ***DOES NOT*** support 2nd level cache. The Blockdiagram
   of ARCset shows no 2nd level cache, and there's ***NO SUPPORT*** at all.

The latter point should be one reason more to stop that 2nd level cache
discussion. If we are going to use the ARCset, we won't have 2nd level
cache. This is a fact unless someone finds an application around the R4200
or Orion *with* 2nd level cache support.
I'm not interested to spend any time to make an SC thing out of a PC CPU.
Of course, 2nd level cache would speed up the thing, but I thought that
we agreed to use an existing design to speed up development. That means
that we would use the ARCset design primarily *as is*, perhaps with
little changes in the I/O area. Integrating 2nd level cache in a design
which is not intended for that is probably no good idea.

Finally, I simply don't understand why this discussion came up.
I thought our goal was to design and produce a board with very good
price/performance relation. Although the price of the ARCset isn't
clear at the moment (which is not my or our fault, but NEC's) it seems
that this is what we are looking for. It offers more speed than
a R3081 solution probably for only few $s more.

If you all insist on a 2nd level cache design, we should forget
about the ARCset. That means in turn that we should forget about
having a design within the next 12 months. I'm not sure what then
happens to the group...

Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Wed Aug 11 05:54:22 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA18221; Wed, 11 Aug 93 05:54:22 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16010; Wed, 11 Aug 93 02:54:12 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15618; Wed, 11 Aug 93 02:52:40 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15611; Wed, 11 Aug 93 02:52:38 -0700
Received: from csunix.urc.kun.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15994; Wed, 11 Aug 93 02:53:34 -0700
Received: by csunix.urc.kun.nl (5.64/1.37)
	id AA01919; Wed, 11 Aug 93 11:45:44 +0200
From: ronald%csunix.urc.kun.nl@kunrc1.urc.kun.nl (Ronald Schalk)
Message-Id: <9308110945.AA01919@csunix.urc.kun.nl>
Subject: Re: Mips chips/performance
To: riscy@pyramid.com
Date: Wed, 11 Aug 1993 11:45:43 +0200 (CET)
In-Reply-To: <9308110735.AA22202@resi.waldorf-gmbh.de> from "Andreas Busse" at Aug 11, 93 09:35:20 am
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 3019      
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> 1. The specs for the R4200 are probably *estimates*. I'm sure they are
>    a bit too high, but not much. The speed of the R4200 must be in
>    between a R3000/40 and a R4000PC/50, simply because
>    - it has 10 MHz clock less than the R4000PC/50 and
>    - it has 64bit wide bus and logic, which makes it faster than a R3000/40.

I guess by now we can close this discussion by voting for R4200.
Why:   1 This project started with the R3K andthe R4.2K is much faster,
         and this HAS FP-support. (No more discussion like 3051<->3081)

       2 It would make software easier, no FP-emulation needed :-)

       3 There are more important issues that have been put to the background
         e.g. ethernet,scsi,video,serial I/O, parallel ports, sound (?)

> 
> 2. The FP92 specs of the R4200 are so good because most floating point
>    instructions have the same execution time as a real R4000 FPU has,
>    only MUL and DIV are slower.

Yes, especially considering that the R3051 was first seriously considered.

> 4. The R4200 has a larger primary cache (16k I + 8k D) than the R4000
>    (8k I + 8k D). I mentioned already that the MIPS R4000 machine I
>    am working on is sometimes 3 (!!) times slower than the R3000 machine
>    with 32+32k cache we have here too.
>    Although I don't believe that those 8k more speeds up the R4200
>    by nearly factor 2 (in comparison to the R4000PC), I'm sure that
>    the larger I cache results in a noticeable sustained speed up.

YES, I guess that's important too.

> 
> 5. The R4200 ***DOES NOT*** support 2nd level cache. The Blockdiagram
>    of ARCset shows no 2nd level cache, and there's ***NO SUPPORT*** at all.
> 
> The latter point should be one reason more to stop that 2nd level cache
> discussion. If we are going to use the ARCset, we won't have 2nd level
> cache. This is a fact unless someone finds an application around the R4200
> or Orion *with* 2nd level cache support.

Yes, it's important to drwaw the line somewhere, there's always something
bigger, better, faster, etc. But the main point is that the board has to
be affordabable. I guess the R4.2K gives us a viable alternative to the R3K.


Well closing off: 

Can we perform some kind of vote on the processor? Even though the 
pricing is not quite clear yet. I guess we can start talking again about 
the above mentioned issues??



Greetings Ronald

 ********************************************************************
 * 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 617997                    6525 GA Nijmegen       *
 * fax   :  +31 80 617979                    Nederland              *
 ********************************************************************
 
 
From owner-riscy@pyramid.com  Wed Aug 11 05:54:39 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA18248; Wed, 11 Aug 93 05:54:39 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16012; Wed, 11 Aug 93 02:54:14 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15629; Wed, 11 Aug 93 02:52:54 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15620; Wed, 11 Aug 93 02:52:51 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15998; Wed, 11 Aug 93 02:53:50 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id IZ02343; Wed, 11 Aug 1993 11:49:25 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA05120; Wed, 11 Aug 93 11:49:35 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA14282; Wed, 11 Aug 93 11:50:00 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Wed, 11 Aug 93 11:49:06 +0200
Message-Id: <9308110949.AA22367@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA22367; Wed, 11 Aug 93 11:49:06 +0200
To: riscy@pyramid.com
Subject: Re: Second level cache?
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


> What I understand is that the ARC chipset supports a secondary cache
> similar to the way it does for the 486.  It is not necessary to use
> the cache support signals from the R4k to have a secondary cache, although
> it may mean that this cache will take two cycles to access data where
> the R4000SC cache would take one.  This may not be great, but it is still
> better than the cycles required to get data from DRAM.

I really wonder from where the information comes that ARCset supports
any kind of 2nd level cache in its *true* sense.
I had a closer look the uPD31432 (Adress Path Controller) data sheet.
Quoted (Page 58,59):

5.1 Memory Interface Signal SUmmary

Signal Name		Description

MADR[10:0]		Multiplexed row and column adress lines.
			Shared with video interface.
/MRAS[3:0]		Early Memory Row Adress Strobe. [...]
/MEM_CAS[A:D]		Four identical copies of early memory
			Column Adress Strobes. [...]
/MWR_CMD		Memory Write Command.
MEM_DATA_OE		The uPD31431 memory data lines output enables.
MEM_DATA_LE		[...] Data latch enables [...]
/B_MASK			Time multiplexed byte mask lines. Used during
			memory and video partial write operations
			originating at Vr4000. Also used for I/O operations.
BM_PHASE		Signal to provide the phase information required
			to demultiplex the B_MASK line. [...]

5.2 uPD31432 Video Interface Signal Summary

Signal Name		Description

VIDEO_CMD[2:0]		Video command bus - Identifies the current
			command being sent to the video interface.
			[...]
VIDEO_ADR10		Video adress bit 10 is used with MADR[10:0] to
			provide a time multiplexed 20bit adress to the
			video interface.
VIDEO_RDY		Video ready is used by the video controller to
			inform the uPD31432 chip that is has completed
			the requested operation.

5.3 Memory System Transfers

Memory Operation	 Description

32 byte read		Vr4000 32 byte cache block fill. [...]
			I/O cache fill operation.
16 byte read		Vr4000 16 byte cache block fill. [...]
32 byte write		Vr4000 32 byte cache block flush. [...]
			I/O full cache line flush
16 byte write		Vr4000 16 byte cache block flush. [...]
Read modify write	Vr4000 write partial [...]
			I/O partial cache line flush
Memory Refresh		Refresh timing set in Refresh Rate Register

[end of qouted material]

Please note those I/O cache operations. These are operations are
I/O caching, what means that 32byte-blocks of data to be transfered
from or to I/O is cached in main memory.
This has ***nothing*** to do with 2nd level cache.
Next thing: The memory interface is a *true* DRAM interface.

Again, quoted from the data sheet. Here's the complete pinout:
[Page 147ff]

Signal Name		I/Otype	Description

R4000_DAL[32:00]	I/O	Vr4000 mux'ed data/adress lines
R4000_CMD[8:0]		I/O	Vr4000 system interface command bus.
R4000_CMDP		I/O	Single bit even parity for command bus.
/R4000_EXTRQST	        OUT	This is the external request line to
				the Vr4000 processor. [...]
/R4000_RELEASE		IN	Vr4000 release indicates that Vr4000
				has released the bus.
/R4000_RDY		OUT	Asserted by uPD31432 when ready to
				accept a R4000 command.
/R4000_VALID_IN		OUT	The uPD31432 asserts this signal when
				driving a command or data on the
				Vr4000 interface.
/R4000_VALID_OUT	IN	The Vr4000 asserts this signal when
				driving a command or data on the
				Vr4000 interface.
R4000_RCLOCK		IN	50 MHz receive clock
R4000_TCLOCK		IN	50 MHz transmit clock
/B_MASK[7:0]		OUT	Contains the byte mask information
				used during write partials [...]
BM_PHASE		OUT	Used to demultiplex /B_MASK[7:0]
CACHE_OP[2:0]		OUT	uPD31432 control bus used to control
				the I/O cache.
BLK_NUM[2:0]		OUT	I/O Cache block number selects one of
				eight cache blocks for current operation.
C_LINE			OUT	The cache line selects the 128 bit cache
				line in the cache block selected by
				BLK_NUM.
DMA_BANK_SEL		OUT	The DMA bank select is used to select
				a 64bit quantity from the selected
				cache line.
C_LTCH_EN		OUT	The cache latch enable is used as the
				latch enable for the selected cache data.
R4000_DP_OD[1:0]	OUT	The R4000_DAL output enable is used to
				turn off the the Vr4000 system bus drivers.
IO_OP[2:0]		OUT	These lines contain encoded control
				information from the uPD31432 to configure
				the uPD31431 chips during 386 bus operations.
/INTR1			IN	Vr4000 interrupt level 1
/INTR2			IN	Vr4000 interrupt level 2
/INTR3			IN	Vr4000 interrupt level 3
/INTR5			IN	Vr4000 interrupt level 5
/MCT_INTR		OUT	I/O DMA channel interrupt
/TIMER_INTR		OUT	Interval Timer Interrupt
TIMER_CLK		IN	Interval Timer base clock
BANK_SEL		OUT	This signal is used to select a 64 bit bank
				out of the 128bit memory line to drive on
				the R4000_DAL.
WMEM_STATE[2:0]		OUT	uPD31431 Vr4000 write buffer control bus.
PAR_ERR[1:0]		IN	Memory parity error lines from each of the
				two datapath chips.
/MRAS[3:0]		OUT	Main memory row adress strobe lines
/MWR_CMD		OUT	Main memory read/write control line.
/MEM_CAS[A:D]		OUT	Four copies of the same main memory
				DRAM column adress strobe.
MEM_DATA_OE		OUT	The uPD31431 memory data output enable
MEM_DATA_LE		OUT	Memory data latch enable controls the
				uPD31431 memory data latches. [...]
MADR[10:0]		OUT	Memory adress lines are multiplexed
				system memory DRAM row and column address
				lines.
VID_ADR10		OUT	Video address bit 10, used with MADR[10:0]
				to from complete video address bus.
VIDEO_CLK		OUT	25 MHz output signal used to drive the
			        video interface
VIDEO_CMD[2:0]		OUT	Video command is used to encode the video
				interface control bus.
VIDEO_RDY		IN	Video ready is used by the video system to
				respond to a uPD31432 video command.
CLK386			OUT	25 MHz (1/2 R4000_TCLOCK) clock used as
				the 386 bus clock.
H386_ADR[23:02]		I/O	I/O adress bus. It is also used to source
				a 3 bit encoded DMA acknowledge packet
				during local DMA operations [...]
/H386_ADS		I/O	I/O bus address strobe.
/H386_BE[3:0]		I/O	I/O bus byte enables.
/H386_M_IO		OUT	I/O bus control signal; used to select
				between 386 I/O bus I/O or memory space.
/H386_RDY		I/O	I/O bus slave ready signal. [...]
/H386_BUS_ERROR		OUT	I/O bus error signal. [...]
/H386_W_R		I/O	I/O bus read and write line. [...]
/H386D_C		OUT	I/O bus command line. Selects between
				normal data cycles and command cycles.
				Used only to perform a 386 compatible
				interrupt acknowledge signal.
ADR[1:0]		OUT	The signals provide the low two addresses
				used by local I/O devices.
DMA_REQ[7:0]		IN	These DMA request lines are used by the
				local DMA devices to signal the availability
				to accept or deliver data.
LDMA_TC			OUT	Local DMA terminal count is used to signal
				the acknowledged DMA operation has reached
				its terminal count. [...]
/DMA_ACK_CNT		OUT	This signal is used to control the assertion
				of the local device DMA line selected with
				H386_ADR[4:2]
/LOCALIO		OUT	Local I/O is used to control the assertion
				of the local device chip select selected
				with H386_ADR[23:20]
/SLAVE_RD		OUT	Local device read strobe.
/SLAVE_WR		OUT	Local device write strobe.
L_HLDA			OUT	LAN hold acknowledge. Used by the address
				chip to grant a requesting local bus master
				the remote bus.
L_HOLD			IN	The LAN; used by a remote bus master to
				request control of the remote bus.
EISA_BCLK		IN	EISA bus clock; received by the address chip
				to synchronize EISA control lines and
				operations.
E_HLDA			OUT	EISA hold acknowledge; used to grant the
				EISA chip set to take control of the remote
				I/O bus.
E_HOLD			IN	The EISA hold is used by the EISA chipsets
				to request control of the remote I/O bus.
HGT16M			IN	EISA address greater than 16MBytes. [...]
/REFRESH		IN	EISA refresh signal. [...]
/IO_BUS_REQ		OUT	I/O bus request. [...]
/EISA_CMD		IN	EISA command line. [...]
/EISA_EXRDY		OUT	EISA ready signal. [...]
/EISA_HLOCMEM		OUT	Driven when an EISA transfer into system
				memory is recognized. [...]
EIS_MBURST		IN	EISA master burst. [...]
EISA_START		IN	EISA start. [...]
/RESET			IN	Chip reset signal.
TEST			IN	Chip test signal.
/MACHCHK		OUT	Machine check interrupt is used to signal
				a catastrophic system error.

[end of qouted material]

Next, we have a look at the data path controller, uPD31431.
The data sheet tells us that this chip contains the I/O cache buffers
mentioned earlier.

qouted from the spec sheet, page 7:

3.4 I/O cache buffers
The I/O cache buffers provide the data storage for eight 128bit bidirectional
data buffers. The cache buffer has a 32bit read/write portto the I/O remote
bus and provide a 64bit bidirectional port to the memory data lines. [...]

[end of quoted material]


I hope it's clear now that this chip set *DOES NOT* support 2nd level
cache. What it does is providing a cache subsystem for I/O operations
which is a good idea, but has nothing to do with 2nd level cache.


Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Wed Aug 11 05:58:42 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA18332; Wed, 11 Aug 93 05:58:42 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16347; Wed, 11 Aug 93 02:58:34 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16122; Wed, 11 Aug 93 02:57:20 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16114; Wed, 11 Aug 93 02:57:18 -0700
Received: from bernina.ethz.ch 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16339; Wed, 11 Aug 93 02:58:23 -0700
Received: from neptune by bernina.ethz.ch with SMTP inbound id <25797-0@bernina.ethz.ch>; Wed, 11 Aug 1993 11:56:53 +0200
Message-Id: <9308110956.AA07164@neptune>
Received: from tau.inf.ethz.ch by neptune id AA07164; Wed, 11 Aug 93 11:56:48 +0200
To: riscy@pyramid.com
Subject: Re: Mips chips/performance 
In-Reply-To: Your message of "Wed, 11 Aug 93 11:45:43 +0100."
	     <9308110945.AA01919@csunix.urc.kun.nl> 
Date: Wed, 11 Aug 93 11:56:45 +0200
From: weingart@inf.ethz.ch
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

You write: 
Sie schreiben: 

> Can we perform some kind of vote on the processor? Even though the 
> pricing is not quite clear yet.

Sure.  I put in mine for either R4kPC, or R4200.

--Toby.
--------------------------------------------------------------
|Tobias Weingartner  |    PGP2.x Public Key available at     |
| +41'01'254'7205    |   'finger weingart@tau.inf.ethz.ch'   |
--------------------------------------------------------------
%SYSTEM-F-ANARCHISM, the operating system has been overthrown
 
From owner-riscy@pyramid.com  Wed Aug 11 06:04:34 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA18502; Wed, 11 Aug 93 06:04:34 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16618; Wed, 11 Aug 93 03:04:30 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16533; Wed, 11 Aug 93 03:03:15 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16526; Wed, 11 Aug 93 03:03:12 -0700
Received: from avignon.daimi.aau.dk 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16496; Wed, 11 Aug 93 03:04:12 -0700
Received: by avignon.daimi.aau.dk id AA03584
  (5.65c8/IDA-1.4.4 for riscy@pyramid.com); Wed, 11 Aug 1993 12:02:49 +0200
Date: Wed, 11 Aug 1993 12:02:49 +0200
From: Tommy Thorn <tthorn@daimi.aau.dk>
Message-Id: <199308111002.AA03584@avignon.daimi.aau.dk>
To: riscy@pyramid.com
Subject: Re: Second level cache?
References: <199308101106.AA17966@romeo.cs.Colorado.EDU>
	<9308101816.AA16534@sword.eng.pyramid.com>
Reply-To: Tommy.Thorn@daimi.aau.dk
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

Neil Russell writes:
 > What I understand is that the ARC chipset supports a secondary cache
 > similar to the way it does for the 486.  It is not necessary to use
 > the cache support signals from the R4k to have a secondary cache, although
 > it may mean that this cache will take two cycles to access data where
 > the R4000SC cache would take one.  This may not be great, but it is still
 > better than the cycles required to get data from DRAM.

Andreas Busse writes:
 > 5. The R4200 ***DOES NOT*** support 2nd level cache. The Blockdiagram
 >    of ARCset shows no 2nd level cache, and there's ***NO SUPPORT*** at all.

Huh? 

 > Finally, I simply don't understand why this discussion came up.
 > I thought our goal was to design and produce a board with very good
 > price/performance relation. Although the price of the ARCset isn't
 > clear at the moment (which is not my or our fault, but NEC's) it seems
 > that this is what we are looking for. It offers more speed than
 > a R3081 solution probably for only few $s more.

I suppose the discussion came becourse there is evidence that cache
size can influence performens (big news ;^) It is then a natural
question to ask "Can we have more? How much will it cost?" That the
ARCset didn't support it was/is non-obvious for the most of us. (Given
that most of us don't have any info on the ARCset besides what's
revealed in this forum.)

 > If you all insist on a 2nd level cache design, we should forget
 > about the ARCset. That means in turn that we should forget about
 > having a design within the next 12 months. I'm not sure what then
 > happens to the group...

Given this, we proberly don't wan't 2nd level cache, but don't flame
us for having the discussion.

/Tommy Thorn

 
From owner-riscy@pyramid.com  Wed Aug 11 06:24:18 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA18843; Wed, 11 Aug 93 06:24:18 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18222; Wed, 11 Aug 93 03:24:16 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA18034; Wed, 11 Aug 93 03:23:01 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA18027; Wed, 11 Aug 93 03:22:58 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18079; Wed, 11 Aug 93 03:23:58 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id IZ03856; Wed, 11 Aug 1993 12:19:20 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA05358; Wed, 11 Aug 93 12:20:08 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA14488; Wed, 11 Aug 93 12:20:34 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Wed, 11 Aug 93 12:19:45 +0200
Message-Id: <9308111019.AA22478@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA22478; Wed, 11 Aug 93 12:19:45 +0200
To: Tommy.Thorn@daimi.aau.dk
Subject: Re: Second level cache?
Cc: riscy@pyramid.com
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


> I suppose the discussion came becourse there is evidence that cache
> size can influence performens (big news ;^) It is then a natural
> question to ask "Can we have more? How much will it cost?" That the
> ARCset didn't support it was/is non-obvious for the most of us. (Given
> that most of us don't have any info on the ARCset besides what's
> revealed in this forum.)

Yes, of course. I always go this way myself :-) Without asking for
more you'll never get more. 

>  > If you all insist on a 2nd level cache design, we should forget
>  > about the ARCset. That means in turn that we should forget about
>  > having a design within the next 12 months. I'm not sure what then
>  > happens to the group...

> Given this, we proberly don't wan't 2nd level cache, but don't flame
> us for having the discussion.

Sorry, it wasn't meant as flame. I just wanted to stop a discussion
which is substantial in general, but isn't very useful for this
particular design.
I have posted the pin description of the NEC address path controller
so that everybody in the list gets at least the idea of what this
chip does.
If you like, I can also post the pin descr. of the data path
controller. Perhaps things are clearer then.

You all might have noticed that the NEC chip has built-in EISA
support. That does not mean that we have to use EISA as our bus
system. The chip also provides a nearly complete 386 bus, so it
shouldn't be a problem to add some ISA chips.

Andy


-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Wed Aug 11 06:41:03 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA19097; Wed, 11 Aug 93 06:41:03 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA19832; Wed, 11 Aug 93 03:41:06 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA19770; Wed, 11 Aug 93 03:39:52 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA19763; Wed, 11 Aug 93 03:39:50 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA19821; Wed, 11 Aug 93 03:40:54 -0700
Message-Id: <9308111040.AA19821@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA05430; Wed, 11 Aug 93 06:38:31 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: EISA?
To: riscy@pyramid.com
Date: Wed, 11 Aug 1993 06:38:31 -0500 (EDT)
In-Reply-To: <9308111019.AA22478@resi.waldorf-gmbh.de> from "Andreas Busse" at Aug 11, 93 12:19:45 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 939       
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> You all might have noticed that the NEC chip has built-in EISA
> support. That does not mean that we have to use EISA as our bus
> system. The chip also provides a nearly complete 386 bus, so it
> shouldn't be a problem to add some ISA chips.
> 
> Andy

EISA is a pretty good bus, something like 6 times the bandwidth of ISA.

Isn't it completely upward compatible from ISA (i.e. we can use it just
like a ISA bus).

I certainly wouldn't object to an EISA bus on the riscy board, and if
the ARC chips support it it's practically free.

I believe the ARC 100 manufacturing kits include plans for 3 EISA boards
Etherenet/serial, audio/mouse, and video.  Whether we we use any of those
would just be a price/performance decision.

-- 
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 owner-riscy@pyramid.com  Wed Aug 11 08:24:20 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA21339; Wed, 11 Aug 93 08:24:20 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA27571; Wed, 11 Aug 93 05:23:51 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA29836; Wed, 11 Aug 93 05:22:28 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA29829; Wed, 11 Aug 93 05:22:26 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA27563; Wed, 11 Aug 93 05:23:26 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id JA08990; Wed, 11 Aug 1993 14:19:03 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA06028; Wed, 11 Aug 93 14:16:09 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA15329; Wed, 11 Aug 93 14:16:32 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Wed, 11 Aug 93 14:15:43 +0200
Message-Id: <9308111215.AA22768@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA22768; Wed, 11 Aug 93 14:15:43 +0200
To: riscy@pyramid.com
Subject: Re:  EISA?
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


> EISA is a pretty good bus, something like 6 times the bandwidth of ISA.

Agreed.

> Isn't it completely upward compatible from ISA (i.e. we can use it just
> like a ISA bus).

No, it's completely incompatibel, from all 3 points of view:
- connector (different pin spacing)
- hardware  (different signals)
- software  (probably, don't really know)

> I certainly wouldn't object to an EISA bus on the riscy board, and if
> the ARC chips support it it's practically free.

No, it wouldn't be free. The ARCset just has a few lines intended
to be used to control the Intel EISA chipset.

Again, quoted from the data sheets (uPD31432, page 107):

6.7 BUS SLAVE INTERFACES

The uPD31432 supports two types of external bus masters: 386-type bus
masters, and an EISA expansion bus interface based on the Intel 82350
EISA chipset.

[end of quoted material]

That means that we can

a) use the EISA bus (with all the advantages and disadvantages it has)
b) skip the EISA bus and make our own ISA interface
c) have no expansion bus at all.

Ok, we already had a discussion wether we want an expansion bus
or not and we decided to go with ISA.
Assuming we have all the really necessary stuff on-board, I would
go with EISA too. It would make the design faster again and it
offers more speed.
On the other hand, not one of the ISA cards people have would
be useful.

> I believe the ARC 100 manufacturing kits include plans for 3 EISA boards
> Etherenet/serial, audio/mouse, and video.  Whether we we use any of those
> would just be a price/performance decision.

I have different block diagram using the ARCset chips:


+-------+               +----------+          +------+
|  Vr	| SysAD Bus     | ARCset   |    +---->| DRAM |
| 4000	|<------------->| D31431x2 |<---|     +------+
|	|               | D31432x1 |    |     +------+
+-------+               +----------+    +---->| VRAM |
                             |                +------+
                             |
        I/O Bus (i386 Bus)   |                
    +----------------------->|<--------------------------+
    |                        |                           |
    |                   +---------+                      |
    |                   |  Buffer |                      |
    |                   +---------+                      |
    |                        |                           |
+-------+   -----------------+----------------------  +------+
| EISA  |   |     |    |     |     |    |    |     |  | Ether|
|Control|   |     |    |     |     |    |    |     |  | net  |
+-------+   |     |    |     |     |    |    |     |  +------+
    |    +------+ | +------+ | +------+ | +------+ |
    |    |Mouse | | | PROM | | | NV-  | | |  RT  | |
    |    |& Kbd | | |      | | | RAM  | | |Clock | |
  EISA   +------+ | +------+ | +------+ | +------+ |
  Bus             |          |          |          |
               +------+   +------+   +------+   +------+
               |Sound |   |Floppy|   | SCSI |   |Par. &|
               | Ctrl |   | Ctrl |   | Ctrl |   |Serial|
               +------+   +------+   +------+   +------+


This blockdiagram contains really *all* of what is needed.
Don't ask me why ethernet is unbuffered, this is perhaps
just a "bug".
The block diagram shows also that the EISA bus is
an option, which probably can be replaced by an ISA bus.


Andy
 
From owner-riscy@pyramid.com  Wed Aug 11 08:32:02 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA21810; Wed, 11 Aug 93 08:32:02 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28222; Wed, 11 Aug 93 05:31:19 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA01024; Wed, 11 Aug 93 05:29:55 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA01017; Wed, 11 Aug 93 05:29:53 -0700
Received: from teal.csn.org 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28214; Wed, 11 Aug 93 05:30:58 -0700
Received: by teal.csn.org id AA05797
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Wed, 11 Aug 1993 06:28:30 -0600
From: Dan Fishman <dfishman@csn.org>
Message-Id: <199308111228.AA05797@teal.csn.org>
Subject: Re: EISA?
To: riscy@pyramid.com
Date: Wed, 11 Aug 1993 06:28:29 -0600 (MDT)
In-Reply-To: <9308111040.AA19821@gossip.pyramid.com> from "Bill Broadley" at Aug 11, 93 06:38:31 am
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1955      
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> 
> > You all might have noticed that the NEC chip has built-in EISA
> > support. That does not mean that we have to use EISA as our bus
> > system. The chip also provides a nearly complete 386 bus, so it
> > shouldn't be a problem to add some ISA chips.
> > 
> > Andy
> 
> EISA is a pretty good bus, something like 6 times the bandwidth of ISA.
> 
> Isn't it completely upward compatible from ISA (i.e. we can use it just
> like a ISA bus).

Yes, EISA is totally upward compatible with ISA.  It has a max clock rate the
same as ISA (8.xxx Mhz I believe) but it has 4byte transfer capability to
get to somewhere around 30+ MB/sec trasnfer rates.  This rate is good enough
for most high speed IO with the possible exceptions of video and future high
speed LANs (FDDI...).

> 
> I certainly wouldn't object to an EISA bus on the riscy board, and if
> the ARC chips support it it's practically free.
> 

I strongly agree.  If it has EISA then that implies ISA support for free and
EISA is good enough reason to go with it.

> I believe the ARC 100 manufacturing kits include plans for 3 EISA boards
> Etherenet/serial, audio/mouse, and video.  Whether we we use any of those
> would just be a price/performance decision.
> 
> -- 
> Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
> Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu

P.S.  What is the overall status of this effort.  I haven't followed closely
but I gather that it is still in discussion and planning stages apparently
discarding R3000 architecture for R4000.  I agree with the decision, but 
keep in mind that this market move incredibly fast these days.  Discuss, plan,
strategize for a few months and a whol new set of options become available.

Let's get this going!  Not to decide is to decide!  Power to the people...
(sorry I'm back now!  whew I was stuck in the sixties for a minute).

Dan Fishman (dfishman@csn.org) (W) (303) 469-6469 (Fax) (303) 465-4396
 
From owner-riscy@pyramid.com  Wed Aug 11 08:39:27 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA22110; Wed, 11 Aug 93 08:39:27 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28883; Wed, 11 Aug 93 05:39:14 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA01689; Wed, 11 Aug 93 05:37:58 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA01682; Wed, 11 Aug 93 05:37:56 -0700
Received: from teal.csn.org 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28871; Wed, 11 Aug 93 05:39:01 -0700
Received: by teal.csn.org id AA06181
  (5.65c/IDA-1.4.4 for riscy@pyramid.com); Wed, 11 Aug 1993 06:36:36 -0600
From: Dan Fishman <dfishman@csn.org>
Message-Id: <199308111236.AA06181@teal.csn.org>
Subject: Re: EISA?
To: riscy@pyramid.com
Date: Wed, 11 Aug 1993 06:36:36 -0600 (MDT)
In-Reply-To: <9308111215.AA22768@resi.waldorf-gmbh.de> from "Andreas Busse" at Aug 11, 93 02:15:43 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: 2407      
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> 
> 
> > EISA is a pretty good bus, something like 6 times the bandwidth of ISA.
> 
> Agreed.
> 
> > Isn't it completely upward compatible from ISA (i.e. we can use it just
> > like a ISA bus).
> 
> No, it's completely incompatibel, from all 3 points of view:
> - connector (different pin spacing)
> - hardware  (different signals)
> - software  (probably, don't really know)
> 

You need to tell that to my motherboard.  ISA boards run just fine in EISA
slot connectors (I know, I do it).  The pin spacing is different  in the sense
that there are double the number of pins and they are spaced vertically one above another.  I don't know all the tech details, but ISA boards simply make
contact with only their required signals and do not interfere with the added
bus signals for EISA control.

> > I certainly wouldn't object to an EISA bus on the riscy board, and if
> > the ARC chips support it it's practically free.
> 
> No, it wouldn't be free. The ARCset just has a few lines intended
> to be used to control the Intel EISA chipset.
> 
> Again, quoted from the data sheets (uPD31432, page 107):
> 
> 6.7 BUS SLAVE INTERFACES
> 
> The uPD31432 supports two types of external bus masters: 386-type bus
> masters, and an EISA expansion bus interface based on the Intel 82350
> EISA chipset.
> 
> [end of quoted material]
> 
> That means that we can
> 
> a) use the EISA bus (with all the advantages and disadvantages it has)
> b) skip the EISA bus and make our own ISA interface
> c) have no expansion bus at all.
> 
> Ok, we already had a discussion wether we want an expansion bus
> or not and we decided to go with ISA.
> Assuming we have all the really necessary stuff on-board, I would
> go with EISA too. It would make the design faster again and it
> offers more speed.
> On the other hand, not one of the ISA cards people have would
> be useful.

WRONG AGAIN.  ALL ISA boards should work just fine in an EISA bus system.
Again I'm doing just that (though obviously I have'nt used EVERY ISA board).
For example, in my EISA bus I currently have EISA AHA1742, ISA Hercules
Graphics Station video, and I had a DEC ISA Ethernet Card (I forget the 
model) and a SONY CDU535 8-bit ISA bus interface  CDROM drive.  They
all worked just fine and cooperated without a hitch.

> ....... Specific design proposal omitted
>
> Andy
> 

Dan Fishman (dfishman@csn.org) (W) (303) 469-6469 (Fax) (303) 465-4396
 
From owner-riscy@pyramid.com  Wed Aug 11 09:55:59 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA24859; Wed, 11 Aug 93 09:55:59 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA02967; Wed, 11 Aug 93 06:55:09 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08505; Wed, 11 Aug 93 06:53:35 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08498; Wed, 11 Aug 93 06:53:32 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA02947; Wed, 11 Aug 93 06:54:34 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id JA13761; Wed, 11 Aug 1993 15:50:11 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA06522; Wed, 11 Aug 93 15:40:10 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA15908; Wed, 11 Aug 93 15:40:32 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Wed, 11 Aug 93 15:39:41 +0200
Message-Id: <9308111339.AA23235@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA23235; Wed, 11 Aug 93 15:39:41 +0200
To: riscy@pyramid.com
Subject: Re: EISA?
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> > > Isn't it completely upward compatible from ISA (i.e. we can use it just
> > > like a ISA bus).
> > 
> > No, it's completely incompatibel, from all 3 points of view:
> > [...]

> You need to tell that to my motherboard.  ISA boards run just fine in EISA
> slot connectors (I know, I do it).  The pin spacing is different  in the sense
> that there are double the number of pins and they are spaced vertically one above another.  I don't know all the tech details, but ISA boards simply make
> contact with only their required signals and do not interfere with the added
> bus signals for EISA control.

> > Ok, we already had a discussion wether we want an expansion bus
> > or not and we decided to go with ISA.
> > [...]
> > On the other hand, not one of the ISA cards people have would
> > be useful.

> WRONG AGAIN.  ALL ISA boards should work just fine in an EISA bus system.
> Again I'm doing just that (though obviously I have'nt used EVERY ISA board).
> For example, in my EISA bus I currently have EISA AHA1742, ISA Hercules
> Graphics Station video, and I had a DEC ISA Ethernet Card (I forget the 
> model) and a SONY CDU535 8-bit ISA bus interface  CDROM drive.  They
> all worked just fine and cooperated without a hitch.

Oh, seems to happen to me that I'm totally mis-informed :-(
Well, if this is case (I *do* wonder), ok, here we go with the EISA bus.
There's no need for further discussion...

Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Wed Aug 11 10:28:14 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA26497; Wed, 11 Aug 93 10:28:14 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06491; Wed, 11 Aug 93 07:27:34 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA10120; Wed, 11 Aug 93 07:26:19 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA10113; Wed, 11 Aug 93 07:26:16 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06483; Wed, 11 Aug 93 07:27:22 -0700
Message-Id: <9308111427.AA06483@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA07721; Wed, 11 Aug 93 10:25:09 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: EISA/arc 100
To: riscy@pyramid.com (Mips 3000)
Date: Wed, 11 Aug 1993 10:25:09 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1186      
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

So anyone have an appoximate price of the Intel 82350 EISA chipset?

The Nec chipset can handle lots of buffered dma devices for on board
goodies, but I believe the implementation of the arc 100 motherboard
puts almost nothing on the motherboard.

If things were on the motherboard why would they offer video, etherenet,
serial, audio, mouse as seperate boards (actually designs for boards)?

I don't have a good handle on the design time/difficulty moving the
devices from the EISA expansion boards that come with the ARC 100 production
kit onto the motherboard.  But the EISA bus is fairly fast/robust
so I think it will be mainly a price and design effort consideration
to decide were things like etherenet, serial, audio etc end up.

We don't HAVE to implement any of the features, but then the cost
of the ISA or EISA purchased seperately devices can add up.  For me
personally the cost of the EISA adaptec scsi controller would make
the system price prohibitive to me.


-- 
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 owner-riscy@pyramid.com  Wed Aug 11 10:58:41 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA28218; Wed, 11 Aug 93 10:58:41 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09521; Wed, 11 Aug 93 07:57:38 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA13488; Wed, 11 Aug 93 07:56:10 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA13457; Wed, 11 Aug 93 07:56:08 -0700
Received: from fngate.fnal.gov 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09491; Wed, 11 Aug 93 07:57:12 -0700
Received: by fngate.fnal.gov (5.57/Ultrix3.0-C)
	id AA06942; Wed, 11 Aug 93 09:55:55 -0500
Received: by fncrdg.fnal.gov (920330.SGI/890607.SGI)
	(for ) id AA24333; Wed, 11 Aug 93 09:53:16 -0500
From: rohrer@fncrd8.fnal.gov (Keith Rohrer)
Message-Id: <9308111453.AA24333@fncrdg.fnal.gov>
Subject: Re: EISA/arc 100
To: riscy@pyramid.com
Date: Wed, 11 Aug 1993 09:53:16 -0600 (CDT)
In-Reply-To: <9308111427.AA06483@gossip.pyramid.com> from "Bill Broadley" at Aug 11, 93 10:25:09 am
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 318       
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> So anyone have an appoximate price of the Intel 82350 EISA chipset?
What about the SiS or other (non-intel but still full 32-bit dma,
unlike the hint nice thingie...)?  The big problem with EISA in the
early days was that only Intel made the chips, and charged the usual
Intel connector-conspiracy prices...

	Keith

 
From owner-riscy@pyramid.com  Wed Aug 11 11:45:04 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA00839; Wed, 11 Aug 93 11:45:04 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA14791; Wed, 11 Aug 93 08:44:11 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA19786; Wed, 11 Aug 93 08:42:30 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA19776; Wed, 11 Aug 93 08:42:28 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA14682; Wed, 11 Aug 93 08:43:27 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id JD20142; Wed, 11 Aug 1993 17:39:00 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA07477; Wed, 11 Aug 93 17:34:38 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA17092; Wed, 11 Aug 93 17:34:57 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Wed, 11 Aug 93 17:34:06 +0200
Message-Id: <9308111534.AA23583@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA23583; Wed, 11 Aug 93 17:34:06 +0200
To: riscy@pyramid.com
Subject: Re:  EISA/arc 100
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> So anyone have an appoximate price of the Intel 82350 EISA chipset?

No, please can someone figure this out ?

> The Nec chipset can handle lots of buffered dma devices for on board
> goodies, but I believe the implementation of the arc 100 motherboard
> puts almost nothing on the motherboard.

What's about that famous ARC 150 board ?

> If things were on the motherboard why would they offer video, etherenet,
> serial, audio, mouse as seperate boards (actually designs for boards)?

Right.

> I don't have a good handle on the design time/difficulty moving the
> devices from the EISA expansion boards that come with the ARC 100 production
> kit onto the motherboard.  But the EISA bus is fairly fast/robust
> so I think it will be mainly a price and design effort consideration
> to decide were things like etherenet, serial, audio etc end up.

> We don't HAVE to implement any of the features, but then the cost
> of the ISA or EISA purchased seperately devices can add up.  For me
> personally the cost of the EISA adaptec scsi controller would make
> the system price prohibitive to me.

Even in the case we can't use the ARC 100 board *as is* it would be
a good design to start from. I doubt that adding on-board SCSI, ethernet,
video and so on will be more complicated than adding this stuff to our
good old 3081/3730 solution. I'm sure it will be easier because most
chips have an intel bus interface, which is provided by the ARC chipset.
But all this are estimates and guesses. As long we (I) don't have
exact documentation about the ARC motherboards, it's hard to say what's
possible and what not.
If it's true that NEC offers complete designs for the I/O boards it
shouldn't be that complicated to integrate that stuff on-board, either
on a faked EISA bus (saving connectors and separate boards) or directly
connected to the Adress/Datapath chips.

I believe I *must* have a look into my MIPS box. The more we're talking
about those stuff the more I feel that this machine is *very* similar
to the ARC design... (it should, then it is called "ARCSystem").
When I remember right, it has SCSI on-board, but everything else on
separate cards, including video.
Ok, I'll be off-line for some minutes...

Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Wed Aug 11 12:11:20 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA02182; Wed, 11 Aug 93 12:11:20 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17045; Wed, 11 Aug 93 09:10:45 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA22882; Wed, 11 Aug 93 09:09:19 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA22874; Wed, 11 Aug 93 09:09:17 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17024; Wed, 11 Aug 93 09:10:21 -0700
Message-Id: <9308111610.AA17024@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA08927; Wed, 11 Aug 93 12:08:08 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Re: EISA/arc 100
To: riscy@pyramid.com
Date: Wed, 11 Aug 1993 12:08:08 -0500 (EDT)
In-Reply-To: <9308111534.AA23583@resi.waldorf-gmbh.de> from "Andreas Busse" at Aug 11, 93 05:34:06 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 629       
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> > The Nec chipset can handle lots of buffered dma devices for on board
> > goodies, but I believe the implementation of the arc 100 motherboard
> > puts almost nothing on the motherboard.
> 
> What's about that famous ARC 150 board ?

Well my impression was the ARC 100 board was for the 4000PC or 4400PC,
and the arc 150 was for the 4400SC and 4000SC.  So no difference
except a bigger cpu socket and cache chips.
 

-- 
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 owner-riscy@pyramid.com  Wed Aug 11 12:37:47 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA03878; Wed, 11 Aug 93 12:37:47 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20238; Wed, 11 Aug 93 09:36:52 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA27628; Wed, 11 Aug 93 09:35:37 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA27604; Wed, 11 Aug 93 09:35:34 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20168; Wed, 11 Aug 93 09:36:35 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id JE22518; Wed, 11 Aug 1993 18:32:11 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA07736; Wed, 11 Aug 93 18:28:48 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA00485; Wed, 11 Aug 93 18:29:06 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Wed, 11 Aug 93 18:28:18 +0200
Message-Id: <9308111628.AA00330@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA00330; Wed, 11 Aug 93 18:28:18 +0200
To: riscy@pyramid.com
Subject: MIPS Magnum 4000 parts
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


Here I am again, and my box is still working :-)

I had no time to totally disassemble my machine, 
therefore I couldn't identify some of the chips
located under the power supply.

I have found:

- a R4000PC/50 :-)

- handwritten stickers on the prom & and on the Dallas clock
  (one of the first Magnum 4000's ever produced...)

- four Intel chips for the EISA bus:
  2x 82358-33
  2x 82352

- National DP83932 Ethernet controller

- NCR 5390 SCSI controller

- 3 LSI Logic chips (couldn't read part names)
  1 large,
  2 smaller ones,
  perhaps (probably ?) similar to the NEC parts

- a NEC chip N82077 (don't know, FDC ?)

- two more chips, couldn't read part names,
  probably serial/parallel stuff.

Video is on a separate card (INMOS chip).

None of the stuff is on the EISA bus, at least none
of the four EISA slots is used.

The most interesting things are the LSI Logic parts.
I'll try to get informations from LSI, but our contact
isn't very good. Please, can somebody contact LSI and
ask them what support chips they offer for R4000 CPUs ?

Hope this helps a bit...

Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Thu Aug 12 02:11:02 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA13670; Thu, 12 Aug 93 02:11:02 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA11716; Wed, 11 Aug 93 23:10:21 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA01724; Wed, 11 Aug 93 23:08:54 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA01717; Wed, 11 Aug 93 23:08:51 -0700
Received: from zen.et.tudelft.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA11628; Wed, 11 Aug 93 23:09:52 -0700
Received: by zen.et.tudelft.nl (4.1/1.34JP)
          id AA20321; Thu, 12 Aug 93 08:07:27 +0200
Date: Thu, 12 Aug 93 08:07:27 +0200
From: wolff@zen.et.tudelft.nl (Rogier Wolff)
Message-Id: <9308120607.AA20321@zen.et.tudelft.nl>
To: riscy@pyramid.com
Subject: Re:  MIPS Magnum 4000 parts
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

	> 
	> No, it's completely incompatibel, from all 3 points of view:
	> - connector (different pin spacing)
	> - hardware  (different signals)
	> - software  (probably, don't really know)
	> 

	You need to tell that to my motherboard.  ISA boards run just fine in EISA
	slot connectors (I know, I do it).  The pin spacing is different  in the sense
	that there are double the number of pins and they are spaced 
	vertically one above another.  I don't know all the tech details,
	 but ISA boards simply make
	contact with only their required signals and do not interfere with the added
	bus signals for EISA control.

The trick is that EISA and ISA are completely different, howevery through
an engineering trick they managed to put the two conectors in the same place
in such a way that there wouldn't be a motherboard realestate penalty for
having both busses.

				Roger.
 
From owner-riscy@pyramid.com  Thu Aug 12 02:24:20 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA14012; Thu, 12 Aug 93 02:24:20 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15807; Wed, 11 Aug 93 23:24:26 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02735; Wed, 11 Aug 93 23:23:04 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02727; Wed, 11 Aug 93 23:23:02 -0700
Received: from zen.et.tudelft.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15488; Wed, 11 Aug 93 23:24:01 -0700
Received: by zen.et.tudelft.nl (4.1/1.34JP)
          id AA20348; Thu, 12 Aug 93 08:21:31 +0200
Date: Thu, 12 Aug 93 08:21:31 +0200
From: wolff@zen.et.tudelft.nl (Rogier Wolff)
Message-Id: <9308120621.AA20348@zen.et.tudelft.nl>
To: riscy@pyramid.com
Subject: Re:  MIPS Magnum 4000 parts
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> The trick is that EISA and ISA are completely different, however through
> an engineering trick they managed to put the two conectors in the same place
> in such a way that there wouldn't be a motherboard realestate penalty for
> having both busses.

On second though, I can't substantiate the "completely different" part.
I just don't know. However the fact that someone has an EISA system, which
will take ISA cards doesn't mean that the ARCset supports the ISA part on
the EISA connectors. 

Note that from what I've heard, a large portion of the price difference
between a simple 486 board and an EISA board comes from the EISA 
connectors (i.e. they are -=* very *=- expensive).

					Roger.

 
From owner-riscy@pyramid.com  Thu Aug 12 05:14:21 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA17719; Thu, 12 Aug 93 05:14:21 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA02411; Thu, 12 Aug 93 02:14:01 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA21164; Thu, 12 Aug 93 02:12:34 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA21157; Thu, 12 Aug 93 02:12:31 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA02396; Thu, 12 Aug 93 02:13:35 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id KC00405; Thu, 12 Aug 1993 11:09:11 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA12842; Thu, 12 Aug 93 11:01:34 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA02069; Thu, 12 Aug 93 11:01:33 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Thu, 12 Aug 93 11:00:43 +0200
Message-Id: <9308120900.AA01420@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA01420; Thu, 12 Aug 93 11:00:43 +0200
To: riscy@pyramid.com
Subject: R4000 chipsets
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


Hi Mipsers,

I called LSI Logic to get more informations about their chips
I've found in my Mips box.
Unfortunally, LSI Logic stopped R4000 support, but the support
guy was so kind to fax me some informations he found in the
Microprocessor Report 4/93.

Quoted:

ACER ANNOUNCES R4000 SYSTEM LOGIC CHIPS

Alternative Designs by MIPS, DeskStation Also in Development

[...]

Acer has announced a system-logic chip set for PC designers
using MIPS' R4000-family CPUs. The eight-chip set, called PICA,
is the first of several MIPS chips sets expected to be available
for the emerging Windows NT market. It provides a complete interface
to second-level cache, main memory, and I/O for an R4000PC or
R4400PC processor. It uses a new high-bandwith bus for video and
memory and connects standard PC buses for expandability. NEC will
probably second source for this chip set.
Two other forthcoming designs provide a "bridge" between the R4000
and standard 486 chip sets. DeskStation (Lenexa, Kansas) created
such a design for its ARCstation 1 system (see uPR 12/30/92, p. 4);
IDT has announced plans to market this implementation in 3Q93.
MIPS itself is developing a similar bridge that it expects Toshiba
and NEC to begin selling in 3Q93.

[...]

To reduce cost, PICA works with the "PC" version of the R4000, which
does not directly control a second-level cache. The CPU/Cache Controller
(CCC) provides the external cache support; this is cost-effective
because the R4000PC is much less expensive than the R4000SC which
includes a second-level cache controller.
The Acer design allows a second-level cache of either 128k or 256k.
(Minimal systems can omit this cache entirely.) A 128k cache typically
uses four 16kx16 parts, while the larger version requires 8 parts.

[...]

The PICA bus provides 200 MBytes per second of peak bandwith (burst mode)
to the memory and video subsystems. Three chips implement the interface
to main memory; the memory controller (MC) and two data buffers. The MC
provides address and control for up to 256 MB of DRAM.
[...]
The MC supports a memory data width of either 64 or 128 bits. With
relatively inexpensive 80-ns DRAMs, the memory can keep pace with the
25 MHz PICA bus; page mode hits return data in a 3-1-1-1 pattern.
>From the viewpoint of the 50MHz processor bus, this 32-byte read would
take 14 cycles.

[end of quoted material]


Here's the block diagram:


   +-------+       +----------+    +------+
   | R4000 |       | L2 cache |----|  L2  |
   |   PC  |       | 0...256k |    | Tags |
   +-------+       +----------+    +------+
       |                |             |
       +----------------|             |
            |           |             |
            |           |             |
        +-------+   +-----------+     |    
        | Data  |   |           |     |    +--------+  +---------+ 
        | FIFOs |   |   CCC     |-----+    | Data   |--| 8..256M |
        +-------+   |           |       +- | Buffers|  |  SIMMs  |
            |       +-----------+       |  + -------+  +---------+
            |             |             |                   |
            |             |             |  +--------+       |
 +-------+  |             | PICA bus    |  | Memory |       |
 | Video |---------------------------------| Ctrl.  |-------+
 | Card  |       |               |         +--------+
 +-------+       |               |
                 |               |
            +-----------+   +----------+
            |   DMA     |   |   I/O    |
            |   Ctrl.   |   |  Cache   |
            +-----------+   +----------+     +-----------+
 +--------+      |               |           |    ISA    |
 |        |----------------------------------|     or    |---- ISA/EISA Bus
 | local  |      |   Remote Bus  |           |    EISA   |
 |  I/O   |      |               |           | Interface |
 |        |      |               |           +-----------+
 +--------+  +----------+  +-------------+
             | Ethernet |  | Keyb./Mouse |
             +----------+  +-------------+


-------

That looks fine, at least for me.
Has someone a phone number of Acer ?


Cheers,
Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Thu Aug 12 05:41:29 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA18495; Thu, 12 Aug 93 05:41:29 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04589; Thu, 12 Aug 93 02:41:22 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA24041; Thu, 12 Aug 93 02:40:06 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA23967; Thu, 12 Aug 93 02:40:03 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04581; Thu, 12 Aug 93 02:40:58 -0700
Message-Id: <9308120940.AA04581@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA18353; Thu, 12 Aug 93 05:38:46 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Re: R4000 chipsets
To: riscy@pyramid.com
Date: Thu, 12 Aug 1993 05:38:45 -0500 (EDT)
In-Reply-To: <9308120900.AA01420@resi.waldorf-gmbh.de> from "Andreas Busse" at Aug 12, 93 11:00:43 am
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1380      
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> ACER ANNOUNCES R4000 SYSTEM LOGIC CHIPS

> It provides a complete interface to second-level cache, main memory, 
> and I/O for an R4000PC or R4400PC processor.

Sounds very good, getting the cheap cpu AND a 2nd level cache.

> IDT has announced plans to market this implementation in 3Q93.
> MIPS itself is developing a similar bridge that it expects Toshiba
> and NEC to begin selling in 3Q93.

Two bridge chips sets due out nowish good.

> The PICA bus provides 200 MBytes per second of peak bandwith (burst mode)
> to the memory and video subsystems. Three chips implement the interface
> to main memory; the memory controller (MC) and two data buffers. The MC
> provides address and control for up to 256 MB of DRAM.

PICA?? Is this proprietary? How wide?  Clock speed?

256 MB sounds good, I'm this means 32 bit wide simms which is good.

> That looks fine, at least for me.
> Has someone a phone number of Acer ?

    Acer Technologies Corp..... Tech Support .......... 408-922-0333

This sounds the best of all the choices, lets hope it's
affordable.

I see no limitation that would keep this system from being a 
formidable, well balanced, 486 killer system.


-- 
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 owner-riscy@pyramid.com  Thu Aug 12 09:50:48 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA22017; Thu, 12 Aug 93 09:50:48 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA08557; Thu, 12 Aug 93 03:33:59 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA28680; Thu, 12 Aug 93 03:32:33 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA28673; Thu, 12 Aug 93 03:32:30 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA08549; Thu, 12 Aug 93 03:33:33 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id KE04783; Thu, 12 Aug 1993 12:29:06 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA13296; Thu, 12 Aug 93 12:20:05 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA02295; Thu, 12 Aug 93 12:20:02 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Thu, 12 Aug 93 12:19:13 +0200
Message-Id: <9308121019.AA01509@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA01509; Thu, 12 Aug 93 12:19:13 +0200
To: riscy@pyramid.com
Subject: Acer chipset
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


I found a german representative of Acer computers and called
them. I can't believe it: They *really* know about the chip set,
and they will send me data sheets, prices and availability
informations.

I'll keep you informed.

Bye,
Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Thu Aug 12 23:18:08 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA29592; Thu, 12 Aug 93 23:18:08 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA13756; Thu, 12 Aug 93 20:17:45 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16850; Thu, 12 Aug 93 20:15:36 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16843; Thu, 12 Aug 93 20:15:33 -0700
Received: from genesis.mcs.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA13743; Thu, 12 Aug 93 20:16:40 -0700
Received: by genesis.mcs.com (/\==/\ Smail3.1.28.1 #28.12)
	id <m0oQpUM-000ZCpC@genesis.mcs.com>; Thu, 12 Aug 93 22:07 CDT
Received: by chinet (/\==/\ Smail3.1.28.1 #28.1{chinet})
	id <m0oQp6X-000D7FC@chinet>; Thu, 12 Aug 93 21:42 CDT
Received: by zarniwoop.chi.il.us (/\==/\ Smail3.1.24.1 #24.3)
	id <m0oQdZ5-00039LC@zarniwoop.chi.il.us>; Thu, 12 Aug 93 07:23 PDT
Message-Id: <m0oQdZ5-00039LC@zarniwoop.chi.il.us>
Date: Thu, 12 Aug 93 07:23 PDT
From: adyer@zarniwoop.chi.il.us (Andrew Dyer)
To: riscy@pyramid.com
Cc: riscy@pyramid.com
In-Reply-To: Rogier Wolff's message of Thu, 12 Aug 93 08:21:31 +0200 <9308120621.AA20348@zen.et.tudelft.nl>
Subject:  MIPS Magnum 4000 parts
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

   Date: Thu, 12 Aug 93 08:21:31 +0200
   From: wolff@zen.et.tudelft.nl (Rogier Wolff)
   Sender: owner-riscy@pyramid.com
   Reply-To: riscy@pyramid.com

   > The trick is that EISA and ISA are completely different, however through
   > an engineering trick they managed to put the two conectors in the same place
   > in such a way that there wouldn't be a motherboard realestate penalty for
   > having both busses.

   On second though, I can't substantiate the "completely different" part.
   I just don't know. However the fact that someone has an EISA system, which
   will take ISA cards doesn't mean that the ARCset supports the ISA part on
   the EISA connectors. 

EISA basically adds another 16 data bits to the 16 on the ISA bus
using a mechanical trick with the connector.  They also add some
specific EISA control signals.  The main "good thing" about EISA is
that all of the bus signals are sampled relative to a clock (no async
bus bullshit!).

The main trick is that since the ISA bus is asynchronous, all they had
to do was send out the correct signals at the correct clock periods,
and most ISA cards should work.  EISA supports ISA xfers to or from
other ISA boards, EISA boards, and/or platform resources.  EISA has
slot specific I/O addressing for EISA cards, and can arbitrate for the
bus using something other than the DMA controller :-o (although that
is supported).  EISA supports fast 8/16/32 bit cycles to memory, and
fast 8/16 bit cycles to I/O.  EISA has burst xfer modes.


--------------------------------------Ich mo"chte ein Eisba"r sein!
(1) adyer@zarniwoop.chi.il.us
(2) adyer@usr.com
 
From owner-riscy@pyramid.com  Mon Aug 16 17:04:44 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA20669; Mon, 16 Aug 93 17:04:44 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA07100; Mon, 16 Aug 93 14:04:31 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15942; Mon, 16 Aug 93 14:01:55 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15935; Mon, 16 Aug 93 14:01:53 -0700
Received: from [192.153.217.9] 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06892; Mon, 16 Aug 93 14:03:00 -0700
Received: from ska.ubitrex.mb.ca ([192.75.16.23]) by ubitrex.mb.ca (4.1/SMI-4.1)
	id AA07936; Mon, 16 Aug 93 16:00:40 CDT
Date: Mon, 16 Aug 93 16:00:39 CDT
From: tim@ubitrex.mb.ca (Tim Braun)
Message-Id: <9308162100.AA07936@ubitrex.mb.ca>
To: riscy@pyramid.com
Subject: r4k chipsets.
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


From "Electronic Design", 93/7/22, p102

Toshiba America Electronic Components, Irvine CA, USA
announces the "Tigershark" R4000 - i486 bus interface
chipset.  Signals on the R4000 (doesn't say whether PC
or SC versions) "Sysadd and Syscmd buses are converted 
to a 32-bit local bus that's compatible with the 486 bus."
Two 160 lead pqfp packages.  Includes a secondary cache
controller for 64-1024KByte of external cache.  Sounds
like it's intended for the r4kpc variant (low-cost is
part of their target).

  US$65, 1k qty per set.
  Contact Jean-Claude Toma, (714) 455-2000

ATI is selling their Mach32 PCI bus chips.  Of course, we don't 
have PCI on the option list yet.  It's the 68800ax.  But
a Mach32 would be a reasonable graphics controller.

  US$55, 1k qty
  Contact Henry Quan, (416) 756-0718

Giving up that r3081 stuff, and joining the r4kpc push...
________________________________________________________________
Tim Braun                          |
Ubitrex Corporation                | Voice: 204-942-2992 ext 228
1900-155 Carlton St                | FAX:   204-942-3001
Winnipeg, Manitoba, Canada R3C 3H8 | Email: tim@ubitrex.mb.ca
 
From owner-riscy@pyramid.com  Tue Aug 17 00:03:21 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA04978; Tue, 17 Aug 93 00:03:21 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA12635; Mon, 16 Aug 93 21:03:10 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA21738; Mon, 16 Aug 93 21:01:30 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA21731; Mon, 16 Aug 93 21:01:27 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA12545; Mon, 16 Aug 93 21:02:41 -0700
Message-Id: <9308170402.AA12545@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA04997; Mon, 16 Aug 93 23:59:59 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Re: r4k chipsets.
To: riscy@pyramid.com
Date: Mon, 16 Aug 1993 23:59:59 -0500 (EDT)
In-Reply-To: <9308162100.AA07936@ubitrex.mb.ca> from "Tim Braun" at Aug 16, 93 04:00:39 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1403      
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

>   US$65, 1k qty per set.
>   Contact Jean-Claude Toma, (714) 455-2000
> 
> ATI is selling their Mach32 PCI bus chips.  Of course, we don't 
> have PCI on the option list yet.  It's the 68800ax.  But
> a Mach32 would be a reasonable graphics controller.
> 
>   US$55, 1k qty
>   Contact Henry Quan, (416) 756-0718

Hmmm my network connecting us to the world has been unstable.

Any prices on the ARC 150 board posted?  Are we looking for an
accelerated chip (as opposed to going with whatever the arc 100/150 has)?

A 50 Mhz 32 bit wide bus to vram should prove very quick (i.e. 8 pixels
per transfer etc).  But of course an accelerated chip will greatly 
offload the cpu, bus bandwidth etc by doing bitblt's etc.

The S3 chips available for VESA ISA and EISA are the best supported of the 
accelerated chipsets under X11, and I'll attempt to get some prices on them 
if we are looking for a graphics cpu.  I already have pinouts/manuals, the 
S3 people are very friendly with giving out information.

From what I hear the S3-928 is a nicer cpu then the ATI MACH 32.

To summarize I'll try to get information on the S3 cpu's if we want
to explore the eaccelerated video options.  Opinions???

-- 
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 owner-riscy@pyramid.com  Thu Aug 19 11:34:23 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA20109; Thu, 19 Aug 93 11:34:23 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09362; Thu, 19 Aug 93 08:25:23 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA21207; Thu, 19 Aug 93 08:20:38 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA21198; Thu, 19 Aug 93 08:20:30 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09046; Thu, 19 Aug 93 08:21:36 -0700
Message-Id: <9308191521.AA09046@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA19330; Thu, 19 Aug 93 11:18:33 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: progress.
To: riscy@pyramid.com
Date: Thu, 19 Aug 1993 11:18:33 -0500 (EDT)
In-Reply-To: <9308162100.AA07936@ubitrex.mb.ca> from "Tim Braun" at Aug 16, 93 04:00:39 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 610       
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

Hmmm just a ping to the list... (having network problems here).

Seems like the 3 biggest choices are:
	ARC 100/150 motherboards from NEC
	ACER chipset 
	TIGERSHARK chipset 

How do the people who would actually design the motherboard feel about
buying a design (Arc) over a new design that we could distribute??

Or is this a useless question till we get more info/prices on the ARC 100
motherboard?
-- 
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 owner-riscy@pyramid.com  Thu Aug 19 13:21:07 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA26895; Thu, 19 Aug 93 13:21:07 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20385; Thu, 19 Aug 93 10:16:21 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA07397; Thu, 19 Aug 93 10:14:46 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA07380; Thu, 19 Aug 93 10:14:43 -0700
Received: from ubiserver.ubitrex.mb.ca 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20210; Thu, 19 Aug 93 10:15:41 -0700
Received: from ska.ubitrex.mb.ca ([192.75.16.23]) by ubitrex.mb.ca (4.1/SMI-4.1)
	id AA25998; Thu, 19 Aug 93 12:13:11 CDT
Date: Thu, 19 Aug 93 12:13:11 CDT
From: tim@ubitrex.mb.ca (Tim Braun)
Message-Id: <9308191713.AA25998@ubitrex.mb.ca>
To: riscy@pyramid.com
Subject: Re: progress.
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

Of course design is always more interesting, but these chips
are pretty fast/sophisticated/have many pins.  Mistakes are
costly.

Let's chase the ACER chipset.  I don't trust NEC.  Of course
the TigerShark chips are interesting, too.

On an unrelated note:  Fil-Mag (San Diego, USA) (617)-569-6577 sells
  SMT AUI transformers for ethernet transceivers.  Part 23Z391SM
________________________________________________________________
Tim Braun                          |
Ubitrex Corporation                | Voice: 204-942-2992 ext 228
1900-155 Carlton St                | FAX:   204-942-3001
Winnipeg, Manitoba, Canada R3C 3H8 | Email: tim@ubitrex.mb.ca
 
From owner-riscy@pyramid.com  Fri Aug 20 03:26:21 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA28422; Fri, 20 Aug 93 03:26:21 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09678; Fri, 20 Aug 93 00:24:37 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06407; Fri, 20 Aug 93 00:21:58 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06400; Fri, 20 Aug 93 00:21:55 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09165; Fri, 20 Aug 93 00:23:12 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id UQ07282; Fri, 20 Aug 1993 09:18:31 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA17841; Fri, 20 Aug 93 09:15:28 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA08809; Fri, 20 Aug 93 09:15:27 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Fri, 20 Aug 93 09:14:47 +0200
Message-Id: <9308200714.AA12593@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA12593; Fri, 20 Aug 93 09:14:47 +0200
To: riscy@pyramid.com
Subject: Re:  progress.
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


> Hmmm just a ping to the list... (having network problems here).
> 
> Seems like the 3 biggest choices are:
> 	ARC 100/150 motherboards from NEC
> 	ACER chipset 
> 	TIGERSHARK chipset 

I'm not sure yet, but there might be a fourth choice. My friend
at SGI told me that Mips Technology is selling a complete design
for few $$$. I'm waiting for details...

> How do the people who would actually design the motherboard feel about
> buying a design (Arc) over a new design that we could distribute??
>
> Or is this a useless question till we get more info/prices on the ARC 100
> motherboard?

I any case I would prefer to start from a complete design and modify
only those parts not satisfying us (if any).

BTW: Yesterday I got some price estimations:

ACER PICA chipset: us$195 in qtys >= 1000
NEC ARC chipset  : us$200 in qtys >= 10

Today I will call ACER Netherlands for more info. I've got also
a phone number of someone at Toshiba who should know more about
the Toshiba chip set.

I'll keep you informed (sorry, I was extremely busy this week).

Cheers,
Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Fri Aug 20 04:34:31 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA01804; Fri, 20 Aug 93 04:34:31 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA14457; Fri, 20 Aug 93 01:33:33 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA09129; Fri, 20 Aug 93 01:31:59 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA09105; Fri, 20 Aug 93 01:31:57 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA14443; Fri, 20 Aug 93 01:33:15 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id US10309; Fri, 20 Aug 1993 10:28:35 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA18529; Fri, 20 Aug 93 10:22:29 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA09312; Fri, 20 Aug 93 10:22:27 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Fri, 20 Aug 93 10:21:47 +0200
Message-Id: <9308200821.AA12741@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA12741; Fri, 20 Aug 93 10:21:47 +0200
To: riscy@pyramid.com
Subject: Mips Design
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


I talked to my friend at SGI again. He said that he expects
the Mips documentation next week and that he will send it to
me as soon he got it.

I have no idea what this design contains and looks like...

Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Fri Aug 20 05:35:33 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA03642; Fri, 20 Aug 93 05:35:33 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA19217; Fri, 20 Aug 93 02:33:26 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15883; Fri, 20 Aug 93 02:31:58 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15875; Fri, 20 Aug 93 02:31:56 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA19204; Fri, 20 Aug 93 02:33:12 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id UU13463; Fri, 20 Aug 1993 11:28:31 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA19213; Fri, 20 Aug 93 11:22:44 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA09685; Fri, 20 Aug 93 11:22:41 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Fri, 20 Aug 93 11:22:02 +0200
Message-Id: <9308200922.AA12825@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA12825; Fri, 20 Aug 93 11:22:02 +0200
To: riscy@pyramid.com
Subject: Toshiba Chip Sets
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


I've got some *very* interesting news from Toshiba:

1. The TigerShark design is currently properiatary of SGI.
   Toshiba will produce the chip set and it *may* become
   available end of the year.

2. They are working on a new design called MERCURY which
   will both support a standard R4000 and the Orion, produced
   by IDT *and* Toshiba. Mercury will be available in both
   3.3 and 5.0 Volt technologies.

3. Toshiba HAS the ARC 100 and 150 design and *is* selling
   chips. 

The guy at Toshiba said that NEC simply doesn't produce
anything and therefor can't sell anything. I'm not sure if
this is true, but we shouldn't care about as long as Toshiba
can sell us what we need.

He also said that Toshiba makes the chips for the Mips design
I mentioned. I know that SGI uses Toshiba chips for their
Indigo and Indy boxes. 

I will receive detailed information next week.


Cheers,
Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Fri Aug 20 07:15:33 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA05679; Fri, 20 Aug 93 07:15:33 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA26585; Fri, 20 Aug 93 04:04:38 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA21764; Fri, 20 Aug 93 04:02:07 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA21757; Fri, 20 Aug 93 04:02:05 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA26294; Fri, 20 Aug 93 04:03:22 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id UW16761; Fri, 20 Aug 1993 12:58:42 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA20043; Fri, 20 Aug 93 12:50:54 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA10194; Fri, 20 Aug 93 12:50:49 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Fri, 20 Aug 93 12:50:05 +0200
Message-Id: <9308201050.AA13065@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA13065; Fri, 20 Aug 93 12:50:05 +0200
To: riscy@pyramid.com
Subject: comp.sys.mips #56 - Re: R4200 pin-compatible with 486DX ?? 
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

I found this article in comp.sys.mips:


In article <js9e6r2@zuni.esd.sgi.com>, olson@anchor.esd.sgi.com (Dave Olson) writes:
|> In <24q0idINNnk9@ymir.cs.umass.edu> doyle@gaia (Jim Doyle) writes:
|> | Windows Sources, Sept 1993 vol 1 issue 8, p25
|> | 
|> | "By the end of this year, MIPS plans to introduce a small footprint
|> | version of its new low power R4200 RISC CPU that will be 
|> | completely pin compatible with the existing Intel 486DX chips. Using
|> | a special MIPS replacement BIOS [...]
|> | 
|> | [...] and by being pin compatible with the 486, the new chip will
|> | allow system board manufacturers to retrofir existing designed with
|> | little or no component modification"   
|> | -----------
|> | 
|> | I was under the impression that NEC was fabricating the 4200 and that 
|> | it would require additional glue logic (an ASIC that MIPS also developed)
|> | to make it work with an ISA or EISA based PC motherboard ??
|> 
|> Windows Sources is blowing smoke.  The R4200 is compatible with the
|> R4000 PC (if I remember everything right).  That's a long way from the
|> Intel chips.
|> 
|> I hope their other news is more reliable.
|> --
|> 
|> The most beautiful things in the world are              |   Dave Olson
|> those from which all excess weight has been             |   Silicon Graphics
|> removed.  -Henry Ford                                   |   olson@sgi.com


What do we think about that ?

Andy
 
From owner-riscy@pyramid.com  Fri Aug 20 08:58:50 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA10092; Fri, 20 Aug 93 08:58:50 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05757; Fri, 20 Aug 93 05:55:18 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA26350; Fri, 20 Aug 93 05:53:40 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA26343; Fri, 20 Aug 93 05:53:37 -0700
Received: from cs.huji.ac.il 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA05689; Fri, 20 Aug 93 05:54:54 -0700
Received: from picton.cs.huji.ac.il by cs.huji.ac.il with SMTP id AA27375
  (5.65b/HUJI 4.114); Fri, 20 Aug 93 15:52:51 +0300
Received: from localhost by picton.cs.huji.ac.il with SMTP id AA01595
  (5.65c/HUJI 4.121 for <riscy@pyramid.com>); Fri, 20 Aug 1993 15:52:10 +0300
Message-Id: <199308201252.AA01595@picton.cs.huji.ac.il>
To: riscy@pyramid.com
Subject: Re: comp.sys.mips #56 - Re: R4200 pin-compatible with 486DX ?? 
In-Reply-To: Your message of Fri, 20 Aug 93 12:50:05 +0200 .
             <9308201050.AA13065@resi.waldorf-gmbh.de> 
From: Amos Shapira <amoss@cs.huji.ac.il>
Date: Fri, 20 Aug 1993 15:52:08 +0300
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

In message <9308201050.AA13065@resi.waldorf-gmbh.de> you write:
|In article <js9e6r2@zuni.esd.sgi.com>, olson@anchor.esd.sgi.com (Dave Olson) w
|rites:
||> In <24q0idINNnk9@ymir.cs.umass.edu> doyle@gaia (Jim Doyle) writes:
||> | Windows Sources, Sept 1993 vol 1 issue 8, p25
||> | 
||> | "By the end of this year, MIPS plans to introduce a small footprint
||> | version of its new low power R4200 RISC CPU that will be 
||> | completely pin compatible with the existing Intel 486DX chips. Using
||> | a special MIPS replacement BIOS [...]
||> | 
||> | [...] and by being pin compatible with the 486, the new chip will
||> | allow system board manufacturers to retrofir existing designed with
||> | little or no component modification"   
||> | -----------
||> | 
||> | I was under the impression that NEC was fabricating the 4200 and that 
||> | it would require additional glue logic (an ASIC that MIPS also developed)
||> | to make it work with an ISA or EISA based PC motherboard ??
||> 
||> Windows Sources is blowing smoke.  The R4200 is compatible with the
||> R4000 PC (if I remember everything right).  That's a long way from the
||> Intel chips.
||> 
||> I hope their other news is more reliable.
||> --
||> 
||> The most beautiful things in the world are              |   Dave Olson
||> those from which all excess weight has been             |   Silicon Graphic
|s
||> removed.  -Henry Ford                                   |   olson@sgi.com
|
|
|What do we think about that ?
|
|Andy

On one hand it sounds like a champ - you take a conventional 486DX board,
change the CPU and viola- you have a risc machine.

But I see two disadvantages to this (as far as my lack of knowledge in
hardware permits me):

1. If you know Dave Olson you should know to listen to him when he doubts about
   the possibility of such a beast (to those who don't know the man - he is the
   guru on the comp.sys.sgi.* news groups and so I heard from someone who
   worked with him,  but I'm not sure how much strong is his h/w side).

2. Maybe more important - you are still stuck with an ISA/EISA bus (right?),
   which I understand is quite limited.  Although the argument of using
   existing hardware from your current boxes is very valid, I would preffer
   to use another bus (dunno what the options are) and hang an EISA on it if
   that's possible.


Cheers,


--Amos

--Amos Shapira (Jumper Extraordinaire) |  "It is true that power corrupts,
C.S. System Group, Hebrew University,  |   but absolute power is better!"
Jerusalem 91904, ISRAEL                |
amoss@cs.huji.ac.il                    |          -- the Demon to his son
 
From owner-riscy@pyramid.com  Fri Aug 20 09:26:01 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA11507; Fri, 20 Aug 93 09:26:01 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA07689; Fri, 20 Aug 93 06:23:36 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA28529; Fri, 20 Aug 93 06:22:01 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA28519; Fri, 20 Aug 93 06:21:59 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA07651; Fri, 20 Aug 93 06:23:15 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id VA25023; Fri, 20 Aug 1993 15:18:31 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA21345; Fri, 20 Aug 93 15:18:29 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA12339; Fri, 20 Aug 93 15:18:22 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Fri, 20 Aug 93 15:17:43 +0200
Message-Id: <9308201317.AA13278@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA13278; Fri, 20 Aug 93 15:17:43 +0200
To: riscy@pyramid.com
Subject: Re: comp.sys.mips #56 - Re: R4200 pin-compatible with 486DX ??
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> [article deleted]
> 
> On one hand it sounds like a champ - you take a conventional 486DX board,
> change the CPU and viola- you have a risc machine.

I think it's just vaporware :-)

> But I see two disadvantages to this (as far as my lack of knowledge in
> hardware permits me):
> 
> 1. If you know Dave Olson you should know to listen to him when he doubts about
>    the possibility of such a beast (to those who don't know the man - he is the
>    guru on the comp.sys.sgi.* news groups and so I heard from someone who
>    worked with him,  but I'm not sure how much strong is his h/w side).

I don't know him...

> 2. Maybe more important - you are still stuck with an ISA/EISA bus (right?),
>    which I understand is quite limited.  Although the argument of using
>    existing hardware from your current boxes is very valid, I would preffer
>    to use another bus (dunno what the options are) and hang an EISA on it if
>    that's possible.

Hmm. You are new to the group, aren't you ?
Well, I believe we are also stuck with the ISA/EISA bus for two
reasons:

1. Most people in this group *want* an ISA bus, because
   cards are cheap and easy to find.
2. It looks like that we are going to use an existing design,
   either from NEC, Toshiba, Acer, Mips or whatever.
   They all come with the EISA bus which is part of the
   ARC specification, the only *real* product of the ACE group.


Cheers,
Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Mon Aug 23 04:02:04 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA07365; Mon, 23 Aug 93 04:02:04 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA25939; Mon, 23 Aug 93 01:00:47 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02484; Mon, 23 Aug 93 00:59:39 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02477; Mon, 23 Aug 93 00:59:36 -0700
Received: from [131.174.81.33] 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA25901; Mon, 23 Aug 93 00:59:27 -0700
Received: by csunix.urc.kun.nl (5.64/1.37)
	id AA22451; Mon, 23 Aug 93 09:57:47 +0200
From: ronald%csunix.urc.kun.nl@kunrc1.urc.kun.nl (Ronald Schalk)
Message-Id: <9308230757.AA22451@csunix.urc.kun.nl>
Subject: Re: progress.
To: riscy@pyramid.com
Date: Mon, 23 Aug 1993 09:57:46 +0200 (CET)
In-Reply-To: <9308200714.AA12593@resi.waldorf-gmbh.de> from "Andreas Busse" at Aug 20, 93 09:14:47 am
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1069      
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> ACER PICA chipset: us$195 in qtys >= 1000
> NEC ARC chipset  : us$200 in qtys >= 10
> 
> Today I will call ACER Netherlands for more info. I've got also
> a phone number of someone at Toshiba who should know more about
> the Toshiba chip set.

Hi, a girl who lives in my dorm works at ACER The Netherlands, I'll ask her
if she can get any info. I'm afraid not, what I heard was that they only
assemble things overthere.

Grtx, Ronald

 ********************************************************************
 * 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 617997                    6525 GA Nijmegen       *
 * fax   :  +31 80 617979                    Nederland              *
 ********************************************************************
 
 
From owner-riscy@pyramid.com  Mon Aug 23 06:37:32 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA10547; Mon, 23 Aug 93 06:37:32 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA07457; Mon, 23 Aug 93 03:32:49 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA12074; Mon, 23 Aug 93 03:32:31 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA12067; Mon, 23 Aug 93 03:32:29 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA07387; Mon, 23 Aug 93 03:32:26 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id YU11427; Mon, 23 Aug 1993 12:28:59 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA24843; Mon, 23 Aug 93 12:20:52 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA26134; Mon, 23 Aug 93 12:20:48 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Mon, 23 Aug 93 12:20:08 +0200
Message-Id: <9308231020.AA17241@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA17241; Mon, 23 Aug 93 12:20:08 +0200
To: riscy@pyramid.com
Subject: Re: progress.
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


> Hi, a girl who lives in my dorm works at ACER The Netherlands, I'll ask her
> if she can get any info. I'm afraid not, what I heard was that they only
> assemble things overthere.
> 
> Grtx, Ronald


Yes, that's a good idea ! (And I've promised too much, I hadn't
enough time to call them).

Please tell her that Mr. Kakavos at ACER Germany said
that I should contact Mr. Gerey Wang (or the like) at
ACER Netherlands. His phone no. is 40 501 234.

Would be good if they could send me informations...

Cheers,
Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Mon Aug 23 13:17:37 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA29820; Mon, 23 Aug 93 13:17:37 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09332; Mon, 23 Aug 93 10:13:44 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA04779; Mon, 23 Aug 93 10:13:21 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA04771; Mon, 23 Aug 93 10:13:15 -0700
Received: from vuse.vuse.vanderbilt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09312; Mon, 23 Aug 93 10:13:15 -0700
Received: from space0 (space0.vuse.vanderbilt.edu) by vuse.vanderbilt.edu (4.1/SMI-4.1/VUSE-1.10)
	id AA07891; Mon, 23 Aug 93 12:11:52 CDT
Message-Id: <9308231711.AA07891@vuse.vanderbilt.edu>
Received: by space0
	(16.6/16.2) id AA02904; Mon, 23 Aug 93 12:11:50 -0500
Date: Mon, 23 Aug 93 12:11:50 -0500
From: Murli Dharan Satagopan[E230 <murli@vuse.vanderbilt.edu>
To: riscy@pyramid.com
Subject: RISC PC
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


 I saw your correspondence at sunsite.unc.edu about RISC PC. I am currently a
Master's student in Vanderbilt university. Prior to this I used to work for
HCL-Hewlett Packard in India and was a key member of the design team of a 
minicomputer based on the MIPS R3000. I did the design of the CPU, cache,
memory interface section. This was all high speed design ( 33 Mhz clock).
Also I did the layout for the CPU - cache section ( CPu, 2Xclocks, FPA,
writebuffers, cache). I was involved with the product throughout the 
design life cycle - from conception to reliability qualification. Therefore,
I became  interested in your design and maybe I can contribute something. 

My address and phone number are as follows

	Murli Dharan Satagopan
	2000, 24th Avenue South
	Nashville TN 37212

        phone (615) 297-8763

 email : murli@vuse.vanderbilt.edu

Looking forward for some interesting work/discussions.

Murli Dharan Satagopan
  
 
From owner-riscy@pyramid.com  Wed Aug 25 07:05:23 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA18550; Wed, 25 Aug 93 07:05:23 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA14130; Wed, 25 Aug 93 04:03:57 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08680; Wed, 25 Aug 93 04:02:55 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08671; Wed, 25 Aug 93 04:02:52 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA14122; Wed, 25 Aug 93 04:02:45 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id dJ23902; Wed, 25 Aug 1993 12:59:13 +0200
Received: from resi
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA14510; Wed, 25 Aug 93 12:59:02 +0200
From: Andreas Busse <andy@waldorf-gmbh.de>
Date: Wed, 25 Aug 93 12:58:20 +0200
Message-Id: <9308251058.AA22179@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for scotty.waldorf-gmbh.de
	id AA22179; Wed, 25 Aug 93 12:58:20 +0200
To: riscy@pyramid.com
Subject: NEC ARCset
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


Hi there !

I've got some news from NEC Europe.
They told me that both ARCsets will be available
in October this year.
Price will be between us$5000 and us$6000.
Both sets will support R4000PC and Orion CPUs.

NEC USA is still testing the designs, which
might be the reason for why it was so hard
to get a statement about the availability.

Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Wed Aug 25 08:35:38 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA21855; Wed, 25 Aug 93 08:35:38 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21351; Wed, 25 Aug 93 05:33:56 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16635; Wed, 25 Aug 93 05:33:35 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16620; Wed, 25 Aug 93 05:33:33 -0700
Received: from bernina.ethz.ch 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21343; Wed, 25 Aug 93 05:33:34 -0700
Received: from neptune by bernina.ethz.ch with SMTP inbound id <7256-0@bernina.ethz.ch>; Wed, 25 Aug 1993 13:06:39 +0200
Message-Id: <9308251106.AA08688@neptune>
Received: from tau.inf.ethz.ch by neptune id AA08688; Wed, 25 Aug 93 13:06:35 +0200
To: riscy@pyramid.com
Subject: Re: NEC ARCset 
In-Reply-To: Your message of "Wed, 25 Aug 93 12:58:20 +0100."
	     <9308251058.AA22179@resi.waldorf-gmbh.de> 
Date: Wed, 25 Aug 93 13:06:30 +0200
From: weingart@inf.ethz.ch
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

You write: 
Sie schreiben: 

> Price will be between us$5000 and us$6000.
> Both sets will support R4000PC and Orion CPUs.

Ok, is that us$5000/piece, or us$5000/10 pieces?

--Toby.
--------------------------------------------------------------
|Tobias Weingartner  |    PGP2.x Public Key available at     |
| +41'01'254'7205    |   'finger weingart@tau.inf.ethz.ch'   |
--------------------------------------------------------------
%SYSTEM-F-ANARCHISM, the operating system has been overthrown
 
From owner-riscy@pyramid.com  Wed Aug 25 09:04:46 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA23012; Wed, 25 Aug 93 09:04:46 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23330; Wed, 25 Aug 93 06:03:12 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA19997; Wed, 25 Aug 93 06:02:54 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA19978; Wed, 25 Aug 93 06:02:51 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23311; Wed, 25 Aug 93 06:02:41 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id dN28883; Wed, 25 Aug 1993 14:58:52 +0200
Received: from resi
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA15752; Wed, 25 Aug 93 14:53:20 +0200
From: Andreas Busse <andy@waldorf-gmbh.de>
Date: Wed, 25 Aug 93 14:52:39 +0200
Message-Id: <9308251252.AA22459@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for scotty.waldorf-gmbh.de
	id AA22459; Wed, 25 Aug 93 14:52:39 +0200
To: riscy@pyramid.com
Subject: Re: NEC ARCset
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


> > Price will be between us$5000 and us$6000.
> > Both sets will support R4000PC and Orion CPUs.
> 
> Ok, is that us$5000/piece, or us$5000/10 pieces?
>

No, no. The price is for the design, not for the board !
It was just an information about progress, and Waldorf
will buy this (or another) design...

As long I don't have a partlist (and I won't have
until the design is finished by NEC) and can't say
how much the board costs, ok ?

Cheers,
Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Wed Aug 25 10:17:20 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA26081; Wed, 25 Aug 93 10:17:20 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28642; Wed, 25 Aug 93 07:15:41 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA24414; Wed, 25 Aug 93 07:15:21 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA24407; Wed, 25 Aug 93 07:15:19 -0700
Received: from bernina.ethz.ch 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28626; Wed, 25 Aug 93 07:15:22 -0700
Received: from neptune by bernina.ethz.ch with SMTP inbound id <14711-0@bernina.ethz.ch>; Wed, 25 Aug 1993 16:14:59 +0200
Message-Id: <9308251414.AA11106@neptune>
Received: from tau.inf.ethz.ch by neptune id AA11106; Wed, 25 Aug 93 16:14:55 +0200
To: riscy@pyramid.com
Subject: Re: NEC ARCset 
In-Reply-To: Your message of "Wed, 25 Aug 93 14:52:39 +0100."
	     <9308251252.AA22459@resi.waldorf-gmbh.de> 
Date: Wed, 25 Aug 93 16:14:53 +0200
From: weingart@inf.ethz.ch
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

You write: 
Sie schreiben: 

> > > Price will be between us$5000 and us$6000.
> > > Both sets will support R4000PC and Orion CPUs.
> > 
> > Ok, is that us$5000/piece, or us$5000/10 pieces?
> >
> 
> No, no. The price is for the design, not for the board !
> It was just an information about progress, and Waldorf
> will buy this (or another) design...

Ah, missunderstanding...


> As long I don't have a partlist (and I won't have
> until the design is finished by NEC) and can't say
> how much the board costs, ok ?

Ok.  Sorry 'bout that, but I think I went for a little trip
there, mentally that is... ;-)

--Toby.
--------------------------------------------------------------
|Tobias Weingartner  |    PGP2.x Public Key available at     |
| +41'01'254'7205    |   'finger weingart@tau.inf.ethz.ch'   |
--------------------------------------------------------------
%SYSTEM-F-ANARCHISM, the operating system has been overthrown
 
