jfh@killer.UUCP (John Haugh) (05/20/87)
In article <12067@topaz.rutgers.edu>, trudel@topaz.rutgers.edu (Jonathan D.) writes: > > Forget artificial > intelligence! Forget relational databases! Forget distributed network > architecture proposal interface protocols! Forget documentation! Forget > associative memory! Let's make computers explode in our lifetime!!! A friend of mine who work at TANO in New Orleans told me (remember now, I'm the guy with the problem about cows ... :-) ) that one of the unused op-codes in the M6800 had the nasty side effect of overloading the bus and causing much grief on the PC board the chip was mounted on. The idea was that this illegal instruction repeatedly fetched from the bus at a rate that was more than what the bus could handle, and poof! instant meltdown. You don't really expect me to believe that this actually happened now do you? Anybody out there heard of anything like this really happening? - John. (Freddy the Freeloader in Decadent Dallas)
sentinel@killer.UUCP (The Sentinel) (05/21/87)
In article <910@killer.UUCP>, jfh@killer.UUCP (John Haugh) writes: > In article <12067@topaz.rutgers.edu>, trudel@topaz.rutgers.edu (Jonathan D.) writes: > > > > Forget artificial > > intelligence! Forget relational databases! Forget distributed network > > architecture proposal interface protocols! Forget documentation! Forget > > associative memory! Let's make computers explode in our lifetime!!! > > [...] that one of the unused op-codes > in the M6800 had the nasty side effect of overloading the bus and causing > much grief on the PC board the chip was mounted on. The idea was that this > illegal instruction repeatedly fetched from the bus at a rate that was more > than what the bus could handle, and poof! instant meltdown. > > You don't really expect me to believe that this actually happened now do you? > Anybody out there heard of anything like this really happening? Yep. When I was in high school, we had several SWTPC 6800 machines, of slightly post-Altair vintage. They had 32k of RAM (a lot at the time), 5-1/4" single density drives that held around 90k, a CP/M-like operating system, and you had to boot them by calling the disk boot rom from the monitor. Anyway, I saw demonstrated (not with the school's permission, as you can probably guess) a program called "DEATH" which did a number of destructive things including stepping the drives out of range and apparently using this opcode you mention. I remember the main board going in for service after that and coming back with lots of new chips. I never knew how a program could do this until now... (Don't take everything I said as absolute truth... my memory is a bit fuzzy... I do distinctly remember the computer being fried by that program, though. And no, I was not the one who did that... I was only a spectator) On another note, some of the earlier Commodore PET's had a register in their video controller that set the number of scan lines (or something like that). On some of them, you could tweak this register to get a better looking screen display. On others, doing so would toast the video circuitry. While this is not strictly in the "exploding computer" category, in the PETs the monitor WAS in the same case, so it has the same effect on the poor guy who watches it happen :-) > - John. (Freddy the Freeloader in Decadent Dallas) --TS -- Rob Tillotson ...ihnp4!killer!sentinel 3922-1 Newport Ave. -or- Fort Wayne, IN 46805 ...rutgers!unirot!sentinel (219) 483-2722 (top one preferred)
rwa@auvax.UUCP (Ross Alexander) (05/24/87)
In article <910@killer.UUCP>, jfh@killer.UUCP (John Haugh) writes: > A friend of mine [...] told me [...] that one of the unused op-codes > in the M6800 had the nasty side effect of overloading the bus and causing > much grief on the PC board the chip was mounted on... > You don't really expect me to believe that this actually happened now do > you? Anybody out there heard of anything like this really happening? The opcode exists, the mnemonic is HCF (Halt and Catch Fire) :-) and without my manuals I can't recall the hex. It's a manufacturability instruction, for testing the chip after the wafers are cut apart, and before they mount the dies onto carriers. It just counts 0000 to FFFF on the address buss continuously. As far as this sort of thing in the mainframe world goes, I (fondly) remember that one of the hackers at the MFCF (U of Waterloo, about 197[45]?), I believe it was C.J. O'Donnel (corrections solicited, any of you guys still around???) found out that if one could synchronously produce a tag fault, a lockup fault and some third fault which I forget (a derail??) that the fault priority arbitrator would fry a diode or something and <*crash*> until the CE could fix it. Of course, this was done more than once - it has to be repeatable to be a scientific experiment, right ;-) !! So be careful about generating faults on an H6050. And this is _not_ hearsay - I saw the code and experienced the crashes. ...!ihnp4!alberta!auvax!rwa Ross Alexander, Athabasca University
davido@gordon.UUCP (David Ornstein) (05/24/87)
When I was working at the Timex Computer Corp. (you remember the little
Times/Sinclair Computers), a couple of us designed a bank-switching
mechanism that was pretty cute. Basically, the thing was runningh on a Z80
so you could only have 64K of memory (16-bit address space). We needed more.
So...
You had up to 256 external banks of memory, each 64K, divided up into 8K
chunks, each bank with 8 chunks. Each bank had some controller logic
associated with it. There was an 8-bit latch that you could write to
from the CPU to enable various chunks in any given bank. Because the
thing needed to be so cheap, there wasn't/couldn't be any logic to make sure
that you (the programmer) didn't turn on multiple chunks in the same address
space and then access that chunk. If you did, both (or ,potentially, all)
of the external banks would respond, turning of their tri-state buffers
and putting whatever they wanted on the bus (e.g. one 5v, the other ground).
My backgroud is mostly digital, with only a few spatterings of the analog
stuff needed to let me do digital work, but it seemed to me that this might
cause some nasty fireworks if taken to the extreme. It offers the
potential for the ultimate trojan horse program!
--
-----------------------------------------------------------------------------
David Ornstein "Never join a religion that has a water slide."
Internet: davido@gordon
UUCP: {mit-eddie|seismo}!mirror!gordon!davido
or {harvard|ames|decvax|husc6}!necntc!davido
US Snail: Access Technology, 6 Pleasant St, Natck MA 01760
-----------------------------------------------------------------------------rsanders@watdcsu.UUCP (05/25/87)
In article <170@auvax.UUCP> rwa@auvax.UUCP (Ross Alexander) writes: >In article <910@killer.UUCP>, jfh@killer.UUCP (John Haugh) writes: >> A friend of mine [...] told me [...] that one of the unused op-codes >> in the M6800 had the nasty side effect of overloading the bus and causing >> much grief on the PC board the chip was mounted on... >> You don't really expect me to believe that this actually happened now do >> you? Anybody out there heard of anything like this really happening? > >The opcode exists, the mnemonic is HCF (Halt and Catch Fire) :-) and >without my manuals I can't recall the hex. It's a manufacturability >instruction, for testing the chip after the wafers are cut apart, and >before they mount the dies onto carriers. It just counts 0000 to FFFF >on the address buss continuously. > The hex value was $DD . It does count up the bus as you describe. It also ignores interupts while doing so. Thats cause the 6800 looks for an interupt at the END of every instruction, and of course this instruction never ended. The result of the interupts being off (including NMI) was that you could not break out of the HCF instruction with anything but a reset. On the SWTP (Southwest Technical Products) machines the reset line went through a tristate buffer which was DISABLED by the HCF instruction. I think the HCF asserted the bus available line or something like that. The bottom line was that the only way out of an HCF on the SWTP was to turn the power off! On most other 6800 implementations a simple reset would get you out. I dont think this instruction could actually harm the machine, the bus was cycling at the normal clock speed. It was just doing it a lot. Anything that couldnt hack that was poorly designed in the first place! -- Roger Sanderson: {clyde|decvax|ihnp4}-\ {tektronix}-+--> watmath!watdcsu!rsanders {ubc-vision|utzoo}-/
magore@watdcsu.UUCP (05/25/87)
In article <910@killer.UUCP>, jfh@killer.UUCP (John Haugh) writes: >> A friend of mine [...] told me [...] that one of the unused op-codes >> in the M6800 had the nasty side effect of overloading the bus and causing >> much grief on the PC board the chip was mounted on... [munch] In article <170@auvax.UUCP> rwa@auvax.UUCP (Ross Alexander) writes: >The opcode exists, the mnemonic is HCF (Halt and Catch Fire) :-) and >without my manuals I can't recall the hex. It's a manufacturability >instruction, for testing the chip after the wafers are cut apart, and >before they mount the dies onto carriers. It just counts 0000 to FFFF >on the address buss continuously. I found that on the Intel 8087 if you do 2 floating point store instructions WITHOUT wait, it will lock-up the local bus until reset! Nothing, not NMI nor external DMA request will get through! You will be forever caught in *_mid-instruction_* that will never finish.... oops :) [ Note: this is *NOT* the interrupt lock-out problem Intel warns everyone about. A logic analyzer proves this... ] For reasons of design the 80287 doesn't have such problems. I have a unix machine with hardware MMU and 8086/8087. I have since dropped using the 8087. Now programs that crash can no longer crash the whole system. Otherwise, one might guess that disabled interrupts in a user task might be a problem, but for this the MMU detects the condition and issues an NMI which calls a system routine which patches the flags in the user task ... [ugh] I hope this just makes everyones day :-) # Mike Gore # Institute for Computer Research. ( watmath!mgvax!root - at home ) # These ideas/concepts do not imply views held by the University of Waterloo.
atbowler@orchid.UUCP (05/25/87)
In article <170@auvax.UUCP> rwa@auvax.UUCP (Ross Alexander) writes: >As far as this sort of thing in the mainframe world goes, I (fondly) >remember that one of the hackers at the MFCF (U of Waterloo, about >197[45]?), I believe it was C.J. O'Donnel (corrections solicited, >any of you guys still around???) found out that if one could >synchronously produce a tag fault, a lockup fault and some third >fault which I forget (a derail??) that the fault priority arbitrator >would fry a diode or something and <*crash*> until the CE could fix >it. Of course, this was done more than once - it has to be >repeatable to be a scientific experiment, right ;-) !! So be careful >about generating faults on an H6050. And this is _not_ hearsay - I >saw the code and experienced the crashes. > Ciaran O'Donnell was responsible for a lot of wierd and wonderful GCOS crashes both in bugs he exposed, and bugs he introduced (For those of you out there who still use GCOS systems, subsystem wrapup in TSS is part of his legacy.) However, this particular item is not one I recall. It sounds unlikely. There was a real hardware/software bug whereby the system could be crashed by a program that caused a carefully timed lockup fault to occur during the initial stages of fault processing while state was still being saved from the first program induced fault. This would cause GCOS to crash, and was fixed by a hardware field change to the lockup fault timing algorithm that removed the vulnerable window. However, no-one here remembers anything that destroyed any electronics. One of the people involved in exposing that likes feeding people tall tales laced with just enough truth to make them seem plausible, I think Ross, you got taken in. Alan (are you still at Waterloo?) Bowler
roy@phri.UUCP (05/25/87)
I can't find the quote, but I remember something in the v6 manual
about (literally) blowing a fuse if you selected more than one DECTAPE
drive at the same time.
On a more esoteric note, I remember having a conversation with
somebody (Alan Lappin?) many years ago about writing a program to seek a
disk arm in such a way as to set up harmonic vibrations in the drive and
cause it to blow up; sort of an electronic Galloping Girdie.
--
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016stuart@bms-at.UUCP (05/28/87)
I inadvertently wrote a BASIC program on an HP2000 at George Mason University that blew up the disk drive. It was an 8 player real time space war game. The problem was that all interprocess communication had to take place via disk. I used the documented LOCK function for serialization. It seems that this function loaded a special OS overlay whenever invoked and reloaded the file I/O overlay directly afterward. With 8 programs doing this as fast as possible, the disk would die. The problem was solved by using an undocumented feature of the scheduler. A process was always assigned 1 sec of CPU following completion of a wait for terminal I/O. This allowed serialization with careful coding while not using the LOCK overlay. BTW, an IBM PC program can blow up the monitor and video cards by programming nasty parameters into the video controller chip. -- Stuart D. Gathman <..!seismo!dgis!bms-at!stuart>
nu070156@ndsuvm1.bitnet.UUCP (05/29/87)
In article <2725@phri.UUCP>, roy@phri.UUCP (Roy Smith) says: > On a more esoteric note, I remember having a conversation with >somebody (Alan Lappin?) many years ago about writing a program to seek a >disk arm in such a way as to set up harmonic vibrations in the drive and >cause it to blow up; sort of an electronic Galloping Girdie. A friend of mine tells a story about our old PDP 11/45 rocking when somebody copied a man page (near the outside of the disk) to his directory (near the middle of the almost-full disk). It gives another meaning to the term 'system crash'! Later in its life, this machine would crash if more than 2 compilations were underway at one time, so a 'pop-can' semaphore was implemented. You had to have one of the 'official' cans before you start your compilation. Glen Overby Bitnet: nu070156@ndsuvm1
bzs@bu-cs.BU.EDU (Barry Shein) (06/01/87)
Posting-Front-End: GNU Emacs 18.41.4 of Mon Mar 23 1987 on bu-cs (berkeley-unix) I can't verify it but I remember a person from the Multics development group claiming that when they installed a highly optimized disk head algorithm (a modified topological sort if memory serves me) the heads just banged back and forth till they blew a disk drive, too optimal. Another similar story referred to the installation (on a different early system) of "high" density tape drives (something like 300BPI) which, when used by programs which did direct access to tapes, eventually stretched and broke the tapes, or melted them to the head or something horrible like that (the programs had been developed for the lower density tapes.) On an opposite note I remember stories of programs which would be run in the background to exercise core memories, that long unused areas tended to go bad. This may all be bar talk but I'd be interested if anyone has any verification. -Barry Shein, Boston University
oster@dewey.soe.berkeley.edu (David Phillip Oster) (06/01/87)
This folt tale was told to me when I was an undergraduate. I'd like confirmation, and details. Long ago, in the early days of computers, a machine at MIT had 1 device controller and attached to it were 7 tape drives (numbered 1-7) and one of the first, early disks, (numbered 0) inevitably each yesr some bright undergraduate, (let's call her Sally) would look at the machine and wonder, "Hmm, they're all on the same controller. I wonder what will happen if I send device 0 a rewind command." So Sally writes a short program to rewind the disk. She hoes into the machine room so she can watch the fun. She runs it and the machine room is filled with the sound of a disk destroying itself. It sounds like a household garbage dispos-all filled with scrap metal. After about a minute, it stops. Sally is panic-stricken, and thinks to herself, "Oh, no, I've destroyed the only disk drive. When they catch me they'll have me paying for it for a decade." Then she notices that the system is still up, that jobs are still running. She goes over to the disk drive and removes the rectangular sheet metal side cover so she can see into the works. There, mounted under disk drive, was a standard household garbage dispos-all, filled with scrap nuts and bolts, connected to the 120 volt power via a relay that must in turn get triggered via the rewind line from the device controller. Sally goes to put the side cover back, and notices, taped to the inside, a sign saying in big letters, "Gotcha!" and signed by the professor who owned the machine. I've also heard stories about students programming a series of disk seeks at the resonant frequency of the disk drive cabinet, so that the entire cabinet could be made to "walk" menacingly toward the operator. Maybe we need comp.misc.folklore. --- David Phillip Oster -- "The goal of Computer Science is to Arpa: oster@dewey.soe.berkeley.edu -- build something that will last at Uucp: ucbvax!dewey.soe!oster -- least until we've finished building it.t.
esf00@amdahl.amdahl.com (Elliott S. Frank) (06/01/87)
In article <8252@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: > >I can't verify it but [. . .] the heads >just banged back and forth till they blew a disk drive > >Another similar story referred to [...] tape drives >which, when used by programs which did direct access to tapes, >eventually stretched and broke the tapes The "washing machine test" stories may refer to the IBM 2311, or it's predecessor, the 1311. The 2311 put 15 megabytes on a stack of 5, 14" platters (the 1311 put 7.5 Mb in the same area), using a combination of (oil-filled) hydraulics and voice coil technology to position the heads. Total mass of the head and arm assembly must have been in the hundreds of grams range (any designers out there who can now say what the mass was?) For ease of installation, the drives had 5" rubber wheels, which were supposed to be jacked off the floor when the drive was positioned. When the 360/75 was installed at Columbia (late '67), one drive was not positioned on its jacks. None of the installation tests caught the problem -- a disk sort that put multiple workareas on the misinstalled drive did. The drive didn't get a chance to go very far -- the disk cables to the controller were IBM systems cables (24 minature coax, about 1 1/2" thick) that did not have any slack. The largest damage was to the ego of the FE who didn't check his checklist. The tape drive stories may be due to the IBM 729 drive, originally designed for 200 bpi, and then upgraded to 556bpi and 800 bpi densities. If you did a fast forward and then issued another command before the fast forward completed, you could get the drive to do interesting things. One trick used by DCS was a fast forward (to the end of the tape and wait for it to complete), fast forward, rewind sequence that allowed it to read past a BOT/EOT marker. That trick allowed you to put both the IBSYS and FMS operating systems on the same single reel of tape, with a BOT/EOT marker in the middle. If you used a single FF to get to the end of the tape and then asked for another operation, you had a problem, as the controller did not implement the equations of motion. -- Elliott S Frank ...!{hplabs,ames,seismo,sun}!amdahl!esf00 (408) 746-6384 [the above opinions are strictly mine, if anyone's.] [the above signature may or may not be repeated, depending upon some inscrutable property of the mailer-of-the-week.]
howellg@idec.UUCP (06/02/87)
In article <170@auvax.UUCP> rwa@auvax.UUCP (Ross Alexander) writes: >In article <910@killer.UUCP>, jfh@killer.UUCP (John Haugh) writes: >> A friend of mine [...] told me [...] that one of the unused op-codes > >The opcode exists, the mnemonic is HCF (Halt and Catch Fire) :-) and Is this opcode related to the similar opcodes on mainframe computers: ECC - Electrify Computer Console WIB - Write Inter-Block Gap (mag tape only i'm afraid). There were mainy more but I can't recall them now. Seriously tho' guys, this series of items is one of the most entertaining I have read on USENET for a long time. Keep it up!! 73s Gareth -- Gareth Howell <howellg@idec.stc.co.uk> G6KVK @ IO91VX ICL Network Systems, Private Networks Business Centre London Road, Stevenage, Herts, England, SG1 1YB Tel:+44 (0)438 738294 howellg%idec%ukc@mcvax.uucp, idec!howellg@seismo.CSS.GOV
marcl@iscuva.UUCP (06/02/87)
You're close, the IBM 2311 had 7 point something megabytes, and the 1311 had 5 megabytes. I know, 'cause we had two 2311s on an IBM 360/40 at Cal Poly in 1969 and converted from DOS to OS/PCP via numerous and clever file copies and disk pack swaps. When we finally got a 3rd 2311 we thought we were in heaven! How things change... -- H. Marc Lewis UUCP: marcl@iscuva.ISCS.COM ISC Systems Corp. Phone: (509) 927-5480 (seismo!uunet!iscuva!marcl) Box TAF-C8 "Men have become tools of their own tools." Spokane, WA 99220 (Henry David Thoreau)
okunewck@psuvax1.UUCP (06/03/87)
In article <15@gordon.UUCP> davido@gordon.UUCP (David Ornstein) writes: >When I was working at the Timex Computer Corp... > >You had up to 256 external banks of memory, each 64K, divided up into 8K >chunks, each bank with 8 chunks. Each bank had some controller logic >associated with it. There was an 8-bit latch... How many were going to Saint Ives? ---Duck
cetron@utah-cs.UUCP (06/03/87)
I don't remember garbage dispos-all's but I do remember the walking rpo6's and 7's and J&J, we would leave masking tape on the floor with our names on them and then put a dollar into the pool at closing time. The next morning the person closest to the drives (or the drive closest to their mark) collected the pool..... -ed
hughes@endor.UUCP (06/03/87)
In article <19211@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: > >This folt tale was told to me when I was an undergraduate. I'd like >confirmation, and details. > [Rewinding the disk drive] I have heard that telling early disk drives to execute "rewind" could do awesome things, but never that anyone put a disposal inside a disk drive to freak out novice hackers. > >I've also heard stories about students programming a series of disk >seeks at the resonant frequency of the disk drive cabinet, so that the >entire cabinet could be made to "walk" menacingly toward the operator. >Maybe we need comp.misc.folklore. >--- David Phillip Oster -- This is actually the Donovan and Madnick hack (supposed to be true, but who knows). Both were in the computer room (this was before there were seperate terminal rooms). Donovan (or perhaps Madnick) punched up a short deck of cards (this is long ago), submitted them, and the disk drive walked across the floor. Madnick scratches his head a while, punches up his own deck of cards, submits it, and the disk drive walks back to its original position. Given a not terribly massive drive, and a heavy set of head arms, this is theoretically possible. Not sure that you'd need to make the drive resonate to do this.
artm@phred.UUCP (06/03/87)
It wasn't mentioned in all the buzz about old computers a few months ago,
but a co-worker who used to be an IBM CE tells me that on at least some
models of the 1403 printer it was possible to make the thing eject pages
so fast that the tractors got hot enough to set the paper on fire.
-------------------------------------------------------------------------
Other than that, and the fact that this nice computer is provided with
net access, my employer takes no responsibility for the veracity of
any of the above. Do not try this at home!!!
-------------------------------------------------------------------------
Art Marriott
...!tikal!phred!artm
--------------------------------------------------------------------------bbownes@eagle_snax.UUCP ( Sun ECD Software) (06/03/87)
I seem to remember the folk tale from college of a student (Who shall remain nameless....;->) Who got a little upset at not being given an extension after the system had been doing a yo-yo imitation for 3 days...Soooo, he stuck a *LITTLE* piece of abrasion cloth (You know, the stuff with tungsten carbide grit on it....) about 100 ft into a tape and had it loaded...The *NEW* operator noticed that there were an AWFULL lot of read errors occuring, so he moved it to the next drive over....three times. Well, there were at least 3 drives left for the bursar to use over christmas break....I got my tuition bill anyway. Bob Bownes Sun Microsystems (PS: It WASN'T me!!!!!! I've done some mean and rotten things, but *HURT* a computer? Never. (well there was a burroughs and a sledgehammer....8nk8n
esf00@amdahl.UUCP (06/04/87)
In article <1519@phred.UUCP> artm@phred.UUCP (Disaster Master) writes: > on at least some >models of the 1403 printer it was possible to make the thing eject pages >so fast that the tractors got hot enough to set the paper on fire. On some models of the the 1403 printer, you could break the print chain by printing characters in the reverse order they were on the print chain. -- Elliott S Frank ...!{hplabs,ames,seismo,sun}!amdahl!esf00 (408) 746-6384 [the above opinions are strictly mine, if anyone's.] [the above signature may or may not be repeated, depending upon some inscrutable property of the mailer-of-the-week.]
rpw3@amdcad.AMD.COM (Rob Warnock) (06/04/87)
O.k., o.k., out it comes again...
There's this ancient story [true? or fairy tale? who knows?] about a DEC line
printer that had an inadequate static supressor on the output side of the
paper path, and an engineer who was having trouble convincing management that
there was a problem. So he constructed a file that had "<ff>x<ff>x<ff>x...",
that is, one letter per page, and named it "fire". Then he called up the
operators in the DEC data center and told them to ".PRINT FIRE". They did.
It did. (And the printer got fixed...)
p.s. The file couldn't just be all form feeds, because there was a "paper
runaway detector" that stopped the printer from spewing paper after 3 or so
sheets with nothing on them. But one letter per page still let the paper
build up a good static charge while defeating the paper runaway detector.
Rob Warnock
Systems Architecture Consultant
UUCP: {amdcad,fortune,sun,attmail}!redwood!rpw3
ATTmail: !rpw3
DDD: (415)572-2607
USPS: 627 26th Ave, San Mateo, CA 94403howard@cos.UUCP (06/04/87)
A variant I personally experienced had to do with making computers (or more specifically tape drives) die temporarily due to external events. In the late '70's, I worked at the Library of Congress. We had IBM and Amdahl mainframes with STC tape drives as our main data base machines. Given the role of the world's largest library, our computer room received considerable attention. The British Broadcasting Corporation was given access to much of the Library, to film a documentary. We found that some major system crashes began to happen when they were in the computer room. We thought it might be their video equipment, floods, etc., but could not find the cause. The symptom was clear: periodically, ALL of our tape drives would simultaneously stop, rewind, and unload, no matter what they were doing. The operating system could not deal with such simultaneous events, and would crash. It turned out to be an intermittent event: most BBC work was film or video, but they occasionally took still photographs. When their electronic flash pointed at the front of the tape drives, the short burst of light was reflected into the photoelectric end-of-tape sensors of each tape drive, causing EVERYTHING to simultaneously sense (erroneously) end-of-tape.
roy@phri.UUCP (Roy Smith) (06/04/87)
In article <2175@husc6.UUCP> hughes@endor.UUCP (Brian Hughes) writes: > Given a not terribly massive drive, and a heavy set of head arms, > this is theoretically possible. Not sure that you'd need to make the drive > resonate to do this. Anybody who has every used a KSR/ASR-33 knows that it's not hard to make a piece of machinery jump around by flopping some parts inside it. The whole teletype would jump around when you did a CR at the end of a long line, especially if the pneumatic shock absorber wasn't working right. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
kurt@tc.fluke.COM (Kurt Guntheroth) (06/05/87)
Anyone ever hear of the Olivetti A5? It was a small-business computer of the mid 1970's, and had a microprocessor (8008 or less) wrapped up in a bright red, hyperthyroidal Selectric-type typewriter. The A5 was a masterpiece of mechanical engineering. Press a key on the (electronic) keyboard. The key press is converted to a six-bit code, which activates six solenoids (!!) which push six push rods that run the width of the machine (about three feet) to contact six microswitches, which in turn talk to the microprocessor. The push rods also moved the type ball somehow. The type head was large and heavy, so Olivetti installed a 1/2 hp electric motor to run it all. There were also millions of little nylon gears. The A5 was programmed with writable magnetic strip cards, each the size of a punch card, and each containing 256 bytes of data. There was also a connector in the back for peripherals. I worked for a company that made a disk drive for the A5. With the drive, you loaded a bootstrap on one mag-card, and the disk did the rest. Well, as it turned out, the printing mechanism on the A5 was not meant for continuous duty. After all, how much work could you if you always had to insert mag cards. With the disk, however, it could run all night doing reports. We went through A5's like crazy. When they got old, they would scream (I mean really scream) every time the type ball returned to the left of the platen. I had worked for these guys for about six weeks when an A5 literally blew up on me. The type ball started to return, then suddenly the air was full of plastic shrapnel as all those gears disintegrated under the awful torque of that huge motor. I should have been thinking of my close encounter with death and disfigurement, but I was a sophomore, and all I could think of was "Mother of God, I've killed a $14,000 computer. At $5/hour, it's gonna take...how long?" I didn't feel better until they explained they took A5's out of the office on a blotter about every three weeks.
eichin@bloom-beacon.UUCP (06/13/87)
The Mac II (we just got ours this week, and we are REAL customers, not developers) has a real power off switch in the back. They warn against it in the documentation, mainly because you can lose work. The normal user will never need it, because the "SHUTDOWN" menu selection powers down the machine. Poof. Fans stop, everything. Really eerie the first time you try it... Turning it on is more odd. The "on" button is a key on the keyboard (which is harmless otherwise) that is monitored by a Lithium battery (expected to last 10 years, out living the computer's useful life.) Bug in early models: the resistor network values were wrong, and the Lithium cell would be dead in a few weeks. So the real problem was getting the computer to turn it self ON, not OFF. /Happy Hacking........\\.............Mark Eichin/ <eichin@ATHENA.MIT.EDU><SIPB member & Watchmaker>
klm@munsell.UUCP (Kevin McBride) (06/24/87)
In regards to the "soft power down" feature being discussed: I first encountered this feature on a Symbolics 3670 Lisp Machine. It feels really wierd to see a computer shut off it's own power. I guess it feels especially odd to see an "AI" machine do it. ... (halt machine) Do you really want to power down the 3670? yes (screen goes blank as circuit breaker trips.) -- Kevin McBride |Disclaimer: These | harvard -\ Eikonix - A Kodak Co. | opinions are mine, | ll-xn ---adelie-----> munsell!klm 23 Crosby Dr. | not my employer's, | decvax -v talcott -v | Bedford, MA 01730 | So There! | allegra ------------encore
snoopy@doghouse.gwd.tek.com (Snoopy) (06/25/87)
In article <1089@knopfler.munsell.UUCP> klm@knopfler.UUCP (Kevin McBride) writes: >In regards to the "soft power down" feature being discussed: >I first encountered this feature on a Symbolics 3670 Lisp Machine. >It feels really wierd to see a computer shut off it's own power. >I guess it feels especially odd to see an "AI" machine do it. >... >(halt machine) >Do you really want to power down the 3670? yes >(screen goes blank as circuit breaker trips.) What's even more entertaining is to see a "Please turn power on" message! I've been tempted to hack login(1) to accept Morse code from the power switch. :-) Snoopy tektronix!doghouse.gwd!snoopy snoopy@doghouse.gwd.tek.com
klm@munsell.UUCP (Kevin McBride) (06/26/87)
In article <8774@tekecs.TEK.COM> snoopy@doghouse.gwd.tek.com (Snoopy) writes: >In article <1089@knopfler.munsell.UUCP> klm@knopfler.UUCP (Kevin McBride) writes: >>... >>(halt machine) >>Do you really want to power down the 3670? yes > >>(screen goes blank as circuit breaker trips.) > >What's even more entertaining is to see a "Please turn power on" >message! I've been tempted to hack login(1) to accept Morse code >from the power switch. :-) Well, we also had one of the older style Symbolics 3600s. It did ask you if you wanted to power up!! There was a little LED display on the front of the box next to the main power key and the reset button, "Yes" button(!), etc. When you turned on the cabinet power with the key, the LEDs would display Power up? The system would do nothing more until you pressed the "Yes" button. When you did, the LEDs displayed Yes, Master. Whereupon the disk would spin up, the system would reset and start Lisping away. I'm not kidding. This is for real! Definitely the most mind blowing feature I've ever seen on a computer. -- Kevin McBride |Disclaimer: These | harvard -\ Eikonix - A Kodak Co. | opinions are mine, | ll-xn ---adelie-----> munsell!klm 23 Crosby Dr. | not my employer's, | decvax -v talcott -v | Bedford, MA 01730 | So There! | allegra li!ekw!ekw!pam!mou