Advent of Computing - Episode 162 - CSIRAC, Australia's First Computer

Episode Date: August 10, 2025

In 1949 CSIRAC sprung to life in a lab in Sydney, Australia. It was a very early stored program computer. All machines of the era were unique. But CSIRAC, well, it was very unique indeed. Selected Sources:  https://cis.unimelb.edu.au/about/csirac/music/reconstruction - The Music of CSIRAC https://sci-hub.se/10.1109/MAHC.1984.10014 - Pearcy and Beard on CSIRAC

When we talk about early computers, the language tends to get kind of nitpicky. And as an example, right there, I already have something that I would need to quantify. When I said computer, I meant, of course, stored program electronic digital computer. You know, the kind that we all love and use today. Once we get past, oh, 1955 or something, we don't really need to say that. But early on, we do, because there are machines that are not stored programmed electronic digital computers. So we can't just say computer. That would be vague.

Now, that can sound very specific, right? For most of history, we are dealing with machines that store programs and memory act on those programs and do so using digital signals carried as charges over wires. That could make it sound like all computers are kind of just the same thing, right? But of course, we all know that couldn't be further from the truth. Even within this very specific definition, there's a lot of space for diversity of design. Just compare, say, an Apple 2 and an IBM System 360. Those are both stored program, electronic, digital computers,

but their designs are wildly different in just about every way. Now, let's do my usual rhetorical trick that I love so much. This restricted field in later history has all sorts of different machines, right? Well, what if we turn back the clock? Then, dear listener, we see even more wacky and wild examples of the art. Once we get back to computing's first decade, roughly 1945 to 1955, we see some truly interesting machines. This is the period where you do have to be careful with your language. This is when we get to see machines with memory and machines without. Machines that can be programmed with code,

next to machines that can be patched together with cables. We even see beasts that can't store their own programs. Imagine it. The field is in such a state of flux, the computers will have deep fundamental differences. Their very principles of operation will differ. What do those differences look like? And just how far can you stretch the design of a stored program electronic digital computer? Well, luckily there are some interesting examples for us to look at. Welcome back to advent of computing. I'm your host, Sean Hasse, and this is episode 162, Cizirac, Australia's first computer. And I'm back. I went on a little bit of a break while I was getting ready to go and then going to VCF West this year. I had a

great time. The Vintage Computer Fester pretty much always a great time. I also managed to unload a whole lot of CPM hardware that I had around that I wasn't using. So, So if your loved one ended up buying a bunch of CPM hardware from me, thank you. It's a huge load off my car's suspension, and it gives me a little more space. Now, I gave a talk there on my LGP30 emulation project. I actually am looking at the SD card with my recording of it on my desk right now. I'm going to be posting that on the Patreon as a bonus episode, along with a PDF of my slide deck. When I do these talks, they're pretty visual, and I only have equipment to capture the audio, really?

So, as far as a public release, I'm going to be waiting for a few months because the showrunners at VCF West will be putting out a video that has an actual, you know, visual component. But if you want to get the audio early and look through my slides, a nice little portable PDF, you can get that on my Patreon. Links to my Patreon and everything else are on advent ofcomputing.com, if you don't already know. Now, to the episode. When I produce these episodes, I like to think of them as each having some learning outcome or some larger question. That's how I tend to focus my topics. But that doesn't always exactly fit with what I want to do. While producing last episode, I ran into this odd machine called Cizirac.

That's C-S-I-R-A-C. It sounded neat, so neat that I want to learn more about it. So, I guess you could say the learning outcome, roughly, for this episode is let's learn more about Cizirac. It's pretty vague, I know, but let's at least pretend to be systematic here, shall we? Cizirac is the Commonwealth Scientific and Industrial Research Automatic Computer. It's the first computer built in Australia, and it's a first-generation vacuum tube. computer. I first heard about this machine because a random report from Rand Corp claimed it was

based off the IAS machine. That is incorrect. This iserac is very much its own machine. Better still, it's a very unique computer. Its design is, in a word, kind of complicated. It uses certain approaches that I'm just not familiar with, which is cool. And in a strange twist, it has a truly wild number of registers. Again, seems pretty unique. So right there, we have a good starting question. What was Cizirac inspired by? What early digital DNA can we find in this machine?

That in itself will be a very interesting line of inquiry because of the time frame. Cizirac starts running in 1949. That's incredibly early, so there aren't many places to draw inspiration from. Perhaps this is even a case where there isn't inspiration. That would also be pretty cool. Besides being so early, Cizirac has another claim to fame. It was supposedly the first computer to play music.

Now, that's a pretty bold claim, and one we should be able to track down the truth about. So, like that, we get our second big question of the episode. And finally, my perennial question, what was it like to program this machine? Cizirac is a pretty isolated computer, and this is so early that we don't have established practice around programming. Heck, we don't even really have established cultural norms for programmers yet. So we may get a chance to look at programming in a very primordial state here.

That sounds like a pretty good plan for something ad hoc, doesn't it? So, let's start our investigation of Cizirac. Very early on, computers formed as a combination of a few existing disciplines. On the one hand, there were a pile of physicists and mathematicians that were chomping at the bit to run calculations. On the other hand, we're more practical folk. In that broad category, we get a surprising number of radar engineers. ENIAC is a great example here.

Its two primary designers were John Eckhart, a radar researcher, and John Moutchley, a physicist. The connection between radar and early computers could sound kind of strange at first. I mean, what do the two have in common with each other, right? It mostly comes down to specific technology and components. Radar systems were some of the most complex vacuum tube circuits of the 1930s and 40s. It turned out that, despite their shortcoming, vacuum tubes were the best early option for logic circuits. So there's that technological crossover.

Radar systems also employed memory. Delay line memory, as in mercury delay line memory, was initially developed for radar systems. So when the idea of logic circuits with memory comes up, well, radar is right there with every tool you need. Just speaking practically, this is very different than earlier computing systems. Analog computers did exist and were in use prior to the digital revolution, but these systems were just too technologically different. Vannevere Bush, the grandfather of hypertext, was originally a huge guy in the field of analog computing. When digital machines took over, He chose to leave the field, in part because his analog skills weren't transferable to the new digital regime.

Some analog peoplin techniques would carry over, but that lineage wouldn't have as much of an impact on digital computers as radar would have. Really, when you get down to it, I think it's just a matter of the vacuum tube. A differential analyzer doesn't have a tube in it. A radar does. You may have noticed that all the examples I've given so far are American examples. It's true that a lot of digital research in this period was happening in the States, but progress can happen anywhere. It's in this early period, around 46, that a duo of researchers in Australia start designing their own computer.

And wouldn't you know it? They were both radar engineers. The first of the duo was Trevor Piercy. He was born in 1919 and graduated from Imperial College London in 1940. While there, he studied physics. After graduation, he took up positions researching, well, radar. Specifically, he was working on microwave optics and something wave guides. I'm sure it's very interesting, but I'm a theory guy when it comes to physics,

and this stuff is on the very edge of my understanding. In 1945, he left England to return to Australia, where he grew up. He had been offered a position at a radar research outfit in Sydney, at the Council for Scientific and Industrial Research. The timing here is interesting. I'm pulling from an article written by Piercy and Beard, who we will meet later. According to that account, Piercy had been talking about the, quote, possibility of using a electronics for fast computation. This would have been prior to September 1945.

Piercy, at this point, was completely out of the whole digital loop. All computers that existed, all digital computers were state secrets at this point, so he had no idea what was being developed. On his way to Australia, he made a stop over in America. He arrived in the States in October. and spent a few months in New England. While there, he met a man named Howard Eichen and came face to face with the Harvard Mark I, one of the earliest computers.

Also, just to tag this again for my notes for later, he would have very likely met Grace Hopper during this visit. Your network is truly your net worth, in other words. Anyway, here's what's crucial. This was Piercy's first introduction to electronic digital computers, and his only contact for a number of years. He did see some differential analyzers, which he was already familiar with, but the only digital machine he saw was the Harvard Mark 1, or the IBM ASCC, if you prefer. At the time, Inniac was still classified. Disclosure wouldn't come until 1940. Colossus was actually classified until the 1970s, and he didn't travel to a honky talk

just over the state line from Iowa State University. So what we have here is, in a neat way, near isolation. Piercy is shown this one glimpse of digital computing in a very, very early state. He's read some of the very early work around the topic. Some preliminary work that's before functional math circuits. And that's it. Then in December, he finishes a trip to Australia and starts his new job. To me, this actually feels kind of similar to Conrad Zeus.

At least, there's a rhyme for me here, I think. Zeus was isolated from the rest of the world, first due to his own hardheadedness, and then due to the Nazi regime. he develops multiple computers from scratch in total isolation. Oddly enough, he also learned that the Harvard Mark 1 existed at one point, but the difference is Piercy had this initial point of contact and then goes into a phase of isolation.

Once he was in Australia, Piercy set to work, and by 1946 he was already planning and designing his own computer. It would seem he had been bit by the digital bug. This is where Radar Engineer No. 2 comes into the picture. Maston Beard. He had stayed in Australia for his education, earning a degree in Sydney in 1939. He would have been around the same age as Piercy. I bring this up because the duo were in their mid-20s when they get into computing.

During wartime, Beard had worked with, surprise, surprise, radar. After the war, he returned to work at CSIR, the same outfit that Piercy just got hired for. Once there, he was studying radar range-finding systems. As in, he was looking at the physics of how waves bounced around between surfaces. By 1947, Piercy was well on his way to building a new machine, and Beard would join the project. Piercy would blaze along and finish the designs, while Beard would be the main engineer. This is where we reach an interesting juncture. INIAC is publicly revealed in 1946,

but it's not until 1947, once designs are well underway, that the team at CSIR learn about this machine. The design of the new computer called CSIR Mark 1 at this point was finalized in late 47. What would usually happen in this story, And what I expected, at least, is that Piercy and Beard would next hear about the EDVAC report and then base their computer off the very detailed design in that paper.

That's kind of the natural starting point for a lot of very early computers. But that's not the case. INIAC seems to have had very little influence on the Mark I. Neither did the EDVAC report. Rather, it seems. that an earlier contact trumped both. The CSIR Mark 1 is, in an odd way, based off the Harvard Mark 1. Now, allow me to explain.

For this part to make sense, we need to talk architecture. We also need to straighten out the names. The CSIR Mark 1 is eventually renamed CSIRAC, or as I will pronounce, announce it, Cizirac. That's our Australian computer. When I say Mark 1, I'm going to be referring to the Harvard machine, also known as the Harvard Mark 1 or the IBM ASCC. I hope that helps keep things clear. The first working digital computers were very different from modern machines. I've heard INIAC described as an electronic version of a differential analyzer, and I think that hits pretty close to all of all things considered.

The Mark I follows this pattern of, well, lack of pattern. It was programmable in the sense that it wasn't exactly programmable in the sense of a stored program computer. Rather, instructions were punched onto paper tapes. Those tapes were read as a program. Crucially, these programs were not stored in memory. The actual instruction format is also very different compared to modern machines, but there's something subtle there.

The Mark I's manual describes the instructions as consisting of three arguments, A, B, and C. They are described as in, out, and miscellaneous. And yes, we do have a tradition of bad documentation. this is some early evidence of the formation of that tradition. So let's say you're a modern programmer and you work with machine code all the time. For the sake of argument, let's also say you have a 300 IQ and you drive a very nice car. Good job. You may assume that this is pretty normal.

You have a source and a destination plus some other field that must be like an operation. That's how most computers work. So what's the big deal? If you want to do an addition, you'd just write add X to Y, just like on any other machine. The only difference that you can spot is you'd have to switch the order up. So it would be like X, Y, add. But that's fine. That's not too out of the ordinary.

But not so fast. For this to make sense, you need to know something else about the Mark I. It's built around two buses, the in-bus and the out-buss. Those buses are connected to a pile of different data storage locations that are, in some cases, special. There are multiple different types of connections between those buses. So, better described, the instruction set is actually something like move data from location A to location B via some pathway called C. This means you could, say, move a value from some register to another, and invert the value

along the way. Not all sources and destinations are equal. Many were counter registers. When a value is transmitted to one of those registers, the value is added to the location's current value. Some locations were constants stored on paper tape. To construct a program, you end up shifting values around from one special location to another, sometimes carrying out certain types of transformations during those transfers.

This is very primitive, but we can still recognize some core features here. On a very low level, all computers work like this. You have special locations like registers for an arithmetic circuit or a memory buffer. You'll have buses for moving data around and some way to trigger that movement. But this is very low level. I'd say that the Harvard Mark I's programming language is below machine code. This is closer to microcode, which you don't usually run into anymore. That's the code that defines how a chip works that isn't normally accessible to a programmer.

How does Cizirac compare to the Harvard machine? Well, they're a lot closer than you might assume. There's this set of core statistics that are used to talk about computers in brief. I think of it like a digital trading card. The top line stats are always things like, how much memory does it have, how fast is its clock, how much storage does it have, and what kind of I.O. devices are we dealing with? That's enough to make some fast comparisons and grab a few factoids about the machine. Getting just a little deeper, you have things like word size, register

set, and instruction format. Those are still vital statistics and defined for basically every computer out there, but it's a little more nerdy. For me, though, that's the real meat potatoes. Those are the little factoids I actually want. Let's just think about register set for a minute here. A register is just a small chunk of memory that usually stores a single number. It's the computer's most immediate working memory. Registers are wired directly into things like math and logic circuits. It's where you do math or do bit manipulation, since traditionally you can't operate directly on an address in memory. That means that, very generally speaking here,

the register set will tell a programmer something about ease of use. It's basically what your working set of data can be. But you can't just throw out a number. You can't just say, I have 10 registers, or I have five registers. That does not tell the whole story. Registers are usually special purpose. Let's take my beloved LGP30 as an example. That machine has three registers,

an instruction pointer, an instruction register, and an accumulator. The instruction pointer points to the address of the current instruction being executed. That isn't really accessible to the programmer because when you change it, that alters the flow of your program. Technically, the jump instruction does just that, but you can't really read and write that register on the LGP30. The instruction register is only used internally by this computer. That's where an instruction is loaded while the computer is decoding it. You can't actually write or manipulate that register because it would break the machine.

It's truly for digital eyes only. Then we get the accumulator. That register is usable. Specifically, it's the destination for all math operations. If you run an ad operation, its results are put in the accumulator, for instance. So for the programmer, your time is spent moving things between the one accumulator and memory. The issue here is one of space. To do any kind of numeric manipulation from ads to divide to bit shifts,

You have to load that number into the accumulator. That's pretty common as far as computers go. The LGP30 only has one register that can do this. So you end up juggling numbers around in memory. Most of your operations are actually setting up for a math operation. Generally speaking, old machines tend to have fewer registers. The IBM 704, as another example, also had one accrued. accumulator. That was helped along by three index registers and some supplemental registers,

but you still have to shuffle to do math. Later processors, like the 8086, have many more registers that can be used for mathematics. Specifically, that chip had four general purpose registers and two index registers. That's a lot more space to work with. And as someone who's programmed for the LGP 30 and the 8086, I can tell you that 8086 just feels more spacious. The broad stroke here is that as machines become more sophisticated, they tend to get more registers, which makes programming a little nicer at the cost of hardware complexity. Cizirac, however, doesn't roll that way. Again, this is its own machine, which is delightful and fascinating to me. Cizzerac is one of those anomalies that makes broadstrokes very dangerous to

paint. This computer, designed in the late 40s, had 27 registers. 27! That is much closer to the complexity we see in mainframes. But even then, the IBM System 360 mainframe only had 21 registers. This is one of the reasons that I was initially so interested in Cizirac. This either speaks to a highly sophisticated machine or just a straight-up different approach to design. So, which is it? Let's go back to basics for a second.

Remember that not all registers are created equal. That is especially true on Cizirac. Let's run down the list and see what's up. First, we have an accumulator. Cizirac is a 20-bit machine, so we have a 20-bit-wide accumulator. That's needed so that everything lines up correctly. Then we have what's called the auxiliary register. This can be used as a general-purpose store, and it can also be connected to the accumulator.

That allows for 40-bit math operations. It's a pretty neat feature, and it's also kind of standard for machines in this period. at least I've seen it show up on several other computers from the early 50s. Then we have another general purpose register that's also used for math. This one can be used for general purpose storage, but it's also wired directly into Cizorax multiplier. So it does have a very specific special purpose. We also have the D register,

which is actually 16 addressable registers that aren't connected to anything special. They're the closest to true general-purpose registers, but it's also kind of like just having a smaller chunk of memory stashed away. After that chunk of space, we have a single 10-bit register. Then we get into more special-purpose stuff. We have, of course, a register for storing the current instruction and pointing to the next instructions address. Two registers are read-only wired directly into a set of switches on Cizarex control panel. There's also a breakpoint register and another register that holds the current value of the paper tape reader. That is a much more complex picture than just saying Cizirac has

27 registers. But even if we take out all that special purpose stuff, the machine still has a staggering amount of generally accessible registers. We're talking about 19 of these 20-bit registers. That's a lot of storage and a lot of complexity. If I was working with an architecture I knew that had that much space, I'd be very comfortable. Looking at the makeup and the caveats of these registers, I think should give us an idea of Cizirac's larger design. As in the Harvard Mark I, we get all these special places for carrying out specific operations. If you need to multiply numbers, you have to load values into the accumulator and the multiplier register. Results are then stored in the accumulator and the auxiliary register.

To read from tape, you grab data from the tape register, then move it to some other location. This can almost read like sophistication, but that's not entirely the case. This can also look like some grand level of complexity, but it's also not really that. Rather, I'd more call this exposure. We're getting to see the gritty underbelly of a computer. Cizirac is functioning on such a low level that everything is exposed to the programmer. Normally, there's a layer between the programmer and these raw bit streams that travel around the machine, jumping from circuit to circuit. But in the case of this very early machine, there isn't.

an abstraction. Abstraction hasn't been invented yet. To cap this all off, the design here is taken directly from Harvard. To quote from Piercy and Beard, one of their core design goals was, quote, the need for sequential execution of instructions and their encodement and subsequent decodement on execution, similar to the method used in the ASCC, which already existed, end quote. So behold, we have a very explicit lineage. And this is talking about work done around 46 or 47. I think that's neat that we can already form a family tree of computing right at the dawn of the discipline. So we're looking at a direct influence from one machine, one of the earliest machines, to another.

And crucially, this is a unique lineage. One of the reasons the Harvard Mark I doesn't come up very often on the show is that there weren't many computers heavily inspired by that machine. That connection alone makes Cizirac very unique and very special. But note that I say inspired. That's because Cizirac is no clone. Rather, it's more taking cues. The core part of the computer, the actual guts that compute,

are very similar in design to the Harvard machine. We have special purpose registers. Those are connected via an in-bus and an out-bus. And we have transfer paths that can perform operations. That is, at least broadly, very similar to the Mark I. Where things diverge is memory and programmability. You see, Cizirac is a Von Neumann architecture computer. And let me explain why that's kind of funny in case you miss the joke.

There are two broad classes of computers, at least when we're talking about how memory is used. The Von Neumann architecture and the Harvard architecture. In a von Neumann architecture machine, code and data live in the same memory space and can be treated interchangeably. In a Harvard architecture, code and data are separate. They live in different spaces and are not interchangeable. On the surface, that should sound a little funny, right? Cizirac is very much inspired by the Harvard Mark 1, but it's not a Harvard computer. Instead, it's a von Neumann computer, even though its designers didn't know about von Neumann

when they were designing Cizirac. That's pretty good, right? Now, there's a bit of a twist here that makes the joke break down. Longtime listeners know that the name von Neumann architecture is a misnomer. It should be something like the Edvac architecture, actually. It turns out that the name Harvard Architecture is also a bit of a misnomer. Apparently, that term shows up in the 70s and isn't actually in reference to the Mark I originally. So maybe the joke isn't super accurate, but I still think it's kind of funny.

Sensible chuckles chuckles aside, there is something curious here. Sizerak isn't created in total isolation, but the team in Oswald. Australia is somewhat isolated. At least we know they aren't getting super up-to-date information. They don't learn about ENIAC until 1947, for instance. So where did the idea to make Cizirac a von Neumann architecture machine come from? Things took a bit of a circular path. At least, maybe. According to Piercy and Beard, the basic design of Cizirac was done with the exception of memory around 1947. However, at that point, it was already decided that the Mark I's approach to programmability wouldn't work. We get a second design goal from the 84 paper, to quote,

the need to make instructions available for execution at about the same rate at which they could be executed. Paper tape was not appropriate as a storage medium during the execution of programs, end quote. So there had to be some mechanism for storing the program that had to operate at the same speed as the rest of the computer. What galls me here is that there are some very early reports on the development of Cizirac from 1948. But it's all those cases where the reports are cited all over but not available digitally. What I have been able to dig up is just as interesting. We have complete sets of yearly reports from CSIR. They include status updates on their computer going back to 48. In one yearly report dated June 1948, we learn that they are already working on Cizorax

memory. Beard was partway through construction of some early mercury delay lines. The timing here, again, is of the utmost importance. In 1948, Piercy and Beard learn about developments in England, namely the Manchester Mark I, Edzac, and Pilot Ace. All three of those computers were von Neumann machines and used Mercury-Delayline memory, but there's some lag time here. We know the team learned of these machines sometime in 48. In November of that year, Piercy traveled to England to see the machines for himself. We're told this trip didn't change much of Cizirac's design. We also know that the team didn't learn of the Edvac paper until much later. Edvac's design being the usual way that

the von Neumann architecture reached the masses. Also to note, the Manchester Mark I and Edzac are based off that Edvac paper. So, again, there's a lineage that's formed. This lands us in a funny place. We know that in the summer of 48, construction was underway on Cizirac's memory. We know that memory was planned to hold code and data because of earlier design goals of the machine. Later that year, Piercy sees Mercury-based machines with shared memory space. The question remains, what influenced the design? Did Piercy and Beard come up with the idea for shared memory space in isolation? If we look at that timeline, I'd say that's possible.

A crucial contributing fact is that Mercury delay lines weren't, computer technology. Early on, there's really no such thing as computer technology. It's all radar circuits that are being abused. Beard had worked on radar range-finding systems, which work on a very similar principle to delay lines. There were radar systems in this period that had built-in mercury delay lines for filtering data.

It was known in the biz that you could use mercury as a form of memory. and Piercy had seen firsthand how awkward the Mark I was. Storing instructions and data on different media led to issues. So the idea that some Australians just kind of came up with the Von Neumann architecture on their own, that doesn't sound impossible to me. It's just that I lack a smoking gun. It's also entirely possible that they had learned about the Manchester Mark I prior to June of 48. If that's the case, then we get another lineage.

The Manchester Mark I and Edzac all took cues from the draft report of the design of EdVac. That would mean that Cizirac was influenced indirectly without Piersi even learning of EdVac until it was too late. All right, we can breathe for a minute. I think that's enough of my speculation for a while. Whatever the case, Cizirac is a von Neumann architecture computer. It uses Mercury to store data, and it uses Mercury to store code. But that's not the only form of memory. I did say Cizirac wasn't sophisticated.

But that doesn't mean it's not very, very complex. In addition to Mercury delay lines, the machine would also end up with drum memory. Now that, dear listener, is wild to consider. I think about mercury as kind of an extreme form of memory. I mean, it's a long tube of heated mercury that you bounce waves through using polished crystalline surfaces. It's a wild technology and a little dangerous. It turns out that mercury vapor is what's the most, well, bad for humans.

And delay lines had to heat up their mercury to operate. That is an extreme technology. indeed. Drum isn't so much extreme, but it's awkward to work with. It's a physically rotating drum that stores magnetic data. Access is time-based, which is odd and uncomfortable. Cizirac having two forms of weird memory, well, that can be a lot to take in. But it's not that strange given the period. Recent show alumni, the IAS machine, also had two forms of memory. It used electrostatic tubes and a rotating drum. Many IAS-inspired machines followed that pattern. Why bother with two memory devices? Well, in part, it was because these were research

machines. The first generation of computers are, well, it's kind of this weird period where machines are partly used as tools for other research, and partly used as tools to research computing itself. You'll see wacky designs because researchers are still trying to figure things out. We aren't yet to the point where computing is a solved problem. Memory is probably the most influx aspect of early machines. So that's where we see the most experiments play out. Scissorax drum fits this mold pretty well. It wasn't added to the machine until 1952, well into its operating years.

By that point, Mercury was showing its age, and newer types of memory were appearing. Trying out drum makes good sense in that context. So we're up to the point where Cizirac has logic and math, it has memory, and it has pathways to connect everything up. But what about instructions? Well, this was actually the first thing I read about Cizirac, and this was the exact reason I wanted to learn more.

Cizirac's instructions are composed of three parts. Address, source function, and destination function. That's weird, and let me explain to you just how weird it is. First of all, it may sound similar to the Harvard Mark I's instruction format. There is a qualitative connection here. I mean, we have three parts. One is source, one is destination, one is something else.

Sure, that's kind of close. What is really going on here is actually kind of sophisticated. Operations are dictated by those source and destination functions. They aren't simple arguments, which is strange. Rather, they're the active part of your program. That means Cizirac doesn't really have operation codes like more conventional machines. Normally, everything a computer can do is described in terms of operation codes or op codes. you get a big table that has a list of every one.

It's every single kind of operation the processor knows how to run. If you want to add two numbers, you go to that table and you find the add operation. It's usually formatted as add X to Y. When the computer reads that instruction, it sees it needs to run an addition, and then it sees what the addition's arguments are. Cizirac does not work that way. Let's do that same addition example. Let's say you have a location and memory that has a value in it.

You want to add that to the accumulator register's value, which is called A. You start by taking your memory address. That becomes the first part of your instruction. Then you find the source destination that refers to an address. It's called M or memory. Then you find a destination function that adds a source value to A. It's called PA. What you end up with are actually two different operations.

You have one that fetches a value from memory and one that adds that value to register A. All of that is encoded as a single instruction. So it's almost like each instruction actually has two operations baked into it. That sounds weird at first, but we actually do have some modern parallels, and there are some benefits to this approach. The most simple way to think about this is a total lack of abstraction. Cizirac isn't hiding anything from you. Just like in the Mark I, you're moving around data at a very low level. You take data directly off the paper tape bus, or you pull data directly from an address in memory onto a circuit bus.

In that sense, programming Cizirac is more like programming microcode than machine code. Again, it's just so low level. That would have made Cizurac, in theory, hard to work with. But there is a saving grace here. That's the fact that each instruction can actually do quite a bit. The Cizirac team pitches this as a feature, specifically that the complexity of each instruction means you can do more with less code. That's important when you have a small memory space.

Oh yeah, did I mention how much memory Cizirac has? It only has a thousand words of programmable memory. This argument is, well, it's highly dependent on context. Let's consider a routine that adds two numbers in memory and then stores that result in another memory location. That's a good exercise for the circuits. On Cizirac, if I understand correctly, that would be three instructions. You first load the value of the first memory location into the accumulator.

Then you add the value of the second address into the accumulator. Then you store the accumulator in memory. That comes out to three words. But that's also how you would accomplish the task on a similar period computer. actually, I was thinking in terms of the LGP 30, and that would be the exact same order of operations. I was trying to figure out exactly how you'd program this on the Harvard Mark I, but the documentation for that machine is inscrutable as all get out.

So you're just going to have to have to trust me. Unless there's some way to add directly to memory, then this will always take three instructions. I don't think there's a way around that. So in this case, Cizirac isn't more efficient than other machines. Where I think this actually comes into play is the overall programming model. For this to make sense, we need to introduce one of the many, many registers at play. It's called S, the sequence register.

This initially sounded like a weird one to me. Piercy and Beard describe it as a normally incrementing register that's of a Mints use. Period. I know. It's strange language. It's actually the machine's instruction pointer. It holds the address of the current operation being executed. What's neat is that the sequence register is hooked directly into Cizirac's arithmetic circuits, and it's also available to the programmer, just as if it were any other register. There's a source and a destination function for the S-Rexamination.

register. So how is it used? How is that so neat? The most important instruction a computer can execute is called a jump or a branch or a transfer. It's how you tell a program to stop what it's doing and start execution on some other piece of code somewhere else in memory. Conditional jumps are how you implement turning complete computers. So it's something of a cornerstone of the digital arts. If you can't do conditional jumping, then you aren't a functional computer. Jumping is a pretty simple routine. You tell the computer to jump to some new address from which it continues execution. Behind the scenes, this is setting the computer's instruction pointer. But remember, Cizirac doesn't really do operations. It's all about data transfer. To jump,

you actually, you do the primitive thing. You write to the S-reg. yourself. Again, no abstraction, just raw data manipulation. If that were the extent of things, then Cizirac wouldn't be that interesting, right? It's just a different way to view a jump. But we get an extra destination function that makes up for it. That function is called PS. Great name, I know. It adds a value to the sequence register. In other words, it lets you make a relative jump. Instead of telling Cizirac to go to such and such address, you can tell it to jump forward by 10 instructions. Or, since negative values are a thing, you can tell it to go back and pick up executing from 15 instructions ago. On the surface, that might not sound super useful,

but this is a subtle thing. This one change enables two tricks. The first is conditional execution. This is what makes Cizirac turning complete. So check it out. There are no destination functions that tell Cizirac to set S to a certain value under specific conditions. However, you can add any number to S. That includes the number zero. That makes conditionals a bit of a trick. There are a few source functions that will return zero under specific conditions.

There are also, well, a bunch of different math equations that evaluate to zero. You can calculate up your conditional transfer however you want. Have a zero mean no transfer, but the actual transfer value be some relative offset. Then you run a PS. You add your value to the sequence register. If you had calculated a zero, execution continues. If you calculated some other value, then you're off on some other brand. This is a very different type of execution model, so much so that I can't immediately get a good read on how complex this code would be. My gut is that your code would just be so different, it wouldn't really be comparable to code written for a contemporary machine.

Again, it's just very different. It's a different way of thinking about things. The second trick this enables is also subtle and sophisticated. That trick is relocatable code. You can easily write all your code to use relative jumps and relative addressing. The fact that you can read in S as a source function helps with this. This lets you do things like calculating where a subroutine should return after a call. With these tricks, it was possible to write code that could be loaded into any location in memory and execute without issue. As far as timeline goes, that's very much.

very sophisticated software. We usually see relocation become a topic of discussion once we get into time sharing and much, much larger systems. Seeing this type of programming practice on a small and early computer, well, that's impressive to say the least. This brings us to the next question. What exactly were people programming on Cizirac? Well, would you believe music? There are many aspects of computing's past that are difficult to preserve. I tend to think there's this whole category of mundane features that no one really keeps track of. The culture around a machine room in the 1950s, for instance, how operators were taught to use machines, how data was stored and organized for easy retrieval, how programs were actually proofread.

All that kind of stuff tends to fade into the background, since, well, why would you record how you organize a shelf of paper tapes. We should add the sound of machines to this category. The fact of the matter is that old computers were allowed. We know that, but we don't really know all the finer details. For instance, let's take one of my bugaboos, Mercury delay lines. There are some period papers that refer to them as, quote, mumbled tubs. And that makes sense, right?

A delay line sends what are essentially sonic pulses down a tube full of mercury. That should make sound, right? Or we're folk calling them mumble tubs as a joke because it seems like they should make sound. It's two crystals talking to each other. We don't know. We don't have recordings. And I don't know of any working mercury delay tubes. So if you are a loved one have access to a working mercury delay.

YouTube, please have them record it and send the audio file to me. Old machines also made sounds in unexpected ways. I just came back from VcF West. One of the exhibits was a restored CDC 160A. That's a smaller machine from the 60s. The exhibitor was telling me that the machine itself is actually silent. But there are relays in its numeric display that click and clack. So when it's running, it will produce a good.

racket, just not from the actual computation. It's little things like this that aren't well-preserved or remembered. If you were able to go back to a machine room in the 1950s, I'm sure you'd be in for an interesting experience even if you had done your reading ahead of time. One of the things that gets missed is the fact that many early computers had speakers directly wired into them. On some machines, like the Pegasus, a speaker was connected up to an internal register. As a program operated, there'd be a characteristic clicking. If you knew your program well, you could tell how it was working based off that sound. This could be used for debugging, albeit in a rudimentary, kind of touchy-feely way.

There were still other machines that could have speakers hooked up in some hacky ways. The Bindex G15, for instance, can have a speaker wired up manually to the output of a data channel. Cizirac, however, was a little special. Its speaker was hooked to the output bus, making it a full destination function. In other words, there was a instruction, kind of, to beep the speaker. The idea was to use this for debugging, basically a way to signal certain spots in your program. similar in style to print debugging that's used today. Cizirac would click its speaker to let you know it got past perhaps a tricky piece of code.

Here I'm working on a paper by Dornbush, which describes the early music of Cizirac and efforts to reconstruct the songs themselves. He describes a natural progression occurring. The actual instruction to signal the speaker, P, only really made the thing click. That wouldn't have been easy to hear in the machine room, so programmers would issue a few P commands or even run a loop to get the computer to generate a tone, to basically beep. A beep is really just a series of clicks if you think about it. By driving the speaker cone in and out, sending multiple clicks, it's possible to create a tone. That would carry

better in a machine room and make it easier to hear your debug points. The first music, played on Cisarack was programmed by Joph Hill. His initial implementation was crude. By looping in different ways, he could produce specific tones. That simple principle was used to make tones of different lengths, and then string those together to make music. Cisirac was playing music by 1950 or 51. The date, however, is a little up in the air. Dornbush has written the most on the subject. there wasn't anything published about the first music of Cicirac. Rather, he's going off latter recollections and interviews with programmers, plus public demonstrations that were notated. The funny thing is, or perhaps the frustrating thing, is that those programmers have

blurry memories, so the specific dates aren't that clear. This evolved into something more sophisticated. In 1955, Thomas Cherry, another programmer, created a new spin on these music programs. He wrote a program that could read in data and use that to play a song. That data encoded the tone and length of notes. It's essentially a simple form of digital sheet music. The music could be stored in memory, but recall, Cizirac never had much memory. Space is always at a premium in this period. So there was another mode. Cherry's program could read its music from paper tape. In that way, longer songs could be encoded and played. What's funny is Cherry describes this program as a player piano. We even get instructions on how to convert sheet music into paper

tape. But again, don't expect too much. This is 1940s technology. Cizzerac was completely monophonic. It could only really play one note at a time. And, well, that was already kind of pushing things. There were also limitations on how quickly you could change notes. If music was stored in memory, then you could switch notes more quickly, since there would be less delay when fetching the next note. Paper tape, on the other hand, introduced a bit of a pause between notes as data was read into memory. Dornbush's work is especially remarkable because of the restoration process he was involved in. He was able to get in touch with some surviving Cizarek programmers,

one of which had actually written an emulator for the computer. He also had preserved printouts of Cherry's music program and some of the player piano tapes. The team was able to recreate a number of songs with extreme accuracy. They even went so far as to recreate Cizarek's vacuum tube amplifier circuits and compared waveforms to all documentation from the 50, to make sure everything lined up. It's a true feat of restoration.

I'll link to where you can listen to the music yourself. It's simple but remarkable for such an early machine. Now, of course, we get to the question of originality. Just how early was the music of Cizirac? Was it the first computer to play music? Or were other machines belting out tunes in this period? That's the funny thing. It appears that the first songs on Cizirac were made in isolation.

Dornbush speculates that Hill's music was simply written as a programming challenge. Again, something to exercise the old circuits. At any rate, the team in Australia didn't know of any other digital music in the wider world. But was there? In 1950, no. There were music programs written for the Ferranti Mark I and the Pilot 8. around 1951. And bear in mind, these were far more traditional machines than Cizirac. I think that, in context, makes this all the more interesting. Cizirac very well could have been

the first computer to ever play music. All right, that does it for our coverage of Cizirac. It's a unique machine which holds a unique position. What blows me away is how strange the computer actually is. I'd assumed it would be a riff off some other machine, probably something like a clone of the EDVAC design. But it's not. That, to me, is wild. Cizirac is very much its own machine that was heavily influenced by the Harvard Mark I, of all things. I've been racking my brain, but I can't think of another computer with that distinction. That on its own makes Cizirac a very unique and interesting case study. But although inspired by the Mark I, Cizirac is, again, its own machine. It has a unique

instruction set, a unique way of doing things. The overall architecture is so out of the ordinary, I'm not entirely sure how to evaluate it. It's just, well, different. And I know that should be expected about these early computers, but when I run into it in person, it's just fascinating to see. Thanks for listening to Advent of Computing. I'll be back in two weeks' time with another piece of Computing's past. Until then, if you want to get a hold of me, you can find links to everything at Advent of Computing.com. And as always, have a great rest of your day.