Advent of Computing - Episode 181 - RAYDAC

Episode Date: May 3, 2026

In 1947 Raytheon signed a contract to make their first computer. It would be their last... at least for many many years. The fruits of this contract was RAYDAC. Early digital computers were odd, to say the least. And RAYDAC distinguishes itself. From zig-zag delay lines to hunting tapes to freon cooling, it truly is a unique machine. Selected Sources: https://ed-thelen.org/McGee_Book-4.2.2.pdf - McGee on his experience programming RAYDAC https://sci-hub.st/10.1109/JRPROC.1948.232626 - A Digital Computer for Scientific Applications https://www.jstor.org/stable/2002859 - The Logical Design of RAYDAC Like Advent of Computing? Then check out the after show! Adjunct of Computing is now LIVE: YouTube Spotify Apple Podcasts

Have you ever heard the one about the appliance company that made a computer? There's this company way back in the day that made refrigerators and microwaves. They also did a little military contracting on the side, which proved to be pretty lucrative in its own right. As technology advanced, they decided it was time, yet again, to diversify. They would try to get into the business of computing. What was the name of that company? Well, you may have guessed it was GE. That is actually true.

Back in the 1960s, GE made some major moves in the computing market. But there was one before them. The refrigerator company that made a computer is none other than Raytheon. That may sound improbable. Actually, that may sound a little weird in both cases, right? How do you go from washing machines to computers? Well, in reality, it was more a matter of a jump from radar or radio, into digital circuits.

The bottom line is that at the beginning of the digital era, there weren't really computer companies. The only exception to that rule initially was the Eckert-Mouchley Computer Company, but that didn't work out very well. During this period, companies were either born, totally fresh and new, or existing companies took a couple stabs at computing. Some, like IBM, the old school punch card house, would stick the landing. Others, like GE, would plunder around for a while.

Then we have examples like Raytheon, who gave it one try and then essentially gave up. Welcome back to Adjutant of Computing. I'm your host, Sean Hass, and this is episode 181, Radak. Today, we're going to be discussing a pretty obscure machine and another computer ending an AC. Before we do, I want to give my usual plug for the not quite new, but relatively new, official advent of computing after show. It's called adjunct of computing. If you've ever wanted a more casual venue where we discuss what was left out of the episode

or just questions that were left on the table, then I think you'd really enjoy adjunct of computing. As of time of recording, I can verify about 10% of the audience has already found their way to the after show. If you'd like to bump those numbers up, then please go give it a listen. There'll be a link in the description of the show, and I think you'd really enjoy it if you like admin of computing itself. Okay, so let me set the stage for this episode. Last time, I was working out of one main source. It was called Review of Input and Output equipment used in Computing Systems,

which was a proceedings of a 1953 joint AIE-I-E-I-E-E-R-E-A-CM computer conference, basically everyone in computing. It gives this wide-reaching survey of the state of input and output in the early 50s. It's a really neat text. in that episode, I made the claim that Bynac was the first computer to use magnetic tape for storage. I'm still standing by that claim, in part because I just think it's true, and also because it's part of this larger story about tape at the Eckert Moutchley Computer Company. The work done on Bynack does have some connection, or at least some dialogue with later work on tape.

But there is another claimant to this first. This claimant even shows up in that I owe proceedings that I like so much. The machine I'm talking about is, of course, Radak, the topic of today's episode. When I say Radak is obscure, well, I mean it's very obscure. This is a very early machine. The name should give it away. The AC at the end is a dead ringer for antiquity. It usually stands for automatic computer.

You know, from the period where you had to specify that. Or, in the case of INIAC, it's short for AND computer. Either way, you see the ending show up in a wild number of early machines. Inniac, EDVAC, EDAC, SEAC, Bynac, and RADAC. The last being the Raytheon Digital Automatic Computer. Now, I must assure you that just because the computers have the same suffix, doesn't mean they're related. There's a joke or some

misinformation that could be made using that, but I'm going to restrain myself. Radak drew my attention for two reasons. The first is the tape connection. Radak was one of the earliest machines to use magnetic tape as storage. That on its own is pretty interesting. The second is that Radak implemented an early form of error checking. I know, obscurity to obscurity, right? Error checking is one of those features that shows up in a good number of very early computers. It's a way to tell if an operation was successful. That could be a calculation or something more basic like transferring data. It could be to make sure that reading from a tape that I've worked or, you know, that a register hasn't suddenly broken. That can sound a

absurd today. Of course a computer will accurately add two numbers. That's kind of their whole deal. But that wasn't the case in the 1950s. Machines were new, delicate, and capricious. Error checking served as a mechanism to combat those factors, but I don't know that much about it. I have, however, heard that Radak was a particularly complex example of the arts. I also just love these vacuum tube episodes as a way to check in on a few storylines. One of those being the matter of lineage. If you're a long-time listener, you may remember the whole Children of IAS argument that I keep thinking about. Well, that's going to be in the back of my head for this one, for sure. The story of Radak comes down to us in a few different sources. The main ones I'm working out of today are two oral histories,

one with Bob Campbell and another with Richard Block. You'll meet both of them as we continue our journey. It's from their oral histories that I'm able to construct today's tale. I've used that kind of as the framework for the story and then added in every other piece of paper trail I can find to fill in the technical details. If you stick to just published material, then you find almost nothing about Radak. So this is a case where we got pretty long. lucky. Everything starts with Project Hurricane. At least, that's the code name we end up saddled with for the episode. In reality, this all has to do more with a series of federal

contracts than some secret project. Around 1946, the U.S. Census Bureau and the U.S. Navy went out looking for computers. Apparently, this was all under the umbrella of the National Bureau of Standards. It sounds like the NBS was the one actually handling contracts, and then the Census Bureau and the Navy were the ones getting the computers for their personal use. It's this contract hunt that's our inciting incident. It's interesting to me how different arms of the feds dealt with the computer revolution in different ways. In this same period, the Bureau of Standards would end up building their own computers for their own use, while the Census Bureau and the Navy would go out and

find a contractor to do their work for them. Both of these approaches would have been, for the time, a little crazy and a little risky. The idea that you could build a computer in 1946 is amazingly ambitious. Remember, this is the year that information about ENIAC is publicly disclosed. It would be like saying, I'm going to go to the moon after seeing the Apollo moon landing and then walking down to the hardware store. There's an aspect of unreality to it, right? Trying to find someone who can build you a computer in 1946 is also wildly ambitious.

I mean, who are you going to turn to? IBM and Harvard have made one machine. It's not really a computer, but it's very, very close. The University of Pennsylvania has done the same. There aren't really established computer companies, and there aren't really established ways to build computers, or even established computers, for that matter. You could probably put every programmer in the world in a single van at this point, and almost every single one of them would be speaking English, too.

The NPS put out a call for contracts, and among the people that actually responded, there are two that matter, EMCC and Raytheon. EMCC, the Eckert Moutchley Computer Company, were already familiar with. They were the star of last episode. They were newly founded by the ENIAC team, direct from the University of Pennsylvania. The other company to enter into the bidding war was Raytheon. Today, Raytheon is a military industrial juggernaut. But things were very different back in the day.

Raytheon was initially founded as the American Appliance Company in the 1920s, with the help of none other than Vannevere Bush. I'm just going to leave this here and not elaborate. The company changed their name to Raytheon as they began to pick up steam manufacturing vacuum tubes and other sundry electronics. During World War II, Raytheon made a lot of money manufacturing magnetrons for use in radar. These are devices that emit microwaves, and yes, this does lead to Raytheon inventing the microwave oven. Also, tag the fact that Raytheon was involved with radar. That might prove important later. Campbell paints a very interesting post-war picture for Raytheon.

The company was relatively low on funds and looking to make a pivot. A large part of that probably had to do with the differences between a wartime and peacetime economy. to quote, Lawrence Marshall, who was the president, was interested in getting into new fields, and one of them was the computer field. It was through George Stibbitts, who had been at Bell Laboratories, and gone into consulting on his own, and was helping Raytheon, end quote. Stibbitt's early digital pioneer, suggested that Raytheon get into making digital machines. Marshall had been one of the original founders of Raytheon way back in the Vannever Bush days, But how did the pivot work in practice?

It basically meant that Raytheon was looking for opportunities to build a computer. So when the NBS called for bids on new machines, Raytheon wanted to play ball. The census contract was basically locked in on EMCC since 1946, but the Navy contract was more open. In practice, these contracts were actually for two very different machines. The census needed a data processing device. The Navy wanted something more like a pure number cruncher.

By late 46, the naval contract was whittled down to two candidates, Hughes Aircraft and Raytheon. The process is described in very brief in a 1947 newsletter from the NBS. They weren't exactly looking for a computer company. Rather, they were looking for, quote, firms known to be competent in the field of electronics, and to have personnel known to be qualified to design electronic digital computing machines, end quote. I think that's fair enough. At the time, there wasn't really a computer company in the whole

world, except for EMCC, and they were up to their noses in work. The report makes it sound like the final decision came down to something like a vibe check. Quote, an investigation by Bureau Personnel resulted in the conclusion that Raytheon manufacturing was better qualified to perform the work, end quote. I actually spent a lot of time trying to figure that sentence out. The immediate question in my head was, What personnel at Raytheon had some kind of digital qualifications? So, here was my train of thought.

The contract for the project Hurricane Computer was signed in January of 1947, specifically January 27th is when it was inked. We know most of the people that worked on the computer project. The ones I can find firm details on all joined Raytheon after the contract was signed. The NBS article gives us two names to work from. Dr. N. E. Edlifson and Dr. Kapp Smith. They were in charge of the contract on the Raytheon side. So, stands to reason that they may be computer people, right?

Well, I'm not entirely sure. I can find hardly anything about these figures before 1947. I know they were Raytheon employees. Edlifson would oversee the Navy contract at first, Then in 1949, he would move on to work at North American Aviation, and Cap Smith would take over the project. They'd both be involved in computing after 47, but I can't find anything prior to the contract that would count as digital experience. But back to the reality of the matter. The contract was called Project Hurricane by the Navy. supposedly the name had to do with a convention around Navy contracts in this period.

I've heard these called the foul weather series of contracts, but I think that's more tongue-in-cheek than actual truth. Project Whirlwind was another one of these foul-weather projects that started over at MIT. That would lead to a computer simply called Whirlwind. There's also Project Typhoon. Hurricane, however, would lead to a computer called Radak. A note about the name here. It was officially called Raydak. But I'm mainly working out of oral histories.

Those are transcribed, and they're not always right. I've seen it show up as Ray Vak or Radvac in some of these transcripts. I only bring this up because it did cause a bit of confusion when trying to sources. I really had to track down oral histories by name or by vague keywords and then figure out what spelling they use for the computer. Like I said, it might come down into the transcription or maybe some fuzzy memories after so many decades. Now, I'm not 100% sure what computer bona feedays Raytheon had before the contract was inked. But I do know what happened next. In 1947, they were on a hiring spree for Hurricane. Among the new inductees were a few programmers

from Harvard. Both Block and Campbell had previously worked on the Harvard Mark I. When I say previously, I mean immediately previously. Both were hired from Harvard straight into Raytheon. Crucially, These aren't hardware guys. They were programmers. In fact, Block himself was one of the first programmers in the world. He even claimed to have shown Grace Hopper the ropes herself when she joined the Mark I project. This is very, very early stuff. I do need to temper this a little. A programmer in this era existed very close to the hardware. They're not like programmers today. Near the end of his tenure, Locke would suggest and design hardware extensions for the Mark I. So these folk aren't clueless about hardware, it's just that they didn't build the Mark

1 themselves. They came into the project after the computer was designed and reaching operational capacity. You could see the start of a lineage forming here, which I think is very interesting. When the ENIAC project wraps, a pile of those engineers move over to the new EMCC. In 1949, that crew also snags Grace Hopper, so EMCC ends up with a blend of talent, but mostly ENIAC heads. Raytheon gets these two folk from the Harvard Mark I actually have a list of the other names that worked on the project, but I can't find a whole lot of information on them besides scant mentions. The only other big figure involved is one Louis Fine, but we aren't up to that part of the story yet,

and he doesn't make a name for himself until after the Radak years. Radak is designed and built between 1947 and sometime in the early 1950s. It ends up taking a while to get the machine up and running, and it's not delivered until 53. But when you get down to it, that kind of timeline was pretty common for the period. Univac didn't become operational until 1951, even though its contract started in 46. It turns out it's just hard to make a computer from absolute scratch. And despite the lineage here, Radak ends up looking nothing like the Harvard Mark I.

It's very much its own machine, so what exactly did it look like? Can we see any borrowed ideas, or was Raytheon truly working from a clean sheet? In 1976, Lois Alamos hosted the International Research Conference on the History of Computing. This was a gathering of the first pioneers in the field to talk about the early days of computing, and, best of all, it was recorded on video. A few years ago, the Computer History Museum released digital transfers of all the talks. It's an invaluable resource. It also goes to show that at least someone has been thinking of preserving this stuff since,

well, since the very beginning. The conference has all the heavy hitters. Eckert and Mouchley give a talk about Inniac. Nick Metropolis is even there to talk about Maniac. There's even Stanislaw Ulam. It must have been a real hoot of an event. One of the attendees was Lou Fine. He wasn't scheduled to give a presentation. On very short notice, he was talked into presenting on Radak. So on the last day, he got up on stage

and gave an impromptu 12-minute lecture about the machine. This is probably one of the best jumping off points we have for understanding the computer. Fine was the third in a line of victims of Radak. The project had three managers over its lifetime, and each would leave Raytheon. Fine was the final manager and the one who oversaw delivery to the Navy before leaving Raytheon. I ran into this talk pretty late into my research. I'd been going down into the pits reading the handful of papers we have on Radak from the period. One of the big issues with old computer papers is, well, the lingo and conventions aren't there yet. It's antiquated. So it's always a little, a little trying to make heads or tails of things. The emphasis is also different. A paper from

1948 will emphasize what was interesting to someone working in 1948. A talk from 1970 is much more of a retrospective. Fines' impromptu lecture is pretty simple. slick because it highlights just what he thought was so interesting about Radak all these years later. It also made one thing clear to me. Radak was far more sophisticated than I initially thought. Let me explain what I mean, and, as is custom, I'm going to start with memory. Radak used mercury delay lines for storage, you know, the classic. Long tubes filled with hot mercury.

acoustic pulses are transmitted down the tubes and then picked up on the far end. By recirculating those pulses, you store data. It's a wild technology, it's an ancient technology, but it works. Many early computers would rely on mercury tanks for their memory. It's also worth remembering this is a borrowed technology. Mercury delay lines come from radar. Raytheon being a pretty heavily invested, radar outfit was very familiar with the technology.

One issue with the delay line is their size. Traditionally, a mercury line is just a long tube filled with liquid metal. As a result, you have to have space for that tube somewhere in your machine. That can get annoying, or at least it can limit your options for how you physically design your machine. and in an era where you have to wire discrete components, those kinds of physical limitations can actually matter a lot to your design. Radak used something more special.

It had delay line modules that each contained three delay lines. Those lines were folded in on themselves, forming more of a delay zigzag. As a result, a module was pretty small, just seven inches long. How did that actually work? Well, it's pretty simple, believe it or not. You're sending acoustic waves down the line after all. Acoustic waves can be reflected. In fact, that was an early issue with development of delay lines.

If your receiver reflected too much of the incoming waves, then you could lose data. Raytheon took advantage of that phenomenon. Waves would go down the first straight run-up. of the line, be bounced around a corner, and then continue on another straight run, then bounce again before running towards the receiver. That 7-inch module actually contained 21-inch-long delay lines. For the time, this was very dense data storage. One module contained 1,836 bits of data. That's actually a lot more dense physically than a Univac delay line. I call this sophisticated because it feels like a step up from existing technology.

It speaks to Raytheon's experience with delay lines and experience with radar. They were able to make a more convenient and dense module because they'd been in that game for so long. They knew how to get Mercury to sing. There was also some logic behind this choice. Campbell explains in his oral history that there were some other options in the running. Quote, Harvard and Engineering Research Associates chose magnetic drums, relatively slow, but a conservative engineering choice.

At Raytheon, we felt they were too slow. We looked in some detail at delay lines and storage tubes. Raytheon had a background in both. We made preliminary designs using both approaches. we decided that delay lines, although slower, were a much safer bet, end quote. First of all, yes, I did include that quote because of the shout-out to ERA. Go hybrid. Electrostatic tubes, aka Williams' tubes, were a very promising option. They were some of the first truly random access memory devices, but they were very new,

and they were actually pretty fickle devices. Raytheon had experience with tubes, but Mercury was a safer bet. It was more of a conservative choice. A computer is already such a huge and risky undertaking, so why make things harder? Besides, the folded delay lines are just such a neat solution. This folded arrangement wasn't entirely unique to Radak. The English electric deuce used folded lines, although a more primitive construction. The Deuce had a two-fold instead of a three-fold line, and they weren't built into compact modules.

Raytheon's delay lines are very much a little seven-inch-long brick that contains memory. It feels very, very modern to look at. These folded lines were more heavily used in radar. However, I'm not entirely sure how heavily. I found some declassified reports that referenced their use. One of the Radak papers even cites a textbook that briefly discusses folded delay lines. These references are from the late 1940s and very casual. So it seems that folded lines weren't an innovation in this period.

They were just one possible configuration of a mercury delay line. Anyway, earmarked this is something to think about in the future. Will we see folded mercury again? It's possible. The other mark of sophistication is Radak's tape drive. You see, Radak had seekable magnetic tapes. If we saw that on its own, well, that may not sound all that impressive. But we should all know better by now, especially after my last dive into the medium.

If you listen to my tape episode, then you can probably guess my three questions here. Question the first. when was this tape drive operational? Question two, what medium did it use? And question three, how seekable are we talking here? The timing one here is perhaps the most slippery. I'm pretty sure Bynac was the first computer to use magnetic tape of any kind. That was almost exactly contemporary with Radak.

The Bynac project starts in 1947, it becomes fully operational in 49. In fact, we know that Bynac ran its first full program in February of 1949. That's going to be my proposed birthday for digital magnetic tape. Does Radak ruin my party here? We know that the contract for Project Hurricane was issued in 1947. The machine was considered complete and operational in 53. It's likely that Radak may have been reading tapes as early as 1948, though. My evidence is a paper titled A Digital Computer for Scientific Applications,

published in the Proceedings of the IRE in December 1948. The paper describes Radak in pretty precise detail. There is another paper published in the same. same year that describes Radak's logical design that I'm using as a supplement here. So, was Radak really spinning tape all the way back in 1948? Well, maybe. This is where things really get slippery. Radak was still very much under development in 1948. In fact, according to one of my oral histories, it wasn't even named Radak until 1950. It wouldn't be delivered to the Navy until,

until July of 1953. If you go purely by when papers were published, then yeah, Radak was first. There's a description of its tape drive, I'll be a kind of rough, in December 1948. But if we go by delivery date, Bynac was first. Really, I don't think this is worth arguing about. It would take us way, way too far into the weeds

and be very, very difficult to prove. Besides, these are both pretty obscure machines with pretty thin paper trails. But it does get a little more weird. You see, Radak used a very specific type tape drive. There's another computer that used, I think, nearly identical drives. In 1950, the NSA built a computer called Abner. And yes, I do love a machine with a human name. This was so early that the NSA was still known as the ASA, the Army Security Agency.

This is an even more mysterious and more obscure computer than Radak. I ran to a few papers that discuss Abner. One has a whole section on programs developed for the computer, which is complete with big redacted sections. It's seriously funny to see sentences like, one developer wrote a program to Redacted. These reports explain that Abner used tape drives sourced from Raytheon, and I'm fairly certain at least the physical mechanism is identical to the drives used by Radak.

I say fairly because I'm basing this off of very bad mimographed photos. Pictures of Abner's tape drives look... almost the same as pictures of Radax drives. And those drives are distinctive, to say the least. To start with, this is an acetate-based system. Raytheon was spinning plastic. That means the tape didn't spin that fast. All of the caveats from last episode apply here.

If you overstress the tape, it will break. Raytheon also implemented a tape loop system like we saw with the Uniservo drives, and the IBM 726. Tape was kept on reels that flicked in order to maintain the proper amount of slack. There was a central capstan that moved the tape forward and backwards, and the slack meant the capstan only had to move a small amount of tape. Very standard. The physical construction, however, was different from what we've seen before.

These drives stacked their reels. So from the front, it looked like you only had a single tape reel. The loops weren't vertical but horizontal. The system used springs to apply tension so orientation didn't matter. Looking head on, you see these big stacked reels in the lower left corner of the drive, then the capstan and loops in the upper right-hand corner. You could spot it at a distance, even in grainy old NSA photos that have been photocopied multiple times.

Again, this is functioning the same as other. looped drives, it's just built differently. There are a pile of similarities here. These Raytheon drives stored data in blocks. They also had a mechanism for dealing with bad regions of tape. The trick employed here was a sync track. One track on the tape was a series of pulses that told the computer when a bit of data was encountered. Those pulses don't have to be placed evenly, so Raytheon only used pulses on regions of good tape. That way, bad chunks of tape would just be passed over. These drives also used magnetic particle clutches.

They're the coolest type of clutch after all, so it is the correct decision to make if you have to choose a clutch. So far, this is all pretty reasonable, right? Pretty close to what IBM and EMCC were dishing out in the same period. There is some variation, but whatever. That's within error bars. Raytheon pulls ahead when it comes to one feature. hunting. This is a feature of the Radak drives specifically. Abner did not have huntable or

seekable tape drives. That actually leads to a small side theory I have. I suspect these tape drives were just a component that Raytheon already manufactured. I haven't quite backed that up. I haven't found a parts catalog that says, oh, the Raytheon 1, 2, 3 tape transport mechanism was manufactured in this year, but it seems to fit the picture here, that Raytheon had some tape drive they already made, they sold that to the NSA, and they also used it in their own computer. Anyway, let's talk about hunting. This was the official word used by Raytheon, but I'd call it seeking. Each block of data on a Radak tape was numbered. You could request a specific block by number, then the tape drive would go and find that block for you and serve it up.

That is a huge improvement over other drives. Early EMCC and IBM drives were purely sequential. You could access the next block of data or the previous block if you wanted. That was it. You couldn't ask for block number 12. This is, again, another step above simple implementation. It's just more complex, it's more sophisticated. How did Raytheon accomplish this feat?

How was the Radak able to find a specific block? The trick, frankly, is wild. It's optical. I honestly wasn't expecting that at all. I would assume you could get away with a counter, right? As tape spins by, you count up the number of blocks you can count. If it spins backwards, well, you count down that counter. Seeking is a simple equation away, right?

But that's not how Radak worked. Again, it's a little more sophisticated. Each tape has actual numbers printed on it. These are printed on the back side of the tape. That way the magnetic head can be reading data off the front side of the tape, while photoelectric heads read its backside. The papers are not explicit here, but I think the actual markings were in binary. One 1953 paper from that big joint review of I.O. devices explains the system in some detail,

but it doesn't show an actual photo of the back of a tape. It just has a diagram with decimal numbers on it. But from its description, I think this was more like a series of lines and bars, something like a barcode or a binary optical code. The hunt operation was controlled by the so-called hunt unit. That's perhaps a bit of a caricature of a name for a military-industrial company, but that's what they call it. It's a cool name.

It's an equally cool device. To use the hunt unit, Radak would send over a 12-bit block number. That was the hunt unit's target. Then it would fire up the tape drive. The drive would tell the hunt unit the number of the current block. The unit would then simply compare that block number to the target number and tell the tape which direction it needed to spin in. Block numbers were placed in two tracks, one for forward hunting and one for backwards

hunting. In this way, the hunt unit could get proper numbers both coming and going. This gave Radak a feature that early computers simply didn't have. Its tape may have been slow, but it could function as random access storage. I'd like to go back to what I said last episode about the fact that Binak was the first computer to use a magnetic tape. I said that wasn't a useful fact, and this is exactly why. It's still unclear to me which actually spun first, Bynac or Radak. But that doesn't really matter.

Bynax tape drive was a minimally functioning unit that was needed to bootstrap the computer. Radax tape drive was much more. Its designers talk about Radax tape drives as an extension to its memory. You'd load your program off tape. You could load data, and it could be controlled by the computer. A program could reach out and use a tape drive

as a bit of extra storage during execution, or it could drop its results onto a reel. That's much more in line with how Univac or an IBM 701 would use tape. But depending on how you interpret the story, Radax Drive could have been earlier or later than Binak. In fact, if we use that 1953 date, Radax drives may actually be more recent than the Uniservo. Another just neat feature with these tapes is that they were buffered.

The tape drive had an input and output buffer. These were, of course, the zigzag mercury delay lines. Whenever we encounter any kind of storage on Radak, besides the tape drives, it's always these neat mercury modules. Anyway, when Radak wanted to write to a tape, the computer would send data into the tape's output buffer. Once the buffer is full, the tape drains the data onto acetate. Reed works in a similar way.

As the tape's head read the data, it would throw it into mercury. Then, when Radak wanted data, it would just drain the buffer into, well, into some other mercury tank. This enables what Block calls, quote, partly synchronous and partly asynchronous operation. Radak's circuits could be crunching numbers while its tape drives were shut settling around data. Now, note the plural, because Radak had four entire tape drives at its disposal. Again, Radak is more than the bare minimum here. It has some very neat features. With that, I think it's time to get deeper into the computer's architecture.

Radak is what's known as a four-address architecture computer. Now, what in the world does that mean? In short, each instruction follows the same format. You have an order, which is what you want to do. Then you have two addresses for arguments. A third address for where you want to store the result of that order, and a fourth address to specify where the next order is located in memory. With this, you tell the computer something like, add X to Y, store the result in Z, and then jump to A. This is actually a very distinctive setup. In more modern parlance, I'd say that each Radak instruction ends with an explicit jump. There are only three machines I can think of offhand that have that feature.

One is the RPC 4000, that's Libroscope's follow-up to the LGP 30. Why would you want to do this? Well, it actually simplifies your design. a bit. But it gets a little weird. The RPC 4000 uses explicit jumps because it uses drum memory. Explicit jumps are a way to optimize based off address fetching. So that's very specific to one type of computer. Radak doesn't use drum. There's possibly another reason for the jump. Radak doesn't actually have registers. All instructions, deal with memory directly.

When you add two values, you're adding two values from memory and storing them directly back into a memory location. Normally, a computer needs something called an instruction pointer. That's a register that keeps track of the address of the current running operation. That register is then used to calculate the next instruction to run. In most machines, this will be the next instruction in memory. but by adding the explicit jump, you don't actually need an instruction pointer. Each instruction says where to go next, so you just need less record keeping.

There is another reason to use this four-address architecture, and for this we can turn back to Abner. More and more, I want to do a really deep dive into Abner, because it sounds like a pretty interesting project. It was developed at a point where there were other computers in use, so the NSA was able to actually do some design research. Abner is the second computer I can think of that uses explicit end-of-instruction jumps, and it's also a four-address computer. In a 1964 paper on the history of computers inside the NSA, we get an explanation as to why they went with four addresses.

Quote, During 1948, ASA analysts made visits to these installations, attended lectures at the Bureau of Standards Digital Computer Laboratory, and performed programming experiments using Atlas, Univac, EDVAC, and Radak Order Codes.

The result of these investigations was a report favoring a design using four-address logic, radac or EDVAC, over one address logic, Atlas or Univac. Four address logic was favored for the following reasons. 1. Time estimates for executing representative operations showed higher speeds. 2. A philosophic conviction that the bulk of computer operations in ASA applications

would be characterized by relatively simple operations on many data items, rather than more complex operations upon data retained in the accumulator, end quote. It's not just that ending jump that cinched it. Rather, it's the overall architecture. I was pretty confused when I first stumbled upon the term four address, but I've worked out the translation. Radak was a memory-to-memory computer. Instructions read for memory and wrote to memory all in one shot.

That contrasts to machines. like Atlas and Univac, which were Load-Store computers. On those computers, you have registers that hold immediate values to manipulate. You have to load data from memory into the register, do whatever work on it you want to do, and then store the result back in memory. The ASA determined that Load Store would be slower for their specific kind of work. they planned to work with a bunch of variables at once to do things like data transformations. Memory to memory worked better for that, and the machines that did memory to memory in this period

were these weird four-addressed computers. So the address number four, at least for the ASA, didn't really matter. The jump isn't important. It's more the rest of the design. You may have noticed I slipped right past the third machine that I could think of that used explicit jumps at the end of each instruction. That machine was EDVAC. But that opens a can of worms now, doesn't it?

You see, there's EDVAC the computer and EDVAC the report. The report was leaked in 1947 and describes a computer of a kind. It doesn't so much describe a very specific. architecture as how one would construct a computer. It gives hints and it does give a kind of rough architectural design, but it doesn't give fine detail. It doesn't tell you, here's the instructions you would need. It tells you things like, oh, you might need a register, and memory, that should have an address. A machine called EDVAC was completed at the Moore School in 1952. That's the place that Inniak was developed and where the EDVAC report was drafted.

But the machine describing the report and the machine built in 1952 are different. Given the period, I would assume that the ASA was talking about EDVAC the report, but that doesn't make sense. The EDVAC report describes a load store architecture. Edvac, the machine, was for address. It was a memory-memory architecture. Radak and Edvac share a similar design, but Radak isn't copying from the Edvac report. That's interesting because many early computers were based off the rough sketch in the

Edvac report. As with all things, this far off the beaten path, there are a lot of questions I'd like to answer. Did Radak copy Edvac? Was there some cross-pollination between developers, or was it the other way around? Is there some secret third machine that originated this four-addressed architecture? I'm not entirely sure. I think Radak is pulling from Edvac here, but I'd need to do some deeper research to prove that. The actual evidence may not even exist anymore. That said, I think the four-address architecture should be viewed as something ancient.

Herman Goldstein, in his book, The Computer from Pascal to Von Neumann, actually discusses four-address machines. He was at the Moore School during the development of Inniak and part of Edvac. According to him, there were proper fights over the four-address architecture, and he and von Neumann were on the losing side. I haven't been able to find any other four-address computers, and I think that's for a good reason. Goldstein points out that the fourth address, the jump, is kind of useless.

It's now taken for granted that a computer will run instructions in the order they're put into memory until some jump or branch is reached. But at the time, it wasn't clear that that's how computers should operate. At least there is enough space that researchers could argue for that fourth address. Things like drum memory are a great example of why you might want to jump. In that kind of computer, memory isn't always sequential. Maybe there is a similar argument with Mercury delay lines, but I haven't seen anything explicitly saying that. You can also argue that address number three isn't really necessary.

That would hold the destination for the result of an operation, but that could be covered by conventions, Lodestar architectures actually end up being easier to implement and more popular for decades. Those are essentially one-address architectures. In that light, Radak and Edvac really read as dinosaurs or experiments from a bygone era. It goes to show how many unknowns there were around computing in this period. This also places Radak in a dead-end lineage. I think that's likely a big reason for its obscurity. The machine didn't really spawn any successor.

I can't find any computers that claim to have taken ideas from Radak. It's an island unto itself over there with Edvac the machine. Another weird example of its antiquity is its cooling. Now, as with all things, Radak, we have precious little information. Fine mentions a wild tidbit in his impromptu, lecture. He said Radak was Frion cooled. This is backed up by some other sources I can find, namely an oral history with Dean Franklin. Quote, it was quite a different setup. The flip-flops were encased in a little plastic container which had an aluminum stud sticking out the bottom.

And the stud went into a bar. The bars went to the sides and the Frion flowed up the sides, cooled the bar and the bar cooled the vacuum tubes." Computers in this period were hot. That's a well-known fact. This was usually dealt with via forced air cooling. Manifolds would direct air over the machine's scalding vacuum tubes. In some more sophisticated setups, an air conditioner would chill the air before it was,

well, forced through the computer. It's the air that would do the first. final work here. The air removed heat from the tubes. Univac, for instance, is sometimes called a water-cooled computer, but that's because it used water in its heat exchangers.

The vacuum tubes were never wet, except maybe with condensation during some failure cases. Franklin is describing something, well, as he said, it's different. It sounds more like vacuum tubes were in direct contact with a heat sink.

and that heat sink was cooled by a Fri-on system. I gotta say, I've really never heard that one before. It's kind of like Radak had an air conditioner built into the chassis of the machine, with each vacuum tube in direct contact with the AC's heat exchanger. Which is one way to do it, I guess. I think it's a pretty heavy-handed approach, right? Maybe even overkill. Early machines did get darn hot, but most other computers managed with air.

I think there's a rhyme between Fri-on cooling and the four-address architecture. Why would you choose to have each instruction in the internet jump? Well, it might be useful in the future to let programs be laid out in any order you could ever want. Why use a complicated Fri-on cooling system? Well, we don't know exactly how hot Radak would get, and it would be bad if it got too hot, so let's have some safety margins. It feels to me like premature optimization. It's so early that we don't really have a playbook for how to build a computer.

There's space to experiment and play around. That can lead to inspired decisions, like a hunting tape drive or odd optimizations for things that don't actually matter. Now, that's all well and good, but... How do you know the machine actually works at all? You could turn the thing on, but that doesn't tell you a whole lot. Radak actually performed self-checks on almost everything it did. When data was transferred from memory, it was checked.

When numbers were added or multiplied, results were checked. If things didn't add up, or I guess if things didn't multiply up, an error was raised. Why would you bother doing that? Well, in short, is to prove the computer actually worked. I know that sounds a little tongue in cheek, but that actually is the fact of the matter. Here's how checking is introduced in a digital computer for scientific applications from 1948 by CF West. Quote, it is desirable that a computer be self-checking in order to minimize the number of undetected errors.

The error checking mechanism should be highly diagnostic. so that the location of a defective part is indicated whenever an error occurs. By incorporating diagnostic checking equipment in the design, the troubleshooting of equipment failures is greatly facilitated, and the percent of total time during which the machine is operative is proportionately increased. End quote. Do you really need any more evidence that computing has come a long way? Radak had a very complex self-checking system.

It took up, quote, less than 20% of its circuits, which I'm just going to guess means that 19% of Radak was devoted to self-checks. The whole point of the system was to alert an operator when something broke. Sadly, we don't have a manual for Radak, but we do have a rough drawing of the machine, some photos, and prose descriptions in a handful of papers. Radak had a special error-checking panel at its control desk. When an error was detected, the machine stopped, and the error was displayed at the panel. West says that magic panel would even show you which component had failed. The whole point of the system is that Radak and early machines in general were not reliable.

Parts would break pretty often, so you had to have some way to diagnose and fix the failure. If you had a panel that told you which delay line was not working, that'd make it pretty quick to get out of that downtime. To quote Russell McGee, a Radak programmer, quote, reliability was our other problem. Ours was very poor, he continues. The Radak was a self-checking machine, which meant it fully checked everything it did,

and if it found any errors, it would stop. It was nice that it didn't create errors at electronic speeds, but it was not so nice to be stopping for errors all the time, end quote. It's nice to have, but it sucks that you have to have it, right? So, how was checking accomplished? The traditional explanation goes like this. Radak had a complex checking system that was similar to casting out nines, but far more sophisticated.

I'm going to follow that tradition. We'll get to the finer details, but the core of this checking system works the same as cast. casting out nines. Wait, have you never heard of casting out nines? That's fine, neither at I until I started hitting the Radak books. This is a very old method for checking your math. In fact, the ancient Greeks may have used a similar method,

and it was in pretty common use up until computers got good. It's one of those methods that a lot of people would have known in the past, especially in the period where these Radak papers were being written. It sounds a little like a number game or like a little trick, but it actually works. This comes down to a method of simplifying numbers. The rule is that you add each digit of a number to get a result. If that result is more than one digit, then, well, you add those digits. You keep doing the process until you end up with a single digit.

That's your checksum. It's a smaller fingerprint of your number. So 1024 would turn into 7. 256 would add up to 13, which turns into a 4. We can also apply this checksum to a sum of two numbers. 1024 plus 256 is, what, 1285, that reduces to 7. Here's the part that blows my mind. If you add the two checksums of your operands, you should get the check sum of your result.

7 plus 4 is 11, which simplifies to 2. That should match the checksum of our earlier result. But, oh, wait, I made an error somewhere. 1024 plus 256 is 1280, 1280. That check sum is 11, which simplifies to 2. And that matches our sum of our checks sums. Okay, good. I'm a little rusty, but that's fine.

I got there. method actually did catch my errors. This trick works the same for multiplication and division. The result of an operation on check sums will always line up with the result of operations on real numbers. Why is this called casting out nines? Well, it turns out that the digit nine doesn't actually matter when you make a check sum. It ends up falling off, basically. 1 plus 9 is 10. When you reduce that, you get one. As a result, you can ignore nines when you do checksums, hence why it's called casting out nines. You throw them away. Radak system is a modified version of casting out nines. Honestly, the description in most articles on radak is more confusing than it needs to be.

Casting out nines works in base 10. Radak uses base 32, so it's technically casting out 32s. That's the real substantial difference. But how is that done automatically? Well, have you noticed I haven't really discussed how memory works on Radak? Technically speaking, Radak uses 45-bit words in memory. Older machines tend to have these really wide words. They like to pack in the bits. But 45 is a little wider than the competition. In practice, Radak actually used smaller number sizes, but these spaces in memory are just very wide. The reason for this is that Radak stores extra data for checking. Numbers are stored in memory as 35-bit values. There's another bit used for the number sign, so it takes us up to 36 actual data bits.

Five more bits are left blank. know why, I think it's probably something about timing, since this is stored in a delay line. Then four bits are dedicated to the, quote, transfer weighted count, aka the checksum. When a number is stored in memory, Radak calculates that checksum, which is thrown into Mercury along with the number. When a number is read from memory, the checksum is recalculated and compared to the stored checksum. If there's a mismatch, the machine stops and alerts the poor long-suffering operator is that, yes, in fact, Radak is broken.

Something similar happens during nearly every operation. When you add two numbers, a dedicated circuit calculates and adds the checksums, runs a checksum on the result, and then compares everything. When an operation fails, Radak just immediately stops. I think this goes to show how far. faulty early computers were. Something near 20% of Radak was devoted to error checking. 8% of its memory was used to hold checksums. This is in a period where every single bit counts. Every cycle is important. When Radak is delivered, there are fewer than 100 computers in the world.

So a tick is a valuable resource. The same goes for a bit. This means that error checking was expensive. It had to be very important to warrant that expense. In 1953, Radak is fully completed and delivered to Point Mugu Naval Base in Southern California. But that was not the end of things. Once delivered, Radak underwent a test campaign, something like a digital shakeout cruise. Franklin Dean describes this process in operating experience with Radak, published on the year of the machine's delivery. At the end of the paper, Dean includes a quote from Francis Murray, the man that observed these tests for the Navy. It includes one particularly interesting line. Quote, the percentage of downtime for the computer during these tests was reasonably good if one takes into

account the fact that this is a new computer, end quote. The machine worked. It did pass all of its tests, but it didn't have the best uptime. It just wasn't a very reliable machine, it turns out. This is further attested to by McGee. He wrote a whole book about his experience with Radak. Sadly, I found this book near the end of my research, so I haven't read the entire thing, but I have found some very important passages. Radak had interesting failure modes that I would never even imagine. To quote, we did everything imaginable to improve radak reliability. At one point, closing the door to the computer room was found to cause acoustical shockwaves

to be propagated into the mercury of the delay line memory. These shockwaves were causing memory errors. The memory was in a separate rack located 10 feet inside the back door of the computer room. Because the doors were quite heavy, it was customary to close them with a bang, hence the problem. So everyone was cautioned to close the door easily or use the other door if possible. This helped, but errors continued to occur frequently. End quote. Imagine that. If someone exited the room with a little too much gusto, your computer goes haywire. The self-check panel lights up like Christmas and the machine goes down. That's hilarious and awful. Part of this is just the

general fragility of early computers. Part of this is also the growing pains around early machines. McGee recounts something else I've never really considered. You see, Point Mugu wasn't new to the digital game. Radak was their first honest-to-goodness computer, but they had something very similar down the hall, an IBM CPC, a card-programmed electronic calculator. The CPC is one of those almost computer devices. It's programmable in the sense that it will run a series of instructions on punch cards,

but it doesn't have memory and can't store programs. But besides that, it's kind of a computer. At least it's the next best thing. It can do a lot of the tasks that a machine like Radak was bought to do. The head of the CPC machine room would always twist McGee's ear about this new computer thing. Apparently he believed, quote, Radak was a big waste and that he could do anything we were doing faster and cheaper. Why? Well, reliability aside, it came down to early adoption.

Radak required dedicated and specialized staff. In 1953, the Office of Naval Research published a survey of all digital computers operational at the time. It's a snapshot of a number of features and details about these machines. It's a little hit or miss when it comes to the dataset, but it gives us a super useful idea of the field. Radak had 52 staff assigned to it. That included operators, programmers, mathematicians, and operators in training. 52. A particularly revealing aspect of that statistic is that it includes trainees.

In 1953, there wasn't a professional class of computer people. Existing experts were very scarce. McGee's autobiography includes something that really makes us hit home. He has photos of a classroom full of trainees. To make use of Radak, you need a large staff, and you need a specially trained staff. The Navy had to start from zero and build up the actual expertise to use this computer. There was only one Radak, so you couldn't advertise for folk who had worked on the

machine. The Navy and Raytheon could compile a list of everyone who knew what Radak was, and that would fit on a single sheet of paper. There were over 150 IBM CPC installations. That meant you could advertise and hire experienced CPC operators. You didn't need the same type of specialized staff, and you could draw from a larger pool of experienced users and, well, just a larger pool of experience. Ultimately, the Radak just wasn't the best machine to work with. McGee, after recounting a particularly complex story of hacking the machine to do integration, wrote, quote, in spite of good experiences like this one, it was difficult to remain positive about Radak, end quote. He would move on to greener pastures. That's clear to see why. Radak came near the end

of the era of unique machines. There were just better machines in the world. It's convention to call all vacuum tube computers, quote, first generation computers. I think it's dumb to do that personally, in reality, there are two very different classes of machines in that generation. The earliest are unique computers, like Edvac, Whirlwind, Bynac, and Radak. The second are serially produced computers, machines like Univac, the IBM 701, the LGP30, and even the IBM CPC, if we choose to call it a computer. That jump to commercialization isn't just a matter of churning out one of the or two more machines. It's a much more fundamental shift. That's why I think it's kind of silly

to call all vacuum tube machines first generation. A machine like Radak is totally unique. It's experimental. It's built at a point where there's almost no prior art to work from. Unique machines tended to be unstable, strange, and painful to work with. Part of that was early adoption. Part of that was the fact that there was no ready community around the computer. Can you seriously compare Radak to an IBM 701 or a Univac? No. I don't think you can. Just the social aspect of mass-produced machines is different, which means that they're used in a different context and in a different way. The supply chain is totally different. That has effects on reliability and convenience, even if your experimental machine has good uptime.

You can't call up the service department for Radak and have an entire tape drive overnighted. There are four Radak tape drives in the world. And if your error panel says one of them's broken, well, you're sitting in the room with every one of those tape drives that's ever been in existence. All right, that does it for a dive into Radak. It's an absurd. It's an absurd. obscure machine, to be sure, but there's a lot more information about it than I first assumed. I was able to track down a number of good papers discussing the machine. Four oral histories, one autobiography, and a pretty sizable paper trail about its contracting and development. That's a lot for such an obscure computer. What I couldn't track down were manuals or programs. That's more

odd. In fact, the only code I've come across for Radak was a small sample program in the back of McGee's autobiography. That's all we get. Raytheon's first computer is just strange in a number of ways. It shows a certain level of sophistication at points. Its mercury delay lines are just a little more advanced than we would have seen in other machines. Its tape drives were playing ahead of the time. In other ways, it was a dead end. The four address archery. architecture just wasn't a good choice. Fri-on cooling made it more complex than other machines, and self-checking while useful for catching errors made the machine around 20% larger and more complex. What we're left with is a picture of unsolved problems. Computing was so new that

any idea could be a good one. We just didn't have all the data to tell what would work, what wouldn't and what wasn't necessary. Ultimately, that's what I love about unique computers. Some of these machines are wild prescient hits like whirlwind. Others, well, others are just plain odd. Thanks for listening to Admon of Computing. I'll be back in two weeks' time with another piece of computing's past. If you like the show, you can support me on Patreon.

You can also listen to Adjunct of Computing, the advent of computing aftershow. You can find links to everything over at advent of computing.com. And as always, have a great rest of your day.