Thread: Core Memory
View Single Post
  #26   Report Post  
Posted to alt.binaries.schematics.electronic
Dan[_14_] Dan[_14_] is offline
external usenet poster
 
Posts: 107
Default Core Memory

flipper wrote:
On Mon, 16 Aug 2010 02:34:53 -0500, Dan wrote:

flipper wrote:

snip

I miss das switchen und blinken lighten. Computers should have lots of
blinking lights.

If nothing else you could stare at the lights and pretend you were in
deep thought. If nothing else it was soothing.

Oh wow, I hadn't though of that in decades but 'das blinken lighten'
reminds me of the time I, as a high school 'summer job' teenager,
found a fatal flaw in a new computer design but it's too long for
here. If you're interested I'll tell it.

You could start another thread.


Well, the machine had core memory and while that has nothing to do
with the story it's enough to feign continuity

The reason das blinken lighten reminded me of it is because, just as
Scotty opined in "Relics" that he could tell the speed the Enterprise
(no bloody A, B, C, *or* D) was going "by the feel of the deck
plates," so it was with your program and das blinken lighten.

I had a summer job at a company that, among other things, made
minicomputers and was assigned to write a very simple 'exercise'
machine language program for a new tape drive they were working on. I
could tell where the program was by the blinks. Load tape, blinky
blinky, seek record, blinkity blink blink, read record, blip blip blip
blip blip.. etc.

Then all hell broke loose with every address light coming on as the
machine zipped through all of memory.

What the...? That ain't right. And I can't reset the program either.

I look at the data buffer: all zeroes. Look at the program: all
zeroes. Everything is zeroes with not a single core set to '1' (notice
now I worked in "core" memory )

Now, the computer was a prototype and the tape drive was a prototype,
so there weren't a plethora of diagnostic tools for these dern things,
and with memory all zeroes 'debug' became pretty much an intellectual
exercise.

The obvious first guess is I made a programming error but I had made
it as simple as possible to preclude just this sort of thing, yet
there I was staring at all 0's.

There had to be *something* writing all those zeroes and it couldn't
be the tape drive. For one, it wasn't anywhere near *that* fast. And
it couldn't be my program either since, even if it tried, it would
crash before finishing from being corrupted to '0s' itself and
executing 0 would... uh

Ah HA!

Executing 0 was a 'fatal flaw' but how did a 0 get there to begin
with?

I finally concluded that, under these circumstances, the 'fatal flaw'
couldn't be tripped unless... gulp... "the geniuses who work here and
wouldn't if they weren't" had miswired the DMA channel but, as 'the
kid', was a bit reluctant to tell them as much.

But I did and they had. The DMA channel was sprinkling data where ever
it felt like which, of course (thank you Murphy), included on top of
my program and that confirmed the 'fatal flaw' trigger could happen.

The 'fatal flaw' was how the op code worked and, in particular, 'store
the A register' (or whichever register, I forget). As was typical of
the era, one of the addressing modes divided the 16 bit word into two
halves with the first being op code plus some addressing mode bits and
the second half an 8 bit relative offset. The machine executed in the
order: fetch instruction, increment address counter, execute
instruction, so an offset of '0' meant the next location after the
instruction (not terribly useful and, in this case, tragic).

Well, as it turned out, the 'store' code with that relative addressing
mode was '0' and if the offset was '0' and you had '0' in the register
then it stored 0 in the next location and then executed that 0, which
did the same thing, storing another 0 in the next location, which it
then executed, which....

It simply zipped as fast as it could go perpetually writing zeroes
through all of memory over and over till you hit HALT. Mystery solved.

One could argue that would only happen in combination with some other
'error' (like it did there) but that's not only tempting Murphy it's
handing him exactly the kind of 'passes every diagnostic one in a
million only happens at the worst possible moment' screw up he loves
to dish out. And wiping all evidence to 0 was a real nice finishing
touch.

I suggested they modify the op codes so that the essentially useless
'0' offset be interpreted as defining an 'extended' 2 word instruction
with the next word used as an absolute address (and double increment
around it).

I never got any word back that summer on how they took the suggestion
but was rather pleased to observe a few years later that the official
instruction set did, indeed, define that same double word extension.

(I also noticed they changed the op code value but that doesn't
eliminate the problem. It only alters which 'magic number' would
trigger it.)

You always remember the bizarre ones and I'll never forget das blinken
lighten going zaaaaaaaaaaaaaaaaaaaap across the address register

Dan, U.S. Air Force, retired

In avionics we used the term "when in doubt tune for maximum flame
and minimum smoke."

Dan, U.S. Air Force, retired


Egad, I have made programming mistakes as bad as that, but no one
ever accused me of being an expert.

Dan, U.S. Air Force, retired