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

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

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

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

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

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

	J

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


--------

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

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

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

I guess this brings up an important issue : 

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

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

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


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

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

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

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

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

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

Serial : 

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

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

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

Ethernet : 

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

My old LANCE equipped HP's show similar throughput.

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

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

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

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

SCSI :

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

Video :

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

--------


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SGI is big-endian.

Tor

 
From caret@pyramid.com Wed Jun 23 23:34:55 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA08687; Wed, 23 Jun 93 23:34:47 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA03985; Wed, 23 Jun 93 14:34:45 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02392; Wed, 23 Jun 93 14:34:42 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306232134.AA02392@sword.eng.pyramid.com>
Subject: Re: MIPS R3000 - 2nd update
To: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge)
Date: Wed, 23 Jun 93 14:34:41 PDT
Cc: riscy@pyramid.com
In-Reply-To: <199306230917.AA05932@sour.sw.oz.au>; from "Jeremy Fitzhardinge" at Jun 23, 93 7:17 pm
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

> Neil Russell says on comp.os.linux:
> > *  I have decided that the IDT 79R3051E (the non FPU version) should be
> >    used.  Since getting good pricing is hard unless quantities are high
> >    I wish to stick to one type of CPU.  The board will be able to
> >    accommodate the IDT 79R3081E (with the FPU and more cache) if the
> >    user wishes to replace the CPU.  This would mean that full floating
> >    point support routines need to be written; ho-hum.
> 
> I suspect the existing FPU emulator can form the core of a IEEE
> FPU emulator.  The hard part would be replacing the 387 front end
> with a mips one, assuming that the mips compiler uses a similar
> subset of IEEE FPU as the 386 one.  Since they are both gcc, this
> is probably the case.  Another guess: Mips FPU instructions are
> not going to be as hard to interpret as 387 ones.

FPU code is not that hard to write; I've done it before.  There seems to
be a fairly large amount of people wanting the FPU though.  That decision
doesn't need to be made until we do purchasing.

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

I don't like the idea of hardware swapping the bits, so this favours
little endian, however, RISCos is big endian and has a few ISA bus
slots; so the software must swap the bytes itself; Mmmm, this is the
RISC way, after all...


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

 
From caret@pyramid.com Wed Jun 23 23:50:48 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA08714; Wed, 23 Jun 93 23:50:41 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06887; Wed, 23 Jun 93 14:50:37 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA04704; Wed, 23 Jun 93 14:50:34 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306232150.AA04704@sword.eng.pyramid.com>
Subject: Re: MIPS R3000 - 2nd update
To: riscy@pyramid.com
Date: Wed, 23 Jun 93 14:50:34 PDT
In-Reply-To: <199306231126.AA21307@nag.cs.Colorado.EDU>; from "Drew Eckhardt" at Jun 23, 93 5:26 am
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

> Software for the board, most noteably an X server and device 
> drivers.  If it doesn't run Linux and X, it's an expensive paper 
> weight.
> 
> We need to set some finite time deadline for the board component
> specs (ie what chips, etc) so us software hackers can get started 
> writing SCSI drivers, VM code, etc that our code will be done and
> ready for debugging once the hardware is ready.

That is kind of difficult right now.  We still have no-one interested in
doing one of the harder tasks on the board, notable the ISA interface.
Once there are people allocated to all the tasks, the design shouldn't
take long.  I figure we a looking at about October for the first
batch of boards.

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

I'm not in favour of doing this kind of byte swapping.  If this issue
really matters, then we should definately run the OS in little
endian mode.  If the OS must run in big endian mode then the software
would have to byte swap for 16 bit accesses; this is the RISC way after
all...  BTW, to stop any possible mis-interpretations before they
start, the CPU must be placed in either big or little endian mode
when its reset.  It cannot be changed later.

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

Agreed.

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

Video, SCSI and ethernet are things that I'm not going to give up
on easily.

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

 
From caret@pyramid.com Thu Jun 24 00:15:24 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA08799; Thu, 24 Jun 93 00:15:22 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA10148; Wed, 23 Jun 93 15:15:07 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08576; Wed, 23 Jun 93 15:15:00 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306232215.AA08576@sword.eng.pyramid.com>
Subject: Re: MIPS R3000 - 2nd update
To: riscy@pyramid.com
Date: Wed, 23 Jun 93 15:15:00 PDT
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

> Neil, what happens with the boot PROM interface: can it be set
> to feed the CPU with either byte order?

Duno.  I'll check.  I'd be surprised if the 3730 didn't just take
care of it.

> >3.  What *other* uarts are out there?  In microlab, we used 
> >	a nice DUART (same vintage as the 8250's) that was 
> >	buffered.
> 
> Steve has been looking at these for a while. I believe he'd
> gotten close to the "best" serial port he could find. Steve?

The best I've seen is the Motorola MC68302, which has 3 serial ports
capable of some very good speed.  However, this guy may be a little
too expensive, since its also has a 68000 CPU core in it.

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

If the required video bandwidth is going to his the main bus hard
(which I think t will) we will need something extra to run the
VRAM.  There are plenty of chips that can do this, but they are
mostly too expensive, or are SMT.  The only exception that comes
to mind is the TMS 34010, which can be has for us$20 in small quantities
and does come in J-lead.  This issue really needs some serious
investigation.

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

 
From calica@cae.wisc.edu Thu Jun 24 05:04:53 1993
Return-Path: <calica@cae.wisc.edu>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA09233; Thu, 24 Jun 93 05:04:51 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20912; Wed, 23 Jun 93 20:04:44 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA20928; Wed, 23 Jun 93 20:04:35 -0700
Received: from serv0.cae.wisc.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20836; Wed, 23 Jun 93 20:04:34 -0700
Received: from hprisc-25.cae.wisc.edu by serv0.cae.wisc.edu (4.1/25)
	id AA24947; Wed, 23 Jun 93 22:03:21 CDT
Received: by hprisc-25.cae.wisc.edu (16.8/client-1.3)
	id AA00861; Wed, 23 Jun 93 22:05:56 -0500
From: Carlo J. Calica <calica@cae.wisc.edu>
Message-Id: <9306240305.AA00861@hprisc-25.cae.wisc.edu>
Subject: Re: MIPS R3000 - 2nd update
To: riscy@pyramid.com
Date: Wed, 23 Jun 93 22:05:56 CDT
Mailer: Elm [revision: 66.36.1.2]
Status: RO
X-Status: 

> The best I've seen is the Motorola MC68302, which has 3 serial ports
> capable of some very good speed.  However, this guy may be a little
> too expensive, since its also has a 68000 CPU core in it.
> 
Well if we do use this 'extra' CPU could we use it for something?  Maybe
sound?  In any case sound is something to think about.  If we do add it
would it be a simple DAC or something more complicated?  If set up properly,
the 68000 (or something more specialized) could combine various waves forms
to two DACs.  That would be all digital and sound better than most anything
for the PC.


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

 
From andy@resi.waldorf-gmbh.de Thu Jun 24 09:13:14 1993
Return-Path: <andy@resi.waldorf-gmbh.de>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA10627; Thu, 24 Jun 93 09:13:08 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09578; Thu, 24 Jun 93 00:12:50 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA22870; Thu, 24 Jun 93 00:12:20 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09126; Thu, 24 Jun 93 00:12:15 -0700
Received: by mail.Germany.EU.net(EUnetD-2.2.6.c) via EUnet
	id JL26502; Thu, 24 Jun 1993 09:09:22 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for unido
	id AA14767; Thu, 24 Jun 93 09:06:20 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Thu, 24 Jun 93 09:04:43 +0200
Message-Id: <9306240704.AA07601@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA07601; Thu, 24 Jun 93 09:04:43 +0200
To: caret@pyramid.com, riscy@pyramid.com
Subject: Re: MIPS R3000 - 2nd update
Cc: andy@resi.waldorf-gmbh.de
Status: RO
X-Status: 


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

There is a MIPS SYSV ABI and it is big-endian. SGI is big-endian too.
So far I know is a Mips Magnum 3000 one of the reference platforms
for Mips-RiscOS 5.01, Irix SVR4 and Sony News. The Magnum 3000
is big-endian. It does not support switching to little-endian.

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

 
