From owner-pc532%daver@mips.com Tue May  1 09:38:40 1990
Flags: 000000000000
X-Path: augean.ua.oz.au!idall
From: idall@augean.ua.oz.au
To: pc532@daver.bungi.com
Subject: GNU cross development tools.
Date: Tue, 1 May 1990 16:28:32 +1000
Reply-To: pc532@bungi.com
Precedence: bulk

The patches I have for anonymous ftp on augean.oz.au, have been
upgraded to support cross development on big-endian machines.

There is little change to the patches for gas and gcc. The only
problem was with floating point constants and then only when -O is
specified.  The changes to ld are quite extensive and are controlled
by the "CROSS_LINKER" preprocessor directive.

The executables built on a sun4 using these tools are byte for byte
identical with those generated using the same tools running on my
ICM3216. If you are downloading (and do not have to have executables
compatable with a native kernel) then this level of compatability
might be more than is necessary.

The cross development environment is likely to not work on host
machines where sizeof(foo) is different from the target machine.
Floating point might still be a problem on machines without IEEE
floating point format. (This doesn't seem to be a problem with
optimisation turned off, but no guarantees).

Gcc's support for long long might also be defective (I don't know,
it is just a hunch) when host and target byte order differs.

I have not made any of the other binutils (ar, nm, strip etc) work on
a bigendian machine. Anyone else want to have a go? They should be
relatively simple. Using the same EXTERNALIZE and INTERNALIZE macros I
used for ld.

I'm not too sure about ar formats, but I think you can use the host's
ar to build a library for cross linking. The library would lack a
__SYMDEF section, but if that is missing I think ld just does a linear
search through all the files in the archive.


Ian Dall

From owner-pc532%daver@mips.com Tue May  1 11:42:37 1990
Flags: 000000000000
X-Path: lars.Seri.GOV!sverre
From: sverre@lars.Seri.GOV (Sverre Froyen)
To: pc532@daver.bungi.com
Subject: Another pc532 is UP
Date: Tue, 1 May 90 07:57:34 MDT
Reply-To: pc532@bungi.com
Precedence: bulk

Plugged in the last few parts (from Trip Martin) yesterday, connected
power and a terminal, and turned it on -- nothing.  Swapped the read
and write wires to the terminal and tried again -- IT WORKS.  I wish
all my projects were this easy to fix -:)

Now for software.  I got the download command to work and wanted to
try the pi program.  However, my atob (version 4) chokes on the
btoa compressed version that got posted to the list.  Can anyone
send me either a more recent atob (or tell me where to find one)
or a uuencoded version of pi (the program that is).  It would also
help me, and perhaps others, if I could get some step by step
instructions of how to compile, link (e.g. or an ICM3216 or Sun),
and run a simple test program.

Again, thanks for a well designed kit!

Sverre

From owner-pc532%daver@mips.com Wed May  2 17:12:06 1990
Flags: 000000000000
X-Path: convex.com!bobm
From: bobm@convex.com
To: pc532@bungi.com
Subject: Re: GNU cross development tools. 
Date: Tue, 01 May 90 13:28:56 CDT
Reply-To: pc532@bungi.com
Precedence: bulk

I've ported all the binutils except for gprof to a bigendian machine
(a convex c2).  I used functions with names like "internalize_symtab"
and "externalize_relocations". I'm using bsd format objects and
executables.  All the word data in the files are little-endian.

Would you like me to mail diffs of my stuff to you?

					K<bob>

From owner-pc532%daver@mips.com Wed May  2 19:17:01 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: re: contributions for PD C lib
Date: 2 May 90 19:04:01 MSZ (Wed)
Reply-To: pc532@bungi.com
Precedence: bulk

Thanks to all that suggested I use BSD's math lib, which has
been tahoe'd and is thus "free". I will do exactly that.

On other fronts, still working on unifying all this stuff (seems
everyone and his brother has their own version of foo.c) and getting
the fig-forth ROM working. All the forth stuff works, I'm just now
trying to get all of Bruce's monitor features folded in ("1000 500 DISASSEMBLE")
and tested. I'll let y'all know how this goes. I also made the somewhat
misleading remark that "Bruce's new rom scsi code didn't work." Sorry, all,
I was referring to a prerelease he was kind enough to send me. The
one he posted to the group apparently works, and I shall test it tonite.
If that all works fine, I will be using Bruce's new scsi_{hi,low} routines
in the next release of the stand-alone library. You will need this
library to compile the forth ROM.

To Bruce: Looks like we have a mail problem again. I sent you
several acks to the pre-release code you sent me, but you
apparently never got them. Sigh. Do you have another mail address?


					Jordan

From owner-pc532%daver@mips.com Fri May  4 00:59:47 1990
Flags: 000000000000
X-Path: uunet.UU.NET!hcr!ron
From: ron%hcr@uunet.UU.NET
To: pc532@daver.bungi.com
Subject: A better CRC routine
Date: Thu, 3 May 90 18:42:30 EDT
Reply-To: pc532@bungi.com
Precedence: bulk

The following is a crc16 routine for the 32000 family,  note that
it is faster than the single bit loop version and the table used
fits into cache. The C code has been tested on a 386 and
a VAX. The results have also been compared to the vax CRC instruction
results. Give it a try.

CAUTION -
This is a true crc16 routine, it has been used for many years
on various communication protocols - it works.  The CCITT routine
posted is NOT a valid CCITT crc (it does not use an initial value
of 0xfff ...).  The interesting property of the crc16 routine is that
a buffer of zeros has a crc value of 0, this is NOT true for the
CCITT crc.

;
; crc16.s
;
; Declare all routines as exports
;
;
; ***	unsigned short crc16(out,buffer,size)
;	char *out;
;	char *buffer;
;	unsigned short size;
;		This routine returns the crc16 for 'buffer' of 'size'. 
;		If 'out' is non-zero, result is also stored there.
;	Registers:	r0 = result
;			r7 = buffer pointer
;			r6 = size remaining
;			r5,r4 intermediate results
;
crc16:
	enter	[r4,r5,r6,r7],0x00	; Enter frame
	movd	12(fp),r7		; Point to buffer
	movzwd	16(fp),r6		; Buffer size
	movd	0,r0			; start result
;
; buffer loop
;
crc_1:	movzbd	0(r7),r5		; Get next character
	xorb	r0,r5			; Xor low byte with previous
	movd	r5,r4			; Copy
	andb	0x0f,r5			; Extract low nibble
	movw	crc16l[r5:w],r5		; Table entry for low nibble
	andb	0xf0,r4			; Extract hi nibble
	lshb	-3,r4			; Index [w] to table
	xorw	crc16h[r4:b],r5		; Xor table entry for hi nibble
	lshw	-8,r0			; Old hi byte to low byte
	xorw	r5,r0			; Xor table entries
	addd	1,r7			; Update pointer
	acbw	-1,r6,crc_1		; Dec size and repeat
;
	cmpd	0,8(fp)			; Output pointer specified?
	beq	crc_2			; No
	movw	r0,0(8(fp))		; Yes -	save result there
crc_2:	exit	[r4,r5,r6,r7]		; Restore
	ret	0			; and return

;
; crc16 table: low and hi halves, each 16 words
;
	.align	4			; word align for speed
crc16l:	.word	0x0000,0xc0c1,0xc181,0x0140
	.word	0xc301,0x03c0,0x0280,0xc241
	.word	0xc601,0x06c0,0x0780,0xc741
	.word	0x0500,0xc5c1,0xc481,0x0440
crc16h:	.word	0x0000,0xcc01,0xd801,0x1400
	.word	0xf001,0x3c00,0x2800,0xe401
	.word	0xa001,0x6c00,0x7800,0xb401
	.word	0x5000,0x9c01,0x8801,0x4400


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

/* C version */
static int      crc();
int	crc_table();

/* crc16 - DDCMP and Bisync (16 bit)
 *	x^16 + x^15 + x^2 + 1
 */

#define TEST	1		/* set to 1 for testing */
#define SINGLE	0		/* single bit version */


/*	crc16 - crc16 routine
 *
 *	R.K. Irvine
 *
 *	This routine returns the crc16 for the buffer pointed
 *	to by "in" of size "size".
 *	crc16 is given by:  x^16 + x^15 + x^2 + 1
 */

unsigned short crc16_l[] = {
	0x0000,0xc0c1,0xc181,0x0140,
	0xc301,0x03c0,0x0280,0xc241,
	0xc601,0x06c0,0x0780,0xc741,
	0x0500,0xc5c1,0xc481,0x0440,
};

unsigned short crc16_h[] = {
	0x0000,0xcc01,0xd801,0x1400,
	0xf001,0x3c00,0x2800,0xe401,
	0xa001,0x6c00,0x7800,0xb401,
	0x5000,0x9c01,0x8801,0x4400,
};

unsigned short
crc16(in, size)
	unsigned char *in;
	int size;
{
	unsigned short	c, n, crc;

	crc = 0;
	while (size--) {	
		n = *in++ ^ crc;
		crc = crc16_l[n&0x0f] ^ crc16_h[(n>>4)&0x0f] ^ (crc>>8);
	}
	return(crc);
}

#if TEST
/* test routine */
main() {

	printf("CRC16 test routine\n");

	test("Hello world.", 0x33f9);
	test("12345678901234567890", 0x9b37);
	test("if else while case", 0xdb7f);

	printf("done\n");
}

test(s, n)
	unsigned char *s;
	int n;
{
	static t=0;
	int	r;

#if SINGLE	/* test with single bit version */
	r = crc_ok(s);
#else	/* test nibble version */
	r = crc16(s, strlen(s));
#endif

	printf("test %d: '%s' = %x; ", t++, s, r);
	if (r != n) {
		printf("BAD, should be %x\n", n);
	}
	else {
		printf("OK\n");
	}
}

/* single bit version of crc16 */

unsigned crc_byte(crc, new_ch)
register unsigned short crc;
int new_ch;
{
	register unsigned short bit;
	register int i;

	for (i=1; i <= 0x80; i<<=1) {

		bit = ((new_ch&i)?0x8000:0);
		if (crc & 1) bit ^= 0x8000;
		crc >>= 1;
		if (bit) crc ^= (int)(0x2001);
		crc |= bit;
  	}
	return crc;
}

crc_ok(p)
	char *p;
{
	unsigned crc = 0;
	while (*p) {
		crc = crc_byte(crc, *p++);
	}
	return(crc);
}
#endif		




From owner-pc532%daver@mips.com Fri May  4 13:17:06 1990
Flags: 000000000000
X-Path: hplwbc.hpl.hp.com!culberts
From: Bruce Culbertson <culberts@hplwbc.hpl.hp.com>
To: pc532@bungi.com
Subject: Re:  A better CRC routine
Date: Fri, 4 May 90 09:59:01 pdt
Reply-To: pc532@bungi.com
Precedence: bulk

When I implemented the monitor download command, I considered the
various popular CRC codes.  I chose the one I did because I thought
it was compatible with both Minix and CCITT.  CCITT is definitely
the wave of the future -- the organizations behind it have far more
clout than the people using CRC16.

I am disappointed to hear that the Minix people blew it when they
implemented their CRC -- that it is not really CCITT.  My preference,
however, is to try to convince them to fix their code and bring
it into conformance.  By the way, does anyone know what POSIX
specifies for the "sum" command?  Is there a POSIX "crc" command?

I used a bit serial algorithm to save ROM space (no table required)
and because download time was dominated by the serial port throughput.
I like the small table size used by the posted CRC16 routine.

Bruce Culbertson

From owner-pc532%daver@mips.com Fri May  4 15:35:18 1990
Flags: 000000000000
X-Path: dlr
From: dlr@daver.bungi.com (Dave Rand)
To: pc532@bungi.com
Subject: Re: Gatewayed mail message
Date: Fri, 4 May 90 12:07:38 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

[In the message entitled "Gatewayed mail message" on May  4, 12:44, bob von borstel writes:]
>   I have another ? that you can answer.  When talking to my NS distributor,
> he found 2 versions of the 32381 fpu, a u and a v version.  I assume I want
> the u version, but can you tell me what the difference is?
The U version is in a ceramic package, and is a PGA (Pin Grid Array).
The V version is in a plastic package, and is a PLCC.

You _should_ be able to use the V version. It is significantly less
expensive. We have ordered a couple to try from the local NS field office
here, but they have been quite slow in getting them to us. I suspect that
they may not be in full production yet. As soon as we get one working,
we will let you know.

BTW - steve.ligett@mac.dartmouth.edu is putting together parts kits
for those that want them. By purchasing in volume, the prices will be
better than you can get on your own - this includes the CPU/FPU/ICU.


>   When I purchase the 532/381 parts, since they are $$$, and the cost
> differential between 25mhz and 30mhz isn't too extreme, is it possible
> to buy the 30mhz parts, and drive the board at 25mhz, and then 'maybe'
> later down the road, replace the 50mhz crystal with 60mhz, or are your
> design tolerances strictly 25mhz?

You are welcome to try this. The design is for 25 Mhz, and every nanosecond
counts. Really. 25 Mhz is a realistic operating frequency, and is picked for
the optimal balance between memory wait states and system performance.
Going to 30 Mhz would really require another wait state on the memory -
reducing memory bandwidth by 33% (3 clocks instead of 2). Right now,
we get 50 megabytes per second at 25 Mhz - at 30, it would be 40 meg/sec.
While the caches on the 532 help, a 10 meg/sec loss in memory bandwidth
would hurt! (The 32016 has a 4 meg/sec bandwidth, the 32032 an 8 meg/sec).

If you do try to push to 30 Mhz without re-doing the memory timing, you
will need to carefully evaluate the worst case paths, and increase the
speed of the PALs and memory devices to match. George has posted on this
topic in the past, let me see... <rummage, rummage, shuffle> Ah HA! 

<From pcdig13>

In-Reply-To: Dave Mason's message on Dec 12, 15:45.
X-Mailer: Mail User's Shell (6.2 5/11/88)
To: pc532@daver.UU.NET
Subject: Re: FPU
Message-Id: <8912122348.AA23965@wombat.UUCP>
Date: 12 Dec 89 23:48:24 PST (Tue)
From: george@wombat.UUCP (George Scolaro)
Status: OR

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

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

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

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

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

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


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

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

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

Fine, you're on the list.

Note: 1 nanosecond is a short piece of wire.

best regards,

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


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

From owner-pc532%daver@mips.com Fri May  4 19:56:20 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: Gatewayed mail message
Date: Fri, 4 May 90 16:48:38 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

[In the message entitled "Gatewayed mail message" on May  4, 17:53, bob von borstel writes:]
> so....i assume driving the 30mhz 532 at 25 mhz is okay.
> I know some ic designers (motorola) for example have minimum timing requirements
> when you want to drive a fast chip slower (88k).  Don't have the specs on
> the 532 driving.

No problem. The 532 minimum clock speed is 10 MHz. Since 30Mhz, 25MHz and
20MHz speeds are all the same part - just graded for speed, you can certainly
run a 30MHz part at 25MHz (or slower).

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 Sun May  6 01:01:01 1990
Flags: 000000000000
X-Path: augean.ua.oz.au!idall
From: idall@augean.ua.oz.au
To: pc532@daver.bungi.com
Subject: GNU binutils patches.
Date: Sun, 6 May 1990 13:13:36 +1000
Reply-To: pc532@bungi.com
Precedence: bulk

Some people have noted that the binutils patches don't apply properly.
It turns out the the version of binutils on prep.ai.mit.edu is *not* the
most recent. I have a version of binutils which has entries in the ChangeLog
by FSF people (including RMS) more recent than the binutils.tar.Z on prep!

I have know idea where we got our version (direct from someone at the FSF?)
but it looks like they have stuffed up or that we got an interim release.

Anyway, so that you can all apply the patches, I have created a set of
patches against the version currently on prep. The patches are available
for anonymous ftp from augean.ua.oz.au.

Please note that there are several versions of the patches. Note that
they are just that -- versions of the same patches and not a sequence
of patches.  You do *not* need to apply binutils.patch1.0.Z and
binutils.patch1.1.Z before applying binutils.patch1.2.Z.


Ian Dall


From owner-pc532%daver@mips.com Sun May  6 23:19:28 1990
Flags: 000000000000
X-Path: ucisae.isae.cancol.oz.au!eyal
From: eyal@ucisae.isae.cancol.oz.au (Eyal Lebedinsky)
To: pc532@bungi.com
Subject: Re:  A better CRC routine
Date: Sat, 5 May 90 13:05:38 
References: <<9005041659.AA01106@hplwbc.HPL.HP.COM>>
Reply-To: pc532@bungi.com
Precedence: bulk

Hi Bruce,

Looking at posix P1003.2 (Draft 9, 29 Aug 89):

The CRC is the sum of the following expressions, where x is each byte of
the file.

x**32+x**7+x**5+x**3+x**2+x**1+x**0

The value returned by cksum (eyal: this is the command...) is truncated to
32-bit value.

----- end of quote ---
Then there is a 2-1/2 pages C program to calculate the CRC, credited to
Steve Bellovin and Peter Honeyman later modified by Glenn Fowler and Landon
Curt Noll.

Hope this helps you.

-- 
Regards
	Eyal


From owner-pc532%daver@mips.com Mon May  7 11:33:38 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: various unresolved issues.
Date: 7 May 90 16:15:33 MSZ (Mon)
Reply-To: pc532@bungi.com
Precedence: bulk


I was feeling especially masochistic this weekend and decided to
re-read the entire pc532 mailing list archive. It's amazing how
many questions I've posted to this group that had already been
answered somewhere in the mists of time. Sigh. It's a pity that the "FM"
is almost 3 megabytes now or I'd have been more willing to RTFM (but that's
still no excuse, I guess).

Anyway, that's all off the subject. After reading all those messages, I
started wondering about a number of issues that seemed to have slipped
between the cracks:

*** On the hardware front: ***

Ken S. was talking about a DSP board, whatever became of that?

Is anyone working on, or planning to work on, a decent intelligent frame
buffer card? This seems like it would be a mondo priority. Given that
I'm a software type, I'm in the position of having to plead and whine
for this stuff and hope that some hardware jock gets irritated enough
to knock something out just to shut me up :-). Still, give me the hardware,
I'll give you an R4 server.

What's the story on the eth532 card? I've seen one message saying that
it supports only thin ethernet and another saying that it supports both
thin-and-thick. What's the truth, here? G&D: Have you guys done a
complete parts cost estimate yet? I want one.

*** On the software front: ***

How's Minix coming along? I can't help but (humorously) remember
a certain quote from Bruce in <8912081857.AA01037@hplwbc.HPL.HP.COM>
on Fri, 8 Dec 89 10:57:10 pst:

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

Ah, the simple naivete of youth! :-) (just kidding Bruce, really!)


I really think it's time that we starting thinking in a more "consortium"
like fashion on the Unix front. I realize that many of us have different
goals and ideas about which Unix would be "best", but there's still
a whole lot of common work that can be shared and ideas that can be exchanged.
I, for example, am working on porting 4.3 and am currently going through
the painful first steps of getting stand-alone versions of mkfs/fsck and
friends working as I proceed towards getting a root file system w/simple
stand-alone kernel booted up. This will naturally be the first step for
many others as well, regardless of the unix in question. The same commonality
will occur with the MMU code, scsi device and terminal drivers, etc etc.
If we can manage to stay in close communication (probably via private
mailing lists to avoid lots of nitty-specific issues from clogging this
list), we can arrange things so as to minimize wheel re-inventing wherever
possible. I have already attempted something along these lines with the
libso/libc libs I posted recently, though they are certainly no more than a
rough start. Lest I be accused of being all talk and no action, I'm willing to
set up and coordinate all this myself if no one else steps forward. We
(software developers) really have quite a massive amount of work ahead of
us and could reap significant benefits from each others work, if only
someone would take the time to properly coordinate it (having everyone
think more in terms of writing "building blocks" rather than quick
just-make-it-work hacks would also be a major boon). Are 90% of us just
sitting around staring owlishly at our boards, or what? Some of us have
had working boards for months and I have yet to see even one program to
pong the friggin' lights back and forth! That is a disgrace! :-)

					Jordan

From budd Mon May  7 13:27:43 1990
Flags: 000000000000
Date:  Mon, 7 May 90 13:27:38 EDT
From: budd (Phil Budne)
To: jkh@meepmeep.pcs.com
Cc: budd
Subject: Re: various unresolved issues.

>I, for example, am working on porting 4.3 ...

Are you using 4.3 Tahoe disk labels?  The only things I find lacking
therein is that they only allow 1 byte for filesys type (and the
per-filesys parameters are taylored to 4.3 FFS) and that the number of
partitions is limited to 8.  I would expand MAXPARTITIONS to 16.

>Are 90% of us just sitting around staring owlishly at our boards, or what?

Yes, but because I'm still missing some parts!!

>Some of us have had working boards for months and I have yet to see
>even one program to pong the friggin' lights back and forth! That is
>a disgrace! :-)

People are probably waiting for you to supply led_{on,off} routines
in libso!!

I was looking at extending libso to allow open by
ctrlr/addr/lun/partition, so multiple open files can be on more than
one disk!! As well as allowing i/o to multiple ttys.

-Phil

From owner-pc532%daver@mips.com Mon May  7 16:44:03 1990
Flags: 000000000000
X-Path: hplwbc.hpl.hp.com!culberts
From: Bruce Culbertson <culberts@hplwbc.hpl.hp.com>
To: pc532@bungi.com
Subject: Re:  various unresolved issues.
Date: Mon, 7 May 90 12:05:25 pdt
Reply-To: pc532@bungi.com
Precedence: bulk

> *** On the software front: ***
> 
> How's Minix coming along? I can't help but (humorously) remember
> a certain quote from Bruce in <8912081857.AA01037@hplwbc.HPL.HP.COM>
> on Fri, 8 Dec 89 10:57:10 pst:
> 
> >I would guess that a one weekend effort would get Minix running on the
> >pc-532.

Oh well, I knew at the time that was a dumb thing to say.  It's
always better to do something and then say you did it.  However,
in my defense...  I just spent my second weekend at home since
November.  The first weekend was consumed getting the monitor to talk
to my OMTI SCSI to floppy/ST-506 interface.  This was prerequisite
to working on Minix.

I finally got some time to work on Minix this weekend.  Those UART's
are a pain in the arse to use -- I wasted a lot of time getting
the TTY task working.  I got the kernel running (no fs or mm yet)
but still have stubs for the SCSI driver and the page manipulation
routines.  I compiled a few test versions with some hard-wired "user"
processes.  One test checked out the TTY driver.  Another had two
processes which passed a token (really a Minix message) back and
forth.  The current token holder printed a string to the screen
and then sent the token back to the other process.  Hence, the
screen looked like

	process 1
	process 2
	process 1
	...

That's even less useful than printing pi to 10,000 places, eh?
I'm pretty sure I will not get any more time to work on Minix in the
next two weeks.  But then (here comes another soon-to-be-regretted
statement), I expect to see a Minix login after another weekend 
of work.

Bruce

From owner-pc532%daver@mips.com Tue May  8 13:09:48 1990
Flags: 000000000000
X-Path: mips!bu-it.BU.EDU!budd
From: budd@bu-it (Phil Budne)
To: pc532@daver
Subject: from comp.periphs.scsi
Date:  Tue, 8 May 90 12:16:08 EDT
Reply-To: pc532@bungi.com
Precedence: bulk

    From: ericz@ucscb.UCSC.EDU (Eric Zamost)
    Newsgroups: comp.periphs.scsi,comp.sys.ibm.pc,ba.market.computers
    Subject: Miniscribe 9380S - info?
    Message-ID: <3150@darkstar.ucsc.edu>
    Date: 7 May 90 16:51:49 GMT

    ....

	 The drive which looks best thus far is a Miniscribe 9380S, 
    330Meg, 16ms, SCSI, full height, new, for $850, from Hi-Tech, Inc.  
==============================================^^^^
    (The story is that Miniscribe was purchased by Maxtor, and Maxtor 
    is getting rid of the old stock.  The drive would be warranteed by 
    Maxtor for a year.)

    ....

	 Also, if anyone has a drive they wish to sell which might work 
    for me, a SCSI controller worthy of this drive, or a case and power
    supply for a full height drive (I might make it external), please
    contact me.

    From: dougp@ico.isc.com (Doug Pintar)
    Newsgroups: comp.periphs.scsi,comp.sys.ibm.pc,comp.unix.xenix,comp.unix.i386
    Subject: Re: Adaptec 154xB SCSI host adapter (was: Re: WD SCSI Controller)
    Message-ID: <1990May7.211407.6954@ico.isc.com>
    Date: 7 May 90 21:14:07 GMT

    In article <1990May6.135921.13129@cti-software.nl> pim@cti-software.nl (Pim Zandbergen) writes:
    >New Adaptec 154xB ? Could anybody shed some light over this?
    >What is different from the A model? How compatible is it?

    I have one, and it's very similar from a programming standpoint, so the
    existing 386/ix HPDD driver works just fine.  It has some additional
    programmability as to speeds when doing its first-party DMA, and you can
    get more information (like who's negotiated synchronous transfers) from
    it.  The board is half-long, and may be a bit faster.  It also supports
    both target and initiator modes, so you could use SCSI to connect two
====^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    systems (386/ix, however, does not support this).  It's a nice board;
    I have no idea as to how available it is, however.  I got mine from Adaptec
    to make sure the new firmware/bios/hardware all worked with 386/ix.

    Doug Pintar


    From: ericz@ucscb.UCSC.EDU (Eric Zamost)
    Newsgroups: comp.periphs.scsi,comp.sys.ibm.pc
    Subject: Need advice on a 300 Meg.
    Message-ID: <3159@darkstar.ucsc.edu>
    Date: 7 May 90 20:25:40 GMT

	 I just asked about the Miniscribe 9380S for $850.  Now I am
    also considering a CDC-Imprimis 94171-307 (320M, 16.5ms, SCSI, FH)
    for $900.  I think that the CDC is probably the better drive.
========^^^^
    Both come with 1 year warranties.  The CDC supposedly has an MTBF
    of 100,000 hours, and the Miniscribe has 50,000 (are these numbers
    meaningful?)

    Any comments?

From owner-pc532%daver@mips.com Tue May  8 13:26:56 1990
Flags: 000000000000
X-Path: dlr
From: dlr@daver.bungi.com (Dave Rand)
To: pc532@bungi.com
Subject: Re: from comp.periphs.scsi
Date: Tue, 8 May 90 10:11:15 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

[In the message entitled "from comp.periphs.scsi" on May  8, 12:16, Phil Budne writes:]
> 
> 	 The drive which looks best thus far is a Miniscribe 9380S, 
>     330Meg, 16ms, SCSI, full height, new, for $850, from Hi-Tech, Inc.  
> ==============================================^^^^
[...deleted...]
> 	 I just asked about the Miniscribe 9380S for $850.  Now I am
>     also considering a CDC-Imprimis 94171-307 (320M, 16.5ms, SCSI, FH)
>     for $900.  I think that the CDC is probably the better drive.
> ========^^^^
> 
>     Any comments?

Yup. I'm happy with the Miniscribe drives that we got. The price was great,
the service has been fine, and they shipped the drives to the non-local
folks, saving Karl a heap of trouble. All in all, we got a good deal!

If we wait a year (or maybe 6 months), there will be a {bigger/smaller/
faster/slower/same} drive for less money. It never fails in this industry.
It was the right drive, and the right time, at the right price for me.



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

From owner-pc532%daver@mips.com Tue May  8 14:57:22 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: pc532 board caps
Date: Tue, 8 May 90 11:38:10 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

[In the message entitled "pc532 board caps" on May  8, 10:16, Jon Buller writes:]
> Can someone tell me if the caps labeled tantalum on the silk screen
> page really need to be tantalum caps?  Is there some critical reason
> for this or can I use disk caps like I have for everything else?

Yes they do. Tantalum caps have larger values than ceramics or monolithics.
They supply the BULK capacitance for the low frequency currents, the
monolithics supply the high frequency currents. I recommend the use of
monolithic caps (0.3 inch centers, look like little bricks - i.e. the same
as a 2 pin DIP integrated circuit), they have better specs than disc caps.
The tantalums should be around 22uf or so and at least 16V, preferably 25V
or the ones on the +/- 12V rails.

> Also, what positions should J1 and J2 be in?  I assume that J1 should
> be A12 -> 1M4M for 1Mb SIMMs and A23 for 4Mb SIMMs.  (Is that really A23

J1 - berg between center and A12 for 1Mbit drams.
J2 - berg between center and A22 for 1Mbit drams.

> or should it be A13?)  I am also guessing that on J2, A22 -> BANKS is

Yes, it really is A23 - note the schematics are 100% correct, the netlist
represents the PCB!! The scheme for selecting A12 or A23 was chosen to
produce the 1M4M signal so that the page comparator (74ALS6311) would be
correctly wired to make use of the maximum page size of the DRAM device.
1Mbit drams have 1k page sizes, 4Mbit have 2k page sizes.

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 May  8 14:58:17 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: more questions about pc532
Date: Tue, 8 May 90 11:39:32 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

[In the message entitled "more questions about pc532" on May  8, 10:31, Jon Buller writes:]
> I just finished a call to a second local chip merchant here in Dallas.
> Neither one of these people has heard of an AIC6250 SCSI controller.
> Can someone tell me the manufacturer of the part, or a source?

The AIC6250 is manufactured by Adaptec. We bought ours through WYLE, a large
US wide distributor.

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 May  8 15:06:22 1990
Flags: 000000000000
X-Path: mips!bu-it.BU.EDU!budd
From: budd@bu-it (Phil Budne)
To: pc532@daver
Subject: 9380S Manual(s)
Date:  Tue, 8 May 90 14:02:19 EDT
Reply-To: pc532@bungi.com
Precedence: bulk

Has the dust settled on the 9830 Manual(s) question?

I got 2 disks and two copies of the "Product Manual" P/N 1093 Revision
P10 (2/2/89), NEITHER of which have any pages between 3-3 and 8-1.

Did anyone get sections 4 through 7?

Is there anything more detailed than the "1093" manual?

Has anyone found out what the settings of J12 & J13 (SECTOR SETTING)
are?

-Phil


From owner-pc532%daver@mips.com Tue May  8 15:29:17 1990
Flags: 000000000000
X-Path: sibyl.eleceng.ua.oz.au!ian
From: ian@sibyl.eleceng.ua.oz.au
To: pc532@daver.bungi.com
Subject: Monitor questions
Date: Tue, 8 May 1990 16:32:27 +1000
Reply-To: pc532@bungi.com
Precedence: bulk

Well, I have just been trying to compile Bruce's monitor using gcc/gas/gld.
Not too bad. I have written a sed script to convert between Bruce's assembler
syntax and gas. This is not too hard because the addressing modes syntax is
the same. I have a couple of questions about the semantics of the pseudo-ops
though. What does ".program" and ".static" do? I have assumed they are
the same as ".text" and ".data" is that right?

Gnu ld does not define _bdata. I am currently linking in a little
assembler first.s which defines _bdata to be the pc for the bottom of
the .data section. Does that sound right?

Bruce uses a -D option for your linker. The GNU ld also takes a -D
option but I suspect the semantics are different. The GNU loader used
-Tdata to specify the starting address of the data section and -D
specifies the *size* of the data section. I *think* -Tdata is the
one to use.

One thing I don't understand is what use a .data section is in the
context of a rom monitor. RAM will be uninitialized and ROM is
unalterable. Constant data can be put in the .text segment (and end up
in ROM) and any non constant data will have to be initialized and
might as well be in the .bss segment.


From owner-pc532%daver@mips.com Tue May  8 19:46: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:  Monitor questions
Date: Tue, 8 May 90 15:00:22 pdt
Reply-To: pc532@bungi.com
Precedence: bulk

Ian writes:

> I have a couple of questions about the semantics of the pseudo-ops
> though. What does ".program" and ".static" do? I have assumed they are
> the same as ".text" and ".data" is that right?

Exactly right.  Actually, my assembler accepts any of those.  .Program
and .static are what National used in their NSX assembler for the 32000.

> Gnu ld does not define _bdata. I am currently linking in a little
> assembler first.s which defines _bdata to be the pc for the bottom of
> the .data section. Does that sound right?

	_btext = beginning of the text segment
	_etext = end of the text segment
	_bdata = beginning of the data segment
	_edata = end of the data segment = beginning of the bss segment
	_end   = end of the bss segment

Note that BSS is always placed after the data segment by my linker.
The -T option my be used to place the text segment anywhere.  By
default, _btext = 0 but if you use -T <num>, then _btext = <num>.
The -D option my be used to place the data segment anywhere.  By
default, _etext = _bdata but if you use -D <num>, then _bdata = <num>.

My linker rounds _etext up to a page boundary, a feature I may change
since you then do not know where the last instruction is.  You can
always round up _etext if that's what you want.  However, I will
always round up _bdata so ROUND_UP_PAGE (_etext) will always be _bdata
if you do not use -D.

> One thing I don't understand is what use a .data section is in the
> context of a rom monitor. RAM will be uninitialized and ROM is
> unalterable. Constant data can be put in the .text segment (and end up
> in ROM) and any non constant data will have to be initialized and
> might as well be in the .bss segment.

The compiler assumes a program environment with text, data, and bss
segments.  You do not want to change the compiler just to compile a
ROM.  Also, you do not want to try to remember that you must not use
initialized data because you'll probably forget.  So, the solution
I came up with is to make the text/data/bss model a reality before
the monitor tries to use anything in its data segment.

The monitor knows that the data segment is placed in the a.out file
starting at the next disk block after the end of the text segment.
The text segment and the data segment are copied, without changing
their relative positions, from the a.out file to the ROM.  Hence,
the following code copies the data segment from the ROM into RAM
where the program expects it.  It assumes that you ran the linker with
the option -D <address> where <address> is in RAM.

	{
	  char *s, *d;
	  extern char _etext[], _bdata[], _edata[];

	  for (s = ROUND_UP_BLOCK (_etext), d = _bdata; d < _edata;)
	    *d++ = *s++;
	}

It is also a good idea to zero the bss segment.  Use this code:

	{
	  char *d;
	  extern char _edata[], _end[];

	  for (d = _edata; d < _end;)
	    *d++ = 0;
	}

I lied about one thing above.  The data segment is currently page
(not block) aligned in the a.out file.  I never noticed this mistake
because on the 32016 both the page size and block size were 1K.
I'll fix this soon and post a cdiff for the linker.

Now are really confused?

Bruce Culbertson

From owner-pc532%daver@mips.com Tue May  8 15:31:09 1990
Flags: 000000000000
X-Path: mac.dartmouth.edu!Steven.D.Ligett
From: Steven.D.Ligett@mac.dartmouth.edu
To: pc532@bungi.com
Subject: Re: pc532 parts
Date: 08 May 90 09:43:26
Reply-To: pc532@bungi.com
Precedence: bulk

Ok, now I'm a month late.  I'll be in Boston this week, at Electro.  I'll be
giving distributors the final list of parts we want to buy.  Please send your
orders to 

pc532-parts@dartmouth.edu

Include your name, address, address, etc, as Dave said for board orders.

thanks

From owner-pc532%daver@mips.com Tue May  8 19:46:30 1990
Flags: 000000000000
X-Path: arthur.wwu.edu!bob
From: bob@arthur.wwu.edu (Bob Hayes)
To: pc532@bungi.com
Subject: 9380 Manuals
Date: Tue, 8 May 90 13:56:48 -0700
Reply-To: pc532@bungi.com
Precedence: bulk

Phil asks:	
	>Has the dust settled on the 9830 Manual(s) question?
	>>
	>I got 2 disks and two copies of the "Product Manual" P/N 1093 Revision
	>P10 (2/2/89), NEITHER of which have any pages between 3-3 and 8-1.
	>
	>Did anyone get sections 4 through 7?
	>
	>Is there anything more detailed than the "1093" manual?
	>
	>Has anyone found out what the settings of J12 & J13 (SECTOR SETTING)
	>are?
	
	>-Phil
The "manuals" shipped with the drive consist of the first (few?) pages
of the REAL P/N 1093 Product Manual Models 9380E, 9380S, Revision
P10 2/2/1989. I got 1 drive thru the group buy, and subsequently
ordered 2 more fron CSC for our department.
The drive from the group buy had a stapled set of sheets, consisting of the
first page of some of the chapters in the REAL manual (from MiniScribe).
The 2 other drives came with spiral bound manuals, consisting of the
first page(s) of some of the chapters. One of these manuals had two
covers in place of the first page. 8-)
The FULL manual has all chapters,1 thru 11, and append. A-B.
1 Introduction  2 pages
2 Product Spec. 4 pages
3 Functional Description
4 ESDI Elect. Interface
5 Esdi Phys. interface
6 ESDI-serial mode implimentation
7 Installation
8 SCSI elect. Interface
9 9380S jumper instructions
10 Error codes
11 unpack/ and inspection
A Defin. and measurement of seek time
B 9380SA Apple compat.- vendor specific implimentation of
	page mode 0x3c (software select id)
 Scsi info is mostly in chapt. 8 -8 pages long. Chapt 9 has jumper
settings. Chapt 6 has esdi info, and the only discussion of the J12/13
jumpers.
>From chapt 6, the ESDI chapter...
For the 9380E <== LOOK, an "E"!!  (are we clear here? 8-))
Option Jumpers:
J7	start/stop motor spindle
J9	Diag. jumper
J10,11	Head configuration
J10	J11	Heads
S	S	13
S	O	7
O	S	11
O	O	15
J12,13,19
J12	J13	J19	Sector
O	O	O	35
O	S	O	36
S	O	O	34
S	S	S	Soft(Controller will select sector #)
******* Do these work on the 9380S?? I DON'T KNOW! ********

	
	
***** Bob Hayes	bob@arthur.wwu.edu *****

From owner-pc532%daver@mips.com Wed May  9 01:20:29 1990
Flags: 000000000000
X-Path: uunet!tarpit!manatee!John.L.Connin
From: John Connin <johnc%manatee%uunet@daver>
To: pc532@daver.bungi.com
Subject: Drive Enclosure..
Date: Tue, 8 May 90 20:09:57 EDT
Reply-To: pc532@bungi.com
Precedence: bulk


I thought I would share with the group how I packaged the 9380S drives
which I purchased in the group buy a while back.  

However, first concerning the "Hi-Tech" 9380S deal, I totally agree with
Dave Rand when he says:

>Yup. I'm happy with the Miniscribe drives that we got. The price was great,
>the service has been fine, and they shipped the drives to the non-local
>folks, saving Karl a heap of trouble. All in all, we got a good deal!

Now, where to begin:  When the tower cases first came out I thought
they were the best thing since sliced bread.  However, I subsequently
have come to realize, at least in the less expensive versions, that the
design inherently provides inadequate cooling to the drive bay area.  
Consequently, I decided package the 9380S's in a separate stand alone 
enclosure.

At a local surplus house I was able to find a mini-AT 'like' case
for $10.00.  I say like because it was designed to minimize case 
height (5 inches) by using a special internal board arrangement.
The first drive simple mounts in the FH drive bay provided in
the case.  I mounted the second drive inside the case on 
3/4 inche stand-offs.  The standoffs screw into the holes
provided on the underside of the disk frame.  Next this assembly
is then secured to the bottom of case by machine screws through 
the case into the standoffs.

For a power supply I used one of the new PC 'mini' style switching
power supplies which are rated for 200 watts.  It measures 5.5"L x 5.8"W 
x 3.38:H and cost me $52.00.  The 12VDC serviced is rated at 8 amps.
In practice I am able to spin-up both drives at once with no apparent 
problem, but I suspect the current margin during this period is thin.  
In addition to price and availability, a standard PC type supply has the 
benefit of comming pre-wired so to speak (ie. ready to plug into the drive 
and AC-line).

The one surprise was that the disks ran VERY hot.  After they had run 
for an hour or so they were almost to hot to touch.  Prior to this I had 
only run the drives for short periods and had not noticed any significant 
heat build-up.  So I did the obvious and added a auxilary fan 
in addition to the small onr within the power supply.  The result is the
drives now run quite cool.  Quite frankly, I was amazed at the difference.
The original IO-card space on the rear of the case make an ideal place
to mount the fan.

To provide the SCSI interface, I mounted a 50-pin female Centronics
style connector on the lower rear surface.

Anyway, I am very pleased with the result, and hope that my brief
discription will help someone.  

One modification I am thinking about is adding the ability to select
SCSI ID's from a switch on the rear surface.  This reminds me,
does anyone know of a simple way in which the SCSI terminator
resistors could be 'inserted/removed' via a rear surface 
switch ??

Best regards,
johnc
-- 

From owner-pc532%daver@mips.com Wed May  9 02:27:57 1990
Flags: 000000000000
X-Path: uunet!tarpit!manatee!John.L.Connin
From: John Connin <johnc%manatee%uunet@daver>
To: pc532@daver.bungi.com
Subject: PC Switching Power Supply Question..
Date: Wed, 9 May 90 0:06:33 EDT
Reply-To: pc532@bungi.com
Precedence: bulk


I am using a PC switching power supply with the 12VDC section rated 
at 8 Amps to supply 2 Miniscribe 9380S disk drive.  So far I have
not had a problem but I suspect the start-up current is a little
thin (both drives are currently spun up at the same time).

My question is:  Is it possible to tweak the current sense
resistor (I assume there is one) to increase the 12VDC 
capacity by a couple of amps, provided the wattage rating of
the supply is not exceeded ??   Since the 5VDC is rated at
20 amps and is lightly loaded there should be many watts
available if they can be re-allocated.

Best regards,
johnc 
-- 

From owner-pc532%daver@mips.com Wed May  9 09:03:56 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: To clarify further unclarified issues..
Date: 9 May 90 14:12:38 MSZ (Wed)
Reply-To: pc532@bungi.com
Precedence: bulk

Some people have apparently gotten the misleading impression that I
intend, at some point, on distributing a 4.3 port for the pc532. I'm
sorry if I gave that impression, but this is simply not the case.

My earlier "call for a consortium" among UNIX developers was aimed
strictly at banding together that small group of folk (less than 5% of the
pc532 owners, I'd say) who are bent on going their own way, for whatever
reason. The majority of you seem to be happy enough to go along with
Dave in his efforts to get SYSV, which I applaud and hope succeed, and that
is fine.  A mainstream UNIX for the pc532 will also further legitimize the
machine and encourage further hardware development, which we need.
I, however, will never run SYSV on my pc532 and cannot benefit
(at least not directly) from these efforts. I don't want to start a
religious war here, but I really cannot conceive of running SYSV while
I have a shred of choice in the matter. I, quite simply, loath it to the
core. Why? Well, maybe it's because I cannot count the number of hours of
my life I have wasted fighting to port various BSD applications to SYSV
or going through the agonizing process of trying to get useful work done
in a single-terminal environment without job control. I'm sorry, but I will
not willingly subject myself to further aggravation along these lines. That
would be masochistic.

I know that these are strong opinions, and I'll probably get flamed for them
(which is fine, but please, not on the list), but I guess I've just had it
up-to-here with what seems to be the pervasive "we've got SYSV running,
what more do you want" attitude that the major hardware vendors have taken
(for what I am sure are very good, sound, business reasons, but I can hate
them just the same).

Sorry, I guess I didn't mean to froth at the mouth quite so much,
but my spleen has needed venting for a long time.. :-)

In any case, the license we have here is a research / commercial license
which allows us to port to new hardware, and I am sort of trying to
work under this (admittedly shakey) umbrella. If worse comes to worse,
I will try and get it more fully declared as an official project. This still
does not allow me to ever redistribute so much as one byte of binary
code, and I do not intend (nor did I ever intend) to do so. I am not
trying to supplant Dave's efforts by any means, I would simply like to
get in touch with that small pc532 faction that also has access to
source and can perhaps share diffs/helpful hints in relation to a pc532
port.

I hope that this clears everything up. (God, I hate this legal $@#%$#@!!).

					Jordan

From bobh@unicorn.wwu.edu Wed May  9 11:49:25 1990
Flags: 000000000000
Date: Wed, 9 May 90 08:49:42 -0800
From: bobh@unicorn.wwu.edu (Bob Hayes)
To: budd@bu-it

Well, I'll try direct mail to you, see what passes.
The scoop is that the OFFICIAL manual is from Miniscribe.
It is about $36 for the manual and the schematics for the
drive. It is a soft-cover manual, glued back, not spiral,
with BLUE (no xrox here!) cover print. Looks like about
40 double-sided pages, covering both the 9380E and 9380S
drives. Mostly the 9380E. I am having some problem geting
the drives to work on a MOtorola Delta (68030) system,
not (most likely) due to the drives, but the expectations
that the 'moto sys has. It seems that assumptions are made
about the mode set params by the moto system, and that
freezes the mini in a check unit condition. No source
for the moto formatter, of course! Grrrrrr
MiniS's 800 number --> 800 356 5333, spare parts is
ext. 2293, which may be entered touch tone.
The regular telephone is 303-651-6000. All these were
>From before the 'sale' in early April.
For mail, try bobh@unicorn.wwu.edu ---For the record,
I can't directly ftp into bu.edu to the archives, either,
>From arthur, but its OK from the unicorn, so maybe mail
will work there.
If you don't have any luck with Miniscribe, I will be happy
to help you out, but frankly it will probably be faster thru
Mini.  NB-- the manual is NOT copyright!!, but my time
is scarce!
Good luck-
Bob-


From owner-pc532%daver@mips.com Wed May  9 14:15:57 1990
Flags: 000000000000
X-Path: sibyl.eleceng.ua.oz.au!ian
From: ian@sibyl.eleceng.ua.oz.au
To: pc532@bungi.com
Subject: Re: various unresolved issues.
Date: Thu, 10 May 1990 01:48:51 +1000
References: <<9005071615.AA02112@meepmeep.pcs.com>>
Reply-To: pc532@bungi.com
Precedence: bulk

Jordan K. Hubbard writes:
 > *** On the software front: ***
 > 
 > How's Minix coming along? I can't help but (humorously) remember
 > a certain quote from Bruce in <8912081857.AA01037@hplwbc.HPL.HP.COM>
 > on Fri, 8 Dec 89 10:57:10 pst:
 > 
 > >I would guess that a one weekend effort would get Minix running on the
 > >pc-532.
 > 
 > Ah, the simple naivete of youth! :-) (just kidding Bruce, really!)

Yes. Then there were the estimates of time to port GCC to a TMS340x0
and write an X server. I usually stay quiet when people say such
things because I know *I* couldn't do it in that time! Maybe there
really are people that can code an order of magnitude faster than I,
but more likely they are underestimating the size of the job.
Apparantly the tendency to grossly underestimate the size of a
software task is a recognised failing of the whole profession!

 > I really think it's time that we starting thinking in a more "consortium"
 > like fashion on the Unix front. I realize that many of us have different
 > goals and ideas about which Unix would be "best", but there's still
 > a whole lot of common work that can be shared and ideas that can be exchanged.
 > I, for example, am working on porting 4.3 and am currently going through
 > the painful first steps of getting stand-alone versions of mkfs/fsck and
 > friends working as I proceed towards getting a root file system w/simple
 > stand-alone kernel booted up.

I would be very interested in this. Whilst one still needs a AT&T
licence for BSD, the amount of code which has been freed has been
increased. My guess is that the machine dependent stuff would be under
the freed category (AT&T didn't have anything to do with the BSD VM
system for example). You should still be able to make diffs available
for any files still restricted. What are you using as the starting
point? The Tahoe release?

 > Lest I be accused of being all talk and no action, I'm willing to
 > set up and coordinate all this myself if no one else steps forward. We
 > (software developers) really have quite a massive amount of work ahead of
 > us and could reap significant benefits from each others work, if only
 > someone would take the time to properly coordinate it (having everyone
 > think more in terms of writing "building blocks" rather than quick
 > just-make-it-work hacks would also be a major boon).

I have a major aversion to reinventing wheels. I did a lot of work on
the gnu stuff and lo and behold, it seems that others were also
working on the same thing. (I have been using GCC for a long time on
my ICM, but the gas and binutils work was motivated primarilly by the
pc532).

So, I think we need a list of tasks and who is working on them. The
tasks don't have to be universally agreed. If you want to work on a
foobar that no one else wants, then who are we to say don't? But, at
least register the fact that you are working on foobar just in case
someone else decides to do the same. The list of tasks would, I
expect, have some entries with no one assigned to them and anyone who
feels so motivated might pick up some of these.

 > Are 90% of us just
 > sitting around staring owlishly at our boards, or what? Some of us have
 > had working boards for months ...

I wish I did! Parts supply is a problem here in the backwaters.

Just to kick off, I am happy to continue to maintain (and merge in
anyone elses bug-fixes and enhancements) the ports of the gnu tools.
I don't expect to have a lot of time to devote in the next 5 months
or so (a thesis to be done) but I am interested in getting the GDB
remote debugging support working and added to the ROM monitor. I am
currently hampered by not having a complete board, but that should
cease to be a problem soon.

	Software Task					Workers 	Status
        -------------					-------		------
	GCC Port					     ID	       Working
	GDB Port					     ID	       Working
        GDB Remote debugging support			     ID	   Not started
            GDB has support for remote debugging over
	    a serial line.  It requires some code at
	    the remote end.  The standard GNU
	    distribution only has such code for a 68K.
	    Equivalent code for the 32k needs to be
	    developed.
	GDB Support for Cross Debugging			     *
	    GDB does not support reading symbolic
	    information from little endian
	    executables on a big endian machine. This
	    is desirable in a cross development
	    environment.
	GAS Port					    ID	     Working
	GNU LD and other Binutils Port			    ID	     Working
	GNU AR Cross Development Support		     *
	    AR does not support reading symbolic
	    information from little endian
	    object files on a big endian machine. This
	    is desirable in a cross development
	    environment.
	GNU RANLIB Cross Development Support		     *
	    RANLIB does not support reading symbolic
	    information from little endian
	    object files on a big endian machine. This
	    is desirable in a cross development
	    environment.
	GNU NM Cross Development Support		     *
	    NM does not support reading symbolic
	    information from little endian object
	    files and executables on a big endian
	    machine. This is desirable in a cross
	    development environment.
	GNU STRIP Cross Development Support		    *
	    STRIP does not support reading symbolic
	    information from little endian
	    execuatbles on a big endian machine. This
	    is desirable in a cross development
	    environment.

It would be an ideal thing for emacs outline mode. The organisation
of the above could be improved no doubt. It would probably be good to
have a section for each program or package of interrelated programs
and make the Software Tasks subsection.  Maybe as well as a list of
workers for each task we need a coodinator for each package, but
appointing one might be too bureaucratic.  I'd suggest a key matching
initials with email address at the end of the list.  The '*' is used
to indicate no one has registered that they are working on it. I
think someone *has* done at least some of the cross development stuff
but I am not sure who. The simplest thing is probably to leave
coordination on a single package up to those working on it. If you
maintain such a list at least we will *know* who are working on it. I
would appreciate any changes to the GNU tools (especially if they are
based on my patches, reported back to me).

Ian Dall


From owner-pc532%daver@mips.com Wed May  9 14:17:47 1990
Flags: 000000000000
X-Path: sibyl.eleceng.ua.oz.au!ian
From: ian@sibyl.eleceng.ua.oz.au
To: pc532@bungi.com
Subject: The great assembler syntax debate.
Date: Thu, 10 May 1990 02:09:45 +1000
Reply-To: pc532@bungi.com
Precedence: bulk

I invited discussion sometime ago on assembler syntax. There is no
really clear concensus except that most people seem to agree with me
that the original gas syntax sux.

The only question is whether to adopt the NS SysV syntax. A couple of
people suggested this but there was no concensus and so the simplest
thing is to leave it like it is.  Also the current syntax is
compatable with Bruce Culbertson's assembler.

The gas uses '|' as a "line comment" character. This is silly as it
means you can't have expressions with logical "or" in them. Since
there is no longer any need for a '#' character to mean "immediate
mode", '#' can be used as the comment character everywhere. These
changes are trivial and I haven't updated the gas patches as I am
waiting until I have perfected(*) a shell/sed script to convert Bruce's
assembler syntax to gas assembler syntax.

Whilst, gas has compatable opcodes and addressing mode syntax to
Bruce's assembler, thhe comment character is different and the pseudo
ops need some work.

Ian Dall

* Possibly not doable with sed when you take things like the
  possibility of comment characters within strings. It seems to be
  pretty good in practice though.


From owner-pc532%daver@mips.com Wed May  9 15:05:49 1990
Flags: 000000000000
X-Path: news
From: vonb@iitmax.IIT.EDU (bob von borstel)
To: xm-pc532@daver.bungi.com
Subject: u532 parts option
Keywords: u532 parts
Date: 9 May 90 14:12:50 GMT
Reply-To: pc532@bungi.com
Organization: Illinois Institute of Technology
Precedence: bulk

As our 532-pc project here requires largely self-generated :) income to
build, we have 4 extra NS532 Designer's Kits for sale.  Each kit consists
of a 25 or 30 MHz U532 (B3/10), PGA socket, 32202N-10 chip and a few other items
that you may or may not find useful. Also included is a Series 32K Programmers
Reference Manual.  Basically you're getting the chips at a good deal, with a
few other goodies thrown in.    
 
The cost per kit is $225.00 + $10 (ups domestic surface shipping).  Please
specify which speed you want 25mhz or 30mhz.  Again, we only have 4 of these 
kits, so FIFO order will rule.

-------------------------------------------------------------
Robert Von Borstel / Illinois Institute of Technology - ACC  
10 West 31st Street,  Chicago, Il   60616
INTERNET:  vonb@iitmax.iit.edu       BITNET:  sysbvb@iitvax

-- 

Robert Von Borstel / Illinois Institute of Technology - ACC  / (312) 567-5962
  10 West 31st Street,  Chicago, Il   60616
INTERNET:  vonb@iitmax.iit.edu       BITNET:  sysbvb@iitvax

From owner-pc532%daver@mips.com Thu May 10 08:10:15 1990
Flags: 000000000000
X-Path: eleazar.dartmouth.edu!stevel
From: stevel@eleazar.dartmouth.edu (Steve Ligett)
To: pc532@bungi.com
Subject: parts...
Date: Thu, 10 May 90 06:59:52 -0400
Reply-To: pc532@bungi.com
Precedence: bulk

Hmmm - now that folks are getting boards, there seems to be more interest
in parts!  I'm in Boston this week (the "big city" to us country folk), and
can't handle replying to all the mail @ 2400 bps.  I'll be talking to the
parts distributors this week (they're all having parties for Electro...)
and will have the final, revised, improved price list.

Dave has gotten a quote from NSC on the CPU, FPU, ICU; I'll be using that
to get the best prices for those chips.

And now a short message from my 4-year old (he loves this mac portable):

klbnj vf  NIKI

So, I'll be posting a final list of prices next week, and will reply to
all who have written for parts, next week.

Steve

From owner-pc532%daver@mips.com Fri May 11 04:32:58 1990
Flags: 000000000000
X-Path: news
From: bpdsun1!dwg (David W. Glessner)
To: xm-pc532@daver.bungi.com
Subject: Re: pc532 board caps
Summary: Tantalums may be *BAD*
Date: 10 May 90 19:42:18 GMT
References: <<m0hSZRj-0000n6C@vw25.chips.com>>
Reply-To: pc532@bungi.com
Organization: Harris Broadcast Div., Quincy, IL
Precedence: bulk

In article <m0hSZRj-0000n6C@vw25.chips.com> gs@vw25.chips.com (George Scolaro) writes:
>[In the message entitled "pc532 board caps" on May  8, 10:16, Jon Buller writes:]
>> Can someone tell me if the caps labeled tantalum on the silk screen
>> page really need to be tantalum caps?
>Yes they do. Tantalum caps have larger values than ceramics or monolithics.

I assume that the tantalums are hung between the power rails in the PC532.

According to one of our components engineers:

  "Tantalum capacitors have a catastrophic failure mode that is
  frequently overlooked in the course of a design.  A series resistance
  of 'three ohms per applied volt' in series with the tantalum is a must
  to avoid its destruction.  The sometimes fiery nature of the failure is
  also a hazard to surrounding components and the circuit board."

The recommendation references MIL-217E, which predicts an INFINITE failure
rate as the series resistance approaches zero ohms.

He continues:

  "In 1974 MIL-217B rated a simple 100uF, 20V tantalum 3:1 more reliable
  than an equivalent rated/quality aluminum electrolytic.  In 1986
  MIL-217E evaluates the same two caps and finds the aluminum
  electrolytic more reliable by 25:1 or better.  This is a major shift in
  reliability and should be of interest for new designs.  My observation
  is also that the new aluminum electrolytics now offered nearly match
  the tantalum's small size for capacity/volt equivalence."

--
David
NET:	quintro!bpdsun1!dwg@lll-winken.llnl.gov
	uunet!tiamat!quintro!bpdsun1!dwg

From owner-pc532%daver@mips.com Sat May 12 07:14:54 1990
Flags: 000000000000
X-Path: uunet!virtech!rickr
From: Rick Rodman <rickr%virtech%uunet@daver>
To: pc532@bungi.com
Subject: Re: The great assembler syntax debate.
Date: Fri, 11 May 90 20:35:02 EDT
References: <<9005091642.29687@munnari.oz.au>>
Reply-To: pc532@bungi.com
Precedence: bulk

> The only question is whether to adopt the NS SysV syntax. A couple of
> people suggested this but there was no concensus and so the simplest
> thing is to leave it like it is.  Also the current syntax is
> compatable with Bruce Culbertson's assembler.

I dislike Bruce's default mode of "immediate", but I can live with it.
We have to avoid ambiguities, such as in the CP/M-86 assembler.

> The gas uses '|' as a "line comment" character. This is silly as it
> means you can't have expressions with logical "or" in them. Since
> there is no longer any need for a '#' character to mean "immediate
> mode", '#' can be used as the comment character everywhere. These

ECHH!  Talk about confusing!  People have been using '#' for immediate mode
for 20 years or so!  The LEAST Bruce could do is to ALLOW the stupid
octothorpe.  But no, no one believes in syntax flexibility.

What in the world is wrong with using a semicolon?

If there is something wrong with a semicolon, then use two hyphens or two
periods.

> Whilst, gas has compatable opcodes and addressing mode syntax to
> Bruce's assembler, thhe comment character is different and the pseudo
> ops need some work.

I haven't used "gas".  What's wrong with Bruce's assembler?  Why do we
need gas?


From owner-pc532%daver@mips.com Sat May 12 07:14:57 1990
Flags: 000000000000
X-Path: uunet!virtech!rickr
From: Rick Rodman <rickr%virtech%uunet@daver>
To: pc532@bungi.com
Subject: Re: pc532 parts
Date: Fri, 11 May 90 20:48:39 EDT
References: <<1523703@mac.Dartmouth.EDU>>
Reply-To: pc532@bungi.com
Precedence: bulk


> Ok, now I'm a month late.  I'll be in Boston this week, at Electro.  I'll be
> giving distributors the final list of parts we want to buy.  Please send your
> orders to 
> 
> pc532-parts@dartmouth.edu

'elm' doesn't like at-signs in addresses - in fact I can't even type one
in in vi! what kind of cuckoo system is this anyhow?

So I hope you can get this message, darn it!  (The only thing I like about
Unix is that it's better than all the other machine-independent portable
operating systems... :-} )

> Include your name, address, address, etc, as Dave said for board orders.

Richard Rodman, 8329 Ivy Glen Court, Manassas VA 22110-4631
Richard Rodman, 8329 Ivy Glen Court, Manassas VA 22110-4631
Richard Rodman, 8329 Ivy Glen Court, Manassas VA 22110-4631
	Oh, and
Richard Rodman, 8329 Ivy Glen Court, Manassas VA 22110-4631

Home phone 703-330-9849.  uunet!virtech!rickr.

> thanks

You're welcome!


From owner-pc532%daver@mips.com Sat May 12 08:42:07 1990
Flags: 000000000000
X-Path: hopf.math.purdue.edu!wilker
From: wilker@hopf.math.purdue.edu (Clarence Wilkerson)
To: pc532@bungi.com
Subject: Re: The great assembler syntax debate.
Date: Sat, 12 May 90 06:24:54 EST
Reply-To: pc532@bungi.com
Precedence: bulk

I think the point is that gas ( or as) was not designed for human written
code of any quantity. Therefore its pseudo-ops facitlities are primitive,
because no one used it enough to complain enough to cause any changes.

From ames!mips!daver!owner-pc532@XN.LL.MIT.EDU Sat May 12 15:28:38 1990
Flags: 000000000001
Posted-Date: Sat, 12 May 1990 15:14:50 +1000
X-Path: sibyl.eleceng.ua.oz.au!ian
From: ames!mips!sibyl.eleceng.ua.oz.au!ian@XN.LL.MIT.EDU
To: mips!bungi.com!pc532
Subject: Re: pc532 board caps
Date: Sat, 12 May 1990 15:14:50 +1000
References: <<1990May10.194218.0@bpdsun1.uucp>>
Reply-To: ames!mips!bungi.com!pc532@XN.LL.MIT.EDU
Precedence: bulk

David W. Glessner writes:
 >   "Tantalum capacitors have a catastrophic failure mode that is
 >   frequently overlooked in the course of a design.  A series resistance
 >   of 'three ohms per applied volt' in series with the tantalum is a must
 >   to avoid its destruction.  The sometimes fiery nature of the failure is
 >   also a hazard to surrounding components and the circuit board."
 >
 > The recommendation references MIL-217E, which predicts an INFINITE failure
 > rate as the series resistance approaches zero ohms.

Essentially to limit the charging current and possibly the discharge
current. This can also be limited by the rate of change of voltage of
the power supply. My power supply is specified to ramp up over 100ms.
The 5 volt supply changes at 50V/s, or a current of 50 * C into each
capacitor. "Three ohms per applied volt", results in a current limit
of 1/3 amps into each capacitor. For typical values of capacitance 50
* C << 1/3 so there is not a problem. Your power supply my differ, but
it is still not going to have and infinite dv/dt.

I think there is only likely to be a problem if you put a switch between
the board and the supply. This would be even more likely to be a problem
if the power supply was something like a lead acid battery. Adding a series
resistor would seriously limit the decoupling ability of the capacitor and
a more practical approach would be to limit the start up current surge
>From the power supply.

                    R
    +------------/\/\/\/\/---------------+
    |                         |          |
    -                       + |     +--------+
   ---                   C  -----   |  Load  |
    -                       -----   +--------+
   ---                      - |          |
    |                         |          |
    +------------------------------------+


Ian Dall


From ames!mips!daver!owner-pc532@XN.LL.MIT.EDU Sat May 12 16:28:46 1990
Flags: 000000000000
Posted-Date: Sat, 12 May 1990 12:44:59 PDT
X-Path: dlr
From: ames!mips!daver.bungi.com!dlr@XN.LL.MIT.EDU (Dave Rand)
To: mips!bungi.com!pc532
Subject: Re: pc532 board caps
Date: Sat, 12 May 1990 12:44:59 PDT
Reply-To: ames!mips!bungi.com!pc532@XN.LL.MIT.EDU
Precedence: bulk

[In the message entitled "Re: pc532 board caps" on May 12, 15:14, ian@sibyl.eleceng.ua.oz.au writes:]
[deleted]
> if the power supply was something like a lead acid battery. Adding a series
> resistor would seriously limit the decoupling ability of the capacitor and
> a more practical approach would be to limit the start up current surge
> from the power supply.
> 
>                     R
>     +------------/\/\/\/\/---------------+
>     |                         |          |
>     -                       + |     +--------+
>    ---                   C  -----   |  Load  |
>     -                       -----   +--------+
>    ---                      - |          |
>     |                         |          |
>     +------------------------------------+
> 

This DOES show a failure mode of Tantalum caps that I am familiar with.
Hooking up the capacitor backwords certainly does cause them to explode :-)



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

From owner-pc532%daver@mips.com Sun May 13 22:39:28 1990
Flags: 000000000000
X-Path: news
From: upl@gumby.cs.wisc.edu (Undergrad Projects Lab)
To: xm-pc532@daver.bungi.com
Subject: pc523 parts and other meanderings
Date: 13 May 90 23:03:50 GMT
Reply-To: pc532@bungi.com
Organization: U of Wisconsin CS Dept Undergraduate Projects Lab
Precedence: bulk


	Greeting to all pc532 people.  I recently received my board, and
am quite impressed with the design.  A number of points/questions follow:

	0.)  Now that we've in comp.nsc.32k, should I post to the
	newsgroup, not the mailing list?  Can everyone get to this
	groups?

	1.)  I would like to get in on the parts buy.  However, all mail to
	Dartmouth seems to be bouncing (Excuse the waste of bandwidth) My
	name and address:

	Greg Thain // 511 West Johnson 206 // Madison WI 53703 (608) 251-1874
	greg@uhura.cs.wisc.edu


	2.)  I called National to ask about parts.  Their response: we give
	out samples of all our products to students.  My reply: Samples?  You
	mean _free samples_?  Them: Sure: How many 32532s do you want?
	I was somewhat curious about this deal, and sure enough, they called
	back later, and said that although the policy is still in effect,
	they are out of stock of this product, and will ship it to me after the
	next production run, which has been indefinetely postponed. I'm not
	holding my breath.  It seems like they may never have another production
	run, given their current market.  Any thoughts?  Doesn't Encore buy a
	fair number of 532s for their Multimax?  They wouldn't _really_ give
	away several $1k chipsets, would they?
	
	3.)  Most people have said that their board build went smoothly.  Any 
	clues/hints for the junior builder?  I have access to a wave solderer,
	should I use it, or do it by hand instead?  Socket everything, or
	just the important ICs?


Greg Thain
greg@uhura.cs.wisc.edu

From owner-pc532%daver@mips.com Sun May 13 23:36: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: The great assembler syntax debate.
Date: Sun, 13 May 1990 12:25:44 +1000
References: <<9005120035.AA17951@virtech.UUCP>>
Reply-To: pc532@bungi.com
Precedence: bulk

Rick Rodman writes:
 > > The gas uses '|' as a "line comment" character. This is silly as it
 > > means you can't have expressions with logical "or" in them. Since
 > > there is no longer any need for a '#' character to mean "immediate
 > > mode", '#' can be used as the comment character everywhere. These
 > 
 > ECHH!  Talk about confusing!  People have been using '#' for immediate mode
 > for 20 years or so!

It is not possible to allow *all* the syntax variations that people
have been using over the last 20 years as they conflict! '#' for
comment seems pretty common for BSD assemblers.

 > The LEAST Bruce could do is to ALLOW the stupid
 > octothorpe.  But no, no one believes in syntax flexibility.

I don't speak for Bruce.

 > What in the world is wrong with using a semicolon?

A semicolon is used by gas to seperate multiple assembler instructions on
one line. This is useful in "asm" statements.

 > I haven't used "gas".  What's wrong with Bruce's assembler?  Why do we
 > need gas?

You don't *need* gas. Gas and the gnu loader support symbolic
debugging.  (And gdb is an excellent debugger).  This for me is a
major win. The FSF code has more people working on it and making
improvements and bug fixes etc. I want to be able to take advantage of
that effort. For example, I haven't tried yet, but it should be much
easier to get g++ working using the gnu assembler and loader than with
anything else. Also I am trying to minimise the changes to gcc needed
so as to minimise the effort of merging in new releases. Using GAS
seems to me the best way to do that.

My patches to gcc make it relatively easy to change the characters
used by gcc addressing modes if you really want to. It is likewise
fairly easy to change gas. I don't especially recommend it though.
You must have missed out on the original assembler syntax debate.
Everyone has their favorites, but as I said, there was no concensus
about the need for any changes.

Ian Dall


From owner-pc532%daver@mips.com Mon May 14 04:27:47 1990
Flags: 000000000000
X-Path: pyramid!pcsbst.pcs.com!meepmeep.pcs.com!jkh
From: jkh@meepmeep.pcs.com (Jordan K. Hubbard)
To: pc532%daver%pc532@pyramid
Subject: re: the great assembler syntax debate
Date: 14 May 90 08:16:39 MSZ (Mon)
Reply-To: pc532@bungi.com
Precedence: bulk

>I dislike Bruce's default mode of "immediate", but I can live with it.
>We have to avoid ambiguities, such as in the CP/M-86 assembler.

I suppose. I kind of don't like having (pc) be necessary in places
where it is clearly implied. An example would be the legal NS syntax
op "casew L123 [r0:w]" which would only be digested as "casew L123(pc) [r0:w]"
in Bruce's assembler. I find this vaguely bothersome.

Another problem with Bruce's assembler that may or may not be a problem
of the syntax is that statements like:

foo(parm)
char *parm;
{
	static int bar[100];
	int foo = strlen(parm);

	...
}

Barf because the static causes a ".bss" op to be generated, but the
"strlen(parm)" wants to be in the text segment. I really don't know
where the bug is here, but it's bitten me a few times.

On the general gcc front, I've migrated Bruce's changes into gcc 1.37.1
and reserved the name "pc532-bc" in the config.gcc file. Since Bruce
uses completely separate tm-wbc.h, xm-wbc.h, out-wbc.c and wbc.md files,
we should be able to merge Ian's changes in for a completely copacetic
"either/or" environment. Being in Germany (and not wanting to waste
expensive bandwidth), I'm a little uncertain as to how to proceed with
the patches. Should I merge in Ian's and make one big patch file
relative to a vanilla 1.37.1 dist, or should I just release the diffs to
what I have for Bruce's stuff and assume than Ian's won't conflict? I'm
not even sure I have Ian's most recent changes. I'm open to suggestions.

						Jordan

P.S. I found a rather dumb error in the standalone fread() routine
last night. It doesn't return the number of bytes read. Sigh. Please
insert a "return i" at the appropriate place in file.c [end of fread()].


From ames!mips!daver!owner-pc532@XN.LL.MIT.EDU Sat May 12 15:31:29 1990
Flags: 000000000000
Posted-Date: Sun, 13 May 1990 00:21:31 +1000
X-Path: sibyl.eleceng.ua.oz.au!ian
From: ames!mips!sibyl.eleceng.ua.oz.au!ian@XN.LL.MIT.EDU
To: mips!bungi.com!pc532
Subject: Building the monitor with gcc/gas/gld
Date: Sun, 13 May 1990 00:21:31 +1000
References: <<9005082200.AA03312@hplwbc.HPL.HP.COM>>
Reply-To: ames!mips!bungi.com!pc532@XN.LL.MIT.EDU
Precedence: bulk

Bruce Culbertson writes:
 > The monitor knows that the data segment is placed in the a.out file
 > starting at the next disk block after the end of the text segment.
 > The text segment and the data segment are copied, without changing
 > their relative positions, from the a.out file to the ROM.
 > ...
 > I lied about one thing above.  The data segment is currently page
 > (not block) aligned in the a.out file.  I never noticed this mistake
 > because on the 32016 both the page size and block size were 1K.
 > I'll fix this soon and post a cdiff for the linker.

The GNU ld rounds up _etext. Futher the rounding is dependent on whether
you use a.out or coff-encapsulated a.out format. I changed init532.c so
that DATARND defaults to whatever it used to be but can be set from the
make file. I also had to change one definition in debugger.h to prevent
a warning from gcc about redefining something.

I changed the Makefile so that it concatenates the output of extractt
and extractd (I have Jon Loeliger's patches applied). I figure that
you only want the information about where things are in the executable
file to reside in one place, rather than have magic numbers in a dd
command.

Finally I wrote a shell script which attempts to emulate Bruce's
assembler by feeding his *.s files through sed and gas. This works
although I recognize that it is not capable of dealing with fully
general input.

The following tar'd, compressed and btoa'd data contains new versions
of the above mentioned files.

Disclaimer:
  I think this works but I are still unable to actually test it on a
  pc532.

Ian Dall

From owner-pc532%daver@mips.com Mon May 14 14:30:37 1990
Flags: 000000000000
X-Path: hplwbc.hpl.hp.com!culberts
From: Bruce Culbertson <culberts@hplwbc.hpl.hp.com>
To: pc532@bungi.com
Subject: Re: The great assembler syntax debate.
Date: Mon, 14 May 90 09:09:28 pdt
Reply-To: pc532@bungi.com
Precedence: bulk

> Talk about confusing!  People have been using '#' for immediate mode
> for 20 years or so!  The LEAST Bruce could do is to ALLOW the stupid
> octothorpe.  But no, no one believes in syntax flexibility.

People may have been using '#' on the computers you have been
using, but other computers have followed other conventions.  I, for
one, have infrequently used small computers and am not familiar with
what MS/DOS and CP/M do.

I am not opposed to allowing the '#'.  To make my assembler more
flexible, I already have a lot of this sort of thing.  For example,
it accepts ".program" (compatible with National) or ".text" (compatible
with GNU).  I am starting to notice a problem, though.  I have not
chosen a "preferred" syntax for writing new code and, consequently,
I sometimes type ".text" and sometimes I type ".program".  The result
is that the code I write is compatible with no assemblers except my
own.  This can usually be fixed with a simple sed script, but is
annoying.

The best solution is to use a high level language.  Once your
compiler and assembler play together, the assembler syntax issues
don't seem so important.

Bruce

From owner-pc532%daver@mips.com Mon May 14 14:32:13 1990
Flags: 000000000000
X-Path: mac.dartmouth.edu!Steven.D.Ligett
From: Steven.D.Ligett@mac.dartmouth.edu
To: pc532@bungi.com
Subject: collage board (was Re:  various unresolved issues.)
Date: 14 May 90 09:41:40
Reply-To: pc532@bungi.com
Precedence: bulk

--- Bruce Culbertson <culberts@hplwbc.hpl.hp.com> wrote:
Oh well, I knew at the time that was a dumb thing to say.  It's
always better to do something and then say you did it.
...
Those UART's
are a pain in the arse to use -- I wasted a lot of time getting
the TTY task working.
--- end of quoted material ---
Bruce - I know how you feel, after working on organizing parts kits.

Um, I thought Dave said that those UARTs were chosen because the
8250-type were a pain in the arse to use?  (Or maybe it was the 
16450-type are a pain...?)

I've been thinking of what's needed in a collage board.  Since there 
aren't many slots, it'd be nice to have a board that crams a lot of
things on it (disagreements welcome).  Here are things I've thought
of:

video - resolution, etc to be fought over
keyboard port
mouse port
floppy

I might also want AppleBus (now called LocalTalk), but many probably
don't want that.

And serial ports! Don't we need some serial ports? :-)

What do you want??

From owner-pc532%daver@mips.com Mon May 14 14:34:09 1990
Flags: 000000000000
X-Path: hplwbc.hpl.hp.com!culberts
From: Bruce Culbertson <culberts@hplwbc.hpl.hp.com>
To: pc532@bungi.com
Subject: re: the great assembler syntax debate
Date: Mon, 14 May 90 10:17:30 pdt
Reply-To: pc532@bungi.com
Precedence: bulk

Jordan writes:

> Another problem with Bruce's assembler that may or may not be a problem
> of the syntax is that statements like:
> 
> foo(parm)
> char *parm;
> {
>	static int bar[100];
>	int foo = strlen(parm);
>
>	...
> }
>
> Barf because the static causes a ".bss" op to be generated, but the
> "strlen(parm)" wants to be in the text segment. I really don't know
> where the bug is here, but it's bitten me a few times.

This seems to work fine on my system.  I did choose to implement a
BSS segment rather than a Fortran common area.

> Since Bruce
> uses completely separate tm-wbc.h, xm-wbc.h, out-wbc.c and wbc.md files,
> we should be able to merge Ian's changes in for a completely copacetic
> "either/or" environment.

My tm-wbc.h #include's the standard tm-ns32k.h and then redefines
some things.  My wbc.md file is the standard ns32k.md with a few small
changes which I could not fix externally to the file.

Bruce

From owner-pc532%daver@mips.com Mon May 14 14:59:46 1990
Flags: 000000000000
X-Path: bu-it.BU.EDU!budd
From: budd@bu-it (Phil Budne)
To: pc532@bungi.com
Subject: Re:  collage board (was Re:  various unresolved issues.)
Date:  Mon, 14 May 90 14:48:54 EDT
Reply-To: pc532@bungi.com
Precedence: bulk

	From: Steven.D.Ligett@mac.dartmouth.edu
	To: pc532@bungi.com
	Date: 14 May 90 09:41:40

	...

	I might also want AppleBus (now called LocalTalk), but many probably
	don't want that.

	And serial ports! Don't we need some serial ports? :-)

Yes. Some Zilog SCC's.  Good for LocalTalk, HDLC, Packet Radio...


From owner-pc532%daver@mips.com Mon May 14 20:41:14 1990
Flags: 000000000000
X-Path: wimsey.bc.ca!tacitus!virgil!tbr
From: tbr%virgil%tacitus%van-bc%uunet@daver (Tom Rushworth)
To: pc532@bungi.com
Subject: Re:  collage board
Date: Mon, 14 May 90 16:24:52 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

--- Steven Ligett <mac.dartmouth.edu!Steven.D.Ligett> wrote:
	video - resolution, etc to be fought over
	keyboard port
	mouse port
	floppy

	I might also want AppleBus (now called LocalTalk), but many probably
	don't want that.
--- end of quoted material ---

How about a parallel port? Also some of us don't need the 16 serial ports
on the et532, but want the ethernet.
---
Tom Rushworth           tbr@tfic.bc.ca


From owner-pc532%daver@mips.com Tue May 15 00:47:51 1990
Flags: 000000000000
X-Path: uunet!virtech!rickr
From: Rick Rodman <rickr%virtech%uunet@daver>
To: pc532@bungi.com
Subject: Re: The great assembler syntax debate.
Date: Mon, 14 May 90 21:55:21 EDT
References: <<9005141609.AA05810@hplwbc.HPL.HP.COM>>
Reply-To: pc532@bungi.com
Precedence: bulk


> > Talk about confusing!  People have been using '#' for immediate mode
> > for 20 years or so!  The LEAST Bruce could do is to ALLOW the stupid
> > octothorpe.  But no, no one believes in syntax flexibility.
> 
> People may have been using '#' on the computers you have been
> using, but other computers have followed other conventions.  I, for
> one, have infrequently used small computers and am not familiar with
> what MS/DOS and CP/M do.

The # is not used under MS/DOS and CP/M, they have worse conventions like
using immediate mode if the *label* (not the instruction that accesses it)
had or did not have a colon.  (ECHH).  The # is used in the PDP-11 and other
machines that imitate it like the 68000, the VAX, the... um...

> I am not opposed to allowing the '#'.  To make my assembler more
> flexible, I already have a lot of this sort of thing.  For example,
> it accepts ".program" (compatible with National) or ".text" (compatible
> with GNU).  I am starting to notice a problem, though.  I have not
> chosen a "preferred" syntax for writing new code and, consequently,
> I sometimes type ".text" and sometimes I type ".program".  The result
> is that the code I write is compatible with no assemblers except my
> own.  This can usually be fixed with a simple sed script, but is
> annoying.

ARGH, that problem hadn't even occurred to me.  Maybe command line
switches could be used to test for compatibility?  :-)

> The best solution is to use a high level language.  Once your
> compiler and assembler play together, the assembler syntax issues
> don't seem so important.

I agree with that.  However, you all ought to give some thought to how
people can get these systems up.  I for one do not presently have access
to a Unix machine other than an ancient Zilog system and dialup access
to Virtech.  If you distribute your monitor in source form in mixed C and
assembler, then I have to compile the C code with Phil Prendeville's C.
I am using your assembler, but (I suspect) an older version, presently
running under MS-DOS.  I plan to move the whole k&k to OS/2 shortly
(time permitting).

At work I have GCC running on VAX/VMS.  (In my opinion, an excellent
compiler, although not written to be ported or maintained.)  However,
I have run across so many "standard C" programs littered with Unixoid
assumptions about their environment that I no longer consider C, as
practised, a portable language.

An example:  If you write system(), it may be portable.  But if you
write execvp(), forget it.  Environment variables are another insidious
practice.  Unix is a fine OS - I just don't want to be locked into
it *either*.  You're right, these are not really *C* issues.  Enough
tirade.

Let me take this opportunity to tell you that your assembler and linker
are an excellent piece of work.  Very fast, bug-free, easy to port,
well-commented, straightforward, etc.  Good job!

Rick


From owner-pc532%daver@mips.com Tue May 15 00:48:43 1990
Flags: 000000000000
X-Path: uunet!virtech!rickr
From: Rick Rodman <rickr%virtech%uunet@daver>
To: pc532@bungi.com
Subject: Re: The great assembler syntax debate.
Date: Mon, 14 May 90 22:08:09 EDT
References: <<9005131634.2537@munnari.oz.au>>
Reply-To: pc532@bungi.com
Precedence: bulk

> It is not possible to allow *all* the syntax variations that people
> have been using over the last 20 years as they conflict! '#' for
> comment seems pretty common for BSD assemblers.

Oh, that's weird.  The PDP-11 and its derivatives used # for immediate.
Following a BSD precedent seems strange.

> A semicolon is used by gas to seperate multiple assembler instructions on
> one line. This is useful in "asm" statements.

I suppose, but it's unusual.

> You don't *need* gas. Gas and the gnu loader support symbolic
> debugging.  (And gdb is an excellent debugger).  This for me is a
> major win. The FSF code has more people working on it and making
> improvements and bug fixes etc. I want to be able to take advantage of

The FSF code is also virtually uncommented, incredibly big and, in my
opinion, sloppily written.  After several days of effort spent attempting

to port GCC to a *unix* (BSD) system, I gave up.  There were 40-character
function names in there!  There were #defines that were pages long!
There were weird constructs like "enum varname : 8" which I have never
seen and don't believe to be standard.

I think the FSF people need to show a little more concern for people who
are attempting to use their code.  We use GCC at work for regular C
programming, and it seems like a good compiler.  But after seeing the
source code, I can't rate it higher than 6 out of 10.

> that effort. For example, I haven't tried yet, but it should be much
> easier to get g++ working using the gnu assembler and loader than with
> anything else.

I'll bet that's true.  But that's not necessarily good.

> Also I am trying to minimise the changes to gcc needed
> so as to minimise the effort of merging in new releases. Using GAS
> seems to me the best way to do that.

But how do I bring it up on a computer that isn't already running it?

> My patches to gcc make it relatively easy to change the characters
> used by gcc addressing modes if you really want to. It is likewise
> fairly easy to change gas. I don't especially recommend it though.
> You must have missed out on the original assembler syntax debate.

Yes, I did.

> Everyone has their favorites, but as I said, there was no concensus
> about the need for any changes.

I agree with that statement.  I just wanted to put my 2 cents in before
a vertical bar was used as a comment character!  (1c) (1c)

A good tool for making portable code should itself be portable.

From owner-pc532%daver@mips.com Tue May 15 00:49:47 1990
Flags: 000000000000
X-Path: news
From: meissner@osf.org (Michael Meissner)
To: xm-pc532@daver.bungi.com
Subject: Re: Building the monitor with gcc/gas/gld
Date: 14 May 90 22:25:08 GMT
References: <<9005082200.AA03312@hplwbc.HPL.HP.COM>>>
Reply-To: pc532@bungi.com
Organization: Open Software Foundation
Precedence: bulk

In article <9005121635.21490@munnari.oz.au> ian@sibyl.eleceng.ua.oz.au
writes:

| Bruce Culbertson writes:
|  > The monitor knows that the data segment is placed in the a.out file
|  > starting at the next disk block after the end of the text segment.
|  > The text segment and the data segment are copied, without changing
|  > their relative positions, from the a.out file to the ROM.
|  > ...
|  > I lied about one thing above.  The data segment is currently page
|  > (not block) aligned in the a.out file.  I never noticed this mistake
|  > because on the 32016 both the page size and block size were 1K.
|  > I'll fix this soon and post a cdiff for the linker.
| 
| The GNU ld rounds up _etext. Futher the rounding is dependent on whether
| you use a.out or coff-encapsulated a.out format. I changed init532.c so
| that DATARND defaults to whatever it used to be but can be set from the
| make file. I also had to change one definition in debugger.h to prevent
| a warning from gcc about redefining something.
| 
| I changed the Makefile so that it concatenates the output of extractt
| and extractd (I have Jon Loeliger's patches applied). I figure that
| you only want the information about where things are in the executable
| file to reside in one place, rather than have magic numbers in a dd
| command.
| 
| Finally I wrote a shell script which attempts to emulate Bruce's
| assembler by feeding his *.s files through sed and gas. This works
| although I recognize that it is not capable of dealing with fully
| general input.

One thing that we just found as OSF, is that in general, it is not a
good idea for the kernel to use the static base register.  I was never
able to get the details straight, on why the interrupt handler
couldn't just save and restore the static base register, but the
kernel gurus assured me that the compiler should have a switch to
never use the static base register.

So I rolled up my sleves, and did some poking around GCC.  It turns
out that it does not use the static base register directly, but it
does use it indirectly, particularly in code from the following:

	struct foo {
		int field1;
		int field2;
	};

	static struct foo *ptr;

	void bar(){
		ptr->field2 = 1;
	}

This produces the following code when optimized (Encore syntax):

		.file	"stdin"
	gcc_compiled.:
	.text
		.align 16
	.globl _bar
	_bar:
		enter [],0
		movqd $1,4(_ptr)
	.L1:
		exit []
		ret 0
		.bss _ptr,4,4

If you look carefully in the 32*32 manuals, you will notice that there
is no indirect through a constant address in the various memory modes.
There is indirect through the static base register + constant, which
is what the assembler turns the above movqd into.  In fact if you use
Sequent syntax, GCC will use the following line:

		movqd $1,4(_ptr(sb))

which makes it more obvious.  So I added a -mnosb switch, and mucked
with the various macros GO_IF_LEGITIMATE_ADDRESS calls to prevent such
code, and use the following sequence instead:

		.file	"stdin"
	gcc_compiled.:
	.text
		.align 16
	.globl _bar
	_bar:
		enter [],0
		movd _ptr,r0
		movqd $1,4(r0)
		exit []
		ret 0
		.bss _ptr,4,4

If people think it might be useful, I suppose I could post the
patches, though I am recovering from Mono right now, and my energy
level is not the highest.....
--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA

Catproof is an oxymoron, Childproof is nearly so

From bdale@col.hp.com Tue May 15 01:12:19 1990
Flags: 000000000000
To: budd@bu-it (Phil Budne)
Subject: Re: collage board (was Re: various unresolved issues.) 
Date: Mon, 14 May 90 23:10:30 MDT
From: Bdale Garbee <bdale@col.hp.com>

> 	I might also want AppleBus (now called LocalTalk), but many probably
> 	don't want that.

> 	And serial ports! Don't we need some serial ports? :-)

> Yes. Some Zilog SCC's.  Good for LocalTalk, HDLC, Packet Radio...

No!  Please use the NEC parts... they've got a few less quirks to deal with
than 8530's.  But, personally, I think this should be a separate card.  I'm
working with a friend who's doing 68302-based boards to do a variant of his
board that's a 68302 with ROM, DRAM, an 8530 for slow stuff, and a SCSI
interface so's we can plug it into our bus or our other SCSI-capable systems.

The 68302 can support a couple of ports running T1 rates...  It has 3 ports
onboard with DMA built in, a 68000 core, and a separate RISC processor to
handle the ports... with the external 8530, we're talking 3 fast ports and
two that will do up through at least 38400 HDLC.

Bdale

From owner-pc532%daver@mips.com Tue May 15 03:54:26 1990
Flags: 000000000000
X-Path: mips!ames!bu-it.BU.EDU!budd
From: budd@bu-it (Phil Budne)
To: bdale@col.hp.com
Subject: Re: collage board (was Re: various unresolved issues.)
Date:  Tue, 15 May 90 02:57:52 EDT
Reply-To: pc532@bungi.com
Precedence: bulk

For all its niftiness the 68302 is not able to do localtalk as
well as the 8530 SCC.  Now if Motorola would allow you access to
the communications processor.....

-Phil

From owner-pc532%daver@mips.com Tue May 15 18:05:53 1990
Flags: 000000000000
X-Path: uunet!tarpit!manatee!John.L.Connin
From: John Connin <johnc%manatee%uunet@daver>
To: pc532@daver.bungi.com
Subject: Drive enclosure follow-up..
Date: Tue, 15 May 90 13:12:51 EDT
Reply-To: pc532@bungi.com
Precedence: bulk

On May 8 I posted a message titled "Drive Enclosure".   The purpose
of this message is to followup on a question I raised and to
share some additional info.

> One modification I am thinking about is adding the ability to select
> SCSI ID's from a switch on the rear surface.  This reminds me,
> does anyone know of a simple way in which the SCSI terminator
> resistors could be 'inserted/removed' via a rear surface 
> switch ??

I decided not to implement a rear surface SCSI ID selected (eg. thumb
wheel switch).  The reason is simply that if I ever remove the drive from
the enclosure I may forget to disconnect the switch cable before 'sliding'
the drive out of the case and thus potentially damaging the drive 
circuit board.  The Miniscribe 9830S ID select pins are located on the
underside of the drive and a 2x6 header connection to the select pins 
would extend below the bottom surface of the drive.

Regarding a SCSI terminator, several people suggested that I use a
Apple, Sun, Hp, et al SCSI terminator or the likeness thereof
(ie a 50 pin male Centronics coonector with enclosed terminating resistors).

Good idea...   

I checked the local Apple store and they wanted $32.00 for the terminator.
Next I checked the Computer Shopper and found that Altex Electronics
carried them for $17.95.  In the end result I went to the local surplus 
and found some male 50 pin Centronics connectors for $2.00.  Now all I have
to do is find time to solder the resistors to the connector housing and
find a hood to enclose the mess.

For interconnection I ended up buying 6 foot male-male SCSI cables
>From JDR (ie CBL-SCSI-MM at $19.95).  Altex Electronics had some
for $11.95 but they were only 18 inches long.  JDR tech-support
assured me the cable is wired one-to-one.  I need to verify this
once the cables arrive.  Of course I could have used flat-cable
and built the cable, but with new parts the cost would have been
about the same.

One parting thought, if you decide to use a separate PC switching power 
supply to power your drives, make sure the primary output (+5VDC) has at 
least a 1 amp load (ie 5 ohms), otherwise the +12VDC may not regulate 
properly.  BTW: the April/May 1989 issue of Circuit Cellar Ink. has a
good article on swithing power supply design.

Best regards,
johnc

-- 

From harvard!ames!pyramid!pcsbst.pcs.com!meepmeep.pcs.com!jkh Wed May 16 09:52:46 1990
Flags: 000000000000
To: pyramid!bu-it.BU.EDU!budd
Subject: re: lib.shar.Z
Date: 16 May 90 10:24:59 MSZ (Wed)
From: harvard!meepmeep.pcs.com!jkh (Jordan K. Hubbard)

Great, I'll test it tonite and let you know how it works..

What's holding your pc532 up?

					Jordan

From owner-pc532%daver@mips.com Wed May 16 16:18:02 1990
Flags: 000000000000
X-Path: sibyl.eleceng.ua.oz.au!ian
From: ian@sibyl.eleceng.ua.oz.au
To: pc532@bungi.com
Subject: Re: The great assembler syntax debate.
Date: Wed, 16 May 1990 14:13:54 +1000
References: <<9005150208.AA02441@virtech.UUCP>>
Reply-To: pc532@bungi.com
Precedence: bulk

Rick Rodman writes:
 > > It is not possible to allow *all* the syntax variations that people
 > > have been using over the last 20 years as they conflict! '#' for
 > > comment seems pretty common for BSD assemblers.
 > 
 > Oh, that's weird.  The PDP-11 and its derivatives used # for immediate.
 > Following a BSD precedent seems strange.

I grew up on pdp-11's too. None the less, I have managed to adapt to
other syntax's so I am sure you can too! Since I want to use the
assembler to assemble BSD (or equivalent) code, it doesn't seem
strange to *me* to follow a BSD precedent.

 > > You don't *need* gas. Gas and the gnu loader support symbolic
 > > debugging.  (And gdb is an excellent debugger).  This for me is a
 > > major win. The FSF code has more people working on it and making
 > > improvements and bug fixes etc. I want to be able to take advantage of
 > 
 > The FSF code is also virtually uncommented, incredibly big and, in my
 > opinion, sloppily written.

Well, I agree that it could be written better, but all things
considered (*), it isn't bad. Much of the ugly code tends to be in the
compatability bits. I agree that the massive macros are a pain to
write, debug and maintain. I tended to turn them into function calls
where I had trouble.

 >  After several days of effort spent attempting
 > 
 > to port GCC to a *unix* (BSD) system, I gave up.  There were 40-character
 > function names in there!  There were #defines that were pages long!

Well, I've ported emacs, gcc, gdb, gas, binutils, fileutils, diff, tar
and fgrep to my ICM running SysV. Considering that the 32k
architecture is not terribly popular and that SysV is only half
supported, the effort required hasn't been too bad. I first put up
emacs, gdb and gcc many versions ago and that was a lot more trouble
that the more recent versions.

 > > Everyone has their favorites, but as I said, there was no concensus
 > > about the need for any changes.
 > 
 > I agree with that statement.  I just wanted to put my 2 cents in before
 > a vertical bar was used as a comment character!  (1c) (1c)

I think you misunderstand. Gas as distributed by the FSF uses the vertical
bar as the line commnet character for the 32k. I was recommending *not*
persisting with that.

 > A good tool for making portable code should itself be portable.

Yes but how portable? Much of the configuration of GCC is to do with
assembler syntax, calling conventions and symbolic debugging support.
These things are inherently non-portable. The portability problems
are reduced if you assume that everyone also uses the GNU assembler,
loader and debugger which brings me full circle...

(*) Things you could consider are how much they have done with what
    resources and for what price. Gcc, gdb and gas are inherently
    architecture dependent and OS dependent so I don't think I think
    it is unreasonable for these to require more porting effort.

    Can you think of any other free ANSII C compiler which generates
    code for a wide variety of architectures?


From owner-pc532%daver@mips.com Wed May 16 16:19:04 1990
Flags: 000000000000
X-Path: sibyl.eleceng.ua.oz.au!ian
From: ian@sibyl.eleceng.ua.oz.au
To: pc532@daver.bungi.com
Subject: Calling conventions
Date: Wed, 16 May 1990 16:14:53 +1000
Reply-To: pc532@bungi.com
Precedence: bulk

Now that I have btoa 5.2 I have unpacked Jordan Hubbards libc and
libso.  I notice that he is apparantly using a convention where R0 -
R2 inclusive are free for use in functions without saving and
restoring.

I built gcc with a convention where R0 - R3 inclusive are free for use
in functions without saving and restoring (for compatability with my
ICM library functions). These two conventions are incompatable.

Does anyone have any data (or ideas or superstitions) about what the
optimum number of registers is for this purpose? What about floating
point registers?

Ian Dall


From owner-pc532%daver@mips.com Wed May 16 16:41:16 1990
Flags: 000000000000
X-Path: col.hp.com!bdale
From: Bdale Garbee <bdale@col.hp.com>
To: pc532@daver.bungi.com
Subject: Re: How many of you have working systems? 
Date: Wed, 16 May 90 08:42:04 MDT
Reply-To: pc532@bungi.com
Precedence: bulk

Fred and I both have working systems with working disk drives.

> I'm just curious. Of that set, how many of you have also gotten any of my
> stand-alone stuff to work (pi/siod/...)? 

We got pi working easily, and in fact Fred has ported it to Minix 1.3 on the
XT, and to Turbo-C under DOS, and compared the speed.  I don't remember the
numbers offhand, but to the resolution he could measure with his sweep
second hand, the 532 was more than an order of magnitude faster than the
Minix 1.3 compile, which was over twice as fast as the TC compile on the same
AT clone.

Can't get malloc to compile with the version of gcc that I have (from Bruce
a while back), and I'm not energetic enough right now to try and bring up
a more recent gcc.  It fails with a 'parse error' in the definition of a
union.

> It just seems like I'm
> sending stuff into a black hole, so I've gotten to wondering. My
> reason for asking does have a practical side as well; I don't know if
> I should be hurrying with my new forth monitor or just taking my time (I.E.
> is there any real current demand or is it going to be several months
> before a need is perceived?).

We'd love your forth monitor sooner.  Fun toys!

Bdale

From owner-pc532%daver@mips.com Wed May 16 16:43:42 1990
Flags: 000000000000
X-Path: dlr
From: dlr@daver.bungi.com (Dave Rand)
To: pc532@bungi.com
Subject: Re: How many of you have working systems?
Date: Wed, 16 May 1990 13:13:58 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

[In the message entitled "Re: How many of you have working systems?" on May 16,  8:42, Bdale Garbee writes:]
> 
> We'd love your forth monitor sooner.  Fun toys!
> 

Me too. I enjoy working with new things, even though I don't have as
much time as I would like to spend right now :-(


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

From owner-pc532%daver@mips.com Mon May  7 11:33:38 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: various unresolved issues.
Date: 7 May 90 16:15:33 MSZ (Mon)
Reply-To: pc532@bungi.com
Precedence: bulk


I was feeling especially masochistic this weekend and decided to
re-read the entire pc532 mailing list archive. It's amazing how
many questions I've posted to this group that had already been
answered somewhere in the mists of time. Sigh. It's a pity that the "FM"
is almost 3 megabytes now or I'd have been more willing to RTFM (but that's
still no excuse, I guess).

Anyway, that's all off the subject. After reading all those messages, I
started wondering about a number of issues that seemed to have slipped
between the cracks:

*** On the hardware front: ***

Ken S. was talking about a DSP board, whatever became of that?

Is anyone working on, or planning to work on, a decent intelligent frame
buffer card? This seems like it would be a mondo priority. Given that
I'm a software type, I'm in the position of having to plead and whine
for this stuff and hope that some hardware jock gets irritated enough
to knock something out just to shut me up :-). Still, give me the hardware,
I'll give you an R4 server.

What's the story on the eth532 card? I've seen one message saying that
it supports only thin ethernet and another saying that it supports both
thin-and-thick. What's the truth, here? G&D: Have you guys done a
complete parts cost estimate yet? I want one.

*** On the software front: ***

How's Minix coming along? I can't help but (humorously) remember
a certain quote from Bruce in <8912081857.AA01037@hplwbc.HPL.HP.COM>
on Fri, 8 Dec 89 10:57:10 pst:

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

Ah, the simple naivete of youth! :-) (just kidding Bruce, really!)


I really think it's time that we starting thinking in a more "consortium"
like fashion on the Unix front. I realize that many of us have different
goals and ideas about which Unix would be "best", but there's still
a whole lot of common work that can be shared and ideas that can be exchanged.
I, for example, am working on porting 4.3 and am currently going through
the painful first steps of getting stand-alone versions of mkfs/fsck and
friends working as I proceed towards getting a root file system w/simple
stand-alone kernel booted up. This will naturally be the first step for
many others as well, regardless of the unix in question. The same commonality
will occur with the MMU code, scsi device and terminal drivers, etc etc.
If we can manage to stay in close communication (probably via private
mailing lists to avoid lots of nitty-specific issues from clogging this
list), we can arrange things so as to minimize wheel re-inventing wherever
possible. I have already attempted something along these lines with the
libso/libc libs I posted recently, though they are certainly no more than a
rough start. Lest I be accused of being all talk and no action, I'm willing to
set up and coordinate all this myself if no one else steps forward. We
(software developers) really have quite a massive amount of work ahead of
us and could reap significant benefits from each others work, if only
someone would take the time to properly coordinate it (having everyone
think more in terms of writing "building blocks" rather than quick
just-make-it-work hacks would also be a major boon). Are 90% of us just
sitting around staring owlishly at our boards, or what? Some of us have
had working boards for months and I have yet to see even one program to
pong the friggin' lights back and forth! That is a disgrace! :-)

					Jordan

From owner-pc532%daver@mips.com Wed May 16 09:39:01 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: How many of you have working systems?
Date: 16 May 90 14:33:30 MSZ (Wed)
Reply-To: pc532@bungi.com
Precedence: bulk

I'm just curious. Of that set, how many of you have also gotten any of my
stand-alone stuff to work (pi/siod/...)? It just seems like I'm
sending stuff into a black hole, so I've gotten to wondering. My
reason for asking does have a practical side as well; I don't know if
I should be hurrying with my new forth monitor or just taking my time (I.E.
is there any real current demand or is it going to be several months
before a need is perceived?).

					Jordan


From owner-pc532%daver@mips.com Wed May 16 17:43:23 1990
Flags: 000000000000
X-Path: bu-it.BU.EDU!budd
From: budd@bu-it (Phil Budne)
To: pc532@bungi.com
Subject: Re: The great assembler syntax debate.
Date:  Wed, 16 May 90 17:08:17 EDT
Reply-To: pc532@bungi.com
Precedence: bulk

Rick Rodman writes:
 > > It is not possible to allow *all* the syntax variations that people
 > > have been using over the last 20 years as they conflict! '#' for
 > > comment seems pretty common for BSD assemblers.
 > 
 > Oh, that's weird.  The PDP-11 and its derivatives used # for immediate.
 > Following a BSD precedent seems strange.

On Unix v6, v7 and 4BSD the immediate character is "$".  Its "#" in
DEC assaemblers. (* is used in place of @, so absolute addressing is
*$x rather than @#x.

-Phil

From owner-pc532%daver@mips.com Thu May 17 12:33:58 1990
Flags: 000000000000
X-Path: uunet.UU.NET!hcr!ron
From: ron%hcr@uunet.UU.NET
To: pc532@daver.bungi.com
Subject: Not a black hole
Date: Thu, 17 May 90 12:13:56 EDT
Reply-To: pc532@bungi.com
Precedence: bulk

My board is up and running!  I did have a problem with the dramem
pal, this is now fixed with a new pal from George (thanks).

Note: I have used r0-r2 as scratch registers in my compiler.  This
has worked very well.  It is very hard to use up 3 registers for
an expression on the 32000, and if you do, the C code is probably
very complex to begin with.  On the other hand it is very nice
to have 5 register variables. The 3/5 split seems to be optimal.
(I actually went through about 2 meg. of code many years ago
and found very few references to r2, I was thinking of a 2/6 split
at the time).


Detailed description of my problem:
-----------------------------------

The problem is the dramen PAL.  The cas0 equation seems to be:
	cas0	= cas & rfcyc & !qo1
		# ...
instead of:
	cas0	= cas & rfcyc
		# ...

This has the effect of turning the refresh cas0 signal into
two short pulses (~20ns).  Note that when ddin is active the
term "cas & ddinl & qo1" is met so the refresh was OK.
Thus the refresh of the LSB was bad when ddin was not active.
In other words the processor had just done a write (or in
the process of doing a write) during refresh.

I have verified the bad PAL with DC signals.  My temporary fix
is to take "cas OR rfcyc" and AND the result with the original
cas0 to produce a new cas0 (7432 & 7408).  The board seems to
work fine now.

Ron Irvine, ron@hcr.com



From owner-pc532%daver@mips.com Fri May 18 18:34:18 1990
Flags: 000000000000
X-Path: mac.dartmouth.edu!Steven.D.Ligett
From: Steven.D.Ligett@mac.dartmouth.edu
To: pc532@bungi.com
Subject: Parts kits.
Date: 18 May 90 16:03:29
Reply-To: pc532@bungi.com
Precedence: bulk

Sorry that I haven't been sending everyone interested in buying parts
asknowledgements.  Agreeing to handle parts "buffet style" has proven to be a
large amount of work.  So, I decided to break it down into managable pieces. 
First, I'm going to try to get a handle on the exact number of

CPUS, FPUS, ICUS, AND MEMORIES you want.

Here's a list of everyone that's expressed interest in parts.  If you're not
on this list, I haven't heard from you.  (Some of you may no longer want
parts.)  After each name is a string of letters: a C - if you want a Cpu, an F
- if you want an Fpu, an I ..., and an M if you want 4 1megx8 SIMMs, and a P
if you want 4 1megx9 SIMMs.  Maybe two M's or P's if I think you want 8 SIMMs. 
4Meg SIMMs - I'm told that there are no 4meg SIMMs available in 80 ns right
now (I'm checking more sources).  Other parts - I'm not worried about them
right now.  Addresses and shipping - I haven't checked all the details of that
either.  However, I would like to order these major pieces soon.  So, I'LL
ORDER THESE PARTS THE WEEK OF MAY 21.  I'd like to get these numbers right,
cuz I can lose a bundle if I order too many of any of these!

What you have to do.  If you are interested in buying any of these components,
check out the list below.  Make sure I've got you down for the right things. 
At this point I'm assuming that everyone wants 25mhz parts; so write me if you
want the 20mhz ones.  IN FACT, PLEASE WRITE TO CONFIRM OR CORRECT WHAT I HAVE
FOR YOU.  A short note with just C, F, I, M, P in the body MAY be enough,
unless I don't have your mailing address.

If I have your address, your name is preceded by a "A".  

Pricing.

Here's some new, lower prices that Dave got on the CPU, FPU, and ICU (oops, no
new prices on that yet).  Dave will notice that each of these is slightly
higher than is on his quote.  I've got to buy these through Dartmouth College,
since my credit's not this good!  Therefore, there's a few bucks added to each
price that goes to Dartmouth to pay for the paperwork.

532 u20  $490
532 u25  $560
381 v20  $ 90
381 v25  $165
202 n10  $ 24

Memories.

Right now, my best pricing is on genuine Toshiba SIMMs (70 ns parts):
1 meg x8 Toshiba thm81000as-70  $75/ea
1 meg x9 Toshiba thm91000as-70  $85/ea
(Maybe some of you want to work out the timing of using these with 30 MHZ
cpu's and 5 ns PALs.)

The list:

A brahma!bert (Bert Vincent) IM
A budd@bu-it.BU.EDU (Phil Budne) M
A frank@unix.sri.com (Victor R. Frank) M
A phil@unicorn.wwu.edu (Phil Nelson) IIMM
A haynes@ucscc.UCSC.EDU (99700000) M
  bobm@convex.com (Bob Miller) CFIP
A taylor@Think.COM (David Taylor) CFIPP
A vonb@iitmax.iit.edu  (bob von borstel) M
A uunet!ubc-cs!van-bc!tacitus!tbr (Tom Rushworth) CFIP
A FELLOWS%UNB.CA@DARTCMS1.dartmouth.edu  (David M. Fellows) CFIM
  s871943@minyos.xx.rmit.OZ.AU (Simon Burge [Snark]) C
  tdavis@zeus.unomaha.edu  (Tom Davis) M
A sequent!rjk@uunet.UU.NET (Robert Kelley) 
  jonathan@comp.vuw.ac.nz CFIM
  wilker@hopf.math.purdue.edu (Clarence Wilkerson)
A rickr%virtech%uunet@daver (Rick Rodman) M
A rutgers!pbhyf.pacbell.com!jfd (J.F. DeFay) F
A sware!hosking@uunet.UU.NET (Doug Hosking) CFIM
A wizlair!root (Robert D. Greene) P
  eyal@cancol.oz.au (Eyal Lebedinsky) P 
A ian@sibyl.eleceng.ua.oz.au (Ian Dall) 
A don@BRL.MIL (Don Merritt) FM
A garyj@neptun.pcs.com (Gary Jennejohn) CFIM
A rutgers!tc.fluke.com!dcd (David Dyck)
A nomad@hydra.convex.com (Lee Damon) M
A rutgers!vector.dallas.tx.us!jonb (Jon Buller) 
A s37814e@kaira.hut.fi (Kimmo Kivilahti)
A rutgers!csufres.csufresno.edu!csusac!unify!goshawk.mason (Mark Mason) M
A cruff@ncar.UCAR.EDU (Craig Ruff) CFIM
A rjohnson@kiwi.mpr.ca (Robbin Johnson)
A conner%empire@hp-col.col.hp.com (John Conner) CFI
A neals@tekigm2.MEN.TEK.COM (Neal Sedell)
  neil@skatter.USask.ca (Neil Johnson)

Oh, I just thought of one more thing - payment.  I'm assuming that
my bank will ok me for VISA/MASTERCARD.  That will be my preferred
form of payment.  I'll be talking with Dave and my brother (who sells
software out of the states) about the details of getting things out
of the USA.

From owner-pc532%daver@mips.com Sat May 19 03:28:50 1990
Flags: 000000000000
X-Path: mac.dartmouth.edu!Steven.D.Ligett
From: Steven.D.Ligett@mac.dartmouth.edu
To: pc532@bungi.com
Subject: Re: Parts kits.
Date: 18 May 90 21:20:47
Reply-To: pc532@bungi.com
Precedence: bulk

--- I wrote:
I'm assuming that my bank will ok me for VISA/MASTERCARD.  That will be my
preferred form of payment.
--- end of quoted material ---
Several things have occurred to me.  I didn't mean to sound like the "Ugly
American" in suggesting plastic as the preferred form of payment.  It may have
been naive of me to suggest it.  The ads I see lead me to believe that
everyone everywhere carries a VISA card.  Really, bars of gold are acceptable
:-)

But the important thing I forgot was an email address.  I've been directing
PC532 parts mail to 

pc532-parts@dartmouth.edu  or
... dartvax!u2!stevel
(I no longer remember the list of backbone hubs we connect to, I'd guess
Harvard, BU, ...)

Oh, and finally, I hope to be able to start filling memory-only orders next
week.  It'll take a little longer to fill more complex orders.  I'll be
working on the rest of the details this weekend, after getting some yard work
done (weeding, mowing, fencing pasture (It's enough to make me want to go back
to work on Monday!))/

From owner-pc532%daver@mips.com Sat May 19 20:05:58 1990
Flags: 000000000000
X-Path: sibyl.eleceng.ua.oz.au!ian
From: ian@sibyl.eleceng.ua.oz.au
To: pc532@daver.bungi.com
Subject: Patches for gnu tools --- update.
Date: Thu, 17 May 1990 12:59:56 +1000
Reply-To: pc532@bungi.com
Precedence: bulk

The patches for gdb and gas on augean.ua.oz have been updated.

The changes are minor. Gas has had the line comment character changed
along the lines we have been discussing. There was also a slight problem
with the catching of SIGCHLD when gas is in a bourne shell pipeline.

Gdb had some bugs in the disassembly (pinsn.c) code. (I think I
introduced this trying to merge David Taylors changes and mine). Not
only has the bug been fixed, but the size of the patch has been
reduced. I regard the latter as a "good thing" because the smaller the
changes, the easier it is to merge them into future FSF releases.

There is also a new file "mon-as.Z" which is a compressed shell script
to cause gas to emulate (as far as possible) Bruce Culbertson's as.
It is so you can assemble his monitor code (hence the name "mon-as").
This is the same code as I posted in btoa format a week or so ago.

Ian Dall


From owner-pc532%daver@mips.com Sat May 19 20:06:04 1990
Flags: 000000000000
X-Path: convex.com!loeliger
From: Jon Loeliger <loeliger@convex.com>
To: pc532 <pc532@daver.bungi.com>
Subject: Re: How many of you have working systems? 
Date: Wed, 16 May 90 09:13:29 CDT
Reply-To: pc532@bungi.com
Precedence: bulk

> Subject:  How many of you have working systems?

He! He!  I asked that question a while ago (9-Apr), and got a
deafening murmur, maybe.  I've got a working system.  Who else
besides D & G?

Here's Jon's definitive list of claimed working systems:

	Dave Rand
	George Scolaro
	Jordan Hubbard
	some other German board noted by Jordan (who's?)
	John Connin
	Jon Loeliger
	Fred's board (can Bdale qualify this?)
	Sverre Froyen
	Desmond Young

If I missed you or your system suddenly springs to life one 3am, please
drop me a note and I'll try to keep the list up to date, eh?


> I'm just curious. Of that set, how many of you have also gotten any of my
> stand-alone stuff to work (pi/siod/...)? It just seems like I'm

I have gotten pi to work only from the distributed binary version.  I've
been unable to get it to work from source.  I tried to compile it with
the *first* release of the stand-alone lib plus the *first* release of
the PD libc.  Since then, many fixes have been made to both those libraries
and some of the GNU gcc/gas/gld code....

Unforturnately, I've not had a chance to up-rev it all yet and give it
another whirl.  (Something to do with the Big Push at work, an upcoming
wedding (mine), murdering my new bride and framing Guilder for it... :-)

> sending stuff into a black hole, so I've gotten to wondering. My
> reason for asking does have a practical side as well; I don't know if
> I should be hurrying with my new forth monitor or just taking my time (I.E.
> is there any real current demand or is it going to be several months
> before a need is perceived?).

Black hole it's not.  They are collecting very nicely in my pc532 folder!

IMHO, the need will become much greater as soon as *some* critical mass of
working boards exists.  I don't know what that number is, though.
I'd like to see (maybe even beta) the new forth moitor if possible, but
it won't be possible for me to get back into things for a short while
(say, a couple of weeks).

jdl

From ames!mips!daver!owner-pc532@XN.LL.MIT.EDU Sun May 20 03:30:55 1990
Flags: 000000000000
Posted-Date: Sat, 19 May 90 8:52:57 EDT
X-Path: uunet!tarpit!manatee!John.L.Connin
From: John Connin <ames!mips!daver!uunet!manatee!johnc@XN.LL.MIT.EDU>
To: mips!daver.bungi.com!pc532
Subject: JDR SCSI cables..
Date: Sat, 19 May 90 8:52:57 EDT
Reply-To: ames!mips!bungi.com!pc532@XN.LL.MIT.EDU
Precedence: bulk

BEWARE:  JDR male-male SCSI cable part no. CBL-SCSI-MM ($19.95) is only
3 feet long, NOT 6 feet as stated in their catalog !!

Does anyone know of an inexpense source for SCSI cables ??  I need
some 6 foot cables and prefer round cables in this situation.

Best regards,
johnc			tarpit!manatee!johnc
-- 

From owner-pc532%daver@mips.com Tue May 22 01:43:01 1990
Flags: 000000000000
X-Path: news
From: amoss@cosmos.huji.ac.il (Amos Shapira)
To: xm-pc532@daver.bungi.com
Subject: Re: Calling conventions
Date: 21 May 90 19:01:48 GMT
References: <<9005161633.26136@munnari.oz.au>>
Reply-To: pc532@bungi.com
Precedence: bulk


Hello,
 In article <9005161633.26136@munnari.oz.au>
 ian@sibyl.eleceng.ua.oz.au askes:
 > I notice that he is apparantly using a convention where R0 -
 > R2 inclusive are free for use in functions without saving and
 > restoring.

 > I built gcc with a convention where R0 - R3 inclusive are free for use
 > in functions without saving and restoring (for compatability with my
 > ICM library functions).

 In the  "GNX - Version 3 Assembler Reference Manual" from NSC (NSC
 Publication Number 424010497-003C) there is a small Appendix
 (E) about calling conventions. This appendix clearly states that only
 registers R0-R2 should be considered as "unsafe", the same with floating
 registers F0-F3. The rest of the registers (i.e. R3-R7 and F4-F7) must
 be saved before used in a procedure.

Hope this helps,
Amos Shapira,
amoss@batata.huji.ac.il.bitnet

"Super users do it without asking for permission." - me.

From owner-pc532%daver@mips.com Wed May 23 14:16:20 1990
Flags: 000000000000
X-Path: sibyl.eleceng.ua.oz.au!ian
From: ian@sibyl.eleceng.ua.oz.au
To: pc532@bungi.com
Subject: Re: Calling conventions
Date: Wed, 23 May 1990 12:18:30 +1000
References: <<1990May21.19148.0@cosmos.huji.ac.il>>
Reply-To: pc532@bungi.com
Precedence: bulk

Amos Shapira writes:
 > 
 > Hello,
 >  In article <9005161633.26136@munnari.oz.au>
 >  ian@sibyl.eleceng.ua.oz.au askes:
 >  > I notice that he is apparantly using a convention where R0 -
 >  > R2 inclusive are free for use in functions without saving and
 >  > restoring.
 > 
 >  > I built gcc with a convention where R0 - R3 inclusive are free for use
 >  > in functions without saving and restoring (for compatability with my
 >  > ICM library functions).
 > 
 >  In the  "GNX - Version 3 Assembler Reference Manual" from NSC (NSC
 >  Publication Number 424010497-003C) there is a small Appendix
 >  (E) about calling conventions. This appendix clearly states that only
 >  registers R0-R2 should be considered as "unsafe", the same with floating
 >  registers F0-F3. The rest of the registers (i.e. R3-R7 and F4-F7) must
 >  be saved before used in a procedure.

Clearly NS haven't been consistent. Whats new? I guess that I could
assume that their more recent compilers are closer to optimal. Clearly
an even number of floating registers must be considered dirty for the
case of double precision functions.

I was wondering if anyone had any information about the pro's and
con's involved. I think it is an oversimplification to consider it a
trade off of expression evaluation registers against register
variables. I think it is more a question of how many registers to make
caller-save and how many make callee-save. The tradeoff seem to me to
depend on the the number of registers typically needed by leaf
functions, and the number of registers which have a "short" life in
the calling functions.

If there are *no* "scratch" registers (in practice, at least the
function return value registers must be dirty) then we have a fully
callee save situation. The trouble is the callee might save and
restore registers which the caller isn't using. If *all* the registers
are marked dirty on every function call, then the situation is fully
caller save. The trouble is that the caller might save and restore
registers never used by the callee. The true optimum could only be
achieved with global optimisation, but that doesn't help for
seperately compiled units (such as library functions) where some
convention is necessary.  Within the constraint that a fixed
convention is necessary for all functions, there must still be a
(constrained) optimum for some "average" mix of code.

I think what I will do in practice is stick with the convention I have
while I am down loading (to avoid having two versions of gcc on my
ICM). When I have a self supporting system on my pc532 I will change
to r0-r2, f0-f3 marked dirty on call and recompile everything.

Ian Dall.


From owner-pc532%daver@mips.com Wed May 23 23:46:03 1990
Flags: 000000000000
X-Path: mac.dartmouth.edu!Steven.D.Ligett
From: Steven.D.Ligett@mac.dartmouth.edu
To: pc532@bungi.com
Subject: Re: Parts kits.
Date: 23 May 90 22:09:42
Reply-To: pc532@bungi.com
Precedence: bulk

Ok, I've gotten confirmations, cancellations, corrections, etc for those
interested in buying parts.  Plus a half dozen newcomers to the list.

The latest news - the bank says it'll be a couple more weeks before I'm
approved as a VISA/MC merchant so parts will be here before I can take
charges.  In which case I'll take checks or something.  (My recollection is
that the approval process only took one phone call a day at my old bank, back
in the good old days.)

I expect that memories will come in first, so orders for only memories will go
out quickly.  (I'm sure that there's one part that has disappeared from the
face of the earth since I first got the quotes, so I'll have to track that
down.)  The 4-meg SIMMs aren't immediately available.  They may be available
in 60 days.  For those who want them, I expect the price to be between $400
and $500 per SIMM.

Since there's only 14 who want the whole kit, I'll have to get new quotes on
almost everything except the memories and the cpu chip set.  I don't expect
any prices to change too much, but I expect them all to change a little bit.  
I'll be posting up-to-date info on prices and delivery.  Or should I be
mailing all this info now?  Yeah, the 35 on my list are the only ones who need
all the gory details.  ok?

From owner-pc532%daver@mips.com Thu May 24 03:01:49 1990
Flags: 000000000000
X-Path: dlr
From: dlr@daver.bungi.com (Dave Rand)
To: pc532@bungi.com
Subject: Re: pc532 Dhrystone
Date: Wed, 23 May 1990 23:05:58 PDT
Reply-To: pc532@bungi.com
Precedence: bulk

[In the message entitled "pc532 Dhrystone" on May 23, 17:31, Jonathan Ryshpan writes:]
> Has anyone done a Dhrystone benchmark on the pc532 board?  I'd be
> interested in seeing the results.

Without hacks, just a CC and link, I got 11,111 on Dhrystone 2.1. I can give
you any number you like (up to 30,000) for Dhrystone 1.1.


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

From owner-pc532%daver@mips.com Thu May 24 05:11:02 1990
Flags: 000000000000
X-Path: news
From: nfotis@theseas (Nikolaos Fotis)
To: xm-pc532@daver.bungi.com
Subject: An idea for a cheap frame buffer
Keywords: color, frame buffer, SCSI
Date: 23 May 90 19:22:22 GMT
Reply-To: pc532@bungi.com
Organization: National Technical University of Athens
Precedence: bulk


Hi Netters,

I vaguely remember a SCSI-based frame buffer for the Mac (8 and/or 24-bit)
with rather high resolution, about 1K*1K
(this is the reason I crosspost to this Mac newsgroup: they know much
better than me what I'm referring)

Could it be a good and economical idea (read: ready hardware) to use this
peripheral to the pc532 project and for the Amigas?
(or, even better, for any SCSI-equipped machine)
What's needed for such a beast to cooperate with a machine different than
the Mac?
(I would like to get any of these i860-based frame buffers, but $$ are
 a BIG problem for students like us)

Possible uses:
Generic frame buffer (high resolution, full color) - good for BRL-CAD etc.
Hardware for use of a generic X Window environment

(no flames or holy wars, please, for crossposting to these newsgroups)

Please respond by mail, and I'll summarize to the posted
newsgroups.
(follow-ups to the Amiga hardware - or the NS 32k - newsgroups, please)

Have a nice day,
Nick.
----
-- 
Nikolaos Fotis			E-mail:
16 Esperidon St.,		UUCP:	mcsun!ariadne!theseas!nfotis
Halandri, GR - 152 32		InterNet: nfotis@theseas.ntua.gr
Athens, GREECE

From owner-pc532%daver@mips.com Thu May 24 05:11:08 1990
Flags: 000000000000
X-Path: news
From: meissner@osf.org (Michael Meissner)
To: xm-pc532@daver.bungi.com
Subject: Re: Calling conventions
Date: 23 May 90 21:05:11 GMT
References: <<1990May21.19148.0@cosmos.huji.ac.il>>>
Reply-To: pc532@bungi.com
Organization: Open Software Foundation
Precedence: bulk

In article <9005231633.29312@munnari.oz.au> ian@sibyl.eleceng.ua.oz.au
writes:

| I think what I will do in practice is stick with the convention I have
| while I am down loading (to avoid having two versions of gcc on my
| ICM). When I have a self supporting system on my pc532 I will change
| to r0-r2, f0-f3 marked dirty on call and recompile everything.

Note, you can specify which registers are which from the GCC command
line.  Quoting from the GCC manual:


     `-ffixed-REG'
          Treat the register named REG as a fixed register; generated
          code should never refer to it (except perhaps as a stack pointer,
          frame pointer or in some other fixed role).

          REG must be the name of a register.  The register names
          accepted are machine-specific and are defined in the
          `REGISTER_NAMES' macro in the machine description macro
          file.

          This flag does not have a negative form, because it specifies a
          three-way choice.

     `-fcall-used-REG'
          Treat the register named REG as an allocatable register
          that is clobbered by function calls.  It may be allocated for
          temporaries or variables that do not live across a call.
          Functions compiled this way will not save and restore the
          register REG.

          Use of this flag for a register that has a fixed pervasive role
          in the machine's execution model, such as the stack pointer or
          frame pointer, will produce disastrous results.

          This flag does not have a negative form, because it specifies a
          three-way choice.

     `-fcall-saved-REG'
          Treat the register named REG as an allocatable register
          saved by functions.  It may be allocated even for temporaries or
          variables that live across a call.  Functions compiled this way
          will save and restore the register REG if they use it.

          Use of this flag for a register that has a fixed pervasive role
          in the machine's execution model, such as the stack pointer or
          frame pointer, will produce disastrous results.

          A different sort of disaster will result from the use of this
          flag for a register in which function values may be returned.

          This flag does not have a negative form, because it specifies a
          three-way choice.
--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA

Catproof is an oxymoron, Childproof is nearly so

From owner-pc532%daver@mips.com Fri May 25 14:08:03 1990
Flags: 000000000000
X-Path: mac.dartmouth.edu!Steven.D.Ligett
From: Steven.D.Ligett@mac.dartmouth.edu
To: george@wombat.bungi.COM, pc532@bungi.com
Subject: capacitor reliability
Date: 25 May 90 12:03:04
Reply-To: pc532@bungi.com
Precedence: bulk

There was recently a question about the reliability of the tantalum
capacitors.  I just got a new tantalum cap catalog from AVX.  Here's a summary
of the reliability info.

Reliability is dependent on three things
1. Vapplied/Vrated
2. Temerature
3. Series resistance.

The caps I'm ordering are rated at 1% failures/1000 hours,
 @85 (degrees)C, with 0.1ohm series resistance.

Factor 1:  All the caps will be rated at 20 volts or higher.  For the 12 volt
supply, this gives a failure factor of 0.03. For the 5 volt supply, this gives
a failure factor of 0.002.

Factor 2:  If you cool your system to 50 C, this gives a failure factor of
0.09.  If you cool your system to 40C, the factor is 0.05.

Factor 3: For a series resistance of 0.2 ohms/volt, the factor is 0.6; for 3
ohms/volt, it's 0.07.

-------------
So, calculating the failure rate of a 20 volt cap on the 12 volt line, in a
system at 50C, with a series resistance of 0.2 ohms/volt, gives 

0.03 x 0.09 x 0.6 x 1%/1000 hours = 0.00162%/1000 hours

That sounds pretty good to me.  Perhaps someone with a flair for statistics
can tell us when we'll likely see the first failure of that cap in the 100
systems that are being built.

Final note - I can buy 25 volt caps and halve that failure rate.  If you want
it, I'll do it.

From owner-pc532%daver@mips.com Sun May 27 02:24:16 1990
Flags: 000000000000
X-Path: news
From: wombat!george (George Scolaro)
To: xm-pc532@daver.bungi.com
Subject: Re: Wanted: answers to commonly asked questions (Long)
Date: 26 May 90 15:46:37 GMT
References: <<740@ucsvc.ucs.unimelb.edu.au>>
Reply-To: pc532@bungi.com
Organization: Assn. for the prevention of Polar Bears and Kangaroos
Precedence: bulk

In article <740@ucsvc.ucs.unimelb.edu.au> U5569462@ucsvc.ucs.unimelb.edu.au (DAVID CLUNIE) writes:
>2 questions/comments:
>
> - I am a relative newcomer to this newsgroup and have figured out that the
>pc532 appears to be a single board 532 design that is available as a printed
>circuit board. Would it be possible for the designers or distributors of this
>board to regularly post a "commonly asked questions" type message that would

>Unix been ported to it yet ?
	Not yet. The two camps are AT&T Sys V and UCB 4.2. There is active
interest but of course source + licensing issues are still in progress,
stay tuned.

-------
The PC532 is a homebrew NS32532 based motherboard. It was designed during a
2 year period, evolving from a PC/AT wirewrap prototype to a baby PC/AT
sized motherboard. The complete schematics (gerber files if required) and
PLD equations for the design are freely available, as is all the source code
that has currently been written. The initial 'production' run of PCBs came to
65, and a further 37 have been mostly shipped (2 to go). With National
Semiconductor's generous support we were able to supply 50 NS32532, NS32381
and NS32202 chipsets with the first 50 PCB orders. The initial 65 boards
were kitted with the more hard to get components and connectors.  Kits with
NS chipset were $450 and kits without were $400. The current run of PCBs
will not be kitted (by us) but S. Ligett, who is on the mailing list is
arranging a similar volume purchase of components.

In addition to the PC532 there are several add-on boards being actively
designed, with some already complete. They include:

- Host SCSI adapter for the PC/AT to be used in conjunction with the PC532.
  This board is currently a wirewrap design.

- Floppy disk and centronics adapter, plugs into the PC532, uses SCSI to
  communicate with the PC532 (or any other SCSI based master). There are
  at least two designs in progress.

- Various medium/high resolution graphics display adapters.

- An i860 based board.

- Ethernet + 16 serial port adapter. NS32GX32 20MHz on board CPU. Plugs into
  the PC532 and communicates via SCSI. May also be run standalone. Designed
  but waiting for photoplotting and fab (I'm going on holidays in a month,
  so will wait till my return - 1st week of August).

The main justification for the PC532 and its brethren is to foster free
hardware design and to provide a platform for development of freely available
software. With the evolution of the PC/XT/AT computers, hardware hacking has
been on the decline. In addition, the increasing complexity of new
generation CPUs has also made it difficult for the home based tinkerer to
venture into the design of a computer system. The PC532 attempts to provide
the base from which new designs can gain leverage. In the long term the PC532
will likely become an adapter for a higher performance CPU.

Over the past few years there has much discussion in some of the news groups
about designing the ultimate homebrew computer, but this rarely ever
concluded. The reality is that few people actually have enough spare time to
design and carry through to completion anything other than the simplest of
projects. The PC532 was architected by two people, one hardware oriented the
other software oriented. Even with only two people, many discussions
(battles) occurred (were fought) prior to the final specification and design.

The current PC532 mailing list has a mixture of people with hardware and
software backgrounds. It currently appears that the software people
outnumber the hardware people. This is probably a good thing, since it
ensures that any hardware that is produced will have good software support,
based on the infinite number of monkeys principle (or less than infinite if
some aren't monkeys :-) ).

Following is a partial excerpt from the PC532 Functional Description
document:

The PC532 is a motherboard which mechanically fits into a PC/AT case. The
mounting holes and power supply connections are arranged accordingly. The
PC532 has 4 PC/XT slots which are mechanically placed to enable a PC/AT
case to be used, though electrically they support the SCSI protocol.

The printed circuit board (PCB) has 6 layers, comprising of two active outer
layers, 2 active inner layers, 1 power layer and 1 ground layer.

The PC532 board has the following features:

1 x NS32532 25 Mhz CPU

1 x NS32381 25 Mhz FPU

1 x NS32202 10 Mhz ICU

1 x DP8490 SCSI device that manages a 62 pin XT mechanically compatible 4
slot multi-master bus. This bus can run to at least 3.8 megabytes per second.
Multi-master is supported by the DP8490 SCSI device.

1 x AIC6250 SCSI device, connects to a 50 pin SCSI header. This device
is intended to connect to hard disk and mag tape media. The AIC6250 supports
async and sync SCSI. The interface supports data transfer rates over 4
megabytes per second.

4 x SCN2681 DUARTs. This gives the PC532 8 serial channels, which are all
individually connected to interrupt inputs on the ICU. Each DUART generates
an INT and in addition a wire or-ed RX ready channel A/channel B.

1 x 27256 EPROM (200 ns). This EPROM contains any necessary boot firmware.
It is intended that a Dallas Semiconductor (or compatible) clock chip/socket
be used under the EPROM to give the PC532 a battery backed real time clock.

4/8 megabytes (1 megabit x 8/9 80ns SIMMs) or 16/32 megabytes (4 megabit x
8/9 80 ns SIMMs). Page mode dram devices must be used and the design utilizes
the page mode access to achieve 0 wait state read (1st access), 0 wait state
write, 1 wait state for the rest of a read burst if in page. If not in page
a penalty of 4 wait states for reads and 3 wait states for writes occurs. The
result is a peak 50 megabyte/second memory interface (while bursting in
page).

The board currently runs a modified version of MON16 which enables a 32000
host system to download code, set break points, source level debug etc.
Bruce Culbertson has also ported his monitor to the PC532 and is in the
process of porting Minix. His Minix port has already been running for
considerable time on his home brew 32016 based computer.

Compute performance is roughly 10 X a 32016 based system (ICM3216). I/O
performance should be considerably faster.

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

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

> - I gather that the board has multiple serial lines, buit no video driver. I
>would love to configure one of these as a "workstation' type thing, but of
>course one needs a frame buffer to plug into the board. Are there any plans
>for such a thing ? Surely designing a memory mapped, 24-bit, no graphics
>
	stuff deleted...

>Regards ... David

Well, the area of graphics support certainly created much discussion, some
excited (heated?), with the end result being a few people deciding to go
their own way. This of course is fine, as long as we standardize on the
software interface (the hardware interface is easy - scsi) then we can
choose whichever board we want (and can afford!).

Note 1: This project is purely non-profit, homebrew, not affiliated with any
company etc. etc. By having a relatively large group of people with similar
interests, group buys can be arranged (with the good faith of all concerned)
for better component pricing.

Note 2: All the current PCB's are spoken for except for 2. Once they are gone,
we will have to wait for another group of people to indicate interest etc,
the more we get made in one shot, the cheaper they are. The last batch of
37 were US$200 each + shipping (including documentation).

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

From owner-pc532%daver@mips.com Sun May 27 11:19:34 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: FYI, forwarded from comp.arch
Date: 27 May 90 16:35:11 MSZ (Sun)
Reply-To: pc532@bungi.com
Precedence: bulk


This posting is on behalf of Johann Ruegg (uunet!dunike!onecom!hans).
Please send all replies directly to him and NOT to me.
  --mj
  mj@myrias.com
>>>>>>>>>>>>>>>>>>>>>>>>>> cut here >>>>>>>>>>>>>>>>>>>>>>

There has been some recent speculation about the history of National's
32000 chip.  We did the official AT&T Unix port for National way back
when, so we thought we'd add our 2 cents worth.

At the time, AT&T contracted with Zilog, Intel, Motorola and National to
do official ports of UNIX.  The porting base was still the VAX and AT&T
Unix still did swapping (no paging).  Each chip maker typically contracted
with a Unix house to do the port.  National originally had a deal with HCR
for their port.  We were working for Burroughs at the time, and they had
a project (since canceled :-( ) which was going to use the National CPU,
so we basically volunteered to do a parallel port for free.

National already had a box running their Berkeley port.  The box was 
called the SYS16 (later re-named SYS32) and their Berkeley port was
called Genix.  Anyway, we already had a fairly stable hardware design
and we decided to use Genix as our host system.  Joe Treat did a
pcc compiler port and a new assembler.  Johann Ruegg did the kernel
porting work.

First, we both agree that the National architecture was superb for
Unix.  The addressing modes and orthagonality of the instruction set
worked out well for the compiler port.  Also, VAX byte order was a
plus since the VAX was our porting base.  The MMU architecture and
trap system worked out well also.  Unix changed from swapping to
its first paging version during the work and we were able to add
paging in 6 weeks!  The National MMU was actually cleaner than the
VAX since it had Modify and Access bits.

One mistake National did make with the architecture was the idea of
modules and external references which went through the module tables.
This let you link to ROM code easily.  The Genix compiler actually
used this for C, but it was so slow that we took it out for the PCC
port.  (I believe National also abandoned it later for Genix).

Also, like other 2 address architectures, the 32000 had the following
problem with instructions which are not commutative (sub, div, shift):

	a = a - 3;

can be coded as "sub $3,r4" if a is in 'r4' but

	a = 3 - a;

cannot be coded in one instruction.  What you really need is another
version of 'sub' that does "dest = src - dest" in addition to
"dest = dest - src".  Does anyone know of a commercial 2 address machine
which provides both?

There were still a few chip bugs however.  Two in particular caused
problems:

	1) Divide didn't always give the correct result.  This was
fixed in the next rev.  What was amazing was that the Genix people hadn't
found this bug previously.  Perhaps because National was still using
VAX's as their host machines internally, while we were using our port.

	2) Page table entries that were marked as modified but were not
writable didn't work right.  Writes trapped in such a situation, but
AFTER the write was already done.  The workaround was to use a different
bit to mark pages which were modified.

Despite these problems, our UNIX port was done long before the other
chip vender's ports and was the only one to include paging.  We spent
our extra time debugging AT&T's Unix validation test suite.  This
was partially due to our brilliance ( :-> ), but mainly due to the
niceness of the architecture.  (We also beat out HCR and were picked
as the port even though HCR had a 3 month head start).

Johann is currently working on the i860 port with Intel.  This is
also a good architecture for UNIX (though not perfect), but it too
has had significant chip bugs.  The major ones have already been fixed -
perhaps quicker than National?  It may however suffer the same fate as
National - being a little too late for its market.  We will see.


	Johann Ruegg  uunet!dunike!onecom!wldrdg!hans
	Joseph Treat  uunet!dunike!onecom!wldrdg!joe

From owner-pc532%daver@mips.com Mon May 28 20:59:15 1990
Flags: 000000000000
X-Path: news
From: nfotis@theseas (Nikolaos Fotis)
To: xm-pc532@daver.bungi.com
Subject: An idea for a general/cheap frame buffer
Keywords: SCSI, 24-bit
Date: 28 May 90 18:04:37 GMT
Reply-To: pc532@bungi.com
Organization: National Technical University of Athens
Precedence: bulk


[It seems that it didn't make it around the world, so I retry - nf]
Hi Gyus,

I vaguely remember a SCSI-based frame buffer for the Mac (8 and/or 24-bit)
with rather high resolution, about 1K*1K
(I posted to the Mac hardware newsgroup: they know much
better than me what I'm referring)

Could it be a good and economical idea (read: ready hardware) to use this
peripheral to the pc532 project and for the Amigas?
(or, even better, for any SCSI-equipped machine)
What's needed for such a beast to cooperate with a machine different than
the Mac?
(I would like to get any of these i860-based frame buffers, but $$ are
 a BIG problem for students like us)

Possible uses:
 Generic frame buffer (high resolution, full color) - good for BRL-CAD,
  Movie.BYU etc.
 Hardware for use of a generic X Window environment

 (no flames or holy wars, please, for crossposting to these newsgroups)

 Please respond by mail, and I'll summarize to the posted
 newsgroups.
 (follow-ups to the Amiga hardware - or the NS 32k - newsgroups, please)

Have a nice day,
Nick.
----
-- 
Nikolaos Fotis			E-mail:
16 Esperidon St.,		UUCP:	mcsun!ariadne!theseas!nfotis
Halandri, GR - 152 32		InterNet: nfotis@theseas.ntua.gr
Athens, GREECE

From owner-pc532%daver@mips.com Mon May 28 21:50:08 1990
Flags: 000000000000
X-Path: hplwbc.hpl.hp.com!culberts
From: Bruce Culbertson <culberts@hplwbc.hpl.hp.com>
To: pc532@hplwbc.hpl.hp.com
Subject: Minix runs
Date: Mon, 28 May 90 15:37:38 pdt
Reply-To: pc532@bungi.com
Precedence: bulk

I am typing this note on a pc532 running Minix!  (I will mail it
>From another machine, however.)  I logged in for the first time
yesterday (Sunday) afternoon and it has been running quite smoothly,
all things considered.  Spent today loading things onto my pc532
hard disk and fixing a few small bugs I discovered along the way.

Performance seems quite snappy aside from I/O, which is not Minix's
strong point.  The latest version, 1.5, is supposed to have faster
I/O but I am running 1.3 currently.  I have not yet investigated what
it will take to upgrade to 1.5.

Another issue I have not thought much about is how to distribute this
stuff.  I guess I can make cdiff's and send them to Phil Budne's
archive.  It will take a while to get all the sources in one place,
figure out what I changed, make diff's, package things in small
enough chunks for mail, etc.  I'll try to get this done soon but
don't hold your breath.

Bruce Culbertson

From bobh@unicorn.wwu.edu Mon May 28 23:13:54 1990
Flags: 000000000000
Date: Mon, 28 May 90 20:14:40 -0800
From: bobh@unicorn.wwu.edu (Bob Hayes)
To: budd@bu-it
Subject: Miniscribe drives

Hello phil,
Deadlines have passed, swamps drained, gators caught,
bandages applied, survivors shot now!
So did you get a manual yet, or do you still need a copy
of the Miniscribe manual? If you're still unsupplied I can
probably find a xerox thats cool enough to touch here somewhere.
Let me know if I can help at this late date.
--
Bob Hayes < bob@arthur.wwu.edu | bobh@unicorn.wwu.edu >	USnail follows:
Western Washington University
Computer Science Dept. Bond Hall 302,     Bellingham, Washington 98225
Obbligato Disclaimers: All; Std Joke:   4 nickels for a used paradigm??;

From ames!mips!daver!owner-pc532@XN.LL.MIT.EDU Tue May 29 09:28:32 1990
Flags: 000000000000
Posted-Date: Tue, 29 May 90 06:22:11 EDT
X-Path: uunet!sware!hosking
From: ames!mips!daver!uunet!sware!hosking@XN.LL.MIT.EDU (Doug Hosking)
To: mips!daver.bungi.com!pc532
Subject: anyone have thoughts re ...
Date: Tue, 29 May 90 06:22:11 EDT
Reply-To: ames!mips!bungi.com!pc532@XN.LL.MIT.EDU
Precedence: bulk


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

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.

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.

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.

Thanks!



From ames!mips!daver!owner-pc532@XN.LL.MIT.EDU Tue May 29 11:35:54 1990
Flags: 000000000000
Posted-Date: 29 May 90 07:16:04 GMT
X-Path: news
From: ames!mips!nsc.nsc.com!chaim@XN.LL.MIT.EDU (Chaim Bendelac)
To: mips!daver.bungi.com!xm-pc532
Subject: Series 32000; alive and well
Keywords: Series 32000, embedded processors, imaging
Summary: 32k used in imaging products; new FX16 fits low-cost fax market
Date: 29 May 90 07:16:04 GMT
Reply-To: ames!mips!bungi.com!pc532@XN.LL.MIT.EDU
Organization: National Semiconductor, Santa Clara
Precedence: bulk


This message was prompted by the following recent threads: 32016 etc, Micro-
processors and market forces, Bubble Memory (was Re: 32016 etc.). I quote
(strongly condensed):

mash@mips.COM (John Mashey) quotes Dave Mason:
>
>   mason@tmsoft.uucp (Dave Mason) in his response to Henry Spencer:
>
>      henry@utzoo.uucp (Henry Spencer):
>      H  "It wasn't for want of trying; a lot of people lost their shirts.
>      H   The successful ones can be counted on your thumbs."
>
>    D "That's how you do it Henry, you have extra hands :-) I count at least
>    D  Encore, Sequent, Whitechapel,... in the Unix market.  32000s are also
>    D  very popular in Laserprinters".

And says: 
> J  "I'm interested in the second part: could somebody give some examples
> J   of laser printers that have 32000's in them?  I don't remember seeing
> J   the 32000 mentioned"


In spite of its elegant architecture, the Series 32000 family was mostly 
unsuccessful in its attempt to carve out part of the "general purpose" market. 
It is no fun to be third.

However, the Series 32000 is not dead. Far from it. When we realized
that we had a very slim chance to succeed in the limited workstation market
we looked around, and repositioned ourselves into what we call the "desktop
imaging" market. The classic example of this market is the laser-printer;
other examples include various (integrated) office-peripherals, such as
servers, fax-machines, scanners, voice-mail equipment, and combinations of
the above. I am not a marketing person, but even I can see that the potential 
in this market is better.  And when we started, not as crowded too :-).

The "desktop imaging" market is characterized by high-volume, low-cost
(that's the bad part), high-performance computing requirements. To hit
the right balance, the original Series 32000 processors were redesigned,
resulting in the Series 32000/EP family of Embedded Processors.

The first member, the NS32CG16, was introduced in 1988. On top of the 
32000 architecture (binary compatible), the CG16 adds some 18 imaging 
instructions (variations of bitblt and other bit operations). 
It is probably no secret that our largest customer for the 32CG16 is Canon, 
whose Mark III/LBP-8 and LBP-4 laser printers use it (I am told that these 
are now the most popular laser printers in Europe). Other announced 
customers include Facit, Ollivetti, Everex (which sells printers under 
various additional labels), and Mannesmann-Tally. We have many more 
design-wins, many which I cannot announce. (This market is undoubtly much 
less glamorous than the WS market).

To further answer "alvitar@xavax.com (Phillip Harbison):
>      I'm sure National would like to THINK it is popular in things like
>      laser printers, but I trust John's analysis more than NSC
>      marketing hype. Laser printer manufacturers certainly can't be
>      too pleased with the 32CG16' performance.  I'd imagine Postscript
>      would be slower than usual. :-)"

The 32CG16 is not an R3000. But it fits the market, in terms of cost/
performance. In fact, at 15 MHz running PostScript, it is equivalent to
the 8PPM Apple LaserWriter NTX, which sports a 16.6 Mhz 68020. At a
fraction of the cost, I may add. All major PS vendors/clones have announced
products around the 32CG16.

The second member of the Series 32000/EP, the NS32GX32, was introduced in
1989. Since it is derived from the NS32532, the 32GX32 is in a higher 
performance bracket. It is about 6-8 times the Apple NTX in performance.
Alps-America has introduced a 20 PPM 32GX32-based PostScript printer;
there are several more GX32 design wins, with at least one color
PostScript printer that I am aware of.

Now after two years, with an established laser printer market, we are
about to expand our focus to the entire office peripheral market.
To that end we proudly introduced last week three more members in the 
Series 32000/EP family, the 32CG160, the 32FX16, and the 32GX320.

The 32CG160 is a more integrated version of the 32CG16 (DMA, counters,
ext bitblt, interrupt control, etc). It runs at 25 Mhz. (And yes, we have 
learned our lessons: samples are available NOW, full spec. We have
PS running on it, dev boards and tools released). The CG160 simply provides
a higher performance/cost ratio, and is in that sense an evolutionary
product over the CG16.

The 32FX16 is our new flagship: our first imaging signal processor.
On top of the CG16's core, we have implemented a DSP block (incl on-chip 
memory for DSP coefficients). This unique combination (of a general 32-bit
processor with DSP capability) makes the FX16 (and its new big brother, 
the GX320), the only embedded processors to have enough computational power 
to implement high speed fax transmission in SOFTWARE alone (all in C!). 
We demonstrated this capability at our product launch. 
As you may know, currently existing fax products usually have at least two 
processors: one dedicated fax-chip (Rockwell, Yamaha, etc),
and another one to do control, compression/decompression, error correction,
grey-scales and other stuff. The FX16 can do all of the above, and 
PostScript capability thrown in (think about PostScript/plain-paper 
fax/printer products).
The FX16 and the GX320 are revolutionary products. We have several
designs in progress, some with *very* big companies. The FX16 is available
in samples (has been since January), runs at a full 25 MHz.

The 32GX320 is our new top-of-the-line. It is based on the 32GX32 core and
has a re-designed hardware multiplier plus 4 new (complex mul and complex
mul-accumulate)in addition to other system integration functions
(DMA, counter/timers, and interrupt control). It is targeted to
fax/printer server types of products. It is offered at 20, 25 and 30 Mhz.
Samples available.

I am hesitant to make this posting any longer than it already is, by adding
more technical details. If there is interest, I will be happy to oblige :-).

To summarize:
The Series 32000 no longer competes with the likes of sparc, mips and
the i860. As such, we have disappeared from the day-to-day spotlights.
But our technology has matured, we have refocused and we are doing well.

---------------------------------------------------------------------------
Footnote:

On a regular basis, whenever a message in this group mentions National's
Series 32000, it is followed by a predictable stream of (sometimes
uninformed, often irrelevant) bashing/flaming. A recent thread that started
with a question about the 32000's limited success in the workstation/Unix
market soon turned into reminiscences of De Gaulle's actions in the fifties,
Hitachi-scandals, sewage treatment, the number of thumbs on Henry's hands,
a story about a bozo NS salesman and Intel's bubble memories.

I will not counter the various claims that were made here on "companies
that went out of business" because of the 32000 or of National. Frankly,
whatever I say, some will continue to stick to their beliefs. Several
readers have pointed out corrections regarding Sequent, Siemens, Encore,
TI, WhiteChapel, etc. Please folks, try to stick to facts, not rumours!

---
chaim@nsc.nsc.com (Chaim Bendelac; National Semiconductor)

From owner-pc532%daver@mips.com Tue May 29 14:40:08 1990
Flags: 000000000000
X-Path: UNB.CA!FELLOWS
From: FELLOWS@UNB.CA
To: pc532@bungi.com
Subject:     Re: Minix runs
Date: 	Tue, 29 May 90 13:17:05 EDT
Reply-To: pc532@bungi.com
Precedence: bulk

On  Mon, 28 May 90 18:37:38 EDT  Bruce Culbertson <culberts@hplwbc.
hpl.hp.com> writes:

> I am typing this note on a pc532 running Minix!  (I will mail it
Great!
Stuff deleted
> strong point.  The latest version, 1.5, is supposed to have faster
> I/O but I am running 1.3 currently.  I have not yet investigated what
> it will take to upgrade to 1.5.
>
It seems that it will be difficult to get a legal base copy of Minix 1.3
at this late date.  I had pretty well decided to wait until 1.5.x is published
before getting a copy.

Point to ponder.  Is porting from the Atari version of 1.5 going to be
easier or harder than from the PC version?  That is, are "endian" problems
better or worse than "segments"problems?

Dave Fellows

From owner-pc532%daver@mips.com Tue May 29 14:42:04 1990
Flags: 000000000000
X-Path: convex.com!loeliger
From: Jon Loeliger <loeliger@convex.com>
To: pc532 <pc532@daver.bungi.com>
Subject: Re: anyone have thoughts re ... 
Date: Tue, 29 May 90 09:40:45 CDT
Reply-To: pc532@bungi.com
Precedence: bulk

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

Now, now, now, he explained, tongue firmly planted in cheek, I used to
have this classic hacker scene on my desk.  You know, a real *distributed*
computing environment, everything kludged together, nothing packaged,
loose wires and cables all over the place, the hip-bone connected to the
thigh-bone and the turbo charger installed.  That was back when it worked.
Now-a-days, I've got it neatly packaged in an AT case, my own, unborrowed
power supply, almost proper cabling, and no extra trash.  It looks real clean.
That's when the disks stopped working...

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

Not exactly an answer to the queston, but, perhaps it is time to drag the
updated version out of fluxes and distribute it so you know who to bug
directly!

Here's Jon's definitive list of claimed working systems:

	The Few, The Proud, The Living
	------------------------------

	Who			Really Who
	---			----------
	John Connin		tarpit!manatee!johnc
	Sverre Froyen		mips!fesk.seri.gov!sverre
	Bdale Garbee		bdale@col.hp.com
	Jordan Hubbard		jkh@meepmeep.pcs.com
	Ron Irvine		ron@hcr.com
	Robbin Johnson		rjohnson@kiwi.mpr.ca
	Jon Loeliger		loeliger@convex.com
	Peter P			pp@prosys.se
	Dave Rand		dlr@daver.bungi.com
	Fred's Schneider	K0YUM
	Karl Swartz		uunet!apple!zygot!ditka!kls
	George Scolaro		george@wombat.bungi.com
	Desmond Young		des@dtg.nsc.com
	Bruce Culbertson	culberts@hplwbc.hpl.hp.com>

	some other German board noted by Jordan (who's?)

As usual, if you aren't on the list and you want to be and your board
suddenly springs to life one dim 3 AM, send me a piece of mail or post
your exuberance to the pc532 list and I'll add you to the list of The Few,
The Proud, The Living.




jdl

From owner-pc532%daver@mips.com Wed May 30 15:13:55 1990
Flags: 000000000000
X-Path: CRVAX.SRI.COM!FRANK
From: "Victor Frank"  <FRANK@CRVAX.SRI.COM>
To: pc532@BUNGI.COM
Subject: Re: Series 32000; alive and well
Date: Wed, 30 MAY 90 09:55:15 PDT 
Reply-To: pc532@bungi.com
Precedence: bulk

     I would like to quiet any misgivings that Chaim Bendalac may have had
about posting in defence of National, and in fact think that such a posting
was long overdue.

     Silence, in the face of rumors of doom, is not the answer.  How many
hardware "wins" and potential software developers may have been scared off
by such talk we will never know.

     So, scotch another rumor, if you may.  What's the status of the 32202
Interrupt Controller?  One catalog said it was being discontinued.  Now I
see the ICU is being put on the advanced CPU chip sets.  

     I, for one, appreciate the time and effort Chaim put into the posting
and hope he will continue to keep us informed.


From owner-pc532%daver@mips.com Thu May 31 14:22:36 1990
Flags: 000000000000
X-Path: news
From: chaim@nsc.nsc.com (Chaim Bendelac)
To: xm-pc532@daver.bungi.com
Subject: Re: Calling conventions
Date: 31 May 90 05:10:29 GMT
References: <<9005231633.29312@munnari.oz.au>>
Reply-To: pc532@bungi.com
Organization: National Semiconductor, Santa Clara
Precedence: bulk

In article <9005231633.29312@munnari.oz.au> ian@sibyl.eleceng.ua.oz.au writes:
>Amos Shapira writes:

> > Hello,
> >  ian@sibyl.eleceng.ua.oz.au askes:
> > 
> >  > I built gcc with a convention where R0 - R3 inclusive are free for use
> >  > in functions without saving and restoring (for compatability with my
> >  > ICM library functions).
> > 
> >  In the  "GNX - Version 3 Assembler Reference Manual" from NSC (NSC
> >  Publication Number 424010497-003C) there is a small Appendix
> >  (E) about calling conventions. This appendix clearly states that only
> >  registers R0-R2 should be considered as "unsafe", the same with floating
> >  registers F0-F3. The rest of the registers (i.e. R3-R7 and F4-F7) must
> >  be saved before used in a procedure.

>Clearly NS haven't been consistent. 

The ICM compiler was inconsistent with most other compilers for the 32K; NSC's
current compilers (GNX) follow the r0-r2,f0-f3 unsafe, rest safe rule.

>I was wondering if anyone had any information about the pro's and
>con's involved. 

We did some experimentation and testing of this (after we had already set
the convention). We implemented a little secret kludge in our compiler to
indicate the "infinite" number of safe and unsafe registers the optimizer
COULD use, were they available (under the same general assumptions as our
current register model, ie, it COSTS something to use a safe register (you
have to save/restore it), it COSTS something to have a global variable or
param in a register (you have to load and sometimes spill it). 
The GNX optimizer performs some additional clever footwork with registers; it
maneuvers "return" results into r0 (to avoid extra mov's), it passes params
to (static) functions thru r0/r1 when advantagous, etc.

Anyway, the results were not clear-cut. In leaf-routines, obviously, more
unsafe registers were needed than in non-leaf routines, which had variable
life-ranges over function-calls. Some functions needed many more safes,
other functions were better off with many more unsafes. Bottom-line, both 
the 3-5 and the 4-4 split make sense, and are certainly better than a 0-8 
or 8-0 convention.
---
chaim@nsc.nsc.com

