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
-----------------------------------------------------------------------------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
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 94403