Advent of Computing - Episode 114 - The LGP-30: A Forgotten Machine

Episode Date: August 15, 2023

In 1956 Librascope released the LGP-30, a truly wild machine. It was, for the time, the most simple and cheap machine that could actually be useful. It was the size of a desk when contemporary machines took up small rooms. It plugged into a normal wall outlet while other machines requires special power feeds. It was, perhaps, the first hint of a personal computer. And at its heart was a magnetic drum that only a true programmer could love.   Selected Sources:   http://www.catb.org/jargon/html/story-of-mel.html - The Story of Mel   https://sci-hub.se/10.1109/TEC.1957.5221555 - Frankel's MINAC Paper   http://www.hp9825.com/html/stan_frankel.html - A Biography of Frankel

Real programmers write in Fortran. Maybe they do now in this decadent era of light beer, hand calculators, and user-friendly software. But back in the good old days, when the term software sounded funny and real computers were made out of drums and vacuum tubes, real programmers wrote in machine code. Not Fortran. Not RAT4. Not even assembly language. Machine code. Raw, unadorned, inscrutable hexadecimal numbers. Directly. Lest a whole new generation of programmers grow up in ignorance of this glorious past, I feel duty-bound to describe, as best I can through the generation gap, how a real programmer wrote code. I'll call him Mel, because that was his name.

I first met Mel when I went to work for Royal McBee Computer Corp., a now-defunct subsidiary of the typewriter company. The firm manufactured the LGP30, a small, cheap, by the standard of the day, drum memory computer, and it just started to manufacture the RPC4000, a much improved, bigger, better, faster, drum memory computer. Cores cost too much and weren't here to stay anyway. That's why you haven't heard of the company or the computer. I had been hired to write a Fortran compiler for this new Marvel, and Mel was my guide to its wonders. Mel didn't approve of compilers.

If a program can't rewrite its own code, he asked, what good is it? Mel had written, in hexadecimal, the most popular computer program the company owned. It ran on the LG P30 and played blackjack with potential customers at computer shows. Its effect was always dramatic. The LGP30 booth was packed at every show, and the IBM salesmen stood around talking to each other. Whether or not this actually sold computers was a question we never discussed. Excerpt from The Story of Mel by Ed Nather, as transmitted by the jargon file. Welcome back to Advent of Computing. I'm your host, Sean Haas, and this is episode 114, The LGP-30, A Forgotten Machine. As promised, this is going to be a markedly less serious episode.

I might have burned myself out a little bit during the prologue series. I'm happy with how things turned out, and it definitely broadened my horizons, but your boy needs a little break. And I guess for me that means producing the next episode. Today I want to shed some light on a surprisingly influential machine, the Libroscope General Purpose 30, better known as the LGP-30. This machine, dear listener, may be one of the most wild computers I've ever heard of. I'm also willing to bet that very few of you even know this machine existed. The LG P30 isn't often viewed as one of those huge landmark machines, but surprisingly,

it's a very well-connected little computer. Perhaps it's deserving of a slightly larger place in the overall canon. Now, I first heard about the LGP-30 way back in my formative years, when I found a copy of the Hacker's Dictionary, a lovely printed version of the old jargon file. This is one of the central repositories for hacker and programmer folklore. If you're a regular listener, then you've heard me wax poetic about this book. It's great. If you don't have a copy, then I highly suggest tracking one down. The LGP30 features in a tale that I opened the show with, the story of Mel. I just gave you an excerpt since I did do a full reading and that ran about 11 minutes. It's a little long in the tooth for an intro, but I think I'm going to put

that out as a separate just soundbite in the feed next week between episodes. In that story, the LGP-30 was the old machine that Mel, this larger-than-life real programmer, worked on. It was superseded by the newer RPC-4000 computer, which became Mel's new home. The story of Mel is really similar to the classic tale of John Henry. Instead of driving steel, Mel is driving the memory drum. That's this bizarre, antiquated form of memory that the LGP-30 used. Despite the existence of fancy tools and automated machines, Mel prefers to work directly and unaided. And despite all logic saying otherwise, Mel can beat those tools any day. There's a certain awe to the story that I was enamored with back when I was younger.

It was a great way to get me more interested in the deep end of programming. I personally think it had that effect on a lot of people. Nestled inside the story of Mel between digital blackjack and inscrutable code is the LGP-30. It's merely a mention, easy to forget, but that's where the story starts. This isn't the only place that the machine shows up, either. The LGP-30 has a wild number of cameos throughout the history of computing. The Dartmouth Oversimplified Programming Language, aka DOPE, was the precursor to BASIC, the direct ancestor. There's actually this really good VICE article about some dude who re-implemented the language

a few years ago. I think his name was Sean something. Anyway, BASIC is a big, important language during the microcomputer revolution. Its ancestor, which shares a whole lot of ideas with it, was developed on an LGP-30. One of the first implementations of ALGOL, one of the most influential languages in history, is written in 1960 for the LGP-30. One of the first computational studies on chaos theory was carried out on an LGP-30. This machine was also, perhaps arguably, one of the first computers that could even be

considered personal. arguably one of the first computers that could even be considered personal. It was still relatively big and pretty expensive, but a single person could easily install and operate the computer. All these factors make the LG P30 a very important machine, but what exactly was this weird computer? Today, we're going to be answering that question. We'll be looking at the history, development, and features of the LG P30. It's a type of machine that could only have existed in its era, in the middle to late 1950s. It's a machine that had wide-reaching impacts, even if they are purely sentimental. And it's a machine that's been widely overlooked. sentimental, and it's a machine that's been widely overlooked. The LGP30's history is somewhat confusing, confounding even. It begins in 1942 with a researcher named Stan Frankel and a little

thing known as the Manhattan Project. 1942 is the year that Frankel graduated with his PhD in physics from UC Berkeley. Then, as now, a PhD is actually only one stepping stone on a very long path of pain. After graduate school, researchers often transition into what's called a post-doc. It's kind of like a super internship that you're actually paid for. You know, you have a position working a research gig, but you're more supervised and have less control than a fully-fledged researcher. Usually, this means you're working under some more senior scientist. For Frankel, that scientist was named J. Robert Oppenheimer. I think the trajectory here is pretty plain to see, or at least guess at. Frankel spends his postdoc years working on the Manhattan Project. But even prior to that, Frankel was instrumental in the path to the nuclear bomb.

He worked on the team that first proved, with mathematical modeling, that a bomb was possible. These calculations were done by adapting thermal diffusion models that Frankel had developed years prior. So, right from the start, Frankl is right in the middle of everything. He's also using math models, something that will prove crucial to our story. Math models are funny things. They're another one of those concepts that sounds a lot more intimidating than it actually is. A mathematical model is really just a way of expressing some phenomenon, but using math. Oftentimes, this takes up more than one equation. Models will usually care about time, since they're representing the real world. In some cases,

for certain models, this presents itself in a discrete way. You have discrete time steps, which create some set of values. Then you can step again using your equations and create a new set of values. Once the Manhattan Project got off the ground, Frankel found himself working in the theoretical division over at Los Alamos Lab in New Mexico. This division was concerned with the actual math of how nuclear weapons would function. As such, there was a whole lot of math to do. They were running models of bombs, but in super slow motion.

At this point, the mid-1940s, there weren't any operable digital computers. Analog machines existed, but they didn't have the needed accuracy for these calculations. Digital machines did technically exist. Colossus was running in England, and there was probably at least one Zeus machine running at any one time in Germany, but the crew at Los Alamos, I don't think, had any idea about the technology. The only way to deal with this glut of math was to use the human computer. In practice, this meant that a bunch of the researchers' wives were hired and armed with mechanical adding machines. From the sources I've

read, it seems that Frankel and his colleagues realized they needed someone to run numbers, remembered they were married, and then ran home with job applications and clearance forms. This filled the mathematical gap for a while, but soon there were simply too many numbers to crunch away at. The desktop calculators were actually breaking down from overuse. So, Frankel and co. convinced management to get a bigger and better machine, an IBM punch card tabulator. It's at this point where we can make an observation about the models being used. They were discrete. That is to say, everything had to be handled in steps with intermittent results. This card tabulator was able to further automate the process.

Frankl had initially organized the human computers into something like a mathematical assembly line. the human computers into something like a mathematical assembly line. One person would run one step in this larger calculation, then pass the results off to the next person, and so on. With the tabulator, it was now possible to run a step, grab the outputs, then feed those back into the hopper. Apparently, there is an oral history interview that was conducted with Stan Frankel at the Smithsonian, but it's tucked off in a box right now. I have a duplication request out, and if that comes back anytime soon, I'm planning to revisit this specific part of the story. Anyway, we're told through secondary sources that Frankel became obsessed with this tabulator. We've seen many cases where folk get bit by the proverbial computer bug.

This time, though, Frankl was a little bit in front of the curve. Computers didn't really exist yet, at least not proper. But he was ready for them. I say he was ready because, despite not being a computer, an IBM tabulator was almost programmable. That's kind of the beauty of these kinds of machines. Frankel would have been working with a number of different IBM machines, the crowning jewel of the setup being a 601 multiplying punch with the division add-on. All these devices, collectively called unit record machines, were basically automated

calculators. Instead of accepting numbers from a keypad, you could feed in data on punch cards. Instead of displaying results in some, you know, easy-to-read format, all data was punched onto fresh cards and spit out into a bin. Operations were configured using a plug board. These were big grids of holes that jumper cables were slotted into. Different sections of the board corresponded to things like inputs, outputs, registers, and operations. By wiring up a plug board, you were, in effect, connecting up different parts of the machine. A savvy operator was able to control the flow of data as cards flew in and were pushed out of the machine. You were programming, save for the whole conditional execution thing. Unit record equipment didn't really do conditional execution, but that's kind of the only thing

they're missing to be a full-on computer. The 601 was special among IBM's catalog because, unlike many other machines, it could multiply. It could also add and subtract, making it a true triple threat. The 601s stationed at Los Alamos were even outfitted with a division unit, so we're dealing with some really high-octane stuff here. At least, for 1943-1944. stuff here, at least for 1943-1944. Frankl seems to have really just enjoyed working with the punch card equipment. This was probably because it fit his whole assembly line mindset. It's much more efficient to chain together operations if every step is automated, after all. However, this posting wouldn't exactly work out for him. In this section, I've been going off a biography of Frankl posted on hp9825.com.

As the new tabulation equipment was coming in, Frankl and one of his colleagues, Eldred Nelson, were put in charge of managing the new systems. This involved training and supervising army folk that actually operated the machines day to day. Apparently, this didn't go well for Frankel. From the HP 9825 article, He reportedly had a temper and verbally abused the soldiers, who were working for Peanuts and didn't have a clue as to why they were running calculations. Frankel also doesn't appear to have worked well under pressure and the tension inevitably

rose as the first atomic test loomed. In addition, Frankel essentially became enraptured with the IBM tabulation equipment. He ignored his supervisory duties, which he didn't execute well anyway, and focused all of his energy on the wonderful technical abilities of the IBM tabulating machines. End quote. I think we can see a budding young programmer here, both the good parts and the bad parts. He's not good at handling people, certainly not management material, he doesn't want to be in a high-pressure position. He just wants to be left alone with his precious IBM hardware. If Frankel had been born a decade later, the image would be complete with a terminal and some actual software.

Now, of course, having someone like this in charge of underlings, that's a recipe for disaster. Apparently, the management of the theoretical division agreed. Frankel was kicked off the team and replaced with, and get this, Richard Feynman. That's THE Richard Feynman. Future Nobel laureate Richard Feynman. This was a high-octane lab in more ways than one. But Frankl didn't get totally kicked to the curb. He was, instead, shuffled around. Frankl moved over to the F Division of the Manhattan Project. And, just to throw out some other huge names in physics, the F Division was ran by Enrico Fermi. That's the man who created the first nuclear reactor.

Frankl's direct supervisor was Edward Teller, the man who would be credited with the creation of the hydrogen bomb. It was this work with Teller that would actually put Frankl in contact with a real, honest-to-goodness computer, conditional execution and all. The hydrogen bomb works on the principle of fusion. That's the same process that powers the sun. Inside a hydrogen bomb, or a star for that matter, hydrogen atoms are smashed together under high pressure and high temperature. If the conditions are just right, then you can force two hydrogen atoms to fuse,

creating a helium atom and a burst of energy. That energy, in turn, can contribute to other fusion events. In a star, there are forces that moderate this reaction, leading to a sustained long-term release of energy over a long period of time. In a bomb, however, there's no moderation. A huge rate of fusion is achieved, resulting in destruction of anything nearby. At least, that was kind of the theory in 1945. A big issue with the theory was the mathematics involved. It turns out that fusion is a good deal more complex than fission. The atomic bomb, powered by nuclear fission of uranium or plutonium, had already pushed the limits of number crunching.

The bomb that Teller was designing, called the Super in this period, would use a fission bomb as a primer. That would initiate the fusion reaction. So, the starting point for the new bomb was the ending point for the last one. I think that should give us an idea of how truly complex things were getting. The new fusion bomb needed more calculating power than a room full of desktop calculators. It needed more than a pile of IBM unit record equipment. Luckily, there was an employee at Los Alamos who had an important connection. Good old Johnny Von Neumann, it turns out, was also working with Edward Teller. In 1944, Von Neumann had met another researcher who was working at this little lab in Philadelphia. That researcher, Goldstein, was involved with this big machine called ENIAC.

That machine had promise, perhaps more than a pile of tabulators. In short order, Frankel and his colleague, a man named Nick Metropolis, were off to the University of Pennsylvania to see this new automatic computer thing. Like with the multiplying punch, Frankel became enamored with this computer. A contributing factor could have been the fact that ENIAC wasn't programmed with code. Rather, it was programmed via punch cables. The entire configuration process is remarkably similar to unit record equipment. You work up your equations, write out how to wire up different components of the machine, then you hop into the computer room with an armload of cables. Over the course of a few site

visits, Frankel learned to program ENIAC. This put him among the first dozen or so programmers in the world. You had the original group of six programmers that were already using ENIAC. Probably Eckert and Mautley who designed the thing, plus Aiken and Hopper over at Harvard and a few more far-afield researchers. Frankel, like all before him, would fall in love with the computer. He and Metropolis developed a program on ENIAC that simulated nuclear fusion. Of course, it was kind of a simple simulation. We aren't up to actually useful computers yet, mind you. That said, this was the first practical program ran on ENIAC. It was also the first time a computer was used to do a type of mathematics that humans can't.

You see, Frankel and Metropolis adapted this thing called the Monte Carlo method. It's a discrete step-by-step simulation that uses probability to approximate solutions to equations. that uses probability to approximate solutions to equations. It's so repetitive and time-intensive that it wasn't a usable method for humans. But to ENIAC, well, that was a different story. The machine was really happy to just crunch away. This is something that I'm planning to do an episode on, and probably pretty soon. Like I mentioned earlier, I have a request in with the Smithsonian right now to get scans of an oral history interview with Stan

Frankel. Once those arrive, I'm totally gonna drop everything and do a Monte Carlo method episode. Gotta get the scoop, you know? This first Monte Carlo program was successful enough that it proved a fusion bomb was possible. This was a huge boon for the superproject. From here, Frankel enters the final days of his federal career. He would make site visits to a number of other computers and learn to program some of the first stored program computers. That is, he actually learns to read and write machine language code. But things broke bad a few years after the war. In 1949, Frankl's security clearance was revoked. Why? Well, it's an obvious thing, really. Anyone could have guessed this. His father had, at one point, been a communist. That simply cannot

be allowed to stand. Thus, Frankl was left in actually a very unique position. At that point, there were only a small number of people in the world who had any experience with computers. Most of them were tied up in secret research projects or universities. Frankl was now a free agent. He had knowledge and experience that very few could match. As the 1950s began, Frankl would make his first decisive steps towards creating his very own machine. This is a great spot to highlight the somewhat fraught relationship the US government had with early computer research. Tax dollars funded many advances, that much is very true. Massive works like the Manhattan Project helped to justify new

advancements in digital technology. But at the same time, federal meddling destroyed nearly as much as it created. When Franco's security clearance was revoked, he was, for all intents and purposes, thrown to the curb. Without clearance, he could not work at Los Alamos, so he lost his job. He lost access to machines, software, the whole nine yards. He was out of the system. John Mauchly, one of the creators of ENIAC, was also a target of the Red Scare. That's a very long story. The short version, though, is that Mouchley and Eckert started a private sector company called EMCC, the Eckert-Mouchley Computer Company. Their only means of survival was to get government contracts,

which required a certain level of security clearance. According to certain powers in DC, this new computer company hired communists and communist sympathizers. The FBI suspected that Mouchley himself was compromised. The only recourse possible was to destroy EMCC. The company was stripped of clearance, which meant it couldn't complete its existing contracts or court new ones. Mouchley was even barred from entering the company's office. While not the only reason for failure, the results of this FBI-coordinated assault did contribute to the demise of EMCC. I recount this story to highlight just how disruptive this period was. Elements within the US government were willing to ruin people's lives for

actually no meaningful gain at all. Losing security clearance wasn't just a small inconvenience, it was a backdoor way to push someone out of their job. So without clearance, and without a job, Frankel and others were left to wander. For Frankel, this actually would open up new possibilities, though. In 1949, Frankel started a new job at Caltech's engineering division. He was to head up a new computing technology group. When you get down to it, I think Frankel was probably one of the most experienced people

for the job. It didn't hurt that he was very suddenly and very abruptly available, either. Now, from what I can tell, this wasn't really a teaching position. This was more of a research type of job. This is something that can be a little confusing when you first encounter it. When you read that so-and-so gets a gig at a university, it's easy to just make the educational assumption. But I don't think that would ever work for Frankel. Remember, he didn't really treat tabulator operators well, after all. He was much more of a scientist than an educator, let's just leave it at that. Many big brand-name colleges have research outfits attached to them.

Think the AI lab at MIT, or the AI lab at Stanford, or probably a few other AI labs around. There may be grad students and professors in those labs, but there are also dedicated researchers. Sometimes those researchers even take on grad students, as Frankl would do from time to time, but it's more of a mentorship than an actual professorship. It was at Caltech that we reach the next turning point in the story. During this period, the early 1940s, Frankel was doing a mix of consulting and research. This position gave him a very unique view on the world of computing. He had continued making visits and working with other computers around the country.

He had seen a primordial SIAC at the National Bureau of Standards, Whirlwind at MIT, at the National Bureau of Standards, Whirlwind at MIT, and continued to communicate with Mautley as ENIAC was designed. Not only did Frankl have the deep understanding of machines that any good researcher should, he also had a very wide view of developments. Frankl would toy with the idea of his own computer for a number of years. By the middle of the 50s, those ideas became more concrete. He had a target, and it was simple. No, really, that was his target. Frankel decided he would create the most minimal computer possible, and he'd call it Minak. Now, this is the place where the paper trail runs thin. The HP 9825 article has some fun details on how Frankl got his hands on some diodes and a magnetic drum, but that's all set dressing to me.

We're missing the why part of this pivot. This is one of those spots where it's easy to create anachronisms. I mean, of course Frankl would want to make a simplified computer. He must have known that cheap computers would cause a domino effect that leads directly to the IBM PC, then to the modern world. A computer on every desk, a floppy disk in every pocket. The thing is, we don't know what he was thinking. The thing is, we don't know what he was thinking.

It could have been that a colleague at Caltech just suggested making a simple computer as a challenge. It could have been that he did believe in some form of proto-personal computing. Or maybe he just thought, hey, there's a market there, I could make some cash. We just don't know, and Frankl's publications are a little low on commentary. What we do know is that this idea had some real bones to it. Frankel would produce a prototype in 1954, along with a full design for the machine. The design was then licensed by this company called Libroscope. They were a defense contractor type outfit, a manufacturer of big electromechanic things. Libroscope rebranded the MINAC as the Libroscope General Purpose 30. Now, there is a small maze here. Frankel was working for Caltech at the time,

so technically Caltech owned the designs for Minac. Thus, Librascope actually licensed the designs from Caltech. Librascope also paid for consulting services from Frankel to get the LGP30 off the ground. To further complicate matters, the Royal Typewriter Company was contracted to sell and support the LG P30. This is why you'll see some places claim that Libroscope hired Frankel to design the computer, or that Libroscope bought the designs from Caltech. In the story of Mel, our main character actually works at Royal and writes software for the LGP30. We can find later documents showing that Mel also worked for Libroscope for a period. It's all a bit of a mess to think about. I suggest we just don't. That's the corporate history out of the way, so let's get to the good stuff,

the computer itself. Here, I'm working off of Frankel's first description in MINAC, the logical design of a simple general-purpose computer, as well as some manuals that later shipped with the LGP30. Now, in general, we can do this since the LGP30 and the MINAC are nearly the same. There are some small tweaks that were made on the path from prototype to production, but we're going to be really avoiding the whole spot the differences game. The platform itself is already wacky enough. I'm going to start with the LGP30's memory, since that's the center of everything. John Henry drove steel, but our hero Mel, he drove the magnetic drum. This is a strange and really a kind of horrifying device. It's a type of very early computer memory,

one that not everyone was comfortable with. Allow me to preface this with some context. Back in the day, memory was the most difficult part of a computer. I mean that in every sense of the word. It was hard to design, hard to manufacture, it was expensive, and it was hard to work with. Some early computers used vacuum tubes for memory, or at least for small amounts of memory. That worked, but it was expensive and very finicky. Vacuum tubes use quite a bit of power. They also get so hot that active cooling is required,

which adds an operating expense. Tubes also like to burn out. Plus, you actually end up needing more than one tube for each bit of storage. This is just a bad way to do things. There were also mercury delay lines, which I've covered extensively. This was, for all intents and purposes, a very dangerous type of magic. It worked by bouncing sound waves down hot tubes full of mercury. Those waves were generated and received by polished and faceted

crystals. It worked, in the strictest sense of the word, but it was literal hot garbage. This was sequential memory, so you had to wait around for your data to come to you. You couldn't just ask for some addresses and immediately get the value stored there. You had to wait for the right wavefront to come along. It's also, theoretically, kind of dangerous to work near a tube of hot, sloshing mercury. But then again, there's no reports of people getting heavy metal poisoning or having cancer that worked with these machines, at least none that point directly to the mercury tubes. That said, I kind of think that maybe that did hurt some people. I don't know. That's pure speculation and fear-mongering. Now, the other type of memory that was used in this early period was drum memory. This was a somewhat common solution,

at least for a number of years. It was used by IBM in some of their earliest computers. A drum device had been hooked up to ENIAC after the war, and UNIVAC even used a drum. Add to that a smattering of other research machines. Frankl had, in some capacity, seen all of these. Once again, he was a very experienced computer nerd. Drum memory is less magic and more, really, brute force. You start with a big cylinder, a drum, that gets spun at some constant speed. That drum is a little special. It has a magnetizable coating, something like the ferric oxides used in audio tapes. The reading and writing is handled by a set of magnetic pickups. These are very similar to the heads used in cassette recorders.

You can pass a current through a head to write to the magnetic surface below it. And conversely, if there is some change in magnetization on the surface below the head, well, the head turns that into an electric current. Let's pick this apart by looking at just one head. Each head is responsible for one track, one ring around the drum. If we're just reading, then things are simple. As the drum spins, the head picks up the magnetization pattern on its track. In reality, this will be some sort of wiggly thing, since magnetization doesn't like to stay exactly in nice little squares. In practice, however, this looks like ones and zeros.

That's because the head is tied into a clock that tells it when to output a value. Think of this like a shutter. Every tick of the clock, the computer grabs whatever value the head sees and calls that a bit. Each of those slices, each discrete bit on a track, is called a sector. Here's a tricky part to the whole operation. You have to time everything out. Each track on the LGP30's drum has 64 sectors, and each tick of the computer's clock reads one sector. In other words, it takes 64 ticks to read every bit on a track. That works out to just under 17 milliseconds. In practice,

you do end up accessing the computer's memory in terms of addresses, but sometimes you have to wait a while to get anything back. That's one head, so let's expand down the drum. The LG P30 used 64 tracks, each with their own magnetic head. Words, or the natural unit of operation the computer was geared to work with, were stored across tracks. That just means that when the LG P30 read out a number from memory, it was actually reading from multiple heads at the same time. Just imagine actual data as being stored in these stripes that run down the drum. Now, there is an added layer of complication. The LGP used 31-bit words. Once again, a word is just the size of numbers that the machine wants to work with. Each sector, each stripe down the drum, actually holds two words plus two extra bits.

Those extras are just never used. They're kind of around. There's some conflicting information as to why this is. I've seen that it's to prevent magnetic bleed over or just to allow some type of relaxation in the coding, but I think the jury's out on this one. It's just kind of how the computer is. There are also a few special tracks on the drum for registers. This is where some eyebrows should be raised. Registers are the working space of a processor. These are tiny chunks of storage, usually just a single word each, that are used for active work. When you want to do mathematics, you load up some register and start crunching numbers. In traditional computers, each register is wired directly up to the machine's mathematics circuits.

This means that you kind of have to use registers. Registers are also, in general, faster to access than the rest of memory. At least, that's kind of what you want. In the modern day, we have registers etched directly onto microprocessors. Chip designers just reserve a little chunk of their processor for registers. Quick and nearby registers give a computer all kinds of benefits. Namely, it's just playing faster. That said, this seems to have been a more modern trend. Older computers don't really do fancy registers. The Univac 1,

a computer that Frankel would have been very familiar with, used mercury delay lines for its registers. That's a very slow type of storage. The LG P30 stored registers on its drum. Each register was allocated its own track. This is a little different than how normal memory was configured. Instead of reading down stripes, a register was read on one head as the drum turned, so it would take a full rotation to access all the bits of a register. This is, of course, garbage. It's a little janky. Machines these days simply don't work that way. We tend to keep memory and registers separated, except in certain special cases. But while the LGB30's registers sound weird today, they were perfectly normal for the period.

The IBM 658, roughly contemporary computer, did the same trick. It kept registers on the same spinning drum that it used for memory. But Frankel isn't just doing this to fit in with the crowd. There are benefits to this arrangement. Mostly, it's cheap and very simple. Adding registers to the drum just took a little space and a single head per register. That beats out vacuum tubes or delay lines any day. You don't need a whole lot of accuracy to make these drums either. As long as it's a cylinder and it's coded evenly, you're really good to go, so add as many registers as you want.

As far as simplicity goes, well, you might not believe me at first. Maybe the spinning drum has you a little concerned. Well, dear listener, I can help you out. You see, the drum really is the center of the entire computer. Thus, Mel's ability to drive that drum made him a true hero. So far, we've only looked at the data parts of the drum, but it's actually hiding one more trick up its sleeve, or rather, under its ferrite coating. The drum was also used to generate timing signals. This is, as far as I'm concerned, the coolest part of this entire machine. So, let me back up here.

All digital computers, even very early machines, rely on a clock signal. These machines are digital in the sense that they operate on discrete numbers, and also digital in the sense that they operate on discrete numbers, and also digital in the sense that they operate in discrete steps. One operation has to come after another, so you need some sort of beat for the machine to follow. The usual way to do this is with a clock circuit. These can be constructed from crystal oscillators, inductors, or anything else that puts out a constant beat. You really just need something that fires off an electrical pulse at regular intervals. One of the difficulties with any delay memory comes down to timing.

The clock used in the computer has to be kept in step with the propagation speed of data in memory. The same goes for drum memory. You need a clock that's in step with the drum, and the drum needs to rotate in some amount of time that's evenly divisible by your clock rate. The LGP-30 deals with this fine-tuning problem by simply not having a clock circuit. No crystals, no oscillators, nothing. Instead, the drum makes its own beat. This is done very simply. There are a few tracks on the end of the drum that are permanently magnetized. These are baked in when the drum is made. Each of these timing tracks has a reed head paired up with it. The clock track is the most simple one to explain. It's just a pattern of magnetic stripes.

As the drum spins, the clock head reads these pulses, which result in a uniform clock signal. As long as the drum is spinning at the same speed, you end up with the same clock rate. But if the drum's a little slow or a little fast, that doesn't really matter. The entire computer works off this clock signal, which is just dictated by the speed of the drum. So you don't really run into sync issues. You could, in theory, use any motor to run the drum. It doesn't even have to spin that evenly.

So once again, the drum makes things easier and cheaper. The rest of the design stems from this very philosophy. We're talking about the MINAC, after all. The most minimal possible computer. Everything needs to be simple, cheap, and minimal. This, of course, extends to the processing parts of the machine as well. The LG P30 is a bit serial computer. For some of you, that might be raising what eyebrows you have left to raise. When you get down to the very lowest level of a computer, everything operates around the bit,

those pesky ones and zeros. Take the humble add operation. That's physically implemented as some type of circuit that can do binary addition. It adds one bit to another to give you a resulting bit. The usual circuit is bit parallel. This type of circuit will take two binary numbers that are each multiple digits long and add each bit at the same time, handling the carries as needed. Sometimes that just means a fancy circuit, sometimes it means two steps, but in general these parallel circuits are nice because they operate quickly. It takes one operation to add two numbers, regardless of how long those numbers are. The circuit will munch any numbers that fit into it. While bit parallel is great, it requires some set dressing

to be effective. These circuits are only efficient if you have some way to feed in entire numbers. You want to have all bits of your inputs ready to roll. To do that, you end up needing memory that can send over lots of bits at once. You need registers that can operate on multiple bits at once. If any part of that tooling can't keep up, well, then you can't reap the benefits of your cool bit-parallel math circuits. There's also the fact that these are just complicated circuits, at least they're repetitive circuits. If you have an 8-bit adding circuit, for instance, that's really 8 1-bit adders that are just

chained together. In the case of MINac, the bit parallel thing wouldn't really work. It's not just that memory operates in a very non-parallel way, you also have to consider the registers. When running an operation like addition, you usually fill up an accumulator with one value, put another value in a register or in a nice spot in memory, then you tell the computer to add to the accumulator. There's a few underlying steps during that process. The values are transferred into the machine's arithmetic circuits, addition is done,

the results are transferred back into the accumulator. Normally, that's done in bit parallel, but the LGP-30 just can't do any of that. I think reads and writes off specific addresses on the drum are the only parallel part of the machine. But everything else, it's all serial. The accumulator, the register in the machine, is serial. Since it's on a track on the drum, you only get one bit at a time. So it doesn't make any sense to bother with bit parallel circuits,

since you'd just be hamstrung by serial registers. Instead, Frankel opted to make the whole machine serial. This means that when operations are carried out, it's done one bit at a time. The adding circuit, for instance, is just a single one-bit adder. The LGP30 only needs one of those circuits. Addition is carried out one bit after another, with results saved one bit after another. On most other machines, that'd be a big problem, but for MINAC, it doesn't really matter. This serial type of operation actually complements the machine's beautiful drum. The drum provides the clock signal, the steady beat that drives the computer forward.

That beat syncs up the read heads on the drum. It also syncs up operation steps with the computer's other circuits. It also syncs up operation steps with the computer's other circuits. So just as a bit is coming out of a register, the computer is ready to operate on that bit. It all fits together in a very satisfying manner. This bit serial design also simplifies the whole machine. If the LGP30 was a bit parallel machine, it would need 31 binary adding circuits to deal with its 31-bit words. As a serial machine, it needs one. The same is true for every other operation. This is all in service of creating a cheap, simple, and reasonable machine. We can even see this in the physical implementation of these simplified circuits.

The LG P30 uses only 113 vacuum tubes. That goes a long way towards making a small and cheap computer that doesn't need a lot of power. Compare that to the IBM 650's nearly 2,000 tubes. Or the Univac's 6,000 tubes, or the UNIVAC's 6,000 tubes. And sure, the LGP-30 is a little underpowered in comparison to its contemporaries, but we're looking at an order of magnitude here. So, if the LGP used so few tubes, how did it, you know, compute? Frankl made judicious use of diodes to get the job done. In total, the MINEC has 1,350 diodes inside its chassis. Almost all computation is done using this diode-based logic. As with most things about this computer, this is a little weird, but it's not illegal.

Computers are built up from these things called logic gates. There's a whole set of gates that can be used here, but the core complement comes down to three. And, or, and not. You can build up more complex logic using just those three gates. With that, you can make your precious adding circuits or anything else your digital heart desires. Two of these three gates can be implemented using diodes alone. And is easy, as is or. Diode circuits can't do negation. You can't make a not gate using diodes alone. That's where vacuum tubes step in.

You don't really need a lot of knots, but you need at least a few. This means that if you're willing to get down and dirty, you can actually create a computer with very few vacuum tubes. Frankel, once again, pulls a couple cool tricks to get away with this diode logic. It all comes down to the drum, as always. The drum is wired up to vacuum tube circuits that temporarily store the value the

heads are reading. There's a pair of these tube circuits. One presents the raw value, while the other presents its inverse. So if one bus is showing 101, then the other will be showing 010. The difference is a logical NOT operation. So for operations that are missing a NOT, the LGP30 can just grab that value off the NOT bus. For everything else, there's a normal bus to connect to. The net result is this beautiful and cheap diode logic. Now, is this setup totally unique? Once again, is the LG P30 doing something totally new? Simply put, no. SIAC, a machine that Frankel at least saw on a trip to the National Bureau of Standards, was another diode-based beast. No one feature of the LG P30 is particularly new. It's just that Frankel is putting everything together in a really savvy way. This combination

of tricks, smart use of technology, and cost reduction leads to the MINAC, the most minimal possible computer for the time. What we get is one of the first computers that can be operated by a single person. It could even be set up by a single person, as long as you had a hand truck or something similar. The entire computer was fit into a desk-sized box, and it weighed only 700 pounds. That may sound like a lot, but considering that other machines were weighed in tons in this period, and, well, 700 pounds isn't that bad. You can buy an LG P30, have it delivered, then install it yourself. Just wheel it into your lab or office, drop it down where you want it, and plug it in. The machine even ran off a normal 120-volt wall socket. No special cooling needed,

no special floor vents, not even a technician. Years later, during the home computer boom, we run into similar machines. Now, I'm not saying that the LG P30 was a home computer. The thing still cost half a million dollars in today's money. Rather, it's a computer that you can buy, plug in, and just use. The folk were saying that about the Macintosh in 1984. I've seen articles from that period singing the praises of that type of machine, as if it was a totally new approach. Well, sorry to burst your bubble, but Frankel did it first. I want to clear the air before we go any further. I'm not just saying that the LG P30 has personal bona fides for a nice headline. Far from it. This isn't just a machine that happened to be small

and cheap enough to look personal. It goes a lot deeper than that. Let me start with the interface. You see, the LG P30 didn't use punch cards. That's already a huge deviation from established norms. The IBM 650, for instance, was kind of just a punch card muncher. A good one-third of the machine was dedicated to handling punch card I.O. And while punch cards are cool in an abstract sort of way, they aren't really great for human-computer interfaces. Punch cards are pretty hostile to human comprehension. Practitioners may have been able to read the pattern of holes by eye alone, but that takes skill and training. You aren't going to walk out of the math department and start shucking cards unaided.

The good ol' Minak was built different. Its primary interface device was a flexo-rider. built different. Its primary interface device was a flexo-rider. In fact, it was so central to the machine that it was built into the very chassis. This is a device that, externally, is the same as a teletype. These were well-established devices being used in telegraphy since way back and even making appearances in some computer rooms. The flexo part of the flexo writer meant that it could be used as more than just a teletype. It could be used offline as a typewriter, connected directly to a computer for serial communication, used to punch paper tape, or to read paper tape into a computer. I think it could even actually take paper tape in and print it out

on a sheet of paper. So these are truly flexible little beasts. The really relevant part here is that the FlexoWriter could be used as a text-based terminal. A person could type into the terminal, the terminal would send data off to the LGP30, and the computer would respond on the same paper feed. This is how some of the earliest interfaces work, the earliest interactive interfaces, that is. And we see it in the LG P30 as early as 1956. So how was the FlexoWriter used in practice? This is a really important question because, well, it has a lot of bearing on how the LG P30 fits into the larger story of personal computing. The bottom line is that the FlexoWriter wasn't as interactive as later terminals. Take programming as an example.

You don't sit down at the keyboard and tell the LGP32 to run a text editor. It's a bit of a more involved process. First, you write out your program in offline mode. This means that the FlexoWriter isn't sending any data to the computer as you type. Instead, it produces a punched paper tape of your source code. Then, you get to turn on the LG-30 and bootstrap the machine. Once it's up and running, you load up a compiler or assembler. Then you pass in your code tape.

That gets processed, then the computer spits out a binary tape that contains your final program. To run that program, you take this output tape and feed it into the FlexoWriter's input. You have to flip a few switches, but after a while, your program starts running. Your program itself could be more interactive, but the actual process of using the computer was still clunky. It's not yet an automatic affair. The FlexoWriter, in this case, is just a clever way to squeeze more usefulness out of paper tape. It's workable, but not the most fancy thing in the world. If that's the interface,

then what were people programming in on this machine? What were people actually using on launch day? Well, we know that Mel used machine code, the native language of the computer itself. That has a lot of connotations to it. The story of Mel says that he wrote in raw, hexadecimal, unaided, and unadorned. In the modern day, that's a seemingly impossible feat. But we aren't talking about the modern day. I don't want to besmirch the memory of Mel, but the LGP-30's machine code was something special. You see, the 30 used a mnemonic type of code.

On the lowest level, you communicate with a computer by passing it a series of operations. The computer doesn't speak a fancy language normally, it just wants numbers. So each operation is represented by an operation code, or an opcode. These are numbers. Instead of saying add, you tell the computer to execute opcode 57, or something along those lines. The opcode is followed by arguments, which are also numeric. With bigger machines, this leads to a lot of complexity. You have to have a way to specify everything numerically. You need some kind of grammar for telling the machine where to get arguments from, where to send numbers, and all manner of little modifications to operations.

where to send numbers and all manner of little modifications to operations. The LGP30 simplifies all of this by, well, you should know the punchline by now, just being simple. Operations are numeric, at least to the machine, but you can choose any numbers you want for opcodes. So Frankel chose some nice numbers. Okay, so here's the deal. The FlexoWriter is able to convert between numbers and letters. This is called character encoding. When you press an A key, the FlexoWriter doesn't actually send an A. It actually sends over the number 57. That's what the computer gets. When the FlexoWriter is sent a 57, it knows that it needs to type out an A. Knowing that, Frankel pulled another one of his patented cool tricks. He chose

all his opcode numbers to overlap with these character codes. The opcode for addition, for example, is 57. That gets printed, or typed rather, as an A. A for addition. I can't help but think this was partly inspired by his relationship with John Mouchley. The Univac-1, a machine that Mouchley helped design, pulled a similar trick. That machine used these mnemonic opcodes just because it made the machine easier to program. You don't have to remember that 57 means add, just A is for add. That's so much easier. That's one trick that ends up making the LGP30 easier to program and, just maybe, make smell less of a masochist. The second is the operand

part of the machine code. I'm kind of reveling in this because, well, I don't get to dive into machine code very much on the show. Usually this is a very complex, navel-gazing type of subject. So humor me a little longer. So the operand part. After each opcode is an operand, an argument, that operand can only mean one thing on the LGP-30. An address on the drum. A pointer, in other words. That makes the entire machine code very easy to remember. Let me just spit something off the dome for you. A1000 tells the LGP30 to take the number stored at memory address 1000 and add it to the accumulator register. That's the only place you can add a number to, which is restrictive, but also makes everything really easy to deal with. Subtraction is handled the same way. S1000 would subtract the number stored at location 1000 from the

accumulator. It's a little more complex for some operations, but only a little. U, the unconditional jump, jumps your program to the given address. So U1000 tells the computer to start executing the code stored at address 1000. And just like that, U2 can actually program like MEL. Or, at least, you can start. There are only 16 instructions. Each has a mnemonic name. Some are awkward. Z means stop, but come on, it's 16 letters to remember. This also has a knock-on effect on the entire tooling used with

the LGP30. You don't really need an assembler, at least not in the classical sense. Normally, an assembler simply lets you write out machine code using nice little mnemonics, like the word ADD instead of 57. But you don't need an assembler to do that for the LGP-30. The machine code is already its own mnemonic. These mnemonic machine languages represent a really interesting transitionary period where programmers were trying to find better ways to work, but full languages didn't really exist, not quite yet. The LGP30 was first sold in 1956, with the design predating that by at least one year. Fortran, the first real programming language to see any widespread use, is released to IBM customers in 1957. Early drafts of the language were circulated in late 56.

You could, if you wanted to stretch things, even look at this as an approach to language design. High-level languages like Fortran exist for a number of reasons. They're programmer-friendly, fewer lines of code can do more things, and they pull the programmer away from the computer and more into the realm of problem-solving. The LGP30's mnemonic assembly language hits one of these features. It's a little more friendly than raw hexadecimal. But it's still assembly, it's still verbose, and it's still tied into the lower level of the machine. It just so happens that this machine is pretty easy to understand. Well, at least on a basic level. on a basic level.

Alright, thus ends our coverage of the LG P30, aka the Minak. Now, I will say, this isn't a full conclusion. I still have that duplication request out with the Smithsonian. As of record time, the request has been accepted and paid for, thanks to Patreon funds, and hopefully the scans will fall into my inbox soon. Once that happens, I'm going to be preparing an episode to supplement this one. I'm hoping to fill in some gaps and cover the Monte Carlo method in depth. As for the LGP-30, well, I think it's fair to call it a very unique machine.

In this one little computer, Frankel combined some of the most interesting ideas in the field at the time. The result is, well, the minimal computer for the late 50s. Compared to its contemporaries, it's small, cheap, and really easy to use. We don't have a lot of Frankel's personal writings, not yet, but I think if we read into the 30s design a little bit, we can find something stunning. There's this larger pattern of lazy personalization. Choosing opcodes that look like letters doesn't cost you anything extra. You already have to pick out numbers, so why not pick out nice ones?

Attaching a FlexoWriter does cost a little more, but a computer user will end up needing something like a FlexoWriter anyway, so why not throw it in? The diode-heavy logic follows the same pattern, as does the drum, as does bit serial. No one of these features was groundbreaking or particularly hard to implement. But put together, you get a remarkably cheap and approachable computer for the period. You get something that's right on the edge of personal computing. Thanks for listening to Advent of Computing. I'll be back in two weeks' time with another piece of computing's past. And hey, if you like the show, there are now a few ways you can support it. If you know someone

else who would like the show, then why not take a minute to share it with them? You can rate and review on Apple Podcasts and Spotify now. And if you want to be a super fan, then you can support the show directly through Advent of Computing merch or signing up as a patron on Patreon. the show directly through Advent of Computing merch or signing up as a patron on Patreon. Patrons get early access to most episodes, polls for the direction of the show, and bonus episodes. You can find links to everything on my website, adventofcomputing.com. If you have any comments or suggestions for a future episode, then go ahead and shoot me a tweet. I'm at Advent of Comp on Twitter. And as always, have a great rest of your day.