I was at UCLA in 1964, joined the Computer Club, learned IBM 7090 and 1401 assembly language and Fortran II, and programmed their historic SWAC computer.
For a year and a half, starting in 1949, the SWAC was the fastest computer in the world. It used Williams tube memories with 256 36-bit words. There were 36 tubes, each storing one bit of each word in a 16x16 array. You could look at the tubes and see the bits.
I wrote an assembler for it on the 1401. It was fairly straightforward except that the SWAC read row binary punched cards and the 1401 wrote column binary cards.
The nice thing about the SWAC was, since it was obsolete, I could get as much time on it as I wanted. I probably spent too much time on it (and the 7094 and 1401 at the Computing Facility).
I also wrote an assembler for the 1401 that became used by others since it ran about 5 times as fast as the IBM provided one.
The SWAC took a whole wall of a large room and took 15 minutes when powered up for everything to stabilize and be usable.
Names which pop into my mind are Fred Hollander (who ran the hardware part of the Computing Facility) and Alex Hurwitz, a mathematician and programmer who, among other things, programmed the SWAC to find two new Mersenne primes. I remember once when something went wrong with the SWAC, Alex found the problem and fixed it by doing some soldering.
I have lots of memories of those years. They were fun.
Another excellent article, Ned. Thanks for posting this. My mind did a backflip when I read this part:
"That means that all those old computers in storage somewhere, in museums, in landfills or wherever they may be, likely still contain the last program they ever ran. And If you could find a way to power one on, that code could actually run again.
Spooky."
If that doesn't sound like a sci-fi writing prompt, nothing does. Love it.
Great article Ned! It was nice to look back on the trials and tribulations of designing and actually applying system memory over the ages.
There was actually another, not so well known core type memory, called "Rod Memory", invented by NCR, and used in their "Century" series computers. Instead of cores, it used small round rods, just 1/16" long, and approximately the diameter of a human hair. The nice part about them was that a type of wire-wrap technology was used to wire them, making them much easier and quicker to manufacture. To my knowledge, the first systems were built in 1968, and used all NAND gate IC's to form the various complex circuits.
I remember when I installed my first, humongous, terribly expensive almost-one-terabyte storage array (it was actually 920 GB occupying a full rack cabinet with 5.25" 47 GB disks) and how fast it was: close to 100MB/s!
Nowadays I routinely deploy 1 PB systems. Most probably when I retire I'll be deploying 1 EB ones.
It seems like you're highlighting a perspective on how advancements in hardware capabilities, particularly cheaper memory and faster processing, may have led to less efficiency in software engineering. Your example with phone systems illustrates how, in the past, there was a need for more efficient use of resources due to limitations, while today's software may be perceived as heavier without necessarily providing a proportional increase in functionality. It's an interesting observation on the evolving relationship between hardware capabilities and software efficiency. https://bit7.org/drift-boss.html
One of the most unconventional use of ferrite cores was the digitisation of signals from a particle detector, the spark chamber. It was used first in balloon then satellite experiments, the last being EGRET on board the Compton Observatory operating until year 2000.
I remember back in the late 80's and 90's working in a test lab that had a PDP with ferrite core memory which ran a language called Basak4 (If I remember correctly) which had the incredibly useful command ON POWERFAIL which used the persistence of the core RAM to allow you to recover from where you left off when power came back after an outage. Very useful because you really didn't want to lose a whole 5000 hour test if something went wrong with the power half way through.
I always wonder why An Wang gets so much credit for "inventing" core memory. Sure, he has a seminal patent, but folks did core memory first, and Jay Forrester made the first really usable core memory for Whirlwind a few years later.
Is there a way to edit a comment? I did not see the option, so I copied it all, deleted the comment, and pasted it as a new comment, which I could then edit.
Thanks for writing about delay line memory! Whenever I get to take someone to the Computer History Museum, I try to beeline directly to that display. Telling people about storing data as signals in liquid really gives me a thrill. Plus, Mercury is such an amazing substance. It takes me right back to playing around with Mercury (safely!) as a kid.
For parents who want to relive the Mercury memories of their youth (sawing apart golfballs, anyone?) a next best bet is Gallium, which has similarly COOL effects, yet is considered safe to play with and handle, and is considered non-toxic in its elemental form. Just don't let them ingest or inhale it. A good learning point for talking about different forms of data storage!
I feel like teaching kids about different forms of memory storage will help get kids out of the trap of thinking that "the current way things are done is the way they will always be". When someone comes up to me talking about creating the next Facebook, I like to tell them stories about what it must have been like to work on the first GPS (an amazing volunteer at Computer History Museum shared this story with me as I asked him about a GIANT module on the showroom floor).
Getting trapped in the idea that of simply working on the next social network makes me fairly upset. There are WHOLE NEW ways to store data in the future. Those frontiers are as exciting as the Japanese inventors of the blue LED. There's such an exciting world to explore beyond the bounds of what is "now", provided there is just a little bit of knowledge about the past.
Excellent article. I loved the descriptions of materials at hand, and some of the backstory when the machinations were made. I simply love this stuff. Ohhh, I came from Hackaday...and happily so.
Ever cheaper memory and faster processing has in my mind made software engineering less efficient. If you look at word as a word processer, current incarnations are a lot heavier but do not do a lot more to justify that.
Example, in phone systems, for tones, a quarter of a sinus wave used to be sampled and stored in 8byte eprom. By flipping on x and y, a full sinus wave was generated. A full wave would have been 32 bytes. Way to expensive..
Some memories of mine.
I was at UCLA in 1964, joined the Computer Club, learned IBM 7090 and 1401 assembly language and Fortran II, and programmed their historic SWAC computer.
For a year and a half, starting in 1949, the SWAC was the fastest computer in the world. It used Williams tube memories with 256 36-bit words. There were 36 tubes, each storing one bit of each word in a 16x16 array. You could look at the tubes and see the bits.
I wrote an assembler for it on the 1401. It was fairly straightforward except that the SWAC read row binary punched cards and the 1401 wrote column binary cards.
The nice thing about the SWAC was, since it was obsolete, I could get as much time on it as I wanted. I probably spent too much time on it (and the 7094 and 1401 at the Computing Facility).
I also wrote an assembler for the 1401 that became used by others since it ran about 5 times as fast as the IBM provided one.
The SWAC took a whole wall of a large room and took 15 minutes when powered up for everything to stabilize and be usable.
Names which pop into my mind are Fred Hollander (who ran the hardware part of the Computing Facility) and Alex Hurwitz, a mathematician and programmer who, among other things, programmed the SWAC to find two new Mersenne primes. I remember once when something went wrong with the SWAC, Alex found the problem and fixed it by doing some soldering.
I have lots of memories of those years. They were fun.
Thanks for the memories!
Another excellent article, Ned. Thanks for posting this. My mind did a backflip when I read this part:
"That means that all those old computers in storage somewhere, in museums, in landfills or wherever they may be, likely still contain the last program they ever ran. And If you could find a way to power one on, that code could actually run again.
Spooky."
If that doesn't sound like a sci-fi writing prompt, nothing does. Love it.
Do you have a Patreon or other option to support your work here? Your stories enrich my day, and I'd like to express that with some kind of support.
Great article Ned! It was nice to look back on the trials and tribulations of designing and actually applying system memory over the ages.
There was actually another, not so well known core type memory, called "Rod Memory", invented by NCR, and used in their "Century" series computers. Instead of cores, it used small round rods, just 1/16" long, and approximately the diameter of a human hair. The nice part about them was that a type of wire-wrap technology was used to wire them, making them much easier and quicker to manufacture. To my knowledge, the first systems were built in 1968, and used all NAND gate IC's to form the various complex circuits.
I remember when I installed my first, humongous, terribly expensive almost-one-terabyte storage array (it was actually 920 GB occupying a full rack cabinet with 5.25" 47 GB disks) and how fast it was: close to 100MB/s!
Nowadays I routinely deploy 1 PB systems. Most probably when I retire I'll be deploying 1 EB ones.
It seems like you're highlighting a perspective on how advancements in hardware capabilities, particularly cheaper memory and faster processing, may have led to less efficiency in software engineering. Your example with phone systems illustrates how, in the past, there was a need for more efficient use of resources due to limitations, while today's software may be perceived as heavier without necessarily providing a proportional increase in functionality. It's an interesting observation on the evolving relationship between hardware capabilities and software efficiency. https://bit7.org/drift-boss.html
One of the most unconventional use of ferrite cores was the digitisation of signals from a particle detector, the spark chamber. It was used first in balloon then satellite experiments, the last being EGRET on board the Compton Observatory operating until year 2000.
I remember back in the late 80's and 90's working in a test lab that had a PDP with ferrite core memory which ran a language called Basak4 (If I remember correctly) which had the incredibly useful command ON POWERFAIL which used the persistence of the core RAM to allow you to recover from where you left off when power came back after an outage. Very useful because you really didn't want to lose a whole 5000 hour test if something went wrong with the power half way through.
I always wonder why An Wang gets so much credit for "inventing" core memory. Sure, he has a seminal patent, but folks did core memory first, and Jay Forrester made the first really usable core memory for Whirlwind a few years later.
Is there a way to edit a comment? I did not see the option, so I copied it all, deleted the comment, and pasted it as a new comment, which I could then edit.
Thanks for writing about delay line memory! Whenever I get to take someone to the Computer History Museum, I try to beeline directly to that display. Telling people about storing data as signals in liquid really gives me a thrill. Plus, Mercury is such an amazing substance. It takes me right back to playing around with Mercury (safely!) as a kid.
For parents who want to relive the Mercury memories of their youth (sawing apart golfballs, anyone?) a next best bet is Gallium, which has similarly COOL effects, yet is considered safe to play with and handle, and is considered non-toxic in its elemental form. Just don't let them ingest or inhale it. A good learning point for talking about different forms of data storage!
I feel like teaching kids about different forms of memory storage will help get kids out of the trap of thinking that "the current way things are done is the way they will always be". When someone comes up to me talking about creating the next Facebook, I like to tell them stories about what it must have been like to work on the first GPS (an amazing volunteer at Computer History Museum shared this story with me as I asked him about a GIANT module on the showroom floor).
Getting trapped in the idea that of simply working on the next social network makes me fairly upset. There are WHOLE NEW ways to store data in the future. Those frontiers are as exciting as the Japanese inventors of the blue LED. There's such an exciting world to explore beyond the bounds of what is "now", provided there is just a little bit of knowledge about the past.
Delay Line Memory all the way!
Excellent article. I loved the descriptions of materials at hand, and some of the backstory when the machinations were made. I simply love this stuff. Ohhh, I came from Hackaday...and happily so.
Very cool, came here from Hackaday and will definitely be coming back.
You forgot rotating drum memory and later disc drives.
Ever cheaper memory and faster processing has in my mind made software engineering less efficient. If you look at word as a word processer, current incarnations are a lot heavier but do not do a lot more to justify that.
Example, in phone systems, for tones, a quarter of a sinus wave used to be sampled and stored in 8byte eprom. By flipping on x and y, a full sinus wave was generated. A full wave would have been 32 bytes. Way to expensive..