From caret@pyramid.com  Ukn Jul  4 00:27:24 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA22787; Sun, 4 Jul 93 00:27:22 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA07361; Sat, 3 Jul 93 21:26:29 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA17812; Sat, 3 Jul 93 21:26:18 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA17803; Sat, 3 Jul 93 21:26:15 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9307040426.AA17803@sword.eng.pyramid.com>
Subject: Main CPU and Peripheral controller
To: riscy@pyramid.com
Date: Sat, 3 Jul 93 21:26:15 PDT
X-Mailer: ELM [version 2.3 PL11]
Sender: riscy-request@pyramid.com
Reply-To: riscy@pyramid.com
Status: RO
X-Status: 

In my original design, I had planned to use the IDT 79R3730 "Raster
Image Processor".  IDT's intended market for the device is the
Laser Printer market, however the chip lends itself to our design
quite nicely.  In the 1992/1993 Data Book entitled "RISC Microprocessor
Components & SubSystems", there is Advance information on the 3730.
The following is copied from it:

  FEATURES:
	*  Integrated System Controller(TM) for the IDT R3051
	   family Raster Image Processors and Laser Printer
	   Controllers:
	     -  Direct interface to R3041, R3051, R3052 and R3081
	     -  Supports clock frequencies to 40 MHz.
	*  High-Performance, programmable DRAM controller:
	     -  Flexible DRAM control for up to 128 MB of two-way
		interleaved or non-interleaved DRAM (up to 8 banks)
	     -  Wide variety of memory configurations (eg. different
		sized DRAMs for base and SIMM extensions)
	     -  DMA channel for memory pattern fill/clear
	     -  DRAM parity generation/checking
	*  Programmable I/O ports support glue-less interface to
	   support low-cost peripherals:
	     -  Burst DMA channels with chaining
	     -  On-chip 4-word x 32-bit FIFOs with data packing
		and unpacking
	     -  Master/slave peripheral interface
	     -  8-bit and 16-bit I/O ports.
	*  Co-processor DMA interface for accelerator ASICs
	   (eg. Adobe's Type 1 font rasterizer and PixelBurst(TM)
	   display list processor)
	*  Programmable Interrupt Controller
	*  High-performance programmable video interface
	     -  1, 2 or 4 serial video streams support high video
		bandwidth (bi-level or 4-bit color)
	     -  Video DMA channels with chaining
	     -  On-chip 8-word x 32-bit video FIFO
	     -  Programmable margin counters
	     -  Video bit rates to 160 mega-bits per second
	     -  Supports split stream video
	     -  PEL counter
	*  Controls for ROM memory system
	     -  Programmable controls for up to 24 MB of interleaved
		or non-interleaved ROM/EPROM (up to 6 banks)
	     -  Burst ROM/EPROM support
	     -  Glue-less interface for 8-bit boot ROM or EPROM
	*  General purpose functions
	     -  Bus timeout counter
	     -  Rotate assist (0, 90, 180, 270 degrees and mirror)
		hard-ware
	     -  General purpose counter/timer
	     -  Bit programmable I/O port.


To rephrase all this into what this means for us:

	*  Our DRAM interface can be two-way interleaved (which means
	   that 64-bits of memory are accessed each memory cycle, so
	   that the CPU will have the data for its next read already
	   in the data buffers, which reduces every second access to
	   1-cycle instead of about 6-cycles), DRAM page mode and
	   early-write modes can be taken advantage of to further
	   speed up access.
	*  The interface to the DRAM is reduced to a handful of
	   buffers and bi-directional latches; there is no logic
	   for address decoding.
	*  DRAM refresh is taken care of.
	*  There are two extra busses provided by the 3730:  an
	   8-bit one and a 16-bit one.  Each bus has a small address
	   bus in addition to its data bus.  The processor can
	   access devices on these busses directly with the 3730 taking
	   care of the data-size/endian issue automatically.  If
	   a DMA is setup to a device on one of these busses, the
	   main memory bus is not held up waiting for the slower
	   devices to respond.  The 3730 will do a burst DMA into
	   main memory whenever there is sufficient data.
	*  Any of the DMA channels can be chained, which means (if
	   I understand this correctly) we can do scatter/gather.
	   (All this would make the SCSI interface almost trivial).
	*  Glue for an extend bus (such as ISA) would require very
	   little additional support.


I talked to IDT on Friday (July 2) and have some more information about
the IDT R3730.

First the good news:  They have already made the first production run
of wafers of this chip.  They expect that the chip will be in the
stores :-) by October.  The salesman I spoke to is willing to provide
an information package this week.

Now the bad news:  The chip is only available in a 208 pin FQFP (a
surface mount package).  The pricing is us$50 - us$70 in lots of
5,000.  This would translate to >us$100 for the quantities that
we want.

However, there have been some developments in the last week or so
that may mean that Surface Mount is OK.  More on that as details
are available.


Alternatives
------------

If we cannot use the 3730, there is another alternative that was
thought up by Steven Ligett, Jerry Callen (and Pat Mackinlay?).

This involves creating a DRAM interface between the main CPU and
memory using programmable logic.  This interface would provide:

	*  DRAM address multiplexing
	*  Two-way interleaving
	*  Page mode support
	*  Early write mode support
		(The last three are provided on the special CPU
		 cycles only, such as the instruction cache refill).

There would be a R3041 co-processor connected to the main CPU via a DMA
channel.  The only connection to the outside world for the main CPU
would be this co-processor.

Information copied from the IDT data book on the 3041:

   FEATURES:
	*  Instruction set compatible with IDT 79R3000A and R3051(TM)
	   family RISC CPUs
	*  High level of integration minimizes system cost:
	     -  RISC CPU
	     -  Multiply/divide unit
	     -  Instruction cache
	     -  Data cache
	     -  Programmable bus interface
	     -  Programmable port width support
	*  On-chip instruction and data caches:
	     -  2 KB of instruction cache
	     -  512 bytes of data cache
	*  Flexible bus interface allows simple, low cost designs
	     -  Superset pin-compatible with R3051
	     -  Adds programmable port width interface
		(8-bit, 16-bit and 32-bit memory sub-regions)
	     -  Adds programmable bus interface timing support
		(Extended address hold, bus turn around time,
		 read/write masks)
	*  Single, double frequency clock input
	*  16 or 20 MHz operation
	*  14 MIPS at 20 MHz
	*  Low cost 84-pin PLCC packaging
	*  On-chip 4-deep write buffer eliminates memory write stalls
	*  On-chip 4-word read buffer supports burst or simple block reads
	*  On-chip DMA arbiter
	*  On-chip 24-bit timer
	*  Boot from 8-bit, 16-bit or 32-bit wide boot ROMs

The 3041 essentially does in software what the 3730 does in hardware,
with the added flexibility that its very programmable.  As an example,
if the 3041 was given a scatter/gather SCSI disk access to do, it
would read/write the data directly top the SCSI port, and write/read
the data to the appropriate location in the main CPUs memory.


Some costings:

    3730:
	3730	about $120 or more (see above)
	glue	about $10 (buffers, latches, one of two PALs)

    3041:
	3041	about $35
	glue	about $30 (buffer, latches, lots of PALs)
	memory	about $45 (maybe those old 256K SIMMS?)


Advantages of 3730:
	-  Single chip does almost everything
	-  Not much R&D to get it going
Disadvantages of 3730:
	-  Cost (maybe; can't tell until October)
	-  Availability
Advantages of 3041:
	-  Parts are available now
	-  Cost
	-  More programmable (RISC does it in software approach)
Disadvantages of 3041:
	-  More R&D
	-  Lots of hard real time software to write
	-  More board space needed.

(Note:  If video is provided on the motherboard and connected to the 3041,
        then maybe some of the unused space in the VRAM could be used as
	program memory for the 3041, further reducing the cost.)


My opinion is that we should dump the 3730 and use the 3041 approach.
The cost of the extra board space is offset by the reduction in cost
of the sub-system, and the parts are available *now*.


Comments?


For you interest, this is the blurb for the R3081 (the proposed main CPU):

    FEATURES:
	*  Instruction set compatible with IDT 79R3000A, R3051 and
	   R3500 RISC CPUs
	*  High level of integration minimizes system cost
	     -  R3000A Compatible CPU
	     -  R3010A Compatible FPU
	     -  Optional R3000A compatible MMU [E suffix - ed]
	     -  Large instruction cache
	     -  Large data cache
	     -  Read/write buffers
	*  35 VUPS at 40 MHz
	     -  64,000 Dhrystones
	     -  11 MFlops
	*  Flexible bus interface allows simple, low cost designs
	*  Optional 1x or 2x clock input
	*  20, 25, 33 or 40 MHz operation
	*  "L" version operates at 3.3V [this saves power - ed]
	*  Large on-chip caches with user configurability
	     -  16 KB Instruction cache, 4 KB data cache
	     -  Dynamically configurable to 8 KB instruction cache
		and 8 KB data cache
	     -  Parity protection over data and tag fields
	*  Low cost 84-pin packaging
	*  Super-set compatible with the R3051
	*  Multiplexed bus interface with support for low-cost,
	   low-speed memory systems with a high speed CPU
	*  On-chip 4-deep write buffer eliminates memory write stalls
	*  On-chip 4-deep read buffer supports burst or simple block reads
	*  On-chip DMA arbiter
	*  Hardware-based cache coherency support [snooping cache - ed]
	*  Programmable power reduction mode
	*  Bus interface can operate at half-processor frequency
-- 
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 andy@piggy.waldorf-gmbh.de  Ukn Jul  4 12:52:46 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA02102; Sun, 4 Jul 93 12:52:44 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA07286; Sun, 4 Jul 93 09:52:14 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA03311; Sun, 4 Jul 93 09:52:01 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA03280; Sun, 4 Jul 93 09:51:58 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA07208; Sun, 4 Jul 93 09:52:02 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.e) via EUnet
	id XC28952; Sun, 4 Jul 1993 18:48:59 +0200
Received: from piggy.waldorf-gmbh.de 
	by wegy.waldorf-gmbh.de with UUCP (5.61/GEN-1.0.7)
	via EUnet for unido
	id AA24929; Sun, 4 Jul 93 18:41:12 +0200
From: Andreas Busse <andy@piggy.waldorf-gmbh.de>
Date: Sun, 4 Jul 93 19:20:20 GMT
Message-Id: <9307041920.AA20101@piggy.waldorf-gmbh.de>
Received: by piggy.waldorf-gmbh.de (5.65b/GEN-1.0.7)
	via EUnet for wegy
	id AA20101; Sun, 4 Jul 93 19:20:20 GMT
To: riscy@pyramid.com
Subject: Re: Main CPU and Peripheral controller
Sender: riscy-request@pyramid.com
Reply-To: riscy@pyramid.com
Status: RO
X-Status: 


> To rephrase all this into what this means for us:
> 
> 	*  Our DRAM interface can be two-way interleaved (which means
> 	   that 64-bits of memory are accessed each memory cycle, so
> 	   that the CPU will have the data for its next read already
> 	   in the data buffers, which reduces every second access to
> 	   1-cycle instead of about 6-cycles), DRAM page mode and
> 	   early-write modes can be taken advantage of to further
> 	   speed up access.

This is *very* important. We have a Mips Magnum 3000 (33 MHz) and
a Magnum 4000PC (50 MHz) in the office. Due to the fact that the
R4000 has only 8+8k cache the machine is sometimes slower (up to
factor 2) than the R3000 machine which has 32+32k cache. By speeding
up main memory access we will improve overall speed by a significant
amount, especially because the 3081E has a rather small cache
compared to discrete R3000/R3010 solutions.

>	*  Glue for an extend bus (such as ISA) would require very
>	   little additional support.

An extra argument for the ISA bus.

> Now the bad news:  The chip is only available in a 208 pin FQFP (a
> surface mount package).  The pricing is us$50 - us$70 in lots of
> 5,000.  This would translate to >us$100 for the quantities that
> we want.

There are FQFP (isn't it called PQFP ?) sockets available.
But they are heavily expensive :-(

> However, there have been some developments in the last week or so
> that may mean that Surface Mount is OK.  More on that as details
> are available.

Hmmmm. :-)


> Alternatives
> ------------
> 
> If we cannot use the 3730, there is another alternative that was
> thought up by Steven Ligett, Jerry Callen (and Pat Mackinlay?).
> 
> This involves creating a DRAM interface between the main CPU and
> memory using programmable logic.  This interface would provide:
>
>	*  DRAM address multiplexing
>	*  Two-way interleaving
>	*  Page mode support
>	*  Early write mode support
>		(The last three are provided on the special CPU
>		 cycles only, such as the instruction cache refill).
>
> There would be a R3041 co-processor connected to the main CPU via a DMA
> channel.  The only connection to the outside world for the main CPU
> would be this co-processor.
> 
> Information copied from the IDT data book on the 3041:
>
> [...]
>
> The 3041 essentially does in software what the 3730 does in hardware,
> with the added flexibility that its very programmable.  As an example,
> if the 3041 was given a scatter/gather SCSI disk access to do, it
> would read/write the data directly top the SCSI port, and write/read
> the data to the appropriate location in the main CPUs memory.
>
>
> Some costings:
> 
>     3730:
> 	3730	about $120 or more (see above)
>	glue	about $10 (buffers, latches, one of two PALs)
		     -----
		      $130
>
>    3041:
>	3041	about $35
>	glue	about $30 (buffer, latches, lots of PALs)
>	memory	about $45 (maybe those old 256K SIMMS?)
		     ----
		     $110

>
> Advantages of 3730:
> 	-  Single chip does almost everything
> 	-  Not much R&D to get it going
> Disadvantages of 3730:
> 	-  Cost (maybe; can't tell until October)
> 	-  Availability
> Advantages of 3041:
> 	-  Parts are available now
> 	-  Cost
> 	-  More programmable (RISC does it in software approach)
> Disadvantages of 3041:
> 	-  More R&D
> 	-  Lots of hard real time software to write
> 	-  More board space needed.

The costs difference isn't that much. But the R&D difference
seems to be large. A 3730 solution would speed up design
and will be more reliable than a hand-made solution with
the 3041.

> (Note:  If video is provided on the motherboard and connected to the 3041,
>        then maybe some of the unused space in the VRAM could be used as
>	program memory for the 3041, further reducing the cost.)

If we would take the 1 Meg / 1152x900 video there won't be
any unused memory anymore...

> My opinion is that we should dump the 3730 and use the 3041 approach.
> The cost of the extra board space is offset by the reduction in cost
> of the sub-system, and the parts are available *now*.

I agree that we would have the board earlier if we are going to
use the 3041 solution. But we will have to spend more time into
programming the 3041 and arranging the hardware around what might
mean that the design isn't finished until October no matter what
solution we use...


Andy
-------------------------------------------------------------------------------
Andreas Busse             | e-mail: andy@piggy.waldorf-gmbh.de (home)
Eislebenstrasse 5         |         andy@resi.waldorf-gmbh.de (office)
D-5300 Bonn 1             | Phone:  +49 (0)228-252687
-------------------------------------------------------------------------------


 
From andy@piggy.waldorf-gmbh.de  Ukn Jul  4 12:52:46 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA02102; Sun, 4 Jul 93 12:52:44 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA07286; Sun, 4 Jul 93 09:52:14 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA03311; Sun, 4 Jul 93 09:52:01 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA03280; Sun, 4 Jul 93 09:51:58 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA07208; Sun, 4 Jul 93 09:52:02 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.e) via EUnet
	id XC28952; Sun, 4 Jul 1993 18:48:59 +0200
Received: from piggy.waldorf-gmbh.de 
	by wegy.waldorf-gmbh.de with UUCP (5.61/GEN-1.0.7)
	via EUnet for unido
	id AA24929; Sun, 4 Jul 93 18:41:12 +0200
From: Andreas Busse <andy@piggy.waldorf-gmbh.de>
Date: Sun, 4 Jul 93 19:20:20 GMT
Message-Id: <9307041920.AA20101@piggy.waldorf-gmbh.de>
Received: by piggy.waldorf-gmbh.de (5.65b/GEN-1.0.7)
	via EUnet for wegy
	id AA20101; Sun, 4 Jul 93 19:20:20 GMT
To: riscy@pyramid.com
Subject: Re: Main CPU and Peripheral controller
Sender: riscy-request@pyramid.com
Reply-To: riscy@pyramid.com
Status: RO
X-Status: 


> To rephrase all this into what this means for us:
> 
> 	*  Our DRAM interface can be two-way interleaved (which means
> 	   that 64-bits of memory are accessed each memory cycle, so
> 	   that the CPU will have the data for its next read already
> 	   in the data buffers, which reduces every second access to
> 	   1-cycle instead of about 6-cycles), DRAM page mode and
> 	   early-write modes can be taken advantage of to further
> 	   speed up access.

This is *very* important. We have a Mips Magnum 3000 (33 MHz) and
a Magnum 4000PC (50 MHz) in the office. Due to the fact that the
R4000 has only 8+8k cache the machine is sometimes slower (up to
factor 2) than the R3000 machine which has 32+32k cache. By speeding
up main memory access we will improve overall speed by a significant
amount, especially because the 3081E has a rather small cache
compared to discrete R3000/R3010 solutions.

>	*  Glue for an extend bus (such as ISA) would require very
>	   little additional support.

An extra argument for the ISA bus.

> Now the bad news:  The chip is only available in a 208 pin FQFP (a
> surface mount package).  The pricing is us$50 - us$70 in lots of
> 5,000.  This would translate to >us$100 for the quantities that
> we want.

There are FQFP (isn't it called PQFP ?) sockets available.
But they are heavily expensive :-(

> However, there have been some developments in the last week or so
> that may mean that Surface Mount is OK.  More on that as details
> are available.

Hmmmm. :-)


> Alternatives
> ------------
> 
> If we cannot use the 3730, there is another alternative that was
> thought up by Steven Ligett, Jerry Callen (and Pat Mackinlay?).
> 
> This involves creating a DRAM interface between the main CPU and
> memory using programmable logic.  This interface would provide:
>
>	*  DRAM address multiplexing
>	*  Two-way interleaving
>	*  Page mode support
>	*  Early write mode support
>		(The last three are provided on the special CPU
>		 cycles only, such as the instruction cache refill).
>
> There would be a R3041 co-processor connected to the main CPU via a DMA
> channel.  The only connection to the outside world for the main CPU
> would be this co-processor.
> 
> Information copied from the IDT data book on the 3041:
>
> [...]
>
> The 3041 essentially does in software what the 3730 does in hardware,
> with the added flexibility that its very programmable.  As an example,
> if the 3041 was given a scatter/gather SCSI disk access to do, it
> would read/write the data directly top the SCSI port, and write/read
> the data to the appropriate location in the main CPUs memory.
>
>
> Some costings:
> 
>     3730:
> 	3730	about $120 or more (see above)
>	glue	about $10 (buffers, latches, one of two PALs)
		     -----
		      $130
>
>    3041:
>	3041	about $35
>	glue	about $30 (buffer, latches, lots of PALs)
>	memory	about $45 (maybe those old 256K SIMMS?)
		     ----
		     $110

>
> Advantages of 3730:
> 	-  Single chip does almost everything
> 	-  Not much R&D to get it going
> Disadvantages of 3730:
> 	-  Cost (maybe; can't tell until October)
> 	-  Availability
> Advantages of 3041:
> 	-  Parts are available now
> 	-  Cost
> 	-  More programmable (RISC does it in software approach)
> Disadvantages of 3041:
> 	-  More R&D
> 	-  Lots of hard real time software to write
> 	-  More board space needed.

The costs difference isn't that much. But the R&D difference
seems to be large. A 3730 solution would speed up design
and will be more reliable than a hand-made solution with
the 3041.

> (Note:  If video is provided on the motherboard and connected to the 3041,
>        then maybe some of the unused space in the VRAM could be used as
>	program memory for the 3041, further reducing the cost.)

If we would take the 1 Meg / 1152x900 video there won't be
any unused memory anymore...

> My opinion is that we should dump the 3730 and use the 3041 approach.
> The cost of the extra board space is offset by the reduction in cost
> of the sub-system, and the parts are available *now*.

I agree that we would have the board earlier if we are going to
use the 3041 solution. But we will have to spend more time into
programming the 3041 and arranging the hardware around what might
mean that the design isn't finished until October no matter what
solution we use...


Andy
-------------------------------------------------------------------------------
Andreas Busse             | e-mail: andy@piggy.waldorf-gmbh.de (home)
Eislebenstrasse 5         |         andy@resi.waldorf-gmbh.de (office)
D-5300 Bonn 1             | Phone:  +49 (0)228-252687
-------------------------------------------------------------------------------


 
From caret@pyramid.com  Ukn Jul  4 13:58:30 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA03107; Sun, 4 Jul 93 13:58:29 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA12085; Sun, 4 Jul 93 10:57:59 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA11379; Sun, 4 Jul 93 10:57:40 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA11370; Sun, 4 Jul 93 10:57:38 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9307041757.AA11370@sword.eng.pyramid.com>
Subject: Re: Main CPU and Peripheral controller
To: riscy@pyramid.com
Date: Sun, 4 Jul 93 10:57:38 PDT
In-Reply-To: <9307041920.AA20101@piggy.waldorf-gmbh.de>; from "Andreas Busse" at Jul 4, 93 7:20 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: riscy-request@pyramid.com
Reply-To: riscy@pyramid.com
Status: RO
X-Status: 

> 
> > However, there have been some developments in the last week or so
> > that may mean that Surface Mount is OK.  More on that as details
> > are available.
> 
> Hmmmm. :-)


This is you!

We need to decide if Waldorf is going to go public about this or not.
If so, it should happen very soon.  This fact could change the way the
design goes.

If you like, I'll tell them.  To do that, all I need is a little
knowledge of what you need on the MB in addition to our stuff (like
a connector to your own boards).

-- 
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  Ukn Jul  4 14:11:20 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA03318; Sun, 4 Jul 93 14:11:19 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA12805; Sun, 4 Jul 93 11:10:53 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA12117; Sun, 4 Jul 93 11:10:41 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA12110; Sun, 4 Jul 93 11:10:40 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9307041810.AA12110@sword.eng.pyramid.com>
Subject: Re: Main CPU and Peripheral controller
To: riscy@pyramid.com
Date: Sun, 4 Jul 93 11:10:39 PDT
In-Reply-To: <9307041757.AA11370@sword.eng.pyramid.com>; from "Neil Russell" at Jul 4, 93 10:57 am
X-Mailer: ELM [version 2.3 PL11]
Sender: riscy-request@pyramid.com
Reply-To: riscy@pyramid.com
Status: RO
X-Status: 

> 
> > 
> > > However, there have been some developments in the last week or so
> > > that may mean that Surface Mount is OK.  More on that as details
> > > are available.
> > 
> > Hmmmm. :-)
> 
> 
> This is you!


Sorry riscers, this was not meant to go to the general group, but
a specific member;  I guess that 'Reply-to' got me... :-(

Please ignore it for now...

 
From jeremy@sw.oz.au  Ukn Jul  5 04:03:20 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA21044; Mon, 5 Jul 93 04:03:19 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA27996; Mon, 5 Jul 93 01:02:45 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA00443; Mon, 5 Jul 93 01:02:32 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA00436; Mon, 5 Jul 93 01:02:29 -0700
Received: from munnari.OZ.AU 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA27876; Mon, 5 Jul 93 01:02:17 -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 AA18509; Mon, 5 Jul 1993 18:00:37 +1000 (from jeremy@sw.oz.au)
Received: from chao.sw.oz.au by swift.sw.oz.au with SMTP
	id AA26177; Mon, 5 Jul 93 17:58:18 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 AA13011; Mon, 5 Jul 93 17:58:03 EST
From: jeremy@sw.oz.au (Jeremy Fitzhardinge)
Message-Id: <9307050758.AA13011@chao.sw.oz.au>
Subject: Re: Main CPU and Peripheral controller
To: riscy@pyramid.com
Date: Mon, 5 Jul 1993 17:58:02 +1000 (EST)
Cc: riscy@pyramid.com
In-Reply-To: <9307040426.AA17803@sword.eng.pyramid.com> from "Neil Russell" at Jul 3, 93 09:26:15 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: 2403      
Sender: riscy-request@pyramid.com
Reply-To: riscy@pyramid.com
Status: RO
X-Status: 

Neil Russell bubbles:

> In my original design, I had planned to use the IDT 79R3730 "Raster
> Image Processor".  IDT's intended market for the device is the
> Laser Printer market, however the chip lends itself to our design
> quite nicely.  In the 1992/1993 Data Book entitled "RISC Microprocessor
> Components & SubSystems", there is Advance information on the 3730.

I think this looks very good, and we should go with it.  The extra
cost doesn't seem that much considering how much it has, and how much
board space it will save.  The extra features make onboard video most
attractive, and the best solution for video.

On the subject of video:

You may of noticed that I like the onboard ideas.  Just one more point:
there has to be at least 2 frames worth of video memory for double
buffering.  Of course, you need only install one frame's worth (I
suggest), but there should be space for 2.  Using the 3730 and directly
connected video memory could get some serious graphics performance.


My Views On Other Things:

* Ether:
	Either main board or ISA.
	I don't care if ether performance is reasonable thru an ISA connector.
	Raw performace isn't the only issue:  its also important to consider
	how much CPU time it sucks while IO is happening.  If DMA can't be done
	with an ISA card, there should be some option on the main board.

* SCSI:
	Yes.

* ISA:
	Yes.  This excludes the need for pretty much everything else.
	At least one slot is going to have a FDC in it.

* RAM:
	There should be memory.

* ROM:
	I don't think lots is needed.  The 3730 allows a single 8 bit
	EPROM to be used.  I think it should.  I don't see that a lot
	of stuff needs to be in it.  The limitation should be 1 chip's
	worth, so whatever EPROM with the most practial capacity.
	Having 4 EPROMs just to make a 32 bit bus would be a waste of
	board.

* RTC & misc goo:
	Well, RTC is probably best done with a Dallas Semi smart watch.
	It can go either under the EPROM or under some static ram to
	make it nv.  Other things are pretty trivial.  Serial ports are
	necessary and easy.  Parallel would be good for simple things.
	I can't see a printer port being that useful (since an ISA card
	is very cheap), but a few bits for diag LEDs is good.  You could
	have a 1 bit speaker for beeping with on it, for those who don't
	need good sound.  For those who do, it should be an option.
	No audio DACs on the board.

	J

 
