From: drew@caesar.cs.colorado.edu (Drew Eckhardt) Subject: Re: MIPS R3000 - 2nd update Date: Mon, 28 Jun 1993 06:15:44 GMT
In article <pdhC9925y.64E@netcom.com> pdh@netcom.com (P D H) writes:
>drew@cs.colorado.edu (Drew Eckhardt) writes:
>>
>>SCSI of some flavor (unfortunately we're limited here because all the
>>really neat SCSI chips are surface mount only), the TI32010 has
>>been suggested for video because it will talk to VRAM and is available
>>in non-surface mount packages,
>
>How about a split (non-interfering, not electrically connected to the
>other ISA bus) one slot ISA bus and just drop in a SCSI card there?
>If there is a cheap SCSI card for some other bus, that is possible,
>though doing ISA may just be easier overall.
It's a lot easier, and cheaper (initially some people I'd talk to
said SCSI chips started at about $5, but it looks like the most promosing
NCR chip will run about $40 in quantity, all it requires is a little
glue to plug it into the bus / DMA controller and SCSI terminators)
to just put it on one of the low speed I/O busses.
>>> CMOS RAM? How many banks of SIMMS?
>>
>>32 simm slots, which will take up to 4M 8 or 9 bit wide SIMMs.
>
>If all disk is SCSI (which I would prefer) then we won't need a setup RAM.
There are other options which might be stored in NOVRAM - ie,
display type (if it isn't jumper selectable)...
>How about at least having the traces on the board for adding more simm
>sockets? Someone might want more than 32M.
They can use 4M chips, for a total of 128M :-)
Besides, more sockets means more real estate used, and I'm not sure
what the limit is on our RAM controller (Pat? Neil?).
>>It's been my experience that device drivers aren't too tricky
>>when there's no variation in the hardware involved (ie, you
>>have a single type of CPU board, running only at 40 Mhz,
>>with a single peripherial) since if it works on your system,
>>there's almost no way it won't work on someone elses....
>
>How about a standardized high resolution clock to make it easier to do
>those short timing loops so that dependency on CPU speed is unnecessary?
I guess I was unclear here - that's not really the problem. The problem
with PC's is that all the hardware is different, and different board
revisions, etc may have quirks that the developer didn't deal with since
his system didn't exhibit them. For example, the original AT disk driver
would puke if there were any non IDE/MFM/other ST-506 drives in the
system (ie SCSI), the Adaptec driver didn't work with the 1542C even
though it was allegedly 1542B compatable, the ET4000 driver (fixed
by coincidence in XFree1.3) wouldn't work with the "backwards
compatable" ET4000/W32....
In otherwords, with everybody using identical hardware, I can be real
sure that if it works on my system it will work on there system.
>
>>It was suggested that we stick an Intel 8051 off of one of the peripherial
>>busses.
>
>How hard would it be for its code to be in RAM and loaded from the main
>CPU? It would not need ROM if the boot ROM loads it with default code.
>I tend to like to play with the code in coprocessors, and would really
>like to be able to code it.
My guess is that it would be downloaded at bootup from someplace. If
you're interested in the design of the board, I suggest you join the
mailing list, riscy-request and riscy@pyramid.com - serious hardware
gurus hang out there who will be better able to answer your questions.
-- Boycott USL/Novell for their absurd anti-BSDI lawsuit. | Condemn Colorado for Amendment Two. | Drew Eckhardt Use Linux, the fast, flexible, and free 386 unix | drew@cs.Colorado.EDU Will administer Unix for food |