[cctalk] Re: System 360 question
The 6800 had an "HCF" instruction. The 6502 had several KIL instructions that had similar behaviour. I don't think either of these made any permanent damage. https://en.wikipedia.org/wiki/Halt_and_Catch_Fire_(computing) https://www.pagetable.com/?p=39 https://en.wikipedia.org/wiki/Killer_poke > On 1 Nov 2024, at 23:00, Peter Coghlan via cctalk > wrote: > > > Nope. If you believe this mythical instruction exists, you are the > person that gets to spend the time digging up the references to it. > > I've been writing assembly on the 6502 since the early 1980s and I have > never managed to damage one when my programs went off the rails, which > they did on many occasions. > > I have never heard from any other 6502 users about issues like this either. > > Regards, > Peter Coghlan. > > David Barto wrote: >> >> Nope. Read the documentation for the chip. Turns out that the HCF >> instruction basically sent the chip into an internal loop which would render >> parts of it unusable after about 30-45 seconds. >> >> Tried it once and the chip got hot. Very very hot and then just stopped >> working. >> >> David >> >>> On Nov 1, 2024, at 9:55 AM, Peter Coghlan via cctalk >>> wrote: >>> >>> David Barto wrote: The 6502 had a HCF (halt and catch fire) undocumented instruction. I forget the opcode and if you knew what you were doing you could get the instruction executed on the chip using any assembler. Security through obscurity back in the 70s. The chip was advanced enough that the DOD wanted to avoid it falling into the “wrong” hands. David Sent from iPhone Hotblack Desiato >>> >>> Did someone tell you this on April 1st? >>> >>> Regards, >>> Peter Coghlan >>> >>> Sent from my DEC Alphaserver 800 >> >> There is nothing more difficult to carry out, nor more doubtful of success, >> nor more dangerous to handle, than to initiate a new order of things. >> For the reformer has enemies in all those who profit by the old order, >> and only lukewarm defenders in all those who would profit by the new... >>--Niccolo Macchiavelli, The Prince >> David Barto >> ba...@kdbarto.org >> >>
[cctalk] Re: System 360 question
Nope. If you believe this mythical instruction exists, you are the person that gets to spend the time digging up the references to it. I've been writing assembly on the 6502 since the early 1980s and I have never managed to damage one when my programs went off the rails, which they did on many occasions. I have never heard from any other 6502 users about issues like this either. Regards, Peter Coghlan. David Barto wrote: > > Nope. Read the documentation for the chip. Turns out that the HCF instruction > basically sent the chip into an internal loop which would render parts of it > unusable after about 30-45 seconds. > > Tried it once and the chip got hot. Very very hot and then just stopped > working. > > David > >> On Nov 1, 2024, at 9:55 AM, Peter Coghlan via cctalk >> wrote: >> >> David Barto wrote: >>> >>> The 6502 had a HCF (halt and catch fire) undocumented instruction. >>> I forget the opcode and if you knew what you were doing you could get the >>> instruction executed on the chip using any assembler. >>> >>> Security through obscurity back in the 70s. >>> The chip was advanced enough that the DOD wanted to avoid it falling into >>> the “wrong” hands. >>> >>> David >>> >>> Sent from iPhone Hotblack Desiato >>> >> >> Did someone tell you this on April 1st? >> >> Regards, >> Peter Coghlan >> >> Sent from my DEC Alphaserver 800 > > There is nothing more difficult to carry out, nor more doubtful of success, > nor more dangerous to handle, than to initiate a new order of things. > For the reformer has enemies in all those who profit by the old order, > and only lukewarm defenders in all those who would profit by the new... > --Niccolo Macchiavelli, The Prince > David Barto > ba...@kdbarto.org > >
[cctalk] Re: System 360 question
On 11/1/24 14:55, CAREY SCHUG via cctalk wrote: Wikipedia lists models 60, 62, 64, and 66 (never shipped) and 65 and 67 as shipped, but no 63. since I don't remember 65s, I assume not many of them made it out the door? Uh, no. The 360/65 was a very popular model, QUITE (4X) a step up from the 360/50. The /67 was a variant of the /65, which had an address translator feature pretty identical to what was used in the later 370/168 for demand-paged virtual memory. The model 65 also allowed two processors to run from shared memory. This was called the MP65. The model /60 was only produced for a short time, it was replaced with the model /65. There is a picture of the /65 console in the Wikipedia article. Also, a variant of the 360/65 was part of the FAA's air traffic control computer complexes. They were called a model 9020. Jon
[cctalk] Re: System 360 question
Wikipedia lists models 60, 62, 64, and 66 (never shipped) and 65 and 67 as shipped, but no 63. since I don't remember 65s, I assume not many of them made it out the door? https://en.wikipedia.org/wiki/IBM_System/360 --Carey > On 11/01/2024 1:12 PM CDT Van Snyder via cctalk wrote: > > > On Fri, 2024-11-01 at 11:01 -0700, David Barto via cctalk wrote: > > > > The 6502 had a HCF (halt and catch fire) undocumented > > > > instruction. > > > > I forget the opcode and if you knew what you were doing you could > > > > get the instruction executed on the chip using any assembler. > > Early in 1965 Caltech installed one of only a few 360/63 computers. > After they installed it, they discovered that the default instruction > when it started up was HCF. It was replaced with a 360/67.
[cctalk] Re: System 360 question
On Fri, 2024-11-01 at 11:01 -0700, David Barto via cctalk wrote: > > > The 6502 had a HCF (halt and catch fire) undocumented > > > instruction. > > > I forget the opcode and if you knew what you were doing you could > > > get the instruction executed on the chip using any assembler. Early in 1965 Caltech installed one of only a few 360/63 computers. After they installed it, they discovered that the default instruction when it started up was HCF. It was replaced with a 360/67.
[cctalk] Re: System 360 question
Nope. Read the documentation for the chip. Turns out that the HCF instruction basically sent the chip into an internal loop which would render parts of it unusable after about 30-45 seconds. Tried it once and the chip got hot. Very very hot and then just stopped working. David > On Nov 1, 2024, at 9:55 AM, Peter Coghlan via cctalk > wrote: > > David Barto wrote: >> >> The 6502 had a HCF (halt and catch fire) undocumented instruction. >> I forget the opcode and if you knew what you were doing you could get the >> instruction executed on the chip using any assembler. >> >> Security through obscurity back in the 70s. >> The chip was advanced enough that the DOD wanted to avoid it falling into >> the “wrong” hands. >> >> David >> >> Sent from iPhone Hotblack Desiato >> > > Did someone tell you this on April 1st? > > Regards, > Peter Coghlan > > Sent from my DEC Alphaserver 800 There is nothing more difficult to carry out, nor more doubtful of success, nor more dangerous to handle, than to initiate a new order of things. For the reformer has enemies in all those who profit by the old order, and only lukewarm defenders in all those who would profit by the new... --Niccolo Macchiavelli, The Prince David Barto ba...@kdbarto.org
[cctalk] Re: System 360 question
David Barto wrote: > > The 6502 had a HCF (halt and catch fire) undocumented instruction. > I forget the opcode and if you knew what you were doing you could get the > instruction executed on the chip using any assembler. > > Security through obscurity back in the 70s. > The chip was advanced enough that the DOD wanted to avoid it falling into the > “wrong” hands. > > David > > Sent from iPhone Hotblack Desiato > Did someone tell you this on April 1st? Regards, Peter Coghlan Sent from my DEC Alphaserver 800
[cctalk] Re: System 360 question
Glad I never tried it. 😊
[cctalk] Re: System 360 question
The 6502 had a HCF (halt and catch fire) undocumented instruction. I forget the opcode and if you knew what you were doing you could get the instruction executed on the chip using any assembler. Security through obscurity back in the 70s. The chip was advanced enough that the DOD wanted to avoid it falling into the “wrong” hands. David Sent from iPhone Hotblack Desiato > On Oct 31, 2024, at 5:03 PM, Jon Elson via cctalk > wrote: > > On 10/31/24 09:35, Donald Whittemore via cctalk wrote: >> If I remember right I was told back in the early 70s by our IBM CE that >> physical damage could be done to our model 30 or 40 if we ran a program that >> did an Assembler instruction, B *For those non-Assembler people that is >> an instruction to branch to the location of the instruction. I think it >> might have caused a heat problem in the core or CCROS or TROS. >> >> Possible? Or is my 76 year old brain hallucinating? > > Hammering a single location in core could overheat the select wires, the > individual cores or the select driver cards. I can believe this could > happen. I seriously doubt it could harm the CCROS or TROS. The model 30 was > SLOW, the original version (first 1000 machines) had a 2.5 us memory cycle > time. But, a B instruction occupied 4 bytes. And the model 30 memory was > ONE SINGLE BYTE wide! So, it would have to access 4 consecutive bytes over a > 10 us period to read the entire instruction. This would involve t different > select wires in one axis, but likely the same wire in the other axis. > > On the model 40, memory was 16 bits wide, so it would still have to access 2 > consecutive words. > > Anyway, I was told that on a model 40 (I think) that if you pressed and held > stop, system reset, and load simultaneously, it would pop a component on a > circuit card in the machine. > > Jon
[cctalk] Re: System 360 question
On 10/31/24 19:02, Jon Elson via cctalk wrote: On 10/31/24 09:35, Donald Whittemore via cctalk wrote: If I remember right I was told back in the early 70s by our IBM CE that physical damage could be done to our model 30 or 40 if we ran a program that did an Assembler instruction, B * For those non-Assembler people that is an instruction to branch to the location of the instruction. I think it might have caused a heat problem in the core or CCROS or TROS. Possible? Or is my 76 year old brain hallucinating? Hammering a single location in core could overheat the select wires, the individual cores or the select driver cards. I can believe this could happen. I seriously doubt it could harm the CCROS or TROS. The model 30 was SLOW, the original version (first 1000 machines) had a 2.5 us memory cycle time. But, a B instruction occupied 4 bytes. And the model 30 memory was ONE SINGLE BYTE wide! So, it would have to access 4 consecutive bytes over a 10 us period to read the entire instruction. This would involve t different select wires in one axis, but likely the same wire in the other axis. On the model 40, memory was 16 bits wide, so it would still have to access 2 consecutive words. Anyway, I was told that on a model 40 (I think) that if you pressed and held stop, system reset, and load simultaneously, it would pop a component on a circuit card in the machine. Jon The Microdata 1600 8k memory boards, and sometimes the 16k core they had would do bad things with continuous half cycle reads. The full cycle was 1ms long and could heat up the resistors, but when you did the half cycle reads it was only 600ns long continuous and could damage the system core. It was used for rippling moves up or down of strings where you'd read a byte from somewhere in core and write it elsewhere with a pointer increment in between. The 1600 was microprogrammed, so there were no machine (macro level) instructions to do damage, so the implementer of the machine language microcode would have had to do the deed to damage the core. Or one could do it from the front panel, as one could execute micro instructions there in 'run" at full speed (200ns) speed. There was a processor delay if you did reads like that which, so the speed would be 600ns back to back. We had a 360/50 with both 512k internal processor core and an LCS of 1mb, and neither had any restrictions on such instructions, though I don't think I know if there were hardware protections like others in this thread are suggesting. thanks Jim
[cctalk] Re: System 360 question
remember, core memory is destructive read out. to read the bits you erase them and have to rewrite them. I doubt the B * running for 30 seconds, then cancel the job would be bad, but if you started it up Friday and it ran all weekend? every time you demagnetize and re-magnetize those cores, probably an atom or two gets displaced. --Carey > On 10/31/2024 7:02 PM CDT Jon Elson via cctalk wrote: > > > On 10/31/24 09:35, Donald Whittemore via cctalk wrote: > > If I remember right I was told back in the early 70s by our IBM CE that > > physical damage could be done to our model 30 or 40 if we ran a program > > that did an Assembler instruction, B *For those non-Assembler people > > that is an instruction to branch to the location of the instruction. I > > think it might have caused a heat problem in the core or CCROS or TROS. > > > > Possible? Or is my 76 year old brain hallucinating? > > Hammering a single location in core could overheat the > select wires, the individual cores or the select driver > cards. I can believe this could happen. I seriously doubt > it could harm the CCROS or TROS. The model 30 was SLOW, the > original version (first 1000 machines) had a 2.5 us memory > cycle time. But, a B instruction occupied 4 bytes. And the > model 30 memory was ONE SINGLE BYTE wide! So, it would have > to access 4 consecutive bytes over a 10 us period to read > the entire instruction. This would involve t different > select wires in one axis, but likely the same wire in the > other axis. > > On the model 40, memory was 16 bits wide, so it would still > have to access 2 consecutive words. > > Anyway, I was told that on a model 40 (I think) that if you > pressed and held stop, system reset, and load > simultaneously, it would pop a component on a circuit card > in the machine. > > Jon
[cctalk] Re: System 360 question
On 10/31/24 09:35, Donald Whittemore via cctalk wrote: If I remember right I was told back in the early 70s by our IBM CE that physical damage could be done to our model 30 or 40 if we ran a program that did an Assembler instruction, B *For those non-Assembler people that is an instruction to branch to the location of the instruction. I think it might have caused a heat problem in the core or CCROS or TROS. Possible? Or is my 76 year old brain hallucinating? Hammering a single location in core could overheat the select wires, the individual cores or the select driver cards. I can believe this could happen. I seriously doubt it could harm the CCROS or TROS. The model 30 was SLOW, the original version (first 1000 machines) had a 2.5 us memory cycle time. But, a B instruction occupied 4 bytes. And the model 30 memory was ONE SINGLE BYTE wide! So, it would have to access 4 consecutive bytes over a 10 us period to read the entire instruction. This would involve t different select wires in one axis, but likely the same wire in the other axis. On the model 40, memory was 16 bits wide, so it would still have to access 2 consecutive words. Anyway, I was told that on a model 40 (I think) that if you pressed and held stop, system reset, and load simultaneously, it would pop a component on a circuit card in the machine. Jon
[cctalk] Re: System 360 question
On Thu, Oct 31, 2024 at 9:35 AM Donald Whittemore via cctalk wrote: > If I remember right I was told back in the early 70s by our IBM CE that > physical damage could be done to our model 30 or 40 if we ran a program that > did an Assembler instruction, B *For those non-Assembler people that is > an instruction to branch to the location of the instruction. Tangentially related: The classic stack-based HP 3000 has an XEQ instruction to treat a word on the stack as an instruction. It was commonly used to generate a customized EXIT instruction at the end of a function. Pretty much every use case was "XEQ 0" meaning take the word from the top of the stack and execute it, but you could also do XEQ 1-7 specifying how far down the stack from the top your instruction word was. On our Series 40 sometime in the 80s I discovered that if you put an "XEQ n" at n words down the stack, where n was 4-7, the microcode would go into a loop that not even the HALT button on the front panel could interrupt and you would have to power-cycle the CPU to recover (this was an unprivileged operation too). The CPU kept the top four words of the stack in registers, so I guess when the target instruction was outside that range it took a different path through the microcode having to fetch it over and over from memory. Fortunately nobody ever used this for evil purposes because it would have been very hard to identify what was going on since you could not get a memory dump.
[cctalk] Re: System 360 question
On 10/31/24 10:39, Paul Koning wrote: > I could imagine it in PPs, also in 6400 machines since they don't have an > "instruction stack" so instruction fetches would go to memory. For all of > those you'd end up hammmering a single memory cell at high speed, and each > time you do that you get a read and a write cycle, both of which inject some > energy into the cores in question. http://www.bitsavers.org/pdf/cdc/cyber/cyber_70/60258200C_7600_RefMan_Feb71.pdf, PDF page 90 "Duty Cycle Integrator" for SCM in the CPU was the fix for the problem. You won't find it described in the very early 7600 hardware manuals. At first, I wondered if it might be a PPU thing, as the 7600 PPUs operate independently (no "barrel"), but the situation would be easy to avoid, since the casual user doesn't write PPU code. "Don't do that" would be sufficient. At any rate, the 7600 was a marvel of complexity when compared with its earlier 6000-series relatives. I remember marveling at the SCOPE 2 design documents and how very different they were from the 6000 operating system implementation. --Chuck
[cctalk] Re: System 360 question
On 10/31/24 10:39 AM, Paul Koning via cctalk wrote:
On Oct 31, 2024, at 11:41 AM, Chuck Guzis via cctalk
wrote:
On 10/31/24 07:35, Donald Whittemore via cctalk wrote:
If I remember right I was told back in the early 70s by our IBM CE that
physical damage could be done to our model 30 or 40 if we ran a program that
did an Assembler instruction, B *For those non-Assembler people that is an
instruction to branch to the location of the instruction. I think it might
have caused a heat problem in the core or CCROS or TROS.
Possible? Or is my 76 year old brain hallucinating?
I recall that sort of thing was an issue in the CDC 7600; it could throw
parity errors because of core heating. I believe that the problem was
in the PPUs, but it's been too many years to remember accurately.
Ahh, yes, the Duty Cycle Integrator. Slows things down when they heat
up. The DECwriter III has a similar feature when you're printing long
lines of dense characters, such as '#'.
I could imagine it in PPs, also in 6400 machines since they don't have an
"instruction stack" so instruction fetches would go to memory. For all of
those you'd end up hammmering a single memory cell at high speed, and each time you do
that you get a read and a write cycle, both of which inject some energy into the cores in
question.
In CDC's OS (NOS) the idle loop contains a couple of instructions which are
fairly slow, apparently with the specific intent to slow down memory references.
A couple divides, or count instructions, though bit counting might not
be as slow as divides on machines that have an instruction stack,
similar to the difference between iterative shifting and a barrel shifter.
--
Jeff Woolsey {woolsey,jlw}@{jlw,jxh}.com first.last@{gmail,jlw}.com
Spum bad keming.
Nature abhors a straight antenna, a clean lens, and empty storage.
"Delete! Delete! OK!" -Dr. Bronner on disk space management
"Card sorting, Joel." -me, re Solitaire
[cctalk] Re: System 360 question
> On Oct 31, 2024, at 11:41 AM, Chuck Guzis via cctalk > wrote: > > On 10/31/24 07:35, Donald Whittemore via cctalk wrote: >> If I remember right I was told back in the early 70s by our IBM CE that >> physical damage could be done to our model 30 or 40 if we ran a program that >> did an Assembler instruction, B *For those non-Assembler people that is >> an instruction to branch to the location of the instruction. I think it >> might have caused a heat problem in the core or CCROS or TROS. >> >> Possible? Or is my 76 year old brain hallucinating? > > I recall that sort of thing was an issue in the CDC 7600; it could throw > parity errors because of core heating. I believe that the problem was > in the PPUs, but it's been too many years to remember accurately. I could imagine it in PPs, also in 6400 machines since they don't have an "instruction stack" so instruction fetches would go to memory. For all of those you'd end up hammmering a single memory cell at high speed, and each time you do that you get a read and a write cycle, both of which inject some energy into the cores in question. In CDC's OS (NOS) the idle loop contains a couple of instructions which are fairly slow, apparently with the specific intent to slow down memory references. I remember a PDP-11 diagnostic called the "core heating test": it knows the geometry of the core modules it was written for, and uses that knowledge to do lots of memory cycles in a small physical region of the core so that section heats up. It them moves around the core planes, looking for regions that are marginal and start misbehaving when heated. It's a very slow test. I actually ran it once, mostly for grins; it didn't fail. paul
[cctalk] Re: System 360 question
On 10/31/24 07:35, Donald Whittemore via cctalk wrote: > If I remember right I was told back in the early 70s by our IBM CE that > physical damage could be done to our model 30 or 40 if we ran a program that > did an Assembler instruction, B *For those non-Assembler people that is > an instruction to branch to the location of the instruction. I think it > might have caused a heat problem in the core or CCROS or TROS. > > Possible? Or is my 76 year old brain hallucinating? I recall that sort of thing was an issue in the CDC 7600; it could throw parity errors because of core heating. I believe that the problem was in the PPUs, but it's been too many years to remember accurately. --Chuck
