HDTenEightyP/NetNews huggingface dataset:
From: rpomeroy@aunext3.amd.com (Ron Pomeroy x(Coop))
Subject: Re: Concerns about NeXT Prices are warranted
Reply-To: rpomeroy@aunext3.amd.com
Organization: Advanced Micro Devices, Inc.; Austin, Texas
Distribution: usa
Date: Wed, 18 Nov 92 14:52:57 GMT

In article <1992Nov17.220242.5902@access.usask.ca> jake@skatter.usask.ca  
writes:
>>From article <1e97r8INNeot@gap.caltech.edu>, by  
ernest@pundit.cithep.caltech.edu (Ernest Prabhakar):
>>> In article <1992Nov16.181812.25376@cbnewsl.cb.att.com>  
coco@cbnewsl.cb.att.com  
>>> (felix.lugo) writes:
>>
>>(stuff tossed)
>>
>>> Well, yes and no.  After all, Unix boxes have had far superior  
>>> price/performance for years, but PCs are still the dominant animal.  Which  
is  
>>> what NeXT is competing against, at least in the LA area (NeXTSTEP vs.  
Windows  
>>> NT, which I guess is fair since they're both 'vapor').
>>> 
>>> It is certainly annoying that NeXT has such wimpy hardware, but I guess  
NeXT is  
>>> still considered fast relative to the PC world.  And don't forget Pentium  
>>> (Intel '586) is due out soon, which will have comparable performance to a  
>>> SPARC, and NeXTSTEP '486 is already running on it in NeXT's labs...
>>>
>>
>>Yeah, yeah,  I heard that Nextstep is running on 370's in NeXT's labs, and
>>I hear it kick's JCL's butt...
                   ^^^^^^^^^^
			What's JCL ?
--
Ronald Pomeroy		[Objective-Cruntime: [Smalltalk runtime]];
Advanced Micro Devices	[self dream-on];
CAM Applications Group
rpomeroy@aunext1.amd.com (NeXTmail preferred)
From: dillon@overload.Berkeley.CA.US (Matthew Dillon)
Newsgroups: comp.sys.next.advocacy
Subject: Re:   DEC's alpha is "way fast" according to WSJournal
Distribution: world
Date: 22 Nov 92 09:29:43 PST
Organization: Not an Organization

In article <1992Nov21.133955.430@tumbolia.sta.sub.org> axel@tumbolia.sta.sub.org writes:
>As this is my first posting to this group, I hope, it will come
>through ...
>
>So far, everybody in this group obviously is convinced, that the
>future lies in 64 bit-architectures. I wonder how Motorola could
>come to the conclusion that 64 bits don't improve performance
>that much (a German computer magazine said that thorough
>statistical analysis had shown that the performance increase could
>be estimated at around 1.5%) -- and the 68060 is going to be a 32-bit
>microprocessor (in good ol' 680x0 tradition).
>
>Is this just another indication that Motorola has lost the micro-
>processor race against Intel and other competitors?
>
>Just wondering...

    If all one is doing is recompiling todays applications then I think
    it's quite obvious why 64 bit architectures don't improve performance
    all that once... For the same reason that recompiling 16 bit
    applications on 32 bit machines don't improve performance all
    that much.

    But for the future, they are necessary.

					-Matt

>Axel.
>
>--------------------------------------------------------------------
>aseibert@tumbolia.sta.sub.org| The will to be stupid is a very
>NeXTmail welcome	      | powerful force.
>
>seiberta@informatik.tu-muenchen.de (please no NeXTmail here!)

--

    Matthew Dillon		dillon@Overload.Berkeley.CA.US
    1005 Apollo Way		uunet.uu.net!overload!dillon
    Incline Village, NV. 89451	ham: KC6LVW (no mail drop)
    USA 			Sandel-Avery Engineering (702)831-8000

Newsgroups: comp.sys.next.advocacy
From: byer@adobe.com (Scott Byer)
Subject: Re: 64-bit CPUs
Reply-To: byer@adobe.com (Scott Byer)
Organization: Adobe Systems Incorporated
Date: Thu, 19 Nov 1992 17:47:28 GMT

Steven T. Abell writes

> do LDQ and STQ load and store four or eight bytes? It would appear
> to be eight, but the comment on the third instruction implies
> otherwise.

8 bytes, quad*word*.  I 'fat-brained' the comment.

> A 64-bit RISC can offer significant speed improvements, at the cost
> of more complex algorithms that may invalidate traditional programming
> idioms.

Yup.  Same with parallelism, pipelining, etc.

The hardware guys seem very determined to keep us programmers
employed.

--
Scott Byer                             NeXTMail: byer@mv.us.adobe.com
Adobe Systems Incorporated               These are *my* opinions, and  
1585 Charleston Road, P.O. Box 7900        do not necessarily reflect
Mountain View, CA 94039-7900             the opinions of my employer.
---------------------------------------------------------------------
Newsgroups: comp.sys.next.advocacy
From: Joseph R. Grace <JGrace@TetraSoft.com>
Subject: Re: 64-bit CPUs (was DEC's alpha is "way fast")
Organization: TetraSoft International
Date: Wed, 18 Nov 1992 08:47:13 GMT

In article <1992Nov18.012959.7716@netcom.com> abell@netcom.com (Steven T.  
Abell) writes:
>  Not being familiar with the Alpha instruction set: what increments your
>  pointers?
>  
>  It's the misaligned case that's interesting. If Alpha has no sub-width
>  reads or writes, I think this algorithm is much more complex than you
>  indicate. You'll need to hang onto the previous read to construct the
>  following write, or reread the previous chunk.
>  
>  Also, I think the code here has a typo: the second LDA. Comments would be
>  helpful.

Well, here's my guess.  WARNING --- I have never ever done any Alpha  
Programming!  I have no Alpha Manual!  Do not base your Alpha compiler on my  
following interpretation of an Alpha code fragment!  I disclaim all warranties  
and liabilities for damages resulting from the following comments.  Have I made  
myself clear. :-)

Well, here goes...  (splash, gurgle, gurgle :-)

			    //  long long  *R1,    *R2,  R3;
			    //  long long  *pFrom, *pTo, From;

Loop:			    //  Loop:-)
        STQ     R3,0(R2)    //  *R2 = R3;	    //  *pTo = From;
        LDA     R2,8(R2)    //  R2++;		    //  pTo++;
        LDQ     R3,0(R1)    //  R3 = *R1;	    //  From = *pFrom;
        LDA     R1,8(R1)    //  R1++;		    //  pFrom++;
??			    //  long long  R31 = 0; /*?Correct assumption?*/
			    //  char  R4[ 8];       //  for 8 IsZero flags.
			    //  char  R3[ 8] = (char[ 8]) R3;
			    //  Hold your nose and wave your hands ;-):
??      CMPBGE  R31,R3,R4   //  For( i=0; i<8; i++)  R4[ i] =  ! R3[ i];
			    //  long long R4 = (long long) R4;
??      BEQ	R4,Loop     //  if( !R4) goto Loop; //  i.e., no NULL byte.

>  Thanks, Scott. Now we're getting somewhere.

Agreed!  What fun :-)

= Joe =
-- 
Joe Grace <JGrace@TetraSoft.com> (NeXTMail preferred.)
TetraSoft International   Business and Personal Productivity Tools for NeXTSTEP
Newsgroups: comp.sys.next.advocacy
From: thomsen@spf.trw.com (Mark Thomsen)
Subject: Re:  DEC's alpha is "way fast" according to WSJournal
Organization: TRW Inc., Redondo Beach, CA
Date: Sat, 21 Nov 92 22:37:00 GMT

axel@tumbolia.sta.sub.org writes
> So far, everybody in this group obviously is convinced, that the
> future lies in 64 bit-architectures.

The value of 64-bit data paths are sometimes useful when you are pushing large  
pieces of data around (like for screen displays and images). Most instructions  
and pieces of data, however, are not large enough to benefit from 64-bit  
transfers.

The value of 64-bit addressing is when people really are pushing weird  
structures to get around 32-bit addressing as a "limit".

One suspects that since they silicon guys can put all of the CPU stuff for a  
32-bit architecture onto a modest chip, designers are looking at "what next?"  
Bigger architecture? Multiprocessors? More units for executing instructions ->  
superscaler/parallel/pipelined? More of the peripheral operations? More very  
local memory with register performance? Whatever else they can dream of.

Yow! It will be fun to see what pops out over the next few years. I wish I was  
smart enough (or, if I am, to have thought enough) to figure out where the  
immediate future lays so I can invest wisely.

But, for now, NeXT following an aggressive 32-bit uniprocessor path is  
adequate. Following the hardware and being a most excellent second adopter on  
the CPU paths (letting someone else step on potential land mines first) makes  
sense. Their aggressiveness on manufacturing, clean engineering, and NeXTSTEP  
is plenty to make them a leader - IMHO.

Mark R. Thomsen
Newsgroups: comp.sys.next.advocacy
From: abell@netcom.com (Steven T. Abell)
Subject: Re: 64-bit CPUs (was DEC's alpha is "way fast")
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Tue, 17 Nov 1992 03:04:23 GMT

byer@adobe.com (Scott Byer) writes:
>Steven T. Abell writes
>> On a 32-bit CISC, the realignment method you're talking about moves
>> 2 bytes in three instructions, which is a net loss to byte movement;
>> a 64-bit CISC moves 4 bytes in 3 instructions, a net gain, but not
>> by all that much.  On a RISC, this method requires 5 instructions
>> per transfer, with 2 bytes moved through 32 bits, 4 bytes through
>> 64, as opposed to 4 instructions per byte for byte movement.
>
>Small point - 64 bits is 8 bytes.  And, remember, you have to count
>cycles, not instructions, as instruction counts can't be compared
>between a CISC machine (which often have multi-cycle instructions)
>and a RISC machine.

Yes, 64 bits is 8 bytes, but the string algorithms we're talking about
can really only move half a register at a time, even though some variants
do involve full-width reads and writes.

Yes, CISC instructions can take multiple cycles (which I'm sure *no one*
else here knew :-) but the instructions we're talking about here are
pretty fast.

>> I'm willing to soften my stance on struct ops, but the normal
>> inheritance architecture leaves holes in aligned structs that have
>> to be masked out, which will palpably decrease throughput in struct
>> compares.
>
>"Holes" have undefined contents, and can be moved as part of a
>large chunk.  A structure containing a char and an int can still
>be moved in one 64-bit chunk despite the alignment hole in the
>middle.

Have you ever needed to *compare* structs? This requires masking.

Steve abell@netcom.com
From: vhs@rhein-main.de (Volker Herminghaus-Shirai)
Subject: Re: 64-bit CPUs (was DEC's alpha is "way fast")
Reply-To: vhs@rhein-main.de
Date: Wed, 18 Nov 92 20:35:51 GMT

In article <1992Nov17.205612.738@adobe.com> byer@adobe.com (Scott Byer) writes:
> Volker Herminghaus-Shirai writes
> 
> > 'cuse me but how is your strcpy routine going to find the end of
> > the string? Strncpy is OK, but strcpy?
> 
> Use the instruction intended for just such an emergency :-)
> 
> 'CMPBGE' is what it's called on the Alpha.  And there are some nice
> examples of it's use in the architecture handbook.
> 
> Assuming that the source and destination address are mis-aligned
> in the same way ( source & 0x07 == destination & 0x07 ) the inner
> loop to strcpy becomes:
> 
> 	<preamble - gets to an aligned point,
> 		    preloads R3 with first aligned quadword>
> Loop:
> 	STQ	R3,0(R2)
> 	LDA	R2,8(R2)
> 	LDQ	R3,0(R1)
> 	LDA	R1,8(R1)
> 	CMPBGE	R31,R3,R4
> 	BEQ	R4,Loop
> 
> 	<postamble - copy the right masked portion of the last
> 		     quadword, based on the set bits in R4, which 
> 		     indicate where the comparison failed>

[cycle calculations etc. deleted]

Sorry I'm not familiar with the Alpha assembler. It seems to me that R1 and R2
are pointers to the source and destination, respectively. I further assume that
the line "CMPBGE R31,R3,R4" should actually read "CMPBGE R1,R3,R4", since an R31
wasn't mentioned before, and that it puts the results of the comparison (R1>R3?)
into R4. Correct? Or, as an alternative, R31 is an always-zero register and
CMPBGE means "Compare Bytewise if Greater or Equal", thus comparing 64 bits
bytewise with zero (seems more likely to me. Also seems to work, but I doubt
many processors have an instruction like this.)

Please enlighten me, especially how you would handle this without the CMPBGE
instruction (provided CMPBGE works as I assumed above).

--
Volker Herminghaus-Shirai (vhs@rhein-main.de)

Computer industry: Industry in which the number of units sold of any
given product is inversely proportional to its technical excellence.
See also: MS-DOS, Windows, IBM-PC, X, QWERTY,
          80x86, TrueType, Survival of the shittest.
Newsgroups: comp.sys.next.advocacy
From: byer@adobe.com (Scott Byer)
Subject: Re: 64-bit CPUs (was DEC's alpha is "way fast")
Reply-To: byer@adobe.com (Scott Byer)
Organization: Adobe Systems Incorporated
Date: Wed, 18 Nov 1992 19:06:19 GMT

Joseph R. Grace <JGrace@TetraSoft.com> writes
In article <1992Nov18.012959.7716@netcom.com> abell@netcom.com (Steven T.  
Abell) writes:

>>  It's the misaligned case that's interesting. If Alpha has no sub-width
>>  reads or writes, I think this algorithm is much more complex than you
>>  indicate. You'll need to hang onto the previous read to construct the
>>  following write, or reread the previous chunk.

Like I said, with two additions shifts and an or you can do the general  
mis-aligned case, and that is the one with 9 instructions per 8 bytes  
moved.  You are putting together the 8 bytes shifted apropriate for an  
alignerd placement.  It does require a more complicated prolog, but the  
loop for most of the movement (on a long string, of course) remains fairly  
tight.  Still a win over the CISC architecture and a byte-by-byte move as  
a stated.

The inner loop becomes something like this:

	<preamble - precalculates the shift values, which are 8 *
byte misalignment between the pointers for R6 and 64-R6
for R7, plus precalulates the first levtover piece at the same time
it does the mask and assign of the first quadword.>

Loop:
        STQ     R3,0(R2)	; Store the alignment adjusted quadword.
        LDA     R2,8(R2)	; increment the to pointer
        LDQ     R4,0(R1)	; load the next quadbyte
	SLL	R4,R6,R3	; R6 pre-calculated in prolog as loop inv.
	BIS	R5,R3,R3	; or in the leftover piece from last iter.
	SRL	R4,R7,R5	; create this times' leftover piece
        LDA     R1,8(R1)	; increment the from pointer
        CMPBGE  R31,R3,R4	; check for null byte
        BEQ     R4,Loop		; loop

	<postamble - clean up by constructing the last assignment>


> Well, here's my guess....

Good guessing!

> ??      CMPBGE  R31,R3,R4   //  For( i=0; i<8; i++)  R4[ i] =  ! R3[ i];
> 			    //  long long R4 = (long long) R4;

Close.  It's more like (done with bit ranges):

for (i=0 to 8) { R4[i] = (R31[i*8+7 : i*8] == R3[i*8+7 : i*8]) }

I can't believe they stuck R31 as the zero register, can you?!?

You can see that R4 ends up with some very useful information for
doing the postamble quickly.  There are even two instructions, ZAP
and ZAPNOT, which directly take this number to do byte masking.

However, neat as this is, I still don't know how you would write
the C code to get the compiler to generate a good strcpy.  RISC
systems require extremely good compilers, and I haven't seen one
of those yet :-)

--
Scott Byer                             NeXTMail: byer@mv.us.adobe.com
Adobe Systems Incorporated               These are *my* opinions, and  
1585 Charleston Road, P.O. Box 7900        do not necessarily reflect
Mountain View, CA 94039-7900             the opinions of my employer.
---------------------------------------------------------------------
Newsgroups: comp.sys.next.advocacy
From: matthews@ecfa.jsc.nasa.gov (Michael C. Matthews)
Subject: Re: Where are they now?
Reply-To: matthews@ial7.jsc.nasa.gov
Organization: NASA/JSC Engineering Computation Facility
Date: Wed, 18 Nov 1992 04:46:18 GMT

In article <1992Nov17.212247.7109@osf.org> david@postman.gr.osf.org (David George) writes:
>In article <1992Nov17.094233.60912@cc.usu.edu>, slhw4@cc.usu.edu (Jason Hunsaker) writes:
>
>|> What ever happened to Steve Wozinak (sp?) co-founder of Apple?
>
>Left retarded after a plane crash Steve gave all his money away to
>pop stars and is currently working on a low component count 2 bit
>microcomputer.
>

Does that mean I'll be able to buy 4 of them for a dollar?  :-)
--
Mike Matthews, ex-Tether Dude +------------->   matthews@ial7.jsc.nasa.gov
"Had the Shuttle on a String"  \_ Now accepting NeXTMail via KlugeNet(TM)!
Lockheed-ESC                  |  
Houston, TX                   |          *** WILL HACK FOR FOOD ***
Newsgroups: comp.sys.next.advocacy
From: rpomeroy@aunext3.amd.com (Ron Pomeroy x(Coop))
Subject: Re: Need For Automated Programming? (Re: I Take It Back)
Reply-To: rpomeroy@aunext3.amd.com
Organization: Advanced Micro Devices, Inc.; Austin, Texas
Distribution: usa
Date: Wed, 18 Nov 92 14:55:14 GMT

In article <1992Nov18.021200.28714@leland.Stanford.EDU>  
gcolello@biosphere.Stanford.EDU (Greg Colello) writes:
>>In article <3745@news.cerf.net> billabs@nic.cerf.net (Bill Romanowski)  
>>writes:
>>> A few weeks ago I posted some gripes about NeXT. Well.....
>>> I've just completed a week at Dev Camp in Chicago. It was
>>> great++. The NeXT people were top notch and material presented
>>> was also of the highest quality. Ahhh! Enlightenment!!
>>> 
>>> The class contained no NeXT religion beyond what is embodied
>>> in design of the system software architects.
>>> 
>>> I now understand that the NeXT vision goes far beyond the physical 
>>> world of the machine. It'll be great when bigger/faster/better
>>> machines come out but after seeing it all more clearly, NeXTSTEP has 
>>> me re-thinking all aspects of how I design for -any- platform. 
>>> Everything else now seems years behind the times. 
>>> 
>>> Sorry NeXT, I take it all back.
>>> 
>>> bill romanowski
>>> prairie research
>>
>>Well it's sure nice to hear that the developer class is so good, but it  
>>reveals a problem too. It's hard to appreciate the programming aspects of  
>>the Next platform without taking a $1000 developer class (and that's just  
                                     ^^^^^
                                     Actually it's $1500.00 :-(
--
Ronald Pomeroy		[Objective-Cruntime: [Smalltalk runtime]];
Advanced Micro Devices	[self dream-on];
CAM Applications Group
rpomeroy@aunext1.amd.com (NeXTmail preferred)
Newsgroups: comp.sys.next.advocacy
Subject: Re: Byte unfairness(?)
From: <UD124895@NDSUVM1.BITNET>
Date: Mon, 16 Nov 1992 00:36:55 CST
Organization: North Dakota Higher Education Computer Network

BYTE is shooting 0 for 2 on the NeXT with their latest issue.  It has
a large section on Objects, and NeXT is only mentioned in a table
stating who the "major players" are.

What bugs me is that Apple and Sun have lengthy sections on their
object achievements(huh?) and future strategies.  NeXT has nothing
listed.  Some of the "new" innovations that Apple and Sun will have
real soon now have appeared in NeXTSTEP since 1988.......

What bugs me even more is the inability of most magazines to capitalize
NeXT correctly.

Matthew McCowan
LHCC/CCDP Data Manager (and unhappy Byte reader.....)
"Hope is where you find it"
From: abs0@coos.dartmouth.edu (Kelvin Leung)
Newsgroups: comp.sys.next.advocacy
Subject: Re: Byte silliness.
Date: 18 Nov 92 18:38:06 GMT
Organization: Dartmouth College, Hanover, NH

wilcoxt@cuug.ab.ca (Terrance Wilcox 260-8100) writes:

>I thought the Mac Quadra 950 had built-in video. Why did they buy a video
>card?

I didn't pay too much attention to that article.  However, I suspect 
they must have tested the Quadra with a 19"/20" monitor...

the Q950's built-in video cannot handle anything bigger than a 16" monitor,
if I remember correctly.

>Let's face it. I just don't understand the criteria.

don't know about the rest.

>Terry Wilcox

Yours sincerely,
Kelvin
e-mail: abs0@coos.dartmouth.edu

PS: the sad fact is that Byte used to be the defacto standard magazine
    for computer buffs... well... it seems their quality has gone down
    quite a bit since IBM PCs conquered the world. :(
From: fischer@iesd.auc.dk (Lars Peter Fischer)
Newsgroups: comp.sys.next.advocacy
Subject: Re: DEC's alpha is "way fast" according to WSJournal
Date: 16 Nov 92 22:43:46 GMT
Organization: Mathematics and Computer Science, Aalborg University


>>>>> "Charles" == Charles William Swiger (cs4w)

Charles> I don't see a major revolution occurring with the transition
Charles> between 32-bit and 64-bit processors because the computer
Charles> industry really hasn't max'ed out the possibilities of 32-bit
Charles> machines yet.  (How many people do you know have complained
Charles> that their machines can only address 4 gigs at a time?
Charles> Anyone ever seen a machine with more than 4 gigs?

I've seen Sun workstations with 512 M *RAM*. 1 G swap is not uncommon
for some tasks. VLSI simulations (for RISC chips, say) often run at
around 2 G these days -- and, yes, people are doing these things on
their UNIX workstations, not Crays. We regularly set up machines with
64 M for average stuff. 32 M should be considered common for a single
user machine these days.

The NeXTstation Turbo takes 128 M. This is only 4 G / 32. It is also
640k * 204. So, the maximum memory of the NeXTstation (a rather modest
workstation) is much closer to maxing out the 32-bit address space
than it is to the PClown limit, once considered more than anyone could
ever need.

/Lars
--
Lars Fischer, fischer@iesd.auc.dk | It takes an uncommon mind to think of
CS Dept., Aalborg Univ., DENMARK. | these things.  -- Calvin
Newsgroups: comp.sys.next.advocacy
From: jfr@RedBrick.COM ()
Subject: String moves/compares (was Re: 64-bit CPUs )
Organization: Red Brick Systems, Los Gatos, CA
Date: Fri, 13 Nov 1992 22:53:47 GMT

In article <1992Nov13.183026.29335@adobe.com> byer@adobe.com (Scott Byer) writes:
>Steven T. Abell writes
>
>>> Partially true.  The standard 'char' is 8 bits, and on a char-by-char
>>> basis, 32- & 64- bit processors tie.  However, a 64-bit processor
>>> can do >string moves and compares close to twice as fast as a
>>> 32-bit, other >things being equal.
>> No, they can't, in general. Please note that my comment is phrased
>> in terms of bus interfaces. Try doing a *general* full-width string
>> move where you often have unaligned data. i86s do it at a
>> substantially higher cost for unaligned data; 68Ks will do the
>> aligned cases only, and *crash* on the unaligned cases. There is
>> *no way* to correct this problem short of 8-bit comparisons. Without
>> a bus interface that none of the vendors seems to want to develop,
>> even a 16-bit CPU is no better than an 8-bit machine for these
>> problems.
>Pardon?  This is true only if you assume a brain dead strcpy
>algorithm.  An intelligent algorithm, which always grabs an aligned
>64-bit word, and uses masks for the beginning and ending can indeed
>run nearly twice as fast as the same algorithm on a 32-bit machine.
>There is no reason all the quad-words in the middle of the string
>can't be copied as is.

  I would concur with the last poster that a good algorithm should be
  able to take advantage of the word-aligned characters.  One question
  would be "At what point does the trade-off between doing the 
  necessary front and back masking, and just doing the byte-by-byte
  transfer occur?"  On the System 370, there was a similar question
  that I once analyzed between the costs of using an MVC (move chars)
  (which was super fast but only handled up to 256 characters) and
  setting up an MVCL (move chars long) which handled up to 16Meg
  character moves (and CLCL for compare chars long) but required
  several extra registers to set up and some special handling at
  the end.  It turned out that you could do 5 or 6 MVCs in the time
  it took to set up and perform an MVCL on a S/370 Model 168 but 
  when the 3033s and more powerful machines came along, MVCL would
  win out over MVC after 2.  

  Second question would be does guaranteeing that strings are
  word-aligned help in 32-bit and 64-bit processors?  Do compilers
  understand and generate good code for these situations?

  Jon Rosen
From: slhw4@cc.usu.edu (Jason Hunsaker)
Newsgroups: comp.sys.next.advocacy
Subject: Where are they now?
Date: 17 Nov 92 09:42:33 MDT
Organization: Utah State University

What ever happened to Steve Wozinak (sp?) co-founder of Apple?

What ever happened to Nolan Bushnell, original founder of Atari?

-----------------------------------------------------------------
Jason Hunsaker  -|-  Logan, Utah  -|-  Internet: slhw4@cc.usu.edu
Newsgroups: comp.sys.next.advocacy