Advent of Computing - Episode 164 - LGP-30 LIVE! from VCF West

Episode Date: September 7, 2025

Last weekend I had the chance to talk about the LGP-30 and my emulation project at VCF West in Mountain View, CA. The showrunners will be posting a full video later, but that takes a while to go live. In the meantime, here's the audio I siphoned off the sound board and my slide deck. View my slides here: https://drive.google.com/file/d/1E9-B3EzxudFWX0yJMevbbIkD2qRbBKWi/view?usp=sharing View the emulator at: https://lgp30.org

Welcome back to a, well, a very strange episode of advent of computing. I'm your host, Sean Hasse, and I need to apologize a little bit. This is not the LSI 11 episode. That's because I'm horror of horrors, bad at planning and bad at time management. So, a line when you set the stage and explain why we're here. A week ago, I got married. I know. Thank you. Congratulations are in order, in fact.

Now, I thought I would have plenty of time to prepare the episode. I'm not recording on the day of my wedding, so after all, I just have to do some research. And I did take the whole week leading up to my wedding off of work because I had to get ready for the wedding. So I figured there'd be some extra time. That wasn't the case. I know. many of you are probably not surprised by that fact. I, in that week, experienced some of the most profound exhaustion I've ever experienced in my life. It was all worth it. The wedding was wonderful, and I'm now married.

But, you see, I didn't finish research for the episode. This was compounded by the fact that, while working on the LSI 11 episode, I realized the research lift is actually going to be a lot heavier than I thought. So, get excited. I've been having to dig kind of deep to get the information I need for the episode. That means the episode is going to be pretty interesting, but it's not coming out for another two weeks. So today, I have a special treat. Luckily, I recorded my talk on the LGP 30 from VCF West in August.

Now, if you're already on the Patreon, I gave you the raw, unedited cut of that talk. Today, you'll be receiving the slightly prettied up audio. It's a great talk. I had a lot of fun giving it, and this is kind of the option to keep the feed going while I'm recuperating. In the talk, I referenced my slide deck a couple of times. If you want to see that, I'll have a link to a PDF copy of my slide presentation in the description of the show. You don't strictly need it. I think I'm just like pointing out some blink and.

lights and pointing to a QR code. So, purely as an audio experience, it will still be enjoyable. And I'll be back in two weeks with the ill-fated LSI 11 episode. Thank you so much for listening, and I hope you enjoy. Are you hitting my audio? Oh, there we go. Now we're starting. Hi, everyone.

Thanks for coming to my talk. My name's Sean Hasse. I'm an independent historian. I think Hackaday has called me a dangerous freelance historian before. I host and produce the Adjunct of Computing Podcast. And today, I'm going to be talking about my favorite computer and some pain to put me through. That is the LGP 30. Now, this is the official name, but the real name is why you should love the LGP 30? Because I love this computer. And I think everyone who's interested in old machines, should too. So to kind of get ahead a little bit, to read ahead in the outline, I wrote an emulator recently. That should lead to some initial questions. Like, why would you do that? And maybe secondarily, what's the emulator for? You know, what's the target system? And then finally,

you know, putting my product hat on, does it do something new? What am I offering that's special here. There's a lot of emulators. So in this talk we're going to kind of be trying to answer these questions and hopefully getting you all excited to write some software yourselves. So first off is, why?

Short answer, emulators are cool, right? I think we can all get behind that. I've always wanted to write an emulator and I've tried quite a few times. I've gotten close to writing Turing completely. I've done simulation stacks for old computer graphics systems, but I've just never really

got there before. Part of that is I just didn't really get the programming techniques, or I didn't have enough time, didn't really apply myself, so I decided I was just going to learn. I was going to take a system, force myself to write the emulation. Now, the secondary question, of course, what system? Well, it's this guy. It's this guy. The LGP 30, a computer from 1954

that I think is of immense historic importance, but is also just a kind of strange machine, which makes emulating it not only a little difficult, but I think an interesting programming challenge. So again, that should lead to the next question. Why would I pick this computer, right? How many people here have heard of the LGP 30? Okay, good.

This is a good crowd. I don't have to tell you why. It's just a neat machine. This is a really cool computer. If you don't believe me, by the end of this talk, you will. That's the goal. It's also, I will argue, the first personal computer. Now, people have said I have wacky opinions about the concept of personal computing.

Again, I hope to prove you wrong, because when you get down to it, the LGP 30 is definitely the first machine that's designed, used as a personal computer. It's also an oddly non-textual machine. So when you're thinking of early machines, it's just text, right? You type in a keyboard, get text out, put in punch cards, get punched out. But the 30 in actual practice has a bizarrely visual component that I think is hard to capture with existing emulator programs.

It's also just an odd architecture. This is a drum-based computer, which makes programming it a headache, but a But it also means that it's a pretty unique system. We don't have computers like the LGP 30 anymore. So it's an interesting enough system that it makes you want to work on it, or at least in my head, it makes me want to try programming it. And then finally, what I've been alluding to the whole time, existing emulators have issues. Now, I have a very specific gripe here.

And that all comes down to documentation. The LGP 30 is a bizarrely well-documented computer. I mean that both culturally and technically. So we have all the expected stuff, right? We have manuals, we have full schematics, we have all this programming information, but we also have things like lesson plans. We have people's accounts and stories of using the LGP 30. We have entire syllabi from classes teaching students how to use the LGP 30.

So we have this great resource culturally that describes how this computer was used step by step in the 1950s. I think that's a great treasure trove to pull from because when we're talking about computer history, I believe it's very experiential. You don't really get a computer unless you've used it. And we have all these documents explaining in context how this was being used. So I think that makes this a really valuable system as like a lens to look into early programming in practice.

And I want to use that documentation. With existing emulators, you kind of can't. So one of the big emulators for the 30 is SimH. They have an LGP30 core, but it's all text-based. You can't press buttons. It doesn't show up with the front panel. You have to type things like press power button, press continue button.

That, to me, kind of breaks the immersiveness that I want from an emulator. I can't sit down with a lesson plan. and go step by step through and program the thing, right? You have to make that conversion to use SIMH. So for me, that's a no-go. That breaks fidelity. The other solution are these FPGA boards,

which these are fabulous. They have full front panels. They have all the physicality that I'd want, but they're not very accessible. You can't buy a completed one. You have to get kits or you have to make your own. So if you don't know how to use a soldering iron or you don't want to spend a few hundred dollars,

you can't really use that as an option for emulation. So that, again, it's kind of a no-go for me. So that's kind of the why I ended up writing an emulator, but there's a bigger why. That's why I love the 30 and why all of you should love the LGP 30. And to explain that, we're going to talk history a little bit. Who doesn't love history, right?

So the LGP 30 is initially designed by this man. named Stan Frankl, and his resume is truly amazing. So he's born the son of a communist, he's a physicist. He actually has a PhD and does his postdoc work under J. Robert Oppenheimer before the start of the Manhattan Project. So when the Manhattan Project starts, he's more of the first people to get pulled over to Los Alamos. When he's there, he's working initially in the calculation division.

So this is the guy doing math, or at least running, or at least running a large part of the division that does math on the Manhattan Project. Now, this introduces him to computers in kind of what I think is an interesting way. So initially, the calculating department is using human calculators. That doesn't work very well because they have a lot of math to do.

It's a lot of linear algebra mainly. So they quickly get upgraded to mechanical adding machines. That also doesn't work out very well. It turns out mechanical computers kind of don't work. These aren't entirely computers. They're mainly just desktop adders. But what happens is they're hitting them so hard that they wear the gears out. So that's not a long-term solution.

Eventually, they're able to get the funding to get an IBM multiplying tabulator. I know. Ooh, that's some fancy stuff. And that results in Stan kind of losing his job. So the story goes that he gets so obsessed with his calculator that he's doing more calculating work for his own enjoyment than actually working on projects for the Manhattan Project. So he gets politely pushed aside from the main project

and pushed onto this kind of second operation working on the fusion bomb. now this is how we reach the next step and the obsession really sets in so he's working on the fusion bomb project with edward teller with fermi with a little bit of john von noyman on the side and he gets exposed to enniac though the long story is Fermi has this method where he kind of does a party trick before the day of an experiment he'll lie in bed and he'll roll some dice in his head and try to figure out, you know, running the odds how an experiment will turn out.

And we'll show up in the morning and say, oh, there's your critical mass. And they'll say, no, Fermi, we can't do the calculations for that. You can't know that. They'll run the experiment, and he'll be right like 90% of the time. And Fermi initially plays it off as a bit of a joke. It's just a way to rile up the coworkers, right? But eventually he starts talking, you know, about the method with John von Neumann and Stan Frankel and as well a man named Nick Metropolis. That leads to, well, INIAC, or at least leads to the first

effective use of INIAC. Stan ends up helping co-develop the Monte Carlo method, as it's now called, on INIAC with Nick Metropolis and von Neumann, and with all the initial programmers on the INIAC project. This is one of the first practical applications of a computer, and our man, Dr. Stan, is involved with it. So that means that coming out in 1945, he is out of the handful of people that know what a computer is, one of the best qualified. He is on the bleeding edge. But there's a problem with his resume that leads to some issues post-war. And he's the son of a communist. Now, a part of computer history that isn't really covered as much as it should be is the horrifying effects of the Red Scare on the development of computing. The Red Scare ends up destroying

EMCC, the first computer company, and it ends up revoking Stan Frankl's clearance, who I will remind you, he's one of the most competent computer people in the world at this point. He's not quite a computer scientist yet because that designation doesn't exist, but he's the closest thing you're going to get. So he gets his security clearance revoked. Too close to the Reds. Can't have that. got to throw out all the good researchers we have. So, as a result, he goes private, kind of. He starts working at the engineering division at Caltech. Now, this isn't a professor position, this is a research position.

And from there, he ends up consulting on really a wild number of computers. If you name a computer in the late 40s, early 50s, there's a good chance that he's either consulted on his design, consulted on programming for it or at least seen the machine and talked with its developers. So again he's the closest thing to a computer scientist by the

end of the 1940s. And that's when he decides to make his own machine. So this gets us to kind of a larger discussion. If you listen to my podcast, you know I like to cover these big arcs in history. And one

of those is this concept of how computers get small. Now, looking at history as a big arc can be dangerous sometimes because we have this superpower of foresight. We're in the future, right? We're not living in the 1950s. We're not immersed in that context.

So when we look at computers today and then look at computers in the past, we think, oh yes, there must be, you know, this big overarching story of how they go from INIAC to my nice little laptop here. And there is, we have ways to describe it. This is a chart you've probably

all seen some variation of. It's Moore's Law, right? Every two years, computers get twice as fast, half the size, half the price, just goes up and up and up. That makes it really easy to, you know, look at the two endpoints and pick out just a straight line. That's not entirely accurate. The actual development, as we get to smaller and more capable computers, is a lot more complicated than that. But, you know, for most conversations, keyword most, this kind of arc works. We can say, oh, yes, well, you know, every few years computers get a little bit better and a little bit better over all these incremental steps we end up with a personal computer, which is, compared to ENIAC, completely unrecognizable. But, you know, we can kind of see the arc,

see how it meanders. But that's not really the truth of the matter. This is where we get into some wrenches. And one of the biggest ones is thrown by our man Stan. So here's the secret truth of how computers got small for the first time. The son of a communist decides computers are too complicated, right? I mean, you've got these mainframe rooms. Nobody needs that. So he starts stealing diodes from Hughes aircraft. You know, it's fine, right? He's a contractor for them at the time. He's helping them build a computer. They, they're paying him already, and they're throwing out all these diodes that are perfectly good. There's no reason he can't just fill his pockets with those. I mean, they're not even using them, right?

He uses that to build a small, personally useful computer in his basement. To those diodes, he also adds some other stolen parts and some gifted equipment. The result is a personal computer in 1954, just in some random contractor's basement. That doesn't really fit on the large arc of, oh yes, every two years computers get incrementally better and closer and closer to these small personal machines. This is why I say that big arc history is a little bit dangerous because it makes it a little hard to deal with these kinds of wrenches. So we're talking about him wanting to build a computer, right?

well, what is his design goal? It's simple. I mean that. His primary design goal is simplicity. He hits upon the fact that not everyone needs a big computer. Not everyone needs a mainframe. Computers are useful universally, but you don't always need the peak of performance.

Instead, some places just need a simple little computer. You just need a little computing power, and that helps with automation, calculation, it just makes everything a little better, makes you more efficient. So his primary design goal is simplicity. He's not going to make a mainframe. He's going to make something that's just a lot smaller. Another design goal that falls out of that is cheapness of cost. So, again, not everyone needs a mainframe. If you only need a little bit of computational power, you're not going to want to spend a lot of money on it. So his design has to be cheap.

He also decides to make it interactive. This, again, is going back to the comparison to mainframes. Mainframes of the era weren't very interactive. If you just need a little bit of power, it'll be a lot more convenient if you could just type right into the thing and get immediate feedback. The result of that is the LGP30. Now, I could just run down the specs, but again, we're out of the context. This isn't 1954.

If I give you a spec sheet, you're not going to just go, oh, yes. Yes, I'll buy one of these today. So I want to make a comparison to a contemporary machine. Enter the IBM 704. This machine's produced in about the same year, and it's a mainframe. There's not a running 704 in the Computer History Museum, but there is a running 1401. That's a much later computer, and it's a pretty different machine,

but the shop layout is really similar. I'd highly recommend if you want to just get a vibe for these mainframe rooms, going down to the 1401 lab and taking a look, because that will immediately give you an idea of the kind of technology we're dealing with. So I just want to highlight a few points here that I think will drive this home. First, and you'll notice this,

the first time you walk in the 1401 lab, mainframes of the era required very customized rooms. They required raised floors. That's because they have very sophisticated power requirements, and they have a whole lot of cords. A mainframe of the period was broken into multiple units. You'd have your central processing unit, and then you'd have things like tape drives, printers,

and other peripherals that you had to have connected to the machine to really do much. So to deal with all that cables, all those, they're very big, they'll make you hold one downstairs. They're like 50 pounds. To deal with all that cabling, you have to have a physically raised floor. The LGP30 had castor wheels. To deal with power requirements,

you could push it a little closer to the wall outlet and then lock the wheels. There's a world of difference there, and this is kind of just the beginning of the comparisons. The 704 used 70 watts of power to operate. That is, a wild amount of power. The LGP 30 used 1.5 kilowatts. That a household can give you that.

This plugged into 120-volt AC with a normal wall plug. The 704 weighs 16 tons just for the computer system. That's not even counting the power supply and cooling setups. You know, the LGP30 has a little caster wheels. It weighs 800 pounds. A single person can push it around. It might put your back into it a little bit, but one person can move that thing.

The 704 and most contemporary mainframes had really stringent cooling requirements. For the 704 specifically, you had to have custom air conditioning setups. The LGP30 has a fan. Like, that's all you need when you're that small. 704s also ran in batch processing mode. So to use the computer, a programmer would prepare a deck of cards ahead of time and go hand it to a clerical worker who would then schedule their program to execute.

That would then be passed on to an operator who would run the machine, run the program, and eventually get the outputs, and then if all went well, the programmer could receive those outputs. You'd never even see the computer. The LGP30 has a keyboard. You're even expected to program on the physical keyboard that's plugged into the computer.

The 704 needed a team of people to support it. Now, traditionally with mainframes, you don't necessarily need multiple people to physically operate the computer, but you have a support staff and a network of people that work around the machine. So you have something closer to a department that would manage the computer for you.

The LGP30 is built for a single person to operate. You can even see in the photo, there's a little nook underneath the keyboard. That's not for show. That's for an office chair to roll under. You're expected to roll up to the keyboard, type away at the desk. On your right-hand side are all the buttons

that control the computer's operation. You have a debug display. On the left-hand side, you have a reader and writer for paper tape. You can physically operate the entire thing from your nice little swivel chair. You could even get a better one than the one it comes with if you wanted. So I hope at this point it's clear that this is a, it's not just an incremental improvement, this is a different type of computer. And I'd argue this is a personal computer.

Stan Frankel designed it to be operated by a single person, and it's built with all of these features that we see in later personal computers. But it's still using 1950s technology, so it's a weird computer. The 30 is a just really strange and fascinating beast when you look at the technicals. So let's do that. Exhibit 1 is the drum. So anyone here ever program a drum-based memory system before? That's right, that's what I...

Oh, you have nice. It's hell, isn't it? I don't know if you wanted to be fast. So how these memory systems work, it's a metal drum with a magnetizable coating. It's really similar to the coating that's on a cassette tape. Then you have magnetic pickups that float just above the drum. The drum spins on the LGP 30.

It's at 4,000 RPM. It says 3,700. Huh, I should change that. Spins at 4,000 RPM, and all the reading is time-based. You have to wait for the drum to roll around to the right position to do read-and-write operations. So that means that operation times are dependent on where the drum is in its rotational cycle. The big implication there is if you have two identical operations next to each other, they will execute in different amounts of time. time. There's also non-volatile, which is just kind of weird to think about. Since it's just a magnetizable coding, you can actually load data on it and leave it there. So you could

load up a bootloader, turn off the machine, and then next Tuesday maybe come in, flip it on. Your bootloader's there already. So it's a, I think in that capacity is very similar to how we use computers today, where we can program in something once and leave it and have it there for later use. But it's just not fun to use. That's kind of the bottom line here. So as I mentioned, the drum is spinning

and the physical location on the drum dictates the address. They're broken into track and sector numbers where a sector is a stripe going down the length of the track, or down length of the drum, excuse me, and a track is a ring going around the drum. There are 64 tracks, 64 sectors, so you go, oh, yes, you know, 4096, right? You get 4K words, addresses are made as a combination of tracks and sectors,

but here's, I took that out. The issue is addresses are concatenations of the track number and sector number, which means that there are some illegal addresses. For instance, 0163 is illegal address. That exists. 0-170 does not exist. So it's almost like having a segmented memory space, which makes especially examining old code kind of strange,

because it takes this assumption on segmentation that isn't really described in the documentation. Exhibit B on why this is a weird machine is diode logic. So in the time period, it was customary to build computers out of vacuum tubes. just because that's what we had for switching that was quick. But it turns out you don't need to use tubes for everything.

Using diode logic, you can implement everything except for inversion. So the result is LGP30 has very few vacuum tubes. It uses 113 vacuum tubes, and they're all for inversion logic. That's backed by 1,400 diodes. Now, this has an interesting knock-on effect. And this is one of the genius cost-cutting measures that Stan came up with. So if you're familiar with vacuum tubes, you might know what that component is. That's a heater.

Vacuum tubes work off the thermionic effect. So they have to be at a certain temperature range to function, and that temperature range is well above room temperature. The issue there is that means your computer is full of tiny heaters. and all components in your computer can break if they're too hot. That's why mainframes of the period had to have sophisticated cooling systems. With LGP30, it has way fewer tubes. That means there's fewer heating elements built into your very expensive computer.

That means there's less waste heat, which has a two-fold effect. One is you don't have to drive the heaters, so you're saving power initially. But the second is you don't need very big cooling. requirements. So you're saving power because you don't have to run an air conditioning unit. So this lets you have a smaller, cheaper computer that's also cheaper in the long run on power utilization. All right, next exhibit, and this is where we get into the visual stuff, is the front panel. This has everything you could ever want, except for text, for operating the computer. You have all your controls for bringing the machine up and down, doing breakpoints, stopping

and starting execution. You have a readout. for diagnostic information, and these light up. All the buttons on the top, well, two of the things on the top are just lights, but all the buttons on the top light up to give you instant feedback. So this is what I meant when I was saying, the computer isn't textual.

It has a visual component to it. Now the scope is actually kind of one of my favorite parts of the machine. It's really your primary view into the machine outside of all the text fields. it shows the machine's whole architecture, it's all the registers that are available. And what's neat is this is also a cost-cutting measure.

Instead of having traditional blinking lights, this is just a normal oscilloscope with an overlay. So the actual traces are square wave values that are just overlaid with this little stencil that shows you what those values mean. Here's just a close-up, it's a diagram of the scope, and you get the three addresses. This is, this plus memory is the entire state of the machine.

You get your counter, which is your instruction pointer. The instruction, which, that's where the instruction is fetched before operation. And then you get the accumulator, which is on the 30 actually your only accessible register that a programmer will ever use. All right, last exhibit is the flexo rider. This is, it's kind of like a teletype. It's kind of like an older teletype. It's, if the scope is your view into the internals, this is your external I.O.

It allows you to type in data to the computer, and it allows a computer to print out data for you to look at. Now, it's not just interactive. This is a direct component, so it's directly wired into the processor. This is a crucial component of the computer. That's very different than having a teletype that you can optionally plug in, and you can have different ones, and you can switch them out. This is a core component. This is part of the design at the beginning.

So much so, there are actually dedicated instructions in the LGP30's instruction set for handling I.O. To and from the Flexo rider. It's also a customized Flexo rider. This is something weird that ASR didn't really do, but that Flexo did. They aren't interchangeable. So you can't just find another flexor writer

and swap it out with the one on an LGP30. This is customized for the character set, but it also has custom switches for sending special signals. So you can see up at the top, there's toggle switches. Those are wired in such a way to send specific signals into the LGP30. The keyboard itself is also customized. So you'll notice some of the keys are beige and some are brown. The beige keys are actually assembly language mnemonics because you're meant to sit down and type assembly language into the machine.

So like the A is the addition mnemonic, just for instance, the T is a transfer, the I is input, the P is print. Again, this is meant for you to program in an interactive environment in front of it in a very personalized way. So, putting this all together, we should find that the LGP30 is, first of all, very cool. I hope we all agree now this is a cool machine, right? Second, it's historically important. This is one of the first small machines that's constructed, and it's such a wild diversion from everything else in the field. I think that more than anything makes us a very historically important machine.

And third of all, it's challenging, right? This is a strange architecture. It's not only a unique computer, but it's just so different from our modern way of programming, our modern practices around using computers. So I decided to hit my head against the wall. I decided to make my emulator because of all of these factors. Hopefully, you understand why now.

My goals in writing the emulator were pretty simple. I wanted to be accessible. So because of that, I chose to target the web and not an FPGA or an executable binary. So actually right now you can go to LGP30.org and it will load up my emulator. Please don't do it on your cell phone. It is not a responsive layout.

It will look like garbage. But you'll get the front panel. This is the front panel for my emulator that's made to match up the front panel on a physical 30. Another goal was to make it visual. Again, good reason to target the web. You get actual buttons you can press. The buttons light up.

You get visual feedback, you get instantaneous feedback. And the final goal, which I'm still working on a little bit, is I wanted this to replicate the experience of an LGP30. I don't just want to run the software and go, oh, very cool. The register sets correct. This memory image is correct to what I know the software should produce. That's not what I want. Instead, I want to replicate that experience.

So I can sit down with a lesson plan and program like I'm in 1954. So to do that, I made a bit of a compromise. When you load up the emulator initially, you get this default view where it does simulate the experience of using a 30. But you can also kick it into a debug view, so we have some actual tooling to use with the computer. Because, again, this is an odd machine that's very difficult to program. Here's another screenshot that's showing the debug view, and this inset is actually the flexo-writer simulator that I have hooked into the computer. In DebugView, you get a follow-along memory map that shows all the addresses in your current program and all the addresses referenced in your program.

You get an assembler that I have built into this, and that's using the same assembly practices that are in the LGP3 manual, which is a little annoying because it's decimal, but all the printout displays are in a weird hexadecimal, but it's what the manual wants. And then you also get numeric representations for all the registers. So you get binary, you get decimal, or I think I have it set to hex right now, and you also get the current instruction and current register transferred into an instruction mnemonic.

So next I want to explain the theory of operation, because remember back way to the beginning, one of the reasons I wanted to write an emulator is because I didn't understand how emulators work. This was hard for me to figure out. I'm sure for a lot of you this will just make sense. You'll go, ah, yes, of course. This took me a good month

or so, so I want to share my struggle. The actual emulator is just a state machine. And I, this was one of those things where I realized, oh, I should just use a state machine.

And I realized that I should have always suspected that's the right way to do it. When you get down to it, all computers are state machines. So if you want to make a computer defined by software, that's kind of the way you want to go. In my case, I went very heavy-handed, object-oriented programming, so it's just a state machine full of classes. The state I'm using is the entire memory contents, the register set, and a few flags that the LGP 30 has internally. That means that you can do things like save and load states like a video game emulator.

The other thing that's really nice about this is each operation is just a state mutator. So how the machine or how the virtual machine functions is it starts with the current state and then it runs a fetch operation that uses the instruction pointer to load that instruction register. Then, excuse me, I have a decode operation that figures out, one, is this an operation? And two, what operation is it? I look up my operation in a table and I operate. Since the operations are just state mutators, I just hand it the current state, they run, and

I get the next state out. Then the emulator can inspect that state, update anything in the UI it needs to, and then apply that and say, next state's this state. This actually made programming this so much simpler than I thought it would be. So yeah, it's pretty nice software. Like I was saying, I really enjoyed working with this image. simulator code, part of the reason for that is there's only 16 operations that the LGP 30 supports. They're called orders on the machine.

And each one, like I was saying, it's a state mutator. It's really simple. The largest one that I have is probably the ad operation, which is 16 lines of code. But some of them like the stop operation, I literally just have to set a single flag and return the state. It's two lines of code and that emulates a whole order on the 30, which again, just super nice. That was something that just fell out of the implementation that I'm pretty pleased with. I also get, you know, not worry about a lot of things with this software.

The target, the LGP 30 is so slow. The slowest operations that can run are 19.5 milliseconds. And modern computers are not slow at all, so I don't have to do any optimization. My code base is big, it's ponderous, and it's pretty easy to read since it's not optimized at all. And it just runs fine in your browser, all the performance targets perfectly on spec. But this nice picture is complicated by the LGP 30s bizarre architecture. There are a lot of things I could say here to explain this, but I'm just going to choose what annoyed me the most. If you want to hear more, catch me outside. I'll tell you.

talk to you for hours. The biggest hurdle was actually instruction packing and addressing. So this is going back to the fact that the 30 has drum memory and that kind of just makes things painful. So allow

me to introduce the instruction format. This is where we're going to be spending the rest of the presentation. Learn it and love it. So the packing's a little weird, but we can see everything we'd expect, right? We have an

order that's a 4-bit number, that's just the op-code, and then we have an address. It's broken up into two, six-bits, but whatever, we can recognize that that's an address. So that's clear enough, right? Op-code address. Fine. But there's some complications. The first is the 30 is technically kind of a 32-bit machine, except bit 31 is ignored. There's nothing on the computer that looks at it. And bit zero is only recognized by the five math orders.

It's used as a sign bit. But for all intents and purposes, it's ignored. There's also kind of that weird spacer between the order and address. I don't know what that's about. Maybe that'll matter later. And then the address format is, again, just kind of cursed because it's two concatenated six-bit numbers, and they're non-contiguous.

They do that segmentation thing I was mentioning. But here is, this is the thing that still kind of baffles me, is that there's wasted bits in the ISA. There are actually 14 wasted bits if you count them. There's that big chunk in front and then that random spacer. Now in context this gets even more strange. At the time, bits were at an extreme premium. If you look at other computers around the era, like the IAS machine, for instance, that has a very wide word, but it packs two instructions into each word because you want to use every single

bit you have in memory. Memory is expensive. So this is wasted real estate. I don't understand why it would be designed this way. And if you look at other computers that use drums, they use that space. They actually use it for an optimization. A machine like the Bendix G15, which has a very similar style drum memory, uses that space for an explicit continue. So each instruction on that machine will say, do this, then unconditional transfer to this address, which on a drum is really good for optimization, and it means you're not wasting space in your ISA. So what's going on? Well, I don't have a concrete answer, but I do have a bit of an explanation, and to do that, let's explain one operation on the LGP30. This is the only one

we're going into, so enjoy it. That's input. Now, Now, inputs, fiddily, this is probably the instruction I spend the most time programming for. How it works is it shifts bits from the flexor rider into the accumulator from the right-hand side to the left. It will do that until it encounters a conditional stop character, which for some reason is rendered as a single quote in the character set. I don't know why, but it makes it so any printout you see of, LGP 30 code is just like number, number, number, single quote, number, number, single quote. It's bizarrely difficult to read, and there are better characters in the character set for it. It was just what Stan chose.

Now, this is almost always followed by a store instruction. The idea being that you would write a loader program that takes input, fills the accumulator, begins operation again, stores that word in memory, and then advances some counters and takes another set of input characters. The idea is that that would be a bootloader. There's actually really small bootloaders for the 30. They're like three words of data. But there's some weird bit math that's going on here.

First of all, as we saw, op codes are four bit. But characters are six bit on the LGP30. That gets a little weirder because by default, the FlexoWriter only sends four bits of data to the machine. It truncates the two least significant bits. So that's kind of weird, but let's apply this to the instruction set. And you won't forgive me. This is a diagram from the manual, and the Kearney is just weird. So those boxes are supposed to be four-bit chunks.

They're a little different in size. But we can see if you break this up into four bits, you get what? 1, 2, 3, 4, 5, 6. You get six nice little chunks. Now, let's say you're running a loader and you're trying to load in this bit pattern. You would type 0-0 to get that big blank that is necessary. Then A for your order. That lines up fine.

Then you type B. You'll notice that that 4-bit chunk doesn't align. very well with your address. The track bits are only picking up the first two bit, or the last two bits of that character. Then you type I, that's fine, that's aligned, and then zero and zero, and at the end you get that same weird alignment. Remember, bit 31 isn't used, but it's still counted when you're shifting in data. The LGP30 would interpret that as, hey, it's an ad instruction, add address 2,000 to the accumulator. But this caused a huge headache for me, one, because the shifting behavior isn't explained very well in the documentation at all. I had to try and error my way through this by looking at archival source code. The other complication, though, is in that archival software. We have a whole lot of software preserved for the LGP30 as tape images, put your text files.

The problem is they're expected to go in through the flexor rider, so there's this weird interpolation step. If you look at a tape image, the actual machine code written on there doesn't make any sense. The op codes are right. You can read those directly, but the addresses, there's that weird bit misalignment. So the addresses get bizarre. You can't just read a tape and understand exactly what it's doing. This is also ambiguous. Remember, six-bit character set, four-bit default input.

So that A-B-I-O-O is also a Q-1-4-O-O, which, again, that makes reading these tapes really annoying because you have to account for that ambiguity, which luckily you can do with some bit-slicing, but still just all these steps that aren't really documented in the original programmers' manuals. So outside of these kinds of complications, how's the code going? Well, it works. It is a fully functioning emulator, for the most part.

It loads tapes, it'll execute simple instructions, and you can actually program test code. The big outstanding issues are it's ugly. I'm not a front-end developer, I'm a back-end guy by trade, so I don't know what CSS is. So the emulator's a little rough around the edges. It's also missing a couple things. I don't have breakpoints implemented, mainly because there's not much example code that uses break points. I also don't have the startup procedure completely simulated.

That's because at this stage, it's kind of annoying. There's supposed to be a 30-second to one-minute warm-up and startup procedure. that allows the small amount of tubes to heat up and the disc, or the drum, excuse me, to spin up to the proper RPMs. That's kind of the next step is for me to program that in, but have it in a way that you can turn it off if you're just trying to go through and debug code.

I also don't have dynamic timing, or dynamic timing, I don't have dynamic timing implemented right now. So this is going back to what I was saying about operations taking a different amount of time dependent on where the drum is in its cycle. I've been, this is what I'm most recently working on implementing, SimH has an implementation of it, but it's written in C with no comments, so I can get it to run, but I'm not entirely sure it's accurate compared to how the 30 was actually running.

And the final piece is I need to build up tutorials. The end goal for me is you'll be able to go to LGP30.org, the emulator logo up and it will have a set of tutorials you can go through so I want to scrape information from these lesson plans and these tutorials from the 50s and use that to make walk-through guides so that way you can sit down and at the click of a button be taught how to use an LGP 30 I think that's really important because that's preserving the experience of programming in the 1950s which unless somehow you have access to one of these machines which I think

there's only one operational you're never going to experience that. And this is something that's just so, so crucial for preserving the experiential part of computer history. So this is where I get to the call for action. Do you know how to program? Please come contribute to my GitHub repository. I need a little bit of help with the front end, and I just love people to contribute. So as I keep saying, if you go to LGP30.org and you can scan the QR code, there's a link on there to the GitHub repository. So please come fork it, come give some PRs, come file some issues, because I really want to make this a bigger project. I love for this to become a community open source project, because this is, I think this is

ground zero for preserving the experience of programming. And if we can just get a little more help, this is a great way to do that. Thank you so much for coming to my talk. And again, go check out the repository. Go run my code. Tell me what's wrong and come fix it. Thank you. Any questions? Yeah. Sean Hasse. Do you want a business card? I can give you a business card.

Yeah. Oh. Anybody wanted to ask questions. Did you actually have an LGP 30 to play with? I wish. So I have a friend David. He runs the tube time. Or not tube time.

He runs Usagi Electric on YouTube. He has an LGP-20. one, which is a cost-reduced 30. He's working on getting it up and running, and I'm going to be stealing some information from that machine once it's going, but right now, this is all based off documentation and SIMH and FPGA code that I've been looking through. I don't think it's running.

There probably is. I think you're right, but not running. Who else? I'd like to know unreasonably detailed things about how the diode logic works in this for a homebrew project. Do you know who to talk to or where to go for that? The University of Stuttgart has a working LGP30, but also if you go to bit savers, they have the full schematics for the computer available. Again, super, super well-preserved documentation around this. You could build one of these if you had enough time.

All right, who else? Answered all your questions, easy. Have you thought about doing it in VR? Ooh, no. Again, not a U-I-U-X guy. All right. Well, thank you so much. Thank you.