From dlr Fri Nov 17 10:26:44 1989
Flags: 000000000000
Date: Fri, 17 Nov 89 10:25 PST
From: dlr (Dave Rand)
To: pc532@daver.uu.net
Subject: Welcome to the mailing list

Welcome to the PC532 mailing list. This list will be used to discuss
issues regarding the PC532 System. For those that missed it:

-------------------------------------------------------------------------------
Article 407 of comp.sys.nsc.32k:
Newsgroups: comp.sys.nsc.32k
Path: daver!dlr
>From: dlr@daver.UU.NET (Dave Rand)
Subject: PC532 system
Message-ID: <1989Nov16.051350.4711@daver.UU.NET>
Organization: Association for the Prevention of Polar Bears and Kangaroos
Date: Thu, 16 Nov 89 05:13:50 GMT

Last year, there was great talk about doing a 32532-based system,
with all kinds of wizzy features. Most people took note of the
suggestions, and some even went so far as to suggest some of
their own ideas :-)

We, george@wombat.UUCP (George Scolaro) and dlr@daver.UU.NET
(Dave Rand) went ahead and did a design. George did the hardware,
and I did (am doing :-) the software. Here are the details:

NS32532 CPU running at 25 Mhz (about 12.5 MIPS peak, 8 MIPS* average)
NS32381 FPU running at 25 Mhz
NS32202 ICU
4 to 32 megabytes of fast page DRAM (0 wait on first access in page,
1 wait in burst). 4 or 8 megabytes with 1 meg SIMMs, 16 or 32 with
4 meg SIMMs.
8 Serial ports (38.4 Kbps) with full modem control (RTS/CTS/DTR/CD)
and hardware flow control (Signetics 2681).
Dual SCSI bus:
    #1 is a Adaptec 6250, supporting Async/Sync SCSI up to >4meg/sec.
    #2 is a DP8490, supporting Async SCSI to 3.8meg/sec.

The #1 SCSI supports external Disk and tape. The #2 SCSI supports
four interal add-in card slots (mechanically IBM-PC style,
electrically not compatible). This gives us a very fast multi-master
bus with a very low risk and pin count. One add-in card has already
been designed (16 serial ports plus an Ethernet, and 1 meg of memory).

The main board is a "baby-AT" style board, and will fit into standard
IBM AT cases. We did a small run of PC boards, and have two of them up
and running now.

A couple of notes: Some of you will recall that George and I worked
for National Semiconductor - we no longer work there. As well, the
number of MIPS of the various processors in the world is always in
question. All that can be said for this 532 board is that it seems to be
at least 2-3 times faster than 33 Mhz 386 systems...

--
George Scolaro <george@wombat.UUCP>
Dave Rand <dlr@daver.uu.net>

-------------------------------------------------------------------------------
I'm getting System V up on it now. Or trying to, before my ICM dies.
The one at home (wombat) crashed twice last night.

The PCB's ran about $600/ea, in the small lot we did them in (5 boards).
If enough people are interested, we will do another run of boards to get
the cost down.

The last time we did this, though, it was not very successful. Most people
want the stuff, but don't wanna pay for it! So this really started out to
be a home project, to replace our aging ICM-3216's. The start came when I
noticed that despite all my tweaking, I could not drive all three Telbits
on daver.uu.net to maximum capacity. The 32016 just does not have enough
grunt to do three uucico's at 19.2Kbps.

Anyway, this is the 6th 32000 board George and I have done (taken to PCB).
We have done (here in the U.S.) 2 32016 cards (the PD-32 and one other
proprietary design); 2 32032 cards (The DSI-32 and one other); 1 32332 card
There were a couple of very proprietary, non-unix based systems that we have
done as well, based on the 32000. One in particular was based on the 32C016.
George has also done a couple of designs for the U of Western Australia, for
underwater probes using the 32000. The 532 design was prototyped on a wire
wrap card, and ran at 20 Mhz!! The PCB came in clean, the only wires were
due to board manufacturing defects (it is a 6 layer board). It is running at
25 Mhz, with no problems (yet).

So - are we going to make the design commercial? Or at least available?
That's up to you. What is it worth? Does it have to come with UNIX?
Does someone want to port Minix to it? How about gcc? What are your
ideas, now that we have hardware?

Send your contributions to pc532@daver.uu.net


From dlr Fri Nov 17 14:23:46 1989
Flags: 000000000001
Date: Fri, 17 Nov 89 14:23:06 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: dlr@daver (Dave Rand)
To: Bruce Culbertson <uunet!hplabs.hp.com!culberts%hplwbc>
Subject: Re: PD532
Cc: pc532@daver.uu.net

[In the message entitled "PD532" on Nov 17, 12:01, Bruce Culbertson writes:]
> > Does someone want to port Minix to it? 
> 
> Modifying my 32000 port should be pretty easy.  I have already replaced
> the PC-Minix memory management with a paged scheme and implemented
> copy-on-write forking.  Of course, I would have difficulty doing the
> port without having a board.
Great! At least we have a source of a 32000 Minix!

> 
> > How about gcc?
> 
> I consider this done.  I ported Minix to my 32000 system using GCC and
> my assembler/linker.  I also compiled the 100+ Minix utilities and many
> library routines.  I would call that a pretty good stress test.  I
> consider my tools and GCC changes to be in the public domain, if anyone
> wants to use them.
And a gcc!


-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From dlr Fri Nov 17 22:10:24 1989
Flags: 000000000000
Date: Fri, 17 Nov 89 22:09 PST
From: dlr (Dave Rand)
To: pc532@daver.uu.net
Subject: More info.

First, many folks have been sending email replies to me directly - while
that is fine, I'm sure that the other folks on the mailing list would
like to hear from you. If you want to do private mail, mail to
dlr@daver.uu.net or george@wombat.uucp. If you do want your comments
to go to the list, mail to pc532@daver.uu.net.

I spent some time on the telephone today with one of the upper
management folks at National. I'm going to try to cut a deal with them
that would (hopefully) reduce the cost of these boards/silicon
substantially. No promises, and nothing will be done for at
least two weeks ( he is off early next week on an overseas trip).

Software is the key issue, as normal. How do we get Unix to you,
in the form you want it, for as little as possible? People have
expressed an interest in BSD, SLIP, TCP/IP, V.3.2, X and a few
other random letters that I have probably forgotten. I have a binary
license for V.2, which may extend to a severely broken V.3.0.
I will be talking to NS about this in detail when we meet, but if
any of you have more ideas, I would like to hear them.

Minix is a real possibility, and would be a *real* screamer on the
532.

For those that want to do additional add-in cards, drop me a line, and
we can talk about it some more. One such card would be a high-res graphics
card with some level of X running on the local processor.

One of the key design issues of this board was to provide for a high
speed multi-master bus. This allows experimentation with partioning
software tasks, yet without the traditional sacrifices that multi-processor
implementations impose (read: $$$).

Anyway, that's it for now. More as it comes: keep that email coming!

Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From ditka!kls Sat Nov 18 01:52:08 1989
Flags: 000000000000
Subject: Mach, anybody?
To: pc532@daver.uu.net
Date: Sat, 18 Nov 89 1:52:38 PST
X-Mailer: ELM [version 2.2t PL7]
From: kls@ditka.UUCP (Karl Swartz)

> management folks at National. I'm going to try to cut a deal with them
> that would (hopefully) reduce the cost of these boards/silicon
> substantially.

That would be great!  Especially the price for the '532 chip itself,
which is still a bit of a shocker.

> Software is the key issue, as normal. How do we get Unix to you,
> in the form you want it, for as little as possible? People have
> expressed an interest in BSD, SLIP, TCP/IP, V.3.2, X and a few
> other random letters that I have probably forgotten.

Rather than straight BSD, Mach and 4.3 BSD would seem to be a better
choice these days.  Maybe somehow I could work on it at the office
(Stanford) and use their source license ...  8-)

But for now, I think just getting the thing working is important.
I'd love to see all the nice goodies, but given a choice of a pipe
dream and cold, hard silicon with an elderly version of System V
I'll take that latter any day.

--
Karl Swartz			 |UUCP	uunet!apple!zygot!ditka!kls
1-408/223-1308			 |INet	zygot!ditka!kls@apple.com
"I never let my schooling get in |BIX	kswartz
the way of my education."(Twain) |Snail	1738 Deer Creek Ct., San Jose CA 95148

From dlr Sat Nov 18 10:15:47 1989
Flags: 000000000000
Date: Sat, 18 Nov 89 10:15:12 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: dlr@daver (Dave Rand)
To: pc532@daver.uu.net
Subject: prices

[In the message entitled "Mach, anybody?" on Nov 18,  1:52, Karl Swartz writes:]
> 
> > management folks at National. I'm going to try to cut a deal with them
> > that would (hopefully) reduce the cost of these boards/silicon
> > substantially.
> 
> That would be great!  Especially the price for the '532 chip itself,
> which is still a bit of a shocker.
It looks like we will be able to get the 532 for <$400, now. 
I'll keep you up to date.

> 
> Rather than straight BSD, Mach and 4.3 BSD would seem to be a better
> choice these days.  Maybe somehow I could work on it at the office
> (Stanford) and use their source license ...  8-)
Could you check into this a little further? I would be willing to pay
for a binary license for BSD, but source (I think) would be way out
of my price bracket!


-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From uunet!pawl.rpi.edu!night Sat Nov 18 11:00:28 1989
Flags: 000000000000
To: daver.uu.NET!pc532
Date: Sat, 18 Nov 89 09:15:49 EST
From: Trip Martin <uunet!pawl.rpi.edu!night>

> So - are we going to make the design commercial? Or at least available?
> That's up to you. What is it worth? Does it have to come with UNIX?
> Does someone want to port Minix to it? How about gcc? What are your
> ideas, now that we have hardware?

I certainly want the design made available.  I already have the chip, and
I want to use it.  I would also like to see the design go commercial.  It 
would simplify getting hardware and software for the machine in the future.
I don't know what's involved there though.  

How much would a Unix license for a machine like this cost (source and/or
binary) ?  Right now my intentions are to port Minix, since I already have 
it, and I know what I'm getting into there.  Gcc would also be a necessity,
since I don't have another compiler available.

My position right now is that I'd like to do this as cheaply (not that
it's going to be particularly cheap) as I can, but I'll spend the money 
if I have to.

BTW, how many people are on the PC532 list now?
--
Trip Martin  KA2LIV                           Trip_Martin@mts.rpi.edu 
night@pawl.rpi.edu                          night@uruguay.acm.rpi.edu
** Murphy's Law of Thermodynamics: Things get worse under pressure **

From dlr Sat Nov 18 11:46:58 1989
Flags: 000000000000
Date: Sat, 18 Nov 89 11:46:30 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: dlr@daver (Dave Rand)
To: pc532@daver.uu.net
Subject: More issues

[In the message entitled "" on Nov 18,  9:15, Trip Martin writes:]
> 
> 
> How much would a Unix license for a machine like this cost (source and/or
> binary) ?  Right now my intentions are to port Minix, since I already have 
> it, and I know what I'm getting into there.  Gcc would also be a necessity,
> since I don't have another compiler available.
I have thousands in my binary redistribution license. My cost per binary
is $250, but this is for V.2. I have not found out what the upgrade to V.3.2
is - I'm sure it will be at least a few thousand more. Source is Many
Thousands. Too rich for me :-(

> 
> My position right now is that I'd like to do this as cheaply (not that
> it's going to be particularly cheap) as I can, but I'll spend the money 
> if I have to.
I agree. Most of the cost  the boards is in the fab, and the chip set.
I'm working on getting the chip set down, but we won't run another set
of boards until we have some people committed to buy them. George will be
posting the BOM for the PC532 so you can see what it will involve.

> 
> BTW, how many people are on the PC532 list now?

Hard to say for sure - there are some local distributions now, but I would
estimate >20. I direct mail to 19 places.

-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From ditka!kls Sat Nov 18 13:40:51 1989
Flags: 000000000000
Subject: BSD source licenses
To: pc532@daver.uu.net
Date: Sat, 18 Nov 89 13:38:01 PST
X-Mailer: ELM [version 2.2t PL7]
From: kls@ditka.UUCP (Karl Swartz)

I wrote:

> > Rather than straight BSD, Mach and 4.3 BSD would seem to be a better
> > choice these days.  Maybe somehow I could work on it at the office
> > (Stanford) and use their source license ...  8-)

And Dave Rand replied:

> Could you check into this a little further? I would be willing to pay
> for a binary license for BSD, but source (I think) would be way out
> of my price bracket!

I may be mistaken but I thought that a Version 7 or later license,
such as your System V (binary?) license, is sufficient license from
AT&T for an equivalent (source or binary) BSD license.  I'm not sure
if you need to sign anything with Berkeley but if you do it's free
or nearly so since BSD was developed with public (DoD) funds.  I know
Mach is free for the asking except for a distribution charge if that
applies.  (You should be able to snag everything over the Internet.

As for the SLAC connection, I'll see what I can find.  Maybe nothing
until after the first of the year due to the holidays, not to mention
the fact that my job there may end on December 31st.  :-(

--
Karl Swartz			 |UUCP	uunet!apple!zygot!ditka!kls
1-408/223-1308			 |INet	zygot!ditka!kls@apple.com
"I never let my schooling get in |BIX	kswartz
the way of my education."(Twain) |Snail	1738 Deer Creek Ct., San Jose CA 95148

From dlr Sat Nov 18 14:15:45 1989
Flags: 000000000000
Date: Sat, 18 Nov 89 14:14:42 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: dlr@daver (Dave Rand)
To: pc532@daver.uu.net
Subject: BSD stuff

[In the message entitled "BSD source licenses" on Nov 18, 13:38, Karl Swartz writes:]
> And Dave Rand replied:
> 
> > Could you check into this a little further? I would be willing to pay
> > for a binary license for BSD, but source (I think) would be way out
> > of my price bracket!
> 
> I may be mistaken but I thought that a Version 7 or later license,
> such as your System V (binary?) license, is sufficient license from
> AT&T for an equivalent (source or binary) BSD license.  I'm not sure
> if you need to sign anything with Berkeley but if you do it's free
> or nearly so since BSD was developed with public (DoD) funds.  I know
> Mach is free for the asking except for a distribution charge if that
> applies.  (You should be able to snag everything over the Internet.
I have so far been unable to find anyone who will sell me a working
32k binary that I can port with. Please let me know if you can
find anyone!

I do intend to use any (and all) BSD sources that are in the public
domain. I have the uunet tapes, and will be using these to good effect.


-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From wombat!george Sat Nov 18 21:44:10 1989
Flags: 000000000000
X-Mailer: Mail User's Shell (6.2 5/11/88)
To: pc532@daver
Subject: boms away
Date: 18 Nov 89 21:39:00 PST (Sat)
From: george@wombat.UUCP (George Scolaro)

Included below is the bill of materials for the 532 AT motherboard.
Some of the features etc of the design are listed below:

- the board is roughly baby AT in size, it is 13 x 8 1/2 inches.
- the schematic capture was done with SCHEMA (from Omation) and the pal
  equations are written for CUPL (from Logical Devices, and formally PCAD).
- the design is conservative, ie it all meets worse case timing at 25 Mhz.
  A lot of work went into the DRAM controller and I feel very confident,
  especially after verifying waveforms on a CRO that the design is solid.
- 8 simm sticks for memory. Either 1 megabit or 4 megabit devices sticks
  may be used, but both banks must be the same type of device, ie no mixing
  of ram stick sizes is supported. The sticks are x 8, ie no parity is
  supported either. I have done parity designs before and rarely are they
  used by unix to do anything other than a panic stop. The main use for
  parity on ram is to determine if the memory is good at power up, and as
  a check for the ruggedness of the dram controller design at prototype time.
  I feel a good memory diagnostic that is run as required is good enough.
- the design uses are very low parts count, since only the essentials are
  on the motherboard.
- the current pcb is a 6 layer board, 2 power layers, 4 signal layers, it
  uses lax design rules, ie 1 trace between 0.1 inch pins, 13 mil traces.
- the current artwork has 1 error, involving a single trace rework. The
  artwork is photoplotted, ie accurate.
- I will gladly send copies of the schematics and pal equations, which will
  all fit on a floppy, plus paper copies of the design, jedec copies of the
  pal equations and the gerber files for the pcb artwork. A small handling
  fee would be appreciated though...
- Regarding fabbing of boards: Volume is inversely proportional to cost, so
  lets see how many people are REALLY interested.

As can be seen from the BOM, the major cost items are the rams, currently
around $130/stick, the CPU/FPU and the PCB. The remainder of the devices
should add up to less than $200 including sockets etc.

Feedback etc?




----------------------------------------------------------------------------------------------------------------
BILL OF MATERIALS    32532 AT BOARD                                   V 1A Sat Nov 18 16:09:57 1989    PAGE   1
----------------------------------------------------------------------------------------------------------------


     ITEM   QUAN.    PART NUMBER           DESCRIPTION                                        REF. DES.        

       1      69                  CAPACITOR,0.1,                                              C1,C10,C11,C12  
                                                                                              C13,C14,C15,C16
                                                                                              C17,C18,C19,C2
                                                                                              C20,C21,C22,C25
                                                                                              C26,C27,C28,C29
                                                                                              C3,C30,C31,C32
                                                                                              C33,C34,C35,C36
                                                                                              C37,C38,C39,C4
                                                                                              C40,C41,C42,C43
                                                                                              C44,C45,C46,C48
                                                                                              C49,C5,C50,C51
                                                                                              C52,C53,C54,C55
                                                                                              C56,C57,C58,C6
                                                                                              C61,C62,C63,C64
                                                                                              C65,C66,C69,C7
                                                                                              C70,C71,C72,C73
                                                                                              C74,C76,C78,C8
                                                                                              C9

       2       1                  CAPACITOR,10PF,                                             C75             

       3       5                  CAPACITOR,10UF                                              C47,C59,C60,C67 
                                                                                              C68

       4       2                  CAPACITOR,50PF,                                             C23,C24         

       5       1                  CAPACITOR,5PF,                                              C77             

       6       1                  CRYSTAL, 3.6864MHZ                                          XTAL1           

       7       1                  DIODE, IN4148                                               D2              

       8       1                  DIODE, IN5817                                               D1              

       9       4                  LIGHT EMITTING DIODE,                                       LED1,LED2,LED3  
                                                                                              LED4

      10       1                  RESISTOR,0.0, 1 Amp Pico Fuse for SCSI                      R3              

      11       1                  RESISTOR,100,                                               R2              

      12       3                  RESISTOR,10K,                                               R1,R4,R5        

      13       1                  RESISTOR,1K,                                                R6              

      14       6                  RESISTOR,22,                                                RES1,RES4,RES5  
                                                                                              RES6,RES7,RES8

      15       2                  RESISTOR,220,                                               RES14,RES15     


----------------------------------------------------------------------------------------------------------------
BILL OF MATERIALS    32532 AT BOARD                                   V 1A Sat Nov 18 16:09:57 1989    PAGE   2
----------------------------------------------------------------------------------------------------------------


     ITEM   QUAN.    PART NUMBER           DESCRIPTION                                        REF. DES.        

      16       4                  RESISTOR,47,                                                RES10,RES2,RES3 
                                                                                              RES9

      17       1                  RESISTOR,4K7,                                               RES12           

      18       2                  RESISTOR,???,                                               R7,R8           

      19       1    300-0000-008  74AS00 - AS TTL QUAD TWO INPUT NAND                         U24             

      20       1    300-0014-001  74ALS14 - ALS TTL HEX INVERTER WITH SCHMITT TRIGGER         U36             

      21       1    300-0032-008  74AS32 - AS TTL QUAD 2 INPUT OR GATE                        U55             

      22       4    300-0062-001  SCSI62 - THE 62 PIN IBM PC/AT BUS CONNECTOR                 CONN12,CONN13   
                                                                                              CONN14,CONN15

      23       2    300-0074-008  74AS74 - AS TTL DUAL D FLIP-FLOP                            U25,U26         

      24       1    300-0139-005  74F139 - FAST TTL DUAL 2 TO 4 DECODER                       U27             

      25       2    300-0174-008  74AS174 - AS TTL HEX D FLIP-FLOP                            U20,U44         

      26       3    300-0258-008  74AS258 - AS TTL QUAD 2 TO 1 MUX, INVERTED TS OUTPUT        U21,U22,U23     

      27       1    300-0646-001  74AS646 - AS TTL OCTAL REGISTERED/TRANS WITH TS OUT         U37             

      28       4    300-1004-004  74AS1004A - AS TTL HEX INVERTING DRIVER                     U1,U12,U15,U16  

      29       1    300-1034-004  74ALS1034A - ALS TTL HEX NON-INVERTING DRIVER               U39             

      30       2    300-1034-004  74AS1034A - AS TTL HEX NON-INVERTING DRIVER                 U13,U17         

      31       4    300-2681-001  SCN2681 - DUAL CHANNEL DUART, 44 PIN PLCC PACKAGE           U42,U46,U49,U53 

      32       1    300-6311-001  74ALS6311 - STATIC COLUMN/PAGE MODE ACCESS DETECTOR         U30             

      33       4    300-TERM-001  220/330 OHM 14 PIN DIP TERMINATOR                           RES11,RES13     
                                                                                              RES16,RES17

      34       1    300-XTAL-001  XTALM - CRYSTAL OSCILLATOR MODULE, 50 MHZ                   U19             

      35       1    304-0256-001  27256 - UV ERASABLE PROM 32KX8, 200 ns                      U38             

      36       8    305-1MEG-001  MSC411024 -  1M X 8 BIT DYNAMIC RAM MODULE, 85 ns           U2,U3,U4,U5,U6  
                                                                                              U7,U8,U9

      37       2    310-0002-001  PAL16L8 - PROGRAM ARRAY LOGIC, B-SPEED                      U31,U34         

      38       1    310-0003-001  PAL16R6 - PROGRAM ARRAY LOGIC, B-SPEED                      U32             


----------------------------------------------------------------------------------------------------------------
BILL OF MATERIALS    32532 AT BOARD                                   V 1A Sat Nov 18 16:09:57 1989    PAGE   3
----------------------------------------------------------------------------------------------------------------


     ITEM   QUAN.    PART NUMBER           DESCRIPTION                                        REF. DES.        

      39       1    310-0004-001  PAL16R8 - PROGRAM ARRAY LOGIC, D-SPEED                      U33             

      40       1    310-0008-001  PAL20L8 - PROGRAM ARRAY LOGIC, D-SPEED                      U14             

      41       1   300-32202-001  32202 - 32000 INTERRUPT CONTROL UNIT, 25 Mhz                U40             

      42       1   300-32352-001  32532 - 32000 SERIES HIGH PERF.  32 BIT BUS CPU, 25 Mhz     U29             

      43       1   300-32381-001  32381 - 32000 SERIES 32 BIT BUS FPU, 25 Mhz                 U18             

      44       1   300-JUMP1-001  JUMP1 - SINGLE JUMPER HEADER                                J3              

      45       2   300-JUMP3-001  JUMP3 - 3 PIN JUMPER                                        J1,J2           

      46       1   300-JUMP4-001  JUMP4 - 4 LOCATION JUMPER BLOCK                             CONN2           

      47       1   300-XTALM-001  CRYSTAL OSCILLATOR MODULE, 20MHZ                            U28             

      48       2  300-74AS832-00  74AS832 - HEX 2 INPUT OR DRIVERS                            U10,U11         

      49       1  300-AIC6250-00  AIC6250 - HIGH PERFORMANCE SCSI PROTOCOL CHIP, 68 PIN PLCC  U35             

      50       1  300-CONN50-001  50 WAY TRANSITION CONNECTOR                                 CONN1           

      51       1  300-DP8490-001  DP8490 - ENHANCED ASYNCHRONOUS SCSI INTERFACE (EASI)        U51             

      52       1  300-IBMPOW-001  IBMPOW - IBM AT POWER CONNECTOR                             CONN11          

      53       8  300-JUMP10-001  JUMP10 - 10 WAY JUMPER BLOCK                                CONN10,CONN3    
                                                                                              CONN4,CONN5
                                                                                              CONN6,CONN7
                                                                                              CONN8,CONN9

      54       8  310-145406-001  MC145406 - HEX LINE DRIVER                                  U41,U43,U45,U47 
                                                                                              U48,U50,U52,U54


-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george)

From dlr Sun Nov 19 10:57:59 1989
Flags: 000000000001
Date: Sun, 19 Nov 89 10:56:46 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: dlr@daver (Dave Rand)
To: pc532@daver.uu.net
Subject: forwarded mailing

[In the message entitled "pc532 - Minix Articles" on Nov 19,  3:58, John L. Connin writes:]
> 
> Hello world:
>  
> I just search approximate 1700 comp.os.minix articles I have on-line
> for references to NSC ports.  I found 4 articles which are attacted
> to this message.
> 
> If there is a serious interest in porting Minix to the pc532 it
> would be prudent to contact AST (ie Andrew S Tanenbaum, the author of
> Minix) to get a definitive handle on all NSC-Minx activity through out 
> the world.
> 
> BTW: I am _very_ familar with the internals of Minix having ported it
> to the i286 in protected mode.  At this point the code, except for
> the file-system, is highly redesigned but that another story.
> 
> IMHO it would be prudent to seriously consider a Minix port for
> the pc532.  Yes, I know some believe it is a toy OS.  However,
> I submit that it is a damm good Version 7 clone, and will
> shortly be POSIX compatible.  As implemented the only draw-back
> that I can see is that the file-system is single-threaded.
> If my memory serves me correctly, I believe a couple of people
> have indicated on comp.os.minix that they have implemented  
> multi-thread file-systems.
> 
> One last thought, Minix supports RPC networking (inter-task communication)
> using Amoeba tasks (based upon the Amoeba operating system).  On the 
> surface Ameoba client/server tasks might be an interesting way to 
> implement multi-master communcation.
> 
> Not to muddy the waters, but it just occured to me that the Amoeba
> Operating Sytem (full-source code) _might_ be a reasonable consideration.
> Again AST is the primary contact to explore this possibility.
> 
> If there is an interest I can post the Amoeba documentation that
> comes with Minix -- good overview.
> 
> best regards,
> tarpit!manatee!johnc
> 
> 	-----------------------------------------------------
> 
> From: Captain-Magic@cup.portal.com (Randy Captain-Magic Holcomb)
> Newsgroups: comp.os.minix
> Subject: Minix for NS 32000
> Message-ID: <20245@cup.portal.com>
> Date: 9 Jul 89 04:19:05 GMT
> 
> In one of the Minix Information sheets it indicates that Minix was ported to
> a National Semiconductor Micro, namely the 16032. Was it ported on a specific
> platform? Would the 16032 version be portable to the NS 32000 family? Is it
> worth doing?
> 
> Randy Holcomb (Captain-Magic@cup.portal.com)
> From: culberts@hpccc.HP.COM (Bruce Culbertson)
> Newsgroups: comp.os.minix
> Subject: New National 32000 Minix Port
> Message-ID: <6910003@hpccc.HP.COM>
> Date: 21 Jul 89 21:32:14 GMT
> 
> I have recently finished porting Minix to a computer I built based on a
> National 32000 Series chip set.  I am not the first person to port Minix
> to the 32000; a group at the Univerity of Warwick reported their port
> well over a year ago.  My port is independent of theirs (I think
> re-inventing the wheel is excusable if you have a good enough time doing
> it).  The Warwick group reported that their port was fairly
> straight-forward.  My port may be the first to make significant use of a
> paging memory management unit.
> 
> Each process on my system runs in its own protected linear virtual
> address space.  The user address spaces are assembled from one kilobyte
> pages of physical memory which, in general, are not contiguous.  A user
> space can grow as large as 16 megabytes, assuming the computer has
> sufficient physical memory.  Because my computer will rarely be used by
> more than one user (me!), and because I expect its memory to be ample, I
> did not think virtual memory would be worth the added overhead.
> Nevertheless, it might be an interesting exercise to implement virtual
> memory in the future.
> 
> Building, forking, and dismantling memory spaces are new services
> provided by the system task in the kernel.  Free lists are kept of dirty
> and clean pages.  Pages which are reclaimed when processes exit are
> placed on the dirty list.  The idle task, which is now a genuine task
> with priority below user processes, writes zero's into dirty pages and
> moves them to the clean list.  Code and initialized data are loaded into
> dirty pages; BSS and stack pages are allocated from the clean list.
> 
> I used copy-on-write to implement fork.  This creates the illusion that
> a user space has been duplicated when, in fact, no user pages have been
> copied.  When a process forks, a new page table is created with pointers
> to the same pages that comprise the parent's address space.  At the same
> time, all pages in the two spaces are set read-only.  When a process or
> the operating system tries to write to a copy-on-write page, a page
> fault is generated.  The page fault handler, after verifying that a
> copy-on-write page is being written, copies the page and sets it
> writable so that the process will have a private copy to modify.  Each
> physical page has a reference count which records the number of virtual
> spaces currently containing the page.  When a process forks, its pages
> have their reference counts incremented.  When an address space is
> reclaimed following an exit or exec, its pages have their reference
> counts decremented.  The reference count of a page is also decremented
> when the page is copied due to a copy-on-write fault.  When a reference
> count drops to zero, the corresponding page is freed and placed on the
> dirty page list.  Pages containing code remain read-only; signals are
> generated when processes try to write them.  No pages contain both code
> and data.
> 
> Stacks are always created at the high end of address spaces, leaving the
> maximum possible space for stack growth and growth due to break system
> calls.  When page faults occur near the lower extent of a stack, the
> system allocates pages to grow the stack and restarts the process.  No
> chmem command is needed.
> 
> One change I made simplified the memory manager process and also helped
> eliminate the bound on environment and argument space.  It could be
> implemented in standard Minix, but would require all commands to be
> relinked.  When processes exec in my system, the environment space is
> copied directly into the new address space and is relocated by the C
> runtime startoff routine (crtso.o) in the new process.  If the exec
> library routine fills its fixed size buffer, it allocates space on the
> heap and starts over building the environment.  In standard Minix, the
> environment is copied into a fixed size buffer in the memory manager,
> where it is relocated before being copied to the new process.
> 
> I designed my computer and posted the design to comp.sys.nsc.32k several
> months ago.  It uses a 10MHz 32016 CPU, and has a floating point unit in
> addition to the paging MMU.  Memory is expandable in increments of 2
> megabytes.  I use a SCSI hard disk and an IBM/PC compatible floppy disk.
> There are several UART's for attaching terminals.  I cannot resist
> making a brief plug for National.  Their 32000 series is cleaner,
> friendlier, and easier to use than its more popular competitors.  Best
> of all, a complete chip set with MMU, FPU and documentation, can be
> purchased for less than $100.
> 
> I am using the GNU C compiler and an assembler and linker I wrote.  My
> assembler and linker are available through the archive which is
> occasionally advertised on comp.sys.nsc.32k.
> 
> Bruce Culbertson (culberts@hplabs.hp.com)
> From: cagney@chook.ua.oz (Andrew Cagney - aka Noid)
> Newsgroups: comp.os.minix
> Subject: NS32000 re-port (attn John Vaudin)
> Message-ID: <533@sirius.ua.oz.au>
> Date: 12 Sep 89 01:51:05 GMT
> 
> John,
>         I've being trying to send you mail for about a month now
>         but the address I have seems to be broken.
> 
> Any way:
> 
>         Your version of NS32000 MINIX now runs on a single processor
>         leopard. Notable changes:
>                 1. Uses coff images
>                 2. Is able to map a graphics board into a processors
>                    address space so that graphics images can be displayed.
> 
> Disclamer:
>         I was not directly responsible for the actual porting work.
>         That was done by several others.
> 
>                                         Andrew Cagney
>                                         cagney@cs.ua.oz.au
> From: dme@doc.ic.ac.uk (Dave Edmondson)
> Newsgroups: comp.os.minix
> Subject: Wanted: information on NatSemi ports of Minix
> Message-ID: <DME.89Oct31142405@gould.doc.ic.ac.uk>
> Date: 31 Oct 89 14:24:05 GMT
> 
> 
> 	I am interested in hearing from people who have done work with
> Minix on the National Semiconductor processors (16032 et al),
> particularly anything done with Whitechapel MG-1 workstations.
> 
> dave.
> --
> Dave Edmondson.                                 Department of Computing,
>      <dme@doc.ic.ac.uk>                         Imperial College,
>      <dme@cc.ic.ac.uk>                          180 Queen's Gate,
>                                                 South Kensington, London.
>  ``If you have A and you have B you can say A and B, but so what ?''
>                                                 --  Ruy de Querioz
> Executing "cat 5080" as root.
> 
> 

-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From dlr Sun Nov 19 11:00:32 1989
Flags: 000000000000
Date: Sun, 19 Nov 89 10:58:27 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: dlr@daver (Dave Rand)
To: pc532@daver.uu.net
Subject: forwarded mailing

[In the message entitled "Expressions of Interest" on Nov 19, 12:00, John L. Connin writes:]
> 
> 
> 
> Regarding expressions of support (ie. money on the table $$ :-)), I
> suspect that the interested audience accessible via comp.nsc.32k
> is quite limited.  In general, during the 1 year that I have been
> reading news, I have seen very little meaningful discussion
> related to hardware projects.
> 
> Anyway, I thought it might be useful to briefly list ways
> that immediately come to mind which might be explored to
> attract a larger target audience and/or exploit the design.
> 
> In no particular order:
> 
> 1).  Shareware:  Like software, except the distribution contains
>      overview, theory of operation, schematic, net list, bill of
>      materials, pcb-design, and an offer to purchase a blank
>      PCB (possibly kit) which are available from time to time
>      subject to demand.
> 
>      I have only seen one example of this -- if my memory serves
>      me correctly a memory board design (fuzzy, but perhaps
>      Lucas memory board for Amiga).  It was post on usenet
>      perhaps a year ago.  I know I have a copy of it stuffed away
>      somewhere, but could not find it this morning.
> 
> 2).  Publish an article in MicroC, Circuit Cellar Ink, or Radio-Electronics
>      Again if my memory serves me correctly, Dave Rand knows the
>      ropes having published design articles in MicroC.
> 
> 3).  A National Semiconductor supported demo/evaluation board kit
>      to showcase the 532 family either by a) explicit involvement
>      such as NSC offering it as a evaluation kit, or b) a back-channel
>      approach were NSC remains anonymous but uses it leverage to get
>      media attention and thereby 532 publicity.
> 
> 4).  A for-profit sub-chapter S corporation which is totally run and
>      directed by the founders via email.  In broad strokes, the idea
>      being:
> 
>         o The founders being those hard-core people (but less than
>           32 by number) who are willing to put money on the table up
>           front AND who are hopefully strong hardware/software
>           contributors to future efforts ( hopefully, includeing an
>           account, lawyer, marketing/sales in addition to technical
>           types).
> 
>         o That in turn for capital a contribution to found the company
>           each investor (founder/shareholder) receives a) X shares
>           of stock and b) a pc532 pcb, and c) if he so desires
>           part-time employment by the company.
> 
>         o That available funds (from capital contributions, sale
>           of kits to non-founders, and possible latter secondary
>           stock sales) be used to develop related hardware / software.
>           That is for the foreseeable future the profit from all
>           transactions be re-invested (ie. bootstrap until at least a
>           full and robust product is in place).
> 
>         o Until profitable, that all employees and consultants to the
>           company be compensated in stock based upon some agreed formula
>           (eg. time, value delivered, hybrid).
> 
>         o  etc...
> 
>      BTW: the benefit of a for-profit subchapter-S corporation is that
>      company losses flow through to the owners of the corporation
>      and thus can be used a personal federal income tax deductions.
> 
> 
> Not that I would expect to get rich, but personally I find item 4)
> above really intrigueing -- a geographicly distributed electronicly
> managed and run company wherein ownership is in proportion to voluntary
> but meaningful services contributed.
> 
> 
> Just some food for thought..
> 
> Best regards,
> tarpit!manatee!johnc
> 
> 
> 
> 
> 

-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From dlr Sun Nov 19 11:16:02 1989
Flags: 000000000000
Date: Sun, 19 Nov 89 11:14:02 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: dlr@daver (Dave Rand)
To: pc532@daver.uu.net
Subject: good ideas

Just a reminder - send your contributions to:
pc532@daver.uu.net

Send requests (additions/deletions) to:
pc532-request@daver.uu.net


[In the message entitled "forwarded mailing" on Nov 19, 10:58, TO: pc532@daver.uu.net writes:]
> 
> [In the message entitled "Expressions of Interest" on Nov 19, 12:00, John L. Connin writes:]
> > Anyway, I thought it might be useful to briefly list ways
> > that immediately come to mind which might be explored to
> > attract a larger target audience and/or exploit the design.
> > 
> > 2).  Publish an article in MicroC, Circuit Cellar Ink, or Radio-Electronics
> >      Again if my memory serves me correctly, Dave Rand knows the
> >      ropes having published design articles in MicroC.
>From my experience, I would say that this is not a effective way to get a
significant number of people involved in a project. Not many people want
to build a system as complex as a 532 board (or even an 016 board :-)
The only reasonable way to do this is have the boards and software
available at publication time.

This was done (in Byte) quite effectively a few years ago, with the
Definicon DSI-32 design.

> > 
> > 3).  A National Semiconductor supported demo/evaluation board kit
> >      to showcase the 532 family either by a) explicit involvement
> >      such as NSC offering it as a evaluation kit, or b) a back-channel
> >      approach were NSC remains anonymous but uses it leverage to get
> >      media attention and thereby 532 publicity.
I am trying 3a and 3b now. No promises. National sounds slightly interested,
but the 532 has been defocused due to the NS32GX32. FYI, the 16 port serial/
Ethernet card can use the GX32 or 532.

> > 
> > 4).  A for-profit sub-chapter S corporation which is totally run and
> >      directed by the founders via email.  In broad strokes, the idea
> >      being:
While this sounds like and interesting idea, I wonder if it can be
accomplished. Does anyone have any experience in forming such a venture?
Are you interested?


-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net


From uunet!nac.no!hsr.uninett!jensen Mon Nov 20 02:59:04 1989
Flags: 000000000000
Date: 20 Nov 89 10:25 -0800
From: "Tarjei T. Jensen" <uunet!nac.no!jensen%hsr.uninett>
To: <pc532%daver>
Subject: pc532

My reason for wanting something like a pc532 is that I want something that will
enable me to have a good time (read: runs Unix or equivalent). I would
probably be happy with a 32016 board, since I'm very keen on memory management
(read: catching wild pointers). But I'd very like to have something like the
pc532 (preferably with a decent os).

I'm amazed that National haven't managed to make a hobbyist board before. It
seems like a very effective way of making people familiar with the processors
in addition to the possibility of selling the kit in large numbers to VARs.
Finally they would get a lot of people porting software to their machines (and
os). I don't think one could underestimate the selling power of having tcp/ip,
nfs and the standard utilities available on a computer (without it costing both
arms and legs). One of the nice things about SUN is that you get a nice
standard kit with the os.

The GNU utilities should be no problem, they already have a 32032 machine
description. Perhaps someone could talk National into donating som 32532 kits
to FSF; that should improve support for that processor.

I'll be happy to buy a pc532 board if I'm still in employment after Xmas (My
current job is of a very temporary nature and I really need a washing machine
first).
----------
    Tarjei T. Jensen - if it isn't broken, fix it anyway.
    jensen%hsr.uninett@nac.no

From voder!nsc!dtg.nsc.com!des Mon Nov 20 09:01:43 1989
Flags: 000000000001
Date: Mon, 20 Nov 89 08:59:16 PST
From: voder!nsc!dtg.nsc.com!des (Desmond Young)
To: pc532@daver.uu.net
Subject: MINIX/ TCP-IP

Guday,
  as a starter, MINIX is a suitable OS for the pc532. It is simple, cheap
and basically functional.
  I have gnu CC, and Bruce Culbertson's as/ld for the 32K, and am starting
a port of MINIX to the 332/32382. I would much rather do it for the 532, but
I am starting now, so do not want to wait around forever for hardware.
  BTW, I ported Phil Karn's KA9Q to MINIX on the PC, so I have TCP-IP
running (slowly :-)). I could easily do a port to the pc532 Ethernet card,
and do a real job this time. Count me in as volunteer effort. The main
problem with MINIX-PC was the limited address space (64K text). This would
not exist on MINIX-532, so we could have a real port.
  Des.
Reply:  des@gpo.nsc.com, or des@dtg.nsc.com
       {decwrl,hplabs,sun,pyramid,amdahl}!nsc.com!gpo!des
Des Young, M/S D3645 National Semiconductor, Santa Clara
The light at the end of the tunnel was only a burglar's torch - J.Buffet.

From uunet!mac.dartmouth.edu!Steven.D.Ligett Mon Nov 20 13:09:33 1989
Flags: 000000000000
Date: 20 Nov 89 10:29:58
From: uunet!mac.dartmouth.edu!Steven.D.Ligett
To: daver.uu.NET!pc532
Subject: Memory

1.  80 ns 1 meg by 8 SIMMs are about $80 each now.  

Largely due to Macintosh demand.  I make my own 1 meg by 8 "DIP SIMMs", but
it's hardly worth it any more - last time I bought legitimate (i.e. factory
built) Samsung SIMMs, they were $81 each.

2.  From "boms Away":  "Either 1 megabit or 4 megabit devices sticks may be
used, but both banks must be the same type of device, ie no mixing of ram
stick sizes is supported."

How hard would it be to remove (or reduce) this resriction?  If the lower bank
is 4 meg SIMMs, why can't the upper be 1 megs without anything noticing?  Is
it integral or peripheral to the Dram controller design?  I know I just said
above that memory is cheap, does anyone else think this is worth worrying
about?  I do have to admit to using 256k SIMMs as coffee stirrers.

From wombat!george Mon Nov 20 20:59:59 1989
Flags: 000000000000
X-Mailer: Mail User's Shell (6.2 5/11/88)
To: pc532@daver
Subject: Re: Memory
Date: 20 Nov 89 20:56:52 PST (Mon)
From: george@wombat.UUCP (George Scolaro)

[In the message entitled "Memory" on Nov 20, 10:29, daver!uunet!mac.dartmouth.edu!Steven.D.Ligett writes:]
> 
> 1.  80 ns 1 meg by 8 SIMMs are about $80 each now.  

That's certainly very cheap. I hadn't realized the prices had fallen that
low, so quickly. All the better!

> 2.  From "boms Away":  "Either 1 megabit or 4 megabit devices sticks may be
> used, but both banks must be the same type of device, ie no mixing of ram
> stick sizes is supported."
> 
> How hard would it be to remove (or reduce) this resriction?  If the lower bank
> is 4 meg SIMMs, why can't the upper be 1 megs without anything noticing?  Is
> it integral or peripheral to the Dram controller design?  I know I just said
> above that memory is cheap, does anyone else think this is worth worrying
> about?  I do have to admit to using 256k SIMMs as coffee stirrers.
						^^^^ lead free solder??

It is a bit messy, since the size of the dram devices selects the page size
comparator address lines to check. You could probably cut & slash a trace or
so and force the page size to the smallest of the 2 devices, ie force the
hard- ware to think it has 1 megabit devices. You would have to changed a
couple of address lines going into the DRAM address mux, it is currently set
up to enable the largest possible page size for the selected DRAM device.
This gives a page size = 1024*4 = 4k bytes for 1 megabit and 8k bytes for
4 megabit devices. Since the 532's mmu has 4k byte pages for mapping, and
refresh breaks the page every 30 odd usec, this would hardly hurt
performance. The hardware does 2 refresh cycles every 30 usec to reduce the
page break hit (the most I could fit in the DRAM control state machine, a
PAL16R8).

regards,

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george)

From dlr Tue Nov 21 20:00:08 1989
Flags: 000000000000
Date: Tue, 21 Nov 89 19:59:15 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: dlr@daver (Dave Rand)
To: pc532@daver.uu.net
Subject: SCSI multi-master question

[In the message entitled "SCSI multi-master question" on Nov 21, 18:19, John L. Connin writes:]


Regarding the multi-master SCSI bus, would it be possible / reasonable
to extend it to have  8 / 16 / 32 bit wide data path ?

Could the SCSI bus be paralleled with something as simple as 3 memory
mapped or io port connected 8-bit wide transceivers ?

Sorry, I do not have a DP8490 data sheet as yet.


The reason I ask is I have the feeling that after time an 8-bit
data path will begin to feel restrictive.  By way of illustration
consider the contrast with the EIAS bus which should be generally
availble in the i386/i486 motherboard market within the next
6 - 12 months.

To amplify further, see Mylex advertizement on page 47 in the
December issue of Mips magazine and a related article beginning
on page 62.  Mylex is pushing their new 32-bit peripherals
(shortly to be EIAS compatible) which include:

        o SCSI cached disk subsystem           - 32 bit bus interface.
        o Buffered ethernet network interface  - 32 bit bus interface.
        o Graphics controller (TI 34020 based) - 32 bit bus interface.

Best regards
johnc








-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From dlr Tue Nov 21 20:01:31 1989
Flags: 000000000000
Date: Tue, 21 Nov 89 20:00:14 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: dlr@daver (Dave Rand)
To: pc532@daver.uu.net
Subject: Amoeba

[In the message entitled "Amoeba" on Nov 21, 18:21, John L. Connin writes:]


Enclosed below is the "net.man" from Minix.

I am posting it to the pc532 mailing-list for the following reasons:

 1) It describes an interesting IPC based upon a RPC protocol
    which can be used between processes residing on one processor,
    and/or multiple processors residing a multi-master bus or
    communications network.

 2) The possibility of the "Amoeba Operating System" as candidate
    OS has not been mentioned (see text below).  I do not know
    the answer, but it may be possible to obtain a source code
    license for a modest fee.

 3) Minix, a candidate OS, does support Ameoba IPC protocol.

Best regards,
johnc

        -----------------------------------------------------


                        MINIX NETWORKING

1. INTRODUCTION
     Network software can be divided into two general categories differing
in the way the software is integrated into the operating system and the user
software.  When networks first developed, they were used over slow wide-area
links (56 kbps or less), so the designers' main concern was using the 
available bandwidth efficiently.  Programmer convenience was not considered.  
Later, as higher bandwidth networks became widespread (especially local area 
networks, such as Ethernet), the focus changed from worrying about bandwidth 
utilization, to worrying about making the network interface convenient for 
the programmers.  This evolution is very similar to the evolution from 
assembly language programming, where the machine came first, to programming 
in high level languages, where the programmer came first.

     Networks of the first type of are said to be connection oriented, and use
what are called sliding window protocols.  All older networks, especially
wide area networks, are of this type.  Some of the better known protocols are
X.25, TCP/IP, and OSI.  Networks of the second type are connectionless, and
use what is called remote procedure call (RPC).  Virtually all modern 
distributed operating systems are based on this concept.  Some well-known 
examples are the work of Xerox PARC [1], the V kernel [2], and Amoeba [3-9].
While it is certainly possible to build RPC on top of a connection-oriented
protocol, this approach is inefficient compared to building the RPC on top of
the bare network.  For an introduction to connection-oriented protocols, RPC,
and networking in general, see [10].

     Networking in MINIX is based on RPC.  Briefly summarized, communication
between two processes works as follows.  One of the processes, called the
server, has some service to offer, such as a file storage.  The other process,
the client, wants to use this service.  The interface to the service consists
of a collection of procedures that the client can call.  In the case of a file
server, the procedures might be CREATE_FILE, RENAME_FILE, READ_DATA,
WRITE_DATA, and so on.  These are library routines available on the client's
machine.

     When the client calls one of these procedures, the procedure sends a
message to the server containing the procedure name and its parameters.  The
procedure then blocks waiting for the reply.  When the message gets to the
server, it is decoded there and executed.  The reply is sent back to the
calling procedure on the client's machine, which then returns the results to
the caller.  From the programmer's point of view, having remote services in the
network essentially means that there is a new collection of procedures to 
call.  The programmer is not burdened with concepts like opening connections,
sending data, or thinking in terms of acknowledgements, all of which are
needed in the connection-oriented model.  Nor is the network software burdened
with having to manage connections.  

     In effect, RPC is based on the abstraction of the procedure call, whereas
connection-oriented networks are based on the much lower-level concept of 
making the network look like an input/output device.  While at first glance it 
might seem that connection-oriented networking could be made to fit with the
UNIX/MINIX concept of a pipe, pipes are set up in a very different way (by a
common ancestor), and fit very poorly to the most common style of local area
network programming, where the client has a request and the server gives a 
response.  With wide area networks, this kind of interaction is painfully slow,
due to the low bandwidth, so the only services generally available are mail
and file transfer, which are batch-oriented.  MINIX networking has been
designed for interactive use on high performance local area networks, so for
this reason, RPC has been chosen over the older connection-oriented style.

     In particular, MINIX networking has been designed to be compatible with
the form of RPC used in the Amoeba distributed operating system [3-9].  Not
only have the concepts and the implementation been well tested, but the
performance is exceedingly good.  For example, for doing file transfers,
something that connection-oriented protocols are supposed to be good at,
Amoeba running on two Sun the
> performance is exceedingly good.  For example, for doing file transfers,
> something that connection-oriented protocols are supposed to be good at,
> Amoeba running on two Sun 3s achieves triple the throughput of TCP/IP running
> on the same hardware.  Data transfers between two Zenith Z-248s running
> the Amoeba RPC on MINIX have been measured at 165 kbytes/sec, almost as fast
> as TCP/IP transfers between two Sun 3/50s.  Considering that the Suns are
> two times as fast as the Z-248s and the network software is 100% CPU
> limited (doubling the CPU speed doubles the throughput), this is a strong
> argument for the Amoeba RPC.  As a final statistic, the RPC throughput between
> a client and server located on the same Z-248 is 1.5 Mbytes/sec, an extremely
> high figure for this class of machine, and much better than what Suns and VAXes
> normally achieve locally, despite their greater CPU power.  In conclusion,
> although RPC was chosen for its elegance and ease of use, it turns out that it
> also has ed 
operating system that was developed at the Vrije Universiteit in Amsterdam and
is now being used there, at the Centre for Mathematics and Computer Science in
Amsterdam, and a number of other research centers in several countries. It is 
written in C and currently runs on a wide variety of microprocessors and 
minicomputers (including the Sun 3, various other MC68020 systems, the PDP 11 
and the DEC Vax).  Note that Amoeba is a complete operating system, just like 
UNIX, MINIX or VMS.  The only relation between Amoeba and MINIX is that MINIX 
networking uses the Amoeba RPC protocols.  Other than that they are quite 
different in structure, funtionality, and goals. Amoeba was designed to run 
on systems consisting of dozens of processors, and yet give the programmer the
illusion that it is a traditional single-CPU time sharing system.  For more
information about Amoeba, see the references.


2. OBJECTS
     Amoeba is an object-oriented system, and to a considerable extent this
orientation is reflected in the protocol.  As a consequence, MINIX also
acquires a certain object-orientation.  Very briefly, an object is a programmer
defined abstract data type that has well-defined operations on it.  As an
example, a file server could define file and directory objects, and provide
operations to read and write the file objects, and insert files in, and delete
files from, directory objects.  Clients can perform these operations by doing 
RPCs with the file server.  Henceforth we will adopt the Amoeba terminology and
call these RPCs "transactions."  A transaction consists of a request message
>From a client to a server, followed by a reply message from the server back to
the client.

     It is up to the writer of each server to decide what kinds of objects the
server will support and what operations will be available on them.  The 
structure of the system guarantees that clients can only perform the 
operations provided by the server.  This style of networking is intended to 
force constraints on programmers, just as high-level languages force 
constraints on former assembly-language programmers.

     Objects are normally protected by capabilities, which are currently 128-
bit numbers, although in the the next version of Amoeba (Amoeba 4.0) this will
become 256 bits.  When a client asks a server to create an object, the server
returns a capability for the object.  This capability must be presented by the
client to perform subsequent operations on the object.  In Amoeba, capabilities
are protected crytographically.  Since the MINIX kernel, unlike the Amoeba
kernel, was not designed from scratch as a distributed system, the protection
aspects in MINIX are not fully implemented.

     A capability has 4 fields, described below.  These fields are important
because they appear in the Amoeba and MINIX message headers.

	Port:	48-bit number used to identify the server owning the object.
	Object:	24-bit number used by the server to identify the object
	Rights:	8 bits telling which operations are allowed
	Cksum:	48-bit checksum to prevent tampering with the capability

The "port" field is a (random) 48-bit number used for addressing.  Any 48-bit
number can be used as a port.  In some situations, an ASCII string can be used
as a port, with the first 48 bits taken as the port number.  All messages
in Amoeba and MINIX are sent to ports, not to machine addresses.  The mapping
of ports to machine addresses is done deep down in the system, and is of little
concern to the average programmer.  Thus: a port uniquely identifies a server
and provides a logical address to which all messages for the server are sent.

     The remaining three fields are called the private part of the capability.
In theory, each server can use them any way it wants to.  In practice, to
prevent total chaos, all existing servers adhere to the following conventions
(just as most UNIX programs adhere to the convention that certain files contain
ASCII characters with a line feed at the end of each line).  The "object" field
is used by the server to identify the specific object being accessed.  For
example, when a file server created a new file on behalf of a client, it could
put the i-node number of the new file in this field, so that when the client
later used the capability, the server could tell which file was being 
addressed.  The field is 24-bits long, providing each server with 16 million
object identifers.

     The "rights" field contains a bit map for up to eight protected
operations.  Each bit controls permission to perform one operation.  Thus a
file server could allocate bit 0 for READ_DATA, bit 1 for WRITE_DATA, bit 2 for
APPEND_DATA, bit 3 for DELETE_FILE, and so on.  When a capability arrives from
a client, the server checks to see if the bit corresponding to the relevant 
operation is on.  If it is not, the operation is rejected.  In this way, a user
can create a file, ask the server to turn off the WRITE_DATA and DELETE_FILE
bits, and then give the capability to another user.  This new user cannot
perform WRITE_DATA and DELETE_FILE operations, but can perform the operations
whose bits are turned on.

     A moment's thought will reveal that the above protection scheme is
worthless if users can turn the rights bits on and off by themselves.  To
prevent this, the "cksum" field is used.  When creating a new object, the
server simultaneously creates a random number and stores it in its internal
tables (e.g., in the i-node).  It then combines the rights bits and the
random number, and passes the result through a one-way cryptographic function.
The result of this function is put in the cksum field.  When a capability
comes in from a client, the server uses the object number to locate the
original random number.  It then combines it with the rights bits present in
the capability, and runs the result through the one-way function.  If the
result disagrees with the cksum field, the capability is considered invalid, 
and an error return is sent back.  In this way, users who change the rights 
bits will simply invalidate their capabilities.  Attempts to break the scheme 
by finding an inverse to the one-way function can be handled by choosing a
cryptographically strong one-way function.  Brute force does not work either,
as picking cksums at random will require, on the average, 2**47 attempts to
guess the 48-bit cksum.  Since a null transaction over a 10 Mbit/sec Ethernet 
using SUN 3/50s takes about 1.4 msec, about 3000 years are needed to perform 
the search.  Furthermore, it is easy enough to program a server to artificially
increase the transaction time to 1 sec after 10 unsuccessful attempts have
been made, thus increasing the mean search time to 3,000,000 years.


3. OVERVIEW OF TRANSACTIONS
    To summarize what we have covered so far, the normal style of networking in
MINIX (and Amoeba) is to structure dialogues in terms of clients and servers.
Each server manages one or more types of objects, and provides operations for
clients to perform operations on these objects.  When a client asks a server to
create an object for it, the server then returns a capability for the object
to the client.  This capability identifies the server, identifies the object,
and tells which subset of the operations the holder of the capability may
perform.  To have an operation performed, the client sends a request message
to the server (with the capability embedded in the message header), and the
server then sends back a reply.  In most cases, the calls to the server are
embedded in library procedures, called "stubs", to encapsulate the message 
passing and hide it from the users.  

      Transactions provide a basis for a large number of user services.
In MINIX, users can use them to build arbitrary services.  Two key services
are provided as standard for MINIX, remote execution and remote file copying.
These services make use of a process called the shell server, or sherver for
short.  The sherver accepts messages from remote (or local) clients, executes
the commands in them, and returns the output.

     Communication is implemented as follows. Each server listens to a
unique 48-bit port.  A client that wants service from the server sends a 
request to that port and blocks until it receives a reply. (If the client 
cannot find anyone listening to the port after a given period, it times
out and returns an error status.)  When the server is ready, it returns a reply
to the client,  which then continues execution. Each transaction is independent
of the previous transactions; there is no connection or virtual circuit.


     Clients must have some way of discovering a server's port.  Under Amoeba 
a directory server is used. The directory server stores capabilities for 
objects and associates them with an ASCII string.  The directory server has a 
well known port.  Under MINIX you make initial contact with a sherver that has
a well known port and then the sherver creates a secret port for all further 
transactions on that machine.

    There are four stub routines in the user library which provide the basic
interface between user processes and transactions.  They are:

	1. getreq() - get request (used by servers to get a request)
	2. putrep() - put reply (used by servers to send reply)
	3. trans() - transaction (used by clients to do a transaction)
	4. timeout() - sets the time limit at which trans() gives up

Getreq() and putrep() are used by servers to get a request from a client and
to send a reply.  A server may not do a getreq() until it has replied to the 
previous getreq().  The call trans() is used by clients to send a request to a
server. It blocks until a reply or a signal arrives, or, if it cannot find a 
server listening to his port, it times out and returns an error code.
The length of the timeout is set using the function timeout().  This timeout
has to do with locating servers, not how long they have to do the work.

     Messages of up to 30000 bytes can be sent between client and server.
This limit will increase to 1 Gbyte in the next version of Amoeba but will
probably remain at 30000 bytes in MINIX due to the small address space of the
IBM PC.  It is possible to provide security so that servers only execute 
remote procedure calls for authorized users. The protection mechanism uses 
capabilities and is discussed in detail in the references.  It will not be
discussed much here.  This protection mechanism is not implemented in the 
remote shell software available with MINIX.  (It requires a directory server, 
among other things. The implementation is left as an exercise for the reader.)


4. SYNTAX AND SEMANTICS OF TRANSACTION PRIMITIVES
     Now we will take a detailed look at the syntax and semantics of the 
library routines for using transactions, followed by some simple examples to 
indicate how the functions are typically used. Remember, that when programming
with transactions, the primitives used in C programs are getreq(), putrep(),
trans(), and timeout().  These can be thought of as "network system calls,"
although they are not implemented quite like that in MINIX.  If you are
building a server, it will typically have a main loop with a getreq() at the
top, a switch in the middle based on some field of the incoming message, and
a putrep() at the bottom.  Furthermore, the server writer will generally also
provide a set of stub procedures that contain trans() calls to access the
server.  The average user will call these library procedures, and will not
make trans() calls directly, although he is, of course, free to do so if he 
wishes.

     Transaction messages always begin with a special header.  The exact
layout of these messages is defined by the Amoeba protocol.  By using this
protocol, MINIX machines can communicate with one another, and with Suns, 
Vaxes, and PDP-11s running Amoeba.  Device drivers have also been written for
UNIX to allow UNIX processes to speak Amoeba, and have Amoeba clients and
servers run on UNIX.  At the Vrije Universiteit, all the Suns, Vaxes, and
PDP-11s that run UNIX have such drivers to communicate with each other and with
machines running Amoeba and MINIX.  It is the local lingua franca, just as
TCP/IP is at some sites.

     The amoeba header is defined in the include file "amoeba.h", which must
be included in all programs using transactions.  The header definition is given
below.  The types used in the header struct are also defined in "amoeba.h".

typedef struct {
	port	h_port;		/* port (i.e., logical address) of the dest. */
	port	h_signature;	/* used for authentication and protection */
	private	h_priv;		/* 10 bytes: object, rights, and cksum */
	unshort h_command;	/* code for operation desired/status returned*/
	long	h_offset;	/* parameter field */
	unshort	h_size;		/* parameter field */
	unshort	h_extra;	/* parameter field */
} header;

     The message header contains the port to which the message should be sent, 
a command/status field for use by the server and space for some parameters to 
go with the command or status.  Let us now look at the four network primitives.
The first one, getreq, has the following declaration:

	unshort getreq(hdr, buffer, size)
	header *hdr;
	char *buffer;
	unshort	size;

The three parameters refer to the header, the buffer, and the buffer size,
respectively.  In a sense, they are analogous to the parameters of the MINIX
READ and WRITE system calls.  The hdr parameter points to a header struct,
which is used to allow the server to specify which port it wants to listen to.
The h_port field of the header must be initialized with the port number.
The buffer parameter is a pointer to a buffer to hold the incoming message.
It can hold a maximum of size bytes, specified by the third parameter.  If 
successful getreq() returns the number of the bytes of data in the buffer that
were actually received.  In addition, the other fields of the header are filled
in by the system.  If an error occurs then it returns a negative error code. 
Possible error codes (defined in "amoeba.h") are: 

	FAILED:	a null port was given or a getreq was attempted before 
		the previous putrep() was done
	BADADDRESS: the buffer pointer and/or size was not valid
	ABORTED: a signal was received
	TRYAGAIN: there were no free transaction slots in the kernel tables

Note that after a getreq(), trans() may be used to communicate with another
server before doing the putrep(). In other words, a server may call other
servers to help it do its job, but it may not process multiple transactions
simultaneously.  (In Amoeba, server processes may contain multiple threads
to allow parallelism, but MINIX does not allow multiple threads per process.)

     The next call is putrep(), used by servers to reply to requests and send
back results and status information.  The declaration is:

	unshort putrep(hdr, buffer, size)
	header *hdr;
	char *buffer;
	unshort	size;

The header returned contains status information, and possibly a new port
(in the h_signature field).  A buffer containing size bytes of data is also
returned to the client.  If successful, putrep() returns the number of bytes 
sent.  The reply message is not acknowledged, so that a successful return
>From this call does not guarantee that the client got the reply.  In general,
it is up to the client to try again if the reply is not forthcoming quickly
enough.  Possible error conditions for putrep() are defined in "amoeba.h" as
follows:

	FAILED: no getreq() was done first
	BADADDRESS: the buffer pointer and/or size was not valid
	ABORTED: a signal was received

     Now we come to the call used by clients to request services and wait for
replies.  Servers can also use this call to request services from other 
servers.  Thus at one instant a process may be acting as a server and at 
another the same process may be acting as a client.  The client call is:

	unshort trans(hdr1, buffer1, size1, hdr2, buffer2, size2)
	header *hdr1, *hdr2;
	char *buffer1, *buffer2;
	unshort	size1, size2;

The call has two independent sets of parameters.  Those with suffix 1 are
used for sending the request message to the server.  Those with suffix 2 are
used for getting the reply.  Both sets have a header, a buffer, and a size.
The two hdr pointers point to structs for message headers.  The first one
contains parameters copied to the outgoing message to the server and the
second one contains space for the data to be copied in from the server's
putrep().  The two buffer parameters are for the outgoing and incoming data,
respectively, and the two sizes tell how large these buffers are.

     After making a trans() call, the client blocks until the message has
been sent, received, processed by the server, and replied to.  Only then can
the client continue execution.  At this point the fields of hdr2 and buffer2
will contain the reply data.  Like MINIX itself, transactions support only this
synchronous form of communication.  Experience has painfully shown that 
asynchronous stream communication is difficult for programmers to deal with.
After all, everything else in programming languages is synchronous.  (Can you
imagine what it would be like to have a procedure call return control to the
caller before having finished its work?)

     If successful, trans(), returns the number of bytes in the reply.  
Possible error codes are: 

	FAILED: a null port was given or the server crashed between doing the 
		getreq and the putrep
	NOTFOUND: the port locate failed to find a server before the timeout
	BADADDRESS: a buffer pointer and/or size was not valid
	ABORTED: a signal was received
	TRYAGAIN: there were no free transaction slots in the kernel's tables

The final network primitive deals with setting timeouts.  When a client first
does a transaction on a previously unknown port, the kernel broadcasts a locate
message to find the server.  It then waits a certain amount of time for a 
server to reply.  If no server replies before the timer goes off, the trans()
fails with NOTFOUND.  The timeout() call allows the client to determine how
long to wait for a server to reply.  After a reply has been received, the
kernel keeps it in a cache, so that locates will not be needed subsequently.
It is important to realize that the timeout relates to locating servers, not
to how much time servers have to perform their work.  The declaration is:

	unshort timeout(time)
	unshort	time;

The function sets the length of the locate timeout in tenths of a second.
The default is 300 (30 seconds). A timeout of 0 means do not time out.
The timeout() call returns the length of the previous timeout. 


5. STRUCTURE OF SERVERS AND CLIENTS
     In this section we will examine typical servers and clients to give an
idea of how they are structured.

5.1 Server structure
     A typical server has the following form:

	/* Declarations needed by the server. */
	header hdr;			/* header for receiving requests */
	char buffer[BUFSIZE];		/* buffer for receiving requests */
	char reply[BUF2SIZE];		/* buffer for sending replies */
	unshort	size, replysize;	/* sizes of the two buffers */
	unshort	getreq();		/* function declaration */
	char *strncpy();		/* string function */

	signal(SIGAMOEBA, SIG_IGN);	/* ignore signals */

	while (1) {

	  /* Have the server listen to a 48-bit port equal to ASCII "MyServ" */
	  strncpy(&hdr.h_port, "MyServ", HEADERSIZE);

	  /* Wait for a request to come in for that port. */
	  size = getreq(&hdr, buffer, BUFSIZE);

	  /* If the size returned is negative then an error occurred. */
	  if ((short) size < 0) {
		handle_error();
	  } else {
		perform_request_found_in_buffer(); /* carry out the work */
		hdr.h_status = OK; 		   /* or whatever */
		putrep(&hdr, reply, replysize);	   /* send reply back */
	  }
	}

If all the information necessary for the request is in the headers then the 
buffers in getreq() and putrep() can be replaced by the value NILBUF and the 
buffer sizes can be replaced by 0.

5.2 Clients Structure
     The structure of a client program is much more variable.  A program that 
deals with the above server might look like this: 

	/* Declarations needed by the client. */
	header	hdr;			/* header used for request */
	char buffer[BUFSIZE];		/* buffer used for request */
	short size;			/* size of the buffer */
	unshort	trans();		/* function declaration */
	char *strncpy();		/* string function */

	/* Initialize server port to "MyServ". */
	strncpy(&hdr.h_port, "MyServ", HEADERSIZE);

	/* Send request to server listening to that port. */
	size = (short) trans(&hdr, buffer, BUFSIZE, &hdr, NILBUF, 0);
	if (size < 0) {
		printf("trans failed %d\n", size);
	} else {
		if (hdr.h_status != OK)	/* nonzero status is an error */
			work_not_done();
		else
			successful_trans();
	}

5.3 Signal Handling
     The semantics of signals with transactions is important for programmers to
understand.  If a client receives a signal while doing a trans(), the signal 
propagates to the server.  If the server is also doing a trans() then it 
propagates again to the next server, and so on.  The aim of this is to request
all servers to terminate their transaction as soon as possible.
 
     If the server receiving the signal is not doing a transaction and not 
already doing a putrep() then the server code must handle the signal.  It may 
choose to catch the signal and send a reply immediately or simply ignore the 
signal.  If it does not catch the signal then it will die since the signal 
propagated is SIGAMOEBA (which is defined as SIGEMT for MINIX).  In this case 
the transaction will fail (with return status FAILED for the client).

     Once the transaction is completed the client process will be signaled.
It in turn must handle the original signal (not necessarily SIGAMOEBA).  The 
exact transaction semantics of Amoeba are not supported under MINIX due to
difficulty in keeping user processes alive until a transaction terminates
after a signal.  Signal propagation does occur, but the client may die before 
a reply comes in.  This should not matter too much for most applications. 
In the next rewrite of Amoeba the syntax and semantics of these functions will
change in non-compatible ways, but this will probably not appear in MINIX.


6. IMPLEMENTATION OF TRANSACTIONS IN MINIX
     Amoeba transactions are implemented in the MINIX kernel as a number of 
kernel tasks. Several alterations were made to the kernel to support these 
tasks, including the addition of an (optional) ethernet driver (for the 
Western Digital EtherCard Plus (TM), also known as the WD1003E) and the 
possibility to specify the size of the stack for kernel tasks on a per task 
basis.  (Amoeba tasks need larger stacks than the other MINIX kernel tasks.)  
There is also an extra system call that is handled by MM.  This is the Amoeba 
system call and is the interface to the kernel.  Special handling of signals is
also provided for in the MM task. 

     There are five kernel tasks for Amoeba.  The first acts as a manager 
which accepts asynchronous events.  Possible events are:

	1. An ethernet packet has arrived
	2. A local signal has arrived
	3. A user task involved in an active transaction has died
	4. A sweep timeout has occurred 

(Locate timeouts are implemented using a counter which is decremented every
tenth of a second by a sweep routine.) Each of the other four tasks manage a 
single user process' transactions.  Thus, a maximum of four processes can
simultaneously do transactions under MINIX.  The number of transaction tasks 
is, however, a constant in an include file and can be increased if needed.

     In the MINIX kernel there is a table which keeps a record of the current 
state of a transaction.  This table is called "am_task" and is declared in the
file "amoeba.c."  This records many things, including, the process number of 
the task doing the transaction, the current state (locating, waiting for a 
reply, waiting for a request, etc.) and the relevant ports and machine 
addresses. 

     The Amoeba network protocol is a stop and wait protocol that guarantees
at most once delivery of a message.  A message consists of the concatenation of
the transaction header with the data in the buffer (if any) given to trans(),
getreq() or putrep().  The transaction code divides messages up into packets 
which fit on the underlying network medium (which is ethernet in the case of 
MINIX).  It then sends over the message fragments and they are reassembled on 
the remote machine before being given to the recipient.

     Each packet begins with an ethernet header (which consists of the source 
and destination ethernet addresses) followed by a 10-byte Amoeba internet 
header containing data about the source and destination processes to ensure
that the message is delivered to the correct process.  The rest of the packet 
is used for sending data.


7. COMPILING THE SYSTEM 
     There are several interesting things you need to know before you can build
a MINIX kernel with Amoeba transactions in it.  First of all, you do not need 
an Ethernet to use transactions.  You can have your clients and servers running
on a single machine.  In this mode, it is possible to write and debug network
software without having a network.  Later, when you move to a real network, the
code will already be fully debugged, as the system itself makes no distinction
between local and remote transactions.  

     Second, the transaction code is quite substantial.  So much so that it
would tend to overshadow the rest of MINIX if it were fully integrated into it.
This fact, combined with the knowledge that not all MINIX users are interested
in networking has led to adding a new top-level directory in MINIX, amoeba.
This directory and its subdirectories contain all the networking code.  If you
are not interested in networking, copy the entire top-level amoeba directory to
a diskette in case you later become interested, and then type

	rm -rf amoeba

This will get rid of all the networking code, and you can continue as usual.
The only thing you will notice is a few #ifdefs in the normal code that relate
to networking; they will all be disabled if you do not specifically enable 
them. 

     Installation of networking is largely auto-configured using the makefiles
provided.  Two new -D entries are used in the mm and amoeba/kernel makefiles:

	-DAM_KERNEL	(used in mm and amoeba/kernel) enables networking
	-DNONET		(used in amoeba/kernel only) single machine networking,
			 in other words, local transactions only

If you use -DAM_KERNEL but not -DNONET, you get full networking and MUST have 
a Western Digital Etherplus card.  To install the makefiles and make other
necessary changes, run the install shell script (amoeba/install)

     If you add a new kernel task of your own then it MUST come between the
Amoeba kernel tasks and the printer task in the file kernel/table.c and should
be numbered relative to AMOEBA_CLASS in the file h/com.h (i.e. The task number
should be AMOEBA_CLASS+1 for the first new task, AMOEBA_CLASS+2 for the second
new task, etc.).  Be sure to set NR_TASKS correctly.

     To compile and install networking, you must follow the steps below 
carefully.


How to Install Amoeba
---------------------

You must do the following important steps carefully.


 1. Make sure that you are in the amoeba directory and that there is plenty
    of free disk space.  Run the command:

	install

 2. Type:  make

 3. When you are instructed to do so, insert a blank diskette and hit return.

 4. Reboot your machine using the new boot floppy.

 5. Test the system.  The directory amoeba/examples contains several programs 
    to test the reliability of transactions.  The READ_ME file in the directory
    gives more details.

 6. If you have an ethernet card then install the network tools.  The directory
    amoeba/util contains utilities for remote shells, remote file copying and
    message sending.  These only work with machines that have Amoeba
    transactions installed.  The READ_ME file there gives more details.


8. NETWORKING UTILITIES 
     There are several utility programs which you may find useful if you have a
network connection.  They are listed below with a brief outline of their use.
Other utilities are possible and reasonably simple to write as shell scripts
that use rsh (remote shell, described below).  The utilities are located in the
amoeba/utilities directory.

8.1 Remote Shell
     One of the main features of MINIX networking is the use of the remote 
shell.  This utility is a server that accepts commands over the network from
clients and executes them.  The syntax of this command is:

	rsh [-bei] <port<command

This program executes the command specified by <commandon the machine with a
sherver (described below) listening to the port <port>, which is an ASCII
string of up to 6 characters.  It is used to generate a unique port name for
the underlying transaction mechanism.

     Normally standard output and standard error from the command are written 
on standard output of the local process.  If the -e flag is specified then they
are kept separate. The -i flag specifies that standard input for the command 
should come from the local process.  The -b flag specifies that the rsh should
be started in the background.  Some examples:

	rsh bozo

starts an interactive shell on the machine running a sherver with port bozo.
Subsequent commands that you type will be fed to the remote shell.  You can
use cd to change to a directory on the remote machine, ls to list files in the
remote directory, and any other commands you want.  In effect, rsh gives you a
simple form of remote login.  Note that to make this work, the remote process
listening on the port bozo must be a shell server (sherver).

     As a second example of rsh, consider

	rsh jumbo cat /etc/passwd

which displays on your screen the file /etc/passwd from the machine running a 
sherver with port jumbo.  The rsh command could also have redirected this 
output to a local file or pipe.

     A slightly more complex example is

	rsh -i freddo 'cat >/usr/ast/junk' </etc/termcap

which runs the command

	cat >/usr/ast/junk

on machine the machine running a sherver with port freddo and takes as input 
the file /etc/termcap from the local machine.  Note that by quoting the
second argument, it is passed as a string to the remote sherver.  If the
command contains magic characters (e.g., *.c) the resulting action depends on
whether the command is quoted or not.  If it is not quoted, the local shell
will expand the magic characters before rsh is even called.  If the command
is quoted, the command string is passed unmodified to the remote sherver,
which then expands it in the directory it is currently working in.

     When you log into a remote machine with rsh, you get a shell having the
uid and gid of the sherver (see below).  To get your own uid and gid, type

	exec su george

assuming that your login is george.  If you have a password, su will ask for
it.  Needless to say, the su program will use /etc/passwd on the remote 
machine.  Do not forget to use exec, as this eliminates the need for an extra
shell.  If you do not need your own uid, don't bother, as it costs memory.

8.2 Shervers
     To enable remote shell operations, it is necessary to have a sherver
running on the destination machine.  Shervers can be started up by:

	sherver <port

assuming that sherver is kept in  /usr/bin.  This program listens to the
port specified and accepts a single request from the program rsh.  It then
executes it with the uid and gid of the sherver.  When it is finished, the
sherver exits.

     The sherver gets its input from a pipe.  This means that it can only do
those things possible with a pipe as input. In particular, signals (e.g., DEL),
EOF (e.g., CTRL-D), and the ioctl system call do not work properly.  Hitting
DEL remotely will kill the sherver.  There is no simple solution, except to
use stty to change your DEL character so that you do not hit it out of habit.

8.3 Masters
     Another useful program is master.  It is started up as follows:

	master <count<uid<gid<command

This program starts up <countcopies of the program specified by <command>
with user id <uidand group id <gid>.  The command may be given parameters.
If at any time the command exits or dies then master will start up a new
invocation of it.  This was designed to work with shervers but has other 
applications as well.  

For example,

	/usr/bin/master 1 2 2 /etc/sherver mumbo

will start a single sherver listening to the port `mumbo' and ensure that
there is always a sherver running.  This sherver will have uid=2 and gid=2,
so that rsh calls to mumbo will be executed with this uid/gid combination.  
It is suggested to start up master in the /etc/rc file of any machine
running shervers. When a sherver finishes executing a command, it exists.
By having master running in the background all the time, every time a sherver
exists, its parent, master, will create a new one.  This mechanism is somewhat
akin to init creating a new login process whenever a shell exits.  Since $PATH
is generally not set prior to executing /etc/rc, master should be specified as
/usr/bin/master (or whatever).


8.4 File Transfer
     The standard MINIX networking provides for file transfer using a shell
script called rcp (remote cp).  The syntax of the call is

	rcp [port!]from_file [port!]to_file 

It can also do local file copy but this is more easily accomplished with cp. 
Here are two examples of rcp usage:

	rcp jumbo!/etc/passwd .
	rcp jumbo!/etc/passwd freddo!/usr/ast/pebble

The first one will copy the file /etc/passwd from the machine running a sherver
with the port jumbo to the file passwd in the current directory. The second one
will copy the file /etc/passwd from the machine running a sherver with the port
jumbo to the file /usr/ast/pebble on the machine running a sherver with the 
port freddo.  Thus it is possible to issue commands on machine A to copy files
>From machine B to machine C.

8.5 Remote Pipes
     It is possible to set up remote pipes using the programs 'to' and 'from'.
The program 'to' reads from standard input and writes its output to the named
port.  Similarly, 'from' reads from the named port and writes to standard
output.  For example, consider the following commands, possibly given on two 
different machines:

	cat F* | sort | to 'port66'
	from 'port66' | uniq -c | sort -n

The first command concatenates files beginning with 'F', sorts them, and writes
the output to 'port66'.  The second commands reads from 'port66' and provides
input to the rest of the pipeline.


9. THE ETHERNET INTERFACE
     The ethernet driver in this version of Minix is for the Western Digital 
Ethercard Plus card, which is also known as the WD1003E. The ethernet 
controller chip on this board is the National Semiconductor DP8390.
If you have a different type of ethernet controller then there are several
things you need to know about the interface between the driver and the Amoeba
transaction layer in order to write a suitable driver for your card.

     There were several fundamental assumptions made while designing the high 
level protocol which affect the ethernet driver.

  1. The ethernet controller has enough local memory to buffer at least one
     incoming packet and one outgoing packet and will not overwrite a buffer
     with a new incoming packet until the buffer has been released.

  2. Read buffers are released in the same order as they were allocated.
     After a read interrupt has occurred and (*bufread)() has been called,
     then bufread will not be called again until an eth_release has been done.

  3. The ethernet driver generates no write interrupts.  This is because we
     found that busy waiting was more efficient than doing a context switch and
     waiting for an interrupt.  By the time the context switch was done, the
     interrupt had already happened, so we had to switch back.  It's faster to
     just wait for it.  On a very slow machine, a different strategy might be
     appropriate.

There are several routines used by the high level code which should be
provided by the ethernet driver.  Unless otherwise stated, these routines are 
called in the file amoeba.c.

1. etheraddr	- get ethernet address of this host from rom.
2. eth_init	- initialises the ethernet card and sets pointers to routines
		  to be called on packet arrival and departure.
3. eth_getbuf	- returns pointer to next write buffer.
4. eth_write	- writes the current "write buffer" to the net.
5. eth_release	- release a read buffer for reuse.
6. eth_stp	- shuts up the ethernet chip so that reboot can stop all
		  interrupts from the chip.  The normal reboot procedure
		  doesn't stop the WD1003E from running, so the next time
		  interrupts are enabled it makes a fuss (called from klib88.s).

The files dp8390.c, dp8390.h, dp8390info.h and dp8390stat.h contain routines
specific to the NS DP8390 chip.  These may need some slight changes before
working correctly with another manufacturer's board which also uses this chip.
The files etherplus.c and etherplus.h contain routines specific to the WD1003E
board.

10. REFERENCES

 1. Birrell, A.D., and Nelson, B.J.: "Implementing Remote Procedure Calls,"
    ACM Transactions on Computer Systems, vol. 2, pp. 39-59, Feb. 1984.

 2. Cheriton, D.. "The V Kernel: A Software Base for Distributed Systems,"
    IEEE Software Magazine, vol. 1, pp. 19-42, April 1984.

 3. Bal, H.E., Renesse, R. van, and Tanenbaum, A.S.: "Implementing Distributed 
    Algorithms using Remote Procedure Call," Proc. National Computer Conference
    AFIPS, pp. 499-505, 1987.

 4. Renesse, R. van, Tanenbaum, A.S., Staveren, H., and Hall, J.: "Connecting
    RPC-Based Distributed Systems using Wide-Area Networks," Proc. Seventh
    International Conf. on Distr. Computer Systems, IEEE, pp. 28-34, 1987.

 5. Tanenbaum, A.S., Mullender, S.J., and van Renesse, R.: "Using Sparse 
    Capabilities in a Distributed Operating System," Proc. Sixth 
    International Conf. on Distr. Computer Systems, IEEE, 1986. 

 6. Mullender, S.J., and Tanenbaum, A.S.: "The Design of a Capability-Based 
    Distributed Operating System," Computer Journal, vol. 29, pp. 289-299, 
    Aug. 1986.

 7. Tanenbaum, A.S., and Renesse, R. van: "Distributed Operating Systems," 
    Computing Surveys, vol. 17, pp. 419-470, Dec. 1985.

 8. Mullender, S.J., and Tanenbaum, A.S.: "A Distributed File Service Based on 
    Optimistic Concurrency Control," Proc. Tenth Symp. Oper. Syst. Prin., 
    pp. 51-62, 1985.

 9. Mullender, S.J., and Tanenbaum, A.S.: "Protection and Resource Control in 
    Distributed Operating Systems," Computer Networks, vol. 8, pp. 421-432, 
    Oct. 1984.

10. Tanenbaum, A.S., "Computer Networks, 2nd ed., Englewood Cliffs, NJ: 
    Prentice-Hall, 1989.



-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From dlr Tue Nov 21 20:24:41 1989
Flags: 000000000000
Date: Tue, 21 Nov 89 20:23:10 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: dlr@daver (Dave Rand)
To: pc532@daver.uu.net
Subject: Re: SCSI stuff

[In the message entitled "SCSI multi-master question" on Nov 21, 18:19, John L. Connin writes:]
> Regarding the multi-master SCSI bus, would it be possible / reasonable
> to extend it to have  8 / 16 / 32 bit wide data path ?
It is possible. The question is why?

> The reason I ask is I have the feeling that after time an 8-bit
> data path will begin to feel restrictive.  By way of illustration
> consider the contrast with the EIAS bus which should be generally
> availble in the i386/i486 motherboard market within the next
> 6 - 12 months.
The reason people are going with 32 bit busses are many and varied.

Our idea is that the SCSI bus offers a high speed (3.8 megabytes/sec)
periperal interface. This _forces_ the peripherals to be "smart" (to have
local CPU's). We have no (zero) interest in having slow, PC add-in cards
being inserted in this machine. Even now, with 16 bit VGA systems, much of
the screen update time is synchronization (wait states) between the 386 and
the VGA memory. The SCSI acts like a FIFO in this case, getting rid of this
degradation in performance. Remember: The 532 (in my opinion) is about
2 times faster than a 486. I don't want to waste those cycles.

> on page 62.  Mylex is pushing their new 32-bit peripherals
> (shortly to be EIAS compatible) which include:
> 
>         o SCSI cached disk subsystem           - 32 bit bus interface.
The disk/tape SCSI is capable of >5 meg/second (although drives currently
can't get over 4 meg/sec burst, 2.2 megabytes/sec sustained). Caching
systems external will not (in general) buy you as much as a low latency
disk system. You can always use some of the 32 megabytes for cache on the
motherboard - who would notice 4 or 6 megabytes? :-)


>         o Buffered ethernet network interface  - 32 bit bus interface.
What for? Ethernet is only 1.25 meg/sec max. *most* important is a low
latency packet handling routine. More grunt on the Ethernet card - which
is why we have a GX32 on the Ethernet.

>         o Graphics controller (TI 34020 based) - 32 bit bus interface.
Now this one I could agree with. However, our intent is to have smart
cards out on the interface. This means at least part of the X server
code (all?) code can reside on the graphics controller (a real graphics
controller, versus a frame buffer).

The local cards (like the Ethernet) can (and do) have a 32 bit bus.
What is the point of having it on the bus? More pins, more drivers, and
more things to go wrong. In my opinion. What do the other folks say?


-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net


From uunet!nac.no!hsr.uninett!jensen Wed Nov 22 04:14:11 1989
Flags: 000000000000
Date: 22 Nov 89 11:59 -0800
From: "Tarjei T. Jensen" <uunet!nac.no!jensen%hsr.uninett>
To: <pc532%daver>
Subject: Re: SCSI stuff.

I am not bothered about the idea of using intelligent peripherals on a SCSI
bus, but I think that there are valid reasons for a conventional 32 bit bus in
a computer like the pc532. Such a bus need not be anything as complex as say,
the Futurebus or VME bus.

 - Remeber the 128k Mac; it was useless before they got expansion slots
   into it. The idea of hanging intelligent peripherals on the serial port
   did not work very well either.

 - Even on 386 PCs with AT slots, they add one or two 32 bit expansion slots
   for memory. It is not unthinkable that we would want to use a bus for
   memory expansion or even for some peripherals (cost reasons).

 - It is very difficult to anticipate the needs of tomorrow, so I think that it
   would be a good idea to have a conventional bus. What if I were to decide
   that I would make a 32 bit graphics card for the pc532 and use it as a high
   performance X server connected to another pc532 client through an ethernet
   or SCSI bus? What if I get hold of a 32 bit wide SCSI controller and want to
   use it in the pc532? What if I decide that for economy's sake I'll have to
   put the ethernet controller on the system bus (and accept performance
   degradation)?

 - With a full blown bus, we could have an intelligent I/O subsystem and an
   empty bank account :-). We could even have a central processor with multiple
   slave processors (control applications). It would even be possible to have
   an complete X server on a card with both keyboard and VDU (cost reasons
   again).

 - For those of us without analyzers (yes, we exist) it would be easier to
   debug a card directly on the bus than over a scsi bus. If we were to use the
   pc532 for applications, it would be very useful if it could be its own
   development system. It could be easier to obtain support from National this
   way.

I see that there are lots of serial ports. Why not a few parallel ports for
printers? Most of the printers in my price range have Centronics interfaces and
with a max data rate of up to 1Mbyte/sec it beats 9600bit/sec hands down for
graphics dumps.

I hope that this in't too negative, it's just that I'm a bit worried about how
much this is going to cost in the end. Even though I'm in favour of an internal
conventional bus, I'm not in favour of that bus replacing one of the SCSI
buses. It would be nice to use one for Macintosh peripherals or for testing
drivers etc.
----------
    Tarjei T. Jensen - if it isn't broken, fix it anyway.
    jensen%hsr.uninett@nac.no


From wombat!george Wed Nov 22 08:52:56 1989
Flags: 000000000000
X-Mailer: Mail User's Shell (6.2 5/11/88)
To: pc532@daver
Subject: scsi stuff
Date: 22 Nov 89 08:34:40 PST (Wed)
From: george@wombat.UUCP (George Scolaro)

[In the message entitled "Re: SCSI stuff." on Nov 22, 11:59, "Tarjei T. Jensen" writes:]
> 
> I am not bothered about the idea of using intelligent peripherals on a SCSI
> bus, but I think that there are valid reasons for a conventional 32 bit bus in
> a computer like the pc532. Such a bus need not be anything as complex as say,
> the Futurebus or VME bus.

Are we going to create yet another bus then? If we want a multi-master
capable bus, we will need arbitration circuitry, transceivers, buffers etc
etc. The SCSI I/O bus (dp8490) has the multi-master feature and the chip
has all the drivers etc built in. It is a 44 pin PLCC device, ie tiny!

> 
>  - Remeber the 128k Mac; it was useless before they got expansion slots
>    into it. The idea of hanging intelligent peripherals on the serial port
>    did not work very well either.

No I don't, I have never played with McComputers, but we are talking about a
machine with up to 32 megabytes of memory, not 128k. Even I in my most
imaginative mode can't consider requiring that much memory, especially from
an ICM that has between 4 & 8 meg (depending on the health of the memory
board). Remember this is meant to be a cheap (as possible), buildable system.
There are 4 SCSI (62 pin XT form factor) sockets on the motherboard. These
are dedicated to I/O boards, there is a seperate SCSI (with sync support) for
the harddisk/tape backup etc.

>  - Even on 386 PCs with AT slots, they add one or two 32 bit expansion slots
>    for memory. It is not unthinkable that we would want to use a bus for
>    memory expansion or even for some peripherals (cost reasons).

Yes, but this is 'cos most 386's don't have more than a couple of meg on the
motherboard. The one (typical) 32 bit slot is just for memory... The SCSI
I/O bus takes care of your I/O expansion needs.

> 
>  - It is very difficult to anticipate the needs of tomorrow, so I think that it
>    would be a good idea to have a conventional bus. What if I were to decide
>    that I would make a 32 bit graphics card for the pc532 and use it as a high
>    performance X server connected to another pc532 client through an ethernet
>    or SCSI bus? What if I get hold of a 32 bit wide SCSI controller and want to
>    use it in the pc532? What if I decide that for economy's sake I'll have to
>    put the ethernet controller on the system bus (and accept performance
>    degradation)?

I don't understand where the degradation from putting it on the system bus
comes from. The pc532 has a dedicated scsi (4 slots for I/O). These 4 slots
support multi-master via the scsi chip (dp8490), ie a plug in x server can
talk to a plug in ethernet board with no 532 contention. If the 532 wants
access to say the ethernet board as well, then it arbitrates via the scsi
chip, this is done automatically, so the 532 can go off and service the disk
for instance and since that is a seperate scsi chip, it is free to do so.
When the I/O scsi has arbitrated, an interrupt is generated back to the 532
to tell it that it now has control of the I/O scsi bus. I don't understand
what more you could want. It works, its pretty fast (4 megabyte/sec) and
real cheap (the dp8490 costs around $5).


> 
>  - With a full blown bus, we could have an intelligent I/O subsystem and an
>    empty bank account :-). We could even have a central processor with multiple
>    slave processors (control applications). It would even be possible to have
>    an complete X server on a card with both keyboard and VDU (cost reasons
>    again).

Again easy to do with the dedicated scsi I/O bus.

>  - For those of us without analyzers (yes, we exist) it would be easier to
>    debug a card directly on the bus than over a scsi bus. If we were to use the
>    pc532 for applications, it would be very useful if it could be its own
>    development system. It could be easier to obtain support from National this
>    way.

You're kidding right? Come on, its a lot easier to debug code running on the
scsi than a real 32 bit bus with multi master arbitration.

> I see that there are lots of serial ports. Why not a few parallel ports for
> printers? Most of the printers in my price range have Centronics interfaces and
> with a max data rate of up to 1Mbyte/sec it beats 9600bit/sec hands down for
> graphics dumps.

Build whatever you want, a plug in board with a small cpu some local ram etc
and you have a centronics. Remember that we want the 532 to do the minimum
amount of I/O itself. Especially centronics which is fast and generates lots
of interrupts. This task is much better handled by a seperate I/O cpu that
gets a packet of data from the 532 via the scsi I/O bus and then takes care
of the interrupt/character handling.

> I hope that this in't too negative, it's just that I'm a bit worried about how
> much this is going to cost in the end. Even though I'm in favour of an internal

No, I don't think its too negative. I think you just don't appreciate the
simplicity of having the I/O expansion bus be a scsi bus. Besides, the board
is designed and works, the net went through a large discussion phase last
year regarding what the ideal 532 system would look like (personal system
that is) and after many wonderful ideas, it just died away. There is a point
in engineering where you just have to stop polishing and build/ship the thing.
I hope that the pc532 is at that stage, and if not, it can always be modified
by people to suit their own needs, the schematics/pal equations etc. a free
for the asking...

One of the main reasons we chose to make the I/O bus a SCSI bus is that there
are no off the shelf DMA controllers for the 532 (much like the rest of the
32k family, and don't mention the 32203!) therefore the 532 has to handle all
I/O via software. Now we don't want to slow the 532 down, so let all the low
level I/O get handled by I/O processors on seperate plug in boards. Transfer
the data via the cheapest fastest bus we can buy (SCSI). The 532 doing a move
string instruction for 32 bit memory to 8 bit (dynamic bus sized) I/O runs
at close to 4 megabytes/sec (just right for the dp8490) or vice versa. So
that was the decision path we talk, ie path of least resistance. It made me
happy (the hardware engineer) and it made Dave Rand happy (the software
engineer). Which is more than can be said of many other designs where the
hardware is designed in a vacuum without regard to the software. I put two
scsi devices on the motherboard, because I had to satisfy Dave and his worry
about bandwidth availability to the disk system if heavy I/O was happening on
the I/O bus. We feel that the decisions we took were the most likely to
succeed and most cost effective way to go with resulting good performance.

>     Tarjei T. Jensen - if it isn't broken, fix it anyway.
>     jensen%hsr.uninett@nac.no

regards,

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george)

From voder!nsc!dtg.nsc.com!des Wed Nov 22 09:44:07 1989
Flags: 000000000000
Date: Wed, 22 Nov 89 09:39:37 PST
From: voder!nsc!dtg.nsc.com!des (Desmond Young)
To: pc532@daver.uu.net
Subject: SCSI

Guday,
  I agree with the decisions to use SCSI I/O. This is a cheap, effective,
adequate-performance bus. It is standardized, and works. Don't forget,
single-ended the bus can go to 6meters of cable - try doing that in your
macintosh or PC !!
Des
Reply:  des@gpo.nsc.com, or des@dtg.nsc.com
       {decwrl,hplabs,sun,pyramid,amdahl}!nsc.com!gpo!des
Des Young, M/S D3645 National Semiconductor, Santa Clara
The light at the end of the tunnel was only a burglar's torch - J.Buffet.

From uunet!pawl.rpi.edu!night Wed Nov 22 11:18:27 1989
Flags: 000000000000
To: daver.uu.NET!pc532
Subject: 
Date: Wed, 22 Nov 89 13:51:54 EST
From: Trip Martin <uunet!pawl.rpi.edu!night>

I'm currently looking into getting Mach.  The nice thing about Mach
is that it's free.  I don't know what sort of licensing restrictions
are attached though.  I should be getting info in the mail in a few
days.  I'll post a summary when it comes.

I find the startup company idea intriguing also.  How many other people
would be interested in it?

What sort of time-frame are we talking about for actually having another
run of PCBs?  When we get a reasonable number of people?  Is it dependent
on talks with NSC?  

Also, what do people think of trying to get more interest, say by
posting to more widely read groups (sci.electronics, misc.forsale,
and possibly comp.arch seem the most appropriate)?
--
Trip Martin  KA2LIV                           Trip_Martin@mts.rpi.edu 
night@pawl.rpi.edu                          night@uruguay.acm.rpi.edu
** Murphy's Law of Thermodynamics: Things get worse under pressure **

From sun!wrs!han!hwajin Wed Nov 22 12:09:42 1989
Flags: 000000000000
Date: Wed, 22 Nov 89 11:09:00 PST
From: sun!wrs!han!hwajin (Hwa Jin Bae)
To: daver.uu.net!pc532
Subject: TCP/IP networking

I think the idea of porting KA9Q to pc532/MINIX is a good one
since it can be done fairly quickly.  I do think that it
would be nicer to have a full 4.3 BSD Tahoe TCP/IP (which is
available in source code format for public use) ported to
pc532/MINIX.  It wouldn't be really that hard.  I make my living
porting/implementing/maintaining TCP/IP protocols, SLIP, and
various ethernet drivers, NFS, RPC, etc. and I would be interested
in doing work in this area.  I've always been a fan of NS32000
architecture (I have the Opus 32032 board) and would love to see
this project succeed.  

hwajin

From dlr Wed Nov 22 18:04:21 1989
Flags: 000000000000
Date: Wed, 22 Nov 89 18:03:10 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: dlr@daver (Dave Rand)
To: pc532@daver.uu.net
Subject: Re: SCSI stuff

One More time: PLEASE mail your contributions to pc532@daver.uu.net. NOT to
pc532-request. pc532 gets expanded to all interested people. pc532-request
gets expanded to me :-(


[In the message entitled "Re: SCSI stuff (fwd)y" on Nov 22, 11:40, John L. Connin writes:]

Forwarded message:

> From: uunet!daver!dlr (Dave Rand)
> Subject: Re: SCSI stuff

> 
> [In the message entitled "SCSI multi-master question" on Nov 21, 18:19, John L. Connin writes:]
> Regarding the multi-master SCSI bus, would it be possible / reasonable
> to extend it to have  8 / 16 / 32 bit wide data path ?

> It is possible. The question is why?

> 
> The reason I ask is I have the feeling that after time an 8-bit
> data path will begin to feel restrictive.  By way of illustration
> consider the contrast with the EIAS bus which should be generally
> availble in the i386/i486 motherboard market within the next
> 6 - 12 months.

> The reason people are going with 32 bit busses are many and varied.

> Our idea is that the SCSI bus offers a high speed (3.8 megabytes/sec)
> periperal interface. This _forces_ the peripherals to be "smart" (to have
> local CPU's). We have no (zero) interest in having slow, PC add-in cards
> being inserted in this machine. Even now, with 16 bit VGA systems, much of
> the screen update time is synchronization (wait states) between the 386 and
> the VGA memory. The SCSI acts like a FIFO in this case, getting rid of this
> degradation in performance. Remember: The 532 (in my opinion) is about
> 2 times faster than a 486. I don't want to waste those cycles.

Apparently I did not clearly state my question and/or the rational behind
the question.  Sorry.  

I did NOT mean to imply replacing the SCSI bus with a EIAS or any other 
bus.  Lets see if I can clearly state what I had in mind.

It seems to me that a 3.8 megabytes/sec bus transfer rate may be too
limiting in the end result.  Thus, it seemed to me that it might be 
possible to extend the width of the pc532 SCSI data bus (without violating
the design integrity) in a manner that the SCSI controller could perform 
8, 16, and 32 bit-wide transfers (ie. 3.8, 7.6, and 15.2 megabytes/second 
respectively ).

In the case of a *basic* SCSI controller, it seems to me that the data width
can be simply extended by adding 3 - 8 bit bi-directional bus transceivers.

As I indicated, I currently do not have a data sheet for the DP  SCSI 
controller.  I gather from Dave's comment the device contains a
FIFO buffer.  Any bus width extension would have to look and feel the
same with resepect to the CPU.


> The local cards (like the Ethernet) can (and do) have a 32 bit bus.
> What is the point of having it on the bus? More pins, more drivers, and
> more things to go wrong. In my opinion. What do the other folks say?
> 

Perhaps I have a misunderstanding. Are you saying that the pc532 has
an Ethernet on the motherboard?  I understood the Ethernet to be a
smart peripheral card which plugs into the the multi-master SCSI bus.

Best regards,
johnc



-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From dlr Wed Nov 22 18:05:17 1989
Flags: 000000000000
Date: Wed, 22 Nov 89 18:03:37 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: dlr@daver (Dave Rand)
To: pc532@daver.uu.net
Subject: Amoeba

[In the message entitled "Amoeba" on Nov 22, 12:29, John L. Connin writes:]


The follow was contained in a message just posted to comp.os.minix
by AST.
	----------------------------------------------

[ stuff deleted]

We are currently in the process of preparing a proper Amoeba distribution
for outside consumption.  This will contain all the code to run Amoeba on
Suns and Vaxes.  In a following distribution, 386s and other CPUS (RISC)
will be added.  The Amoeba distribution will contain all the source code
for the high, low, and intermediate level stuff.  This work is being
partially supported by OSF, since they are interested in examining it for
potential use in OSF/2 or OSF/3.

The tape with everything will be available to universities and the like for
a nominal charge.  We hope to have it available in the Spring of 1990
(Spring is March 21 to June 21 or thereabouts).  Time will tell.

Andy Tanenbaum (ast@cs.vu.nl)



-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From dlr Wed Nov 22 18:07:04 1989
Flags: 000000000000
Date: Wed, 22 Nov 89 18:04:22 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: dlr@daver (Dave Rand)
To: pc532@daver.uu.net
Subject: Internal SCSI bus speed

[In the message entitled "Internal SCSI bus speed" on Nov 22, 17:57, John L. Connin writes:]


As I understand, the "internal multi-master" SCSI bus, at least with
respect to the pc532 motherboard is controlled by a SCSI controller chip
in an asynchronous mode only.

If this is the case, since the SCSI bus is NOT likely to connected
directly to third party "standard" SCSI devices (ie. no off-the-self
plug-in cards exist for the pc532), is it possible / reasonable to
double the bus speed to 7.6 Megabytes/sec with a standard 8-bit data
width ??

I am assuming the design intent is to use SCSI controller A to connect
to "standard" SCSI devices, whether internal or external to the cabinet.
Whereas SCSI controller B is designed to be strictly a "local" bus
to interconnect smart multi-master peripheral "boards".  The only
limitation I can see (with my dim vision :-) ) would be the maximum
rated speed of the SCSI controller chip.

Got to get some data sheets.

best regards,
johnc



-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net


From ames!mips!daver!dlr@harvard.UUCP@bu-it.BU.EDU Thu Nov 23 01:34:24 1989
Flags: 000000000000
Date: Wed, 22 Nov 89 20:18:06 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: ames!mips!daver!dlr@harvard.UUCP (Dave Rand)
To: daver.uu.net!pc532@mips.UUCP
Subject: Re: SCSI stuff

[In the message entitled "Re: SCSI stuff" on Nov 22, 18:03, TO: pc532@daver.uu.net writes:]
> > 
> > [In the message entitled "SCSI multi-master question" on Nov 21, 18:19, John L. Connin writes:]
> > Regarding the multi-master SCSI bus, would it be possible / reasonable
> > to extend it to have  8 / 16 / 32 bit wide data path ?
> 
> > It is possible. The question is why?
>
> It seems to me that a 3.8 megabytes/sec bus transfer rate may be too
> limiting in the end result.  Thus, it seemed to me that it might be 
> possible to extend the width of the pc532 SCSI data bus (without violating
> the design integrity) in a manner that the SCSI controller could perform 
> 8, 16, and 32 bit-wide transfers (ie. 3.8, 7.6, and 15.2 megabytes/second 
> respectively ).

I presume that you could (with some significant re-resign of the hardware).

The question is why? Why is 3.8 meg/sec "too limiting"? What device could
*possibly* use more than this? At this rate, you could run 4 ethernet
cards, each to a different net, and max all of them out (which
*no* other system could keep up with, due to back-to-back packets).
No video system could keep up with 3.8 meg second. No current technology
disk drive could keep up, and even if it could, we have the other SCSI
for that. True, you could only keep half of an FDDI bus busy, but with
two pc532's, you could even max out an FDDI. You could keep 20 full
stereo 44.1 Khz digital channels (like Compact Disks) busy.

Why is there a need for more than 3.8 megabytes per second?

This is not a faint of heart bus. This is real fast, all the time. All
the logic is inside of one chip, so you can't get it wrong (no problems
with compatibility - how many of your pc plug in cards can't work in your
new 386 system?). You can extend the bus 6 m, with a 25 pin unshielded
cable (well - so long as you don't go for FCC approval :-). No extra
drivers, no mucking about with arbitration - It Just Works. This would not
be possible if you just added some tranceivers.

Besides, as George says, at some point you have to stop polishing the
chrome, and ship it. That's what happened last year in comp.sys.nsc.32k.
Lots of people wanted lots of things, and nothing got done. We sat down,
discussed (Calm and Rational "Either you give me an interrupt or I'll rip
your head off" discussions) the tradeoffs and came up with a *very* unique
design. George then built it - in two stages. A wire-wrap prototype, then a
full blown PCB. It works.

Since the schematics are available, if you like, you can make changes, try
them out, and see what you think. There is even some prototype space on the
current PCB (6 0.3 inch packages). We just can't figure out why you would
need more than 3.8 meg/sec on the internal bus!

(Points of interest - The DSI-32, in an IBM AT at 8 Mhz had a 250 Kbyte per
second maximum bus rate. The PD-32 had about 500K per second.)

> > The local cards (like the Ethernet) can (and do) have a 32 bit bus.
> > What is the point of having it on the bus? More pins, more drivers, and
> > more things to go wrong. In my opinion. What do the other folks say?
> > 
> 
> Perhaps I have a misunderstanding. Are you saying that the pc532 has
> an Ethernet on the motherboard?  I understood the Ethernet to be a
> smart peripheral card which plugs into the the multi-master SCSI bus.

Sorry - this one is my fault. Let me try it again.

Plug in SCSI cards (like the Ethernet) can and do have a 32 bit internal
to the card bus to access memory, and the devices. They still go back to
the 8 bit SCSI bus for data interchange with other devices. What is the
point of having all 32 bits going out over the main bus? More pins, more
drivers, more packages, and more things to go wrong. 

Again - what do you folks say? Is there something we are missing?


-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From ames!mips!daver!dlr@harvard.UUCP@bu-it.BU.EDU Thu Nov 23 01:34:28 1989
Flags: 000000000000
Date: Wed, 22 Nov 89 20:23:04 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: ames!mips!daver!dlr@harvard.UUCP (Dave Rand)
To: daver.uu.net!pc532@mips.UUCP
Subject: More SCSI stuff

[In the message entitled "Internal SCSI bus speed" on Nov 22, 17:57, John L. Connin writes:]
> If this is the case, since the SCSI bus is NOT likely to connected
> directly to third party "standard" SCSI devices (ie. no off-the-self
> plug-in cards exist for the pc532), is it possible / reasonable to
> double the bus speed to 7.6 Megabytes/sec with a standard 8-bit data
> width ??
Regretfully, no. This is the maximum speed of the DP8490, and (due to
the way the dynamic bus sizing of the 532 works) the maximum speed of
a dynamic bus sized 32 bit to 8 bit string move works.



-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From ames!mips!daver!sun!ames.arc.nasa.gov!gatech!mm!ken@harvard.UUCP@bu-it.BU.EDU Thu Nov 23 01:34:31 1989
Flags: 000000000000
X-Mailer: Mail User's Shell (6.4 2/14/89)
To: daver.uu.net!pc532@mips.UUCP
Subject: comments
Date: 22 Nov 89 15:35:03 EST (Wed)
From: ames!mips!ames.arc.nasa.gov!gatech!mm!ken@harvard.UUCP (Ken Seefried iii)

I got all the backlog just fine, and I must say...wow...

A few of you may remeber a board I was working on at one point
(32332, NuBus).  Everyone seemed to hate the idea at the time (all
wanting either super-cheap (32016) or super-fast (32532), so I
pretty much let it drop prior to finishing the last details.  I'm
happy to see that *someone* out there was serious enough about the
whole thing to actually finish.

Here are my comments to date:

*Commercial or not*

I certainly would like to see Dave and George make tons 'o $$$ on
the design, but given a personal choice, why don't you start the
Free Hardware Foundation that was talked about some months ago.
Get the FSF guys fired up about the board.  Which leads me
directly to...

*Software*

Minix is okay.  

It has the great advantage of being relatively easy to port and
extend, and more importantly, there are lots of people out there
working on it.  As mentioned, it will so be POSIX compliant, which
is nice.  However, lot's of nifty things that alot of people will
expect to be able to run won't (i.e. X11, GNU Emacs).

Ameoba is interesting for a variety of reasons.

I personally would like to see the thing run the GNU-OS (probably
Mach based with the Sprite filesystem).  They have most of the
tools in place, and a Mach based OS will run most anything one
would want to throw at it.  There are lot's of people working on
the GNU tools, and most of them are of the highest quality (being
an Emacs devote).  

However...it isn't done yet, and won't be for a while.  In any 
we will need *some* kind of OS running to get the GNU-OS running.
Therefore, in the near term, I'd have to throw my hat into the
Minix ring, unless someone got really motivated to port something
like Stanford V or some such.

I'd *really* like to stay away from source licenses and lawyers
and such (i.e. System V and BSD), though even System V.2 would 
be plesant at 8MIPS...;')

*SCSI bus*

Great idea!  Really, truly great!  Only one caveat...

Most good multi-processing systems (Sequent, mc88000, etc.) 
have some kind of shared memory.  We don't have that with SCSI.
This is really the only advantage I see for the more traditional 
buses (NuBus, ESIA, etc.).

I believe Ameoba embodies a kind of multiprocessing in the 
large based on networked processors without shared memory, 
but it doesn't allow very fine grained applications (i.e. 
LWPs, etc.).  Stanford V OS also deals with networked 
multi-processors, but I don't remember how (other than 
blindingly fast network primatives).

(N.B. - I have not had time to read the Minix/Ameoba RPC doc
that I was sent...)

Of course, feel free to abuse me if any of this is inacurate...

On another note...

NCR is making some really interesting intelligent SCSI controller 
chips with all sorts of nifty features (including on-chip RISC
processors, etc., and a simplified programming layer).  Check it
out...

*Graphics*

Which reminds me...

Any way I can build a video board whose frame buffer lives in main
memory, or do I *have* to go across the SCSI bus to some sort of
smart-card.  I'd sure as hell hate to port X to such an
arrangement (not impossible...just a pain).

MGR would be faster than X in such an arrangement, but it still 
likes to live in the processors address space, makeing a port
annoying.  

Course, GSS and others have already ported the X server to the 
340x0 graphics processors, but that costs money to buy (lots of
it, I would imagine).

Maybe I'll look at putting together a 34020-based graphics board.
Hmmmmm....and a DSP would be nice...Hmmmm...;')

*Serial I/O*

Any reason why you guys didn't use 16550A's for the serial I/O?
they seem to be *so* much nicer than 2681's, and they have that
16-byte buffer...

*Ththththats all floks...*

Thats it for now...


-- 

	...ken seefried iii	...!<anywhere>!gatech!mm!ken
	   MetaMedia, Inc.
	   mm!ken@gatech.edu	

From ames!mips!daver!dlr@harvard.UUCP@bu-it.BU.EDU Thu Nov 23 01:34:35 1989
Flags: 000000000000
Date: Wed, 22 Nov 89 21:32:30 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: ames!mips!daver!dlr@harvard.UUCP (Dave Rand)
To: daver.uu.net!pc532@mips.UUCP
Subject: Re: Comments

[In the message entitled "comments" on Nov 22, 15:35, Ken Seefried iii writes:]
> NCR is making some really interesting intelligent SCSI controller 
> chips with all sorts of nifty features (including on-chip RISC
> processors, etc., and a simplified programming layer).  Check it
> out...
> 
I have, and will be looking at these...

> *Graphics*
> 
> Any way I can build a video board whose frame buffer lives in main
> memory, or do I *have* to go across the SCSI bus to some sort of
> smart-card.  I'd sure as hell hate to port X to such an
> arrangement (not impossible...just a pain).
You have to - unless you want to hack on the board (always possible).
The idea is to keep the main processor busy processing - not rendering.
Frame buffers (almost) always extract a cost in wait states.

> *Serial I/O*
> 
> Any reason why you guys didn't use 16550A's for the serial I/O?
> they seem to be *so* much nicer than 2681's, and they have that
> 16-byte buffer...

*snarl*

I _HATE_ 16550A's. They cost too much (1 16550A is the same price as
all 8 ports on the PC532). And they are useless in a flow controlled
situation:

	host		550		terminal
	2k to go,
	please
			I'll take 16
			bytes
					Uhh <chugg, chugg>
					I CAN'T TAKE IT ANYMORE!
					RTS! RTS! 
			Ooops, I got
			a change of
			state on CTS. Oh well,
			I'll tell the
			host. Only 5 bytes
			left to transmit.
	Hmm. Seems			<gasp, gasp>
	like the terminal
	is overflowing.
	Turn off TX.
			But - but - I've
			still got 5 bytes
			to go! Oh well. I'll
			just drop them in
			this bucket here.
			<evil chuckle>


The 2681's have a four byte rx fifo, AND THEY UNDERSTAND HARDWARE HANDSHAKE.

The 550's do great on rx, but can't use the tx fifo on a flow controlled
(either software or hardware) system. And - if you can't get to the
uart in time (admitted: not a problem here), you lose anyway. The 2681
and the hardware handshake wins big time.

To say nothing of the board space savings. And the cost.

	

-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From ames!mips!daver!sun!ucscc.UCSC.EDU!clanhlm!blank@harvard.UUCP@bu-it.BU.EDU Thu Nov 23 09:04:03 1989
Flags: 000000000000
From: ames!mips!ucscc.UCSC.EDU!clanhlm!blank@harvard.UUCP
To: ames.arc.nasa.gov!daver!pc532@mips.UUCP
Subject: SCSI vs 32 bit bus
Date: Thu Nov 23 01:57:39 1989

from

	For whatever it is worth, I feel that a secondary port into
	memory, with a full 32 bit data path would be a good thing.
	The secondary port would support high speed i/o (can you say
	100 Mb/sec network, folks?) and varoius other multi-ported memory
	things (such as true i/o processors).  The other uses would be for
	memory expansion, and related things.

	General aside -- is the memory controller set up so it can be
	expanded into a multiported memory?  (ie, if the accesses are
	in different banks, both accesses are granted, otherwise
	round robin priority...)

					John


From ames!mips!daver!uunet!nac.no!hsr.uninett!jensen@harvard.UUCP@bu-it.BU.EDU Thu Nov 23 10:34:13 1989
Flags: 000000000000
Date: 23 Nov 89 13:50 -0800
From: "Tarjei T. Jensen" <ames!mips!nac.no!hsr.uninett!jensen@harvard.UUCP>
To: <daver!pc532@mips.UUCP>
Subject: Re: scsi stuff

george@wombat writes:

> Are we going to create yet another bus then? If we want a multi-master
> capable bus, we will need arbitration circuitry, transceivers, buffers etc
> etc. The SCSI I/O bus (dp8490) has the multi-master feature and the chip
> has all the drivers etc built in. It is a 44 pin PLCC device, ie tiny!

I'm sorry that I didn't make it clear that I thought of something far less
grandiose (I have read somewhere that futurebus was very simple). I was just
hoping for a ZX81 style bus (concerning simplicity); just the pins from the cpu
and very little more to an euroconnector or two. The only "multimaster"
feature I would expect would be the to be able to use the /HOLD pin.

One of the advantages of using a computer with a conventional bus is that you
can use the _standard_ computer (e.g. Apple II) as the development system. This
is probably why the Apple II and IBM PC were so successful. In other words; the
_entry cost_ consisted mainly of cost of the computer itself.

I don't doubt at all that life is extremely simple when the intelligent
peripheral has been developed and one wants to use it accross a SCSI bus.
However this does not ease the bottleneck for me which is the _development_
(debugging) of the peripheral. A simple bus will allow me to make my own
peripherals (e.g ethernet card) at low cost with a low overhead in equipment.
If there is no such bus, then I will have to be content with a software only
approach for the time being.

> I don't understand where the degradation from putting it on the system bus
> comes from. The pc532 has a dedicated scsi (4 slots for I/O). These 4 slots
> support multi-master via the scsi chip (dp8490), ie a plug in x server can
> talk to a plug in ethernet board with no 532 contention. If the 532 wants
> access to say the ethernet board as well, then it arbitrates via the scsi
> chip, this is done automatically, so the 532 can go off and service the disk
> for instance and since that is a seperate scsi chip, it is free to do so.
> When the I/O scsi has arbitrated, an interrupt is generated back to the 532
> to tell it that it now has control of the I/O scsi bus. I don't understand
> what more you could want. It works, its pretty fast (4 megabyte/sec) and
> real cheap (the dp8490 costs around $5).

I assumed that the system bus would be the above mentioned conventional bus. I
also assumed that the ethernet controller (e.g. LANCE) would generate quite a
lot of interrupts and would contend with the CPU for memory access.

I'm not worried about the cost of the SCSI chips. What worry me is the cost of
the ethernet card. If I can't afford to buy it, then it will be hell to debug
my own SCSI based design without a proper development system. Having said that,
I must admit that ethernet connectivity is not crucial for me currently so it
can wait.

> One of the main reasons we chose to make the I/O bus a SCSI bus is that there
> are no off the shelf DMA controllers for the 532 (much like the rest of the
> 32k family, and don't mention the 32203!) therefore the 532 has to handle all
> I/O via software. Now we don't want to slow the 532 down, so let all the low

Are there any suitable DMA controllers available from other manufacturers?
Could National be shamed into making one?

By the way, am I overlooking something concerning the development of the
peripheral cards? Are there any ultra cheap microprocessor emulators available
anywhere? The best (cheapest) I have seen up to now is a device using dual-
ported RAM masquarading as SRAM/PROM in the target system and being modifyable
>From the host. I'm not sure if it is still available.

----------
    Tarjei T. Jensen - if it isn't broken, fix it anyway.
    jensen%hsr.uninett@nac.no

From think!ames!mips!daver!uunet!tarpit!manatee!johnc%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Thu Nov 23 13:16:56 1989
Flags: 000000000000
Subject: Re: comments
To: mips!daver.uu.NET!tarpit!pc532@EDDIE.MIT.EDU
Date: Thu, 23 Nov 89 11:42:04 EST
From: John L. Connin <think!ames!mips!daver!uunet!manatee!johnc@EDDIE.MIT.EDU>
X-Mailer: Elm [version 2.1 PL1]


[In the message entitled "comments" on Nov 22, , "Ken Seefried" writes:]

> Minix is okay.
>
> [stuff deleted]
>           However, lot's of nifty things that alot of people will
> expect to be able to run won't (i.e. X11, GNU Emacs).

Perhaps I have missed something.  I am assuming that if Minix is
ported that at some early point demand page virtual memory
would be implemented.  Is there some limitation that I have over looked ??

> *SCSI bus*
>
> Great idea!  Really, truly great!  Only one caveat...
>

BTW: I also agree.. that it is a great idea..

> Most good multi-processing systems (Sequent, mc88000, etc.)
> have some kind of shared memory.  We don't have that with SCSI.
> This is really the only advantage I see for the more traditional
> buses (NuBus, ESIA, etc.).
>
> I believe Ameoba embodies a kind of multiprocessing in the
> large based on networked processors without shared memory,
> but it doesn't allow very fine grained applications (i.e.
> LWPs, etc.).
>  [ stuff deleted]

Don Libes posted a neat solution to multi-processor shared memory some
time back in comp.sources.misc called "Common Memory Manager CCM" (sorry
I do not have the volume/issue number at my finger tips).  Very
simply, shared memory is emulated using a server process (CMM).  I
believe it would be straight forward to adapt it to Ameoba or any other
communications protocol.  Furthermore, the code is clean and well
documented.

Best regards,
johnc



From think!ames!mips!daver!wombat!george%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Thu Nov 23 15:49:41 1989
Flags: 000000000000
X-Mailer: Mail User's Shell (6.2 5/11/88)
To: mips!daver!pc532@EDDIE.MIT.EDU
Subject: THE BUS
Date: 23 Nov 89 11:48:52 PST (Thu)
From: think!ames!mips!wombat!george@EDDIE.MIT.EDU (George Scolaro)

Ok, here we go for the last time (please). The PC532 has a SCSI bus, it is
designed, built and working. If people want a normal bus, then just design a
SCSI to normal bus converter board. If you want access to a PC/AT bus, then
design a plug in board with SCSI and stick it into the PC/AT, run a cable to
a dummy board that plugs into the pc532 SCSI I/O bus. Then you can use the
'286 etc as an intelligent I/O processor for the pc532. Note that the PC/AT
bus is good for a couple of megabytes per second if you try real hard.

Dave and I have built 32k boards, even with graphics support, that transfer
memory via a software protocol from the main cpu (32016/032/332 boards) to
the PC/AT for stuff like bit mapped graphics. We did this at a lowly 250 -
800 kbytes/sec, it worked real good, how fast are your eyes?

[In the message entitled "SCSI vs 32 bit bus" on Nov 23,  1:57, daver!sun!ucscc.UCSC.EDU!clanhlm!blank writes:]
> 
> 	General aside -- is the memory controller set up so it can be
> 	expanded into a multiported memory?  (ie, if the accesses are
> 	in different banks, both accesses are granted, otherwise
> 	round robin priority...)

No it isn't. I don't want to sound aggressive, but have any of you tried to
design a tight (efficient) memory controller that tries to squeeze
performance out of a 25 Mhz CPU, with burst support, page mode support,
hidden refresh, 2 clock bus access, 1 clock burst access etc? The design I
have is worst case guaranteed (it better be) and gets the most out of the
CPU-memory. The moment you start multi-porting, arbitrating for the memory,
you start introducing extra logic (say wait states). The 532 does not like
wait-states (ignore NS literature!), so we have tried to make the memory
system as efficient as possible (more than a couple of months went into it).
In addition the only way to get performance is to very very tightly couple
the CPU and memory system, there are some D-speed pals (10 ns) in the
critical paths, we can't afford complexity if we want speed.

[In the message entitled "Re: scsi stuff" on Nov 23, 13:50, "Tarjei T. Jensen" writes:]
> 
> I'm sorry that I didn't make it clear that I thought of something far less
> grandiose (I have read somewhere that futurebus was very simple). I was just
> hoping for a ZX81 style bus (concerning simplicity); just the pins from the cpu
> and very little more to an euroconnector or two. The only "multimaster"
> feature I would expect would be the to be able to use the /HOLD pin.

I'm sure that futurebus is very simple, please design me a SCSI to futurebus
conversion card. Also, please sell me some futurenet plug in boards.... they
must be really popular since the bus is so simple (tee hee).

And - the big question - Why would you want such a simple bus? That's how
we determined what would be on this board. What would you use it for? How
often? Could it be done a better way? What would the impact be on the CPU
performance? Would it overly complicate the design? Would it offer any
significant advantage? If not - off it went! (and a General Purpose bus,
due to the DRAM controller design and a number of other features, was the
first thing to go.)

 
> One of the advantages of using a computer with a conventional bus is that you
> can use the _standard_ computer (e.g. Apple II) as the development system. This
> is probably why the Apple II and IBM PC were so successful. In other words; the
> _entry cost_ consisted mainly of cost of the computer itself.

Conventional bus in an Apple and PC, gee I'm sure that when they first came out
they weren't too conventional...

Designing SCSI cards is not tough. It is a _single chip_ bus interface.
Nothing to it. You can use Z80's, 8085's, 6800, 68000, 68XXX, 32K, whatever
you want. A minimum design would be a DP8490 and an HPC, for example. That's
all you would _need_. A bit of CPU, a bit of RAM, and a bit of ROM, and the
SCSI chip (any of the SCSI chips will do by the way - you don't _have_ to
use the DP8490.)

> 
> > One of the main reasons we chose to make the I/O bus a SCSI bus is that there
> > are no off the shelf DMA controllers for the 532 (much like the rest of the
> > 32k family, and don't mention the 32203!) therefore the 532 has to handle all
> > I/O via software. Now we don't want to slow the 532 down, so let all the low
> 
> Are there any suitable DMA controllers available from other manufacturers?
> Could National be shamed into making one?

a) No, AT&T has something that some people have kludged up but it isn't
really what you call a clean solution. And its timing isn't exactly like the
'532s, therefore we are again compromising the CPU-memory interface, ie
the dreaded wait states hit again.

b) National shamed into making a DMA controller, come-on, National is as
shamed as it can ever get with regard to the 32016/032/332 and the dreaded
32203 DMA controller. They have no local designers left (32k family) in the
US, and the Israel crowd (the home of the 32k now), is off designing megamip
computers. A boring DMA controller - get away - megamips forever.... Besides,
you could do it in a gate array, couldn't you? (inside joke :-)

> By the way, am I overlooking something concerning the development of the
> peripheral cards? Are there any ultra cheap microprocessor emulators available
> anywhere? The best (cheapest) I have seen up to now is a device using dual-
> ported RAM masquarading as SRAM/PROM in the target system and being modifyable
> from the host. I'm not sure if it is still available.

Yes probably, but all I have ever done is use a scope and a software loops to
verify timing (at home, of course work has logic analysers etc), but you can
do a hell of a lot with a wire and a CRT. Even at work, all we do is sit down
with the books, write the software, hang a scope on the hardware, and get it
working. We don't (ever) use ICE (or ISE) systems. We don't use rom emulators.
We don't waste time - we just get it working. For the 80960, we used the nindy
software (which permits downloading software via XMODEM). For the 68000, we
use a simple monitor Dave wrote. For the 32000, we use MON16. In all cases,
we have the ability to download test programs - for the 32000 we even have
symbolic debugging (via nothing more than an RS-232 port at 9600 bps).


[In the message entitled "Re: comments" on Nov 23, "John L. Connin" writes:]
>
>
> > Most good multi-processing systems (Sequent, mc88000, etc.)
> > have some kind of shared memory.  We don't have that with SCSI.
> > This is really the only advantage I see for the more traditional
> > buses (NuBus, ESIA, etc.).
> >
> > I believe Ameoba embodies a kind of multiprocessing in the
> > large based on networked processors without shared memory,
> > but it doesn't allow very fine grained applications (i.e.
> > LWPs, etc.).
> >  [ stuff deleted]
> 
> Don Libes posted a neat solution to multi-processor shared memory some
> time back in comp.sources.misc called "Common Memory Manager CCM" (sorry
> I do not have the volume/issue number at my finger tips).  Very
> simply, shared memory is emulated using a server process (CMM).  I
> believe it would be straight forward to adapt it to Ameoba or any other
> communications protocol.  Furthermore, the code is clean and well
> documented.

This is precisely the sort of thing we did with the 016/032/332 boards we
did. The interface was an 8 or 16 bit I/O address as far as the PC/AT was
concerned. We still got good performance (repeat string instructions) from
250k-800k bytes/sec. This was a very simple interface design. Opus with their
032/332/532 boards went for a shared memory design. The reality was that the
boards we did with the I/O interface were faster at I/O than the Opus boards,
and a HELL of a lot simpler. We typically had around 3-5 pals, Opus had up to
20 or more pals plus a couple of Xylinc arrays (on their 532 board).

To sum up, (again), we have a working design, working pcbs (6 layer), we have
made engineering tradeoffs (which we feel are reasonable) and we are giving
the design (in total) away to people that want it. If interested parties want
to make changes, fine, but the pc532 is a done deal, Dave & I are happy with
it, enjoy the results.

best regards,
george & dave.


-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george)

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Thu Nov 23 19:47:42 1989
Flags: 000000000000
Date: Thu, 23 Nov 89 13:19:37 PST
From: think!ames!mips!daver!sun!wrs!wrs!hwajin@EDDIE.MIT.EDU (Hwa Jin Bae)
To: mips!daver.uu.net!pc532@EDDIE.MIT.EDU
Subject: LANCE

Folks,

The LANCE will not generate so many interrupts -- at least
not enough to create memory access contention problem on the
bus.  I have worked on serveral LANCE drivers myself.  It is 
always possible to allocate a chunk of RMD's and TMD's and use
separate memory for the ring buffers (possibly located on the
ethernet controller board itself).  LANCE will fill in as many
buffers as possible using the incoming ethernet frames and 
interrupt the CPU with one or more of the ring buffers full of
ethernet frames, it won't interrupt the CPU every time.  Besides,
if a separate memory is dedicated to the LANCE, memory contention is not
a problem any ways.  Or am I missing something?  I didn't even
know that the ethernet board for the pc532 was designed around
LANCE.  Is it?

hwajin

---
Hwa Jin Bae
Wind River Systems, 1351 Ocean Avenue, Emeryville, CA 94608

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Thu Nov 23 19:48:51 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Thu, 23 Nov 89 14:46:21 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: think!ames!mips!daver!dlr@EDDIE.MIT.EDU (Dave Rand)
To: mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Re: LANCE

[In the message entitled "LANCE" on Nov 23, 13:19, Hwa Jin Bae writes:]
> if a separate memory is dedicated to the LANCE, memory contention is not
> a problem any ways.  Or am I missing something?  I didn't even
> know that the ethernet board for the pc532 was designed around
> LANCE.  Is it?

It is not. We are (currently) using the National Ethernet chip set.
And you are correct - the local CPU on the Ethernet board will be
handling the majority of interrupts. Only real data will make it
back to the host CPU. 

By the way, if your mail software can deal with Reply-To:, you
should be able to just "reply" to mailings now. I think I finally
have figured out how do do this... Let me know if you have problems.


-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Thu Nov 23 19:50:38 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
X-Mailer: Mail User's Shell (6.2 5/11/88)
To: mips!daver!pc532@EDDIE.MIT.EDU
Subject: ethernet
Date: 23 Nov 89 15:36:03 PST (Thu)
From: think!ames!mips!wombat!george@EDDIE.MIT.EDU (George Scolaro)

> a problem any ways.  Or am I missing something?  I didn't even
> know that the ethernet board for the pc532 was designed around
> LANCE.  Is it?
> ---
> Hwa Jin Bae
> Wind River Systems, 1351 Ocean Avenue, Emeryville, CA 94608
> 
We have a design and a nearly complete pcb layout (those last traces
are always a pain) for a multiserial + ethernet board. The board
has 16 serial channels (using octarts from signetics) a 32532 or GX32,
1 boot eprom, 1 megabyte of dram and an NS ethernet controller with
its own local sram buffer for the ethernet ring packet buffer.
The NS part is the dp8390 + the associated stuff for getting onto
ethernet. The board only supports thin ethernet, ie the thin coax.
There are modules that take thin to thick or to the new twisted pair
format.
We chose the NS ethernet controller, a) 'cos we were at NS and could
get samples easily, b) we had 'easy' access to getting info on how it
really worked as against the data sheet, c) NS has sold lots and lots
and therefore it is actually a working/shipping part. Not to say
that the LANCE isn't, just that we went with NS part. And most
importantly we had used the NS ethernet before and were familiar with
its capabilities and how to interface to it, ie we minimized our
engineering risk for the ether532.

regards,


-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george)

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Fri Nov 24 02:47:06 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
To: The pc532 Mailing List <mips!daver.uu.NET!pc532@EDDIE.MIT.EDU>
Fcc: pc532
From: Dave Mason <think!ames!mips!daver!uunet!tmsoft!mason@EDDIE.MIT.EDU>
Subject: Re: comments
Organization: TM Software Associates Inc.
Date: 23 Nov 89 16:15:45 EST (Thu)

In <8911221535.AA13744@mm.UUCP>, gatech!mm!ken (Ken Seefried iii) writes:
> I got all the backlog just fine, and I must say...wow...

I concur.  Looks really good....just a couple small nits :-)

> A few of you may remeber a board I was working on at one point
>[...]
> happy to see that *someone* out there was serious enough about the
> whole thing to actually finish.

I wasn't as far as Ken, but I'd offered to help someone work on a 532
project a year or so ago, but nothing came of it.  Thanks Dave &
George for actually doing something about it.

> *Commercial or not*
>[...]
> Get the FSF guys fired up about the board.

I thought that the FSF thought hardware profits were fine, just
*software* profits were evil (1/2 :-).  The net-wide consortium
sounded interesting, though.

> *Software*
> 
> Minix is okay.  

Certainly for a first cut, it seems like the way to go.

> I personally would like to see the thing run the GNU-OS

Gee, I was hoping to get away with only an 8MB machine...but if we use
GNU, I might not even get the kernel in that!

As another possibility, some of my thesis students and I are working
on a Unix-clone O/S, initially aimed at the ICM3216, it will be at
least as freely available as Minix.  I don't want to say any more at
this stage, though we'll certainly be talking about it as it starts to
get closer to running. 

> I'd *really* like to stay away from source licenses and lawyers
> and such (i.e. System V and BSD), though even System V.2 would 
> be plesant at 8MIPS...;')

I agree.  Though I personally think V.2 is fairly reasonable at
.75MIPS.  I'd love people to tell me (IN PERSONAL MAIL PLEASE, DON'T
BOG THIS MAILING LIST DOWN WITH O/S WARS!) what features of BSD they
(would) seriously miss when using V.2.  Convince me, and the features
will find their way into our O/S.  Job control & pttys are all
that occur to me (and they'll be there). (REPEAT, PERSONAL MAIL PLEASE!)

> *SCSI bus*
> Great idea!  Really, truly great!  Only one caveat...

Great idea! No caveat.

> Most good multi-processing systems (Sequent, mc88000, etc.) 
> have some kind of shared memory.  We don't have that with SCSI. [...]
> 
> I believe Ameoba embodies a kind of multiprocessing in the 
> large based on networked processors without shared memory, 
> but it doesn't allow very fine grained applications (i.e. 
> LWPs, etc.).  Stanford V OS also deals with networked 
> multi-processors, but I don't remember how (other than 
> blindingly fast network primatives).

If your processors (say 4 pc532's) are attached over a ~4MB/sec,
error free network, (interconnected SCSI's), this is not too hard to
do.  Mach and Emerald, (and to some extent Amoeba and V, I believe)
have talked about or support ``shared memory'' between processes on
different processors with separate physical memories.

> *Graphics*
> 
> Any way I can build a video board whose frame buffer lives in main
> memory, or do I *have* to go across the SCSI bus to some sort of
> smart-card.  I'd sure as hell hate to port X to such an
> arrangement (not impossible...just a pain).

This is what 386 boxes were designed for...  A cheapo 386 with VGA and
a SCSI interface card (say $2000-3000 total), plugged into the I/O SCSI
running X and TCP/IP across the 4MB/sec network to a pc532, sounds
close to heaven!  4 of these, a pc532 with 32MB and a GB of disk would
make for a damned nice 4 seat CAD system, for under $5000/seat!  (One
of them, rest as described would make a nice ANYTHING system @$11000)

(It would also add a touch more dignity for my 386, which right now is
my terminal into my ICM3216 :-)

> *Serial I/O*
> 
> Any reason why you guys didn't use 16550A's for the serial I/O?
> they seem to be *so* much nicer than 2681's, and they have that
> 16-byte buffer...

Gee, I was going to say the same, but given how the phone wires are
just cooling down from DaveR's response, I won't :-)

Doesn't anybody build a uart with a decent sized outbound FIFO that
understands hardware flow control?  Remember that a 16 deep FIFO
reduces the number of ugly uart interrupts by a factor of 12 or so!  I
would guess that most people will use the on-board uarts, rather than
the ones on the Ethernet board.  I really don't think cost should be
the issue here.  We're talking $1700-2000 for a fully populated 4MB
board, so I don't think we should be worrying about an extra $30/uart
(random number estimate).  If someone's looking for a rock-bottom
cost, they could always leave out some of the uarts.  I'd guess that
1/2 the CPU time spent driving Telebits (that DaveR was giving as part
of the justification for going to a 532) was servicing interrupts.
Personally I'd rather have 4 ports with FIFO & no hardware flow
control and 4 ports with no FIFO & hardware flow control than to
suffer all those interrupts.  (Actually *I'd* rather 8 with FIFOs),

The other nit is about memory parity.  Even if the O/S can't do
anything except throw in the towel when it discovers a parity error
(and I can think of several useful alternatives), I'd rather know I
had a problem.  (If YOU don't, a flipflop or jumper to remove to
disable it certainly wouldn't bother me.) I can understand you not
wanting to do ECC, and given the general reliability of memory these
days, I certainly can't disagree, but please, include parity in REV 2
of the board (9 bit SIMMs aren't much more than 8 bit, from my
browsing).

Last point. When, oh WHEN, can I get my hands on one of these!  I'll
happily send a small cheque today to reserve one, and pay the balance
early in '90!  (If I have one by the end of February, we might have a
kernel running on it by April.  Then all the ICM owners out there could
swap boards & start using the pc532!)

Excitedly,	../Dave

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Fri Nov 24 03:44:55 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Thu, 23 Nov 89 23:51:08 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: think!ames!mips!daver!dlr@EDDIE.MIT.EDU (Dave Rand)
To: mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Re: comments

[In the message entitled "Re: comments" on Nov 23, 16:15, Dave Mason writes:]
> > *Serial I/O*
> > 
> Gee, I was going to say the same, but given how the phone wires are
> just cooling down from DaveR's response, I won't :-)
*blush* Thanks - I just had to get that off my chest...

> 
> Doesn't anybody build a uart with a decent sized outbound FIFO that
> understands hardware flow control?  Remember that a 16 deep FIFO
> reduces the number of ugly uart interrupts by a factor of 12 or so!
I look at the Ethernet/Serial card as being 16 uarts each with a 2K
I/O buffer -and they understand flow control.

> cost, they could always leave out some of the uarts.  I'd guess that
> 1/2 the CPU time spent driving Telebits (that DaveR was giving as part
> of the justification for going to a 532) was servicing interrupts.
... and you would be wrong. Most of the time is spent handing messages
back and forth, copying the data, calculating checksums, etc.
"e" protocol (no handshaking) uses about 30 seconds of CPU time 
to transfer a 500K file over a 19.2K bps link. "g" protocol uses
about (going from memory here folks - go easy on me) 300-400 seconds
of CPU time. This is on my ICM-3216. On a 532 system when I was at
National, it seems to me that the CPU time was down in the 30 second
mark for "g" protocol.

The 2681's do have a 4 byte FIFO on RX, and I spent a *lot* of time
getting the drivers to work. First to work at all, then to get
3 ports to run at 19.2 without dropping characters. I do agree that
on the 32016 getting in and out of the interrupt routine is expensive,
but it can be minimized (and I have done this). On the 532, interrupts
are real cheap (in clocks).

Two things - I have improved drivers for both the serial ports and
the disk available for the ICM. If you want them, please send mail
to: dlr@daver.uu.net. In return, I would like to hear from someone
that has worked with the 8 port serial board, or the Ethernet board
set for the ICM.

> Last point. When, oh WHEN, can I get my hands on one of these!  I'll

If you really want one, you can get a bare board. We have about $600/ea
in these right now ( we have three bare boards left). 

We really should start plannng another run, I guess. In a week or so,
I'll be talking to NS again. No promises, so let's figure out how many
boards we will need, and then we can calculate a price. If someone knows
of a board house (or owns one :-) that can do a conservative 6 layer board
cheap - speak up now.

What I would like to see is a guess of how many boards each of you will
want... Thanks much!



-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Fri Nov 24 03:46:40 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Thu, 23 Nov 89 23:28 PDT
From: Mark Geisert <think!ames!mips!l66a.ladc.bull.com!Mark-Geisert@EDDIE.MIT.EDU>
To: mips!daver!pc532@EDDIE.MIT.EDU
Really-To: pc532%daver@uunet.UU.NET
Subject: FYI.. Mt Xinu's upcoming Mach distribution

I'll post the questionnaire mentioned in it only if somebody asks :-)
 
..mark
 
 
    Sent: 11/22/89 08:25  Rcvd: 11/22/89 08:25  Number: 569
      To: MARK GEISERT                            From: Alan Tobey
Reply To: alan@mtxinu.COM
 Subject: Mach from Mt Xinu
 
Thanks for your inquiry about Mt Xinu's Mach distributions.
 
A generic description of what we're doing appears between the lines
below, followed by answers to any more specific questions you raised.
We'll be sending full information and license agreements to you shortly.
 
If you still have questions, feel free to send further e-mail to
 
	mtxinu-mach@mtxinu.com or {uunet,ucbvax,sun}!mtxinu!mtxinu-mach
 
or call Noel Krenkel or Alan Tobey at (415) 644-0146
 
In a following message, we've sent a brief questionnaire about your interest
in Mach.  If you could spend a few minutes to fill this out and send it
back to us, it would greatly help us improve our plans for meeting your Mach
needs.  If you're too busy, or would prefer to treat it like junk mail,
no hard feelings.
 
_________________________________________________________________________
 
			MT XINU'S DISTRIBUTION OF
 
 			CMU MACH SOFTWARE FOR
 
 			SUN 3,  DEC VAX,  AND IBM RT PC
 
 
 WHAT IS BEING DISTRIBUTED?
 
 Mt Xinu  will distribute version 2.5 of Mach, supporting a 4.3BSD ("Berkeley
 UNIX") interface with such recent Berkeley changes as the "Tahoe" TCP/IP
 networking improvements.  Other software expected to be in the distribution
 includes NFS; X; the Andrew File System and Andrew Toolkit;  ISIS, a toolkit
 for building distributed and fault-tolerant applications;  and Camelot, a
 distributed transaction-processing system.
 
 WHY IS THIS COMING FROM MT XINU RATHER THAN CMU?
 
 Mt Xinu has a contract with Carnegie Mellon University to do the release
 engineering of Mach on the DEC VAX, Sun 3 and IBM RT PC in order to provide a
 standard, supported Mach distribution  for the research and development
 community.  Mt Xinu has been supporting 4BSD and other  system software for
 that community since 1982.
 
 WHEN WILL IT BE AVAILABLE?
 
 The first release is scheduled for late January, 1990.
 
 WHAT FORM WILL THE DISTRIBUTION TAKE?
 
 The distribution will be in source code form.  It will be completely self-
 contained and will boot on naked hardware.  All source code will be included,
 unless license problems force some parts to be binary-only.  Mt Xinu is not
 now announcing any binary-only distributions.
 
 WHAT LICENSES WILL BE REQUIRED?
 
 Recipients of the distribution must have an AT&T source code license --
 educational or commercial, System V Release 2 or newer.  Mt Xinu intends to
 be a "one-stop source" for as much of any other  required licensing as we
 can, but other licenses -- for example, a Sun NFS source license or Andrew
 File System license -- might also be required as a precondition for all or
 some parts of the distribution.
 
 WHAT WILL IT COST?
 
 Prices haven't been set, but  we expect to charge a "reasonable" and less-
 than-commercial price that's easily affordable by universities.  The final
 price will depend in part on whether  or not the originators of parts of the
 distribution require us to collect royalties for them.
 
 WILL SUPPORT BE AVAILABLE?
 
 As part of the initial purchase, Mt Xinu will provide installation support,
 plus minimal support thereafter via e-mail.  For those wanting more extensive
 support, Mt Xinu will likely offer a yearly support contract and can provide
 consulting for specific projects.
 
 WILL THERE BE UPDATES?
 
 A second release is scheduled for December, 1990.  We may make interim
 updates available to existing customers.
 
 WILL OTHER HARDWARE PLATFORMS BE SUPPORTED?
 
 Different groups are working on Mach for the DecStation 3100 (PMAX),  Sun 4,
 Macintosh II, HP 9000/300 and 80386.  We hope to include at least one of
 these in the second release, possibly replacing one or more of the original
 platforms.  We're not currently considering other hardware for this
 distribution.
 
 WHAT ELSE IS MT XINU DOING WITH MACH?
 
 We're porting Mach to some new processors, working with other companies
 developing Mach-based products, and designing commercial Mach products of
 our own.    We expect to make  product announcements later this year.
 
WHO IS MT XINU?
 
 Founded in 1982, Mt Xinu is a Berkeley, California software company
 specializing in technically-advanced UNIX system software for the research,
 development and higher-education communities.  We are most known for
 MORE/bsd, our enhanced and supported version of 4.3BSD which is available
 in source or binary form for HP 9000 and VAX computers.
 
_________________________________________________________________________

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Fri Nov 24 08:52:23 1989
Flags: 000000000001
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date:         Fri, 24 Nov 89 13:00:01 EET
From: Antti-Pekka  <think!ames!mips!MAMMUTTI.UTU.FI!T6T-VIRT@EDDIE.MIT.EDU>
Subject:      pc532 boards
To: mips!daver.uu.NET!pc532@EDDIE.MIT.EDU

Hi all ||
  I have built a '032 machine and am just about to get minix running.
(I am using Bruce Culbertson's port of minix)
I was delighted to hear that you have made already a '532 board.
I would like to know, what is the availability of that PCB
and how much does it cost| And, where to get more detailed schematics etc. ?



           Regards, Antti-Pekka


 AVIRTANEN@KONTU.UTU.FI   or   ANTSU@MEA.UTU.FI

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Fri Nov 24 22:24:18 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: SCSI channel capacity
To: mips!daver.uu.NET!tarpit!pc532@EDDIE.MIT.EDU
Date: Fri, 24 Nov 89 21:15:28 EST
From: John L. Connin <think!ames!mips!daver!uunet!manatee!johnc@EDDIE.MIT.EDU>
X-Mailer: Elm [version 2.1 PL1]


SCSI channel capacity:
----------------------

Pardon me, but my mind is still wrestling the implications of the
multi-master SCSI channel bandwidth.

Would it be possible to classify the SCSI channel capacity in terms
of IPC "message bandwidth" (not to be confused with SCSI protocol
'message phase') ?

Something like messages per second versus message size (say 1, 2, 4, 8,
 16, 32, ... , 1024 bytes) would certainly be helpful (at least to me).

Lets see, rate is 1 divided by the period.  In this case, ignoring
reconnection, the period would be:

   arbitration_phase_time +
     selection_phase_time +
       command_phase_time +
          data_phase_time = No_IPC_bytes * ( data_period + acknowledge_period ) +
        status_phase_time +
       message_phase_time +
 ---------------------------
        total_message_period        (of course, excluding software processing)


Assuming all periods remain constant, then:

      message_period = No_IPC_bytes * K1 + K2         (K1 and K2 constants)

or
                                1
      message_rate =  -----------------------
                       No_IPC_bytes * K1 + K1

Are my assumptions valid  ??   Is so, can either Dave or George
suggest reasonable values for the calculation.

Sorry to belabor an issue, but I am visualize using the pc532 in a
message intensive way (ie. numerous small 16-32 byte IPC messages
plus many block data transfers).

        -----------------------------------------------------

Change of Subject:

Perhaps getting the cart before the horse -- just spotted an attractive
price for Adaptek SCSI to QIC-36 adapter boards.  More specifically,

        Streaming tape controller, Adaptek Model ACB-3530a
        SCSI to QIC-36 .

        $39.95

        Gott Electronics
        2227 DuFour Ave
        Redondo Beach, CA  90278
        (213) 380-6287

I have a model ACB-3530ga and have had no problems.  I am not sure, but
I think 'ga' implies "gate-array" and is a shorter length board than the
'a' version.  The 'ga' version is the same size as the streaming tape
drive.  Recently I have seen Wangtek and Caliper tape drives selling 
for approximate $150.

Best regards,
johnc


From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Sat Nov 25 00:24:37 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Fri, 24 Nov 89 20:22:09 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: think!ames!mips!daver!dlr@EDDIE.MIT.EDU (Dave Rand)
To: mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Re: SCSI channel capacity

[In the message entitled "SCSI channel capacity" on Nov 24, 21:15, John L. Connin writes:]
> 
3.0 usec>    arbitration_phase_time + (incl min. bus free of 800 ns)
1.2 usec>      selection_phase_time +
[       >        command_phase_time +
265 ns  >           data_phase_time = No_IPC_bytes * ( data_period + acknowledge_period ) +
per byte>         status_phase_time +
]       >        message_phase_time +
        >  ---------------------------
        >         total_message_period        (of course, excluding software processing)
Sounds good. The big time in here is the 2.2usec SCSI arbitration delay, and
the min. bus free of 800 ns. Of course, you can choose to ignore these times
if you do all the scsi devices yourself. 

If you don't, and assuming a 6 byte SCSI command (why?), and 2 byte status/
message, then your minimum per-packet time is 6.32 usec, plus data bytes.
When applied to 16 byte packets, this works out to 10.56 usec, or about
95K packets per second (about 1.5 megabytes per second).

You can increase the PPS value by reducing the command phase (since this is
user-defined, unless you want to communicate with hard drives and the like)
by reducing the number of command bytes sent. You can also choose to change
or eliminate the 3 usec arbitration time, and drop straight into the
selection phase (this is what the old SASI controllers did).

But, again, why? My initial plan for the Ethernet board, for example,
is to poll every 10 milliseonds or so, and burst whatever needs to go
at that time. This keeps the data transfer rate high, and the overhead
low (only 200 packets per second max, none if there is no data to go).

I am _very_ interested in working with this system as a distributed
processing environment, as well. This is a "pet project" of both
George and I - something we have been considering for many years
now. Right now we have one of the boards wired into a spare PC
with a SCSI board in it, and I'm doing some software to use some
of the resources of the host PC...

More as it comes.

-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Sat Nov 25 16:46:32 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: SCSI channel example / calc
To: mips!daver.uu.NET!tarpit!pc532@EDDIE.MIT.EDU
Date: Sat, 25 Nov 89 15:18:55 EST
From: John L. Connin <think!ames!mips!daver!uunet!manatee!johnc@EDDIE.MIT.EDU>
X-Mailer: Elm [version 2.1 PL1]


 SCSI channel example
=======================


Analysis of AMOEBA style remote reads over SCSI channel.
---------------------------------------------------------

I trust the following is generally self-explainatory.


#define BLOCK_SIZE  1024


  int  fd;
  int  n, m;
  char buf[ BLOCK_SIZE];

  fd = open(REMOTE,2)
  set_device( __  )       /* set raw mode, etc */

  while (1) {
	n = read(fd1, buf, BLOCK_SIZE);
	if (n < 0) quit();
	if (n == 0) return;
        m = write(fd2, buf, n);
        if (m != n) quit();
   }



At the driver level, the read results in three actions
    o  request to remote
    o  reply from remote
    o  acknowlegement to remote



Case 1:  REMOTE is a serial port which hypotically returns one
-------  character on each read.


For simplicity, assume each action is 16 bytes inclusive of data.

         10.56 usec =   16 bytes * 265 nsec / byte + 6.32 usec
         10.56 usec =   16 bytes * 265 nsec / byte + 6.32 usec
         10.56 usec =   16 bytes * 265 nsec / byte + 6.32 usec
   -----------------
         31.68 usec / char

Assuming no other overhead, we receive at 33.33 kbytes / sec from the remote.


Case 2:  REMOTE is a file which hypotically returns BLOCK_SIZE
-------  characters on each read.


Again for simplicity, assume each action is 16 bytes inclusive of data,
except for the reply which is 16 + 1024 bytes.

         10.56 usec =   16 bytes * 265 nsec / byte + 6.32usec
        275.60 usec =  (16 byte + 1024 bytes) * 265 nsec / byte + 6.32 usec
         10.56 usec =   16 bytes * 265 nsec / byte + 6.32usec
   -----------------
        281.92 usec / block

Again assuming no other overhead, we receive at 3.54 Megabytes / sec from
the remote


Observation:
------------

Assuming I have not make a error, block transfers look  OK provide
there is not too much other channel activity.  However, the
the character transfer rate seems to me inadequate.


Attachment:
-----------

Illustration of a remote server.  The code is /minix/amoeba/examples/client3.c
and /minix/amoeba/examples/server3.c.  The following narriative is from an
associated read_me file written by AST.


best regards..
johnc
        --------------------------------------------------------

[ stuff deleted ]

3. Test 3 is an example of how one might go about making a remote file server
   for MINIX to service diskless PCs.  In this approach, one writes a server,
   server3.c in this example, and a set of library routines, contained in
   client3.c.  These library routines should have the same names as the MINIX
   system calls, such as open(), read(), and write().  When programs are linked
   with these routines instead of the usual ones, the routines make calls to
   the remote file server instead of FS.  The file client3.c contains not only
   a few of these library routines, but also a short main program to test them.
   The main program fetches a file from the remote file server and copies it to
   stdout.  To test the program, type:

	make client3 server3
	server3 &
	client3 <filename>

   where <filename> is the name of a file on the same machine as server3.  The
   result of this command will be that <filename> is written to client3's 
   standard output.



/* client3.c */

/* This file shows how one could build a remote file server for MINIX.
 * In this file there are several library routines for the basic system
 * calls.  Unlike the "real" ones, these call a remote file server instead
 * of the local kernel.  On client machines, one would replace the library
 * routines with these routines, and then recompile programs.  In this way,
 * clients will then call the remote file server.  It should be obvious that
 * this file is just an example, and that a productio version would have to
 * be much more complete.
 *
 * The file server3.c contains the start of a stateless file server.  Because
 * MINIX is not stateless, the conversion must be done in this library.  For
 * example, when an open() is done, the library records the name, but no
 * operation is performed on the file server.
 *
 * An alternative approach to making a remote file systems is to replace FS, 
 * the local file server, with one that makes the calls to the remote file 
 * server itself.  This approach is less efficient, because a call then 
 * consists of a local FS call plus a remote one, but it is more transparent 
 * because no programs need to recompiled.
 */

#include <amoeba.h>
#include <errno.h>
#include <minix/callnr.h>
#include "header.h"

#define MAX_FD 20
#define LOCAL 100
#define HEAPSIZE 512			/* space for file names */
#define WRITING 2
#define ER -1
#define FS 1
#define NIL_PTR (char*) 0

/* The local array is indexed by file descriptor.  Those entries containing
 * LOCAL are local (e.g., stdin), those containing REMOTE are remote, and
 * those containing 0 are unassigned.
 */

char where[MAX_FD] = {LOCAL, LOCAL, LOCAL};
long pos[MAX_FD];			/* current offset */
char *server_name = "filsrv";
char *file_name[MAX_FD];

char heap[HEAPSIZE];
char *heap_ptr = heap;
header hdr1, hdr2;
char buffer[BUF_SIZE+NAME_SIZE];

extern int errno;


/*============================= Remote Library ==============================*/
int open(name, how)
char *name;
int how;
{
/* Open is entirely local. */

  int i, len;

  if (how < 0 || how > 2) { errno = EINVAL; return(ER);}

  /* Find a free file descriptor. */
  for (i = 0; i < MAX_FD; i++) {
	if (where[i] == 0) {
		len = strlen(name);
		file_name[i] = heap_ptr;
		bcopy(name, heap_ptr, len);
		heap_ptr += len;
		*heap_ptr++ = 0;
		where[i] = how+1;
		return(i);
	}
  }
  errno = EMFILE;
  return(ER);
}
  
int creat(name, mode)
char *name;
int mode;
{
/* Create a file. */

  int i, len, n;

  /* Find a free file descriptor. */
  for (i = 0; i < MAX_FD; i++) {
	if (where[i] == 0) {
		len = strlen(name);
		file_name[i] = heap_ptr;
		bcopy(name, heap_ptr, len);
		heap_ptr += len;
		*heap_ptr++ = 0;
		where[i] = WRITING;

		strncpy(&hdr1.h_port, server_name, PORTSIZE);
		hdr1.h_command = CREAT;
		hdr1.h_size = mode;
		n = trans(&hdr1, file_name[i], len+1, &hdr2, buffer, 0);
		if (n < 0) {errno = EIO; return(ER);}
		return(hdr2.h_status);
	}
  }
  errno = EMFILE;
  return(ER);
}
  

int close(fd)
int fd;
{
/* Close a file. */

  if (where[fd] == LOCAL) return(Xclose(fd));
  if (where[fd] == 0) {errno = EBADF; return(ER);}
  where[fd] = 0;
  return(OK);
}


int read(fd, buf, bytes)
int fd, bytes;
char buf[];
{
/* Primitive read() routine for reads up to 1K. */

  int n;

  if (where[fd] == LOCAL) return (Xread(fd, buf, bytes));
  if ((where[fd]&1) == 0) {errno = EBADF; return(ER);}
  if (bytes > BUF_SIZE) return(EINVAL);	/* in a real version, fix this */
  strncpy(&hdr1.h_port, server_name, PORTSIZE);

  hdr1.h_command = READ;
  hdr1.h_size = bytes;
  hdr1.h_offset = pos[fd];
  n = trans(&hdr1, file_name[fd], strlen(file_name[fd])+1, &hdr2, buf, bytes);
  if (n < 0) {errno = EIO; return(ER);}
  if (hdr2.h_extra != 0) errno = hdr2.h_extra;
  pos[fd] += hdr2.h_status;		/* advance file position */
  return(hdr2.h_status);
}


int write(fd, buf, bytes)
int fd, bytes;
char buf[];
{
/* Primitive write() routine for writes up to 1K.  This is a very simple
 * routine.  Because the server is stateless, for a write we must send both
 * the data and the file name.  In this example, the first 1K of the buffer
 * is reserved for the data, with the file name starting at position 1024.
 */

  int n, len;

  if (where[fd] == LOCAL) return (Xwrite(fd, buf, bytes));
  if ((where[fd]&02) == 0) {errno = EBADF; return(ER);}
  if (bytes > BUF_SIZE) return(EINVAL);	/* in a real version, fix this */
  strncpy(&hdr1.h_port, server_name, PORTSIZE);

  len = strlen(file_name[fd]);
  hdr1.h_command = WRITE;
  hdr1.h_size = bytes;
  hdr1.h_offset = pos[fd];
  bcopy(buf, buffer, bytes);		/* copy data to message */
  bcopy(file_name[fd], &buffer[BUF_SIZE], len+1);
  n = trans(&hdr1, buffer, BUF_SIZE+len+1, &hdr2, buf, 0);
  if(n < 0) {errno = EIO; return(ER);}
  if (hdr2.h_extra != 0) errno = hdr2.h_extra;
  pos[fd] += hdr2.h_status;
  return(hdr2.h_status);
}




/* Below are the real calls, which are sometimes needed. */

int Xread(fd, buffer, nbytes)
int fd;
char *buffer;
int nbytes;
{
  int n;
  n = callm1(FS, READ, fd, nbytes, 0, buffer, NIL_PTR, NIL_PTR);
  return(n);
}

int Xwrite(fd, buffer, nbytes)
char *buffer;
int nbytes;
{
  return callm1(FS, WRITE, fd, nbytes, 0, buffer, NIL_PTR, NIL_PTR);
}


int Xclose(fd)
int fd;
{
  return callm1(FS, CLOSE, fd, 0, 0, NIL_PTR, NIL_PTR, NIL_PTR);

}


/* ========================= test program =============================*/
main(argc, argv)
int argc;
char *argv[];
{
  int fd1, n;
  char b[1024];

  if (argc != 2) {
	printf("Usage: client3 file\n");
	exit(1);
  }

  fd1 = open(argv[1], 0);
  if (fd1 < 0) {
	printf("Open of %s failed\n", argv[1]);
	exit(1);
  }

  do {
	if ((n=read(fd1, b, 1024) < 0)) {
		printf("Cannot read %s\n", argv[1]);
		exit(1);
	}
	if (write(1, b, n) < 0) {
		printf("Cannot write stdout\n");
		exit(1);
	}
  } while (n > 0);
}


/* server3.c */

#include <amoeba.h>
#include <minix/callnr.h>
#include <errno.h>
#include "header.h"

header hdr;				/* header for incoming messages */
char buffer[BUF_SIZE+NAME_SIZE];	/* buffer for incoming messages */
char *server_name = "filsrv";
int repsize;
extern int errno;

main()
{
/* This is a primitive file server.  The client runs with a special set of
 * routines for read(), write(), etc. that call this server.  The server is
 * stateless.
 */

  int s;
  int count;
  unshort opcode, size;

  strncpy( (char *) &hdr.h_port, server_name, PORTSIZE);  /* init port */

  while (1) {
	/* Wait for a request to arrive. */
	count = (short) getreq(&hdr, buffer, MAX_TRANS);
	if (count < 0) {
	    printf("Server's getreq failed. Error = %d.   ", count);
	    printf("Hit F1 to see if AMTASK running.\n");
	    exit(1);
	}
	
	/* Dispatch on opcode. */
	opcode = hdr.h_command;
	repsize = 0;
	errno = 0;
	switch(opcode) {
		case CREAT:	s = do_creat();		break;
		case READ:	s = do_read();		break;
		case WRITE:	s = do_write();		break;
		default:	s = EINVAL;		break;
	}

	/* Work done.  Send a reply. */
	hdr.h_status = (unshort) s;
 	hdr.h_extra = (unshort) errno;
	putrep(&hdr, buffer, repsize);
  }
}

int do_read()
{
  /* Stateless read. */

  int fd, n;
  long offset;
  unshort count;

  offset = hdr.h_offset;
  count = hdr.h_size;
  if (count > MAX_TRANS) count = MAX_TRANS;

  fd = open(buffer, 0);		/* open the file for reading */
  if (fd < 0) return(errno);
  lseek(fd, offset, 0);
  n = read(fd, buffer, count);
  close(fd);
  repsize = n;
  return(n);
}

int do_write()
{
  /* Stateless write. */

  int fd, n;
  long offset;
  unshort count;

  offset = hdr.h_offset;
  count = hdr.h_size;
  if (count > MAX_TRANS) count = MAX_TRANS;

  fd = open(&buffer[BUF_SIZE], 2);		/* open the file for writing */
  if (fd < 0) return(errno);
  lseek(fd, offset, 0);
  n = write(fd, buffer, count);
  close(fd);
  return(n);
}

int do_creat()
{
  /* Stateless creat. */

  int fd, n, mode;
  

  mode = hdr.h_size;
  fd = creat(buffer, mode);		/* creat the file  */ 
  close(fd);
  return(fd);
}


From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Sat Nov 25 17:44:42 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Sat, 25 Nov 89 14:00:16 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: think!ames!mips!daver!dlr@EDDIE.MIT.EDU (Dave Rand)
To: mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Re: SCSI channel example / calc

[In the message entitled "SCSI channel example / calc" on Nov 25, 15:18, John L. Connin writes:]
> At the driver level, the read results in three actions
>     o  request to remote
>     o  reply from remote
>     o  acknowlegement to remote
> 
> Case 1:  REMOTE is a serial port which hypotically returns one
> -------  character on each read.
> 
>          31.68 usec / char
> 
> Assuming no other overhead, we receive at 33.33 kbytes / sec from the remote.

Yup. Looks like this is a good way not to do things over the SCSI. My intent
was (and is) to block requests for transmission every 10-20 msec. That way,
we get more data transferred per block, and less overhead. There is (should
be?) no need to ACK the remote. You can use STATUS/MESSAGE phase for this.
One transaction, with all the data queued, would be all that is required.

Let's assume we have 1 serial port active, at 19.2K bps. Every 10 msec,
we pack up the data, and send it off to the pc532. We get 100 transactions
per second (assuming incoming data only). Every 10 msec, we get nearly
20 characters, so we will assume (actually 19.19).

         12.415 usec =   23 bytes * 265 nsec / byte + 6.32usec

Or an effective rate of 1.61 meg per second.

Now, let's assume a *busy* system. 14 telebits, at 19.2 running g protocol.
2 interactive users on the other 2 ports, at 38.4 doing large cat's. No
ethernet activity. (This gets hard). Each telebit is incoming, so we get
1,920 characters per second incoming. To maintain this, we have to send
27.4 acks back out per second, per channel (at 6 bytes each), for 165
characters per second per channel. This is 26,880 chars per second
incoming, and 2310 per second outgoing for the Telebits. Add 7680 per
second for the interactive users. Now... each packet, at a 10 msec rate
>From the Ethernet board would contain 269 characters, plus mux overhead
(3 bytes/channel):

         88.735 usec =   311 bytes * 265 nsec / byte + 6.32usec

Or an effective rate of 3.03 meg per second.

Outgoing, we have 100 bytes per packet, plus mux overhead:

         45.54 usec =   148 bytes * 265 nsec / byte + 6.32usec

Or an effective rate of 2.20 meg per second.

*AND* We are using 13.43 msec of bus every second. A whopping 1.3 %
of the bus. 

Now. Add on fully saturating the Ethernet (625K/sec in and out), and
we are still only using about 33% of the bus. In reality, all the
Ethernet data would not be crossing the SCSI, as we would be
doing IP (at least) on the board.

The pc532 has a SCSI bus. You have to re-think how you do protocols in
order to get maximal use of the bus. But then again, that is
the fun!

Make *maximum* use of local processing power. We don't have to poll,
and we don't have to acknowledge (if we can't take the data, we will
use the status/message phase to tell the remote, or simply not respond
to the SEL). Packetize things. It's *always* a win to process more than
one byte at a time. Even in my serial drivers, I have more than one
character (if possible) ready for the upper layers before I wake them
up.

Note that this does not sacrifice interactive speed. If the interactive
speed is not "fast enough", then go to 5 msec packet bursts. Don't
send packets if they aren't required. Stuff like that...



-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Sun Nov 26 21:27:41 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: SCSI example 2
To: mips!daver.uu.NET!tarpit!pc532@EDDIE.MIT.EDU
Date: Sun, 26 Nov 89 19:28:35 EST
From: John L. Connin <think!ames!mips!daver!uunet!manatee!johnc@EDDIE.MIT.EDU>
X-Mailer: Elm [version 2.1 PL1]


Generally I feel uncomfortable with polling bus boards or doing other
'special' things.  It seems to me that implementing 'special' schemes
moves the SCSI channel away from being a general-purpose multi-master bus
towards a special-purpose host IO bus.

Anyway, I decided to re-examine my previous posting "SCSI channel example"
in-light of Dave's response to this message.  What I came up with this
time is outlined below.  Under the assumptions outlined, the results
feel *much* more promising.  The key appears, as Dave has points out,
utilizing intelligent buffering schemes so as to not overload the
SCSI channel with single character activity.  While at the same time
guaranteeing that low rate input such as keyboards are passed quickly
enough that the system appears responsive.




        -----------------------------------------------------

Revisions / changes in assumptions:
-----------------------------------

a) Header size is 32 bytes not 16 bytes as previously assumed.


MINIX Amoeba packet header:


/* extracted from amoeba.h */

#define PORTSIZE         6
#define OOBSIZE         20
#define HEADERSIZE      32
#define PRIVSIZE        10
#define CAPSIZE         16

typedef struct {
        char    _portbytes[PORTSIZE];
} port;

struct _fakeport {
        long    _p1;
        short   _p2;
};

typedef struct {        /* private part of capability */
        char    prv_object[3];
        char    prv_rights;
        port    prv_random;
} private;

typedef struct {
        port    cap_port;
        private cap_priv;
} capability;

typedef struct {
        port    h_port;
        port    h_signature;
        private h_priv;
        unshort h_command;
        long    h_offset;
        unshort h_size;
        unshort h_extra;
} header;



b) Assume the header totally replaces the SCSI command header
   which was previously assumed to be 6 bytes -- overall
   net increase in size, 10 bytes = 32 - (16 + 6).

c) Assume serial device has characteristics similar to 16550,
   ie. collects characters in FIFO until FIFO high-water mark is
   reached or a time period has elasped.

d) Assume FIFO high-water mark / time period is 16 characters / 8.33 msec.
   8.33 msec corresponds to a 16 characters at 19200 baud.

e) Assume that for low rate input such as keyboards, a 8.33 msec
   'hold' time will yield acceptable performance -- ie. the delay will
   not be perceptible to the user.


New CASE:  Assume a telebit receiving a large file at 19.2 kilobits / second.
---------

overhead is:

        3.0 usec   arbitration_phase_time + (incl min. bus free of 800 ns)
        1.2 usec    selection_phase_time
        ---------
        4.2 usec

scsi bus periods are:

read request      12.60 usec =  32 bytes * 265 nsec / byte + 4.20 usec
read reply        16.92 usec =  48 bytes * 265 nsec / byte + 4.20 usec
read ack          12.60 usec =  32 bytes * 265 nsec / byte + 4.20 usec
                  ------------
total             42.14 usec


In other words every 8.33 msec we need to spend 42.14 usec on the SCSI
channel to read-reply-acknowledge the serial-in FIFO.

This result seems to feel comfortable -- only 0.50 percent of the SCSI
channel capacity is utilized.



My favorite question, what if the SCSI bus was extended to 16 or 32 bits:
-------------------------------------------------------------------------

The overhead remains the same at 4.2 usec for arbitration - selection.

Data bytes become data-words / data-dwords.

At 16 bits, the scsi bus periods are:

read request       8.44 usec =  16 words * 265 nsec / byte + 4.20 usec
read reply        10.65 usec =  24 words * 265 nsec / byte + 4.20 usec
read ack           8.44 usec =  16 words * 265 nsec / byte + 4.20 usec
                  ------------
total             27.53 usec


At 32 bits, the scsi bus periods are:

read request       6.32 usec =   8 dwords * 265 nsec / byte + 4.20 usec
read reply         7.38 usec =  12 dwords * 265 nsec / byte + 4.20 usec
read ack           6.32 usec =   8 dwords * 265 nsec / byte + 4.20 usec
                  ------------
total             20.02 usec




From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Mon Nov 27 00:13:50 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
From: think!ames!mips!sibyl.eleceng.ua.oz.au!ian@EDDIE.MIT.EDU
Date: Mon, 27 Nov 89 03:05:28 +1100
To: mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Design and commitment.

I am very interested in this project. The use of the SCSI bus as a general
system bus sounds interesting and the arguments in favour of that decision
have me convinced it is a viable way to go.

I am a little unsure of the variants of SCSI around now. Are Async and Sync
SCSI compatible (say by falling back to Async automatically)? What about
SCSI II? Can I test/run peripheral cards on my ICM?

I am not happy however about the lack of memory parity checking. I
might have believed it was useless until recently. I upgraded my ICM
3216 from 2MB to 4MB and I started getting memory parity faults (and
system panics). Curiously enough, the ROM based memory test program
could find nothing wrong, but every time I brought Unix up it would
crash after some indeterminate period. Most agravating. It seems that
the chips had some kind of refresh problem and that continuously
testing them with the memory test program caused them not to fail.
Unix fell over frequently if it was left for a while without being
used.  Replacing the Goldstar chips with TI chips fixed the problem.
The point I am making is that without the parity error panics, I would
never have tracked this down.

OK, if the memory test program had tested better for this kind of
failure it would have been better, but how do you know if your memory
test program is good enough if you have undetected errors?

Count me in as a definite maybe for the boards! It depends on how much
the price comes down with volume. Also, the amount I can justify
spending, depends on how usable it is (which means software). I can
spend a few hundred on a toy, but if I spend a few thousand it has to
be useful! Unless I can run emacs, tex, X etc, then I would get more
use from my ICM, even if it is one tenth the speed! Basically I
consider Unix (or an emulation such as is provided under Mach) as
essential. Also I am a bit sick of Sys V.2. This is not a matter of
religion, it is a matter of how easilly I can get the code I want
working! I am willing and interested in helping with operating system
code but as always we keep returning to the perenial problem of source
licences.


From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Mon Nov 27 02:48:51 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Sun, 26 Nov 89 22:38:32 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: think!ames!mips!daver!dlr@EDDIE.MIT.EDU (Dave Rand)
To: mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Re: Design and commitment.

[In the message entitled "Design and commitment." on Nov 27,  3:05, uunet!munnari!sibyl.eleceng.ua.oz.au!ian writes:]
> I am a little unsure of the variants of SCSI around now. Are Async and Sync
> SCSI compatible (say by falling back to Async automatically)? What about
> SCSI II? Can I test/run peripheral cards on my ICM?
Sync and async are compatible on the same bus. It is an arbitrated option
between the target and initiator. I don't know enough about SCSI II to
comment - can someone else help out?

> 
> I am not happy however about the lack of memory parity checking. I
> might have believed it was useless until recently. I upgraded my ICM
> 3216 from 2MB to 4MB and I started getting memory parity faults (and
Sigh. I just went through this myself. Turns out that:

1) The parity logic was not being tested by the ICM software under UNIX.
2) The the logic in the kernel is wrong about determining the address.

I fixed problem #1:
>From wombat!daver Sat Nov 18 14:44:02 1989
Return-Path: <wombat!daver>
Received: by daver.uu.net (/\=-/\ Smail3.1.17.5 #17.13)
	id <m0gSdmo-0000mbC@daver.uu.net>; Sat, 18 Nov 89 14:43 PST
Received: by wombat.UUCP (smail2.5)
	id AA04211; 18 Nov 89 14:40:53 PST (Sat)
To: bill@bct, dlr@daver
Subject: parity error fix:
Message-Id: <8911181440.AA04211@wombat.UUCP>
Date: 18 Nov 89 14:40:53 PST (Sat)
From: daver@wombat.UUCP (Dave Rand)

adb -w /unix
_nmi_type,4?i
_nmi_type?W 0a815005f
_nmi_type,4?i




This changes the:
	movb	a000c0,r0	to
	movw	a000c0,r0

and causes all the nice logic in the kernel to be *USED* when a parity error
is found.

Arrgh.

Dave

-------

Two designs that we have done have had parity logic on them (for Unix).
Neither one was used (until the issue was forced!)

The pc532 uses SIMMs. You have a much lower failure rate on SIMMs than
dips. Agreed - lower is not zero. So this weekend (long weekend in the
US), George tried to add parity to the board. This is what we came
up with:

1. Parity error logic adds a minimum of 10 chips.
2. This adds at least one wait on writes, and probably one on reads.
3. There are 45 chips on the board. Uarts and all. Adding 10 chips
   will decrease the MTBF.
4. Adding parity will increase the chance of a parity error by 1/9 th.
5. Parity will only detect a single bit error. ECC or other correction
   mechanism will greatly increase the complexity of the board, and
   again, increase the probability of an error.
6. The memory test on the ICM in rom is _very_ simple, and will not
   detect most failure mechanisms (other than very gross chip-not-present
   errors).

Parity is a good "safety net", especially while you are bringing up a
system, and are uncertain about the design. With 4 SIMM's in the PC532,
there are only 4 "devices" to fail.

IN MY EXPERIENCE: I have run UNIX on systems with and without parity. 
I have not encountered a situation where the parity would have saved me.
Unix can only crash (without significant modifications) when it gets
a parity error. Applications may crash without paririty (especially
on poor memory designs). Applications may crash with parity. I believe
that parity is not worth it on large memory arrays, and that ECC
is too expensive (in $$ and wait states) for a board like the pc532.

Besides (on the lighter side :-), according to the NS32532 data sheet:
"Life Support Policy

National's Products are not authorized for use as critical components in life
support devices or systems without the express written approval of the
president of National Semiconductor Corporation."

If someone can come up with a good parity design that can identify the
failing SIMM (even via a LED or something),  please let us know. George
can't find a good way to do it, without impacting performance and board
space.

> working! I am willing and interested in helping with operating system
> code but as always we keep returning to the perenial problem of source
> licences.
> 
John Weber dropped by this evening with a tape. I am looking _very_
seriously at alternative operating systems, and such. Currently, I have
the board running a simple operating system, and an Assembler/Linker.
If you are interested in running some non I/O benchmarks (I don't have
the filesystem running currently), I can run them now. With a little
work, I will be able to get millisecond accuracy, but I would
appreciate it if you kept them "stopwatchable" (ie. to the second).


As always, please let us know your comments.

-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Mon Nov 27 03:43:12 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Mon, 27 Nov 89 00:06:46 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: think!ames!mips!daver!dlr@EDDIE.MIT.EDU (Dave Rand)
To: mips!daver.uu.net!pc532@EDDIE.MIT.EDU
Subject: lateral thinking

So. Parity checking is too expensive in hardware. ECC is Really to
expensive. Now what? We don't want to trust the RAM, and we don't want
to add cost/unreliability to the design.

Why not do CRC in software, on a per-page basis?

Page size is 4K. If the modified bit is set, recalculate the CRC. When
we are bored, run around and check the CRC. Simple (crude) CRC
checking would take about 10 clocks per byte. Simple parity would take
less than 4 clocks per doubleword - less if you push it. A straight
XOR would be 2 clocks per double - same for ADD.

If there is one thing we have in abundance, it is CPU grunt. Let it
do the work. A 4 byte CRC/checksum for 4 Megabytes/4k pages would be
4K bytes. We can run the "memory scrubber" in the idle loop, so as
not to take away time from the user processes - or we can devote
(via a regular scheduled task) a percentage of the CPU to do memory
scrubs.

I believe that RAM is more reliable than disk. Disk works fine with
CRC - but for the paranoid, we can use an agressive Reed-Solamon
code.


-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Mon Nov 27 17:11:23 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Mon, 27 Nov 89 12:09:15 PST
From: think!ames!mips!daver!sun!wrs!yuba!hwajin@EDDIE.MIT.EDU (Hwa Jin Bae)
To: mips!daver.uu.net!pc532@EDDIE.MIT.EDU
Subject: SCSI channel example / calc

Folks,

>Now. Add on fully saturating the Ethernet (625K/sec in and out), and
>we are still only using about 33% of the bus. In reality, all the
>Ethernet data would not be crossing the SCSI, as we would be
>doing IP (at least) on the board.

Which implementation of IP are you planning to use?  Are you writing
your own implementation or a version of 4.3 BSD implementation or
KA9Q?  I'm just curious.

Also, I'm not too sure about just running IP on the board itself.  
Doing this will increase the amount of data to be sent over the bus
since the IP header will need to be attached to the ethernet frame
before being sent over the bus.  The savings gained by using the
local CPU for IP processing won't be significant enough to cancel
out the bus traffic increase.

Some implementations do run the whole TCP/IP and most of the socket code 
on the ethernet boards (i.e. Excelan).  This method is effective
only if: (a) the on-board CPU is fast (almost as fast as the main CPU),
which is true in our case, and (b) the amount of data passed over
the bus and the number/frequency of data transfers are reduced 
significantly, which is true only if you run the whole TCP/IP+socket 
code on the ethernet board.

If (a) is not true (i.e. Excelan's 80186 (slow) + 82586 based board),
the TCP/IP performance suffers due to the slow speed of the TCP/IP
protocol handling on slow CPU.  The (b) is not true, the benefit
of processing protocols on local CPU is compromised at best; it's
more likely that you'll have more traffic on the bus.  It's really
important to draw the boundary at the right place when deciding
which part of TCP/IP to put on the ethernet board.  If the whole
TCP/IP and socket code is put on the ethernet board, the main 
CPU only needs to run a small driver that will poll the socket data
>From the ethernet board and copy it to the user space, which saves
the number of packet transmissions over the bus (IP fragments,
TCP segments are not passed over the bus at all.  Only the
full user data is passed over the bus) as well as the amount of
data (the protocol headers are not passed over the bus).

Unfortunately, this is not really is so easy to do with 4.3 TCP/IP. 
Porting 4.3 BSD TCP/IP code requires a number of Unix style kernel 
level code (spl*()'s, timeout(), sleep(), wakeup(), mbuf's, 
clusters, etc.) emulation; the OS running on the ether-board's 32532
needs to become fairly sophisticated.  Do we want this?

On the other hand, the latest KA9Q code has BSD compatible socket 
support and it is much more portable and smaller (runs on MS-DOS)
so it may be a better candidate for an implementation of TCP/IP
that runs on the ethernet board.  The KA9Q TCP/IP implementation is 
quite good (lots of interesting optimizations in TCP code, etc.)
and bug free.  The socket code looked pretty good too.  This
package also contains a small non-preemptive tasking kernel for handling 
multiple TCP/IP sessions (implemented portably -- using setjmp()
and longjmp(), etc).

BTW, thanks for all the informative articles.  This mailing-list
is one of the most informative ones I've ever subscribed to.

hwajin
---
Hwa Jin Bae
Wind River Systems, 1351 Ocean Avenue, Emeryville, CA 94608

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Mon Nov 27 18:01:06 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Mon, 27 Nov 89 13:46:46 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: think!ames!mips!daver!dlr@EDDIE.MIT.EDU (Dave Rand)
To: mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Re: SCSI channel example / calc

[In the message entitled "SCSI channel example / calc" on Nov 27, 12:09, Hwa Jin Bae writes:]

> Which implementation of IP are you planning to use?  Are you writing
> your own implementation or a version of 4.3 BSD implementation or
> KA9Q?  I'm just curious.
I have written a partial IP/UDP implementation which is running on some
custom hardware that we have built around a 32CG16 and an Ethernet.

I think I would prefer to use the KA9Q. I have a "not recent" version,
and will be picking up the more recent one before implementing.

> Some implementations do run the whole TCP/IP and most of the socket code 
> on the ethernet boards (i.e. Excelan).  This method is effective
> only if: (a) the on-board CPU is fast (almost as fast as the main CPU),
> which is true in our case, and (b) the amount of data passed over
> the bus and the number/frequency of data transfers are reduced 
> significantly, which is true only if you run the whole TCP/IP+socket 
> code on the ethernet board.
I am aiming for running the whole socket interface on the board. As
you point out, since we are running a 32GX32 on the Ethernet board,
we will have ample CPU time.

> BTW, thanks for all the informative articles.  This mailing-list
> is one of the most informative ones I've ever subscribed to.
> 
> hwajin
> ---
> Hwa Jin Bae
> Wind River Systems, 1351 Ocean Avenue, Emeryville, CA 94608
> 

I'm also learning a lot, by listening to the other folks here.
By the way, I'm counting on you to do the NFS implementation!


-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Tue Nov 28 11:19:38 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Mon, 27 Nov 89 14:45:45 PST
From: think!ames!mips!daver!sun!wrs!yuba!hwajin@EDDIE.MIT.EDU (Hwa Jin Bae)
To: mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: SCSI channel capacity

Folks,

>I am _very_ interested in working with this system as a distributed
>processing environment, as well. This is a "pet project" of both
>George and I - something we have been considering for many years
>now. Right now we have one of the boards wired into a spare PC
>with a SCSI board in it, and I'm doing some software to use some
>of the resources of the host PC...

I'm certain that some of you already know this but 
MINIX kernel is based on the message passing architecture (like Mach).
There are three processes -- process control, filesystem, and
memory manager -- that communicate with one another via a set
of short messages.  This means that if you reimplement the
message passing primitives (routines) to either use the
SCSI bus or shared memory or network, you can have any
one of these processes on a remote machine.  If you put the
filesystem process on a remote machine which has a ethernet
board with TCP/IP and implment the message passing routines
to use the TCP/IP to talk with that remote filesystem process,
you have implemented a truely transparent network filesystem which
supports full local filesystem semantics.  Putting the memory
manager on a remote machine the same way boggles my mind.

I've implemented network drivers for Motorola Delta Box Unix V.3
TCP/IP, one of which was a STREAMS driver that sits below the
IP multiplexor module (i.e. linked to it via I_LINK message)
and emulated the behaviors of ethernet on the VME bus backplane
using dual-ported shared memory on the CPU.  Using this driver,
you can access other CPU boards on the VME backplane via sockets
using TCP/IP -- rlogin, rsh, NFS, etc. all worked transparently
over the backplane.  We could do the same thing over SCSI.

hwajin


From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Tue Nov 28 11:20:37 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
To: mips!ames.arc.nasa.gov!daver!pc532@EDDIE.MIT.EDU
Subject: More on software memory protection...
Date: Mon Nov 27 17:10:46 1989
From: think!ames!mips!ucscc.UCSC.EDU!clanhlm!blank@EDDIE.MIT.EDU


	I don't know too much about DRAM failure modes -- maybe someone 
	out there could correct any mistakes I am about to make...

	Looking at my TI MOS memory data book, it seems that there are
	only a few (simple) failure modes on a DRAM.  You can get a soft
	error in one bit, you can get a hard error in one bit, you can
	get a row decoder failure, you can get a column failure, and you
	can get the whole part failing.

	If there was an idle task whose job was to update the CRC for modified
	pages, compute the checksum for unmodified pages, and call a 
	handeler for corrupted pages, you could note the following failure
	modes:

	part failure -- system crashes.
	column decoder failed -- system crashes.
	complete row decoder failure -- system crashes.
	one row decoder fails -- call the handeler and kill the effected 
				 processes.
	bit hard error -- kill the process.
	soft bit error -- kill hte process.

	Overhead -- approx none, if done correctly.  The idle task would
	run at priority 19, or some moral equivelant (a scheduler stub?)
	and not interfere with normal operation.  On a heavily loaded
	system, you lose.

	Algorithm considerations -- the checksum should be able to tell if
	a page is good, and not detect as good a page of zeros or a page
	of 0xff, unless it is really good.  The checksum table must be
	protected.  Question: how much overhead is a complete page diagnostic?
	(write a shifting bit pattern to the word, and various other 
	patterns which might cause it to fail).

	This is all off the top of my head, so it is pretty incoherent.
	Ah, well...

					John

	


From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Tue Nov 28 11:21:05 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Mon, 27 Nov 89 18:02:24 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: think!ames!mips!daver!dlr@EDDIE.MIT.EDU (Dave Rand)
To: mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Re: what's the CPU overhead of the polled SCSI?

[In the message entitled "what's the CPU overhead of the polled SCSI?" on Nov 27, 11:39, sun!ucscc.UCSC.EDU!clanhlm!blank writes:]
> 
> 	How much of a preformance hit it is, anyway?  (don't get me
> 	wrong, just curious).
I'm not sure if I understand, so I'll respond in two ways.

1) You can poll for each byte, as well as poll for each phase change. This
   is not the best way to run it, though. In this case, the CPU is busy
   for the entire SCSI transaction from arbitration to message phase -
   could be as much as 250 milliseconds (just for the selection).

2) You can have a state machine (in software) for the phase changes,
   and an interrupt (from the DP8490 or AIC-6250) changes the state
   as the phase changes. When the data phase comes along, you fall
   into a "MOVSD" instruction which transfers a "sector" of data.
   This pulls waits as required to synchronize, and is the fastest
   way to transfer data on the bus. In this case, the CPU is busy
   only during the data phase.


-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Tue Nov 28 16:35:47 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Tue, 28 Nov 89 10:11:09 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: think!ames!mips!daver!dlr@EDDIE.MIT.EDU (Dave Rand)
To: mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Re: Design and commitment.

[In the message entitled "Re: Design and commitment." on Nov 28, 10:18, uunet!munnari!sibyl.eleceng.ua.oz.au!ian writes:]
> 
> Dave Rand writes:
>  > 1) The parity logic was not being tested by the ICM software under UNIX.
> 
> It looks like it but why does it report a "Memory parity fault at all?"
> (I tried unplugging a chip from the board when it it running and it definitly
> does die with a memory parity fault!).
It doesn't on V.2.6.1. At all. It may NMI, but it don't parity error.

> 
>  2) The the logic in the kernel is wrong about determining the address.
> 
> I got correct NMI status words. The low 4 bits have to be complemented
> to get the row number.
Yup. That is the second bug. The address that the NMI routine (would have)
reported is wrong. The bottom *3* bits have to be complemented - the
4th bit is correct.

> 
> But why are there memory parity errors reported at all? My guess is that
> subsequent logic used bits 4 and 5 of the nmi status word. Does the presence of
> bit 8 in the returned value make any difference?
Dunno. I was *never* able to get mine to do a parity error, and from
disassembling the code, it can't - without the presence of bit 8.


-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Tue Nov 28 16:36:02 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
From: think!ames!mips!sibyl.eleceng.ua.oz.au!ian@EDDIE.MIT.EDU
Date: Tue, 28 Nov 89 10:18:22 +1100
To: mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Re: Design and commitment.

Dave Rand writes:
 > 1) The parity logic was not being tested by the ICM software under UNIX.

It looks like it but why does it report a "Memory parity fault at all?"
(I tried unplugging a chip from the board when it it running and it definitly
does die with a memory parity fault!).

 2) The the logic in the kernel is wrong about determining the address.

I got correct NMI status words. The low 4 bits have to be complemented
to get the row number.

 > I fixed problem #1:
 > >From wombat!daver Sat Nov 18 14:44:02 1989
 > adb -w /unix
 > _nmi_type,4?i
 > _nmi_type?W 0a815005f
 > _nmi_type,4?i
 > 
 > 
 > 
 > 
 > This changes the:
 > 	movb	a000c0,r0	to
 > 	movw	a000c0,r0
 > 
 > and causes all the nice logic in the kernel to be *USED* when a parity error
 > is found.

But why are there memory parity errors reported at all? My guess is that subsequent logic used bits 4 and 5 of the nmi status word. Does the presence of
bit 8 in the returned value make any difference?

Ian.


From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Tue Nov 28 16:36:09 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
From: think!ames!mips!sibyl.eleceng.ua.oz.au!ian@EDDIE.MIT.EDU
Date: Tue, 28 Nov 89 11:04:16 +1100
To: mips!daver.uu.NET!pc532@EDDIE.MIT.EDU
Subject: Operating Systems

I favour Mach. Unfortunately, despite rumours to the contrary, it is only
as free as BSD Unix. i.e. you need a 100k$ AT&T source licence.

One possibility is a french operating system called something like CROAP I
don't know much about it but I can try and find out. I believe it is NOT
unix compatible.

I am in the process of adding some BSD extensions (sockets and select)
to Sys V.2.2 for my ICM. This is a binary licence but it turns out that
there is only one object module to replace if the sysent structure is
to be expanded. (You also have to patch one location in trap.o, but that
is the way it goes.) Anyway, it strikes me that

a) large chunks of this binary distribution should work unmodified on
   the pc532.

b) Much of the BSD code is freely available.

It would be feasible (I didn't say easy) to reverse
engineer/disassemble the object modules which need to be changed to port this
to the pc532. We could then add enhancements as necessary.

Another possibility is the GNU project. As far as I am aware, the GNU
operating system is vapourware, but if we are going to invest effort into
operating system development we might as well cooperate with GNU. The more
people working on it the quicker it will get done.

Ian


From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Tue Nov 28 16:36:17 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Tue, 28 Nov 89 10:29:09 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: think!ames!mips!daver!dlr@EDDIE.MIT.EDU (Dave Rand)
To: mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Re: System Console and FDC plans

[In the message entitled "System Console and FDC plans" on Nov 28,  1:47, John L. Connin writes:]
> 
> 
> George and Dave, I know you want to freeze the hardware design and
> ship it, but suchs I'll ask the question anyway.
(small point - the PC boards are already up and running. In my opinion,
unless we find a *major* bug in the design, there will be no revision for
the next run)

> 
> My understanding is pc532 provides the system console / keyboard support
> via an rs-232 terminal.
Yes, this is correct.

> 
> I was just looking at Intel's July/August 1989 "Solutions" publication
> which briefly describes their "single-chip, VGA-compatible device
> called the 82706".  "This is a 132-pin, plastic-mounted part that
As mentioned earlier, we intend for there to be a video card for the
system. I believe that it should *not* be on the motherboard. VGA
screens, in particular, are quite slow (many, many wait states to get
to the video ram), and would be best served out on the bus.


> The above would make a DAM-NICE pc532 system console/keyboard.
I, personally, would suggest looking at some of the Chips and Technology
chip sets for graphics :-)

A VGA (or 8514) chip set, with a GX 32, SCSI, and support circuity would
make quite a nice system console. Would you be willing to design it?
We would like to, but with other support issues, it won't be done in the
next few weeks.

>   
> Floppy Disk Support:
> --------------------
> 
> Which raises the question,  what is the plan with respect to floppy
> disk support ??

SCSI FDC controllers are available now. If you want to though, it should
be easy to integrate the FDC onto the video card.

-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Tue Nov 28 16:38:54 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: System Console and FDC plans
To: mips!daver.uu.NET!tarpit!pc532@EDDIE.MIT.EDU
Date: Tue, 28 Nov 89 1:47:28 EST
From: John L. Connin <think!ames!mips!daver!uunet!manatee!johnc@EDDIE.MIT.EDU>
X-Mailer: Elm [version 2.1 PL1]


George and Dave, I know you want to freeze the hardware design and
ship it, but suchs I'll ask the question anyway.

System Console / Keyboard:
--------------------------

My understanding is pc532 provides the system console / keyboard support
via an rs-232 terminal.

I was just looking at Intel's July/August 1989 "Solutions" publication
which briefly describes their "single-chip, VGA-compatible device
called the 82706".  "This is a 132-pin, plastic-mounted part that
maintains 100-percent register-level compatibility with IBM's
VGA standard".  The article goes on to say that a complete graphics
subsystem can be implemented with 16 integrated circuits, including:

   1 - 82706 VGA Chip
   8 - 64K x 4 bit RAMs
   1 - IMS 8171 color palette lookup table DAC

I assume the 6 remaining circuits are glue chips.

In addition to the above 8042 keyboard controller is needed.

The above would make a DAM-NICE pc532 system console/keyboard.

BTW:  I have developed a character based Minix device driver that
      emulates very closely  DRI-'s window manager  (ie. numerous windows,
      each window can be size from 1x1 to max screen width-depth,
      positioned, panned, scrolled, colored, promoted, and display on
      one of two monitors)

      As I have it configured, except for a message window and debug
      window, each window is a different virtual console with its
      own shell.

      It is implemented by associating each virtual window with a different
      video ram page (actually any memory will do).  At each system 'tick'
      a display routine looks for sections of windows that are 'dirty'
      and visible.  If found, using mapping structures, it then updates
      (writes) the visible and dirty window sections to the 'visible'
      video page (ie. the CRTC video memory regen base address).

      To switch a window from one monitor to another simply requires
      changing one pointer.  Of course two monitors requires two
      video controllers.  The other window manager functions simply
      manipulate the contents or linked order of the mapping structures.
      The driver is 100 percent self-contained -- no ROM-Bios code is
      used.

      Really nice -- would love to have this capability on the pc532,
      as well as someday a X-Window server.

Any possibility ??  The nth virtual console would only be a "ALT-N"
away -:).

  
Floppy Disk Support:
--------------------

In the same article Intel describes their latest FDC design.

Which raises the question,  what is the plan with respect to floppy
disk support ??


Best regards,
johnc



From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Tue Nov 28 20:14:25 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date:  Tue, 28 Nov 89 18:33:28 EST
From: think!ames!mips!bu-it.BU.EDU!tower@EDDIE.MIT.EDU
To: mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Cc: mips!daver.uu.NET!pc532@EDDIE.MIT.EDU
Subject: Operating Systems

   Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
   From: think!ames!mips!sibyl.eleceng.ua.oz.au!ian@EDDIE.MIT.EDU
   Date: Tue, 28 Nov 89 11:04:16 +1100

   I favour Mach. Unfortunately, despite rumours to the contrary, it
   is only as free as BSD Unix. i.e. you need a 100k$ AT&T source
   licence.

MACH is working on freeing it's mini-kernal from the AT&T license.  If
this happends and MACH remains free of export controls, GNU will use
it.  A freed file system will be needed.

   One possibility is a french operating system called something like
   CROAP I don't know much about it but I can try and find out. I
   believe it is NOT unix compatible.

If you are thinking of CHORUS, it's licensed proprietary software.  I
don't have further details.

   Another possibility is the GNU project. As far as I am aware, the
   GNU operating system is vapourware, but if we are going to invest
   effort into operating system development we might as well cooperate
   with GNU. The more people working on it the quicker it will get
   done.

   Ian

GNU has been holding off on kernel work until the MACH situation
clears up or we run out of more productive work to do on the rest of
the system.  We are designing and considering the issues though.


We have everything else except a file system that one expects to find
on a modern Unix box.

You could certainly help GNU out and get yourselves in a position to
help with the GNU kernel work, by adopting as much of the released GNU
software as possible, especially gdb, gcc. gas, and gld (these are all
close to the machine, and are good background to have for kernal
hacking).  The other utilities are usually better than what else is
available. 

I was glad to see the freed BSD TCP/IP code mentioned.  GNU is almost
certainly going to use this code.

enjoy -len 

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Wed Nov 29 14:13:53 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
From: think!ames!mips!daver!swbatl!texbell!moray!siswat!buck@EDDIE.MIT.EDU
Apparently-From: swbatl!texbell!moray!siswat!buck
Date: Wed, 29 Nov 89 11:26 CST
Apparently-From: swbatl!texbell!moray!siswat!buck
To: mips!moray!texbell!daver!pc532@EDDIE.MIT.EDU
Subject: another(?) source for 4.1BSD on 32000

I saved this posting from the unix.wizards newsgroup.  It describes a 4.1BSD
kernel completely rewritten in another language, called Turing.  It already
runs on 32000 hardware.  They don't mention what licensing restrictions
might apply.  I tried sending mail to this guy a long time ago, but never
got any reply back.

A. Lester Buck		...!texbell!moray!siswat!buck


From: funke@turing.toronto.edu (Mark Funkenhauser)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: TUNIS ( was Re: Future at Berzerkeley )
Message-ID: <89Mar28.205312est.4328@turing.toronto.edu>
Date: 29 Mar 89 01:53:08 GMT

In article <373@bnr-fos.UUCP> hwt@bnr-public.UUCP (Henry Troup) writes:
> Some years ago, when I was an undergrad at the University of Toronto, 
> a prof had just completed TUNIS, the Toronto UNIx System.
> This was a Unix (BSD) kernel written in Concurrent Euclid.
> Anyone know what if anything happened with this?
>

[ I believe TUNIS is short for "Toronto UNIversity System" ]

TUNIS is a re-implementation of the UNIX kernel.  Its principle design goals
were to determine if a kernel could be written using the most recent
software engineering techniques without significant performance loss.  These
techniques include modularity, hierarchical structuring, abstraction and
information hiding.  A concurrent programming language was also developed
(somewhat in parallel) to aid in the implementation of TUNIS.  This language
was called Concurrent Euclid.  This has since been replaced by a new
generation language called Turing and Turing Plus.  The Turing language is
strongly typed, has a precise and formally defined semantics, enforces
modularity and data abstraction and Turing Plus provides concurrency
primitives (e.g. light weight processes, synchronization and mutual
exclusion constructs ...  ). The compiler optionally provides a multitude of
runtime checks to ensure that the program execution conforms to the language
semantics.

An important concept used during the design is that the language defines
truly concurrent processes.  Each process could run on a separate processor
if multiple processors were available and the processors shared a common
memory.  In fact there have been 2 successful implementations of tightly
coupled multi-processor systems using TUNIS:  a Master-Slave version and a
Symmetric (or distributed) version.  The Master-Slave version supports
real-time applications and is being used by a group within the university to
do robotics research and development.


Research and development of TUNIS is still active.  It is currently 4.1BSD
compatible and runs on several NS32000 systems.  We are in the process of
becoming POSIX (and SVID) compatible.  We are also porting it to the mc68030
and 80386 architectures.

Currently ongoing projects include :

  1) the development of Trusted TUNIS. A 'Unix' system that meets the
     US DoD's B3 level criteria for trusted computer systems.

  2) the development of HECTOR - a tightly coupled multiprocessor system 
     that can contain several hundred (thousand?) 88000 processors.
     This includes the development of a new hierarchical bus architecture.
     The software will be BSD4.3 and/or SunOS compatible 
     with new features such as user controllable light-weight processes 
     (aka threads).


The source code for TUNIS has been available to universities for teaching
and/or research purposes. There does not exist a commercially available
version (yet) but we sure would like to hear from anyone interested
(commercially or otherwise) especially in our Trusted TUNIS research.


Any further info can be obtained from:

   TUNIS Distribution Manager
   Computer Systems Research Institute
   University of Toronto
   10 King's College Road
   Toronto, Ontario, Canada
   M5S 1A4


or from me :

   Mark Funkenhauser   		     email:   funke@csri.toronto.edu
   ( at the above address )




From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Wed Nov 29 14:14:05 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: re: FYI.. Mt Xinu's upcoming Mach distribution
To: mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
From: think!ames!mips!s49.prime.com!KENYEE@EDDIE.MIT.EDU
Date: 27 Nov 89 16:16:03 UT

I don't want to be obnoxious with suggestions, but how simple is an upgrade
of the 2681 to the Cirrus Logic octal uart?  I know, the board has been
designed already, etc...

   Ken
 ,   " Why couldn't National get its marketing act togetther?  I was even
       hoping they'd get the marketing win with Atari (their last big chance
       with computers)."

p.s., I've always been a fan of NS32k processors too.  If I can help in any
way, I'd like to but I have no large expertise yet.  Add one more hacker..


From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Wed Nov 29 15:49:56 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Wed, 29 Nov 89 10:31:39 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: think!ames!mips!daver!dlr@EDDIE.MIT.EDU (Dave Rand)
To: mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: re: FYI.. Mt Xinu's upcoming Mach distribution

[In the message entitled "re: FYI.. Mt Xinu's upcoming Mach distribution" on Nov 27, 16:16, uunet!s49.prime.com!KENYEE writes:]
> 
> I don't want to be obnoxious with suggestions, but how simple is an upgrade
> of the 2681 to the Cirrus Logic octal uart?  I know, the board has been
> designed already, etc...

Dunno - as you say, the board is done (PCB's are out).

We do use 2698's (Octal UARTs) on the Ethernet/serial card. This gives
you 16 serial ports with only two devices. We didn't want to go for more
than 8 serial ports on the main board - why use up the main CPU for
seial I/O when you can do it on an I/O processor?

More information on the Ethernet board in a future mailing...


-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Wed Nov 29 21:12:05 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Wed, 29 Nov 89 13:06:51 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: think!ames!mips!daver!dlr@EDDIE.MIT.EDU (Dave Rand)
To: mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: re: FYI.. Mt Xinu's upcoming Mach distribution

[In the message entitled "re: FYI.. Mt Xinu's upcoming Mach distribution" on Nov 29, 15:26, uunet!mac.dartmouth.edu!Steven.D.Ligett writes:]
> 
> --- You wrote:
> More information on the Ethernet board in a future mailing...
> --- end of quoted material ---
> 
> I haven't seen the pinout of the "XT"  SCSI connectors.  Is that coming soon?
> 
Full schematics are (and have been) available for the motherboard for some
time now. 


[In the message entitled "boms away" on Nov 18, 21:39, George Scolaro writes:]
> 
> - the current pcb is a 6 layer board, 2 power layers, 4 signal layers, it
>   uses lax design rules, ie 1 trace between 0.1 inch pins, 13 mil traces.
> - the current artwork has 1 error, involving a single trace rework. The
>   artwork is photoplotted, ie accurate.
> - I will gladly send copies of the schematics and pal equations, which will
>   all fit on a floppy, plus paper copies of the design, jedec copies of the
>   pal equations and the gerber files for the pcb artwork. A small handling
>   fee would be appreciated though...


-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Wed Nov 29 21:12:13 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
X-Mailer: Mail User's Shell (6.4 2/14/89)
To: mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Re: another(?) source for 4.1BSD on 32000
Date: 29 Nov 89 21:08:47 GMT (Wed)
From: think!ames!mips!daver!uunet!ames!gatech!mm!ken@EDDIE.MIT.EDU (Ken Seefried iii)

A complete discription of Concurrent Euclid (the predicessor of
Turing Plus) and of the design of Tunis can be found in the book:

        "Concurrent Euclid, the Unix System and Tunis", R.C. Holt
        Addison Wesley, (c) 1983, ISBN 0-201-10694-9

Basicly, Euclid and Turing are procedural languages with very
strong typing and lots of support for concurrency.  It also has
reasonable support for low-level programming and real-time work.
I've never written any Euclid or Turing, so I can't say how it
works in practice, but it looks pretty good on paper.

Tunis was conceived as a Unix-compatable OS whose implimentation
is supported by the features of Euclid.  Again, it looks good
on paper.

I wouldn't mind hacking Euclid/Tunis.  I question the true level
of compatability with Unix, but it has quite a bit going for it.

I can address specific question concerning Euclid and Tunis, but
for now, I'll defer to the book.  I know nothing about it's 
availibility...


-- 

	...ken seefried iii	...!<anywhere>!gatech!mm!ken
	   MetaMedia, Inc.
	   mm!ken@gatech.edu	

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Thu Nov 30 07:42:52 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Wed, 29 Nov 89 20:01 PST
From: think!ames!mips!daver.uu.net!dlr@EDDIE.MIT.EDU (Dave Rand)
To: mips!daver.uu.net!pc532@EDDIE.MIT.EDU

>From wombat
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gWhqK-0000o0C@daver.uu.net>; Wed, 29 Nov 89 19:52 PST
Received: by wombat.UUCP (smail2.5)
	id AA25521; 29 Nov 89 19:47:28 PST (Wed)
X-Mailer: Mail User's Shell (6.2 5/11/88)
To: daver!pc532
Subject: scsi pinout
Message-Id: <8911291947.AA25514@wombat.UUCP>
Date: 29 Nov 89 19:47:20 PST (Wed)
From: george@wombat.UUCP (George Scolaro)

[In the message entitled "re: FYI.. Mt Xinu's upcoming Mach distribution" on Nov 29, 15:26, daver!uunet!mac.dartmouth.edu!Steven.D.Ligett writes:]
> 
> --- You wrote:
> More information on the Ethernet board in a future mailing...
> --- end of quoted material ---
> 
> I haven't seen the pinout of the "XT"  SCSI connectors.  Is that coming soon?
> 
Ok here it is:

	B side		A side
1	gnd		nc
2	reset		nc
3	+5		nc
4	nc		nc
5	nc		nc
6	nc		nc
7	-12		nc
8	nc		nc
9	+12		nc
10	gnd		nc
11	gnd		/ir3		;general interrupts to 32202
12	gnd		/ir2		; icu
13	gnd		/ir1
14	gnd		/sd0		;scsi stuff here
15	gnd		/sd1
16	gnd		/sd2
17	gnd		/sd3
18	gnd		/sd4
19	gnd		/sd5
20	gnd		/sd6
21	gnd		/sd7
22	gnd		/sdp
23	gnd		/satn
24	gnd		/sbsy
25	gnd		/sack
26	gnd		/srst
27	gnd		/smsg
28	gnd		/ssel
29	+5		/scd
30	gnd		/sreq
31	gnd		/sio

The power connection is compatible with current xt boards, ie you
can use a normal xt wirewrap board with this pinout. The 3 interrupt
lines are free for use by and board in any of the 4 slots, just in
case you need some weird interrupt capability in addition to the scsi
protocol.

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george)

From daver!dlr@uunet.UU.NET Thu Nov 30 08:38:16 1989
Flags: 000000000000
Date: Thu, 30 Nov 89 05:35:36 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: dlr%daver@uunet.UU.NET (Dave Rand)
To: uunet!bu-it.BU.EDU!budd@uunet.UU.NET
Subject: re: FYI.. Mt Xinu's upcoming Mach distribution

[In the message entitled "re: FYI.. Mt Xinu's upcoming Mach distribution" on Nov 30,  4:02, uunet!bu-it.BU.EDU!budd writes:]
> 
> What is the current state of boardmaking?  Do you plan to have
> any batches made in the future?
> 
We have three boards left now - these cost us about $600/ea. I will be
talking to National next week. I am going to try to convince them to
make the boards and everything, but no promises.

Yes, there are plans for batches in the future (independent of National),
but the price/board depends on the volume. If you know of a low-cost
place to fab 6 layer boards, please let me know.


-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Thu Nov 30 11:11:57 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Thu, 30 Nov 89 05:54:53 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: think!ames!mips!daver!dlr@EDDIE.MIT.EDU (Dave Rand)
To: mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Re: SCSI

[In the message entitled "Re: SCSI" on Nov 30,  9:17, "Tarjei T. Jensen" writes:]
> 

> He said that one would have to modify the SCSI driver for each type of drive.
> He claimed that there were a lot of manufacturer specific parameters to set. He
> could not find the standard when I talked to him. Is this really so? I don't

Modern SCSI drives (usually) observe the Common Command Set commands. With
this, there is no need for device specific commands - and certainly never
any need to change the device driver.

With older SCSI periperals, usually a separate drive/controller combination,
you must set a jumper, or use the Mode Select command prior to the first
format. This is used to instruct the controller as to the drive
characteristics, like heads, cylinders and other information. This
information is then recorded on the media in a reserved, unaccessable
area. Again, no need to change the device driver. All the separate
SCSI controllers that I have purchased in the last 8-10 years have been
of this type (before it was called SCSI :-)

On very old SCSI periperals, a Mode Select command must be issued
after every SCSI reset. In this case, you could change the device driver
for each specific combination. A better solution (if you are still using
this type of equipment) would be to reserve sector 1, and load the
Mode Select command from this location. The controller will still be
able to read track 0, even if it doesn't know how big the rest of the
drive is. I have never actually had a controller that did this, but
I have seen the code to handle it.

The device driver should not need to change from periperal to periperal.
The device driver should be able to read and write any SCSI device,
synchronous or asynchronous, without modification.


-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr@daver.uu.net

