HDTenEightyP/NetNews huggingface dataset:
From: jimf@centerline.com (Jim Frost)
Newsgroups: alt.folklore.computers,comp.unix.misc
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 15 Sep 92 15:40:50 GMT
Organization: CenterLine Software, Inc.
NNTP-Posting-Host: 140.239.3.202

peter@NeoSoft.com (Peter da Silva) writes:
>In article <1992Sep15.074843.25871@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>> That's fine; also maybe their performance expectations as to effective machine
>> speed are virtually non-existent.

>Last I checked, most UNIX workstations and minicomputers are significantly
>faster than IBM-PC clones. There's a technical point for you.

Let's clarify "significantly" for him.

The newest 486's are about up to the speeds that Sparcs were at two
years ago (note that the Sparcs were three to five times as fast as
the fastest x86's as far back as 1988) and the MIPS chips were four
years ago.  They are currently running about half the speed of the
RS/6000, no more than a quarter of the speed of the new sparcs, and a
fifth of the HP 700 series and a tenth of the speed of the upcoming
Alpha.

In the workstation world we don't bother quibbling about incremental
percentage improvements.  Double it or don't talk to me.  Most of the
time the hardware guys nearly triple it.

The Intel guys have been doing pretty well at boosting the x86
architecture (much like their VAX designer counterparts) but they lag
some three to four years behind the production systems of workstation
vendors.  The upcoming P5 will probably correct this, but from all
reports existing code will not realize the benefits of the speedup
without at least a recompile.

On the HP 700 even badly written HLL code outperforms the tightest
possible x86 assembly running on the fastest available x86 platform.

Happy hacking,

jim frost
jimf@centerline.com
Newsgroups: alt.folklore.computers
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: The need for an assembler (was: Favorite CPU)
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Tue, 8 Sep 1992 09:05:11 GMT

In article <O7ZIWJC@taronga.com> peter@taronga.com (Peter da Silva) writes:
>In article <1992Aug31.050254.12657@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>In any case, the point was made abundantly clear: there are untranslatable
>>features expressable only in assembler.
>
>Some languages allow access to any machine code instruction from quite a high
>level (A-Natural, the C variant on the Bellmac-32, any Forth worth using),
>and other high level languages allow access to any machine facility (PL/M,
>for example, is about the same level as C and provides direct access to all
>80x86 capabilities).

This is quite true, however must be taken literally, and not for what you
intend to distort it into:

Yes, you can *access* the capabilities, an oversimplification is to claim
that BASIC can *access* *anything* using PEEK and POKE.  But what's wrong
is that you have to call closed assembly-language-written functions to allow
certain structures to be expressed, since C doesn't have the means to
express the actually running code.  Sloppy mathematically "equivalent" code
doesn't count here.  Assembler can do well what C can express sloppily in
certain cases.  But what you say is usefully true: *any* language can
call assembler-written routines that may be a better place to have something
done that's either damn near impossible, or grossly inefficient, or merely
just enough better that you really want to consider it.  

This minimal part of what you say isn't new.  There have been languages 
around for years that specify such things as "external sort" routines because
while you can express certain algorithms in the hll, you can't get the
performance you deserve.  And generally, this is the "just enough better"
kind of case; this doesn't address the first two, more important types of
cases.

cjl
Xref: sparky alt.folklore.computers:13657 comp.unix.xenix.misc:183
Newsgroups: alt.folklore.computers,comp.peripherals,comp.unix.xenix.misc
Subject: Unix on tired iron - info needed about Altos box
From: lesley@cavebbs.welly.gen.nz (Lesley Walker)
Date: Sun, 06 Sep 92 02:01:38 GMT
Followup-To: comp.peripherals,comp.unix.xenix.misc
Organization: The Cave MegaBBS, Public Access Usenet, Wellington, NZ

sarr@sinshan.citi.umich.edu (Sarr J. Blumson) writes:
>
>In 1982 we were running Xenix on 8086 boxes from
>Altos (with an Altos proprietary memory manager) and their own UNIX
>port on the Onyx Z-8000 machines mentioned earlier.  Both were 512k
>machines, and both worked well.

That first one sounds like a machine I am currently trying to repair.

Does anyone have any technical information about the Altos 586?

My immediate problem is with the floppy drive.  I bought a replacement
floppy drive for the one that died while I was trying to replace the
crashed hard disc... 

The good news is, it is possible to boot up from the new floppy. 

The bad news is, the system will only read from the floppy if the drive is 
already spinning when the read attempt is made.  Eg, the first boot attempt 
fails, but the second works, as long as the second attempt starts while the 
floppy is still spinning from the previous attempt. 

The question: Is there some way I can wire up the floppy drive so that the 
motor is always spinning as long as the power is on?  (I realise this is a 
horrible solution, but it's the easiest I can think of) 

Or is there some sort of Drive Ready signal that I can fake somehow? Would 
any of the jumpers on the drive have anything do with it? 

The drive is 5.25" quad density made by Mitsubishi and it has jumpers on it
labelled MX, HS, HM.  There is a jumper in the HS position.


(I have cross-posted, and redirected followups to comp.peripherals and
comp.unix.xenix.misc, as this hardly qualifies as a folklore question)

Replies by email would be appreciated, as the system I am posting from
expires articles *very* quickly and I could easily miss something important.


-- 
  -=- The Leather Goddess (aka Lesley Walker) -=- Wellington, New Zealand -=-
        lesley@cavebbs.welly.gen.nz                      Vote for MMP!
   DoD#258 -=- Yamaha XV1000 -=- Yamaha XS650 -=- Ford Cortina -=- Altos 586
Newsgroups: alt.folklore.computers
From: jeremy@sw.oz.au (Jeremy Fitzhardinge)
Subject: Re: Renumbering BASIC programs (was Re: Branching in HLL vs. Assembler)
Organization: Softway Pty Ltd
Date: 14 Sep 92 06:19:17 GMT

In <1992Sep11.234844.29705@dscomsf.desy.de> hallam@zeus02.desy.de (Phill Hallam-Baker) writes:
>Yes but you miss the point of the "one touch keystrokes" it was purely because
>the intepreter on the ZX80 was too small to be able to include a proper parser,
>or even a tokenizer. So the "one touch" idea was born! Most people who used it
>probably never realized that the idea was to make things easy for the
>programmer!

Well, it was a "proper parser", its just that tokens were only 1 byte.  With
memory being so short, there sometimes wasn't room for a whole expanded token.
The memory scavenging techniques for video on a 1k '8[01] have been covered here
before.

	J

--
jeremy@sw.oz.au ph:+61 2 698 2322-x122 fax:+61 2 699 9174
The pumpkin.  The sheep.  My brother's wife.
Newsgroups: alt.folklore.computers
Subject: automatic CP/M to MS-DOS migration?
From: ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig)
Date: Sun, 6 Sep 1992 02:11:33 GMT
Organization: University of Auckland, New Zealand.
Keywords: assembler, 8080, 8088, 8086

If I remember correctly, one of the points in favour of MS-DOS 1.0 when
it was introduced was the easy porting of CP/M software (^Z as end of
file marker, COM - files, file control blocks).

Just how far was this automated? Are 8080 and 8086 related closely enough
that you could write an assembler which translated 8080 assembly into
8086 code? Was this how, for example, WordStar was ported?

Speaking of WordStar, a friend of mine had recently generated a 2
megabyte text file of experimental data, directly from the data
aquisition, under MS-DOS. After much cursing ("What? You can't load that
into the Turbo Pascal editor???") he finally wrote an utility to split
it up into many, many small pieces. I suppose WordStar would have been
able to handle that file, but not many more editors under MS-DOS :-)
-- 
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.
From: barmar@think.com (Barry Margolin)
Newsgroups: alt.folklore.computers
Subject: Smileys make the mainstream press
Date: 16 Sep 1992 04:02:44 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
Distribution: world
NNTP-Posting-Host: gandalf.think.com

The September 15 Wall Street Journal has a front-page article on the use of
smileys in computer conferencing.  It was pretty well written.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: alt.folklore.computers
Subject: Famous Quote on Unix Philosophy
From: gnat@kauri.vuw.ac.nz (Nathan Torkington)
Date: Sat, 12 Sep 1992 01:59:50 GMT
Reply-To: Nathan.Torkington@vuw.ac.nz
Followup-To: poster
Distribution: alt
Organization: Contract to CSC, Victoria Uni, Wellington, New Zealand

I would like the famous quote on Unix philosophy that goes along the
lines of "you've got to let them cut their throats if you want them to
do anything useful" (or words to that effect).

Please don't post the quote - this group has enough fluff already,
without this oft-rehashed quote being posted twelve more times.  Send
it via e-mail please.

Nat.
(gnat@kauri.vuw.ac.nz)
Xref: sparky alt.folklore.computers:13747 comp.unix.misc:3574
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: 8 Sep 92 09:21:50 GMT
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University

In article <liam.06m7@durie.amigans.gen.nz> liam@durie.amigans.gen.nz (Liam Greenwood) writes:
>In article <1992Sep4.042704.21287@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>The non-portability of code to incompatible architectures is well known and
>>usually an acceptable tradeoff to writers of assembly code.  The previous
>>poster was attempting to take a pile of nits and claim incompatibility as
>>opposed to a readily adaptible situation it actually is.
>>
>        #include <stdio.h>
>        #include <stdlib.h>
>
>        main()
>        {
>            puts("Hello World!");
>            return(0);
>        }
>   O.K. then, the above code put onto some machines say... RS/6000, some
>IBM PC or clone therof, Amiga, NCR Tower, Unisys 1100/2200, U6000, some
>CP/M machine, really anything with a K&R C or ANSI C compiler. Compile it
>and it will run. Please show us the code to do this on the above list of
>machines in assembler.

The mere fact tht you even believe that this is the crux of any useful
argument for/against assembler proves that you don't understand the
thread on this newsgroup.  Assembler is not meant to make the trivial
part of a program be any easier.  On each and every machine, the purpose
of assembler goes miles beyond any knowledge that it would take to produce
trivial non-sense like that.  It is a given that on each machine the 
solution to the problem will be as trivial as the C code you give, and
admittedly all incompatible with each other.  But the key point is that
it *is* trivial in each case.  Assembly is to be used for special-purpose
routines such as *efficiently* implementing real-time drivers, interrupt
handlers, co-routines, and general speed-improvement of time-critical or
oft repeated coding that literally cannot be expressed in hll.  Yes, in
some you can create a *semblance* of the same thing, but it's not the
same, merely a poor-performing "mathematical equivalent" of the assembler
routines.  And some of these assembler jobs literally are inexpressible in
many hll's.  Some hll's, however can *call* the routines, because they are
provided by the vendor *and written in assembler*.

Please follow the thread, people.  Randomly lashing out at misinterpretation
of what's happening here is just wasting bandwidth, including this
explanation of why the post is off the subject.

cjl
From: saustin@bbn.com (Steve Austin)
Newsgroups: alt.folklore.computers
Subject: Re: Better dead than IBM
Date: 5 Sep 1992 14:48:15 GMT
NNTP-Posting-Host: bbn.com

pdt@munta.cs.mu.OZ.AU (Peter David THOMPSON) writes:

>What about "I've Been Munged"?

A friend of mine worked in a Arabic-speaking country and said that
the government departments were said to work on the IBM principle. 
This was (with wildly inaccurate spelling/translation):

	Intshala		God willing, it may happen
	Bacara			... Tomorrow
	Malesh			... Perhaps

	Steve Austin
Newsgroups: alt.folklore.computers
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Subject: Re: Undocumented (mis-)operation codes
Date: Mon, 14 Sep 1992 14:27:19 GMT
Organization: University of Iowa, Iowa City, IA, USA

I've recently been trying to figure out what the PDP-8/E RAR RAL and RTR RTL
operations do.  They're officially "reserved for future expansion" or some
such, and looking at the CPU schematics, odd things show up.

Background:  The PDP-8 has one instruction, OPR, opcode 7 (octal) that allows
for a variety of microcoded operations.  There are bits for clearing the
accumulator, complementing the accumulator, incrementing the accumulator, and
things like that.  Three of the bits are RAR RAL TWICE -- rotate accumulator
right, rotate accumulator left, and double the shift count.  The following
interpretations of these bits are "official" on the PDP-8/E:

	000 - do nothing
	001 - swap bytes in the accumulator
	010 - rotate accumulator left one place
	011 - rotate accumulator left two places
	100 - rotate accumulator right one place
	101 - rotate accumulator right two places

This leaves two undocumented combinations

	110 - rotate left and right one place
	111 - rotate left and right two places

In fact, on some models of the PDP-8, they did something like what I've
mentioned above, but on the PDP-8/E, 110 uses a data path that's normally
used for the logical AND instruction, it ands AC with the contents of the
memory buffer register (the contents of MB got set somewhere in the past,
but not by this instruction), and 111 uses a data path used in effective
address computation, but with large parts of it disabled because it's used
at a time in the instruction execution cycle when those parts aren't active.

So, does anyone know what 110 and 111 do, from a user's viewpoint, on a
PDP-8/E?

				Doug Jones
				jones@cs.uiowa.edu
Newsgroups: alt.folklore.computers,comp.unix.misc
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: The need for an assembler (was: Favorite CPU)
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Tue, 15 Sep 1992 10:23:42 GMT

In article <id.__2T.SWB@ferranti.com> peter@ferranti.com (peter da silva) writes:
>In article <1992Sep8.093152.15699@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>> would believe the mess of existent problems there are.  I suspect that
>> most readers on this group have insufficent "broad" experience to appreciate
>> just how bad this problem can be, especially with a program such as Kermit
>> that reaches into so many "corners" of a system all at once.
>
>What? Kermit doesn't reach into so many corners of a system. It talks on
>precisely two I/O streams, both of which are handled by the O/S. It's a
>*simple* program compared to most of the stuff I use. Even on DOS I've
>written a more complex terminal emulator (handled 2 ports concurrently
>on seperate scrolling windows on an 8088, in 64K total, in 99% C: I had
>to do some assembly for the interrupt handlers).

That gross oversimplification paints an untrue picture of the problem of
realistically getting it to work correctly.  Lotsa stuff just doesn't work.
Furthermore, that's not specifically true either, since C-Kermit on unix does
outgoing Kermit as well.  A terminal emulator is a pale subset of a sliding
windows Kermit; do you seriously want to hold up that puny an example to
give us a "feel" for what needs to be done within a successful Kermit?

>
>CKermit isn't that well designed a program, but even so out of 185 conditionals
>126 of them are in the terminal I/O code. Most files have just a single #ifdef
>for old compilers that didn't define NULL! I don't see how you can say it's
>"mostly" conditional.

I never gave a percentage of conditionals as bulk of source.  The point is
that there are incompatibilities of implementation, especially for such odd
cases as demented Microsoft compilers, etc.

>-- 
>Peter da Silva                                               `-_-'
>Ferranti Intl. Ctls. Corp.                                    'U` 
>Sugar Land, TX  77487-5012
>+1 713 274 5180                                   Har du kramat din varg idag?

cjl


Newsgroups: alt.folklore.computers
From: rlw@IDA.ORG (Richard Wexelblat)
Subject: Re: Who invented the digital computer
Organization: IDA, Alexandria, VA
X-Newsreader: Tin 1.1 PL4
Date: Tue, 8 Sep 92 17:45:47 GMT

Nevertheless, Babbage certainly was [appears to have been] first with a
lot of the basic concepts.

But there is something missing in several of the postings on this issue:
	Eckert&Mauchley, von Neumann, Atanasoff, etc. are all in the
	domain of the ELECTRONIC digital computer.

Relay digital computers came first and none of the above (I believe) had
anything to do with that.

So far as I'm concerned, the big issues that will not be definitively
solved in my lifetime, if ever, concerns the stored program concept.
The majority stil support von Neumann, but from what I've heard, I'm in
the Mauchley camp.
-- 
--Dick Wexelblat  (rlw@ida.org) 703 845 6601
  This message is not copyright.  Please feel free to use it
  in any context, at any time, with or without attribution.
  Quotes out of context and parodies are encouraged.
Newsgroups: alt.folklore.computers
From: morris@grian.cps.altadena.ca.us (Mike Morris)
Subject: Re: Renumbering BASIC programs (was Re: Branching in HLL vs. Assembler)
Organization: College Park Software, Altadena, CA
Date: Wed, 9 Sep 1992 17:10:16 GMT

jimf@centerline.com (Jim Frost) writes:

>ttak@troi.cc.rochester.edu (Tim Takahashi) writes:
>>>The second BASIC I used did not store the program in
>>>ASCII, but rather in an undocumented tokenized form.  I think they provided
>>>a RENUM command (but I don't remember).
>>>
>>>	Bonus:  guess the BASIC's.

>>(2) Microsoft Basic (or a derivative thereof) - Altair 8k Basic, Radio Shack
>>      Level II Basic, Applesoft Basic, etc. all used the tokenized form.

>So did most other versions, such as the Atari and Commodore BASICs.
>Even the IBM Datamaster BASIC was tokenized.  MS's BASIC derivatives
>were certainly pervasive but they weren't the only ones who used
>tokenization by any means.

>I could see his BASIC being from the TRS 80 I or II (both of which had
>RENUM if I remember right) but it certainly wasn't Applesoft; you
>needed to load a special program to get renumbering under Applesoft
>(and the renumbering program had some nasty bugs that would
>occasionally trash your BASIC program).  I can't remember for sure but
>I'm almost certain the CP/M MBASIC didn't have RENUM either.

It did.  And also the MBASIC for MS/PC DOS used the same tokenizing as
the MBASIC for CP/M - I was able to move several tokenized programs over 
from my IMSAI to my XT using a serial connection and two comm programs.
Funny - they ran slower on the 6mhz XT than on the 4mhz Z80.

-- 
Mike Morris   WA6ILQ   | This space intentionally left blank.
PO Box 1130            | 
Arcadia, CA. 91077     | All opinions must be my own since nobody pays
818-447-7052 evenings  | me enough to be their mouthpiece...
Newsgroups: alt.folklore.computers,comp.lang.c
From: rob@guinness.eng.ohio-state.edu (Rob Carriere)
Subject: Re: bogosort revisited (No longer with source -- valuable trade secrets at risk)
Organization: The Ohio State University Dept of Electrical Engineering
Date: Thu, 10 Sep 1992 06:56:14 GMT

In article <1992Sep10.024031.4524@monu6.cc.monash.edu.au>
parry@yoyo.cc.monash.edu.au (Tom J Parry) writes: 
>Rob Carriere (rob@guinness.eng.ohio-state.edu) wrote:
>>I don't understand.  This sort can take forever[1].  Therefore, the worst case
>>bound is O(\infty).  How much worse can you do than that?  :-)

>Yes, but most discussion here has been about BEST case complexity not
>worst. Believe it or not, some algorithms have been posted with o(n^2!)
>best case complexities (or something like that).

OK, that's a good point.  

>Also, just doing an infinite loop and waiting for bit rot is a little
>suspect. I do believe we are talking about an algorithm, one that does
>something, with an intention to sort - even if that intention is very
>deeply hidden.

Hm.  The loop that inspired my post (random sort) was not necessarily
infinite, and the algorithm _did_ attempt to sort, albeit in a rather unsorted
fashion.  :-)

SR
---


Newsgroups: alt.folklore.computers,comp.windows.misc,comp.windows.x,comp.human-factors
From: bzs@ussr.std.com (Barry Shein)
Subject: Re: GUIs Considered Harmful
Organization: The World
Date: Sun, 13 Sep 1992 01:29:20 GMT


If you have a good quality photocopier you can photocopy optical mouse
pads and use that. Someone recently posted a postscript program for
producing optical mouse pads. Some of them will work on well-worn
denims.

Not an opinion one way or the other, but I've always found that
amusing (and useful if you find yourself short one mousepad.)


--
        -Barry Shein

Software Tool & Die    | bzs@world.std.com          | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
Newsgroups: alt.folklore.computers
From: u734120@bruny.cc.utas.edu.au (John Lamp)
Subject: Lear Siegler Printer Manual
Keywords: lear siegler 300 series ballistic printer
Organization: University of Tasmania, Australia.
Date: Thu, 10 Sep 1992 12:32:11 GMT


I am trying to locate _any_ information on the Lear Siegler Inc
300 Series ballistic printer.

A manual would be ideal vague memories certainly acceptable.
Escape sequences for graphics mode in any form ideal.

Why ballistic? - will my ears suffer (450 cps!!!)?

(I don't suppose there's a windows 3.1 driver eh? ;->)

Cheers!
John

--
   _--_|\             John Lamp, originating in Hobart, Tasmania
  /      \                 Phone: 002 23 1366 - Fax: 002 34 5685
  \_.--._/                   email: u734120@bruny.cc.utas.edu.au
        v <-----------------------------------------------------
Xref: sparky alt.folklore.computers:14012 comp.unix.misc:3686
From: jimf@centerline.com (Jim Frost)
Newsgroups: alt.folklore.computers,comp.unix.misc
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 15 Sep 1992 15:08:08 GMT
Organization: CenterLine Software, Inc.
NNTP-Posting-Host: 140.239.3.202

lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>In article <id.303T.Z2C@ferranti.com> peter@ferranti.com (peter da silva) writes:
>>Yes, OS/2 is a bit of a mess internally. Typical IBM design.

>No, it's purely a Microsoft design.

I would have said that it's a typical MS design (same thing, it's an
aberration when either company generates good software), but you're
wrong.  IBM dictated a lot of the design considerations, the most
important being that OS/2 must target the '286 and not the '386.

jim frost
jimf@centerline.com
Newsgroups: alt.folklore.computers