Advent of Computing - Episode 19 - PLATO Part 1: A Revolution in Teaching

Episode Date: December 16, 2019

In  the 1960s a small project started at the University of Illinois. This project, called PLATO, would go on to pioneer a truly impressive amount of new technology, including the first plasma screen, MMO video games, and time-sharing. However, PLATO remains relatively unknown today. Like the show? Then why not head over and support me on Patreon. Perks include early access to future episodes, and stickers: https://www.patreon.com/adventofcomputing Important dates in this episode: 1952: ILLIAC Becomes Operational 1960: PLATO I Developed 1961: PLATO II Developed 1969: PLATO III Developed http://tee.pub/lic/4jnwv7m_ZPw

If you've ever used one, then you know that computers are frustratingly complicated. So it should go without saying that their history follows a very similar pattern. There's a lot of things that go on, and they usually happen all at once. And when you attempt to simplify things, you run the real risk of missing out on what's actually going on just under the surface. I bring this up because it's often tempting to look at the development of the computer as a linear progression. You have the first barely usable behemoths like ENIAC developed in university labs and government-funded programs. Then you transition to relatively small and more powerful computers created by big businesses like IBM or DEC. And eventually,

you wind up with the creation of the personal systems spun out of Silicon Valley that we're familiar with today. And while that's a nice way to sum up generations of progress, things get a lot more muddied when you look a little bit below the surface. A lot of the technology that we think of as strikingly modern coexisted with some of the earliest mainframes, and many downright antique devices were in common use as late as the release of the IBM PC. An amazing example of this is a system called the Programmed Logic for Automated Teaching Operations, or PLATO. It's an often-forgotten project from the University of Illinois that

pioneered a shocking amount of new technology. The terminals used by PLATO were incredibly distinctive. They centered around an orange gas plasma display decades before the flat-panel display would come into common use. At the same time the computer mouse was being invented, Play-Doh terminals were already being outfitted with touchscreens. By the time the ARPANET was just starting, Play-Doh already had connected terminals across its entire home campus. And as ARPANET was just turning three, Play-Doh terminals were already being used for networked multiplayer video games. And here's the wild part. Plato wasn't being created as some kind of tech demo or a military project. It was designed as

an educational platform, meant to teach automated classes. So let's take a look at Plato, and let's see just how much it complicates the story of the computer. Let's see how a project aimed at improving education turned into something even bigger, and why its story remains somewhat enigmatic today. Welcome back to Advent of Computing. I'm your host, Sean Haas, and this is episode 19, Plato, part one, a revolution in teaching. Today, we're going to be looking at a project that's remarkable for a large number of reasons. Plato was an early player when it came to computers, first starting in 1960. It was also incredibly long-lived. It would survive on in some fashion or another nearly 50 years. During that long lifespan, Plato would usher in a huge number of advancements.

But despite all these factors, it remains not very well known today. And I guess the first step in fixing that is to explain what Plato actually was. And right away, we start to run into a complex story. The front-facing part of Plato was a line of terminals. Those terminals were backed up with special-purpose software and hardware that ran on a remote mainframe. Later in its life, Plato terminals would start to become more sophisticated, but they'd still rely on a network connection for a lot of functionality. So it's better to think of Plato as an entire ecosystem than any one single device and even then it's more of a lineage of systems. Another complicating factor is that for Plato a lot of

technical advances were just a means to an end. For instance a handful of programmers at the University of Illinois would implement an entire timesharing operating system in basically stolen time just so that they could run more terminals at once. Around that same time, a massive team of researchers at MIT would spend years of work and countless government dollars trying to create their own timesharing system. The development of PLATO just had different priorities. It went at a pacing that's contrary to its contemporaries. And in doing so,

it pioneered countless advancements that wouldn't be seen outside of the University of Illinois for years to come. In this episode and the next, we're going to be taking an in-depth look at PLATO. And that's right, we have another two-part series on our hands. Along the way, we'll see how a project that was aimed at revolutionizing teaching led to a revolution in technology at large. We'll see time and time again how the team behind Plato turned limitations into mere bumps in the road. And we'll spend a lot of time looking for where we can see Plato's legacy today. For me, when I look at Plato, I see a story of constant struggle against limited resources. The ideas behind Plato always seem to be a few years ahead of the state of the art,

and definitely outside of the team's budget. This tradition, though, goes back far before the project actually started, all the way back to the 1950s. The world was just starting to recover from the largest war in history, and the US was just starting to come to grips with the growing Cold War. This was a period where a lot of technical advancements started to take place. And with the 1957 launch of Sputnik, it was becoming apparent the U.S. wasn't on the winning side of this new conflict, and wasn't the major player in a lot of these advancements. During this period, the U.S. government would spend considerable effort trying to catch up to the USSR, and

education was one of the areas for improvement that was realized relatively early on. Part of the issue with education just came down to the scale of things. The post-war baby boom had dramatically increased the number of students in primary and secondary schools. And at the same time, the GI Bill, which, among other things, paid for college educations for returning veterans, meant that enrollment in higher education was also increasing. Students learn best when they can move through material at their own pace, and that requires one-on-one or at least close to one-on-one instruction. But with increasing stress on the education system, classrooms were getting further and further away from that

one-to-one ratio. And during this time period, to a lot of educators and researchers, a solution started to appear. Automation. But here's where you run into more problems. How exactly do you go about automating something as large and far-reaching as education? How can you remove a teacher from teaching? There's not really an instant solution that springs up. There were a good number of early attempts that used purely mechanical means to make teaching machines, so to speak. These would run the gamut from simple to inanely complicated. One tactic was a device of sorts called a scrambled book. It's essentially a

textbook in the form of a choose-your-own-adventure novel. Other researchers created clockwork multiple-choice test machines, where a student would answer a series of test questions and get immediate feedback from a series of gears and punch- paper tapes. All these devices worked, broadly speaking at least, but they weren't flexible enough to really take off. There would be continued attempts at using single-purpose teaching machines through the 50s, concurrent to which a new solution would start to develop in the background. The post-war years also saw some of the first general-purpose computers hitting the scene. Compared to anything remotely modern, these systems were monstrosities. This generation of computers would have to be housed in large, purpose-built rooms,

with high-wattage power supplies and careful temperature controls. These beasts were built primarily out of vacuum tubes. These were an antiquated and somewhat unreliable equivalent of the transistor. Out of the handful of primitive computers from the era, the machine that matters for our story goes by the charming name of ILLIAC, the Illinois Automatic Computer. ILLIAC was built by the University of Illinois in 1952, and it weighed in at a whopping two tons, and it used over 2,800 vacuum tubes. Interestingly enough, it used 40-bit wide words, so the amount of memory it used takes a little bit of converting to put into modern terms.

Doing some math, it had roughly 69 kilobytes of memory to play with, but the usable space would vary on how the machine was configured. There wasn't a standard loadout for these types of computers. For the time, ILLIAC was one of the more powerful computers out there, and amazingly, it would see use almost constantly for 10 years, until it was taken offline once and for all in 1962. There started to be talk of applying computers to automate teaching pretty early on in their development, but nothing ever got very serious at first. Remember, at this point in history, computers were a very limited resource, something more easily enshrined in some locked-down lab than used in a classroom in any regard. By 1959, the conversation would come up again, this time between the physics and

engineering faculty at the University of Illinois. And as the decade had gone on, things had started to change. There were more computers being built, so there was a little bit more room for experimentation. So the idle musings started to turn into more concrete plans. There were meetings, and eventually a team started to form to tackle the problem. Over the years, there'll be a huge cast behind the creation of what would become Plato. But there were two driving players in the early years. Plato. But there were two driving players in the early years. The first was Dan Alpert, a physicist who by 1959 already had an illustrious and long career. He had worked on the Manhattan Project during World War II, after which he spent a few years working at Westinghouse before finally

joining the University of Illinois in 1957. Once at U of I, he served as director of the Coordinated Science Laboratory, or CSL. Although Alpert was himself a physicist, a lot of the work he did with CSL would be concerned with finding better methods of education. Alpert would handle the administrative side of things and help facilitate research. A lot of his contribution isn't glamorous, so he tends to sink into the background, but his work is very core to Plato. The second player was another physicist by the name of Don Bitzer. Once the team started to form, Alpert almost immediately brought Bitzer on to head up the actual design

and implementation side of things. When Plato started, Don was just completing his PhD in electrical engineering and was working as a lab assistant at the time. He was inexperienced, but that wouldn't stand for long. From all accounts I've read, he had a certain drive about him that made him a perfect fit for clearing new ground. Alpert would make the lab and computer access possible while Bitzer figured out the what and how of the project. And to start with, that meant space in CSL's lab and time on ILLIAC. By 1960, all the pieces to start were in place. There was a problem, a team to work on it, and an idea of the solution, at least.

But beyond that, details were pretty fuzzy. Don, Dan, and an assortment of other researchers had a lab and a computer. But outside of that, they didn't have a lot of resources or funding. You have to realize that at this early stage, Plato was more of an exploration of the possible, and it had yet to prove that very much was possible. So the first attempt at creating a teaching machine really came down to finding a way to computerize the earlier mechanical teaching devices. The problem with all these failed mechanical means was that they were massively

inflexible that and a student could very easily just cheat on their tests there wasn't any way to make sure that they didn't just try until they got the right answer and then moved on add to that the fact that early teaching machines couldn't really teach. More, they just tested students. And you can see that that altogether makes a lot of space to improve. The ideal machine and the goal that the Plato team would work towards was a system that could accurately and responsibly test students on their knowledge while also presenting entire lesson plans. To be most efficient, this would have to be done in such a way that many, many students could each go through their self-paced lessons simultaneously. Bitser realized that for a first go, they should just worry about one student, though.

If a prototype works, then it can always be scaled out somehow. That removed one complication, but there were still plenty of issues to address. The design of the lessons would be pretty easy to work out. It would have to take the shape of a somewhat interactive textbook, with figures, pictures, and text all displayed on some type of screen. Along with that would be the all-important testing aspect. Each lesson would have to have a series of questions mixed in with the important information. Somehow, they'd have to devise a device that could display the lesson and test information while also taking student input. Today, that's a no-brainer. You'd use a computer and a keyboard. But in 1960, none of that existed yet.

There wasn't an easy way to display graphics. Heck, the computer keyboard wasn't even a standard offering yet. And it wasn't even an option to give each student a computer. Remember that the University of Illinois had a whopping one computer. You got ILLIAC and that was it. So Bitzer and Co. would have to get a little bit creative to make something work, and I think that's the best way to describe these early days of Plato. The first device that they hammered out was called Plato 1, since the team already knew that there would have to be future iterations, and the inner workings of the machine are a perfect example of creative thinking. The student would sit at a terminal that was made out of an old TV that Bitzer got off the side of the road and a simple keypad. The keypad was wired directly up to ILLIAC so that anything the student

punched in would get input straight into the computer as quickly as possible. The output side of things, however, was a little more complicated. The fact of the matter was that ILLIAC simply didn't have enough memory to store a whole lesson. And on its own, there was no way for ILLIAC to render graphics. To work around this, PLATO-1 used a combination of new and old technology. One piece of this simple solution was a computer controlled slide projector. Parts of lessons that didn't need to be interactive were turned into small photo slides. ILLIAC could then just tell the projector to advance to a given slide. It worked in a similar way to the earlier choose your own test books, but this was all computerized.

It might not be the most elegant solution, but when you think about it, the simplicity here is pretty clear. The user is the only person who needs to see most of the lesson, so it doesn't matter if the bulk of the lesson is loaded into the computer itself or just visible to the user through some other means. Slides would handle the static part of the lesson, but there was still the matter of the interactive component. That would be handled by a device known as a storage tube. Now, these were somewhat similar to cathode ray tubes used in the older style of TVs, but with a little bit of a twist. A storage tube, as the name implied, could store information. It had an inherent memory.

That means that anything that you plotted on the tube would stay on the tube, at least for a little while. Normally, a display like a computer monitor needs to be constantly getting a signal to display anything. But with a storage tube, you can just send in an image once and it stays displayed. with a storage tube, you can just send in an image once and it stays displayed. ILLIAC could push out a new line of text, a multiple choice question, or a relatively simple graphic to the tube, and then move on to another task without needing to keep much in its own limited memory. The two signals from the slide projector and the tube were then mixed together and displayed on the terminal's TV screen. It's a pretty effective trick. Play-Doh could circumvent memory limitations while also allowing for more complicated graphics

than ILLIAC could natively produce. Play-Doh 1 was completed in 1960, including hardware, software, and a couple test lessons. To quote from a status report written by Bitzer, To test the versatility of the machine as well as the basic logic of the computer program, a number of instructional sequences have been prepared, ranging from topics in mathematics to instructions in computer programming. To change machine instructions from one subject matter to another requires only replacing slides in the slide selector End quote. In practice, Plato 1 was something like a sophisticated interactive slideshow.

To prepare a lesson, an instructor would transfer their usual slides or notes into a format that could fit into the slide selector. Then, they'd need to work up and program a series of test questions to go along with that lesson. The questions didn't have to be multiple choice. Plato 1 could interpret simple expressions and some words. Once the program was loaded into ILLIAC and the slides into the slide selector, a student could sit down and begin to learn. From the terminal, a student was able to navigate both forwards and backwards through slides, answer questions, and get immediate feedback on the answers. More sophisticated lessons could even adapt questions depending on how well the student was doing. Once done, a complete record of the session would be spit out of ILLIAC

for the teacher to review. PLATO 1 worked very well as a proof of concept, but there was a lot of space for improvement. The next step for Bitzer was going to be growing the system out. Having a limit of a single terminal was a really big issue that had to be addressed, since for PLATO to work as an automatic teaching machine, it would need to be able to teach many, many students at once. So work started on the next iteration, called Play-Doh 2. The new version would consist of only two terminals that could be used simultaneously. That may sound like a small step forward. I mean, it is better than one terminal, but not by much. However, for the time, the jump to a shared system was actually pretty ambitious.

Allow me to explain a little bit. Play-Doh 2 used a mostly separate signal flow for each terminal. There were two TVs, two keyboards, and two sets of storage tubes. Strangely enough, though, they used a shared slide selector, but that's not super important for our purposes here. The last component, and the most important component, was ILLIAC. And remember, they only had one ILLIAC, so it had to be shared between the two Plato terminals. one ILLIAC, so it had to be shared between the two PLATO terminals. This was done using a method called timesharing. Today, we think of it as something like multitasking. For 1961, timesharing was the very cutting edge of computer technology. It worked by storing and then quickly switching between what each user was running on the computer. In the case of Play-Doh, that included which slide the student was viewing

and the content for the storage tubes. By swapping back and forth between running each terminal, it was possible to make it seem that each student had their very own, slightly smaller ILLIAC. On its own, Play-Doh's implementation of a timesharing system on a vacuum tube computer is pretty impressive, even if it only worked for two terminals, and even if it was developed just as a cog in a larger project.

But in context, it gets even more impressive. Play-Doh 2 started working sometime in early 1961, first being demonstrated in March of that year. But the team at U of I weren't the only people working on timesharing. The largest institution working on cracking the case was none other than MIT, and they had their own project called the Experimental Timesharing System. The first demo of MIT's system was in July of 1961, meaning that the Plato team had beat MIT to the punch by a matter of months. And keep in mind, MIT had a full team of researchers dedicated just to implementing timesharing. The Plato team at this time was small, maybe as few as a dozen people, and timesharing was just a step

in their road. Once again, PLATO2 was a proof of concept, and it worked well in that capacity, showing that it was going to be possible to scale up the system. It was used for testing and some research into computerized teaching, but was still a small-scale step. The next iteration of Play-Doh, which in a bolt from the blue would be called Play-Doh 3, was slated to be capable of teaching still more students. But that's where Bitzer and the rest of the team ran into a problem, and that problem was named Iliac. Play-Doh 2 was already a pretty big load on the aging computer circuitry. Upgrading to multiple more users was just more than the venerable machine could handle. The project was just plain outgrowing ILLIAC. It had served them well for many years, but it was time to move

up. And as luck would have it, a solution would find its way into the lab. Sometime in 1962, CSL would buy a fancy new computer, the CDC-1604. The new machine cost the university just under a million dollars, or about 8 million once you adjust for inflation. This machine was not only faster, but was more powerful and just plain nicer and easier to use than ILLIAC. One of the pain points, computer memory, was also fixed. The CDC machine came with 192 kilobytes of memory. That's a lot more than ILLIAC. But that wouldn't solve problems overnight. All the software for PLATO had been written for ILLIAC,

so they would need to painstakingly rewrite all of that code for the CDC machine. And there was also the reality that Play-Doh wasn't the only project in CSL. The new mainframe had to be shared, so initially the Play-Doh team would only get one or two hours a day on this fancy new computer. Despite the constraints, Play-Doh would flourish on this new hardware. Over the next handful of years, the system's software would get a total overhaul. The first big change was, of course, porting the old software from ILLIAC. But that gave a really good opportunity to improve and expand some things. The first order of business was,

of course, timesharing. Plato's early implementation had been fine for just two terminals, but things would need to be ramped up to get anywhere close to their initial vision. With limited computer access and limited human power, at this point, Plato's team amounted to a smattering of professors, some undergrads, interns, and even some students from a nearby high school, Plato 3 would start to take shape. The hardware side of things wouldn't be much different from the earlier versions. The system still used storage tubes, a TV, and a key set for each student's terminal, with a single shared slide selector. The difference, though, was in

scale. Play-Doh 3 was able to handle up to 20 users at once, which is a vast improvement over just two. That leap was thanks to some clever software on the mainframe side of things. The new software was called KtorRes, short for Compiler for Automatic Teaching Operations Resident. It's not a very catchy name. KatorRes managed the entire Play-Doh 3 installation. That included timesharing between up to 20 terminals at once. This ran from managing each student's screen, to routing keyset input, to even setting up regions of common shared memory for communications between running processes and terminals.

This one-two punch of expanded hardware and new software made PLATO3 robust enough to start seeing actual use. Over the next few years, multiple studies on computerized education were carried out using PLAT Plato. And along with that came a multitude of new lessons being developed for the system. In 1956, for the first time since conception, entire university-level college classes started being offered on Plato. They even counted for credits. The project was finally starting to reach its goal, 20 students at a time. But there would be more than just teaching alone. Useful terminals backed by a shared mainframe tend to make a hotbed for software development and tinkering, and Play-Doh is no exception.

One result of this time period is something that seems like a no-brainer in retrospect. time period is something that seems like a no-brainer in retrospect. That's the creation of a full-screen text editor. That program was called, and once again, this is a great acronym, the Multiple Online Nifty Speed and Terminal Editing Routine, aka MONSTER. And it would be one of the earliest computer text editors, at least one of the earliest ones that made use of an entire screen. The program itself was relatively simple. It just allowed a user to edit text files, including source code, from the comfort of a Play-Doh 3 terminal. But despite that simplicity, Monster and other similar tools marked a shift in what Plato was at its very core. Tutor was another tool being developed around this time. This was a highly simplified programming language that was designed specifically for creating Plato lessons. It was simplified in the sense that it was made to be

easy to use. Before Tutor hit the scene, most Plato lessons had to be written in Fortran, so anything up from there is a vast improvement. And here's what makes this development interesting. The combination of a new and easy-to-use language with powerful authoring tools changed what Plato could be used for. Prior to these tools being developed, creating lessons for Play-Doh kind of sucked. A teacher would have to prepare the code for the lesson on paper. Then that paper handwritten source code would have to be transferred to a set of punched paper tapes. Then you run that tape through another computer to compile it into machine code. And finally, once that's all done, you can load it into Play-Doh's mainframe. The process worked, but it took a lot of time and it relied on outside machinery.

These new tools made it so teachers could create a new Play-Doh lesson from within Play-Doh itself. This kind of concept of being able to write software for some platform from within the platform itself is called self-hosting. And it makes it so the platform, in this case Plato, can support itself without outside help. The immediate implication of this was that lessons were easier to make, but long-term it would contribute to a huge shift in what Plato was. We've already seen how Plato 3 was a major shift for the project, but remember the throughline of the story. Plato is all about struggling against limits, and in some cases, those limits are from within Plato itself. As the project evolved into a larger and larger undertaking in the latter half of the 1960s, it would contend

with some major limitations inherent to its design. Some smart thinking could get around some problems, but ultimately ultimately changes would have to be made. Slides, and the fancy computerized slide selector, had been part of Plato since the beginning of the project. The primary reason for this was the memory limitations imposed by using Iliac. Another contributing factor was the simple fact that it was easier for teachers to turn their existing notes into slides than program them out for ILLIAC to somehow display. However, PLATO3 was no longer running on ILLIAC. On the new CDC mainframe, a lesson could use more memory.

So there was less and less reason to rely so heavily on slides. And with the introduction of Tutor, Monster, and a couple other ancillary tools that could all run from a Plato terminal, teachers started to realize that they could much more easily move away from using slides altogether, or at least rely on slides a lot less. That simplified lessons a lot right there, and it gave teachers, or really anyone writing material for Plato, a chance to develop more and it gave teachers, or really anyone writing material for Play-Doh, a chance to develop more and more interactive lessons and programs. But, you see, everything has a trade-off, especially when it comes to computers. As slides were being used less and less, that meant that the downright arcane magic of storage tubes

were being used more and more. Now, reliable electronics are so normal in the modern day that it's easy to forget that that wasn't always the case. Just as an example, I've been using the same computer monitor with no issues for years. But the 60s were a lot different. Electronics weren't always as durable, and the storage tube is a great example. Over time, a tube would burn out, it would become unreliable, and it would need to be replaced. You can't really tell when the storage tube is finally going to run out. And if it happens to die on the terminal you're using, then you're out of luck. Storage tubes also didn't really store an image for all that long, maybe a matter of minutes before it would start to fade away from the tube's screen.

Play-Doh got around this by doing something kind of dumb, but I love the simplicity of it. It had a dedicated button on every key set that, with a student pressed, would redraw the entire screen once it got too faded to view and that works but that's obviously not a sustainable solution for a large project that is going to be used by students the other issue was remote access play-doh was designed so that a terminal could connect up to the mainframe from anywhere, at least in theory.

Bitzer and Alpert's conception of computerized education depended on being able to connect up remote terminals to some centralized system that could be far away from the actual classroom, mainly just to make logistics easier. And in theory, even Plato 1 could do that. But there's some major caveats. Play-Doh 3 did have a remote site, a single terminal located at Springfield High School in Illinois, about 80 miles away from the university lab. The keyboard side of things was the least complicated. The Springfield terminal used a modem to send keystrokes back to CSL over a dedicated phone line.

The video signal was where things get a little more complicated. Terminals inside CSL just used a closed-circuit TV setup. It's the same technology that's used for security cameras inside buildings. But for the single remote display, they had to lease a video line. Something more akin to what a local TV station would have to do than a high school. All of that made having a remote Play-Doh terminal very expensive. Just the two communication lines alone cost Springfield High School some $1,500 a month in 1960s dollars. The cost and complication of a remote terminal was

a big issue, and was one that couldn't easily be fixed without making some big changes to how Plato operated. That being said, Plato 3 was a step in the right direction, and as the decade wore on, the project would get more attention and acclaim. All the while, Bitzer, Alpert, and their cohort were working on the next step in their quest for better educational machines. But their plan would take time, and most importantly, it would take a lot of money. In 1967, the National Science Foundation would spin up a new branch, the Office of Computing Activities. And with most national-level institutions, the name is a little bit obtuse, but their main goal is relatively simple. They wanted to help advance the new field of computer-assisted education. And, as it turned out, this was the perfect opportunity for the PLATO project to get a much-needed infusion of funds.

Up to this point, the project had been running mainly on grants and determination. But, with the NSF, they had a shot at a continuous cash flow. Armed with the latest designs for a new iteration of their system, Alpert was able to secure initial funding from the National Science Foundation. PLATO 3 had already made a really good impression with the higher-ups at NSF, and the drafts for the new PLATO 4 seemed even more impressive. If Alpert and Bitzer were to be believed, then the system they had in the works was going to blow away all contemporary technology. system that they had in the works was going to blow away all contemporary technology. Backed by a supercomputer that would cost millions of dollars, Plato 4 would be able to run over 4,000 terminals at once, at any distance from the main computer. It would do away with the

cumbersome storage tubes, and it would provide an even higher level of interactivity than the earlier PLATO terminals. And the new terminals would be built around an entirely new type of display, a technology so new that it was only just starting to make its way out of the University of Illinois' labs. PLATO 4 terminals, you see, were planned to use a totally flat display, PLATO4 terminals, you see, were planned to use a totally flat display, less than an inch thick, and filled simply with an inert gas. This newfangled device, well, it was called a plasma screen. Alright, that's it for part one of our dive into the world of Play-Doh. We saw how an ambitious team was able to use limited resources to create a stunning invention. But the story doesn't stop here. Talking about Play-Doh is sort of like talking about the entire history of the PC.

It has a finite starting point, but as time goes on, it gets more and more complicated and more spread out as multiple players start to enter the arena. For IBM, that happened sometime after the first PC clones hit the market. But for Play-Doh, that happened after its fourth iteration launched. While I can't possibly cover everything about the system or all the software written on it, I'd be doing an injustice if I didn't give it the attention it deserves. So next episode, we're going to look at PLATO4, from the development of the groundbreaking plasma display to the proliferation of newly networked terminals, and finally, we'll take a look at what kind of software sprang up in

that environment. And just as a hint, it's a lot of video games. After part one, I feel we have a good foundation for where Play-Doh came from and how it was designed for education. But with the introduction of Play-Doh 4, a lot of that is going to change. In the meantime, if you want to learn more about Play-Doh, then I'd highly recommend checking out the book The Friendly Orange Glow by Brian Deer. It tells the entire story of Plato in amazing detail, and it got me deep into the topic. So until next time,

thanks for listening to Advent of Computing. I'll be back in two weeks' time with the conclusion of our discussion of Plato. If you liked the show, then why not take a minute to share it with a friend? Word of mouth is the primary way that I've been growing lately. You can also rate and review on Apple Podcasts. If you have any comments or suggestions for a future topic, go ahead and shoot me a tweet. I'm at adrenofcomp on Twitter. And hey, if you want to be a super fan and support the show, I'm always putting out new merch. I'll have a link to my TeePublic store in the description for this episode.

And as always, have a great rest of your day.