 If I was welcome to the Artificial Life Advanced class, good news everybody, things are better. Let's start by taking a look at what's been going on on the T2 Tile grid for the last 10 days or so. At a new engine getting distributed along with new physics. So there's a bunch of different things here that are important. I'll talk about some of it afterwards. The contact warnings, when the diamonds are bumping into each other or bumping into the edge of the universe, they've been toned down to make it easier to see. So there, for example. So right in there, that used to be much more blary, but it's following the same old pattern right where I, when I first designed something, first get it running, it's taking up all kinds of screen real estate. But as I move on, everything that used to be all over the place gets smaller and smaller and smaller because I want to have visual space left for whatever is actually new. And what's new now is the loops around the diamond sequencer. But this is running quite quickly by T2 Tile standards. And it's been running somewhat. It's been running for 10 days or something like that. I'm going to let it keep running until it stops running by itself, unless I get much better code. I'd like to let it run for another maybe a week or so, we'll see. But this is encouraging and this is part of the reason why things are bad. And the main point is, yeah, it's still alive. That was yesterday, but it's still alive today I just checked. So the goals for this time for today was self-copying program, loads and runs, did not achieve that. But there was progress across the board and that's why I'm feeling pretty good. So the T2 Grid speedup, that's what we were just seeing. In addition to tweaking the graphics and so forth, I made an incredibly simple change that made a huge difference. And this is it. Can you see it? This little three-line function took the first line and made it the last line and it made a huge change. So what this is, the whole MFM T2, the engine that performs all of the sequencing and the running of the events and all that stuff on the T2 tiles is based on a priority queue, time-based thing so that whenever it finishes doing whatever it was just doing, it goes and finds the thing that has the earliest deadline, the thing that most wants to go, either the thing that's nearest in the future or the thing that is in the past if we have overrun our time. And then we call it and the on-timeout method is what gets called. And so what this does is the first thing it does is it puts itself back on the time queue, the T queue, for redisplay miss in the future. Now in this case, it was a sixth of a second. So I was doing six frames a second and then I check for touchscreen input and then I redisplay everything and then that's it. And then we go on about other business like for example performing events on the sites of the grid. But as we've got more and more custom graphics with the contact warnings and then the pocket chains with their long, long downstream side and their short upstream side and so forth, somewhere along there it got to the point where the redisplay function could take more than a sixth of a second. So what happens? We put it back on the time queue for a sixth of a second from now. We take more than a sixth of a second and then we release ourselves and we immediately are at the top of the queue again. So we just get displayed again and everybody else who's trying to get in to do events on sites gets starved. They get an event every so often and so on, but this I think explains some weird behavior, one of these worries that I didn't even actually talk about that goes all the way back months, if not years, where every so often, especially before I got the fans going to keep everything cool, some of the tiles, especially in the center of the grid where they would get hot, they start slowing their clock down to try to maintain, to control the temperature. And sometimes, not often, I would see a specific tile that essentially was paralyzed and even the stuff that was moving from adjacent tiles would get stuck trying to go into this thing and I couldn't figure out why. I suspect it may have been a problem like this. So now what I have done is I have taken the, don't insert it back into the time queue until the end, until after you've finished redisplaying. So this is the kind of top-down control freak, I want six redisplays a second. This is the bottom-up best effort. Don't call me again for at least a sixth of a second. That's what it says here. So we do all our work however long that takes and then we say, okay, we have a sixth of a second to go to other things. In fact, I have now changed this to a third of a second as well. And that's what we were just seeing. Yeah, we can actually look at it. So here, I just shot it with my phone, right? And so this is real time, no time lapse at all. And we can see, you can see the HC3 grid compressions moving through the dots. You can see the loops moving around from place to place. Now, this is fast in no sense, but it's faster than it was. And you can see the new revised little subtle contact warnings there, the little orange things. And all I really need, I mean, the grid cam time lapse, which is mostly what we're looking at, takes one frame every five seconds. Redisplay, miss, could be a fifth, well, could be four seconds, could be two seconds, three seconds, whatever. So this is much better. This is a long-standing anxiety of mine is eased. So great, the timeline has improved. This is what the timeline looked like last time. It didn't have state machines, didn't have the HC3 sequencer, that's what's now called the diamond sequencer, it wasn't really working. And so forth, this is what it looks, whoops, this is what it looks like today. I am calling, we have HC3 sequencer, we have state machine, got some examples. The redeploy centers, we don't have yet. We'll talk about that in a minute. We've still got little bits and pieces of stuff, but this makes me feel like there's a real shot. Just getting kind of worried, the last couple of updates, the things were going pretty slow, but progress. And a big reason for that progress is because diamond sequencer programs are actually running. Yeah, and let's take a look at a demo, what's next? Yes, okay, and so I've got this just started up. So the L1s are just seeds that place proto loops in the place. And we'll just let this go for a little while. Okay, so now three of the four L1s have popped out. So we have a marker in, so the southwest, the red diamond sequencer pocket, the DSPs, we have four pockets. The southwest is the red one, which is output in this case. If this can be rearranged, the northwest is green, which is supposed to be input. The north, sorry, northwest, northeast is blue, which is temporary storage. And southwest is white, which is the execution stream. And in the execution stream, we have the loader, where the idea is the loader is going to take the ancestor code, whatever it is, that's stored someplace. And as the loop in the instruction stream relaxes and gets bigger, the loader inserts the instructions for the ancestor into this primordial cell. So if we let this run a little bit, the important point to notice, it's all bopping around and doing its thing. But the markers stay in the DSPs, the southwest, northwest, northeast, and the loader stays in the instruction stream. And in fact, it's got a couple of zons in here, that's an RS down there. That's a reset instruction and so forth. The loader is inserting the program into the instruction loop. And none of it is executing. Why? Because the loader is hogging the DSP, the domain sequencer pocket. And it's going to stay there now because it's working until the program is entirely loaded into the loop, and it just took itself out there. And then it decayed away to an empty codon and marked the instruction stream as we have to move on to the next instruction. And that's how we boot in the domain sequencer programming language. It's actually working. So that's pretty good. And we'll see another example or two in a minute. And finally, construction arm constructed. What does that mean? Well, there's a John von Neumann, or a father of computing in many ways. One of the many things he did was he built this cellular automata. It's kind of blocking me here that it reproduces itself. So it's in the very much in the same spirit of what our artificial life creation countdown challenge that we're doing right here right now is, except the nature of the cellular automata that we're using is very, very different. His was deterministic, synchronous, all of that stuff. Cuz it was a proof of principle. And what we're doing here is a proof of principle too. But it's a different principle. It's a principle of bottom up, robust first, and so forth. And so the important point for this story, so this yellow line, you can see down here if you actually go to Wikipedia, it's a blue line cuz I've inverted all this stuff, that's the actual instruction string that's like sticking off hell and go on to wherever. And we're saying that's not really very practical, especially if we want the entire thing to move. The von Neumann universal constructor can only move by making copies of itself. It can't actually get up and go anywhere like our cells can. That's an example of the difference in flavor, even though we're making a constructor that constructs itself. And in particular, one key step of it is that there's a tape of some kind, which is gonna be the instruction loop in Arceus system. And is that big long line of states in von Neumann's original universal constructor that tell this construction arm another automata that functions like an operating system. I don't know if that's great Wikipedia language. But whatever. But the point is the construction arm can move around and deposit stuff in various places. And that's a part of, well, it's the main thing about how it makes copies. Since the construction arm goes 0-1-1, 0-1-1, and so forth. So we have a construction arm, let's see, here we are. Okay, this is just a minute or so. So these start out looking like, oops, that's what you get for pushing the wrong button. These start out looking like what we just saw in the demo. But they're gonna start diverging in a minute. And the program is getting loaded into them, and the program is starting to exit in the end. Look at this, these little guys here, little beings here. They head towards the wall, and they take a turn. And all this stuff is going on all at once. The thing is the grid is growing, the grid is moving around on the larger background of events, and it's building a box. And the important point of that is that the box is largely an arbitrary shape that I just picked last night to demo. And then the cell suicides. The cell has pre-programmed cell death to leave the box behind. A box made out of wall atoms. Take a minute for this last one, last being to make its box. Because in fact, it was close to the wall, actually. And when you get contact warnings, it takes longer to grow and can't actually build the box until the cell gets big enough. So look at that. And how do we do that? Here is our revised sample ancestor code, and look at that. North, west, west, west, west, south, south, south, south, east, east, east, and so forth. Capital W means withdraw the construction arm one step and leave behind a wall atom. And dot means we're done. The program is running and performing arbitrary business, arbitrary acts. So that's what gives me hope. Control of the box is chaos around, we've kind of got that. So I'm calling this the big comeback, because I was getting a little bit worried. And our three raggedy, the saddest little boxes you're ever likely to see is the evidence of the comeback. And so that is it. The next update will not be until December. We are now entering a pre-programmed hold at T-3. The goals for then is to have a proto-ancestor code running. We shall see. Publish a book, talk about that later. I didn't write it, and I want to have big fun. And thank you so much for coming, and I hope to see you in December.