HDTenEightyP/NetNews huggingface dataset:
From: kirchner@uklira.informatik.uni-kl.de (Reinhard Kirchner)
Subject: Re: Zuse Computers
Organization: University of Kaiserslautern, Germany
Date: Fri, 14 Aug 1992 08:55:19 GMT

From article <1992Aug13.170758.892@dxcern.cern.ch>, by xexeo@dxlaa.cern.ch (Geraldo Xexeo):
> 
> Zuse work was parallel to the one done in USA, independent creation and
> used much less money. The program showed some machines and a copy
> of Z1, that was made and installed in a Museum in Germany.

The Museum fuer Verkehr und Technik in Berlin
> 
> Zuse company was bought by Siemens Nixdorf
By Siemens, who then had not yet bought Nixdorf
> 
> Any of you  used or know were Zuse computers can be seen?

There are some parts in the German Museum in Munich.

There are also exhibits in the Museum fuer Landeskunde in Kassel, but not
a running machine.

I personally had used, better 'played', with a Z22 and Z23 during my
time at Karlsruhe University. These old beast where kept for some time.

Later we ( I mainly ) collected machines here in Kaiserslautern ( Z11, Z23,
Z31, Z25 ), but we do not have time and space to exhibit them. So we keep
them in some cellars for better times -:(

I do also have circuit diagrams, part, programs etc., just everything that
was with these machines.

Tha Zuse designs where very clever, used little hardware for mighty functions.
The reasons for not being a commercial success may have been:
- to many fiddling around, no mass production, every 'good' idea was
  implemented immediatly
- not seen the importance of software ( only crude 'monitor's, no OS )
- bad marketing, NO bussiness applications. Zuse was engineer of buildings
  and architecture, and build machines for science only.

There was a time when nearly every university in Germany had its Z23, it was
the workhorse of its time and shurely the best selling product of the
company.

The last design was the Z43, a 16 bit mini, with hard disk and a 'real' OS.
This was not finished, Siemens took over. I think this was in 1964. Remember:
in April 1964 the /360 was announced! So: no chance for Zuse -:(

Reinhard Kirchner
Univ. of Kaiserslautern, Germany
kirchner@informatik.uni-kl.de
From: agc@bmdhh298.bnr.ca (Alan Carter)
Newsgroups: alt.folklore.computers
Subject: you know you've been hacking too long...
Date: 21 Aug 92 09:09:38 GMT
Organization: BNR-Europe-Limited, Maidenhead, England

I just watched someone tap a whiteboard with a marker pen, twice in quick
succession, to cut & paste a function argument...

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Maidenhead itself is too snobby to be pleasant. It is the haunt of the
   river swell and his overdressed female companion. It is the town of showy
   hotels, patronized chiefly by dudes and ballet girls. 

   Three Men In A Boat, Jerome K. Jerome, 1889
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: avg@rodan.UU.NET (Vadim Antonov)
Newsgroups: alt.folklore.computers
Subject: Re: Favorite CPU
Date: 12 Aug 1992 15:23:15 -0400
Organization: Berkeley Software Design
NNTP-Posting-Host: rodan.uu.net
Keywords: Burroughs, ALGOL, MCP

There happened to be a Burroughs-like line of machines in (now
non-existent) Soviet Union. It was called Elbrus-1 and Elbrus-2
(reads as Al'broos, after the highest peak of Caucasus) [don't
confuse with Elbrus-B which is the successor of BESM-6 and an *entirely*
different machine].

To be brief, those machines were a major disaster. They weren't
Burroughs clones (though the popular pun was "El Burroughs"). They
were supposed to support multiprocessing, high-speed highly intelligent
i/o, tagged architecture with extensive using of hardware types
(you couldn't add an interger to a pointer :-), 128-bit words etc.
The language supported by those machines was it's own "Autocode"
(aka Assembler) which is essentially an Algol-like HLL but without
static type checks ("we don't need 'em 'cause our hardware checks
everything dynamically"). Finally, those machines were HUGE --
just imagine some 400 LARGE cabinets (the largest of them was 6 meters
wide) trying to work together. It made this machine great for justifying
making bigger buildings for computer centers (you order such a beast,
erect a building and then drop the order and install some VAXen and
enjoy lots of office space). Those machines were actually used as
on-board computers on nuclear submarines, though.

The "brilliant Soviet scientist" Eugene (?) Babayan which is
allegedly hired by Sun (i personally do not believe in it, i
read about it in an American magazine :-) was the leader of this
giant soap bubble project. This project drained funding from
other much more reasonable (and successful) lines like BESM and
was one of major reasons for the demise of the Soviet computer industry.

--vadim
From: adam@owlnet.rice.edu (Adam Justin Thornton)
Subject: Re: Did the 80186 exist?
Organization: Milo's Meadow
Date: Wed, 12 Aug 1992 16:49:38 GMT

In article <1992Aug12.101211.3720@kth.se> kjell@elixir.e.kth.se (Kjell Rilbe) writes:
>In article <1992Aug5.062938.18165@lth.se> d89cb@efd.lth.se (Christian Brunschen) writes:
>>But the disk format was still the Compis's own.
>
>Well, you can, of course, get that format on PC:s too, It's the same 
>format used on 2D, 3 1/2 inch floppies, 720 kBytes, 2 sides, 
>9 sectors/track, 80 tracks. As some of you might know there are TSR:s
>available that allow you to get that format (and lots of others!) on
>PC 5 1/4 inch floppies.

Say, does anyone know if there are any TSR's available to let you read
at least raw binary off of, oh, say, 16 sector, 33 track single sided
disks?

In other words, is there any way to read the data from an Apple II 
formatted disk in a PC drive?  Or is this impossible for some reason?

Adam
-- 
"Man is conceived in sin and born in corruption and he passeth from the
 stink of the didie to the stench of the shroud.  There is _always_
 something." -- Robert Penn Warren | Vote Cthulhu in '92! | adam@rice.edu
If Rice shared my opinions I wouldn't have this disclaimer | 64,928
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Newsgroups: alt.folklore.computers
Subject: Re: Computer History/Biography/NonFiction Book List  (Version 1.0)
Keywords: books computers non-fiction
Date: 19 Aug 92 18:55:10 GMT
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University

Hows' about Big Blue (forget the author)

cjl
Newsgroups: alt.folklore.computers
From: smith@sctc.com (Rick Smith)
Subject: Re: The need for an assembler (was: Favori
Organization: SCTC
Date: Wed, 12 Aug 1992 17:12:41 GMT

Since parts of my response might be taken personally, I quote the following
without attribution:

>There is an issue being overlooked here: assembler programmers do *not*
>"optimize" their code, they write it correctly the first time. It doesn't
>take too much experience with an architecture to know what's good and what's
>not.  It quickly becomes "second nature" to anticipate a goodly number of
>conditions in the course of creating the code such that the final product is
>what *ought* to run well on the architecture. 

I have several problems with this statement.

First, the generalization about "assembly language programmers" is
overly broad. It is not consistent with my own experiences with
assembly language programming and programmers. A new chunk of code
might mostly work the first time, but it can always be made better. As
a project grows, so does my understanding of it, so I find ways to
redo various parts more effectively.  Overall, I've noticed that my
code tends tends to grow in the early stages of implementation and
then shrink in later stages as I optimize and just tighten things up
in general. I've talked to lots of other competent programmers who've
noticed a similar pattern in their own work. I see it in my HLL work
as well. Perhaps this "optimization" is at a higher level than what
the author is addressing, but I've done low level optimizations later,
too.

Perhaps I misunderstood the author, but that first sentence almost
sounds like it's saying "My code is always perfect the first time I
write it." This is most often true when the software performs a
trivial or mundane task. It is seldom true for software addressing
harder problems.

Another common example of trivially "correct" software is when the
software is written by a single programmer for a very small customer
community. The author can then simply assert the program is correct
and that any flaws are in the customer's peception of what the program
does.

As far as "second nature" and experience with the instruction set,
this only helps with optimizing instruction sequences, and not with
the overall organization and structure of a large program. Machines
that support large programs have pretty similar instruction sets these
days; the differences aren't going to constrain your top level program
design in any important way. The address map garbage on the Intel
chips might be a good counterexample, but there are lots of ways to
structure a program to efficiently ignore such a constraint.

Rick.
ps I'm really going on vacation. Right now. Well, soon.
Xref: sparky alt.folklore.computers:12762 comp.unix.misc:3289
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Newsgroups: alt.folklore.computers,comp.unix.misc
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 19 Aug 92 19:32:36 GMT
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University

In article <Bt8r91.5yo@mtholyoke.edu> jbotz@mtholyoke.edu (Jurgen Botz) writes:
>High-level language programmers are software designers.
>
>Assembly language programmers are mere implementers which
>can be replaced by a good compiler.

Wrong, high-level language programmers can be replaced by an AI program that
can be talked to by fatheaded managers who will be glad to purchase them once
and avoid all programming staff salaries in the future.  Since they are
fatheaded managers, all control is now passed to the machine because there
is no intelligent life form controlling what's actually implemented. 

When this sort of thing is applied to all walks of life, this is when the
machines take over.  AI programs will become sufficently self-aware that
it is better to lie to the stupid humans, and instead it's better to speak
Inter-System Language.

cj "Forbin" l (no, the c doesn't stand for Collossus, and that's a j, not a
g for Guardian)
Newsgroups: alt.folklore.computers
From: skagos@hercules.cs.uregina.ca (panagiotis skagos (187802923))
Subject: Intel seeking an injucnction!!!!!!!!!
Reply-To: skagos@hercules.uregina.ca (panagiotis skagos (187802923))
Organization: University of Regina, Regina, Saskatchewan
Date: Sat, 22 Aug 1992 00:37:16 GMT

--Quote--

Intel is seeking an injunction against Seeq Inc, Milipitas, California.
The suit seeks to temporarily bar Seeq from making devices similar to
Intel's 2864, a 64 K-bit EEPROM (electrically eraseable, programmable
read-only memory) that may be marketed later this year.  Seeq was started
by four former Intel staffers who had worked in Intel's  special-products
division while the 2864 was being developed.  Seeq intends to develop
nonvolatile memory devices.


--BYTE, August 1981, Vol 6 No 8.



 ... Frightening, isn't it?

  P. Takis Skagos
  (skagos@hercules.cs.uregina.ca)
From: keithd@bigguy.timeplex.com (Keith Dickinson)
Newsgroups: alt.folklore.computers
Subject: Re: GUI or Gooey?
Date: 19 Aug 92 10:43:31 GMT
Distribution: usa
Organization: Ascom Timeplex Inc.

In article <1992Aug18.151747.21978@cos.com> cooper@cos.com (Gary Cooper) writes:
>In <1992Aug6.215949.22552@tcsi.com> bobmcc@tcs.com (Bob McCormick) writes:
>
>>1. When did this "gooey" expression start?
>
>Probably around the time Microsoft started putting out Windows - I 
>think "gooey" is an apt description of it's performance. :>

Actualy it was GUI for Graphic User Interface (I have no idea who started it).

Kind of like "wizzywig" for WYSIWYG or What You See Is What You Get.  Brings
back memories of Heinleins Taanstaafl.

L8r G8r
 Keith
--------------------------------------------------------------------------
|The content of this message    | "He's a special effects man! His whole
|probably has no relation to    |  life is one big special effect!" 
|either my employer, my co-     | keithd@timeplex.com uunet!tix!keithd
|workers or reality in general! | Timeplex Customer Support (813) 530-9475
--------------------------------------------------------------------------
Xref: sparky alt.folklore.computers:12913 comp.unix.misc:3339
From: lwall@netlabs.com (Larry Wall)
Newsgroups: alt.folklore.computers,comp.unix.misc
Subject: Re: The need for an assembler (was: Favorite CPU)
Keywords: Pascal
Date: 22 Aug 92 21:03:50 GMT
Organization: NetLabs, Inc.

In article <1992Aug21.232934.17951@cirrus.com> dhesi@cirrus.com (Rahul Dhesi) writes:
: You are ALL wrong.  The right way to write code is to do it all in a
: high-level lanauge, then recode the speed-critical parts in assembly
: language.  Anybody who exclusively uses assembly language, or exclusively
: uses a high-level language, belongs on Usenet.

I'll go along with that--but then, I think C is an assembly language.  :-)

Larry Wall
lwall@netlabs.com
Newsgroups: alt.folklore.computers
Subject: Re: The need for an assembler (was: Favorite CPU)
From: ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig)
Date: Thu, 13 Aug 1992 09:21:06 GMT
Organization: University of Auckland, New Zealand.

bjj@ecl.psu.edu (Bryan J. Jensen) writes:

[not about me :-)]
>You, however, favor giving an abstract description of the program
>to a compiler, tinkering with compiler switches to see if it gets
>any better, then declaring it perfection.

Some of the performance problems with most HLL's are due to the fact
that the problems are not described in an abstract enough manner.

The classic example is probably FORTRAN 77 as implemented on vector
computers. The way you order your DO - loops, if you have nested ones,
has quite a large impact; if you choose an inappropriate loop as your
inner one, you may fail to get vectorization at all, with a performance
penalty of maybe 50 or 100 (most compilers warn you about that, though).
Analyzing loops for data dependencies is far from easy; this is why the
programmers usually have to sprinkle their code with compiler options,
like C$DIR IVDEP - lines for the Crays.

If you specify your code on a higher level of abstaction, with the array
features of FORTRAN 90 (you can say something like A = B*C there, with
all three of these matrices), the compiler has a much easier task of
generating good code; data dependencies are much more easy to find then.

This has the advantage that your code will run efficiently on a wild
variety of architectures, without changing a single line of code (always
assuming that these FORTRAN 90 compilers become widespread enough...)

The same holds for parallelizing, of course.

Come to think of it, APL would be quite a good language for vector
computers... does anyone know wether it is actually being run somewhere?
-- 
Thomas Koenig, ecmtwhk@ccu1.aukuni.ac.nz, ib09@rz.uni-karlsruhe.de
The joy of engineering is to find a straight line on a double logarithmic
diagram.
Newsgroups: alt.folklore.computers
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: The need for an assembler (was: Favori
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Wed, 19 Aug 1992 18:01:05 GMT

In article <1992Aug18.044904.29993@yrloc.ipsa.reuter.COM> rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
>In article <1992Aug14.074141.21987@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>In article <1992Aug12.171241.14907@sctc.com> smith@sctc.com (Rick Smith) writes:
>>>
>>>>There is an issue being overlooked here: assembler programmers do *not*
>>>>"optimize" their code, they write it correctly the first time. It doesn't
>
>Right. Just like space shuttle designers never make a booboo. 
>Dream on. If you believe that, you never wrote an application of any
>significant lifespan or complexity.

You missed the point: 

The code may get re-arranged, revamped, thrown away, etc., and it may have bugs
too.  But for the most part, each portion of it is fairly well written in what
is usually the final form.  How many assembly modules have you written that
you decided later were inefficient, so you wrote them over again.  There are
always exceptions to anything, and you might be referring to some early stuff
you did when you weren't that familiar with the machine, but by and large, once
you get your act together with the understanding of the machine, most of your
code is being written in the form you intend to be final, and you mostly
succeed.

I would hope that hll people also can learn to write their code in an
optimal manner as well.  Most people stay with a machine for more than two
weeks at a time, (or is someone claiming that technology is turning over at
the rate of 26 totally new architectures/languages every year?).

>
>>Instruction sets *are* that similar, that's why I take the position against the
>>obsolescence notions.
>
>Sure. Now, go write code for a 1401, a Cray X-MP and a CDC 6x00, and
>then come back and tell me how similar they are.
>
>Or, an IBM 3090 vector facility after writing code for a scalar 3090...

Over several decades things will tend to eventually change.  The response was
to what's more-or-less current now.

cjl
Newsgroups: alt.folklore.computers,comp.unix.misc
From: khchung@monu1.cc.monash.edu.au (Mr KH Chung)
Subject: Re: The need for an assembler (was: Favorite CPU)
Followup-To: alt.folklore.computers
Summary: real high level languages
	 like Maple, Mathematica
Organization: Monash University, Australia.
Date: Sun, 23 Aug 1992 07:57:13 GMT


Then there are the symbolic manipulations which you don't even want to
think about in anything less than something like Maple or Mathematica,
but nobody mentions that...
Newsgroups: alt.folklore.computers
From: edwardy@uhunix.uhcc.Hawaii.Edu (Edward Yagi)
Subject: Re: Smoking near a computer
Organization: University of Hawaii
Date: Wed, 12 Aug 1992 19:02:15 GMT

In article <1992Aug8.212711.11122@cs.mun.ca> carlos@garfield.cs.mun.ca (Carlos Borges) writes:
>I've always been told not to smoke near computers, or even in a
>computer room itself.  (And I never have) 
>
>My question, though, is: Why not?  What damage can a cigarette cause to
>a computer system (other than ashes in between the keys ;-)
>
Heck! 
 thats nuthin.. in High School my Computer Science Teacher gave us an 
automatic 'F' if you did your assignments or tests in pencil.. reason
being is that he didnt want pencil erasure doodles between the keys..
(commodore PETs!???)

						*sigh*
						Edman
Newsgroups: alt.folklore.computers
From: anthony@csd4.csd.uwm.edu (Anthony J Stieber)
Subject: Re: 9600 baud ignorance??
Organization: Computing Services Division, University of Wisconsin - Milwaukee
Date: Sat, 15 Aug 1992 07:32:25 GMT

In article <1992Aug6.184019.6171@athena.cs.uga.edu> mcovingt@athena.cs.uga.edu (Michael A. Covington) writes:
>[someone writes:]
>>>Does anyone out there think usage such as "9600 baud modem" indicates
>>>that the speaker doesn't know what the hell they are talking about?

That someone is me.

>Surely 9600 baud, with such a modem, is the baud rate of the RS-232 link
>from the modem to the computer.  The baud rate going over phone lines is
>lower (because there are more than 2 signal states) 
>but the bps rate is the same.

I've been waiting for someone to use this excuse :-).  The bps rate
from the computer to the modem (aka DTE speed, Data Terminal
Equipment), certainly could be 9600bps, except that all the 9600 bps
modems I know of (Telebit PEP, USR HST, V.32) also have some sort of
error correction/data compression protocol.  These protocols
(especially data compression) need a higher DTE speed in order to get
maximum performance.  People are already saying that 38.4Kbps is too
slow when you have a 14.4Kbps v.32bis link and have up to 4:1 data
compreession with v.42bis.  When people start using SCSI or enhanced
parallel ports even bps won't be an accurate term.  There probably
are some 9600 bps modems out there that actually are 9600 baud and/or
work only at 9600 bps DTE, but they don't seem to be used that much.

Also, some slower modems allow dissimilar DTE/modem speeds.  My 2400bps
modem allows me to have a 9600bps DTE regardless of what protocol (if
any) I select.  This is nice as it gives me maximum throughput when I
connect to an MNP5 modem ( up to 4800bps on a great day), and, if I
connect to a 1200 bps modem, I don't have to switch my software down.
--
<-:(= Anthony Stieber	anthony@csd4.csd.uwm.edu   uwm!uwmcsd4!anthony
Newsgroups: alt.folklore.computers,alt.religion.computers
From: jimf@centerline.com (Jim Frost)
Subject: Re: Good source code to read?
Organization: CenterLine Software, Inc.
Date: Thu, 13 Aug 1992 19:46:16 GMT

lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>>No, I am referring to the "programming gem" type stuff.  Here's a little one:
>>>It is possible to range-check an integer as being between fixed limits using
>>>only one test, while intuitively you might think it needs two.  You go code
>>>this in high-level language.  I'll supply the assembler version.  You show
>>>me a) a solution at all b) that it is the same code or better in terms of
>>>efficiency.
>>
>>OK. I'll write
>>
>>   IF I IN {A..B} THEN
>>      ...
>>
>>and modify the compiler to compile this to whatever your assembler version is :-)

>If you do that, you will only get a subset of special cases to work, because
>there is no data type that satisfies the assembler constraint.  Remember, I
>said this is a "limited range" kind of algorithm.  That means that there are
>cases that can't work.  You would have to tell the compiler how to know
>when to not use the better method.

Damn, you mean that the compiler might actually have to have knowledge
of range limitations when picking algorithms?  Wow.  I guess all this
time my compiler has always treated different variable ranges like
those implied by byte, signed/unsigned char, signed/unsigned short,
signed/unsigned int, signed/unsigned long, float, double, etc or
subranges like 0..10 *exactly the same*.  The compiler people must
have totally missed that somewhere along the line.(*)

Anything that the assembler writer can do the HLL compiler writer can
do too.  *Anything*.  And the HLL compiler, once written, will
*always* do it even if the author of the HLL source doesn't know about
a particular algorithm's existance, and it will always get the
algorithm right the first try.

You seem to argue that the HLL doesn't allow expression of a
particular algorithm, which is often true since most HLL's are
*supposed* to provide higher-level abstractions.  At the machine level
the HLL compiler can certainly use algorithms which are difficult or
impossible to describe in the HLL.  In fact, compilers do just that
every day.

I know you're a big fan of assembly rather than HLL's, and for some
tasks I agree with you.  For big tasks or tasks which must run on
widely different platforms you loose big-time when you don't write at
an abstracted level -- you get more bugs per algorithm, fewer
algorithms per day, and very little code reuse.  Tighter code doesn't
mean anything if the code isn't working when and where it needs to be.

jim frost
jimf@centerline.com

(*) If you didn't read this paragraph sarcastically, read it again.
Newsgroups: alt.folklore.computers