A number of
computers form the ancestry of the personal-scale computing
tradition. Here are my recollections of the ones I worked on:A number of
computers form the ancestry of the personal-scale computing
tradition. Here are my recollections of the ones I worked on:
When I was approaching my fifteenth birthday, my parents asked me what I wanted for a present. I asked for the neatest toy I had ever heard of -- a computer. Not remarkable today, but this was in 1960. The computer I requested (I knew it was hopeless) was an IBM 650.
The IBM 650 occupies a unique place in computer history. In my opinion, it deserves credit as being the earliest ancestor of the personal computer. Most computers that came before it were designed to expand the envelope of computing: bigger, faster, more bell and whistles. Often they were initially designed for large government agencies with insatiable computing needs, such as the AEC or NSA. The IBM 650, on the other hand was designed to be affordable and easy to use. And compared to what else was available in the late 1950's it was:
In hindsight, you would think an affordable, easy to use computer should have sold like hot cakes. Well, it did! IBM sold hundreds of them and it was the first computer to made a profit for its manufacturer. It may have even had the first "after market" programming instruction book, a large format paperback by a fellow named Andre, titled "Programming the IBM 650".
The IBM 650 used a drum memory organized into signed, ten-digit decimal words. The basic '650 had 2000 words of memory. You could add additional drums for up to 10,000 words. [Tom Zaslavsky remembers 6,000 max.] Jonathan Baker tells us there were 200 read/write heads with 50 words per set of 5 heads. A later option added 60 words of core memory where you could store fast loops.
Each word could represent a signed decimal integer or an instruction. There was an optional floating point unit with an eight-digit signed mantissa and a two digit exponent biased by 50.
Each digit was represented in seven bit "bi-quinary" notation: one bit out of 5 represented a value from zero to four; one bit out of two indicated whether or not to add 5 to that value, essentially an electronic abacus. The front panel had rows of lights in groups of five to display register contents. "28019" would be displayed as follows:
* o o * * o * o o * 0 o 5 0 o 5 0 * 5 0 o 5 0 o 5 1 o 6 1 o 6 1 o 6 1 * 6 1 o 6 2 * 7 2 o 7 2 o 7 2 o 7 2 o 7 3 o 8 3 * 8 3 o 8 3 o 8 3 o 8 4 o 9 4 o 9 4 o 9 4 o 9 4 * 9
Actual displays were 10 digits long, with the sign on the right side, just 2 lights in the same space as a full digit. The console layout is per Jonathan Baker's correction to my original posting. His other comments appear below.
An IBM 650 instruction looked like this:
xx yyyy zzzz
where xx was the op code, yyyy was the operand address and zzzz was the address of the next instruction. Thus each instruction contained a jump. This allowed "optimization."
If you program a drum machine with the instructions stored sequentially, you have to wait at least one drum revolution to read the next instruction. By carefully calculating the expected execution time for each instruction, you could place the next instruction at the right angle around the drum so that it would be coming up under a read head when the current instruction was done. Since instructions could execute in as little as little as 0.3 ms (for an add), versus a drum revolution time of about 4.8 ms, careful optimization could increase execution speed by a factor of 5 or more.
To aid 650 programmers, IBM published a memory chart. It had 200 rows and 10 columns. Each cell represented a word of memory. As you wrote your program, you would place each instruction and data word in an optimal location and then mark that memory cell off as used on the chart. Since head to head switching time was fast, any cell on a row would do for instruction placement.
Later, someone came up with an assembler that did optimization. It was called SOAP, Symbolic Optimizing Assembly Program. The SOAP optimization algorithm was very crude and I remember debates on the morality of using assembler vs. properly optimized machine language.
Anthropomorphic computer jokes, where a computer is programmed to output something cute, are commonplace nowadays. The first one I ever saw was an IBM 650 output card on which was punched:
I AM STUPID. I CAN ADD TWO 10 DIGIT NUMBERS IN .3 MS. WHAT DOES THAT MAKE YOU
What really makes the IBM 650 the ancestor of personal computers is that it popularized a concept known as "open shop programming." Prior to the '650 computers, were so expensive that most programmers did not have physical access to them. You handed in a card deck containing your program and data and got it back with your output some time later. Often this took several days. Overnight turnaround times were considered good.
With the '650, you were actually given a block of time to work with the machine. You could run your program, see what went wrong, fix it and try again. This was programmer heaven!
Of course the machine was kept busy 24 hours a day. Your time might be scheduled at 3 a.m. Worse, you were often forced to share your block of time with another programmer. When your program stopped, or went into a loop (you could tell by the way the lights flickered) you were supposed to record the console lights, get off and let your partner use the machine while you looked for the bug. You would have to list your output cards, it there were any, on a IBM 407 accounting machine. The IBM 650 did not have a printer.
One programmer, according to a story that circulated at the time, wrote a special program that made the lights blink meaningfully and punch a card or spin a tape every now and then. He would nonchalantly load it into the '650 whenever his real program crashed, so that he would not be asked to give up the machine.
Eventually he was caught and hauled off to the Computer Center Director's office for a stern reprimand. When asked if he wasn't ashamed of writing such a program that wasted precious computing time he replied: "Hell no, it's optimized!"
Here are some images of the IBM 650 that I found on the 'net:
IBM Mug shot
Load card and detail of console
Innards showing drum
Ed Thelen has placed online "A Third Survey of Domestic Electronic Digital Computing Systems", by Martin H. Weik, published by Ballistic Research Laboratories, Aberdeen Proving Ground, Maryland in March 1961. This historic treasure is full of information on and photos of the IBM650 and dozens of other early computer systems.
From m-jb3281@DRYSDALE.CS.NYU.EDU Wed Mar 8 06:56:14 EST 1995 Article: 97636 of alt.folklore.computers Xref: world alt.folklore.computers:97636 From: m-jb3281@DRYSDALE.CS.NYU.EDU (Jonathan Baker) Newsgroups: alt.folklore.computers Subject: Re: IBM 650 (was Drum Memory) Date: 7 Mar 1995 22:55:59 -0600 Organization: UTexas Mail-to-News Gateway Lines: 55 Sender: nobody@cs.utexas.edu Message-ID: <9503080456.AA02215@DRYSDALE.CS.NYU.EDU> References: <D513DH.2sr@world.std.com> NNTP-Posting-Host: news.cs.utexas.edu A few nits to pick, but a great post. In alt.folklore.computers Arnold G. Reinhold writes: >first "after market" programming instruction book, a large format >paperback by a fellow named Andre, titled "Programming the IBM 650". I know at least 2 such books: the one you mentioned, and a red one from McGraw Hill: "A Primer of Programming for Digital Computers" by Marshall Wrubel. Unfortunately, I found both of these *after* writing my thesis on the 650. >You could add additional drums for up to 10,000 words. Really? I never heard that one could add drums. Core, disk, tape yes, but not additional drums. Do you have some documentation for this? > If I remember right there were 10 read heads per drum with 200 >words per read head. A later option added 50 words of core memory where >you could store fast loops. 200 read/write heads with 50 words per set of 5 heads, but see my other posting for details. I think the core option added 60 words. ... >versus a drum revolution time of about 3.5 ms (as I recall), careful 4.8 ms rotation time, giving avg. latency of 2.4 ms. Of course, as you say, optimum programming could reduce latency almost to 0. Great stuff about the open shop on the 650. I've been saying for years on this newsgroup (not that anyone ever paid attention) that the 650 was the first PC - really a full-power computer that could be operated by one person, who wasn't necessarily an Official Computer Operator. Jonathan Baker Article: 97942 of alt.folklore.computers Xref: world alt.folklore.computers:97942 From: jcmorris@mwunix.mitre.org (Joe Morris) Newsgroups: alt.folklore.computers Subject: Re: IBM 650 (was Drum Memory) Date: 7 Mar 1995 14:14:34 GMT Organization: The MITRE Corporation Lines: 33 Message-ID: <3jhpoa$f72@reuters2.mitre.org> References: <D513DH.2sr@world.std.com> NNTP-Posting-Host: mwunix.mitre.org reinhold@world.std.com (Arnold G Reinhold) writes: >The IBM 650 [...] may have even had >the first "after market" programming instruction book, a large format >paperback by a fellow named Andre, titled "Programming the IBM 650". I don't remember that one; the one I do recall reading at the time was by Elliott Organick. [...] One section in Organick's book covered a subject that many observers feel should be taught (but isn't) in today's world. The title of the chapter was "Machine Room Etiquette." (Perhaps someone should send an updated copy gratis to Cantor & Siegel?) While I don't recall the exact wording he used, Organick ended the book with something along the lines of: Good luck! Happy computing! Joe Morris / MITRE
The LGP-30, made by the Librascope division of General Precision, Inc., was another early computer built on a personal scale. It was quite popular with "half a thousand" units sold, starting in 1956.
Librascope tried to build a usable computer with a minimal amount of hardware. The single address instruction set had only 23 commands. Not only was the main memory on magnetic drum, but so were the CPU registers, each on a dedicated track.
The drum stored 2048 32-bit words. Input and output was by six level paper tape. The number of vacuum tubes was kept to a minimum by using solid-state diode logic wherever possible. The whole machine was the size of a large desk.
To further reduce costs, the traditional rows of lights showing internal registers were absent. Instead, Librascope mounted a small oscilloscope on the front panel. It displayed the output from the register read heads, allowing you to actually see the bits. Horizontal and vertical size controls let you to adjust the display to match a plastic overlay engraved with the bit numbers.
The LGP-30 had an "Algol-like" high level language called ACT-III. Every token had to be delimited by an apostrophe, making it hard to read and even harder to prepare tapes.
The procedure for cold starting the LGP-30 was the most complicated I ever encountered. First, you snapped the bootstrap tape into the console Frieden Flexowriter, pressed a lever on the Flexowriter to read the initial field and pressed a button on the front panel to transfer the data. Then you pressed the lever on the Flexowriter to read the next field and pressed three more buttons on the front panel. This process was repeated, maybe 6-8 times, and one developed a rhythm:
burrrp, clunk, burrrp, clunk, clunk, clunk, burrrp, clunk, burrrp, clunk, clunk, clunk, burrrp, clunk, burrrp, clunk, clunk, clunk, burrrp, clunk, burrrp, clunk, clunk, clunk, burrrp, clunk, burrrp, clunk, clunk, clunk, burrrp, clunk, burrrp, clunk, clunk, clunk.
You then removed the bootstrap tape, snapped in the tape containing the regular loader, carefully arranging it so it wouldn't jam, and pressed a few more buttons to start up the bootstrap program.
Once the regular loader was in, you were ready to read in your program tape. The regular loader read a more compact format tape than the bootstrap loader. Each block began with a starting address so you could back up the tape and continue reading if an error occurred.
Of course if you messed up on any of the above steps, or if your program crashed and damaged the loader program, you had to start all over from the beginning.
Some Net Resources: Computer Museum of America | Ed Thelen | Lawrence A. Crowl
The 1620 was IBM's first transistorized low end scientific machine. Like the IBM 650, it was a decimal machine, but it did not have a fixed word length. Each digit was individually addressable and was six bits wide: four numeric bits, a "field mark" bit and a parity check bit.
Numbers had to have the field mark bit set at the high order digit and were addressed by the low order digit. Instructions were 12 digits long, with a two digit op code and two 5-digit addresses. Both addresses referenced operands in memory. The 1620 had no accumulator register.
The basic 1620 came with 20,000 digits, the same size as IBM 650, but all memory was core storage. I/O was by punch card and a console typewriter, options included paper tape and, later, a disk drive from the 1401 series.
The most remarkable thing about the 1620 was that it did arithmetic digit by digit using table look-up. Addition and multiplication tables had to be stored at fixed positions in low memory. Division was by subroutine, though optional divide instructions could be purchased to speed things up.
Programmers were always trying to think of something else you could do with the tables, but I don't recall anything successful beyond addition in number bases less than 10.
I first heard about the 1620 when IBM gave a presentation on it to the Bronx High School of Science math club. The 1620 was to become Science's first computer. Several faculty members were disappointed that IBM had not simply built a transistorized 650. The change meant they would have to rewrite all their programs.
The Computer Museum History Center in California is restoring it's IBM 1620 computer system to operating condition. Here is a nice photo of a complete IBM 1620 installation at the Technology Museum of Thessaloniki in Greece.
The IBM 1130 was a third generation machine aimed at the low end scientific market. It used 360-era technology and had a 16 bit binary architecture, not very different from minicomputers like the PDP-11 or Nova.
The address space was 15 bits, so you could only get 32K words of core memory. Indirect addressing used up the other bit. If the high order address bit was set, the address was treated as a pointer to another address. Amazing loops were possible.
We mostly programmed in Fortran. The 1130 Fortran compiler could run on a machine with only 4 K of core. That's 8 K bytes, the minimum file size on my Mac.
The basic 1130 came with a 2315-type disk drive. These read pizza-box-sized single platter cartridges that held 500 K words. Disk memory was used to store the operating system, object code, and data, but not source code. The last was kept on punch cards.
The disk operating system, was called DM-2 (for Disk Monitor). Supposedly the DM-2 disk routine did a checksum on itself before writing to disk, dramatically improving reliability over the earlier DM-1.
The 1130 used a nice 1442 card reader/punch from the IBM System/360. Since it had a column serial punch, you could safely make a card with all the holes punched, something most card punches weren't capable of. We called such cards "IBM Doilies." I still have a few.
Another option IBM offered was a Calcomp 565 drum plotter, shocking in an era when IBM generally fought 3rd party attachments tooth and nail. The plotter was very useful for engineering work and we even built a digitizer by hooking up a home-made joy stick to the 1130's sense switches and using it to control the plotter.
The console typewriter used an IBM Selectric mechanism, which meant you could change the type by replacing a hollow, golf-ball sized type element. There was a special type element available for APL, a cryptic, but powerful array-oriented programming language.
For a printer, the 1130 used a stripped down 407 printing mechanism. The 407 was IBM's top-of-the-line punch card accounting machine from the 1950's. They must have had lots of them laying around. The 1130 had 120 power transistors, each wired to the hammer solenoid at a 407 print position. As the print drum spun, the 1130 received an interrupt for each character position. The print driver had to output a 120 bit vector designating which transistors were to fire for that cycle. This put a big burden on the software, but resulted in an inexpensive (for the time) printer.
Sometimes a printer output line driver would fail, resulting in a blank print position. If you knew your way around inside the 1130, it was possible to swap driver circuit cards so as to move the bad print position to near the end of the printed line. This kept the 1130 usable until the repairman showed up.
The standard 1130 had a 3.6 us memory cycle time. To further tap the low end of the market, IBM introduced the 1130 Model 4, with a 5.6 us cycle time, at a lower price of course. The model 4's printer was derated as well, but the slower CPU must not have been able keep up with it. Careful readers of the 1130 hardware manual discovered that when the printer interrupt level (4) was on, the 1130 Model 4 ran at the faster 3.6 us cycle time. Some users of the Model 4 would write a phony printer driver that turned on level 4 and left it on. They would call this driver when running a compute intensive job and write their output to disk, the printer being unusable, of course. When done, they'd run a normal program to print their output.
I remember when we decided to upgrade the 1130 at Arcon Corp., where I worked, from 8 K to 16 K. In those days, IBM sent out a field service engineer to make sure everything was in order prior to installation. After looking our small computer room over, he announced that we would have to put in a new 220 volt circuit before work could proceed. Why, I asked, did we need a new circuit? With a straight face he told me: "Because it's a more powerful computer."
Years later I worked for Miguel Suarez at Computervision who used to be an IBM program manager at Boca Raton, Florida. He was in charge of an 1130 follow-on project called "Bimini." They had developed a multi-tasking operating system and put together a big demo for upper management, with disks, tape drives, printers and what not busily going through their paces all at the same time.
The IBM execs came and saw all this as a threat to their 1400 series business systems sales and shut the project down. IMHO, they could have kept DEC at bay with this product.
In the early 1970's, my employer hired one of the first emigrants allowed to leave the Soviet Union. An experienced programmer, he adapted quickly to our modest IBM 1130 installation and was doing fine.
One morning my colleagues arrived to find him in the computer room. A box of blank IBM cards and a long sheet of paper was in front of him, and he had a micrometer in his hand. He was intently measuring the thickness of each card and writing down the answer. Judging from the number of cards scattered about, he had been at this for some time.
My colleagues watched in horror. He was oblivious to their presence and they, in turn, feared that the stress of immigration had sent him off the deep end. Finally, one of them spoke up:
"Boris, what are you doing?"
"They are all the same," Boris muttered.
"What are all the same?"
"The cards! They are all the same thickness."
"Of course they're all the same thickness. Otherwise they'd jam in the card reader."
"In Soviet Union, they are not all the same. We get jams all the time."
He went on to tell us that he had found wood chips the size of a finger nail in Russian punch card stock. Needless to say, there was nothing wrong with him.
You can see a picture of a Russian punch card at http://www.qedata.se/e_js_n-halkort.htm
Please send comments, typos and broken link reports to the email address at my home page.
Back to Arnold
Reinhold's Home
page.
