From wolff@dutecai.et.tudelft.nl Tue Jun 22 17:41:22 1993
Return-Path: <wolff@dutecai.et.tudelft.nl>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA03653; Tue, 22 Jun 93 17:41:18 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA24610; Tue, 22 Jun 93 08:43:44 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02800; Tue, 22 Jun 93 08:40:48 -0700
Received: from liberator.et.tudelft.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA24597; Tue, 22 Jun 93 08:43:37 -0700
Received: by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA03031; Tue, 22 Jun 93 17:39:15 +0200
Date: Tue, 22 Jun 93 17:39:15 +0200
From: wolff@dutecai.et.tudelft.nl (Rogier Wolff)
Message-Id: <9306221539.AA03031@liberator.et.tudelft.nl>
To: riscy@pyramid.com
Subject: Boot rom  and other useless junk.
Status: RO
X-Status: 



Hi everyone,

After reading the "preliminary specs" I have the following suggestions:

>* Boot EPROM
>        Because of the 3730, we can get away with just one EPROM.
>        Maybe two just for kicks.  Access to this is slow, so if
>        speed were are problem, then code could be copied to RAM.

I'd suggest using the approach that we've used for a design here. What
we do is we have the x86 CPU control the reset line of the "bigger" cpu.
The x86 also has access to (at least some of) the RAM of the R3000.
This will enable the x86 to place the boot code into the RAM before
releasing the RESET of the R3000.

Instant saving: 1 eprom per board, Development costs (reburning EPROMS all 
the time....)

>*  Keyboard controller
>        This should certainly handle IBM compatible style keyboards.
>        The only way I know to do this is to use the 8051(?) micro-
>        controller to drive the keyboard exactly the same way as
>        every mother-board I've seen does.  This circuit should
>        connect easily to the 8-bit bus of the 3730.

See below, near "serial port".

>*  Non-Volatile-RAM and Real-Time-Clock
>        This should be looked into.  The clock is almost a requirement
>        but the NV-RAM could be replaced with the feature selector.

Why do you need a NV RAM? Why do you  need a RTC? You do need an
interrupt every 10ms. You can initialize from the RTC on the PC.
(ok. ok. Those are crummy, but you can live with it....)

>*  Serial port
>        Because of the ISA bus, serial is always possible.  It might
>        be a good idea, if just for debugging to have some serial
>        ports on the mother-board.  If this is the case, they should
>        be at least as good as 16550's.

My suggestion is to have a shared memory interface that looks like a 
serial line:

        struct combuf {
                int hd,tl;
                char buf[BUFSIZE];
                }
        
        out_char (struct combuf *cb,ch)
        {
        int hd = cb->hd;
        cb->buf[hd] = ch;
        inc (hd);
        while (hd == cb->tl)
                sleep_a_little_while ();
        cb->hd = hd;
        }

        in_char (struct combuf *cb)
        {
        int tl = cb->tl;
        int ch;

        while (tl == cb->head)
                sleep_a_little_while ();
        ch = cb->buf[tl];
        inc (tl);
        cb->tl = tl;
        }
        

Both sides (on the PC and on the R3000) use this interface (with different
cb pointers). To both sides this looks more or less like a serial stream 
of data.

To make this work in an multitasking environment it would be nice
to have an interrupt too.

                                Roger.


 
From mackinla@cs.curtin.edu.au Tue Jun 22 17:49:00 1993
Return-Path: <mackinla@cs.curtin.edu.au>
Received: from liberator.et.tudelft.nl by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA03711; Tue, 22 Jun 93 17:48:55 +0200
Received: from marsh.cs.curtin.edu.au by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA03041; Tue, 22 Jun 93 17:48:42 +0200
Received: from vincent.cs.curtin.edu.au by marsh.cs.curtin.edu.au with SMTP id AA11182
  (5.67a/IDA-1.4.4 for <wolff@liberator.et.tudelft.nl>); Tue, 22 Jun 1993 23:47:57 +0800
Received: by vincent.cs.curtin.edu.au id AA14768
  (5.65c/IDA-1.4.4 for wolff@liberator.et.tudelft.nl); Tue, 22 Jun 1993 23:47:56 +0800
From: Patrick Mackinlay <mackinla@cs.curtin.edu.au>
Message-Id: <199306221547.AA14768@vincent.cs.curtin.edu.au>
Subject: Re: Boot rom  and other useless junk.
To: wolff@dutecai.et.tudelft.nl (Rogier Wolff)
Date: Tue, 22 Jun 1993 23:47:56 +0800 (WST)
In-Reply-To: <9306221539.AA03031@liberator.et.tudelft.nl> from "Rogier Wolff" at Jun 22, 93 05:39:15 pm
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 707       
Status: RO
X-Status: 


>I'd suggest using the approach that we've used for a design here. What
>we do is we have the x86 CPU control the reset line of the "bigger" cpu.

[...other suggestions deleted...]

Actually, we're working on the premise that the board is independant
of any other machine. The proposed board is a complete replacement
motherboard, no x86 involved. I think the majority of people have
kinda agreed that this is the best way to go. It makes the machine
a bit more expensive, but also more useful, as it can outgrow the
"host" PC.

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

 
