Slashdot Mirror
The 305 RAMAC — First Commercial Hard Drive
Captain DaFt writes "Snopes.com has an article that gives an interesting look back at the first commercial hard drive, the IBM 350. Twice as big as a refrigerator and weighing in at a ton, it packed a whopping 4.4MB! Compare that to the 1-4GB sticks that most of us have on our keychains today."
pen drive: will fit in my pocket
RAMAC: will maybe fit in my kitchen
pen drive: holds quite a bit of data
RAMAC: can't hold that much data
pen drive: cannot be used as cover in a gun fight
RAMAC: essentially is a battlement worthy of any castle
AND THE WINNER IS....... RAMAC! I know I want a storage device that protect me from sundry projectiles.
I got a catholic block.
I'm sick of storing all my porn on punchcards.
I'm sure "SlashdotMedia" will improve on all the wonders that Dice Holdings blessed us all with
Truly Moore's Law is an amazing thing.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
...even the simplest computer took up six city blocks, and was over ten storeys tall if you included the intercooler arrays.
My sixteen brothers and sisters had to walk forty-six kilometers through the blistering snow to even reach the keyboard, and then even when you did each key required over nine pounds per inch of pressure to depress them. And, since this was before Dvorak composed his famous New World symphony, the keys were always arranged in a completely random order.
Next we would chop wood and heft it into the boiler to keep the computer going, pausing only to replace vaccuum tubes or to put in a few hours at a Dickensian sweat-shop in order to afford that previous penny to buy us a sasperilly to share between us.
We all had tuberculosis, of course, which was the style at the time.
But did we complain? No, we didn't. We performed floating point calculations by tying little knots in the tatters from our pants, and rendered sums for the differential equations the war effort needed to bomb out the Nazis. How much RAM did we have, you ask? We had 1 bit. Today my grandson complains when his WoW refresh rates are too low, but back then we made out just fine with 1 bit of RAM and a box of Cracker Jacks.
Monochrome? We could only dream. Our display was semichrome. And our printer? His name was Guttenberg.
Man, those were the days.
These stories are free but worth money.
Actually, the metric equivalent to a 'shitload' is the metric 'assload.' As in, 'That's an assload of storage!'
It's much easier to talk in terms of milliassloads, centiassloads, assloads, kiloassloads and mega-assloads than in shitloads; who can ever remember that one shitload=4 'whole piles of' = 7.46 'whole lotta's = 14.5 (14 even in certain states) 'whole buncha's = 31 'fair chunk of' which, finally, contains 252 'bitta's.
After all, isn't it easier to say 'there's 40 centiassloads of storage on that mem card' than 'there's a whole lotta and a bitta space on that mem card'?
Vintage computer games and RPG books available. Email me if you're interested.
Not to date myself, but boy that brings back memories. I started in this business in the mid 1960s a decade after this IBM disk. We used magnetic drums and head-per-track disks for storage. That makes the IBM unit with moving heads truly advanced for 1956. But what a dog it was at 600 ms seek time! Thats milliseconds guys, not microseconds. Six tenths of a second just to move the head.
The drum memories I used had one head per track, as did the head-per-track disks. In that case, seek time is zero (for head movement.) One need only wait for the latency time for the bytes you want to rotate under the head. Depending on rotation speed, latency could be as much as 5 to 15 milliseconds.
The amusing part, when I think back on it, was the way that the hardware design influenced the programming. Suppose you had a clause that looked like: IF X THEN A ELSE B ENDIF. To make your program run as fast as possible, you would arrange it so that the instructions for A and for B would reside on two different tracks at the same azimuthal angle, (right behind the instructions to evaluate IF X.) That way, no matter whether the branch evaluated true or false, one didn't have to wait for additional memory latency to read the next instruction.
We also didn't have room in RAM (core memory or registers at that time) to store data or calculated results. We had as few as 24 bytes of RAM. Thus, each data value also had to be assigned an address on the drum or disk. The location of that address relative to the code which accessed the value had a dramatic impact on program speed.
Therefore, to optimize programs for running speed, we spent more time devising optimum ways to store the code and data fragments on the drum or disk, than we did designing the functionality of the code. What language and OS did we use? No language, just program the instructions one bit at a time. No OS.
So what fancy apps did we do with this spaghetti software? We did real time control of power plants, both conventional and nuclear. We made flight simulators. We supported the Apollo project to send a man to the moon.
Despite the fact that the computers of those days were as much as 10,000 to 100,000 times slower than today's hardware, the real time applications were only 10 to 100 times slower and/or of lesser scope compared to today's apps. It was because of the extreme squeeze-blood-out-of-a-stone coding methods we used in those days.
For a really good story, get someone to write about how they streamed instructions sequences from earth to the Lunar Excursion Module for Apollo 11. Not streaming video, not music but streaming the code to execute. Buy the time one machine instruction would finish, the next one would be received and read to go. It was just-in-time delivery of the next instruction. That way, they needed no onboard mass storage of any kind. In my book, that was programming heroics that any slashdotter should appreciate.