 My name is Guy Fedorko. I am here from the United States. I apologize. I have to be uni-lingual today. I have been working on this program for the project, for Whirlwind for a couple of years, along with the MIT Museum and also with the Computer History Museum in California. And now, of course, with HNF as well in Potterborne. What I want to talk about today a little bit is the Whirlwind machine, some of the background, and some of its architecture. And then switch to one particular application that we spent time working on as far as I can tell the first demo in the world for using a computer for air defense for tracking incoming attackers and directing interceptors. So we'll talk about that. And we can show all of the software in the demonstration down the hall. OK, so let's start. The first part, then, is about what is this Whirlwind machine. It was one of a kind research computer designed in the 1950s. It first started working in 1949 and stayed at MIT functionally until about 1958. The program was begun under a contract from the US Navy. So this was all done under the Department of Defense in the US. MIT did a lot of work during the war, did a lot of defense work, to an extent that became quite controversial later in the decades. But this was done with the Navy. Their intention initially was to design an aircraft simulator that is for training pilots. That evolved, as all good research projects do, evolved from that into air traffic control and finally into guiding interceptor aircraft. The machine itself is a 16-bit parallel architecture. This was at a time when serial architectures were all the rage. And it was designed to be fast. So this would have been one of the fastest computer on the block at the time. 50,000 ads per second, how fast can you possibly need? The project is now mostly remembered for the development of magnetic core memory. This was developed at MIT. There were a number of teams working on magnetic core. And it took quite a few years of legal dispute to agree that MIT actually, quote, invented magnetic core memory. The machine was initially built with electrostatic CRT memory. And they tried for years and could not get it to be reliable. The program project evolved substantially. This started as a small project in the Servomechanisms lab, where they had experience with radar tracking for aiming anti-aircraft guns. And eventually evolved into the US Air Force semi-automated ground environment, SAGE, which was a humongous program for continental air defense. The contract allowed MIT to use. It gave the Department of Defense the good hours during the day, but it gave MIT researchers the less good hours of the day. And they used it for many, many different kinds of applied mathematics research projects around MIT. And it stayed on campus until about 1959. The machine ultimately was, let's say, disassembled. And many of the pieces saved around 1970. But the machine itself will never exist again. It's long gone. Some of the timelines, I say they started in 44, thinking they were going to build an analog aircraft simulator. In 1945, I think J. Forrester, the program lead, saw ENIAC and decided that digital computers were the thing that they wanted to do. By 1948, I haven't figured out quite what happened. But by 1948, they decided an aircraft simulator. No, we're not going to do that. By 1949, they had enough machine running to display simple equations on a CRT display. 1951, we'll come back to this one. The first radar intercept demo. 1952, they started on SAGE, the air defense system. So the whirlwind team became the system architects for SAGE, along with IBM and a couple of other very large contractors. By 1953, they had a thing called the quote Cape Cod system, which, again, was centered on whirlwind to demonstrate some more of the SAGE technology. 1953 also was the date that they switched from a lighter static to core memory. And that is an important date in the history of the machine, because at that point, it became reliable enough that anyone could believe that this was really going to be useful for something. I have no idea how they convinced the Air Force to spend so much money when the electrostatic tubes were just not working very well. But J. Forrester, the project lead, was a very persuasive guy. And then 1959 was when it was decommissioned. This computer would work fine in a 1950s science fiction movie. It had all the things, whirling tape drives, hundreds of blinking lights, switches. You will notice there is not a keyboard in sight. They did add a keyboard quite late in the program project. This is J. Forrester, who's the project lead. This is Bob Everett, who is the guy who keeps the trains running on time. This often happens. This pairing often happens in these kinds of computer projects. This is the guy who's got the big ideas and can't quite remember how to tie his shoes. And this is the guy who says, boss, yeah, OK, good. Yeah, we're working on that. And could you go away while we're, and don't think up anything else just right away. This woman I know whose name is Romana, but we don't know anything much more about her. But that is sitting in front of one of the larger CRT displays that they used. The machine itself, people in this room probably have heard of digital equipment, deck computers. Yeah, OK. Ken Olson was one of the engineers on whirlwind. So he was a junior engineer along with Harlan Anderson on whirlwind. And by about 1957, I think, had left whirlwind because, you know, like, hey, we could start a company. And so I think you will find the architecture looks spookily familiar. Sage also was, once it's turned into Sage, IBM took a very large role in designing the equipment and consequently, while the 701 was designed following von Neumann, 704 and on also has whirlwind influence. So the architecture is familiar because almost every computer we have has lineage back to either IBM or deck. The machine was a very straightforward von Neumann machine, what we would now recognize as von Neumann. In fact, von Neumann visited the whirlwind site a number of times. We've seen his name in the visitor log. The standard thing, memory, program counter, one accumulator, a second half of the accumulator for 32-bit numbers, a boot ROM, which was 32 words of toggle switches. So we would literally toggle the boot ROM and then push the start button, and it would jump to zero and run. And then quite a large list of IO devices which continued to grow. There's the IO instruction set is much more complicated than the computing instruction set for this machine. Because of the real-time focus, they kept on bolting on more stuff. This audience will be well aware that computers used to be kind of big. So this was one machine about 2,500 square feet for the computer itself. Sorry. That would be the ALU. So a 16-bit ALU was 16 racks, bit slice machine, very ahead of its time. This was five registers of programmable memory made of vacuum tubes, and then the rest is control and all that stuff. When they added core memory, some of this stuff went away, of course, to put in the core memory. The basement of the machine was full of power supplies. The first floor of the machine had the drums and some of the other peripherals, and then this is the second floor of the machine. This was built in a building at MIT called the Bartha Building. And the building is still there, and it's right across the street from where the MIT museum used to be. It has been renovated many times and is now occupied by a pharmaceutical company. But there's an IEEE plaque on the building to say this is where they built whirlwind. Again, this audience would be well aware of this, but most people I run into and say, wow, it must have been really big, bigger than a refrigerator even. I said, yeah, it's bigger than a fridge. Yeah, a lot bigger than a fridge. The I.O. system, there was the usual stuff. They used a machine called a flexorider, like a teletype machine. Paper tape was the medium of choice, the original source for all of the software that went into the machine. They added tape and magnetic tapes early. They added drum storage a little bit later, and they added a line printer later than that. The not-so-familiar stuff, as you saw, there are not only in the control room are there hundreds of buttons and lights just to see what's going on, but the actual operation of the machine was focused around buttons and lights. It's in their view a real-time application. So you've got consoles with guys sitting at the console with looking at buttons and lights and looking at CRTs. There is the graphical output capability, which Reiner will talk about a little more, that was intentionally designed from the start for drawing images on a CRT. So this is not a character-oriented display. What they do is literally, they draw lines and dots. The CRT system also, there was a camera attached so that you could get hard copies of your output. And if you wanted to do a core dump, in fact, they would cycle through core on the CRT and flash it with a camera because the printer was not there. The second unusual thing is the so-called light gun, which we would call a light pen, which anyone outside of this room would recognize as sort of like a mouse, right, for pointing at the screen and in indicating points. They developed this, this is less known and quite unique, but developed mechanisms to connect to remote radar stations across telephone lines. So it wasn't exactly a modem, but they did encode radar signals, digitize radar signals on telephone lines to get from a couple of radar stations tens of miles away back to this BARTA building. And then a bunch of other specialized interfaces. Again, developed for SAGE, for multiple sites. Cross-tell, I think, is the buzzword for my computer. My sector tells your sector, hey, there's a guy coming your way you might want to look at. So this would have been a picture of, you know, one of the CRTs. I originally thought this looks like a prop, but I think it really is the real thing. There was a little story that they said they hired a local woodworker to make the display for, or the cabinet for this display, and he accidentally made a thing which was, looked too much like furniture, and they said, oh my God, the Navy is going to kill us for wasting money. So they had to paint it gray so it didn't look too nice. This would be one of the original light guns. The museum in California has a number of these. I would love to know what's inside, but we have not convinced them to take one apart yet. By the time IBM was involved, the light gun had evolved, and the IBM industrial designers knew how to make stuff. To me, this picture illustrates why the Navy, or the Air Force liked MIT because they could get new stuff that no one had ever thought of before to work, and they liked IBM because they could make stuff, and it would stay working. Whirlwind was a continuous science experiment with stuff coming and going and working and not working and all kinds of things. They were very interested in reliability and worked hard on it, but man it was tough and they didn't have the right environment for manufacturing. Okay. Reiner will spend more time on the graphics system. I just want to say the underlying principle is extremely straightforward in a way that people who are accustomed to modern graphics have a hard time. Sometimes understanding is how straightforward it is. All they did was take two digital to analog converters, one for X, one for Y, connect them to oscilloscopes, and then a couple of bits put 16, some more. Anyways, in our case, we are only using two to modulate the Z-axis to turn the bit on and off. So if you want to draw a point on the screen, you set the D2As to the point you want, and then you flip the Z-bit and it will display the point when the Z-bit goes away, then you move the beam somewhere else and display another point. That's all there is. The good news is you don't have to do garbage collection. If you want to erase the display, you just stop and it's gone. This is a little hard to emulate, but that's what there was and that's what Reiner's kit does. Again, this will be quite familiar for this crowd, but the whirlwind, I like to tell people it's like an Arduino except slow, but the approximate memory capacities are similar. There's the 2K words of RAM, 32K words of drum space, sorry, 48K of drum space. The power is a little different. The third column here, at the time, if you wanted to do a large calculation, what you did was you hired a room full of computers, that is people who were quote-programmed to do steps in a repetitive calculation of some sort. The United States had a thing called the math tables project during the Depression, and at one point had 450 people, computers working on a single tables project. Curiously, 450 people, aside from what you have to buy for lunch, adds up to about 60 kilowatts of power. It's in the same ballpark. That makes 50,000 ads per second look really fast, and that's of course, we all know why this was a ground changer. Whirlwind was also expensive. It consumed at one point 80 percent of the budget of the Office of Naval Research, and the program had a bit of an existential crisis in about 1951, where the Navy said, where is our aircraft simulator? MIT said, well, here's this computer. It's really cool. You'll love it a lot. The Navy said, excuse me, where is our aircraft simulator? Fortunately, at that point, the Air Force, fortunately for whirlwind, not the rest of us, in 1949, we'll cover this again, the Soviet Union tested a nuclear weapon, and the Air Force was going, oh my God, what are we going to do? It picked up funding for whirlwind to change the focus to air defense. But one reason I can say with some confidence that this was the first of something or another is that the program was so expensive, there could not have been another one. If it uses half the budget, then there is not another one bigger. Okay, so what is this project about? What is my project about? The MIT, it's not just the museum, the MIT and its archives have many whirlwind documents. As a Department of Defense project, they were required to submit reports all the time. And so there are many, many documents. The librarians list gives 8,000 of them. I know about 2,000 exist. The Computer History Museum has hundreds of tapes, paper tapes and magnetic tapes. And of course, two sides of the country, oops. Well, okay, so what do we get if we put these together? There are some physical artifacts around, but not very many. So there's not a lot to learn from that, but there's enough that you can see kind of what it was like. So the question of course, can we combine all these resources and learn something about the evolution of this machine? And can we somehow make this material more accessible to non-specialists? The tapes in particular had been sitting on a shelf in the museum for 50 years. And it occurred to us all that it sitting on the shelf, they weren't actually helping much. And so they have been read and we're gradually interpreting them. How did whirlwind programmers program? People often say, oh, that must have an assembler language. And I'm saying, yeah. It was in the early stage of the program, it was pencil and paper. So you, the programmer, see it was a multimedia graphical presentation with sketch comments. Yeah, so you would write out your program on a coding sheet if you were lucky and then hand it to a typist who, you, the programmer are probably responsible for turning this into octal code and then handing it to a typist who is responsible for turning the octal into flexo codes and typing it on a paper tape. So you'd write it out on a coding sheet, type onto paper tape. The programmer gets a scheduled time slot, runs it, it crashes, you go back and try and figure out what to do and hope that you get another run that night. They, the project was structured in two parts. There was the primary application component of the machine, of course, for developing the use of the machine, but the Navy continued to fund development of tools for search. This was at a time when everyone was coming to the realization that, uh-oh, these things are hard to program. We better think about this. So the quote, automatic programming was all the thing in the mid-50s. And at the time MIT was one of the three major contenders in how should you program computers. So they rapidly developed an assembler and then gradually made the assembler more sophisticated paper tapes. This, of course, carried through to the DEC world and as soon as IBM was involved with SAGE, whirlwind grew a card reader. Okay, so of the software media, all of the, as far as we know, all of the tapes have been read. They're posted on BitSavers, so CHM read them, Al Casso posted them on his BitSaver site. We've read about 60 of the 100 magnetic tapes. Magnetic tapes, those are much harder to figure out. Some of them, some of the both, the formats are obvious and we are using some of that material. Some of them I expect we'll never figure out because they're data tapes for some application that we can't figure out. But there's still a lot of decoding there. And of course, what we have been doing the way this works is we can sometimes link a document on a program with the actual code of the program. So the Air Defense one is an excellent example of that. There are a few others where we have an actual document which describes the functioning of the program and then we have the program itself. I haven't found the index for the tape department. Documents, yeah, it's 8,000 titles. 1,800 of them or so are on MIT's site. Al Casso has about 280, some of them overlap but there are actually some that are unique on Al's site. The Smithsonian, this is a problem, has 30 boxes of these documents and I have an index and have looked at some of them but that's a lot of stuff. And there was a whirlwind project photographer who spent, I don't know, he's literally full time but there was a guy who spent during the decade his career taking pictures of things in whirlwind. Okay, in my project, I have developed a tool chain to help reverse engineer and then re-engineer some of this code. The general flow, we start with the binary tapes and some of the source code tapes now, those are hard to use in a different way. So decode the tapes, disassemble the binary objects, the machine instruction set is very straightforward so rough disassembly is easy enough. I can then add comments to the assembler code if I can figure out what it does, reassemble that and run the image in a simulation environment. And of course the trick here is to go around this loop 100 times to run it and say, what the heck is that doing? Oh, I see, go back and comment the code some more and insert a debug assistance along the way so that you can start to understand the function of the program. Here is a sample runner can run this on the display in the other room. We came across this tape, Chad Blackjack written on it. Blackjack is a card game, also known as 21. As far as we can tell, this was a completely unofficial bit of work. We have not found a single document that even mentions it and the structure of the code looks like a mess. So I suspect it was graduate students at three in the morning who were just figuring out how to use a computer, but it does play a respectable game of Blackjack. It uses the light gun. So there's again no keyboard interaction, but you hit points on the screen to make it do things. So the one on the top right, for example, shuffles the card deck. These are the two critical ones where the player can say, I want to play the next card or you play the next card and at that point, you can tell who's one. So this code works. You can see the character generator is a seven-segment vector generator, so it doesn't, you know, there's no rasters, there's no bitmaps. All you can do is draw any combination of the seven different segments. So sometimes they have to get a little creative in how you make a character. That does not say C-A-A-D-S, of course, that says C-A-R-D-S. Okay, I want to switch topics now to the air defense application. Okay, we know about the machine. This application, there was, of course, the Soviet test in 1949, which has people who have seen the movie Oppenheimer might know the US government had declared to be not possible, and suddenly when it was, it was, oh, so MIT had all of these defense connections and the Air Force sponsored a competition. I'm not sure whether MIT's thumb was already on the scale or not, but there was a competition for what should we do for air defense for the continental US? And MIT, of course, responded with what you need as a computer, and we happen to have one, and it's, yeah, it's kind of expensive, but don't worry. And of course, SAGE ultimately became a very large program, I think at the time $30 billion went into SAGE. Okay, so in 1951, there's a guy named David Israel who was part of the whirlwind team and I think spent his entire life working on radars, computers, and airplanes, but he assembled a demo which was intended to steer an interceptor aircraft towards a target aircraft. I can't help being amused that they officially started work with radar and airplanes and computers on air traffic control where of course the goal is to make sure they do not collide and switched the sign bit and changed it into air defense where the goal is to make sure they do collide. So we'll see the goal of the program, of course, is for the radar operator to be as if that's the target, that's the attacker, that's the defender, go get them. The document which describes this is unusually straightforward and clear in modern times, you'd say, well, of course, that's a functional spec you described the problem. They did the mathematical analysis, a software flowchart commentary on the code and then the actual code. The astonishing thing is that this fit into 256 words of code, that's all there was at the time. This was in the era before they had the magnetic core and the electrostatic memory was very troublesome. So they had a small amount of core of main memory to work with and used every word. Okay, so here's the scenario for how you use this thing. The assumption is that you have a radar station, there is a target of some sort that you think you're trying to defend. There are aircraft in the vicinity, the radar operator, of course, the radar operator has to know somehow which one is which because that's what their job is, is to figure out who is the attacker and where the defenders are. So all they see on the screen is there are, there are blips here and there. In this scenario for this simulation, I know that this guy is the interceptor and these two guys are attackers. And so in my simulation I set initial conditions for these guys where both of the attackers are heading for a target which I have arbitrarily placed at the northern edge of the screen. So what the operator is supposed to do is watch the scopes for incoming attackers. There's again switches, buttons and lights. So you switch the switch to say, I see an attacker and you use the light gun to point to the attacker and say, computer, this guy is an attacker, watch him. And then you switch the switch and you tell the computer, computer, this guy is the interceptor I would like to use right now. Follow that please. And when the operator has identified both of them, then the computer can compute a heading, a direction to fly for the interceptor that will cause the interceptor in not exactly the most efficient way, but as close as they could get to efficient to bring them close together. And once they're within a mile or two, then the guy in the whirlwind control room can take a break and it's up to the interceptor pilot from there. It displays as we'll see, it displays on the scopes, on two oscilloscopes, one all of the radar traffic and on the other oscilloscope, the two that it's actually tracking and trying to converge. As the program runs, every radar scan, it will compute a new heading because of course the target, the attackers might say, hey there's someone come at me, I'm gonna change my course. So it continuously updates the heading for the interceptor to go towards wherever it thinks the attacker is going. The resulting heading is displayed on lights, of course, in binary coded decimal. And the radar operator's job is to read off the headings from the whirlwind and talk on the phone to the pilot to say, yo dude, the new heading is 329 and the pilot steers to 329. So that's the way the program works. In our environment, what I wanna try and do is help see which part of this is actually real code in which is the substantial simulation environment. So the real code is running, of course, in the simulated whirlwind, as I said, there are only 256 words of this stuff. So underneath this is, of course, is a straightforward whirlwind instruction simulator along with the simulated buttons and lights and stuff. On the right hand side, then we simulate the graphical system, Reiner's system is a little bit closer to real with the hardware, but that's our modern interpretation of it. It's a little more complicated. On the left hand side, there's, in my simulation environment is the radar station which transmits headings and azimuth across the telephone lines. So this simulated radar station acts as enough like the real radar station so this thing can interpret the codes. And then ahead of that are the simulated airplanes. So I set the initial tracks when the whirlwind operator reads off the lights to save the heading, then I'm feeding the interceptor headings back into the aircraft myself. So I am not making Reiner read the numbers and steer the interceptor. So there's a lot of stuff here, but this piece of code in the middle is running unchanged. There were, as usual, a couple of typos, but other than fixing the typos, it's running as it did in 1951. And I can't help but point out the stuff around is 50 megabytes of stuff to connect to a 256-word program. Jay Forester would say, you are out of your reeking mind to waste 50 megabytes. Okay, this is what the air defense screen looks like. This, to me, has been completely vexing. This is one of the most in terms of the development of the air defense application and real-time computing. This has to be one of the most significant demos that was ever done, right? This would have been just jaw-dropping at the time, right? There would have been generals and stuff watching this to see real airplanes flying real flight paths with real radar stations, with a computer in real-time saying, pilot, steer this way, and they would watch the radar and they would intercept. In modern terms, as a demo, this is the most boring thing you've ever seen because when you look at it, it's just a couple of diets moving across the screen. So it's a little hard to get this across in a live demo, but you can see how it goes. Again, I do this with one screen on the laptop. Runner has two screens, so he can see the entire radar situation and then the two tracks, the two airplanes are being tracked as they converge. There's my own output there to help us figure out what the heck is supposed to be, what's going on. So this is the heading that whirlwind is computing that would be in BCD 330, 330 degrees heading for the interceptor pilot. And in the real code, of course, when they intercept, nothing happens because they're just watching the radar. So if the interceptor pilot is good enough to down the attacker, then one of the blips would disappear, otherwise they'd just fly off and go home. Oh, and the interceptor pilots were not allowed to down the attackers. It was against the rules. And in fact, they flew at different altitudes just in case it worked. Because the attacker pilots wanted to get home at night. And I read which aircraft they flew. I don't remember, they were not exotic airplanes. A curious thing is if we actually analyze the results of this tracking program, if I don't mess up, if I don't mess with a thing that the attacker, of course, stays on a completely straight path because that's the way I programmed it, the defender should intercept here, but actually intercepts a little bit further down. And I'm still working on figuring out why are these not quite right. I know part of it is an artifact here where it starts out thinking its interceptor is roughly zero velocity, which of course, if the interceptor is zero velocity, you've got a long way to go before you're gonna get an intercept. So it starts out too far north and then correct, but I don't know why it doesn't come closer. That's one we're still trying to figure out. Okay, so let me start to wrap up here. A key observation, of course, is it works. It's not quite optimal. I'm not sure why. Because of the way the code is structured, not only does it use the 256 words, but you can tell they had to work at it to get it to fit. There are various things in there that surely no one would do unless they needed one more word somewhere else. So I assume there are approximations in there that I don't understand yet. Ironically, the trigonometric functions, signs and cosines and tangents, all seem to be accurate, which is surprising in such a small piece of code. One lesson that I would draw from this is, whoa, this must have been just misery to debug. I have no idea how they did it, other than the obvious thing of banging their heads on the wall a lot. It's a real-time program, and they didn't have any debug framework. There wasn't any spare memory to put handy print statements in, and the printer is too slow anyways because if you printed 10 characters, you'd miss 20 radar readings. So we know that they ordered a couple of analog multi-track recorders, tape recorders, so they could record the actual flight tests and play them back over and over again. But it still must have been just total misery debugging this stuff. I can only expect that they had quite a few graduate students who got locked in a room with a source code and not let out until they could manually work through every instruction and demonstrate how the program was supposed to be working or not. I think the code review would have been more like hardware design than what we think of as software design. But I oddly have not found a lot of material on how they did that stuff. I think it was just part of the landscape. Of course, it's miserable. What can you do about it? What I want to do going forward then is to try to follow the development of this air defense application. This demo obviously was influential and somehow eventually became sage and there must have been a lot of stuff that happened in between. I'm trying to see how the impact of this work spread. On a completely different thread, there's quite a bit of material available on their development of this automatic programming environment. They eventually ended up with something that looks a little bit like an operating system that most of the whirlwind material is bare metal code. Eventually, they got to a point where they didn't actually have to reload everything every time. Someone wanted to run something and I think it would be interesting to dig a little bit harder through that stuff and understand a bit more how the machine was used for the other applications. That is my favorite picture from the whirlwind photo archive. It was scheduled for June 1st, 1959, but as a shutdown, they actually turned it off a couple of days ahead of that, I think, to avoid any accidents. Okay. The documents, the bit savers, of course, is well known. MIT whirlwind is the place to look. MIT is public. Many of the tape images, all of the paper tape and some of the magnetic tapes are on bit savers and I have a GitHub site with the simulator. Reiner will talk about this in more detail. Reiner's focus has been on the vector interface, the actual graphical interface part of this stuff and has together produced two things. One is the underlying interface mechanism that is spliced into my simulator so that we can run real whirlwind code and display the results. But Reiner has a number of programs which are modern programs written to exercise that and demonstrate the graphical environment. So this menu is from a program dispatcher that projects on the screen and you can use the light gun to say, I want to run number nine and number nine is linked to the whirlwind vibrating string demo. Okay. With that, I think I can stop. Do you want to switch to yours? Okay. Yes. Oh, thank you. Oh, the remote microphone. Yes. So you had this diagram with this flow chart with the simulator on one end and I think the input on the other end in any case. So you have all of these. This code that you've recovered on a... This one? Or the tools flow? I think it was. Yes, this one. So you've recovered all of these tapes, all of this code which you've recovered imperfectly but also the simulator. I mean, how can you know that the simulator is a match to what the actual hardware was? Is there any uncertainty there? Yes. How do we know the simulator is simulating the real instruction set? In fact, of course, at some level that's a bit of a metaphysical question because the instruction set itself evolved. Fortunately, not much. There was a major change in the instruction set around 1952 and after that it stayed quite stable. There is a document, thank God, it survived, published in 1958 which is the definition of the instruction set for programmers and that document, I think, had been evolved and reviewed and evolved and reviewed for years and I think we found it to be very accurate. There are a couple of areas that seem suspiciously vague so where we might not have quite the right thing but fortunately the later instantiation of the instruction set is quite well documented. The tapes have quite a few diagnostic programs, some of them we've been able to get to work and of course that's a clue as well that if the diagnostics run then it probably runs. I have been surprised that, again, when the instruction set is very straightforward there are only 35 instructions and there's only one addressing mode. One's complement arithmetic is not fundamentally that hard but it certainly introduces a little bit of confusion here and there but other than that I think it's been relatively straightforward to decode the instruction set. I don't think it's a bio system, not so much but that's what we use as confidence for the thing. Other questions? Is this your personal private work or are you funded by something? Money? I don't know whether we can talk about money in a place like this. What is the diplomatic answer to that, Reiner? Yeah. The support from the museums that you mentioned and most of this I think is your private enterprise. Yeah, let's leave money out of it but it is done in conjunction with the three institutions and MIT has been generous enough to provide work space and so on so I spend three days a week at the MIT Museum on this and other related stuff. All questions? Okay.