 I'm Dave Ackley. This is the second weekly update of the T2 Tile project. Let's get into it. So one of the things I had on the schedule last week was to make, I spent like four minutes or something last week describing the problems of the current system and so forth. One of the goals was this week was to boil it down to like a single sentence, make some sort of intro thing that we could show at the beginning of each of these episodes. I don't have an intro video thing to show yet, but I did work on trying to compress all this stuff down to one sentence. Man, it is hard. I was starting out, I mean October 6th, this was before even last week's thing. Digital computer revolutionized how we work, but limits to do things, we follow so long, I don't know, something like that and I worked on it a bunch more and there's just tons of too much stuff and this has always happened to me. I always want to get too much in upfront because like I said last time there's too many ways that one could possibly introduce it. So all right, I've settled on one way to introduce it. I'll read it off now and you know who knows if we get a half decent reading they will be able to use the sound to go with the video which will hopefully exist in the future. So here it is, let's take a go at it. The T2TILE project is working towards bigger and safer computing using living systems principles. Follow our progress Tuesdays at noon mountain time. T Tuesday updates. Yeah, I don't know, so pro. Okay well, so again the pattern is what we accomplished in the previous week, what we're hoping for in the next week, and then maybe some kind of feature or backstory fill in, answering questions, whatever it is. So one of the things that we did get to if people may not be familiar with it, my friend and colleague Michael Litman and I have had this sort of on and off again about monthly podcast called Computing Up Conversations about Computation Rit Large and there's a new one out specifically about T Tuesday updates. And so if you like podcasts, I mean on the one hand the information density is kind of low, but on the other hand you can kind of do other stuff while it's playing. So in this episode of Computing Up you talk about the stuff I've been doing lately in particular this and in fact you could even find out why the second weekly update would be labeled 11. That's in the Computing Update, the Computing Up latest episode. All right, so that's that. The main event, oh and I did yes work more on hacking with this I feel always guilty for having done that, but in fact these zoom in, zoom out presentation images that we're using now, you know, those are new this week and so forth. What I mostly want to spend time talking about today is some of the aspects of the new things in ULAMM4, where they came from, why they exist, and so on. So a couple of days ago, I don't know Wednesday or something like that, pulled a big chunk of commits from Elena Sa's repo into mine for MFM and also ULAMM brick wall geometry. And several things to notice about this. The first thing being, I don't know if you can actually read it down here, it goes back to last fall. So this has been a fairly long coming change this brick wall geometry, whatever it is, and it is all tied up with the T2 tile. So I want to focus on that mostly today. All right, so let's look back to 2009. Here's a bit of video. I'm going to play maybe 25 seconds of it or something like that and then I'll talk about it, okay? Together as well, although they're not syncing each other, what we're going to do here is we're going to send some new code into the system. This is a USB connection that we've got over here that we've got connected up to the laptop. And I'm just going to recompile the sketch that these guys are running and I'll do that now. And oh, that flash right there was that system had discovered that new code was available. So it dropped back down into its bootloader and there you can actually see it's pulling the code in through the USB connector and then burning it into its flash. And that takes a couple of seconds and now it's a red one. And at the same time, the guy next to him, he just heard about this new code from the first guy and he compared the date of the new code and said, oh, this is much nicer and newer than what I've got. So now he's picking it up and over the next minute or so. Okay, so you get the idea. These little teeny tiles, here it is. This is the Illuminato Ex Machina from 2009. I think of them now as the T1 tile, although we didn't call it that at the time. It's got a ARM7 chip on the back. It doesn't really matter. It's sort of a 2000 era smartphone, although from these days we would probably consider that a fairly stupid phone. It's important that it's a 100 mega Hertz processor. It's really slow. But it's all designed so that you can just take a regular 10th inch connector and you can plug it in like that. And then you can take another one and plug that in too. And now it talks to itself just like in the video. Actually, let's clear out the screen here so now we can be able to look over here without stepping on ourselves. So you get the idea. It's very cool. And again, you can continue on down and plug another guy in. I don't have another one here, but you get the idea. So the idea is you'd make a grid of these things and you would compute with them. They don't have a whole I.O. They have one LED, an RGB LED in the center and then a four blue LEDs around the edge. But that's about it. They also have a couple of buttons. But the important point is that it's a little unit of computing, a little square of stuff that it can do. And if we now look here at MFMS, the simulator here, we get rid of this. And so you see this, these four gray squares, they are meant to represent exactly the sort of thing that these tiles would be. Like here's two of them. That's not literally the T1, the IXM because the movable feast machine, this model didn't exist at the time. It came after the IXMs, but you'd get the idea of how it would work. And you know, we can pull up, we can plop down an atom here and we can let it run. If you're not familiar with how the movable feast works, it's okay. Don't really need it for now. But that's pretty hard to see where the Dreg went. It's heading around. It'll bounce around. And so maybe we should put some more stuff in just to help it out. Whoops, maybe not that much. How did I do that? Somehow I got it on flood. All right, so there's a bunch of stuff. I don't know exactly how I did that either. It's all right. The point is these things all interact with each other. They make little local decisions. They see the little neighborhood and they decide what to do. And the point is, is that scales indefinitely. Now, you look at this and you say, okay, well, I can imagine how that sort of thing would run on these, but there is a fundamental problem. And let's get rid of this for now. Where's my flashback? Okay, so imagine it really was a grid of these guys. Or in the sake of argument, imagine, you know, it really is this grid that if we had this all fleshed out and so forth. Okay, now there's two problems with this. One is a completely prosaic problem. The other one is sort of a higher level kind of software programming problem, but they're both really serious. And the first one is, okay, so say we've got a whole grid of these things. And they're talking to each other, they're using the little seven pin headers, it's actually 14 pin, this connector for the IXM is symmetric. It's like we invented USB-C in 2009. But now one of them fails. What are you going to do? You know, you can't, you know, let's get this back up here. Okay, so here you are. What are you going to do? You can't pull this guy out this way because there's another tile on the other side of them. Oh, there's another tile over here. How are you going to get this guy out? You're going to get the side cutters and just cut all the pins out and then lift it out. Okay, you do that. How are you going to get the next guy back in? This has a fundamental problem that the interconnect mechanism of the tile operates in the same plane X, Y as the grid scales in X and Y. And it makes it very compact and cute, but it also means that you're fundamentally screwed when it would come to maintenance or changing these things. So one of the things I wanted absolutely out of the T2 tile was to avoid this problem. That a T2 tile, whatever else it did, you ought to be able to replace a tile out of the middle of the grid without having to disassemble the entire universe. So we've achieved that. But there's another problem and the problem is this. When we looked over here and we had all of these things running around here doing whatever they were doing, let's pick this guy. This R right here. When he goes, he's going to look around his nearest neighbor and he's going to decide to do whatever he's going to do. So he went east. But after he went east, this tile and this tile at least, if not these two tiles, would need to know about that so that they can coordinate the fact that there was just one guy before the event and one guy after the event. So how are they going to do that when you have a grid of tiles like these that are only connected in four directions? North, south, north, south, east, and west. They're not connected diagonally. How are you going to tell this guy, this guy, how is this guy here going to tell this guy up here that something happened on the corner? In the simulator that happens because the simulator presumes there are eight-way connections between the boards, not four-way connections like on the IXMs. This is a very serious problem and in fact in 2009-2010 when I was originally developing the Moveable Feast Machine architecture, I tried to implement it on the IXMs and the fact that there was no diagonal connections was a huge problem. It would mean when one of these things happened where you need to say across the corner, hey, this changed, you had to actually send it by a bounce shot. You'd send it north and say, Mr North, could you please send it to your east so that it could end up in my northeast? It slowed everything down tremendously and I never even really got it completely working. So for the T2, we want to have connectors that operate in Z instead of in the scalable directions of X and Y so that we can actually replace things and build them and assemble them incrementally. And number two, we have to have some way of communicating to all our nearest neighbors directly. Now that's a problem. You know, again the simulator, it just assumes that this guy has connections north, northeast, east, and so on. But when you actually start going looking for hardware, it's pretty hard to come up with communication systems that have communication channels of low latency. Exactly what that is doesn't matter, but the point is the sort of typical things of, you know, Bluetooth, USB, Wi-Fi, Ethernet, those things are not actually that good for getting a small number of bits very quickly round trip between two places. They're much more optimized for bulk lifting. It takes a while to get the first bit through, but then they can really pound them through quickly. It's not what we need here. We need to get small amounts through very quickly. So what we really want is to be able to talk in eight directions simultaneously. And that's hard to come by. Again, computer engineers, they can do anything you want. Sure, but the goal is to get as much off the shelf as we possibly could and really fundamentally the best thing I could come up with was we could come up with stuff that had hardware support for six directions at once. Those could either be sort of serial ports or a variety of other things, but six was about as far as was going to go without doing really heroic hardware engineering, which I don't want to do. So what if instead of having the tiles arranged like a checkerboard, we had them arranged like, let's see, let me get rid of this please. There we go. We let them be arranged like a brick wall. And what does that do for us? Well, what it does is is if you look at this guy here, say, let's put some drag down for him, put some res over here, whatever. You let these guys run. Well, it doesn't even matter, but the point is this guy has one, two, three, four, five, six neighbors. Each guy in the brick wall, each brick in a brick wall, has six neighbors. And in fact, if you imagine the brick sort of bulging out in the middle, this is topologically equivalent to a honeycomb hexagon grid, but it's easier to fabricate and it has some other advantages internally, which can talk about another time. So with six-way connectivity, we only require, well, six channels for glad to talk to the neighbors. And furthermore, when we used the checkerboard, when we use something like this, we might end, we had an event right here in the upper corner, something, let's put a wall here, it's easier to see. So if this guy had an event, he would need to tell one, two, three other tiles about it. And the way it works internally is that that has to, you know, ask the other tiles to wait. Can I have exclusive access to this little region of space? Can you please wait until I'm done? I'll tell you what goes in there. Okay, it's very slow, a lot of overhead. Whereas if we do the same thing in brick wall, there are at most two other tiles necessary to talk to. If we put a guy here, for example, then he might need to talk to his northwest and his northeast, but he doesn't have to talk to his east. If it's here, he only has to talk to his east and so forth. So with the brick wall geometry, we have at most two other tiles that we need to talk to at once to tell them about what's going on, what we've just done. That's how the T2 tile is going to work. The T2 tile looks like a brick wall. And we're already at 16. Oh my god! All right, well I'm going to keep on going. This is the dress rehearsal and we'll figure out what we're going to cut afterwards. So brick wall geometry is what the T2 tile is going to use. The six-way connections at once. It's now in develop. You can play with it and you may have seen that the trick of it is you've got, back is that, when you run the simulator, the first argument if you want can be this geometry specification, which is like rows, columns, and a letter code in the middle saying what size each individual tile is supposed to be. So 3d2 is, you know, three columns by two rows and so on. If you put two levels of curly brackets around that first argument, you get checkerboard. I'm sorry, you get brick wall geometry, otherwise you get checkerboard. Okay, so progress is being made. We're on the way there. And going forward, what do we want? Well, so next week I would like to have a video, an actual video or some kind of visualization to go with the little quick one-off summary sentence of what the project is all about. I want Splat, one of the questions that came up. In fact, here Spencer Harman, he's trying to talk about Splat, mentioned it was currently empty. Will Splat be in community? Will I'm for update? Yes, it will. And the hope is that we'll get the GitHub repo populated next week. Be warned, Splat is very rough. It's very primitive. It's implemented in Perl. But it does do what it does and it's mostly about showing the ideas. And Kaikad is the schematic circuit, electronic circuit, and PC board layout, the stuff that we've done all this in. Got to get that running again so that we can start to move for it, move toward the final prototyping of the boards. We'll take just a quick question. So this will be a 20-minute one, sorry. 4729, Zex asks, are these new type of computers going to serve as supercomputers or personal computers? Yes. You know, whenever you ask a question that's a disjunction, you're vulnerable to the answer. Yes, but it's really meant to be true. The idea of being indefinitely scalable, not with the IXMs, but with the T2s, is that if you use a few of them, you have small capabilities. If you use many of them, you get bigger and bigger capabilities, that you should be able to decide how much compute you need after the fact, rather than just saying, okay, well, I'm going to specify a 100 megahertz ARM7. Now I'm done. You say, well, I'm going to leave room for however many tiles and so forth, and maybe I'll only populate a few of them, but plug them all in. Is it meant for something else? Oh, who knows? It's meant for everything. It's really a research thing. Can these change video gaming? Yeah. It'll take a while. But really, this sort of stuff where, you know, when you have a video game that supposedly has space and you're walking around and shooting things, that's really all completely phony, right? It's all inside RAM. It's all just pointers. It's all arithmetic floating point. But with these things, space is actually space. And with this kind of computation, all the stuff happening in parallel, this is points directly at the way towards voxel processing, where you're actually going to, everything is going to be live. It's not a matter of the artists and the gamers and the triple leg sweatshops developing the next game, deciding which things are going to be live. Everything's going to be live. Is that going to make a necessarily great game? Who knows? But it's going to make an extremely rich game. Again, not soon. None of this is soon. The question is like, you know, how can I use this for my spreadsheet? It's like, well, you know, don't. All right, one more, and then maybe we'll stop. Excellent presenters. When you see this alongside decentralization trends in general. Yeah, absolutely. The point is, is that one of my favorite analogies is to think about computer architecture like political science. If the computer was a society, what kind of society would it be? CPU and RAM is a centrally organized dictatorship. It is. And that's one, that's another one way of understanding why it's very efficient, right? Mussolini made the trains run on time. But at the same time, it doesn't scale. And it's extremely fragile. The resistance can disrupt it. Because the vast majority of the system, all the little memory gates out there and ram that they're all forced to compute the identity function. Remember, remember, remember, even if they could do some more complicated function, they're not allowed to do. Means that once something does go wrong and something always goes wrong, nobody is going to fix it. Nobody is going to notice because all the decision making is at the center. So, absolutely, the movable feast machine, all of this kind of programming that I'm suggesting we need to get into and understand is all based on this decentralized idea. Do you need to sometimes get together and elect a leader or have a committee and make a decision? Absolutely. For sure. There's no magic. Anarchy does everything. But the goal is, is to use only as much synchronization, only as much centralization as you need for the particular task, rather than thinking if I was just emperor of everything, everything would be fine. It wouldn't. Thanks for the question. Okay, we should really stop. The next update will be out Tuesday, October 23. Let me know what you think. Let me know what you think of the little summary line. Is this too long? Do we need more? Do we need short? Thanks so much for watching.