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."

1 of 244 comments (clear)

  1. Programming heroics. by anorlunda · · Score: 5, Interesting

    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.