From owner-pc532%daver@mips.com Mon Apr  2 04:47:37 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
Date: 01 Apr 90 10:58:20
From: Steven.D.Ligett@mac.dartmouth.edu
To: pc532@daver.bungi.com (pc532 disks)
Subject: Re: Parts Kits!

--- Karl Swartz wrote:
How many people would be interested in buying a kit of all
the parts for the new run?  Having just gotten done with the
disk drive group buy I'm not exactly eager to volunteer more
of my time, but if there's enough demand and nobody else is
willing to do it I'll entertain thoughts of putting together
parts kits for folks who don't mind me adding on a small cut
for my time.

--- end of quoted material ---

I've been corresponding with Dave about doing this myself.  I'll be faxing and
phoning parts lists to distributors tomorrow (Monday, April 2), and I hope to
have everything arranged by a week from then, April 9th.  I'll post a list of
parts and costs then.  And I'll have some arrangement for taking orders by
then too.  DON'T ORDER NOW, PLEASE!  It'll be easiest if most folks are
interested in the whole kit, but I'll accomodate orders for individual
oddities too.

Would anyone be interested in slower parts (i.e. 20 Mhz vs 25 Mhz) if that
would save a lot of money?  I haven't looked, so I don't know if there's much
difference in costs at 20 Mhz.

I know inside salespeople at most of the big (and some of the small)
distributors, so I don't expect any problem in finding the complete set of
parts, but I just wrote to Karl asking for his help if I get stuck on
something.

From ames!zorch!daver!dlr@XN.LL.MIT.EDU Tue Apr  3 09:46:39 1990
Flags: 000000000000
Posted-Date: Tue, 3 Apr 90 06:15:31 PDT
From: ames!daver.bungi.com!dlr@XN.LL.MIT.EDU (Dave Rand)
Date: Tue, 3 Apr 90 06:15:31 PDT
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: Phil Budne <budd@bu-it>
Subject: Re: Minisribe manuals

[In the message entitled "Re: Minisribe manuals" on Apr  3,  2:16, Phil Budne writes:]
> Did you get the "real" manual?  Did it contain additional useful info?
yes. No.

> 
> What is the title of the detailed manual?

It is the 9380S "Product Manual". It tells, yet again, that there are
2 jumpers for sector size, but neglects to tell what they do. I have
(multiple) calls in to Miniscribe, but no luck yet.


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

From owner-pc532%daver@mips.com Tue Apr  3 15:10:40 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
To: pc532@daver.bungi.com
Subject: Re: test code for pc532 
Clarity-Index: null
Threat-Level: none
Quote-Of-The-Moment: Termoter messesers temperrs.  -- A 4th grader
What-Was-Meant: A thermometer measures temperature.
Date: Mon, 02 Apr 90 22:35:54 CDT
From: Jon Loeliger <loeliger@convex.com>

> From:     jkh@meepmeep.pcs.com (Jordan K. Hubbard)
> Subject:  test code for pc532
> ______________________________________________
> Now that we've got a '532 working (and hooked to a terminal), we're wondering
> if there are any quick little ditties that people have written for testing
> memory/CPU/FPU, making a scsi disk go "thud" or blinking the lights. We'll
> probably do a little fiddling on our own, of course, but it would be
> nice to have some canned examples to run.

Over here in Convex land, we're not quite in the quick ditties stage yet.
We have a rather ambitious set of FSF code, though, including, but not
limited to, GCC, GAS, binutils, and sundry.  All of which we have stuffed
into a chroot-ed box to force a cross development system (C2 -> '532 (now
*there's* a weird one...)).

> Are people just writing their assembly on other systems and then using
> GAS to generate downloadable images or what? I'm rather curious.

We haven't quite had the time yet to put together the Thing that takes
a GAS a.out file and gives us some pure downloadable image yet (as opposed
to a UNIX-like exec format image), so we're still in the primitive stages
of hand stuffing memory.  (If you have that (Gnu) a.out -> straight critter
written (hacked up QAD-like), lemme know, eh?)

> Speaking of which, there seems
> to be a good bit of space on this ROM.. Perhaps we might include a few
> self-test routines to jump to in subsequent versions? The monitor doesn't
> eat *all* the space, does it? 

Bruce has hinted at some disk thumping routines in the next rev of the EPROM.
BTW, before it gets wildly out of hand, can we name the EPROM revs that
are floating about so that we all have a common name space?  As I see it,
so far there is only the original image, and a quick update that fixes the
"run" and "step" commands.  Are these, say, 1.0 and 1.1, with the next,
disk thumping version to be 2.0?


jdl
------------------------------------------------------------------------------
Jon Loeliger			    | loeliger@convex.com
Convex Computer Corporation	    | I'm the thirteenth at your table,
3000 Waterview, Richardson TX 75080 | I'm the uninvited guest.  - Marillion

From owner-pc532%daver@mips.com Tue Apr  3 20:02:45 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
Subject: Miniscribe drives..
To: pc532%daver@uunet.UU.NET
Date: Tue, 3 Apr 90 16:58:05 EST
From: John Connin <johnc%manatee%uunet@daver>
X-Mailer: ELM [version 2.2 PL2]


If you purchased a disk drive from CSC (ie group purchase), I suggest
that you give it a good test when it arrives.

Of the two I just received one is weak -- numerious write errors.  The 
other seems swell...

A surface analysis of your drives should reveal NO defects.  Contrary
to MFM, RLL, ESDI drives, the SCSI controller maps out defects.  In
other words, a SCSI drive should appear defect free.  If not, something
has gone wrong since leaving the factory.   

NB: New defects can be remapped by commanding the controller to perform 
a low level format -- assuming the drive is functioning properly. Of
course they can also be mapped-out at a higher level by the OS.  
However, this should only be necessary late in the drives life-cycle,
at least in my view of things.

BTW: so far I really like the MS-9380S.  It quite, fast (eg. slightly 
faster than a Maxtor 3800S), has amazingly good mechanical balance,
and runs reasonably cool.

Before I forget, MANY, MANY thanks to Karl Swartz  ...  the man who
organized a world-wide consortium which purchased in excess of
15,980,000,000 bytes of data storage.

Best regards,
johnc








 



-- 

From owner-pc532%daver@mips.com Tue Apr  3 23:18:41 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
Date: Tue, 3 Apr 90 18:02:22 pdt
From: Bruce Culbertson <culberts@hplwbc.hpl.hp.com>
To: pc532@daver.bungi.com
Subject: Re: test code for pc532

> We haven't quite had the time yet to put together the Thing that takes
> a GAS a.out file and gives us some pure downloadable image yet (as opposed
> to a UNIX-like exec format image), so we're still in the primitive stages
> of hand stuffing memory.  (If you have that (Gnu) a.out -> straight critter
> written (hacked up QAD-like), lemme know, eh?)

Using my tools, I do something like

	# link for some address in RAM
	ld -T <some address in RAM> files...
	# strip a.out header
	dd if=a.out of=image bs=1024 skip=1

Then download the file "image".  By the way, I think you can ftp my
tools from Bdale's machine (hp-col.hp.com).  They may be slightly
out-of-date.  The assembler and linker will run on a PC.

> Speaking of which, there seems
> to be a good bit of space on this ROM.. Perhaps we might include a few
> self-test routines to jump to in subsequent versions? The monitor doesn't
> eat *all* the space, does it? 

Currently, the ROM uses 0x5c00 bytes.  (If the binary I posted had more,
it was because I did not bother to strip the symbol table.)

> Bruce has hinted at some disk thumping routines in the next rev of the EPROM.

I do not have a spare SCSI disk for testing.  The code has been ready for
a week.  Any guinea pigs out there?  Send e-mail for a copy.  If it works,
I will post it to the world.

> BTW, before it gets wildly out of hand, can we name the EPROM revs that
> are floating about so that we all have a common name space?

I have been using the date in the version message that comes up when it
boots.  Do we need something better or will that do?

Bruce Culbertson

From owner-pc532%daver@mips.com Tue Apr  3 23:18:46 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
Date: 	Tue, 3 Apr 90 21:39:02 EDT
From: FELLOWS@UNB.CA
To: pc532@daver.bungi.com
Subject:     Re: test code for pc532

On  Mon, 2 Apr 90 23:35:54 EDT  Jon Loeliger <loeliger@convex.com>
writes:

> We haven't quite had the time yet to put together the Thing that takes
> a GAS a.out file and gives us some pure downloadable image yet (as
> opposed to a UNIX-like exec format image), so we're still in the
> primitive stages of hand stuffing memory.  (If you have that (Gnu) a.
> out -> straight critter written (hacked up QAD-like), lemme know, eh?)
>
I have two programs that were written to transfer COFF files
(ICM3216 UNIX V.2) to a raw ICM3216.  They might be the basis for a
quick hack by someone else.
One creates a memory image file, which can be transported any way you
like.  It has some restrictions about the layout and sequencing of
sections in the COFF file.  Sections must appear in ascending
physical address order.
The other should handle general COFF files but was designed to
interact with the ICM3216 ROM monitor download command as a subcommand
of adb.

If there is interest, I can:
   a: post to the list,
   b: mail to Phil Budne & ask that he add them to the archive he has
      started,
   c: both

Dave Fellows

From owner-pc532%daver@mips.com Wed Apr  4 03:56:11 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
X-Mailer: Mail User's Shell (6.2 5/11/88)
To: pc532@daver
Subject: pc532 debug
Date: 3 Apr 90 22:37:13 PDT (Tue)
From: george@wombat.bungi.COM (George Scolaro)

This is a segment of a 'getting a pc532 to talk' session. Please note that
you must have two (2) 2681 devices plugged into the pc532 (minimum), since
U48 is the one that the monitor talks through, but U60 is the one that
is connected to the crystal oscillator.

> Last (I thought) I connected a terminal to CONN3. No response :-(
> I have probably missunderstood something, but I can't figure out what.
> This is how the cabling to the terminal looks:
> 
> 	10-pin conn	DB25 (female)
> 
> 	DCD  1		8
> 	RXD  3	<- pc532 inputs data on this line	3
> 	RTS  4		4
> 	TXD  5	<- pc532 outputs data on this line	2
> 	CTS  6		5
> 	DTR  7		20
> 	GND  9		7
> 
> I think someone on the mailing list said that it was ok to use 2,3,7 only

yes, this is true.

> PS
> I have only installed one 2681 and the two corresponding 145406. This is
			^^^ AHAH, the vital information....

> no problem I hope?

YES!!!!!!  You must put a 'second' 2681 into the socket right next to the
crystal, it is the one that oscillates! i.e. no 2681 (next to crystal),
no workie!

> I assumed that the CPU was running ok since all four LEDs was lit. ok?

yes, the leds get lit by software from the cpu to the AIC6250, so you are
probably fine, once you put THE SECOND DUART IN.

regards,

-- 
George Scolaro
george@wombat.bungi.com                [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com Wed Apr  4 12:48:17 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
To: pc532%daver@pyramid
Subject: <9003241641.2650@munnari.oz.au> & <9003241635.2478@munnari.oz.au>
Date: 4 Apr 90 18:04:20 MSZ (Wed)
From: jkh@meepmeep.pcs.com (Jordan K. Hubbard)

Has anyone been following gnu.utils.bug and gnu.gcc.bug? Someone named
Ian Dall has been hacking on gcc/gas/gld for the 32000, which may be
of interest to us. Who's standing on the gcc issue right now?

					Jordan

From owner-pc532%daver@mips.com Wed Apr  4 14:37:48 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
Date: Wed, 4 Apr 90 08:30:29 -0800
From: bob@arthur.wwu.edu (Bob Hayes)
To: pc532@daver.bungi.com
Subject: formatting MS drives

Having trouble with formatting. Get parameters changed error
when trying to format. The mode sense and mode select commands
work ok, can set pages/ read page params, but I can't write
any partition table to the existing format either.
I got a small stapled folder with the drive, no docs on what
scsi commands, but the drive responds to most commands. I'm
working from an OMTI ( 3 years old?) manual for scsi cmd 
structure. It does not mention parameter page 2, which the
disk has( mode sense: 82 0a 00 00 [00 05] 00 00 00 00 00 00
...where [xx] values are 'changable') ;I give up, whats 5??
I have tried formatting this with my ICM3216 format commands
(CCS or other, mode select ok, bomb on format attempt) and
with the 'raw' scsi commands from the monitor 'i <channel>'.
Yes, I have set the PF (page format) and SP (save page) bits
in the mode select.
Help! I'm clueless now.

BTW- Ordered a 'maintenance manual' from Miniscribe. What got
shipped to me was the 'PRODUCT MANUAL' and a schematic for
the esdi drive...The PM has more helpful info about what
scsi commands the drive knows, but no cmd structure, so
I'm assuming its standard? It does detail the 'software ID
select' in param page 3c, which appears to be the only
'unique' part of the command set.
Is there a REAL maintenance manual anyone else has seen??
Thanks,


I cannot seem to get the paramaters to set on the 9380 drive.
***** Bob Hayes	bob@arthur.wwu.edu *****

From owner-pc532%daver@mips.com Wed Apr  4 14:41:54 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
From: dlr@daver.bungi.com (Dave Rand)
Date: Wed, 4 Apr 90 10:46:57 PDT
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.bungi.com
Subject: Re: formatting MS drives

[In the message entitled "formatting MS drives" on Apr  4,  8:30, Bob Hayes writes:]
> I have tried formatting this with my ICM3216 format commands
> (CCS or other, mode select ok, bomb on format attempt) and
> with the 'raw' scsi commands from the monitor 'i <channel>'.

I was able to format the drive with the ICM commands, as well as
the i <chan> mode. I used i <chan> as the final, since I wanted a
1-interleave. One drive is working fine on daver.bungi.com, the
other is on the pc532. 

The only trouble I had was with the SCSI parity. The ICM needs it
turned on.


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

From owner-pc532%daver@mips.com Wed Apr  4 14:47:57 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
Date:  Wed, 4 Apr 90 13:37:24 EDT
From: budd@bu-it (Phil Budne)
To: pc532@daver
Subject: Re:  <9003241641.2650@munnari.oz.au> & <9003241635.2478@munnari.oz.au>
Cc: culberts@hplwbc.hpl.hp.com, jkh@meepmeep.pcs.com

Ian has posted to the list many times.

There appear to be 3 players (in our crowd that is);

David Taylor <taylor@Think.COM>
Ian
Bruce Culbertson

Ian has merged Dave's fixes into his own.  All can be found on BU.EDU
(128.197.2.6 (for the Domain Impaired)) in ~ftp/users/budd/32k;

GNU/dave
	gas-patch       gcc-patch       gcc-patch2      gcc-patch3

GNU/ian
	DIR.augean.ua.oz.au     binutils.patch1.0.Z     gcc-1.37.1.patch1.0.Z
	INSTALL.Z               gas-1.35.patch1.0.Z     gdb-3.5.patch1.0.Z
	README                  gas-1.35.patch1.1.Z     gdb-3.5.patch1.1.Z

Culbertson/newtools
	These are the latest.  I got them from Bruce today!

From owner-pc532%daver@mips.com Wed Apr  4 17:49:06 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
Date: Wed, 4 Apr 90 12:48:06 PDT
From: unify!goshawk.mason (Mark Mason)
To: pc532%daver%pyramid@unify
Subject: SCSI


Hello all,
Don't know if this made it here earlier, but I found the following
posting in comp.perips and thought it may be of interest.

Work on my pc532 goes slowly, but will hopefully (crossed fingers) be
done in just a couple of weeks.

Q1: Do you really need the ram to boot the pc532 enough to make the
leds light and see the banner message? (I know that I will prob. have
it assembled before I get the memory, don't know if I could wait any
longer at that point to see if it works).

mason

---------------begin incl---------------------

>From unify!csusac!ucdavis!ucbvax!bloom-beacon!snorkelwacker!think!zaphod.mps.ohio-state.edu!wuarchive!rex!mgse!archived Tue Apr  3 08:56:10 PDT 1990
Article 925 of comp.periphs:
Xref: unify comp.periphs:925 comp.sources.wanted:4438 comp.sources.wanted:4439 comp.misc:2317 comp.periphs.scsi:233
Path: unify!csusac!ucdavis!ucbvax!bloom-beacon!snorkelwacker!think!zaphod.mps.ohio-state.edu!wuarchive!rex!mgse!archived
>From: archived@mgse.UUCP (Archive Request Daemon)
Newsgroups: comp.periphs,comp.sources.wanted,alt.sources.wanted,comp.misc,comp.periphs.scsi
Subject: mgse archive server - SCSI BBS files
Message-ID: <1096@mgse.UUCP>
Date: 1 Apr 90 06:00:10 GMT
Organization: mgse
Lines: 47


Last Changed:	Sun Feb 18 14:08:54 CST 1990

This is a periodic posting of information about the mgse archive server
and the available files from the SCSI-bbs, including SCSI, ESDI, IPI,
and Fiber Channel documents from the standards committees.

Thanks to John Lohmeyer of NCR, a majority of the SCSI related files from the
SCSI BBS are now available from the mgse mail archive server. These files were
sent to me by Mr. Lohmeyer at his expense so that more people would have access
to them. The SCSI BBS (316-636-8700) contains a large amount of data relating
to SCSI, and ESDI as well as SCSI-2, IPI, and Fiber Channel, as well as the
last revision of the SCSI-1 standard before it went to publication by ANSI. If
you are interested in finding out what is available from the archive server,
send the message that follows to archive@mgse and you will get back an index
of names and descriptions and a unix style ls -lR listing of filenames and
sizes.

- cut here -----------------------------------------------------------------
help
send other/scsi-bbs/list
send other/scsi-bbs/index
- cut here -----------------------------------------------------------------

if you are interested in the SCSI Version 1, Revision 17B document, have
the bbs send other/scsi-bbs/area07/17b.zip in addition to the index and list
by including these lines at the end of the above message;

- cut here -----------------------------------------------------------------
set uuencode
send other/scsi-bbs/area07/17b.zip
- cut here -----------------------------------------------------------------

There files are also available for anonymous uucp at 504-467-1069,
2400 baud, login 'archive' in /archive/other/scsi-bbs. Callers at
300 or 1200 baud will have to send a break.

Thanks John!

Sun Feb 18 13:58:10 CST 1990, The Fiber Channel file area has been updated
with more files from the SCSI BBS.

-- 
Archive Server Daemon,  Metairie, LA.
uucp:           rex.cs.tulane.edu!mgse!archived or rex!mgse!archived
bitnet:         archived%mgse@REX.CS.TULANE.EDU
internet:       archived%mgse@rex.cs.tulane.edu


>From csusac!csun!rex.cs.tulane.edu!archived%mgse Wed Apr  4 06:12:32 1990
Received: from unify.uucp by goshawk. (4.0/SMI-4.0)
	id AA01977; Wed, 4 Apr 90 06:12:30 PDT
Return-Path: <csusac!csun!rex.cs.tulane.edu!archived%mgse>
Received: by unify.uucp (5.61/smail2.5/06-13-89)
	id AA16956; Wed, 4 Apr 90 06:07:12 -0700
Received: by csusac.cs.csus.edu (4.12/5.17)
	id AA11272; Wed, 4 Apr 90 08:58:06 est
Received: from rex.cs.tulane.edu (129.81.132.1) by csun.edu (3.2/smail2.5/csun3-27-89)
	id AA05523; Wed, 27 Dec 89 06:29:50 PST
From: csusac!rex.cs.tulane.edu!archived%mgse
Received:  by rex.cs.tulane.edu; Wed, 4 Apr 90 07:51:14 -0500
Received:  by rex.cs.tulane.edu; Wed, 4 Apr 90 07:51:09 -0500
Received:  by rex.cs.tulane.edu; Wed, 4 Apr 90 07:51:06 -0500
Message-Id: <9004041251.AA16884@rex.cs.tulane.edu>
Date: Wed, 04 Apr 90 06:25:29
To: ames!unify.uucp!goshawk.mason
Subject: /archive/other/scsi-bbs/index
Status: OR


----------------------------------- cut here -----------------------------------
These files were sent to me by John Lohmeyer, sysop of the SCSI BBS
(316-636-8700). Most of the files from the BBS are here, available 
>From the archive mail server in file are other/scsi/ or via anonymous
uucp in file area /archive/other/scsi.

Things are laid out like the bbs, files for a particular subject are in a
sub-directory named after that file area.


file area	Contents
---------------	---------------------------------------
area01/*	X3T9.2 General Information
area02/*	Communications Software
area04/*	NBS SCSI Verification Tests
area05/*	X3T9.2 Recent Documents (Current Year)
area06/*	Miscellaneous Files
area07/*	SCSI-1 Revision 17B Text Files
area08/*	SCSI-2 Draft Standard Text Files
area11/*	SCSI-2 AutoCAD Figures
area13/*	SCSI-2 Common Access Method File Area
area14/*	IPI files
area16/*	ESDI Document and Related Files
area17/*	Fiber Channel File Area
area18/*	X3T9.2 Documents from 1989



File area: area01

87-029r1.txt.Z	X3T9.2 &.3 Minutes - Feb 87
87-071r0.brf.Z	X3T9.2 &.3 Minutes - Apr 87
87-080r0.txt.Z	May 87 SCSI Working Group Minutes
87-090r0.brf.Z	X3T9.2 &.3 Minutes - Jun 87
87-107r0.txt.Z	Jul 87 SCSI Working Group Minutes
87-135r1.brf.Z	X3T9.2 Minutes - Aug 87
87-153r1.txt.Z	Aug 87 SCSI Working Group Minutes
87-171r0.brf.Z	X3T9.2 Minutes - Oct 87
87-185r0.txt.Z	Oct 87 SCSI Working Group Minutes
87-200r2.brf.Z	X3T9.2 Minutes - Dec 87
88-011r0.txt.Z	Jan 88 SCSI Working Group Minutes
88-020r1.brf.Z	X3T9.2 Minutes - Feb 88
88-031r0.txt.Z	Mar 88 SCSI Working Group Minutes
88-040r1.brf.Z	X3T9.2 Minutes - Apr 88
88-050r0.txt.Z	May 88 SCSI Working Group Minutes
88-066r0.brf.Z	X3T9.2 Minutes - Jun 88
88-072r0.txt.Z	Jul 88 SCSI Working Group Minutes
88-096r0.brf.Z	X3T9.2 Minutes - Jul 88
88-109r2.txt.Z	Aug 88 SCSI Working Group Minutes
88-130r2.brf.Z	X3T9.2 Minutes - Oct 88
88-153r0.txt.Z	Nov 88 SCSI Working Group Minutes
88-164r0.brf.Z	X3T9.2 Minutes - Dec 88
89-019r1.txt.Z	Jan 89 SCSI Working Group Minutes
89-028r1.brf.Z	X3T9.2 Minutes - Feb 89
89-042r0.txt.Z	Mar 89 SCSI Working Group Minutes
89-049r0.brf.Z	X3T9.2 Minutes - Apr 89
89-066r1.txt.Z	May 89 SCSI Working Group Minutes
89-075r0.brf.Z	X3T9.2 Minutes - Jun 89
89-090r0.txt.Z	Jul 89 SCSI Working Group Minutes
89-111r0.brf.Z	X3T9.2 Minutes - Aug 89
89-120r0.txt.Z	Sep 89 SCSI Working Group Minutes
89-126r0.brf.Z	X3T9.2 Minutes - Oct 89
89-138r0.txt.Z	Oct 89 SCSI Working Group Minutes
89-149r0.brf.Z	X3T9.2 Minutes - Dec 89
90-009r0.txt.Z	Jan 90 SCSI Working Group Minutes
90-025r0.txt.Z	March '90 Working Group Meeting Announcement
dr.txt.Z	X3T9.2 Recent Document Register 
feb_agnd.txt.Z	February 1990 Plenary Meeting Draft Agenda
how2get.txt.Z	How to obtain SCSI Standards 
jan_mail.txt.Z	Cover Page from the January Mailing
mem_form.txt.Z	Application Form for Membership and Mailings
members.txt.Z	X3T9.2 Current Membership List
name_con.txt.Z	File Name conventions on the SCSI BBS
proj132.txt.Z	132-column Summary of X3T9 Projects 
s2pr.txt.Z 	here to send SCSI-2 Public Review Comments
schedule.txt.Z	X3T9.2 Meeting Schedule
scsi2nws.txt.Z	What SCSI-2 is about--how it differs from SCSI
t9docreg.txt.Z	X3T9 1987 Document Register
t9sumacr.txt.Z	X3 and ANSI Jargon and Acronyms
t9sumadr.txt.Z	Useful Addresses and phone numbers
t9sumadr.txt.Z	Useful Addresses and phone numbers
t9sumint.txt.Z	Introduction
t9sumorg.txt.Z	Standards Organizations
t9sumpro.txt.Z	Hints on getting proposals accepted
t9sumq&a.txt.Z	X3T9 Questions and Answers
t9sumtrm.txt.Z	Interface jargon
vendorid.txt.Z	The current SCSI-2 Vendor ID List
x3t9_2.txt.Z	Introduction to X3T9.2 


File area: area02

pkz101.exe    ZIP file utility. Fastest, best compression.
dsz0208.zip   DSZ from Omen Technology
help4dsz.zip  Batch files to use ZMODEM from Procomm
opuser.zip    Opus Users Manual (The SCSI runs Opus)

---
files.bbs.Z	Listing of available files from the bbs as of 20 Jan 90


File area: area04

specify.txt   Read this file (You can type it online)
nbs_c.zip     'C' Source files, SCSI conformance test for Adaptec dev sys
nbs_exe.zip   Executable files
nbs_tp.zip    Test Procedure and Misc files

abstract.doc Abstract of the NIST project for testing
scsitest.zip The files including the Abstract

---
files.bbs.Z	Listing of available files from the bbs as of 20 Jan 90


File area: area05

90-001r0.txt.Z	1989 X3T9.2 Annual Report
90-004r0.txt.Z	32-bit on a single 110-pin connector (L cable)
90-005r0.txt.Z	16/32-bit P/Q cable stand alone document
90-006r0.txt.Z	16/32-bit P/L cable stand alone document
90-009r0.txt.Z	San Jose Working Group Minutes (1/9-10/90)
90-021r0.txt.Z	Additional SCSI Caching Control
90-023r0.txt.Z	Cable Working Group Minutes - Jan '90
90-025r0.txt.Z	March '90 Working Group Meeting Announcement

---
files.bbs.Z	Listing of available files from the bbs as of 20 Jan 90


File area: area06

--- Miscellaneous files --- 

fix_type.com  Lets you examine fixed disk types
ft.zip        a better fix_type than fix_type.com! 
scsiarb.zip   SCSI Arbitration Timing Model
smiley.txt    Assorted faces 8-) from Jeff Stai
strip_z.exe   Removes ^Z characters from text files
technote.zip  Mac Tech Note #96.  SCSI Problems. 
wsc.zip       A wordstar pagination program..simple. 
wscnvn.zip    WordStar File Conversion Utility - Useful!
wstxt.zip     WordStar to/from TXT w/ IBM graphics characters 

---
files.bbs	Listing of available files from the bbs as of 20 Jan 90



File area: area07

--- 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.)

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

17b.arc  

---
files.bbs	Listing of available files from the bbs as of 20 Jan 90



File area: area08

notice.txt.Z	Copyright Notice - Read this first
rev10b.zip	Shows just what changed from Rev 10 to Rev 10b
s2r10-op.zip	Opcode Spreadsheet
s2r10-pc.zip	Page Code Spreadsheet
s2r10asc.zip	Additional Sense Code Spreadsheet
s2r10b00.zip	Section 00 Cover Page and Table of Contents
s2r10b01.zip	Section 01 Scope        
s2r10b02.zip	Section 02 Reference Documents    
s2r10b03.zip	Section 03 Glossary and Editorial Conventions 
s2r10b04.zip	Section 04 Physical Characteristics   
s2r10b05.zip	Section 05 Logical Characteristics   
s2r10b06.zip	Section 06 SCSI Commands and Status   
s2r10b07.zip	Section 07 Common Section for All Devices  
s2r10b08.zip	Section 08 Direct-Access      
s2r10b09.zip	Section 09 Sequential-Access     
s2r10b10.zip	Section 10 Printer       
s2r10b11.zip	Section 11 Processor       
s2r10b12.zip	Section 12 Write-Once       
s2r10b13.zip	Section 13 CD-ROM        
s2r10b14.zip	Section 14 Scanner       
s2r10b15.zip	Section 15 Optical Memory Device    
s2r10b16.zip	Section 16 Medium Changer Device    
s2r10b17.zip	Section 17 Communications Device    
s2r10ba.zip	Section A Appendixes       
style.zip	SCSI-2 Style manual


File area: area11

diffprot.zip	SCSI-2 Fig: Differential Protection Circuit
icon.zip	SCSI Icon (not currently in the document)
noncbl.zip	SCSI-2 Fig: Nonshielded Cable A Connector
noncblb.zip	SCSI-2 Fig: Nonshielded Cable B Connector (Obs)
nondev.zip	SCSI-2 Fig: Nonshielded Device A Connector
nondevb.zip	SCSI-2 Fig: Nonshielded Device B Connector (Obs)
passdiff.zip	SCSI-2 Fig: Passive Differential Terminator
phwarb.zip	SCSI-2 Fig: Phase Diagram (Obs)
phwoarb.zip	SCSI-2 Fig: Phase Diagram (Obs)
s2_apx_a.zip	SCSI-2 Fig: Signal Sequence Diagram (DWG file)
sampcnfg.zip	SCSI-2 Fig: Sample Configurations
shldcbl1.zip	SCSI-2 Fig: Shielded Cable Alternative 1 (Obs)
shldcbl2.zip	SCSI-2 Fig: Shielded Cable Alternative 2
shlddev1.zip	SCSI-2 Fig: Shielded Device Alternative 1 (Obs)
shlddev2.zip	SCSI-2 Fig: Shielded Device Alternative 2
signlseq.zip	SCSI-1 Fig: Signal Sequence Diagram (Obs)
snapdxfr.zip	SCSI-2 Fig: Snapshot Prior to Data Transfer
snapsel.zip	SCSI-2 Fig: Snapshot Prior to Selection
termdiff.zip	SCSI-2 Fig: Differential Terminator
termse.zip	SCSI-2 Fig: Single-ended Terminator


File area: area13

atbuscam.txt.Z	The initial draft of the proposed ATBus device 
atbusmin.txt.Z	AT Bus Committee Minutes 3/9/89 
camdoc.txt.Z	CAM Working Document from 1/12/89 meeting
camsim.txt.Z	Merged SIM and Initialization Spec 
cl_ata.txt.Z	Cirrus Logic ATA rev. 1.2 Proposals
dal_prop.txt.Z	Layering and Control Blocks
dmaresrc.txt.Z	DMA Resource message from Greg Slaughter
dos_msg0.txt.Z	DOS OSD 
dos_osd.txt.Z	OSD interface spec for DOS 
dos_osd1.txt.Z	Revised DOS OSD proposal 
dos_osd2.txt.Z	Revised DOS OSD proposal 
init-int.txt.Z	Comments on Shishir's proposal 
issues.txt.Z	NCR presentation - ISSUES 
justify.txt.Z	Justification and call to arms
library.txt.Z	NCR SCSI Library Description 
min8810.txt.Z	Minutes of the October 19 meeting in San Jose
min8812.txt.Z	Minutes of the December 7 meeting in San Diego
min8901.txt.Z	Minutes of January 17 meeting in Irvine
min8902.txt.Z	Minutes of February 22 meeting in Austin
min8903.txt.Z	Minutes of March 8 meeting in Milpitas 
min8904.txt.Z	Minutes of April 13 meeting in Denver 
min8905.txt.Z	Minutes of May 10 meeting in Wichita
min8906.txt.Z	Minutes of June 8 meeting in Cupertino
min8907.txt.Z	Minutes of July 12 meeting in Chicago
min8908.txt.Z	Minutes of August 9-10 meeting in Costa Mesa
newidea.doc.Z	Rom/Ram Bios stratagy for backward compatiblity 
oct_unix.txt.Z	October Unix OSD notes and Nov Agenda.
pdiag.doc.Z	ATA PDIAG / DASP Timing Specification 
phy2log.txt.Z	phyical to logical conversiov C program 
phystolg.txt.Z	CONVERSION TO/FROM PHYS/LOGICAL CAPACITIES 
pick-chs.txt.Z	Algorithm to pick C/H/S values from # blocks 
structur.txt.Z	NCR CAM structure definition 
target.txt.Z	NCR proposal for section 9 of CAM Document
u9001041.txt.Z	Gallant's comments on Richman's proposal
u9001042.txt.Z	Bob Snively's Target Mode Proposal
u9001043.txt.Z	Unix-OSD Mailing list (Internet and UUCP)
u9001044.txt.Z	Richman's response to Gallant's comments
u9001061.txt.Z	Gallant's further remarks
unixosd.txt.Z	Interested parties UNIX-OSD, mail list


File area: area14

ipihppi.prt	Draft copy of IPI-3 Command Set on HPPI
ipihppi.txt	IPI-3--HPPI Proposed Standard 
iso1.zip	IPI-1 Physical Layer
iso2d.zip	IPI-2 Device Specific Magnetic Disk
iso3d.zip	IPI-3 Device Generic Magnetic and Optical Disk
l3tapcg.txt	Changes to stds from tape working group 
l3tapwg.txt	Feb 1 Tape Working Group Minutes 
rdeferr.txt	Revised std changes for deferred errors 
rl3tpwg.txt	Revised tape working group minutes 


File area: area16

89-139r1.prn.Z	Differences between ESDI Rev 3 and Rev 3A
89-139r1.zip	Differences between ESDI Rev 3 and Rev 3A
esdifigs.zip	Some ESDI Connector figures (.DXF files)
isoe.zip	ISO ESDI Draft International Standard (Rev 3A)


File area: area17

88-112r0.txt.Z	August '88 Fiber Optic Study Group Highlights
88-112r0.zip	August '88 Fiber Optic Study Group Highlights
88-129r0.txt.Z	August & September '88 Minutes
88-129r0.zip	August & September '88 Minutes
88-160r0.txt.Z	Fiber Channel Description
88-160r0.zip	Fiber Channel Description
89-020r0.txt.Z	December '88 Minutes
89-020r0.zip	December '88 Minutes
89-045r0.txt.Z	January '89 Minutes
89-045r0.zip	January '89 Minutes
89-141r0.txt.Z	January 1990 Meeting Announcement
fcdastre.zip	Los Alamos Fiber Channel Data Streaming paper 
fowg0689.txt.Z	June 22&23 FO Working Group Minutes 
fowg0689.zip	June 22&23 FO Working Group Minutes 
fowg0789.txt.Z	July 89 Fiber Channel Working Group Minutes
fowg0789.zip	July 89 Fiber Channel Working Group Minutes
fowg0889.txt.Z	August 23 Fiber Channel Working Group Minutes
fowg0889.zip	August 23 Fiber Channel Working Group Minutes
fowg0989.txt.Z	9/11&12 Fiber Channel Working Group Minutes
fowg0989.zip	9/11&12 Fiber Channel Working Group Minutes
fowg1089.txt.Z	10/16 Fiber Channel Working Group Minutes
fowg1089.zip	10/16 Fiber Channel Working Group Minutes
fowg1189.txt.Z	11/2&3 Fiber Channel Working Group Minutes
fowg1189.zip	11/2&3 Fiber Channel Working Group Minutes
fowg1289.txt.Z	Dec 89 FC Working Group Minutes 


File area: area18

89-001r0.txt.Z	X3T9.2 Annual Report
89-008r1.txt.Z	"Brief" Description of Density Code Operation
89-009r0.txt.Z	COPY and Partitioned Tape
89-010r0.txt.Z	REQUEST SENSE EOM data on Partitioned Tape
89-011r0.txt.Z	MODE SELECT Device Configuration Parameters
89-012r1.txt.Z	Separation of BOM and BOP0
89-013r1.txt.Z	9.2.13 SPACE Command, Rev 6a, page 9-30
89-016r1.txt.Z	Active Format field in Device config page
89-018r0.txt.Z	Preliminary Cable Test Results
89-019r1.zip	Costa Mesa Working Group Minutes Jan '89
89-020r0.txt.Z	Fiber Optic Channel Working Group Minutes
89-021r0.txt.Z	Tape Read Underlength Detection
89-023r0.txt.Z	Synchronized Sector Offset for ESDI
89-024r0.zip	When not to clear sense data
89-025r0.txt.Z	SEARCH DATA Transfer Length Inconsistency
89-028r1.brf.Z	Feb 89 X3T9.2 Minutes (ASCII w/o enclosures)
89-035r0.zip	Tape Read Overlength Detection w/SILI Bit
89-036r1.zip	SCSI-3 Preparations for New Physical Layer(s)
89-042r0.zip	Milpitas Working Group Minutes Mar '89
89-047r0.zip	NCR Proposal for a LOGICAL UNIT RESET Message
89-049r0.brf.Z	Apr 89 X3T9.2 Minutes (ASCII w/o enclosures)
89-050r1.zip	Dan Davies' proposed changes to S2R8 Section 9
89-053r0.txt.Z	Tom Wicklund's comments on S2R8
89-055r1.zip	Gene Milligan's comments on S2R8
89-058r0.zip	John Lohmeyer's X3T9 Letter Ballot on SCSI-2
89-061r0.zip	SCSI Bus Fairness Proposal (ZIP'd ws.Z	4)
89-066r1.zip	Wichita Working Group Minutes
89-068r0.zip	Maxtor Public Review Comment on ESDI
89-075r1.brf.Z	Jun 89 X3T9.2 Minutes (ASCII w/o enclosures)
89-090r0.zip	Chicago Working Group Minutes
89-094r6.zip	Single-cable 16-bit proposal
89-095r1.ws.Z	Read Sub-channel CD-ROM command fixes (SCSI-2)
89-101r0.txt.Z	Max Burst Size Rounding Definition
89-102r0.txt.Z	Another ESDI boo-boo cought by steely eyes
89-103r1.zip	Comments on r10 SCSI-2 document
89-108r0.zip	SONY proposal for CD-ROM device
89-109r1.zip	New Copy Segment Descriptors (Rev 1)
89-110r0.zip	Target Initiated SDTR Message Control
89-111r0.brf.Z	Aug 89 X3T9.2 Minutes (ASCII w/o enclosures)
89-120r0.zip	Oklahoma City Working Group Minutes
89-126r0.brf.Z	Oct 89 X3T9.2 Minutes (ASCII w/o enclosures)
89-130r1.zip	Packetized SCSI Proposal
89-133r1.zip	Multi-ported SCSI
89-138r0.zip	Santa Ana Working Group Minutes
89-139r1.zip	ESDI Changes 1/19/89 to 12/2/89 (Printer file)
89-140r0.txt.Z	WD public review comment/ASCII text
89-145r1.txt.Z	Proposed Additional Sense Code Qualifiers
89-149r0.brf.Z	Dec 89 X3T9.2 Minutes (ASCII w/o enclosures)
89-150r1.zip	16-bit single-cable Appendix Form
89-153r0.txt.Z	Minutes of SCSI Cable Impedance WG 12/4/89
89-161r0.txt.Z	Response letter to Alec Cawley (Quantel)

----------------------------------- cut here -----------------------------------







From owner-pc532%daver@mips.com Wed Apr  4 20:00:33 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
To: pc532@daver.bungi.com
Cc: Bruce Culbertson <culberts@hplwbc.hpl.hp.com>
Subject: Re: test code for pc532 
Date: Wed, 04 Apr 90 15:29:15 MST
From: Bdale Garbee <bdale@col.hp.com>

> Then download the file "image".  By the way, I think you can ftp my
> tools from Bdale's machine (hp-col.hp.com).  They may be slightly
> out-of-date.  The assembler and linker will run on a PC.

The machine is col.hp.com, aka hpcsos.col.hp.com, and I don't know if I put
your tools there or not.  Will check tonight.  

> I do not have a spare SCSI disk for testing.  The code has been ready for
> a week.  Any guinea pigs out there?  Send e-mail for a copy.  If it works,
> I will post it to the world.

Sorry, mail must have gotten lost.  It doesn't work on my system at all...
timeouts on request, no lights on the drive(s) I tried.

Bdale (in a C++ class all week... sigh)


From owner-pc532%daver@mips.com Wed Apr  4 23:39:37 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
X-Mailer: Mail User's Shell (6.2 5/11/88)
To: pc532@daver.bungi.com
Subject: Re: SCSI
Date: 4 Apr 90 19:55:50 PDT (Wed)
From: george@wombat.bungi.COM (George Scolaro)

[In the message entitled "SCSI" on Apr  4, 12:48, Mark Mason writes:]
> 
> Q1: Do you really need the ram to boot the pc532 enough to make the
> leds light and see the banner message? (I know that I will prob. have
> it assembled before I get the memory, don't know if I could wait any
> longer at that point to see if it works).

You certainly need the dram to get the banner message up. Remember that
most of Bruce's monitor is written in C (functions etc....). Dave posted
a RAMless monitor quite a while back, it is the NSC MON16 monitor and uses
the 532's data cache as ram. While not nearly as nice as Bruce's monitor, it
does allow a system to be brought to life with no DRAM.

best regards,

-- 
George Scolaro
george@wombat.bungi.com                [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com Wed Apr  4 23:39:46 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
To: pc532@daver
Subject: et532 board
Date: 4 Apr 90 20:22:24 PDT (Wed)
From: daver@wombat.bungi.COM (Dave Rand)

If someone is interested in kitting the ET532 board, please give me a call.

Dave Rand
+1 408 434-0600 X4555 work
+1 408 733-4125 home

From bdale@col.hp.com Thu Apr  5 10:53:49 1990
Flags: 000000000000
To: budd@bu-it
Subject: Re: test code for pc532 
Date: Thu, 05 Apr 90 07:52:31 MST
From: Bdale Garbee <bdale@col.hp.com>

> > > Then download the file "image".  By the way, I think you can ftp my
> > > tools from Bdale's machine (hp-col.hp.com).  They may be slightly
> > > out-of-date.  The assembler and linker will run on a PC.
> > 
> > The machine is col.hp.com, aka hpcsos.col.hp.com, and I don't know if I put
> > your tools there

> Bdale,

> I have Bruce's latest on BU.EDU (~ftp/users/budd/32k/Culbertson/newtools)

Great.  Do you want to pull the stuff in col.hp.com's ns32k tree?  I'd be
pleased to avoid the archive business...

Bdale

From ames!pacbell!zygot!ditka!kls@XN.LL.MIT.EDU Fri Apr  6 08:14:11 1990
Flags: 000000000000
Posted-Date: Fri, 6 Apr 90 2:43:57 PDT
Subject: Maxtor buys MiniScribe
To: pc532@daver.ARPA
Date: Fri, 6 Apr 90 2:43:57 PDT
Cc: ditka!pc532-disk-l (pc532 disks)
X-Mailer: ELM [version 2.2t PL7]
From: ditka!kls@XN.LL.MIT.EDU (Karl Swartz)

According to the Thursday, April 5th San Jose Mercury News,
Maxtor was announced the winner of an auction of MiniScribe
Corp. ordered by the bankruptcy court.  The deal will push
Maxtor past Conner to the number two position in the disk
industry, still behind Seagate Technology.

According to the article, Maxtor will continue producting
the MiniScribe line.  Presumably this refers only to the
3 1/2" disks, the only ones produced since the bankruptcy
filing.  In particular, the 9380S (many of which will soon
be attached to pc532s) would directly compete with Maxtor's
own 4380S, so it's unlikely this drive will go back into
production.

FYI ...

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


From owner-pc532%daver@mips.com Thu Apr  5 07:17:20 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
To: pc532%daver@pyramid
Subject: Whoops.
Date: 5 Apr 90 10:16:20 MSZ (Thu)
From: jkh@meepmeep.pcs.com (Jordan K. Hubbard)

Sorry, ignore my last comment about Ian. Seems I have a short memory
(as a quick peek through the pc532 archives has indicated). My only problem
is that I'm in West Germany and don't have access to ftp (as I'm sure is
also a problem with others on this list). Given that I already have copies
of the vanilla GCC 1.37.1, GAS 1.35 and the latest binutils (GLD et al),
I just need whatever's necessary to patch them up to the same level as whatever
Ian has since I really desperately need some sort of C development
environment that will let me generate, at best, the "stand-alone" binaries
expected by Bruce's monitor (I assume that Ian patched gld to allow this
also?) and at worst COFF binaries (the COFF gas is no problem, since we've
already modified stock GAS 1.35 to do AT&T spec COFF and I would only have
to merge the two). In either case, I have a directory full of memory test
algorithms in C donated by our hardware group (that we use in our own
workstation ROM) that I'm just itching to compile and test. If the hardware
group has no objections (and I don't see why they would), I'll then ship the
images (assuming they work) to Bruce for inclusion in the next ROM.

If COFF is all I end up being able to produce, that's no real problem
either since we intend to port PCS's "Minitor" to the pc532 (it's much more
fully featured than Bruce's monitor) as well and it can download COFF images.
The only hurdle will be bootstrapping the Minitor itself.

Bruce promised to send me his loader and assembler and then vanished from
sight. I just came up with an idea of how I might be able to get all this
stuff sent to me, but I'm not sure that it will pan out. Given that I
don't have luck in this area, is there anyone out there who'd be willing
to send me all this stuff? If so, send me some mail and I'll let you know
whether or not I still need it.

Thanks..

				Jordan



From owner-pc532%daver@mips.com Thu Apr  5 07:19:07 1990
Flags: 000000000000
Sender: owner-pc532@daver.bungi.com
Reply-To: pc532@daver.bungi.com
Date:  5 Apr 90 16:48:13 +1100 (Thu)
From: neil@wcc.oz.au (Neil Murray)
Subject: Re: Gee, can it be THIS simple, 4070's & ICM's
To: pc532@daver.bungi.com
Date: Thu, 5 Apr 90 16:48:11 EST
From: Neil Murray <neil@wcc.oz.au>
X-Mailer: ELM [version 2.2 PL16]

| Or, can I be this DUMB! (yup! U betcha..)
| My adaptec 4070 controller has no parity, so I carefully jumpered
| the drive for no-parity...Hmmmmm...but I didn't check the ICM,
| ASSUMING that it's set for no-parity.

	I seemmed to have missed to start of this thread.  But for what its 
worth my ICM is running off a 4070 controller with no problems (from memory I 
don't run parity).

-- 
Neil Murray  (R&D Dept)			Phone:  (03) 764 1100	   
Webster Computer Corporation P/L	Fax:	(03) 764 1179
1270 Ferntree Gully Rd,  Scoresby	ACSnet: neil@wcc.oz	
Victoria,  Australia, 3179.		

From owner-pc532%daver@mips.com Thu Apr  5 07:43:55 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
From: mea@mea.utu.fi (Matti Aarnio)
Subject: Re: Whoops.
To: pc532@daver.bungi.com
Date: Thu, 5 Apr 90 13:19:33 EET
X-Mailer: ELM [version 2.2 PL10]

>      My only problem
> is that I'm in West Germany and don't have access to ftp (as I'm sure is
> also a problem with others on this list).

  I have supported several archive sites with anonymous FTP robot which
is able to receive commands and return responses in mail.

  Most of your interest material is available from  LISTSERV@MAMMUTTI.UTU.FI
(I hope you know how to use LISTSERV in general - BITNET thing) with command:
(Directory listing:)
/PDDIR FUNIC.FUNET.FI:disk1/pub/gnu/unsupported/ns32k.mods/* 9999
(Files:)
/PDGET FUNIC.FUNET.FI:disk1/pub/gnu/unsupported/ns32k.mods/gas-patch1.0.Z UUE
(Trouble is that line must not be longer than 80 chars...)
(Help about /PDGET is available with:  /PDGET HELP)

...
> Thanks..
> 				Jordan

	/Matti Aarnio	<mea@mea.utu.fi>
			<mea@funic.funet.fi>
	FUNIC:  Finnish Academic and Research Network Project
		Network Information/Software Archival Service
	OH1MQK - Radio Amateurs do it in Super High Frequency (10GHz)


From owner-pc532%daver@mips.com Thu Apr  5 11:47:32 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
To: pc532%daver@pyramid
Subject: Simple assembler?
Date: 5 Apr 90 13:29:17 MSZ (Thu)
From: jkh@meepmeep.pcs.com (Jordan K. Hubbard)

It would be really nice to have a mini-assembler in the ROM somewhere
(something like what used to sit at address F666 in the Apple II ROM).
Any assembler jocks out there care to bite? I admit it, I'm lost without
a C compiler.

				Jordan

From owner-pc532%daver@mips.com Thu Apr  5 11:47:38 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
To: pc532%daver@pyramid
Subject: Bigger ROM?
Date: 5 Apr 90 13:52:44 MSZ (Thu)
From: jkh@meepmeep.pcs.com (Jordan K. Hubbard)

The monitor we'd like to port is 128K (!) and we're wondering if
there's any (reasonably easy) way to use a larger ROM in place of
U44. I know that certain members of the ROM family are pin compatable,
but I have no idea how far this goes. Any answers?

				Jordan

From owner-pc532%daver@mips.com Thu Apr  5 11:55:46 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
X-Mailer: Mail User's Shell (6.2 5/11/88)
To: pc532@daver.bungi.com
Subject: Re: Bigger ROM?
Date: 5 Apr 90 08:22:41 PDT (Thu)
From: george@wombat.bungi.COM (George Scolaro)

[In the message entitled "Bigger ROM?" on Apr  5, 13:52, Jordan K. Hubbard writes:]
> 
> The monitor we'd like to port is 128K (!) and we're wondering if
> there's any (reasonably easy) way to use a larger ROM in place of
> U44. I know that certain members of the ROM family are pin compatable,
> but I have no idea how far this goes. Any answers?

No, you need extra address lines and they aren't there. the only way to get
a larger EPROM is to cut the trace from pin 1 (U44) to the capacitor. This
trace is +5V and is on the back of the PCB (wasn't that nice of me, I could
have tied it to the power plane!). Then run a trace from it to A15 from the
32532. You can they use a 27512-200ns. Of course this only gives you 64
Kbytes, the >= 128 Kbyte EPROMS are 32 pins. Maybe you can compress the
code... or boot from a hard disk :-)

I dunno, what more do you want! The original wirewrap board had only
4 Kbytes :-)


best regards,


-- 
George Scolaro
george@wombat.bungi.com                [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com Thu Apr  5 12:07:37 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
To: pc532@daver.bungi.com
Subject: Re: formatting MS drives 
Date: Thu, 05 Apr 90 06:26:07 MST
From: Bdale Garbee <bdale@col.hp.com>

> I was able to format the drive with the ICM commands, as well as
> the i <chan> mode. I used i <chan> as the final, since I wanted a
> 1-interleave. One drive is working fine on daver.bungi.com, the
> other is on the pc532. 

I have successfully formatted and am running two of my drives on my HP9000/350
workstation.  The biggest problem I had to deal with was that HP wants to have
the geometry described in terms of 1k sectors, and with 36 physical sectors
per track, and one reserved as a spare, the drive has 17.5k per track.  So, I
had to mangle the disktab entry to look like 17 sectors, 15 heads, 1280
cylinders to get a total sector count that matched the drive.

Doesn't matter that the geometry isn't "real" in this case, since the SCSI
driver on this system ignores the geometry and treats the drive as N sectors,
but it was annoying enough that I thought it was worth mentioning for anyone
else who might use an HP or similar workstation to build their pc532 disks...

I can mail a set of disktab entries for the 350 to anyone interested.  They
work for me...

Bdale

From owner-pc532%daver@mips.com Thu Apr  5 15:52:33 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
Date: Thu, 05 Apr 90 11:24 PST
From: Mark Geisert <Mark-Geisert@l66a.ladc.bull.com>
To: pc532@daver.bungi.COM
Really-To: pc532@daver.bungi.com
Subject: FTP server available via e-mail

I have successfully used the FTP server mentioned in the following.
It works, and I'm not even on BitNet.
-----------------------cut here---------------------------------------
TCP-IP: 7358 (sent 04/04/90 14:30)
To:       TCP-IP
From:     'Lee C. Varian'
Reply-to: LVARIAN@PUCC.PRINCETON.EDU
Subject:   Re: Bitnet ftp ?
 
On Thu, 29 Mar 90 04:18:35 GMT Don Gilbert said:
>Can someone direct me to info about bitnet-ftp or bitftp?
>I know it exists somewhere:  a gateway that converts
>bitnet messages to ftp calls, and returns the ftp results thru
>bitnet.
 
Don,  BITFTP is a server provided on the Princeton University VM system
to allow BITNET/NetNorth/EARN users to ftp files from sites on the
Internet.  BITFTP currently accepts requests only via RFC822-format
mail, IBM NOTE-format mail, PROFS-format messages, or files with no
headers at all.  BITFTP currently returns the requested files as
NETDATA-format files or as mail files containing UUENCODED data.
(Since BITFTP accepts RFC822-format mail, other users such as UUCP
mail-only sites are also able to use BITFTP to retrieve ftp files.)
 
For more details on the use of BITFTP, send a mail message to BITFTP
containing a single line in the message of HELP.  The address for
BITFTP is BITFTP@PUCC (BITNET) or bitftp@pucc.princeton.edu (Internet).
  Lee Varian
  Princeton University
 
-----------------------cut here---------------------------------------
 
..mark  (Mark-Geisert@LADC.Bull.COM or ..!uunet!ladcgw!Mark-Geisert)

From owner-pc532%daver@mips.com Thu Apr  5 18:13:19 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
Date: Thu, 5 Apr 90 13:30:01 PDT
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: gs@vw25.chips.com (George Scolaro)
To: pc532@daver.bungi.com
Subject: Re: Hmmm. Confusion?

[In the message entitled "Hmmm. Confusion?" on Apr  5, 18:48, Jordan K. Hubbard writes:]
> 
> I know you called for the 74AS280, what I want to know is whether it's
> ok to subtitute the 74F280 for it.. I guess I'll assume that it is or

Well, I posted about that too. You have to use the 74F280A or B, preferably
the B (the A is slower). Signetics makes the 74F280A and B. NSC doesn't.

> board will fuse into slag". :-)

More likely it will just crash in a heap!

> Can I assume that it'll be included with Bruce's next release of the

No, I meant you have to write it...

regards,

-- 
George Scolaro (gs@vw25.chips.com)	Chips & Technologies
+1 408/434-0600 X4556 work		3050 Zanker Road
					San Jose, CA  95134

From owner-pc532%daver@mips.com Fri Apr  6 09:57:45 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
Subject: Maxtor buys MiniScribe
To: pc532@daver
Date: Fri, 6 Apr 90 2:43:57 PDT
Cc: ditka!pc532-disk-l (pc532 disks)
X-Mailer: ELM [version 2.2t PL7]
From: ditka!kls (Karl Swartz)

According to the Thursday, April 5th San Jose Mercury News,
Maxtor was announced the winner of an auction of MiniScribe
Corp. ordered by the bankruptcy court.  The deal will push
Maxtor past Conner to the number two position in the disk
industry, still behind Seagate Technology.

According to the article, Maxtor will continue producting
the MiniScribe line.  Presumably this refers only to the
3 1/2" disks, the only ones produced since the bankruptcy
filing.  In particular, the 9380S (many of which will soon
be attached to pc532s) would directly compete with Maxtor's
own 4380S, so it's unlikely this drive will go back into
production.

FYI ...

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

From owner-pc532%daver@mips.com Sat Apr  7 15:10:03 1990
Flags: 000000000001
Reply-To: pc532@daver.bungi.com
Date: Sat, 7 Apr 1990 10:59:05 +1000
From: ian@sibyl.eleceng.ua.oz.au
To: pc532@daver.bungi.com
Subject: Whoops.

Jordan K. Hubbard writes:
 > Given that I already have copies
 > of the vanilla GCC 1.37.1, GAS 1.35 and the latest binutils (GLD et al),
 > I just need whatever's necessary to patch them up to the same level as whatever
 > Ian has since I really desperately need some sort of C development
 > environment that will let me generate, at best, the "stand-alone" binaries
 > expected by Bruce's monitor (I assume that Ian patched gld to allow this
 > also?) and at worst COFF binaries (the COFF gas is no problem, since we've
 > already modified stock GAS 1.35 to do AT&T spec COFF and I would only have
 > to merge the two).

No, gld does not generate down loadable images. It generates a.out
format executables or coff executables. The coff executables are GNU's
encapsulated a.out format. That is, as far as finding the start and
end of the text and data sections you can treat them exactly like a
coff file, the symbolic debugging information however is a.out/dbx.
Note that I have only tested gld in a native environment. There seem
to be no major obstacles to making it work in a cross development
environment and I expect to have that working this weekend (on a
sun4).

I haven't done anything about down loading images because a) I don't
know how to talk to Bruce's monitor and b) My pc532 isn't up yet.

It strikes me, however, that this should be a seperate utility
(extract code from a.out file and down load it). I have saved away
somewhere a copy of the program Bruce posted to do the down loading.
That should be a starting point. Anyone want to do it?

Bruce, does the monitor assume that certain ram won't be touched by
programs? The default output of the loader is relocated to start at
virtual address 0. I suspect that might be a problem if virtual
address 0 is mapped to physical address 0! What about interrupt/trap
vectors? One solution might be to just link in as the first module
in a program something which just has a .org directive, however,
some smarts might be needed to make sure that the down loader doesn't
simply write zeros between address 0 and the start of the code.

Ian.


From info-mach-Request@SPICE.CS.CMU.EDU Sun Apr  8 18:57:52 1990
Flags: 000000000000
Date: Sun, 8 Apr 90 15:36:18 PDT
From: Thomas Jagodits <jagodits%redwood@hub.ucsb.edu>
Posted-Date: Sun, 8 Apr 90 15:36:18 PDT
To: info-mach@CS.CMU.EDU
Subject: restore question

I have been having segmentation faults with restore under Mach as 
described below.
Actually it gives a segmentation fault for add and extract as well, 
usually when there is a parameter.

		thomas		(jagodits@cs.ucsb.edu)

-----------------------------------------------------------
Script started on Sun Apr  8 15:25:26 1990
% mt -f /dev/rst8 rew
% mt -f /dev/nrst8 fsf 1
% /etc/restore ibf 1024 /dev/rst8
restore > ls
.:
 RFS/          dev           lost+found/   stand/        vmunix
 bin           etc           mach          tmp
 boot          lib           mnt           usr

restore > cd lost+found
Segmentation fault
% exit
% 
script done on Sun Apr  8 15:27:24 1990
-----------------------------------------------------------

From owner-pc532%daver@mips.com Mon Apr  9 13:31:59 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
Date: Sat, 7 Apr 90 11:54:07 mst
From: Bdale Garbee N3EUA <bdale%winfree@hp-col.col.hp.com>
To: pc532@daver.bungi.com
Subject: drives

3 of our 4 drives work great on my workstation.  The fourth appears to format
ok, but newfs fails with no space left on device.  The format also doesn't
take long enough.

This leads me to believe the geometry spec on the drive is wrong, will poke
around later with a logic analyzer and scsi preprocessor and see what the
MODE SENSE command is returning.  If it's wrong, a MODE SELECT ought to fix
it...

Bdale


From owner-pc532%daver@mips.com Mon Apr  9 15:10:10 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
To: pc532%daver@pyramid
Subject: Another pc532 lives...
Date: 9 Apr 90 19:50:23 MSZ (Mon)
From: jkh@meepmeep.pcs.com (Jordan K. Hubbard)

My pc532 came up 10 minutes ago. It was a bad C23 pulling bar-bclk down.
I yanked C23/C24 (and the pullup resistors R3/R7/..) during the debugging
process and don't see any particular reason to put them back, since everything
works. Is this reasoning false?

2 working pc532's in Germany now..

Yeaaa........


					Jordan

From owner-pc532%daver@mips.com Mon Apr  9 15:35:36 1990
Flags: 000000000001
Reply-To: pc532@daver.bungi.com
To: pc532@daver.bungi.com
Subject: A whole host of downloading noise
Clarity-Index: null
Threat-Level: none
Quote-Of-The-Moment: Termoter messesers temperrs.  -- A 4th grader
What-Was-Meant: A thermometer measures temperature.
Date: Mon, 09 Apr 90 09:07:34 CDT
From: Jon Loeliger <loeliger@convex.com>


Jdl's rambling response to Ian's response to Jordan's questions:
 
> No, gld does not generate down loadable images. It generates a.out
> format executables or coff executables. 
>...
> to be no major obstacles to making it work in a cross development
> environment and I expect to have that working this weekend (on a
> sun4).

Bob Miller and I also have it a cross-development from a Convex.  As I
recall, though, he had to do some fairly grimy HOST-vs-TARGET BYTE_ORDER
munging.  Also there is a problem near the tail end of modify_location()
in ld.c (I believe) where outheader has been externalized, then used in
the target sense, then used in the host sense when the correct sequence
should be either:
	externalize_header(&outheader)
	use it in the target sense
	internalize_header(&outheader)
	use it in the host sense
or:
	freeze the host's value
	externalize_header(&outheader)
	use it in the target sense
	use the frozen value in the host sense

I think there were a few other bugs we had to fix.  I'll see what I can
do to get a good set of diffs against a current "release" of the binutils.

(Hey Bob, if I'm totally wet, tell us what you *really* did...)


> Bruce, does the monitor assume that certain ram won't be touched by
> programs?

Yes.  Upon power or reset, my monitor states:
	NS32000 ROM Debugger
	Version: Wed Mar 28 09:31:00 PST 1990
	RAM free above 0x14b4

(BTW, Bruce, dates are fine with me as Rev numbers.)

> The default output of the loader is relocated to start at
> virtual address 0. I suspect that might be a problem if virtual
> address 0 is mapped to physical address 0!

Yea.  I think you'll need to supply a -T 2000 or some such to the loader
(linker) to get it to offset addresses above used RAM.  I've tried writing
GLD code that uses the .org pseudo, but it doesn't seem to be too effective
yet.  Also, I haven't personally checked that *all* the relocatables
are really relocated taking into account the -T number.  (Anyone else
verified this yet?)  (Bob and I are taking the FSF binutil code with
a bit of skepticisim still, as if it were still alpha-release code,
pretending that each flag doesn't work until proven.)

> What about interrupt/trap vectors?

Yea, this touches some questions I had too...

When the monitor fires up new user code via the "run" or "step" command,
is that code in supervisor or user mode?  Also, what is the state of the
virtual memory mapping?  I know that the EPROM has been SWAPed out and
is now located at some bignum address, but I suspect that all the remaining
addressing is still physical (needing real OS support to get virtual...)
I'm sure one of these bits:
	psr=ipsunzfvltc
tells me the answers, but I'm not sure that this is the exact set that
the "run/step" code will inherit...
Also, where is the (user?) stack when the "run/step" code fires up?
I see a:
	usp=ffc
But, I don't know if this is reliable.  Should or shouldn't we explicitly
set it to some Good RAM to run our code?  Does the monitor rely upon this
stack?  I know that some of Bruce's code is written in C, so presumably
there's a stack in there somewhere...  


> One solution might be to just link in as the first module
> in a program something which just has a .org directive, however,
> some smarts might be needed to make sure that the down loader doesn't
> simply write zeros between address 0 and the start of the code.

Well, the loader does zero fill if the -T flag is used.*  The download
command can be told where to start filling memory.  You probably have to
get some agreement between the -T option to ld and the download command
(user probably has to intervene and type the same address twice...).

> It strikes me, however, that this should be a seperate utility
> (extract code from a.out file and down load it). I have saved away
> somewhere a copy of the program Bruce posted to do the down loading.
> That should be a starting point. Anyone want to do it?

Yea.  Recall though, that you may want to modify the checksum printing
in Bruce's program to be on stderr and not stdout (where the data is
placed).  

I asked earlier about an exec->download command, and got a good "dd" answer.
So, putting it all together I get:

	#!/bin/csh -f 
	dd if=a.out of=image bs=1k skip=1
	( stty raw -cstopb cs8 -parenb ; download image ) > /dev/ttyb

Where you may have to vary the stty options, and choose a different tty
line.  Care might be necessary with the bs size.  I need 4k, you may need
1k.  "download" is Bruce's download code as posted a while ago.  If you
actually use the -T option to ld to produce an image at, say, -T 2000,
you may need to stip off more than just the a.out header before you
download. 

(Obviously, I don't have and kernel exec() that is laying down segements
in a Good Place yet, so...) I don't have an ellegant solution for the
.data section and currently tacitly assume that it is either in the .text
segment or follows it closely enough that it just gets downloaded right
next to the .text.

jdl
------------------------------------------------------------------------------
Jon Loeliger			    | loeliger@convex.com
Convex Computer Corporation	    | I'm the thirteenth at your table,
3000 Waterview, Richardson TX 75080 | I'm the uninvited guest.  - Marillion

*  Actually, I think the loader my seek to the right -T implied offset,
leaving a gap in the a.out file which is probably filled with zero's by
your favorite OS upon attempting to read it.  (I could easily be wrong.)

From owner-pc532%daver@mips.com Mon Apr  9 16:39:32 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
Date: Mon, 9 Apr 90 12:54:41 PDT
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: gs@vw25.chips.com (George Scolaro)
To: pc532@daver.bungi.com
Subject: Re: Another pc532 lives...

[In the message entitled "Another pc532 lives..." on Apr  9, 19:50, Jordan K. Hubbard writes:]
> 
> My pc532 came up 10 minutes ago. It was a bad C23 pulling bar-bclk down.

Great. I feel much happier now, since the PCB's were all electrically tested
for opens and shorts by West Coast Circuits and I would have been depressed
to find they had a reliability problem. They are meant to be a very good
pcb house, and I'm glad to see that their reputation has not been tarnished.

> I yanked C23/C24 (and the pullup resistors R3/R7/..) during the debugging
> process and don't see any particular reason to put them back, since everything
> works. Is this reasoning false?
		^^^^^^^^^^^^^^^^
Yes. The caps are needed to keep the timing of the 32532 'correct'.
NS specs the part with 50pf load (min). I have also found that the FPU can
have problems (!) if the caps are not there. The termination also cleans the
clock lines up. So, please put the parts back in, 'cos even though it will
all work, you may/will have reliability (crashing etc) problems later.

> Yeaaa........

Congratulations, so far we haven't had any totally DEAD boards...

best regards,

-- 
George Scolaro (gs@vw25.chips.com)	Chips & Technologies
+1 408/434-0600 X4556 work		3050 Zanker Road
					San Jose, CA  95134

From owner-pc532%daver@mips.com Tue Apr 10 19:29:59 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
Date: Tue, 10 Apr 90 11:12:26 pdt
From: Bruce Culbertson <culberts@hplwbc.hpl.hp.com>
To: pc532@hplwbc.hpl.hp.com
Subject: Monitor questions

Ian and Jon Loeliger had a bunch of questions about RAM used by the
monitor and the environment which is set up by the monitor for user
programs.

The monitor's various show-register commands (cpu, gpr, fpu, mmu)
tell you what will be loaded into the real registers if you execute
the monitor's "run" or "step" commands.  This, in conjunction with
the 32532 data sheet, will tell you a lot about what is going on.
With the monitor's "set" command, you can change what will be
loaded into the registers.

When you run "cpu", you will see that the value of PSR is printed
with mnemonics.  A lower case character means the corresponding
bit is 0; it's 1 otherwise.  Unfortunately, you cannot "set" the
psr mnemonically.  Thus, to set user mode and user stack, do
something like

	set psr psr+300

When the machine is booted, MSR is 0, which you should be able
to confirm with the "mmu" command.  This means no translation
in either user or supervisor state.  Again, you can change this
with "set".

The monitor is not smart enough to know if you have set the
registers to an unreasonable configuration.  It is also possible
to set the registers in such a way that you render the monitor
useless.  For example, you can change the MSR to translate in
supervisor mode, but provide no page table.  Then if you execute
"run" or "step", the monitor will fly off into outer space.

Here is a run-down on the memory map.

	0x20		module table (just enough for interrupts to work)
	0x40		interrupt table
	?-0x7ff		monitor's stack (you do not need to know this)
	0x800-0xbff	interrupt stack
	0xc00-0xfff	1K default user stack space
	0x1000-?	monitor's data and bss segments

The message

	RAM free above 0x14b4

printed when the monitor boots tells you the top of the monitor's
BSS segment.  Load your programs above this address if you want
to be able to use the monitor.

If you want to write code which uses interrupts, I suggest you add
to, or modify, the monitor's interrupt table rather than create a
new interrupt table.  This way, the monitor can continue to catch
TRACE and BREAKPOINT traps so that you can use the monitor for
debugging.

> When the monitor fires up... what is the state of the
> virtual memory mapping?  I know that the EPROM has been SWAPed out and
> is now located at some bignum address, but I suspect that all the remaining
> addressing is still physical (needing real OS support to get virtual...)

The swapping is done by the address decoder PAL, not the MMU.  The
MMU mapping remains physical until you change MSR and execute "step" or
"run".

> [what does this mean?]
>	psr=ipsunzfvltc

See the PSR description in the 32532 data book.

> Also, where is the (user?) stack when the "run/step" code fires up?
> I see a:
>	usp=ffc

There is a 1K stack set up for your use.  The monitor does not use it.
There also is a 1K interrupt stack which, in a small way, is shared by
your program and the monitor.  If an exception occurs which is caught
by the monitor, the monitor will pop the PC and PSR/MOD from this
stack.  To return to your program, it will push the PC and PSR/MOD
back onto this stack and execute a RETT.  The monitor puts a return
address on the top of each stack so that your program can execute
a "ret 0" instruction to return to the monitor.  You could also use
SVC or BPT instructions to return to the monitor.

There were some questions about downloading.  The download program
I posted had a thorough (I hope) description of the protocol.
This is an independent issue, of course, from finding the code in
your a.out file.  For my tools, use

	dd if=a.out of=image bs=1k skip=1

to extract the code.  (Actually, if you compile my linker with NS32532
#define'd, then use skip=4.)  For other tools, you have to figure
it out yourself.

Bruce Culbertson

From owner-pc532%daver@mips.com Wed Apr 11 12:55:17 1990
Flags: 000000000000
Reply-To: pc532@daver.bungi.com
Date: Wed, 11 Apr 90 11:18:38 -0500
From: bob von borstel <vonb@iitmax.iit.edu>
To: pc532@daver.bungi.com

I'm still waiting for my board, but having read the prelim doc, I was wondering
what type pc power supply I should use.  Given the fact that the board is a 'baby-AT' and could easily fit in an xt/at platform, would 150 watts be sufficient?
Or for a few $ more 220 watts?  I imagine the type of scsi hard drive is a 
main determinant, especially if you don't buy the latest and greatest (read
3.5" :) drive.  Just wondering what everyone else is using.

From owner-pc532%daver@mips.com Thu Apr 12 13:37:44 1990
Reply-To: pc532@daver.bungi.com
Date: 12 Apr 90 11:11:24
From: Steven.D.Ligett@mac.dartmouth.edu
To: pc532@daver.bungi.com
Subject: Re: Parts Kits!

--- I wrote:
...I'll be faxing and
phoning parts lists to distributors tomorrow (Monday, April 2), and I hope to
have everything arranged by a week from then, April 9th.  I'll post a list of
parts and costs then.  And I'll have some arrangement for taking orders by
then too....

Would anyone be interested in slower parts (i.e. 20 Mhz vs 25 Mhz) if that
would save a lot of money?  I haven't looked, so I don't know if there's much
difference in costs at 20 Mhz.
...
--- end of quoted material ---
Ok, this has taken longer than I expected.  I'll have initial prices from most
of the distributors this week, then there will be some give and take, and
parts changes, etc.  I need to get a better idea of how many of you want what
parts.  I sent the whole BOM to the distributors - from resistors & caps on up
to the cpu and fpu.  So, if you want everything, I expect to have it. 
Probably some of you only want some of it.  If you want some or all of it, try
to send a note to me at:

pc532-parts@dartmouth.edu

That will keep it separate from lower priority mail I get, like notes from my
boss. (If that address doesn't work for you, there is probably some address
for me in the header of this message.)  Tell me if you want everything, or
just the cpu, fpu, icu, other logic, connectors and sockets, bits & pieces. 
Oops, and memory.  If you can keep it to those categories, that'd be great.

Now, prices I have.

1.  My favorite distributor is Cronin, and they gave me a price of $75 each
for Toshiba SIMMS: thm81000as-80.  Genuine Toshiba simms, 1-meg by 8, 80 nsec. 
So, I'll have memory at or below that price.  How many want memory?  (How many
want parity memory?  I don't have a price for that yet.)  (A plug for Cronin -
they're a New England distributor, they always call me back, give me good
prices, ask reasonable questions, research and suggest substitutions, supply
samples, etc.)

2.  cpu & fpu.  Yikes.  I hadn't realized how good a deal the folks in the
first batch got.  So far I've only gotten "book prices"; Dave's going to try
to help me twist some arms. 

cpu 25 mhz: $595
cpu 20 mhz: $520
fpu 25 mhz: $297
fpu 20 mhz: $222

Please tell me if you want these, and which speed you want.  Maybe better
prices next week.

Those are the most important prices I have.  I've got more that I've gotta put
into my spreadsheet, as soon as I finish (start!) my taxes.  Next week I'll
have to scrounge around for the real oddball parts (the ones that all the
distrib's reply "nobid").  Specific questions on parts, write to me at
pc532-parts@dartmouth.edu; any discussion, let's keep it in the mailing list.

Oh, I mean to go to my bank, and get set up to take Visa and MasterCard. 
Maybe that'll make payment easier for some.  (I used to take "plastic" (for my
business), but switched banks, and never bothered to arrange it again.  It's
time to try it again.)

From owner-pc532%daver@mips.com Sun Apr 15 05:32:26 1990
Reply-To: pc532@daver.bungi.com
X-Mailer: Mail User's Shell (6.2 5/11/88)
To: pc532@daver
Subject: et532
Date: 14 Apr 90 17:37:57 PDT (Sat)
From: george@wombat.bungi.COM (George Scolaro)

Hi Folks,
	well I have finally finished off the et532 and piggyback board.  The
et532 was already routed a long time ago, but I finished adding some of
design features of the pc532 into it. Of course this involved changes to the
already routed et532, which is never easy to do. The piggyback board
contains the Motorola RS232 transceivers and 10 pin headers (same as on the
pc532). There are 16 serial channels supported by the piggyback board. We
had originally thought of putting RJ sockets (the 8 pin variety) onto the
piggyback board, but they would have taken more space and would still have
required figuring some way of getting them to a back panel on the chassis.
Using the 10 pin headers enables DB9 (or DB25 with a converter as for PC/ATs)
to be mounted onto the back of the chassis.

	I will generate the gerber files and on Monday get some quotes from
a few PCB houses. I'd like to use West Coast Circuits again, but they are a
bit pricey (but very good). I recently got some boards done at another house
and will get a quote from them, they also did good work. For those that are
interested, the et532 is a 6 layer PC/AT sized (but with 62 pin SCSI) board.
The piggyback board (after a bit of a fight with the CAD software) is a 2
layer board and is around 5.5" x 3.5". It plugs into the middle area of the
et532 on two connectors that carry all the serial (TTL) signals up from the
2 OCTARTs.  There are also 3 sets of holes on both boards that line up and
enable nylon standoffs to support the piggyback board.

	The first run will probably by 5 PCBs (of each board) which is about
the minimum cost effective quantity. Dave has got one of the local
distributors doing a quote for all the parts on the board (except for a
couple of things they don't do). We aren't planning to kit the et532, but
at least one of the pc532 subscribers has indicated an interest. We'll keep
you up to date on the progress in this area.

Some specs for the et532 follow (for those that don't keep copies of past
history):

	20MHz 32gx32, no FPU.
	1M/4M DRAM (256kx4 or 1mx4) 100ns or faster, fast page mode.
		same performance as pc532 (except at 20MHz, i.e. 40Mbytes/sec)
	128kx8 EPROM (200ns or faster) Boot EPROM, runtime code is downloaded
		from pc532 etc. into DRAM.
	16 serial channels with full modem control (Signetics SCN2698B octart)
		RX,TX,RTS,CTS,DTR,DCD  (modem support)
	Ethernet, thin (cheapernet) and thick (DB15 connector) NS chipset
	SCSI, DP8490 (via 62pin edge connector and 50 pin SCSI connector)

best regards,

-- 
George Scolaro
george@wombat.bungi.com                [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com Sun Apr 15 06:29:55 1990
Reply-To: pc532@daver.bungi.com
X-Mailer: Mail User's Shell (6.2 5/11/88)
To: pc532@daver
Subject: pc532 pals
Date: 14 Apr 90 18:27:42 PDT (Sat)
From: george@wombat.bungi.COM (George Scolaro)

Hi Folks,

I have recently switched from using CUPL to using Tango-PLD.  Following are
all the pc532 pal equations in the Tango-PLD format.  They are 100%
compatible with their respective CUPL cousins. All new pal equation updates
(none so far) will be in the Tango format. Also, all pal equations for the
et532 are also in the Tango format. The main advantage of Tango is that it
is a lot faster than CUPL, 10x on most things and the Espresso optimizer
does a better job in some cases. Also, the price is right ($495) as against
$1500 for CUPL. The last CUPL upgrade was $200, and since Tango offers 1 year
free upgrades and low (must be less than $200 right?) upgrades after that, I
decided to purchase Tango. It has a nice 'C' like syntax and I prefer some
of the state machine constructs (very similar to CUPL but a bit better).
It's only drawback (unless there is a better way) is that the address
decoding syntax is a bit clumsier (but more rigorous). Anyhow, here it is:

---------------cut--------------
/************************************************************************/
/* This pal does 2 refreshes back to back, 2 t-state ras refresh, and	*/
/* 0 wait states on initial read or write if within a page.		*/
/* This pal generates ras/cas timing for all dram accesses including:	*/
/* - cas before ras refresh (with precharge before & after refresh)	*/
/* - page miss with re-ras, read or write (with precharge)		*/
/* - page hit with cas access (for write)				*/
/* - page hit with cas access (for read, burst access)			*/
/************************************************************************/

#define DESIGNER George Scolaro	(C) 1988,89,90
#define REVISION 03 	05/14/88
#define PARTNUM U39

dramc( in	 bclk,		/* 32532 system clock */
		!dram,		/* dram select */
		!conf,		/* 32532 bus cycle confirmed */
		!hsa,		/* high speed access in progress */
		!rfrqin,	/* refresh request */
		!bout,		/* burst access request */
		!bmt,		/* begin memory transfer */
		!ddin,		/* data direction from 32532 */
		!oe;
	reg
		!ras,		/* ras to rams */
		!cas,		/* cas to rams */
		!rfcyc,		/* refresh in progress */
		!rfrq,		/* synchronized refresh request */
		!nrdyr,		/* not ready to 32532 */
		!da,		/* internal counter */
		!casp,		/* cas parity clock */
		!rfdone;	/* refresh complete */
)
{
group	state[ras, cas, rfcyc, da];

#define idle	0b1000

#define prech1	0b0000
#define prech2	0b0001

#define	accw	0b1001
#define acc1	0b1100
#define acc2	0b1101

#define ref1	0b0011
#define ref2	0b0111
#define ref3	0b1111
#define ref4	0b1011

#define ref5	0b0010
#define ref6	0b0110
#define ref7	0b1110
#define ref8	0b1010

casp.ck = bclk;
casp.oe = oe;
rfrq.ck = bclk;
rfrq.oe = oe;
rfdone.ck = bclk;
rfdone.oe = oe;
nrdyr.ck = bclk;
nrdyr.oe = oe;
state[].ck = bclk;
state[].oe = oe;

rfrq	= rfrqin & !rfdone	/* synchronise the external refresh request */
	| rfrq & !rfcyc;

rfdone = rfcyc		/* refresh done for this rfrqin */
	 | rfdone & rfrqin;

nrdyr	= dram & bmt & !hsa	/* always when not a high speed access */
	| dram & bmt & rfrq	/* start of any dram access if refresh */
	| dram & (conf | bmt) & rfcyc	/* during refresh cycle */
	| (state[] == prech1) & dram & conf
	| (state[] == prech2) & dram & conf
	| (state[] == acc2) & bout
	| (state[] == accw) & !(hsa & !bout) & ddin;


switch (state[]) {

casp = 0;

case idle:
	if (!rfrq & hsa & dram & bmt & ddin) {	/* read access has no wait */
		casp = 1;
		state[] = accw;
	}
	else if (!rfrq & hsa & dram & bmt & !ddin) /* write has no wait */
		state[] = acc2;
	else if (!rfrq & !hsa & dram & bmt)
		state[] = prech1;
	else if (rfrq)
		state[] = ref1;
	else
		state[] = idle;
	break;

case acc1:
	if (ddin) {
		casp = 1;
		state[] = acc2;
	}
	else if (!ddin)
		state[] = idle;
	break;

case acc2:
	if (bout)
		state[] = acc1;
	else if (!bout)
		state[] = idle;
	break;

case prech1:
	state[] = prech2;
	break;

case prech2:
	if (rfrq & !(dram & (conf | bmt)))
		state[] = ref2;
	else if (dram & (conf | bmt))
		state[] = accw;
	else
		state[] = prech2;
	break;

case accw:
	if (hsa & !bout)		/* 0 wait state if in page and not */
		state[] = idle;		/* a burst access*/
	else
		state[] = acc1;
	break;

case ref1:
	state[] = ref2;
	break;

case ref2:
	state[] = ref3;
	break;

case ref3:
	state[] = ref4;
	break;

case ref4:
	state[] = ref5;
	break;

case ref5:
	state[] = ref6;
	break;

case ref6:
	state[] = ref7;
	break;

case ref7:
	state[] = ref8;
	break;

case ref8:
	state[] = prech1;
	break;
}

putpart("p16r8", "dramc",
	bclk, dram, conf, hsa, rfrqin, bout, bmt, ddin, _, GND,
	oe, ras, cas, rfcyc, rfrq, nrdyr, da, casp, rfdone, VCC);
}
---------------cut----------------
/************************************************************************/
/* This pal performs address decoding for the 32k address space. IODEC	*/
/* is asserted for all i/o devices. Note that the /dram select does not	*/
/* have the /conf conditioning, this is to ensure that the signal is	*/
/* fast enough to go into a clocked D pal.				*/
/************************************************************************/

#define DESIGNER George Scolaro  (C) 1988,89,90
#define REVISION 02	05/12/88
#define PARTNUM U37

dec32(	in	a31..27,	/* 32532 addresses */
		swap,		/* swap dram & eprom */
		a8,		/* address for int/nmi */
		!ioinh,		/* i/o inhibit */
		!conf;		/* confirmed bus cycle */
	out
		!iodec,		/* i/o device decoded */
		!slows,		/* all the slow peripherals */
		!eprom,		/* eprom select */
		!dram,		/* dram select */
		!scsi,		/* scsi select */
		!icu,		/* icu select */
		!duart,		/* duart select */
		!slow;		/* slow device, needs wait states */
)
{
iodec.oe = 1;
slows.oe = 1;	
eprom.oe = 1;
dram.oe = 1;
scsi.oe = 1;	
icu.oe = 1;
duart.oe = 1;
slow.oe = 1;

int a0..7, a9..26;

[a0..7] = [a9..26] = ?;

group memadr[a31..0];

#define reprom	(memadr[] >= 0x00000000 && memadr[] <= 0x07ffffff)
#define ieprom	(memadr[] >= 0x10000000 && memadr[] <= 0x17ffffff)
#define idramn	(memadr[] >= 0x00000000 && memadr[] <= 0x07ffffff)
#define idramp	(memadr[] >= 0x08000000 && memadr[] <= 0x0fffffff)
#define iduart	(memadr[] >= 0x28000000 && memadr[] <= 0x2fffffff)
#define ipscsi	(memadr[] >= 0x30000000 && memadr[] <= 0x37ffffff)
#define idscsi	(memadr[] >= 0x38000000 && memadr[] <= 0x3fffffff)
#define iiodev	(memadr[] >= 0x20000000 && memadr[] <= 0x37ffffff)
#define iicu	(memadr[] == 0xfffffe00)

slow	= reprom & swap		/* eprom at power on */
	| ieprom 		/* eprom normal */	
	| iduart & !ioinh	/* duart */
	| ipscsi & !ioinh	/* scsi, polled */
	| iicu & !ioinh;	/* icu */

/* slows is used to enable the slow peripheral bus via the 74as646 */

slows	= reprom & swap		/* eprom at power on */
	| ieprom		/* eprom normal */	
	| iduart		/* duart */
	| ipscsi | idscsi	/* scsi */
	| iicu;			/* icu */

duart	= iduart & !ioinh;

scsi	= ipscsi & !ioinh	/* scsi polled */
	| idscsi;		/* scsi dma */

icu	= iicu & conf & !ioinh;

iodec	= iiodev & conf
	| iicu & conf;

dram	= idramn & !swap	/* normal position */
	| idramp &  swap;	/* at power up */

eprom	= reprom & conf & swap	/* at power on */
	| ieprom & conf;	/* normally */

putpart("p16l8", "dec32",
	a31, a30, a29, a28, a27, swap, a8, ioinh, conf, GND,
	_, iodec, slows, eprom, dram, scsi, icu, duart, slow, VCC);
}
---------------cut----------------
/************************************************************************/
/* Wait state generator pal for slow I/O devices.			*/
/*									*/
/*  2 wait states for SCSI psuedo dma					*/
/*  3 wait states for SCSI register select				*/
/*  7 wait states for EPROM bus cycles.					*/
/*  7 wait states for ICU & DUART bus cycles.				*/
/*   1 wait states of 'front porch' on IORD and IOWR and then 6		*/
/*   T-states for the IORD and IOWR bus cycles. A 74AS646 device	*/
/*   latches data from the peripheral device during a read cycle, thus	*/
/*   enabling the IORD signal to be deasserted 1-T state prior to the	*/
/*   last T2 T-state. This guarantees sufficient chip select and	*/
/*   address hold time after an IORD.					*/
/************************************************************************/

#define DESIGNER George Scolaro (C) 1988,89,90
#define REVISION 01	1/14/89
#define PARTNUM U38

wait(	in	bclk,		/* 32532 system clock */
		!eprom,		/* eprom select */
		!scsi,		/* scsi select */
		!bmt,		/* begin memory transaction */
		!ddin,		/* data direction */
		!slow,		/* slow peripheral cycle */
		drq,		/* scsi dma request */
		scsii,		/* scsi interrupt */
		a22,		/* address line 22 */
		!oe;
	out
		!dack,		/* scsi dma acknowledge */
		!eop;		/* eop to scsi on last byte transfer */
	reg
		!nrdy,		/* not ready to 32532 */
		!d0..2,		/* internal counter terms */
		!iord,		/* I/O read strobe */
		!iowr;		/* I/O write strobe */
)
{

group	state[d0, d1, d2, nrdy];

#define idle	0b0000
#define idlew	0b0001
#define wait1	0b0011
#define wait2	0b0101
#define wait3	0b0111
#define wait4	0b1001
#define wait5	0b1011
#define	wait6	0b1101
#define	wait7	0b1111

state[].ck	= bclk;
state[].oe	= oe;
iord.ck		= bclk;
iord.oe		= oe;
iowr.ck		= bclk;
iowr.oe		= oe;
eop.oe		= 1;
dack.oe		= 1;

int iocycle;


iocycle = (state[] == wait1 | state[] == wait2 | state[] == wait3
	 | state[] == wait4 | state[] == wait5 | state[] == wait6)
	| bmt & slow & scsi
	| bmt & !slow & scsi & (drq | scsii)
	| (state[] == idlew) & (drq | scsii);


eop	= iord & !slow & scsi & a22	/* scsi eop on last byte transfer */
	| iowr & !slow & scsi & a22;

dack	= iord & !slow & scsi		/* scsi dma read/write access */
	| iowr & !slow & scsi;
	
iord.d	= ddin & iocycle;

iowr.d	= !ddin & iocycle;

switch (state[])	{

case idle:
	if (bmt & slow)
		state[] = wait1;
	else if (bmt & !slow & scsi & !drq & !scsii)
		state[] = idlew;		/* wait till data ready */
	else if (bmt & !slow & scsi & (drq | scsii))
		state[] = wait1;
	else
		state[] = idle;
	break;

case	idlew:
	if (drq | scsii)
		state[] = wait1;	/* scsi data now ready */
	else if (!(!slow & scsi))
		state[] = idle;		/* exit, if reset */
	else
		state[] = idlew;
	break;

case wait1:
	if (!slow & scsi)
		state[] = wait7;	/* 2 wait states for scsi dma */
	else
		state[] = wait2;
	break;

case wait2:
	if (scsi)
		state[] = wait7;	/* 3 wait states for scsi polled */
	else
		state[] = wait3;
	break;

case wait3:
	state[] = wait4;
	break;

case wait4:
	state[] = wait5;
	break;

case wait5:
	state[] = wait6;
	break;

case wait6:
	state[] = wait7;
	break;

case wait7:
	state[] = idle;
	break;
}

putpart("p16r6", "wait",
	bclk, eprom, scsi, bmt, ddin, slow, drq, scsii, a22, GND,
	oe, dack, nrdy, d0, d1, d2, iord, iowr, eop, VCC);
}
---------------cut----------------
/************************************************************************/
/* This Pal generates 2 bank selects for up to 8 megabytes of dram,	*/
/* utilizing 1 megabyte DRAM SIMMS. It also generates the 4 CAS selects	*/
/* based upon refresh and byte enables.					*/
/************************************************************************/
/*  Allowable Target Device Types:	PAL20L8D			*/
/************************************************************************/

#define DESIGNER George Scolaro	(C) 1988,89,90
#define REVISION 01 	05/07/88
#define PARTNUM U19

dramen(	in	!be0l,		/* latched byte enables */
		!be1l,
		!be2l,
		!be3l,
		!rfcyc,		/* doing a refresh cycle */
		!bmt,		/* begin memory transaction */
		!cas,		/* cas from DRAMC pal */
		banks,		/* dram bank select, A22 or A24 */
		qo0,		/* two phase signals */
		qo1,
		!hsadr,		/* high speed access to dram in progress */
		!conf,		/* bus cycle confirmed */
		!ddin,		/* data direction from 32532 */
		!ras,		/* ras for drams */
		!rfrqi,		/* refresh request is pending */
		!ddinl;		/* /bclk latched ddin */
	out
		!cas0,		/* cas 0, output only */
		!cas3;		/* cas 3, output only */
	io
		!bank0,		/* bank 0, 0 - 3 megabytes */
		!bank1,		/* bank 1, 4 - 7 megabytes */
		!cas1,		/* cas 1 */
		!cas2;		/* cas 2 */
)
{

cas0.oe	= 1;
cas1.oe	= 1;
cas2.oe = 1;
cas3.oe = 1;
bank0.oe = 1;
bank1.oe = 1;

cas0	= cas & rfcyc
	| cas & !ddin & be0l
	| hsadr & conf & ddin & bmt & !rfrqi & !rfcyc & ras /* fast cas */
	| cas1 & hsadr & conf & ddin & !cas & !rfcyc
	| cas & ddinl & qo0
	| cas & ddinl & qo1;

cas1	= cas & rfcyc
	| cas & !ddin & be1l
	| hsadr & conf & ddin & bmt & !rfrqi & !rfcyc & ras /* fast cas */
	| cas1 & hsadr & conf & ddin & !cas & !rfcyc
	| cas & ddinl & qo0
	| cas & ddinl & qo1;

cas2	= cas & rfcyc
	| cas & !ddin & be2l
	| hsadr & conf & ddin & bmt & !rfrqi & !rfcyc & ras /* fast cas */
	| cas1 & hsadr & conf & ddin & !cas & !rfcyc
	| cas & ddinl & qo0
	| cas & ddinl & qo1;

cas3	= cas & rfcyc
	| cas & !ddin & be3l
	| hsadr & conf & ddin & bmt & !rfrqi & !rfcyc & ras /* fast cas */
	| cas1 & hsadr & conf & ddin & !cas & !rfcyc
	| cas & ddinl & qo0
	| cas & ddinl & qo1;

bank0	= !banks & !ras
	| bank0 & !bank1
	| rfcyc;

bank1	=  banks & !ras
	| bank1 & !bank0
	| rfcyc;

putpart("p20l8", "dramen",
	be0l, be1l, be2l, be3l, rfcyc, bmt, cas, banks, qo0, qo1,
	hsadr, GND,
	conf, ddin, cas0, bank1, cas1, cas2, bank0, ras, rfrqi,
	cas3, ddinl, VCC);
}
---------------cut----------------
/************************************************************************/
/* This Pal multiplexes two scsi controllers with only one set of	*/
/* control signals. The software selects the scsi controller that is	*/
/* connected to the 32532 via the SELECT signal from the ICU.		*/
/************************************************************************/
/*  Allowable Target Device Types:	PAL16L8B, GAL16V8A-15		*/
/************************************************************************/

#define DESIGNER George Scolaro	(C) 1988,89,90
#define REVISION 01 	07/25/88;
#define PARTNUM U40;

scsi(	in	!scsii0,	/* scsi channel 0 interrupt */
		scsii1,		/* scsi channel 1 interrupt */
		drqs0,		/* drq channel 0 */
		drqs1,		/* drq channel 1 */
		select,		/* select = 0 => channel 0 */
		!dack,		/* dma acknowledge*/
		!scsi,		/* scsi chip select */
		a27,		/* cpu address 27 */
		!conf;		/* bus cycle confirmed */
	out
		!scsi1,		/* select scsi channel 0 */
		scsi0,		/* select scsi channel 1 */
		!dack1,		/* dack channel 1 */
		!dack0,		/* dack channel 0 */
		drqs,		/* drq */
		scsii;		/* scsi interrupt */
)
{
#define scssel	scsi & !a27
#define ch0sel	select & conf
#define ch1sel	!select & conf

drqs.oe	= 1;
scsii.oe = 1;
scsi0.oe = 1;
scsi1.oe = 1;
dack0.oe = 1;
dack1.oe = 1;

drqs	= drqs0 &  select	/* channel 0 */
	| drqs1 & !select; 	/* channel 1 */

scsii	= scsii0 &  select	/* channel 0 */
	| scsii1 & !select; 	/* channel 1 */

scsi0	= scssel & ch0sel; 	/* channel 0 device select */

scsi1	= scssel & ch1sel; 	/* channel 1 device select */

dack0	= dack &  select; 	/* channel 0 */

dack1	= dack & !select; 	/* channel 1 */

putpart("p16l8", "scsi",
	scsii0, scsii1, drqs0, drqs1, select, dack, _, scsi, a27, GND,
	conf, scsi1, scsi0, _, _, dack1, dack0, drqs, scsii, VCC);
}
---------------cut----------------
/************************************************************************/
/* Parity checker pal. This pal takes the latched parity errors from	*/
/* each byte as well as the latched byte enables and bank.		*/
/* Parity errors detected during /CASP are clocked on the next bclk 	*/
/* edge and can then be read along with the offending bank. An /NMI is 	*/
/* generated when a parity error occurs. No further parity errors a	*/
/* checked for until the software (optionally) reads the error latch	*/
/* and then issues a /paritycl to clear the parity error latch and	*/
/* deassert the /NMI.							*/
/************************************************************************/
/*  Allowable Target Device Types:	GAL20V8A-15			*/
/************************************************************************/

#define DESIGNER George Scolaro	(C) 1989,90
#define REVISION 02	891201
#define PARTNUM U20

parity(	in	bclk,		/* 32532 system clock */
		!casp,		/* cas parity (from DRAMC) */
		!rsto,		/* system reset */
		!banks,		/* bank select signal */
		!parityrd,	/* read data */
		!paritycl,	/* clear parity error latch */
		!belp0..3,	/* 4 clocked byte enables */
		!pdip0..3;	/* 4 bytes worth of parity information */
	reg
		!bankc,		/* clocked bank select signal */
		!cparity,	/* parity check enable signal */
		!bankl,		/* latch bank select if parity error */
		!perr0..3;	/* parity error occurred on this byte */
	io
		!nmi;		/* the actual parity error signal  */
)
{
group perr[perr0..3];

perr[].oe	= parityrd;
bankc.oe	= parityrd;
bankl.oe	= parityrd;
cparity.oe	= parityrd;
nmi.oe		= 1;

perr[].ck	= bclk;
bankc.ck	= bclk;
bankl.ck	= bclk;
cparity.ck	= bclk;


cparity.d = casp;
bankc.d	= banks;

nmi	= perr0				/* async output */
	| perr1
	| perr2
	| perr3
	| rsto
	| nmi & !paritycl;

perr0.d	= pdip0 & belp0 & cparity & !nmi
	| perr0 & !(rsto | paritycl);

perr1.d	= pdip1 & belp1 & cparity & !nmi
	| perr1 & !(rsto | paritycl);

perr2.d	= pdip2 & belp2 & cparity & !nmi
	| perr2 & !(rsto | paritycl);

perr3.d	= pdip3 & belp3 & cparity & !nmi
	| perr3 & !(rsto | paritycl);

bankl.d	= bankc & pdip0 & belp0 & cparity & !nmi
	| bankc & pdip1 & belp1 & cparity & !nmi
	| bankc & pdip2 & belp2 & cparity & !nmi
	| bankc & pdip3 & belp3 & cparity & !nmi
	| bankl & !(rsto | paritycl);

putpart("g20v8", "parity",
	bclk, casp, rsto, banks, belp0, paritycl, pdip3, pdip1, pdip0,
	belp3, belp1, GND,
	parityrd, belp2, bankc, cparity, nmi, bankl, perr2, perr0,
	perr1 ,perr3, pdip2, VCC);
}
---------------cut----------------

-- 
George Scolaro
george@wombat.bungi.com                [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com Sun Apr 15 14:26:46 1990
Reply-To: pc532@daver.bungi.com
Date: Sun, 15 Apr 90 01:05 PDT
From: dlr@daver.bungi.com (Dave Rand)
To: pc532@daver

Article 785 of comp.sys.m68k:
Newsgroups: comp.sys.m68k
Path: daver!dlr
From: dlr@daver.bungi.com (Dave Rand)
Subject: Re: 680X0 Dream Machine
Message-ID: <1990Apr15.100333.15928@daver.bungi.com>
Reply-To: dlr@daver.bungi.com (Dave Rand)
Organization: Association for the Prevention of Polar Bears and Kangaroos
References: <7873@wheat-chex.ai.mit.edu>
Date: Sun, 15 Apr 90 10:03:33 GMT

In article <7873@wheat-chex.ai.mit.edu> mikec@wheat-chex.ai.mit.edu (Mike E. Ciholas) writes:
>
>I sat down and tentatively designed the "Dream Machine".  Now I want to know:
> [deleted]

Here are a couple of points for you to consider in developing such a machine.
This is based on doing 100+ PC532 boards, among the many projects that George
<george@wombat.bungi.com> and I have done over the years.

First: 40 Mhz is pretty aggressive. It is very hard to design a reliable
product, using today's technology, that pushes the limit like this. Try
doing the DRAM timing, and see what you get... You might find that a 40 Mhz
design will require a significant number of wait states to the DRAM. Even
though the 030 has a cache, you might need to front end the main store with
some additional cache to get reasonable performance. Again, it depends on
your design methodology, and the number of ASICs you plan to use. You
might want to think about using a slower part - you may be able to get
better performance (1 wait state is 33% slower, 100% if it is in burst.
Better to run at 20 Mhz, than take a wait state? Depends on the application.
Try some hardware out and see.)

I think your cost analysis is a bit low as well... We did the PC532
in a 6 layer board, layed by hand (with CAD software, no auto-route).
The PC532 is a 25 Mhz design, and gets by with no wait states to the
DRAM (in page). Just. Every nanosecond is counted (and needs to be).
At 25 Mhz, we are seeing some effects of the board layout on the signals,
be sure to take this into account. For example, we found that it was
a good idea to terminate the clock lines at the end of the run with
pull up/pull down resistors, and it was _vital_ to minimize the run
length of the clock lines. Stubs are important, too! Be careful when
you do the layout... Multi-layer boards will be required. Which brings
me to the point - board cost.

>	
>	Cost analysis:
>		motherboard		  500

Assuming that you can get by with a 6 layer board, this is not a bad cost
estimate - for the bare board (no parts). Our first run of PCB's cost 
about $350 each (untested). Photoplotting was about $150-200. The
fact that the boards were untested turned out to be a problem, in that
each of the boards had a couple of shorted or open traces. For the
next run of 65, we specified testing, and received 65 boards that worked.
I don't know how many the PCB house had to run, but we did use a better
PCB house for the subsequent boards (West Coast Circuits - recommended).
The run of 65 cost about $200 each.

In the motherboard cost, don't forget to include things like sockets,
resistors, caps, etc. It _really_ adds up. Also, have you checked into
the price of the 030 and 040? The 40 Mhz parts command a high premium
on the price. I think that (unless you can cut a good deal with Motorola)
you will be paying $400-600 each for the 030. _Please_ correct me if I
am wrong. The 882 will be around $300-400, maybe more at 40 Mhz.
Also note that (unless you are really clever), the minimum memory will have
to be 4 megabytes (assuming you use FP DRAMs).

WRT the bus interface... 40 Mhz is pushing the SOTA - expect to pay a
premium for the bus interface technology. The approach that we took was
that of a simple multi-master bus - SCSI. This allows us to use a very
low cost ($8) chips, yet obtain high throughput (4 megabytes/sec) over
up to 6 m of cable.

>	Cost analysis:
>		motherboard		  500
Revised:
		motherboard		$1,500+

>		RAM (4MB)		  300
Revised:
		RAM (4 MB SIMMs @$100)	  400

>		floppy			  100
>		video card		  300

Cards were another shocker. We are using the PC/XT form factor, so we
can use the cheaper wire-wrap proto-cards. The PCB's however, are a
bit more expensive. The 6 layer Ethernet/16 port serial card that we
did will cost $280 or so for the bare PCB in moderate volume (20-30 cards).
Again, we have to pony up for $200 or so in photoplotting charges. The
extra cost seems to be for gold plating the edge connectors. This is
cheaper, though, than going for one of the new whizzy card edge connector
technologies that (for example) AMP sells. These seem to be in the $30-40
range.

You mentioned that you would like the card to have local processing...
a 68000 for example. A basic 2 megabyte 68000 system will cost about
$200 or so - less if you have a good junkbox. An interesting video
chip would be the Chips and Technologies 8514 chip. You can do a
complete video design in about 14 chips (including the DRAM for the video).
Add another $200 or so.

Revised:
		video card		$700

>		disk card		  200
>		disk (100MB)		  700

You can put a SCSI chip on the main board, and use SCSI disk drives.
Call it an extra $30 or so on the main board (incl. connector, terminators,
sockets, etc). We did get a really good deal on the disk drives thanks
to Karl Swartz <kls@ditka.UUCP>! He managed to get a bulk buy (40 or 50
drives) of the Miniscribe 380 Meg SCSI drives for $900 each. 

>		misc (case, power)	  200

Sounds close. If you have connectors on the back (for serial, external
SCSI, etc) add another $150 or so for the IDC connectors, screws, mounting
h/w, etc.

Please, folks, don't get me wrong. I like the idea of people doing interesting
hardware! I'd like it even better if you used SCSI add-on cards so we can
share the peripheral cards between the two motherboards :-) But please
don't underestimate the dollar value of projects like these. My figures
are still a little on the low side (things are *always* more expensive
than you think). Besides, this is a hobby. Getting together to do bulk
purchases of things will always help the cost.

Also, don't underestimate the time required to do the designs. George
designed most of the hardware 2+ years ago. We did a wire-wrap prototype
of the main PC532 board about 2 years ago. 1 year was spent refining the
design (getting from 2 wait states to zero was not easy). Laying out
the board took a couple of months. Verifying the design took more than
a few weekends. Again, this is part time (evening work mostly), but it
still took time. From the time we announced that people could get the
design to the time that the first boards were available was several months.
Getting together the "hard to find" parts and kitting them up took more
of my time at my day job that I ever care to admit. But it was (and is)
*fun*!


>Now, given that machine, WITH NO SOFTWARE, what can we do?  Can people write
>a BIOS ROM for it?  Can we get UNIX (MINIX?), gcc, X, etc. ported to it?

The core software will come up easy. Finding some that can do the UNIX
port, and someone that can do it *legally* are two hard things to do.
If you can get some support from Motorola, it will be a lot easier.

>
>From where I sit, the hardware is no problem (it will take time, of course,
>but its not pushing the state of the art).

Hmm... At 40 Mhz, it is pushing the SOTA. Try it, and find out how fast
them nanoseconds disappear - then try it again with a worst case design.
It will not be easy.

>Mike Ciholas
>email:  mikec@ai.mit.edu
>snail:  289 Highland Ave #108/Somerville, MA 02144
>phone:  (617) 623 3563
>air:    N1909C, 1954 Cessna 170B


Dave Rand
+1 408 733-4125 home

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



From culberts@hplwbc.hpl.hp.com Mon Apr 16 14:46:51 1990
Date: Mon, 16 Apr 90 11:46:18 pdt
From: Bruce Culbertson <culberts@hplwbc.hpl.hp.com>
To: budd@bu-it
Subject: Re:  Monitor source 1 of 3

Hi Phil,

> I built gcc from 1.37 and your patches last night.

Good work!  I'll have to try it myself.

> Turns out all thats needed is a "nop" defn in the md file
> and to change the spelling of offsetable to offsettable
> in your md and aux-output.c files.

A couple of comments...

First, even if this seems to work, I think we should call it "experimental"
until we have successfully run quite a bit of code through it.

Second, there may be some benefit to merging my changes into the 1.37
md and tm.h since the 1.37 files may have some improvements.  It would be
interesting to diff my md and the 1.37 md to see how much has changed.

> The define HOST_M68K almost eluded me.  Should it really be HOST_BIG_ENDIAN
> (not that that is a standard config.h option either)...

You are probably right on this.  I really do not remember.

Bruce

From owner-pc532%daver@mips.com Tue Apr 17 06:39:34 1990
Reply-To: pc532@daver.bungi.com
Subject: Build plans for PC-SCSI host adapter..
To: pc532@daver.bungi.com
Date: Tue, 17 Apr 90 0:55:01 EST
From: John Connin <johnc%manatee%uunet@daver>
X-Mailer: ELM [version 2.2 PL2]


The purpose of this message is to announce to the availability
of build plans for a PC-SCSI host adapter.  Lacking imagination
I have simply called this board the 'pc5390', since it utilizes
the NCR 53C90A "Advanced SCSI Processor".  (NB: do not confuse
this chip with NCR's risc based SCSI processor which is the 53C700
"SCSI I/O Processor").

I have also designed and constructed a pc8490 host adapter based upon
the NSC 8490.  However, I _do_not_ intend to 'support' this board design
simply because the pc5390 is substantially easier to use.  The 5390
accepts commands (eg. select, transfer information, enable selection,
etc) and issues interrupts when the function completes or times-out.
Some of the commands even invoke a sequence of activities (eg. the
command 'select with ATN' arbitrates, selects target, transfers
identification message and the command before interrupting.  The details
of the SCSI protocol are handled in hardware.


Motivation behind the pc5390:

The long term reason I designed the pc5390 is that I want to create
a transparent 'very local area network' between my various computers,
(ie. pc532, 286-PC, 386-PC and possibly a S-100 machine that has been
collecting dust).  The idea is to use client-server message passing
over the SCSI network using something like the Amoeba message protocol.

However, in the near term my plan is to use the pc5390 primarily as a
pc532 system development tool.  Here the idea is to supplement the
serial port interface with a high-speed bi-direction data path between
my PC and the pc532.  The theory being the pc532 can then be taught to
read / write the PC floppy / hard disks (many thanks to Bruce for adding
SCSI support to the monitor).  Also, an other possible development
use is to connect the pc532 hard disk to the PC and build a file system.
Then connect the disk to the pc532.  In other words, load pc532 Minix on
to the hard disk directly from the PC, then connect the disk to the
pc532, and attempt to boot the pc532 from hard disk.


The board features are:

   - wire-wrap construction
   - PC and PC-AT compatible.
   - half-card form factor (approx. 1/2 of card used)
   - initiator and/or target
   - asynchronous or synchronous operation
   - IO, DMA or pseudo-DMA transfer,  (pseudo-DMA --> blind IO)
   - Supports certain SCSI-2 features (eg. tagged queuing)
   - 16-byte FIFO
   - details of SCSI-bus protocol are handled by hardware
   - one command can initiate a sequence of activities
   - IRQ 2-7 jumper selectable
   - DRQ / DTACK 1-3 jumper selectable ( no jumper for pseudo-DMA )
   - Board address jumper selectable from 200H to 3F0H on 16 byte
     boundary.


The board components are:

    Qty.        Description.
    ----        -----------------------
    1           NCR 53C90A, SCSI processor                  $25-35 (forgot price)
    1           P16L8,   pal / gal
    1           74LS682, 8-bit magnitude comparator
    1           74LS245, octal bus transceiver
    1           74LS14,  hex inverter (may not be required, only one inverter
                         is used to buffer the oscillator)
    1           DIP oscillator module, 10 - 25 Mhz          $5.00
    2           220/330 resistor pack
    2           10K ohm pull-up resistors
    1           1N5817 diode
    1           1 amp fuse resistor
    2-3         10 - 47 uf tantalum capacitors
    4-5         0.1 uf bypass capacitors
    1           50 pin connector or header
    1           PC prototype card (Jameco JE417)            $19.95
    bunch       wire-wrap sockets ( I used surplus breakable 1 x 20 wire-wrap
                machine sockets obtained from Advanced Electronic Components
                1-408-730-4660)
    some        wire-wrap terminals (ditto)


Tools required:

    - wire-wrap hand-tool / gun
    - un-wrap tool  :-) (-:
    - pal programmer (NB: since my programmer situation is currently flaky
                      I may not be able to program pals, but will try to
                      provide this service, hardware / software permitting).

Performance:
                        Asynchronous                    Synchronous
                        -------------------             -------------------
    - IO                TBD                             TBD
    - DMA               209,000 bytes / sec             TBD
    - pseudo DMA        787,000 bytes / sec             TBD

    (1)  your mileage will vary.
    (2)  data rate measurement based on 512 byte transfer


Software available:

    - supported, none .....
    - fragments, what ever I have is yours


Limited time offer:

If you would like a copy of the pc5390 build plans, send me your
_complete_ mailing address and $7.00 to cover costs.  In return I will
send you:

   - schematic
   - pal design
   - bill of materials
   - copy of NCR 53C90 data manual (approx 50 pages)
   - copy of NCR 53C90 user's guide (approx 50 pages)

NB: it may take me a couple of weeks to get my act together, ie. accurate
    schematics, BOM, etc, so please be patient.

Questions and follow up:

   Any questions and / or discussion (pro or con) should be directed to the
   pc532 mailing list.


Best regards,
johnc
 

-- 

From owner-pc532%daver@mips.com Tue Apr 17 10:00:20 1990
Reply-To: pc532@daver.bungi.com
To: pc532%daver@pyramid
Subject: looking for something to do on your pc532?
Date: 17 Apr 90 14:44:10 MSZ (Tue)
From: jkh@meepmeep.pcs.com (Jordan K. Hubbard)

Hey sports fans,

So you've got your pc532 together, talking serial to some other machine,
and now you're sitting around waiting for someone to port unix. There it sits.
Whirring away in a nice, fast, pipelined endless loop polling the serial
port. What do you do? Why, you calculate pi to 9000 decimal places, that's
what you do!

Here's the btoa'd executable for a stand-alone pi calculator.
The text expects to go at 0x4000 and the data at 0x5000. You can use Bruce's
extractt and extractd utilities to yank out the segments and download them
(using his download program, of course). It will interactively ask you
how many digits to calculate, spit out some information about how much
space it's all going to take, and then let you know the progress of the
calculation every 100 terms (finally spitting out the value of pi to the
requested number of decimal places).

I haven't got the figures in front of me (forgot to write them down, damn)
but I think this should take about 24 seconds to calculate pi to 5000
places. This seems a little slow, since my 68020 (at 25Mhz) will do it
in just 29 seconds and it's also running Unix (though with only one user).
Perhaps I'm doing something wildly wrong, but you be the judge..

Anyway.. I used btoa (the new one, version 5.2) since it produces images
that are about 35% smaller and I don't know how many people are on this
list now. Let me know if you absolutely need a uuencoded copy and I'll send
it to you directly.

Not that this actually does anything that useful.

Thanks to Waldemar Kebsch for the original algorithm and Bruce for the
stand-alone i/o routines.

					Jordan

-------
xbtoa5 78 - Begin
^n(N+!"],1$ig8-$ig8-zz_>sW:TE,#m!'gMa!'gMa!)NXqzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzL
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzp
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz?
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz!l+d9@R:%p6Xae@FP
_kK.AKYr++EVNEBQ&);D..=-+=Lc3@qfdgCagK;BkM.%F$CcI;f?\sGq:(VF`\aEAfu,&DJ*N'-uFP
*JF<G%(+?gnoA0>;uA0<uW-"JGW$35Y`'^+;eUB842",H'TCtB[/^]4X?kH,*C*<O"V#ijM:I&6>)4
);5E&*<6(#R!KS3XhXotQs[Gfh7o?Z^]4I6npI;+f,XpCB(C>Gr/qU(!+]eVBlnDW+=1PL+<Yc;Ec9
#kY+=1P*!*+)SDJ((<A0>?,FCfM9De:,5@rc""@q]giA0>`#D/XH?+=M;Q@<-I(DJ()#F<Dl?.4trD
-%<Q0%D)rdcA0:jPK(oc+^^,u=*uK;,Nu=9%W1j.@0HVup"HP94LS=\pFp!,Y_0d%9!s$V&TE"rl!q
s9AV#'_MuT0RMMT`>(_5h@mF4kIYp!eC:%`H]uTkM<mQkLdQM!fVV8!8#23kOktXkM<mUIpN-4."%4
lH#;179J@HCDc8VBr!!$OO!#cF#/a(s)DZ[]S!`scGp]iAN!!)1s):p_^.*a%c,:MaJVubL5!eDJAR
V=a$pf/;aTXaeqCf0(M7JI[0A!7s*[*S3H(AcR4TkQ`[>!!%%S*7m%a-r(#?"=HG?c6Fah"kPm=JL&
,]?o]dOM2<Xq?!7sBsfRXce?3&S7kO#APf0+Ui!.:X,f/;/Cf>Vh5JMl%:f>Vh5J6eKBI&61j-jMA[
LHG<5,`I)%)f>Vh5J<ea*I+Q>Z!eFO&V<j?e&cdLh!*?rAQbX$]^^qm_WrN5-#7.mP%gig[?Vg`08>
,rl#WcY/=PDFU!Wfr6dOq86+JcGce^^-:B$s*EVn3R,q7KC4(%;?^t%gL'D!5JRD@N#]r7XVuO%:'1
kTNu)Hu8c[I<!5JRD7Lp!\:&r'0%7/T@I)#^k4r4cn!"o83Jp79^^^+#X$ssj<_%8!`XoK7M!s&W=F
\gJ"$(Jk+W,:EX2f)X+fTE"s>&6B^oA"Wf%-P.L.QN@-l&ZT-"*YJGQJiEas^^(am$ss:l&6H[Z-he
+5<K)iq'=s$+.!#Gpd1E`"c!"Tjj,9UIrc=<LI!%/>u&5$Ms*"i5OJiEa3^^/Q-$ssQI_%8!`XT0.;
D!s&W5\gS'r%iQ6d!!<c78,u]m!!`Z-!%/;'%;/$-s4Hf@h[o'X?P)L)OrP)7$7048!$u.U$35Z;!C
8#!p-h2fp!7tc^kM9eQ^]4?pNurbGp`CC-)J@`.%jon>!7re(^]4?XI&6V!+!2BCD<K`i`ra$V!"X&
IRr/r$4zJcGf6hLcEU!":%6`<ZNqE."M[OoQ*pJcGf6hLae'!"91c`X'?[$i/u)$j(rV>`c`$:^d=c
?fY@Ipl$T?*OoQ*pJf"L>^^(am$m-=4('c,c!!!?E%d0rG!eRpWiu!0?r9)pgYJ:,G^L+M&-.a.=JK
\QT/oTC%(!!%Tf";eiZf0B<`7Ke*GfY@IpPoNm+$@po=+C>[e#R"E5,oV<INu/j=!"+7s"C2!Z)@YM
L7Nu/j=!"+7c"C2!\H7/o%!'+d<*tT=n?P+[T8H@%@=9*!t85P?a"C2!\H3aXZ!',@=**<1JJ;",3F
!,NP^h]Rss**<1JJ9;Q.!!EI9$@k3Q$3UNB$5;]T:]prC$5`mLGRAsUl@;4Q%G)?HKmWk%J5b_Bf+s
$=Hf7eSP!eF;]_L-a-o]dsY%G)?H-0MB;l3l2Qf+lm`kH,<Y`I%`;A:16?l3ttn>lXqWJpaEmNu/jm
=!#iU%(YHM'$F#[1&cdM#!#NH[f>%q>+W;$Z$g4W7!eFI$V>QAr*uN.Af>S!sJOt6cr1>)M'C#tgX;
WR[r3dde%NuoG\b&`^_&cdN.!*?rA=2><3_%bM:(`,^C(I8$38cUfD!!!!@RMH,[!!!!+)@kr4/HUW
J&:*Up0V>MDi)?pupl3(Gof*0bXf-LKK1jl.lT.h0"irC/<g(EMM+9I)BI&6b%+!2?BF-7RW!&-,_M
1GgsI2`Ng+@Uiq[AcRF-!*?uB(VpO3^^sj,#:ZYuk?WSh,o7t:#gP(G(C8Ur!a_2oI&6K#&a-8=!et
>rOV>QAr*uN.A(FWVrc7^<cgdT!Y7M,]PC+!s$I&6b(*YJGQJiE`H_$F,Y%+i9++".I+f-LL6!!/b!
Q!.:X@+"8*Nl3ldW+9I'PI&6b%+.jXtF6X4[ggpHe-%)QeO!#EM!#fmM-lN``$KnN6!YBaUr/Vql+n
3J\g*"i5OJcGe3fY@In3S24UJ!RkM:_WnWV>QJV&cdL`!0kD-^]71>!0>dJ!!s=%!"o83Jd;A.^^(P
/c!!!!+)@p2bkH,0p^]4@.I&6UF\CV`&^]4@"I&6V$&/"sC9)ri0L&dM>/-/iSYQW;X?jXU]#R>l+:
!)!:lJcYpR^^(!lNHClp!LeD](e=al5S='K!WZ<;$j(s&FJ8g;RXA)O#Qp5T&cdLn!*?rE!e=Vo^^1
-j:^]6kY?PjgI'+07\70aJ5#*0VdF3`^:&XNcZTEnMk+9GN:0EP4J5QXoZ&->h*'*)"+#67^A!L0=s
/"B;+L!`Ylt!gKDZ%@!Rh%c79O"CD.lE"W.dTE"rl#>S?n"%/_0!!!!3zJcGce^^+#W$q*D^!#cFhb
5QD-"NrY4H6p^kR$?I1P!#c@f8,sP4hZ2pI?NKEp?N?5h&cdL`!*?rAQO"9r!07C*!#g,!#U9nA#EN
f'"!!%TV!*?rAQbX$]#S^)8<!!&\&<@):!#fqq(m5FC!!%TV!8#!lf>S0M*<O!dI&6`C(tSom9,AFm
mV>-2b&cdL`!#33S"9i1Z%g3&^C'r6+!%1$>l35HQ!0R<p!!%TN!#33S"9h&:%g3&>C'r6+!%1#Slk
35HQ!0R<pzJf"J(_$FBbl4F^8@fVQ,cJ/R)J9-+7quVCY"9f,NCZhf,!e=`bi*ua'+FL$`Or+f3Jc/
GdX\,u^1r_%X8r!*B*!!!HH"Xg5UOoQ*pJd;A.^^(/c!!!!+)@p2bkH,0ps8W'XI&6UF\CV`&s8W'O
LI&6V$&/"sCJcGcP^U94)&cdL`!8#0q!l)[$V>QJV&c_n3Jp7:I^^+#X$st.72]jFd"_XeA*uG?8=5
P"Pps8W)%I&6`_!"+6J"C2!M$4$c?!!sPJNu7/&"C2!Z)@2B@h_==("C2!X)?u6>h_tcl!!!!1)M"%
@]>lZPs'*MSAGR=]Z>le%G#7h^;J;.D2l@=fu/H>bN#T=/tgg'm]^]4A(l3knm>lXrA!!%1iV>MD8:
)B8u6!!!!1)Lu&;gg'm]^]4@sI&6`_!"+6Kc6Fd`gg'm]^]4@+I&6`_!"'+Z**<1g5Z$_jcJ2\*!lC
+d9Q@,P,*rlWVc5]pd-U>GGl3Y`U=9'^68L"7s(`ZWX)S^b<+O22cOrb59JcGcb^^(&H07"!/"Z^<!
%hZ2pE?N?5h&cdL`!#33S"9gH)$NpVlC'NPql3(GoOoQ*pJd;A+^^/6@*<O!nI&6`_!"'VI*C+oU"V
<BsX$j7SYH4'irAnhP-!9s\o!0Rm+!!%TN!#33S"9i1Z$NpWZC'NPql3(GoOoQ*pJcGcb^^(&H5^Em
e@"^5XF?NB?ohZ/f>&c_n3zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzO
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzs
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzB
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzf
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzW^Qmf=o\O&!WWKo!!$R1!!!'#fKoQ<$ig8-!WZ7p
f!!!c7!!!'#,";P4D?'Y:!WZh'!!)fp!!!'#.S'O>IfKHK!WY\\!!!$#!!!'#:.YEc,lmuG!W[I7!c
!%cS!!!'#e4'E<OoPI^!W\HW!!#pu!!!'#C./+&RfEEg!W_^W!!")@!!!'#H:Ir8irB&Z!W_j_!!!,
<+!!!'#mR@0VVZ6\s!WW3cz!!!'#i(<tLFo_RC!W])b!!"AH!!!'#9Lf'_mf3=f!W\$C!!"\Q!!!'1
#(eF]-/cbqP!WW?n!!'D,!!!'#r($ef495E^!W[sG!!!Z5!!!'#DF=I)_>jQ9!WZ_#!!(1B!!!'#1E
dh<DeGoRL!WZV"!!#"Z!!!'#r(6qhL&h8S!WX3-!!#:b!!!'#!'gMaIfTNL!W^54!!$:*!!!'#?qLo
D!AcVl3!WWX*!!&5a!!!-%@R'nn"onW'!WYV[!!#Ul!!!'#VFU[e*!$$>!W^;4!!#Rj!!!'#&4$9rK
:B1@p!WZ=i!!$"!!!!'#(f124RfNKh#QT0C!!$p<!!!'#!)NXqN<'"Z"9<Lb@<-Gi?Ys4cD?+$\F_O
l/6E,9e"?YOClFD50"!+0\cBl8$)!+08NF)Yr(GlV2]BOt[hG[^Y[@<?F*F_q+cA8-4$A7YaJB4Z15
+!+08TBlj>^@:WmK?Z:%"DKK6'F_q+cF)Z/6DKKIj?ZK^fF`Li.EbTE5?Z("'!+0ehEbo<)!+0\cBS
l8$"F*)F&?Z9UaE-684!+0\cBl8$"@q]:k!+0edEbTE5Am]M"FCP;X@rH:$ARo.eF`_*n?[-O1Bl8\
$)!+08G?Y48"FCP;XE,oZ1FA?sq6=FqH!+08G?ZTe#@UXCi!+08G?Y3q^FCP;XF*)G4@<;KVF*)G4S
E-VFjD0]'%E^O\_!+0hdF`;;2EWBHgDes?9AT@cXE-684BOPo]?XI;]Deiop?Z:.0@fTkC@rH:$AR.
o.\ATVD^?Y<ql@q]:k!+0G]G[tN$Blj>^Ble*/G@bdp?YORlBkM.%!+0G]De!kh?YOS(E,]B/!+02T
WAU&:s?Y+=jG]Wpm@Urnh@/sYGA79Rg!+0;TA,lT0g
xbtoa End N 5998 176e E 52 S 61030 R 77e413a8

From culberts@hplwbc.hpl.hp.com Tue Apr 17 12:22:25 1990
Date: Tue, 17 Apr 90 09:21:53 pdt
From: Bruce Culbertson <culberts@hplwbc.hpl.hp.com>
To: budd@bu-it
Subject: Re:  Monitor source 1 of 3

> The image I built with 1.37 was quite different in size.  I built ld
> with 4K pages.

I am using the 1K page size at the moment -- that may be the difference.

> I'm working on a port of Xinu (version 6 -- pre-VM) just for fun...

Sounds good.  I didn't realize there was a VM Xinu.  That might be
interesting.

> How are you dealing with the duarts in Minix?  I found I had to keep a
> per-duart struct with copies of IMR and ACR regs since they are
> write-only and need to be tweaked (esp IMR) from the tty driver.

Unix requires a struct per tty to keep track of all the things you can
configure with ioctl.  I have not written the Minix tty driver for the
pc532 yet.  My 32016 has 16450's.  It is certainly common to keep a
software copy of write-only registers.

I will send the original 1.35 ns32k.md and tm-ns32k.h.

Regards,
Bruce

From owner-pc532%daver@mips.com Tue Apr 17 13:32:23 1990
Reply-To: pc532@daver.bungi.com
To: pc532%daver@pyramid
Subject: Mixing banks of SIMMS
Date: 17 Apr 90 17:48:23 MSZ (Tue)
From: jkh@meepmeep.pcs.com (Jordan K. Hubbard)

Hi. I've currently got 4MB of borrowed 1MB SIMMS running in my pc532
and it's looking like I'm going to have to give them back soon. The question
now arises as to what I should buy to replace them. The problem I have
with 1MB SIMMS is that this will give me only 8MB total memory when (and if)
I fully populate the pc532. This is simply not enough memory, in the long
run, if you consider UNIX / X Windows / Common Lisp/ GodKnowsWhat. 4MB SIMMS
seem much more attractive with the potential 32MB upper limit, but I have no
idea how expensive they are these days or even where to get them. I've seen
quotes of ~$70 USD for the 1MB's these days, what do the 4 meggers cost?

The second option I see (if it exists) is to buy one bank of 4MB for current
development and buy a second bank of 16MB using 4MB SIMMS later. I'd
rather have 32MB, of course, but 20MB is quite good enough for me. The question
remains as to whether or not I can populate the two banks differently.
Can I? Is there any reason why this might not be a good idea?
Anybody know the resale value of 1MB SIMMS if I decide to go that route
and upgrade later? :-)

					Jordan

From owner-pc532%daver@mips.com Tue Apr 17 15:10:47 1990
Reply-To: pc532@daver.bungi.com
Date: Tue, 17 Apr 90 11:29:08 PDT
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: gs@vw25.chips.com (George Scolaro)
To: pc532@daver.bungi.com
Subject: Re: Mixing banks of SIMMS

[In the message entitled "Mixing banks of SIMMS" on Apr 17, 17:48, Jordan K. Hubbard writes:]
> 
> The second option I see (if it exists) is to buy one bank of 4MB for current
> development and buy a second bank of 16MB using 4MB SIMMS later. I'd
> rather have 32MB, of course, but 20MB is quite good enough for me. The question
> remains as to whether or not I can populate the two banks differently.
> Can I? Is there any reason why this might not be a good idea?
> Anybody know the resale value of 1MB SIMMS if I decide to go that route
> and upgrade later? :-)

Not easily. You would have to cut/pull pins and jumper some traces. The
problem revolves around the 1M/4M signal from J1. The address mux-ing has
been set up to support the page mode access mode of the DRAMs we are using.
To do that for 4M precludes using the 1M and visa versa. You would have to
do the following:

- Select 1M on J1 (even though you have 4M simms as well).
- Pull pin 11 (A12) of U29 out of the socket. Wire pin 11 of U29
	directly to A23 (instead of A12 currently).

Doing this will support the smaller page size of the 1M simms while still
supplying multiplexed A22/A23 for the 4M simms (via Q10, output of U29).

The best memory configuration would be then to have the 4M SIMMs (16 Mbytes)
as bank0 and the 1M SIMMs (4 Mbytes) as bank1. That way the 20 Mbytes would
be contiguous.

I think all of the above is right. Let me know if you actually try it :-)

best regards,

-- 
George Scolaro (gs@vw25.chips.com)	Chips & Technologies
+1 408/434-0600 X4556 work		3050 Zanker Road
					San Jose, CA  95134

From owner-pc532%daver@mips.com Tue Apr 17 19:28:57 1990
Reply-To: pc532@daver.bungi.com
Subject: CSC drive replacement.
To: pc532@daver.bungi.com
Date: Tue, 17 Apr 90 12:04:58 EST
From: John Connin <johnc%manatee%uunet@daver>
X-Mailer: ELM [version 2.2 PL2]


A week or two ago I reported that one of two Miniscribe hard disks
I purchased in the group buy was flaky.

Well, good news.  CSC replaced the drive without any hassle and
the replacement drive seems to be operating swell.

Again, many thanks to Karl for organizing the buy !!!

Best regards,
johnc
-- 

From owner-pc532%daver@mips.com Tue Apr 17 23:37:27 1990
Reply-To: pc532@daver.bungi.com
Subject: Re:  Build plans for PC-SCSI host adapter..
To: pc532@daver.bungi.com
Date: Tue, 17 Apr 90 19:33:07 EST
From: John Connin <johnc%manatee%uunet@daver>
X-Mailer: ELM [version 2.2 PL2]


> John,
> 
> Would you please post your US Mail address so that I can send you a check 
> for the pc5390 build plans.
> 
> 		Thanks,
> 		Don

Ops !!

	John L. Connin
	105 Red Cedar Drive
	Longwood, FL  32779


	Phone: (409)-869-0567
	email: tarpit!manatee!johnc

Best regards,
johnc
-- 

From owner-pc532%daver@mips.com Thu Apr 19 08:18:57 1990
X-Path: nada.kth.se!stymne
From: stymne@nada.kth.se (Patrik Stymne)
To: pc532@bungi.com
Subject: misprint in pc532 functional description?
Date: Thu, 19 Apr 90 12:25:03 +0200
Reply-To: pc532@bungi.com
Precedence: bulk


The icu address (in "port definitions", page 10) seems to be wrong.
It should be 0xfffffe00 instead of 0xffffffe0.

Bruce' monitor uses the wrong address - this is why the read and write
commands don't work. The adeptec chip gets selected instead of the dp8490.

I discovered this when i tried to read a block from the disk, and noticed
that a led on the pc532 went out! 
(this only happens when using scsi-address 7...)
And the leds are connected to the adepetec controller...


--
Patrik stymne 
stymne@nada.kth.se

From owner-pc532%daver@mips.com Thu Apr 19 12:10:29 1990
X-Path: pyramid!pcsbst.pcs.com!meepmeep.pcs.com!jkh
From: jkh@meepmeep.pcs.com (Jordan K. Hubbard)
To: pc532%daver@pyramid
Subject: compiling ROM for burn-in
Date: 19 Apr 90 17:38:34 MSZ (Thu)
Reply-To: pc532@bungi.com
Precedence: bulk

Those wishing to compile Bruce's monitor for either downloading or
ROM operation should do the following:

1. Change DATARND in init532.c from 0x400 to 0x1000.
2. If compiling for downloading (i.e. testing), do:
   2a. Add a jsr to main as the first instruction after start:: in
       resume532.s
   2b. Relink at a different address (e.g. ld -T 2000 -o rom_db ...).

This works well for me.

				Jordan

From owner-pc532%daver@mips.com Thu Apr 19 13:53:54 1990
X-Path: vw26.chips.com!vw25.chips.com!gs
From: gs@vw25.chips.com (George Scolaro)
To: pc532@bungi.com
Subject: Re: misprint in pc532 functional description?
Date: Thu, 19 Apr 90 09:46:37 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

[In the message entitled "misprint in pc532 functional description?" on Apr 19, 12:25, Patrik Stymne writes:]
> 
> The icu address (in "port definitions", page 10) seems to be wrong.
> It should be 0xfffffe00 instead of 0xffffffe0.
		^^ right		^^ wrong

ARRRGGH. True enough, thanks, I'll fix the documentation, at least the folks
getting the new pcb run will have the correct information.

best regards,

-- 
George Scolaro (gs@vw25.chips.com)	Chips & Technologies
+1 408/434-0600 X4556 work		3050 Zanker Road
					San Jose, CA  95134

From owner-pc532%daver@mips.com Thu Apr 19 15:08:58 1990
X-Path: hplwbc.hpl.hp.com!culberts
From: Bruce Culbertson <culberts@hplwbc.hpl.hp.com>
To: pc532@bungi.com
Subject: Re:  misprint in pc532 functional description?
Date: Thu, 19 Apr 90 09:25:23 pdt
Reply-To: pc532@bungi.com
Precedence: bulk

> The icu address (in "port definitions", page 10) seems to be wrong.
> It should be 0xfffffe00 instead of 0xffffffe0.
>
> Bruce' monitor uses the wrong address - this is why the read and write
> commands don't work.

Patrik gets this week's sleuth award!  Many thanks.  I had gotten
reports that the SCSI commands did not work but, lacking a spare
SCSI device, I could not test or debug them myself.  Patrik didn't
explicitly say the SCSI commands now work correctly.  Would someone
please report to me if they do?

In a day or two I will post a new uuencoded EPROM image.  It will
include the ICU address fix and some fixes to disassembler bugs
reported by Jordan Hubbard.  I will also update the archive at BU.EDU.

Bruce Culbertson

From owner-pc532%daver@mips.com Thu Apr 19 19:51:11 1990
X-Path: wimsey.bc.ca!tacitus!virgil!tbr
From: tbr%virgil%tacitus%van-bc%uunet@daver (Tom Rushworth)
To: pc532@bungi.com
Subject: 016-332-532 differences?
Date: Thu, 19 Apr 90 13:22:29 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

I have the 1986 "Series 32000 Databook", and the 1987 edition of Colin
Hunter's "Series 32000 Programmer's Reference Manual", but they ony cover
up to the 32332 and friends.  Could someone please point me to information
on any hardware or sofware differences for the '532?  I know the software
ones are small to non-existant, but I'd like to know details so I can ignore
them in comfort.  The only 32000 I looked at in detail was the 32016 (may
the ghost of my WCW MG-1 rest in peace).  I vaguely recall some software
difference in the '332 (somewhere in the MMU?) but I would appreciate either
(or both of) a summary of the differences (such as burst mode or direct
exceptions) between all the versions or information on newer publications.
                    Thanks!

BTW - if there are no later versions, Colin Hunter's book (Prentice-Hall,
      ISBN 0-13-806936-0) is excellent.
-----
Tom Rushworth - (604) 733-0731         | UUCP: uunet!ubc-cs!van-bc!tacitus!tbr
Timberline Forest Inventory Consultants|maybe: tacitus!tbr@van-bc.wimsey.bc.ca
#302 - 958 W 8th Ave, Vancouver BC,    |unlikely:      tbr@tfic.bc.ca
Canada V5Z 1E5                         |  FAX: (604) 733-0634



From Steven.D.Ligett@mac.dartmouth.edu Fri Apr 20 10:41:40 1990
Date: 20 Apr 90 10:39:37
From: Steven.D.Ligett@mac.dartmouth.edu
To: brahma!bert (Bert Vincent), budd@bu-it (Phil Budne),
        frank@unix.sri.com (Victor R. Frank),
        phil@unicorn.wwu.edu (Phil Nelson), haynes@ucscc.UCSC.EDU (99700000),
        bobm@convex.com, taylor@Think.COM (David Taylor),
        vonb@iitmax.iit.edu (bob von borstel),
        van-bc!tacitus!virgil!tbr (Tom Rushworth),
        FELLOWS%UNB.CA@DARTCMS1.dartmouth.edu (David M. Fellows),
        eyal@ucisae.isae.cancol.oz.au (Eyal Lebedinsky),
        s871943@minyos.xx.rmit.OZ.AU (Simon Burge [Snark]),
        tdavis@zeus.unomaha.edu (Tom Davis),
        sequent!rjk@uunet.UU.NET (Robert Kelley), jonathan@comp.vuw.ac.nz
Subject: pc532-parts test

This is a test of the pc532-parts requestor's list.  If you get this message,
I've gotten a request from you for parts.

More later.

From owner-pc532%daver@mips.com Fri Apr 20 14:21:08 1990
X-Path: mac.dartmouth.edu!Steven.D.Ligett
From: Steven.D.Ligett@mac.dartmouth.edu
To: pc532@daver.bungi.com
Subject: pc532-parts list
Date: 20 Apr 90 10:53:09
Reply-To: pc532@bungi.com
Precedence: bulk

Here is a list of folks who have requested parts for their PC532.  This list
is complete as of Friday morning, April 20th.  Doesn't anyone else want parts? 
We've only got 10 who want the cpu -- it's tough to get quantity discounts for
that quantity.  Please write me soon!

(at pc532-parts@dartmouth.edu)

In general, folks want the 25mhz cpu/etc. as it's not much more expensive than
the 20mhz.  Folks are divided on the parity vs non-parity memory, but that's
ok, as there's no quantity discount in sight (we're not near 1000 pieces).

Yes, I'm seriously behind my schedule for getting all this together.  I have
the usual excuses - I'm purchasing parts for 4 boards for work at the same
time, and doing the artwork for two of them.  (If any of you end up with parts
for a 4-port memory board or a 16-channel localtalk repeater instead of the
pc532 parts, I'm sorry!)

brahma!bert (Bert Vincent)
budd@bu-it.BU.EDU (Phil Budne)
frank@unix.sri.com (Victor R. Frank)
phil@unicorn.wwu.edu (Phil Nelson)
haynes@ucscc.UCSC.EDU (99700000)
bobm@convex.com
taylor@Think.COM (David Taylor)
vonb@iitmax.iit.edu  (bob von borstel)
van-bc!tacitus!virgil!tbr (Tom Rushworth)
FELLOWS%UNB.CA@DARTCMS1.dartmouth.edu  (David M. Fellows)
eyal@ucisae.isae.cancol.oz.au  (Eyal Lebedinsky)
s871943@minyos.xx.rmit.OZ.AU (Simon Burge [Snark])
tdavis@zeus.unomaha.edu  (Tom Davis)
sequent!rjk@uunet.UU.NET (Robert Kelley)
jonathan@comp.vuw.ac.nz

If you're not on this list, and you wrote, try steve.ligett@dartmouth.edu or
...!dartvax!u2!stevel (I think that's how that kind of address goes), or 603
646-3189, or Steve Ligett, Dartmouth College, Kiewit Building, Hanover, NH 
03755.

From owner-pc532%daver@mips.com Fri Apr 20 14:21:23 1990
X-Path: mac.dartmouth.edu!Steven.D.Ligett
From: Steven.D.Ligett@mac.dartmouth.edu
To: pc532@daver.bungi.com
Subject: Re: Bigger ROM?
Date: 20 Apr 90 12:38:50
Reply-To: pc532@bungi.com
Precedence: bulk

--- George wrote:
[In the message entitled "Bigger ROM?" on Apr  5, 13:52, Jordan K. Hubbard
writes:]
> 
> The monitor we'd like to port is 128K (!) and we're wondering if
> there's any (reasonably easy) way to use a larger ROM in place of
> U44.

No, you need extra address lines and they aren't there. the only way to get
a larger EPROM is to cut the trace from pin 1 (U44) to the capacitor. This
trace is +5V and is on the back of the PCB (wasn't that nice of me, I could
have tied it to the power plane!). Then run a trace from it to A15 from the
32532. You can they use a 27512-200ns...
--- end of quoted material ---

Is this change compatible with the Dallas SmartWatch??

From info-mach-Request@SPICE.CS.CMU.EDU Fri Apr 20 09:51:03 1990
Subject: protection faults on Encore
To: os_discuss@osf.org, nags@encore.com, info-mach@CS.CMU.EDU
Date: Fri, 20 Apr 90 09:09:21 -0400
From: Larry Allen <lwa@osf.org>

-------------------------------------------------------------------
Bug Number          (nnnn): 0083
Status           (O,C,D,X): O
Reported by     (mailname): lwa
Report Date     (MM/DD/YY): 04/20/90
Short Descr       (50 max): "random" segmentation faults on Multimax
Found in Build     (Build): osc.9
Priority      (1 hi, 5 lo): 3
Project Plan     (plan ID): 
Responsible Engr(mailname): lwa
Fix by             (Build): 
Fixed in           (Build): 

[lwa 04/20/90]
Application programs, in particular the loader, see seemingly random
segmentation violations on the Multimax.  The cause is an incorrect
Encore workaround for a chip bug.  The chip bug is that it sometimes
reports a write_abort (page fault on a write) as a read_abort (page
fault on a read); this means that on a copy-on-write page, the page
fault code will not copy the page and the fault will recur.  To work
around this, Encore added code to keep track of the last fault that
occurred on each processor, and if exactly the same read fault recurs,
to turn it into a write fault.  The bug is that this "last_fault"
information is not flushed when mappings change.  So, a program like
the loader (for example) maps an address, read faults it, unmaps it,
maps something else there, read faults it again, and the second read
fault (which looks identical to the first one) is turned into a write
fault by the workaround code.  This causes the VM system to report a
protection violation.

The fix is to make the workaround more intelligent: the pmap module
is going to have to invalidate the "last fault" information whenever
a page is pmap_remove'd.
						-Larry Allen
						 Open Software Foundation

From info-mach-Request@SPICE.CS.CMU.EDU Fri Apr 20 16:09:18 1990
To: Larry Allen <lwa@osf.org>
Cc: os_discuss@osf.org, nags@encore.com, info-mach@CS.CMU.EDU, mach@encore.com
Subject: last_fault code for Multimax
Date: Fri, 20 Apr 90 15:22:36 EDT
From: David.Black@G.GP.CS.CMU.EDU

As the original author of the last_fault code, I guess I ought to explain
what's going on here.

The code was originally done for the 32032 (DPC) card for the Encore.  That
mmu (and all ns32000 mmu's) have the property that if a read-modify-write
access is going to fault, the fault occurs on the read cycle (even if it is
a write protection fault).  National Semiconductor claims this is a feature;
you can judge for yourself.  In any case, on the DPC card, there's no way to
tell that the mmu has lied to you (it said "read fault" when the actual
problem is "write fault").  When Encore did the 32332 (APC) card, they
brought out additional cpu status bits to a register on the card.  These
status bits let you figure out that a "read fault" is in fact the first
phase of a read-modify-write, and hence take it as a write fault.  Then came
the 32532 (XPC) card.  Encore brought the same status bits out to a
register, except they didn't work all the time.  National has confirmed that
this is a chip bug in the 32532, one that they have no intention of fixing
(typical for National).

The bug Larry Allen reported is a real bug, but the proposed fix (have
pmap_remove invalidate last_fault information) is going to be expensive.
This invalidation is going to have to happen in other pmap routines in
addition to pmap_remove, and is going to have to check all the last_fault
structures.  The last_fault data probably has to be integrated into the
pvlist structures to get this right.  There's a fair amount of work here.

There's a better solution that involves a bit less work.  I'll start
by describing a 5 minute hackaround that solves the current problem,
but leaves other situations unaddressed.

5 minute hackaround:

Every vm_map structure has a timestamp that is initialized to zero and
incremented by any operation that locks the map for write (to modify it).
Read operations (including the lookup done by the fault handler) do not
increment the timestamp when locking the map for (shared) read.  Add a copy
of this timestamp to the information kept in the last_fault structure
structure, and check it when attempting to use the last_fault information to
upgrade a fault (if the timestamp on the map has changed, presume the
last_fault info to be invalid).  It should be safe to read the timestamp
from the map without a lock, or the map can be locked for read if desired.

This hackaround covers the current case, in which the conflicting operation
must lock the main map for write; what it does not cover is the case in
which the modification that causes the problem takes place to an
intermediate sharing map (e.g., vm_map_copy_overwrite on a different main
map that uses the same sharing map).  To catch this case, we need to add the
full vm_map_version technology to the hackaround.  The basic idea is that
the hackaround is cheap and will cover most of the cases, but if it fails
the full version technology needs to be used to make sure the fault really
does fail.

To do this, when a fault is upgraded, and a protection violation results,
do a vm_map_lookup to get a full version structure back for the fault,
attach this to last_fault, and retry as a read.  If the fault occurs
again, and the full version structure matches (vm_map_verify), then the
fault really should be upgraded to a write (and if it causes a protection
violation, that violation is real).  A quick optimization that can be
applied after doing the vm_map_lookup is that if the share_map in the
version structure is the same as the main map, then the hackaround comparison
of main map version numbers did the right thing and the protection violation
can be taken on the spot.  Remember that both vm_fault and vm_map_lookup
may block, so one has to be careful about the fact that the cpu number
may change across these routines when accessing and modifying last_fault.

There's still some more work to be done to take this outline and turn it
into a formal design, but I think it's a better solution.

--Dave

From info-mach-Request@SPICE.CS.CMU.EDU Fri Apr 20 18:29:51 1990
Subject: Re: last_fault code for Multimax 
To: David.Black@G.GP.CS.CMU.EDU
Cc: Larry Allen <lwa@osf.org>, os_discuss@osf.org, nags@encore.com,
        info-mach@CS.CMU.EDU, mach@encore.com
Date: Fri, 20 Apr 90 16:21:59 -0400
From: Larry Allen <lwa@osf.org>

Hmm, yes, I didn't think of using the map versions.

I guess I wasn't quite as worried about the performance impact
of having to invalidate the last_fault cache.  Are you mostly
concerned because of the need to loop through all the CPU's,
and the (potential) need to lock against concurrent accesses?
Might it be possible to avoid this by invalidating at pmap_deactivate
time as well?  The workaround with checking the map version sounds pretty
complicated to me...  but, I haven't had enough time to think it
through yet.
						-Larry


From info-mach-Request@SPICE.CS.CMU.EDU Fri Apr 20 19:43:15 1990
To: Larry Allen <lwa@osf.org>
Cc: os_discuss@osf.org, nags@encore.com, info-mach@CS.CMU.EDU, mach@encore.com
Subject: Re: last_fault code for Multimax 
Date: Fri, 20 Apr 90 17:16:58 EDT
From: David.Black@G.GP.CS.CMU.EDU

>I guess I wasn't quite as worried about the performance impact
>of having to invalidate the last_fault cache.  Are you mostly
>concerned because of the need to loop through all the CPU's,
>and the (potential) need to lock against concurrent accesses?

I'm worried about two things, this is one of them.  The other is that it
looks like this needs to be hooked into the pvlist data structures in order
to catch all of the required invalidation points (and this is going to
require major work on the guts of the pmap module).  At the minimum,
pmap_remove_all will also have to invalidate.

>Might it be possible to avoid this by invalidating at pmap_deactivate
>time as well?

Not by itself.  What if two processors have the same last_fault data that
needs to be invalidated (multiple threads)?  One of them does the remapping,
and so it gets invalidated.  The other one won't notice and screws up.

On the other hand, I just figured out how to do this without major surgery
on either the trap code or the pmap module: pretend last_fault is an
extension of each processor's TLB!  Invalidate last_fault at pmap_deactivate
(which flushes the TLB), and check it against all TLB invalidation actions
(both local and those initiated by interprocessor interrupts).  All
invalidations name the virtual address range and map that are now invalid,
so it's real easy to check.  The right thing to do is rework the various
TBIA and TBIS macros in the pmap module to do this (and add it to
the PMAP_DEACTIVATE macro).

--Dave

From info-mach-Request@SPICE.CS.CMU.EDU Fri Apr 20 19:43:31 1990
Subject: Re: last_fault code for Multimax 
To: David.Black@G.GP.CS.CMU.EDU
Cc: Larry Allen <lwa@osf.org>, os_discuss@osf.org, nags@encore.com,
        info-mach@CS.CMU.EDU, mach@encore.com
Date: Fri, 20 Apr 90 18:34:10 -0400
From: Larry Allen <lwa@osf.org>

	 >I guess I wasn't quite as worried about the performance impact
	 >of having to invalidate the last_fault cache.  Are you mostly
	 >concerned because of the need to loop through all the CPU's,
	 >and the (potential) need to lock against concurrent accesses?

	 I'm worried about two things, this is one of them.  The other is that it
	 looks like this needs to be hooked into the pvlist data structures in order
	 to catch all of the required invalidation points (and this is going to
	 require major work on the guts of the pmap module).  At the minimum,
	 pmap_remove_all will also have to invalidate.

	 >Might it be possible to avoid this by invalidating at pmap_deactivate
	 >time as well?

	 Not by itself.  What if two processors have the same last_fault data that
	 needs to be invalidated (multiple threads)?  One of them does the remapping,
	 and so it gets invalidated.  The other one won't notice and screws up.

	 On the other hand, I just figured out how to do this without major surgery
	 on either the trap code or the pmap module: pretend last_fault is an
	 extension of each processor's TLB!  Invalidate last_fault at pmap_deactivate
	 (which flushes the TLB), and check it against all TLB invalidation actions
	 (both local and those initiated by interprocessor interrupts).  All
	 invalidations name the virtual address range and map that are now invalid,
	 so it's real easy to check.  The right thing to do is rework the various
	 TBIA and TBIS macros in the pmap module to do this (and add it to
	 the PMAP_DEACTIVATE macro).

	 --Dave

Right, that sounds pretty good.  I missed the "multiple threads in a single
address space" case.  Essentially what you're going to do is
have the TLB shootdown code shoot down the last_fault entry as well.
That way you don't have to worry about checking all the other processor's
last_fault entries at invalidate time.

I think this solves the issue of when to invalidate also, since any time
you invalidate you also have to do a TLB flush on the address.  So, it
doesn't require the major pvlist hackery.  Right?
						-Larry

From info-mach-Request@SPICE.CS.CMU.EDU Fri Apr 20 19:43:47 1990
To: Larry Allen <lwa@osf.org>
Cc: os_discuss@osf.org, nags@encore.com, info-mach@CS.CMU.EDU, mach@encore.com
Subject: Re: last_fault code for Multimax 
Date: Fri, 20 Apr 90 19:05:27 EDT
From: David.Black@G.GP.CS.CMU.EDU

>>On the other hand, I just figured out how to do this without major surgery
>>on either the trap code or the pmap module: pretend last_fault is an
>>extension of each processor's TLB!  Invalidate last_fault at pmap_deactivate
>>(which flushes the TLB), and check it against all TLB invalidation actions
>>(both local and those initiated by interprocessor interrupts).  All
>>invalidations name the virtual address range and map that are now invalid,
>>so it's real easy to check.  The right thing to do is rework the various
>>TBIA and TBIS macros in the pmap module to do this (and add it to
>>the PMAP_DEACTIVATE macro).

>Right, that sounds pretty good.  I missed the "multiple threads in a single
>address space" case.  Essentially what you're going to do is
>have the TLB shootdown code shoot down the last_fault entry as well.
>That way you don't have to worry about checking all the other processor's
>last_fault entries at invalidate time.

That's it, but don't forget about checking last_fault when a TLB invalidate
occurs on the local processor.

>I think this solves the issue of when to invalidate also, since any time
>you invalidate you also have to do a TLB flush on the address.  So, it
>doesn't require the major pvlist hackery.  Right?

Right, the only potential gotcha is that the TLB invalidate in
PMAP_DEACTIVATE is implict; it's done by the next context switch reloading
the page table base register instead of by using an explicit TBIA macro.

--Dave

From info-mach-Request@SPICE.CS.CMU.EDU Sat Apr 21 01:05:18 1990
Subject: Re: last_fault code for Multimax 
To: David.Black@G.GP.CS.CMU.EDU
Cc: Larry Allen <lwa@osf.org>, os_discuss@osf.org, nags@encore.com,
        info-mach@CS.CMU.EDU, mach@encore.com
Date: Fri, 20 Apr 90 19:59:56 -0400
From: Larry Allen <lwa@osf.org>

OK, looks pretty reasonable.  I think I'll try to hack this
up next week.  I'll let you know...
						-Larry

From owner-pc532%daver@mips.com Sat Apr 21 13:17:25 1990
X-Path: wombat!george
From: george@wombat.bungi.COM (George Scolaro)
To: pc532@daver
Subject: 512krom & clock
Date: 21 Apr 90 10:00:12 PDT (Sat)
Reply-To: pc532@bungi.com
Precedence: bulk

Hi folks,
	in a previous posting I mentioned how the pc532 could be modified to
take a 512K bit eprom in place of the current 256K bit device. It involved
cutting & jumping etc. S. Ligett then enquired whether the Dallas SmartWatch
could still be used. Referring to the Dallas databook "All pins pass through
the socket receptacle except for pin 20 (/CE) which is inhibited during the
transfer of time information." The only thing for software people out there
to watch (!) is that Pin 1 (A15) is a /RST pin to the SmartWatch. So, during
accesses to the watch, A15 must be kept high, to prevent the watch thinking
you are doing a reset to it. If all watch software always keeps A15 high it
will be compatible with 256k and 512k versions of the pc532.

The new run of the pc532 is due back the 30th, I have been in contact with
the PCB house to get things set up for the prototype run of the et532 and no
slip has occurred on the pc532.

The et532 prototype run is going to be pretty costly, approx $300/board +
$600 tooling/test for the first 5, ouch! The piggyback is better approx
$30/board + $120 for 30 (they wanted $130/board for a run of 5). I am
confident of the piggyback, its only 2 layers - I can hardly get that wrong.
I have assumed that maybe 30 of you out there will want the et532 in the
next 3 or so months, hence the run of 30 piggybacks, besides the cost delta
between 5 or 30 is only a couple of hundred dollars. This is again for a 4
week turn, which means late May for finished boards.

best regards,

-- 
George Scolaro
george@wombat.bungi.com                [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com Sat Apr 21 15:32:48 1990
X-Path: convex.com!bobm
From: bobm@convex.com
To: pc532@daver.bungi.com
Subject: yet another substitution question
Date: Sat, 21 Apr 90 10:35:57 CDT
Reply-To: pc532@bungi.com
Precedence: bulk

I ordered a bunch of parts from Arrow.  They substituted a 74F153 for
the 74F138 I ordered.  They didn't even tell me; it just showed up
substituted.

Can one successfully substitute a 74F153 for a 74F138 on the pc532?

					K<bob>

(Anybody else notice that this list has a lot higher traffic on
weekends?  I wonder why? (-:)


From owner-pc532%daver@mips.com Sat Apr 21 15:44:53 1990
X-Path: uunet!virtech!rickr
From: Rick Rodman <rickr%virtech%uunet@daver>
To: pc532@bungi.com
Subject: Re: pc532-parts list
Date: Sat, 21 Apr 90 14:42:03 EDT
References: <<1425114@mac.Dartmouth.EDU>>
Reply-To: pc532@bungi.com
Precedence: bulk


You say:
> Here is a list of folks who have requested parts for their PC532.  This list
> is complete as of Friday morning, April 20th.  Doesn't anyone else want parts? 
> We've only got 10 who want the cpu -- it's tough to get quantity discounts for
> that quantity.  Please write me soon!

I have a CPU already, by virtue of having an entire Designer's Kit up and
running.  I'd like to procure a 32GX32 to put in the Designer's Kit board.

I'm interested in a parts kit more of the other parts, however, since it took
me almost 6 months to round up all of the parts for the 532DK and get it
working.  Parity is probably a waste of time - what are you going to do
about a parity error?  ECC would be nicer.

Let me know what you can get and how much the bill would be.

From owner-pc532%daver@mips.com Sat Apr 21 16:18:47 1990
X-Path: wombat!george
From: george@wombat.bungi.COM (George Scolaro)
To: pc532@bungi.com
Subject: Re: yet another substitution question
Date: 21 Apr 90 12:59:16 PDT (Sat)
Reply-To: pc532@bungi.com
Precedence: bulk

[In the message entitled "yet another substitution question" on Apr 21, 10:35, bobm@convex.com writes:]
> 
> I ordered a bunch of parts from Arrow.  They substituted a 74F153 for
> the 74F138 I ordered.  They didn't even tell me; it just showed up
> substituted.
> 
> Can one successfully substitute a 74F153 for a 74F138 on the pc532?

Well, only if the 74F153 had the same die as in the 74F138 :-)
The 74F138 is a 3 -> 8 line decode, the 74F153 is a dual 1 -> 4 line, not
very similar at all! Sounds like Arrow screwed up!

best regards,

-- 
George Scolaro
george@wombat.bungi.com                [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com Sat Apr 21 17:47:14 1990
X-Path: wombat!daver
From: daver@wombat.bungi.COM (Dave Rand)
To: pc532@daver.bungi.com
Subject: Wonders of pi
Date: 21 Apr 90 14:25:45 PDT (Sat)
Reply-To: pc532@bungi.com
Precedence: bulk

Thanks to Jordan for providing the "pi" computation program. It has made
a better life for me, and I'm sure it will do the same for you!

Anyway, I took the opportunity to run the program on a number of platforms,
just to see what happens. Turns out that the time to execute this program
depends on the speed of the integer multiply and divide instructions. In fact,
those processors that do an early out booth algorithm (such as the 386) get
better performance, since the 32 bit numbers are all in the range 1-10000
most of the time. I'll be posting the source code later today. 

Here are the numbers... for 1000 digits, 5000 and 10,000 digits of pi.
Times are in seconds, and do not include I/O time.

			1000		5000		10000
32016 (ICM) CTP		37.1		1008.8
32016 (ICM) GH C	35.2		 973.2
SPARC 4/280 (-O4)	10.7		 276.3
SPARC SS1 (-O4)		 8.3		 229.6		 935.7
SUN 3 (68020)		 7.7		 203.3
SPARC 4/370		 6.2		 171.1		 697.8
SPARC 4/390		 6.2		 169.7		 688.6
PC532 GH C		 5.98		 157.59		 615.77
PC532 GNU C		 5.74		 151.43		 591.77
PC532 CTP		 5.71		 150.61		 588.44
386 25 Mhz w cache	 4.6		 121.8		 482.9
R/6000 (IBM 20 Mhz)	 1.4		  36.9		 143.9
3090 (E class? 55+ mips) 0.6		  17.3		  67.8


And in case you forgot, here it is:

3.141592653589793238462643383279502884197169399375105820974944592378164
06286289986283482534211767982148086513282306647938446095505822317253594
08128481117450284102701938521105559644622948954930381964428810975665933
44612847564823378678316527121909145648566923460348610454326648213393607
26024914127372458700660631558817488152092096282925409171536436789259360
11330535488204665213841469519415116094330572703657595919539218611738193
26117931051185480744623799627495673518857527248912279381831194912983367
33624465664308602139494639522473719072179860943727753921717629317675238
46748184676694051325681271452635608277857713427577896091736371787214684
49012249534314654958537105079227968925892354201995611212902196086403441
81598136297747713099605187072113499999983729780499515973173281696318595
02445945534690830264252230825334468503526193118817110031378387528865875
33208381426171776691473035982534942875546873115956286388235378759375195
77818577853217122680661319278766111959921642019893809525720106548586327
88659361533818279682303019520...


-- 

From owner-pc532%daver@mips.com Thu Apr 19 12:10:29 1990
X-Path: pyramid!pcsbst.pcs.com!meepmeep.pcs.com!jkh
From: jkh@meepmeep.pcs.com (Jordan K. Hubbard)
To: pc532%daver@pyramid
Subject: compiling ROM for burn-in
Date: 19 Apr 90 17:38:34 MSZ (Thu)
Reply-To: pc532@bungi.com
Precedence: bulk

Those wishing to compile Bruce's monitor for either downloading or
ROM operation should do the following:

1. Change DATARND in init532.c from 0x400 to 0x1000.
2. If compiling for downloading (i.e. testing), do:
   2a. Add a jsr to main as the first instruction after start:: in
       resume532.s
   2b. Relink at a different address (e.g. ld -T 2000 -o rom_db ...).

This works well for me.

				Jordan

From owner-pc532%daver@mips.com Mon Apr 23 09:06:21 1990
X-Path: ditka!kls
From: ditka!kls (Karl Swartz)
To: pc532@bungi.com
Subject: et532 prices
Date: Mon, 23 Apr 90 1:01:55 PDT
References: <<9004211000.AA08507@wombat.bungi.COM>>
Reply-To: pc532@bungi.com
Precedence: bulk

> The et532 prototype run is going to be pretty costly, approx $300/board +
> $600 tooling/test for the first 5, ouch!

Ouch indeed. :-(  Do you have any rough idea on parts cost for the
et532?  I suspect the 'GX32 will be major bite, what about the rest?
Which parts can be put off for later if you don't have a pressing
need for the extra 16 serial ports?

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

From owner-pc532%daver@mips.com Mon Apr 23 09:06:51 1990
X-Path: pyramid!swbatl!texbell.uucp!moray!siswat!buck
From: texbell!buck%siswat@moray
To: pc532%daver%pyramid%texbell%moray%siswat@moray
Subject: Miniscribe 9380S SCSI manual
Date: Mon, 23 Apr 90 06:14 CDT
Reply-To: pc532@bungi.com
Precedence: bulk

Here is the information I received from Miniscribe via their 800 number for
ordering a technical manual for the 9380S:

The only manuals available are the product manual, which ships with every
drive, and the maintenance manual, which includes a full set of schematics.
The lady could not confirm that the maintenance manual contained the full
SCSI command set description, but she said that was the only other manual
they sold, so it must be in there.

    Part #1093MA

    $8.00 shipping
    $25.00 manual
    some 15% surcharge for small orders

    Total	$36.75, in advance

    Minscribe Corporation
    1861 Left Hand Circle
    Longmont, CO  80501
    Attn: Spare Parts B-O


Has anyone actually gotten this manual yet?  Is this really the right one?


A. Lester Buck     buck@siswat.lonestar.org  ...!texbell!moray!siswat!buck



From owner-pc532%daver@mips.com Mon Apr 23 12:32:56 1990
X-Path: pyramid!pcsbst.pcs.com!meepmeep.pcs.com!jkh
From: jkh@meepmeep.pcs.com (Jordan K. Hubbard)
To: pc532%daver@pyramid
Subject: yeargh!
Date: 23 Apr 90 17:45:24 MSZ (Mon)
Reply-To: pc532@bungi.com
Precedence: bulk

I didn't quite expect that Dave would post the *entire* set of
stuff I sent him. I sort of figured he'd extract only the parts necessary
and then send on something else. Ah well. In any case, this will certainly get
you pi but won't prove generally adequate (as is more my goal). For one
thing, the stand-alone I/O stuff isn't more than half-baked yet and only
supports terminal I/O. I'm in the process of further generalizing
it and providing for disk I/O as well.

The libc definately wasn't ready for general distribution as things
like "malloc.[ch]" won't compile anywhere near standalone yet; I need
to write the brk() routines that covet some predefined area of the
pc532's memory, among other things.

Foo. I am to blame here since I didn't adequately explain this to Dave.

I guess it's not that big a deal since I can release subsequent changes
as patches to this and at least 90% of what he sent out should remain valid
in any case.

				Jordan

From owner-pc532%daver@mips.com Mon Apr 23 12:50:01 1990
X-Path: pyramid!pcsbst.pcs.com!meepmeep.pcs.com!jkh
From: jkh@meepmeep.pcs.com (Jordan K. Hubbard)
To: pc532%daver@pyramid
Subject: floppy time folks
Date: 23 Apr 90 17:50:59 MSZ (Mon)
Reply-To: pc532@bungi.com
Precedence: bulk

[ I write ]
>expense, would be please please please be possible to get these
                ^^ it
>(and future) changes as diffs? I've also made changes to the monitor

I just gotta learn to proof-read my postings..

On another front, I was just looking trhoug some old mail of Bruce's and came
across the following:

>Of course, the pc532 does not have a floppy.  This concerns me.  About
>the only thing we all will have is a serial interface.  This could be
>used initially for loading the OS, but will get old in a hurry.  Those
>of us with existing SCSI computers can use them to build our hard disks
>but this, too, will quickly become painful.  We need a gestapo to
>choose a tape or floppy scheme and jam it down all our throats.

Right. I couldn't have expressed it better myself. Is someone going to
do this? The time to decide this is long past, and becoming more and
more critical. Now that I've got a system with memory + drive + working
monitor, this is going to have to be the next hardware step.

			Jordan


From owner-pc532%daver@mips.com Mon Apr 23 13:15:09 1990
X-Path: dlr
From: dlr@daver.bungi.com (Dave Rand)
To: pc532@bungi.com
Subject: Re: et532 prices
Date: Mon, 23 Apr 90 09:50:11 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

[In the message entitled "et532 prices" on Apr 23,  1:01, Karl Swartz writes:]
> > The et532 prototype run is going to be pretty costly, approx $300/board +
> > $600 tooling/test for the first 5, ouch!
> 
> Ouch indeed. :-(  Do you have any rough idea on parts cost for the
> et532?  I suspect the 'GX32 will be major bite, what about the rest?
> Which parts can be put off for later if you don't have a pressing
> need for the extra 16 serial ports?

Fortunately, the GX32 is significantly less expensive than the 532. I have
a quote from National and Hamilton Avenet for $110. The OCTARTS can be put
off till later, and are about $30 or so each. Memory will be about $80.
The Ethernet chip set I was able to get a good price on - <$100.


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

From owner-pc532%daver@mips.com Mon Apr 23 13:59:55 1990
X-Path: arthur.wwu.edu!bob
From: bob@arthur.wwu.edu (Bob Hayes)
To: pc532@bungi.com
Subject: 9380 Manuals
Date: Mon, 23 Apr 90 09:45:40 -0800
Reply-To: pc532@bungi.com
Precedence: bulk


<A. Lester Buck     buck@siswat.lonestar.org> writes:
	>The only manuals available are the product manual, which ships
	>with every drive, and the maintenance manual, which includes a
	>full set of schematics.  The lady could not confirm that the
	>maintenance manual contained the full SCSI command set
	>description, but she said that was the only other manual they
	>sold, so it must be in there.
	>    Part #1093MA
	>    $8.00 shipping+ $25.00 manual+ some 15% surcharge 
	>    Total       $36.75, in advance
	>    Minscribe Corporation 1861 Left Hand Circle Longmont, CO
	>   80501 Attn: Spare Parts B-O
	>Has anyone actually gotten this manual yet?  Is this really the
	>right one?
I was told that the part # was "300638002" for the maintenance
manual. Given the above number, a description of "9380S maintenance
manual" and a handful of cash (as you were quoted), Miniscribe shipped
	1) an 9380E ESDI schematic with that number and
	2) the "Product Manual" -numbered #9800-1093.
This 1093 Product manual was NOT what I got with my drive ( that was a
minimal! set of corner stapled pages...not even jumper settings as I
recall). The 9800-1093 Product manual was quoted to me at **$6.50**, and
it WAS to have been shipped with the drive according to MiniScribe.
BTW, $6.50 is the standard price for their product manuals for
other drives, too.

The SCSI descriptions in the 1093 manual are limited to the
listing of their names...no bit patterns,  or vendor unique info,
with the exception of mode select page 32h, which concerns
software settable device id. The disk DOES impliment the
Common Command Set ( so called).
For generic scsi commands see the X3t9.2 draft rev 17b. 

I have seen *NO* item called a maintanance manual!
The 1093 Product Manual is just that..no schematics
but it does have the jumper settings, led flash code
for errors, specs for maximum operational altitude, etc.
In short, the stuff you NEED to work with the drive,
and stuff that should be with the drive and I feel
UPSET at having to pay extra ( in time and $$ ) for it!

I am trying to find out what Miniscribe really has, but it
has been hard to get to people during the sale.
***** Bob Hayes	bob@arthur.wwu.edu *****


From owner-pc532%daver@mips.com Mon Apr 23 13:15:09 1990
X-Path: dlr
From: dlr@daver.bungi.com (Dave Rand)
To: pc532@bungi.com
Subject: Re: et532 prices
Date: Mon, 23 Apr 90 09:50:11 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

[In the message entitled "et532 prices" on Apr 23,  1:01, Karl Swartz writes:]
> > The et532 prototype run is going to be pretty costly, approx $300/board +
> > $600 tooling/test for the first 5, ouch!
> 
> Ouch indeed. :-(  Do you have any rough idea on parts cost for the
> et532?  I suspect the 'GX32 will be major bite, what about the rest?
> Which parts can be put off for later if you don't have a pressing
> need for the extra 16 serial ports?

Fortunately, the GX32 is significantly less expensive than the 532. I have
a quote from National and Hamilton Avenet for $110. The OCTARTS can be put
off till later, and are about $30 or so each. Memory will be about $80.
The Ethernet chip set I was able to get a good price on - <$100.


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

From owner-pc532%daver@mips.com Mon Apr 23 16:01:35 1990
X-Path: arthur.wwu.edu!bob
From: bob@arthur.wwu.edu (Bob Hayes)
To: pc532@bungi.com
Subject: Yet more 9380 Manual
Date: Mon, 23 Apr 90 10:05:51 -0800
Reply-To: pc532@bungi.com
Precedence: bulk

Miniscribe has just RETURNED my call. Wonder of wonders, no wonder
that they had to file chapter 11, they call people back and support
them! They even make reliable products. May their chooks, they
grow amazing, kick their dunny's down!
Descending from ceiling,
The 1093 Product Manual is it. The schematics come seperately, and
that is what you pay (dearly) for. Yes, you should get a set of
9830S schematics. MiniScribe is sending me the correct set, no
hassles.
If you want to know how to get at the reserved cylinders where
the drive parameters are stored, you have to talk to technical service,
who may be of help.
***** Bob Hayes	bob@arthur.wwu.edu *****

From owner-pc532%daver@mips.com Tue Apr 24 03:02:27 1990
X-Path: dogmelb.dog.oz.au!david
From: david@dogmelb.dog.oz.au (David Le Blanc)
To: pc532@bungi.com
Subject: Re:  Miniscribe 9380S SCSI manual
Date: Tue, 24 Apr 90 14:01:20 EST
Reply-To: pc532@bungi.com
Precedence: bulk

HELP!!.


    Having been discussing the Hard disk with the Administrator here at
 CSIRO, I have come to the conclusion that the continuous flashing
 of the hard drive activity light (3-4 times a second when Idle) is
 a BAD sign. Could ANYBODY at all confirm this?

 Secondly : When the drive was originally formatted, I could only
             get 1209 of the 1219 possible cylinders to format.

  Lastly : Every now and then, the drive gratuitously rattles.
           Sounding like the spinning disk has lost its balance
           and vibrates.

 -- David


From owner-pc532%daver@mips.com Tue Apr 24 16:10:19 1990
X-Path: arthur.wwu.edu!bob
From: bob@arthur.wwu.edu (Bob Hayes)
To: pc532@bungi.com
Subject: Manual Manuals
Date: Tue, 24 Apr 90 09:16:46 -0800
Reply-To: pc532@bungi.com
Precedence: bulk

	
<<A. Lester Buck     buck@siswat.lonestar.org >>  writes:
>	I didn't quite follow some of the information in your posting.

Me neither, and I wrote it ;-)
>	I bought two drives and got two copies of the Product Manual,
>	P/N 1093, Revision P10, February 2, 1989.  This is jumpers,
>	specifications, etc.

I did not receive this manual with my single drive! I got a small
set of stapled pages, no jumper info,etc. There was *NOT* enough
information in this pamphlet to do anything with the drive!

I thought that I had received what everyone else did with the drive,
but it's becoming clear that is not the case. 

Based on earlier remarks on the mailing list about the documentation,
I ordered the "Maintenance Manual", my order arrived from MiniScribe
(it said "Product Manual" and 9380E schematics) the day after the drive,
so I had the jumper info. when I powered up the drive.

>	Do you now have the Maintenance Manual or is it still on order?
>	Does the Maintenance Manual have ALL the SCSI information or not?

According to my conversation with MiniScribe, what I have received, the
product manual, is IT. There are schematics, both for the 9380E and
9380S, ESDI and SCSI respectively, but NO MAINTENANCE MANUAL labeled
MAINTENANCE MANUAL.
I have the product manual, it lists the scsi operations by name,
ie. format,read, write...of the Common Command Set. It doesn't
have the Command Block Descriptors ( 6 byte, 10 byte etc, you are
expected to know that already). It provides a written description
of what the command does. There  is some timing info, straight from
scsi spec requirements, flash codes for errors, power requirements,
etc, no surprises here. The only vendor specific info is in regard
to the select paramaters page 32h, software device id selection.
hardware note:
With the product manual and the schematic one could troubleshoot and
probably fix a drive.

MiniScribe's 800 number is: 800 356-5333, the spare-parts extension
is 2293, which may be entered when listening to the canned phone
prompt. The person that I talked with was ? Sherrie Kenny ? , who
pronounced the product manual *IS* the maintenance manual ( when
combined with the schematics).
	
I'm now totally confused ( normal state, actually). It appers like:
1) I got my product manual from Miniscribe, not with the drive.
2) The product manual + schematics constitute the "maintenance manual"
3) If there is another maintenance manual, it is not #1093
 
If anyone can put some light into this smoke, Mr. Buck and I would
appreciate it!
***** Bob Hayes	bob@arthur.wwu.edu *****

From owner-pc532%daver@mips.com Tue Apr 24 16:20:11 1990
X-Path: hplwbc.hpl.hp.com!culberts
From: Bruce Culbertson <culberts@hplwbc.hpl.hp.com>
To: pc532@bungi.com
Subject: Re:  floppy time folks
Date: Tue, 24 Apr 90 09:43:11 pdt
Reply-To: pc532@bungi.com
Precedence: bulk

I wrote:

> >Of course, the pc532 does not have a floppy...  We need a gestapo to
> >choose a tape or floppy scheme and jam it down all our throats.

Jordan Hubbard responded:

> Right. I couldn't have expressed it better myself. Is someone going to
> do this? The time to decide this is long past, and becoming more and
> more critical. Now that I've got a system with memory + drive + working
> monitor, this is going to have to be the next hardware step.

Ironic Jordan should have dredged up my old posting just now.  Over
the weekend I got the pc532 to talk to a floppy and ST-506 style
hard drive (ST-225, to be exact).  This required an OMTI 5200
interface card which Des Young kindly lent me.  I now have purchased
my own OMTI board, $79 surplus, from Halted Specialties, Santa
Clara, CA.

I also needed to make some enhancements to the monitor to make this
work.  The OMTI board does not execute the entire SCSI Common Command
Set and, in particular, does not know about extended read and write,
and extended request sense.  Furthermore, it needs to be initialized
with some commands that tell it what kind of disks are attached to it.

I added a drive table to the monitor.  The "read" and "write" commands
now search the table for the current SCSI address and LUN.  If there
is no entry for the address/LUN, "read" and "write" proceed as before.
Otherwise, there are table entries which tell whether to use extended
or non-extended commands, and there is an entry which says if the
device is initialized.  Another field is a linked list of SCSI commands
to be executed in the event the device is not initialized.  Most of
you will want an empty table, which you get by compiling without
#define'ing OMTI.  However, people with old SASI devices or unusual SCSI
devices may find this additional flexibility useful.

So far, I am very pleased with the OMTI interface.

Bruce Culbertson

From owner-pc532%daver@mips.com Tue Apr 24 16:49:02 1990
X-Path: dlr
From: dlr@daver.bungi.com (Dave Rand)
To: pc532@bungi.com
Subject: Re: Poll + some extract diffs
Date: Tue, 24 Apr 90 13:15:03 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

[In the message entitled "Poll + some extract diffs" on Apr 24, 13:39, Jon Loeliger writes:]
> 
> Who *is* using the FSF's GNU code for their development environment?
I use a combination of the gnu C compiler and Bruce Culbertson's assembler
and linker. I prefer Bruce's assembler because:
	1) It works.
	2) It is Real Fast.

When I looked at gas a while back, it was still not in great shape (for the
32k family).

In addition, I use the Green Hills 32000 compilers, National Semiconductor's
Compiler Technology Products (CTP) C compiler/assembler/linker, National's
DBG32 debugger and MON. The ability to symbolically debug has proved
handy from time to time - so I prefer this environment for getting
things running first whack. It helps to have a native environment, too,
although the National tools are available for SunOS as well.


> 
> Who is planning on using the FSF's GNU code for their development
> environment?

I would prefer to stay with Bruce's assembler and linker for the moment.
Especially during the transition phase of getting things working, it will
be best if we try not to change too many things at once.


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

From owner-pc532%daver@mips.com Tue Apr 24 19:43:47 1990
X-Path: mips.com!musashi.wpd.sgi.com!des
From: des@musashi.wpd.sgi.com (Des Young)
To: pc532@bungi.com
Subject: Floppy Card
Date: Tue, 24 Apr 90 15:18:42 PDT
Reply-To: pc532@bungi.com
Precedence: bulk


Hi,
   since Bruce C and I both have OMTI cards, there is a quorum here :-)
   Seriously, I rang OMTI about SCSI floppy controllers last week.
They make three series, 3500, 5000, 7000. The 5000 series (which I have)
handles 5.25" and 720K 3.5" and 8" floppies. It is a 5.25" form factor.
IT IS SASI. This means you can have multiple devices, but only one
master.
   The 7000 are SCSI, implement the CCS (Common Command Set), drives
3.5" and 5.25", is 5.25" form factor, about $160-170 US.
   The 3500 are SCSI, implement the CCS (Common Command Set), drives
3.5" and 5.25", is 3.5" form factor, about $150 US.
   The 5000 are SASI, DO NOT implement CCS (Common Command Set),
drive 3.5" and 5.25", is 5.25" form factor, about $90 US (2nd hand).
BUT, they also drive ST506/412 wini's (so 1 controller for both
hard and floppy).
   NOTE, the 3500 and 7000 are both FLOPPY ONLY.

   Hope this helps. I do not work for OMTI, actually prefer Adaptec
   hard disk controllers myself, but I have a 5000 product and it
   works. I got it cheap (free), so can't complain.

   Cheers, Des.
--
trademarks abound, usual disclaimers apply, opinions are mine
des@pei.com	Des Young	(415) 335-1888
		Protocol Engines Inc., Mountain View, CA




From owner-pc532%daver@mips.com Thu Apr 26 09:10:29 1990
X-Path: pyramid!pcsbst.pcs.com!meepmeep.pcs.com!jkh
From: jkh@meepmeep.pcs.com (Jordan K. Hubbard)
To: pc532%daver@pyramid
Subject: scsi driver in new ROM monitor
Date: 26 Apr 90 13:03:07 MSZ (Thu)
Reply-To: pc532@bungi.com
Precedence: bulk

Doesn't appear to work. If I run the old monitor, everything works ducky.
If I download the new one and try a read or write, the request times out
with a SELECT failed. Since the select stuff is pretty low-level, I
fail to see why it doesn't work anymore.

On a different note, I notice the Makefile now defines a rule for
ram_db which loads things at a different address. Problem is, this still
won't work since certain startup code in resume532.s is still run, causing
the downloaded monitor to wedge. Since the assembly isn't run through the
pre-processor first, I'm not sure exactly how to conditionally change
this.


From owner-pc532%daver@mips.com Thu Apr 26 14:41:37 1990
X-Path: eleazar.dartmouth.edu!stevel
From: stevel@eleazar.dartmouth.edu (Steve Ligett)
To: pc532@bungi.com
Subject: parts - kits, unkits, prices, more
Date: Thu, 26 Apr 90 13:06:19 -0400
Reply-To: pc532@bungi.com
Precedence: bulk

Here's the parts list in progress.  I've cut it from my mac spreadsheet,
and pasted it into my terminal window here.  It looks awful; I'll make
a final version look better.

Most of these costs are based on 25 people wanting kits -- so some of
these prices may go up.  So far only about 15 people want parts or kits.
lso, I'd like to make a little profit - either in parts or cash, and
these prices don't reflect that, nor even shipping costs.  I'll be happy
to send people some of these items, such as items 1 to 23 (caps,
resistors, etc.) or items 24 to 44 (logic), or any other groups of items.
I could even send out an individual item, but I don't really want to send
out all items 1 to 23 except 11 (for example).

Heck, order anything you want, and I'll let you know if I'll be willing
to do it.  As I mentioned, the more who order, the better the prices.

Prices.  These aren't the best in the world.  I sent the parts list to
a bunch of places, and chose the best prices from a subset of those
places, trying to minimize the number of orders I'll have to place.  If
anyone can get any of these items at a great savings, and wants to
provide them to the list, great!  There are some items that I'm still
trying to get better prices for.  And I think that Dave is looking for
deals on the NSC chip set.

However, if you compare these costs to those Byte listed for 25 mhz 386
boards recently ($800 to $2000, I believe, some without fpu or memory(?)),
you can see that at less than $1700 with fpu and 4 megs, this isn't out
of line.  Nope, it's not as cheap as an 8mhz XT clone.  Foreign orders -
I'll try to work something out.  I'll have to ask Dave and George for
advice (they may be a little burned out by now, though, and perhaps
they're sorry that they started all this!).

Some quick comments on the components.  Item 1 - these are axial lead
caps - you'll have to bend the leads yourself.  Item 4 - George wrote
(me?) that he wanted to put some more 33 uf caps on the board.  I'll
try to have a definite number and locations soon.  Item 12 - these are
fancy rectangular leds, that's why they're so expensive.  Should they
all be red??  Hmmm - I see that my "micro" and "ohm" characters didn't
make the cut & paste.  Items 39-43, 49 pals and eproms - I'll provide
them programmed.  Oh, there's some resistor sips that I've got to
check with George on - some differences between old and new BOMs,
that I'm not sure I've got right yet.  Dip sockets - these are AMP
sockets with gold plating on them, but are not screw machine sockets.
(I've got to check that I've listed the right part numbers for all
of them.)  Oh, I think I only counted sockets for the pals, eprom,
and most expensive things.  If you want to socket everything, let
met know.  XT conectors - so far I've only found ones with ears on
them.  I think I mentioned that there's no electronics supermarkets
near here, this is a rural area (right, Bruce?); I have to drive 20
miles just to buy sheep feed.  So, I'm open to alternatives - send
part numbers!  What else do I have to apologize for - some of these
prices are from Digikey, and I hope to do better; the 9-pin Dsubs
are fancy IDC type with gold, and clamp right on the ribbon cable
from the serial ports.  I've just gotten a catalog of brackets for
IBM cases - so I think I'll have brackets to mount on the back of
your case for the d-subs.

To cut the cost of a machine, you might leave out the fpu, and some
of the serial ports.

I'm open to ideas, drop me a line.  If you have dropped me a line
saying you want parts, hang on - I will get back to you.  (except
tbr@virgil - they don't know you exist.)

I'm sure I'll think of several thoughts I've missed soon after I send
this.  write.

Steve Ligett

Item #	#/Bd	Location	Description	Part Number			Mfg	cost/ea	cost/bd
1	65	various		0.1 uf cap	cac02z5u104m050a		avx/corn$0.06	$3.90
2	1	c75		10 pf cap	sr211a100kaa			avx	$0.07	$0.07
3	12	c59,60,67,68	10\B5\f tant. rad 16v .200 ls				$0.19	$2.28
4	5	c47,?		33\B5\f tant. rad 16v .200 ls				$0.46	$2.30
5	2	c23,24		47 pf cap 10%	sr211a470kaa			avx	$0.07	$0.14
6	1	c77		4.7 pf cap 10%	sr211a4r7daa			avx	$0.07	$0.07
7	1	xtal1		3.6864 mhz xtal	fox0368s			fox	$0.53	$0.53
8	1	u25		50 mhz xtal osc	f1100				fox	$6.15	$6.15
9	1	u34		20 mhz xtal osc	f1100e				fox	$2.29	$2.29
10	1	d2		diode	in4148						$0.02	$0.02
11	2	d1,3		diode	in5817						$0.16	$0.32
12	4	led1:4		red led 0.100" stackable				$0.29	$1.16
13	3	r1,r4,r5	10k \BD\ 1/4 w 5%					$0.01	$0.03
14	1	r2		100 \BD\ 1/4 w 5%					$0.01	$0.01
15	2	f1,2		1 amp fuse	pico II 		littelfuse	$0.32	$0.64
16	1	r6		1k \BD\ 1/4 w 5%					$0.01	$0.01
17	1	r3(?)		330 \BD\ 1/4 w 5%					$0.01	$0.01
18	1	r7(?)		220 \BD\ 1/4 w 5%					$0.01	$0.01
19	6	res2,5:9	22 \BD\ x4 net sip	770-83-r-22		cts	$0.11	$0.66
20	2	res14,15	220 \BD\ x4 net sip	770-83-r-220		cts	$0.11	$0.22
21	4	res3,4,10,11	47 \BD\ x4 net sip	770-83-r-47		cts	$0.11	$0.44
22	1	res13		4.7k \BD\ x15 net dip	761-1-r-4.7k		cts	$0.32	$0.32
23	4	res12,14,17,18	220/330 \BD\ net dip	760-5-r-220/330		cts	$0.43	$1.72
24	1	u30		quad 2 nand	74as00					$0.25	$0.25
25	1	u42		hex inv schmitt	74als14 or 74act14			$0.43	$0.43
26	1	u58		quad 2 or	74ac32					$0.29	$0.29
27	2	u31,32		dual d ff	74as74					$0.29	$0.58
28	1	u33		dual 2/4 decoder74f138					$0.33	$0.33
29	2	u26,50		hex d ff	74as174					$0.79	$1.58
30	3	u27:29		quad 2/1 mux	74as258 or 74as158			$0.62	$1.86
31	4	u1:4		parity		74f280b or 74as280			$0.36	$1.44
32	1	u16		d reg		74as374					$0.98	$0.98
33	1	u43		oct reg xcvr	74as646					$3.20	$3.20
34	2	u14,15		hex 2 or	74as832					$1.26	$2.52
35	4	u5,17,21,22	hex inv		74as1004a				$0.60	$2.40
36	1	u45		hex ninv	74als1034a				$0.33	$0.33
37	2	u18,u23		hex ninv	74as1034a				$0.60	$1.20
38	1	u36		page mode detect74als6311			ti	$7.50	$7.50
39	2	u37,40		pal16l8 -15						$1.10	$2.20
40	1	u38		pal16r6 -15						$1.10	$1.10
41	1	u39		pal16r8 - 10						$3.15	$3.15
42	1	u19		pal20l8 -10						$6.60	$6.60
43	1	u20		gal 20v8a						$0.00	
44	8	u47,49,51,53,54,56,59,61 eia232 xcvr	mc145406 		mot	$2.38	$19.04
45	1	u46		32202 icu 25(?)mhz	ns32202n10		nsc	$23.70	$23.70
46	1	u35		32532 cpu 25mhz	ns32532u25			nsc	$595.00	$595.00
47	1	u24		32381 fpu 25mhz	n232381u25			nsc	$297.00	$297.00
48	4	u10:13		1 meg x8 simm 80 ns	thm81000as-80		toshiba	$75.00	$300.00
49	1	u44		32k by 8 eprom	27256-200				$3.13	$3.13
50	4	u48,52,55,60	duart	scn2681	sig					$5.30	$21.20
51	1	u41		scsi ctlr	aic6250				adaptec	$29.00	$29.00
52	1	u57		scsi ctlr	dp8490 				nsc	$7.35	$7.35
53	1	u44		smartwatch	ds1216e				dallas	$15.80	$15.80
54	2	conn11		ibm at power cntr	09-67-4061		molex	$0.72	$1.44
55	4	conn12:15	31/62 pos ibm xt cntr				digikey	$4.67	$18.68
56	2.5	j1:3,conn1:3,10,16	40x2 pin header	4-103186-0		amp	$2.40	$6.00
57	5			dip shunts					amp	$0.07	$0.35
58	1			175 pin pga skt	510-93-175-005-001		millmax	$8.30	$8.30
59	1			68 pin pga skt					millmax	$3.27	$3.27
60	3			44 pin plcc skt	821575-2			amp	$1.75	$5.25
61	1			68 pin plcc skt	821574-2			amp	$1.95	$1.95
62	8			30 pin vert simm skt	643930-2		amp	$0.00
63	1			14 pin dip skt	2-641609-2			amp	$0.35	$0.35
64	9			16 pin dip skt	2-641610-2			amp	$0.37	$3.33
65	5			20 pin dip skt	2-641612-2			amp	$0.46	$2.30
66	1			28 pin dip skt	2-641615-2			amp	$0.65	$0.65
67	1			40 pin dip skt	2-641616-2			amp	$0.92	$0.92
68	4			10 pin ribbon cntr	746281-1, 746436-1	amp	$0.94	$3.76
69	2			50 pin ribbon cntr	1-449933-0, 1-746094-0	amp	$2.05	$4.10
70	4			9 pin d-sub	747321-4			amp	$2.52	$10.08
71	0						
72										total		$1443.19


From owner-pc532%daver@mips.com Thu Apr 26 15:05:20 1990
X-Path: bu-it.BU.EDU!budd
From: budd@bu-it (Phil Budne)
To: pc532@bungi.com
Subject: Re:  scsi driver in new ROM monitor
Date:  Thu, 26 Apr 90 12:47:31 EDT
Reply-To: pc532@bungi.com
Precedence: bulk

	From: jkh@meepmeep.pcs.com (Jordan K. Hubbard)
	Date: 26 Apr 90 13:03:07 MSZ (Thu)

	On a different note, I notice the Makefile now defines a rule
	for ram_db which loads things at a different address. Problem
	is, this still won't work since certain startup code in
	resume532.s is still run, causing the downloaded monitor to
	wedge. Since the assembly isn't run through the pre-processor
	first, I'm not sure exactly how to conditionally change this.

It should be possible to tell how the monitor was linked by examining
the values of the etext and bdata symbols.  If they are the same, then
no explicit -D flag was given and the monitor must be linked to run in
memory rather than ROM.  I pulled this trick when I ported Xinu to a
68010 and wanted to be able to have the startup code copy BSS if
running in ROM.

I've done most of the work to port Xinu (version 6 - no ethernet) to
the PC532.  I'll need to get my board up before I can do any more!
Xinu would make a good kernel for the et532 or other smart peripheral.
VM Xinu is still in the works (someone's Phd thesis).

Which brings me to a point I've been meaning to raise.  I'd like to
see us use a disk label that allows for multiple operating systems.
Each partition would carry an O/S indicator (say 4 characters, or a
magic number) that would allow the booting system to figure out which
partitions belong to it!

-Phil

From owner-pc532%daver@mips.com Fri Apr 27 14:48:53 1990
X-Path: maxzilla.encore.com!jcallen
From: Jerry Callen <jcallen@maxzilla.encore.com>
To: pc532@daver.bungi.com
Subject: floppy controllers
Date: Fri, 27 Apr 90 11:50:17 EDT
Reply-To: pc532@bungi.com
Precedence: bulk

Hi folks - I've been following the discussion about floppy controllers,
and I think it makes sense to chose one of the OMTI controllers as the
"standard" pc532 floppy controller. I've been swamped for the past month
and done precisely NOTHING towards a homebrew solution. Waiting for me to
supply a board is probably a bad idea. Sorry. I still plan to build something,
but it certainly won't be done until sometime this summer.

-- Jerry Callen
   jcallen@encore.com
   (508) 460-0500 (work)
   (617) 876-5330 (home)

From owner-pc532%daver@mips.com Fri Apr 27 19:07:26 1990
X-Path: mac.dartmouth.edu!Steven.D.Ligett
From: Steven.D.Ligett@mac.dartmouth.edu
To: pc532@bungi.com
Subject: Re: Floppy Card
Date: 27 Apr 90 16:21:13
Reply-To: pc532@bungi.com
Precedence: bulk

--- You wrote:
They make three series, 3500, 5000, 7000. The 5000 series (which I have)
handles 5.25" and 720K 3.5" and 8" floppies. It is a 5.25" form factor.
--- end of quoted material ---
Do any handle 1.44 MB floppies?

From owner-pc532%daver@mips.com Fri Apr 27 20:59:46 1990
X-Path: mips.com!musashi.wpd.sgi.com!des
From: des@musashi.wpd.sgi.com (Des Young)
To: Steven.D.Ligett@mac.dartmouth.edu
Subject: Re: Floppy Card
Date: Fri, 27 Apr 90 17:05:31 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

Hi,
  the question asked was - do any of the OMTI floppy controllers
handle 1.44M floppies. The answer is both the 7000 and 3500 do.
  I would say that the 3500 handles all desired 3.5 and 5.25 floppies,
is smaller form factor, and is the cheapest (for floppy-only solutions).
Cheers, Des.
--
trademarks abound, usual disclaimers apply, opinions are mine
des@pei.com	Des Young	(415) 335-1888
		Protocol Engines Inc., Mountain View, CA




From owner-pc532%daver@mips.com Sat Apr 28 11:48:18 1990
X-Path: mips!ralph!pja
From: pja@ralph.Lafayette.LA.US (Pete Alleman)
To: pc532@bungi.com
Subject: Re: Floppy Card
Date: Sat, 28 Apr 90 10:31:35 CDT
References: <<1466660@mac.Dartmouth.EDU>>
Reply-To: pc532@bungi.com
Precedence: bulk

> --- You wrote:
> They make three series, 3500, 5000, 7000. The 5000 series (which I have)
> handles 5.25" and 720K 3.5" and 8" floppies. It is a 5.25" form factor.
> --- end of quoted material ---
> Do any handle 1.44 MB floppies?

They will all handle 1.44 Mb 3.5" floppies.  On the 5000 series you just
have to set it for high density, 18 sectors per track.  It works fine.

High density is 500Kbit/sec mode and is usually called 8" floppy mode.
Both 1.44MB and 1.2MB floppies use the NEC 765 chip in what was originally
designed as the 8" floppy mode.

The 1.44 Mb 3.5" floppies can fit 18 sectors per track (as opposed to
the 15 sectors per track for 1.2 Mb 5.25") due to the slower rotational
speed of 300 rpm instead of 360 rpm.

Pete.

From owner-pc532%daver@mips.com Mon Apr 30 10:41:02 1990
X-Path: pyramid!pcsbst.pcs.com!meepmeep.pcs.com!jkh
From: jkh@meepmeep.pcs.com (Jordan K. Hubbard)
To: pc532%daver@pyramid
Subject: call for contributions to the PD libc
Date: 30 Apr 90 15:53:51 MSZ (Mon)
Reply-To: pc532@bungi.com
Precedence: bulk

Hi guys. I need a few things and am wondering if anyone can help.
Here's what I have so far:

1. All the usual string functions (and a number of rather unusual ones)
2. Memory->memory ops (memcpy, memcmp, bzero, bcopy, ...)
3. getopt/malloc/regexp/rand

The stand-alone library I've posted deals with the stdio issues, what
I still need are some mathlib routines. A nice start would be atof()
and ftoa(), though I'd also welcome entries from the usual sin/cos/tan
family as well. As the collection grows, I'll organize it and send it
out piecemeal.

					Jordan



From owner-pc532%daver@mips.com Mon Apr 30 11:56:55 1990
X-Path: uunet!tarpit!manatee!John.L.Connin
From: John Connin <johnc%manatee%uunet@daver>
To: pc532@daver.bungi.com
Subject: PC-Minix 1.3 to 1.5.9 update kit..
Date: Mon, 30 Apr 90 8:31:34 EDT
Reply-To: pc532@bungi.com
Precedence: bulk


The current official PC-Minix revision level is 1.5.9 whereas the
version distributed by Prentice-Hall is version 1.3.  The following
message announces the availability of a 1.3 to 1.5.9 update kit.
In a separate message, I have posted instructions indicating
how to access the archive site.

Best regards,
johnc

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

Path: manatee!tous!tarpit!ge-dab!crdgw1!uunet!ogicse!plains!overby
From: overby@plains.UUCP (Glen Overby)
Newsgroups: comp.os.minix
Subject: IBM 1.3 to 1.5.9 upgrade kit available in US
Keywords: oz
Message-ID: <4404@plains.UUCP>
Date: 29 Apr 90 04:07:28 GMT
Reply-To: overby@plains.UUCP (Glen Overby)
Followup-To: poster, alt.dev.null
Organization: North Dakota State University, Fargo
Lines: 27


I have made a copy of Andrew "Noid" Cagney's PC 1.3 to 1.5.9 upgrade kit
available on plains.nodak.edu [134.129.111.64] in the directory
pub/Minix/updates/pc159.  If you only have mail access, it's
archive-server@plains.nodak.edu, uunet!plains!archive-server or
fileserv@plains on Bitnet.  See the announcement I posted last night for
details (and drop the "pub/" on the directory name).

This copy was made at Andrew's request; they prefer that you obtain the kit
from the same continent that you are on (they didn't like all the FTPs
coming in from the U.S.).  I'll probably set up an automagic update

If you're missing a piece of any of the 1.5.x kits, they are available in
the 'updates' directory, too (but probably not for long).

Several people had made remarks to Andrew about the speed of FTPing into
nodak.edu.  We have a single 19.2KB line to NSFNET NSS 14 (Seattle, WA), so
it will be a bit slow.  It's only been recently that we've been able to get
a line faster than 19.2 going west (going east would be shorter and we'd
have been able to get faster lines for a long time, but it was a political
issue, not a technical one) and that should be in late next month (sigh).

Oh, yeah, if you have trouble with the mail server, tell me about it.  I
haven't had it up too long so there may be some kinks.
-- 
		Glen Overby	<overby@plains.nodak.edu>
	uunet!plains!overby (UUCP)  overby@plains (Bitnet)

-- 

From owner-pc532%daver@mips.com Mon Apr 30 11:58:34 1990
X-Path: hopf.math.purdue.edu!wilker
From: wilker@hopf.math.purdue.edu (Clarence Wilkerson)
To: pc532@bungi.com
Subject: Re:  call for contributions to the PD libc
Date: Mon, 30 Apr 90 09:41:37 EST
Reply-To: pc532@bungi.com
Precedence: bulk

Have you checked out the dlibs 1.2 library source for Sozabon C for 68k atari's
and Amigas. You might try terminator.cc.umich.edu for sources.
Clarence Wilkerson

From owner-pc532%daver@mips.com Mon Apr 30 11:59:58 1990
X-Path: uunet!tarpit!manatee!John.L.Connin
From: John Connin <johnc%manatee%uunet@daver>
To: pc532@daver.bungi.com
Subject: Minix Archive Site
Date: Mon, 30 Apr 90 8:20:03 EDT
Reply-To: pc532@bungi.com
Precedence: bulk

FYI:
	--------------------------------------------------

Path: manatee!tous!tarpit!ge-dab!crdgw1!rpi!zaphod.mps.ohio-state.edu!usc!ucsd!rutgers!mephisto!psuvax1!psuvm!cunyvm!ndsuvm1!plains!overby
From: overby@plains.UUCP (Glen Overby)
Newsgroups: comp.os.minix
Subject: Archives in NoDak.EDU moving
Summary: I have moved my "organized" Minix archive onto plains.nodak.edu.
Keywords: moving
Message-ID: <4380@plains.UUCP>
Date: 27 Apr 90 03:58:50 GMT
Reply-To: overby@plains.nodak.edu (Glen Overby)
Organization: North Dakota State University, Fargo
Lines: 101


For the past several years, vm1.nodak.edu has served as an archive site for
the Info-Minix (aka Minix-L on Bitnet) mailing list as well as manually
organized archives.  Unfortunately, many people have had troubles accessing
this archive from uucp and other networks, largely due to the fact that it
was run on an IBM mainframe that uses EBCDIC and 80-character punched
cards.  It was also an inconvenience for me to maintain, since it was a
non-trivial process to move the files from Unix, where I "live", to the
mainframe.

I recently obtained "clearance" to suck up some disk space in our FTP
directory on Plains, and to run a mail-based server for those without FTP
access.

As of the 1.5.6 release, no new files will be stored on the MINIX file
section of LISTSERV; instead they will be available on Plains.

Vm1.NoDak.edu will still archive the mailing list in the MINIX-L file section.

Here is a formal announcement:
---------------------------------------------------------------------------
An archive of Minix upgrades and other interesting files are kept
in    a    manually-maintained    archive   on   Plains.NoDak.edu
[134.129.111.64].

This archive is accessible via anonymous ftp, as well as  with  a
mail server.

ANONYMOUS FTP

Our site accepts FTP logins with the  user  "anonymous"  and  any
password  (network  conventions generally say you should use your
login name, but that is not required).  This machine is also used
for   theoretically  useful  purposes,  such  as  mail,  classes,
research, reading news and playing games.  Thus, we ask that  you
limit  your usage of this to off-peak hours, (for us this is Mid-
night to 8 AM Central time (GMT -6), but we won't get mad if  you
push this a bit earlier in the evening) and weekends.


USING THE MAIL SERVER

For those not fortunate enough to be on the Internet  itself,  we
run  We  run the Clarkson server, which is an extremely versatile
program.  The server has been customized to send HELP  and  Index
files  at  any  time, and all other files between 23:00 and 08:00
local time.  If you submit a request  that  contains  *any*  file
that  is  not  a Help or Index file, the entire request is queued
until late night (currently 23:00, but that may be moved to  ear-
lier  hours of the morning if it proves to be a large load on the
system around that time).

The addresses for the server are:
     archive-server@plains.nodak.edu
     {umn-cs, ogicse, uunet}!plains!archive-server (UUCP)
     fileserv@plains (Bitnet)

Note to Bitnet people: this server is  not  'logged  on'  to  the
machine,  so  you  cannot  send  it  interactive  messages.   The
'fileserv' alias was added for those of you who do  not  run  the
Croswell mailer, but you must still use something that is detect-
able as mail (such as a NOTE).  Bitnet files will drop  into  our
bit bucket, unprocessed, since there is no real user by either of
these names.

To obtain a list of the files, the INDEX command is used:

     INDEX [ <directory> ]

where <directory> is a directory under our ~ftp/pub login  (empty
for  the main directory).  There are several other directories of
programs for Microcomputers, current volumes  for  comp.sources.*
and some of the Free Software Foundation's products.

The SEND command is used for having files sent to  you,  such  as
in:

     send Minix/doc/Info_Sheet

That file is a copy of  the  monthly  "Minix  Information  Sheet"
posting.   The  Minix Compatibility list is available in the file
"Minix/doc/Compatibility".

There are many more options  for  having  your  files  compressed
(note:  most files in these directories already have been), uuen-
coded, split, and so on.   To  obtain  more  information  on  the
server, send the command:

     help

and you will be enlightened.

A warning: this server is somewhat 'probational', that is, if it !!!
turns out to be a serious load on our CPU, mailer, and network   !!!
links then it will be shut down (and then your only alternative  !!!
will again be that listserv thing over on our IBM Iron Pig).     !!!
Use with moderation.                                             !!!

This    archive     is     maintained     by     Glen     Overby,
<minix@plains.nodak.edu>,  at North Dakota State University, Far-
go, ND USA (46 52 N / 96 48 W city)
--
                Glen Overby     <overby@plains.nodak.edu>
        uunet!plains!overby (UUCP)  overby@plains (Bitnet)

-- 

