Subject: Re: MIPS R3000 - 2nd update

From: Patrick Mackinlay <[email-masked]>
Date: Wed, 23 Jun 1993 23:48:29 +0800 (WST)

>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: [email-masked] (Tor Arntsen)
Date: Wed, 23 Jun 1993 18:34:45 +0200

On Jun 23, 11:48pm, Patrick Mackinlay wrote:
[...]
> to feed the CPU with either byte order?

SGI is big-endian.

Tor

---

From: [email-masked] (Neil Russell)
Date: Wed, 23 Jun 93 15:15:00 PDT

> 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.

> 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.

> complicated stuff like these things, and just shoot for a straight

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:  [email-masked]
3860 N. First Street			Voice:  (408) 428-7302
San Jose, CA 95134-1702			  FAX:  (408) 428-8845

---

From: Carlo J. Calica <[email-masked]>
Date: Wed, 23 Jun 93 22:05:56 CDT

> 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  |
|     [email-masked]       | Dittos from the People's              | 
 \ University of Wisconsin      | Republic of Madison                  /

---

From: Andreas Busse <[email-masked]>
Date: Thu, 24 Jun 93 09:04:43 +0200

> If there's a SYSV MIPS ABI, we should comply with the endianness

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: [email-masked]
-------------------------------------------------------------------------------