Old Computers

LCM+L PDP-7 booting and running UNIX Version 0

When I was studying Computer Science at The University of Texas in Austin, I had one class where we were allowed to use a PDP computer that was normally reserved for graduate students. The professor who was in charge of it gave a group of us a 30 second instruction on how to boot the machine: flip this switch, flip that switch, and then push the go button. Great, that explains nothing. WTF are all these switches and why does this sequence work? It was rote memorization and my mind balked. I caught him later on and asked him to repeat these instructions and he gave me shit for not paying attention the first time. Effing jerk.

I don't recall what I did with the machine, it was probably just an exercise to familiarize us with working with actual hardware. Everything else we did was done at an arm lengths remove from the giant fricking CDC machine via punch cards and printouts. There was one graduate student there who was mucking about with something and he discovered an undocumented opcode. He played with it for a bit and finally concluded that it was 'jump random and destroy' which doesn't sound particularly useful.

TI-990 Front Panel

My first job out of school was working with a Texas Instruments DX-10 mini computer (TI-900 was the computer, DX-10 was the operating system). It had a bank of front panel switches much like the ones in the video above. We actually used them a couple of times, but it was such a slow tedious process that almost any amount of software contortions were preferable.

IBM Channel Cable

We needed to hook it up to an IBM tape drive (I think it was an IBM, it used those frigging giant IBM channel cables). It wasn't too difficult, just a matter of figuring out which plugs to use and setting some jumpers, but I seemed to be the only one in the shop that could figure it out. I remember thinking the connector was pretty weird because the cable itself was this thick, armored thing about an inch in diameter, but at the end the sheathing had been stripped away and the connector was just hanging on a bunch of loose wires. Alien tech, but it worked.

Via Stu

Searching & Sorting

Space Needle or Cloud City?

I recently realized that were some things you could do with the C library sort (qsort) & search (bsearch) functions that can make them more useful. bsearch will run a binary search on a sorted array and return a pointer to the matching element, if there is one. If it doesn't find a match, all it tells you is that it didn't find it.

But what if you want to find an element with a value close to the one you want? The trick I just figured out is you simply add the element you want to use as a target in your search, run qsort on the array to sort it, and then search for that element. That will put you in the ballpark. Now all you need to do is check adjacent elements to see if they meet your criteria.

To delete this fictitious element, simple change it's value to the maximum possible for this item and then run qsort again. It will now be at the top of the list. All it takes to effectively delete it is to reduce the array's element count by one.

All this extra sorting will use some processor power, and if you were having to sort a gigabyte of data more than once a second, it might have an effect on your system's overall performance.

But if this is for any kind of desktop application, the ease of coding it makes it a worthwhile shortcut.

The last time I went down this road I wrote my own search function that would return the element with the closest value to my requested target. I also wrote my own insert and delete routines. I did this because when I went to school everything about computer programming was about saving CPU cycles. Beginning programmers got seven seconds of execution time on the mainframe. I screwed up once in a junior level class and burned my entire semester's allotment before the OS kicked me off. That rated some words from my professor.

I wonder why it took me so long to figure this out. I'm thinking it might because most of the programming work I did involved making things work, and there was no end to it. Well, I guess it did come to an end which is why I am unemployed. Computer companies eventually got their acts together and started building machines that worked when you turned them on, and software companies started producing software that people could use to do something useful. Took a while but they eventually got it sorted.

So I never got to work on anything that might have been more interesting than the nuts and bolts of getting the hardware to behave. Not that it wasn't interesting, but it was interesting in a picayune kind of way, not a cosmic, universe expanding kind of way.

Modern desktop computers are roughly ten thousand times faster than the old CDC 6600.

Pyramids of my Mind

When I got started messing with computers as a student at UT Austin in 1978, mainframes still ruled the earth. I remember we got seven seconds to run our programs before the system would boot us off. Seven seconds back in those days was just enough time for one of those dinosaurs to take a small bite of a problem, chew it once or twice and swallow it. If you failed to adhere to the rituals and protocols laid down by the high priests, your program would run out of time and off you would go with no more ceremony than a bum getting tossed out of the Hyatt.
    Today, of course, seven seconds on any modern computer is an a veritable eternity. It it time enough to accomplish most anything. If your computer appears to be slow, it's because your computer now has a zillion things to do, and a zillion divided by seven is still long enough for you to go get a cup of coffee, or at least long enough to give you an excuse to go get a cuppa.
    Earlier this year I noticed that Google's Chrome Browser had gotten slower, which was kind of weird being as Google is all about delivering more faster (can you use more as a noun? Maybe I should say faster more? Or make a new compound word like moraster. Hmm. Maybe not.)
    Then I realized that one of the new tricks for speeding up computers is to explore future possibilities. At the low level this involves following both branches of a jump before you actually get there. Some low level operations take longer than others. While a simple load or store instruction might only take a nanosecond, dividing might take four or five.
     If there is a conditional jump instruction right after the divide, in a computer from the dark ages, the part of the computer that loads the next instruction is going  to be sitting there idle, and we can't have that, the devil and idle hands you know. So the whiz kids came up with the idea of going ahead and loading the next instructions for both branches of the jump instruction. That way when the logic/math part of the CPU finishes mucking about with the divide instruction we'll have the next instruction already loaded, ready for execution.
     When the CPU finally gets to the branch instruction and makes a decision on which way to go, all the stuff that got loaded for the wrong branch is discarded, and the look-ahead instruction pre-fetcher can concentrate on the right branch, at least until it comes to another one, and then it goes through the same contortions again.
    Following two execution paths means you need more circuitry, and since that seems to be the one thing we can have in abundance these days, it's not a problem. At least if you don't count the man-years that have been invested in figuring out the gory little details of implementation. And you can bet they are gory.
    Anyway, back to Google and Chrome. I suspect what Chrome is doing is something similar to the look-ahead instruction prefetcher in the CPU. There are guessing as to what you are going to do next and following that branch and maybe several others, just in case, so they can deliver what you choose more quickly.
    The reason I noticed that Chrome was slower is that I am using a veritable antique computer. I don't really know what's inside. It's an old Dell I picked up a recycler's shop for a pittance, like $100 or so. Just for the record, let's check (Start / Control Panel / System).

It doesn't say anything about quad cores or even dual cores. Hmm. Let's see what a current computer looks like.

I suspect it's a quad-core CPU, though it doesn't actually say that. Quad-core means it has four CPU's in one processor chip. Certainly has more memory.

What brought this all up was the comment from Sarah Sukhoi about Engineers and Designers that I ran across yesterday.

The pharaohs of ancient Egypt built huge pyramids out of stone. They are big and impressive and they lasted for thousands of years, but nobody builds like that anymore. Look at a modern city and you have a zillion buildings of all shapes and sizes growing willy-nilly all over the landscape. Centralized authority and control has all but vanished.

Something similar has happened in the computer business. When computers were a big deal, the standards for software design were strenuous and only the most dedicated survived. Now computers are ubiquitous (the average smart phone is more powerful than the CRAY-1, the awesomest super computer ever), and the standards for software design have relaxed (or plummeted, depending on your point of view), and anyone who can spell QWERTY can get in on the game.

This is why I am no longer at Intel. I was trained in the old school of designing software to do a specific task. I can write code to do anything you want. The problem here is you have to know what you want, and nobody at Intel knew exactly what that was. What they wanted was the next killer ap, a new software program that everyone would want. So we had a bunch of people like Sarah's Designers running around, full of enthusiasm, spouting buzzwords. My problem was I had no enthusiasm for any of the stuff (crap) that everyone was so hyped about. It didn't look serious or useful. Some of it, like video conferencing, did not even look possible.
    During my last few years (it may have only been months, but it sure seemed like years), Pro-Share was the big deal. Andy Grove had come to Oregon and the honchos had demoed some aps for him. Some of them might have been useful, or even successful, but the one that caught his eye was video conferencing, and so a whole division was given the task of trying to force a gigabyte of data down a pipe that would hold, at best, a few hundred K. It was basically hopeless, but they did give it the old college try. Some of the video compression algorithms they developed may even have provided the foundation for our current video-over-the-internet experience.
    Processing video does eat up the CPU cycles, and since that is what Andy was looking for (the killer ap that demands a powerful CPU) it made a certain kind of sense. Too bad they had to wait ten years for broadband internet to catch up. I wonder, if we looked back, who was pushing for broadband internet. Anybody in the computer business wanted more speed, but wiring the entire country for broadband was going to take some capital investment. The cable TV companies already had most of the country wired, but all their equipment was geared to one-way distribution, and if you have a business that is making money are you going to be inclined to sink a bunch of money in new equipment for an unproven market? I think not.
    Which makes me wonder why Verizon even bothered with wiring the country with fiber-optic cable, or as much of it as they did. I have it, and I mostly like it, though Frontier (who took it over here) seems to be slightly pathetic. I went with Verizon and fiber-optic because, 1) I already had a Verizon account and 2) I had heard nothing but bad things about Comcast.
    Anyway, back to the main point, i.e. Sarah's comment about Designers versus Engineers. Good software design requires a certain mental discipline. I am a fairly smart guy (in certain restricted fields. Ask my wife.) and I found the course work required to get a computer science degree very difficult. Everything in there was alien. Oh, there was logic and math, but these guys had combined it in ways that made my head hurt. Still, I must have some affinity for it because I stuck with it. Weird.
   People who are real computer gear-heads are few and far between, and since the demand for programmers is very high, all kinds of other people are getting in the game, and since enthusiasm counts for a whole lot in the employment business, we are getting all kinds of software that is cute and/or fancy but doesn't necessarily work very well.
    If it is useful and/or popular, we can always spend money to go back and try and fix it. If it doesn't make that first cut, then we can forget about it.
    Some people are naturally more social, some are enthusiastic. Good gear-heads are generally neither.

Bonus

Pyramids on my mind - acoustic 12 string - Douglas from the Dirt Road Bluze Band.

Punch Cards

Computation Center (COM) CDC 6600 & 6400 – Photo supplied by Charles H. Warlick

    E. B. Misfit's post prompted me to tell this old-ish story. It has been told many times before, perhaps even by me, but evidently it's worth repeating because every day there are new people showing up who have never heard of, much less seen, a punch card. So I'll tell it again.
    I studied Computer Science at the University of Texas in Austin from 1977 to 1980. This was in the days before the PC. All your programming assignments were run on the mainframe. The mainframe was a giant CDC machine in a glass walled basement room in the administration building. You had to search it out if you wanted to see it. You could do all your programming without ever knowing where it was. Everything ran on the mainframe: student programs as well as University business applications. Well, everything except for a few projects being done on a mini-computer by graduate students. Note that was a mini-computer. There were no micro-computers.

Not the Painter Hall keypunch room, but similar.

Student programs were run in batch mode. In the computer science building there were two rooms: a keypunch room and the I/O room. The keypunch room had maybe eight keypunch machines. They were usually busy, sometimes you had to wait for one to open up. In the I/O room was the card reader and the printer. The I/O room (I don't think that's what we called it, but for the life of me I can't remember just what we did call it) was divided roughly in two by a counter. You took your stack of punched cards to the counter and handed them to the operator, who fed them into the card reader, and when they had been read, handed them back. Then you stepped back and waited for your program to run. Actually, you waited for the results of your "job" to be printed.

Turn the volume way up to get the full effect.
    The printer was always busy, hammering away from dawn to bedtime, spitting out a continuous stream of green bar printer paper. The printer operator would watch for job headers to appear, tear off the preceding stack of paper and file the output in a folder hanging in a rack. The rack was accessible from two sides. The operator put the output files in on one side and the students pulled theirs out from the other side. The folders were arranged alphabetically by user code, so you waited and watched for your printout to be deposited in your folder.
    To run a program first you had to write it. This you printed by hand on paper. When you were satisfied, you took your hand written copy and a stack of blank punch cards to the keypunch room and found yourself a machine. Load your cards into the machine and then type your program in, one line to a card. If you made an error, the card went in the trash. Since programs in those days were about equal parts letters, numbers and punctuation, and errors meant the sacrifice of a card, it was slow going.
    In addition to your program you needed a job card. There may have been more than one, and there may have been an end-of-job card as well. These had a cryptic string of characters that the professor supplied at the beginning of the term. I never even tried to decipher their meaning. Writing my assigned programming tasks was enough of a challenge.
    So now you have your completed stack of punch cards, your "job", and you can hand it over to the operator and wait for it to run. When you get printout back you find out what became of your job. Most of the time it came back with an error of some sort. You forgot to put in a punctuation mark, or you misspelled GOTO. These were syntax errors, which meant your program did not actually run. Once you got all of these nitpicky little errors fixed, then you could move on to what happened when your program ran. Again, most of the time it didn't. The computer failed to understand your logic and tried to do what you told it instead of what you meant, which resulted in a crash or a nonsensical output. This is when it got interesting.
    Now you get to try and puzzle out what happened. Sometimes it was obvious. Once you had gotten to this point (no mean feat), and you actually looked at your program, it became perfectly obvious what you had done wrong. Sometimes you got to repeat this sequence several times:

• run the program
• read the output
• start reading your program
• exclaim "Oh!" when your foolish mistake jumps out at you
• correct the program

    At this point sometimes you got lucky and the program ran as it was supposed to. This happened more in the early days, when your program was a stack of maybe 20 cards. As time went by and I stared taking more advanced classes my programs got longer. Now we start running into logic errors, things that might cause your program to go into an endless loop. This meant your program ran until your allowed time expired, which meant the only feedback you got was a notice that you ran out of time. Put that in your pipe and smoke it. My longest program was about a thousand cards which meant a thousand lines of code. It filled a box the size of a shoebox.

These cards are blank, just waiting for you to engrave the wisdom of the ages. 

I wonder how many boxes I went through. A dozen? Two dozen?

    The operations room in the Computer Science building (Painter Hall, maybe?) closed up in the early evening. If your program was due tomorrow and it still wasn't running, this meant going down to the street to the engineering building. Things were not quite so hospitable there. For one thing it was full of engineering students whose smallest programs were one box of cards. Some of these guys had programs that comprised a stack of boxes. Also, I don't think they were any keypunch machines there, but that doesn't make any sense. How could you get anything done? In any case, I can picture the operations room but I cannot picture any keypunches there.

    I had a couple of job interviews after I graduated with companies (defense contractors) that used punch cards. I was horrified. By this time I had been exposed to video terminals (text only CRT's) and punch cards were obviously going away. Fortunately neither one these companies offered me a job. Actually, one was even worse. You handed your program to the secretary who typed it in using a typewriter. The typewriter was connected to a modem, which was connected to mainframe on the other side of town via a phone line. I think it was an IBM electric typewriter. I think they mailed the results of your job back to you.

Update November 2017 replaced one dead link & deleted another. Fixed problems with picture and video.

CDC 6600

Ever wonder what the state of the art in Computer Science was back in 1964? Me neither, but Jack sent me a link. I glanced at it, but geez, if they aren't exactly dinosaurs, they are more like American cars from the same era, big, expensive and flashy. Then Jay notices that there is a Control Data 6600 in the list, which brings back some memories

We had a CDC 6600 at the University of Texas when I was there (1978-80). It was installed in a room under the patio in back of the (infamous) tower. There was a hallway alongside the room separated by glass. It was slightly elevated so you could walk by and gaze down upon the great and terrible Oz. It was some kind of yellowish color. Burnt ochre? Almond?

When I started my Computer Science classes there our jobs were limited to like 7 seconds to compile and run. When I got to upper division classes the reigns were loosened a bit. I wrote a program to process a small image (like 50 gray scale pixels square) and I didn't really plan it out very well, I just sort of hacked it together. It seemed like a trivial problem. It ran, but it used something like a couple of minutes of time which almost consumed the entire class's allotment for the semester. I got dinged for being inefficient.

Some time later I came across some old CDC controller cabinets for sale. They were pretty cool, about four feet high, they had a pair of cast aluminum doors on the front with a series of dark green glass windows. I would still like to get my hands on one. They were right out of a science fiction movie.

Another thing that was cool was that the operators console had a little bar in the bottom left corner of the screen for status messages. It would had some kind of swirly/barber pole thing going on. This was in the days when all you normally got on the screen was text.

Update January 2017 replaced missing picture.
Update November 2017 replaced dead link

Goto

Goto? What's that? Spanish for duck? Greek for tarantula? How would you pronouce it? Got-oh, like in "Got Milk"?

No, no, no. Goto is why programmers can't spell. Goto is short for "go to". Wow, you save a whole space. It's an instruction used in computer programs to arbitrarily change the point of execution. Back in the good old days, when Fortran was the king of beasts, goto's were the only way to change course in a computer program.

IBM Keypunch Machine

Back in the good old days, computer programs were written on punched cards. You sat at a keypunch machine and typed in one line of your program at a time. As you typed, the keypunch machine typed the letter on the top line of the card and punched a series of holes representing the machine code for that letter in a column beneath the letter. If you made a mistake, the card went in the trash, and you started over with a fresh card.

Most of my early programs were pretty small, on the order of a hundred cards or so. You take your deck of punched cards and hand them in to the opertor who loads them in the card reader, one program/job after another. There were always a dozen or two people in there. The computer reads the cards, compiles the program, runs the program, and then queues the output to the printer. The operator seperates the output from the printer into seperate jobs and turns them over to the waiting geeks/students.

You looked at the output to see, first of all, if your program compiled correctly. If it didn't, it was back to the keypunch machine to correct your typing errors. If it did compile correctly, you looked at the output to see if the program performed as expected. Simple programs were easy to debug. More complex programs, well, then you got to strain your brain.


If you were only dealing with a hundred cards or so, things were not too tough. But some people, especially in engineering were running massive programs that might be one or two thousand lines/cards long. These required boxes to carry around, and don't dare drop them. You might never be able to put Humpty together again.

There was one story floating around that this happened to one poor guy, and to ensure that it never caused him a problem again, he added a goto to every line of his program. The version of Fortran we were using was an advanced (!) version: it allowed two statements on each line. What our hero did is he gave each line of his program a label (Fortran uses numbers in the first few columns), and tacked on a second statement to end of each program line. The second statement was simply a GOTO directing the program to the next line.

Take the box of cards, drop it on the ground. Gather up the cards in any random order, just make sure the first card is first, and turn them in. The program will compile and run. A horrible idea, but effective for dealing with a box of a thousand cards.

Update December 2016 replaced missing picture.