riscy
[Top] [All Lists]

Re: MIPS R3000 - 2nd update

To: riscy@pyramid.com (R3000 PC Mailing List)
Subject: Re: MIPS R3000 - 2nd update
From: Patrick Mackinlay <mackinla@cs.curtin.edu.au>
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

 

<Prev in Thread] Current Thread [Next in Thread>