PLATO welcome screen
(click any photo for a larger version)
On June 2nd and 3rd, 2010 I attended a conference at the Computer History Museum called “PLATO@50: Fifty Years of Innovation”. The first computer I ever saw in person or used was the PLATO installation at the University of Delaware. My sister was taking a course in biomechanics at the University and brought me into the terminal room where I could login to PLATO and use a variety of educational courseware without needing a special account or paying any fees. The rest, as they say, is history. I spent quite a number of hours exploring all the educational courseware on PLATO. I was in this weird age range where the “kids” courseware was too simple and the University student courseware was too complex. However, I was immensely fascinated with this thing called a computer.
The University had several PLATO terminal rooms around the campus. One of them was located in Smith Hall, the location of the Computer Science department. Adjacent to the PLATO terminal room was the general time sharing terminal room, containing a large number of LA-36 DECwriter printing terminals, a couple HP2648A CRT graphics terminals and a couple Tektronix 4010 storage tube graphics terminals including an attached printer. These terminals were connected to a multiplexing device called the port selector that allowed you to connect the terminal to one of several minicomputers and mainframe computers located in the Computer Center complex across town. There was an HP2000 minicomputer, a couple DEC PDP-11 minicomputers, a Burroughs B7700 and a DECsystem-10. You would select the desired system by presing the RETURN key, a number designating the desired system, and another RETURN.
Like the PLATO system, these systems generally had free logins you could use to explore the system. Unlike the PLATO system, you could easily write your own software and execute it on the system. The HP2000 came with a large library of BASIC programs that would remain resident in your workspace after execution. You could see the source code by simply typing LIST after running the program. For me, understanding the source code of a program was a much more challenging and interesting lesson than anything that PLATO had for me and so I drifted away from using the PLATO system and concentrated on the HP2000. In their software library there was a series of programs called TUT01 through TUT25 that would teach you programming in BASIC, exploiting the fact that running the lesson loaded it into your workspace. I proceeded to teach myself BASIC programming on the HP2000 and began a 30 year (and counting) career in software engineering.
In 1978, it was freakishly weird for a 13 year old to be engrossed in computers and programming. Now, we’d consider it freakish (or perhaps sad) if a 13 year old had no familiarity with computers. Within a few months, I had shifted from the HP2000 environment to using RSTS/E on a PDP-11/70 run by Project DELTA. DELTA rented LA-36 serial terminals to the high schools in Delaware, who could use them for whatever purpose they desired. Some high schools used them to teach programming classes. When I got to high school—I started programming the summer before I entered the 8th grade at Central Middle School—I found out that Newark High School used the DELTA terminal primarily to run a program called SIGI. SIGI was essentially a relational database that allowed you to select prospective colleges based on a set of desired criteria: size of the student body, location of the school, degree programs offered, etc. It’s still around today in a 3rd generation incarnation called SIGI3.
What I found at DELTA was an amazing experience. Kids were given the freedom to explore and write programs that they found interesting. You could even get paid for it! I remember getting my first paycheck from DELTA for working on some software for their library. (It’s also the very moment I became a libertarian as I looked at all the deductions from my pay and realized I would never see that portion of the money I earned.) We were given quite a bit of trust, considering that we were just teenagers with a passion for programming.
At first I earned my own login on the PDP-11/70. After earning some more trust, I was given a security pass that would allow me off hours access to the building and room containing DELTA’s terminals. I’d come to the building and get out the campus security callbox phone and call the security guards over to the building to let me into the building and into DELTA’s terminal room. I don’t think the security guards ever understood why these teenage kids had security passes and were always wanting into the building at all hours of the night and on weekends. Sometimes they even questioned the legitimacy of our passes, but when they called for confirmation, our access was always granted. Eventually I would get my own key to the building and terminal room so that security wasn’t necessary anymore.
At the PLATO@50 Conference, I learned that I was not alone in cherishing this special fondness for getting an unusual chance to play with computers at a very early age. In fact, I learned that by PLATO standards I was a latecomer to the game.
PLATO Overview
Brian Dear
Brian Dear opened up the conference with a nice overview of the PLATO system. Brian is writing a book on the history of PLATO, due to be published in 2010, called “The Friendly Orange Glow”. Brian is the founder of the PLATO History Foundation, a group dedicated to preserving the history of the PLATO system and the people who made and used it.
Even though the title of the conference was “PLATO@50”, I was still surprised to learn that the original PLATO proposal was indeed made in 1960. PLATO was an acronym for Programmed Logic for Automated Teaching Operations. It was conceived by Don Bitzer as a system on June 3rd, 1960 with the following block diagram:
While such an arrangement of equipment might seem fairly straightforward today (with the possible exception of the slide projector), almost none of the hardware existed in 1960. The display alone was very problematic; storage tube displays were expensive and didn’t have the interactivity that was needed for an interactive system designed for teaching. Today’s raster graphic based displays would be enourmously expensive for the display buffer memory alone in an era when memory cost $2 per bit. The solution was to invent and commercialize the gas plasma display panel, the same basic technology that is at the core of every plasma display in use today.
Another design goal that was felt to be paramount was the responsiveness of the system. In order for a student to be properly engaged in a lesson, the computer’s response had to feel instantaneous. In technical terms, this meant that the system’s response had to appear in under 100 ms. Those who work in the real-time gaming industry appreciate the difficulty of maintaining 60 Hz refresh in today’s resource rich environment. Consider the difficulty of achieving that response time in the resource poor environment of 1960, when batch processing was the norm. You’d take your pile of punched cards representing your program, and possibly a separate magnetic tape for your data set, to a service counter where an operator would receive your program cards and data. If you were lucky, the results would be available in a half an hour when you could return to the service counter and obtain a line printer printout of the results of your job. You might also pickup an output magnetic tape if you had written a large data set.
PLATO began its first hardware incarnation as a program running on the ILLIAC I, a large vacuum tube computer at the University of Illinois at Urbana-Champaign and supported a single user. In 1961, PLATO II supported two users on a single system. PLATO III was created In 1963, running on a Control Data Corporation 1604. It would grow through 1972 to support up to 70 terminals around Illinois. PLATO III introduced a visual editor to assist in the creation of courseware, written in FORTRAN and assembly language. The TUTOR programming language was created to assist specialists in their subject matter in creating courseware, largely removing the need for courseware to be created exclusively by specialized software engineers. This would make TUTOR one of the first domain-specific languages and greatly expand the variety of courseware available on PLATO.
In 1972 the National Science Foundation invested in the PLATO project, resulting in the PLATO IV system. This was the system I used at the University of Delaware. The terminals had a 512×512 plasma display screens that were touch sensitive and were connected to a CDC mainframe, a CDC 170 at UD. The touch screen was used for pointing instead of a mouse because it was felt that children would be more readily engaged by touching the screen than by manipulating a pointer indirectly through the mouse. By the late 1970s and early 1980s, the cost of memory had come down sufficiently that raster terminals would also be introduced at UD.
Shortly after the introduction of the PLATO IV system, social computing applications began to emerge naturally from the PLATO users: email, instant messaging, chat rooms, message boards, the world’s first online newspaper, multiplayer games, animations and emoticons all appeared. In our little group at DELTA, the notes messaging system on PLATO inspired Phil Bernosky to create a similar application for us to use on RSTS/E where we exchanged animated ASCII art messages. None of these social networking applications were part of the original plan for PLATO, they emerged organically from the wants and needs of the PLATO users themselves, creating a situation Brian Dear refers to as “beta testing the future”. The Notes application on PLATO would inspire Ray Ozzie to create Lotus Notes.
In 1976, Control Data Corporation began a long-term relationship with PLATO to develop and market PLATO worldwide. That relationship would continue through 1990. I believe this is the reason that the University had a PLATO installation; all the equipment I remember seeing was branded with CDC logos and of course the mainframe was a CDC product. In the early 1980s, CDC and CERL, Bitzer’s Computer-based Education Research Laboratory at the University of Illinois, decided to pursue different paths. Bitzer formed a company called NovaNET that continues to profitably offer courseware today. CDC would eventually sell its interest in PLATO, including the trademark. This would eventually result in a company called PLATO Learning which still supplies solutions for classroom education.
There was a brief Q&A with Brian that isn’t shown on the YouTube video. In response to one question, Brian observed:
Computer users are like ideal gases—they fill any available [storage] space.
As a chronic disk pig myself, I can identify with that!
Day 1: Panel Discussion
John Markoff, Don Bitzer and Ray Ozzie
This panel discussion covered the breadth of the history and development of PLATO. Guided by New York Times reporter John Markoff, we get an in-depth discussion with Don Bitzer, the father of PLATO. We also get contributions from Ray Ozzie, who got his start in computing with PLATO.
Bitzer recounted how they would enter early programs in binary on paper tape using a teletype machine to punch 4-bit values. To enter the binary values 0-9, you would type the keys 0-9 on the teletype, but in order to enter the binary values 10-15 for a 4-bit value, you would type the keys K, S, N, J, F, and L. They had created the mnemonic “kind souls never joust fat ladies” in order to remember the proper sequence of keys for the hexadecimal values. John Markoff asked Don how the Sputnik scare of 1957 affected him. He said it wasn’t embarrassing so much because the Russians had launched Sputnik, but more because the attempts by the United States to launch a rocket had been failing so miserably:
What was embarrassing was that we had been trying to put a rocket up for a long time. […] They called it civil service as a nickname and that was because it wouldn’t work and you couldn’t fire them.
Ray Ozzie asked Don how he came about organizing (or not) the teams at CERL. Don’s answer reflects the same philosophy that we find in agile coaches today. Don selected bright capable people for his teams so that they didn’t need detailed oversight. He viewed his role as making sure that the teams didn’t have to worry about things like funding or problems introduced by the larger environment of the University in which they worked. He would keep tabs on their progress, but to a large extent simply got out of their way so that they could get their work done. If there were any problems outside the work at hand, Don would put his energies there to solve those issues and keep them off the radar of his team so they could stay focused on the mission.
At the Salt Lake Agile Roundtable we routinely have discussions focused around this sort of problem. Usually it all boils down to trust, or more accurately the lack of trust, in an organization. Don’s management style clearly imparted his trust to his teams to do the right thing and make progress towards the mission at hand—the interactive form of education envisioned in PLATO’s architecture.
Don also commented how the age of the team members–most of them were very young, so young that child labor laws would come into play when hiring them–gave them some unique qualities:
That was really very nice. They were receptive to ideas. They didn’t believe in defeat. In fact, we didn’t know what defeat was. I can’t picture any case where we really felt defeated and quit.
In the Q&A session, Don was asked: “What subject matter makes a good candidate for automated teaching?” His answer was that it was the good teachers that made good courseware. His example was of a Latin teacher that had been teaching the language in a traditional manner for many years and was very familiar with the material and ways of presenting it that aided comprehension and retention. The expertise of teaching latin was the key factor that enabled this teacher to create courseware for Latin that was very effective.
The lesson here for modern software developers is to find the person in your application’s domain that is the true expert and find ways to leverage their expertise to make your software better than your competition. Its amazing how often we forget this in software development and approach the domain as a software engineer instead of approaching the software engineering as a domain expert. One advantage PLATO had over other systems is that its TUTOR language took the middleman out of the picture and let the domain expert create the courseware directly. A modern example of eliminating the middleman is FitNesse which allows the domain expert to express domain requirements in a natural way and turn them into executable acceptance tests against the system.
Day 2: A Culture of Innovation: What Don Bitzer Wrought
Robert M. Price, David Frankel, Dr. Don Bitzer, C.K. Gunsales, and Dr. Robert I. Sutton
Day two of the conference contained a series of in-depth panels covering various aspects of the PLATO system: culture, hardware, software, courseware, games and community. The first panel, “A Culture of Innovation”, went into a detailed discussion of the culture surrounding the Computer-based Education Research Laboratory (CERL). As I listened to the discussion, I was struck by the parallels between CERL and Project DELTA. Like CERL, we had a large number of young students working for us writing software. Like CERL, we were generally left alone to make progress on our projects without being micromanaged. We had a large, open terminal room where people tended to help one another on their programs. Also, just like CERL, we were trusted with positions of authority over the computer system. For the most part, it worked well.
Don Bitzer talked about having his team have a party once a week instead of meetings. The group was large enough that generally there was a birthday to celebrate every week. They would get some cake and have a little party and everyone would catch up on what the rest of the team had been doing. This is a great example of what Alistair Cockburn would call a “low ceremony process”. No daily status reports, no weekly meetings with everyone sitting around a conference table going one-by-one and taking forever. Instead, its cake and ice cream and excitedly telling your teammate what youv’e been doing.
Robert Price had some interesting observations about innovation. First, he said “Failure is the most common characteristic of innovation.” Sometimes in the desire to produce software rapidly, we forget that failure is to be expected when trying something new. Instead of embracing the failure as a learning opportunity to get closer to our goal, we feel afraid to express failure when exploring a possibility. If innovation were a process that always succeeded the first time, it would be something that anyone could do as simple as falling off a log. This is a similar sentiment to Thomas Edison’s quote of his inventions not being created by accident, but that they boiled down to “one per cent inspiration and ninety-nine per cent perspiration”. In order to innovate, we must be given permission to fail.
His other comment was: “Marketplace acceptance is the hardest part of innovation.” As the former chairman and CEO of Control Data Corporation, Bob really understands that coming up with the idea or product is only the beginning. “If you build it, they will come” may work in a Hollywood movie, but its not a good way to plan a business or a product. After you’ve worked hard to create your innovative product, you have to work even harder to gain marketplace acceptance of your product.
C.K. Gunsales described the atmosphere at CERL (Computer-based Education Research Laboratory) as “community without conformity”, a community of individuals. As a strong individualist myself, this is a comment that resonates with me. For a community to be encouraging of innovation, individuality must be embraced; innovation rarely comes out of a committee.
David Frankel told the story of the “indispensible engineer”:
Engineer: “You can’t fire me because I’m indispensible!”
Frankel: “That’s why you’re fired.”
Frankel’s point was that noone should ever be allowed to become indispensible; its a weakness in your organization. The best way to overcome that weakness was to force it to the top by getting rid of the indispensible party, thereby forcing the team to absorb and acquire the indispensible knowledge. Pair programming is a modern practice that guards against indispensibility by diffusing knowledge from the experts to other members of the team. At CERL, there were no indispensible personnel; everyone could contribute to everything and knowledge of the system was freely shared and questions were encouraged and always answered, no matter who asked them.
Robert Sutton observed that the culture of CERL “gave [the kids] permission and gave them protection”. Many of the key software advances at CERL were written by people under the age of 18 and hired by Don Bitzer because they were passionate, bright, creative individuals. A good leader gives his team permission to explore and fail. (Remember, failure is part of innovation.) At the same time, you give your team protection. That might be protection from some other part of the company that doesn’t understand the creative nature of knowledge work (“What’s so hard about it? Its just typing!”) or protection from other influences that would discourage experimentation and innovation.
Day 2: Innovations in Hardware: Mission-based Developments
Dr. Larry Weber, Dr. Roger L. Johnson, Dr. Don Bitzer and Philip McKinney
The hardware panel was interesting to me because I didn’t realize just how much hardware had been invented specifically for the PLATO mission. I knew that there was all this strange software (like the TUTOR language) that surrounded PLATO. It was obvious that PLATO was different from the other computer installations at the University of Delaware because of its odd terminals and weird peripherals like a text to speech synthesizer and its ability to play music.
Over 35 primary patents in the areas of system design, display, and communication were obtained in pursuit of the PLATO mission of interactive computer-based education. Those patents were awarded in the following areas: 3 for system design (mainframe and cluster), 18 for display (mostly plasma display panel related), 3 for touch input (infrared and light pen), 7 for communications (data over video, voice networks and satellite) and 4 for other areas (slide and audio selection). I was surprised to learn that 9600 baud modem patent came about because of PLATO. Because PLATO terminals were remote from the mainframe and communicated over modem connections on phone lines, it was desirable to increase the communication rate of the terminals. By tricky encoding of the signals on a phone line, an effective baud rate of 9600 could be obtained on lines that previously only supported 1200 baud, all without updating the phone network infrastructure.
The majority of the hardware patents revolved around the invention of the plasma display panel. Due to its nature, the plasma display panel not only generated an image, but also served as a memory store for the displayed image. This eliminated the need for image scanout and display circuitry found in every video card today. It also eliminated the need for expensive memory to store the displayed image. By 1971 the plasma display panel had reached a level of maturity that Owens-Illinois was contracted to build the display panels used in PLATO terminals. The display was 512×512 pixels, bistable and had a 12″ diagonal screen.
Over time, enhancements would be made to plasma display panel technology. For instance, by managing the duty cycle of a bistable pixel you could simulate grayscale imagery. Eventually the technology advanced to the point where full-color imagery could be displayed. You can see this for yourself on a trip to any consumer electronics store that sells plasma display panels.
I asked how printing was supported by the PLATO terminals. Printing worked by imaging the back of the display onto an imaging drum and using xerographic techniques on the drum to print. As they told me of their solution, I remembered that the terminal room in Willard Hall at the University housed such a printer in order to be able to print out the results on the screen.
Day 2: PLATO Software: Driven by a Clear, Compelling Challenge
Dr. Robert Rader, Dr. Bruce Sherwood, Michael Walker, and Steve Gillmor
Don Bitzer did early real-time radar analysis work for the military. This informed Don’s idea of how educational software should be experienced, driving home the importance of graphics and imagery. It was also necessary to drive down the cost per terminal of the system and timesharing was the obvious answer. PLATO II allowed the ILLIAC I to be shared between two terminals, but that was only the beginning. PLATO III supported up to 32 terminals in 1963 and was introduced just a few years before the introduction of the Dartmouth Time Sharing System. (Dartmouth was also to introduce the BASIC language around the same time.)
By the time I was using PLATO at the University of Delaware in 1978, timesharing had proliferated. Delaware still had batch punchcard stations, so-called remote job entry stations, placed around the University but I rarely saw anyone use them. At one point Project DELTA was located in an office that was shared with an RJE station—called the “fish bowl” since it was adjacent to the first floor lobby of Willard Hall and was surrounded on three sides with windows—and I can’t remember anyone submitting jobs to it while we were colocated with it. Not only was timesharing ubiquitous, it was supported by many different vendors. UD had timesharing on the HP2000, on the Burroughs B7700, on DEC PDP-11s running RSTS/E and Unix and on the DECsystem-10 running TOPS-10.
Michael Walker recounted how Andy Hanson was one of the young students working in Don Bitzer’s lab for about 2-3 years. In the summer of 1962, Andy created a timesharing resident module for PLATO III running on the CDC 1604. A FORTRAN compiler was being created at the same time and it was possible for a FORTRAN program to treat the system as if it were a single terminal, but could run on any terminal. This was a significant achievement for the time, implemented by teenagers who didn’t know you weren’t supposed to be able to do this sort of thing with a computer. Most competing timesharing systems (including UD’s systems up through the early 1980s) operated on a line-by-line basis, with no concept of a screen—printing terminals like the LA36 were common. PLATO operated on a character-by-character basis and could assume the presence of a uniform 512×512 graphics screen, making for a very different environment. On top of the resource rich environment that could be assumed, everything on PLATO had built into it the design requirement of a highly interactive and responsive system, with the requirement that the system always be able to respond in 100ms or less.
Compared to other timesharing systems of the day, things were even stranger for the Burroughs timesharing system which talked to the terminals using half-duplex communication. In the case of the Burroughs system, characters were not echoed by the mainframe computer but entirely by the local terminal which made for an interesting mechanism to secure passwords. On the Burroughs system, a password prompt would be printed followed by a series of characters, such as #, $, &, etc., that were overprinted to create a solid printed block on the page over which you would type your password. In case you were using a video terminal, another block of characters would overprint your password after you pressed RETURN to erase the password from the screen. Another odd side-effect of half-duplex communication on the Burroughs system was that when you pressed RETURN, that happened immediately due to the local echoing of the terminal. The linefeed that advanced to the next line would be transmitted by the mainframe after receiving your carraige-return character. When the system was heavily loaded, there was a noticeable delay between the two characters giving you the odd feeling of your CR/LF combination being a schizophrenic operation.
The next key advance in reducing the development cycle of PLATO software was the creation of the TUTOR language in the mid 1960s. TUTOR’s goal was:
It should be possible for ordinary people to write software without the intercession of system programmers.
While some significant courseware had already been developer for PLATO in assembly and FORTRAN, such as nursing and electrical engineering curricula, TUTOR opened the door for the teaching expert to directly create the courseware without the need of additional software engineering expertise.
PLATO IV architecture
One unique aspect of TUTOR was a feature called answer judging. Bruce Sherwood showed some TUTOR source code that demonstrated the syntax and operation of answer judging. With answer judging, the student types in free flowing text for the answer to a question. TUTOR had to be able to flexibly process and understand as best it could and respond to student input that may be malformed. TUTOR allowed for the author of a lesson to specify ignorable words, common spelling errors, acceptable synonyms and the appropriate responses for right answers and wrong answers with hints for how to correct the problem. This is a stark contrast to the typical multiple-choice type computer-based instruction. A consequence of answer judging is that it forces you to think about the answer instead of just making an educated guess based on the multiple choices presented to you.
Day 2: On-Line Education and Courseware: Lessons Learned, Insights Gained
Dr. Bruce Sherwood, Dr. Sharon Dugdale, Bonnie Anderson Seiler, Dr. Ruth Chabay, and Dr. Roy D. Pea
The education panel consisted mostly of educators, the authors of PLATO courseware. Bonnie Seiler directed the development of computer-based educational materials on PLATO at the University of Delaware and was the author of some of the math lessons that I tried in my first PLATO experience. While this panel was interesting, it was the farthest away from my personal areas of expertise and I had fewer of those “aha!” moments. However, unlike the other panels, there were several demonstrations of PLATO lessons shown during the session.
Ruth Chabay shared her experiences of being introduced to PLATO by way of chemistry courseware. She showed some examples of courseware for performing titration, which displayed the whole lesson graphically as essentially a real-time simulation of the actual labwork. This was groundbreaking for the 1970s as graphics and visual simulation wouldn’t become pervasive in computing for another two decades. Inspired by the titration lesson, Chabay worked on courseware for organic synthesis and charged particle interaction. There are some lessons here for how to create inspiring and educational games on platforms such as the Xbox 360 using XNA.
Bonnie Seiler described how her story was a little bit different in that she was already a 4th grade teacher and chose the University of Illinois for her master’s degree because of the PLATO system. She talked about how the touch screen interface of PLATO was essential for the courseware used by 2nd graders because it allowed for direct interaction with the problems by directly touching what was on the screen without. Seiler took inspiration from Dr. Bob Davis who said:
“Math is a story of the real world.”
Her courseware “Animal Bagger” was an example of putting this idea into practice to contextualize the model of fractions into a real-world problem of helping a pet store owner divide up pets into bags. Kids could create their own custom problems by selecting the pet, the fraction into which they would be divided.
“How the West Was 1+3*4” was a game designed by Seiler to teach children the order of operations: multiplication, division, addition and subtraction. This was a two-player game but a single-player version was created where the child would play against the computer. The player chose the expertise of the computer: worse, average or best. Children were complaining that PLATO cheated, but Seiler didn’t believe them thinking that they just didn’t know the order of operations. However, when the “TERM Comment” feature was added to PLATO, she found out that the kids had been right all along. TERM comment allowed the user to make a comment on the lesson at any time. Recorded with the comment was the lesson software context, allowing the author of the lesson to associate comments with particular portions of the tutor program. This was used to identify and correct a bug in the lesson. Providing opportunities for contextualized feedback in software can lead to rapid improvement of the software, yet how often do we fail to provide even the most basic mechanisms for feedback in our software?
Sharon Dugdale described a program designed to teach fractions by allowing you to mark up a rectangle with lines and paint blocks delimited by the lines crossing the rectangle. The result would be a painting that visualizes the fractaion. However, each student could take their painting and put it in the library where other students could see their painting. This resulted in a viral competition between students to come up with creative ways of painting the fractions, including painting their names in the fractions. At first, when only students from a single school were using this lesson, nothing really interesting happened, but when the lesson was opened to 300 children across several schools, the viral competition took off. The networking abilities of PLATO allowed for enough critical mass in the size of the community for the viral aspect.
Day 2: PLATO Games: An Early, Robust Community of Multi-player, Online Games
Rich Hilleman, Bruce Artwick, John Daleske, Dr. Brand Fortner, and Dr. Andrew Shapira
The gaming panel was an interesting view into the origin of the kinds of gaming we all take for granted now: real-time, graphics oriented, multiplayer and networked. John Markoff recalled the advertising slogan of InfoCom: “The best graphics are in your head.” and commented how with the current crop of games this is no longer true. Early computer games required a willing suspension of disbelief in order to really get into the games. Bruce Artwick noted that you have to meet a certain threshold of realism for something to be usable, but the treshold is lower than you might think because your mind interpolates what’s there and fills in the rest. He showed an example of his flight simulator program running on the TRS-80 using character graphics which was compelling enough that people would become immersed in it. Andrew Shapira noted that there are elements of immersion other than graphics; you can create a sense that there’s a depth to the game that is hidden, that there is always something more to the game than what you see.
PLATO’s graphics (512×512 raster with a plasma display, 1972) gave rise to early forms of multiplayer computer gaming. Rich Hilleman observed that games have an “imagination load” comparable to “pilot load” in airplane cockpits. As the graphics in games got better, the imagination load was transferred from filling in the blanks of schematic graphics to the underlying strategy of the game. This results in playing the game in ways the author never intended, such that the game author rarely is able to win at their own game. Is there a parallel for other kinds of software? How can we explicitly leverage imagination load to allow users of our software to solve problems in ways we never intended or imagined?
In keeping with the PLATO goal of interactive response rates, Bruce Artwick described how there was an explicit conscious choice to simplify the image quality in order to achieve the desired frame rate. There has been a similar parallel in the scientific visualization where computational steering has become the goal for compute intensive simulations. Instead of just grinding the simulation for a long time and visualizing the result later, computational steering attempts to compute coarse results of the simulation so that the scientist can further guide more detailed simulation runs.
All the game authors on the panel admitted that once their games were released, they didn’t win at their games. Rich Hilleman observed that “those who discover the exploits are the winners”. The authors were playing their games the way they were meant to be played, but others played their games the way the software allowed the games to be played.
Rich Hilleman commented that games are compulsion systems and share some attributes with gambling. Many of the aspects of gambling that keep the customer returning for more of the experience are also present in computer gaming. Those aspects were also present in use of PLATO in general and captivated their users early and kept them coming back often for more PLATO.
Day 2: An Early Online Community: People Plus Computing Grows Communities
Lili Cheng, Kim Mast, Dave Woolley, and Charlene Li
The community panel had Dave Woolley and Kim Mast, who were both programmers at CERL. Dave Woolley is the creator of PLATO Notes and Kim Mast was the author of “pnotes”—Personal Notes, a precursor to modern email systems. Creating an on-line community was never part of the plan for PLATO because noone had ever seen an on-line community before.
Charlene Li asked Dave Woolley what was the impetus for the creation of Notes? Woolley responded that this was the time between the transition from PLATO III to PLATO IV. It hadn’t occurred to anyone to use PLATO III as a communication tool because all the terminals were in one room, but PLATO IV was starting to network terminals across geographic distances. In PLATO III, when you encountered a problem, you would simply edit a common file called “notes” and append your problem to the end of the file. Once the problem was fixed, then the operators would edit the file and annotate the problem with “fixed”. However, this was a solution that didn’t scale very well to large numbers of users because only one person could edit the file at a time and occasionally people thought it would be funny to delete the notes file. As a result, Paul Tenczar came to Dave Woolley and essentially asked him to write a bug tracking system. Tenczar’s vision was of a system where the top part of the screen showed the reported problem and the bottom part of the screen showed the response from the system operator.
It occurred to Dave Woolley that this idea of a single question and answer wasn’t versatile enough because the operator might want to ask follow-up questions of the user if they had tried various things and the users would respond, and so-on. Woolley realized that what was needed was a system that allowed people to have conversations, so that’s what he created. You could start a note and there could be any number of responses to your note. When the PLATO Notes system was released, it became a system command that invoked the notes application whereas before you would have edited the notes file in the system’s courseware authoring mode. Notes was initially released with three notes files: system announcements, help notes where users could get help from each other and staff and public notes, a free-for-all about anything. Public notes was the notes file that really took off.
Kim Mast recalled the inspiration for pnotes. As the number of PLATO users increased and the usage of Notes increased, your day typically started off by coming in and reading Notes and seeing what was happening on the system. The workplace environment of CERL was very much self-initiated, so you would rarely be given an “assignment” for what you were going to do. Instead, you found something that needed doing that seemed to be interesting to you and just started working on it. As you would arrive in the morning and read through Notes, it eventually became obvious that you’d like to send a note to an individual person and not to a public group as was possible with Notes. PNotes arose out of this desire to send personal notes to an individual. When you logged into the system, PLATO would inform you if you had pnotes waiting for you to read.
When I first used PLATO at the University of Delaware in 1978, the notes system was already firmly in place. PLATO installations around the US were networked together, so that notes didn’t just apply to the community of users at UD but also at UIUC and the University of Hawaii. One of the more prolific notes users at UD was “Dr. Gräper”, who wrote a large number humorous rantings in notes. I remember reading these at the time and finding them quite hilarious, particularly as the locale described in the rantings was intimately familiar to me.
What wasn’t mentioned on the panel is that PLATO Notes is probably the first instance of cybersex, at least at UD. Delaware had courses in human sexuality and a corresponding public notes file on the PLATO system where students were encouraged to share their feelings and thoughts about their sexuality. To encourage openness and discourage judgment of these intimate feelings, users were encouraged to post anonymously to the notes file. The notes file was also monitored for abusive and hateful comments, which were removed. Anyone with a PLATO login could read the notes file, called “sexednotes”. Sometimes the discussions were factual inquiries into this or that aspect of human sexuality and sometimes they read like an entry in Penthouse Letters with fairly graphic and detailed accounts of a sexual encounter. As a teenager myself, this made for highly interesting reading! Somewhere along the way, I learned quite a bit about human sexual practices, contraception, safeguards against sexually transmitted diseases, etc. Hmm…. maybe that was their intention all along?
The PLATO online communities were more subject oriented and less attached to an individual. Modern online communities are somewhat egocentric in that each person has a profile which they customize around themselves and so-on. While every PLATO user had a logon, there was no “home page” about you that other people could view. You only came to know other individuals through their public actions in Notes or in other software. In some ways, this made PLATO the great equalizer—everyone’s thoughts and exchanges were presented in a uniform manner.
Charlene Li asked Lili Cheng how you foster an environment that supports the kind of innovation seen in the PLATO systems. Cheng observed that trust creates the safety needed to take risks and you need create an environment containing trust in order to foster innovation. Taking risks is necessary for innovation, but risks will never be taken in an atmosphere of low safety or trust. Don Bitzer hired smart, creative young individuals and trusted them to get the right things done in the right way. He created a safe atmosphere that allowed them to explore solutions and experiment without fear.
Day 2: The PLATO Playground
Douglas Crockford at a PLATO IV terminal, PLATO V terminals, IST III Terminal
PLATO III terminal, EIS PLATO Random Access Audio System, IST I Terminal and TUTOR Language manual
Portable plasma terminal mockup, prototype wireless keyboard, modem, prototype color terminal
Conclusion
The PLATO system was my first computer experience and that “friendly orange glow” of the plasma screens shaped the direction of my entire career. It was always a fun experience to use PLATO and many of the elements of PLATO presaged what the rest of the world would get in their computing experience by decades. Until I attended this conference, I had no idea how much of what I take for granted around me was due to PLATO and specifically to the vision of Dr. Don Bitzer. I really am thankful that the Computer History Museum put on this conference and that Microsoft sponsored the event and the video recording of all the panels. My heartfelt thanks goes out to Don Bitzer and to all the folks from CERL, UD and elsewhere who created that wonderful mix of people, hardware and software that was called PLATO. My apologies for any factual errors I might have made while writing this essay on the conference.
Legalize Adulthood! 
10-July-2010 at 12:31 pm
Re the synthesized music and the PLATO audio player shown in the photo — indeed those are not the same thing. The audio player would play a magnetic disk with short snippets of pre-recorded sound; think of it as an audio tape but random access.
The synthesizer is the Gooch Synthetic Woodwind (GSW or “Gooch box”) after its inventor. That was one of the earliest, probably THE earliest, digital audio synthesizer. I don’t see it in the photos. You can hear an emulation of it via the “pterm” program connected to cyber1, though, not just the ragtime pieces you mentioned but lots of others. And the full schematics are available in US Patent 4,206,675.
A later device was the Gooch Cybernetic Synthesizer, a 16 channel fully programmable waveform synthesizer, again probably the first of its kind. So far I haven’t succeeded in finding enough technical data or the controlling software to be able to emulate it in pterm, but I continue to try for that…
–paul
LikeLike