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
7:27 p.m.
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
<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 
1 Nov
1 Nov
9:55 a.m.
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
11:01 a.m.
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
<cctalk(a)classiccmp.org> wrote:
David Barto wrote:
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
barto(a)kdbarto.org
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
11:12 a.m.
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.
12:55 p.m.
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
<pre>--Carey</pre>
On 11/01/2024 1:12 PM CDT Van Snyder via cctalk
<cctalk(a)classiccmp.org> 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.
1:26 p.m.
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
3 p.m.
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 <cctalk(a)classiccmp.org> wrote:
David Barto wrote:
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
barto(a)kdbarto.org
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 
3 Nov
3 Nov
1:22 a.m.
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
<cctalk(a)classiccmp.org> 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
<cctalk(a)classiccmp.org> 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
> barto(a)kdbarto.org
>
>
7:13 a.m.
New subject: HCF [was: System 360 question]
I'm going to suggest that the 1620 had the most HCF instructions of any commercially
produced computer, ever. And the most intentionally used on a daily basis. It is a
memory-to-memory computer with no actual registers (the model II had index registers, but
they were in memory). Few machines had disks, and fewer had tape (magnetic or paper), so
they were almost always run from tabulating cards. I always started my session with the
clear memory command below, and maybe several more times during my scheduled hour.
1. you could press "insert" on the typewriter and enter a program starting at
location zero which was executed when you hit return. If you wanted to clear memory, you
typed in 12 digits "310000900010" (transmit record) which meant copy the
character at location 9 to location 10, then 10 to 11, etc until it found the special
character "record mark", which it would never find as you typed in a zero at the
starting address. watch the address lights till it looped and hit reset. Or "TF
9,8" (transmit field) which worked the other direction looking for a field mark,
which it would never find either. There was a two card program you could put in front of
your card deck that would zero memory then load your program, but since the model 1 did
addition by table lookup in locations 100-199, if there was any chance that table was bad,
it would not work. I think other "catch fire" instruction variants would
continue forever.
2. remember that record mark? if you ever executed an instruction with a record mark in
the address, you got a MAR check red light, a hard reset was required to escape. probably
if in the op code also. And some hard stop for any invalid op code, but these may have
been in the category below.
3. there were other errors, but you could press start to continue and there was a toggle
switch to ignore at least some of them, like a parity error in memory.
4. I seem to recall being told "don't do this, it can break the hardware",
but don't remember any details, and not an instant thing, it would be like the "B
*" loop, causing issues if left running a long time.
The IBM 1401 had a similar architecture (but with 7 useable bits per address vs 5 for the
1620, and was also memory to memory, so probably had instructions that would run forever.
No typewriter available on the 1401 AFAIK, so my example would not have been a routine
action..
<pre>--Carey</pre>
10:06 a.m.
New subject: HCF [was: System 360 question]
1620 owner here.
Sure there are ways to cause a CHECK STOP, and one-instruction infinite loops, including
the IBM-sanctioned one you describe below - which everyone used all day to clobber core -
but that's all they are, they don't damage hardware.
You can make an infinite loop that is sort of less than one instruction. It's an
instruction with a self-referencing indirect address. (Only applies to Model II, and
Model I machines with the Indirect Addressing feature installed, like mine.) When it
tries to fetch the indirect operand, it loops in the Fetch cycle without ever reaching
Execute stage. While that sounds like a core hammer, it is still less than 30% duty cycle
on any one address. Also remember the core stack has air blowing through it nonstop.
There is a setup on the Customer Engineer switch panel (INC plus BYP) that will hammer a
single address, but I don't remember a warning. The only damage risk is if one or
more of your decode switch transistors are failing to ground their A/B/C/D drive line, or
you have an open X or Y line. In that case there's an inductive voltage spike that
will stress all the other D-S transistors. The CE Reference Manual warns against clocking
in this state for more than a couple seconds.
Dave Wise in Hillsboro Oregon
The entire first production run (Suffix B) was paper tape only. Card support was added at
Suffix C.
The core memory array is 3D with two-level selection. The main array select lines are X
and Y. They are driven by 10x10 matrix switches which are in turn driven by 10 decode
switches each on A, B, C, and D. A and B select X, C and D select Y. This is slow but it
minimizes the number of costly high-performance transistors. The 1401 is the same.
________________________________
From: CAREY SCHUG via cctalk <cctalk(a)classiccmp.org>
Sent: Sunday, November 3, 2024 7:13 AM
To: General Discussion: On-Topic and Off-Topic Posts <cctalk(a)classiccmp.org>
Cc: CAREY SCHUG <sqrfolkdnc(a)comcast.net>
Subject: [cctalk] HCF [was: System 360 question]
I'm going to suggest that the 1620 had the most HCF instructions of any commercially
produced computer, ever. And the most intentionally used on a daily basis. It is a
memory-to-memory computer with no actual registers (the model II had index registers, but
they were in memory). Few machines had disks, and fewer had tape (magnetic or paper), so
they were almost always run from tabulating cards. I always started my session with the
clear memory command below, and maybe several more times during my scheduled hour.
1. you could press "insert" on the typewriter and enter a program starting at
location zero which was executed when you hit return. If you wanted to clear memory, you
typed in 12 digits "310000900010" (transmit record) which meant copy the
character at location 9 to location 10, then 10 to 11, etc until it found the special
character "record mark", which it would never find as you typed in a zero at the
starting address. watch the address lights till it looped and hit reset. Or "TF
9,8" (transmit field) which worked the other direction looking for a field mark,
which it would never find either. There was a two card program you could put in front of
your card deck that would zero memory then load your program, but since the model 1 did
addition by table lookup in locations 100-199, if there was any chance that table was bad,
it would not work. I think other "catch fire" instruction variants would
continue forever.
2. remember that record mark? if you ever executed an instruction with a record mark in
the address, you got a MAR check red light, a hard reset was required to escape. probably
if in the op code also. And some hard stop for any invalid op code, but these may have
been in the category below.
3. there were other errors, but you could press start to continue and there was a toggle
switch to ignore at least some of them, like a parity error in memory.
4. I seem to recall being told "don't do this, it can break the hardware",
but don't remember any details, and not an instant thing, it would be like the "B
*" loop, causing issues if left running a long time.
The IBM 1401 had a similar architecture (but with 7 useable bits per address vs 5 for the
1620, and was also memory to memory, so probably had instructions that would run forever.
No typewriter available on the 1401 AFAIK, so my example would not have been a routine
action..
<pre>--Carey</pre>
12:55 p.m.
New subject: HCF [was: System 360 question]
On 11/3/24 10:06, David Wise via cctalk wrote:
1620 owner here.
Sure there are ways to cause a CHECK STOP, and one-instruction infinite loops, including
the IBM-sanctioned one you describe below - which everyone used all day to clobber core -
but that's all they are, they don't damage hardware.
You can make an infinite loop that is sort of less than one instruction. It's an
instruction with a self-referencing indirect address. (Only applies to Model II, and
Model I machines with the Indirect Addressing feature installed, like mine.) When it
tries to fetch the indirect operand, it loops in the Fetch cycle without ever reaching
Execute stage. While that sounds like a core hammer, it is still less than 30% duty cycle
on any one address. Also remember the core stack has air blowing through it nonstop.
Sure, there was more than one way to, say, clear memory on a 1620 with a
single instruction--and it was common knowledge. One could use a
transmit record or transmit field instruction that not only over-wrote
general memory, but also clobbered the instruction itself.
Such is the glory of variable field/record length architectures.
--Chuck
1:39 p.m.
New subject: HCF [was: System 360 question]
On Nov 3, 2024, at 3:55 PM, Chuck Guzis via cctalk
<cctalk(a)classiccmp.org> wrote:
On 11/3/24 10:06, David Wise via cctalk wrote:
Yes, but you don't need such an architecture for this. A PDP-11 can do it also. I
once assigned that as a a pair of homework questions in an assembly language programming
course:
1. Show a one-word PDP-11 program that writes all of memory, in reverse order.
2. Show a one-word PDP-11 program that clears all of memory, in forward order, halting on
completion.
paul
1620 owner here.
Sure there are ways to cause a CHECK STOP, and one-instruction infinite loops, including
the IBM-sanctioned one you describe below - which everyone used all day to clobber core -
but that's all they are, they don't damage hardware.
You can make an infinite loop that is sort of less than one instruction. It's an
instruction with a self-referencing indirect address. (Only applies to Model II, and
Model I machines with the Indirect Addressing feature installed, like mine.) When it
tries to fetch the indirect operand, it loops in the Fetch cycle without ever reaching
Execute stage. While that sounds like a core hammer, it is still less than 30% duty cycle
on any one address. Also remember the core stack has air blowing through it nonstop.
Sure, there was more than one way to, say, clear memory on a 1620 with a
single instruction--and it was common knowledge. One could use a
transmit record or transmit field instruction that not only over-wrote
general memory, but also clobbered the instruction itself.
Such is the glory of variable field/record length architectures. 
1:59 p.m.
New subject: HCF [was: System 360 question]
Paul Koning wrote:
1. Show a one-word PDP-11 program that writes all of
memory, in reverse order.
MOV -(PC),-(PC)
I remember this one from late-Soviet/early-Russian BK0010 hacker clubs...
BK0010 was a "home computer" built around 1801VM1 microprocessor, a
Soviet implementation of basic PDP-11 instruction set. No idea exactly
which DEC model it corresponds to, if any.
2. Show a one-word PDP-11 program that clears all of
memory,
in forward order, halting on completion.
This one I am struggling with - it's been too many decades since I did
any PDP-11 assembly...
M~
2:03 p.m.
New subject: HCF [was: System 360 question]
On Nov 3, 2024, at 4:59 PM, Mychaela Falconia
<falcon(a)freecalypso.org> wrote:
Paul Koning wrote:
Hint: you get to pick the initial values of the registers.
paul
1. Show a one-word PDP-11 program that writes all
of memory, in reverse order.
MOV -(PC),-(PC)
I remember this one from late-Soviet/early-Russian BK0010 hacker clubs...
BK0010 was a "home computer" built around 1801VM1 microprocessor, a
Soviet implementation of basic PDP-11 instruction set. No idea exactly
which DEC model it corresponds to, if any.
2. Show a one-word PDP-11 program that clears all
of memory,
in forward order, halting on completion.
This one I am struggling with - it's been too many decades since I did
any PDP-11 assembly... 
2:48 p.m.
New subject: Self modifying code was HCF
Though not Halt and Catch Fire you guys are forgetting the joy of self
modifying code.
That is how many PDP-8 programs worked. Even the bin loader where the
jump to loop instruction would be replaced with a jump to loaded program
start by the loader itself.
There were many programs that were very difficult to figure out what
they were doing, due to using this technique.
I love the PDP-8 but I don't miss self modifying code at all.
On 11/3/2024 4:03 PM, Paul Koning via cctalk wrote:
On Nov 3, 2024, at 4:59 PM, Mychaela Falconia
<falcon(a)freecalypso.org> wrote:
Paul Koning wrote:
Hint: you get to pick the initial values of the registers.
paul
1. Show a one-word PDP-11 program that writes all
of memory, in reverse order.
MOV -(PC),-(PC)
I remember this one from late-Soviet/early-Russian BK0010 hacker clubs...
BK0010 was a "home computer" built around 1801VM1 microprocessor, a
Soviet implementation of basic PDP-11 instruction set. No idea exactly
which DEC model it corresponds to, if any.
2. Show a one-word PDP-11 program that clears all
of memory,
in forward order, halting on completion.
This one I am struggling with - it's
been too many decades since I did
any PDP-11 assembly...
3:36 p.m.
New subject: Self modifying code was HCF
On 11/3/24 14:48, Mike Katz via cctalk wrote:
Though not Halt and Catch Fire you guys are forgetting
the joy of self
modifying code.
Indeed, this was the *only* way to do things on early first- and
second-generation systems. Even the lowly 1620 CADET, without the
optional indirect addressing feature mandated use of code modification.
--Chuck
3:56 p.m.
New subject: Self modifying code was HCF
I/O addresses for the 8080 come to mind.
Dwight
________________________________
From: Chuck Guzis via cctalk <cctalk(a)classiccmp.org>
Sent: Sunday, November 3, 2024 3:36 PM
To: Mike Katz via cctalk <cctalk(a)classiccmp.org>
Cc: Chuck Guzis <cclist(a)sydex.com>
Subject: [cctalk] Re: Self modifying code was HCF
On 11/3/24 14:48, Mike Katz via cctalk wrote:
Though not Halt and Catch Fire you guys are forgetting
the joy of self
modifying code.
Indeed, this was the *only* way to do things on early first- and
second-generation systems. Even the lowly 1620 CADET, without the
optional indirect addressing feature mandated use of code modification.
--Chuck
7:17 p.m.
New subject: Self modifying code was HCF
On 11/3/24 15:56, dwight wrote:
I/O addresses for the 8080 come to mind.
Dwight
Well, in theory you could avoid that one by constructing 256-entry
tables for IN and OUT instructions and using a computed CALL/JUMP to
access the right one. The 8080 I/O address space is only 256 addresses.
Not pretty, but a possible solution.
--Chuck
8:34 p.m.
New subject: Self modifying code was HCF
On Mon, Nov 4, 2024 at 12:05 AM dwight via cctalk <cctalk(a)classiccmp.org> wrote:
I/O addresses for the 8080 come to mind.
BASIC-09 under OS-9 (6809 processor) lets you execute a system call
from a BASIC program. The problem is that a system call is coded as a
software interrupt instruction followed by a byte giving the call
number. So doing that implies self-modifying code. But under OS-9,
code modules are re-entrant and can be called by any process running
on the machine. You could find the process is switched between storing
the call number byte and executing the instruction.
It gets round this by building a trivial program (basically a software
interrupt, the call number byte, and a return instructio) on the user
stack (which is local to each process) and then calling it there.
On the HP9825 with a String Variables ROM and an Advanced Programming
ROM, there is a documented instruction to store the contents of a
string variable as a program line which of course you can then
execute. This is one of the few high level languages I've seen with a
specific instruction for self-modifyng code.
-tony
11:15 p.m.
New subject: Self modifying code was HCF
On Sun, Nov 3, 2024 at 10:35 PM Tony Duell via cctalk
<cctalk(a)classiccmp.org> wrote:
This is one of the few high level languages I've
seen with a
specific instruction for self-modifying code.
Don't forget the ALTER statement in COBOL which changes a GO TO
statement in some paragraph somewhere to point to a different
destination than what's written in the source code.
COBOL has a few funky features. Another one is that you can have a
sequence of Paragraphs:
PARA-A.
PARA-B.
PARA-C.
PARA-D.
And in one place you can say PERFORM PARA-A THROUGH PARA-C, and in
another place PERFORM PARA-B THROUGH PARA-D, etc. which means you have
to somehow pass in the paragraph you want to return from and every
paragraph has to end with a conditional return based on whether it's
the requested exit point. Some machines had special machine
instructions for COBOL Paragraph call and return to help deal with
these and similar oddities.
4:19 p.m.
New subject: HCF [was: System 360 question]
2. Show a one-word PDP-11 program that clears all of
memory,
in forward order, halting on completion.
This one I am struggling with - it's been too many decades since I did
any PDP-11 assembly...
8:37 p.m.
New subject: HCF [was: System 360 question]
On Mon, Nov 4, 2024 at 4:06 AM Mychaela Falconia via cctalk
<cctalk(a)classiccmp.org> wrote:
Paul Koning wrote:
Does that work on all models of PDP11?
I had an idea that (as in C) the order of the decrements and reads was
not specified by the instruction set definition and that on some
machines (the 11/45?) it doubly decrements PC before reading or
storing.
-tony
1. Show a one-word PDP-11 program that writes all
of memory, in reverse order.
MOV -(PC),-(PC) 
9:34 p.m.
New subject: HCF [was: System 360 question]
On 2024-11-03 9:37 p.m., Tony Duell via cctalk wrote:
On Mon, Nov 4, 2024 at 4:06 AM Mychaela Falconia via
cctalk
<cctalk(a)classiccmp.org> wrote:
Where there any user instructions between models that gave strange
behavior on the wrong machine?
Paul Koning wrote:
Does that work on all models of PDP11?
I had an idea that (as in C) the order of the decrements and reads was
not specified by the instruction set definition and that on some
machines (the 11/45?) it doubly decrements PC before reading or
storing.
-tony 1. Show a one-word PDP-11 program that writes all
of memory, in reverse order.
MOV -(PC),-(PC)
4 Nov
4 Nov
5:31 a.m.
New subject: model dependent differences [was: HCF [was: System 360 question]]
not wrong, but in my benchmarks, the order of how long it took to clear out a 255 byte
area exactly reversed between the 370/168 and 3033. I hope I remember all the ways, not
sure if I remember the order, or the exact syntax. Not included are the 'costs'
of storage required for code and data areas. I did not think to try with various byte
alignments of the fields, or account for mvcl being interuptable (though i ran during low
activity times). this order was fastest to slowest on 3033, slowest to fastest on 168. I
did this after reading a claim that the lm/stm was the fastest way.
also inspired by a programmer that used a LOOP including "MVC field, field+1) to left
align a large alphanumeric field, that consumed 1/2 of the CPU time for the main overnight
posting run, causing online to not come up on time in the morning...over 4 hours on the
ONE instruction.
xc field,field
mvc field,field-1
mvc field,=xl255'0'
mvcl field,=x'00' (well load the registers to accomplish this)
stm/lm (store all but base reg, load them with zeros, several inline stm, restore)
...I wonder what the order would be in Hercules...anybody want to take the challenge?
I'd guess like the 168 maybe with the XC moved to be faster or fastest. I had
Hercules installed and running several times in the distant past, but...without access to
a legal zVM operating system, not of much interest to me now.
<pre>--Carey</pre>
On 11/03/2024 11:34 PM CST ben via cctalk
<cctalk(a)classiccmp.org> wrote:
On 2024-11-03 9:37 p.m., Tony Duell via cctalk wrote:
On Mon, Nov 4, 2024 at 4:06 AM Mychaela Falconia
via cctalk
<cctalk(a)classiccmp.org> wrote:
Where there any user instructions between models that gave strange
behavior on the wrong machine?
Paul Koning wrote:
Does that work on all models of PDP11?
I had an idea that (as in C) the order of the decrements and reads was
not specified by the instruction set definition and that on some
machines (the 11/45?) it doubly decrements PC before reading or
storing.
-tony 1. Show a one-word PDP-11 program that writes all
of memory, in reverse order.
MOV -(PC),-(PC)
7:29 a.m.
New subject: HCF [was: System 360 question]
On Nov 4, 2024, at 12:34 AM, ben via cctalk
<cctalk(a)classiccmp.org> wrote:
On 2024-11-03 9:37 p.m., Tony Duell via cctalk wrote:
Yes, and they are documented in the PDP-11 architecture manual, in an appendix. But it
cases that are machine dependent are more exotic, things like mixing a register reference
with an auto inc/dec of the same register. The magic move will work on any of them.
On the "one word clear", I missed a detail. I pointed out you get to initialize
the registers. You can also initiate one memory word. In other words: choose two words
in memory, and registers contents, such that execution will give you a memory full of
zeroes and a halted machine.
paul
On Mon, Nov 4, 2024 at 4:06 AM Mychaela Falconia
via cctalk
<cctalk(a)classiccmp.org> wrote:
Where there any user instructions between models that gave strange behavior on the wrong
machine?
Paul Koning wrote:
Does that work on all models of PDP11?
I had an idea that (as in C) the order of the decrements and reads was
not specified by the instruction set definition and that on some
machines (the 11/45?) it doubly decrements PC before reading or
storing.
-tony 1. Show a one-word PDP-11 program that writes all
of memory, in reverse order.
MOV -(PC),-(PC)
9:15 a.m.
New subject: HCF [was: System 360 question]
Paul Koning wrote:
On the "one word clear", I missed a detail.
I pointed out you get to
initialize the registers. You can also initiate one memory word. In other
words: choose two words in memory, and registers contents, such that
execution will give you a memory full of zeroes and a halted machine.
OK, *now* the problem has a clear solution:
1) Write 000000 into memory word 015720;
2) Write 015720 [ MOV @-(PC),(R0)+ ] into the last word of system RAM;
3) Clear R0;
4) Jump to the last word of RAM where you wrote the 015720 instruction.
This solution does require that the system RAM be of certain minimum
size. Assuming power-of-2 sizes only, the machine must have at least
8 KiB of RAM, otherwise location 015720 does not exist. What was the
smallest RAM configuration on PDP-11?
M~
9:42 a.m.
New subject: The other dectape
The other dectape (image below)
1 bit =- 1/8th inch
1 byte = 1 inch
DECtp Tape Measure DEC DIGITAL EQUIPMENT CORPORATION - 1980's - Picture
1 of 5
12:23 p.m.
New subject: HCF [was: System 360 question]
On Nov 4, 2024, at 12:15 PM, Mychaela Falconia
<falcon(a)freecalypso.org> wrote:
Paul Koning wrote:
Yes, that's the correct answer.
4 kW is the smallest PDP-11 memory I know of, though I don't have direct exposure to
the T-11.
paul
On the "one word clear", I missed a
detail. I pointed out you get to
initialize the registers. You can also initiate one memory word. In other
words: choose two words in memory, and registers contents, such that
execution will give you a memory full of zeroes and a halted machine.
OK, *now* the problem has a clear solution:
1) Write 000000 into memory word 015720;
2) Write 015720 [ MOV @-(PC),(R0)+ ] into the last word of system RAM;
3) Clear R0;
4) Jump to the last word of RAM where you wrote the 015720 instruction.
This solution does require that the system RAM be of certain minimum
size. Assuming power-of-2 sizes only, the machine must have at least
8 KiB of RAM, otherwise location 015720 does not exist. What was the
smallest RAM configuration on PDP-11?
3 Nov
3 Nov
11:12 p.m.
New subject: HCF [was: System 360 question]
Tony Duell wrote:
[Context: MOV -(PC),-(PC) ]
Does that work on all models of PDP11?
No idea, I just know that it worked on Soviet 1801VM1, which is where
I learned it.
Meanwhile, I am still struggling with the second part of Paul's
original challenge:
2. Show a one-word PDP-11 program that clears all of
memory,
in forward order, halting on completion.
The problem statement says that the trick must *clear* all of memory,
which I read as making it all zeros, rather than some other clobber
pattern. The "halting on completion" part makes sense: 000000 is the
opcode for HALT, hence if there is a magic instruction running in a
loop at the end of memory that writes zeros moving forward, once this
write of zeros hits the executing code, halt will occur.
But I am still not able to come up with a single-word PDP-11
instruction that does these two functions simultaneously:
(1) decrements PC so that the instruction keeps re-executing, and
(2) writes zeros moving forward. Paul gave this hint:
Hint: you get to pick the initial values of the
registers.
I can easily think of something like this:
MOV -(PC),(R0)+
But this one won't satisfy the requirement of writing zeros: it does a
forward clobber, but writes 014720 (the opcode for this instruction)
instead of zeros. I thought of refining it like this:
BIC -(PC),(R0)+
This one gets a bit closer in that it will clear _some_ bits to zero
in every memory word, but still, it is not a write of all zeros.
Then I thought about the XOR instruction that appears in later PDP-11
models; something like:
XOR R0,-(PC)
If R0 is preset to 074047 (the opcode), the instruction will overwrite
itself with 0 word (HALT), and then the halt will happen. But that's
only one word, not clearing all of memory, and of course it would be
even simpler with:
CLR -(PC)
Why is there a -(PC) operand in each of my attempts above? Because I
don't see another way to make the instruction keep re-executing. If
it weren't for this re-execution requirement, the solution would be as
simple as
CLR (R0)+
but of course that one will result in the CPU executing garbage
following this instruction after clearing just one memory word - not
interesting...
If PDP-11 had 3-operand instructions like VAXen do, we could do an
instruction that has -(PC) as one operand, a preset register as the
second operand to the addition or XOR or whatever, and something like
(R0)+ as the destination operand - but we are talking about PDP-11
here, not VAX, and the requirement is for a single-word instruction.
Thus I do not see how a single PDP-11 instruction can accomplish what
is asked here - unless I am misinterpreting the problem statement...
M~
4:09 p.m.
New subject: HCF [was: System 360 question]
On 11/3/24 15:39, Paul Koning via cctalk wrote:
Yes, but you don't need such an architecture for this. A PDP-11 can do it also. I
once assigned that as a a pair of homework questions in an assembly language programming
course:
1. Show a one-word PDP-11 program that writes all of memory, in reverse order.
2. Show a one-word PDP-11 program that clears all of memory, in forward order, halting on
completion.
Yes, I did something like this when we got our first VAX 11/780.
Jon
12:56 p.m.
New subject: HCF [was: System 360 question]
CAREY SCHUG wrote:
I'm going to suggest that the 1620 had the most
HCF instructions of any commercially
produced computer, ever. And the most intentionally used on a daily basis.
<snip>
1. you could press "insert" on the
typewriter and enter a program starting at
location zero which was executed when you hit return. If you wanted to clear memory,
you
typed in 12 digits "310000900010" (transmit record) which meant copy the
character at location 9 to location 10, then 10 to 11, etc until it found the special
character "record mark", which it would never find as you typed in a zero at
the
starting address. watch the address lights till it looped and hit reset.
Note that, as written, your instruction doesn't clear memory, it shifts memory to the
left by one digit every complete cycle through memory, because the destination address is
lower than the source address. What you need to do a "forward smear," where the
source address is lower than the destination address, so that the destination digits
become source digits as the addresses increase, e.g., 310000300002.
That would only work on a 1620 Model 1, however. It wouldn't work on a Model 2. Both
models fetched two digits from memory at a time, but for many instructions (including TR
and TF) the Model 2 would stash the digit at the odd address and use it during the
odd-address fetch cycle, saving a redundant fetch from the same digit pair in memory.
Therefore, the source and destination addresses had to differ by at least 2 -- this will
work on the Model 2: 310000400002.
But nobody bothered with that on the Model 2, because it had a hardware memory clear
mechanism. Simultaneously pressing MODIFY (which wasn't present on the Model 1) and
CHECK RESET on the console would turn on the CLR MEM control gate. Then pressing START
would clear all of memory once and halt.
<snip>
2. remember that record mark? if you ever executed an
instruction with a record mark in
the address, you got a MAR check red light, a hard reset was required to escape.
probably
if in the op code also. And some hard stop for any invalid op code, but these may have
been in the category below.
Shouldn't these be considered good error-trapping features and not in the same league
as HCF? An RM had the 8 and 2 bits set, so it wasn't a valid decimal digit, and
couldn't be used in an address. An RM in the Q field of an immediate instruction was
okay, though.
3. there were other errors, but you could press start
to continue and there was a toggle
switch to ignore at least some of them, like a parity error in memory.
You could press START to continue after a memory parity error or an I/O parity error, but
not after a MAR CHECK.
The PROGRAM/STOP toggle switches (there were four of them, for DISK, MEMORY, I/O, and
arithmetic OVERFLOW) did not cause the errors to be ignored, they just controlled whether
the CPU halted when exceptions occurred. In all cases, internal flags (termed
"indicators") were set, which could be interrogated by the BI and BNI
instructions. The MEMORY switch had no effect on a MAR CHECK -- the CPU always did a hard
stop on those and required a RESET.
<snip>
Paul
1:45 p.m.
New subject: HCF [was: System 360 question]
On 11/3/24 12:56, paul.kimpel--- via cctalk wrote:
On card-oriented CADETs, there were a few alternatives to the nuisance
of having to multipunch a record or group mark on an 026. I seem to
recall that a period read numerically translated to 8-2-1 and worked
just as well.
Among other shortcomings of the 1620, there was no way to test for
numeric blank (8-4). You just had to know that it was there. There
were several such bugaboos, with which Dijkstra had issues. Still, the
1620 was capable of doing real work--and its 1710 relative was capable
of industrial process control application.
--Chuck
CAREY SCHUG wrote:
2. remember
that record mark? if you ever executed an instruction with a record mark in
the address, you got a MAR check red light, a hard reset was required to escape.
probably
if in the op code also. And some hard stop for any invalid op code, but these may have
been in the category below.
Shouldn't these be considered good error-trapping features and not in the same league
as HCF? An RM had the 8 and 2 bits set, so it wasn't a valid decimal digit, and
couldn't be used in an address. An RM in the Q field of an immediate instruction was
okay, though.
1 Nov
1 Nov
12:37 p.m.
New subject: undocumented instructions including HCF [was: System 360 question]
I had remembered the HCF as being a z-80 thing, so I searched for it.
All I can find says it was 6800, not 6502.
https://en.wikipedia.org/wiki/Halt_and_Catch_Fire_(computing)
http://www.ffd2.com/fridge/docs/6502-NMOS.extra.opcodes
http://www.z80.info/zip/z80-documented.pdf
New question: what do emulators do with these undocumented instructions? I seem to recall
in the 8086 (?) family tree, some clone cpu chips had actually useful instructions.
<pre>--Carey</pre>
On 11/01/2024 11:55 AM CDT Peter Coghlan via cctalk
<cctalk(a)classiccmp.org> 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
2:57 p.m.
New subject: undocumented instructions including HCF [was: System 360 question]
I had remembered the HCF as being a z-80 thing, so I
searched for it.
All I can find says it was 6800, not 6502.
The NMOS 6502 has a number of undocumented lock-up opcodes. However, they arise
as a consequence of its instruction decoder PLA and weren't intended for
testing like the 6800 HCF. They were eliminated in the 65C02, though later
versions add the STP opcode as an intentional way to halt the CPU until reset.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.com
-- Eggheads unite! You have nothing to lose but your yolks. -- Adlai Stevenson
3:43 p.m.
New subject: undocumented instructions including HCF [was: System 360 question]
There was a "Killer Poke" on the commodore PET that would alter the video
horizontal output frequency, which had the effect of physically damaging
the video hardware as the high voltage was generated by the flyback
transformer.l and there was no regulation.
It's mere existence made my father paranoid about machine code
programming. I was probably 10 at the time.
On Sat, 2 Nov 2024, 8:57 am Cameron Kaiser via cctalk, <
cctalk(a)classiccmp.org> wrote:
I had remembered the HCF as being a z-80 thing,
so I searched for it.
All I can find says it was 6800, not 6502.
The NMOS 6502 has a number of undocumented lock-up opcodes. However, they
arise
as a consequence of its instruction decoder PLA and weren't intended for
testing like the 6800 HCF. They were eliminated in the 65C02, though later
versions add the STP opcode as an intentional way to halt the CPU until
reset.
--
------------------------------------ personal:
http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com *
ckaiser(a)floodgap.com
-- Eggheads unite! You have nothing to lose but your yolks. -- Adlai
Stevenson
4:13 p.m.
New subject: undocumented instructions including HCF [was: System 360 question]
The IBM monochrome monitor could be damaged by putting it into an
unsupported mode.
The idea of a command that would brick the system is popular.
It may be possible, but it's very difficult to track down the details from
FOAFs.
--
Grumpy Ol' Fred cisin(a)xenosoft.com
2 Nov
2 Nov
8:50 a.m.
New subject: undocumented instructions including HCF [was: System 360 question]
The idea of a command that would brick the system is popular.
It may be possible, but it's very difficult to track down the details from
FOAFs.
Not bricking, but breaking:
From multicians.org:
"The tape drives used on the GE-635
<https://www.multicians.org/mga.html#635> were some of the first self
threading drives. As a result they needed an extremely long tape leader
before the "reflector spot" and this was a pain for MIT operators
<https://www.multicians.org/mgo.html#operator> when loading the tapes onto
the IBM 7094 <https://www.multicians.org/mga.html#7094> running CTSS
<https://www.multicians.org/mgc.html#CTSS>. Lee Varian
<https://www.multicians.org/multicians.html#Varian> wrote some tricky code,
and we put two load point reflectors on the tapes we shuttled between the
7094 and the 635. The 635 would only sense the farther-in load point; the
7094 would load to the early load point and then Lee's code would space it
way out and rewind back to the 635 load point. If we didn't find the right
label, his code tried three times and then deliberately broke the tape so
the operator would have to put on new load points at the correct places.
(You could break a tape on the '94 by putting it into high speed rewind and
then doing a reset data channel command, I suppose it's safe to reveal this
now.)"
-- Charles
X-Clacks-Overhead: GNU Terry Pratchett
31 Oct
31 Oct
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
48
days inactive
52
days old
45 comments
23 participants
participants (23)
-
ben -
Cameron Kaiser -
CAREY SCHUG -
Charles Anthony -
Chuck Guzis -
David Barto -
David Wise -
Donald Whittemore -
Doug Jackson -
dwight -
Fred Cisin -
Gavin Scott -
Jeff Woolsey -
jim stephens -
Jon Elson -
Mike Katz -
Mychaela Falconia -
Paul Koning -
paul.kimpel＠digm.com -
Peter Coghlan -
raymond.wiker＠icloud.com -
Tony Duell -
Van Snyder