by Brian Dear
The ILLIAC had only about five thousand bytes of computer memory, not enough even to store the text of this chapter of this book. To a CSL engineer, it was just another constraint. Engineers tend to relish constraints. With the ILLIAC the PLATO team had much to relish.
Over the summer of 1960, they built a crude prototype, based on a diagram they’d sketched that would wind up printed in one of CSL’s Quarterly Progress Reports a few months later. This would mark the first time the PLATO acronym was mentioned in print as well.
The PLATO I diagram, September 1960 Credit 9
The diagram, labeled the “Equipment Diagram for PLATO,” contains the core design DNA of the PLATO system that would set the course for the next four decades. The diagram is as simple as can be—practically primitive. It’s as if Bitzer and Braunfeld said, “Let’s see, we’ll need this and that and this and that and this and that,” drew a quick sketch on the back of an envelope to reflect all those things, then later had an artist tidy it up and make a more presentable illustration for the CSL report. And yet, despite its utter simplicity, the diagram speaks volumes. It suggested what the system could do. It suggested what it could not do. It reflected the thinking of its creators, not only in terms of electrical engineering, but in terms of education.
There are three general components to this diagram, and while they’re not spelled out, they can be summarized as Input and Process and Output. What gets put in, either by a human or by some device—either way, it has to get converted into electronic signals—gets sent to the computer to be evaluated and acted upon. Depending on how the computer’s evaluation of the input goes, there may or may not be anything to put out, those electronic signals sent onward to those parts of the system that blink lights, print something out, display something on the screen, or play some media.
The diagram shows five boxes, labeled “Keyset,” for student input; “Computer,” for processing; and not one but three components driving output: “Storage Device,” “Slide Selector,” and “TV Display.” But there’s a sixth part of the diagram, the most important part: the student. Fitting with the era in which the diagram was created, the well-groomed student has his shirt tucked in and is wearing a tie. In a few years he’d more likely have long hair and a big peace symbol dangling from his neck, but nevertheless, there he is, the student, drawn into the diagram as if to emphasize the importance of the human being to this system—as if to remind everyone building the system to remember what this project is all about.
Arrows run between each of the five boxes, indicating how information flows. If you step back and view the entire diagram as a whole, there are two clear ways to interpret it in terms of the model it is representing. You can see the diagram representing a student-centric model, where everything starts with the student and ends with the student. Or you could view it as a computer-centric model, where everything starts and ends with the machine, and the student is just along for the ride.
Viewing the diagram in the student-centric way, we see the student reading material on the screen and then responding to what he sees by reaching out to touch a key on the keyboard—which Bitzer and company called the “keyset.” The information loop starts with the student and ends back at the student. The student is in fact the bridge between the keyboard and the “TV display.” Two lines are missing but are implied: information from the TV display reaches the student’s eyes, where they’re processed in the student’s brain, and signals are then sent to the student’s arm and finger and through a typed character on the keyboard, the input traveling to the computer triggering another round of the loop.
This wasn’t some Air Force corporal sitting at a console watching little blips on a radar display, identifying which were friendly jets and which were foes. This was going to be a student sitting at a terminal. Someone who, you could be sure, had never used a computer before or even seen one. The computer was the teacher, and needed to exhibit some characteristics that all good teachers exhibit: patience, leadership, and subject matter proficiency. The teacher had to know his or her stuff. In 1960 the computer was not going to “know” its stuff. It was, however, the “miracle of mechanical ingenuity” that had escaped Edward Thorndike in 1912: a machine capable of arranging instruction in such a way that “only to him who had done what was directed on page one would page two become visible, and so on.” But it did something neither Thorndike’s vision nor even Skinner’s gadgeteering could pull off: answer judging. The ability of the computer to not only evaluate the input of the student, but also figure out its meaning, and not only determine if it was correct or not, but also figure out if it was partially correct or partially incorrect, and provide the most meaningful feedback to the student no matter what had been input.
It’s notable that Bitzer positioned the “Computer” box in the diagram as far away as possible from “Student” and “Keyset.” The student and the student’s keyset and screen could be physically distant from the computer, hopefully as far away as possible: this would remain one of the core characteristics of the PLATO system, and time-shared computers in general, in all of its manifestations for decades to come. It didn’t matter if the user was sitting in the same room as the computer or sitting twelve thousand miles away: a loop is a loop, and this is the way PLATO worked. In 1960, it was the only way it was going to work: computers were too expensive and too large for each student to have his or her own. Time-sharing was the answer, with terminals connected remotely all feeding into the same shared machine. Time-sharing would be the beginning of what we refer to today as “the cloud.”
—
The growing body of late-1950s academic research and commercial projects inspired by the behaviorist work of Pressey, Skinner, and Crowder had raised awareness of the advantages of teaching machines and programmed instruction, among those being Self-Pacing and Immediate Feedback. Self-Pacing was a given, just as it had been with the earlier pre-computer boxes. The PLATO team took particular interest in the Immediate Feedback concept, imbuing the system with a need for responsiveness right down deep into the very core of the hardware. Another influence no doubt was the team having experienced, in prior CSL projects like Cornfield, the advantages of fast and responsive signals in the military radar and air traffic control systems: when in combat, it helps to know right away whether that blip on the screen is friend or foe.
In order for there to be Immediate Feedback, PLATO in its role as teacher was going to need to maintain an illusion of being very responsive to the student. Real teachers expect to encounter inattentive students all the time, but a student encountering an inattentive teacher is a surefire way of losing that student’s focus. PLATO was going to need to be so fast that it appeared to work at the speed of thought—certainly at the speed of typing. As soon as the student pressed a key on the keyset, the system needed to recognize that a key had been pressed and quickly echo a representation of that key onto the display to be seen by the student. There was a kind of Skinnerian cause-and-effect satisfaction to achieving this simple feat: so subtle the student might not even notice what’s going on. Tap on the bar and the pigeon gets a pellet of food. Tap on a key and the student gets something new appearing on the screen, providing Skinner’s much designed “immediate knowledge of results.” So far so good.
This was what we might call the “Fast Round Trip,” the loop that consisted of the input followed by the processing followed by the output. The PLATO team decided that a Fast Round Trip would happen so very fast that the student sitting at the terminal would not even think about the magic that happened when he or she typed a letter and then immediately saw it on the screen. It just worked.
But behind the scenes, electrons embarked on a journey down tiny wire paths, every time a student tapped a key on the keyset. The journey began the moment the key was pressed, triggering an electrical connection inside the keyset, which launched an electronic signal out of the wire coming out of the back of the keyset, and then down through whatever length of wire might separat
e the keyset from the computer, be it ten feet or, in theory, ten miles or ten thousand miles, the bits of information that announced that “the user just pressed the ‘3’ key on the keyset” would fly down that wire and in just a few hundredths of a second would reach the computer, traveling across more wires and through layers of circuitry and logic and relays and vacuum tubes until the information was absorbed and considered by the deepest reptilian layers of the computer’s brain and recognized for what it was, “ah, a keypress,” and then passed through whatever machine-code logic had been written to decide what to do with this signal that way out there somewhere in the realm of humans the “3” key had been pressed, and then either do something with the “3” or just send a signal out to display a “3” on the screen—so the human would see visual confirmation of the pressing of the “3.” And all of that had to be very fast: from start to finish in under a quarter of a second. Any slower and the person sitting at the terminal would start to notice an annoying time lag between typing on the keyset and seeing the typed characters appear on the screen. Much of computing even today is about maintaining this elaborate illusion, just to keep the human’s attention on-task and not on the computer itself.
One aspect of PLATO that one cannot glean from a glance at the diagram is the fact that the connecting lines drawn between the various components do not reflect how much information is passing through the lines at any given point. In fact there’s an asymmetry to the information being sent out to the students’ display versus what’s being sent to the machine. If the diagram had been drawn to reflect the asymmetry, the lines coming out of the “Storage Device” and “Slide Selector” boxes heading toward the “TV Display” would be massively thick compared to the hairline connecting the “Keyset” to the “Computer.” The “pipes” leading out to the student were big, while the pipes leading from the student to the system were little. It’s the difference between a fire hose and a straw. There were all sorts of reasons why this was a practical approach. The speed of the little pipe was “good enough” for the Fast Round Trip and to enable working at the speed of thought. PLATO was like a building where the computer’s processor was on the top floor, the students worked on the ground floor, and data going down was able to hop on an express elevator, but data going up required taking the stairs. To this day, what most Internet service providers provide is an asymmetric Internet service to the home: they give you a big pipe down (so you can watch streaming videos, listen to streaming music, download big files, etc.) and a smaller pipe up. Of course, today, that pipe up is still pretty big. At the start of PLATO, that pipe only allowed a tiny trickle of data back to the computer, and that decision would have serious repercussions in years to come.
—
The box labeled “TV Display” in the diagram was obvious enough, but what about the “Slide Selector” and “Storage Device”? The label didn’t say “Slide Projector,” it said “Slide Selector.” What the PLATO team decided to do was use photographic slides to show pictures, diagrams, and other complex illustrations that would simply be too difficult or require too much memory or power to be generated by the computer itself. The other thing about slides: people—especially instructors, educators, and people in the audiovisual trade—knew how to design and produce slides for presentations, lectures, and classes. They wouldn’t have to learn machine programming language to create the displays, even if they could, which they couldn’t due to the limitations of the ILLIAC. What the ILLIAC could control was a digitally addressable slide selector, which fed its output to the “Storage Device,” which Bitzer and company decided would take the form of a Raytheon QK-685 storage tube from which a video signal could be generated and sent to the “TV Display.” The storage tube, which was a type of cathode ray tube that could store a computer-generated display image, was the key to making this work. CSL just so happened to have some Raytheon storage tubes lying around. They had been used in the Cornfield radar projects, so a computer could “draw” the radar images of approaching and departing aircraft and assist the operator to identify “friend” and “foe” in the sky. The drawn “image” was then read from the storage tube and displayed on a video screen. Couldn’t the same principle be used to, for instance, draw a triangle, label the sides A, B, and C, provide the lengths of A and B, and ask the student to solve for C? A TV display could show the image that had been “written” into the electrostatic memory of the storage tube.
The storage tube had four operating modes: write, read, erase, and selective erase. Under computer control, the tube could be told which mode to switch into. Bitzer and team described it at the time this way, reinforcing their notion that the storage tube was an “electronic blackboard”:
When the tube is in the write position, letters and diagrams can be written on the storage surface point by point. In the read position the information on the storage surface is read out onto a display for presentation to the student. When the tube is switched to the erase mode, the entire surface is erased, while in the selective erase mode any individual point on the surface can be erased.
Raytheon storage tubes were expensive and didn’t last very long, burning out after about one thousand hours of use. They also had the annoying habit of “forgetting” the contents of their memory after a while. A student sitting in front of the TV display being fed from a storage tube would see this “forgetting” as a gradual fade-out on the screen. Soon the entire picture would fade away, like an increasingly overexposed photograph. For this reason, for as long as the PLATO system made use of storage tubes—and it would, for a long time to come, the first dozen years—the keysets had a special “REFRESH” button on them, which when pressed told the computer to redraw the image into the storage tube’s memory, which would in an instant then appear as a fresh, crisp picture on the screen. Until it started to fade again after a few minutes…
For slides, the team originally considered having the ILLIAC control a device that would feed from a set of everyday 35mm slide magazines and automatically select any random slide for presentation to the student. In PLATO’s earliest incarnation, as the student reached a certain point in a lesson that required a slide to be selected, a technician in another room picked out the appropriate slide and scanned it with a camera, merging the image into the video from the storage tube. (“He got pretty fast at it,” says Bitzer.) But these manual approaches didn’t last long. Nor did the idea of some sort of ILLIAC-controlled 35mm slide carousel or slide magazine reader. Such devices would be too slow and unreliable: too many moving parts, too many things could break down. They needed something heavy-duty, and, always, something fast.
That something didn’t exist. So they designed something that they could build. It was a machine that would hold three thin, disk-shaped platters, each about a foot wide, and upon each, slides would be printed as annular bands. Next to each slide a special binary code would be printed, so the computer could tell the machine exactly what slide to select, and the machine could read the codes at lightning speed and jump right to the correct slide. They envisioned fitting 224 slides on each disk, which should be plenty for any individual lesson.
The nearly nonexistent budget for PLATO in its first few months meant that Bitzer, Braunfeld, and Lichtenberger needed to be as creative in finding resources as they were in designing the system. For some parts, that meant the occasional “borrowing” of something lying around the lab or home. For the “TV Display,” Bitzer found someone selling a used TV for a few dollars. The TV’s channel tuner was broken. Not a problem for an intrepid electrical engineer like Bitzer. They didn’t need the tuner working; they’d rig the TV to “tune” directly into the closed-circuit video signal coming over the wire from the storage tube.
The crude “Keyset” in the diagram was an apt choice of term, for this little box was far from being a keyboard. It contained sixteen keys for inputting answers to questions, as well as some additional keys such as “Continue” for moving ahead and “Reverse” for moving back through the
“slides” presented in the lesson. The lack of a full keyboard limited the range of possible student answers, as well as the range of possible teacher questions. That would be solved in time, but PLATO I was a prototype, a proof-of-concept.
PLATO I terminal Credit 10
Among other function keys were HELP and AHA, both notable and worth a moment of consideration, as they represent, like the diagram itself, an insight into PLATO’s original DNA. If while taking a lesson you got stuck or confused trying to answer a question, you could always press HELP to see one or more pages of material providing more detail on the concept you were stuck on. Once you were ready to go back to the problem, you would press AHA to indicate to PLATO that you now understood and wanted to go back to where you were in the lesson before you pressed HELP. The AHA key would fall out of use in a few years as PLATO evolved, but it became an unspoken rule that the HELP key should always provide you with contextual help, whether you were a student in a lesson or an author doing something else on the system. This tradition would become so ingrained in the PLATO community that even games, as we’ll see in Part Two of this book, had extensive HELP sequences. If you wrote a program on PLATO, it was assumed that you would spend as much time as necessary to write a thorough collection of context-sensitive help pages to go along with the program. On PLATO, when you pressed the HELP button anywhere, no matter what you were doing, the help page that appeared was always about the very thing you were doing at that moment. (Reliable, fast, context-sensitive help would become the norm on PLATO over the coming decades—something that the personal computing, smartphone, and Web industry has never embraced as vigorously.)
