31 Oct
2024
31 Oct
'24
7:35 a.m.
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?
31 Oct
31 Oct
8:41 a.m.
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
10:39 a.m.
On Oct 31, 2024, at 11:41 AM, Chuck Guzis via cctalk
<cctalk(a)classiccmp.org> wrote:
On 10/31/24 07:35, Donald Whittemore via cctalk 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.
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
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. 
11:53 a.m.
On 10/31/24 10:39 AM, Paul Koning via cctalk wrote:
> On Oct 31, 2024, at 11:41 AM, Chuck Guzis via cctalk<cctalk(a)classiccmp.org>
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}(a){jlw,jxh}.com first.last(a){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
12:25 p.m.
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 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
3:12 p.m.
On Thu, Oct 31, 2024 at 9:35 AM Donald Whittemore via cctalk
<cctalk(a)classiccmp.org> 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.
5:02 p.m.
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
9:16 p.m.
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.
<pre>--Carey</pre>
On 10/31/2024 7:02 PM CDT Jon Elson via cctalk
<cctalk(a)classiccmp.org> 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 
9:28 p.m.
On 10/31/24 19:02, Jon Elson via cctalk wrote:
On 10/31/24 09:35, Donald Whittemore via cctalk
wrote:
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
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
0
days inactive
1
days old
8 comments
8 participants
participants (8)
-
CAREY SCHUG -
Chuck Guzis -
Donald Whittemore -
Gavin Scott -
Jeff Woolsey -
jim stephens -
Jon Elson -
Paul Koning