Subject: Boot rom and other useless junk.

From: [email-masked] (Rogier Wolff)
Date: Tue, 22 Jun 93 17:39:15 +0200

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: Patrick Mackinlay <[email-masked]>
Date: Tue, 22 Jun 1993 23:47:56 +0800 (WST)

>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