Amen.
:)
- Mike: dogas(a)leading.net
-----Original Message-----
From: Max Eskin <max82(a)surfree.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Saturday, April 03, 1999 11:44 PM
Subject: Hallelujah!
>I've finally gotten around to reading a LISP book that I had bought months
>before, and I can see why people refer to LISP as a religious experience
>(I've seen that said at least twice). It's really a wonderful language. I
>wonder how it is worse than BASIC or Perl. Also, although I didn't really
>take the time to really understand smalltalk (Squeak is slow and
>unstable), I can see the beginnings of smalltalk in LISP. Wow. This thing
>really is pretty amazing. This should be taught in every computer
>programming course, along with PAL-8, C, and Perl. I am now certain that
>if a language is hard to learn (C++ comes to mind), there's something
>wrong with it :)
>
>--Max Eskin (max82(a)surfree.com)
>
>
I'm not sure if anyone else knows about what I'm talking about, but in my
Jeep (pre-ABS), there's a little panel on the dashboard (not original).
There's 4 LED's on the panel (one corresponding to each wheel). When the
wheel corresponding to a particular LED is completely stopped, the LED
lights steadily red. When the wheel is turning, the LED flashes green (one
flash for each revolution).
Anyone know how this would work (with out me pulling it out of my Jeep)? It
would be probably a good accessory for non-ABS cars.
--
-Jason Willgruber
(roblwill(a)usaor.net)
ICQ#: 1730318
<http://members.tripod.com/general_1>
>2) even if the ABS system fails it still works just like non-ABS brakes.
unless
>the vacuum (power assisted) system fails or the brake line is cut, or (very
>unlikely) the piston sticks open, the brakes will work just fine.
>
ABS - American Bull Shi...
I have noted one difficulty with ABS, and that is its failure to operate on
snow
and ice. Since I live in Southern California, I do not get that much snow
but,
in any quick application of my Mustang's breaks, on snow covered roads,
they always seem to lock up. Well, the pumping action occurs but, at each
application of the pump, I notice wheel lock-up. There is no stopping.
William R. Buckley
>>Sure. And the microcode compilers I've written and used are much better
>>at optimizing horizontal microcode than I have the time or patience to
>>do by hand.
>Your lack of time and patience is not equal to the claim you make
>regarding the quality of optimisation possible.
well put... I've yet to find a compiler which can produce code which
could not then be further optimized in some way by a person well
versed in that machine's architecture...
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
I've finally managed to partially satisfy
my nostalgic obsession to resurrect a PDP-10.
I just recently located a KS10, and, after a 480
mile mile trip in the back of my poor little
pickup truck, it is now safely sitting in front
of my garage (still in the truck... It will
be _in_ the garage as soon as I can con a couple
of my friends into giving me a hand. This is not
a light load :-)
The next thing I'm going to need is a Massbus
drive (preferably, an RM80) If anyone has one of
these that they would be willing to part with,
please drop me an email note. I'm located in
Virginia, but I'm willing to drive a reasonable
distance to pick one of these critters up (the
closer the better, of course :-) Shipping would
be impractical.
The other possibility is to build an adapter
that I could stick in a PC which would emulate
a Massbus device, but to do this, I'd need pretty
complete specs on the Massbus (i.e. pinouts,
timing, etc.) Does anyone happen to have this
info? I've done a dejanews search, but nothing
really useful turned up.
If I can locate a partially complete RM80 (i.e.
one with the Massbus to modified-SMD adapter
still present and intact in the drive pedistal,
then I might try to build an adapter to emulate
the modified-SMD interface supported by the
massbus adapter cardset. I suspect this might
be a simpler emulation, but it would still
require info on the modified-SMD interface
supported by the RM80. If anyone has details
on this interface, please let me know!
BTW, I'm also on the lookout for TOPS-10 and/or
TOPS-20 load tapes (or images thereof, or bits
and pieces... whatever I can find that will get
me closer to bringing this critter back to life!
-Thanks in advance...
-al
-acorda(a)geocities.com
--- Jason Willgruber <roblwill(a)usaor.net> wrote:
> Does anyone have (or know where to get) an old (b/w) Apple
> ImageWriter printer for under $20?
I have an untested ImageWriter that I got last month that was attached
to the Apple //c+ that was the object of my interest. I would be
willing to let it go for $20 plus shipping.
> I also need a cable to connect an Apple //c to a printer.
I only have the one cable that came with the //c+. I could get you
the pinout if you needed it.
-ethan
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
>
> ::> > I have heard of Airbuses crashing because the controls were poorly
> ::> > designed. I've never heard of a 777 crashing. I've also never heard of any
> ::> > medical machines failing, though this would tend to be underpublicized.
>
> ::Actually, the THERAC-25 radiation therapy machine is a good example of
> ::poor hardware AND software design which killed a number of people by
> ::giving them too high a dose of radiation, either for too long or
> ::without the proper screen in place.
>
> !?!
>
> Has this been documented anywhere? Where did you find this out from?
>
I read an article about it several years ago, but I don't remember
what magazine it was it... One of the IEEE or ACM periodicals, I think.
A quick Alta-Vista search on "therac" turns up 476 matches, but a lot
of them are CS student papers.
Take a look at http://ei.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html
This is a reprint from IEEE Computer (might even be the original article
I saw :)
clint
>
>
> Max Eskin <max82(a)surfree.com> wrote:
> >
> > I have heard of Airbuses crashing because the controls were poorly
> > designed. I've never heard of a 777 crashing. I've also never heard of any
> > medical machines failing, though this would tend to be underpublicized.
>
Actually, the THERAC-25 radiation therapy machine is a good example of
poor hardware AND software design which killed a number of people by
giving them too high a dose of radiation, either for too long or
without the proper screen in place.
clint
William writes:
> My wish is for a computer system that provides for dynamically modifiable
> microcode, so that my self-modifying programs could obtain a new level
> of self-modifyability!
Ah..a few decades too late :)
The Burroughs B1700 (and B1800 and B1900) could have been
used that way, I suppose. The machine had multiple microcode
sets, executed by picocode. (IIRC, Picocode was written in an
ALGOL-like language)
I don't recall seeing any particularly protection mechanism that
would have prevented you from modifying a microcode on the fly.
The COBOL compiler determined which microcode to use, based on
things like the number of variables used by the program being
compiled. (If a program used a small number of variables, it could
be compiled to a microcode instruction set that had more compact
instructions because the number of address bits was smaller.)
Another microcode instruction set was used for the primary OS
programming language (SPL? XPL? can't recall). I seem to recall
several other microcode sets being around as well.
When processes were "time sliced" (multi-programming), the
microcode was also time sliced. (I.e., process A might be using one
microcode, while "simultaneously" process B might be using a
different microcode).
> As for the Lisp difficulties, remember, it takes only a few of the basic
> operators to define the language. All else can be derived from same,
> and AFAIK is derived from same. So, there is no need to implement
> derivable functions in microcode.
>
> William R. Buckley
>
