From owner-pc532%daver@mips.com Fri Jun  1 17:57:03 1990
Flags: 000000000000
X-Path: uunet.UU.NET!hcr!ron
From: ron%hcr@uunet.UU.NET
To: pc532@daver.bungi.com
Subject: IBM/PC C cross development
Date: Fri, 1 Jun 90 13:00:47 EDT
Reply-To: pc532@bungi.com
Precedence: bulk

I have a C compiler, assembler and libraries that run on an
IBM/PC and produce 532 code.  I have also have a host-link
program that allows the 532 to read and write files to the
PC.  The tools need to be targeted to the pc532 (some are for
a 32332 co-processor and 32016 standalone board).  I would
like to get a list of people who are interested in the system.
I can not distribute source for the compiler or assembler.
If fact I can only distribute the compiler for "testing"
so you will have to be "Beta" sites.  If you are interested
in this package send me email (ron@hcr.com).  (I figure $20
(US) should cover the copying and distribution costs).


A brief summary of what I have:

Host:	IBM/PC (preferably an AT or greater, with serial port)
Target:	pc532 board (via serial link)

C compiler:
	The compiler has been used for over 5 years.  It has some
	ANSI features. One strange (limiting) aspect is that
	the entire program must be compiled as a monolithic
	program - there is no linker.  This was fine for the
	original system the compiler was used on since it
	used the import/export feature of the NS32000.  It
	may be a problem for porting UNIX code.
	The compiler is reasonably fast and does some limited
	optimization.
	There are currently problems with
		typedef - I broke this (I will try to fix it)
		floats - never used float so the code is untested

Assembler:
	Target assembler for the compiler.  3 pass optimizing
	assembler.  It produces intel hex format.  I have a
	program that converts this to a binary image.

Host-Link:
	This is a two part interface that allows the target
	pc532 to call the system services of the host PC.
	It allows open/read/write of files from the host
	by the target.  Since this is done over the serial
	link it will be slow (setting the baud to 38K+ will
	help).  I plan to upgrade the link to be a SCSI
	link between my AT and pc532.

Download Driver:
	Program on the IBM/PC to download and run a compiled
	pc532 program.

Ron Irvine,  hcr.com!ron


From owner-pc532%daver@mips.com Fri Jun  1 22:42:49 1990
Flags: 000000000000
X-Path: mips!bu-it.BU.EDU!budd
From: budd@bu-it
To: pc532@daver
Subject: PC532 open/close/read/write standalone I/O system
Date:  Fri, 1 Jun 90 18:21:40 EDT
Reply-To: pc532@bungi.com
Precedence: bulk

I've been working on a standalone I/O system, but as I don't have my
board up yet (!!) I have not been able to test it on bare metal.  I'd
be interested in having a few brave souls shake some bugs out!  It can
be found on BU.EDU in ~ftp/users/budd/32k/PC532/IO/Part0[123]

	-Phil

Here is the README;

Here is a first pass and a full scale standalone I/O system for the
PC532.  It has NOT yet been tested running on real hardware (I'm still
missing some parts!).

It features;
*	a sgtty subset interface for ttys
*	uses 4.3 Tahoe style disklabel
*	several disks/partitions can be open at once.
*	the ability to read files from Minix filesystems.
*	open/close/read/write/ioctl/lseek
*	overkill: dup/dup2

Missing;
*	stdio functions!!!
*	Device Initialization (esp for a SASI floppy ctlr etc)
*	ioctl's for disk label (keep labels in core)
*	ioctl's for formatting!!

bugs/features;
*	sgtty state is per FD (not device!!)
*	Superblock is at (1k!) block 1.  This is dumb.
	it should be at block zero and the boot block and label
	should be accessed using the raw disk (partition 0).

The intended use is for boot roms, secondary bootstraps, standalone
copy, mkfs, and other disk utilities.

pathname syntax;

tt(n)		where n is 1-8 ie; tt(0)

sd(c,u,l,p)	raw disk, ctrlr c, unit u, lun l, partition p
		partition 0 is magic, and always the entire raw disk.

The default is sd(1,0,0,0) (the DP8490 unit 0 lun 0 raw partition)

If the partition contains a filesystem (only minix currently
supported) then a filename may follow (no leading slash needed);
sd(1,1,0,0)minix

(perhaps unit and lun should be encoded into a single value the way
sun does (ie; unit*8 + lun)??)

From ames!mips!daver!owner-pc532@XN.LL.MIT.EDU Sat Jun  2 09:23:42 1990
Flags: 000000000000
Posted-Date: 1 Jun 90 22:39:54 GMT
X-Path: news
From: ames!mips!bu-it.bu.edu!budd@XN.LL.MIT.EDU (Phil Budne)
To: mips!daver.bungi.com!xm-pc532
Subject: Re: Minix runs
Date: 1 Jun 90 22:39:54 GMT
References: <<9006010319.AA19313@virtech.UUCP>>
Reply-To: ames!mips!bungi.com!pc532@XN.LL.MIT.EDU
Precedence: bulk

In article <9006010319.AA19313@virtech.UUCP> someone writes:
>What is "cdiff", for that matter?  I assume it's something like diff.

A context diff (generated using diff -c). cdiffs are much better input
for patch than are plain diffs.

>It's not clear to me if I have access to "Phil Budne's archive."

I keep an ftp archive on BU.EDU in ~ftp/users/budd (see dirs 32k,
32k/PC532 and beowulf)

There are several mail/FTP g/w's (Princeton and CSnet) so you should
be able to list and grab files.

	Phil Budne, Boston University

From ames!mips!daver!owner-pc532@XN.LL.MIT.EDU Sat Jun  2 19:20:34 1990
Flags: 000000000000
Posted-Date: Sat, 2 Jun 90 08:35:27 CDT
X-Path: Central.Sun.COM!Jim.Thompson
From: ames!mips!Central.Sun.COM!Jim.Thompson@XN.LL.MIT.EDU (Jim Thompson)
To: mips!bungi.com!pc532
Subject: PC532 open/close/read/write standalone I/O system
Date: Sat, 2 Jun 90 08:35:27 CDT
References: <<9006012221.AA15539@buit2.bu.edu>>
Reply-To: ames!mips!bungi.com!pc532@XN.LL.MIT.EDU
Precedence: bulk

   X-Path: mips!bu-it.BU.EDU!budd
   From: daver!mips!bu-it.BU.EDU!budd@Sun.COM
   Date:  Fri, 1 Jun 90 18:21:40 EDT
   Reply-To: pc532@bungi.com
   Precedence: bulk

   I've been working on a standalone I/O system, but as I don't have my
   board up yet (!!) I have not been able to test it on bare metal.  I'd
   be interested in having a few brave souls shake some bugs out!  It can
   be found on BU.EDU in ~ftp/users/budd/32k/PC532/IO/Part0[123]

[...]

   (perhaps unit and lun should be encoded into a single value the way
   sun does (ie; unit*8 + lun)??)

Sun is trying not to do this anymore....


Jim


From Steven.D.Ligett@mac.dartmouth.edu Sun Jun  3 15:20:54 1990
Flags: 000000000000
Date: 03 Jun 90 14:58:42
From: Steven.D.Ligett@mac.dartmouth.edu
To: bert@Shiva.COM, wizlair!root@iapetus.rice.edu, bobm@convex.com,
        vonb@iitmax.iit.edu, wilker@hopf.math.purdue.edu, cruff@ncar.ucar.edu,
        FELLOWS%UNB.CA@DARTCMS1.dartmouth.edu, haynes@ucscc.UCSC.EDU,
        taylor@think.com, don@BRL.MIL, hosking@sware.uu.net, eyal@cancol.oz.au,
        garyj@neptun.pcs.com, greg@uhura.cs.wisc.edu, asgard@omni.com,
        jfd@pbhyf.PacBell.COM, conner%empire@hp-col.col.hp.com,
        uunet!tarpit!manatee!johnc, jonb@vector.dallas.tx.us,
        jonathan@comp.vuw.ac.nz, s37814e@kaira.hut.fi, nomad@hydra.convex.com,
        rutgers!csufres.csufresno.edu!csusac!unify!goshawk.mason,
        neals@tekigm2.MEN.TEK.COM, neil@skatter.USask.ca, budd@bu-it,
        phil@unicorn.wwu.edu, virtech!rickr@uunet.UU.NET, rjohnson@kiwi.mpr.ca,
        sequent!rjk@uunet.UU.NET, xrolfa@dna.lu.se,
        871943@minyos.xx.rmit.oz.au, oh1ji@mea.utu.fi,
        uunet!ubc-cs!van-bc!tacitus!tbr, frank@crvax.sri.com
Subject: test

Hi, this is a test of this mailing list.  It's everyone who want parts for the
pc-532, or wants to stay up-to-date as to the status of the parts buy.

The status is, parts are coming in.  I hope to have all the sockets in by June
8th.  I'll send out packages of sockets, caps, resistors, and other such
little things to USA folk so they can get started right away.  I dson't know
if it makes sense to send a separate package of such things out of the country
as the shipping is higher.  Write and tell me what you think.

Also, some memories are in.  I hope everything comes in soon so I can ship
them, as I have to start paying for these things soon!

Prices - I have to get prices back into my spreadsheet.  Then I can send them
out.  Probably not today, tommorrow I hope.  Some things have gone up, some
have gone down.

Below are names, email addresses, and the first line of shipping addresses. 
If there is no shipping address listed, I have none for you (even if I
previously indicated that I did!).

name	ename	addr1
Bert Vincent	bert@Shiva.COM	Shiva Corporation
Bob Greene	wizlair!root@iapetus.rice.edu	
bob miller	bobm@convex.com	3501 N. Jupiter Rd., #5D
bob von borstel	vonb@iitmax.iit.edu	
Clarence Wilkerson	wilker@hopf.math.purdue.edu	
Craig Ruff	cruff@ncar.ucar.edu	3880 Britting Ave.
Dave Fellows	FELLOWS%UNB.CA@DARTCMS1.dartmouth.edu	School of Computer
Science
David Haynes	haynes@ucscc.UCSC.EDU	
David Taylor	taylor@think.com	3A Bellevue Terrace
Don Merritt	don@BRL.MIL	2001 Beech Street
Doug Hosking	hosking@sware.uu.net	3833 Peachtree Rd. NE #509
Eyal Lebedinsky	eyal@cancol.oz.au	SPL (Australia) P/L
Gary Jennejohn	garyj@neptun.pcs.com	Oberfoehringer Str. 63
Greg Thain	greg@uhura.cs.wisc.edu	511 West Johnson 206
J.R. Stoner	asgard@omni.com	
Jeff DeFay	jfd@pbhyf.PacBell.COM	2414 Regis Drive
John Conner	conner%empire@hp-col.col.hp.com	3631 Brentwood Terrace
John L. Connin	uunet!tarpit!manatee!johnc	105 Red Cedar Drive
Jon Buller	jonb@vector.dallas.tx.us	4815 Westgrove #706
Jonathan Stone	jonathan@comp.vuw.ac.nz	Victoria University of Wellington
Kimmo Kivilahti	s37814e@kaira.hut.fi	Matkusjoki
Lee Damon	nomad@hydra.convex.com	3517 Hillridge Dr
Mark Mason	rutgers!csufres.csufresno.edu!csusac!unify!goshawk.mason
c/o Unify Corp.
Neal Sedell	neals@tekigm2.MEN.TEK.COM	
Neil Johnson	neil@skatter.USask.ca	223 Forrester Road
Phil Budne	budd@bu-it.BU.EDU	58 Playstead Rd
Phil Nelson	phil@unicorn.wwu.edu	Computer Science Dept
Rick Rodman	virtech!rickr@uunet.UU.NET	8329 Ivy Glen Court
Robbin W. Johnson	rjohnson@kiwi.mpr.ca	4758 Inman Avenue
Robert Kelley	sequent!rjk@uunet.UU.NET	50 NE Sacramento Street
Rolf Andersson	xrolfa@dna.lu.se	Sankt Mansgatan 9E
Simon Burge	871943@minyos.xx.rmit.oz.au	
Tom Javen	oh1ji@mea.utu.fi	Lajax Oy
Tom Rushworth	uunet!ubc-cs!van-bc!tacitus!tbr	Timberline Forest Inventory
Consultants
Victor Frank	frank@crvax.sri.com	12450 Skyline Blvd.

From owner-pc532%daver@mips.com Sun Jun  3 15:52:39 1990
Flags: 000000000000
X-Path: sibyl.eleceng.ua.oz.au!ian
From: ian@sibyl.eleceng.ua.oz.au
To: pc532@daver.bungi.com
Subject: ROM Monitor and Serial lines.
Date: Sun, 3 Jun 1990 18:07:28 +1000
Reply-To: pc532@bungi.com
Precedence: bulk


Some time ago, I posted some patches to Bruce's monitor (mainly a sed
script and some make file changes) to allow it to be built with all
the GNU tools. At the time I added a disclaimer that I couldn't
actually test the code because my pc532 wasn't working yet. Well, it
is working and I have tested it (and it works).

It seems that the ROM monitor does not raise DTR on the serial ports.
If you have defeated DTR handshaking on whatever you have your pc532
connected to, this is not a problem. I think the appropriate change
is in dblib.s near the end of db_setbaud where it should be

        movb	h'f,14(r2)	; set RTS and DTR on

instead of

	movb	h'3,14(r2)	; set RTS on


Ian Dall.


From owner-pc532%daver@mips.com Mon Jun  4 13:12:13 1990
Flags: 000000000000
X-Path: sibyl.eleceng.ua.oz.au!ian
From: ian@sibyl.eleceng.ua.oz.au
To: pc532@daver.bungi.com
Subject: Hardware Problems
Date: Mon, 4 Jun 1990 12:51:59 +1000
Reply-To: pc532@bungi.com
Precedence: bulk

My board occasionally gets into a stuck state, where "reset" fails to
restart things.

When it is in this state, the LED's are out and the CPU is stopped
with /rdy high. It appears to stop in a write to the AIC6250 or at
least with /scsi selected. I've measured the signals around the WAIT
PAL a DVM which is not the most appropriate instrument, but its the
best I have at home.

		U38
	Pin		Logic Level
      -----------------------------
	1 (ck)		Pulsing (*)
	2 (/eprom)	1
	3 (/scsi)	0
	4 (/bmt)	1
	5 (/ddin)	1
	6 (/slow)	1
	7 (drq)		0
	8 (scsii)	0
	9 (a22)		1
	11 (/oe)	0
	12 (/dack)	1
	13 (/nrdy)	0
	14		1
	15		1
	16		1
	17 (/rd)	1
	18 (/wr)	1
	19 (/eop)	1

* I measure an intermediate voltage so I presume there is clock present.

This fault is difficult to reproduce. This state is *after* I have pressed
reset, however, reset normally does the write thing. Is there some flip
flop somewhere which should be reset and isn't? I have no idea if this is
a design fault or a fault on my particular board.

Ian Dall


From owner-pc532%daver@mips.com Mon Jun  4 13:12:30 1990
Flags: 000000000000
X-Path: col.hp.com!bdale
From: Bdale Garbee <bdale@col.hp.com>
To: pc532@daver.bungi.com
Subject: Minix on the PC532
Date: Mon, 4 Jun 90 10:44:17 mdt
Reply-To: pc532@bungi.com
Precedence: bulk

Saturday afternoon, Minix ran on my PC532.  Bruce asked me to play beta-tester 
for his bits, and I was able to pull some files from his machine at work and 
give it a shot.  Sunday morning, Fred came down with his box, and we were 
successful in building a non-trivial root filesystem with all of Bruce's 
32016 binaries loaded.  Everything seems to be working pretty well, except 
that kermit hangs once in a while when in connected mode on /dev/tty1, and 
xemacs won't grok my terminal type...

Here's the blow-by-blow:

I invented a partitioning for the Miniscribe, which basically includes a 
2100k /dev/hd1 for the kernel image, 10 31500k partitions for filesystems, 
and another 2100k /dev/hdc at the end of the drive for a backup kernel image.  
The numbers don't quite work out to be the entire disk, I realize, but it's 
close enough for now. 

Once I had a partitioning invented, I used my HP 9000/350 with SCSI interface
to dd the kernel on to the front of the disk, and then to dd a 360k root
filesystem image Bruce provided into the first 360k of the /dev/hd2 31500k
partition. 

For the curious, the commands were:
	dd if=min532 of=/dev/rdsk/1s0 bs=1024 seek=2100
	dd if=minix of=/dev/rdsk/1s0 bs=1024 skip=1
The min532 file was the root filesystem, the seek command put it after the
kernel image partition.  The minix file was the kernel, the skip command drops
the a.out.h header from the file as it's copied to the front of the disk.  The
drive was obviously attached as /dev/rdsk/1s0, familiar notation to HP folk.

Then, I moved the disk to my PC532, loaded the kernel using
	read 0 2000 150
and used the output of nm on the kernel to locate and patch the drive table
and partition table for the Miniscribe.  I then saved the kernel image back
out with
	write 0 2000 150
and then loaded and ran the copy from disk with
	read 0 2000 150
	run 2000

and VOILA!  Up came Minix with a banner and login prompt.  

Well, actually, it took about 6 iterations through the process to get all the
numbers right (I finally found my HP 16C calculator in the heap of stuff
in my basement after the 5th try, and quickly fixed my hex conversion errors
[sigh] /o\).

Feeling really up on things, I then went back to the 350, and used Bruce's
toolset compiled for the workstation to rebuild the kernel from scratch with
my modified scsi_hi.c, where Bruce has (temporarily?) kernel-embedded the 
drive and partition tables.  The rebuild looked good, so I went through the
dd process and tried again.  No luck.  After several iterations, I realized
that Bruce was defining 'OMTI' at the top of the scsi_hi.c file instead of
in the Makefile as a -DOMTI, meaning I hadn't realized it was defined, and of
course that was giving me a bogus drive table with strange initializers as far
as the Miniscribe was concerned.  Removing that line, leaving only the
-DM9380S in the Makefile, caused me to get a working kernel, and the next boot
attempt worked great.

Suffering heavily from pine-pollen-induced sinus congestion, I called it quits
for Saturday.

Sunday morning, Fred arrived bright and early, and we dove in again.  This time,
we brought over the 32016 binaries to my workstation, and editted up the mkfs
proto file to include all the binaries.  Running the Minix mkfs compiled for
the workstation, I successfully built and dd'ed a 31500k root filesystem that
included a full set of binaries from Bruce, along with pi.c and the pi 
Makefile.  We moved the disk over, booted the pc532, and were successful in
compiling and running pi on the pc532!  Then, I hooked up a serial line to my
workstation, and we successfully used the second serial port to kermit a file
>From the workstation to the PC532.  However, as earlier mentioned, we had
some problems with hangs, and the kermit seemed to lose out at 9600 baud.  More
on that when I have time to investigate.

There is also a seemingly weird problem where kermit using the connect command
to log in to the workstation, will apparently not flush the received character
buffer to the display for the last partial buffer size without a keypress.  It
doesn't keep you from doing anything, but it's weird to not get the last few
chars of the login prompt, or the shell prompt, until you type the first
character of the next hunk of text you are going to input... this may be a
problem in the serial port driver, in kermit, or in the interaction between
the two.  Regardless, it's annoying enought to deserve some time.  It *IS*
really neat being able to log in to the workstation and kermit files on day
one though!  Thanks Bruce for having your 32016 binaries executable on your
32532 port, and thanks National for making it even possible...  :-)

Since then, I've been pulling the source tree over on to the pc532, in
preparation for trying to recompile the kernel and binaries in place.  Bruce
warns me that he's seeing an occasional SCSI write failure, but I haven't
seen one yet, as far as I can tell.  Bruce, what's the symptom, so I can watch
for it?

Folks, this is pretty exciting stuff!  There are a few things that ought to
be ironed out before everyone jumps in and tries to duplicate our efforts,
like we should provide a kernel pre-configured for the PC532 with Miniscribe
drive.  But, it's pretty close to being a functional machine for us at this
point!

Bruce, job well done on the OS port to date.  I'll shar my changes and send 
them to you tonight, if I have time...  Dave and George, thanks again
for providing such a neat platform to play with! 

Bdale

From owner-pc532%daver@mips.com Mon Jun  4 13:34:41 1990
Flags: 000000000000
X-Path: vw26.chips.com!vw25.chips.com!gs
From: gs@vw25.chips.com (George Scolaro)
To: pc532@bungi.com
Subject: Re: Hardware Problems
Date: Mon, 4 Jun 90 10:29:46 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

[In the message entitled "Hardware Problems" on Jun  4, 12:51, ian@sibyl.eleceng.ua.oz.au writes:]
> My board occasionally gets into a stuck state, where "reset" fails to
> restart things.
> 
> When it is in this state, the LED's are out and the CPU is stopped
> with /rdy high. It appears to stop in a write to the AIC6250 or at
> least with /scsi selected. I've measured the signals around the WAIT
> PAL a DVM which is not the most appropriate instrument, but its the
> best I have at home.
> 
> 		U38
> 	Pin		Logic Level
>       -----------------------------
> 	1 (ck)		Pulsing (*)
> 	2 (/eprom)	1
> 	3 (/scsi)	0
> 	4 (/bmt)	1
> 	5 (/ddin)	1
> 	6 (/slow)	1
> 	7 (drq)		0
> 	8 (scsii)	0
> 	9 (a22)		1
> 	11 (/oe)	0
> 	12 (/dack)	1
> 	13 (/nrdy)	0 ]
> 	14		1 ]
> 	15		1 ] This indicates the IDLEW state in the wait pal.
> 	16		1 ]
> 	17 (/rd)	1
> 	18 (/wr)	1
> 	19 (/eop)	1
> 
> This fault is difficult to reproduce. This state is *after* I have pressed
> reset, however, reset normally does the write thing. Is there some flip
> flop somewhere which should be reset and isn't? I have no idea if this is
> a design fault or a fault on my particular board.

All ff's that should be reset are. The only things that are not are some of
the state machines in the pals. These rely on getting into the 'reset' state,
i.e. the idle state by clocking there. I have not seen the problem you are
having - in fact the IDLEW state that the wait pal is in can only be reached
by performing a read/write to the pseudo-dma port. If you look at the wait
pal source you will see that once in the IDLEW state the only way to exit
is via reset (ie !(!slow & scsi)) or if drq or scsii are asserted (which will
never happen if you get into IDLEW by accident). The only way to get
there is if a bus cycle when bmt & !slow & scsi & !drq & !scsii is true.
This should never happen except for pseudo-dma scsi accesses. i.e. something
is wrong! But if we look at the voltages that you have indicated are present:

	 1      1      0      0       0
	bmt & !slow & scsi & !drq & !scsii

Note: bmt is only asserted (low) in the 1st T-state of a bus cycle, so it
would have been low initially (to get to the IDLEW state). The equation is
true - which explains why you are in the IDLEW state. i.e. the wait pal is
doing the right thing, but for some reason the EPROM boot code is doing
the wrong thing. My bet is that the EPROM is flakey - if it is an AMD part
then toss it and re-program it into a different part. We have had lots of
trouble with AMD EPROMS - we had to return a whole bunch we bought for the
PC532 kits. You may have got one of the few that 'appeared' to work.

anyhow, keep us informed of your progress, - at last some hardware problem
I can think about...

p.s. measuring the signals on the wait pal was exactly the right thing to do.


-- 
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 Mon Jun  4 18:28:54 1990
Flags: 000000000000
X-Path: col.hp.com!bdale
From: Bdale Garbee <bdale@col.hp.com>
To: pc532@daver.bungi.com
Subject: Re: anyone have thoughts re ... 
Date: Mon, 04 Jun 90 14:14:33 MDT
Reply-To: pc532@bungi.com
Precedence: bulk

> 1) whether the pc532 can get by without a fan
>    (if not, what's recommended air flow ?)

We mounted our PC532 boards in PC tower cases, which normally have fans on the
power supply only, exhausting air from high in the box.  The CPU/FPU seemed
to be running warm, so I added a 12V, about 25CFM fan to the bottom front of
the box, in a space apparently intended for this purpose (holes in the right
places, physical perfect fit between the sheet metal of the case and the plastic
front, etc), and everything runs *much* cooler now.  I would suggest some form
of airflow inducement over the CPU/FPU combo.

> 2) how much trouble a pc532 causes with respect to EMI
>    (Is a tightly sealed metal chassis necessary, or can I get away with
>    a chassis built from popsicle sticks ?)
>    The only working pc532 I've seen (Jon Loeliger's) was surrounded by so
>    many other EMI generators that it was almost impossible to gather
>    any meaningful data regarding EMI.

Ditto for mine, plus I've not yet run it with the cover on, and am not likely
to in the near future... my "Bit Basement" is an RF nightmare anyway, with
transmitters on at least 3 amateur radio bands going 24hrs/day, and loads of
computer gear...

> 3) unexpected problems during assembly and troubleshooting ?  I've seen a
>    few mentioned on this list, but given the apparently low percentage of
>    pc532 owners with significant hardware experience, it seems likely that
>    there are some tales worth telling.  If nothing else, I'd expect at least
>    a few DOA chips, given the total number of components installed in pc532
>    systmes to date.

No DOA chips on the two boards I have been involved with (mine and Fred 
Schneider's)... but as reported earlier, we did get some bad 50Mhz oscillators.
That was easy to find, as the first thing I checked when nothing worked was
the osc, and it was flatlined... am running a 40Mhz osc right now, no incentive
yet to buy a 50Mhz part.

In my case, at least, there's lots of hardware knowledge.  But the design of
the board is good enough that it's a non-issue.  Other than a bad osc, we used
my normal board assembly practices, and everything just works great!

> 4) Anyone have recommendations/sources for the misc. stuff (power supply,
>    fan, chassis, terminals, cables, disks, etc.) that's not been included
>    in the group parts buys ?  I'd be especially interested in comments about
>    what to look for re power supplies. I suspect there's a fair amount of
>    junk on the market, and would prefer not to find out the hard way.
>    If you recommend suppliers, please include address and phone number.

Buy a PC tower case with supply, and you're set.  Any of the AT cases and power
supplies should work fine.

Bdale

From owner-pc532%daver@mips.com Mon Jun  4 20:28:21 1990
Flags: 000000000000
X-Path: uunet!tarpit!manatee!John.L.Connin
From: John Connin <johnc%manatee%uunet@daver>
To: pc532@bungi.com
Subject: Re: Hardware Problems
Date: Mon, 4 Jun 90 18:35:17 EDT
References: <<9006041632.19186@munnari.oz.au>>
Reply-To: pc532@bungi.com
Precedence: bulk

> 
> My board occasionally gets into a stuck state, where "reset" fails to
> restart things.
> 
> When it is in this state, the LED's are out and the CPU is stopped

[stuff deleted]

A long-shot, but the problem kinda sounds like the one I had.

In my case, I did not have the 32532 __fully__ seated and as a result
some signals (which unknown) were intermittent.

johnc
--

From owner-pc532%daver@mips.com Tue Jun  5 18:52:43 1990
Flags: 000000000000
X-Path: news
From: levy@nsc.nsc.com (Jonathan Levy)
To: xm-pc532@daver.bungi.com
Subject: Re: anyone have thoughts re ...
Date: 5 Jun 90 16:37:56 GMT
References: <<9006042014.AA14006@hpcsbg.col.hp.com>>
Reply-To: pc532@bungi.com
Organization: National Semiconductor, Santa Clara
Precedence: bulk

In article <9006042014.AA14006@hpcsbg.col.hp.com> bdale@col.hp.com (Bdale Garbee) writes:
>> 1) whether the pc532 can get by without a fan
>>    (if not, what's recommended air flow ?)
>We mounted our PC532 boards in PC tower cases, which normall. In all
>power supply only, exhausting air from high in the box.  The CPU/FPU seemed
>to be running warm, so I added a 12V, about 25CFM fan to the bottom front of

I have worked with systems which incorporated the 532, GX32,
and GX320 (yes, the newly announced CPU, code name Barracuda). In
all the CPU/FPU tend to get very hot to touch, 
but none the less, work flawlessly
at room temperature with no fan. The 532 on my desk used to work
for days on end at 30Mhz with no problems. We also have a GX32 
system running MicroSoft/Bauer Postscript compatible PDL at 30Mhz 
with no fan. This system is very reliable. 

This is not to say that a fan is not a good idea, but to reasure
you that it is quite normal for the 532/381 to get hot. 

Jonathan

From owner-pc532%daver@mips.com Tue Jun  5 19:43:10 1990
Flags: 000000000000
X-Path: uunet!tarpit!manatee!John.L.Connin
From: John Connin <johnc%manatee%uunet@daver>
To: pc532@daver.bungi.com
Subject: Document Scanner (ds532) Proposal..
Date: Tue, 5 Jun 90 8:45:20 EDT
Reply-To: pc532@bungi.com
Precedence: bulk


Document Scanner Idea/Proposal (ds532)
---------------------------------------

First let me make clear that I personally do not have the time to assume 
responsibility for the design and implementation of this proposal !
Therefore, even if there is a strong interest, the realization will require 
a hardware type to step forward and volunteer to do the electronic design.

The idea is to use an existing fully functional surplus document scanner 
module and add to it the necessary control electronics and SCSI interface.  
This is a high-end scanner module which is self-contained and housed in 
attractive plastic casework.  The scanner module contains an automatic 
document feeder, 400 dpi optical section, liquid crystal display (LCD) 
assembly, keyboard assembly, and a 3.5 inch floppy disk.  The electrical 
connections to the module are through three interface connectors.  It's size 
is 23" wide by 22' deep by 5.75" height, exclusive of a document receiver 
tray which can be attached to the left hand side of the module.

Let me emphasize again, this is a very high-end scanner which is 
a self contained module and wrapped in attractive casework.  The resolution
is 400 dpi and the throughput is 18 pages per minute for 8.5 x 11 
inch pages.


Scanner Module:
--------------

The keyboard has 46 keys arranged like an ordinary typewriter.  Four keys
control a cursor and five keys are used for special functions.  The five
keys are "enter", "yes", "no", "stop", and "blank".  The keyboard
assembly is located along the front top surface and also includes
three LED indicators (on, autoprint, alarm), and a screen contrast 
control slide lever.  The keyboard matrix is converted to scan codes by a
8042 processor.

The LCD has a resolution of 128 x 380 pixels. Using 10x8 pixel characters
this corresponds to a 12 line by 60 character display.  The display is
located on the rear top surface.  The contrast can be adjusted by changing
the tilt of the LCD assembly or varying the contract control level mention
previously.  The LCD has a backlight.

The document hopper can hold up to 50 documents.  Oversize documents
up to 11x14 inches may be scanned by opening up the paper guides.  This
actuates a microswitch which in turn causes a 25 percent reduction of
the image in order to fit an 8.5 inch width.  Carrier sheets are
used to scan documents smaller than 8.5 x 11 inches.

The optical assembly is cast aluminum fixture containing a mirror, and lens.
The lens focuses the image onto a 4096 element charged couple device (CCD) 
mounted on a pixel processing circuit board.  This pixel processing board 
is quite sophisticated and includes an automatic shading equalizer, 
dither signal processor for half tone documents, and skewing
depending on 'light', 'normal', 'dark' and 'half tone' modes input
>From the keyboard.  The CCD is shifted out to a 256 level A/D converted
and stored in a 4089 x  8 bit line buffer.  The line buffer is then 
processed applying various corrections and then converted to analog via 
a 16 level D/A converter.

The unit also contains a mechanical interface circuit board which routes
signals, provides stepper motor control, and drive buffering to the
LED's and speaker.  Also a power unit contains a DC-DC converter to
provide +5VDC and +12VDC power.  The power unit also inverts the 
+24VDC to supply high-frequency high-voltage power to light the
scanner fluorescent lamp.


CODEC board:
-----------

As you may have noted the image signal out of the scanner module is analog.
It just so happens that a matching CODEC (coder-decoder) board is 
also available.  In other words a complete SCSI interface scanner system
would include the scanner module, a CODEC board, a custom design
glue board and a power supply.  

The codec board contains the following:  frame memory (2 Megabyte),
memory interface, printer interface, coder/decoder, and buffer.

The scanner image signal is converted to a digital voltage of 8 bits
per byte, buffered into 2 bytes, and written 16 bits at time into
the frame memory.  The memory interface can also on read convert
the 16 bit data to 8-bit parallel output, or serial output.  In 
addition the coder/decoder can optionally compress/decompress the 
image using CCITT run-length encoding (ie GROUP IV, 400 x 400 dpi  
or GROUP III, 200 x 200 dpi).  The coder/decoder is implemented in
hardware using an AMD 2900 processor.

As I envision it, the CODEC, glue circuit board and power supply 
would be located under the scanner module, adding perhaps 1.5 to
2.0 inches to the overall height of the scanner.  It just so 
happens that the scanner module was design to sit on top of a
open top cabinet.

Almost forgot, the CODEC board frame memory (64 - 256K x 1 DRAM) 
was removed during the period of high memory prices. Otherwise,
the boards are complete.


Cost of Scanner module and CODEC board:
--------------------------------------

Would you believe:

	Qty		Approximate Cost (excluding shipping)
	---		------------------------------------
	1		$200
	50 		$125


Of course this does not include the cost of the glue board which we
must design and a power power supply.

It just occurred to me that the original switching power supply module may 
also be available for a nominal amount.  I will check out this possibility
if sufficient interest is expressed for the overall proposal.

BTW: approximately 125 scanner modules and CODEC boards are available.


Proposal:
--------

I hope the above clearly articulates the idea.  If there is 
sufficient interest AND someone volunteers to design the glue board,
then I propose that we organize a group purchase BEFORE the board is 
designed.  Reason, the scanner modules may not be available when the 
board design is complete.  

Of course the down-side to this proposal is that the glue board may never
materialize.  But I submit the exposure of say $125 plus shipping 
is a reasonable risk considering the possible up-side benefits.


Background:
-----------

The scanner is from a Federal Express IPS-3 fax station.  The fax
station comprised the scanner, laser printer, electronics module
and floor standing cabinet.  Unfortunately, the complete fax station 
is no longer available.

I have a complete IPS-3 fax station excluding modem, but including 
maintence level documentation.  The documentation includes schematics, 
parts list, and theory of operation.

So far I have only been using it as a copier, and I might add
the copy quality is excellent.  As a copier, copies can  be made 
in either the collate or non-collate mode.  In the collate mode 
page images are first scanned to an internal harddisk (40Mb), and then 
printed from disk.

I have no association with the surplus house.


Its your turn:
--------------

What do you all think ??  
Any hardware types want to volunteer ??
Is there sufficient interest to move forward ??


Best regards,
johnc		email:  tarpit!manatee!johnc

-- 

From owner-pc532%daver@mips.com Tue Jun  5 23:21:14 1990
Flags: 000000000000
X-Path: chips.chips.com!vw26.chips.com!vw25.chips.com!gs
From: gs@vw25.chips.com (George Scolaro)
To: pc532@bungi.com
Subject: Re: anyone have thoughts re ...
Date: Tue, 5 Jun 90 16:17:00 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

[In the message entitled "Re: anyone have thoughts re ..." on Jun  5, 16:37, Jonathan Levy writes:]
> 
> and GX320 (yes, the newly announced CPU, code name Barracuda). In
> 
> Jonathan

Why not tell us more about the new chips - I wont even call it advertising!
Besides, I'm sure you're dying to.....

thanks,

-- 
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 Jun  7 01:05:28 1990
Flags: 000000000000
X-Path: news
From: levy@nsc.nsc.com (Jonathan Levy)
To: xm-pc532@daver.bungi.com
Subject: New CPUs from National (was:Re: anyone have thoughts re ...)
Keywords: FX16, CG160, GX320
Date: 6 Jun 90 23:17:00 GMT
References: <<m0hcn8v-0000o2C@vw25.chips.com>>
Reply-To: pc532@bungi.com
Organization: National Semiconductor, Santa Clara
Precedence: bulk

In article <m0hcn8v-0000o2C@vw25.chips.com> gs@vw25.chips.com (George Scolaro) writes:
>
>Why not tell us more about the new chips - I wont even call it advertising!
>Besides, I'm sure you're dying to.....
>
>thanks,
>

Well, you twisted my arm :-) ...

I will try to summarize the main points regarding the recent (may 23rd)
announcement from NSC.

Three new processors were announced: The 32CG160, the 32FX16 (both
based on CG16 cores), and the 32GX320 (based on the GX32 core). As
you well know the main thrust of the Series 32000 (now called
Series 32000/EP) is the embedded market with emphasis on office
imaging peripherals. We call this market 'desktop imaging' and it
includes (but is not limited to) printers, faxes, scanners.

The CG160 was designed with the purpose of further reducing the cost
of PostScript laser beam printers in the 4 - 8 ppm range and PCL
printers. This was done by adding to the basic CG16 core 
several H/W modules which reduce system cost and also improve the
performance in certain (printer specific) areas. These are:

   - 2 Channel DMA controller 
   - 3 timer/counters (which can also be used to generate pulse
     width modulated signals).
   - 15 level prioritized interrupt controller
   - BitBLT unit which significantly improves the performance of
     some of the low level bitmap manipulation operations. This
     is especially important for PCL type printers.
   - H/W multiplier 

Other than these additions, the CG160 is fully S/W compatable to
the CG16 (which itself is compatable to the rest of the 32k with
exception of the graphic instructions).

The real innovation in the recent announcement, however, is in the
other two parts, the FX16 and the GX320.

The FX16 was developed to penetrate the emerging (and exploding)
FAX market. It is based on the CG16 core, and as such is fully
compatable to the CG16 (including all graphic instructions). It
does not include any on-chip peripherals. Instead it includes
a special purpose DSP module. This module implemets *just* enough
of the DSP functionality to make it ideal for the FAX modem
implementation. The concept behind the FX16 definiton was not to build a
DSP chip (there are enough of those), but rather to come up with
an embedded processor with enough general purpose computation
power to implement traditional CPU intensive tasks *and* sufficient
DSP power to implement the modem functions of a 9600 baud fax.

The result is a processor that can perform all office peripheral
functions in S/W alone (what is begining to be called the Multi
Functional Office Peripheral). This capability was demonstrated
at our launch by combining PostScript (compatable) PDL, a full
fledged 9600 baud fax, Voice Mail functions, and preview capability.
By combining all these, we also landed with a plain paper fax
(or laser fax).

I hope the above didn't sound *too* much like a commercial, but I
wanted to convey some of the uniqueness to you 32k'ers out there.

The GX320 is based on the GX32 core, and is also targetted at the
Multi-Functional market in addition to the more 'conventional'
applications such as mid-range printers, FAX servers, Communication
servers (Ethernet & FDDI), and others. It is capable of the
same S/W integration as its smaller brother, the FX16, but
has much more general purpose power. This makes it possible 
to support many applications simultaneously.

Some technical info on the GX320:

  - GX32 core ( 0.5k Instruction Cache, 1k Data Cache, 4 Stage
    pipeline etc. In fact, it has all the on-chip goodies of
    the 32532 except MMU and the H/W cache coherency techniques.)
  - H/W multiplier (reduces a MULD to 11 cycles from 37)
  - Performance of certain instructions were improved:
    Set Bit and Clear Bit reduced from 15 to 9 cycles
    Test Bit reduced from 11 to 7 cycles
    Index reduced from 43 to 16 cycles
    Arithmetic Shift (left) reduced from 9 to 5 cycles
  - 4 new *complex arithmetic* instructions were added. 
    These use the H/W multiplier in pipeline: 
    A complex multiply accumulate ( which requires 4 multiplies and 
    2 additions) takes only 12 cycles.
    This makes the S/W implementation of a modem possible.  
  - 2 DMA channels on chip
  - 15 level prioritized interrupt controller on chip
  - 3 timer/counters on chip

As with the FX16, the GX320 is not targetted at pure DSP applications.
These can be implemented with conventional DSP chips (such as the
56001, TMS32C25, TMSC050 etc.) which can have better DSP performance.
The GX320, however, can do what none of the above can do: It can
implemet Postscript (5x - 10x NTX), and at the same time, with no
extra DSP H/W, perform all functions required from a FAX.

By including on the FX16 and GX320 just enough DSP capability to 
perform the most common DSP functions, the user has the option of 
adding/changing/enahcing filter characteristics in S/W. 
This opens the possibility for someone who uses the chips to start off
with a low end FAX, for example, and then add voice cabability, 
data modem capability, and Postscript. All this with no change to
his H/W platform.


Price and availability :
Samples of all the parts are available NOW. Production later this
year.

All prices in 1000 Quantity

CG160   15Mhz	38.90	
	20Mhz	40.70
	25Mhz	48.40

FX16	15Mhz	31.20
	20Mhz	33.60
	25Mhz	40.80

GX320	20Mhz	135.70
	25Mhz	155.25
	30Mhz	224.25

If anyone wants more info please send me e-mail and I will try
to respond personally. If there are more general queries, I will
post a response through the net.

Jonathan

From owner-pc532%daver@mips.com Thu Jun  7 14:24:12 1990
Flags: 000000000000
X-Path: dlr
From: dlr@daver.bungi.com (Dave Rand)
To: pc532@bungi.com
Subject: Re: Info on AIC6250 SCSI chip for PC532?
Date: Thu, 7 Jun 1990 11:02:32 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

[In the message entitled "Info on AIC6250 SCSI chip for PC532?" on Jun  7,  4:41, Craig Ruff writes:]
> I've been gathering the data sheets for the various chips used in the PC532,
> but haven't yet located the sheet for the AIC6250.  Who makes this chip?

Adaptec, Inc
691 South Milpitas Blvd.
Milpitas, CA  95035
+1 408 945-8600
+1 408 262-2533 (fax)


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

From owner-pc532%daver@mips.com Fri Jun  8 13:39:59 1990
Flags: 000000000000
X-Path: pyramid!pcsbst.pcs.com!meepmeep.pcs.com!jkh
From: jkh@meepmeep.pcs.com (Jordan K. Hubbard)
To: pc532%daver@pyramid
Subject: requested clarification of minix issues
Date: 8 Jun 90 17:16:40 MSZ (Fri)
Reply-To: pc532@bungi.com
Precedence: bulk

I, like many of the folks on this list (I assume), am interested in
Bruce's minix port to the pc532 but also somewhat reluctant to jump
into the morass of multiple patches, revisions and strange licensing
issues without some assurance that I won't simply be buried by it all.

I am also not adverse to shelling out some bucks to Prentice-Hall
(since it's not big bucks) for release X.XX if I know for a fact
that I can use it for this project, and that there's a reasonable
upgrade path in sight.

To this end, I think a few works from Bruce about eventual 1.5.X compliance
(or whatever's being bandied around as the "latest" in comp.os.minix),
and what should be purchaed from PH at this point would be very reassuring.

Naturally, everybody wants the latest and greatest (if for no other
reason than being able to apply patches as they come across the net)
without screwing Prof. Tannenbaum out of the few bucks he probably makes
>From all this, so what do we do?

					Jordan


From Steven.D.Ligett@mac.dartmouth.edu Fri Jun  8 00:00:53 1990
Flags: 000000000000
Date: 07 Jun 90 22:45:36
From: Steven.D.Ligett@mac.dartmouth.edu
To: bert@Shiva.COM, wizlair!root@iapetus.rice.edu, bobm@convex.com,
        vonb@iitmax.iit.edu, wilker@hopf.math.purdue.edu, cruff@ncar.ucar.edu,
        FELLOWS%UNB.CA@DARTCMS1.dartmouth.edu, haynes@ucscc.UCSC.EDU,
        taylor@think.com, don@BRL.MIL, hosking@sware.uu.net, eyal@cancol.oz.au,
        garyj@neptun.pcs.com, greg@uhura.cs.wisc.edu, asgard@omni.com,
        jfd@pbhyf.PacBell.COM, conner%empire@hp-col.col.hp.com,
        uunet!tarpit!manatee!johnc, jonb@vector.dallas.tx.us,
        jonathan@comp.vuw.ac.nz, s37814e@kaira.hut.fi, nomad@hydra.convex.com,
        rutgers!csufres.csufresno.edu!csusac!unify!goshawk.mason,
        neals@tekigm2.MEN.TEK.COM, neil@skatter.USask.ca, budd@bu-it,
        phil@unicorn.wwu.edu, virtech!rickr@uunet.UU.NET, rjohnson@kiwi.mpr.ca,
        sequent!rjk@uunet.UU.NET, xrolfa@dna.lu.se,
        871943@minyos.xx.rmit.oz.au, oh1ji@mea.utu.fi,
        uunet!ubc-cs!van-bc!tacitus!tbr, frank@crvax.sri.com,
        mason%tmsoft@toronto.edu, Steven.D.Ligett@mac.dartmouth.edu
Cc: dlr@daver.bungi.com
Subject: Final Prices, payment, etc.

Ok, finally, here are the final prices!  There was a snafu in getting the
CPU chipset - my local distributor said they couldn't honor the quote that
Dave had.  So, Dave has volunteered to buy the cpu chipsets for those who
need them, and send them to me to send to you all.  I mean, he HAS ORDERED
them, and will send them to me.  Also, he has to pay sales tax, and could
only get the 100 piece price, not the 500 piece price.  The final bad news
is that the CPU and FPU may not arrive till the end of July.  The good news 
is that the FPU will be in the cheaper package (that I may have mentioned
before).

Other prices have changed.  Since I couldn't get the NSC parts from my 
local distributor, I decided not to order from them at all, as that order
had to go through Dartmouth, with attendent complications.  Also, some parts
required a 200 to 2000 piece minimum (leds, and caps), so I've made some
changes to what I had planned.  George sent me a drawing with another 12
tantalum caps on it.  At that time I didn't know which were across 12 volts
versus which were across 5, so you're getting overrated caps for many of
the 5 volt places.  (Does everyone have that drawing??)  This affected 
items 1, 3, and 4.  Some of the logic is more expensive since I switched
distributors.  Other parts are a little cheaper.  I increased the number
of sockets, as many want to socket everything.

I don't remember all the changes, you could look at the old list I posted,
if you're interested.  The total with cpu chipset, and 4 megs of memory is
about $1400, a little less than before.  If you add parity memory, it's about
the same as what I quoted before, with non-parity memory.  And this is
70 ns memory, vs the 80 ns memory that I had quoted.

Other than the stuff on the board, I'm including what you need to connect
up your 8 serial ports - some 50 conductor ribbon cable (strip it into
10 conductor parts), the connectors for both ends, screwlock kits to mount
the connectors, and the brackets that are the onto which that the screwlock
kits mount the connectors (;-).  Don't strip all the 50 conductor cable into
pieces - I'm including 2 50 pin connectors so you can hook up a disk drive.

All in all, there's a tale to almost every line of this list.  The end 
result is that Cronin (a distributor) thinks that I'm a pain, but they're
willing to put up with me since I ordered over $10000 of memories and 
connectors, and ...

Prices.  There are two lists of prices.  One lists parts at basicly what
I'm paying, with a little added on where I had to buy extras.  That list
is for those who are buying complete or nearly complete kits (with or
without the CPU bits).  I made a second list for those who are buying just
a few things, where I rounded each price up to the next nickel.  (Except for
the 5 resistors, which I'll only sell together, for a total of 10 cents.)

Shipping, payment, VISA, etc.  I haven't heard back from my bank about VISA
 - I guess they have to custom make one of those imprinters for me (;-/).
And it was pointed out to me that VISA will charge me 3% or 4% of my gross
sales.  So, maybe that clever idea won't pan out.  Maybe it will in a week or
so, I'll keep you up to date.

For those in the USA, who don't want the CPU or FPU - it's time to mail me
your payment.  Not all the parts are here yet, so I'll hold the checks
as needed till the parts are here.  Then I'll deposit them, and send
the parts out in about 48 hours (will that protect me from bad checks?
That's my hope.)  Everything will go out insured, second day delivery -
FED EX, UPS Blue, or USPS express.  My guess is that shipping is about
$10 in the USA.  If it's much more or less than that, I'll get back to
you.  If you're willing to throw in a few extra bucks, I'll be grateful!

For those outside the USA, I'll be writing to you to determine your preferred
payment method.

In fact, I intend to write to everyone on the list individually.  There are
mail messages from about a dozen of you that I haven't answered yet.
I probably will write this weekend.

My postal address is

Steve Ligett
RR#3  Box 451
Lyme, NH  03768

The parts list:

Item #/Bd  Description         cost/ea cost/bd cost/ea
                                in kit         by piece
1   57  0.1 uf cap               $0.10   $5.70   $0.10
2   1   10 pf cap                $0.09   $0.09   $0.10
3   8   22uf tant. 16v .200 ls   $0.27   $2.16   $0.30
4   7   22uf tant. 25v .200 ls   $0.69   $4.83   $0.70
5   2   47 pf cap 10%            $0.09   $0.18   $0.10
6   1   5 (4.7) pf cap           $0.09   $0.09   $0.10
7   1   3.6864 mhz xtal          $0.69   $0.69   $0.70
8   1   50 mhz xtal osc          $6.15   $6.15   $6.15
9   1   20 mhz xtal osc          $3.25   $3.25   $3.25
10  1   diode  1n4148            $0.02   $0.02   $0.05
11  2   diode  1n5717            $0.16   $0.32   $0.20
12  4   led 0.100" stackable     $0.40   $1.60   $0.40
13  3   10k ohm 1/4 w 5%         $0.02   $0.06   $0.02
14  1   100 ohm 1/4 w 5%         $0.02   $0.02   $0.02
15  2   1 amp fuse               $0.32   $0.64   $0.35
16  1   1k ohm 1/4 w 5%          $0.02   $0.02   $0.02
17  1   330 ohm 1/4 w 5%         $0.02   $0.02   $0.02
18  1   220 ohm 1/4 w 5%         $0.02   $0.02   $0.02
19  6   22 ohm x4 net sip        $0.11   $0.66   $0.15
20  2   220 ohm x4 net sip       $0.11   $0.22   $0.15
21  4   47 ohm x4 net sip        $0.11   $0.44   $0.15
22  1   4.7k ohm x15 net dip     $0.32   $0.32   $0.35
23  4   220/330 ohm net dip      $0.50   $2.00   $0.50
24  1   74as00                   $0.29   $0.29   $0.30
25  1   74als14 or 74act14       $0.43   $0.43   $0.45
26  1   74ac32                   $0.29   $0.29   $0.30
27  2   74as74                   $0.35   $0.70   $0.35
28  1   74f138                   $0.33   $0.33   $0.35
29  2   74as174                  $0.97   $1.94   $1.00
30  3   74as258 or 74as158       $0.72   $2.16   $0.75
31  4   74f280b or 74as280       $0.72   $2.88   $0.75
32  1   74as374                  $1.17   $1.17   $1.20
33  1   74as646                  $3.35   $3.35   $3.35
34  2   74as832                  $1.26   $2.52   $1.30
35  4   74as1004a                $0.60   $2.40   $0.60
36  1   74als1034a               $0.33   $0.33   $0.35
37  2   74as1034a                $0.60   $1.20   $0.60
38  1   74als6311                $8.39   $8.39   $8.40
39  1   pal16l8 -15              $1.39   $1.39   $1.40 note - the pals will
40  1   pal16r6 -15              $1.39   $1.39   $1.40 be sent out programmed
41  1   pal16r8 -10              $4.39   $4.39   $4.40
42  1   pal20l8 -10              $6.60   $6.60   $6.60
43  1   gal 20v8a -15            $5.89   $5.89   $5.90
44  8   mc145406                 $1.78  $14.24   $1.80
45  1   32202 icu 10mhz         $21.00  $21.00  $21.00
46  1   32532 cpu 25mhz        $616.00 $616.00 $616.00
47  1   32381 fpu 25mhz        $180.00 $180.00 $180.00
48  4   thm81000as-70           $73.75 $295.00  $73.75 add $10/MB for parity
49  1   27256-200                $3.29   $3.29   $3.30 this will be programmed
50  4   scn2681                  $5.45  $21.80   $5.45
51  1   aic6250                 $29.00  $29.00  $29.00
52  1   dp8490                   $8.00   $8.00   $8.00
53  1   ds1216e                 $19.00  $19.00  $19.00
54  2   ibm at power cntr        $0.47   $0.94   $0.50
55  4   31/62 pos ibm xt cntr    $2.50  $10.00   $2.50
56  2.5 40x2 pin header          $2.40   $6.00   $2.40
57  5   dip shunts               $0.09   $0.45   $0.10
58  1   175 pin pga skt          $8.30   $8.30   $8.30
59  0   68 pin pga skt           $0.00   $0.00   $0.00 FPU will be in PLCC
60  5   44 pin plcc skt          $1.75   $8.75   $1.75
61  2   68 pin plcc skt          $1.95   $3.90   $1.95
62  8   30 pin vert simm skt     $3.10  $24.80   $3.10
63  21  14 pin dip skt           $0.35   $7.35   $0.35
64  14  16 pin dip skt           $0.37   $5.18   $0.40
65  7   20 pin dip skt           $0.46   $3.22   $0.50
65a  3  24 pin dip socket        $0.65   $1.95   $0.65
66  1   28 pin dip skt           $0.92   $0.92   $0.95
67  1   40 pin dip skt           $0.92   $0.92   $0.95
68  8   10 pin ribbon cntr       $0.94   $7.52   $0.95
69  2   50 pin ribbon cntr       $3.25   $6.50   $3.25
70  8   9 pin d-sub              $2.52  $20.16   $2.55
71  8   screwlocks               $0.79   $6.32   $0.80
72  4   d-sub brackets           $2.55  $10.20   $2.55
73  3   50 conductor ribbon      $0.80   $2.40   $0.80

    total                             $1407.69

    total except cpu chipset           $590.69



From owner-pc532%daver@mips.com Fri Jun  8 19:09:00 1990
Flags: 000000000000
X-Path: hplwbc.hpl.hp.com!culberts
From: Bruce Culbertson <culberts@hplwbc.hpl.hp.com>
To: pc532@bungi.com
Subject: Re:  requested clarification of minix issues
Date: Fri, 8 Jun 90 12:24:31 pdt
Reply-To: pc532@bungi.com
Precedence: bulk

In response to Jordan's questions, here is my current thinking on
distributing Minix for the pc532.  I would appreciate your comments.
This is not final!

Here's what I might distribute:

	min.Z, 103K, a minimal file system with all the files
	necessary for booting, plus a few commands

	minix.tar.Z, 252K, includes the OS image, nm output of
	the image so you can patch your disk info into it, all
	sources (not cdiff's) needed to recompile the image,
	libc.a, and a handful of other things

After someone proves they have a legal copy of Minix by mailing
me their official Minix boot disk with the Prentice-Hall copyright
on it, I would return the disk and e-mail the above files to the
individual.  (Is e-mail secure enough for this?  I would be sending
plain-text copyrighted sources.)  The above files could be divided
into 7 pieces of less than 64K bytes each (is that the e-mail
limit?) for e-mailing.  I really would like to avoid copying floppies
and mailing them by conventional mail.

The files I have already mentioned do not include cc, as, ld, ar,
ranlib, etc.  However, these can be legally distributed by putting
the binaries on the BU.EDU archive.  Naturally, special arrangements
will have to be made for those without access to the archive.

The files I have now mentioned, in addition to a standard Minix
distribution, are sufficient to build the whole works.  The
particular Minix version should not be too critical.  I will
post critical gotcha's, like how to fix fsck so it will not
cream your disk.

The latest Minix version is 1.5.10.  It is supposed to be stable
for quite some time because Dr. Tanenbaum has other things to
do.  However, it will not be distributed from Prentice-Hall until
fall.  Prentice-Hall currently is selling 1.3 (plus older versions --
beware).  You can get 1.5.10 by buying some version from Prentice-Hall,
getting an upgrade kit from an archive, and applying a million diff's.
Or, better, get it from a friend who already did all that.

I am aware that getting the latest Minix version is a real pain.
However, it is a problem I do not intend to solve.  I think you
will do just fine with Minix-pc532, even if you do not have the
latest version.  The important thing is that you have the right
sources for the OS image, which you get from the above procedure.

My port is based on 1.3.  I intend to upgrade it to 1.5.10, but I
don't know when.  I might have a look at it this weekend.

So, what do you think?

Bruce Culbertson

From owner-pc532%daver@mips.com Sat Jun  9 12:05:18 1990
Flags: 000000000000
X-Path: uunet!tarpit!manatee!John.L.Connin
From: John Connin <johnc%manatee%uunet@daver>
To: pc532@bungi.com
Subject: Re:  requested clarification of minix issues
Date: Sat, 9 Jun 90 10:27:07 EDT
References: <<9006081924.AA02248@hplwbc.hpl.hp.com>>
Reply-To: pc532@bungi.com
Precedence: bulk

> 
> In response to Jordan's questions, here is my current thinking on
> distributing Minix for the pc532.  I would appreciate your comments.
> This is not final!
> 
> Here's what I might distribute:
> 
> 	min.Z, 103K, a minimal file system with all the files
> 	necessary for booting, plus a few commands
> 
> 	minix.tar.Z, 252K, includes the OS image, nm output of
> 	the image so you can patch your disk info into it, all
> 	sources (not cdiff's) needed to recompile the image,
> 	libc.a, and a handful of other things
> 
> After someone proves they have a legal copy of Minix by mailing
> me their official Minix boot disk with the Prentice-Hall copyright
> on it, I would return the disk and e-mail the above files to the
> individual.  (Is e-mail secure enough for this?  I would be sending
[ stuff deleted]

Possible alternative, assuming AST is agreeable.

AST seems to have no problem with posting binaries and cdiffs to
comp.os.minix.  So what if we ask AST's permission to (1) post the
above (except using cdiff's  for source) to comp.os.minix and (2)
permission to use comp.os.minix in the future as the "official"
channel for PC532-Minix communications.  (I am assuming these
postings would in general be cross-linked to comp.sys.nsc.32k).

Benefits:
  1)  Should eliminate immediate concerns of distributing copyrighted sources
  2)  Keeps AST informed/involved at all times (thinking of futures here)
  3)  Should attract additional interest in the pc532 concept/effort 
  4)  Automaticly provides archive sites in North America, Europe,
      and Australlia (??) 
  5)  etc....

Best regards,
johnc

PS. Some time back I sent an official Minix disk to Dave Rand as
proof of purchase/license.

-- 

From owner-pc532%daver@mips.com Sat Jun  9 13:56:24 1990
Flags: 000000000000
X-Path: news
From: cagney@chook.ua.oz (Andrew Cagney - aka Noid)
To: xm-pc532@daver.bungi.com
Subject: Re:  requested clarification of minix issues
Date: 9 Jun 90 04:38:45 GMT
References: <<9006081924.AA02248@hplwbc.hpl.hp.com>>
Reply-To: pc532@bungi.com
Precedence: bulk

Sorry about being a bit `minix technical'

>From article <9006081924.AA02248@hplwbc.hpl.hp.com>, by culberts@hplwbc.hpl.hp.com (Bruce Culbertson):
> The latest Minix version is 1.5.10.  It is supposed to be stable
> for quite some time because Dr. Tanenbaum has other things to
> do.

To the end user, this version is a significant improvement over 1.3
	- many more commands (115 -> 160)
	- Much improved libc & include.
	- Additional software including UUCP is available for ftp/fetchfile.
It has also seen a re-merge of the st & ibm versions. They are now
identical except for the kernel proper. In addition, there is a 386 32bit
version arround. (Again only the kernel is changed)

> beware).  You can get 1.5.10 by buying some version from Prentice-Hall,
> getting an upgrade kit from an archive, and applying a million diff's.

Fair comment. The process is very time consuming. In addition, the the less
UNIX/C experience you have the slower it will be.

> My port is based on 1.3.  I intend to upgrade it to 1.5.10, but I
> don't know when.  I might have a look at it this weekend.

Two key area's are effected
	1. None of the existing 1.5 versions (ibm 386 atari mac amiga)
	   understand single pages. The 386 32bit version for instance
	   has taken a simple minded approach and allocates contigious memory
	   to a process. The MM process would again need modifying to support
	   page level allocation.
	2. The Kernel, in places,  was given a rewrite. This this includes
	   how the kernel initially interacts with the MM & FS
So to guess :-) I expect most of the work to be in the MM & Kernel. I'd also
expect there to be a significant amount of work required. Most of it being
the booring job of rearanging things so they interact correctly with the
1.5 MM & FS. Not a job for one weekend :-(.

> latest version.  The important thing is that you have the right
> sources for the OS image, which you get from the above procedure.

I don't know about the legalities of your distribution method but your
justification is spot on. The last thing someone wants to be doing is
spending weeks developing the cross developement environment, compiling
MINIX, fixing compiler bugs...

Having the patches available for ftp may also be useful. This would allow
others (eg us here) with older NS32 versions of minix to catch up.


				Andrew Cagney

From owner-pc532%daver@mips.com Sat Jun  9 13:56:24 1990
Flags: 000000000000
X-Path: news
From: cruff@ncar.ucar.edu (Craig Ruff)
To: xm-pc532@daver.bungi.com
Subject: Re:  requested clarification of minix issues
Date: 9 Jun 90 14:31:03 GMT
References: <<9006081924.AA02248@hplwbc.hpl.hp.com>>
Reply-To: pc532@bungi.com
Organization: Scientific Computing Division/NCAR, Boulder CO
Precedence: bulk

In article <9006081924.AA02248@hplwbc.hpl.hp.com> culberts@hplwbc.hpl.hp.com (Bruce Culbertson) writes:
>	minix.tar.Z, 252K, includes the OS image, nm output of
>	the image so you can patch your disk info into it, all
>	sources (not cdiff's) needed to recompile the image,
>	libc.a, and a handful of other things

I think this will be the more useful of the two.

>After someone proves they have a legal copy of Minix by mailing
>me their official Minix boot disk with the Prentice-Hall copyright

Is this really necessary?  I'm considering getting the 1/2" tape version.
Do you want me to mail the tape?  Would it be sufficient to e-mail part
of a program included in the distribution that hasn't been published?
Perhaps the part should be chosen on a case by case basis.  Well, that
may be too much trouble.  Of course, the Mac version may be available by
then and I'll just get that instead.  (Then mailing a floppy isn't much
of a problem.)

>on it, I would return the disk and e-mail the above files to the individual.

E-mail is fine for me.  Are the pieces included in minix.tar.Z really useful
by themselves?  For example, if it was just the kernel, mm, fs and 32k-specific
parts of libc, it might make sense to place it into the archive too.
A person would still need the rest of Minix to get things running.
-- 
Craig Ruff      	NCAR			cruff@ncar.ucar.edu
(303) 497-1211  	P.O. Box 3000
			Boulder, CO  80307

From owner-pc532%daver@mips.com Sat Jun  9 16:06:26 1990
Flags: 000000000000
X-Path: uunet!ladcgw!l66a.ladc.bull.com!Mark-Geisert
From: Mark Geisert <Mark-Geisert@l66a.ladc.bull.com>
To: pc532@bungi.COM
Subject: Re: Re: requested clarification of minix issues
Date: Sat, 09 Jun 90 11:53 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

In a recent posting, Bruce Culbertson wrote:
> After someone proves they have a legal copy of Minix by mailing
> me their official Minix boot disk with the Prentice-Hall copyright
> on it, I would return the disk and e-mail the above files to the
> individual.  (Is e-mail secure enough for this?  I would be sending
> plain-text copyrighted sources.)  The above files could be divided
> into 7 pieces of less than 64K bytes each (is that the e-mail
> limit?) for e-mailing.  I really would like to avoid copying floppies
> and mailing them by conventional mail.
 
To verify ownership of a legal copy of Minix, how about..
(1) prospective user snail-mails a photocopy of his Minix boot disk
    (with the P-H copyright on it) and his own e-mail address
    to Bruce
(2) Bruce challenges prospective user by e-mail with a 'simple'
    question that only the holder of the Minix diskettes can
    answer
(3) prospective user e-mails the answer to the question (or begs
    for another question?)
(4) Bruce e-mails Minix materials.
 
Re e-mail security, there is none :-).  Perhaps you could leave
out something(s) that are essential from your materials.. something
that can be supplied by the holder of Minix diskettes.
 
Just some ideas......
 
..mark  (Mark-Geisert@LADC.Bull.COM or ..!uunet!ladcgw!Mark-Geisert)

From owner-pc532%daver@mips.com Sat Jun  9 19:25:11 1990
Flags: 000000000000
X-Path: dlr
From: dlr@daver.bungi.com (Dave Rand)
To: pc532@bungi.com
Subject: Re: Re: requested clarification of minix issues
Date: Sat, 9 Jun 1990 16:20:26 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

[In the message entitled "Re: Re: requested clarification of minix issues" on Jun  9, 11:53, Mark Geisert writes:]
> To verify ownership of a legal copy of Minix, how about..

The only way to "prove" ownership is to mail the _original_ disk, with
the P/H copyright notice on it. This is the only proof that is acceptable,
to me at least. No photocopies, "challanges", or anything else will suffice.
Bruce, George and I went over this issue a few months ago. Same goes for
tapes - send the original tape. 

As a reminder: Andrew S. Tanenbaum wrote MINIX. He does not, however,
hold the copyright. Prentice-Hall holds the copyright. Even if AST tells
us that we can mass-duplicate it, and give it away - we still must confirm
this with Prentice-Hall's lawyers. We all know what they will say.

I will be happy to handle this, if no one else wants to.


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

From owner-pc532%daver@mips.com Sat Jun  9 21:31:20 1990
Flags: 000000000000
X-Path: comp.vuw.ac.nz!jonathan
From: jonathan@comp.vuw.ac.nz
To: pc532@bungi.com
Subject: Re: Re: Re: requested clarification of minix issues 
Date: Sun, 10 Jun 90 13:07:16 +1200
Reply-To: pc532@bungi.com
Precedence: bulk


    
    
    [In the message entitled "Re: Re: requested clarification of minix issues" 
   on Jun  9, 11:53, Mark Geisert writes:]
    > To verify ownership of a legal copy of Minix, how about..
    
    The only way to "prove" ownership is to mail the _original_ disk, with
    the P/H copyright notice on it. This is the only proof that is acceptable,
    to me at least. No photocopies, "challanges", or anything else will suffice

What about if one's _original_ disk, with the P/H copyright
notice on it, was stolen?
This really happened here; does not having the original disk
leave me absolutely out in the cold?

How about constructing a patch kit containing cdifs for the NS32k
the minix  kernel, mm, and fs, with new files as appropriate?
I'd be happy with diffs from *any*  PC-minix version.  And I do mean *any*:

	 1.1		(the original floppy or tape from PH)
	 1.2		(the second floppy version from PH)
	 1.3[a-f]	(the pre-release kits or the third floppy)
         1.4.x		(never released by PH)
	 1.5.x		(not yet released by PH)

for any x. (The only original PH floppies I had were 1.1)
I still have all these versions, or can at least re-generate
them from patch kits. I'm sure I'm not the only one.

Similar patch kits have been posted to Usenet by ast@cs.vu.nl; others
are available for anonymous FTP.   I think this solution would
be far and away the easiest for those of us who *do* follow
comp.os.minix.

--Jonathan Stone

From owner-pc532%daver@mips.com Sun Jun 10 00:37:55 1990
Flags: 000000000000
X-Path: dlr
From: dlr@daver.bungi.com (Dave Rand)
To: pc532@bungi.com
Subject: Re: Re: Re: requested clarification of minix issues
Date: Sat, 9 Jun 1990 21:14:20 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

[In the message entitled "Re: Re: Re: requested clarification of minix issues" on Jun 10, 13:07, jonathan@comp.vuw.ac.nz writes:]
>     [In the message entitled "Re: Re: requested clarification of minix issues" 
>    on Jun  9, 11:53, Mark Geisert writes:]
>     > To verify ownership of a legal copy of Minix, how about..
>     
>     The only way to "prove" ownership is to mail the _original_ disk, with
>     the P/H copyright notice on it. This is the only proof that is acceptable,
>     to me at least. No photocopies, "challanges", or anything else will suffice
> 
> What about if one's _original_ disk, with the P/H copyright
> notice on it, was stolen?
> This really happened here; does not having the original disk
> leave me absolutely out in the cold?

A case such as yours can be handled on an individual basis. Still, to avoid
copyright infringment, we must have some assurance that appropriate
royalties have been paid. A receipt would suffice, or other written
assurance. Besides, the MINIX disks are _very_ cheap; another copy can be
purchased. I have done this on more than one occasion.

Context diffs are an option for those that have a current working system,
but to provide an easy "first start" for the people just starting, the
current solution is the best. As we make changes to the system, context
diffs make sense, and should be used.  Bruce's modifications go beyond a
two-line change though :-)

Can we end this discussion now?

On other topics, there has been a major upheaval at National Semiconductor.
I do not know what the long term implication for the pc532 project is. It
has delayed (again) some announcements from George and I... I'll keep
you up to date.



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

From owner-pc532%daver@mips.com Sun Jun 10 13:26:06 1990
Flags: 000000000000
X-Path: sibyl.eleceng.ua.oz.au!ian
From: ian@sibyl.eleceng.ua.oz.au
To: pc532@bungi.com
Subject: Re: Hardware Problems
Date: Mon, 11 Jun 1990 01:20:57 +1000
References: <<m0hcLFL-0000oKC@vw25.chips.com>>
Reply-To: pc532@bungi.com
Precedence: bulk


George Scolaro writes:
 > [In the message entitled "Hardware Problems" on Jun  4, 12:51, ian@sibyl.eleceng.ua.oz.au writes:]
 > > My board occasionally gets into a stuck state, where "reset" fails to
 > > restart things.
 > > 
 > > When it is in this state, the LED's are out and the CPU is stopped
 > > with /rdy high. It appears to stop in a write to the AIC6250 or at
 > > least with /scsi selected. I've measured the signals around the WAIT
 > > PAL a DVM which is not the most appropriate instrument, but its the
 > > best I have at home.

Things have deteriorated! I can no longer talk to the serial port at
all and the "stuck" state is now quite reproducable. What happens is
this.  On power up (or "successful" reset) the leds go out almost
immediately and there are pulses on the icu select line for about
30sec. There are also pulses on the erom, and scsi lines for a much
shorter period. The DUART never gets selected. During the 30 seconds
there are pulses on the dram select line. After the 30sec the only
thing that ever gets selected is the DRAM. Eventually (10minutes) the
thing gets totally stuck with scsi selected and the cpu waiting for
rdy. If I reset before the "stuck" state then the cycle is repeatable.
If I wait until it is "stuck" then reset won't work and the only way out
is to power off.

The "stuck so it won't reset problem" seemed the easiest to attack so
I investigated it further. It seems that reseting the wait pal from
the "idlew" state is supposed to happen when the cpu starts its first
bus cycle to the eprom. Well, /slow and /scsi can both be observed to
momentarilly change state (to 0 and 1 respectively) when the reset is
removed. I can't for the moment say whether that happens
simultaneously. I've borrowed a logic probe but not a logic analyser
yet! The eprom also gets momentarilly selected when reset is raised
but that is about all that happens before it is stuck in the same
"idlew" state as before!  The swap signal is also high.

My current hypothesis is that the select pal is dodgy. I will attempt
to run the test vectors on all the pals tomorrow (don't actually know
if our programmer will do that). I can't think of many hypotheses which
let "reset" work when the system is in any state except "idlew".

Other observations: When it was working, I *think* the monitor idle
loop got totally cached and there where no dram accesses (except for
refresh), so it is a bit strange that it now sits there accessing RAM.
Of course, if it is slowly executing garbage until it hits the scsi
select problem then I suppose that would explain why it is doing DRAM
accesses, but maybe it is a sign that the chip select is broken.  I
have also tried removing the parity GAL but it makes no apparant
difference.

I have three eproms. The original monitor that came with the system,
the most recent binary that Bruce posted and also a locally compiled
version. They all exhibit this behaviour, so I am disinclined to think
it is a eprom problem.

I am for now assuming that the "can't talk to the duart" and "stuck so
it won't reset" problems are symtoms of the same fault.

Any suggestions are still very much welcome!

Ian Dall.

P.S. Should I discuss this directly with George or is there enough interest
     to warrant posting to the whole list?


From owner-pc532%daver@mips.com Sun Jun 10 14:39:51 1990
Flags: 000000000000
X-Path: wombat!george
From: george@wombat.bungi.COM (George Scolaro)
To: pc532@bungi.com
Subject: Re: Hardware Problems
Date: 10 Jun 90 11:01:08 PDT (Sun)
Reply-To: pc532@bungi.com
Precedence: bulk

[In the message entitled "Re: Hardware Problems" on Jun 11,  1:20, ian@sibyl.eleceng.ua.oz.au writes:]
> 
> Things have deteriorated! I can no longer talk to the serial port at
> all and the "stuck" state is now quite reproducable. What happens is

As John Connin mentioned, have you ensured that the 32532 is fully seated
in it's socket. There are 4 pins (near each corner of the chip) which have
small rings that should seat all the way flush with the socket. The 32532
should be pushed all the way it until this occurs - it does take a lot of
pressure - i.e. place the board flat on something a bit soft (several sheets
of newspaper) and then stand over the board and with the palm of the hand
PUSH until the chip is fully seated (if you ever have to extract the 32532
you will discover the wonders of splintering ceramic - unless you have a
PGA chip extractor!).

> thing that ever gets selected is the DRAM. Eventually (10minutes) the
> thing gets totally stuck with scsi selected and the cpu waiting for
> rdy. If I reset before the "stuck" state then the cycle is repeatable.
> If I wait until it is "stuck" then reset won't work and the only way out
> is to power off.

You definitely have some major problem - a dead chip or bad contact.

> The "stuck so it won't reset problem" seemed the easiest to attack so
> I investigated it further. It seems that reseting the wait pal from
> the "idlew" state is supposed to happen when the cpu starts its first
> bus cycle to the eprom. Well, /slow and /scsi can both be observed to
> momentarilly change state (to 0 and 1 respectively) when the reset is

/SLOW is asserted for all slow devices - i.e. checking the DEC32 equations:

SLOW	= EPROM (in both swapped and non-swapped positions)
	# duart (all 4)
	# scsi (software polled only - Not pseudo-dma)
	# icu.

> removed. I can't for the moment say whether that happens
> simultaneously. I've borrowed a logic probe but not a logic analyser
> yet! The eprom also gets momentarilly selected when reset is raised

Obviously the thing to check is that /SCSI should be asserted along with
/SLOW when the monitor is programming the AIC chip to turn the LEDs on. If
/SLOW isn't asserted then the WAIT pal is not at fault - it's doing what it
should be - and the fault is the code being executed by the 32532 - data
path or control problem to/from the EPROM-32532. 

> but that is about all that happens before it is stuck in the same
> "idlew" state as before!  The swap signal is also high.

Again, the only way this can happen is if  /SCSI is asserted and the
/SLOW is not. This is only for pseudo-dma accesses which are not present
in the monitor (at least not at the boot/signon phase). This means that
the cpu is executing incorrect code. Maybe the WAIT pal is broken - or
something that controls the EPROM-CPU data path access. Since this is a
rock hard reproduceable problem you should attack it from there.

> My current hypothesis is that the select pal is dodgy. I will attempt
> to run the test vectors on all the pals tomorrow (don't actually know
> if our programmer will do that). I can't think of many hypotheses which
> let "reset" work when the system is in any state except "idlew".

The SELECT pal shouldn't be able to cause the problem you are seeing, unless
it is selecting the AIC or 8490 device (via their chip selects) continuously
and therefore causing data bus contention etc. The monitor code will still
fire up if you pull the AIC, 8490 and SELECT pal out - maybe you should
also try that.

> I have three eproms. The original monitor that came with the system,
> the most recent binary that Bruce posted and also a locally compiled
> version. They all exhibit this behaviour, so I am disinclined to think
> it is a eprom problem.

Agreed, the EPROMs themselves are not at fault.

> I am for now assuming that the "can't talk to the duart" and "stuck so
> it won't reset" problems are symtoms of the same fault.

Definitely - whatever is causing the pseudo-dma access instead of a normal
programmed access to the AIC chip is at fault.

best regards,

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

From owner-pc532%daver@mips.com Mon Jun 11 10:02:20 1990
X-Path: news
From: cagney@chook.ua.oz (Andrew Cagney - aka Noid)
To: xm-pc532@daver.bungi.com
Subject: Re:  minix issues (Supply from PH)
Date: 11 Jun 90 06:16:33 GMT
References: <<7609@ncar.ucar.edu>>
Reply-To: pc532@bungi.com
Precedence: bulk

Sorry, more MINIX trivia.  If you are thinking of getting MINIX from PH
then the following background will be be very usefull

>From article <7609@ncar.ucar.edu>, by cruff@ncar.ucar.edu (Craig Ruff):
> Is this really necessary?  I'm considering getting the 1/2" tape version.

Hmm, a bit if MINIX distribution background is probably required before
you rush out and do this :-)

	ibm 1.1	Available on 1/2" tape and 5.25 inch disks. Both for the pc.
		Very out of date.

	ibm 1.2	Distributed on 5.25 disks with several variations

	ibm 1.3	Available as either a) Complete distribution b) Upgrade kit
		from 1.2. Rumored to no longer be available pending 1.5
		[Fortunatly, by not living in USA I can't confirm this]

	st 1.1	Best compared with ibm1.3 but the two have different sources
	
	1.5	Available for the IBM in either 3.5 or 5.25 format. Also
		for the Atari ST, Mac, Amega. Sources identical except
		1) in the kernel proper (for obivious reasons) and 2)
		where the word IBM was replaced by ST/Amega/...

		Rumored available Aug/Sept. I don't know if this version will
		be distributed on tape. Don't bother asking PH sales they
		don't even know if it exists.

If ordering, you should specify the ISBN number so that you can avoid any
confusion over which version you ordered :-). See below.

Also people with old versions will be able to `upgrade' at a cheeper rate
by sending PH their boot disk. This is almost the same as what Bruce is
suggesting. The only difference being PH keep the old disk :-(.


			sorry,  back to your regular viewing.
					Andrew Cagney.

Ordering details [Taken from the minix Information Sheet posted each month in
comp.os.minix]

  When ordering it, please specify one of the following versions:

     MINIX 1.3 for 640K IBM PC                   $79.95  (0-13-583444-9)
     MINIX 1.3 for 512K IBM PC/AT                $79.95  (0-13-583303-5)
     MINIX 1.1 sources on mag tape               $79.95
     MINIX 1.3 code + reference manual (PC)      $116    (0-13-584426-6)
     MINIX 1.3 code + reference manual (AT)      $116    (0-13-584418-5)
     MINIX-PC upgrade (1.2 to 1.3)               $29.95  (0-13-584723-0)
          (Sources *ONLY* -- you will need to already have
          a working PC-Minix system to use this)
     MINIX 1.1 for the Atari ST                  $79.95 (0-13-584392-8)

     Textbook: Operating Systems: Design and Implementation (0-13-637406-9)
     Reference Manual: MINIX for the IBM PC, XT, and AT (0-13-584400-2)

Finally, below are two articles AST posted on 1.5 from PH:

The tentative plan is as follows.  P-H will release 5 packages around
August 1, 1990 (if all goes well).  They will be:

  1. PC/XT/AT/386 version on 5.25 inch disks
  2. PC/XT/AT/386 version on 3.5 inch disks
  3. Atari ST
  4. Amiga
  5. Macintosh

They will all contain the same basic files, but will vary slightly in the
sense that there will be no TOSREAD for the Macintosh and no routine to read
the IBM clock on the Atari.  Other than that sort of stuff, they will be
pretty much alike.  Most files will be identical, in fact.  The 3 68000
versions will use the same binaries so you can compile a program on an
Amiga and execute it on an Atari, etc.  The 2 IBM versions will differ only
in the layout of the disks.  Both IBM packages will contain the PC boot
disk, the AT boot disk, and the BIOS boot disk, and both will require only
512K (but will use whatever is available).  This will eliminate a lot of
problems.  Tentative price is $140 for first time buyers, with a $40 discount
to people who are upgrading from a previous version (and prove it by sending
in their old P-H boot diskette).  P-H is definitely committed to bringing out
1.5 as a product, but the dates and prices are tentative.  Don't call them now
since the people who answer the phone know nothing about this and will
vigorously deny all of it.

Andy Tanenbaum (ast@cs.vu.nl)

Oops!   I forgot something important in my previous discussion of 1.5.
The $140 or $100 price will include > 700 pages of paper, including over
200 pages of manuals, very detailed installation instructions, and a listing
of the 1.5 kernel, MM, and FS in the same format as the book.  The manuals have
all appeared on the net at one time or other.  I've just cleaned them up a
little.

It will also come with a couple of shell scripts for installing the whole
thing on a hard disk.  The beta testers have been pretty enthusiastic
about the shell scripts.  (There is no point in my posting them since they
are very closely tied to the exact format of what is on which diskette.)

Thus the package is comparable to the current IBM slipcase version ($119),
not to the yellow box ($79.95).

They have to raise the price to cover the cost of the additional disks.

Andy Tanenbaum (ast@cs.vu.nl)

From budd Mon Jun 11 10:59:23 1990
Date:  Mon, 11 Jun 90 10:59:20 EDT
From: budd (Phil Budne)
To: Steven.D.Ligett@mac.dartmouth.edu
Subject: Re:  Final Prices, payment, etc.
Cc: budd

Here is what I'd like to get.  Please confirm that you can make up
this order, then I'll get a check to you.

item	quan	piece	exten
#8	1	6.15	6.15
#11	2	0.20	0.40
#15	2	0.35	0.70
#24	1	0.30	0.30
#29	2	1.00	2.00
#30	3	0.75	2.25
#31	4	0.75	3.00
#35	4	0.60	2.40

subttl			17.20

#48	4	73.75	295.00

ttl w/ mem		312.20

shipping		 10.00

grand ttl		322.20

From owner-pc532%daver@mips.com Mon Jun 11 13:31:51 1990
X-Path: news
From: cruff@ncar.ucar.edu (Craig Ruff)
To: xm-pc532@daver.bungi.com
Subject: Re:  minix issues (Supply from PH)
Date: 11 Jun 90 14:29:09 GMT
References: <<1026@sirius.ucs.adelaide.edu.au>>
Reply-To: pc532@bungi.com
Organization: Scientific Computing Division/NCAR, Boulder CO
Precedence: bulk

In article <1026@sirius.ucs.adelaide.edu.au> cagney@chook.ua.oz (Andrew Cagney - aka Noid) writes:
>	ibm 1.1	Available on 1/2" tape and 5.25 inch disks. Both for the pc.
>		Very out of date.

I downloaded this from uunet, where Prentice Hall has just placed some of
their book catalog online:

	MINIX 1.3 Sources on 9-Track Magnetic Tape
	@ 1988 (58438-3) 0-13-584384-7

Not so out of date, and even the right level for the current Minix-PC532.
Of course, I don't know yet if I'll have a working pc532 by the time
Minix 1.5 sees the light of day, so I may have the latest anyway.

By the way, the Prentice Hall stuff is available via anonymous FTP
on 'uunet:tmp/prenhall'.
-- 
Craig Ruff      	NCAR			cruff@ncar.ucar.edu
(303) 497-1211  	P.O. Box 3000
			Boulder, CO  80307

From owner-pc532%daver@mips.com Mon Jun 11 13:41:03 1990
X-Path: CRVAX.SRI.COM!FRANK
From: "Victor Frank"  <FRANK@CRVAX.SRI.COM>
To: pc532@BUNGI.COM
Subject: Re(2):  requested clarification of minix issues
Date: Mon, 11 JUN 90 10:00:02 PDT 
Reply-To: pc532@bungi.com
Precedence: bulk

     BRUCE:
     HOW MANY PEOPLE ARE INVOLVED, AND HOW BIG ARE THE FILES?

     I will probably regret this, but if the load is not too great, I would
offer my services in sending these out on disk in 360K, 720K, or 1.2M IBM 
(MSDOS) formats at cost.

Victor R. Frank
12450 Skyline Blvd.
Woodside, CA 94062-4541
Phone (415)851-7031  HOME
      (415)859-2495  WORK


From owner-pc532%daver@mips.com Tue Jun 12 11:28:52 1990
X-Path: wombat!george
From: george@wombat.bungi.COM (George Scolaro)
To: pc532@bungi.com
Subject: Re: pc532's r3 and r7
Date: 12 Jun 90 08:05:31 PDT (Tue)
Reply-To: pc532@bungi.com
Precedence: bulk

[In the message entitled "pc532's r3 and r7" on Jun 11, 20:29, Jon Buller writes:]
> 
> Can someone tell me what the value of r3 and r7 should be?  They are
> claimed to be clock termination resistors in the docs, but no value is
								????
> given for them.  If there is no "use this value and be quiet" answer,
> is there a way to easily figure it out?  Steve's kit has them as 220 and 330
> ohms, but I don't know which is which.  (The process of elimination can
> only take one so far...)

Actually, there are 4 resistors for termination, 2 x 220 and 2 x 330, one
220 and one 330 for each clock line (BCLK, /BCLK). The PCB only has the
holes for the 330 resistors. The 220 resistors have to be soldered to the
back of the board.  The doc explains how to do it in the CPU SECTION first
paragraph:

	for each clock line {
		330 ohm resistor from clock to ground (holes provided)
		220 ohm resistor from clock to +5V (holes not provided)
	}

This terminates the clock traces at close to the PCB impedance and reduces
reflections from the end of the trace.

best regards,

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

From owner-pc532%daver@mips.com Tue Jun 12 11:40:36 1990
X-Path: lars.Seri.GOV!sverre
From: sverre@lars.Seri.GOV (Sverre Froyen)
To: pc532@daver.bungi.com
Subject: Disk problems
Date: Tue, 12 Jun 90 9:28:58 MDT
Reply-To: pc532@bungi.com
Precedence: bulk

I just bought a new disk (Micropolis 1578) to replace a dead one,
however, I have problems bringing it up on my ICM3216.

The drive formats without any errors and I can read and write
to it.  I (re)partition the drive as follows:

Partition table for SCSI device 1:0

partition   first block   last block   number of blocks
    0               2        16385       16384 (  8 Mb)
    1           16386        94209       77824 ( 38 Mb)
    2           94210       276157      181948 ( 88 Mb)
    3          276158       458105      181948 ( 88 Mb)
    4          656438       656501          64 (  0 Mb)
    5          640054       656437       16384 (  8 Mb)
    6               0            1           2 (  0 Mb)
    7          458106       640053      181948 ( 88 Mb)

I can copy the loader and root file system to partitions 4 and 0 and
boot unix (Rev H).  I then proceed to make the other file systems using

	mkfs /dev/dsk/0sx 90974 1 540

for partitions 2, 3, and 7 and 

	mkfs /dev/dsk/0s1 38912 1 540

for partition 1.

After having done this I can observe a number of different
problems:

1) Making the filesystems in the sequence 1, 2, 3, 7,
causes labelit to report that 0s1 has 181948 blocks.

2) Reversing the sequence made the root file system vanish
on one try and made all the blocks in the /usr (0s1) file
system disappear while cpio-ing the usr files in a second.

3) I have also seen the /usr file system being clobbered
after mkfs-ing another file system (possibly 0s7).

I have tried reformatting the drive (no errors again) and rearranging
the partitions with 2 and 3 larger and 7 as the (default) entire drive.

The errors appear to be associated with writing on the last part
of the drive (partition 7).  I have brought it up skipping partition
7 and it appears! to work.

This may, of course, be a bad disk drive or bad cabling, however,
this drive is larger than anything I have tried on the ICM before,
and I suspect there may be driver problems (e.g., if you use more
than ~32000 2^15-1? inodes, df will report "not a file system").
Has anyone observed anything like this?

Since the drive is destined for the pc532 an ICM software problem
is not all that critical, however, if the drive itself is bad
I need to find out now.

BTW, the drive works with the asyncronous SCSI port on the pc532
and gives read and write transfer rates of 700 kB/s and 440 kB/s
respectively (on 3MB transfers).

Sverre

-- 
Sverre Froyen
sverre@seri.gov, sunpeaks!seri!sverre

From owner-pc532%daver@mips.com Tue Jun 12 20:59:14 1990
X-Path: sibyl.eleceng.ua.oz.au!ian
From: ian@sibyl.eleceng.ua.oz.au
To: pc532@bungi.com
Subject: Re: Hardware Problems
Date: Wed, 13 Jun 1990 03:16:23 +1000
References: <<9006101101.AA05461@wombat.bungi.COM>>
Reply-To: pc532@bungi.com
Precedence: bulk

George Scolaro writes:
 > [In the message entitled "Re: Hardware Problems" on Jun 11,  1:20, ian@sibyl.eleceng.ua.oz.au writes:]
 > > 
 > > Things have deteriorated! I can no longer talk to the serial port at
 > > all and the "stuck" state is now quite reproducable. What happens is
 > 
 > As John Connin mentioned, have you ensured that the 32532 is fully seated
 > in it's socket.

I think so.
 > There are 4 pins (near each corner of the chip) which have
 > small rings that should seat all the way flush with the socket.

I can't see any rings on *my* 32532. However, I used the method you
suggested and applied a *lot* of force -- my full weight which is
95kg. I am unwilling to use any more force than that!

To quantify, there is a .6 - .7 mm gap between the ceramic of the pc532 and
the top of the socket (I measured with feeler gauges)! This is the same or
slightly less than the gap for the 32381.

 > (if you ever have to extract the 32532
 > you will discover the wonders of splintering ceramic - unless you have a
 > PGA chip extractor!).

I shudder to think. The thought crossed my mind as I pushed it in that
I hope I never have to extract it! It does beg the question, what use
is a socket that you can only plug in once to?

I attempted to verify the PALS. Well it turns out that I can verify
PALs but not GALs (which most of them in fact are). So I blew a new
decoder PAL and plugged it in. Lo and behold it worked! Being the
suspicious sort, I plugged the original back in and it still worked!
Strange.

While it was working I deliberatly got it into the "idlew" state by
accessing location 3800 0000 with the rom monitors dump and set
commands. Sure enough it ground to a halt. It then takes *two* resets
to get the prompt back. Can you please check this? It was quite
repeatable.

Clearly I hadn't actually fixed anything but maybe there was an
intermittent dry joint near the socket, so I pulled the board out, and
resoldered that socket. Now it doesn't work again in exactly the same
way as before and with either PAL.

Poking around the decoder PAL reveals a strange anomaly. /ioinh is
permanantly high and yet I get pulses out of /icu. This, according to
the PAL equations, is impossible! The only explanation I can think of
is that there *are* pulses on /ioinh which are two short for the logic
probe and which get stretched going through the PAL. This still
doesn't seem very likely, the probe detects pulses on bclk and /bclk
perfectly well. I also thought that maybe there was a bad connection
to the 532 on that pin. However, removing the DEC32 PAL shows that the
/ioinh pin is still high. The only explanation for that is that the
532 is driving it that way!

When should the 32532 assert /ioinh? My reading of the manual implies that
it should get asserted for every bus read. Is there anything which can
prevent /ioinh being asserted? Note that the CPU is active with address
lines waggling up and down and /conf waggling up and down.

As Alice said "curiouser and curiouser".

Ian Dall.


From owner-pc532%daver@mips.com Tue Jun 12 21:01:10 1990
X-Path: vw26.chips.com!vw25.chips.com!gs
From: gs@vw25.chips.com (George Scolaro)
To: pc532@bungi.com
Subject: Re: Hardware Problems
Date: Tue, 12 Jun 90 17:21:32 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

[In the message entitled "Re: Hardware Problems" on Jun 13,  3:16, ian@sibyl.eleceng.ua.oz.au writes:]
> 
> I can't see any rings on *my* 32532. However, I used the method you
> suggested and applied a *lot* of force -- my full weight which is
> 95kg. I am unwilling to use any more force than that!

Sounds like it is definitely seated properly - since you can't see the rings.

> I shudder to think. The thought crossed my mind as I pushed it in that
> I hope I never have to extract it! It does beg the question, what use
> is a socket that you can only plug in once to?

With the correct chip extractor (which looks like a medieval thumb screw)
it is quite an easy task. The reason the socket is so tight is that I
neglected to get very low insertion force pins! Oh well.

> decoder PAL and plugged it in. Lo and behold it worked! Being the
> suspicious sort, I plugged the original back in and it still worked!

Hmm, an intermittent of some sort - that's for sure. Maybe you should
check (if you haven't done so) that no chip legs are bent under in their
sockets. Also 'wiggle' the board while resetting to see if it comes to
life. Also, check the resistor packs (the SIPs primarily), I have seen
them with hairline cracks that cause all sorts of nasty intermittent
problems.

> commands. Sure enough it ground to a halt. It then takes *two* resets
> to get the prompt back. Can you please check this? It was quite
> repeatable.

I have seen this sort of thing. Even though the pal should come out
of the IDLEW state, I think that the 532 gets 'confused' on the first
new access. Anyhow - I'm not sure why it takes 2 resets, but that is
normal behaviour when it crashes in this way.

> resoldered that socket. Now it doesn't work again in exactly the same
> way as before and with either PAL.

The fault must be at some other place - that causes the IDLEW state lockup.

> Poking around the decoder PAL reveals a strange anomaly. /ioinh is
> permanantly high and yet I get pulses out of /icu. This, according to
> the PAL equations, is impossible! The only explanation I can think of

No, the I/O access is inhibited if /IOINH is low. i.e. it should be high
for a valid I/O access to proceed.

> /ioinh pin is still high. The only explanation for that is that the
> 532 is driving it that way!

Yes it is - i.e. it is correct for /IOINH to be normally high.

> When should the 32532 assert /ioinh? My reading of the manual implies that
> it should get asserted for every bus read. Is there anything which can

No. /IOINH means I/O inhibit. The only time the 32532 does this is if there
is a pending write (i.e. in it's on-chip write fifo) and you are trying to
do a read access. /IOINH is asserted to tell the hardware that if the
current access is to an I/O device then it should be ignored. At the same
time the hardware should generate /IODEC (set it low) to inform the 32532
that the current access really was to an I/O device. The 32532 will then
flush out the write fifo and re-execute the aborted read access (this time
not asserting /IOINH).

These events are essential to ensure that a write to a I/O control port
followed by a read from the I/O device (e.g. while setting up a UART)
executes in the correct order. I'm pretty sure that NS has a patent on this
protocol. The 486 etc can get away with not having this stuff since it has
dedicated I/O instructions - the 32532 has no special purpose instructions
for handling I/O so it needs this extra hardware - of course you get
a more powerful instruction set to do I/O with.

> As Alice said "curiouser and curiouser".

But at least everything still makes sense....

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 Jun 12 22:13:45 1990
X-Path: mips.com!musashi.wpd.sgi.com!des
From: des@musashi.wpd.sgi.com (Des Young)
To: pc532@bungi.com
Subject: Re: Hardware Problems
Date: Tue, 12 Jun 90 18:03:51 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

Hmm,
  this is beginning to look like shorted pins/wires. May pay to check
adjacent wires are not shorted, say adjacent pins on the PAL. A
solder bridge between two traces can do it. Give the PCB a good scrub
with a stiff brush on the back.
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 Wed Jun 13 04:47:37 1990
X-Path: dlr
From: dlr@daver.bungi.com (Dave Rand)
To: pc532@bungi.com
Subject: lower cost options
Date: Tue, 12 Jun 1990 23:30:19 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

A lot of people have becoming interested in the PC532 project over the
last few months. Some people have indicated that they wish to get 
involved with the 32000 family, but can't afford the PC532.

An offer has been made to me for some older technology board products,
using the 32032 and 32332. These boards are well designed and well
manufactured. George and I have used the 32032 boards quite a bit, and
George has used the 332 board (I didn't have much of a chance to use the
332 board). A range of boards are available, from fully populated
and working to bare boards. Kits of parts are also available.

These boards are intended to plug into IBM-PC/AT type systems, but could
be modified (with some work) to be stand-alone to any type of system with
a parallel I/O port (bidirectional, not Centronics :-). UNIX is running
on the boards, and could be made available (with some work on my part).
They would serve as a good base for MINIX work, as well.

The 32032 board can accept up to 4 megabytes of RAM; the 32332 board
up to 16 megabytes.

These boards will required more hardware knowledge, as less documentation
is available for them (compared to the pc532).

If you are interested in further information on these boards, please drop
me some mail. If there is a sufficient number of people interested, I will
negotiate a price for you.

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

From owner-pc532%daver@mips.com Wed Jun 13 05:42:51 1990
X-Path: sibyl.eleceng.ua.oz.au!ian
From: ian@sibyl.eleceng.ua.oz.au
To: pc532@bungi.com
Subject: Re: Hardware Problems
Date: Wed, 13 Jun 1990 14:26:35 +1000
References: <<m0hfLUD-0000o8C@vw25.chips.com>>
Reply-To: pc532@bungi.com
Precedence: bulk

George Scolaro writes:
 > > Poking around the decoder PAL reveals a strange anomaly. /ioinh is
 > > permanantly high and yet I get pulses out of /icu. This, according to
 > > the PAL equations, is impossible! The only explanation I can think of
 > 
 > No, the I/O access is inhibited if /IOINH is low. i.e. it should be high
 > for a valid I/O access to proceed.

Sorry. I often get confused with negative logic.

The problem is no doubt just a bad connection somewhere, but where is
a bit tricky. I am running out of things I can test with a logic
probe. If I haven't fixed by this weekend I'll take it into Uni and
use a logic analyser on it.  I have been a bit reluctant to do that
because of the difficulty of attaching probes to either the PGA chips
or the PLCC chips. Still, the ROM, the PALS and the buffers should
provide access to most interesting signals.

Ian Dall


From dlr%daver@mips.com Wed Jun 13 13:18:03 1990
From: dlr@daver.bungi.com (Dave Rand)
Date: Wed, 13 Jun 1990 10:04:07 PDT
X-Mailer: Mail User's Shell (7.1.1 5/02/90)
To: budd@bu-it (Phil Budne)
Subject: Re: Drivers for Adaptec SCSI

[In the message entitled "Drivers for Adaptec SCSI" on Jun 13, 12:19, Phil Budne writes:]
> Do you have (simple) drivers for the Adaptec SCSI on the PC532?
> Since I've seen disk thruput numbers posted I'm wagering you do!
> 

I do, but they don't work very well yet, and I have not had sufficient time
to get them into better shape. I'll mail you what I have over the weekend.



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

From owner-pc532%daver@mips.com Wed Jun 13 12:49:54 1990
X-Path: mips!bu-it.BU.EDU!budd
From: budd@bu-it (Phil Budne)
To: pc532@daver
Subject: Boot/Diag switch?!
Date:  Wed, 13 Jun 90 12:23:17 EDT
Reply-To: pc532@bungi.com
Precedence: bulk

One shorcomming of the PC532 I've come to realize is that is has no
autoboot/diag switch!!  I'm tempted to wire one up from a spare ICU
line to a header pair (soldered into one of the spare IC spots) and
get a case with a "turbo" switch!

-Phil


From owner-pc532%daver@mips.com Wed Jun 13 13:40:07 1990
X-Path: CRVAX.SRI.COM!FRANK
From: "Victor Frank"  <FRANK@CRVAX.SRI.COM>
To: pc532@BUNGI.COM
Subject: Re: lower cost options
Date: Wed, 13 JUN 90 09:36:37 PDT 
Reply-To: pc532@bungi.com
Precedence: bulk

     I am interested in finding out what is available and for what price;
although having come this far with the pc532 it is unlikely I would buy
another board.  Who knows?

     By the way, future meetings of our club (after July 5) are: August 1,
September 5, October 3, should you be interested in 1) talking about the
project, 2) possibly forming a local pc532 group.  We talked with George
about this last night on the phone.

Regards,

Victor R. Frank


From owner-pc532%daver@mips.com Wed Jun 13 18:53:34 1990
X-Path: uunet!tarpit!manatee!John.L.Connin
From: John Connin <johnc%manatee%uunet@daver>
To: pc532@bungi.com
Subject: Re: Hardware Problems
Date: Wed, 13 Jun 90 7:59:52 EDT
References: <<9006121804.29038@munnari.oz.au>>
Reply-To: pc532@bungi.com
Precedence: bulk


Suggestions:  

1)  If you have not done so, decrease the processor clock frequency 
    (ie XTALM - U25) from 50 Mhz to say 20 Mhz.

2)  Using a magnifier carefully examine each component and all solder
    joints.

3)  Push, pull, shove each component while running.

johnc
-- 

From owner-pc532%daver@mips.com Wed Jun 13 18:56:18 1990
X-Path: uunet!tarpit!manatee!John.L.Connin
From: John Connin <johnc%manatee%uunet@daver>
To: pc532@daver.bungi.com
Subject: Minix 1.5 Amoeba driver posted..
Date: Wed, 13 Jun 90 9:23:46 EDT
Reply-To: pc532@bungi.com
Precedence: bulk


If you do not track comp.os.minix, you might want to take a peek.
The full source for the Amoeba driver for Minix 1.5 was just
posted by AST.

The attached narriative was extracted from part 1 of the posting.

johnc

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

From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Amoeba 1 of 4
Message-ID: <6922@star.cs.vu.nl>
Date: 12 Jun 90 14:26:42 GMT
Sender: news@cs.vu.nl
Organization: Fac. Wiskunde & Informatica, VU, Amsterdam
Lines: 1263

Here is the long awaited Amoeba driver for MINIX 1.5.  First a bit of
introduction.    Read the whole thing to see the relevance to MINIX.
     
Amoeba is a new operating system.  It is a complete 
operating system that runs on the bare hardware, just as UNIX, MINIX, MS-DOS,
OS/2, and VMS do.  It contains process management, memory management,
a file system, and comes with over 100 utilities, just as all the above do.
You can think of it as an alternative to MINIX.

However, Amoeba is targeted at the other end of the spectrum.  Whereas
MINIX is for single user, low-end, home and educational users with one
smallish machine, Amoeba is a full-fledged distributed system aimed at
high performance applications.  At the Vrije Universiteit, we are running
it on a system with some 30-odd 68020s and 68030s.  Its goal is to make
the whole collection of hardware look and act like a single system.  Users
are not aware of where jobs run, where files are stored, etc.  It is just
one big system.  This is in contrast to say, Sun UNIX, in which users are
very much aware of the machine boundaries.

In addition to being distributed, Amoeba has been designed to be very fast.
Our major customer at the moment is the European Space Agency, which is
using it as the operating system for a digital system for transmitting
real time video over a fast LAN.  Right now they have 1 camera on the
spacecraft, but eventually they want to have 50, and be able to dynamically
switch channels etc digitally.  As you can well imagine, high performance
is a major issue here.  That is why Amoeba was chosen over UNIX, Chorus,
Mach etc.

If you want to learn more about Amoeba, see the May 1990 issue of IEEE
Computer Magazine.  If you want still more information, there is a 300
page book about Amoeba available via anonymous FTP on midgard.ucsc.edu
in the directory ftp/pub/amoeba in both source and compress postscript
form.  Amoeba will be available to universities for a modest licensing
fee (probably $500 to $1000), including all the source code, in the second
half of 1990.  It runs on Sun-3s, VAXes, and 386s.  If we can find someone
to finance it, we will port it to RISC machines as well.

This said, what does Amoeba have to do with MINIX?  In theory, nothing.
However, since I am the chief architect of both systems, when looking
around for a network protocol to put in MINIX, I was naturally attracted
to the Amoeba protocol, due to its great speed.  Thus we have written a
driver for MINIX (and also one for UNIX) that implements the Amoeba
protocol for MINIX systems.  In this way, two Amoeba systems can
communicate over an Ethernet using the WD board.  Software is also
provided for remote login, file transfer, and other goodies.    When using
the Amoeba protocols, Sun-3s, MINIX systems etc can talk to each other
over the Ethernet.  The Amoeba driver I am about to supply is for the
IBM version of MINIX only.

Rather than post cdiffs against 1.3, I have decided to post the whole
thing.  Please note that you can run Amoeba on a SINGLE MACHINE.  You
do not need an Ethernet or two machines.  All you have to do for the
single machine version is put the -DNONET flag in all the Makefiles.
This allows you to experiment with networking, RPC, etc. without a network,
but the code you develop will run unmodified on a real Ethernet.
Below you will find two items: The crcs for the amoeba directory, and
the manual.  Please install amoeba at the top level, i.e., in the same
directory as kernel, mm, fs, and tools.  This is essential, as it accesses
the kernel directory via ../stuff.

The posting consists of 4 parts.  This one (part 0), parts 1 and 2 (the
kernel directory) and part 3 (the fs, mm, examples, and util directory,
and the top level Makefile, all shar'ed together for posting purposes).

[stuff deleted]

-- 

From owner-pc532%daver@mips.com Thu Jun 14 00:09:23 1990
X-Path: wombat!george
From: george@wombat.bungi.COM (George Scolaro)
To: pc532@bungi.com
Subject: Re: Boot/Diag switch?!
Date: 13 Jun 90 20:49:04 PDT (Wed)
Reply-To: pc532@bungi.com
Precedence: bulk

[In the message entitled "Boot/Diag switch?!" on Jun 13, 12:23, Phil Budne writes:]
> 
> One shorcomming of the PC532 I've come to realize is that is has no
> autoboot/diag switch!!  I'm tempted to wire one up from a spare ICU
> line to a header pair (soldered into one of the spare IC spots) and
> get a case with a "turbo" switch!

Our ICM3216s have a neat way to do this without extra hardware. When you
reset them they give you so many seconds of grace - if you hit a key
on the terminal during this time they will exit to the rom diagnostics, else
they will continue with the boot.

best regards,

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

From owner-pc532%daver@mips.com Thu Jun 14 13:46:43 1990
X-Path: sibyl.eleceng.ua.oz.au!ian
From: ian@sibyl.eleceng.ua.oz.au
To: pc532@bungi.com
Subject: Re: Hardware Problems
Date: Thu, 14 Jun 1990 21:41:07 +1000
References: <<9006121804.29038@munnari.oz.au>>
Reply-To: pc532@bungi.com
Precedence: bulk


I *think* it is fixed now. I found a dry joint on U22. The +5 I think
it was.  Don't ask me how that caused the problem!

The power supply and ground pins need quite a lot more heat than the
signal pins due to the large amount of copper attached to them. I
noticed this when I was soldering but I guess I didn't quite give this
one enough.

I hope that was all that is wrong (keeps fingers crossed)!

Thanks for the help,

Ian Dall


From Steven.D.Ligett@mac.dartmouth.edu Fri Jun 15 14:04:00 1990
Date: 15 Jun 90 14:03:49
From: Steven.D.Ligett@mac.dartmouth.edu
To: budd@bu-it (Phil Budne)
Subject: Re:  Final Prices, payment, etc.

I have most of the parts you need now.  It's likely that the rest will be here
later today via UPS.  I didn't check your addition, but assuming it's right,
sure, send the check, and you'll have the parts next week!

From owner-pc532%daver@mips.com Fri Jun 15 18:46:14 1990
X-Path: dlr
From: dlr@daver.bungi.com (Dave Rand)
To: pc532@bungi.com
Subject: next run...
Date: Fri, 15 Jun 1990 14:21:03 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

Well, people are asking again, so I suppose it is time to talk about another
run of boards. I'll collect names for those that are interested for 4 weeks,
and then put in the board order. This should get everyone that is interested...

If you are interested, please mail your request to:

pc-order@daver.bungi.com -or- {sun|mips|pyramid|vsi1|uunet}!daver!pc-order

*PLEASE*! Include your Name, *ADDRESS*, telephone number, and
quantity desired. Also, please include your address. And, if it
is not too much trouble, your address. That is, please include the
address you would like the board shipped to.

(too many people didn't include their address on the first go-around)

The expected cost will be $200, although this will depend on the number
of boards that we order.

For those that don't know...

Subject: PC532 system
Message-ID: <1989Nov16.051350.4711@daver.UU.NET>
Date: Thu, 16 Nov 89 05:13:50 GMT


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

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

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

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

The main board is a "baby-AT" style board, and will fit into standard
IBM AT cases. We did a small run of PC boards, and have two of them up
and running now. [we now have over 100 boards out all over the world - dlr]

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

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

Other folks are doing more (and more significant) software, like Bruce
Culbertson with Minix. If you would like more information, please drop me
mail.


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

From owner-pc532%daver@mips.com Fri Jun 15 18:46:39 1990
X-Path: mac.dartmouth.edu!Steven.D.Ligett
From: Steven.D.Ligett@mac.dartmouth.edu
To: pc532@bungi.com
Subject: Re: Hardware Problems
Date: 15 Jun 90 13:17:48
Reply-To: pc532@bungi.com
Precedence: bulk

--- Ian Dall wrote:
The power supply and ground pins need quite a lot more heat than the
signal pins due to the large amount of copper attached to them. I
noticed this when I was soldering but I guess I didn't quite give this
one enough.
--- end of quoted material ---
Congratulations!  I hope you've got it!

At Dartmouth, we build a lot of our own hardware for our communications
network.  The shop technicians build the boards at home for overtime. 
Usually, I just give them a bag of parts, a blank board, and a board to copy. 
My only instructions are "More heat; less solder."  You don't want joints with
blobs of solder, you want joints where the solder has wicked up into the hole.

If you're soldering sockets, it impossible to see how the joint looks on the
top.  If you're soldering chips straight into the board, you can look for a
hole filled with solder, and a fillet on the top and bottom side.  Frankly,
you probably can't do it consistently on the power and ground pins.  Or maybe,
frankly, *I* can't do it on a board with power and ground planes.

If a joint looks bad, don't just blob more solder on it, remove the old
solder, and try again.

From owner-pc532%daver@mips.com Fri Jun 15 20:13:42 1990
X-Path: vw26.chips.com!vw25.chips.com!gs
From: gs@vw25.chips.com (George Scolaro)
To: pc532@bungi.com
Subject: Re: Hardware Problems
Date: Fri, 15 Jun 90 16:31:37 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

[In the message entitled "Re: Hardware Problems" on Jun 15, 13:17, Steven.D.Ligett@mac.dartmouth.edu writes:]
> --- Ian Dall wrote:
> The power supply and ground pins need quite a lot more heat than the
> signal pins due to the large amount of copper attached to them. I
> noticed this when I was soldering but I guess I didn't quite give this
> one enough.
> --- end of quoted material ---
> Congratulations!  I hope you've got it!
> 
> At Dartmouth, we build a lot of our own hardware for our communications
> network.  The shop technicians build the boards at home for overtime. 
> Usually, I just give them a bag of parts, a blank board, and a board to copy. 
> My only instructions are "More heat; less solder."  You don't want joints with
> blobs of solder, you want joints where the solder has wicked up into the hole.

Very true. Most of the ground and power pins on the PC532 use thermal
reliefs. That means that the pin is not 100% connected to the copper plane
but instead has small pie sections (4 of them) in each quadrant that don't
contain copper. The thermal relief is intended to enable a good solder
joint to be made on a wave solderer - where consistent joints are essential
on all pins at a given solder temperature.

For manual soldering, I generally like to have the tip well tinned and then
bring it down on the pin/pad that I am about to solder. I leave it there for
1/2 or so before adding the solder. This ensures that the pin and pad/hole
are heated and the solder wicks nicely down the hole.

A 'nice' solder joint will always be shiny. Even though it takes a bit of
work it is a good idea to clean the flux off the board after soldering with
one of the commerial flux removers. Then it is much easier to inspect your
handywork. The flux (resin) in electronics grade solder will not cause
corrosion of the traces and pads - the reason to remove it is to make the
board like 'nice' and to be able to inspect the joints.

Ditto on the congats.

best regards,

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

From owner-pc532%daver@mips.com Sun Jun 17 03:42:40 1990
X-Path: news
From: dvinci!neil (Neil Johnson,132L,6078,3825591)
To: xm-pc532@daver.bungi.com
Subject: Re: Hardware Problems
Date: 16 Jun 90 01:03:40 GMT
References: <<9006121804.29038@munnari.oz.au>>
Reply-To: pc532@bungi.com
Organization: University of Saskatchewan
Precedence: bulk

You could also try cold spray. A can costs about $10, and lasts for
a couple of minutes. Spray suspicious chips/resistor packs/capacitors,
etc for a few seconds. You want to cool the component, but do not want
a lot of frost. The temperature change may cause a marginal part to start
working or stop working. If a component consistantly changes the operation
of your system when sprayed try replacing it. This can also be used 
to detect cracked traces.

By the way, add one more board to the list of running systems. I had
one screw-up during construction - I got the 68 pin PGA socket and
LCC socket soldered in each other's place. I wrecked the PGA socket
unsoldering it, but reused the leadless one. Luckily, the board worked 
the first time I applied power.

Neil Johnson
neil@skatter.USask.Ca

From owner-pc532%daver@mips.com Sun Jun 17 14:20:41 1990
X-Path: news
From: starfire!john (John Lind)
To: xm-pc532@daver.bungi.com
Subject: Re: Document Scanner (ds532) Proposal..
Summary: I WANT ONE!  Forget SCSI -- gimme parallel data
Date: 13 Jun 90 20:49:23 GMT
References: <<9006050845.AA01208@manatee.UUCP>>
Reply-To: pc532@bungi.com
Organization: Starfire Consultings Services, Mpls., MN
Precedence: bulk

Note!  To avoid the line-counter, I am quoting with # instead of >.

In article <9006050845.AA01208@manatee.UUCP>,  writes:
# Document Scanner Idea/Proposal (ds532)
# ---------------------------------------
...
# Let me emphasize again, this is a very high-end scanner which is 
# a self contained module and wrapped in attractive casework.  The resolution
# is 400 dpi and the throughput is 18 pages per minute for 8.5 x 11 
# inch pages.
...
# Almost forgot, the CODEC board frame memory (64 - 256K x 1 DRAM) 
# was removed during the period of high memory prices. Otherwise,
# the boards are complete.
# 
# Cost of Scanner module and CODEC board:
# --------------------------------------
# Would you believe:
# 	Qty		Approximate Cost (excluding shipping)
# 	---		------------------------------------
# 	1		$200
# 	50 		$125
# 
# Of course this does not include the cost of the glue board which we
# must design and a power power supply.
...
# What do you all think ??  
# Any hardware types want to volunteer ??
# Is there sufficient interest to move forward ??

At that price, I don't CARE about a glue board -- give me parallel
input data, no problem.  I'd LOVE to have a scanner like that, and
see no particular reason that it should have to have a SCSI interface.
Of course, you fellows with PC532s are a little short of bi-directional
or input parallel ports -- too bad (small smirk).

Let me make this clear: I WANT ONE, and I intend to interface it to
my archaic Multibus I ns32016 system using one of my $7.50 i517
parallel IO boards.  That amount of hardware bashing I can handle.
If anyone wants help with the glue to do that amount of interfacing,
I can help.  But, whether or not a SCSI interface is designed, I have
no use for it, but I want one of these scanners at $200 if I have to,
or for $125 if I can.  Then, it's off to the library to learn about
document scanning software...

Well, I hope I have provided enough "original" text to make the line
counter happy, or I'm gonna be mad when it throws this away...

Oops!  Didn't make it -- let's try using a different "quote"
character...
-- 
		   John Lind, Starfire Consulting Services
E-mail: john@starfire.MN.ORG		USnail: PO Box 13001, Mpls MN  55414

From owner-pc532%daver@mips.com Mon Jun 18 13:33:59 1990
X-Path: pyramid!unify!goshawk.mason
From: unifx!goshawk.mason (Mark Mason)
To: pc532%daver%pyramid@unify
Subject: Gatewayed mail message
Date: Mon, 18 Jun 80 08:25:30 PDT
Reply-To: pc532@bungi.com
Precedence: bulk



This is probably premature, BUT...

Consider this to be on the level of a strong rumor.

I just taljed to a friend of mine who had fone to Usenhx last week.
Evidently, the Berkley project to remove AT&T code from 4.[34]bsd unix
is almost complete. They are down to (quote) "one and a half typed
liner" of prograls that still need to be freed (I think sed hs one of
them...).  The kernel hs (almort?) finished. When this is all done,
you will still need a Berkley source license to have a set of sources
($400-$500), but you will NOT need a AT&T source license.

I thought this might be of some interest to the group. ;-(

Mark Mason
pyramid!unify!mason


From owner-pc532%daver@mips.com Mon Jun 18 14:22:50 1990
X-Path: lll-winken.llnl.gov!quintro!bpdsun1!rmf
From: rmf%bpdsun1%quintro@lll-winken.llnl.gov (Rob Finley)
To: pc532@bungi.com
Subject: Re: Hardware Problems
Date: Sun, 17 Jun 90 15:22:41 CDT
Reply-To: pc532@bungi.com
Precedence: bulk

Ah, your pcb package does use thermal reliefs!  Great!  I was wondering.
Scicards won't let us use thermal reliefs for anything but a full ground
plane.  We do area-fill on all layers where it starts with a hole that
is connected to ground (or any node) and draws boxes outwards until it
runs into something else.

In that case, Ignore my previous thermal suggestion.  I was in the midst
of redoing a board (had to take out the area fills.  Darn.) because the
lack of thermal relief caused heartburn in the Manufacturing dept.

P.S.  Still working on FDC board.  I screwed up the 62 pin connector
and have to blow a generation but things are progressing.

Take care.  Robert

From owner-pc532%daver@mips.com Mon Jun 18 17:55:26 1990
X-Path: acsu.buffalo.edu!owens
From: owens@acsu.buffalo.edu (bill owens)
To: pc532@daver.bungi.com
Subject: More info on BSD availability
Date: Mon, 18 Jun 90 16:54:28 EDT
Reply-To: pc532@bungi.com
Precedence: bulk

After the recent article about 'rumours' at Usenix, I talked to someone
here at the University of Buffalo CS lab, and he filled me in on the
status of their port of BSD4.4 to the Data General AViiON workstation
series (88100 based). With his permission,

From: bowen@cs.Buffalo.EDU (Devon E Bowen)
Subject: Re:  Would you care to comment on the DG port?

> Evidently, the Berkley project to remove AT&T code from 4.[34]bsd unix
> is almost complete.

Depends on what you mean by almost. About 80% of user level programs are
cut over. There's a list of things that still need to be done. It is a much
smaller list than at the last USENIX, though. This sounds like almost, but
it only includes user level stuff.

> (I think sed hs one of them...).

Yes, that's being done here (kensmith@cs.buffalo.edu).

> The kernel hs (almort?) finished.

Since the kernel code is system dependent, this is a system dependent
statement. They are still a long way from having the kernel done in some
ports and very close in others. If you want to say something generic like
"the kernel" then I'd say on average they are still quite far.

> When this is all done,
> you will still need a Berkley source license to have a set of sources
> ($400-$500), but you will NOT need a AT&T source license.

There will be a charge for distribution (about $100), but no license from
Berkeley. The whole point of the rewrite is to make it freely distributable
not to give Berkeley control in place of AT&T. The copyright will basically
only restrict it to the point where all you have to do is give Berkeley
credit for the work. It will be very much like their current copyright on
the TCP suite that is now available for ftping.

Devon


I'm not involved with the port (unfortunately!) but Devon can probably
answer your questions about specifics (as long as you don't flood him
with them :) He also posts to comp.sys.m88k now and then. 

Bill.

Bill Owens                                              owens@acsu.buffalo.edu
108 Computing Center                              uunet!acsu.buffalo.edu!owens
Buffalo, NY 12460                                                 716/636-3511

From Steven.D.Ligett@mac.dartmouth.edu Wed Jun 20 21:40:08 1990
Date: 20 Jun 90 21:39:20
From: Steven.D.Ligett@mac.dartmouth.edu
To: budd@bu-it (Phil Budne)
Subject: Re:  Final Prices, payment, etc.

I just ran out of simms - shall I wait till Monday to send your order, with
simms, or send it this week?

From Steven.D.Ligett@mac.dartmouth.edu Wed Jun 20 22:15:35 1990
Date: 20 Jun 90 22:12:17
From: Steven.D.Ligett@mac.dartmouth.edu
To: bobm@convex.com, cruff@ncar.ucar.edu, don@BRL.MIL,
        sware!hosking@uunet.UU.NET, phil@unicorn.wwu.edu,
        manatee!johnc@uunet.UU.NET, jonb@vector.dallas.tx.us, budd@bu-it,
        jfd@pbhyf.PacBell.COM, Steven.D.Ligett@mac.dartmouth.edu
Subject: parts shipments

Hi, the following people will receive PC532 parts on Friday:

Bob Finch
Phil Nelson
Robert Hayes
Craig Ruff
John Connin
Don Merritt
Doug Hosking
Bob Miller

The following will receive parts next week:

Jon Buller
Phil Budne
Jeff Defay

I have run out of SIMMs; they were supposed to be factory stock.  Perhaps they
meant in Japan.  I'm reordering SIMMs; they'll be in next week.  Some other
parts have never arrived; I'm following up on them and will have them all
reordered tomorrow.  There are a couple of caps missing, two resistor sips,
two ttl parts, the dp8490s, and some sockets.  I was told today that some AMP
employees are working without pay now; this was given as an excuse for having
trouble in getting AMP parts.  Dave has paid for the dp8490s, and the icu's,
too, but it looks like he'll be out of the country before they arrive.

I'm sorry for all these delays; I've held up sending out most of the packages
waiting for promised parts.  I was trying to keep my list of vendors to three;
tomorrow I'll be calling a fourth for parts.

Please write me if you have any questions or problems with the parts.  Thanks.

Steve.Ligett@dartmouth.edu
pc532-parts@dartmouth.edu
...!dartvax!u2!stevel

603 646-3189 (work)
603 795-2244 (home)

Steve Ligett
Rural Route 3, Box 451
Lyme, New Hampshire  03768

From owner-pc532%daver@mips.com Wed Jun 20 14:58:30 1990
X-Path: UNB.CA!FELLOWS
From: "David M. Fellows" <FELLOWS@UNB.CA>
To: pc532@bungi.com
Subject:     NS32532 background info
Date: 	Wed, 20 Jun 90 10:01:04 EDT
Reply-To: pc532@bungi.com
Precedence: bulk


I knew I would find it again...

pc532ers who haven't already read it
will probably find the article "Design Considerations for a
General Purpose Microprocessor", Maytal et al, IEEE Computer, January
1989, page 66  of interest.  It discusses the design rationale and
choices for the processor chip.

Actually, pc532ers will probably find most of the articles in that issue
interesting.

David M. Fellows
Professor,
Faculty of Computer Science
University of New Brunswick
P. O. Box 4400
Fredericton, N. B., Canada
E3B 5A3

Telephone: 506 453 4566

From owner-pc532%daver@mips.com Thu Jun 21 00:35:49 1990
X-Path: mac.dartmouth.edu!Steven.D.Ligett
From: Steven.D.Ligett@mac.dartmouth.edu
To: pc532@bungi.com
Subject: PC532 Parts Kits Progress
Date: 20 Jun 90 23:10:56
Reply-To: pc532@bungi.com
Precedence: bulk

Yes, there have been some delays, but about a dozen of you will have parts
kits by this weekend.  I've tried to write to all of you who are on my list to
let you know things are rolling.

I've been taking checks for the kits minus the cpu and fpu, since they won't
be available for another month.  If you didn't the get price list, or mail
from me in the last week, please write!

Dave will be back from vacation in mid-July.  Please have your checks for the
CPU and FPU to me by the 16th; then I'll send one big certified check to Dave. 
He has paid for the dp8490's and ICUs; but I don't know if they've been
shipped to him yet.


From owner-pc532%daver@mips.com Fri Jun 22 03:28:48 1990
X-Path: uunet!virtech!rickr
From: rickr%virtech%uunet@daver (Rick Rodman)
To: pc532@bungi.com
Subject: Re: Hardware Problems
Date: Thu, 21 Jun 90 22:27:21 EDT
References: <<9006160057.AA16555@hpcsbg.col.hp.com>>
Reply-To: pc532@bungi.com
Precedence: bulk

Bdale Garbee writes:
...
> > Yes, but the 32532 when fully seated is really in to stay. The wood would
> > have to be petrified to be able to remove the 32532 without itself
> > splintering.
> 
> I second the motion for a real PGA extractor when one is available...
> 
> ...but apparently unlike many others on the list, I *have* been able to remove
> 175+ pin PGA's with metal screwdrivers without breaking anything.  The key is
> to have about 6 screwdrivers and as many hands... even pressure all around...
> I end up doing 68pin PGA's routinely, so maybe it's just a matter of practice
> (being used to the frustration? :-)
> 
> "These are trained professionals.  Do not attempt this at home."  :-)

I have removed 80386's several times (and, unfortunately, had to reinstall
them :->) by using a single screwdriver many times around the periphery of
the device.  Patience is clearly called for.  Anyhow, if it's *your chip*,
you won't break it because you know it's big $$$ if it breaks.  I hope to
move my '532 from the Designer's Kit to the PC532.  I'd like to use a ZIF,
though, if one is available.  There appears to be sufficient room around
the chip.

Rick Rodman

From owner-pc532%daver@mips.com Fri Jun 22 21:57:15 1990
X-Path: col.hp.com!bdale
From: Bdale Garbee <bdale@col.hp.com>
To: pc532@daver.bungi.com
Subject: Re: Hardware Problems 
Date: Fri, 22 Jun 90 10:29:07 MDT
Reply-To: pc532@bungi.com
Precedence: bulk

> I hope to
> move my '532 from the Designer's Kit to the PC532.  I'd like to use a ZIF,
> though, if one is available.  There appears to be sufficient room around
> the chip.

Be careful about height.  If you get too tall, you'll have trouble putting in
expansion cards... same reason a daughter card under the CPU to implement a
frame buffer is mechanically a problem.

Bdale

From owner-pc532%daver@mips.com Sun Jun 24 23:44:33 1990
X-Path: hplwbc.hpl.hp.com!culberts
From: Bruce Culbertson <culberts@hplwbc.hpl.hp.com>
To: pc532@hplwbc.hpl.hp.com
Subject: Minix
Date: Sun, 24 Jun 90 15:49:59 pdt
Reply-To: pc532@bungi.com
Precedence: bulk

Ok, I am finally ready to distribute Minix for the pc532.  There are
three machines running it already in addition to my own.  Dave Rand and
George Scolero have taken a copy with them to Australia so there may be
some more systems soon.  I think people are generally pleased.  Think of
this as an experimental system, however, rather than a supported,
reliable, production system.  Setting up Minix to run on your pc532 will
very likely involve some grubby bit-twiddling.  Installation notes will
be skimpy but I will answer questions via e-mail and the mailing list.

Minix is copyrighted by Prentice-Hall so I have to be careful about
distributing it.  To receive Minix from me, you will need to send me the
boot disk from any official Prentice-Hall Minix distribution.  The
copyright must appear on the disk label.  No reasonable facsimiles,
please.  If you have a tape version, please send it along with enough
postage for me to send it back to you.  I will return all tapes and
disks but do keep a copy!

I originally intended to distribute pc532-Minix via e-mail.  However,
since I have to return your boot disks anyway, I decided to distribute
it on floppy disks.  There were also concerns about e-mail security,
reliability and cost.

I also intend to distribute more files than I originally announced.  You
will still need to get most of the library and command sources from a
standard Minix distribution.  The distribution will include

  * Over 100 command binaries
  * All sources to rebuild the OS image
  * All code development tools
  * Standard library and floating point library binaries
  * Floating point library sources
  * Full include file tree

At least in the beginning, I will supply these on MS-DOS disks.  MS-DOS
machines are pretty common and PC-Minix owners can read MS-DOS disks
from their Minix machines.  The files will be tar'ed and compress'ed.
The files fit on two 1.2 megabyte or six 360 kilobyte disks.  I prefer
to make 1.2 megabyte disks.  I'll consider making other formats (besides
360K and 1.2M MS-DOS) as time and equipment allows.  Getting the files
onto your pc532 SCSI disk is a problem you will have to solve.

To receive the distribution, send your boot disk and one of

  plan A
    * two 1.2M floppies
    * packaging for return mail
    * postage for return mail

  plan B
    * six 360K floppies
    * packaging for return mail
    * postage for return mail

  plan C
    * six dollars for floppies, packaging, and return postage

Send the above to

  Bruce Culbertson
  2083 Princeton Street
  Palo Alto, California 94306
  U.S.A.

That's it.  Hope this goes smoothly.

Bruce

From owner-pc532%daver@mips.com Tue Jun 26 00:28:34 1990
X-Path: mips!bu-it.BU.EDU!budd
From: budd@bu-it (Phil Budne)
To: pc532@daver
Subject: (Massachusetts) Bay Area PC532ers
Date:  Mon, 25 Jun 90 23:34:05 EDT
Reply-To: pc532@bungi.com
Precedence: bulk

Here are the pc532 crew members I know of in Massachusetts;

Bert (and soon to be me) at Shiva
Dave Taylor at Thinking Machines
Jerry Callen at Encore
Me at BU (for only a little while longer)

and to the North there is the good Steve Ligett purveyor of parts.

Anyone else in New England?
	-Phil

From owner-pc532%daver@mips.com Wed Jun 27 02:40:05 1990
X-Path: mac.dartmouth.edu!Steven.D.Ligett
From: Steven.D.Ligett@mac.dartmouth.edu
To: pc532@bungi.com
Subject: Re: (Massachusetts) Bay Area PC532ers
Date: 26 Jun 90 16:02:21
Reply-To: pc532@bungi.com
Precedence: bulk

I don't have any other New Englanders on my list.

From owner-pc532%daver@mips.com Fri Jun 29 10:23:41 1990
X-Path: pyramid!swbatl!texbell!vector!jonb
From: jonb@vector.dallas.tx.us (Jon Buller)
To: pc532@daver.bungi.com (pc532)
Subject: Getting hard disks for all those parts we have bought.
Date: Fri, 29 Jun 90 7:31:30 CDT
Reply-To: pc532@bungi.com
Precedence: bulk

Well, now that the pc532 parts kits are headed all over the world from
the NorthEast... (BIG round of applause for Steve)  Has anyone given
thought to the idea of a group buy on hard disks.  I was thinking about
a Micropolis (1570, I think) 5.25" half height 340MB SCSI drive.  That
way I can put it inside either my Mac or my pc532...  A quote for a
SINGLE drive from a local distributor was about $1300, but I think that
20 or 30 would bring the price down quite a bit.  There was a 720MB full
height drive that was quoted at about $2110, too.  Anyway I am open to
suggestions on what people would like and if there is demand for this.
I have also thought some people from comp.sys.mac might want to get in
on this for their Mac II's (but then we are restricted to 5 inch half
height or 3.25" drives (if we want to include the IIc? and SE* people).
So, what do you think???

----------------------------------------------------------------------
Jon Buller       jonb@vector.dallas.tx.us       ..!texbell!vector!jonb
FROM Fortune IMPORT Quote;             FROM Lawyers IMPORT Disclaimer;

From FELLOWS%UNB.CA@BUACCA.BU.EDU Fri Jun 29 15:10:31 1990
Date:        Fri, 29 Jun 90 15:25:27 ADT
From: FELLOWS%UNB.CA@BUACCA.BU.EDU
To: <budd@bu-it>
Subject:     Re:  GCC, GDB, GAS and binutils for the ICM3216 and other NS32k
 Systems

On  Fri, 23 Mar 90 03:26:29 EST  budd@bu-it.bu.edu (Phil Budne)
writes:

> I now have Ian's files (along with many other 32k goodies) in North
> America.  Use anonymous ftp to BU.EDU (128.197.2.6) and look in
> ~ftp/users/budd/32k

Greetings from not too far from New England.  I noticed that you
mentioned moving.  Does that mean that the archives mentioned above
are going to evaporate or move too?  I ask because I have been waiting
for our institution to get connected to the internet so that I can
ftp them directly instead of going through bitftp (which is painful,
but much better than nothing).   I think 2 more weeks will see at
least an experimental connection.  Can I wait that long?

Dave Fellows

From FELLOWS%UNB.CA@BUACCA.BU.EDU Fri Jun 29 15:43:12 1990
Date:        Fri, 29 Jun 90 16:39:15 ADT
From: FELLOWS%UNB.CA@BUACCA.BU.EDU
To: budd@bu-it(Phil Budne)
Subject:     Re:  GCC, GDB, GAS and binutils for the ICM3216 and other NS32k
 Systems

On  Fri, 29 Jun 90 15:18:11 EDT  budd@bu-it.BU.EDU (Phil Budne)
writes:

> The files will continue to be available.  I expect to move them
> at some point to my new workplace.
>
That's a relief.  Thanks.  Wil be in touch if need be.  Dave Fellows

From owner-pc532%daver@mips.com Sat Jun 30 01:35:10 1990
X-Path: mac.dartmouth.edu!Steven.D.Ligett
From: Steven.D.Ligett@mac.dartmouth.edu
To: pc532@bungi.com
Subject: The PC532 Parts Kits News
Date: 29 Jun 90 15:55:37
Reply-To: pc532@bungi.com
Precedence: bulk

Volume 1, Number 1.  "All the parts that's fit to kit"

Many packages are going out tomorrow.  I don't have a list in front of me;
I'll send it out tomorrow too.  Thank you for your patience.  This has taken
more time than I expected.

Has anyone had any problems with the kits, or questions?

State of the kits:  All the parts have come in except the CPU, FPU, ICU, and
DP8490.  The DP8490 and ICU were shipped to me last week from California, I'm
told.  I plan to ship out as many packages tomorrow (Saturday June 30) to
PC532'ers in the USA as I can.  I'll finish filling new orders and fill-in
missing parts from old orders.  I haven't shipped any parts out of the country
since shipping costs are so high.  I'm temporarily short on 74as1034s and
74als1034s, but found a supply of them.  My first three choices for
distributors had lead times of 8 to 16 weeks, but Newark has them in stock. 
For now I'll ship 3 'as1034s, and will ship later orders with 1 'als1034, and
2 'as1034s.

PALs.  My PAL programmer needs a software update to be able to program the
20L8-10 PAL.  I'm supposed to get that in 10 days.  Until then I'll be
shipping kits without PALs - unless you have a PAL programmer, and you want
unprogrammed PALs.  I use TI PALs; TIBPAL20L8-10CNT is the one I can't yet do.

Memories.  I haven't been able to get the non-parity memories.  (Yes, they
were supposed to be factory stock.)  However, I have gotten slightly better
prices on the parity memories - the Toshiba THM91000AS-70.  So, for now, item
48 on the list is 4 megs of parity memory at US$80 per meg.  (I'll refund
those who overpaid, or credit the overpayment toward CPU and FPU.)  If you
ordered non-parity memory, please tell me if you want to "upgrade" to parity
memory.  The difference is US$25.

More on memories.  Four meg SIMMs are getting cheaper.  I won't have exact
prices or availability until July 2, but the estimated price is
   US$325 per 4 meg by 8 SIMM, Hitachi 80 ns parts
   US$350 per 4 meg by 9 SIMM, Hitachi 80 ns parts.
I can change orders to 4 meg SIMMs, as long as not everyone changes - I have
over 50 megs of 1x9 SIMMs on hand!

The CPU and FPU.  Dave will be back from vacation in two weeks.  The CPU and
FPU may arrive anytime after that.  Please have payment to me by July 16 for
the CPU and FPU.

Foreign orders.  Please have payment to me by July 16.  I'd estimate shipping
charges at US$50, for UPS pretty quick (about a week) delivery.  I'll check
once more on Monday to see if I'm authorized to take VISA/MC.  So far I'm not. 
Some of you want to wire money to my bank account.  Here's the info:

Bank:  First New Hampshire Bank of Lebanon
       20 West Park Street
       Lebanon, New Hampshire  03766
       USA
ABA#:  011700878       some sort of bank number
Acct#: 1003715647 01   my account number

My Postal Address:
Steve Ligett
Rural Route 3, Box 451
Lyme, New hampshire 03768
USA

My phone numbers:
603 646-3189 (work)
603 795-2244 (home)

From daver!owner-pc532 Sat Jun 30 17:28:41 1990
X-Path: uunet!tarpit!manatee!John.L.Connin
From: John Connin <daver!uunet!manatee!johnc>
To: uunet!bungi.com!pc532
Subject: A pc532 / ISA-386 X-Window Opportunity
Date: Sat, 30 Jun 90 11:53:50 EDT
Reply-To: pc532@bungi.com
Precedence: bulk


Recently, a message in comp.os.minix indicated the availability of
Bruce Evans' 32-bit update for PC-Minix Version 1.5.X.  This 
coupled with the availability of Bruce Culberts'pc532 Minix and 
X11R4 should provide a method for supporting X-Windows, if you are 
so inclined.  

Simply the thought is to use an ISA-386SX/DX as an IO server 
using RPCs'over the SCSI peripherial bus as illustrated below.  
An additional benefit is access to floppy disk, parallel port, etc 
devices.


     Platform - ISA 386 SX/DX                           Platform - pc532 
    +-----------------------+                         +-----------------+
    |                       |  	                      |                 |  
    | OS - PC Minix (32bit) |                         | OS - 532 Minix  | 
    |                       |                         |                 |
    | Keyboard              |                         |                 |
    | Mouse                 |                         |                 |
    | Display Adapter 	    |                         |                 |
    | Display (ega/vga/8514)|	                      |                 |
    | Disk Adapter 	    |                         |                 |
    | Floppy Disk	    |		              |                 |
    | Hard Disk (optional)  |      	              | Hard Disk       |
    |                       |         (1)             |                 |
    | SCSI host adapter	    | <----- scsi bus  -----> | (built-in)      |
    |                       |       Amoeba RPC        |	                |
    |                       |        Protocol         |                 |
    | parallel ports, etc.. |         	              | serial ports,   |
    |                       |                         | ethernet, etc   |  
    |                       |                         |                 |
    +-----------------------+                         +-----------------+

 (1) When the et532 becomes available, the SCSI bus network could 
     be replaced with an ethernet.

Of course this approach may not be your cup of tea.  But it does appear
to provide an interesting opportunity for those who already own the requisite
hardware.

Please understand my intent in posting this message is to merely share
an observation -- I do not plan to develop it.

Best regards,
johnc

-- 

