From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Fri Dec  1 16:18:31 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: 01 Dec 89 15:21:23
From: think!ames!mips!mac.dartmouth.edu!Steven.D.Ligett@EDDIE.MIT.EDU
To: mips!daver.uu.NET!pc532@EDDIE.MIT.EDU (Dave Rand)
Subject: re: FYI.. Mt Xinu's upcoming Mach distribution

--- You wrote:
...
[In the message entitled "boms away" on Nov 18, 21:39, George Scolaro writes:]

> - 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...
--- end of quoted material ---

Is there a set fee?  $15 plus 2 3.5" floppies plus SASE?  If you had
PostScript files
for schematics and drawings, that'd be great.  I could probably turn Gerber
files
into PostScript to preview the artwork.  What's the USPS address?

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Fri Dec  1 16:24:37 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Fri, 1 Dec 89 12:42: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: FYI.. Mt Xinu's upcoming Mach distribution

[In the message entitled "re: FYI.. Mt Xinu's upcoming Mach distribution" on Dec  1, 15:21, uunet!mac.dartmouth.edu!Steven.D.Ligett writes:]
> 
> --- You wrote:
> ...
> [In the message entitled "boms away" on Nov 18, 21:39, George Scolaro writes:]
> 
> > - 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...
> --- end of quoted material ---
> 
> Is there a set fee?  $15 plus 2 3.5" floppies plus SASE?  If you had
> PostScript files
> for schematics and drawings, that'd be great.  I could probably turn Gerber
> files
> into PostScript to preview the artwork.  What's the USPS address?
> 
No, there is no set fee. Enough to cover the postage, one 5.25" disk, and
the mailing container is fine. Call it $5 domestic, $10 overseas.

But look at it this way :-)

10 people send us $5 - each of those people sent it to 10 other people, and
change $5... At the end of the year, we will all have made AT LEAST $50,000!
(Sorry - I couldn't resist :-)

The address is:

	941 Chehalis Drive
	Sunnyvale, CA  94087

Voice contact:
	(408) 434-0600 X4555 (Dave) or X4556 (George)
	(408) 733-4125 home

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

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Sat Dec  2 03:31:04 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
To: mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Interest poll for Multibus version
Date: 1 Dec 89 23:34:28 CST (Fri)
From: think!ames!mips!daver!uunet!starfire!john@EDDIE.MIT.EDU (John Lind)

Is there anyone else out there who would be interested in a Multibus
version of the PC532?  What I have in mind is replacing one of the
SCSI busses with the multibus interface, and try to get it on a multibus
card.  The reason for this is that I can't afford to just junk all my
spiffy Multibus controllers and associated peripherals.

I know that this is a fair amount of work, even starting with the
schematics and other info provided by Dave and George, so I am not
quite willing to undertake it for myself by myself (ah, if only work
did not cramp one's lifestyle so!).  Anyway, if there is any interest
out there to help and/or support such an effort, I am willing to
give it a shot.

CAVEAT:  I am NOT interested in changing a single thing about the design
that does not directly relate to the bus swap.  Not One Thing.  You want
to fiddle with it, you find another fiddler.  I want a machine, not
a piece of evolving art.
--
		   John Lind, Starfire Consulting Services
E-mail: john@starfire.MN.ORG		USnail: PO Box 13001, Mpls MN  55414

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Sat Dec  2 03:31:31 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
To: mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Re: SCSI
Date: 1 Dec 89 23:25:14 CST (Fri)
From: think!ames!mips!daver!uunet!starfire!john@EDDIE.MIT.EDU (John Lind)

dlr writes:
>[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.

I think this is a case of "you are both right" to some degree.  I have
done a fair amount of SCSI HBA Unix driver work, so this is an informed
opinion.

You don't have to change anything in the driver to go from disk drive to
disk drive, except where bugs pop up.  For instance, we have run into
drives that choke if you negotiate for synchronous transfers, and drives
that only work in synchronous mode.  So, you add device-configurable
bits to the driver to say things like "don't negotiate for synchronous"
or "don't try asynchronous transfers" and garbage like that.  Of, and
there are always the jokers with the NON-STANDARD Mode Sense information,
or who put things in the wrong page (was that 5 or 20?  12?  18? oh, just
pick one...).

Also, you often do have to have different sections in the driver for
different CLASSES of devices.  You can't use all the same driver code
for both disks and 9-track tapes (with variable size records), for instance.
So, if you want to add a new class of devices (like WORM drives) and your
driver doesn't already support it, you have to change the driver.

I hope that cleared things up rather than confusing them further...
--
		   John Lind, Starfire Consulting Services
E-mail: john@starfire.MN.ORG		USnail: PO Box 13001, Mpls MN  55414

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Sat Dec  2 03:34:59 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Fri, 1 Dec 89 22:57:00 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: Interest poll for Multibus version

[In the message entitled "Interest poll for Multibus version" on Dec  1, 23:34, John Lind writes:]
> 
> Is there anyone else out there who would be interested in a Multibus
> version of the PC532?  What I have in mind is replacing one of the
> SCSI busses with the multibus interface, and try to get it on a multibus
> card.  The reason for this is that I can't afford to just junk all my
> spiffy Multibus controllers and associated peripherals.
> 
I know it has been said before... but this might be an solution for you
in the mean time...

Can't you leave a CPU in the multibus card cage, and use the pc532
SCSI to talk to the other CPU, which then talks to the multibus?

This would allow you to do some neat buffering, and really get
the performance out of those multibus cards. Plus, with some of
the ideas of hwajin@wrs.com, you could set up some multi-processing
kind of stuff.

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

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Sat Dec  2 05:52:02 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: parity!?
Date: 2 Dec 89 00:48:45 PST (Sat)
From: think!ames!mips!wombat!george@EDDIE.MIT.EDU (George Scolaro)

Well, after saying that it was too much of a pain etc etc, I have figured
out how to put parity onto the pc532 dram interface without causing any
additional wait states on reads or writes. I know we have said many a time
that the design is done etc etc, but it was an intellectual exercise, ie I
was bored... (waiting for all that software!). Anyhow, the bottom line is
that it can be done (with a bit of a lateral approach), it takes 4 x 74AS280
parity chips, 1 74AS374 (to latch the parity info & byte enables) and a
pal22v10 to latch the parity error up, generate an NMI to the cpu and store
the offending byte(s) and bank that produced the parity error.  Once a
parity error is detected, it will cause the error information to remain
latched until it is optionally read and then cleared (by software), thus
parity errors in subsequent accesses are not or-ed into the status register,
ie fix one bug at a time. The parity information is reported as 5 bits (the
bad byte(s) and the bank (0 or 1)), on data lines D00-D04.

The parity generation is real easy, ie 1ns to spare worst case, but the
parity checking was a bit of a challenge (I hate using lots of chips), and
what I ended up doing was latching the parity bits from the 74AS280s and
the byte enables into a 74AS374 using the 532's BCLK. Then in next clock
I synchronously qualify each of the latched parity bits with it's byte
enable, qualify the lot with a signal from the dram control pal that says
we are in the clock following a valid DRAM read, and latch any error that
occurred. This works for both a single read access or for a burst read
access.

I have just about updated the PCB database to reflect the parity circuit, I
have simulated it on a logic verifier and it all looks good. The important
thing of course is that the people that want it can populate the circuit
and those that don't can leave it blank. Quite a few people have requested
the design pack for the pc532, and all but two (already gone out) will
be for the new parity design. The addition of the parity circuit shouldn't
affect the rest of the design, the circuit is an addition and if not
populated will result in an exact replica of the old (ie working) design.

Note that this is definitely the only change that I will entertain doing
on the board, any others can be done by yourselves.

-- 
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 Sat Dec  2 05:53:31 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date:  2 Dec 89  9:46 -0800
From: "Tarjei T. Jensen" <think!ames!mips!nac.no!hsr.uninett!jensen@EDDIE.MIT.EDU>
To: <mips!daver!pc532@EDDIE.MIT.EDU>
Subject: Re: Interest poll for Multibus version

I think that it would be more useful with either a stripped down pc532 with
real PC/AT slots and a PC keyboard interface or a 32016 with the same outfit as
a platform for cheap peripherals (if we want to stay with a National CPU). The
latter would of course do double duty as a cheap general purpose microprocessor
trainer since it can work with the glorious NS32203 DMA controller.

The outfit would then be a standard pc532 as the compute engine and the above
mentioned item as the terminal (with keyboard and VGA controller). Personally
I expect to use the pc532 with either a vt100 or a vt320. I don't expect much
more mileage from my old trusted BBC microcomputer.

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

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Sat Dec  2 14:00:50 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Sat, 2 Dec 89 10:03:50 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: Interest poll for Multibus version

[In the message entitled "Re: Interest poll for Multibus version" on Dec  2,  9:46, "Tarjei T. Jensen" writes:]
> 
> I think that it would be more useful with either a stripped down pc532 with
> real PC/AT slots and a PC keyboard interface or a 32016 with the same outfit as
> a platform for cheap peripherals (if we want to stay with a National CPU). The
> latter would of course do double duty as a cheap general purpose microprocessor
> trainer since it can work with the glorious NS32203 DMA controller.

As it turns out, this is an option :-)

There is a board available from National with a 15 Mhz NS32CG16, several
IBM-PC slots (real ones), a PC Keyboard connector, and even sound output.
It has an HPC micro-controller on it to handle the Keyboard (and other
tasks).  I have tried to get pricing information on it, and to try to work a
deal with the "owner" of the board, but he has not replied yet (this was
about 1-2 weeks ago now).

Before I left National, I was able to write a bit of software for this
board, including some Ethernet monitoring software (with a standard
IBM PC Ethernet board), a Hercules driver (used in the above software),
and the rudiments of a floppy disk driver. The board has a dicrete DMA
design which is quite nice (being gentle: the NS32203 can't work above
10 Mhz). It also has a "native" bus slot that allows access to the
32CG16's bus.

While the NS32CG16 doesn't have the ability to interface to an MMU, it
should be able to run a nice single user operating system.

I am unsure of the price of the board. It is probably quite high,
retail, but if you are interested, I will pursue getting this board
as a bulk purchase.

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

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Sat Dec  2 18:41:18 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
To: mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Re: Interest poll for Multibus version
Date: 2 Dec 89 13:39:21 CST (Sat)
From: think!ames!mips!daver!uunet!starfire!john@EDDIE.MIT.EDU (John Lind)

[In the message entitled "Re: Interest poll for Multibus version" on Dec  1, 22:57, Dave Rand writes:]
>[In the message entitled "Interest poll for Multibus version" on Dec  1, 23:34, John Lind writes:]
>> 
>> Is there anyone else out there who would be interested in a Multibus
>> version of the PC532?  What I have in mind is replacing one of the
>> SCSI busses with the multibus interface, and try to get it on a multibus
>> card.  The reason for this is that I can't afford to just junk all my
>> spiffy Multibus controllers and associated peripherals.
>
>Can't you leave a CPU in the multibus card cage, and use the pc532
>SCSI to talk to the other CPU, which then talks to the multibus?

Not to belabor the obvious, but the pc532 SCSI ain't gonna talk to no
CPU -- there has to be a HBA in there somewhere.  HBAs that will allow
you to run in target mode are rare, and the support is purely vapour.
I am working on just such a project now (though not for remote peripheral
support), and it is nightmareish.

So, I don't really want to have to buy a Multibus HBA, and futher increase
my investment in that bus, and then have to break new ground in SCSI
interfaces, as well.  Yech!
--
		   John Lind, Starfire Consulting Services
E-mail: john@starfire.MN.ORG		USnail: PO Box 13001, Mpls MN  55414

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Sat Dec  2 18:41:48 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
To: mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Re: Interest poll for Multibus version
Date: 2 Dec 89 14:03:29 CST (Sat)
From: think!ames!mips!daver!uunet!starfire!john@EDDIE.MIT.EDU (John Lind)

	From uucp Sat Dec  2 07:03:47 1989
	>From altos!vsi1!daver!owner-pc532  Sat Dec  2 07:03:44 1989 remote from quest
	Received: by starfire.UUCP (smail2.5)
		id AA03429; 2 Dec 89 07:03:44 CST (Sat)
	Received: by quest.UUCP (smail2.3)
		id AA18792; 2 Dec 89 05:53:16 CST (Sat)
	Received: by altos.Altos.COM (smail2.5)
		id AA05592; 2 Dec 89 03:16:28 PST (Sat)
	Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
		id <m0gXWOh-00011yC@daver.uu.net>; Sat, 2 Dec 89 01:51 PST
	Reply-To: pc532@daver.UU.NET
	Return-Path: <uunet!nac.no!jensen%hsr.uninett>
	Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
		id <m0gXWOc-0000mfC@daver.uu.net>; Sat, 2 Dec 89 01:51 PST
	Received: from mcsun.eu.net by uunet.uu.net (5.61/1.14) with SMTP 
		id AA09736; Sat, 2 Dec 89 04:45:02 -0500
	Received: by mcsun.EU.net with SMTP; Sat, 2 Dec 89 10:44:52 +0100 (MET)
	Received: by runix.runit.sintef.no (norunix.EARN) (1.2/7.8)
		id AA16275;  Sat, 2 Dec 89 10:45:31 +0100
	Date:  2 Dec 89  9:46 -0800
	To: <pc532%daver>
	In-Reply-To: <8912012334.AA02703@starfire.UUCP>
	Message-Id: <2471*jensen@hsr.uninett>
	
[In a message titled "Re: Interest poll for Multibus version", Tarjei T. Jensen writes:]
>I think that it would be more useful with either a stripped down pc532 with
>real PC/AT slots and a PC keyboard interface or a 32016 with the same outfit as
>a platform for cheap peripherals (if we want to stay with a National CPU). The
>...

Your interest, not mine.  I don't want to acquire cheap peripherals.  I already
have some very nice, high-performance peripherals WHICH I WISH TO KEEP USING.
I have command-list and parameter-block driven controllers for ESDI, QIC02,
9-track and floppy (8", 5.25", 3.5"), and I have not interest in replacing
them.  Multibus is a GREAT bus for I/O, and I ALREADY HAVE THE HARDWARE.
Think about it.  You can get 5MB/sec burst transfer rates in 16-bit mode.
(2.5MHz transfers is about what you can reasonably get).  Dave and George
have already described why 3.8MB/sec is more than anyone will ever need
:-).

Unlike the card-based SCSI stuff, there's already a TON of Multibus gear in
existance.  Sometimes bargains exist.  I picked up my parallel interface card
for $7.50 at a Ham Fest.  Find a bargain like that for PC cards.  Multibus is
darned well "mature."

Please understand, starfire is a 32016 Unix Multibus system.  Running.  Now.
There is dual-ported memory is on the SBC, so the Multibus isn't loaded down
with memory accesses from the CPU, but bus devices can do UNAIDED DMA.
My ultimate dream would be to move the filesystem code (and TCP/NFS?) to my
current CPU and use a higher-horsepower CPU for the real process work.  Yes,
I know that current versions of Unix take more than casual hacking to do that,
but maybe someday Mach or Tunis would be real and available.

I have a configurable binary license.  I want to upgrade the machine, not
junk it.  In fact, if it is one or the other, I'd choose to upgrade the
software (the fast filesystem code alone would be a GREAT help) and leave the
CPU alone, but the pc532 is SO CLOSE to a TRULY GREAT solution for me,
that I hate to walk away from it.

If there are any of you out there who ALREADY OWN Multibus gear and don't
want to have to replace it, YOU are the people I am looking for.  The
rest of you, form your own SIG, but don't rain on MY parade.
--
		   John Lind, Starfire Consulting Services
E-mail: john@starfire.MN.ORG		USnail: PO Box 13001, Mpls MN  55414

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Sun Dec  3 03:29:04 1989
Flags: 000000000001
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: System Console
To: mips!daver.uu.NET!tarpit!pc532@EDDIE.MIT.EDU
Date: Fri, 1 Dec 89 20:53:49 EST
From: John L. Connin <think!ames!mips!daver!uunet!manatee!johnc@EDDIE.MIT.EDU>
X-Mailer: Elm [version 2.1 PL1]


Kind of a continuation of Dave Rand's response to my message "System Console
and FDC plans".

System Console:
---------------

> 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?

This area interests me, so possibly yes.   Please understand that I have
never designed any display equipment.  Therefore, before I can make a
_any_ commitment, I need to explore the subject in more detail.

Like others, what I really would like is a high performance X-Window
server.  On the other hand, as a first step, this may be just too big
a bite.  So, what I have been thinking about is an incremental approach
which I will outline:

1)  Explore the issues of a server providing video and keyboard service
    by interconnecting two pc's via a SCSI bus -- one pc being the client
    the other the server.  Begin to design the message protocol.

        pc -  SCSI adapter  -   SCSI bus  -   SCSI adapter  -  pc

     pc532 -  SCSI extender -   SCSI bus  -   SCSI adapter  -  pc

2)  Replace the 'pc' server with a board which contains:

        o  SCSI interface
        o  Micro-controller, RAM, ROM
        o  Interface to standard pc video adapter
        o  Keyboard interface.

        pc -  SCSI adapter  -   SCSI bus  -   SCSI interface - video adapter

     pc532 -  SCSI extender -   SCSI bus  -   SCSI interface - video adapter

     pc532 -  SCSI interface - video adapter


3)  Depending upon the above and item 4 below:

    o Design a SCSI board which interfaces to a standard pc video adapter
    o Design a SCSI board which incorporates a VGA chip-set.
    o Jump to a SCSI board incorporating a high-performance video subsystem

4)  In parallel with the above explore paper designs of a high-performance
    pc532 video adapter.


Any comments ??..


Things that would be very helpful:
----------------------------------

1)  Availability of a flexible pc SCSI adapter board.

2)  Availability of a pc532 SCSI extender board.  (ie. pc532 connector
    to SCSI cable)

3)  Availability of guideline SCSI software (eg. as mentioned in AN-563
    "A SCSI Printer Controller Using Either the DP8490 EASI or DP5390 ASI
    and Users Guide").  Does any one have this or know how to easily
    obtain it ??.

4)  Application notes, paper designs, etc of high-performance video
    adapter designs.  Any and all leads in this area would be appreciated.

Dave / George, regarding 1 and 2 above, how about adding these two items to
the "pc532 build kit" ??.  Both should be easy to produce and add have high
value to all in numerous situations.

I have briefly looked at the TI TMS32010 chip, Intel 72686 graphics
co-processor, and Nationals parts contained within their "1989 Graphics
Handbook".  My instant observation was that the Intel 72686 while interesting
was too limiting with respect to resolution;  whatever National was
pitching was too obscure for me to understand, and the TI 32010 looked
like a dam good candidate.  On the other hand, it (TI 32010) would mean
yet another processor to support (ie. additional binary tools etc).

Does National have any other documentation which would illuminate there
products ??  Would it be possible to obtain from National the design
details of there DP850EB and DP850DB8 Raster Graphic evaluation boards ??


SCSI FDC:
---------

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

Who are the manufactures, suppliers, and what is the approximate price ??


Counter / Timer / Real Time Clocks:
-----------------------------------

What hardware support for counters, clocks, and real time clocks does
the pc532 provide ??.


Best regards,
johnc


From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Sun Dec  3 06:57:20 1989
Flags: 000000000001
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Sun, 3 Dec 89 02:30:14 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

[In the message entitled "System Console" on Dec  1, 20:53, John L. Connin writes:]
> Things that would be very helpful:
> ----------------------------------
> 
> 1)  Availability of a flexible pc SCSI adapter board.
> 
No shortage of SCSI cards for pc's. There is a shortage of DOCUMENTED
scsi boards, however. A wire wrap PC add in card with a DP8490 on it
should only require a pal or two, some decode, and some glue.

If no one else wants to do it, I might even try (*gasp* - a software
type doing hardware, what is the world coming to?)


> 2)  Availability of a pc532 SCSI extender board.  (ie. pc532 connector
>     to SCSI cable)

We did this with a IBM-PC wire wrap card, a 50 pin transition header in
wire wrap, and 20 minutes. No logic of any kind is required.

> 
> 3)  Availability of guideline SCSI software (eg. as mentioned in AN-563
>     "A SCSI Printer Controller Using Either the DP8490 EASI or DP5390 ASI
>     and Users Guide").  Does any one have this or know how to easily
>     obtain it ??.
I have this. I am uncertain of the legality of distributing it, though.
I will check on it an get back to you.


> Does National have any other documentation which would illuminate there
> products ??  Would it be possible to obtain from National the design
> details of there DP850EB and DP850DB8 Raster Graphic evaluation boards ??

I don't think we want to get involved with the RGP. I will leave to your
imagination what I believe R.G.P. stands for. HINT: Think 16550A's. Another
hint: I think the Z80 can add register-to-register faster. I don't want
to discourage you too much - but be sure to check the instruction timings
before you select any part.


> 
> 
> SCSI FDC:
> ---------
> 
> > SCSI FDC controllers are available now. If you want to though, it should
> > be easy to integrate the FDC onto the video card.
> 
> Who are the manufactures, suppliers, and what is the approximate price ??
> 
Emulux makes one. Price is too high (as with all their products). Suppliers
are Hamilton (I think that's were we got our ICM controllers). There were
a bunch of SCSI controllers in Computer Surplus (a local store here), I'll
check on the prices... Personally, I think I will be using a PC via FTP
(or serial, as we do now) to do floppy work. Some folks may want it, though.


> 
> Counter / Timer / Real Time Clocks:
> -----------------------------------
> 
> What hardware support for counters, clocks, and real time clocks does
> the pc532 provide ??.
> 
The PC532 provides the ICU, with 15 interrupt sources. It has two T/C 
inside, of which one is used for refresh (16 bits). Each of the four
2681's has a T/C, with range from 115Khz to 3.5 hz with the input
clock/16 rates. You can provide other clocks to it, though.

RTC function is provided by software after power on, and by a Dallas
Semiconductor Clock module, which fits under the eprom (accessed via
address ranges), during power off. It provides some SRAM as well,
which is battery backed for storing configuration parameters.

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

From bu-cs!snorkelwacker!apple!vsi1!daver!dlr Mon Dec  4 03:45:44 1989
Flags: 000000000000
Relay-Version: version B 2.10.3 4.3bds beta 6/6/85; site bu-cs.BU.EDU
Path: bu-cs!snorkelwacker!apple!vsi1!daver!dlr
From: dlr@daver.UU.NET (Dave Rand)
Newsgroups: comp.sys.nsc.32k,comp.arch,sci.electronics
Subject: Low cost NS32532 system
Message-ID: <1989Nov30.225050.2124@daver.UU.NET>
Date: 30 Nov 89 22:50:50 GMT
Date-Received: 1 Dec 89 04:40:49 GMT
Organization: Association for the Prevention of Polar Bears and Kangaroos
Lines: 69
Xref: bu-cs comp.sys.nsc.32k:795 comp.arch:13307 sci.electronics:10014

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.

The design goal for this board was to produce a home brew design that was as
cheap as possible, with the best performance. It does not have external
cache, nor does it have parity, nor does it have a wizzy we-do-it-all-for-you
bus. It does have all the necessary goods to deliver a good performance,
lots of software hacking (and hardware via the SCSI *cheap* expansion) system
that will keep you busy during the rainy days...

In keeping with the design goal, the schematics, and pal equations and gerber
files (if required) are available for the asking. This design is totally free
and is there for people that want to hack (in the old style).

There is a mailing list for those of you that are interested. Send
your requests to: <pc532-request@daver.uu.net>. 

The PC532 board has the following features:

1 x NS32532 25 Mhz CPU
1 x NS32381 25 Mhz FPU
1 x NS32202 10 Mhz ICU
1 x DP8490 SCSI device that manages a 62 pin XT mechanically compatible 4
	slot multimaster bus. This bus can run at up to 3.8 megabytes per
	second. Multimaster is supported by the DP8490 SCSI device.
1 x AIC6250 SCSI device that connects to a 50 pin SCSI header. This device
	is intended to connect to hard disk and mag tape media. The AIC6250
	supports async and sync SCSI. The interface supports data transfers	nables over 4 megabytes
	per second.
4 x SCN2681 DUARTs. This gives the PC532 8 serial channels, which are all
	individually connected to interrupt inputs on the ICU. Each DUART
	generates an INT and in addition a wire or-ed RX ready channel A/
	channel B.
1 x 27256 EPROM (200 ns). This EPROM contains any necessary boot firmware.
	It is intended that a Dallas Semiconductor (or compatible) clock
	chip/socket be used under the EPROM to give the PC532 a battery
	backed real time clock.
4/8 megabytes (1 megabit x 8 80ns SIMMs) or 16/32 megabytes (4 megabit x 8
	80 ns SIMMs). Page mode dram devices must be used and the design
	utilizes the page mode access to achieve 0 wait state read (1st
	access), 0 wait state write, 1 wait state for the rest of a read burst
	if in page. If not in page a 4 wait state penalty occurs. Two refresh
	cycles are performed every 30us (to reduce the page break rate).
	This gives a 50 megabyte/second memory interface (while bursting in
	page).

The board currently runs a modified version of MON16 which enables a 32000
host system to download code, set break points, source level debug etc.
Compute performance is roughly 10 X a 32016 based system (ICM3216). I/O
performance should be considerably faster.

Total of 45 devices, including CPU etc, but excluding the DRAM SIMMs. There
are 2 D-speed PAL devices and 3 B-speed PAL devices on the board. All glue
logic, buffers and latches are either 74AS or 74ALS technology.

The PCB is 6 layers, 13 in x 8 in baby AT form factor. It connects to a
standard AT power supply (draws 2.6 Amps typical), has holes to mount in an
AT chassis, have 4 XT (mechanical only) slots that will accept XT or AT
wirewrap prototype cards (power pins are XT compatible).


-- 
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 Dec  4 14:44:24 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Mon, 4 Dec 89 10:31: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: I'm interested...

[In the message entitled "I'm interested..." on Dec  4,  0:39, Bob Izenberg writes:]
> 
> I'm going to call National to get whatever instruction set docs they have
> for the CPU and FPU.  Somehow I'll bet that Dave or George has a number
> for their tech pubs people.  When I called for the 32016 book, I recall
> having to try three or four wrong numbers before finding the one that I
> don't have anymore...
The best way is to call your local rep. They should be able to give
you a programmers reference manual (should be available in your local
Prentice-Hall bookstore). If you call National, you may have more success
getting the data sheet for the NS32GX32 - The instructions are the same
as the NS32532.

> I haven't seen a newsletter issue
> since moving, so I'm curious if the "pc532" has had a write-up there or
> anywhere yet?
No, we have not written up anything for publication yet.


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

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Mon Dec  4 14:44:24 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Mon, 4 Dec 89 10:31: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: I'm interested...

[In the message entitled "I'm interested..." on Dec  4,  0:39, Bob Izenberg writes:]
> 
> I'm going to call National to get whatever instruction set docs they have
> for the CPU and FPU.  Somehow I'll bet that Dave or George has a number
> for their tech pubs people.  When I called for the 32016 book, I recall
> having to try three or four wrong numbers before finding the one that I
> don't have anymore...
The best way is to call your local rep. They should be able to give
you a programmers reference manual (should be available in your local
Prentice-Hall bookstore). If you call National, you may have more success
getting the data sheet for the NS32GX32 - The instructions are the same
as the NS32532.

> I haven't seen a newsletter issue
> since moving, so I'm curious if the "pc532" has had a write-up there or
> anywhere yet?
No, we have not written up anything for publication yet.


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

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Mon Dec  4 14:44:24 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Mon, 4 Dec 89 10:31: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: I'm interested...

[In the message entitled "I'm interested..." on Dec  4,  0:39, Bob Izenberg writes:]
> 
> I'm going to call National to get whatever instruction set docs they have
> for the CPU and FPU.  Somehow I'll bet that Dave or George has a number
> for their tech pubs people.  When I called for the 32016 book, I recall
> having to try three or four wrong numbers before finding the one that I
> don't have anymore...
The best way is to call your local rep. They should be able to give
you a programmers reference manual (should be available in your local
Prentice-Hall bookstore). If you call National, you may have more success
getting the data sheet for the NS32GX32 - The instructions are the same
as the NS32532.

> I haven't seen a newsletter issue
> since moving, so I'm curious if the "pc532" has had a write-up there or
> anywhere yet?
No, we have not written up anything for publication yet.


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

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Mon Dec  4 16:22:16 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Multiple processors (follow-on to add on card suggestion)
To: mips!daver.uu.NET!tarpit!pc532@EDDIE.MIT.EDU
Date: Sun, 3 Dec 89 14:48:32 EST
From: John L. Connin <think!ames!mips!daver!uunet!manatee!johnc@EDDIE.MIT.EDU>
X-Mailer: Elm [version 2.1 PL1]


Alternative to pc532 add-on card suggestion:
-------------------------------------------

Multiple, pc532's would also provide a multi-processor capability,
which in the end result might be less expensive (ie. increase pc532
volume) and perhaps be more flexible.  Quite frankly, I do not know
which is the better arrangement.

With this in mind, would it be possible to reduce the width of the
pc532 card to say 7.75 inches from 8.50 inches ??.  Reason, two
7.75 inch wide cards will fit side-by-side in 17 inch a rack mount
case.  This change would not violate the current pc mounting design.

Assuming one is interested in multi-processors, IMHO two pc532's
per 17 rack-style case is better than two separate pc cases.
On the other hand, if one has only one processor board, the pc case
is probably the enclosure of choice.

The interior of a 17 inch rack mount case is approximately 17.0 plus
inches deep by 15.5 plus inches wide.  This would leave an area about
4 inches by 15.5 inches for such things as a power supply, etc.

If it can be done, a 7.0 inch width would be even better.  Rational,
the interior width of 17 inch rack case could accommodate one pc532
and 5 vertical half-height drive bays.  The present 8.5 inch board
width will permit 4 vertical half-height drive bays plus one pc532,
which is reasonable.

In any event, if the pc532 board width could be decreased by 0.75
inches to 7.75 inches, the mounting flexibility could be improved.

Best regards,
johnc


From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Mon Dec  4 16:24:04 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Add on card proposal..
To: mips!daver.uu.NET!tarpit!pc532@EDDIE.MIT.EDU
Date: Sun, 3 Dec 89 12:56:17 EST
From: John L. Connin <think!ames!mips!daver!uunet!manatee!johnc@EDDIE.MIT.EDU>
X-Mailer: Elm [version 2.1 PL1]


pc532 add-on card suggestion:
-----------------------------

I just received the pc532 schematics (thank you George) and it trigger me
to think about an add-on card design.  Very simply, I would like to propose
that we seriously consider a 532 processor add-on card which incorporates
a sub-set of the pc532 design plus one extension.

In broad strokes what I am proposing is:

        o  XT adapter board physical format (but with AT height),
        o  DP8490 SCSI interface via edge card connector
        o  32532 cpu
        o  32022 ICU ??
        o  32381 floating point processor
        o  8 - SIMM connectors for RAM (alternately DIP RAM if packaging
           dictates)
        o  1 - ROM
        o  optional on-board 3 1/2 inch hard disk plus interface

That is the pc532 design *less*:

        o  the 8 - rs232 serial ports,
        o  6250 SCSI disk / tape interface
        o  connectors conn12-conn15

        and the addition of:

        o  16-bit direct hard disk interface (forgot its industry name)
        o  3 1/2 inch hard disk (40 megabytes typical).

The reason for the optional harddisk is to provide swap and spool space
on-board (ie. without utilization of the SCSI bus and host).

Any comments ??

George, would the design physically fit on the board ??



SCSI bus connector spacing;
---------------------------

The bad news is that such a add-in board would cause interference with
an adjacent full-length card (ie added thickness in the area of the hard
disk).

That is the possibility of either (a) increasing the number of SCSI bus
connectors or (b) increasing the spacing between conn12 - conn15 ??

Independent of the above proposal, I might be prudent to consider the
addition of 3 more scsi connectors.


Best regards,
johnc


From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Mon Dec  4 16:32:48 1989
Flags: 000000000001
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Graphic Chips
To: mips!daver.uu.NET!tarpit!pc532@EDDIE.MIT.EDU
Date: Mon, 4 Dec 89 10:54:25 EST
From: John L. Connin <think!ames!mips!daver!uunet!manatee!johnc@EDDIE.MIT.EDU>
X-Mailer: Elm [version 2.1 PL1]

I thought the following article just posted in comp.graphics would
be of interest to all.

Best regards,
johnc
	----------------------------------------------------

Date: 2 Dec 89 06:43:30 GMT
References: <1414@utkcs2.cs.utk.edu>
Reply-To: rmf@bpdsun1.UUCP (Rob Finley)
Organization: Harris Broadcast Div., Quincy, IL
Lines: 52

In article <1414@utkcs2.cs.utk.edu> mueller@alphard.cs.utk.edu (Carl Mueller) writes:
>I have a pressing need to find out all there is to know about the
>following graphic controller chips:
>    TI 34010 and 34020
>    IBM 8514/A

I don't do graphics for a living, I do pcb's for radio transmitters and such.
Also, I am using VI telnetted from a PC.  So please forgive...

I have little experience with both.  But, here are some tips and observations:

If you want good 8514 hardware information and info on a very neato chip.
Call up Chips and Technologies (408) 434-0600 and ask for data on the 82C480.

This product and its companion chip, the 82B484 make up a full implementation 
of the 8514 display system.  Great specs great resoution, great stuff.  Next
spring the price for the chipset should be about $100 to $150.  The main chip
is packaged as 160 pins with -you guessed it- 25 mil centers.  Not your home
brew type of stuff.  It will work like the Compaq display board and can feed
through a VGA chip even to the point that they can share display memory.  Wild!
Any one know of a bios chip ready for this.  Can I steal the one from a PS2 in
the mean time???
Just a thought.

On the TMS34010.  A basic 34010 can be gotten at your distributor for a very
small amount of cash:  about $40 or $50.  It is also in a reasonable package
for homebrew.   The 64 pin flat package fits in a pin-grid array socket
quite nicely.  

The 8514 is essentially a display controller that does line
draws, area fills, and such.  It works well for what it is designed to do.
But, if you are going to do 3D rendering with it, the computational load
is stuck on the system processor.  On the otherhand, TI wrote a neat 
data sheet on a PC coprocessor that uses the microprocessor capabilities of
the '010 to do a wire frame simulation in real time!  I don't remember the
performance though.  You can do things like hang off DSP chips to do numbers
and all sorts of neat things.  Rave Rave Rave Rave.  Find the toll free
number of TI (800) 232-3200 and order the data book and the APPLICATIONS guide.
The guide also has things like doing 1024 by 768 where the PC loads up the
program on the 34010 board and it goes on its way.
Don't forget that you can emulate just about any PC graphics adapter with
the TI34010.  The Autocad stations we have here use 34010 boards from
Rennaisance to take vector lists from the 80286 and show it at 1024 by
768.  It works great.  The next version up emulates the 8514A :(  whish we had
waited...

Please let me know what you decided.  This is something I wanted to play with
until we are about to get Suns on our desks.  What is their shipping time now...
-----
Rob
	quintro!bpdsun1!rmf@lll-winken.llnl.gov
	uunet!tiamat!quintro!bpdsun1!rmf


From dlr%daver@mips.com Mon Dec  4 16:43:42 1989
Flags: 000000000000
Date: Mon, 4 Dec 89 12:54:25 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: dlr@daver (Dave Rand)
To: budd@bu-it.bu.edu
Subject: Re: I'm interested...

[In the message entitled "Re: I'm interested..." on Dec  4, 15:18, mips!bu-it.BU.EDU!budd writes:]
> 
> What IS a 32GX32?  Newer than the 532?
> 
A NS32GX32 is a pin-compatible, software-compatible, functionally-compatible,
logic-compatible (everything-compatible) Series 32000 part, compatible with
the NS32532.

It was brought out as an "embedded systems processor" marketing alternative.

It is not meant to have an MMU in it.

It is a *lot* cheaper than the 532. A Whole Lot. The advertised price
in 1,000's is $99, and I have received a quote for much less than this.

The 532 lists at about $590. The GX lists at $187.

Give me a call if you want more info...

Dave
408/434-0600 X4555
408/733-4125 home


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

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Mon Dec  4 16:58:58 1989
Flags: 000000000001
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Mon, 4 Dec 89 12:44:54 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 question & PC boards?

[In the message entitled "SCSI question & PC boards?" on Dec  4, 21:45, Jukka Virtanen writes:]
> 	We are wondering why you have two different SCSI chips on
> 	PC532. If you have any specific reasons, please tell.
Originally, we had two DP8490's on the board. On talking to Hitachi,
we learned that they have *very* cheap 1.2 gigabyte 5.25" drives ($2300).
Regretfully, we learned that to obtain maximum transfer rate (4 megabytes
per second), we had to use synchronous SCSI. Even though the DP8490 was
capable of 3.8 meg/sec, the drive would only do 1.2 meg (or so) asynchonous.

We talked to the folks at National, and were told that we could not expect
a synchonous SCSI chip from them for some time (this was about a year ago).
On talking to Adaptec, they had a chip that could do sync and async, fairly
cheap, and with a very low external parts count. So we chose the AIC-6250
for the external disk/tape bus.

> 
> 	Also, do you have any reasons why the DP8490 *should* be used
> 	for the I/O bus (instead of some other device, like WD or whatever)?
> 
> 	Two reasons come to mind, as Dave said, it's tiny and cheap
> 	(USD 5$). I was not aware that ASYNC SCSI works at 3.8 MB/s,
> 	I thought that the sync version was made to achieve that kind
> 	of transmission rates. But then again, I only thought so.

True. We are actually able to drive the SCSI >3.8 meg per second, but
the chip cannot drive the bus any faster than 3.8 meg per second.

The primary advantage of the DP8490 is that it has an "extended" mode
of operation - yet retains compatibilty with the NCR-5380. This extended
mode of operation takes the drugery out of arbitration, by letting the
chip do it, then interrupt the CPU when the arbitration is complete.

> 
> 	Since I'm not familiar with the DP8490, is it nice to write
> 	software to? No religious war, please.
Well - it ain't simple. But it isn't that tough, either. I am trying
now to get it to talk in a multi-master mode with the ICM-3216. Sigh.
Thank goodness for tape backups :-)

> 
> 	If everything goes well, it is possible that we'll design a
> 	board (with 80860 & graphics) that can be attached to the
> 	PC532 SCSI and/or to PC-AT bus. We've written some specs out
Great! Please share it with us when you can.

> 
> 	Then: I read that you are planning to make another round
> 	for the PC-boards. Can you tell me any estimates of the
> 	costs, I will propably want one.
As soon as we get some quotes, we'll let you know. Again, if any of
you folks can do a 6 layer board in some local fab, *please* let us
know.

> 
> 	Also, are you planning to do a PCB-round for the Ethernet board?
> 	I'd like to get also that. (It's kinda stupid to order
Yes. (Secret time: The Ethernet board can be used as a stand-alone
computer on its own right. It has 1 megabyte of memory, 16 serial
ports, a GX32 (or 532) at 20 Mhz, Ethernet, and a SCSI. No fundamental
difference from the main board, except it has only one SCSI, no FPU,
and less memory.) The quote we got back, for a run of 10 boards (20
work day delivery) was a fab cost of $291 per board. A larger run
is less cost per board, of course. 

> 
> 	There are some other people around here that are also
> 	interested, but we need to have *some* information of the
> 	board cost. What's the value of 32532 et. al. nowadays?
The trick is to get as many done at once as we can. The cost per board
drops dramatically, when the number of boards increases. We are hoping
for a tested per-board cost of $200USD.

Today, I sent a FAX to the appropriate parties at National. I *hope*
to be able to get some support from them - again, no promises.

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

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Mon Dec  4 20:49:28 1989
Flags: 000000000001
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Mon, 4 Dec 89 16:38 PST
From: think!ames!mips!daver.uu.net!dlr@EDDIE.MIT.EDU (Dave Rand)
To: mips!daver.uu.net!pc532@EDDIE.MIT.EDU
Subject: First response

I just got the first response from National... here's what is going on.

National currently has a NS32CG16 development board, with several IBM PC
slots. This board has a CG16 (like 32016 with graphics instructions) running
at 15 Mhz, up to 8 megabytes of RAM, a HPC micro-controller, sound output,
etc. Basically, the functions you would find on a standard IBM-XT motherboard.

The current retail price for this board is $1,200 USD with 2 megabytes
of RAM. An article is being planned for early next year in one of the
trade magazines, with a special price for these boards. The exact price
has not been set yet, but should be fair.

The slots are IBM-PC Compatible. While at National, I was able to get
Hercules-compatible cards to run, an Ethernet card (using DMA), and the
basic I/O for floppy disk. The address space of the card slots are
accessed as an address range in the CG16's memory space. The I/O ports
are similarly mapped. There is no provision on the NS32CG16 for a MMU,
so no virtual environment is provided for.

If you would like more information on this, let me know. National has
agreed in principle to a low(er) cost on this board for a group buy - again,
the more people, the lower the cost.

National also has a NS32GX32 development board, with two IBM PC slots, 
and two AT slots, as well as a "native" bus expansion. It has a DP8490
SCSI chip on it, and comes with 4 megabytes of memory.

The NS32GX32 runs at 30 Mhz, with one wait state (in page) on first
access. The GX32 is much like a 32532, but (again) without the MMU.
An MMU can not be added to this board, but a 32532 could be replaced.

This board currently retails for $2,995 USD, but again, if people are
interested, we can arrage a group purchase. National was not willing
to discuss the final cost (to us) at this time, but suggested that
it would be reasonable.

Of course, both of these boards have sound output.

In both boards, the bus is single-master. Even though the IBM-AT
bus can support multi-master, this implementation does not. Performance
of the PC bus is quite slow (as you already know), so high-speed I/O
is not an option on these boards...

They do, however, provide for low-cost expansion boards. For some
of you, this may be a more important factor. 

If you are interested, in either of these boards, please let me know, and
I will find out the final price.

Dave Rand

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Mon Dec  4 20:54:23 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Tue, 5 Dec 89 00:30:07 +0100
From: P{r Emanuelsson <think!ames!mips!isy.liu.se!pell@EDDIE.MIT.EDU>
To: mips!daver.uu.NET!pc532@EDDIE.MIT.EDU
Subject: Archive

Digests from the current discussion of the PC532 is available by
anonymous FTP to isy.liu.se (130.236.1.3), directory "32k/PC532". It is
updated daily.

Note that my digests are identical to Dave's up to, and including, #5.
After that, I've saved each article to the digests myself so the sizes
and number of articles per digest is possibly different from Dave's.

The "32k" directory was originally intended to be a repository of beowulf's
archive, but when the stuff arrived here it needed a major cleanup, on
the order of several days of tedious work. The only stuff I had patience
enough to finish is in the "Monitors" directory.

In the "32k" directory there is also a "tools32k.tar.Z" file. I seem to
remember that it's Bruce Culbertson's (culberts@hplabs.hp.com) assembler
and loader (plus a few other utilities). Looks like this:

15% zcat tools32k.tar.Z |tar tvf -
rwxrwxr-x207/117      0 Dec  8 19:14 1988 as_dist/
rw-rw-r--207/117   1014 Dec  1 19:43 1988 as_dist/Makefile
rw-rw-r--207/117  12030 Jul  2 22:56 1988 as_dist/exp.c
rw-rw-r--207/117    202 Jul  2 22:56 1988 as_dist/glob.c
rw-rw-rw-207/117  11168 Dec  8 04:51 1988 as_dist/glob.h
rw-rw-r--207/117   5273 Dec  8 04:51 1988 as_dist/init_in
rw-rw-rw-207/117  19397 Dec  8 04:56 1988 as_dist/inst.c
rw-rw-r--207/117   3188 Jul  2 22:56 1988 as_dist/list.c
rw-rw-r--207/117   3697 Dec  1 19:32 1988 as_dist/main.c
rw-rw-r--207/117   2635 Jul  2 22:56 1988 as_dist/mk_init.c
rw-rw-r--207/117  19348 Jul  2 22:56 1988 as_dist/phase1.c
rw-rw-r--207/117   6076 Jul  2 22:56 1988 as_dist/phase2.c
rw-rw-r--207/117   6489 Jul  2 22:56 1988 as_dist/phase3.c
rw-rw-rw-207/117  10834 Jul  2 22:56 1988 as_dist/pseudo.c
rw-rw-rw-207/117   3617 Jul  2 22:56 1988 as_dist/util.c
rw-rw-r--207/117     24 Dec  1 19:28 1988 as_dist/version
rwxrwxr-x207/117      0 Dec  8 19:18 1988 ld_dist/
rw-rw-r--207/117    248 Jun 29 05:12 1988 ld_dist/Makefile
rw-rw-r--207/117   3004 Jul 11 02:57 1988 ld_dist/ld.h
rw-rw-r--207/117  16769 Sep 16 03:51 1988 ld_dist/ld1.c
rw-rw-r--207/117   9428 Jul 12 18:42 1988 ld_dist/ld2.c
rwxrwxr-x207/117      0 Dec  8 19:19 1988 utl_dist/
rw-rw-r--207/117    399 Jul  1 23:08 1988 utl_dist/Makefile
rw-rw-r--207/117   7430 Jul  2 22:56 1988 utl_dist/ar.c
rw-rw-r--207/117   3693 Jul  2 22:56 1988 utl_dist/nm.c
rw-rw-r--207/117   9691 Sep 16 04:20 1988 utl_dist/ranlib.c
rwxrwxr-x207/117      0 Jun 12 00:27 1987 include/
rw-rw-r--207/117   3596 Jul  2 22:56 1988 include/a.out.h
rw-rw-r--207/117    551 Jul  2 22:56 1988 include/ar.h
rw-rw-r--207/117   1744 Jul  2 22:56 1988 include/conv.h
rw-rw-r--207/117    203 Jul  3 22:15 1988 include/magic.h
rw-rw-r--207/117   1040 Jul  2 22:56 1988 include/ranlib.h

In the directory "32k/532-group" there are some articles from an old
mailing list from last year.

Cheers,

    /Pell
--
Dept. of Electrical Engineering	                         pell@isy.liu.se
University of Linkoping, Sweden	                    ...!uunet!isy.liu.se!pell

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Mon Dec  4 20:56:19 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Mon, 4 Dec 89 17:12:30 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: sync/async scsi

[In the message entitled "sync/async scsi" on Dec  5,  0:11, Jukka Virtanen writes:]
> 
> 
> 	Great! I mixed them up.
No, you didn't!

> 
> 	So DP8490 is a ASYNC (a.k.a. faster) only SCSI controller,
> 	the other one knows both that and the old-slow-sync one,
> 	right?
> 
No. The DP8490 is ASYNC (a.k.a. SLOWER) only SCSI controller.
The AIC-6250 is SYNC (a.k.a. FASTER) and ASYNC.

The AIC-6250 can do up to 5 meg/sec sync, and (only) 3 meg/sec async,
which is why we didn't use it in both places...

As it turns out, the AIC-6250 is significantly harder (in my opinion)
to talk to, as well.

Older SCSI devices implement async SCSI, meaning that each byte is
passed via the REQ/ACK protocol on the SCSI bus. In the case of
sync SCSI, many REQ's may be issued before an ACK is required. In the
case of AIC-6250, up to 8 bytes may be "outstanding" (waiting for the
ACK).

This gets rid of the dead time on the SCSI bus, after the ACK, but before
the bus can release the REQ and send the next one...

I know we have a number of SCSI experts on this list - please feel free
to correct me and/or place a more complete description of sync/async.


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

From daver!dlr@uunet.UU.NET Mon Dec  4 23:54:43 1989
Flags: 000000000000
Date: Mon, 4 Dec 89 19:58:46 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: GX

[In the message entitled "GX" on Dec  4, 16:47, uunet!bu-it.BU.EDU!budd writes:]
> 
> thanks... just wondering..  and the 532 has a builtin MMU?
> I never realized!
> 
True. TLB hits take zero clocks. You *can* do a memory to memory add,
translated to physical, in two clocks. Neat, huh?


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

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Tue Dec  5 00:40:44 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.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Re: Add on card proposal..
Date: 4 Dec 89 21:14:21 PST (Mon)
From: think!ames!mips!wombat!george@EDDIE.MIT.EDU (George Scolaro)

[In the message entitled "Add on card proposal.." on Dec  3, 12:56, John L. Connin writes:]
> 
> pc532 add-on card suggestion:
> 
> to think about an add-on card design.  Very simply, I would like to propose
> that we seriously consider a 532 processor add-on card which incorporates
> a sub-set of the pc532 design plus one extension.
> 
> That is the pc532 design *less*:
> 
>         o  the 8 - rs232 serial ports,
>         o  6250 SCSI disk / tape interface
>         o  connectors conn12-conn15
> 
>         and the addition of:
> 
>         o  16-bit direct hard disk interface (forgot its industry name)
>         o  3 1/2 inch hard disk (40 megabytes typical).
> 
> Any comments ??
> 
> George, would the design physically fit on the board ??

It might fit, but it would certainly be a job to route the board. In fact
I think that the main problem that will face any I/O board that we dream
up is that 1) someone has to route the board (I did not particularly enjoy
doing the PC532), 2) enough people have to want a particular board to get
a reasonable volume price on the pcbs.

It struck me that one way to package the pc532 in a multi board setup is to
stack the boards vertically, ie don't populate one of the slots with a
62 pin connector, but put a male on the back side of the top board, and a
female connector on the top side of the bottom board. You can get connectors
explicitly made for connecting boards together. How's that for a really
hairbrained idea?

> SCSI bus connector spacing;
> ---------------------------
> The bad news is that such a add-in board would cause interference with
> an adjacent full-length card (ie added thickness in the area of the hard
> disk).
> That is the possibility of either (a) increasing the number of SCSI bus
> connectors or (b) increasing the spacing between conn12 - conn15 ??

The above requirements are sort of contradictory, its a bit hard to increase
the spacing and also increase the # of connectors. In fact, the reason that
there are only (only?) 4 connectors is that any more would make it impossible
to have full length boards in the new slots since they would hit the ram
SIMMs. Doing a re-lay of the board would enable the SIMM's to be move a bit
to enable another connector or so. The current board is an evolution from a
previous concept (when rams cost heaps) which had 4 megabytes max with
256kx4 drams. Just before fabbing the board we noticed the steady decline of
the SIMM pricing and I figured out how to get 0/1 wait using non-interleaved
memory, so I re-did the RAM array routing plus the drivers etc (boring!!)
and ended up with the pcb we now have. Of course that meant that the
placement of the SIMM was dictated by the placement of the rest of the logic
but there was no way I was going to change any of that.

I am not sure if many of you appreciate the work that goes into routing a
pcb, but it sure is a pain in the rear end. If any of you enjoy that kind
of brain deading work, please tell me and I will gladly send you netlists
etc of boards I would like routed.... (Note I don't want an autorouted
board with a million vias and clock lines that run around the periphery of
the board 8 times)!

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 Tue Dec  5 00:41:15 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.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Re: TermPwr Jumps
Date: 4 Dec 89 20:38:20 PST (Mon)
From: think!ames!mips!wombat!george@EDDIE.MIT.EDU (George Scolaro)

[In the message entitled "TermPwr Jumps" on Dec  4, 19:07, John L. Connin writes:]
> 
> It might be a good idea to add jumper terminals inline with each
> SCSI TermPwr signal.
> 
> Best regards,
> johnc

I'm not too sure what you mean here. The Disk SCSI (aic6250) must supply
power to the cable, its the other end that decides whether or not it needs
external power for the terminators. Note that the diode ensures that if two
units both supply terminator power, that one doesn't end up powering the
others +5V requirement. With respect to the I/O SCSI, being a 62 pin PC/XT
connector, it doesn't conform to the 50 pin SCSI cable pin out anyhow.
Besides the 62 pin connector has +5, +/-12 and GND, and obviously any board
that plugs in will get terminator power from the PC532 (without need to
resort to TermPwr).

Is this what you were worried about?

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 Tue Dec  5 09:00:02 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Mach and OS Recommendation
To: mips!daver.uu.NET!tarpit!pc532@EDDIE.MIT.EDU
Date: Tue, 5 Dec 89 2:17:26 EST
From: John L. Connin <think!ames!mips!daver!uunet!manatee!johnc@EDDIE.MIT.EDU>
X-Mailer: Elm [version 2.1 PL1]


I sent the following message to the "Mach Distribution Coordinator"
and just received the reply which follows:

Message
-------

> To: Lori Iannamico, Mach Distribution Coordinator
>
> Is it possible to obtain a copy of Mach *less* any code requiring
> nn AT&T or BSD source code license??
>

Reply
------

> From: uunet!SPICE.CS.CMU.EDU!Lori.Iannamico
>
>John,
>
>Nothing like that is available at this time.  Our next release, Mach 3
>will be free of such code,except for the drivers.  We hope to have Release
>3 ready for distribution by March of 1990.
>
>Lori Iannamico
>Mach Distribution Coordinator
>lli+@spice.cs.cmu.edu
>

OS Recommendation:
------------------

1)  Adopt and port Bruce Culbertson's version of Minix to the pc532.

2)  On an incremental basis, incorporate those portions of Mach which make
    sense (eg  Virtual Memory, etc)

Quite frankly, with the possible exception of Tunis, all other alternatives
look quite remote.

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

Someone mentioned reverse engineering BSD.  I have no idea of the legal
implications.  However, if any one is interested I have the source code
to 'decomp', an object file de-compiler.

All things considered it really does a good job.  The bad news is that it
was designed specifically to decompile VAX b.out objects.  The code is
cleanly written but it would take a fairly large investment of time to
a) understand how it works, and b) convert it to understand 32000
instructions ( and COFF format if appropriate).

If any one is really serious and willing to invest the time, a better
approach IMHO would be to convert it to understand GNU's  RTL (register
translation language).  Then write a program to translate 32000 objects
to RTL.  The latter should be fairly straight forward.

Best regards,
johnc


From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Tue Dec  5 16:42:23 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: 
To: mips!daver.uu.NET!tarpit!pc532@EDDIE.MIT.EDU
Date: Tue, 5 Dec 89 13:35:37 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 "TermPwr Jumps" on Dec  4, 19:07, John L. Connin writes:]
>>
>> It might be a good idea to add jumper terminals inline with each
>> SCSI TermPwr signal.
>>

[ George's reply]

>I'm not too sure what you mean here. The Disk SCSI (aic6250) must supply
>power to the cable, its the other end that decides whether or not it needs
>external power for the terminators. Note that the diode ensures that if two
>units both supply terminator power, that one doesn't end up powering the
>others +5V requirement. With respect to the I/O SCSI, being a 62 pin PC/XT
>connector, it doesn't conform to the 50 pin SCSI cable pin out anyhow.
>Besides the 62 pin connector has +5, +/-12 and GND, and obviously any board
>that plugs in will get terminator power from the PC532 (without need to
>resort to TermPwr).
>
>Is this what you were worried about?

Quite frankly, from a technical point of view as far as *I* can see there
is no need to provide in-line jumper blocks in the TermPwr lines.  On the
other hand I am not a SCSI expert at this point.  As you point out the
in-line diode prevents one unit from powering another unit.  I was
reacting to the fact that two host adapters and two SCSI hard disks
I looked at all provided in-line TermPwr jumpers.  For reference, the
host adapters are Adaptec AHA-1540 and Western Digital 7000-Fasst, and
the hard disks are Maxtor XT-4000S and CDC Wren III.

Again, I do not understand why and none of the manuals are really clear
in this regard, but the Adaptec 1540 Manual states in section 3.2.4,
"If another SCSI device is supplying terminator power, then F1 may
optionally be removed.  No more than 5 SCSI devices should be configured
to supply terminator power to a single SCSI bus".

Focusing on the words "No more than 5 SCSI devices", and not really
knowing the reason why, it seemed to me that in-line jumper blocks
might be prudent.

Best regards,
johnc


From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Tue Dec  5 19:56:46 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Tue, 5 Dec 89 15:59:20 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: Re: TermPwr Jumps

[In the message entitled "re: Re: TermPwr Jumps" on Dec  5, 10:20, uunet!s49.prime.com!KENYEE writes:]
> 
>     Ariel Electronics (Sunnyvale)
> It's claimed that a six-layer board with 150 ICs done with Ariel equipment
> can be done in five hourse for about $200.  In quantity, these baords are
> more expensive, but for protos they might be cheaper...
> 

Well, since they are local, I gave them a ring. Here's the story.

Ariel sells the equipment to do boards. The price is $60-65,000 USD.
They extrude a conductive polymer, followed by a non-conductive polymer.
The polymers cure quickly, and allow subsequent "traces" to be placed
without delay.

They currently do not have the equipment available, and won't until the
middle of next year. They do not offer a short-run service, but expect
someone in the valley here will.

So - this isn't an option, at the moment. I'm also suspicious of the
conductive polymer approach... I have an info packet on the way though.


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

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Tue Dec  5 20:08:22 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Tue, 5 Dec 89 16:03:41 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: Followup

[In the message entitled "Followup" on Dec  4, 22:27, John L. Connin writes:]
> 
> 
> >> 3)  Availability of guideline SCSI software (eg. as mentioned in AN-563
> >>     "A SCSI Printer Controller Using Either the DP8490 EASI or DP5390 ASI
> >>     and Users Guide").  Does any one have this or know how to easily
> >>     obtain it ??.
> >
> >I have this. I am uncertain of the legality of distributing it, though.
> >I will check on it an get back to you.
> 
> Thank you.
> 
I have three applications notes on the way from National. They include
code, and apparently can be distributed without problems. I'll make it
available whenever you are ready. I have also written code for driving the
SCSI in a non-interrupt mode - this too is available.

> Out of curiosity, is the "Computer Store" the same as the "Computer
> Surplus Store" that advertises in the Computer Shopper ??

Yes. This is also called the "Wierd Stuff Warehouse" (no kidding).

If you are *ever* in San Jose, take the opportunity to go here. It is
quite a fun place to spend an hour or 3. They really do have a lot of
stuff, most of it quite weird :-)


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

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Tue Dec  5 22:23:35 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Tue, 5 Dec 89 18:09:04 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: Minor intro and questions...

[In the message entitled "Minor intro and questions..." on Dec  5, 16:05, Jon Loeliger writes:]
> Can we make a priority list for the OS in some way?  I'm thinking along
> the lines that some of the proposed solutions are NOT feasible for
> another 6 months or so.  In particular, I think I read a "free" Mach
> is not available until March era while MINIX could be implemented
> today.  A completely un-strung BSD is still in the future a ways.
> Any other external restrictions or bottlenecks?  What are the hardware
> imposed limitations/necessities on the OS?

There are no hardware-constrained limits on the OS, unless you consider
4 megabytes a limit - of course you can always swap the kernel :-)

A clarification here. MINIX Will Be Available. No decisions required on
this, whatsoever. I will be porting from Bruce Culbertson's 32000 Minix,
with his help (if he can spare the time...)

Real Unix is up to you folks. So far, I have only two "votes" for
Unix. Any of the Unixes will cost Real Money. If you are really
interested in Unix, let me know, and I'll pursue getting my license
upgraded to V.3.2 (the last release National has, and probably will
do). This will mean commitment on your part, esp. if the upgrade costs
more than a few hundred dollars. I heard $100,000 being bantered around,
but I think (I hope!) that was for source upgrade.

As mentioned before, I do have a simple O/S running on the card with
native compilers. This runs now, but I don't think it is "good enough"
to release.

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

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Tue Dec  5 22:27:14 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Tue, 5 Dec 89 18:10:11 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: Repost of message

[In the message entitled "Repost of message" on Dec  5, 14:45, Nicolai Kosche writes:]
> 
> >From nk Mon Dec  4 19:25:11 1989
> >To: pc532@daver.uu.net
> >
> >Is there interest in providing a populated board?
Dunno - so far you are the only one to ask... Perhaps someone would like
to build more than one board?


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

From jap@proteon.com Wed Dec  6 10:42:49 1989
Flags: 000000000000
Date: Wed, 6 Dec 89 10:38:19 EST
From: jap@proteon.com (John A. Papadopoulos)
To: budd@bu-it.bu.edu
Subject: Re:  Fabs for 6 layer boards

Hmm...not a trivial question to answer.

Yes, I know of several board shops that can perform the task but their are
many issues involved.


1)	What form of data is to be sent to the board shop?

	Is their existing artwork, in the form of Mylar photoplots or
	as Gerber data files?

	If their isn't such artwork and you only have a netlist and a 
	partslist then:

	Is there a mechanical drawing of the board showing board dimensions?

	Is their a drill tape for numerically controlled drill machine?

	Is there a fabrication drawing showing the drill sizes for all the
	holes, the stackup of the layers of the board, and any special
	manufacturing guidelines and/or specifications for details such
	as copper thickness, machining of the edges of the card, etc?

	Of course, you are now looking at the task of getting the board
	layout designed by this shop in addition to having them produce it.

	This is a costly and potentially lengthy task so it is very wise
	to pick a shop that is near by so that you can work fairly closely
	with them to resolve questions about component placement and signal
	routing, etc.  You can send them data and have them do everything
	but they don't (and can't) worry about critical areas of the design
	because they are not electrical engineers that will be looking at 
	your schematics (if you have any) and making decisions about how  
	to route the board.  The problem with this is it is difficult to
	provide all of the needed data up front (i.e. all of the drawings
	that I mentioned above).  In addition, there are bound to be 
	conversions needed to get the netlist and partslist into a form that
	they can use.  I would expect this cost several thousand dollars.
	The complexity of the design, which is increases with the number
	of signals (nets) and components and decreases with board size is
	a major factor in setting cost as is the schedule for completion.

	In the end, it may prove best to find a shop that has done this very
	same board before and see if they can replicate more for the group.

	This will certainly involve tracking down the engineer(s) responsible
	for the design and getting the info and their permission in writing.

	If there is a set of artwork then the problem is quite easy and I
	can reccommend a few shops that specialize in small lots of boards.

	Give me some more feedback on this problem and I can start narrowing
	down the list of shops to the ones that will be best suited for the
	project.


	John...

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Wed Dec  6 16:14:13 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Wed, 6 Dec 89 13:46:35 EST
From: think!ames!mips!masig3.ocean.fsu.edu!mccalpin@EDDIE.MIT.EDU (John D. McCalpin)
To: mips!daver.uu.NET!pc532@EDDIE.MIT.EDU
Subject: FPU performance

Does anyone have any info on the (potential) performance of the FPU
(32582?) on this board?

The last time I looked at any of the National FPU's, it was for the 
(then-called) 16032 cpu, and the performance looked OK, but that was
lots of years ago.

Useful info might include:
	(1) How many clocks are needed to do a 32-bit FP add or multiply?
	(2) Does this device work with an extended-precision
	    internal format like the 80x87 and 68881/2 chips?
	(3) Does anyone have any real performance numbers?
	    (like the C version of LINPACK?).

For comparison, the 68881 requires about 50 cycles to do an FP add
and the 68882 cuts that down to 41.  The 88000 requires only 5 cycles
for this operation....

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Wed Dec  6 20:55:31 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Wed, 6 Dec 89 16:32:02 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: think!ames!mips!vw25.chips.com!gs@EDDIE.MIT.EDU (George Scolaro)
To: mips!daver!pc532@EDDIE.MIT.EDU
Subject: pcb for the pc532

Ok, I have got some cold hard facts for all you out there that are interested
in getting hold of pc532 PCBs. I rang a local pcb house (a good one) and
have got pricing for doing another run of PCBs.

10	US$208/each	+ $350 tooling and $380 test (1 time charge)
20	US$167/each		ditto
30	US$156/each		ditto

The photoplotting will be around $200-250 which is also a one time charge.

These prices are for 4 week turn around (ie 20 working days) which is the
cheapest rate available. A 2 week turn adds about $20/board. So, now is the
time to start deciding if you really want to commit to a pcb. I have told the
pcb house that Mid January would be when I'd get boards made, but obviously
if enough of you want to commit before xmas (ie have money left over) then
we can do a run of boards earlier. If I can get at least 10 real commitments
then I will do a run of 20 and bankroll the rest, since it appears that the
best deal is the 20 off price which including the 1 time tooling/test and
photoplotting will come to approx US$215/board. So, please email your reponse
if you definitely ($$) want a PCB, and also if you will want one early '90.
Note that the pcb run would include the features that Dave and I have
mentioned before and that the parity circuit (for those that really want it)
is also on the new design.

thanks,

-- 
George Scolaro
(try daver!vw25.chips.com!gs)

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Thu Dec  7 01:23:40 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Mach clarification
To: mips!daver.uu.NET!tarpit!pc532@EDDIE.MIT.EDU
Date: Wed, 6 Dec 89 23:49:12 EST
From: John L. Connin <think!ames!mips!daver!uunet!manatee!johnc@EDDIE.MIT.EDU>
X-Mailer: Elm [version 2.1 PL1]

The reply I received regarding Mach Release 3 was somewhat unclear 
regarding license requirements, so ask for clarification and 
received the following:

> To: "John L. Connin" <johnc%manatee>
> Subject: Re: Mach Release 3 
> In-Reply-To: Your message of Tue, 05 Dec 89 12:20:32 -0500.
>             <8912051735.AA01419@uunet.uu.net> 
> Date: Wed, 06 Dec 89 15:39:10 EST
> Message-Id: <26367.628979950@SPICE.CS.CMU.EDU>
> From: uunet!SPICE.CS.CMU.EDU!Lori.Iannamico
>
> John,
>
> Ok, here's the deal.  You'll need a Berkeley 4.3 BSD to obtain the 3.0
> release.  But machine independent code will be available without
> licensing.  The Unix server will still be covered by the Berkeley license
> but that may change, too.
>
> I'll keep you posted.  This information is definitly subject to change.
>
> Lori

Best regards
johnc


From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Thu Dec  7 04:25:58 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.UU.NET!pc532@EDDIE.MIT.EDU
Subject: Re: FPU performance
Date: 7 Dec 89 00:03:52 PST (Thu)
From: think!ames!mips!wombat!george@EDDIE.MIT.EDU (George Scolaro)

[In the message entitled "FPU performance" on Dec  6, 13:46, John D. McCalpin writes:]
> 
> Does anyone have any info on the (potential) performance of the FPU
> (32582?) on this board?

32381 is the FPU part number that is on the pc532.

> 
> The last time I looked at any of the National FPU's, it was for the 
> (then-called) 16032 cpu, and the performance looked OK, but that was
> lots of years ago.
> 
> Useful info might include:
> 	(1) How many clocks are needed to do a 32-bit FP add or multiply?

FPU add is 11/42 clocks (same time for 32 bit or 64 bit)
FPU multiply is 11/31 clocks (for 32 bit or 11/38 for 64 bit).

The first time is from receipt of the last operand from the cpu to
the generation of the early done (ie the 532 can commence the next
instruction, since no error will occur), the second time is the total
elapsed time from receipt of the last operand and the fpu completing
the instruction and being ready for the next operand. ie the 32381
can operate in parallel with cpu for most of the actual fpu time, IF
the compiler can seperate FPU/integer instructions sufficiently.
The FPU runs at 25 Mhz, the same speed as the 32532. Note also that
the 32081 took:

FPU add 70 clocks
FPU multiply 44 clocks for 32 bits and 62 clocks for 64 bits.

and the 32081 was a 10 mhz part (or 15 mhz with a 32332). Note also
that the 32532 transfers operands to the 32381 much faster than the
old 32k and 32081. The operands are transferred via a 32 bit bus and
use a faster protocol. Another neat thing is that the 32381 is a
CMOS device (ie does not glow at the surface temperature of the sun)
and more to the point will power down (to 10% power consumption) if
it doesn't receive work from the CPU with 256 clocks, it will start
up instantly with no performance penalty. It also has some new
instructions to support transcendental operations, it has:
	SCALBf
	LOGBf
	DOTf
	POLYf
Also supported transparent to existing software are 4 additional
64 bit FPU registers. Old software accesses 64 bit FPU registers
as L0, L2, L4 and L6 (which mapped into F0/F1, F2/F3, F4/F5 and
F6/F7) new software can access the new 4 64 bit registers as L1,
L3, L5 and L7.

> 	(2) Does this device work with an extended-precision
> 	    internal format like the 80x87 and 68881/2 chips?

No, NS has never supported extended precision on their FPUs, 64 bits
is it.

> 	(3) Does anyone have any real performance numbers?
> 	    (like the C version of LINPACK?).

No, we have linpack in fortran so we will run that, if someone has
it in C please email to us. We'll post the numbers as soon as we can.

> For comparison, the 68881 requires about 50 cycles to do an FP add
> and the 68882 cuts that down to 41.  The 88000 requires only 5 cycles
> for this operation....

Well, we're faster than the 68k stuff, but quite a bit slower than
the 88k (but then we are cheaper!).

-- 
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 Dec  8 11:09:17 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Thu, 7 Dec 89 23:35:14 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: OSes and such

[In the message entitled "Re: OSes and such" on Dec  7, 22:11, Karl Swartz writes:]
> > >Dave has said he's well along on getting SVR2 running on the PC532.
> > >That doesn't sound very remote to me.
> 
> Dave's more recent comments make it clear that I had my head in my
> armpit when I said that.  Sorry.
> 
No problem - what I do for myself is one thing. Supporting UNIX is
something quite different. If my machine crashes every day (like
daver.uu.net was doing for over 6 months, until I found and fixed
some of the more nasty bugs in V.2.6.1), I don't mind. Most other
folks would get a trifle upset, though.

If you *really* want UNIX, you need to tell me. It means that
1) I try to beat up NS to get 3.2 in Binary.
2) I do a complete port, perhaps with the help of some of the
   other binary redistributors on this list (John?)
3) I have to support the port. This means that when you find a bug,
   I have to find it, and fix it, in binary. Upgrading to V.3.3 or V.4
   likely will not be an option. Source will not be an option.

I can't count on anyone else (including NS) to find & fix bugs for
me - if you buy a UNIX from me, you are going to want support, one
way or another. So I need to know what you folks want...

The reason MINIX will be available is so that we can use the
boards, quickly and at a very low software cost. This is in
line with the original goals of the board. As an aside, I also
feel that this is the way to get the maximum performace from
this board. 700+K kernels are FAR too bloated to get performance -
you don't even know where to start tweaking.

I also have a lead on an O/S called Oberon. This is running, now
on a very similar 532 system. As I get more information on this,
I'll pass it along.


> What about the folks in Canada (U. Toronto?) who did the BSD 4.2 port
> to the ICM?  Any chance they might be enticed to move it over to the
> PC532, perhaps if a few of us were to fund the contribution of a system
> for them to use?  With their ICM investment I'd think they'd have a lot
> of interest in the PC532.

I have tried several times to get in touch with these folks, to no
avail. If *anyone* has a direct contact with responsible people at
U of T, please drop me a line, and I'll follow up on it.

I, too, would like to see 4.3 BSD on this hardware. I'm willing to
put the effort in to get it done, but so far have made no headway.

Summary:

Some folks want/need UNIX. If you are in this catagory, please
make yourself heard! (kls@ditka excepted :-)

Some folks want/need source. This means !UNIX. Minix is alternative
number one at this point.

I am actively looking at Trix, MACH, GNU and other alternatives. The 
thing in common with these are that they are not complete. Either
you get a kernel with no filesystem, or a kernel with AT&T restrictions,
or no kernel with utilities, or utilities with no libraries...

No one seems to have a complete BSD or SysV implementation, with
full source, libraries & utilities, for free. Why is that? :-)


(BTW - daver.uu.net is an ICM-3216 running System V.2.6.1 from
NS. After patching it heavily, it is now able to stay up for
months at a time. It currently handles 250+ Megabytes of mail
and news per week, and is directly connected to about
40 other sites. It is the reason that the 532 project was
started. It is unable to keep up with the three Telebit modems
at 19.2 Kbps running g protocol uucp, and I will be replacing
it with the pc532.)

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

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Fri Dec  8 15:47:19 1989
Flags: 000000000001
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Fri, 8 Dec 89 10:57:10 pst
From: Bruce Culbertson <think!ames!mips!hplabs.hp.com!hplwbc!culberts@EDDIE.MIT.EDU>
To: mips!daver.uu.NET!pc532@EDDIE.MIT.EDU
Subject: 32000 Minix

Hello 32000-hackers,

Since there has been discussion of porting my 32016 Minix port to the
32532 (is that what you call a "report"?), I thought I would post some
information about Minix.

Minix is a reasonably complete re-implementation of Unix Edition 7.  The
objective of its author, professor Andrew S.  Tanenbaum, was to create
an operating system whose sources could be legally distributed to
students.  It is missing a few of the Edition 7 calls: ptrace, prof,
nice and perhaps a couple others.  It can be obtained with sources and
8088 binaries for about $80US.  Updates can be obtained free from
comp.os.minix.  A large number of utilities are provided which mimic
their Unix namesakes.  Recent additions to libc have made the porting of
Unix programs generally quite painless.  A POSIX version is in the
works, due to appear in a year or two.

While Minix mimics Unix at the interface level, its structure has no
resemblance to traditional implementations.  Minix has a very small
message passing micro-kernel which supports three operations: send,
receive, and send-receive.  Messages have fixed size: 32 bytes in my
version.  There is no message queueing.  This means that if process A
wants to send to process B, and B is not blocked waiting for a message,
then A blocks until B does a receive.  While this seems very
restrictive, I have become convinced that it is sufficient for
implementing a full-featured, high performance operating system.

The rest of the operating system is implemented in two layers of
processes above the micro-kernel.  The lower layer consists of device
drivers and other processes providing hardware related services.  The
upper layer consists of the memory management process (MM), which
implements exec, fork, exit, and so forth; and the file system process
(FS), which implements read, write, open, close, etc.  User processes
speak only to MM and FS.

So far, so good.  Minix's biggest problem is that MM and FS have not
been written to provide enough concurrency.  For example, when FS
receives a read or write system call for a block device, it waits to
complete that call before beginning another system call.  Suppose you
are compiling one file while editing another.  The editor, operating in
raw mode, will not even echo characters during the five seconds it takes
to load gcc.  Fortunately, there is nothing about the structure of Minix
which precludes improving this situation.  Think of it as a magnificent
opportunity to hack.  When you use Minix in the typical MS-DOS style,
running one I/O intensive program at a time, you do not notice this
problem.

By the way, why does it take five seconds to load gcc?  Simply because
the I/O has not been tuned.  So far I have not even played with the
interleaving.  Consequently, Minix reads only one block per disk
revolution.  More opportunity for hacking...

I would guess that a one weekend effort would get Minix running on the
pc-532.

Below is a message I posted to comp.os.minix in June about my Minix
port.

Best wishes to all of you who are about to buy yourselves pc-532 boards.
Who knows -- maybe I'll get one, too.

Bruce Culbertson

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

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 think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Fri Dec  8 20:21:09 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
To: mips!daver.uu.NET!pc532@EDDIE.MIT.EDU
Subject: U of T
Date: 8 Dec 89 16:43:12 CST (Fri)
From: think!ames!mips!daver!uunet!starfire!john@EDDIE.MIT.EDU (John Lind)

[In an article entitled "Re: OSes and such" kls@ditka.UUCP (Karl Swartz)
>What about the folks in Canada (U. Toronto?) who did the BSD 4.2 port
>to the ICM?  Any chance they might be enticed to move it over to the
>PC532, perhaps if a few of us were to fund the contribution of a system
>for them to use?  With their ICM investment I'd think they'd have a lot
>of interest in the PC532.

Hey, if you know a way to get ahold of these people, there's a couple of
us that would REALLY like to know about it.  Dave has had complete failure
in getting a response from these people.

The idea may have merit.  I got my serial drivers and my orignal obsoleted
mass storage drivers from Carnegie Mellon on a hardware/software exchange.
The mass storage drivers are not used anymore because I switched controllers,
but it was a great start.

My hardware is very like the ICM (isn't daver an ICM, too?) EXCEPT THAT
I HAVE DRIVER SOURCE.  I also have what I need for the ICU, RTC, and other
software parts that are intimately associated with the hardware (yes,
a binary configurable license has A LITTLE source with it), but they probably
won't be any good for 4.2 or 4.3, though the drivers should be almost
ready (they are relatd to SunOS drivers).  If you can help me get a 4.2 port
either for my current machine or for the pc532, I will be very, very happy
to provide whatever porting support I can from my location.  Actually, my
chances of getting a pc532 are dwindling since no-one seems to be interested
in a Multibus version, but I would still be happy to help with the porting if
I can upgrade my software in the process, with the appropriate exchange of
funds.

In other words, I will be willing to pitch in and help get UofT some pc532s
if I get a port, or whatever reasonable and appropriate exchange of funds
makes it work.
--
		   John Lind, Starfire Consulting Services
E-mail: john@starfire.MN.ORG		USnail: PO Box 13001, Mpls MN  55414

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Sat Dec  9 01:44:35 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
Date: Fri, 8 Dec 89 19:00:22 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: Total System Cost

[In the message entitled "Total System Cost" on Dec  8, 16:00, Miles O'Neal writes:]
> 
> My pc532 archive got hosed (my fault), and I lost some of
> the cost data. I know the main board is `$210. In similar
> volume, would the comm board be the same? And what are the
> prices on the pricey chips?

The estimated PCB cost is $215 USD. The serial/Ethernet board is
a bit more (best we can tell it is due to the cost of the gold
fingers), but that has not been finalized.

On the positive side, I got my second call from National today. This
was from a "high ranking" person at National, and he is quite interested
in the project. There *will* be a deal made, and we will be getting
support from National! This is _very_ good news. To give you an
idea of how good that news is, the estimated cost of the PCB,
and all support components (incl. 4 megabyte RAM) is $600 USD.
Retail (Q1) price of the CPU, FPU and ICU is $995 USD. With the
help of National, we will be able to get a lower price. How
much lower will be determined early next week. More info
as it happens.


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

From think!ames!mips!daver!owner-pc532%EDDIE.MIT.EDU@EDDIE.MIT.EDU@bu-it.BU.EDU Sat Dec  9 01:46:50 1989
Flags: 000000000000
Reply-To: think!ames!mips!daver.UU.NET!pc532@EDDIE.MIT.EDU
To: mips!ames.arc.nasa.gov!gatech!uunet!daver!pc532@EDDIE.MIT.EDU
Subject: Incorporation
Date: 8 Dec 89 16:17:12 EST (Fri)
From: think!ames!mips!ames.arc.nasa.gov!gatech!stiatl!meo@EDDIE.MIT.EDU (Miles O'Neal)

As far as the "distributed corporation" goes, I've incorporated
a company here in Georgia - it's not that hard (after the 1st time -
for that 1 you read a lot and call a lot of people). It cost about $200,
plus a business license in your county (if you are actually "doing
business"). As whoever brought up the idea pointed out, we would
definately want a legal guy and an accountant-type involved.

Most states now have pretty much the same laws regarding corporations,
based on The Model Corporation Act (or something like that). For tax
reasons, it may be best to incorporate in Delaware (if anybody thinks
there's real money to be made here 8^). The only thing here is that
we might have to register as "foreign corporations" in some of the
other states where people actually do work, which costs (in GA) about
$500. But I think (anybody got a lawyer handy?) that as long as the
corporation isn't "doing business" (ie, money changing hands) in those
states, that's not a requirement.

The only other hassle is the paperwork. There's all those tax forms to
file quarterly. Of course, as long as there's no payroll and you aren't
selling anything, those just have lots of empty spaces... Anyway, that
could be a job for either the accountant or someone else willing to do
it for extra stock.

Well, what do you think?

-Miles O'Neal
{yr fave backbone here}!emory!stiatl!meo

From owner-pc532%daver@mips.com@bu-it.BU.EDU Sat Dec  9 10:12:39 1989
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
Subject: X11 Server Alternative.
To: pc532%tarpit@daver.uu.NET
Date: Fri, 8 Dec 89 17:52:53 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]


An X11 Alternative:
-------------------

As mentioned in a previous message, I have been spending sometime thinking
about the implementation of a system console.

Most likely the total cost of implementing a display board based upon
the TMS34020, TMS34010, i80860 or whatever, will be quite expensive.
Not only is there the cost of the display board, but also a monitor,
keyboard, and mouse to be considered.

While I sure would like to have the latest and greatest in sparkling
8 plane color, it occurred to me that there might be a low cost alternative
that would be satisfactory to the majority.  The idea is to simply design
an interface to an existing work-station display which is now somewhat out
of favor and therefore inexpensive in the used market.

As an illustration, consider the following DEC 1024x760 monochrome
graphics subsystem:

        o VCB01, display controller  - has Q-bus interface
        o BC18p, cable set
        o VR260, mono-chrome monitor - 1024x760
        o LK201, keyboard            - connects to controller
        o VS10X, mouse               - connects to controller

This configuration is plentiful and should cost approximately $300 to $400.
Furthermore, and equally important, is that this configuration is supported
in the X11 release.

In summary the idea is to:

        o Select a graphics work-station display configuration which is:
          - plentiful in the used marked
          - has a sufficiently low cost
          - is a X11 supported configuration
          - has sufficent pc532 user support

        o Design a display server which interfaces the above to the
          pc532.


Any thoughts either pro or con ??   Please speak out, any and all
thoughts, ideas, suggestions would be helpful.

What would be the best display configuration to use ??  This is not
an are where I have much knowledge.

Are there other areas where this approach can / should be applied 
(eg. laser printer, scanner, etc) ??


Best regards,
johnc


From owner-pc532%daver@mips.com@bu-it.BU.EDU Sat Dec  9 15:19:53 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
X-Mailer: Mail User's Shell (6.2 5/11/88)
To: pc532@daver
Subject: scsi terminators
Date: 9 Dec 89 10:48:43 PST (Sat)
From: george@wombat.UUCP (George Scolaro)

I have been wondering about expansion boards etc for the pc532, the first
one that comes to mind of course is a board to plug into the PC/AT so we can
access any of it's peripherals (via software in the AT of course). While
considering the combinations of switched on AT, but off PC532 and vice versa
I thought of the SCSI terminator power condition. I have always wondered why
the SCSI bus makes allowance for the SCSI terminators to be powered from the
cable rather than the adapter they are on. This is the reason I came up with,
does any one know the real reason?

If we hook up terminators like this:

		1st board	   |		2nd board

	+5 ------------|>|-.--o-o--.------.--o-o--|<|-------- +5
			   |		  |
			   |		  |
			terminator    terminator
			   |		  |
			   |		  |
Ground	-------------------.--------------.------------------ Ground

	o-o is a jumper
	|>| is a diode

then the terminator would still have active power at both ends, rather than
one end being grounded if it's board was powered off. ie, we can have an AT
always connected to a PC532 and it could be on/off and not affect the PC532's
SCSI bus. It seems like an obvious mode of operation (now that I think of it)
is it the way its meant to be used?

And is this the reason (reported by John Connin) why at most 5 boards can
provide terminator power: if 3 are off will the reverse leakage of the diodes
cause the TERMPWR to drop too low? BTW the diodes are Schottky devices, ie
low forward drop (typ. 0.2V).

I had a look at an emulex (arrgghh!) scsi->disk controller board and it is
not wired this way, it's terminators are powered from the cathode side of
the diode.

any ideas?

Anyhow, ignoring all that. I still think that a scsi board plugged into the
AT will be a simple (just software right?) way to access a whole bunch of
peripherals initially without having to buy more hardware. Dave and I did
this when we designed the software interface between the PC/AT and the
Definicon board. We had all the software running on the 32k board with the
PC/AT performing I/O functions. In fact this method worked well even when
Zaiaz ported Unix to the board. This same technique was also used with the
PD32 (32016 board in uC). We got a reasonable >250 kbytes/sec transfer with
the PC/AT doing out string instructions to the 32k interface. It should be
a simple job to wrap a dp8490 with a pal to do wait states etc onto a PC/AT
prototype board (or just buy a real cheapie host adapter board).

This is my 2c worth regarding expansion boards for the PC532 initially. I
will post the BOM etc for the serial/ethernet expansion board in a while
and see what that stirs up. The reason for mentioning the PC/AT connection
again is that it seems that for most people just buying and building up the
bits for a PC532 will sufficiently stretch the xmas budget for a while and
committing to yet another board (with a 32gx32) will be a bit tight.
Regarding commitments to the PC532, thanks for all the responses, we have
more than 10 boards being requested (with various amounts of urgency), so
depending on the next week or so, I will decide whether to put it into the
PCB shop or wait till after xmas. As soon as I decide I will post a list of
interested people + number of boards that they have requested, so as to
be able to reconfirm yey/nay. The +ve advantage of waiting a bit more is that
dram prices keep dropping....

In addition several people have shown interest in getting pre-programmed
pals/eprom for the PC532. I accept that many people do not have access to
programmers (let alone D-speed pals etc) so I will supply pre-programmed
devices with all PCB's (unless specifically requested not to). B-speed pals
run around $3-$4 and D-speed (2 on the board) are probably $8-$10. The pal
equations are written in CUPL (similar capabilities to ABEL) and I will
also supply JEDEC files (and expanded AND/OR files for those with PALASM
only).

Note also, I have sent several copies of schematics etc out to interested
parties, please get the latest and greatest version from me before you
actually attempt to get a pcb done. I have found a couple of things that have
to be updated (already in the new artwork). e.g. the FPU has a few reserved
pins (A10, B1, B9) that have to be grounded. This wasn't documented in the
old 32381 data sheet I had, grrr! Apparently the 32381 FPU (in a noisy
environment, whatever that is) can get into TEST mode and NS now recommends
that these pins be tied to ground. In addition I have moved some components
around on the PCB. So, the current (not yet shipped to anyone) schematics
and Gerber files should reflect REV 1D.

regards,

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com@bu-it.BU.EDU Sat Dec  9 19:10:17 1989
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
X-Mailer: Mail User's Shell (6.4 2/14/89)
To: pc532@daver.UU.NET
Subject: Re: X11 Server Alternative.
Date: 9 Dec 89 22:02:06 GMT (Sat)
From: ken%mm@gatech.edu (Ken Seefried iii)

On Dec 8,  5:52pm, John L. Connin wrote:
} Subject: X11 Server Alternative.
} 
} As an illustration, consider the following DEC 1024x760 monochrome
} graphics subsystem:
} 
}         o VCB01, display controller  - has Q-bus interface
}         o BC18p, cable set
}         o VR260, mono-chrome monitor - 1024x760
}         o LK201, keyboard            - connects to controller
}         o VS10X, mouse               - connects to controller
} 
} This configuration is plentiful and should cost approximately $300 to $400.
} Furthermore, and equally important, is that this configuration is supported
} in the X11 release.
} 

I *think* this configuration is also known as the VS100, and I
have never seen one as cheap as that, but you may be able to
scrounge better than I...:-)

While at first glance, this seems to be a good idea, there are some
big problems with doing this.  Seems to me that by the time you
build a Q-Bus psuedo-master that talked to the pc532 over SCSI,
and then figured out all the issues relating to driving the thing,
you could have spent the time much more profitably building a
board from scratch.

Certainly, the current X support routines would be useless in such
a configuration.  Also, if I am not mistaken, vs100 support is
going away in future releases of X (or is that VMS...I forget).

One idea that I had, that would probably save a hell of a lot of
work, would be to simply get the X clients going on the pc532
(an easy job), and get a little X terminal, plug it into the ethernet, 
and rock-n-roll.  You can now buy X terminals for anything from around
$1k (Acer Zebra, roughly PC resolutions) up into the stratosphere
(for, say, the Tektronix 24-bit MC88000 based X-Terminal-from-hell).
I'm generally pretty fond of the Visual 640 (800x600 Mono) for
around $2k, though I have heard a few disparaging comments of late.
In any case, your terminal takes care of the display, and the 
pc532 just runs clients.  

Also, if you have a PC or PC/AT laying around with and EGA or VGA
monitor, you can slap in a WD Ethernet card in it for something like
$250 and get the GSS PC-XView software (something like $250, I
think) and get the same effect (believe it or not, it actually
works pretty well).  GSS also supports super-VGA cards at 800x600
resolution and TI 340x0 based DGIS cards (DGIS is a standard for
talking to 340x0-family graphics boards).  There is another
company with a similar product running under MS-Windows that
supports any card with a Windows drivers (like the Wyse-700 and
1,024x1,024 NEC Monograph).  Niether product is a speed deamon,
especially drawing pixmaps (`xchomp', for example, is far to slow
to be playable), but is otherwise an acceptable environment for
most X things.

Basicly, the amount of $$$ you wanted to spend would determine
what resolution you got.  You could choose as big or as small as
you want.

I'll note, again, that this would save a ton of development time
and $$$.  Almost *any* solution that *I* can see to the
video-cum-X problem will cost in the $1k-$2k range once all is
said and done (probably more).  Why not go for the plug-and-play solution
('course, you don't have the fun of building it yourself...:-)
No drivers to write (and debug), no hardware to build (and debug),
and a warrenty...such a deal...:-)


-- 

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

From owner-pc532%daver@mips.com@bu-it.BU.EDU Sat Dec  9 22:18:23 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
X-Mailer: Mail User's Shell (6.2 5/11/88)
To: pc532@daver.UU.NET
Subject: Re: quick ethernet board question
Date: 9 Dec 89 19:00:23 PST (Sat)
From: george@wombat.UUCP (George Scolaro)

[In the message entitled "quick ethernet board question" on Dec  9, 23:30, Ken Seefried iii writes:]
> 
> On the ethernet board that has been designed...
> 
> It was mentioned that there were a hoard of serial ports on it.  I
> assume that there are no problems with not populating these ports,
> as the 8 on the motherboard are more than enough for me.  Is this
> correct?
> 
Yes, the ethernet board has 2 Octarts on (16 channels), plus a piggy-
back board with all the driver/receivers and RJ11 connectors. If you
don't want more serial ports then just leave the bits off (2 Octarts)
and leave off the piggy-back board.

regards,

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com@bu-it.BU.EDU Sat Dec  9 22:18:47 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
X-Mailer: Mail User's Shell (6.2 5/11/88)
To: pc532@daver.UU.NET
Subject: Re: FPU
Date: 9 Dec 89 18:56:51 PST (Sat)
From: george@wombat.UUCP (George Scolaro)

[In the message entitled "FPU" on Dec  9, 23:16, Ken Seefried iii writes:]
> 
> Wasn't there a chip produced that bound the 32532 and one of the
> Weitek chip sets?  Seems like I got some technical data on it a
> year or more ago and it was significantly faster than the 32381.

Yes, its called the NS32580. I have never seen it, nor did I ever
see it while I worked at NS. I assume it must exist (somewhere), but
I doubt if it ever made it to full production. Anyone from NS wish
to comment further? Anyhow it was(is) meant to be really illustrious,
15 mflops (@30mhz) in pipelined mode. The 532 has magic to enable it
to feed the 580 (which interfaces to the Weitek WTL3164) in pipe-lined
mode via a FIFO inside (the CPU). The smart thing is that the pin out
of the 580 is a superset of the 32381, ie its a bigger PGA but the
inside pins enable the 32381 to be plugged in (if the 580/WTL chips
are not needed). I have kept away from this chipset, primarily due
to cost (I'm sure it's astronomical), and availability...
And NO, I am not going to modify the PCB to support it!

Anyone know more?

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com@bu-it.BU.EDU Sun Dec 10 00:34:56 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Sun, 10 Dec 89 00:07:32 EST
From: ken@cs.rochester.edu
To: pc532@daver.uu.NET
Subject: choice of OS

Having been intimidated by all those fascinating hardware details
(haven't played with hardware for years), I venture to post my first
article to the group.

My reaction to this OS discussion is: go with Minix. It is small and
easy to improve. People are porting more and more utilities to Minix
all the time, just watch comp.os.minix.  Andy has declared his
intention to be POSIX compatible and that's the portability ticket
these days.  GNU OS is vapourware, FSF is waiting to see what develops.
Mach is smaller than you think; when all the AT&T code is taken out,
you are left with a small kernel that needs a filesystem and other
things. This from a colleague who came from CMU.  Amoeba is worth
watching, it has been chosen by OSF for further down the line. There is
even Unix emulation in the upcoming release. Amoeba has an elegant and
powerful design and can form the nucleus of a multiprocessor OS when
these boards get cheap enough to stamp out by the dozen.  But Amoeba is
research software and not for end users yet.  I mean no disrespect to
the Ameoba folk, I have worked with them and know they are good. Give
Amoeba time to mature.

I'm biased against anything that doesn't come with source, I'm funny
that way. Lots of other programmers feel this way too.

From owner-pc532%daver@mips.com@bu-it.BU.EDU Sun Dec 10 02:25:20 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
X-Mailer: Mail User's Shell (6.2 5/11/88)
To: pc532@daver.UU.NET
Subject: Re: PC532
Date: 9 Dec 89 22:01:28 PST (Sat)
From: george@wombat.UUCP (George Scolaro)

[In the message entitled "PC532" on Dec  9, 12:37, "Robert D. Greene" writes:]
> 
> Well, I guess I'm going to join the mad mob and dedicate myself for one
> of the next batch of PCB's. From what I can tell, is the following what
> we are looking at for a complete (operational) 4M system:
> 
>      PCB (215) + Components/RAM (400) + CPU/FPU (995) = $1600-1700 approx.?
> 
Yep, plus disk, powersupply, case etc... Less if NS comes through
with a good deal on the chip set. Dave is working on that and
this week will hopefully see some facts coming to light.

regards, (P.S your request copy of info is going out monday, sorry
for the delay).

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com@bu-it.BU.EDU Sun Dec 10 09:29:43 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: Jukka Virtanen <jtv@kampi.hut.fi>
To: pc532@daver
Subject: Re: FPU performance
Date: 	Sun, 10 Dec 89 15:04:30 EET


>>   FPU's Early Done signal. This can be done by moving integer instructions
>>   between the FP instructions (interleaving?). The FPU likes to have

	GNU CC will support instruction scheduling in version 2.
	(Next release will be 1.37, any time now. After that
	there will be two versions of GCC. The research version is
	called 2.xx, and the 1.xx is for production use)

	Michael Tiemann did some work on instruction scheduling
	with version 1.3? (oops, maybe it was 1.35, sorry I forgot),
	read his paper. It's a good view to GCC.

	The paper is available from sauna.hut.fi, anonymous
	ftp, file pub/gnu/gcc/dbr.texinfo if you don't find
	it in your own continent...

	(yes, you need TeX to print it. On request I can make
	 an Emacs info file available to kampi.hut.fi)

					Juki
					jtv@hut.fi

From owner-pc532%daver@mips.com@bu-it.BU.EDU Sun Dec 10 12:40:26 1989
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
Date: Mon, 11 Dec 89 00:51:52 GMT
From: athos@otto.bf.rmit.oz.au (David Burren [Athos])
To: pc532@daver.UU.NET
Subject: I/O cards

Sitting around a bonfire last night with a group of other locals interested in
the pc532, one of the things that turned up was an idea for a PostScript board.
I'll bounce the idea off the mailing-list and see what people think:

The board sits on SCSI, and as such could (with a different connector) be used
in a variety of systems besides the pc532.  It would contain a CPU, memory, and
a parallel port.  PostScript sent to the board would be interpreted, with the
resulting bitmap being either sent to the parallel port or returned to the
host.  One _could_ licence a PostScript interpreter from Adobe, but we have
enough experience with NeWS, PD PostScript interpreters, as well as Adobe
products to feel that an Adobe-free interpreter is feasible.

Of course, the board's CPU must have enough grunt to make it worthwhile, or
we may as well just run the interpreter on the host.  We're toying with the
idea of a 32CG16 or a 32GX32 for a prototype.  Using a 32k processor simplifies
the software development somewhat in a pc532 environment.

The parallel port would probably have some form of FIFO support, using a WD
FIFO or somesuch (have to check the datasheets on this).

PostScript supports the concept of files, and some high-end PostScript printers
these days have a SCSI Port for a local disk.  We'd provide file operations
through the host.  A message-passing system such as Minix with a seperate FS
makes this particularly nice.

The board's software would be downloaded from the host (except the boot ROM :-)
Part of the software is the reconfigurable driver for the printer port, with
modules for Epson dot-matrixes, LaserJets, you name it.

On today's PostScript printers, adding more memory both means the interpreter
can run faster, and it can handle more complex ps programs.  The board would
have 1 Mb or so of local RAM.  Depending on what restrictions are imposed by
our choice of processor, we'd like to implement virtual memory, again using
the host filesystem.  Handling large PostScript programs will cause a
performance droop, but at least it won't come back after 10 minutes with a
"Out of Stack" message....

We'd be unlikely to achieve the performance of the latest RISC PostScript
controllers, but it won't be hard to leave the 68k-based controllers behind
in the speed stakes.

While the hardware could be connected to any SCSI bus, the functions of virtual
memory and filing are intertwined with the host and it's OS.  We _could_ add
a local SCSI bus and implement a filesystem for it, but that both complicates
the hardware (and bumps up the cost) and adds to the complexity of the software
(also leaves less memory for large PostScript files).

While we proceed to flesh out the design, is there anyone out there interested?
Any areas where what I've outlined would fall down?  Thanks.



From: daver!sun!ames.arc.nasa.gov!gatech!mm!ken@murtoa.cs.mu.oz (Ken Seefried iii)
> 
> Would there be any interest in a Motorola 96001-based DSP board
> for the pc532?  Several of us around here have been designing such
> a device to connect to the Sun 3 and SGI Personal Iris SCSI bus.
> It would not take a huge amount of modification to fit it on a PC
> sized card.  The card is a way from being done, promarily because
> it is a back-burner project, but could concievably be speeded up.
> 
> Voice mail, anyone?

Sounds great.  As with everything, how popular it will be depends somewhat on
the end price :-(
By the way, can someone refresh my memory on the 96001?  I recall bits about
the 56001, but not the 96001 (ie. was that a typo or is my ignorance showing
through?).


The idea of using IBM's as I/O hosts, while not particularly big on
performance, has great "hacker appeal".  Dropping a SCSI card into my
'286 Xenix system has interesting possibilities.

I'd dearly love a TMS34020 or i860 graphics board with 24-bit colour, and I
hope to be able to afford such a beastie, but if in the meantime I can press
my existing hardware into service, then great!


Dave and George,
	We're atttempting to organise ourselves a bit here, work out how many
locals will order boards, and do it all in one batch.  I'll be interested to
hear the details of the cheap chip deal from NS: we may want to get them from
you with the boards, as I suspect the local NS distributors may be a little
hard to convince that they should give us discounts...

Keep up the good work!
_______________________________________________________________________________
David Burren (Athos),			       ACSnet: athos@otto.rmit.oz
Survey Computing Consultants, Hawthorn, Vic.   

From owner-pc532%daver@mips.com@bu-it.BU.EDU Sun Dec 10 14:34:49 1989
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
Subject: All about SCSI and more..
To: pc532%tarpit@daver.uu.NET
Date: Sun, 10 Dec 89 11:14:37 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]


In mid-November, John Lohmeyer of NCR Wichita (J.Lohmeyer@Wichita.NCR.COM)
mentioned in comp.periphs that the SCSI-1 and draft SCSI-2 standards
were available in electronic form on the "SCSI BBS" (1-316-636-8700).
Anyway, using George's phrase, I got bored and decided to take a peek.

Below is a listing of the files contained in each file area of the BBS.
I suspect there may be other goodies in file areas accessible once you 
become a 'registered' user.

Enjoy,
johnc


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

        SCSI BBS directory listing, 10dec89
        (316) 636-8700, 300/1200/2400

        Includes all file areas listed below execpt area 16.
        There may be other file areas available to registered users.

         johnc
        ------------------------------------------------------



File Areas -------------------------

  1 ... X3T9.2 General Information
  2 ... Communications Software
  3 ... X3T9.2 Documents from 1988
  4 ... NBS SCSI Verification Tests
  5 ... X3T9.2 Recent Documents (Current Year)
  6 ... Miscellaneous Files
  7 ... SCSI-1 Revision 17B Text Files
  8 ... SCSI-2 Draft Standard Text Files
 11 ... SCSI-2 AutoCAD Figures
 13 ... SCSI-2 Common Access Method File Area
 14 ... IPI files
 15 ... X3T9.2 Documents from 1987 and Prior Years
 16 ... ESDI Document and Related Files
 17 ... Fiber Channel File Area



File area: 1

File area #  1 ... X3T9.2 General Information

--- X3T9.2 Committee Information:
X3T9_2.TXT      5021 07-03-89* Introduction to X3T9.2 
HOW2GET.TXT     1494 11-01-89* How to obtain SCSI Standards 
MEM_FORM.ZIP    1791 02-01-89* Membership application form (ZIP'd WordStar)
MEM_FORM.TXT    3973 07-03-89* Membership application form (Plain ASCII)
SCHEDULE.TXT    2432 11-30-89* X3T9.2 Meeting Schedule
SCSI2NWS.TXT    4864 07-31-89* What SCSI-2 is about--how it differs from SCSI
SCSI2NWS.ZIP    2668 12-20-88* Same as above ZIP'd in WordStar format
NAME_CON.TXT    2011 06-28-89* File Name conventions on the SCSI BBS
VENDORID.TXT    4991 11-20-89* The current SCSI-2 Vendor ID List
NOV_MAIL.TXT    5227 11-06-89* Cover Page from the November Mailing
89-141R0.TXT    2550 12-06-89* January 1990 Working Group Announcement
DEC_AGND.TXT    1876 12-01-89* December Plenary Draft Agenda
S2PR.TXT        1101 12-01-89* Where to send SCSI-2 Public Review Comments

--- Information about X3T9 and its task groups (Prepared by William E. Burr,
    National Institute of Standards and Technology)

T9SUMINT.TXT    1536 03-29-88* Introduction
T9SUMORG.TXT    1536 03-29-88* Standards Organizations
T9SUMQ&A.TXT   13440 03-29-88* X3T9 Questions and Answers
T9SUMPRO.TXT    5888 03-29-88* Hints on getting proposals accepted
T9SUMTRM.TXT   14853 03-25-88* Interface jargon
T9SUMACR.TXT    4864 03-29-88* X3 and ANSI Jargon and Acronyms
T9SUMADR.TXT    4224 03-28-88* Useful Addresses and phone numbers
T9SUM.ZIP      24721 03-29-88* The above 7 files ZIP'd for downloading

--- Minutes of X3T9.2 Plenary Meetings:
    (See File Area 5 for 1989 meetings and areas 3 or 15 for prior years)
87-029R1.TXT   16896 12-12-88* X3T9.2 &.3 Minutes - Feb 87
87-071R0.TXT  107648 05-21-87* X3T9.2 &.3 Minutes - Apr 87    (See file
87-090R0.TXT  118400 07-01-87* X3T9.2 &.3 Minutes - Jun 87     area 3, 5,
87-135R1.TXT  128640 10-20-87* X3T9.2 Minutes - Aug 87         or 15 for
87-171R0.TXT  145792 10-20-87* X3T9.2 Minutes - Oct 87         compressed 
87-200R2.TXT  133376 01-18-88* X3T9.2 Minutes - Dec 87         versions
88-020R1.TXT  116864 05-05-88* X3T9.2 Minutes - Feb 88         of these
88-040R1.TXT  120704 07-05-88* X3T9.2 Minutes - Apr 88         files.)
88-066R0.TXT  142464 07-05-88* X3T9.2 Minutes - Jun 88
88-096R0.TXT  143616 08-22-88* X3T9.2 Minutes - Jul 88
88-130R2.TXT  147712 12-13-88* X3T9.2 Minutes - Oct 88
88-164R0.TXT  148480 12-13-88* X3T9.2 Minutes - Dec 88
89-028R1.TXT  146176 05-02-89* X3T9.2 Minutes - Feb 89
89-049R0.TXT  142336 05-01-89* X3T9.2 Minutes - Apr 89
89-075R0.TXT  154368 06-23-89* X3T9.2 Minutes - Jun 89
89-111R0.TXT  162688 08-26-89* X3T9.2 Minutes - Aug 89
89-126R0.TXT  159232 10-19-89* X3T9.2 Minutes - Oct 89
89-149R0.TXT  151296 12-08-89* X3T9.2 Minutes - Dec 89

--- Minutes of X3T9.2 Working Group Meetings:
    (See File Area 5 for 1989 meetings and areas 3 or 15 for prior years)
87-080R0.TXT   16640 08-31-88* May 87 SCSI Working Group Minutes
87-107R0.TXT   18176 07-17-87* Jul 87 SCSI Working Group Minutes  (See file
87-153R1.TXT   24576 09-07-87* Aug 87 SCSI Working Group Minutes   area 3, 5,
87-185R0.TXT   21504 11-01-87* Oct 87 SCSI Working Group Minutes   or 15 for
88-011R0.TXT   13952 01-18-88* Jan 88 SCSI Working Group Minutes   compressed
88-031R0.TXT   18176 03-14-88* Mar 88 SCSI Working Group Minutes   versions
88-050R0.TXT   19200 05-13-88* May 88 SCSI Working Group Minutes   of these
88-072R0.TXT   25984 07-14-88* Jul 88 SCSI Working Group Minutes   files.)
88-109R2.TXT   21504 09-08-88* Aug 88 SCSI Working Group Minutes
88-153R0.TXT   19712 11-11-88* Nov 88 SCSI Working Group Minutes
89-019R1.TXT   14592 01-16-89* Jan 89 SCSI Working Group Minutes
89-042R0.TXT    9141 03-13-89* Mar 89 SCSI Working Group Minutes
89-066R1.TXT   24192 05-11-89* May 89 SCSI Working Group Minutes
89-090R0.TXT   19456 07-12-89* Jul 89 SCSI Working Group Minutes
89-120R0.TXT   18816 09-09-89* Sep 89 SCSI Working Group Minutes
89-138R0.TXT   19712 11-02-89* Oct 89 SCSI Working Group Minutes

--- Other 1989 Minutes:
    (See File Areas 3 or 15 for prior years)

--- Document Register:
    (Lists X3T9.2 documents - some are in File Area #5)
DR1989.TXT     16695 11-06-89* X3T9.2 1989 Document Register 
DR1989.ZIP      4986 11-06-89* X3T9.2 1989 Document Register 

--- Membership List:
MEMBERS.TXT    50381 11-06-89* X3T9.2 Current Membership List
MEMBERS.ZIP    17636 11-06-89* Same as above, ZIP'd for downloading

--- X3T9 Project Summary:
PROJ_WKS.ZIP    4908 12-08-89* VP-Planner (1-2-3?) Spreadsheet 
PROJ132.TXT     4864 12-08-89* 132-column Summary of X3T9 Projects 
PROJ80.TXT      4096 12-08-89* 80-column Summary of X3T9 Projects 
T9DOCREG.TXT   18048 12-01-87* X3T9 1987 Document Register



File area: 2

File area #  2 ... Communications Software

--- Communications Files --- 

 Compression Programs

PKZ101.EXE    131517 07-21-89* ZIP file utility. Fastest, best compression.
                               Used on this board!
ARC51.COM      58880 03-22-86* Archive utility program  (old and slow)
PKX35A35.EXE   71680 05-18-87* Fast archive program  (fast, but infringes ARC)
ZIPQUIK5.ZIP   17408 02-19-89* For converting ARCs to ZIPs
ZIPDS10.ZIP     9216 02-18-89* Restore internal file Date & Time to Zip files

--- Procomm - a great PC communications package

PROCM242.ZIP  102267 10-17-86* Procomm version 2.4.2  (the program)
PRUTL242.ZIP   24729 10-07-86* Procomm Utilities      (optional)
PROCMD.ZIP     72036 01-26-87* Procomm Command Editor (optional)
READDOC.ME       835 10-07-86* Information about next two files (optional)
PRCMDOC.ZIP   109865 01-00-80* Documentation - formatted for printer (optional)
PRCMDOCP.ZIP   99792 02-17-87* Same as above - unformatted (optional)
PROPLUS.ZIP   172449 02-11-88* New version of Procomm called Procomm Plus

--- Standalone ZMODEM protocol -- you can use it by itself or
    with Procomm (via Alt-F4)

DSZ0208.ZIP    53332 02-08-88* DSZ from Omen Technology
HELP4DSZ.ZIP    1082 08-18-88* Batch files to use ZMODEM from Procomm

--- The following file describes how to use Opus Bulletin Boards

OPUSER.ZIP     34361 12-19-86* Opus Users Manual (This BBS runs Opus)
 
--- Files to help MAC users: Contact John Farnsworth (on this
    BBS if you have any questions or comments.
 
MACRDME.TXT     1920 09-03-87* MacReadMe  Information to use Mac instead of PC 
DOWNLOAD.TXT   12672 07-30-87* Everything you wanted to know about downloading 
BINHEX50.BAS   15744 07-30-87* BASIC prog to gen BinHex5.0 MacBinary converter 
PACKIT.APP     29824 07-30-87* PackIt III v1.2 - required for .PIT files 
MACARC.APP     36992 07-30-87* MacArc v0.03 - for .ARC files 
DESKZAP.APP    16384 07-30-87* DeskZap v1.3 Desk acc to strip Word Star files 
DESKZAP.HLP    28928 07-30-87* DeskZap MacWrite help file 
UNZIP101.SIT   98432 10-12-89* Mac unZIPper application - PKZIP 1.01 compatible


File area: 3

File area #  3 ... X3T9.2 Documents from 1988

--- X3T9.2 Documents from 1988 ---
    Numbers in the form of xx-yyyRz.eee are X3T9.2 Document Numbers
    (See DOCREG.TXT in area 1), where "xx" is the year and "yyy" is the 
    document number for that year. "z" is the revision number.
    File Name Extensions "eee" are defined as follows:
    .WS  WordStar file
    .TXT Plain ASCII
    .PRN Print file
    .ZIP Compressed File(s) (usually contains a lengthy .WS file)

-                    File area 3 X3T9.2 Documents from 1988
-       This file last updated on Sunday December 10, 1989 at 4:01 AM
FILES.BBS       9311 12-10-89* This file as of Sunday December 10, 1989
1988DR.TXT     18719 01-30-89* X3T9.2 1988 Document Register
1988DR.ZIP      7200 01-30-89* X3T9.2 1988 Document Register (ZIP'd)
88-006R0.TXT   23552 03-14-88* 1st draft LOG SELECT/SENSE
88-006R1.TXT   24448 05-19-88* First revision of LOG SENSE/SELECT
88-006R2.TXT   34688 07-11-88* LOG SELECT/SENSE, REV2
88-009R1.WS     3584 03-07-88* Target message response clarification
88-011R0.TXT   13952 01-18-88* Jan 88 SCSI-2 WG Minutes (Plain ASCII)
88-011R0.ZIP    7547 01-18-88* Jan 88 SCSI-2 WG Minutes (ZIP'd WordStar)
88-012R0.TXT    3072 01-20-88* FORMAT UNIT with no verify clarification
88-015R0.TXT    2560 01-29-88* PF Bit Requirement
88-015R0.WS     2688 01-29-88* PF Bit Requirement
88-016R0.TXT    2560 01-29-88* Autosense Protocol
88-016R0.WS     2688 01-29-88* Autosense Protocol
88-017R1.TXT   93440 02-08-88* X3T9.2 1987 Annual Report
88-017R1.ZIP   36431 02-08-88* X3T9.2 1987 Annual Report (ZIP'd WordStar file)
88-018R0.TXT    1664 02-03-88* Follow-up report on miniature shielded connector
88-020R1.BRF   36736 05-05-88* X3T9.2 Minutes - Feb 88 (Minus encl - ASCII)
88-020R1.TXT  116864 05-05-88* X3T9.2 Minutes - Feb 88 (plain ASCII)
88-020R1.ZAP   17467 06-14-89* X3T9.2 Minutes - Feb 88 (Minus encl - WS file)
88-020R1.ZIP   45769 04-27-88* X3T9.2 Minutes - Feb 88 (ZIP'd WS file)
88-025R0.TXT    8113 02-29-88* Rotational Position Locking Proposal
88-025R0.WS     8192 02-29-88* Rotational Position Locking Proposal
88-025R1.WS     8832 03-09-88* Rotational Position Locking Proposal
88-026R0.TXT    1861 02-29-88* Add new unit attention conditions
88-026R0.WS     2048 02-29-88* Add new unit attention conditions
88-027R0.TXT    5624 02-29-88* Fixing MODE SELECT square bracket notes
88-027R0.WS     5760 02-29-88* Fixing MODE SELECT square bracket notes
88-028R0.TXT     908 03-02-88* Comments on Gerry Houlder's proposals
88-029R0.WS     3200 03-07-88* REQUEST SENSE clarification
88-030R0.TXT    9344 03-07-88* Proposed definition of Caching
88-030R1.TXT   10112 05-16-88* Caching Definition
88-031R0.TXT   18176 03-14-88* Mar 88 SCSI-2 WG Minutes (Plain ASCII)
88-031R0.ZIP    9690 03-14-88* Mar 88 SCSI-2 WG Minutes (ZIP'd WordStar)
88-032R1.TXT    9344 05-16-88* Memo on Additional Sense Codes
88-032R1.WKS   19540 05-16-88* VP-planner spreadsheet (1-2-3 compat.) on ASCs
88-032R1.ZIP    4732 05-16-88* Memo on Additional Sense Codes
88-038R0.TXT    4108 04-26-88* Rev 4 Issues - Sections 7 and 8
88-039R0.WS     9088 04-18-88* Proposed Clarification to ESDI
88-040R1.BRF   35584 07-05-88* X3T9.2 Minutes - Apr 88 (Minus encl - ASCII)
88-040R1.TXT  120704 07-05-88* X3T9.2 Minutes - Apr 88 (plain ASCII)
88-040R1.ZAP   17268 06-14-89* X3T9.2 Minutes - Apr 88 (Minus encl - WS file)
88-040R1.ZIP   47668 07-05-88* X3T9.2 Minutes - Apr 88 (ZIP'd WS file)
88-042R0.WS     6400 05-09-88* Sequential Access Device Init. Procedure
88-043R0.WS     3712 05-10-88* MODE SELECT Clarification
88-044R0.TXT    3968 04-25-88* WORM MODE SELECT Page Archive Bit
88-044R0.ZIP    2271 04-24-88* WORM MODE SELECT Page Archive Bit
88-047R0.TXT    4736 05-03-88* FORMAT TRACK COMMAND FOR FLOPPY DISK
88-048R1.TXT   15104 05-17-88* Proposed pinouts for SCSI-2 connectors
88-049R0.TXT   12110 04-26-88* Proposed Read Caching Page
88-049R2.TXT   16128 05-16-88* Proposed read caching page
88-050R0.TXT   19200 05-13-88* May 88 SCSI-2 WG Minutes (Plain ASCII)
88-050R0.ZIP   10554 05-13-88* May 88 SCSI-2 WG Minutes (ZIP'd WordStar)
88-054R1.TXT    2304 07-08-88* San Jose August WG meeting Notice
88-055R0.TXT    1920 05-20-88* Advisory vs Mandatory bit in read cache page
88-056R0.TXT    2607 05-12-88* July SCSI Working Group meeting info
88-057R0.TXT    8064 05-17-88* Mode Select/Sense
88-059R1.TXT    2393 05-26-88* Yet another clarification to SDTR
88-060R0.WS     2944 05-13-88* Active Termination for Differential B Cable
88-061R0.TXT   17408 05-16-88* Registration Authority for SCSI-2 and ESDI
88-061R0.ZIP    8814 05-16-88* Registration Authority for SCSI-2 and ESDI
88-064R0.WS     4352 10-19-88* processor device model proposal
88-064R1.MAC    7424 10-21-88* Processor Device Type Model
88-064R1.TXT    7778 10-24-88* Processor Device Type Model
88-064R1.WS     7808 10-24-88* Processor Device Type Model
88-065R3.TXT   12672 10-19-88* Asynchronous Event Notification Revision
88-065R3.ZIP    6050 10-09-88* Asynchronous Event Notification Revision
88-066R0.BRF   41984 07-05-88* X3T9.2 Minutes - Jun 88 (Minus encl - ASCII)
88-066R0.TXT  142464 07-05-88* X3T9.2 Minutes - Jun 88 (plain ASCII)
88-066R0.ZAP   38734 06-14-89* X3T9.2 Minutes - Jun 88 (Minus encl - WS file)
88-066R0.ZIP   55857 07-05-88* X3T9.2 Minutes - Jun 88 (ZIP'd WS file)
88-069R0.TXT   15488 07-19-88* IBM 60 pin Proposal
88-071R0.TXT    4736 06-30-88* Dal's letter on automatic address re-assignment
88-071R0.WS     4864 06-30-88* Dal's letter on automatic address re-assignment
88-072R0.TXT   25984 07-14-88* Jul 88 SCSI-2 WG Minutes (Plain ASCII)
88-072R0.ZIP   13922 07-14-88* Jul 88 SCSI-2 WG Minutes (ZIP'd WordStar)
88-077R0.TXT    3968 07-07-88* Proposed Mod. to X3T9.2/88-048 R1 (Pinouts)
88-081R0.TXT    3712 07-14-88* Bill Spence's 1st draft of LOG pages
88-081R1.TXT   25070 07-25-88* LOG SELECT/SENSE PAGES
88-081R1.WS    25728 07-26-88* LOG SELECT/SENSE PAGES (converted to WS by JBL)
88-087R0.TXT    5248 07-18-88* Proposed TERMPWR requirements for SCSI-2
88-088R0.TXT    4352 07-19-88* SCSI ID proposal
88-091R0.TXT    8807 08-08-88* Proposal to make Wide Negotiation same as Sync
88-091R0.ZIP    4720 08-08-88* Proposal to make Wide Negotiation same as Sync
88-093R0.TXT    3152 08-10-88* SCSI-2 Proposal for Non-data Errors
88-095R1.TXT   50432 09-30-88* LOG SELECT/SENSE for large logs
88-095R1.ZIP    9380 09-30-88* LOG SELECT/SENSE for large logs
88-096R0.BRF   41088 08-22-88* X3T9.2 Minutes - Jul 88 (Minus encl - ASCII)
88-096R0.TXT  143616 08-22-88* X3T9.2 Minutes - Jul 88 (plain ASCII)
88-096R0.ZAP   20892 06-14-89* X3T9.2 Minutes - Jul 88 (Minus encl - WS file)
88-096R0.ZIP   57170 08-22-88* X3T9.2 Minutes - Jul 88 (ZIP'd WS file)
88-099R0.TXT    7040 08-22-88* Minutes of Auto-Config SSWG August 15, 1988
88-099R0.ZIP    4185 08-22-88* Minutes of Auto-Config SSWG August 15, 1988
88-100R0.TXT    6538 08-22-88* McGrath's Auto-Configuration Proposal)
88-103R0.ZIP    5481 09-02-88* GENERIC READ-WRITE ERROR RECOVERY MODE PARAMES
88-103R1.ZIP    6614 09-01-88* Generic Error Recovery Mode Page
88-107R1.ZIP   40506 10-07-88* Hierarchical Filemarks (Setmarks)
88-108R2.MAC    3456 10-21-88* REQ/ACK Timing relationship with REQB/ACKB
88-108R2.TXT    3712 10-24-88* REQ/ACK Timing relationship with REQB/ACKB
88-108R2.WS     3584 10-24-88* REQ/ACK Timing relationship with REQB/ACKB
88-109R2.TXT   21504 09-08-88* Aug 88 SCSI-2 WG Minutes (Plain ASCII)
88-109R2.ZIP   11722 09-08-88* Aug 88 SCSI-2 WG Minutes (ZIP'd WordStar)
88-112R0.TXT    3840 09-06-88* Aug Fiber Optic Study Group Highlights
88-113R0.TXT    7680 09-08-88* Ciprico and NCR comments on ESDI
88-113R0.ZIP    3871 09-08-88* Ciprico and NCR comments on ESDI
88-114R0.TXT   21504 09-08-88* Ciprico comments on SCSI-2 Rev 5
88-115R0.TXT    2267 10-10-88* SCSI-2 Implications for SCSI-3 Reconfiguration
88-115R0.ZIP    1366 10-10-88* SCSI-2 Implications for SCSI-3 Reconfiguration
88-116R0.TXT    2967 09-27-88* WDTR Disable Residue Function
88-116R0.ZIP    1766 09-28-88* WDTR Disable Residue Function
88-117R0.TXT    2555 09-27-88* Comment on Connector Proposals
88-117R0.ZIP    1768 09-28-88* Comment on Connector Proposals
88-118R0.TXT    3229 09-27-88* Response to 88-177
88-118R0.ZIP    2123 09-27-88* Response to 88-177
88-119R0.TXT    5760 09-29-88* NCR public review comment on ESDI
88-119R0.ZIP    3503 09-29-88* NCR public review comment on ESDI
88-121R0.TXT    3840 10-19-88* Disconnect control via Mode Select
88-121R0.ZIP    2179 10-19-88* Disconnect control via Mode Select
88-126R0.TXT   10982 10-19-88* Tom Wicklund's comments on SCSI-2 Rev 5
88-129R0.TXT   44160 10-19-88* Fiber Optic Study Group minutes (Aug & Sep '88)
88-130R2.BRF   41088 12-13-88* X3T9.2 Minutes - Oct 88 (Minus encl - ASCII)
88-130R2.TXT  147712 12-13-88* X3T9.2 Minutes - Oct 88 (plain ASCII)
88-130R2.ZAP   20274 06-14-89* X3T9.2 Minutes - Oct 88 (Minus encl - WS file)
88-130R2.ZIP   59083 12-13-88* X3T9.2 Minutes - Oct 88 (ZIP'd WS file)
88-131R0.TXT    4352 10-19-88* Minutes of ad hoc to resolve ESDI comments
88-131R0.ZIP    2732 10-11-88* Minutes of ad hoc to resolve ESDI comments
88-132R1.TXT    2048 10-14-88* Parameter Pointer for LOG SENSE command
88-135R0.TXT   14009 10-19-88* Tom Wicklund's comments on SCSI-2 command codes
88-138R0.TXT   13056 10-24-88* SCSI-2 Revision 5, Section 9 Comments
88-138R0.ZIP    6512 10-24-88* SCSI-2 Revision 5, Section 9 Comments
88-139R0.TXT   28032 10-24-88* Bill Burr's Direct-Access Device Model
88-139R0.WS    28032 10-24-88* Bill Burr's Direct-Access Device Model
88-140R0.TXT    7680 10-25-88* Communications Device Model
88-140R0.WS     7808 10-25-88* Communications Device Model
88-143R0.TXT    5376 11-04-88* HP's comments, questions on SCSI-2 rev. 5
88-144R0.TXT    5676 11-03-88* Single-ended Termination Alternatives
88-144R0.ZIP    3340 11-06-88* Single-ended Termination Alternatives
88-144R1.BAS    5376 12-04-88* Basic program to calc terminator parameters
88-144R1.TXT   10496 12-13-88* Single-Ended Terminator Alternatives
88-144R1.WS    10880 12-05-88* Single-Ended Terminator Alternatives
88-150R0.TXT    8448 11-07-88* SCSI Single-ended Physical Layer Testing
88-150R0.ZIP    4186 11-10-88* SCSI Single-ended Physical Layer Testing
88-152R0.TXT    1920 11-11-88* Proposed revision to SDP message
88-152R0.ZIP    1525 11-08-88* Proposed revision to SDP message
88-153R0.TXT   19712 11-11-88* Nov 88 SCSI-2 WG Minutes (Plain ASCII)
88-153R0.ZIP   10880 11-10-88* Nov 88 SCSI-2 WG Minutes (ZIP'd WordStar)
88-155R0.TXT    1446 11-29-88* January Working Group meeting notice
88-155R0.WS     1536 11-29-88* January Working Group meeting notice
88-156R0.TXT    7168 12-02-88* Detect B Cable Proposal (Wide SCSI)
88-156R0.WS     7552 12-02-88* Detect B Cable Proposal (Wide SCSI)
88-158R0.TXT    2560 12-13-88* Terminate Immediate Sequence
88-158R0.WS     2560 12-05-88* Terminate Immediate Sequence
88-158R1.TXT   41856 01-31-89* Terminate I/O Process Proposal
88-158R1.ZIP   17910 01-31-89* Terminate I/O Process Proposal
88-160R0.TXT   20096 12-12-88* Fiber Channel Description
88-160R0.WS    22144 12-12-88* Fiber Channel Description
88-161R0.TXT    2176 12-13-88* Single Ended Terminator Requirements
88-161R0.WS     2176 12-07-88* Single Ended Terminator Requirements
88-164R0.BRF   36736 12-13-88* X3T9.2 Minutes - Dec 88 (Minus encl - ASCII)
88-164R0.TXT  148480 12-13-88* X3T9.2 Minutes - Dec 88 (plain ASCII)
88-164R0.ZAP   18492 06-14-89* X3T9.2 Minutes - Dec 88 (Minus encl - WS file)
88-164R0.ZIP   58699 12-13-88* X3T9.2 Minutes - Dec 88 (ZIP'd WS file)
88-165R1.TXT    3808 01-17-89* Input Current and Resistor Tolerances
88-167R0.TXT   10752 12-21-88* Steve Cornaby's comments on RPL
88-168R0.TXT    2314 12-22-88* AEN Initialization Procedure
FOSGMINA.ZIP   10036 06-17-88* 6/2&3 FO Group Minutes (ASCII version)
FOSGMINE.ZIP   10241 06-17-88* 6/2&3 FO Group Minutes (with line draw chs)
SC13MIN3.TXT   34816 10-06-88* ISO/IEC JTC1/SC13 minutes of Tokyo meeting
SC13MIN3.ZIP   17313 10-06-88* ISO/IEC JTC1/SC13 minutes of Tokyo meeting
SMTAUG88.TXT   19456 09-18-88* FDDI Station Management WG Minutes Aug 88
T9AUG88.TXT    22528 09-18-88* X3T9 Minutes of Aug 88 Meeting
T9FEB88.TXT    23661 03-25-88* X3T9 Minutes of Feb 88 Meeting
- Total of 172 files in file area number 3


File area: 4
File area #  4 ... NBS SCSI Verification Tests

--- SCSI Verification files --- 

--- Note: These files were developed by the National Bureau of Standards
          to assist in testing SCSI devices for conformance to the SCSI
          standard.  They are preliminary and require the Adaptec SCSI
          Development System to operate.

SPECIFY.TXT     5222 12-02-87* Read this file (You can type it online)
NBS_C.ZIP      43757 05-13-87* 'C' Source files
NBS_EXE.ZIP   116154 06-03-86* Executable files
NBS_TP.ZIP     45105 06-03-87* Test Procedure and Misc files

--- Note: The following files were developed by the National Institute
          of Standards and Technology (was the National Bureau of Standards)
          for test SCSI devices using a Micro Design International Host
          Adapter on a PC-compatible machine.  I believe the host adapter
          uses a 5380 SCSI protocol chip and thus this code could be fairly
          easily ported to other host adapters employing a 5380.

ABSTRACT.DOC    1111 02-15-89* Abstract of the project
SCSITEST.ZIP   16673 02-15-89* The files including the Abstract



File area #  5 ... X3T9.2 Recent Documents (Current Year)

--- Recent X3T9.2 Documents ---
    Numbers in the form of xx-yyyRz.eee are X3T9.2 Document Numbers
    (See DOCREG.TXT in area 1), where "xx" is the year and "yyy" is the 
    document number for that year. "z" is the revision number.
    File Name Extensions "eee" are defined as follows:
    .WS  WordStar file
    .TXT Plain ASCII
    .PRN Print file
    .ZIP Compressed File(s) (usually contains a lengthy .WS file)

-              File area 5 X3T9.2 Recent Documents (Current Year)
-       This file last updated on Sunday December 10, 1989 at 4:01 AM
------------------------------------------------------------------------------
- Files newer than 30 days:
- 89-149R0.BRF  32000 Dec 89 X3T9.2 Minutes (ASCII w/o enclosures)
- 89-149R0.TXT 151296 Dec 89 X3T9.2 Minutes (plain ASCII)
- 89-149R0.ZAP  12723 Dec 89 X3T9.2 Minutes (ZIP'd WS w/o encl.)
- 89-149R0.ZIP  44420 Dec 89 X3T9.2 Minutes (ZIP'd WordStar file)
- 89-094R5.TXT  77568 Single-cable 16-bit proposal
- 89-094R5.ZIP  13849 Single-cable 16-bit proposal
- 89-150R0.TXT  15748 16-bit single-cable Appendix Form
- 89-150R0.ZIP   3062 16-bit single-cable Appendix Form
- 89-145R0.TXT   1591 Proposed Additional Sense Code Qualifiers
- Total of 9 new files
------------------------------------------------------------------------------
FILES.BBS       7300 12-10-89* This file as of Sunday December 10, 1989
89-001R0.TXT  101888 01-30-89* X3T9.2 Annual Report
89-001R0.ZIP   39063 01-30-89* X3T9.2 Annual Report
89-008R1.TXT    2688 01-13-89* "Brief" Description of Density Code Operation
89-008R1.WS     2816 01-10-89* "Brief" Description of Density Code Operation
89-009R0.TXT     640 01-13-89* COPY and Partitioned Tape
89-009R0.WS      640 01-10-89* COPY and Partitioned Tape
89-010R0.TXT     768 01-13-89* REQUEST SENSE EOM data on Partitioned Tape
89-010R0.WS      768 01-10-89* REQUEST SENSE EOM data on Partitioned Tape
89-011R0.TXT     640 01-13-89* MODE SELECT Device Configuration Parameters
89-011R0.WS      640 01-10-89* MODE SELECT Device Configuration Parameters
89-012R1.TXT    1536 01-13-89* Separation of BOM and BOP0
89-012R1.WS     1536 01-12-89* Separation of BOM and BOP0
89-013R1.TXT    1536 01-13-89* 9.2.13 SPACE Command, Rev 6a, page 9-30
89-013R1.WS     1536 01-12-89* 9.2.13 SPACE Command, Rev 6a, page 9-30
89-016R1.TXT    1408 01-13-89* Active Format field in Device config page
89-016R1.WS     1408 01-10-89* Active Format field in Device config page
89-018R0.TXT    7358 01-17-89* Preliminary Cable Test Results
89-019R1.TXT   14592 01-16-89* Costa Mesa Working Group Minutes Jan '89
89-019R1.ZIP    7796 01-16-89* Costa Mesa Working Group Minutes Jan '89
89-020R0.TXT   22199 01-17-89* Fiber Optic Channel Working Group Minutes
89-021R0.TXT    2235 01-17-89* Tape Read Underlength Detection
89-023R0.TXT    2048 01-17-89* Synchronized Sector Offset for ESDI
89-023R0.WS     2304 01-17-89* Synchronized Sector Offset for ESDI
89-024R0.TXT    1792 01-24-89* When not to clear sense data
89-024R0.ZIP    1264 01-24-89* When not to clear sense data
89-025R0.TXT    2176 01-26-89* SEARCH DATA Transfer Length Inconsistency
89-025R0.WS     2304 01-26-89* SEARCH DATA Transfer Length Inconsistency
89-026R0.TXT    2336 02-06-89* March SCSI Working Group Meeting Announcement
89-027R0.TXT     640 02-14-89* ESDI 3.0 Resolves NCR's Public Review Comment
89-028R1.BRF   55552 05-02-89* Feb 89 X3T9.2 Minutes (ASCII w/o enclosures)
89-028R1.TXT  146176 05-02-89* Feb 89 X3T9.2 Minutes (plain ASCII)
89-028R1.ZAP   23524 06-14-89* Feb 89 X3T9.2 Minutes (ZIP'd WS w/o encl.)
89-028R1.ZIP   58437 05-02-89* Feb 89 X3T9.2 Minutes (ZIP'd WordStar file)
89-029R0.TXT     702 02-16-89* Letter thanking Bill Burr for editing ISO 9316
89-035R0.TXT    5888 02-28-89* Tape Read Overlength Detection w/SILI Bit
89-035R0.ZIP    3197 02-21-89* Tape Read Overlength Detection w/SILI Bit
89-036R1.TXT    7393 09-08-89* SCSI-3 Preparations for New Physical Layer(s)
89-036R1.ZIP    3591 09-08-89* SCSI-3 Preparations for New Physical Layer(s)
89-037R0.TXT   14354 01-04-80* Change to Media Changer Elem. Stat. Descriptor
89-042R0.TXT    9141 03-13-89* Milpitas Working Group Minutes Mar '89
89-042R0.ZIP    5306 03-13-89* Milpitas Working Group Minutes Mar '89
89-045R0.TXT   20864 03-15-89* Fiber Channel Working Group Minutes (Jan '89)
89-047R0.TXT    9728 04-12-89* NCR Proposal for a LOGICAL UNIT RESET Message
89-047R0.ZIP    4707 04-12-89* NCR Proposal for a LOGICAL UNIT RESET Message
89-049R0.BRF   35968 05-01-89* Apr 89 X3T9.2 Minutes (ASCII w/o enclosures)
89-049R0.TXT  142336 05-01-89* Apr 89 X3T9.2 Minutes (plain ASCII)
89-049R0.ZAP   16902 06-14-89* Apr 89 X3T9.2 Minutes (ZIP'd WS w/o encl.)
89-049R0.ZIP   55344 05-01-89* Apr 89 X3T9.2 Minutes (ZIP'd WordStar file)
89-050R1.TXT   29184 05-10-89* Dan Davies' proposed changes to S2R8 Section 9
89-050R1.ZIP   13671 05-09-89* Dan Davies' proposed changes to S2R8 Section 9
89-053R0.TXT    6759 06-30-89* Tom Wicklund's comments on S2R8
89-055R1.TXT  102144 05-02-89* Gene Milligan's comments on S2R8
89-055R1.ZIP   45322 05-02-89* Gene Milligan's comments on S2R8
89-058R0.TXT    4224 05-02-89* John Lohmeyer's X3T9 Letter Ballot on SCSI-2
89-058R0.ZIP    2491 05-02-89* John Lohmeyer's X3T9 Letter Ballot on SCSI-2
89-061R0.PRN   17218 05-05-89* SCSI Bus Fairness Proposal (IBM line chars)
89-061R0.TXT   17280 05-05-89* SCSI Bus Fairness Proposal (ugly ASCII)
89-061R0.ZIP    7952 05-05-89* SCSI Bus Fairness Proposal (ZIP'd WS 4)
89-066R1.TXT   24192 05-11-89* Wichita Working Group Minutes
89-066R1.ZIP   12527 05-11-89* Wichita Working Group Minutes
89-068R0.TXT    1536 05-10-89* Maxtor Public Review Comment on ESDI
89-068R0.ZIP    1134 05-10-89* Maxtor Public Review Comment on ESDI
89-075R1.BRF   46720 08-29-89* Jun 89 X3T9.2 Minutes (ASCII w/o enclosures)
89-075R1.TXT  154496 08-29-89* Jun 89 X3T9.2 Minutes (plain ASCII)
89-075R1.ZAP   17777 08-29-89* Jun 89 X3T9.2 Minutes (ZIP'd WS w/o encl.)
89-075R1.ZIP   46464 08-29-89* Jun 89 X3T9.2 Minutes (ZIP'd WordStar file)
89-090R0.TXT   19456 07-12-89* Chicago Working Group Minutes
89-090R0.ZIP   10240 07-12-89* Chicago Working Group Minutes
89-094R5.TXT   77568 12-01-89* Single-cable 16-bit proposal
89-094R5.ZIP   13849 12-01-89* Single-cable 16-bit proposal
89-095R1.WS    16896 07-18-89* Read Sub-channel CD-ROM command fixes (SCSI-2)
89-100R1.TXT    2714 08-03-89* November Working Group Meeting Announcement
89-100R1.WS     2432 08-03-89* November Working Group Meeting Announcement
89-100R1.WS5    2688 08-03-89* November Working Group Meeting Announcement
89-101R0.TXT    1142 08-07-89* Max Burst Size Rounding Definition
89-102R0.TXT    1792 08-08-89* Another ESDI boo-boo cought by steely eyes
89-102R0.WS     1920 08-08-89* Another ESDI boo-boo cought by steely eyes
89-103R1.TXT    7040 09-08-89* Comments on R10 SCSI-2 document
89-103R1.ZIP    3275 09-08-89* Comments on R10 SCSI-2 document
89-105R0.TXT    2304 08-15-89* Response to Hospodor (X3B7.1) letter
89-105R0.ZIP    1627 08-15-89* Response to Hospodor (X3B7.1) letter
89-108R0.ZIP  107871 08-17-89* SONY proposal for CD-ROM device
89-109R1.TXT   13821 08-28-89* New Copy Segment Descriptors (Rev 1)
89-109R1.ZIP    4889 08-28-89* New Copy Segment Descriptors (Rev 1)
89-110R0.TXT    4480 08-18-89* Target Initiated SDTR Message Control
89-110R0.ZIP    2406 08-18-89* Target Initiated SDTR Message Control
89-111R0.BRF   45568 08-26-89* Aug 89 X3T9.2 Minutes (ASCII w/o enclosures)
89-111R0.TXT  162688 08-26-89* Aug 89 X3T9.2 Minutes (plain ASCII)
89-111R0.ZAP   21163 08-26-89* Aug 89 X3T9.2 Minutes (ZIP'd WS w/o encl.)
89-111R0.ZIP   55353 08-26-89* Aug 89 X3T9.2 Minutes (ZIP'd WordStar file)
89-120R0.TXT   18816 09-09-89* Oklahoma City Working Group Minutes
89-120R0.ZIP    8127 09-09-89* Oklahoma City Working Group Minutes
89-121R0.PRN   15744 09-13-89* Differences between ESDI Rev 3 and Rev 3A
89-121R0.ZIP    4346 09-13-89* Differences between ESDI Rev 3 and Rev 3A
89-126R0.BRF   43520 10-19-89* Oct 89 X3T9.2 Minutes (ASCII w/o enclosures)
89-126R0.TXT  159232 10-19-89* Oct 89 X3T9.2 Minutes (plain ASCII)
89-126R0.ZAP   17595 10-19-89* Oct 89 X3T9.2 Minutes (ZIP'd WS w/o encl.)
89-126R0.ZIP   47987 10-19-89* Oct 89 X3T9.2 Minutes (ZIP'd WordStar file)
89-138R0.TXT   19712 11-02-89* Santa Ana Working Group Minutes
89-138R0.ZIP    8498 11-02-89* Santa Ana Working Group Minutes
89-140R0.TXT    4445 11-03-89* WD public review comment/ASCII text
89-140R0.ZIP    2622 11-06-89* WD public review comment/WordPerfect
89-145R0.TXT    1591 11-29-89* Proposed Additional Sense Code Qualifiers
89-149R0.BRF   32000 12-08-89* Dec 89 X3T9.2 Minutes (ASCII w/o enclosures)
89-149R0.TXT  151296 12-08-89* Dec 89 X3T9.2 Minutes (plain ASCII)
89-149R0.ZAP   12723 12-08-89* Dec 89 X3T9.2 Minutes (ZIP'd WS w/o encl.)
89-149R0.ZIP   44420 12-08-89* Dec 89 X3T9.2 Minutes (ZIP'd WordStar file)
89-150R0.TXT   15748 12-01-89* 16-bit single-cable Appendix Form
89-150R0.ZIP    3062 12-01-89* 16-bit single-cable Appendix Form
EXPOS.TXT       6276 02-09-89* Draft Expository Remarks for SCSI-2 [Comments?]
EXPOS.ZIP       3803 02-09-89* Draft Expository Remarks for SCSI-2 [Comments?]
- Total of 112 files in file area number 5



File area: 6

File area #  6 ... Miscellaneous Files

--- Miscellaneous files --- 

WSCNVN.ZIP     36394 12-14-84* WordStar File Conversion Utility - Useful!
STRIP_Z.EXE     9181 02-17-87* Removes ^Z characters from text files
FIX_TYPE.COM   14799 03-07-86* Lets you examine fixed disk types
WSTXT.ZIP      13334 04-08-88* WordStar to/from TXT w/ IBM graphics characters 
TECHNOTE.ZIP    9201 11-01-88* Mac Tech Note #96.  SCSI Problems. 
SCSIARB.ZIP     1216 02-10-89* SCSI Arbitration Timing Model
FT.ZIP         21509 03-01-89* a better fix_type than fix_type.com! 
WSC.ZIP        10139 03-09-89* A wordstar pagination program..simple. 
SMILEY.ZIP      4013 05-24-89* Assorted faces 8-) from Jeff Stai
SMILEY.TXT      7227 05-25-89* Assorted faces 8-) from Jeff Stai


File area #  7 ... SCSI-1 Revision 17B Text Files

--- SCSI Version 1 Revision 17B WordStar Files --- 

    (This is the last revision prior to publication by ANSI.
     The editorial changes made during the final edit are not
     included in these files.  These files may be useful in 
     preparing functional specifications, etc.)

--- SCSI-1 by Sections:

17B_00.ZIP     20859 09-25-89* 
17B_01.ZIP      3282 12-17-85* 
17B_02.ZIP       430 12-17-85* 
17B_03.ZIP      2285 12-17-85* 
17B_04.ZIP     12591 12-17-85* 
17B_05.ZIP     21110 12-17-85* 
17B_06.ZIP      9386 12-17-85* 
17B_07.ZIP     19711 12-17-85* 
17B_08.ZIP     28658 12-17-85* 
17B_09.ZIP     20419 12-17-85* 
17B_10.ZIP      9585 12-17-85* 
17B_11.ZIP      2245 12-17-85* 
17B_12.ZIP     10992 12-17-85* 
17B_13.ZIP      1872 12-17-85* 
17B_14.ZIP      1970 12-17-85* 
17B_A0.ZIP      4326 12-17-85* 
17B_B0.ZIP      1814 12-17-85* 
17B_C0.ZIP      5517 12-17-85* 
17B_D0.ZIP      4279 12-17-85* 
17B_E0.ZIP      2059 12-17-85* 
17B_F0.ZIP      2099 12-17-85* 
17B_G0.ZIP      1689 12-17-85* 

--- The whole SCSI-1 document (all of the above):

17B.ZIP       187041 09-25-89* 



File area #  8 ... SCSI-2 Draft Standard Text Files

--- SCSI-2 Draft Standard --- 

 NOTE: An ANSI Copyright applies to these files

NOTICE.TXT      1099 06-28-89* Copyright Notice - Read this first

--- WordStar Files  (Revision 10b) ---

     The following files are ready to print using WordStar. If you don't 
     have WordStar, either consider downloading WSCNVN.ZIP from file area 
     6 or download the .TXT versions of these files.

S2R10-B.ZIP   385961 09-25-89* The whole Rev 10b (Sections 00 -- 17, A)
REV10B.ZIP     22523 08-22-89* Shows just what changed from Rev 10 to Rev 10b

     Rev 10b broken up into one file per section:

S2R10B00.ZIP   16756 08-22-89* Section 00 Cover Page and Table of Contents
                                         (includes merge print file)
S2R10B01.ZIP    3489 08-22-89* Section 01 Scope                              
S2R10B02.ZIP     893 08-22-89* Section 02 Reference Documents                
S2R10B03.ZIP    4022 08-22-89* Section 03 Glossary and Editorial Conventions 
S2R10B04.ZIP   14943 08-22-89* Section 04 Physical Characteristics           
S2R10B05.ZIP   31129 08-22-89* Section 05 Logical Characteristics            
S2R10B06.ZIP   19050 08-22-89* Section 06 SCSI Commands and Status           
S2R10B07.ZIP   61209 08-22-89* Section 07 Common Section for All Devices     
S2R10B08.ZIP   58025 08-22-89* Section 08 Direct-Access                      
S2R10B09.ZIP   36344 08-22-89* Section 09 Sequential-Access                  
S2R10B10.ZIP    9891 08-22-89* Section 10 Printer                            
S2R10B11.ZIP    5385 08-22-89* Section 11 Processor                          
S2R10B12.ZIP    3404 08-22-89* Section 12 Write-Once                         
S2R10B13.ZIP   32780 08-22-89* Section 13 CD-ROM                             
S2R10B14.ZIP   11599 08-22-89* Section 14 Scanner                            
S2R10B15.ZIP   15233 08-22-89* Section 15 Optical Memory Device              
S2R10B16.ZIP   22651 08-22-89* Section 16 Medium Changer Device              
S2R10B17.ZIP    6164 08-22-89* Section 17 Communications Device              
S2R10BA.ZIP    32663 08-22-89* Section A  Appendixes                         

     Rev 10b broken up into one plain ASCII file per section:

S2R10B00.TXT   77431 11-22-89* Section 00 Cover Page and Table of Contents
S2R10B01.TXT    7438 11-22-89* Section 01 Scope                              
S2R10B02.TXT     921 11-22-89* Section 02 Reference Documents                
S2R10B03.TXT    8934 11-22-89* Section 03 Glossary and Editorial Conventions 
S2R10B04.TXT   54165 11-22-89* Section 04 Physical Characteristics           
S2R10B05.TXT  102093 11-22-89* Section 05 Logical Characteristics            
S2R10B06.TXT   63258 11-22-89* Section 06 SCSI Commands and Status           
S2R10B07.TXT  251342 11-22-89* Section 07 Common Section for All Devices     
S2R10B08.TXT  256338 11-22-89* Section 08 Direct-Access                      
S2R10B09.TXT  147571 11-22-89* Section 09 Sequential-Access                  
S2R10B10.TXT   42403 11-22-89* Section 10 Printer                            
S2R10B11.TXT   17633 11-22-89* Section 11 Processor                          
S2R10B12.TXT    8794 11-22-89* Section 12 Write-Once                         
S2R10B13.TXT  147988 11-22-89* Section 13 CD-ROM                             
S2R10B14.TXT   57608 11-22-89* Section 14 Scanner                            
S2R10B15.TXT   80560 11-22-89* Section 15 Optical Memory Device              
S2R10B16.TXT  113621 11-22-89* Section 16 Medium Changer Device              
S2R10B17.TXT   29007 11-22-89* Section 17 Communications Device              
S2R10BA.TXT   101976 11-22-89* Section A  Appendixes                         

--- The following files are spreadsheets (1-2-3 compatible) that the editors
    use to maintain the document.

S2R10-OP.ZIP    5162 06-23-89* Opcode Spreadsheet
S2R10-PC.ZIP    3251 06-23-89* Page Code Spreadsheet
S2R10ASC.ZIP   10056 06-23-89* Additional Sense Code Spreadsheet

--- Draft SCSI-2 Style manual

STYLE.ZIP       8968 06-23-89* SCSI-2 Style manual



File area # 11 ... SCSI-2 AutoCAD Figures

--- SCSI-2 Draft Standard Figures --- 

 NOTE: An ANSI Copyright applies to these files
       (See NOTICE file in each ZIP)

 SCSI Figures in AutoCAD DXF (Data Exchange) Format:
      [(Obs) means the figure is obsolete.]

DIFFPROT.ZIP    3433 04-20-87* SCSI-2 Fig: Differential Protection Circuit
NONCBL.ZIP      9590 04-20-87* SCSI-2 Fig: Nonshielded Cable A Connector
NONCBLB.ZIP    10006 04-20-87* SCSI-2 Fig: Nonshielded Cable B Connector (Obs)
NONDEV.ZIP     20666 04-20-87* SCSI-2 Fig: Nonshielded Device A Connector
NONDEVB.ZIP    21602 04-20-87* SCSI-2 Fig: Nonshielded Device B Connector (Obs)
PASSDIFF.ZIP    3093 04-20-87* SCSI-2 Fig: Passive Differential Terminator
PHWARB.ZIP      4272 04-20-87* SCSI-2 Fig: Phase Diagram (Obs)
PHWOARB.ZIP     3772 04-20-87* SCSI-2 Fig: Phase Diagram (Obs)
SAMPCNFG.ZIP    5638 04-20-87* SCSI-2 Fig: Sample Configurations
SHLDCBL1.ZIP   28780 04-20-87* SCSI-2 Fig: Shielded Cable Alternative 1 (Obs)
SHLDCBL2.ZIP   27594 04-20-87* SCSI-2 Fig: Shielded Cable Alternative 2
SHLDDEV1.ZIP   19366 04-20-87* SCSI-2 Fig: Shielded Device Alternative 1 (Obs)
SHLDDEV2.ZIP   30914 04-20-87* SCSI-2 Fig: Shielded Device Alternative 2
SIGNLSEQ.ZIP    8568 04-20-87* SCSI-1 Fig: Signal Sequence Diagram (Obs)
S2_APX_A.ZIP    7045 03-20-89* SCSI-2 Fig: Signal Sequence Diagram (DWG file)
SNAPDXFR.ZIP    7206 04-20-87* SCSI-2 Fig: Snapshot Prior to Data Transfer
SNAPSEL.ZIP     6750 04-20-87* SCSI-2 Fig: Snapshot Prior to Selection
TERMDIFF.ZIP    3380 04-20-87* SCSI-2 Fig: Differential Terminator
TERMSE.ZIP      3241 04-20-87* SCSI-2 Fig: Single-ended Terminator
ICON.ZIP        6113 03-31-88* SCSI Icon (not currently in the document)



File area # 13 ... SCSI-2 Common Access Method File Area

--- SCSI-2 Common Access Method Files --- 

 This file area is associated with the SCSI-2 CAM group activities.  
 (If you want to display a file on-line, Type the .TXT version of the file.)

JUSTIFY.TXT    10240 11-29-88* Justification and call to arms

--- CAM Meeting Minutes:

MIN8810.TXT    10752 11-29-88* Minutes of the October 19 meeting in San Jose
MIN8812.TXT     4992 12-29-88* Minutes of the December 7 meeting in San Diego
MIN8901.TXT     7680 02-17-89* Minutes of January 17 meeting in Irvine
MIN8902.TXT     4992 02-27-89* Minutes of February 22 meeting in Austin
MIN8902.ZIP     3382 07-27-89* Minutes of February 22 meeting in Austin
MIN8903.TXT     5504 03-29-89* Minutes of March 8 meeting in Milpitas 
ATBUSMIN.TXT    6272 03-10-89* AT Bus Committee Minutes 3/9/89 
MIN8904.TXT     8576 05-02-89* Minutes of April 13 meeting in Denver 
MIN8904.ZIP     5118 07-27-89* Minutes of April 13 meeting in Denver 
MIN8905.TXT     7356 05-14-89* Minutes of May 10 meeting in Wichita
MIN8906.TXT     9856 06-28-89* Minutes of June 8 meeting in Cupertino
MIN8906.ZIP     5828 07-27-89* Minutes of June 8 meeting in Cupertino
MIN8907.TXT     7354 07-26-89* Minutes of July 12 meeting in Chicago
MIN8907.ZIP     4595 07-27-89* Minutes of July 12 meeting in Chicago
MIN8908.TXT     6841 09-03-89* Minutes of August 9-10 meeting in Costa Mesa
MIN8908.ZIP     4347 09-03-89* Minutes of August 9-10 meeting in Costa Mesa

--- Other files (in order received):

ISSUES.TXT      1792 12-16-88* NCR presentation - ISSUES 
LIBRARY.TXT     5632 12-16-88* NCR SCSI Library Description 
STRUCTUR.TXT    6272 12-16-88* NCR CAM structure definition 
CAMDOC.TXT     20224 01-17-89* CAM Working Document from 1/12/89 meeting
DAL_PROP.TXT    1792 01-18-89* Layering and Control Blocks
DAL_PROP.WS     1792 01-18-89* Layering and Control Blocks
PHYSTOLG.TXT    5504 01-25-89* CONVERSION TO/FROM PHYS/LOGICAL CAPACITIES 
DOS_OSD.TXT    10752 03-21-89* OSD interface spec for DOS 
PHY2LOG.TXT     3823 02-16-89* phyical to logical conversiov C program 
DMARESRC.TXT    1888 02-27-89* DMA Resource message from Greg Slaughter
PICK-CHS.TXT   13699 03-04-89* Algorithm to pick C/H/S values from # blocks 
INIT-INT.TXT    4096 03-15-89* Comments on Shishir's proposal 
DOS_MSG0.TXT    2688 03-20-89* DOS OSD 
ATBUSCAM.ZIP   28449 03-31-89* The initial draft of the proposed ATBus device  
ATBUSCAM.TXT   78336 03-31-89* The initial draft of the proposed ATBus device  
DOS_OSD1.TXT   16640 04-04-89* Revised DOS OSD proposal 
CAMSIM.TXT     39040 05-15-89* Merged SIM and Initialization Spec 
DOS_OSD2.TXT   17280 05-18-89* Revised DOS OSD proposal 
UNIXOSD.TXT     2048 06-04-89* Interested parties UNIX-OSD, mail list
CL_ATA.TXT     22784 07-24-89* Cirrus Logic ATA rev. 1.2 Proposals
CL_ATA.WS      22144 07-24-89* Cirrus Logic ATA rev. 1.2 Proposals
OCT_UNIX.TXT    4393 10-23-89* October Unix OSD notes and Nov Agenda.
89-141R0.TXT    2422 11-17-89* January 1990 Meeting Announcement
PDIAG.DOC       8960 12-04-89* ATA PDIAG / DASP Timing Specification 




File area: 17
File area # 17 ... Fiber Channel File Area

--- FILES:  --- 

 Fiber Channel Related Files.

89-141R0.TXT    2422 11-17-89* January 1990 Meeting Announcement
DECMEET.TXT     1536 11-20-89* Meeting Agenda for Dec FC Working Group

88-112R0.TXT    3840 09-06-88* August '88 Fiber Optic Study Group Highlights
88-112R0.ZIP    2481 07-26-89* August '88 Fiber Optic Study Group Highlights
88-129R0.TXT   44160 10-19-88* August & September '88 Minutes
88-129R0.ZIP   20032 07-26-89* August & September '88 Minutes
88-160R0.TXT   20096 12-12-88* Fiber Channel Description
88-160R0.ZIP    9150 07-26-89* Fiber Channel Description
89-020R0.TXT   22199 01-17-89* December '88 Minutes
89-020R0.ZIP   11063 07-26-89* December '88 Minutes
89-045R0.TXT   20864 03-15-89* January '89 Minutes
89-045R0.ZIP   10384 07-26-89* January '89 Minutes
FOWG0689.TXT   32512 06-15-89* June 22&23 FO Working Group Minutes 
FOWG0689.ZIP   15692 07-26-89* June 22&23 FO Working Group Minutes 
FOWG0789.TXT   24320 08-10-89* July 89 Fiber Channel Working Group Minutes
FOWG0789.ZIP   11838 08-14-89* July 89 Fiber Channel Working Group Minutes
FOWG0889.TXT   24320 09-01-89* August 23 Fiber Channel Working Group Minutes
FOWG0889.ZIP   11813 09-03-89* August 23 Fiber Channel Working Group Minutes
FOWG0989.TXT   39424 09-21-89* 9/11&12 Fiber Channel Working Group Minutes
FOWG0989.ZIP   18563 09-21-89* 9/11&12 Fiber Channel Working Group Minutes
FOWG1089.TXT    8704 11-16-89* 10/16 Fiber Channel Working Group Minutes
FOWG1089.ZIP    4035 11-17-89* 10/16 Fiber Channel Working Group Minutes
FOWG1189.TXT   28416 11-16-89* 11/2&3 Fiber Channel Working Group Minutes
FOWG1189.ZIP   11119 11-17-89* 11/2&3 Fiber Channel Working Group Minutes


From owner-pc532%daver@mips.com@bu-it.BU.EDU Sun Dec 10 15:41:35 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
X-Mailer: Mail User's Shell (6.2 5/11/88)
To: pc532@daver.UU.NET
Subject: Re: I/O cards
Date: 10 Dec 89 11:50:44 PST (Sun)
From: george@wombat.UUCP (George Scolaro)

[In the message entitled "I/O cards" on Dec 11,  0:51, David Burren [Athos] writes:]
> 
> Sitting around a bonfire last night with a group of other locals interested in
> the pc532, one of the things that turned up was an idea for a PostScript board.
> I'll bounce the idea off the mailing-list and see what people think:
> 
> Of course, the board's CPU must have enough grunt to make it worthwhile, or
> we may as well just run the interpreter on the host.  We're toying with the
> idea of a 32CG16 or a 32GX32 for a prototype.  Using a 32k processor simplifies
> the software development somewhat in a pc532 environment.

The 32cg16 offers similar performance to a 68k, ie both running at the same
clock. The main advantage of the cg16 is that it can talk to an FPU, either
the 32081 or 32381. I have heard from various factions that postscript really
does/doesn't need floating point. People in the know claim that having fp
only improves performance by 5-10%, since lots of the bezier stuff is done
in fixed point, or via other approximations anyhow.

> We'd be unlikely to achieve the performance of the latest RISC PostScript
> controllers, but it won't be hard to leave the 68k-based controllers behind
> in the speed stakes.

I'm not sure how much the 80960 costs these days (real price as against
quoted large volume pricing) but it is a pretty neat chip. Dave and I have
played with it at work (on a laser printer design) and it certainly rips
along at a great rate of knots. The register scoreboarding is a real win
when trying to make use of the memory bandwidth. The other advantage is that
it is real easy to hook two of them on the same bus. I wired up a kludge
board that takes two 80960's and plugs into one 80960 socket. Intel did a
real nice job of supporting two 960's on one bus, and with the instruction
cache and load scheduling you can keep both of them quite busy. There is an
elaborate interprocessor communication facility as well as the obvious
memory/semaphore message handling. The 960 is supported (how well?) by the
GNU software, the only problem with it is that it would be a different
software base than the 32k. Also, if we use the 32k family NS might be even
nicer about chipset pricing! Note also, even though the 80960KB has the on
chip FPU and the 80960CA doesn't, both actually have the FPU. Intel is
obviously trying to create a cheaper part (ie differentiate the product
line). I assume that using the FPU in the 80960CA is a case of use at your
own risk!

> While we proceed to flesh out the design, is there anyone out there interested?
> Any areas where what I've outlined would fall down?  Thanks.

Sounds like an interesting project, certainly anything that speeds up
printing is definitely something I want. When Dave & I were in OZ at the end
of '88, we visited Osiris (in Sydney) for NS, and at the time they claimed
that they had a Postscript clone in the works/near completion. It might pay
to check with them and see how they are doing and or if they are interested
in your group's plans. Osiris has been a 32k supporter for quite a few years
and have done System V ports and their own hardware. Their # is (02)406-6299
and they are in Chatsworth, the bloke in charge is Eric Mills.

> Dave and George,
> 	We're atttempting to organise ourselves a bit here, work out how many
> locals will order boards, and do it all in one batch.  I'll be interested to
> hear the details of the cheap chip deal from NS: we may want to get them from
> you with the boards, as I suspect the local NS distributors may be a little
> hard to convince that they should give us discounts...

We are getting ready for another batch of boards, from the interest shown so
far we will definitely do 20 boards (maybe 30 if a few more people commit).
Yes, I have friends in oz (I suffered through it too) that have had lots of
trouble with NS distributors and getting any pricing at all. You should try
getting support from W.A. (from any distributor!).

Monday the salesman from the PCB house I plan to use will be visiting me,
so I plan to try and hassle him for a lower price, in addition I will ask
what method payment has to be made. At $4-6K for the PCB's (20 or 30) I
don't really want to have to pay up front etc, hopefully a deposit will
keep him happy, we'll see.

best regards,

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com@bu-it.BU.EDU Sun Dec 10 15:44:31 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
X-Mailer: Mail User's Shell (6.4 2/14/89)
To: pc532@daver.UU.NET
Subject: Re: FPU
Date: 10 Dec 89 18:47:33 GMT (Sun)
From: ken%mm@gatech.edu (Ken Seefried iii)

On Dec 9,  6:56pm, George Scolaro wrote:
} 
} Yes, its called the NS32580. 
...[cool stuff deleted]...
} And NO, I am not going to modify the PCB to support it!
} 

Fair enough, but do you think it would be possible to build a 
little daughter card that sits in the 532 socket and has the 
requisite sockets on it?  Something like the Mac 68020/030
upgrade boards that sit in the 68000 socket, or the Wietek
Wm1167 boards that sit in the 80387 sockets?

12 MFLOPS is gawd-awful hard to pass up (even though the 
96001 is rated at something like *40* MFLOPS).

The Wm31xx chipset can be had for <<$2000.


-- 

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

From owner-pc532%daver@mips.com@bu-it.BU.EDU Sun Dec 10 15:45:36 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
X-Mailer: Mail User's Shell (6.4 2/14/89)
To: pc532@daver.UU.NET
Subject: Re: I/O cards
Date: 10 Dec 89 19:07:27 GMT (Sun)
From: ken%mm@gatech.edu (Ken Seefried iii)

On Dec 11, 12:51am, David Burren [Athos] wrote:
} 
} Sitting around a bonfire last night with a group of other locals interested in
} the pc532, one of the things that turned up was an idea for a PostScript board.
} I'll bounce the idea off the mailing-list and see what people think:
} 

What a truely awsome idea!  I'd sure as hell buy one (if I could 
afford it, 'course).

}
} .......One _could_ licence a PostScript interpreter from Adobe, but we have
} enough experience with NeWS, PD PostScript interpreters, as well as Adobe
} products to feel that an Adobe-free interpreter is feasible.
} 

Does not GNU have some form of a PostScript clone?  

}
} Of course, the board's CPU must have enough grunt to make it worthwhile, or
} we may as well just run the interpreter on the host.  We're toying with the
} idea of a 32CG16 or a 32GX32 for a prototype.  Using a 32k processor simplifies
} the software development somewhat in a pc532 environment.
} 

The 32GX32, I should think...or another '532.  I am also under the 
impression that the Weitek PostScript chips are not obscenely
expensive, though I could be wrong.

} 
} PostScript supports the concept of files, and some high-end PostScript printers
} these days have a SCSI Port for a local disk.  We'd provide file operations
} through the host.  A message-passing system such as Minix with a seperate FS
} makes this particularly nice.
} 

Neet...having played with an Apple LaserWriter NTX with an attached
100MB font drive, I can vouch for the fact that this is a really
good way of doing things...

}
} The board's software would be downloaded from the host (except the boot ROM :-)
} Part of the software is the reconfigurable driver for the printer port, with
} modules for Epson dot-matrixes, LaserJets, you name it.
} 

Okay...I'm sold...;')

}
}                                                              The board would
} have 1 Mb or so of local RAM.  Depending on what restrictions are imposed by
} our choice of processor, we'd like to implement virtual memory, again using
} the host filesystem.  
}

Pretty ambitious...maybe it would be better to allow for 4MB or so
on the card...??

} 
} Sounds great.  As with everything, how popular it will be depends somewhat on
} the end price :-(
} By the way, can someone refresh my memory on the 96001?  I recall bits about
} the 56001, but not the 96001 (ie. was that a typo or is my ignorance showing
} through?).
} 

Well...the design will be free...not sure what can be done on price.
Students can get the pricy parts for free from Motorola, usually.

The 96001 is a floating-point version of the 56001 streched from
56-bit arithmetic to 96-bit (hence the names).  Motorola throws 
around truly astounding performance figures (40 MFLOPS, for one).
I don't have my hands on one yet, so I can't verify...

Oh...the control processor is a 68020.  I hope that isn't sacriledge...

;-)


-- 

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

From owner-pc532%daver@mips.com@bu-it.BU.EDU Sun Dec 10 16:27:16 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Sun, 10 Dec 89 15:47:02 EST
From: mccalpin@masig3.ocean.fsu.edu (John D. McCalpin)
To: pc532@daver.uu.NET
Subject: re: FPU Performance

>Well, I ran the Linpack in C. Looks like about 327 Kflops. Rolled is
>better than unrolled (309K unrolled). This was at 25 Mhz. About 1/40th
>the Cray.

This is less than a factor of 1.6 faster than my NeXT with a
25 MHz 68030/68882 combination.  The 532/381 looks a lot better than
that on paper....

>If someone is interested, I'll work on it some more to see what is
>really possible with the 532/381 combination.

I am very interested in how much improvement you can get toward the 
~2 MFLOPS asymptotic limit of the chip.  If the floating-point performance
of this board can be gotten into the 1+ MFLOPS range, then I would be
very interested in putting together one to use in my consulting work.
In fact, I'm so crazy that I would probably try very hard to spring for
the Weitek chip if it were available....

From owner-pc532%daver@mips.com@bu-it.BU.EDU Sun Dec 10 17:27:21 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Sun, 10 Dec 89 14:02:50 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: dlr@daver (Dave Rand)
To: pc532@daver.UU.NET
Subject: Re: FPU

[In the message entitled "Re: FPU" on Dec 10, 21:06, "Tarjei T. Jensen" writes:]
> I think National has an application note for a laserprinter controller with the
> 32CG16. I have no idea how much a bare bones laserprinter costs.

Yes. George did the GX32 app note for LBP applications while at National.
Essentially his design was used by one (or more) Laser Printer manufacturers.

I wrote the simple LBP software. I also did the 32k modeling of the
CG16 instructions, and devised a couple of them (at least one of which
only exists on the A rev CG16 - ROTIMG). I also did the microcode for
a number of the CG16 instructions, and helped to eliminate the outstanding
bugs in the older instructions. The CG16 and the 532/GX32 are the only
chips that don't have any bugs (to my knowledge) in the 32000 family.

George and I were in the Electronic Imaging Group at National.

And to make the record clear - the pc532 is not sponsered by, nor
was it designed by National Semiconductor nor any other company.
This is strictly a home project.

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

From owner-pc532%daver@mips.com@bu-it.BU.EDU Sun Dec 10 20:41:46 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
X-Mailer: Mail User's Shell (6.2 5/11/88)
To: pc532@daver.UU.NET
Subject: Re: re: FPU Performance
Date: 10 Dec 89 17:25:40 PST (Sun)
From: george@wombat.UUCP (George Scolaro)

[In the message entitled "re: FPU Performance" on Dec 10, 15:47, John D. McCalpin writes:]
> 
> >Well, I ran the Linpack in C. Looks like about 327 Kflops. Rolled is
> >better than unrolled (309K unrolled). This was at 25 Mhz. About 1/40th
> >the Cray.

The latest numbers from Dave are 411 kflops Single precision or 1/29th the
Cray something. To get this Dave interleave the code some more and used the
dot instruction where appropriate (the compilers don't use dot etc).
 
> This is less than a factor of 1.6 faster than my NeXT with a
> 25 MHz 68030/68882 combination.  The 532/381 looks a lot better than
> that on paper....

Seems to me that getting 1.6x on FPU at the same frequency is pretty damn
good for an fpu that costs a lot less than Moto's. Note also that the
architecture of the 381 pre-dates the 68882, so I don't think we can really
expect amazing performance in the FPU area. Also, how much is the Next
system? We are building a home brew system remember? If we want real
performance we should be playing with ECL MIPS chips.

> I am very interested in how much improvement you can get toward the 
> ~2 MFLOPS asymptotic limit of the chip.  If the floating-point performance

2mflops? How, the average multiply/add of the 381 is 40 clocks, at 25 mhz
this gives around 600kflops max assuming back to back fpu operations. Note
that the 381 has an early done mechanism to enable fpu and integer operations
to overlap, but if you saturate the fpu you still hit that 40 clock execution
time.

> of this board can be gotten into the 1+ MFLOPS range, then I would be

Not with a 381 you wont. Sorry.

> In fact, I'm so crazy that I would probably try very hard to spring for
> the Weitek chip if it were available....

>From the responses from NS in Israel (home of the 532 etc etc) you can see
that the 580/weitek sort-a-kinda doesn't exist and if it does it would
probably cost and arm and a leg. So, lets stick to the parts that are
readily available.

best regards,

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com@bu-it.BU.EDU Sun Dec 10 22:00:24 1989
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
Date: Sun, 10 Dec 89 21:17:30 EST
From: mccalpin@masig3.ocean.fsu.edu (John D. McCalpin)
To: pc532@daver.uu.NET
Subject: re: re: fpu performance

I wrote:
> This is less than a factor of 1.6 faster than my NeXT with a
> 25 MHz 68030/68882 combination.  The 532/381 looks a lot better than
> that on paper....

George replied:
>Seems to me that getting 1.6x on FPU at the same frequency is pretty damn
>good for an fpu that costs a lot less than Moto's. Note also that the
>architecture of the 381 pre-dates the 68882, so I don't think we can really
>expect amazing performance in the FPU area. Also, how much is the Next
>system? We are building a home brew system remember? If we want real
>performance we should be playing with ECL MIPS chips.

I don't know anything about the prices of the Motorola chips....
The basic NeXT system is $6500 at educational discounts.  That gets
you a 25 MHz 68030/68882 pair, a Motorola 56001 DSP, 8 MB RAM
(expandible to 16 MB with 1 MB SIMM's and 64 MB with 4 MB SIMM's),
a 256 MB read/write optical disk, 40 MB SCSI drive (for swap and
/dev/tmp), thin-wire ethernet, Mach, 4-slot cube with power supply,
monitor (1100x800x2), keyboard with stereo speakers, mouse.  The system
comes with GNU cc, GNU emacs, and TeX.

That sounds like a commercial, doesn't it?  Anyway, that system is $10,000
for non-university types, and can be purchased from Businessland.

I would guess that this system is not going to be a lot cheaper once the
cost of the disk drives, ethernet card, and monitor/graphics subsystem
are added in -- maybe $6000???

The 32532 should be a lot faster overall, since the NeXT is typically
rated at 3.5-5.0 Vax MIPS, and the 32532 should be between 8-12 Vax MIPS.

I wrote:
> I am very interested in how much improvement you can get toward the 
> ~2 MFLOPS asymptotic limit of the chip.  If the floating-point performance

George replied:
>2mflops? How, the average multiply/add of the 381 is 40 clocks, at 25 mhz
>this gives around 600kflops max assuming back to back fpu operations. Note
>that the 381 has an early done mechanism to enable fpu and integer operations
>to overlap, but if you saturate the fpu you still hit that 40 clock execution
>time.

Ooops, I misunderstood the implications of the early done mechanism. 
I assumed that it implied some degree of pipelining within the FPU that
would enable the FPU to accept new operands every 11 clocks.  I guess not. :-(

I wrote:
> In fact, I'm so crazy that I would probably try very hard to spring for
> the Weitek chip if it were available....

George replied:
>From the responses from NS in Israel (home of the 532 etc etc) you can see
>that the 580/weitek sort-a-kinda doesn't exist and if it does it would
>probably cost and arm and a leg. So, lets stick to the parts that are
>readily available.

Probably the best idea --- but the idea of a daughterboard that could accept
the Weitek chip is appealing....  I have gotten very spoiled having (almost)
exclusive access to an ETA-10Q (~50 native MIPS, ~200 MFLOPS), so I keep
on hoping....

From owner-pc532%daver@mips.com@bu-it.BU.EDU Sun Dec 10 23:30:31 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Sun, 10 Dec 89 16:36 PDT
From: Mark Geisert <Mark-Geisert@l66a.ladc.bull.com>
To: pc532@daver
Really-To: pc532%daver@uunet.uu.net
Subject: Re: FPU

Nobody has mentioned it yet, but to me the neatest thing about the
NS32580 + Weitek3164 combination is that it is *object-code*
compatible with the NS32381 FPU.  So all that nifty performance boost
can be bolted on with no need to recompile your applications.
 
All moot, of course, if you can't get the parts.  I have a copy of
a resale price guide from a local NS distributor that shows..
    NS32580U-20     $275
    NS32580U-25     $326
    NS32580U-30     $361
(small print is such a pain when FAX'ed...)
These are all Qty 1..24 prices.  Does anybody know how much the Weitek
3164 costs, and if it's available in small quantities?
 
As for the VME532, I talked to somebody at National a couple months
ago who seemed to think that Heurikon would be the best source for
VME532.  I called them and they were more interested in selling me
their own HK32/V532.  Can't say I blame them...  However the VME532
supported the 32580+Weitek and had cache SRAM as well.
 
The high cost of either VME532 or HK32/V532 was why pc532 sounds so
attractive to me.
 
..mark

From owner-pc532%daver@mips.com@bu-it.BU.EDU Mon Dec 11 13:11:22 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
X-Mailer: Mail User's Shell (6.2 5/11/88)
To: pc532@daver.UU.NET
Subject: Re: I/O cards
Date: 11 Dec 89 08:36:20 PST (Mon)
From: george@wombat.UUCP (George Scolaro)

[In the message entitled "Re: I/O cards" on Dec 11, 23:07, David Burren [Athos] writes:]

> Ok, having answered (?) a few questions, I'll get onto the new stuff:
> 
> People mention the i960, the Weitek PostScript chips, the AMD 29000, and other
> high-end chips.  Sure, we'd love to be able to build a world-record-speed
> PostScript controller, but as I've mentioned, we're not hardware freaks,
> although we might be able to find someone to design the board for us.
> We have to draw a line somewhere between pipe dreams and achievable (for us)
> goals.  What we'd like is a solution that everyone with a pc532 can afford,
> with good performance.

This tickled my funny bone a bit. It was my chance to get on the 'we need the
kitchen sink' band wagon too. 

> During lunch-time, we settled on the TMS34010 (possibly the '020 - but the
> hardware complexity is greater there. Anyway, this is just a crude design
> sketch).  I've done a few "paper designs" around the TMS chips and I've spent
> a while doing ray-tracing on a PC video card with an '010.

> George -> The Ethernet/serial board doesn't have a parallel port does it?
> 	  There are probably a zillion reasons why not - no room, the board's
> 	  already been designed, etc. - but it would be nice.  Otherwise I'll
> 	  end up making up a board with a Z8 and two ports, or use the ports
> 	  on my Xenix AT.

No it doesnt, and yes space was one of the major considerations, especially
since the actual backplate has the thick/thin ethernet connectors. But since
it (lets call it the et532 board) has a piggy back connector for all the
serial driver/receivers I might look at putting a centronics up there. The
real reason though is that I built a printer buffer box (with a cg16) that
takes ethernet/serial to centronics. It has a 512k byte input buffer, and
enables me to download large bitmaps quickly to the printer buffer that then
slowly outputs the stuff to the hp laserjet II. Note that one nice feature
of the HP LJII is that if you can drive the centronics fast enough, and no
normal computer does/can, you can double the transfer rate. This is because
of the way that the 68000 interrupt routine was probably coded in the
printer, it must get into the interrupt routine on receipt of a character and
prior to exiting check if another character has turned up, if so it reads it
while still in the interrupt routine. The sum result is that I can send a
250kbyte (150 dpi) bit map to the printer including rasterization time in the
AT in 18 seconds, this includes the page actually coming out, not bad!

> In a way it's a shame to see what seemed a neat hardware idea disappear in a
> puff of software, so I'd like to hear your comments and opinions on what we
> should do.  The PostScript board has the advantage that it is optimized for
> PostScript, and doesn't rob the host of grunt, but when you're not imaging it's
> sitting there idle.  In a multi-board pc532 system you start to worry less
> about "losing" grunt.

Maybe we are having the same thought here? I just 'imagined' that the et532
board could be used as you postscript accelerator board, it does have 1meg
of ram (1megabit chips) or 4 meg (4mbit chips), a gx32, no fpu, ethernet,
serial ports (and if you think that this is a good idea, centronics?). In
this way the occasional postscript print could be handled by an existing
resource, or if you don't want the serial ports etc as some have mentioned
then you have a ready made print/engine board. Or if you have lots of money
and or lots of printing to do, get two et532's, one as an actual ethernet/
serial board and the other as the printer, just don't populate the serial
ports and ethernet sections. Anyhow what do you think? Not wanting to stop
your hardware project, since that was my main reason for giving out the design
free of charge, (Dave's reason was to get people doing software) but maybe
you'd prefer to concentrate on the software?

> Another question:
> 	If I get two pc532 boards, what facility is there for hooking them
> together?  Physically I can put them in seperate cases and run a SCSI cable
> between them, but what will that cable connect to?  If I use it to hook the
> asynch buses together, can I change the ID of one board to prevent a conflict?
> Even if I can, I start to run out of IDs if I add any more boards.  One
> Ethernet/serial card, one SCSI adaptor in my AT, and two motherboards means
> 4 IDs gone.

After a request from John Connin, I have added a single 50 pin header (SCSI
compatible pinout etc) to the SCSI I/O bus (REV 1D) so you can now just run
a normal cable across from the I/O bus to any other SCSI device, including
another PC532. Yes the ID can easily be changed (it is programmable within
the dp8490 SCSI chip). True you do start to run out of IDs, not much that
can be done about that, the dp8490 supports 8 devices. The other solution,
which means you can't share boards between two PC532s is to use the spare
SYNC SCSI of one PC532 (the other I assume goes to a disk etc) to connect
to the other's I/O bus, or use ethernet to connect to PC532s if bandwidth is
not so essential (whenever that is).

Totally unrelated issue: Dave got the clock working (a no-slot Dallas Semi
DS1216E) on the weekend, so we now have a battery backed real time clock. The
DS1216E plugs into the 256k eprom socket on the PC532, and then you plug the
EPROM into the socket on top of the no-slot clock. JDR (local San Jose store,
advertises in Byte) is selling them on sale for $25 which is fairly
reasonable. The DS1216E has a 10 year life lithium battery, auto sense of
power fail etc. It gives time in years, hours (AM/PM or 24 hour), minutes,
seconds and 100ths of seconds.

Also, I got a mail message saying that to turn the FPU is disabled via an
internal connection within the 80960CA (I assume he meant 80960KA), this is
not the case. We actually tried the FPU in the 80960KA, and it sure gave the
impression of being there, or otherwise it did a real fast emulation! Another
person we spoke to some time ago, mentioned the same link, I'm sure its just
propaganda being put out by Intel to stop people trying to buy KA's on the
cheap and using them as KB's (there is a pretty big price difference).

best regards,

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com@bu-it.BU.EDU Mon Dec 11 15:27:42 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Mon, 11 Dec 89 11:37:19 PST
From: des@dtg.nsc.com (Desmond Young)
To: pc532@daver.UU.NET
Subject: Re: I/O cards

Guday,
  actually the DP8490 can support more than 8 devices. The cheapo way the
selection logic was done was there to support SCSI/PLUS, touted by AMPRO
way back. It allowed up to 64 devices. Nobody else ever picked up on it.
AMPRO wanted it because they used SCSI as a backplane I/O standard (well,
pc532 gets around to it about 5 yrs later).
  Anyway, I cannot remember how it is handled, but, the first person to
actually use more than 8 devices, I will dig out something and post code.
Cheers, Des.
Reply:  des@gpo.nsc.com, or des@dtg.nsc.com
       {decwrl,hplabs,sun,pyramid,amdahl}!nsc.com!gpo!des
Des Young, M/S D3615 National Semiconductor, Santa Clara
"The segmented structure of the 8086/8088 memory space supports
 modular software design by discouraging huge, monolithic programs"
>From iAPX 86 User Manual.        (read useful) - MY OPINION NOT NSC's

From owner-pc532%daver@mips.com@bu-it.BU.EDU Mon Dec 11 15:30:52 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Mon, 11 Dec 89 11:19:34 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: dlr@daver (Dave Rand)
To: pc532@daver.uu.net
Subject: ARRGH!

[In the message entitled "Re:  32k BSD port?" on Dec 11, 13:27, Brian Thomson writes:]
> 
> The University does not have an OEM (i.e. binary redistribution) licence,
> but we do have applicable source licences (both educational and commercial).
> The way the AT&T licence works in this instance is that we are able to
> sell/give binaries and/or source to source licencees, but we are not able to
> give/sell source OR binaries to non-source licencees.  So, unless you
> hold an appropriate set of source licences (AT&T and Berkeley) I am afraid
> there is not much we can do for you.
> 

*SIGH*

Now, does that finish the BSD idea? If *anyone* has any more ideas, please
let me know.



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

From owner-pc532%daver@mips.com@bu-it.BU.EDU Mon Dec 11 18:14:22 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: Anthony J Stieber <astieber@csd4.csd.uwm.edu>
Subject: Buying Source?
To: pc532@daver.uu.NET
Date: Mon, 11 Dec 89 15:27:59 CDT
X-Mailer: ELM [version 2.2 PL10]

    The full source code for SysV.4 to businesses is "only" $100K.
If we get enough people interested perhaps we could start a holding
company for source code.  This is something that even people outside
the pc532 group woud be interested in.  I don't know the legal
aspects of this however.  Would everyone involved in the corporation
be able to use the source?  Given the number of people who want
source or at least want to get changes made to source this may be
workable.
-- 
<-:(= Tony Stieber	astieber@csd4.csd.uwm.edu   att!uwm!uwmcsd4!astieber

From owner-pc532%daver@mips.com@bu-it.BU.EDU Mon Dec 11 18:15:22 1989
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
Date: Mon, 11 Dec 89 22:17:21 +0100
From: P{r Emanuelsson <pell@isy.liu.se>
To: pc532@daver
Subject: Re:  Parts and things..

>   Sidebar: I thought of this while wondering about using the Inmos
>   IMS C012 link adapters as auxiliary communication paths between
>   plug-in boards.
>
>                   board  |                        |  board
>
>                   +------+  20 or 10 Mbits/sec    +------+
>    8-bit parallel |      |       serial link      |      |  8-bit parallel
>    <------------> | C012 | <--------------------> | C012 | <-------------->
>                   |      |                        |      |
>                   +------+                        +------+
>
>    Interesting chip.  Single part price of the C012 is about $12.
>     BTW, a low cost transputer ($20), the T400, is now available.

I have a friend who built a very cheap link using these chips. He says
they are extremely easy to interface, and they are fast.
Of course, the ability to also connect to a transputer comes for free...

     /Pell

From owner-pc532%daver@mips.com@bu-it.BU.EDU Tue Dec 12 01:13:54 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
To: pc532@daver.UU.NET
From: Dave Mason <mason%tmsoft%uunet@daver>
Subject: Re: FPU
Organization: TM Software Associates Inc.
Date: 11 Dec 89 19:04:42 EST (Mon)

> Nobody has mentioned it yet, but to me the neatest thing about the
> NS32580 + Weitek3164 combination is that it is *object-code*
> compatible with the NS32381 FPU.  So all that nifty performance boost
> can be bolted on with no need to recompile your applications.

Actually, the neatest thing about the 580 is that it is *plug*
compatible with the 381, as ?George? pointed out.  It is designed so
the 381 can plug into a 580 socket & work!  Now, if we could find a
way to get George bored enough :-), he could route things for the larger
socket, but TRY THIS ONE FOR SIZE:

	How about a miniboard with the NS32580+WTL3164 that would plug
	into the 381 socket?!!!?

I've spent the last few minutes comparing the sockets, and all the pins
on the 580 that aren't on the 381 are connected to the 3164 or are extra
ground/power, EXCEPT: 
	BS	(P10)	- wired to a 0
	ST3	(P11)	- from the 532, but looks like it could be
				safely wired to ST4 ????
	LMODE	(R10)	- wired to Vcc/Gnd (depending on something I
				haven't figured out yet)
	~BCLK	(B8)	- the only tricky one (comes from the 532,
				complement of BCLK which IS on the 381
				socket, but presumably a NOT gate would
				add too much delay/skew)

You'd probably want additional power/ground wires running from this
miniboard to the power supply too.

> All moot, of course, if you can't get the parts.  I have a copy of
> a resale price guide from a local NS distributor that shows..
>     NS32580U-25     $326

I confirmed this versus US$310 for the 32381.

I also called Weitek and the small quantity list for the WTL3164 is
US$890 for 75ns (60ns is $1115).

Local National office (National Semi Canada Head Office!) doesn't know
anything (like availability) about any of the chips.  Though Ed Howell
is trying to track down info for me.

I really think ?johnc?'s suggestion of selling a chip kit will be a
requirement.  Not necessarily George & Dave of course, but someone.
This will also help the price, I'm sure.

12.5MFLOPS still looks possible, from here (for about 600-900
more/board) .... but then I don't know what I'm talking about with
hardware :-).  George? 

Excitedly	../Dave <mason@tmsoft>

From owner-pc532%daver@mips.com@bu-it.BU.EDU Tue Dec 12 01:13:54 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
To: pc532@daver.UU.NET
From: Dave Mason <mason%tmsoft%uunet@daver>
Subject: Re: FPU
Organization: TM Software Associates Inc.
Date: 11 Dec 89 19:04:42 EST (Mon)

> Nobody has mentioned it yet, but to me the neatest thing about the
> NS32580 + Weitek3164 combination is that it is *object-code*
> compatible with the NS32381 FPU.  So all that nifty performance boost
> can be bolted on with no need to recompile your applications.

Actually, the neatest thing about the 580 is that it is *plug*
compatible with the 381, as ?George? pointed out.  It is designed so
the 381 can plug into a 580 socket & work!  Now, if we could find a
way to get George bored enough :-), he could route things for the larger
socket, but TRY THIS ONE FOR SIZE:

	How about a miniboard with the NS32580+WTL3164 that would plug
	into the 381 socket?!!!?

I've spent the last few minutes comparing the sockets, and all the pins
on the 580 that aren't on the 381 are connected to the 3164 or are extra
ground/power, EXCEPT: 
	BS	(P10)	- wired to a 0
	ST3	(P11)	- from the 532, but looks like it could be
				safely wired to ST4 ????
	LMODE	(R10)	- wired to Vcc/Gnd (depending on something I
				haven't figured out yet)
	~BCLK	(B8)	- the only tricky one (comes from the 532,
				complement of BCLK which IS on the 381
				socket, but presumably a NOT gate would
				add too much delay/skew)

You'd probably want additional power/ground wires running from this
miniboard to the power supply too.

> All moot, of course, if you can't get the parts.  I have a copy of
> a resale price guide from a local NS distributor that shows..
>     NS32580U-25     $326

I confirmed this versus US$310 for the 32381.

I also called Weitek and the small quantity list for the WTL3164 is
US$890 for 75ns (60ns is $1115).

Local National office (National Semi Canada Head Office!) doesn't know
anything (like availability) about any of the chips.  Though Ed Howell
is trying to track down info for me.

I really think ?johnc?'s suggestion of selling a chip kit will be a
requirement.  Not necessarily George & Dave of course, but someone.
This will also help the price, I'm sure.

12.5MFLOPS still looks possible, from here (for about 600-900
more/board) .... but then I don't know what I'm talking about with
hardware :-).  George? 

Excitedly	../Dave <mason@tmsoft>

From owner-pc532%daver@mips.com@bu-it.BU.EDU Tue Dec 12 10:31:53 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Tue, 12 Dec 89 10:13:18 EST
From: Jerry Callen <jcallen@maxzilla.encore.com>
To: pc532@daver.uu.NET
Subject: Keep it CHEAP!

I think I must be in the minority on this list, but what _I_ am hoping for
out of the pc532 is an *inexpensive* Unix-like system for my home. This
means that I will be perfectly happy with Minix, plus whatever other 
goodies I can scrounge from, say, GNU. Source is medium important to
me; my guess is that I want source because I'm not willing to pay
for maintenance, so I will have to fix bugs myself.

Dave, do you have any idea what a complete system is going to come in at?
Here are my own plucked-from-the-air guestimates...

PCB				$215
parts				$400
memory (4 megs)			$400
SCSI drive (about 100 meg)	$1000
case+power supply		$150
floppy drive			$100
			      --------
				$2265

I already have a terminal. I'm sure I've missed something; what?

Anyway, $3000 is really my upper limit. Is there any chance at all that I
am going to make it?

-- Jerry Callen
   jcallen@encore.encore.com

From owner-pc532%daver@mips.com@bu-it.BU.EDU Tue Dec 12 10:32:08 1989
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
Date: 12 Dec 89 14:59 -0800
From: "Tarjei T. Jensen" <jensen%hsr.uninett@nac.no>
To: <pc532@daver>
Subject: video and postscript

Would it not be easier to have something like a Am95C60 or a DP8500 with a
BitBlt processor do the graphics for a postscript card? When it is finished
with the page you download it to the printer. All you have to do is to
translate from PostScript to the native graphics instructions. This trick has
been done before with a NEC 7220 (not postscript). [see: at last a use for an
expansion slot: a graphical console card :-)]. A graphics processor probably
cost both arms and legs.

Do anybody know whether Xwindows really needs a processor or whether it will be
happy with a Am95C60 or equivalent as the graphics engine? How would lack of a
FPU affect performance? What would the 32580/Weitek combo do to performance?
Will a 32CG16 be enough or would a 32GX32 with BitBlt slave(s) be THE thing to
have? The answer to whether I can afford this is NO for the foreseeable future.

I have seen that Berkeley have developed tools for making IC's. Do anybody
happen to know if something equivalent is available by ftp or equivalent for
pcb design?
----------
    Tarjei T. Jensen - if it isn't broken, fix it anyway.
    jensen%hsr.uninett@nac.no

From owner-pc532%daver@mips.com@bu-it.BU.EDU Tue Dec 12 11:01:34 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Tue, 12 Dec 89 07:38:41 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: dlr@daver (Dave Rand)
To: pc532@daver.UU.NET
Subject: Re: Keep it CHEAP!

[In the message entitled "Keep it CHEAP!" on Dec 12, 10:13, Jerry Callen writes:]
> 
> Dave, do you have any idea what a complete system is going to come in at?
> Here are my own plucked-from-the-air guestimates...
> 
> PCB				$215
> parts				$400
> memory (4 megs)			$400
> SCSI drive (about 100 meg)	$1000
> case+power supply		$150
> floppy drive			$100
> 			      --------
> 				$2265
> 
> I already have a terminal. I'm sure I've missed something; what?
You are pretty close (perhaps a bit low on the case). The disk drive
is nearly spot on - I saw a 150 (?) meg SCSI drive a Computer Surplus
for $1200.

The only thing you may have underestimated is the cost of the parts.
The retail price of the CPU, FPU and ICU combination is $995 - and there
is about $200 of other parts (roughly - probably a lot less if you can
scrounge a bit). Sockets and pin headers and the like.

I am working on the cost of the CPU/FPU/ICU. I know that we will be
able to get a deal on the three. I don't know how much of a deal.
More later this week (I hope)!

By the way, although we lost Amos Shapir (from National Semiconductor
in Israel), he set us up as a local newsgroup within National, Israel.
So we may see a lot of the folks from NSTA chiming in now and then.

While we are on unrelated topics, Bruce Culbertson dropped by last
night with his Minix port for the 32k... I hope to have it running
soon. I'll keep you informed.


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

From owner-pc532%daver@mips.com@bu-it.BU.EDU Tue Dec 12 12:11:43 1989
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
X-Mailer: Mail User's Shell (6.2 5/11/88)
To: pc532@daver.UU.NET
Subject: Re: video and postscript
Date: 12 Dec 89 08:13:08 PST (Tue)
From: george@wombat.UUCP (George Scolaro)

[In the message entitled "video and postscript" on Dec 12, 14:59, "Tarjei T. Jensen" writes:]
> 
> Would it not be easier to have something like a Am95C60 or a DP8500 with a
> BitBlt processor do the graphics for a postscript card? When it is finished

Listen everyone: The DP8500 is a DOG, no more suggestions about using it for
any graphics application. It has a rotten architecture is real slow, dozens
of clocks to do simple things like memory to memory move of a word (16 bit),
rotten hardware interface (each mode of operation uses different memory
timing, eg instruction read, BitBlt, data reference etc etc all different).
It is an overpriced chip, the BitBlt units are the only reasonable part of
the family and their interface is pretty bad as well. i.e. ignore the wizzy
adverts, the DP8500 is useless as a graphics processor, unless you want to
build the most complicated/slowest engine around. Lets stick to a standard,
easy to program (Oh thats right, the software tools are bad also) CPU with
a graphics back end controller. Note also, the BitBlt doesn't really help
Postscript much at all, since it does font generation (unless you have local
precomputed fonts) most of the time is burnt at that stage + the interpreter
of course. A GX32 can do BitBlt in pure 32k software faster than the CG16
can in microcode.

woof woof!

best regards,


-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com@bu-it.BU.EDU Tue Dec 12 13:44:36 1989
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
X-Mailer: Mail User's Shell (6.4 2/14/89)
To: pc532@daver.UU.NET
Subject: Re: video and postscript
Date: 12 Dec 89 16:55:38 GMT (Tue)
From: ken%mm@gatech.edu (Ken Seefried iii)

On Dec 12,  2:59pm, "Tarjei T. Jensen" wrote:
} 
} Do anybody know whether Xwindows really needs a processor or whether it will be
} happy with a Am95C60 or equivalent as the graphics engine? How would lack of a
} FPU affect performance? What would the 32580/Weitek combo do to performance?
} Will a 32CG16 be enough or would a 32GX32 with BitBlt slave(s) be THE thing to
} have? The answer to whether I can afford this is NO for the foreseeable future.
} 

X is simplest to port if there is *no* hardware, only a region of
memory in the main processors address space.  Sun 3/50s are the
classic example.

In general, the routines that take the most time are the BitBlt
routines, so theoreticly, a hardware blitter is a win.  Indeed,
many of the `intellegent' graphics boards running X never use more
than the graphics chips blitter (the older Bell Tech BLIT card
being one).  

I guess hardware line and arc drawing could be a win, but you
really don't do *that* much arc drawing in X...

Most of the routines in X are fixed-point or integer for
performance reasons.  I dunno if a really fast FPU will help you
or not.

}
} I have seen that Berkeley have developed tools for making IC's. Do anybody
} happen to know if something equivalent is available by ftp or equivalent for
} pcb design?
} 

I think your talking about `Magic'.  If I remember, it is covered
by some for of licensing agreement.  Call the EE dept. at UCB, I
guess...

-- 

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

From owner-pc532%daver@mips.com@bu-it.BU.EDU Tue Dec 12 18:47:21 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
To: pc532%daver@uunet.UU.NET
Subject: AMD 95C60
Date: Tue Dec 12 12:56:51 1989
From: blank%clanhlm@ucscc.UCSC.EDU

	I have been looking at the chip very closely for a video board
	design, and I have reached several conclusions about it.
	1) It is slow
	2) It is slow
	3) It is slow
	More serously, it is fairly slow, but it has some advantages.  With
	an external parts count of about 6, you can have a very nice
	1280 X 1024 monochrome display.  If you up the parts count to about
	30, you can have a very nice 4 bitplane colour display, at 1280 X 1024.
	The major problem is that you can only draw about 50k lines/sec
	with it (off the top of my head -- it is order 50k to 500k,
	depending on a lot of factors).  It handles almost everything
	for you, but it has a couple of wierdnesses to it.  It really
	wants to talk to memory through an DMA controller, it's
	VSYNC and HSYNC aren't well synced to the dot clock, and it is
	very easy to crash.  (In the tech ref, there is a page on how
	to crash it.  Some very simple ways, too).

	I think that a 32cg16, about 2MB of memory, a 95C60, 1 bitplane
	(4 X 256k X 4 VRAMS), Ethernet controler, and SCSI port would
	be a very nice video board (Oh, yes, and it should have a 
	keyboard port, something like an IBM RT keyboard, and a mouse
	port).  I wonder what type of monitor that the video board should
	drive -- NEC Multisync, Multisync/3D, something else?  What
	resolution should it have?

	Should it talk X, or something else (I vote for something else.
	X is a bandwidth hog).

	The tenative design I have been working on has about the above
	hardware, without the mouse/keyboard ports.

					John


From owner-pc532%daver@mips.com@bu-it.BU.EDU Tue Dec 12 21:12:47 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Tue, 12 Dec 89 17:13:54 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: gs@vw25.chips.com (George Scolaro)
To: pc532@daver
Subject: assembling the pc532

> [In the message entitled "A couple of misc questions..." on Dec 12, 13:58, Jon Loeliger writes:]
>  1)  What sort of building skills are necessary to build a pc532?  I am

The pc532 does not require any special skills (other the use of both hands
etc). I have built two boards up, both by hand soldering, both boards worked
first time (caveat: both pcbs had a single trace flaw due to the previous pcb
house + me trying to save some bucks and not requesting test). A standard
small tip soldering iron (Weller or similar reasonable brand) is all that is
required. I have already agreed to supply pre-programmed pals and eproms to
those that require them (more on this as the project progresses). The pcbs
can be wave soldered if you have access, the board does have solder masks on
top & bottom layers. All pals are written in CUPL which outputs a standard
JEDEC file that most any programmer can handle (industry standard).

>  2)  What sort of availability of major parts will be needed to piece
>      together a good, working system?  In particular, loose comments like
>			...
>      Is the canonical case a PC AT case?  Will anything I can pick up at
>      the local 'Lectronic-swap-meet-cum-ham-fest at dirt cheap prices that
>      happens to house a (what-was-it?) 10" x 11" card be sufficient?
>      Again, is some off-the-shelf Jameco power supply at the right specs
>      the way to power this critter?

Any SCSI drive should work as long as the lowest common denominator in the
SCSI command set is used. There are people out there that are better
qualified than me on this, but you should be safe in this area. Any AT case
should work fine, I have tried the motherboard in a generic clone case and
if fits perfect. The power supply connections are in the same general area
as an AT motherboard and the connectors are identical, ie yes cheap box plus
cheap power supply is all you need.

>  3)  What sort of terminal interfacing is *required*, what is *acceptable*?
>      Fuzzy questions, I know.  Let me tell you what I have and see if we

Any terminal that supports RS232 is fine. Each of the serial channels on
the pc532 has TX, RX, CTS and RTS. The connectors are 10 pin headers that
connect to standard PC/AT 10pin-9pin D connectors and are pin compatible.
ie you have hardware flow control via CTS and RTS and/or you can do software
XON/XOFF. The serial channels are software programmable from 110 to 38k,
1/2 stop bits, even/none/odd parity, 5/6/7/8 bits etc etc.

>      the pc532?  Similarly, the only printer I have right now is a simple
>      centronics-port (parallel) dot matrix Epson thing...

This is a bit trickier. The pc532 only has serial ports. There are a few
companies out there (I know of one in particular) that will sell you a little
gadget for $20-30 that will convert fast serial (>38kbaud) to centronics.

>  4)  What is the canonical booting method?  Will I be able to initially boot
>      this right off of EPROM or download from either the Xerox or Scald
>      system?  Ideally, I'd like to tweak OS and reboot somehow...

Well, at this stage we are running a MON16 clone which is a real basic dumb
monitor that talks to NS's DBG16/32 stuff that runs under NS's development
software. We will obviously have to develop some more reasonable booting
procedure (eg xmodem download). This is a software area....

>  5)  Now, without being *too* idealistic, I doubt that I will be able to
>      build a flawless system, so, tell me what sort of mechanism I will
>      have to employ to debug the hardware.  I could *probably* arrange to
>      use some of the logic analizers here at work, but that would be on a
>      rather catch-as-catch-can basis with no expert help...

Well, all that I have used (to design & checkout) is a 100mhz scope. A logic
analyser is an overkill for the level of testing that you would have to do.
The PCBs that will be run off real soon now, WILL be tested. When Dave & I
first got the pc532 going (when it was a wirewrap version) we got MON16
running without any DRAM at all. A neat trick (in my opinion) was that we
did a read (ie caused the data to be cached, since the 32532 will only cache
on a read reference) of the data space that MON16 uses, then locked the data
cache - zap - instant fast ram! So, we could use MON16 to read and write
memory/ports etc without even having any dram in the board, in fact I hadn't
even wired it up yet. I think one of the essential things that will be in
the EPROM is a self test that starts off with dram disabled etc... The
design of the pc532 is very very simple (not to belittle the work that went
into it) and as such is simple to debug, there is very little that needs to
work to get the basic cpu running. I will gladly write a theory of
operation/how it all works document in the near future (while I still
remember what it all means..).

any more questions?

-- 
George Scolaro
(try daver!vw25.chips.com!gs)

From owner-pc532%daver@mips.com@bu-it.BU.EDU Wed Dec 13 02:25:07 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
To: pc532@daver.UU.NET
From: Dave Mason <mason%tmsoft%uunet@daver>
Subject: Re: FPU
Organization: TM Software Associates Inc.
Date: 12 Dec 89 15:45:42 EST (Tue)

Yesterday I said:
> ?ken? said:
> > All moot, of course, if you can't get the parts.  I have a copy of
> > a resale price guide from a local NS distributor that shows..
> >     NS32580U-25     $326
> 
> I confirmed this versus US$310 for the 32381.
> 
> I also called Weitek and the small quantity list for the WTL3164 is
> US$890 for 75ns (60ns is $1115).
> 
> Local National office (National Semi Canada Head Office!) doesn't know
> anything (like availability) about any of the chips.  Though Ed Howell
> is trying to track down info for me.

Ed called me back this morning to say that in ?Santa Clara? they have
stock in 30MHz parts for 532,580,381; 25MhZ 381.  The 25MHz 532 is 3
week delivery, and they don't currently make a 25MHz 580.  He said
he'd sell me the 30MHz parts at 25MHz prices (still rather steep).

Could the board be run at 30MHz with faster DRAMs?  I just looked and
70ns rams are about 30% more expensive than 80ns.  George's BOM says
85ns rams, so if you boosted the clock to 30MHz 70ns rams should
work.... ???  Would there be any advantages (or would it even be
possible) to run the processor at 30MHz with wait states for the
memory?

15 MIPS peak/ 10 MIPS sustained makes a good thing (pc532) sound even
better.... but maybe I'm just getting greedy.  Actually, I just want
the best system I can get and I'm certainly willing to spend an extra
$500 to get the extra 20% of performance!  And I'm willing to pay the
extra $900 for 30x FPU performance. $3-4000 for a 15 MIPS/ 15 MFLOPS
processor with memory is definitely a bargain.  That's is the same
general class as a MIPS M/120, which I can tell you is a darned nice
class to be in!  (Among other things its 20-500% faster than the
IBM4381 I sometimes use!)

BTW, I don't think I've said it yet, but definitely count me in for 2
boards (plus associated PALs/PLAs and EPROMs).  Early February
delivery time is fine. 

	../Dave

From owner-pc532%daver@mips.com@bu-it.BU.EDU Wed Dec 13 03:24:33 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
To: pc532@daver
Subject: Re:  TUNIS/Polyx
Date: Tue Dec 12 16:16:58 1989
From: blank%clanhlm@ucscc.UCSC.EDU

	From uucp Tue Dec 12 16:07:41 1989
	>From cad.Berkeley.EDU!ames!mailrus!utai!turing.toronto.edu!funke  Tue Dec 12 16:07:39 1989 remote from ucscc
	Received: by clanhlm.UUCP (smail2.5)
		id AA01139; 12 Dec 89 16:07:39 PST (Tue)
	Received: from cad.Berkeley.EDU by ucscc.UCSC.EDU (5.61/1.35)
		id AA11874; Tue, 12 Dec 89 15:53:32 -0800
	Received: from ames.arc.nasa.gov by cad.Berkeley.EDU (5.58/1.37)
		id AA13392; Tue, 12 Dec 89 15:51:48 PST
	Received: by ames.arc.nasa.gov (5.61/1.2); Tue, 12 Dec 89 15:52:47 -0800
	Received: by mailrus.cc.umich.edu (5.61/1123-0.9)
		id AA24106; Tue, 12 Dec 89 18:44:55 -0500
	Received: from turing.toronto.edu by neat.cs.toronto.edu with SMTP id 2218; Tue, 12 Dec 89 18:30:50 EST
	Received: by turing.toronto.edu id 2704; Tue, 12 Dec 89 18:28:30 EST
	From: Mark Funkenhauser <ucscc!cad.Berkeley.EDU!ames!turing.toronto.edu!funke>
	To: ames!ucbcad!ucscc.UCSC.EDU!clanhlm!blank
	Subject: Re:  TUNIS/Polyx
	Message-Id: <89Dec12.182830est.2704@turing.toronto.edu>
	Date: 	Tue, 12 Dec 89 18:28:25 EST
	
	OS:
	    Tunis and Polyx are both written in Turing Plus.
	    These are research projects completely separate from the language
	    Turing Plus.
	    Each has its own distribution tape (or will when the tapes ever get made!)
	    This tape only has the OS src, no compiler!
	
	    In the past, distribution of TUNIS was available to Universities for
	    teaching purposes but with the new policy that Polyx is freely 
	    distributable, I think I've convinced people to allow TUNIS to be
	    distributed the same way.
	
	    Documentation on TUNIS:
		1. Holt, R.C. "Concurrent Euclid, The UNIX System, and Tunis"
		   Addison Wesley Publishing Co., 1983. 
		   ISBN = 0-201-10694-9
	
		2. "The Tunis Report", CSRI Technical Report, 1986
	
	    I can get you a copy of 2. if you send me your postal address.
		
	
	Compiler:
	    Turing and Turing Plus are written in Turing Plus.
	    Turing is commercially available (binary only).
	    Normally Turing is available for PC version ($90)
	    or sold by the site license for SUN or VAX ($2000).
	
	    Turing Plus is in beta test and is available to educational sites
	    on special trial use only. ($Pricing unknown!)
	    (I would have to get you to talk to Holt Software Associates about that)
	    If it would be any help I could send you some more info on Turing 
	    and Turing Plus (i.e., language spec ...).
	    If you could get someone at the University interested in the compiler
	    it would certainly make getting it a lot easier.
	
	    Turing Plus generates native assembler on Sun's and Vaxes only.
	    The neat thing about TP is that it can generate C instead of assembler.
	    Thus, to port to a new machine, we compile the compiler to C, and then
	    get the remote C compiler to make a new TP compiler.
	    From then on, the new TP compiler runs on the remote system and generates
	    C code.
	    Therefore on anything but Suns and Vaxes, you need a C compiler to get the
	    Turing Plus compiler to work.
	
	    There is a new version of a *FAST* TP compiler in the works
	    which may eventually come out on the PC. This version would only
	    generate C code so it could be used for cross developement to any machine.
	    I don't know when this would be available.
	
	
	Licencing:
	    Probably none for TUNIS or Polyx. Maybe just the standard form
	    saying that these are property of UofT (and remain property of UofT)
	    but can be freely distributable but only for non-profit.
	    And that we offer no support for the src, etc ....
	    ( I don't know the exact details, but I assume the above to be close )
	
	    Turing Plus would be a special case.
	    It would probably only be sold under a site licence (annual licence?)
	    You will have to talk to Holt Software directly on this.
	    ( *I think* that if there were sufficient interest, that a special
	      deal could be arranged - perhaps a binary version that generates
	      C code and runs on the SUN ?.
	      I don't know what position Holt Software will take.
	      Perhaps your only hope is if there is lots of interest from
	      the pc532 grp or if the University has some interest )
	
	
	If you have more questions, let me know.
	Mark Funkenhauser
	


From owner-pc532%daver@mips.com@bu-it.BU.EDU Wed Dec 13 04:46:53 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
X-Mailer: Mail User's Shell (6.2 5/11/88)
To: pc532@daver.UU.NET
Subject: Re: FPU
Date: 12 Dec 89 23:48:24 PST (Tue)
From: george@wombat.UUCP (George Scolaro)

> Could the board be run at 30MHz with faster DRAMs?  I just looked and
> 70ns rams are about 30% more expensive than 80ns.  George's BOM says
> 85ns rams, so if you boosted the clock to 30MHz 70ns rams should
> work.... ???  Would there be any advantages (or would it even be
> possible) to run the processor at 30MHz with wait states for the
> memory?

No, I'm afraid not. The design is very balanced to 25mhz, achieving
the 0 wait state read/write on first access & 1 wait state in burst is
very tight. The worst case margin is a couple of nanoseconds in the
critical paths. Pushing to 30mhz would increase the number of wait states,
definitely 1 on read/write and probably 2 during the burst. The performance
gained by running at 30mhz would be mostly lost via the wait states. The
10 mips sustained at 30mhz is for zero wait states, and experimenting has
shown that each wait state costs you 7% or more. Dhrystone can show up
to a 20% hit per wait state.

Besides, the cost of the 32532+381 would definitely be a lot higher at
30mhz, since you would then be paying for 'el primo parts. Note we are
still hoping that NS will do a good deal with us, and this would probably
be the case on the volume parts not their top of the line stuff.

Dhrystone 2.1 gets 10869 on this board, note this isn't version 1.1 which
gave much higher values (due to cheating optimizing compilers). Our 25mhz
compaq 386's (with 64k cache) get around 6-7000 dhrystones. Note: Dhrystone
is very very memory bandwidth sensitive, this is where wait states really
hurt performance a lot.

Note some more numbers to place the pc532 with regard to other systems:

Cray 2 gets	9375 - 13043 (new compiler)
Aeon (532)	9998
Encore (532)	11117 - 11223
Sun 4/280	10889
Vax 8700	10791 - 11082
Amdahl 5990-700 gets 91463/cpu


> 15 MIPS peak/ 10 MIPS sustained makes a good thing (pc532) sound even
> better.... but maybe I'm just getting greedy.  Actually, I just want

Yes you definitely are, but then we all are. We jiggled the design for a
long time (I started designing the pc532 last year around April and had a
wirewrap prototype running around June or so of '88), so the choice of 25mhz
is based on a lot of design tradeoffs. Besides, you wouldn't really notice a
20% (less the wait state loss) performance difference, it would be like
comparing an 8mhz 286 to a 10mhz 286. If you want to try and push to 30mhz,
you can change the pal equations, get faster memory, get faster NS parts and
use 7.5 ns PALs and it might all work (I'll leave this as an exercise for the
interested reader...), but I'm happy to let it sit at 25mhz, the parts are a
lot cheaper!

> BTW, I don't think I've said it yet, but definitely count me in for 2
> boards (plus associated PALs/PLAs and EPROMs).  Early February
> delivery time is fine. 

Fine, you're on the list.

Note: 1 nanosecond is a short piece of wire.

best regards,

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com@bu-it.BU.EDU Wed Dec 13 08:41:15 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Subject: RE: Keep it CHEAP
To: pc532%tarpit@daver.uu.NET
Date: Wed, 13 Dec 89 3:35:31 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]


[In the message entitled "Keep it CHEAP!" on Dec 12, 10:13, Jerry Callen writes:]
> 
> Dave, do you have any idea what a complete system is going to come in at?
> Here are my own plucked-from-the-air guestimates...
> 
> PCB				$215
> parts				$400
> memory (4 megs)			$400
> SCSI drive (about 100 meg)	$1000
> case+power supply		$150
> floppy drive			$100
> 			      --------
> 				$2265

[ Dave Rand responds ]
> You are pretty close (perhaps a bit low on the case). The disk drive
> is nearly spot on - I saw a 150 (?) meg SCSI drive a Computer Surplus
> for $1200.

You might want to get on the mailing list of Corporate Systems Center,
730 N. Pastoria Ave. Sunnyvale, CA 94086  (408) 737-7312.  They generally
have ESDI and SCSI pulled or factory refurbished drives.  There typical
price is $695 for 150 Mbytes to $1295 for 320Mbytes.  I have purchased
several items from them and have had no bad experiences.  There stock
turns over fast so keep watching.  Also periodicly ask for a list of
disks in stock.  Low quantity items may not appear in there periodic
catalog.   Also misc.forsale can be a good source.  The key is to
be patient and keep a sharp eye.

Best regards,
johnc


From owner-pc532%daver@mips.com@bu-it.BU.EDU Wed Dec 13 10:40:17 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: Jukka Virtanen <jtv@kampi.hut.fi>
To: pc532@daver
Subject: EMU machine (i860 board for the pc532)
Date: 	Wed, 13 Dec 89 17:10:29 EET


	Here is a description of one card we might design. It will
	be quite expensive, but should be fast. It may also be connected
	to the PC532, and it can act as a display controller. This is
	the reason why I sent this to the list.

	When the design is done, it will be made available for everybody.

Keywords: EMU, i860, RISC, MC68302, SCSI, IMS 6300, PC532, GNU, AT-BUS

	All Comments Welcome!

	If you think that the pc532 mailing list is interested
	in your comments, please send them there.

	Otherwise send them to: jtv@hut.fi

	I can also send a short description of the i860, in case you
	want to know something about the processor.

					Juki

Disclaimer:

	This paper describes something that does not yet exist,
	and it is possible that it will never exist. However,
	we have some interest to build this board, and maybe
	we can even allocate time to do it. You never can tell...

	Here is the description (maybe too long):
				
Version:       EMU-i860-0.10
Last modified: Wed Dec 13 17:03:21 1989
By:	       Juki

Authors:       Jukka Virtanen   <jtv@hut.fi>
               Petri Alhola	<petri@digiw.fi>


	    Copyright (C) 1989 by Jukka Virtanen & Petri Alhola


			 The EMU machine
			 ===============


Abstract

	We are implementing a freely available high performance computer
	design for general usage. All documents, schemas, PAL equations
	and possible LCA prom contents are released under the GNU copyright
	or some similar concept.

	The design is an Intel 80860 RISC based board that uses an
	AT-bus computer, like any 80386 PC, as an I/O processor.
	The board also contains a SCSI-bus and a MC68302 single chip
	processor for I/O handling.

	The primary reason for us doing this project is simply to
	build ourselves computers. By publishing the documents we wish
	to raise the level of standard computing environment and to
	challenge others to improve our work - for the benefit of the
	user community.


Hardware goals
	
	The EMU machine is a PC-AT bus card that contains the Intel
	80860 RISC processor. Main memory consists of one or two banks
	of 64 bit wide memory with byte parity checks.  One bank is
	either 8 MB or 32 MB depending of the size of the DRAM modules
	used (1 Mbit * 9 SIMs or 4 Mbit * 9 SIMs are allowed) thus
	making the total memory size 8, 16, 32 or 64 MB on the processor
	board. Both banks have to have the same kind of SIMs.

	Other features include 2 MB Video RAMs and an IMS6300 video
	controller with RGB and video outputs, 256 KB of triple ported
	static RAM for I/O buffers and command lists, boot EPROM and a
	MC68302 single chip processor that contains fast UARTs,
	timers, DMA channels and a MC68000 compatible processor for
	handling all this.
	
	In addition to the industry standard PC-AT bus the board
	includes an DP8490 SCSI controller to implement a multimaster
	bus capable of transferring 3.8 Mbytes/second. Mainly this
	is meant to connect the EMU machine to the PC532 system,
	but it can also be used for mass storage devices.

	The board is build so that it will work with 33, 40 and 50 MHz
	versions of the processor. If possible, the slower processor
	versions are made to run without wait states on non-interleaved
	main memory. It is not yet clear if this is possible, it depends
	of both the processor and DRAM timings. (It may be possible
	because the processor supports three outstanding bus cycles
	simultaneously, and the NENE-pin, which informs if the address
	is on the same ram page than the previous address.)

	All this doesn't need to be present on the board, it is our
	intention to make the board configurable so that all
	unnecessary stuff can be left out. This includes the video,
	SCSI-bus and the AT-bus. It may be that you can not drop the
	MC68302 out without serious side effects.

	So one may choose the minimum configuration that is suitable for a
	particular purpose.

	It may also be that we are not able to pack all this to the
	AT-bus card, so it may be that we have to use some kind of a
	sandwich card to survive. It is even likely that we will have
	to use some surface mountable devices to be able to save
	space, but you *can* solder them by hand. Just DON'T PANIC.


About the project

	When Richard Stallman (RMS) started the GNU project he wanted to
	write good software that people could use and share with other
	people without the usual licensing politics. Also since RMS
	writes first class software that is worth studying, he and the
	other GNU software writers will teach and encourage other people
	to write good programs.  This principle has spread around the
	world and more and more free software is being written
	everywhere either under the GNU license or otherwise.

	At the time of this writing one very interesting freely
	available computer board was designed by George Scolaro && Dave
	Rand featuring the NS32532 chip set and a SCSI-bus used as a
	multiprocessor bus at 3.8 Mbytes/second. It is in fact so
	interesting that we think we should interface the EMU machine
	to the PC532 system.

	We would like to contribute the EMU machine design to the user
	community and hope to see that people who have the knowledge
	would design more and more advanced systems in software and in
	hardware to build a tool we all like to see: an affordable
	high performance computer with a freely available operating
	system.

	All documents produced by this project will be published
	so that people can build these cards and use them
	in their favourite environment with minimal (?) costs.

	When Intel announced the i860 RISC chip in February the local
	Intel distributor, Fintronic in Finland, had the datasheets when
	I asked them. They also provided other helpful information,
	such as the programmers reference manual. Intel has also been
	very helpful with providing information and a sample i860.

	Since the chip,	according to Intel prochures, seemed quite
	impressive and the architecture looked interesting, I thought
	that maybe it would be nice to evaluate it. However, since
	it's so new there are no cheap commercial boards available for
	the processor. To my knowledge, Intel will not make their own
	i860 board commercially available. At the time of this
	writing, there exists one PC-AT board with i860, but that is
	far too expensive for Joe "Random" User to buy it. Please
	notice that `cheap' in this context is a relative issue.


Personel

	The EMU card is primarily designed by Petri Alhola and
	the author, Jukka Virtanen. Petri has been designing hardware
	for several years (mostly Motorola based systems, with 68020 &
	68030 VME boards). I, not being so experienced in hardware
	design, am doing some secondary stuff, like the LCA designs
	for the buses, arbitration and SRAM interfaces.  So, Petri is
	mainly trying to keep the board fast and I am helping it to
	communicate with the outside world.
	
	We hope several other people will participate in this project
	inside Helsinki University of Technology and elsewhere, but it
	is too early to tell.


Hardware

	We decided to build a card for the PC-AT bus that is simple
	enough it should not be too hard to implement and it would have
	the possibility to utilize the existing I/O system of the widely
	spread PC machines. On the other hand, we thought that it is not
	fun to design a board with no challenge, so we did choose the
	following features. I did not yet even try to guess the price
	of the components, but let's hope you can afford it if you
	like it enough.

	First of all the board should contain the i860. We decided to
	split the memory in two parts, the CPU main memory and I/O
	buffer memory.  The latter is arbitrated between three
	clients. This split is done because at 40 MHz the pipelined
	i860 external bus bandwidth is about 160 MB/s, making it
	intolerable for a slow 16 bit AT-bus with microsecond class
	cycle times to disturb the bus. (Although the burden would be
	reduced due to the internal processor caches).  Since the I/O
	buffer memory is made of static rams it can not be pipelined,
	thus making it unavoidable to add wait states in the processor
	cycle. Each access will need about two wait states in contrast
	to none when using pipelined page mode/static column dynamic
	rams. The i860 is the only one that can access the main memory.

	Since the AT-bus and the SCSI-bus used for external accesses
	are relatively slow anyhow, the lack of pipelining should not
	be a performance bottleneck when i860 is reading or writing
	the I/O memory.

	Using static rams is a question of board space, but it is
	likely that the access time of the static rams is made
	configurable for those who require really fast I/O buffer
	accesses.
	
	The I/O-buffer memory is also the only part of the board's
	memory that is mapped to the AT-bus address space for I/O
	operations.  The I/O-buffer address is made configurable so
	that it may be mapped on different portions of the AT address
	space for loosely coupled multiprocessor EMU systems.

	It may be argued that the I/O buffer could be larger, but we
	thought that most of the PC's own memory may be used as second
	level I/O buffer cache for whole disk tracks or whatever. And
	it can be several megabytes.

	The board will contain a MC68302 single chip processor that
	includes UARTs, DMA channels and timers and one Kbyte of
	dual port ram for critical loops/data. It is also software
	compatible with standard MC68000. (I don't have detailed info
	about this chip yet)

	All on board I/O will be handled by the MC68302 to let the
	i860 be happy with other activities. The MC68302 uses part
	of the I/O-memory for its operating system and data area.

	If a data transfer occurs between the AT-bus and the I/O-buffer,
	it may also be controlled by the PC.


Display subsystem

	The video subsystem memory is build with 16 VRAMS (256Kbit*4)
	organized in two 32 bit banks.

	These rams feed the IMS 6300 video controller that generates
	either RGB true colour for 16 million colours (24 bit RGB
	info, used with i860 processor supported 32 bits/pixel size,
	or it can be configured to support monitors with 8 bit pixel
	size. It can also be configured for a colour palette, if true
	colour is not required (with the 8 bit pixels it can show 256
	colours from a palette).

	If the system is configured to use 8 bit pixels it can use
	1600*1200 pixel displays. If 32 bit pixel size is chosen, it
	supports 800*600 display with 16 million colours.

	Normal operation for the video rams is that they are used on
	the IMS side as two interleaved banks of 32 bits wide pixel
	information, and on the processor side they are used as a
	single 64 bits wide pixel memory.

	The video rams can be configured in two separate banks, so it
	can be used for animation (the IMS displays one frame while
	the processor builds up the new one in the other buffer). In
	this mode, the resolution drops in half of the above figures,
	being at the level of a colour TV screen.

	The AT-bus interface also traps the address of some registers
	for the PC standard M6845 (MDA) display controller thus making
	it possible to emulate the simplest PC standard display with
	software on the EMU machine console while the system boots.
	(What the heck, I know nothing about PCs!)

	The asynchronous ports in the MC68302 may be used as a
	keyboard and mouse interface for the computer.

	It should also be possible to use the keyboard/mouse interface on
	the AT/PC532, if you think that this board should not handle this
	stuff.
	

Buses

	The board will contain an industry standard AT-bus interface
	and a SCSI-bus for communicating with other systems or in a
	minimal configuration it can act as a mass storage channel.

	There will be bus connectors for an industry standard AT-bus
	and on the other edge of the board there will be an XT-bus
	connector with SCSI signals, as required by the PC532. So,
	when the board is on AT-bus you are still able to use the
	SCSI-bus with a cable (i.e. you can connect it to both the AT
	and PC532) or you can directly connect it to the PC532 in
	which case you propably don't need the AT-bus at all.


The arbiter & interrupt handling

	The arbiter needs to arbitrate the accesses for the I/O buffer
	memory between three clients: the i860, AT-bus and the SCSI-bus.

	On simultaneous requests the arbiter grants access to the I/O
	memory in the following order: AT-bus, MC68302, and i860.
	The processors are able to lock the memory during critical
	functions.

	The interrupt sources on the board are few, since the MC68302
	takes care of it's internal devices and the SCSI bus controller.
	We will include a real time clock and some form of a 100 Hz
	clock interrupt for the i860.

	The arbiter and bus controllers are designed with PALs
	or with one Xilinx gate array, whichever takes less
	space.


Software concept

	The system will be based on message passing software.

	Part of the I/O buffer memory acts as a command list space and
	it is interpreted by both of the processor and the AT-bus
	side.  The i860 does not care about the physical format of the
	system, it just expects some basic services to be available
	(like disks, ethernet etc.), and issues commands to use these
	services whenever it needs to. The MC68302 takes care of the
	I/O devices on the EMU machine, and so it needs some small
	multitasking kernel. It also scans the i860 command lists and
	informs the main processor when the requests are completed. By
	this method it does not matter much what is running on the
	other side of the AT-bus or SCSI-bus whichever is used. It may
	be a PC532, a 386 with Unix, a 286 with DOS or whatever you
	like as long as there is a way to connect there and it speaks
	the correct protocol. It is likely that we will concentrate on
	software running UNIX or Minix or Amoeba.

	The first opsys ported to the board will propably be the Minix
	operating system, since there is some work being done here at
	HUT to port it to i386, and since the memory management of
	i860 and i386 are practicaly identical, the port should not be
	too difficult. MINIX is propably the one used in the PC532
	project. We'll see.

	Due to some amusing export restrictions we don't yet have the
	CMU's MACH kernel at HUT. However, it is likely that the
	restrictions are temporary, and once we get it, it will
	propably be the system we want to use before the GNU operating
	system exists. (Which is also likely to be based on the MACH
	kernel).

	One newly appeared candidate is the Amoeba kernel. We have to
	study this possibility more before we can say much of it.


Software tools

	Most of all we need a good C compiler, for both the I/O server
	side and the i860 board. Almost by magic, the GNU CC (from
	test release 1.35.96 up) supports each of i860, i386, MC68000
	and the NS-32000 family processors so it can be used for
	programming the whole system.

	I am also porting the GNU Assembler and linker for the i860.
	Both of these already support the i386.

	The Gnu Debugger (GDB) also runs on all of the above (an old
	i860 GDB is available from Intel. If not, I will port it).


More information

	If you have any questions about this project, I could try to
	help you out. Please do not ask if it's ready yet, we will let
	you know. All comments appreciated. Thanks.


				Jukka Virtanen

				Computing Centre
				Helsinki University of Technology
				02150 Espoo
				Finland

				Email:	jtv@hut.fi

Additional suggestions for the EMU machine hardware from various persons:

	Include the new Intel 82596 Ethernet controller on the CPU board.
	Should we also consider of allowing it to directly access the
	i860 main memory? Or should we hook up something more affordable?

	Include a white noise source to be able to generate true random
	numbers. These are usable i.e. in secure communications with the
	one time pad concept.

	Include a transputer TRAM interface socket on the board.  This
	allows (?) multiprocessor connections with the four transputer
	serial links. Additional thought should be given whether or not
	these links should be build with fiber optics.

	Include ECC logic in the DRAM interface :-)

From owner-pc532%daver@mips.com@bu-it.BU.EDU Wed Dec 13 12:12:15 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Subject: Re: assembling the pc532
To: pc532@daver.UU.NET
Date: Wed, 13 Dec 89 8:31:10 MST
X-Mailer: ELM [version 2.2 PL14]
From: sverre@fesk.seri.gov (Sverre Froyen)

>Any terminal that supports RS232 is fine. Each of the serial channels on
>the pc532 has TX, RX, CTS and RTS. The connectors are 10 pin headers that
>connect to standard PC/AT 10pin-9pin D connectors and are pin compatible.

Is there a reason for not including the modem control lines (DTR,
DSR, and DCD).  Those are real handy for talking to modems, data
switches, etc.
--
Sverre Froyen
INTERNET: sverre@fesk.seri.gov
UUCP:     boulder!fesk!sverre, sunpeaks!seri!fesk!sverre
BITNET:   froyen@csugold.bitnet

From owner-pc532%daver@mips.com@bu-it.BU.EDU Wed Dec 13 12:14:00 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Wed, 13 Dec 89 10:50:30 EST
From: mccalpin@masig3.ocean.fsu.edu (John D. McCalpin)
To: pc532@daver.uu.NET
Subject: fpu performance

Just so no one gets too optimistic on the potential floating-point
performance of the 32580+WTL3164 combination, I should mention the
following things to consider.  I have been working on performance 
characterization of high-performance (vector) floating-point systems
for the last 5 years, so this is based on a fair bit of experience.

On the negative side:

(1) You will not get 12.5 MFLOPS out of the Weitek 3164.  At least
    not over any appreciable time period!  The Alliant mini-supers
    are a good example of disappointing performance from pipelined
    Weitek chips.

    To run pipelined operations in streaming mode (vectors) requires
    two loads and one store for every operation (2 cycles in this case).
    I don't know what the PC532 memory subsytem can deliver, but I
    strongly suspect that it cannot sustain one 32-bit load every
    cycle combined with one 32-bit store every other cycle.
    The situation is correspondingly worse for 64-bit arithmetic.

    George, could you give us an idea of how fast the 32532 can
    grab data from consecutive memory locations and feed it to the
    coprocessor interface?

(2) Code generated for the 32381, while compatible with code generated
    for the 32580+3164, is not likely to be anywhere near optimal
    for the 32580+3164.  It is often quite tricky to interleave
    loads, stores, and address calculations in an optimal way on such
    systems, and the compiler is not likely to do a whiz-bang job of it.

On the positive side:

(3) Even naive code running through a 32580+3164 will be quite a bit
    faster than the same code on a 32381.  Naive LINPACK should jump
    from 400 KFLOPS to about 1 MFLOPS.

(4) It is perfectly legitimate to hand-code the low-level routines in
    LINPACK.  Depending on what kind of FP work you tend to do, this
    can be a big win.  I would guess that you should be able to get 
    more than 2 MFLOPS by hand-coding the SAXPY routine.  If you can
    convince a compiler to inline assembly-language functions, then
    you might be able to do even better.

(5) If you do linear algebra or signal processing, then this combination
    should work very well, since you can isolate your FP code into 
    reusable modules which can then be hand-coded.  If your applications
    are less modular, then you have to rely on compiler smarts, which
    are certain to be disappointing.  On the other hand, you can look
    at this as a great opportunity to hack on the optimizer in the 
    compiler. :-)

From owner-pc532%daver@mips.com@bu-it.BU.EDU Wed Dec 13 12:17:41 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Subject: Auguat Holtite Sockets..
To: pc532%tarpit@daver.uu.NET
Date: Wed, 13 Dec 89 11:28:52 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]


Does anyone have any experience with Augat 'Holtite' solderless sockets ??

The Holtite socket is a contact designed to be press-fit into PCB plated-thru
holes (0.041 +/- .002 finish diameter).  The idea is to convert a plated-thru
hole into a component socket.  The cost is about 7 cents a contact.

Assuming this is a reliable system, this would appear to be a nice
uniform way of socketing all pc532 components which are on a 0.10 grid.

Best regards,
johnc


From owner-pc532%daver@mips.com@bu-it.BU.EDU Wed Dec 13 12:18:35 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
X-Mailer: Mail User's Shell (6.2 5/11/88)
To: pc532@daver.UU.NET
Subject: Re: assembling the pc532
Date: 13 Dec 89 08:29:23 PST (Wed)
From: george@wombat.UUCP (George Scolaro)

[In the message entitled "Re: assembling the pc532" on Dec 13,  8:31, Sverre Froyen writes:]
> 
> >Any terminal that supports RS232 is fine. Each of the serial channels on
> >the pc532 has TX, RX, CTS and RTS. The connectors are 10 pin headers that
> >connect to standard PC/AT 10pin-9pin D connectors and are pin compatible.
> 
> Is there a reason for not including the modem control lines (DTR,
> DSR, and DCD).  Those are real handy for talking to modems, data
> switches, etc.

Arghh, yes pc532 DOES have DCD and DTR in addition to TX,RX,CTS and RTS
which is all you need to talk to a modem, esp.  a telebit trailblazer.
I was too quick to respond without checking the schematics first, I'm
beginning to forget the features that the board has. It obviously must
have all the prerequisite lines for full modem control, since that was
the primary reason for doing the pc532 (Dave wanted a fast news/mail
system! with lots of trailblazers).

regards,

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com@bu-it.BU.EDU Wed Dec 13 12:19:44 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
X-Mailer: Mail User's Shell (6.2 5/11/88)
To: pc532@daver.UU.NET
Subject: Re: fpu performance
Date: 13 Dec 89 08:46:43 PST (Wed)
From: george@wombat.UUCP (George Scolaro)

[In the message entitled "fpu performance" on Dec 13, 10:50, John D. McCalpin writes:]
> 
> Just so no one gets too optimistic on the potential floating-point
> performance of the 32580+WTL3164 combination, I should mention the
> following things to consider.  I have been working on performance 
> characterization of high-performance (vector) floating-point systems
> for the last 5 years, so this is based on a fair bit of experience.
> 
> On the negative side:
> 
>     To run pipelined operations in streaming mode (vectors) requires
>     two loads and one store for every operation (2 cycles in this case).
>     I don't know what the PC532 memory subsytem can deliver, but I
>     strongly suspect that it cannot sustain one 32-bit load every
>     cycle combined with one 32-bit store every other cycle.
>     The situation is correspondingly worse for 64-bit arithmetic.
> 
>     George, could you give us an idea of how fast the 32532 can
>     grab data from consecutive memory locations and feed it to the
>     coprocessor interface?

The pc532 system will read or write data (when in page) every 2 clocks, ie
32bits/2 clocks. I have looked (quickly) through the 580 data sheet and it
claims that the WTL chip can be run in 2 cycle or 3 cycle mode for taking up
the latency. The data sheet shows 2 clock times for many instruction without
pipe breakage, so I assume the 1 clock/op is not used in this scheme.  Again
I assume that the 15 mflops peak = 30mhz/2 clocks/op? The 580 has a bunch of
fifos internally to hold operands etc to try and keep the 580 pipe going,
the 580 also translates the input stream into loads/stores for the WTL
chip.  NS would be best to comment on the sustained performance (which is
obviously very dependent on compiler technology as well as the user code).

P.S. Just 'cos I looked at the 580 data sheet doesn't mean I'm putting it on!

regards,

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com@bu-it.BU.EDU Wed Dec 13 12:21:57 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
X-Mailer: Mail User's Shell (6.2 5/11/88)
To: pc532@daver.UU.NET
Subject: Re: Auguat Holtite Sockets..
Date: 13 Dec 89 08:53:33 PST (Wed)
From: george@wombat.UUCP (George Scolaro)

[In the message entitled "Auguat Holtite Sockets.." on Dec 13, 11:28, John L. Connin writes:]
> 
> 
> Does anyone have any experience with Augat 'Holtite' solderless sockets ??

No, but I have seen them used on hard disk controllers (the one on the
disk drive itself). They seem to be used when low profile is a very
important consideration.
> 
> The Holtite socket is a contact designed to be press-fit into PCB plated-thru
> holes (0.041 +/- .002 finish diameter).  The idea is to convert a plated-thru
> hole into a component socket.  The cost is about 7 cents a contact.

The pc532 hole diameters at 0.038 inch (+/- the pcb house). This of
course could be increased a couple of thou.
 
> Assuming this is a reliable system, this would appear to be a nice
> uniform way of socketing all pc532 components which are on a 0.10 grid.

Well, not all, the plcc devices would have trouble plugging in! Also
I'm not sure how well the round pins on the 532/381 PGA packages would
work? Of course the SIMMs are generally available without tails, and
I prefer them that way, since they are more rigidly held in a socket.
Regarding reliability: I assume it must work fine, since disk drives
tend to live in dirt attracting environments (due to their fans etc).

> Best regards,
> johnc

besides, has the spirit of hand soldering totally died away.....
If you have some samples I could try and push them into one of the
blank boards I have and see how well it works.

regards,


-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com@bu-it.BU.EDU Wed Dec 13 13:00:10 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: Anthony J Stieber <astieber@csd4.csd.uwm.edu>
Subject: SysV.4 Source Licenceing
To: pc532@daver.uu.NET
Date: Wed, 13 Dec 89 11:19:23 CDT
X-Mailer: ELM [version 2.2 PL10]

The AT&T Licenseing number is 1-800-828-8649.

I called them up, source code $100,000 on 9 track or data cartridge in
tar or cpio format.  This is not an upgrade but is the actual price
for the code for businesses.  More information is going to be sent
to me, I'll forward it as it get it.  The binary-redistribution 
license is $25,000.  There are probably royalty fee as well.
-- 
<-:(= Tony Stieber	astieber@csd4.csd.uwm.edu   att!uwm!uwmcsd4!astieber

From owner-pc532%daver@mips.com@bu-it.BU.EDU Wed Dec 13 16:25:08 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Wed, 13 Dec 89 12:12:25 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: gs@vw25.chips.com (George Scolaro)
To: pc532@daver
Subject: 30mhz 532

Ok, what I need are some specs for 70ns fast page mode DRAM SIMMs.

What is:

	tRP		(ras precharge time)
	tCAC		(column access time)
	tAA		(access time from column address)
	tCP		(cas precharge time)
	tRAH		(row address hold time)

30mhz 0 wait on read, 0 wait on write (same as current 25 mhz pc532) might
work if (with 0 or -1ns worst case margin... the parity is real hairy):

	tRP < 66ns
	tCAC < 15ns
	tCP < 16ns
	tAA < 40ns

these are the most critical parameters. Of course a 7.5ns 16r8 and 20l8 are
needed also.

Of course this is for the few people that want to pay the premium....

regards,

-- 
George Scolaro
(try daver!vw25.chips.com!gs)

From owner-pc532%daver@mips.com@bu-it.BU.EDU Wed Dec 13 16:27:20 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Wed, 13 Dec 89 12:47 PST
From: dlr@daver.uu.net (Dave Rand)
To: pc532@daver.uu.net
Subject: Assembly people wanted

I would like to hear from a few people that would like to assemble some
pc532's. Some of the folks on the list would prefer to obtain pre-soldered
boards, and would not mind paying a bit extra for this. This may be
a way for you to earn enough extra money to pay for a pcb for yourself :-)

Please mail directly to dlr@daver.uu.net, or failing that, try 
dlr%daver@uunet.uu.net.

Also, some people have noticed that the S/N ratio of the list is getting
worse, and would like the list moderated. I believe that the noise is
good - more people expressing their opinions. But in any event, sometime
in January, I would like to start a mainstream USENET group. Probably
alt.sys.pc532 or some such. Don't send your votes, yet! We would like
to get the pcb's out before we do that...

As always, if you have questions that you feel would not interest the
rest of the list, you may address them to us directy. For hardware
questions, try george@wombat.UUCP (daver!wombat!george). There is
an alias for george on daver.uu.net too, so you can try that.

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

From owner-pc532%daver@mips.com@bu-it.BU.EDU Wed Dec 13 18:13:11 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Wed, 13 Dec 89 14:00 MST
From: rwa@cs.AthabascaU.CA (Ross Alexander)
To: pc532@daver.UU.NET
Subject: video card (was: AMD 95C60)

>	Should it talk X, or something else (I vote for something else.
>	X is a bandwidth hog).

We have bandwidth coming out our eyeballs.  Let it talk X, it will
simplify the debugging a whole bunch.  KISS, and that includes not
reinventing the wheel ;-).  BTW, I see in another group (comp.arch for
the usenetters) some interesting figures on X bandwidth requirements.
Pretty modest; only a few Kbytes/second for much representative work.
We can get the bandwidth way down if there's enough mem on the card to
run a cacheing server.  Say 2 to 4 megs (it doesn't need to be VRAM,
klunky old slow DRAM is fine for X cache).

	Ross

From owner-pc532%daver@mips.com@bu-it.BU.EDU Wed Dec 13 21:52:03 1989
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
Posted-Date: Wed, 13 Dec 89 13:27:07 CST
Date: Wed, 13 Dec 89 13:27:07 CST
From: neil@skatter.USask.ca
Subject: low cost committment
To: pc532@daver.UU.NET
Cc: neil@SASK.USask.ca

I am interested in one board if the 32XXX chips can be obtained for
$400 or so. If RAM is included, GREAT! At $1000 for the National 
chips I would have to reconsider, but probably would not want a board.

There has been some talk of connecting a PC to the pc532 using a PC SCSI
adapter. The intent is to use the PC's peripherals and thereby
reduce costs. Can we use a low cost SCSI hard drive controller, such
as the $75 units from Jameco or JDR? Or would this new controller 
have to replace the normal hard drive/floppy drive controller and 
thereby eliminate the main components I would have wanted to access?

I want to minimize the cost of my system. One approach is to minimize
the size of the hard drive. A 100 Megabyte drive would be nice, but
20 Megabyte drives are more affordable. I would rather spend the extra
money on graphics or other hardware. For those of you who are familiar
with Minix, how much space is needed for the operating system? With 
4 or 8 megabytes of RAM available, how much performance will be lost 
using a slow hard drive?

How do Minix licencing restrictions apply to modified versions of the 
software? Can they be freely distributed to people who have copies of
Tannenbaum's book? Copies of the original programs? Also, will you make
copies of Culbert's version available before the port is complete?

Neil

From owner-pc532%daver@mips.com@bu-it.BU.EDU Wed Dec 13 23:26:32 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Wed, 13 Dec 89 19:39:55 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: dlr@daver (Dave Rand)
To: pc532@daver.UU.NET
Subject: Re: low cost committment

[In the message entitled "low cost committment" on Dec 13, 13:27, uunet!skatter.USask.ca!neil writes:]
> 
> I am interested in one board if the 32XXX chips can be obtained for
> $400 or so. If RAM is included, GREAT!

Since the ram is currently $320, I assume you meant ":-)"

If you are really on a tight budget, please remember that you
need not populate everything. The FPU, for example, could come
later. 3 of the serial chips (6 ports) don't need to be there, etc.

> 
> There has been some talk of connecting a PC to the pc532 using a PC SCSI
> adapter. The intent is to use the PC's peripherals and thereby
> reduce costs. Can we use a low cost SCSI hard drive controller, such

You should be able to do this. You could also build one for a fair
bit cheaper - $8.95 for the DP8490, some glue, a spare IBM-PC Wire Wrap
card... (Hint: Someone needs to design this board. Anyone game?)

As long as the address of the SCSI card does not conflict with existing
peripherals, there should be no problem with accessing your pc's hard
disk, etc.


> How do Minix licencing restrictions apply to modified versions of the 
> software? Can they be freely distributed to people who have copies of
> Tannenbaum's book? Copies of the original programs? Also, will you make
> copies of Culbert's version available before the port is complete?
> 

The word I have is that you have to have purchased the original programs.
I'm not sure how to validate this, and I don't want to spread around
copies without the validation. If you want to get Bruce Culberts' version
of the Minix port, you can get a copy from him - I don't expect the port
to take too long. I managed to get his gcc version up and running in
a few hours, and I expect to have significant sections running this
weekend. Bruce ballparked the porting time at 2 full-time days, and
I've already put in at least 1/4th of that...

I really expect to have Minix running this weekend.

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

From owner-pc532%daver@mips.com@bu-it.BU.EDU Thu Dec 14 05:59:17 1989
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
From: Jukka Virtanen <jtv@kampi.hut.fi>
To: pc532@daver.uu.NET
Subject: Emu machine IMS 6300 should be IMS G300
Date: 	Thu, 14 Dec 89 08:09:13 EET


	Sorry, my pattern matcher failed. The IMS 6300 video
	controller's real name is:

		IMS G300 colour video controller

	(See Inmos "The Graphics Databook, first edition 1989",
	 page 73 for a closer view)

					Juki
					jtv@hut.fi

	Ps. I now have the MC68302 databooks. Looks nice!


From owner-pc532%daver@mips.com@bu-it.BU.EDU Thu Dec 14 09:36:45 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Thu, 14 Dec 89 13:12:34 +0100
From: P{r Emanuelsson <pell@isy.liu.se>
To: pc532@daver
Subject: Re:  low cost committment

>Also, will you make
>copies of Culbert's version available before the port is complete?

I have sent Dave money for disks etc, and if he puts Bruce's original sources
on them, I will make it available by FTP. I have an old 16032 board that
needs a better OS.

Since it's the time of year when mail flows even more slowly than usual, I
expect it to take several weeks before anything happens. I will announce
the availability when I have it.

     /Pell

From owner-pc532%daver@mips.com@bu-it.BU.EDU Thu Dec 14 12:29:55 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
To: pc532@daver.uu.NET
Subject: 56, not 64 SCSI devices
Date: 14 Dec 89 09:34:04 CST (Thu)
From: john@starfire.MN.ORG

From: daver!uunet!mea.utu.fi!mea (Matti Aarnio)
Subject: Re: I/O cards
To: pc532@daver
Date: Tue, 12 Dec 89 10:09:58 EET

[Matti Aarnio <mea@mea.utu.fi> writes:]
>  There have been some others lately to use this idea, don't remember who it
>was.  Anyway, I did recently a search for SCSI disks which I need on one
>project far more than can be put into Sun SCSI adapter. (read: two dozens)
>How ?  Simple:  Let there be 4 controllers, each having up to 8 LUNs.
>Problem: Very few disk manufacturers give controllers for their disks that
>are able to handle more than one physical disk.

LUNs have been a part of SCSI from the early days of the formation of the
committee.  They were used more back then, when SCSI controllers were NOT
imbedded.  These controllers are often called bridge controllers.  The
previous line of Sun workstations (3/1xx, 3/2xx and 4/2xx) used an Adaptec
or Emulex bridge controller to talk SCSI to ST506 disks (some might have
used ESDI) in the top of the workstation (the "shoebox").

OMTI, Emulex, Adaptec, Fujitsu and others make SCSI bridge controllers.
The bridge controller itself has the Target ID, and each of the devices it
controls has a LUN (0-7 also).  These controllers RARELY appear at the
end-user market, but are available in the OEM realm.  In fact, Fujitsu
may not sell them apart from their own disk subsystems -- I'm not sure.

>On the other hand, there seems to be devices at market, which should be able
>to act as controller with up to 8 LUNs behind it, which it translates to
>8 controllers, each with single LUN... (A brief glimpse on some advertisement,
>not exactly sure what they did sell.)

>  How 64 ?  Lets see:  8 controllers, 8 LUNS...

Nope, nope, nope.  You are forgetting that each HBA on the bus (probably
only 1 in our case) must ALSO have a target ID, and since the HBA
a. is not considered a "device" for our purposes and b. does not support
LUNs (why would it?), that means only 7 target IDs remain for 7 times
8 for a maximum of 56 "devices."  HOWEVER, I have never seen a bridge
controller that actually support 8 LUNs except SMD bridges.  2, 3, and
4 are much more common (3 being for "unlike" LUNs -- 1 tape and 2 disks).

There are other considerations here.  Even with disconnect/reselect,
you can't really use the bandwidth of 32 disk devices on one SCSI bus.
The HBA has a certain command overhead, and there are the protocol delays
(negotiations count up!), so that even 16 disk devices are more than a
synchronous SCSI can really feed.  If your point is to have a disk farm
with lots of data that need not all be in use at once, this is a good,
cheap way to go.  If you want to have huge active data sets, you should
think about limiting each HBA to about 4 disk devices and one tape device.
I'm sorry, but that's just the way it works out.  Even at four, you will
see some performance degradation in each device as compared to operating
it without the others in use.  Furthermore, not all bridge controllers
support n-way command interleave, so that can mean that the distribution
of your data sets between target IDs and LUNs can impact your performance
bunches.

Let me state that a little more clearly.  As long as you only plan to
have transfers in progress or pending for 1, 2 or 3 fast devices on the SCSI
bus, go ahead and put as many devices out there as you like.  The inactive
devices will not interfere with the active ones.  If you actually might be
talking to boocoo devices at once, split them up amoung SCSI busses.

Of course, if you get CDC (Imprimis, whatever) Sabre SCSI drives at 1.2Gb
each, maybe you don't really need more than 4!  Add an Exebyte 8mm
tape drive, and you're all set.  (DON'T get DAT 4mm drives -- they don't
work right yet, and they don't cache enough, and they don't decouple
>From the bus decently -- they are SLOW in Unix applications, when they
work at all, and don't eat your tape.)
--
		   John Lind, Starfire Consulting Services
E-mail: john@starfire.MN.ORG		USnail: PO Box 13001, Mpls MN  55414

From owner-pc532%daver@mips.com@bu-it.BU.EDU Thu Dec 14 14:14:42 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Subject: RE: low cost commitment
To: pc532%tarpit@daver.uu.NET
Date: Thu, 14 Dec 89 11:18:44 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]


[ in "low cost committment" neil writes ]

> There has been some talk of connecting a PC to the pc532 using a PC SCSI
> adapter. The intent is to use the PC's peripherals and thereby
> reduce costs. Can we use a low cost SCSI hard drive controller, such
> as the $75 units from Jameco or JDR? Or would this new controller
> have to replace the normal hard drive/floppy drive controller and
> thereby eliminate the main components I would have wanted to access?

If you are referring to the Future Domain / Seagate ST01 and ST02, the
simple answer is NO.  This controller is an initiator only, it can not
act as a target.  In other words if used in a PC to connect to a pc532,
the PC will not be able to respond to requests initiated by the pc532.

This is a hardware limitation of the design which can not be circumvented
by software.  As designed it can only act as a SCSI host adapter for
connecting to non-initiating SCSI block devices.

Can anyone recommend a readily available inexpensive PC SCSI adapter that 
can act as either an initiator or target ??

Best regards,
johnc


From owner-pc532%daver@mips.com@bu-it.BU.EDU Thu Dec 14 14:18:20 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: Jukka Virtanen <jtv@kampi.hut.fi>
To: pc532@daver.uu.NET
Subject: Tanenbaum's reply about Amoeba availability
Date: 	Thu, 14 Dec 89 19:17:36 EET


	I asked Andy Tanenbaum about Amoeba availability for
	the pc532 group, also for those not in universities.

	Here is a copy of his reply:

>From hp4nl.nluug.nl!cs.vu.nl!ast Thu Dec 14 16:53:02 1989
Date:   Thu, 14 Dec 89 16:43:38 EET
From:   Andy Tanenbaum <ast@cs.vu.nl>
To:     Jukka Virtanen <jtv@kampi.hut.fi>
Subject:  Re:  Amoeba

Right now the only machines we support are the Sun-3 and Microvax II.
We will have a tape ready for distribution to universities for a small
fee early in 1990.  If you want to use this to port Amoeba to the 532 or 860,
we have no objection of course, but we have no manpower ourselves.

Andy Tanenbaum

From owner-pc532%daver@mips.com@bu-it.BU.EDU Thu Dec 14 14:18:41 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Subject: SCSI Overview.
To: pc532%tarpit@daver.uu.NET
Date: Thu, 14 Dec 89 12:13:48 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]


Warning: this message may be judged to contain noise..

Though oriented to PC hardware running MSDOS or Unix, the following 
comp.periphs article may be of interest to those not familar
with SCSI. 

If you are considering buying a SCSI drive, the section "Recommended
products to avoid" at the end of the article may be of interest.

BTW: I assume the 'Cast' drives currently being pushed by the Computer
Surplus Store are the same as mentioned in "Recommended products to avoid".

best regards,
johnc

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

From: neese@adaptex.UUCP
Newsgroups: comp.periphs
Subject: How to choose SCSI
Message-ID: <9700002@adaptex>
Date: 14 Nov 89 23:31:00 GMT
Lines: 258
Nf-ID: #N:adaptex:9700002:000:12910
Nf-From: adaptex.UUCP!neese    Nov 14 17:31:00 1989


The following is inetended for those who may have or are thinking about
purchasing a SCSI subsytem.

THE HOST ADAPTER: THE FIRST PIECE OF THE PUZZLE

  Host adapters come in many flavors.  Some are well supported, others are
not.  Some are intelligent, some are not.

  To decide on the correct host adapter to use is a difficult decision and
one that should not be taken lightly.  Unless you are prepared to continue
investing in other adapters as your systems needs grow, you need to study and
understand the different types of host adapters and the application they are
going to be used in.

  The simplest host adapters are cards that may have an INT13 At BIOS to
support hard drives under MS-DOS.  These host adapters usually have no UNIX
support as it is very difficult to do a device driver that can be made to work
reliably.  Dumb cards such as these usually have timing constraints that make
it almost impossible to have a UNIX driver.

  The next level of host adapter goes to the other extreme.  They are very
intelligent and usually hide the SCSI bus from the operating system.  These
types of adapters have a wide base of support in software, as they can run
in any environment with very little software effort.  They are also expensive
adapters, which may not be needed in the MS-DOS machine.  Indeed, they may be
overkill for a machine that is to be relegated to the DOS environment.

  If you are going to be using MS-DOS and MS-DOS alone, then the low cost
approach is not a bad one.  But if you intend to use UNIX/Novell/OS2, then
the low cost approach will be a poor one.  These operating systems/environments
are all multi-threaded.  That is they can issue more than one command at a
time.  With an intelligent host adapter, this is easily done and managed by
the host adapter.  With a low cost board, the software to do this work must
be driven by the main CPU, which will incur considerable command overhead.

  Of course, there is also the support issue.  You always would like to
avoid the finger pointing that can occur when using products from several
companies, when a bug arises.  This is best done by buying a product that
is supported by the operating system manufacturer.  There are very few
SCSI host adapters supported by the operating systems manufacturers.  You
need to ask them what they will support and what they won't.  A little
planning in this area may solve many potential problems for you.
  
	Questions you should ask:
	a) What operating environment will I be using?
	b) Is the operating environment multi-threaded?
	c) Am I going to be using several operating systems?
	d) Do I care if support is from one operating system vendor?

  
SCSI DEVICES AND MANUFACTURER'S CLAIMED DATA RATES

  Ignore the manufacturer's rated data rates.  They are measured on the SCSI
bus assuming that no data is being transferred to the device buffer from
the media and they also assume the best case data transfer (no disconnects).

To get an idea of how a device might perform, look at the clock rate of
the head.  You will see a range from 7.5 Mhz to 24 Mhz.  Some devices
have multiple clock rates.  These are bit zone recorded devices.  They have
more sectors on the outer tracks than they do on the inner tracks.

  The data rate to the devices buffer is the rate of the clock on the head.
A 7.5Mhz head moves data to the buffer at 750KB/sec and a 24Mhz clock on
the head moves data at 2.4MBytes/sec.

  Data rates to/from the buffer from/to the SCSI bus are regulated by the clock
rate of the dual ported buffer (where applicable).  If the buffer has a 4MHz
clock, then the fastest the data can be shipped to/from the buffer is 4MBytes/
sec, but if data is being shipped to/from the media from/to the buffer, then
the rate that data can move across the SCSI bus is directly impacted.  For
instance, if the drive is putting data into the buffer at 2.0MBytes/sec and the
buffer is a 4MHz part.  The fastest data can be moved to the SCSI bus is
2.0MBytes/sec not 4MBytes/sec.  This, of course, only applies to those devices
that have a dual ported buffer.  How the buffer full/empty ratios are used will
also effect the data rate.

  SCSI devices, for the most part, have programmable buffer full/empty ratios
stored in a mode page of the device.  NOTE:  Not all devices allow a user to
reprogram these parameters.  These parameters affect when the device should and
should not, get on the SCSI bus for a data transfer.  Typically, a SCSI device
will ask for the bus, on a read, when there is at least 1 sector in the data
buffer ready to transfer.  The transfer will start and the device will continue
to put data into the buffer if possible, as data is taken out of the
buffer.  If the buffer falls below the 1 sector limit, then the device will
disconnect from the bus and will not reconnect until the buffer has at least
one sector's worth of information.

	Questions you should ask:
	a) How fast is the dual ported buffer?
	b) What is the clock rate of the heads?
	c) Is the device capable of synchronous transfers?
	d) How is the buffer full/empty ratios calculated and implemented?


TO BUFFER OR NOT TO BUFFER?

  The size of the buffer has a lot to do with the overall performance of the
SCSI device.  Buffer sizes range from 16K to 256K.  If the buffer is not dual
ported, then that implies the device cannot allow data to be moved from/to the
SCSI bus while the HD is moving data to/from the buffer and vice-versa.

  If the buffer is just a buffer to smooth the data transfer, then the size of
the buffer can be small if you have a host adapter capable of moving the data
at the full rate of the SCSI bus.  If the adapter is dumb and cannot move data
very quickly, then a larger buffer is required to minimize the disconnects/
reconnects on the SCSI bus.  In this implementation, the size of the buffer
will not impact nor help performance.  Also, with a dumb adapter you will
find it very difficult to maintain a 1:1 interleave with this type of buffering
scheme.  Typically, this is the poorest performing SCSI device.

  If the device has a read ahead buffer, then sequential accesses will be
much quicker.  Although the more fragmented the file system the worse the
worse the performance.  In this case, the size is dependent on the overall
implementation.  If the read ahead will abort at the end of a track, then the
buffer need not be larger than the largest track on a device.  If the read
ahead is aborted at a cylinder switch, then the buffer size should be large
enough to accommodate the largest cylinder.  For the most part, this is a good
implementation.

  If the device has a read ahead cache buffer, then this, like the read ahead
buffer, will give good sequential accesses, but still poor performance on a
very fragmented filesystem.  As data in the buffer is recoverable, because
this is a cache, some performance gains will be noticed in a multi-user
environment.  The same rules for the read ahead buffer above apply when it
concerns the size of the buffer.  A better performance implementation.

  If the device has a segmented cache buffer, then this will yield the
best performance available in all operating environments.  It must be tunable
so you can match the characteristics of the operating environment.  The size
of the buffer should not be less than 64K for this type of implementation to
be effective,  but it can be as large as the vendor chooses and the bigger
the better.  This is the best performance choice.

	Questions you should ask:
	a) What type of buffer algorithm do you use?  (i.e. read-ahead, cache)
	b) Is the buffer algorithm programmable?
	c) What is the size of the buffer?
	d) What is the clock (or resolution) of the buffer?
	e) Is the buffer dual ported?


SCSI COMMAND OVERHEAD

  SCSI command overhead is a much discussed topic when users opt to go with
SCSI and generally a very heated topic.  In the past, the overhead was very
high (on the order of 3 milli-seconds).  Today SCSI overhead, for the device,
is down to 1 milli-second and less.  Some devices have multiple processors, one
for running the SCSI bus and one for the device electronics.  These type of
devices have less overhead than a single processor device as they can do things
in parallel.  Be aware of the manufacturers specs.  Though they don't lie, they
publish the best case overhead times.  SCSI command overhead, as measured by
the manufacturer, is typically taken from the time a TEST UNIT READY command
takes to complete. The problem with that is this command takes the shortest
path through the vendor's firmware as it does not require any data transfers.

  The best way to measure the overhead for a SCSI device is to issue a write
command and then issue the same command again, to ensure the device is at the
track it should be.  Using a logic analyzer, measure the time from the last
command byte to the ending status phase for the second write command.  Subtract
the data phase of the command and you will have a more believable idea of the
overhead.  The reason you want to use a write command is to eliminate any disk
latency that a read command would generate.

  Measuring overhead from the system level is virtually impossible, as you also
have the host adapter overhead and then the bus and CPU rates come into play.

	Questions you should ask:
	a) What is the SCSI command overhead for your controller?
	b) How is the overhead measured?
	c) Does your device have multiple processors?
	d) What is the clock rate of the processors?


BENCHMARKING MADE EASY??

  Throw away CORETEST, or disregard the seek times and the size of the
request.  Seek times on a SCSI device cannot be measured at the BIOS level
unless the benchmark can be told what physical parameters to use.

  SCSI is a logical block interface and has no physical characteristics.  The
number of heads, sectors, and cylinders at the BIOS level are all incorrect, so
the seek times that virtually all of the benchmark programs use will not yield
accurate seek times.

  You cannot use the manufacturer's seek rate as it is measured at the
mechanical level and not at the SCSI bus level.  To test the seek times, you
almost have to write your own benchmark.  If 'adaptex' was going to be around
I would have a program that would do just that for SCSI devices and post it,
but alas.

  CORETEST also reads the same data over and over again, so a SCSI device that
has a read ahead buffer, will not be accurately measured.

  In order to get a fair idea of the data rates that a SCSI device can yield
requires you to measure data transfers in the following ways:

	1) Sequentially
	2) Random (1/3 stroke, preferred as you can do that at the BIOS level)
	3) Read the same data over and over again.

  Now that will take care of the single-threaded benchmark, but what UNIX/XENIX
and other multi-threaded operating environments?  While none of the current
benchmarks really do a fair job of measuring the correct thing for these
environments, they can yield some useful information.

  With a multi-threaded environment, you should not only consider the average
access time and the data rate, but more importantly.  How does the SCSI
implementation I have chosen effect the overall throughput of my system?  While
in a single-threaded environment most devices will benchmark well, device
characteristics change dramatically in a multi-threaded mode.

  This is due in part to the devices ability to efficiently arbitrate for the
SCSI bus.  Some devices may take as long as 3 milli-seconds to complete an
arbitration cycle, while others take only 1 milli-second.  The only way you
can judge the devices is via a logic analyzer.  You are basically looking
for the overall usage of the SCSI bus.

	Questions you should ask:
	a) How can I measure the average seek time?
	b) What environment will this implementation be used in?
	c) How can I best judge the performance in this environment?


PERSONAL PERFORMANCE RATING

If I had to rate, regardless of capacity, the best performing SCSI devices
that I have used, the list would go:

Quantum		(3 1/2") 64K segmentable cache buffer, RLL 2.7, ZBR
			 async/sync
Quantum		(5 1/4") 64K segmentable circular cache buffer, RLL 2.7, async
Imprimis	(5 1/4") 32K read ahead buffer (*), RLL 2.7, ZBR, async/sync
Maxtor		(5 1/4") 45K read ahead buffer (*), RLL 2.7, async/sync
Micropolis	(5 1/4")
Priam		(5 1/4")
Imprimis	(3 1/2")
Maxtor		(3 1/2") 8K buffer, RLL 2.7, async
Seagate		(5 1/4") Basic buffer
Conner		(3 1/2") Basic buffer
Rodime		(3 1/2") Basic buffer

* Drives come with read ahead disabled.  It can only be activated via
  software

Recomended products to avoid

Cast/Newbury    Do not meet SCSI standard (Rev17B)
Microscience	Do not meet SCSI standard (Rev17B)

TERMS
ZBR	Zone Bit Recorded


			Roy Neese
			Adaptec Central Field Applications Engineer
			UUCP @ {texbell,attctc}!cpe!adaptex!neese
				merch!adaptex!neese



From owner-pc532%daver@mips.com@bu-it.BU.EDU Thu Dec 14 14:21:41 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Thu, 14 Dec 89 10:57:11 PST
From: des@dtg.nsc.com (Desmond Young)
To: pc532@daver.UU.NET
Subject: Re:  low cost committment

Hi,
  I use MINIX, so maybe can answer a couple of the questions. As Bruce
pointed out, the I/O performance lacks somewhat - it is an educational
package, not production. It is sound (ish), with a very large number
of utilities and applications ported. Just recently a vnews port was
posted (do not know how good). (Sorry, that was rn I think).
  I originally used a 120ms HD in my PC (with MINIX). This was less than
adequate. I upgraded to a 60ms RLL drive, and definitely noticed the
speed increase. It became quite satisfactory. I finally added a 23ms
RLL drive, but was disappointed with the speed increase. In contrast,
I had run XENIX on all the above setups, and with the 23ms RLL drive
XENIX really was quite good. MINIX did not however see much improvement.
  One qualifier is that I have not installed the improved stdio packages
that are claimed to improve throughput substantially.
  On the distribution: I have seen comments about a MINIX owner allowed to
make 3 copies, and if they went to friends, ok. Well, I bought my MINIX
with the book from Prentice Hall. The book + software was ~$100. If you
plan to play with it, you really should purchase the book, at least you
know what the objectives, (and bad decisions) were.
Des.

From owner-pc532%daver@mips.com@bu-it.BU.EDU Thu Dec 14 18:06:04 1989
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
Date: Thu, 14 Dec 89 13:34:38 pst
From: Bruce Culbertson <culberts%hplwbc@hplabs.hp.com>
To: pc532@daver.uu.NET
Subject: Disk space, licensing

Howdy gang,

> For those of you who are familiar
> with Minix, how much space is needed for the operating system?

Of course, there is no simple answer to this question.  I have a
"minimal file system" with everything you need to boot plus a good
handful of commands.  It uses 300K.  I keep this file system on a
floppy and use it, instead of my hard disk, when testing new
kernels.  I have filled about 6 megabytes on my hard disk so far.
It has all the libraries, binaries, enough source to rebuild the
OS, but few library and command sources.  My HP9000 workstation,
which I used for the original cross-development, has everything
including multiple versions of some things.  Minix consumes 13
megabytes on its disk.  Because I am a lazy person and have plenty
of disk space, I make no great effort to remove old files, .o
files, etc.

While I am at it, I might as well mention RAM requirements.  The
OS text segment is 0x9c00 bytes.  The data segment is 0x5800 bytes
plus the buffer cache.  I am using a 128K buffer cache at the
moment but PC-Minix gets by with just a 30K buffer cache.

I think the conclusion is that Minix, for the moment at least,
is pretty lean.

> ...how much performance will be lost using a slow hard drive?

At the moment, performance can be improved more by tuning the
OS (for example, setting interleaving optimally) than by spending
wads of money on a fancy disk.  Once the OS is tuned, though, you
may wish you had a fast drive.  I have a Seagate ST-277N, which
certainly is not very fancy.

> How do Minix licencing restrictions apply to modified versions of the 
> software? Can they be freely distributed to people who have copies of
> Tannenbaum's book? Copies of the original programs?

I am as bewildered as anyone by law.  However, I assume I am staying
within the spirit of the law by only giving my 32000 sources to
people who have bought a full set of Minix disks from Prentice-Hall.
I am sure we all agree that Minix is the kind of software we want
to see more of, and that cheating its author and distributor might
kill the proverbial goose.

> I have sent Dave money for disks etc, and if he puts Bruce's original sources
> on them, I will make it available by FTP.

Dr. Tanenbaum has explicitly stated that the sources should not be
put on multi-user systems and I am sure he would be even more
upset if they were available via FTP.  I assume, however, that
we could make cdiff's available via FTP.  So far I have not given
people cdiff's because they are almost as large as the original
sources.  (Cdiff's are quite inefficient when you have lots of
small changes.)

> Also, will you make copies of Culbert's version available before
> the port is complete?

Dave Rand is making such swift progress that I suspect this will be
impossible.  I will not have time to put together a cdiff distribution
until some time in January.  Perhaps Dave will have time sooner, but I
am not sure if he has an up-to-date PC version for comparison.

Happy Holidays,
Bruce Culbertson

From owner-pc532%daver@mips.com@bu-it.BU.EDU Thu Dec 14 23:32:19 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: dlr@daver.UU.NET (Dave Rand)
Date: Thu, 14 Dec 89 20:17:25 PST
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.uu.net, bill@foxpv2
Subject: Santa is here.

Well, the moment you all have waited for is here. Just how much is the
NS chip set going to cost, anyway?

National Semiconductor has been very receptive to our concept, and
thanks to Russ Johnson, has given us quite extra-ordinary pricing
on the CPU, FPU and ICU cluster. In return, National would like some
technical articles written about the boards, which I'm sure will be
no problem given the technical ability of the pc532 group.

In addition ( ** no promises ** ), we are working on a UNIX solution.
I will, as always, let you know what this will be. This will not impact
any of the other efforts for software.

Due to the demand of you good folks, it looks like we will have to run
40 boards. As it turns out, the setup charge will be a one-time shot,
so we should be able to get additional boards done in the future, with
only the standard per-board charge. This will be higher than the current
price, as we will be doing fewer boards, but it should be reasonable.

Some of the parts on the pc532 may be difficult to obtain, and George
has already indicated that we will blow the proms and pals for you.
We are now working to expand that, and hope to include:

	1) The sockets for the CPU and FPU.
	2) The other PLCC sockets (5 x 44 pin, 1 x 68 pin)
	3) The IBM AT power connector.
	4) The DRAM sockets
	5) The XT Motherboard connectors.
	6) The NS32532U-25, NS32381U-25, and NS32202-10
	7) The AIC-6250 SCSI chip
	8) The DP8490V SCSI chip.
	9) 4 15ns GALs (pre-programmed)
       10) 2 10ns (D-speed) PALS (pre-programmed)
       11) 1 27256 eprom (pre-programmed)
       12) 74ALS6311 (TI Page comparator chip)

You will still need to obtain the other TTL chips, the terminators, resistors,
bypass caps, RAMS, 2681 (or SCC2692V), etc.

Basically, you should be able to put together a complete, 25 Mhz, 4 megabyte
system for less than $1,000.

Here is the tentative pricing:

	1) PC532 bare PCB 	$200 USD
	2) Kit of above parts	$450 USD (including PCB)

The prices do not include postage, insurance or UNIX. No, it is not a typo.
The $450 price includes the PCB, and the kit of parts, including the CPU,
FPU and ICU.

Note that this is a *very* limited offer. You will not be able to get the
parts separately, and you will not be able to get just the 532 on its own.
We are going out on a limb for this - don't expect more.

In order to get this deal, it is first come, first served. When we run out
of chips, that is it - we will not get such a price from National again.
The plan is to put the PCB's in for fab next week, so they should be
done near the end of January.

Just so no one gets confused: This system is not sponsored by any company.
This is strictly a personal, hobby level effort. Although the boards are
tested, we do not guarantee that the boards will work. You are on your
own!

If you would like to order a system, we request that your have your cheques
here no later than January 15, 1990. We also request that you confirm your
order, by email to: pc-order@daver.uu.net. You must indicate the quantity of
boards, and if you want a kits of parts. Please include a mailing address,
telephone number, and email address. We may (regretfully) have to limit
the number of boards each person receives. Of course (need I mention this?)
Purchase Orders are not acceptable. Visa and Master Card not accepted.

If you have any questions, please let us know.

Dave Rand	<dlr@daver.uu.net>
George Scolaro	<george@wombat.UUCP>
+1 408 434-0600 X4555
+1 408 733-4125 home

The following people have indicated that they would like a board. Everyone
still must re-confirm, but these people do have priority.

From:	jkh@meepmeep.pcs.com (Jordan K. Hubbard)

From:	Eyal Lebedinsky <daver!munnari!ucisae.isae.cancol.oz.au!eyal>

From:	Dave Mason <daver!uunet!tmsoft!mason>
	2 boards.

From:	Jerry Callen	<jcallen@encore.encore.com>

From:	ian@sibyl.eleceng.ua.oz

From:	<asgard@omni.com>

From:	daver!uunet!sybase.com!nk (Nicolai Kosche)
	2 boards

From:	 Per Holmer  <daver!voder!uunet!farkas.math.kth.se!per>

From:	daver!uunet!fesk.seri.gov!sverre (Sverre Froyen)
	2 boards.

From:	daver!uunet!hcrvx1!ron

From:	daver!uunet!munnari!otto.bf.rmit.oz.au!athos

From:	daver!uunet!meepmeep.pcs.com!jkh (Jordan K. Hubbard)

From:	"Robert D. Greene" <ricevm1.rice.edu!RGREENEB@cs.utexas.edu>

From: 	...ken seefried iii	...!<anywhere>!gatech!mm!ken

From:	Bob <attctc!puzzle!bei>

From:	David Taylor	<taylor@think.com>

From:	Sean Eric Fagan	<sef@kithrup.com>


From: daver!uunet!equi.com!John.J.Ackley
 
"Juki"            <jtv@hut.fi>
"Jyrki Kuoppala"  <jkp@kampi.hut.fi>
"Petri Ojala"     <ojala@sauna.hut.fi>
"Ari Lemmke"      <arl@cs.hut.fi>
"Markku J{rvinen" <mta@tut.fi>
"Kenneth S.A. Oksanen" <cessu@joker.hut.fi>
"Matti Aarnio"    <mea@mea.utu.fi>
"Johan Myreen"    <jem@cs.hut.fi>
"Johannes Helander" <jvh@niksula.hut.fi>
"Jarkko Oikarinen" <jto@tolsun.oulu.fi>

Rolf Andersson writes:		xrolfa@dna.lth.se
	2 boards

Trip Martin  Trip_Martin@mts.rpi.edu
		night@pawl.rpi.edu    night@uruguay.acm.rpi.edu


34 boards.

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

From owner-pc532%daver@mips.com@bu-it.BU.EDU Fri Dec 15 03:37:41 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Thu, 14 Dec 89 23:42 PST
From: dlr@daver.uu.net (Dave Rand)
To: pc532@daver.uu.net
Subject: help building kits

I have several people that have offered to help assemble the kits. If you
are among those who DO NOT want to build your own board, please mail
me directly, and I'll send you the email address of the folks that
are willing to build the boards with you.

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

From owner-pc532%daver@mips.com@bu-it.BU.EDU Fri Dec 15 07:47:54 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Thu, 14 Dec 89 12:24:29 EST
From: ron%hcrvx1%uunet@daver
To: pc532@daver.UU.NET
Subject: Cheap system

The NS32GX32 is only about $200.  It is a 532 without mmu, but
it has all the rest of the 532 (cache, fpu interface, 25MHz, ...).
It seems to me that a GX32 with 4 meg of ram running minix
would be a powerful, cheap system.  As for floating point, I have
no interest in a fpu.  I just want memory and integer speed.



From owner-pc532%daver@mips.com@bu-it.BU.EDU Fri Dec 15 14:14:00 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Fri, 15 Dec 89 10:02 PST
From: dlr@daver.uu.net (Dave Rand)
To: pc532@daver.uu.net
Subject: Ordering Information

Sorry - I neglected to put in the ordering details.

Cheques should be mailed to:

George Scolaro or Dave Rand
941 Chehalis Drive
Sunnyvale, CA  94087

We are not sure how much the postage and insurance will be. We're trying
to get some data sheets for the parts, and include as much documentation
as possible, so the final weight is not available.

You can make the cheque payable to either George or myself.

If you have any questions, please let us know!

Dave Rand / George Scolaro
+1 408 434-0600 X4555 / X4556
+1 408 733-4125 home

From owner-pc532%daver@mips.com@bu-it.BU.EDU Fri Dec 15 16:11:51 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Fri, 15 Dec 89 08:45:43 CST
From: rmf%bpdsun1%quintro%tiamat%uunet@daver (Rob Finley)
To: pc532@daver
Subject: Re:  Assembly people wanted

Include me in.  I cannot afford a board yet (pay for school and a car first)
but would love to solder a few of them together.  Put me on the list!!!

We do wave solder a lot but I am not sure if I could get it done through
good channels and as they only run the contraption for 6 hours a week,
I can't sneak it on either...  But, I have lots of solder experience, patience
great eyesight, and all sorts of stuff.

Mail this to anyone who needs it.  We can email back and forth to get it set up.
Thanks. 
-----Robert.  I hope you can pick my email address out of the header because
I can't remember what the hell it was...

From owner-pc532%daver@mips.com@bu-it.BU.EDU Fri Dec 15 17:07:26 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Fri, 15 Dec 89 15:50:11 EST
From: Jerry Callen <jcallen@maxzilla.encore.com>
To: pc532@daver.uu.NET
Subject: Minix distribution

Has anyone approached Dr. Tanenbaum about some appropriate distribution
mechanism for Minix? I'm sure all of us who want it are willing to pay the
usual fee (about $100), but it really seems crazy to have to get disks from
P-H and then apply 6.02E23 diffs. 

If no one else has contacted him, I'd be happy to send him mail. Dave,
if Dr. T. consented, would you be willing to keep a copy of Minix on
your system for un-anonymous FTP?

-- Jerry Callen
   jcallen@encore.encore.com

From owner-pc532%daver@mips.com@bu-it.BU.EDU Fri Dec 15 17:08:53 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
X-Mailer: Mail User's Shell (6.4 2/14/89)
To: pc532@daver.UU.NET
Subject: Re: help building kits
Date: 15 Dec 89 20:38:33 GMT (Fri)
From: ken%mm@gatech.edu (Ken Seefried iii)

Thought I'd pass this along...

I am making arangments now to have the sockets soldered on my
pc532 motherboard by a professional.  Seems that quite a few of
the tech people at Georgia Tech do piece-meal soldering work to
make a few extra $$$.  The work I've seen looks really good
(cerrtainly *vastly* better than I could do).  It's not wave
soldering, but noone will wave one board...

For us clumsy people who scortch and ruin boards when we soldier,
it seems like a really good idea...

-- 

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

From owner-pc532%daver@mips.com@bu-it.BU.EDU Sat Dec 16 14:39:17 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date:  Sat, 16 Dec 89 14:03:34 EST
From: budd@bu-it.bu.edu
To: pc532@daver.uu.NET
Subject: Another OS Alternative -- TRIX

TRIX is a message passing kernel that was developed by the Real Time
group of MIT's Labratory for Computer Science for an early TI 68k
nubus machine.

It was freed using the "Sussman" (scheme) Copyright which only
restricts the use of MIT's name.

Like Minix, TRIX provides a filesystem at the level of Unix v7.  It
also appears to contain a threads abtraction.

TRIX has been the Free Software Foundation's second choice kernel
(after Mach).

Of course Bruce's Minix port is the quickest way up, but I'm bothered
by the restrictive nature of Minix's licencing because it makes
distribution and sharing harder for us.

Not only that, but if pc532 people out there start doing major hackery
in the quest for performance (which lets face it, is what this list is
about), Tanenbaum will probably not be interested in the results,
putting us out of the Minix mainstream.  And there are few things I
hate more than merging changes from divergent code!

-Phil Budne

From owner-pc532%daver@mips.com@bu-it.BU.EDU Sat Dec 16 18:03:46 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date:  Sat, 16 Dec 89 16:43:14 EST
From: tower@bu-it.bu.edu
To: pc532@daver.UU.NET
Subject: Another OS Alternative -- TRIX

   Reply-To: pc532@daver.UU.NET
   Date:  Sat, 16 Dec 89 14:03:34 EST
   From: budd@bu-it.bu.edu

   TRIX is a message passing kernel that was developed by the Real Time
   group of MIT's Labratory for Computer Science for an early TI 68k
   nubus machine.

   It was freed using the "Sussman" (scheme) Copyright which only
   restricts the use of MIT's name.

Richard Stallman was the main person who got MIT to release it this way.

Like to point our that all the Public Domain utilites done for MINIX
woul run port to TRIX with little effort.

enjoy -len 

From owner-pc532%daver@mips.com@bu-it.BU.EDU Sat Dec 16 21:32:24 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Subject: Multis VIP query.
To: pc532%tarpit@daver.uu.NET
Date: Sat, 16 Dec 89 20:00:52 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]


On page 29 of the January issue of Mips magazine is an advertisement by
Multis Corporation, Lowell, MA.  It features their VIP (video interface
processor).  Quoting the advertizement, "The VIP is a fully programable
Transputer based video board with display resolutions up to 1600 x 1280
pixels, and over 16 million colors".  It further indicates the VIP comes
with 1 or 4 megabytes of processor memory and 2 megabytes of vido memory.

Physically the board is 4 TRAM slots wide and contains:

        1  - T800 transputer
        1  - ????   (chip the same size and style as the T800)
        6  - DIPS
        1  - oscillator
        3  - resistor packs
        1  - capactor
        24 - memory modules (?? type ??)
        4  - BNC connectors ( red, green, blue, sync)

Thats all no other components that I can see.

Is any one familiar with this board and its design ??

Does anyone know what the ???? chip is ??

On the surface, the design looks like it should be of interest to the
pc532 crew.

Best Regards,
johnc



From owner-pc532%daver@mips.com@bu-it.BU.EDU Sat Dec 16 22:02:49 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: george@wombat (George Scolaro)
Date: Sat, 16 Dec 89 18:52:07 PST
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver
Subject: progress...

Hi folks,
	well, the purchasing of parts has commenced. We have
went and bought a couple of stores out of SIMM connectors, XT
connectors, resistor packs etc. Tommorrow we descend on another
store in the Fremont area (the wonder of sillycone valley, some
electronic stores are actually open on a Sunday!!).
	On Monday we have quotes coming in from a major distributor
for many of the IC's etc.
	At this stage we have 40 boards re-committed. Thanks, we'll
now have to do a run of 50 boards instead of 20 then 30...
Tomorrow we will post a list of all the people that have confirmed
for boards so you can double check. Thanks also to the people that
have already indicated that they have sent cheques, it helps to
bankroll some of this stuff (it adds up, XT connectors @ $2 x 50 x 4
is $400).

we'll keep you informed on the progress.

regards,

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com@bu-it.BU.EDU Sat Dec 16 23:46:37 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Subject: RE: Another OS Alternative -- TRIX
To: pc532%tarpit@daver.uu.NET
Date: Sat, 16 Dec 89 22:16:45 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]

 
If it means anything, with the exception of the filesystem, I have
replaced the Minix OS with a similar (still uses Minix messages)
but different design.

Best regards,
johnc


From owner-pc532%daver@mips.com@bu-it.BU.EDU Sun Dec 17 19:45:39 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Sun, 17 Dec 89 15:34 PST
From: dlr@daver.uu.net (Dave Rand)
To: pc532@daver.uu.net
Subject: Update on minix

Well, Bruce's modifications are quite nice. Everything compiled OK.
I'll be transferring the "miniroot" that he prepared for me to the hard
disk today.

Right now I going through his MMU modifications, changing the page size to 
4k instead of 1k. This looks not too bad, as he did most of his
MMU jiggling in the .h files...

As an aside, I tried to bring up the stock PC minix on my system.
Aside from the obvious problems, I found that it doesn't support the
VGA (in text mode) very well, as the screen kept disappearing on me.
As well, I couldn't transfer the files to the hard disk, due to some
bad blocks... Anyone have a bad block mapper for Minix?

Later today, we'll be posting the list of re-confirmed orders.
It looks like we have some serious interest in this board. I'm
glad to see that...

A lot of folks have had some intereting ideas on follow-ons. I am hoping
that we (George and I) won't be the only ones designing new things. Currently,
there are several people thinking about designs supporting the pc532's SCSI
bus. We have a couple of people researching "alternative" processor support,
and hope to get some additional proccessor boards available in the future.
Even if you can't bring the design to PCB, I hope that you will make the
effort to get schematics out to people, so we can all benefit.

Currently, we have the et532 board in the final PCB layout stage. We will
probably not do a pcb run of these boards until February, so we can
concentrate on getting the pc532's out to those that want them. 

The video board is still up in the air - more research needs to be done
on this. The best idea we have (so far) is to support the 8514 video
standard - this allows us to get the highest resolution display at
the lowest cost, and with the lowest chip count. There is another
video board planned using the 860 (see article from jtv@kampi.hut.fi).
There is another video board being researched now as well...

We talked to one of the folks involved in FDDI work on Saturday, and we may
be able to get an FDDI board after all (surprise!). More on this as it comes.

We are still in need of a simple SCSI-to-AT bus adapter. Using the DP8490,
it should not take more than a PAL or two, and some glue logic - an hour
or so to wrap. I would like someone to design this, but if not, I'll
do it in January. This will allow us to have a high speed link to the
PC. Currently, I'm just using on of the serial ports running at 38.4 Kbps.

I'd like to see a few more people contributing hardware designs, if
possible. If you are thinking of doing a design, but don't want to
broadcast your ideas just yet, drop a line to George or myself.
We can't do everything, but we may be able to drop hints now and
then :-)

We are still in need of someone that has access to PCB routing
software. George is getting quite tired of routing boards - it would
be nice if someone could do a board or two...

If someone has good contacts into "other" companies, so that we could
get good prices on other components (like Toshiba, DRAM division :-),
please try. 

Anyway, that's enough ranting for now. Looks like we have a great
deal of interest in this project, and I'm sure that more people
will join us as time goes by.

From owner-pc532%daver@mips.com@bu-it.BU.EDU Sun Dec 17 22:48:24 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: dlr@daver.UU.NET (Dave Rand)
Date: Sun, 17 Dec 89 18:44:25 PST
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.uu.net
Subject: Order Confirmation

Here is the list of people that have ordered, as of 18:33 PST 12/17/89.

Some names appear more than once - this is because they have ordered more
than one board (or have changed the number of boards that they want). This
list was created by extracting the From: address lines from the Orders file
that is appended to when mailing to pc-order@daver.uu.net. We currently have
45 boards allocated, all with the parts kit (wonder why ;-)

			IF YOU ARE ON THIS LIST
You are confirmed for a board. If, for whatever reason, you DO NOT wish to
get a board and kit of parts in late January, PLEASE cancel your order. If 
you feel that you cannot get a cheque to us by the 15th of January, but
still want a board (at some point), PLEASE let us know. Since we intend
to commit for 50 boards, this represents a sizable risk on George and my
behalf (about $10,000 in the cost of the PCB's alone).

			IF YOU ARE NOT ON THIS LIST
You do not have a board allocated for you. If you want a board, we have
very few left. If you want a board and parts kit, please let us know.
You may telephone your confirmation in, if you like.

Thank you for your time!

Dave Rand/George Scolaro
941 Chehalis Drive
Sunnyvale, CA  94087
+1 408 733-4125 home
+1 408 434-0600 X4555 / X4556 work

From: mips!kithrup.COM!sef (Sean Eric Fagan)
From: kls@ditka.UUCP (Karl Swartz)
From: "Thomas Davis" <uunet!zeus.unl.edu!conslt16>
From: Rolf Andersson <uunet!DNA.LTH.Se!xrolfa>
From: "Robert D. Greene" <ricevm1.rice.edu!RGREENEB@cs.utexas.edu>
From: Mark Geisert <uunet!l66a.ladc.bull.com!Mark-Geisert>
From: uunet!ccm.UManitoba.CA!RFLUKES
From: David Taylor <uunet!Think.COM!taylor>
From: Bruce Culbertson <uunet!hplabs.hp.com!culberts%hplwbc>
From: John L. Connin <uunet!manatee!johnc>
From: Johan Myreen <uunet!cs.hut.fi!jem>
From: sun!emory.mathcs.emory.edu!stiatl!meo (Miles O'Neal)
From: uunet!funet.fi!hks (Harri Salminen)
From: <uunet!prosys!pp>
From: uunet!CUNYVM.CUNY.EDU!1GTLMKF%CALSTATE.BITNET  (Marc Furon)
From: Petri Ojala <uunet!cs.hut.fi!ojala>
From: Per Holmer  <uunet!farkas.math.kth.se!per>
From: Johannes Helander <uunet!joker.hut.fi!jvh>
From: Jerry Callen <uunet!maxzilla.encore.com!jcallen>
From: Jon Loeliger <uunet!uxc.cso.uiuc.edu!convex!loeliger>
From: sun!ames.arc.nasa.gov!gatech!mm!ken (Ken Seefried iii)
From: uunet!bu-it.bu.edu!budd
From: uunet!equi.com!John.J.Ackley
From: Tatu Yl|nen <uunet!ngs.fi!ylo>
From: Robbin W Johnson <uunet!resrch.molienergy.bc.ca!robbin>
From: Jukka Virtanen <uunet!kampi.hut.fi!jtv>
From: uunet!skatter.USask.ca!neil
From: Trip Martin <uunet!pawl.rpi.edu!night>
From: mips!kithrup.COM!sef (Sean Eric Fagan)
From: Gary Lowell <uunet!hpda.hp.com!glowell>
From: David Taylor <uunet!Think.COM!taylor>
From: uunet!tolsun.oulu.fi!jto
From: Jyrki Kuoppala <uunet!cs.hut.fi!jkp>
From: uunet!dgp.toronto.edu!pavel (Pavel Rozalski)
From: uunet!tut.fi!mta
From: Robert Finley <rmf@bpdsun1>
From: James Penny <jpenny@s.ms.uky.edu>
From: Antti Louko <uunet!kampi.hut.fi!alo>
From: P{r Emanuelsson <uunet!isy.liu.se!pell>
From: asgard@omni.com (J.R. Stoner)

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

From owner-pc532%daver@mips.com@bu-it.BU.EDU Mon Dec 18 11:44:46 1989
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
Date: Mon, 18 Dec 89 08:36 PST
From: dlr@daver.uu.net (Dave Rand)
To: pc532@daver.uu.net
Subject: Kits of parts are gone.

All kits of parts are now commited. We will be posting a list of
people and number of kits this evening. Thank you for your tremendous
response!

We will have additional blank PCB's available, if you need them.
The price is still $200.

Dave Rand / George Scolaro
+1 408 733-4125 home
+1 408 434-0600 X4555 / X4556 work

From owner-pc532%daver@mips.com@bu-it.BU.EDU Mon Dec 18 22:47:35 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Mon, 18 Dec 89 21:16:16 EST
From: Jerry Callen <jcallen@maxzilla.encore.com>
To: pc532@daver.uu.NET
Subject: Minix

Folks,

Here is mail that I swapped with ast today regarding Minix. 

-- Jerry

-----------------------------------------------------------------------
Dr. Tanenbaum,

Dave Rand and George Scolaro (both formerly with National Semiconductor)
have designed a hacker's machine around the NS 32532 chip. There is a 
mailing list for the machine, and things are now at the point that we
should be getting circuit boards and parts sometime in January. This
promises to be a nice machine; the big question now is software.

Bruce Culbertson (among others) has ported Minix to a similar (32016)
system; many of us on the list plan to run his version of Minix.

My question is this: what is the proper way for us to get Minix from
Bruce? All of us appreciate the work you have put into Minix and want
to pay the usual price for the code (I seem to recall that it's about
$100, eh?), but it seems silly for us to order the PC minix from P-H
and have to wait for the disks and then apply a zillion diffs to the
code. Is there any way Bruce (or someone else) could serve as a distribution
point for the 532 version of Minix? I would suggest that P-H do this,
but I suspect that the volume (far smaller than the PC version) would
make it unattractive for them. How should we proceed?

-- Jerry Callen

>From ast@cs.vu.nl Mon Dec 18 17:28:54 1989
Date:     Mon, 18 Dec 89 23:19:16 MET
From: Andy Tanenbaum <ast@cs.vu.nl>
To: Jerry Callen <jcallen@maxzilla>
Subject:  Re:  NS32532 Minix

If it is only a small number of people, just do it.  P-H won't want to
get involved.  If everybody buys a copy of the book from P-H, they will
probably be happy.  If it is a lot of people (> 50), we'd better figure
something out.  Please don't post things to any public newsgroups though.
Just private email or diskettes.

Andy Tanenbaum

From owner-pc532%daver@mips.com@bu-it.BU.EDU Wed Dec 20 04:19:58 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: buck%siswat%moray%texbell%swbatl@daver
Apparently-From: swbatl!texbell!moray!siswat!buck
Date: Wed, 20 Dec 89 01:19 CST
Apparently-From: swbatl!texbell!moray!siswat!buck
To: pc532@daver.uu.net
Subject: ST01 cannot be a target

>>   If you are referring to the Future Domain / Seagate ST01 and ST02, the
>>   simple answer is NO.  This controller is an initiator only, it can not
>>   act as a target.  In other words if used in a PC to connect to a pc532,
>>   the PC will not be able to respond to requests initiated by the pc532.
>>
>>   This is a hardware limitation of the design which can not be circumvented
>>   by software.  As designed it can only act as a SCSI host adapter for
>>   connecting to non-initiating SCSI block devices.
>
>I wrote a unix scsi driver for the ST01 about an year ago (Microport
>sysV/386).  I see no reason why it could not be used as a target.  My

The ST01 chip has a very simple data handshake setup.  It waits for REQ to
be asserted by the target, then reads or writes the data onto the bus and
asserts ACK.  The ST01 status register has a bit to check for REQ asserted,
but it has NO ability to write REQ, or to either read or write ACK.  End of
story for ST01 as a target.

Reference: ST01, ST02 SCSI Host Adapter Product Manual,
		Seagate 36027-002, Rev. G, April 5, 1989


A. Lester Buck     buck@siswat.lonestar.org  ...!texbell!moray!siswat!buck



From owner-pc532%daver@mips.com@bu-it.BU.EDU Wed Dec 20 12:03:58 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
To: pc532@daver.uu.NET
Subject: Midi on pc532
Date: 20 Dec 89 13:03:54 MEZ (Wed)
From: jkh@meepmeep.pcs.com (Jordan K. Hubbard)

>Are the serial ports on either the pc532 or the et532 capable of being driven
>at 312500 baud?  Probably not, as it doesn't seem to match the divisor series
>for "normal" rates, but I thought I'd ask anyway.  (312500 baud is the data
>rate of MIDI)

The bigger question is will they do *real* 38.4K? If so, an adaptor
can be purchased for the kingly sum of $40 (They cost 89DM here so
I'm extrapolating, your exchange rate may differ) that provides 4
midi DIN style connectors for 1 38.4K serial in.

That would work.

>Has anyone thought about the distribution formats to be used?  Cartridge tape?
>PC floppies?  Punch cards?  :-)

Good question, this. Does the ns532 even support a floppy drive directly?
I never even thought to ask.. The only SCSI floppy drive I've seen so
far (for the Sun 3/50) was a real dog. I hope that we can do better.

					Jordan

From owner-pc532%daver@mips.com@bu-it.BU.EDU Wed Dec 20 12:04:50 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: dlr@daver.UU.NET (Dave Rand)
Date: Wed, 20 Dec 89 07:25:49 PST
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.UU.NET
Subject: Re: Midi on pc532

[In the message entitled "Midi on pc532" on Dec 20, 13:03, Jordan K. Hubbard writes:]
> The bigger question is will they do *real* 38.4K? If so, an adaptor
> can be purchased for the kingly sum of $40 (They cost 89DM here so
> I'm extrapolating, your exchange rate may differ) that provides 4
> midi DIN style connectors for 1 38.4K serial in.

Yes, the serial ports *really* work at 38.4k bps. I got George to connect
6 ports (a->b->c->d->e->f), and wrote code that
1) took a timer interrupt every 250 microseconds (not milliseconds)
2) took an interrupt for every character, RX and TX
3) implemented a queue for each rx, and interrupt driven tx
4) copied the "appropriate" data from the rx queue of one port to the tx
   queue of the port, as the main task.

Since I used a "wait" instruction, we could look at CPU utilization via
the /PFS pin. It was quite amazingly low. And we looked at the data
on the ring - it was actually going out at 38.4kbps, according to the
scope.

> Good question, this. Does the ns532 even support a floppy drive directly?

No. Sounds like another project to me though - why not do a Z80 or
64180 based plug in card, with 256k-512k of DRAM, a FDC and a SCSI?
You could support 3.5-5.25" drives, and offer read-ahead and write
caching...


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

From owner-pc532%daver@mips.com@bu-it.BU.EDU Wed Dec 20 12:06:17 1989
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
Date: Wed, 20 Dec 89 10:26:03 EST
From: Jerry Callen <jcallen@maxzilla.encore.com>
To: pc532@daver.uu.NET
Subject: Finding parts

I've been looking for the parts NOT in the kit (looking in catalogs) and
have a few questions:

- What substitutions are possible for the 74xxnnn parts? George has specified
  mostly 74ALSnn and 74ASnn, and none of the catalogs I've checked have these.
  Can I substitute 74F or 74HCT? Maybe someone could post a table of
  acceptable substitutions?

- I haven't been able to find a PLCC version of the 2681 (just 40 pin DIP 
  versions). Help, anyone?

-- Jerry Callen
   jcallen@encore.encore.com

From owner-pc532%daver@mips.com@bu-it.BU.EDU Wed Dec 20 12:08:12 1989
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
From: george@wombat (George Scolaro)
Date: Wed, 20 Dec 89 08:01:18 PST
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.UU.NET
Subject: Re: Finding parts

[In the message entitled "Finding parts" on Dec 20, 10:26, Jerry Callen writes:]
> I've been looking for the parts NOT in the kit (looking in catalogs) and
> have a few questions:
> 
> - What substitutions are possible for the 74xxnnn parts? George has specified
>   mostly 74ALSnn and 74ASnn, and none of the catalogs I've checked have these.
>   Can I substitute 74F or 74HCT? Maybe someone could post a table of
>   acceptable substitutions?

Nope. All parts must be as specified except for the 74als14, it can be
whatever you want, since its only used in the reset area. Remember that the
board runs at 25Mhz, and each ns counts, and 74ASxx is typically 1 or more ns
faster than 74Fxx stuff.

NOTE: I will get Dave to post a list of the parts that we are trying to
include into the kit today. Since volume pricing helps, your money will go
further so we are attempting to include other stuff.

> - I haven't been able to find a PLCC version of the 2681 (just 40 pin DIP 
>   versions). Help, anyone?

The 2681 or actually the 2692 (the better/faster/newer version) is also one
of the parts we are trying to get. There are 4 in a board and that means
we are doing (4x50) 200 pricing, comes to around $8 each, or $32 per board.
Anyhow, we have a vendor with them in stock, so they'll more than likely be
in the kit.

What we are trying to arrange with the distributors is a delivery of parts
on the 15th of Jan, that way most of the cheques will be in, and we wont be
out of pocket for weeks etc. Thanks again for all those people that have
already indicated that cheques are on the way etc, we'll start to acknowledge
each person (privately) as they turn up, but note that things will be going
quiet till the new year (holidays etc).

> -- Jerry Callen
>    jcallen@encore.encore.com


-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com@bu-it.BU.EDU Wed Dec 20 12:56:35 1989
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
From: dlr@daver.UU.NET (Dave Rand)
Date: Wed, 20 Dec 89 09:05:15 PST
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.UU.NET
Subject: Re: Finding parts

[In the message entitled "Re: Finding parts" on Dec 20,  8:01, George Scolaro writes:]
> NOTE: I will get Dave to post a list of the parts that we are trying to
> include into the kit today. Since volume pricing helps, your money will go
> further so we are attempting to include other stuff.

1. GAL20V8A-15
2. GAL16V8A-15
3. PAL16R8D
4. PAL20L8D
5. 74AS832
6. MC145406
7. AIC-6250
8. 27C256-20
9. DP8490
10. 74ALS6311 (this one is gonna be hard...)
11. 44 pin PLCC sockets
12. 68 pin PLCC sockets
13. IBM-XT edge connectors
14. 175 pin PGA socket for CPU
15. 68 pin PGA socket for FPU
16. NS32532-25
17. NS32381-25
18. NS32202-10
19. SCC2692AC1A44 (CMOS version of 2681, only 4 ma vs 100 ma)
20. 3.6864 Mhz Crystal
21. 220/330 terminator resistor DIP
22. 22 ohm SIP resistors
23. 47 ohm SIP resistors
24. 4.7K ohm DIP resistors
25. 220 ohm SIP resistors
26. 56 pf mono capacitors
27. Sockets for SIMMs (memory)


That's what it looks like right now. More than one of some of the items
are included (eg. 8 MC145406's). Things change, and the list may get bigger
or smaller depending on what we can get, and the price we can get it at.

You will still need to get the bypass capacitors (0.1 mfd), several resistors
and capacitors (5 & 10 pf for DUART), the other 74xxxxx parts, 50 pin and
10 pin transition headers, etc. (Just the pins, no shroud required or 
desired).

Again, if someone comes across a bargain on something, please let us know
(like 1 meg DRAM SIMMs for $10 or something... :-)



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

From daver!dlr@uunet.UU.NET Wed Dec 20 16:54:55 1989
Flags: 000000000000
From: dlr%daver@uunet.UU.NET (Dave Rand)
Date: Wed, 20 Dec 89 13:48:50 PST
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc-kit%daver@uunet.UU.NET
Subject: Fully Confirmed

Each of you that receive this notice are confirmed for 1 pc532 board
with kit of parts. There are exactly 50 mailings going out from this
list. There are 13 other people that have mailed in wanting boards
with kits of parts, and some of you may be on that list as well. This
mailing (that you are reading) means that you will receive a kit,
for $450.

If, for any reason, you no longer wish to recieve a kit, PLEASE let me
know. Unless I hear from you, I will assume that you want a kit, and
have sent a cheque for $450. If you have ordered two kits, I'm sorry,
but I have had to limit the number of kits each person receives. This
was done by the date of receipt of order, with priority given to those
that had ordered previously (when we weren't going to get any deal from
National - faith and all that :-)

If, for any reason, you feel that you cannot have a cheque to us by the
15th of January, *please* let me know as soon as possible. We are counting
on having this money available to pay for the PCB's. We do not have enough
spare money to carry $10,000 worth of parts and PCBs! If you can't send the
money in before the 15th, but still want the kit, perhaps we can work
something out - BUT YOU MUST LET US KNOW NOW!!!

If there are any other questions, or comments, please let us know.

Dave Rand / George Scolaro
941 Chehalis Drive
Sunnyvale, CA  94087
+1 408 733-4125 home
+1 408 434-0600 X4555 / X4556 work


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

From owner-pc532%daver@mips.com@bu-it.BU.EDU Wed Dec 20 17:41:52 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Wed, 20 Dec 89 14:02 PST
From: dlr@daver.uu.net (Dave Rand)
To: pc532@daver.uu.net
Subject: Order confirmation

Order confirmations have gone out. If you don't get yours within a few
hours, please let me know. We have 63 people that wanted kits, but only
had parts for 50. Of course, you may still order the bare boards for $200,
but regretfully, the parts are gone. More details in the email that has
gone out already.

If you have any questions, or need to change your order, please let me
know as soon as possible. We are putting the boards in for fab tommorow!

Dave Rand / George Scolaro

+1 408 733-4125 home
+1 408 434-0600 X4555 / X4556 work


From xinu-librarian@cs.purdue.edu@bu-it.BU.EDU Thu Dec 21 20:27:48 1989
Flags: 000000000000
Date: 22 Dec 89 19:10:14 GMT
From: cs.utexas.edu!samsung!munnari.oz.au!bruce!mlacus!eitan@tut.cis.ohio-state.edu  (Eitan Froumine)
Organization: Aust Centre for UNISYS Software(ACUS Melb)
Subject: XVMC - Xinu for the Versatile MultiComputer
Sender: xinu-librarian@cs.purdue.edu
To: info-xinu@cs.purdue.edu

Around 1986-1987 I ported Xinu for the NS32000 family and extended it
into the XVMC - Xinu for the Versatile MultiComputer. A multiprocessors
project that run in the Technion - Israel Institute of Technology.

Have anybody used it or know what have happened with it?


Eitan Froumine

Australian Centre for UNISYS software

From owner-pc532%daver@mips.com@bu-it.BU.EDU Thu Dec 21 21:58:26 1989
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Subject: SCSI drives
To: pc532%tarpit@daver.uu.NET
Date: Thu, 21 Dec 89 14:24:05 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]

 
In a previous message I mentioned that CSC (Corporate Systems Center)
generally has good hard-disk prices.

There current flyer lists the following SCSI hard-disks:

1)  CDC 155MB (formated) Wren III, 18ms, P/N 94161-155    $795	 $749
2)  Micropolis 380MB (320MB formated), 18ms,  P/N 1578,  $1295	$1195
3)  Rodine 3085, 67MB formated, 28ms, P/N ???             $495   $449  **

**  Not sure if this is SCSI 

As of today, Thu 12-21-89, they had 20 of the CDC's remaining.

Corporate Systems Center
730 North Pastoria Ave
Sunnyvale, CA  94086
(408) 737-7312

I have no association with CSC.

Best regards,
johnc


From tower@bu-it.bu.edu Fri Dec 22 16:32:10 1989
Flags: 000000000000
Date:  Fri, 22 Dec 89 16:32:06 EST
From: tower@bu-it.bu.edu
To: budd@bu-it.bu.edu
Subject: [wayne%teemc@itivax.UUCP /\/\ichael R. \/\/ayne: Cheap, big drives]

Return-Path: <wayne%teemc%lokkur.UUCP%itivax@itivax>
To: sun-buy%lokkur@itivax.UUCP
Subject: Cheap, big drives
Internet-Address: wayne%teemc.uucp@sharkey.cc.umich.edu
From: <wayne%teemc@itivax.UUCP> /\/\ichael R. \/\/ayne
Organization: TMC & Associates, Troy, MI
Date: Fri, 22 Dec 89 12:21:47 EST
Sender: wayne%sharkey@itivax.UUCP

	The price keeps going down!  ICS is putting an ad in the Sun Observer
next month for the HP 660 Mb (formatted) drives, in a box w/ p/s and cables
for $2495.  Delivery is 45 days.

/\/\ \/\/


From "Jerry Callen <jcallen@maxzilla.encore.com>" Tue Dec 26 21:30:39 1989
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
Date: Tue, 26 Dec 89 15:57:30 EST
From: Jerry Callen <jcallen@maxzilla.encore.com>
To: pc532@daver.uu.NET
Subject: "Dreaded" 32203 DMAC?
Status: O

Why do Dave and George refer to the 32203 as the "dreaded" 32203? I've
been looking at the data sheet and I don't see anything TOO horrible yet.
Is it because it is only 16 bits wide? Or maybe it takes too much glue
(especially in "remote" configurations)? Or is there some horrible flaw
that isn't in the documentation?

The reason I ask is that I am playing with the design of a SCSI peripheral
for the pc532 and I am considering using a 32016/32203/DP8490 combination
(so I can use the same compiler/assembler that are used on the main CPU
of the pc532). My idea is to come up with a fairly generic design that
could be used to build all sorts of neat SCSI peripherals. The board would
talk to the SCSI bus via a DP8490 and DMA and talk to <your device here>
using <logic of your choice>.

If anyone already HAS such a design (using any combination of CPU/DMAC)
please let me know; I'm having fun re-inventing the wheel, but only SO
much fun. :-)

-- Jerry Callen
   jcallen@encore.com


From "Bruce Culbertson <culberts%hplwbc@hplabs.hp.com>" Wed Dec 27 22:49:46 1989
Flags: 000000000001
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Wed, 27 Dec 89 17:49:41 EST
Received: from MIPS.COM by bu-it.BU.EDU (5.58/4.7)
	id AA14361; Wed, 27 Dec 89 17:49:34 EST
Received: by mips.com (5.61.14/1.11) id AA26046; Wed, 27 Dec 89 14:49:20 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gglX1-000093C@daver.uu.net>; Wed, 27 Dec 89 13:50 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!hplabs.hp.com!culberts%hplwbc>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gglWw-00009SC@daver.uu.net>; Wed, 27 Dec 89 13:49 PST
Received: from hplms2.hpl.hp.com by uunet.uu.net (5.61/1.14) with SMTP 
	id AA27047; Wed, 27 Dec 89 16:17:41 -0500
Received: from hplwbc.HPL.HP.COM (hplwbc.hpl.hp.com) by hplms2.hp.com; Wed, 27 Dec 89 13:17:17 pst
Received: by hplwbc.HPL.HP.COM; Wed, 27 Dec 89 13:17:11 pst
Date: Wed, 27 Dec 89 13:17:11 pst
From: Bruce Culbertson <culberts%hplwbc@hplabs.hp.com>
Message-Id: <8912272117.AA09261@hplwbc.HPL.HP.COM>
To: pc532@daver.UU.NET
Subject: Re:  "Dreaded" 32203 DMAC?
Status: RO

> Why do Dave and George refer to the 32203 as the "dreaded" 32203? I've
> been looking at the data sheet and I don't see anything TOO horrible yet.
> Is it because it is only 16 bits wide? Or maybe it takes too much glue
> (especially in "remote" configurations)? Or is there some horrible flaw
> that isn't in the documentation?

I can give you some information since I have used the 32203 in my
32016 system.

I maintain that the 32203 is a pretty good choice for the 32016 and a bad
choice for the 32532.

The '532 has an interrupt mode with excellent latency.  I have not checked,
but I suspect it can field an interrupt, move a byte, and return at
about the same speed as the 32203 can work through the bus request/grant
protocol and move a byte.  This is partly because the 32203 is available
only up to 10MHz.  The DMA solution requires extra hardware: the DMA
controller plus glue.  Hence, DMA is a bad choice.

Since the 32016 is available only up to 15MHz, the 32203 is a better
match for the 32016.  Also, the 32016 only has one interrupt mode --
that mode uses external addressing mode and is swift as a speeding
glacier.  Hence, there is no way the 32016 can move data as fast as
the 32203.  The 32203 is very easy to use with the 32016.  It requires
no extra glue and its pin-out matches the CPU for easy routing.

The 32203 has some misfeatures and compares unfavorably with competing
DMA controllers.  Many controllers, like the AMD9516, allow chaining
tables of arbitrary length in memory.  Chaining (it is charitable
to call it that) with the '203 gives you, in effect, a table of length
two and forces you to not use one of the other channels.  If you want to
use byte assembly and disassembly, you must throw away all the channels
but one.  Nevertheless, I used the 32203 because one of my objectives
was low parts count.

Bruce Culbertson

From owner-pc532%daver@mips.com@bu-it.BU.EDU Tue Dec 26 06:20:52 1989
Flags: 000000000001
Received: from MIPS.COM by bu-it.BU.EDU (5.58/4.7)
	id AA25510; Tue, 26 Dec 89 06:20:52 EST
Received: by mips.com (5.61.14/1.11) id AA23944; Tue, 26 Dec 89 03:20:45 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0ggF0Y-0000C7C@daver.uu.net>; Tue, 26 Dec 89 03:06 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <voder!nsc!taux01.nsc.com!cyusta>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0ggF0Q-0000CQC@daver.uu.net>; Tue, 26 Dec 89 03:06 PST
Received: from nsc by voder.nsc.com (5.61/1.34) with UUCP
	id AA07158 for pc532; Tue, 26 Dec 89 03:04:53 -0800
From: cyusta@taux01.nsc.com
Received: from taux01.nsc.com by nsc.nsc.com (5.61/1.34) with UUCP
	id AA21078 for pc532; Tue, 26 Dec 89 03:06:03 -0800
Date: Tue, 26 Dec 89 12:45:56 -0200
Message-Id: <8912261045.AA04450@taux01.UUCP>
To: pc532@daver.UU.NET
Subject: Re: Order confirmation
Newsgroups: nsc.pc532
In-Reply-To: <m0geEOR-0000D1C@daver.uu.net>
Organization: National Semiconductor (IC) Ltd, Israel
Cc: cyusta@daver.uu.net

Hi Dave / George

 I was not involved in this issue so far, but am getting interested..
 For now, all I can say is that it just occured to me this may be of
 interest to the Tel-Aviv University. They have been working with our
 VME boards, but could surely use a cheap solution for using it as a
 system, or for research (although, research mainly involves parallel
 computing, and the VME boards are well suited for this purpose). 
 Anyway, as this has just occured to me I have just mailed them about
 it and will have more info soon.


   Regards, and Merry Christmas
   Yuval Shachar
-- 
	Yuval Shachar				cyusta@taux01.nsc.com 
						cyusta@nsc.nsc.com
    National Semiconductor (Israel) P.O.B. 3007, Herzlia 46104, Israel
    Tel. +972 52 522261  TWX: 33691, fax: +972-52-558322


From owner-pc532%daver@mips.com@bu-it.BU.EDU Tue Dec 26 16:30:39 1989
Flags: 000000000001
Received: from BU.EDU by bu-it.BU.EDU (5.58/4.7)
	id AA00237; Tue, 26 Dec 89 16:30:39 EST
Received: from MIPS.COM by BU.EDU (1.97) Tue, 26 Dec 89 16:12:27 EST
Received: by mips.com (5.61.14/1.11) id AA01991; Tue, 26 Dec 89 13:12:12 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0ggOKu-00008lC@daver.uu.net>; Tue, 26 Dec 89 13:04 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!maxzilla.encore.com!jcallen>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0ggOKq-00009CC@daver.uu.net>; Tue, 26 Dec 89 13:03 PST
Received: from multimax.encore.COM by uunet.uu.net (5.61/1.14) with SMTP 
	id AA18821; Tue, 26 Dec 89 15:56:03 -0500
Received: from maxzilla.encore.COM by encore.encore.com with SMTP (5.61/25-eef)
	id AA28243; Tue, 26 Dec 89 15:55:26 -0500
Received: by maxzilla. (4.0/SMI-4.0)
	id AA10009; Tue, 26 Dec 89 15:57:30 EST
Date: Tue, 26 Dec 89 15:57:30 EST
From: Jerry Callen <jcallen@maxzilla.encore.com>
Message-Id: <8912262057.AA10009@maxzilla.>
To: pc532@daver.uu.NET
Subject: "Dreaded" 32203 DMAC?

Why do Dave and George refer to the 32203 as the "dreaded" 32203? I've
been looking at the data sheet and I don't see anything TOO horrible yet.
Is it because it is only 16 bits wide? Or maybe it takes too much glue
(especially in "remote" configurations)? Or is there some horrible flaw
that isn't in the documentation?

The reason I ask is that I am playing with the design of a SCSI peripheral
for the pc532 and I am considering using a 32016/32203/DP8490 combination
(so I can use the same compiler/assembler that are used on the main CPU
of the pc532). My idea is to come up with a fairly generic design that
could be used to build all sorts of neat SCSI peripherals. The board would
talk to the SCSI bus via a DP8490 and DMA and talk to <your device here>
using <logic of your choice>.

If anyone already HAS such a design (using any combination of CPU/DMAC)
please let me know; I'm having fun re-inventing the wheel, but only SO
much fun. :-)

-- Jerry Callen
   jcallen@encore.com

