 Our next talk will be by TQ, Kelvin and Tech Fury, which would have been far more difficult actually if we would have met in Leipzig, because TQ is originally from the US, now he lives in Belgium, Kelvin is from Canada and Tech Fury is from the US. So this would have been far more difficult to do in person. TQ has been into retro computing for around 20 years, starting with the TIRS-80, moving over to minicomputers, and yeah, he's especially interested in the features that died with that market segment. Kelvin from Canada started retro computing also as a hobby, and he lives the dream of most of us because he got to make a job out of it, so he works with the more modern iterations of the systems he started out with as a hobby. And Tech Fury is a daytime shipment tracking software developer, and a nighttime necromancer for weird old hardware, and together the three will talk to us about what have we lost, features of mainframes and so on. Good evening everyone, let's talk about some fun old shit you can learn from at home. Hi, I basically do a whole bunch of PHP hacking on IBM I, and then I basically enjoy preserving software for future generations, apparently there's also this guy called TQ. Hi, I build the distributed trust system for computers, and at night I figure out how to make old computers feel comfortable in a modern world, and there's also Landon. In my day job I maintain an in-house iOS app, and at night I'm a curator and a fixie and auto bygone Japanese and British computer systems, you know like NEC, PC98, Acorn, Archimedes, etc. And with that being said, let's hand off to TQ with his presentation on the Symbolics Lisp machine. So, in the early 80s, MIT spun off part of its research group into a firm that produced Lisp machines. That firm was called Symbolics, they built a machine called the Symbolics 3600 that ran an operating system called Genera. What exactly was this? Well, obviously based on the name it's a Lisp machine, it's a it's got hardware that runs Lisp directly. Everything that ran on the machine was written in Lisp, from the microcode to the operating system, all of the drivers, everything. It included all of your development tools that you'd expect. So the editors, your editor, your compiler, your debuggers, inspectors to be able to look at data structures all in Lisp. And it was for a very long time considered to be one of the best development environments around. It ended up buying a sort of ignoble beth because for a combination of reasons. First of all, the company made some absolutely terrible decisions. They ported their platform to run on a new bus on Macintosh, shortly before Apple switched to PowerPC and PCI. And then they went from there to the architecture of the future, Alpha. And then they died. We're not here to talk about the deaths of symbolics, we're here to talk about their life. Let's talk about their first machine, the 3600. Shipped in 1983, it had a 36-bit word, four bits of which were set aside for tag bits to tell what type of data was stored in a particular word. And the other 32 bits for the value of that particular word. The processor microcode had 36, the processor microcode had up to 16 hardware tasks to be able to handle things like interfacing with the disks, driving the display, scanning the keyboard, accessing the network, et cetera. That microcode also provided a high-level instruction set that had instructions like cons to allocate memory and garbage collective necessary. It also had your usual complement of arithmetic instructions, add, subtract, et cetera. But unlike most architectures, even modern architectures, the arithmetic instructions operated on arbitrary precision words, even possibly rational numbers. At one point they ported a C compiler to it, it just used the native machine integers, because why not? And somebody tried to run a program that determined the size of the word by shifting one left until it ran off the end. And this program ran for about an hour until it ran out of memory. So I could explain the interface, but it's probably easiest to start with a demo. When you start up Genera, you're greeted by a pretty high-resolution graphics display. The original machine's shipped with an 1100 by 900 resolution screen, so this full HD display that you're seeing right now is not far off from original hardware. So many pixels to play with, it may actually be surprising that the entire display is taken up by a command line. But this is not the Unix command line that you're used to. We'll start by logging in, that's what it tells us to do. And immediately we see that there's a significant difference. Normally with a Unix command line, you start by, you type in a command, Cp, LS, whatever. And it just waits for you to type in the rest of the command. If you need to give parameters, you need to already know what those parameters are, possibly looking them up in a man page. Genera on the other hand, Genera holds your hand a bit more and prompts you, you need to enter a username. Okay, I'll do that. Okay, so what can we do here? As any Unix user knows, the first thing that you do in any terminal, whether or not, or whether you've just changed the directory or whatever, the first thing you do is do LS. Genera spells it a bit differently, and I'm going to list my home directory, which hopefully is already selected. This still looks very much like a traditional Unix directory listing. But you'll notice that as I mouse over it, it actually highlights individual lines. And this is the first hint that there's something really special going on. Suppose that I want to list the contents of one of these directories. I'll type in show directory. You'll notice actually that I just typed in the first couple characters and it auto-completed. I want to list the list directory. And I could type it, but it's already on screen. I should be able to just click it. And when I do, it pastes it into the prompt and I can hit enter to accept it. That just lists the directory itself, which is not quite ideal. Wonder what else we can do? What happens if you just click it directly? That actually lists the contents. And you'll notice that it actually filled in a command for me. It says show directory generavlm home the box that lists last star. What has actually happened here is very subtle. Each of these objects that is shown on screen has a set of handlers attached to them. And when I click on them, it's the system knows a command that should get run. Such a command could be bound to the left mouse button, which is what you'd expect. It might be bound to the right mouse button. In fact, at the bottom of the screen here, you can see, well, I can't actually point it out, but you can see that if I press the left mouse button, it will execute show file. If I execute the right mouse button, it'll show a menu. And there's a bunch of other commands. So now that I've shown the contents of the list directory, let's say that I want to actually show what is in a file, just type in show file. And we'll get to these files later. For now, let's just look at this file one, file two, paste file one, and it shows the contents. It says no need to get catty, which makes sense. This is basically the equivalent of cat. I could have done the same thing by just clicking that without typing in the command first. I have other options too. I can open up an editor, going to resize the current window, open an editor, and move that aside so that I can see the window underneath. This is emacs, as you can probably guess from the name. It's just an emacs clone. The Z actually stands for Svi, which stands, or which in turn stands for, Svi was Ina initially. And in case you're curious what Ina stood for, Ina is not emacs. It's a long good pun. Being an emacs clone, we can open a file with Ctrl X, Ctrl F. We know that we want to look at file one. So we can click it, and it opens. Earlier, we clicked file one, and it printed it down below. If the active window is a Zmax window though, we can click another file, and instead of printing it in the Lisp listener, it opens it. This shows that each window has an input context associated with it, and the input context controls what commands will be automatically executed when you select or interact with some object that's on the screen. I'd like to point out one more feature of the command line. I remember reading that Lisp was widely seen as the language to implement advanced AISI, and I decided that I didn't care to actually write this talk. I wanted the system to do it for me. It's good at that. So I made a grand. And it asks me what I want to give a talk on. I'm giving a talk on genera for now. I click that, and it asks me a couple more questions. Do I want to talk about presentations? Yes. Do I want to talk about the inspector? I might have time, let's see. Oh, what do I want to inspect? I can click hit this, and it's like in a function, the results of which it'll show me later. I'll skip that for now, because chances are we'll have enough to talk about that I won't actually have time to get into that. Do I want to talk about documentation? Yes. Cool. Let's do that. And as it turns out, I didn't have actually have time to make an AI to write the talk for me. So, well, let's take a look at what the code that created that looks like. Here's the source code. All I did is I declared a couple of variables. I called the accepting values function, and then asked a series of questions. Some of the questions or whether some of the questions got asked depends on the answers to some of the earlier questions. You may recognize this pattern. This is exactly the same way that you'd write code for React, or I am GUI, or any of the many modern immediate mode GUI frameworks. What have you learned? Interesting things that you saw there that you should really keep in mind. The things that you should remember from that demo are that Genera had a pervasive command line interface that integrated very well with the graphical interface, and that everything that got displayed on screen represented an actual object, and you can manipulate those objects based on the things that appeared on the screen. Let's look at an alternative implementation of the same idea, just from the west coast. Lando? On the west coast, Xerox actually invented its own sort of list machine. They originally ported BVN's lists for the PDP-10 as people moved over to park from the east coast, used to work at BVN-MIT. Then they ported it to the Alto park using a Bica virtual machine implemented in the Alto microcode. Then it got ported to the successors, the D machines, which they called because they had names starting with the letter D, Dandelion, Dorado, Daybreak, so on and so forth. Since the entry list D team was near the Smalltalk team, many of Smalltalk's concepts like overlapping windows made their way into Interlist B, and as happened with Symbolics, Interlist B was also the victim of the AI Wincher, and it never really thrived after Xerox sold it off in 88, but recently Xerox has open sourced it. Now, since the D machines were actually originally meant to run Xerox's Mesa virtual machine and they kind of just hacked interlist bond to them, they're more or less just a simple 16-bit microcode stack machine, you know, not really that different from a lot of 70s many computers, just kind of in a workstation form factor. So they aren't as fast, there's a lot less fancy features, you know, none of these fancy tag pointers, none of that, but it worked and it was a lot cheaper than Symbolics. Eventually a team at Fuji Xerox actually implements this virtual machine in C on top of SunOS, and it's actually now open sourced, and you can write on your common X86 ARM whatnot system today, just get it off, get it off. So just like East Coast list machines, Interlist B is also a complete off-rank system, again, written entirely in Lisp. However, there's no Emacs for the editor. It's a little bit different on Interlist. Interlist's S-edit text, or I'm sorry, code editor, works by adding S expressions directly in memory. It's not a text editor, it does not touch source files on disk at all. You just merely edit your S expressions directly in memory and then just hit done, and it automatically commits the changes in memory, but it requires a further step to save them. And also Interlist B provides TO, which is a rich text editor that was inspired by the famous Bravo editor on the Alto. And now let's see Interlist B for ourselves. Let's start with Interlist B. You can try this at home. Everything I'm about to show you can be done with just the materials on GitHub. As you can see, this is a bit more like small talk than generic in terms of the stacks. We have draggable and resizable windows, just like modern windowing systems. We also have right click context menus. They've been around a while. Now note that this environment looks more or less the same as Interlist D in the 80s. They haven't changed a whole, whole lot. So anyway, in the exact menu, we can pull up a REPL. We have Xerox CommonLisp, a strict CommonLisp mode, and we have Interlist. So let's pull up an Interlist REPL. All right. So let's customize our environment a little bit. Background is kind of plain. So we're going to use files load star BG to load in a program called star BG. But we don't know what the name of the function we need to call is. But we do know that there's a variable called the star BG comms. And that's kind of like a package manifest where all the variables and functions are grouped together. So what we can do is we can pull up the editor on star BG comms. Now, this is asset. It's a little interesting, as I mentioned earlier. This is not a text editor. This editor is actually editing the S expressions directly in memory and formatting them as code. So the nice thing about this is that the, we change the size of it. As you can see, the code automatically is formatted to fit the different sizes. Now let's look at our functions down here. See it's in the function section. Again, notice as I double click on things, the scope expands. I thought that was pretty cool. So let's see star BG. This looks similar. So we'll select that, see how it's underlined. And then we will middle click on the menu bar here. You can choose edit, functions, and take a look at that. That's the function star BG is code. Now let's run it. And you see it's nice little space themed background. Now let's do a little bit of editing. This is a little bit of a famous demo here, sort of. You see this a lot in old brochures. And why is the mouse being very laggy today? It's kind of strange. Famous has the intro list B logo. But I think we should change some things about. So one moment we, since we know we called CotoLogoW the function, we'll do df define function, which also edits CotoLogoW. Now we could just simply use some of the arguments, such as a string, but now let's just hack it. So we're going to change the intro list B high RC3. And we're going to go to the S edit menu. Going to choose done. This commits the changes, but only in memory. So it has not changed the file that's loaded from. Run the logo again. Hey, look at that high RC3. Now, like I said, it doesn't save into disk. So if we do files question mark, it notices that we've made changes to the CotoLogoW function and the CotoLogo file. And if we do make files, we've now saved it. We can also try this. Let's see how this works with the new function. Let's try df hello. And do a little bit of hello world function. You can do this old school intro list style. So we're going to use lambda. See a template's already filled out. We're going to highlight this argument. And then we're just going to hit backward delete, or I'm sorry, forward delete, and then see how that's cleared out. And we'll do the same here. Notice when I type the closing parent, it just simply closes it. It doesn't insert anything. I can't just type morons. This is very structured. So either you're done. Now we have our hello world function. And if we do files question mark again, it's going to ask where we would like to put it. Oh, speaking at me because that's a yes or no question. They do a lot of things like listen intro. So we'll just hit why. And we'll give it a name. Hello to create a new file. And you can see the changes are marked in there. Sorry, create a hello to comms. Let's take a look at that. So you can see it's already built a package with just the function hello, which is the same hello as we see there as we will see when I pull up at it. Same thing. So moving on further from that, you can also do save it, make files. And we can also explicitly do that with make file. Again, and notice there's a version number. This is inherited from tops 20, which is what they ran this on originally before they poured it to the D machines. Now let's see if we can T edit document editor and the file browser. So we right click on here, we can choose the file browser. And we're going to give it medley. Notice the use of the greater than symbol for the path separator. So all right, we're gonna take a look here, table of contents. This is the list users library. This is basically a contributed program from users. So we select it like such there with the left button. We're going to go to edit T edit. Ask us to define our window. See, take a look at this. This is a T edit rich text editor, kind of getting a little bit of a generic document examiner vibe here almost. And it's back to complete rich text. Let me see if we can get the here we go expanded menu, page layout and stuff. You can also quit it, close that window. And similarly, most of these entries like say star BG, we were looking at just a little bit ago. Let's find that. Similarly, it has its documentation available through here. Now similarly, we also have a language reference manual available through dnfo. And that too also appears to be based upon T edit. Let's go ahead and actually close T edit there. All right. See you can navigate through this all hypertext style. And then we almost forgot about Dwayne. Dwayne is pretty cool. Dwayne is do what I mean. And so remember how we typed hello. And that has to be in all caps because this was case instance in this regard. But let's see what happens if I type it all lowercase. It suggests for me automatically that perhaps I meant all uppercase or I could tell that it's wrong, undefined function. And similarly, as you might expect from a virtual machine, virtual memory persistent setup, you can also simply log out. Just got to end again to all caps. And then that will save the entire world. And we can pull it back up again just exactly where we were. And that's it for the entry list D demo. And now we will go on to our next and last platform I will be demonstrating today, Beetron. Japan's attempt to design their own desktop operating system from scratch. But what is Beetron? It's an outgrowth of the Tron project, which basically was a Japanese academic academia and industry initiative to develop a new set of operating systems and standards for a computerized society of the 21st century. And they came up with all sorts of standards like the Tron keyboard, they even have CPU architecture. The end goal of all this is to have essentially a world in which all of the objects in your everyday life would be based on itron embedded operating systems, interlinked through a network of C Tron machines to your Beetron based desktop computer. And so Beetron is known as business Tron. It has desktop metaphor. It's meant for personal computers has a heavy emphasis on working with documents. And one implementation of it is still sold today as a VMware image. And speaking of these futuristic systems that sound awfully like the internet of things, I highly recommend watching this Tron smart house video I've linked here. We couldn't fit in here. There wasn't enough time, but you will see that the internet of things is really nothing new as a concept and that these guys even thought as far as the internet of things toilet back in the day. So one of the unique features of Beetron is the Tron application data bus, which defines real objects and virtual objects. Real objects are a type of structured container file, they can contain any number of embedded virtual objects or links to other virtual objects within other real objects. Beetron additionally calls for a unified document editor in which various basic objects can be freely mixed in bed. For instance, you can actually use an embedded spreadsheet object as a table and system updates actually are shipped as documents. And speaking of system updates shipped as documents, we're going to actually show you how to install one right now in this demo right now. All right, so I fired up to a kanji v here. This is the virtual machine VMware version does not need any special hardware or anything. So first, we need to put this in English. So do that, we're going to open up a web browser. It's actually a document that our plug in, then get to the support page, find the chokan gv English kit, we'll download it, tell it to save it as an archive file, and then we open it and we'll drag the document out. So now we've created the real object containing the English patch and we'll open it up. It's actually a variety of virtual objects inside. See, I'm double clicking on them. It's very hypertext like go into installation. If you can see right here, update is actually a blob within the document. So we'll go ahead and to go to system setup, version tab, drag it in here. Once the three boot, we'll go ahead and do that. All right, then we'll open the document again. Actually, before we do that, we need to switch the language to the English. Another reboot. Okay, now we're in English. We'll open this back up again. What we can do here is if we actually, here's a even cooler way of doing this. And right click on it here, go to real object, virtual object network. Ah, you can actually see the structure of all the virtual objects within this document. So if we see this right here, we can do copy to tray and then copy from tray. I guess the tray is what they call it the clip board. And let's see, let's open up a text pad, kind of like a basic document. So how about, let's put our English patch inside this document here. As you can see, it's even been moved out of there. Ah, let's see. Oh, let's open up a drawing. Got some funny little shapes. You can either and you can save it to a new real object or the original. And then we can actually draw it, drop it right in here, which I thought was pretty cool. But you can also embed individual objects from within there. So those are also embeddable because again, it's the same document editor. But here's what I thought was really strange. So open that web browser again. Let's take this back out. Now we can save. There's a tad file. Let me do that and look at that. There's our object right there. We can just plop it right in here. And then if we go to see here, let's save this first. If we go to the same real object, do the virtual object network, you'll actually find that when we save the web page as a tad file, it actually preserved every hyperlink. But each hyperlink is actually a virtual object. I thought that was rather interesting and fascinating. I'd never really seen anything like that from the system before. So that's all for the Beetron demo. Hope you enjoyed. Hi, this is the last system we're going to be talking about today. And I actually like Beetron the only other one that's still sold today. Unlike many of its contemporaries, especially in the IBM mainframe world, it combines an easy to use interface with then cutting edge computer science innovations like capability security. If you haven't heard of IBM I, you've probably heard of it under as many former names, and sold to almost exclusively average and non-technical multimedia businesses, basically designed to be treated like an appliance. Runs an IBM's normal PowerPC server lineup. For that, it used to run various kinds of custom PowerPC and its own even custom architecture boxes. There are no emulators for this, unfortunately. Real steel only. The weird thing about IBM is that it outlived almost all of its contemporaries, and even the ones that have survived don't tend to have a healthy and unique system as I. Despite this, unless you work with your average and small-to-medium businesses, you'd never really know I was a thing. I was designed to be easy to learn. It's kind of looks like MVS, COS, or 370 mainframes that's notoriously broken hard to learn. A lot of the deny feels like it looks similar to the MVS, but it files away for rough edges because they actually had the luxury of starting scratch. The biggest change is how all the commands were made consistent. Everything is a mix of verbs announced in consistent vocabulary. You can just learn Vs, and from there you can guess most commands. If you don't know the arguments to a command, or even the values that pass into an argument or a WC on-screen, you can just press the F4 key. That'll bring up a form prompt, and where you can have all the options presented to you and even explained. It'll usually even generate the actual command to it, so you can use it both as a learning tool and as a convenience. If you see something on the screen that you're unsure of, you can just press F1, and it'll show context-sensitive help for anything under the cursor. As for how the F4 prompt works, it's because you're not really invoking the program directly. Instead, there are commands that provide the list of arguments with names, types, and other information, in addition to the actual calls of the program itself. Interestingly, the values from this get passed directly to RGV. You can handle pointers, including buffers past your program, we'll come to that soon, integers, and floats in VRAW. The actual interface is also unlike your typical character terminal. On the right side of the presentation there, you can see Wireshark showing a breakdown of the IP version of the 5250 protocol. It's actually based on setting updates to positions of a screen and fields, so that the terminal nodes where available parts are. While the user submits back only for parts that changed. It sounds a lot like your HTML web form. This means you don't have ANZE-like fine-grained control, but since the machine can make sense of what's given to it, it's easy to navigate by cursor. The first thing you'll notice about the interface is that it's quite menu-based by default. For example, we can navigate this way. You can par... as you notice, the bottom commands are also all consistent. Things like F3 for exit, F12 for cancel, and F4 for prompt, for example, are also consistent. You can also... if we highlight something on the screen, and press F1, we'll get context-sensitive help. We can press F12 to exit out of that. We can also mention the command. Press F1, and it'll also start explaining commands and some of our options. So we have F3 to exit here, and if we do an F1 here, you'll also notice that the help system is hypertext. If we press enter here, when the cursor is there, there, we can navigate, and then we can press F3 to exit. The difference between F3 and F12 is that basically F3 exits out of the screen entirely, while F12 will only exit out of one screen. So you see here, I pressed F3 that one time, but here I can just do an F12 and go that way. You also notice that each link had a little triangle indicating that was visited before. Next, we can run more character jobs and now show us a little bit more interesting screen. This tends to be sort of a what they call a point-and-shoot interface in the mainframe world, and these work with commands pretty much work similarly. You get some options here. You can get F1 for an explanation of each option with a little detail view and so on. As well, you can also put in these options here, and you can just do things like delete or multiple files. In this case, we'll enter 5 to get to the work with screen, and we'll just hit enter here and kind of cancel out of that, but as you can see there, it can do multiple things at a single time. For a little bit more interesting screen, however, you might want to shut down the system, but you don't know all the options for it. So what you can do here is you can press F4, and it'll show you an explanation of everything, and the context instead of help here works too. You press F1 and on option, and it'll explain it for you. And these, well, you can even F4 again to get more options available. And as you also saw, the vocabulary is also consistent. If we want to work with objects in, say, the advent 2020, this is TQ's library for his advent to code Stefan keeps doing in COBOL, and the all-various just kind of a special option. Almost kind of like an atom, except in behind the scenes it's all handles of strings. Scenes is there. We can scroll through, and again, we get the same point-to-shoot interface. We can hit delete here. As you can see there, when we enter something that we shouldn't, that is, it's not a marked field. It'll give us an error. We can do this. We can press reset key in the simulator, Ctrl R, and then we can just space over anything we don't want here. So I'm not probably not going to delete these things, but as you can see here, if we press enter, it would delete this stuff there. But Eva would prompt, I'm going to be a nice person, and I'm not going to do that. So that's just kind of a quick overview of what the interface is like on these systems. Part of the appliance nature is that SQL is built to the system, even implemented at the kernel level. Despite that, it's basically built to the same premise as the rest of the system, the same record files that source code is stored in their used SQL tables. A variety of rich are objects that aren't bags of bytes provide the basis for more complex objects. The interesting part is how you store and work with them. There's no traditional file system in the sense that hot data of a memory becomes cold data on your desk in a separate structure. Instead, all objects are stored in a single address space. Each object has an address that persists even on reboot. If that isn't in RAM, it'll be paged in for page faults, and committing it basically flushes changes back to disk, kind of like a map on Unix. The interesting part of this is you can simply work with pointers from other programs like your own and hold on to them without worrying about them disappearing when the program dies. It changes how you think about buffers or even the differences between programs and processes. Think of the term orthogonal persistence. How is this even secure? I is probably the most popular example of a capability system in the wild. Each pointer is actually 128 bits, 64 bits of metadata, and 64 bits of address space. Outside of a pointer is a tag, which when written to invalidates a pointer. Since only trusted code in the kernel can generate the tags, they function effectively as capabilities. Big tags are stored in ECC. It uses some unfortunately undocumented PowerPC extensions to actually work. Using machine-independent bytecodes is the other part of the security model. Since native programs aren't allowed, we'll accept outside of the Nexus call emulator, but that's a long story. All programs get compiled to native code by the trusted translator in the kernel. This enforces the security model, like say how a JVM would work, as even allowed the transition from their custom CISC processors to PowerPC, and even allowed them to change the kernel ABI. We're going to show you a demo of some of the behind-the-scenes tools of IBM I. Unfortunately, a lot of this isn't too well documented because it's usually intended for IBM technicians, but we'll show you here. The next thing we're going to take a look at is SST, the system service tools. These provide some low-level insight to what's behind the kernel in the IBM I. It's usually intended for technicians, or people have to get information for technicians. So, we'll start it. It has its own separate credentials from the rest of the system, because this is probably something you don't want to give people that don't need it. From this one, you can do things like work with disks or VMs, but you might also have common use for. In this case, we're interested in the service tools. In the service tools, you get things like being able to trace the kernel, as they call it, license internal code in IBM, speak the kernel logs, kind of like a kernel Syslog. You need storage dump manager if that's the crashes. But we're interested in particular, is display ultra dump. This has a bunch of things like special commands, a hex editor, that lets you look anywhere in memory, which is really interesting in the system with a single-level store. Again, you can also take a look at some of the structure of objects, which, since this is in the bag of bytes system forever, deals with structured objects. This is, again, interesting. So, we'll take a look at display and ultra storage. The dump to printer is pretty much the same, except they'll just print out to a spool file, or an actual printer if you have one. We'll take a look at an object. And we'll take a look at a program, which I have some special support for. For a lot of these objects, you can display the actual structure, but in addition to the structure of the program, you can also display this assembly appended to it. So, we'll do that. We know the name and context name. As a reason why it's called the context here, it's because libraries are built on lower-level primitives called contacts. And we'll put in one of the programs that TQ wrote for Advent to code. These are in COBOL, but it doesn't matter. They'll compile to the same byte code. We'll enter a Advent 2020 library. See there? I found it. Let's see, wrote it. And if we take a look at this assembled code, it would have a base structure stuff. But in addition, it's also got a disassembly to it. So, a lot of this information, you'd pretty much have to work for IBM or thought at least know a lot of the system to get a lot of it. But things like hex dumps, the actual base kind of structure, that's all pretty interesting. There's things like a string table, but we're also interested here is the actual disassembly. And see there? It looks like a normal PPC disassembly, except there's a bunch of weird instructions like set tag and TX error. So, as you can tell here, this is probably using the PowerPC assembly that you're used to, even if you are used to PowerPC assembly. But that's pretty interesting. Why don't we take a look at what the actual object looks like. So, I should probably have 12 here instead of a freed. But it's nice enough to remember that. And we're going to go into hex editor. This is capable of making alterations, but we probably don't want to do that. Here, we just kind of want to scroll and actually take a look at things. But this assembler has some interesting features like being able to decode PowerPC instructions such or there. If you enter I there, it can also do things like follow pointers and such. But we're kind of done with that. Now, let's take a look at a different kind of object. That's a little bit more interesting. We're going to take a look at a system entry point table. This is just basically a big list of pointers that point to basically the entry points of programs. Nothing too crazy, but it also has tags in it, which is going to be pretty interesting to see in the hex editor. So, what we're going to do here is we're going to look for the spaces kind of object. This case is this object type 19 in hex. This is number 25 of the menu. We'll take a look at the object. We'll put in the name here. And it has a special object subtype of C3. We need to know this because it doesn't really know how to deal with it otherwise. So, it's found it. And we'll take a look at base structure. It's nothing too crazy here. Again, this would make more sense if you worked for IBM. So, we'll have 12 here and we'll get into the hex editor. As you can see there, scroll down far enough. The type of T here is for tag. And those are over there just a bunch of pointers. So, that's basically SST in a nutshell there. There's more service tools, but this kind of gets you sort of a good idea of what's behind the curtain, what's kind of not really well understood. But it would certainly help if you had to send to IBM. Anyways, that's it for IBM I. We'd like to thank you for coming to the end of our FinCYS Competing bullshit you can learn from. So, by the way, we've got more. That's right. We do have more. In fact, you can try almost everything we've shown you at home. We've got some emulators here for Tenera. Enter a list. And it is possible to get your hands on Chocanji and run in VMware. That's an exercise up to the reader, but you can probably find if you look around. But unfortunately for IBM I, there's no emulator. And if anyone wants to rise up to the challenge, go right ahead. We would love to see it. And we also have some additional resources on intro list, Btrod, Genera, and IBM I right here. And we also have an IBM I hobbyist discord. We hate discord too, but hey, it brought a bunch of enthusiasts out of the woodwork. So, we can't complain. It's also bridged to an IRC channel for the traditionalists like us. And that's it everyone. Thanks for your time. Hope you enjoyed watching our presentation. It was a quite fascinating talk. And I see why you called it what we have lost because yeah, it's quite a lot that got lost in the progress of the dominance of the PC. And yeah, we got some questions actually. And yeah, I would just dive right into them if there is nothing you would like to add. Thank you. Oh, yeah. Nice. We got the third one. Yeah. Okay. Nice. So someone in the IRC asked, what does it mean for a computer to be a list machine? So it's really, to me, there's a couple of, there's two main points. First of all, on a list machine, the instruction set and entire system architecture is built around the idea of running less. And so you had features like garbage collection in microcode that you had you had hardware management of list arrangement or list arrangement. So for example, you could not tell from a user perspective, whether a list was stored as just contiguous cells of memory or an actual linked list. Integers were all infinite precision. I think that I mentioned a that this caused problems for the C compiler because size of care was one and max care was infinity. So the other feature though, which I think is more important is that all of the software on the machine is running list. There's no operating system underneath it written in C or there's no assembly component. It's all just, so if you want to replace the drivers or build a driver for some additional hardware that you've attached, you can do that entirely in Lisp. There's a tale from one of the symbolic field engineers about the fact that at one point they had a customer with the machine that was running very slowly and they couldn't figure it out and turned out that they had installed a patch which replaced a bunch of the drivers on the system. And they never compiled that patch. And so it was interpreting the driver code and it was slow, but everything just worked. And yeah, I think that's really the core of it. What about InterLisp? Well, I don't actually know that much about InterLisp. You'd have to ask TechFear. InterLisp, it seems, doesn't really do as much in a fancy hardware microcode as Genera does and I think a lot of this is because the hardware it ran on the D machines was really mainly meant to run Xerox's Mesa virtual machine. And so they kind of just hacked InterLisp onto it by coming up with new microcodes. I think they kind of just had to work within the constraints of that. So for the most part, you don't really see things like hardware garbage collection or rather microcode based garbage collection. You do see the basics though, like the fact, you know, like car and cons and such are all basically literally mapped directly to op codes. That's probably the biggest thing I've noticed from digging into the D machines. Yeah, my impression is it's basically West Coast disease coastless machine. It's a biggie into a pocket of computer science. Well put, Calvin. Well put. All right. I think we have another question. Who still uses the Beetron system and the HTML export functionality seems semi recent. So to my understanding, it's basically mostly a legacy platform at this point. It as far as I understand has a contingent of academia users, mainly humanities who tend to use it because it has better support for, shall we say, old slash deprecated congee characters. I think it's just kind of stuck with some of them through inertia mainly. And I believe the HTML export stuff showed up some time around the turn of the century give or take probably when the change over to Beetron three slash be right me slash Joe Congee, which would have been about 98 99 2000 give or take. So I think it's about when that ended up in there. All right. And it looks like our next question is what's the most recent advanced or interesting list machine? What do you think TQ? So the cheeky answer is Emacs because yes, there is a C core to it, but all of the interface functionality and all of the interaction is purely list. The answer to the question that you were probably asking, though, is that it there isn't really an answer. You've got the the generic side and the interlisp side. Don't really share any they don't share a common ancestor. List was very popular in academic and AI communities in the 80s and very early 90s. And so symbolics commercialized the first list machine, but the rocks came along and developed their own for starting from scratch and came up with interlisp. And the two we developed in parallel and didn't really cross pollinate very much. So interlisp is still maintained and it's worth and it's worth using and in particular interlisp can be used without any question about legality because it's all open source now. Yeah, a VLM source is kind of floating around that the owner of rights is still unclear interlisp is explicitly free software now. And and one thing to add, I do find it amusing that both interlisp engineer that really common the ancestor by the common sort of source platform of the PDP that PDP 10. Yes, the list classic the PDP 10. The PDP 10 is a beautiful machine. It could give an entire talk on its instruction set. Equal bait. So it looks like our next question is it really better to run the GC and microcode instead of normal code on an additional core. And that's a really good question, I think. And I honestly want to be surprised if the answer is that no, it's really not. I think that's just what made sense at the time because you have to remember, at the time they were designing all this stuff, it was just trendy to do everything in microcode. I mean, look at the Xerox Alto, it basically bit bangs all its IO and microcode tasks. Much like Xerox Media GX came back. It's not just that it was trendy. At the time, in order to get decent performance running Lisp, you needed to do it in microcode because machines just weren't very fast, right? We didn't have pipelining. We didn't have the fast memory buses that we do now. But technically, you had to buy like a free 60 model 90 or a cray one or something like that. Yeah. And there's no way that you could assign one of those to a single person. No. And the cray probably wouldn't have been that gray of an answer either because the cray is really only designed for vector calculations. Exactly. So, as it turns out, one of the big reasons that the Lisp machines died is that Franz Lisp ran fantastically on a Vax and didn't need any of the special hardware support that Lisp machines offered. Even basically risk processes, just but final nail to coffin. Yeah. And that's why the registered machines really won was they just got faster. And even, I think I recall reading that for Xerox, enter Lisp even, I think by about 87, a Sun 3 model 60, which is a 20 megahertz motor, a 680, 20 was already faster than the D machines, according to Xerox's own studies, apparently. I mean, they're pretty much every rich environment that didn't die got reported to you, basically risk score or something sufficiently risk-like under the foot. Yeah. I got that rebased onto PowerPC. As you know, interlists actually sort of got a second life running on sparks. An interlist. Yeah, it did. And GeoGeneric ran on alphas. But don't worry, we're living here in future again. Interlist still runs on arm. So I thought this next question was really interesting. What extensions would be required to a normalish risk design to improve Lisp throughput and or latency? I guess it could add like memory tagging. One IBM has would actually probably work well for a Lisp. That's a good point. Memory tagging would be cool. Point. Yeah, Xerox did that. I think the memory tagging, I think the memory tagging extensions are arms. The armor are only really good for security because they're basically more pointer signing, I think. Spark ones they don't know much about, but I think they're intended for GBMs. So yeah, less would work. The spark instruction set, or the spark extensions, as I understand, were actually specifically designed for Lisp. They give you two additional tag bits for types and arithmetic instructions that will... I believe that the arithmetic instructions trap if the tag bits aren't the same for two pointers. And so you can just do fix, you can pretend that everything's a fixed num and handle it if it's not. Yeah, sounds like it would work for JVM, but what works for JVM would probably work for a Lisp. Yeah, and what's a little known above the IBM extensions all they really do is there's no hardware enforcement, rather it's just like acceleration for basically software-based checks. So actually one feature that's surprisingly good, that is surprising at accelerating Lisp code is IEEE Floating Point. Look into Nanboxing if you haven't because it is... I've heard about Nanboxing, yeah. Yeah, it turns out that you could store pointers and most types in the unused bits, not a number. And they'll trap if you try to add two things that are numbers. Oh my god, Nan Singling. Dangerous. Oh god, that's cursed, I like it. Right? It really is. Yeah, so I'm afraid we'll have to cut it a bit here because we're running a bit short in time. No worries. So there are two questions left and one personal remark. Yeah, the one... the first one is if the Beach One situation is similar to what happened to OS2's respectively, Ecom Station? So I'm not sure if you can really draw an analogy there because Ecom Station is kind of a, if I recall correctly, the whole range of Ecom Stations, that's a OEM distribution of OS2, but it's a little bit different with Beetron because Beetron is an open specification that realistically only one vendor really made implementations of the media. Imagine if basically there's only single POSIX implementation standing. That's basically it. What he said. So and I think someone asked, when are you going to give a talk on the PDP 10? Maybe next year? Oh yeah, hopefully. I think that was then quite easy to answer. And someone personally remarked that they have a 60 page paper on the on the Tron in case in case someone was listening on the IRC, but it's in German. So yeah, if you still read it, maybe this person can... Maybe this person will be with suit your needs. Also, there was the request from the IRC to the speakers to maybe hang around a bit longer in the IRC to answer any questions there because we sadly have to end the targets here. Time slot. So yeah, thank you. Thank you for taking the time to prepare all this. Thank you for joining us from such remote locations. Thank you for standing up early or late. Wow, it's really early for us. So yeah. So thank you very much for that and have a nice remote chaos experience. Thank you. Thank you for your talk.