Advent of Computing - Episode 120 - Simply COSMAC

Episode Date: November 13, 2023

Have you ever opined for a simpler time? Have you ever wanted a computer that you can understand all the way down to the silicon? Then RCA's COSMAC might be the architecture for you! COSMAC was a simplified computer architecture designed in the early 70s. It's tiny, cheap, and built to be easy to understand. But is the chip actually useful?   Selected Sources:   https://archive.org/details/manualzilla-id-5721710/page/26/mode/1up?view=theater - All the ELF articles in one place!   https://sci-hub.se/10.1109/MC.1974.6323475 - A Simplified Microcomputer Architecture

Is progress in and of itself a good thing? Is it always better to make technology bigger, more complex, and more powerful? As someone who works professionally in the tech sector, and as an observer of computer history, this is a question that I often grapple with. I think it's a question that everyone should grapple with, especially if you work with computers. Not every new technology is actually useful. Some advancements are simply shams made to take us in and make a few bucks.

Some are way more trouble than they're worth once you get down to it. Still, others are just a single step down a dead-end road. Now, those are all pretty complex scenarios. I can name a handful of times that new technology was used as a grift. I've covered some of those on the show. Cough, cough, viatron. I can point to advancements that led researchers down useless paths. And I can even point to some tech that, while a huge leap forward, is actually a huge headache in practice.

Cough, cough, my beloved cryotron. All those examples lead to long, drawn-out discussions and huge sagas. But I have an easier example at hand. Technological advancement can quickly lead to technology that's simply too hard to understand. The wheels of progress can grind so fine that they chew up any acolytes that approach too closely. We can see this phenomenon in the long arc of computing's past. Give me five minutes and I can probably explain how a very early machine worked. They didn't have many parts, they didn't have many features, and those features that they did have were very simple. This was all by necessity.

Progress was still slow back in those days, but describing an early machine will give you the foundational bedrock to understand a modern computer. But let us turn to those modern computers. Look at, say, any processor made this century. Do I know all the ins and outs of a modern chip? No, there's no way that I could. I'd have to be specialized in just that one field. I'd almost need a degree in electrical engineering to get started. Modern processors pack in so many features and so many complexities that the mind reels. Newer Intel chips, for instance, have at least five different operating modes that they can run in. These new chips even have multiple processors packed onto a single wafer of silicon, with all the requisite circuitry to communicate between

those processors. There are even hardware-level mechanisms for protecting and managing memory. That's all packed into the chip itself. While all those features are a boon to anyone that uses a computer, they introduce a problem for programmers and for hobbyists and novices especially. How can someone from the outside world hope to ever understand one of these chips? If you sat me down with a thousand-plus page manual and a processor, I think I'd actually just leave the room. It would be too much to take in, especially as a side thing. It wouldn't be fun as a hobby. It would be a slog that would suck up all your time. Progress has pushed out the novice in favor of industry veterans, or those who have time to earn a whole degree, at least

on the very low end, on the chip level. But does it have to be that way? Is there an alternative to this model of progress? Welcome back to Advent of Computing. I'm your host, Sean Haas, and this is episode 120, Simply Cosmac. I'm back from spook month, and that means it's time to recenter ourselves with a classic topic. Today, we'll be discussing the RCA-1802, a weird little microprocessor from 1974-ish. I've covered a lot of chips on the show, so what makes the 1802 special? What makes it stick out from the others? Simply put, it's simple. There's this old adage that shows up again and again. It's called the KISS principle, or keep it simple, stupid. The idea is that if something becomes more complicated, you're apt to run into more problems, so it's best to just stick with the basics.

Don't add too many features, don't worry about optimization too early, just, you know, keep it simple, stupid. This principle is at the core of the 1802. To quote from a 1974 paper describing the new machine, the motivation behind this work has been the view that for 20 years computer hardware has become increasingly complex, languages more devious, and operating systems less efficient. Now, microcomputers afford us the opportunity to return to simpler systems. Inexpensive LSI microcomputers could open up vast new markets. Unfortunately, development of those markets may be delayed

due to emphasis on performance levels which prohibit minimum costs. End quote. I know it's early for a quote, but I really like this one. The motivation behind the 1802 is that computers were too complicated. Large machines, from mainframes to minicomputers, had these decades of baggage and expectations that made them lumbering beasts. With the advent of the microcomputer, well, there was an opportunity to push back the hands of time. This could be a fresh break, a new beginning. A whole new type of computer could be created, one that was founded on earlier principles while taking advantage of newer technology. All it would take would be a simple and cheap chip. This was a very new approach. I mean, heck, this is a very new approach.

approach. I mean, heck, this is a very new approach. Look no further than the contemporary field. In the 1970s, you have Intel's 8-bit processors, which are based off of legacy technology and locked into this infinite death spiral of technical debt. The 8008, Intel's first 8-bit processor, is a re-implementation of a random smart terminal from 1969. All of Intel's big chips fall into that lineage, so they're stuck in this legacy rut of re-implementing older, larger computers. Intel's second 8-bit chip, the 8080, was designed as an extended and souped-up version of the 8008. Performance and capability was the driver of development, not necessarily simplicity, and cost only somewhat. If we go further afield, we even reach more wild quote-unquote microprocessors. There's this whole group of

multi-chip processors from the very early 70s with inflated feature sets. Their architecture diagrams span pages just to describe how data flows from bus to accumulator to outputs. But I shouldn't get too ahead of myself. The 1802 is so interesting because it pops up in this period of very rapid development, but it takes a path against the prevailing winds. As other microprocessors are getting faster and more powerful,

RCA's chip is built to be simple and cheap. It's a whole different philosophy. And while there are chips that were built to be cheap, they don't really have simplicity at their heart. So how did this weird project get its start? How do you even design for simplicity? And perhaps most interesting of all, was the 1802's simplicity a good thing, or did it actually hold the chip back? My guiding light for this episode, and the source for that earlier quote, is a paper titled A Simplified Microcomputer Architecture by Joe Weisbecker.

It was published in 1974 in IEEE. The paper describes this new simplified machine as it stood in 1974. But by that point, the project was well underway. To get to the bottom of this, we need to go back to 1970, maybe actually a little bit earlier than that. Weisbecker is one of those characters that, I'm honestly amazed, isn't better documented. He passed away relatively young, so we don't have recent interviews with him. No oral histories either. We just have articles he wrote and a collection of his papers. And honestly, I'm kind of shocked that no one's written a biography on this dude. Perhaps this is one of those exercises that I'm going to leave here for the reader. Joe was born in the 1930s in New Jersey.

He earns a degree in electrical engineering a few years after his birth, then starts working at RCA as an engineer. That's a pretty standard backstory for a computer person of this era. standard backstory for a computer person of this era. What's not standard is that Weisbecker seems to have had a fascination with toys as educational tools. A collection of his papers are housed at the Hagley Museum and Library in Delaware. Browsing the online listing, you'll come across dozens of papers and pamphlets outlining small games or other ways to teach about engineering, mathematics, and computers. I may go so far to say that Weisbecker could have been a career educator if he wasn't employed as an engineer. This is a unique perspective that he brings to

the table, a perspective that will serve him well throughout his entire career. that will serve him well throughout his entire career. One of the most well-documented of these games is called Think-A-Dot. It's not the best name, but it's an interesting game. The game was developed by Weisbecker and sold in the 1960s. It's a simple plastic grid with semicircular shutters at each grid point. The shutters can rotate to open or close tracks that go from the top to the bottom of the grid. Dropping a ball bearing down a track will cause The shutters can rotate to open or close tracks that go from the top to the bottom of the grid. Dropping a ball bearing down a track will cause any shutters it travels past to flip, thus changing the path open for new balls as they drop down. In other words, this is a simulation of a grid of flip-flops. The aim of the game was to get the shutters into a certain state,

to create a specific pattern by dropping balls down the chutes in the correct order. It was a simple and automatic logic puzzle aimed at children. The Thinkadot was just one of a pile of these educational games that Weisbecker invented. That's the main character of the saga, but what about the setting? What about RCA, the Radio Corporation of America? Depending on your age, you may or may not know that name. I personally remember watching TV on an old RCA-branded set.

If you go back further, you might have owned an RCA sound system, but that's all very consumer-grade stuff. RCA was, first and foremost, a radio company. That's how they got their start back in the 19-teens. Their primary products were hardware used for receiving, playing, and transmitting radio signals. On the surface, that may sound pretty far from a computer company, but that's where you'd be wrong. Radio and early computers actually go hand in hand. There are a shocking number of connections between old-school radio technology and early digital systems. Case in point, the vacuum tube. I actually keep a vacuum tube on my desk. It's right nearby as I'm recording this. These little glass tubes were the core element of

computers from, well, their advent up until 1960 or so. But vacuum tubes weren't initially meant for digital use. Rather, tubes started life as analog devices. They were intended as a way to rectify signals in radio and a means to amplify audio. It's radio stuff, pure and simple. There were a number of tube manufacturers back in the day. My personal desktop tube is a Sylvania brand, but RCA was also a major source for these devices. As the first computers were cobbled together,

companies like RCA were right there on the front lines. ENIAC was actually composed of tubes manufactured, as near as I can tell, by either RCA or Sylvania. Maybe both. The specific types of flip-flops used in ENIAC were sold by those two companies. So despite being in the radio business, RCA was very close to computing. The corp would continue to stay at the cutting edge of this shared technology, and as tubes were replaced with transistors, RCA moved from working in glass to silicon. In fact, RCA even made their own computers.

This is actually something that I had no idea about. In the 1960s, RCA built this series of machines called the Spectra 70s. Now, I don't know a whole lot about these machines. I feel like this is the tip of a very big and concerning iceberg that I will have to deal with one day. The Spectra 70s were somewhat compatible with IBM System 360s, Big Blue's top-of-the-line machine in this era. And that is, well, that is very strange. That's really, really weird, and it's something that I'm just going to pass over and think about another time, because we have to move on. The point here is that RCA had manufacturing resources to make full-on computers, and they also had the technical know-how to do so. By the 70s, RCA isn't just a radio company. They're spread out into multiple fields.

They're making transistors, integrated circuits, even computers. You could probably crack open a spectra and find piles of components made in-house by RCA themselves. It's in this environment that our buddy Joe starts to complain. One thing we know about good computer folk is that when they complain, they quickly turn to scheming. Now, before we move forward, we do have some caveats. The earliest part of our timeline is a little sketchy at best. It's suggested that Weisbecker started putting plans together in 1970, maybe 1969. The story I'm going to present is put together from publications made later in the 1970s and this one article from Fast Company that sourced information from an interview

with Weisbecker's daughter, Joyce. In either 69 or 70, Weisbecker started designing a computer. According to Joyce via Fast Company, quote, he wanted to buy a Heathkit to build a computer, but since there weren't any available, he decided that it was his goal in life to design a Heathkit for computers so that anyone could build one. End quote.

Something funny to note here. Heathkit was a company that sold electronic kits in this period. You could get kits to build things like amplifiers, radios, oscilloscopes, all that kind of nerd stuff. The kits would contain everything you needed to get started, from circuit boards and resistors up to nice enclosures and instructions. They were meant to be educational, so while you were building your new oscilloscope, you also learned how oscilloscopes worked. The fun irony here is that before the 70s were out, Heathkit would be selling computer kits. I actually have one sitting in the guest room very close to me right now, a nice H89 kit,

all assembled and polished and everything. But in 1969 or 1970, these kits didn't exist. And this is where we see Joe's educational slant taking hold. He didn't just want a little computer that he could use around the house. He wanted something more impactful. He would later write in a 1974 article, While stored program computers have been one of man's greatest achievements, the majority of people are denied direct contact with these fascinating machines. Why can't thousands enjoy computers as a rewarding new hobby? Why aren't children, who as a rewarding new hobby?

Why aren't children, who may be tomorrow's social problem solvers, having their minds turned on constructively by playing with computers? End quote. With no existing options, Weisbecker blazed his own path. And I want to be crystal clear about the timeline here. This is really, really early in the history of home computing. I can't underline this enough, so allow me to underline this in a few ways. The usual start date for the microcomputer era, if you want to go by eras, is 1974. That's when the Altair 8800 hit the scene.

is 1974. That's when the Altair 8800 hit the scene. This is the first computer that's powered by a microprocessor that a normal person could buy pre-assembled. There are a pile of caveats to that, but it's a good yardstick. The release of the Altair sparks a lot of interest in home computing. We can draw a direct line from that computer to everything from Apple to Microsoft. That said, we can actually push the timeline a little further back. In the early 70s, we're talking 73 or 72, there are a scant few home computers. These are still hobbyist machines, much like the Altair, but they are actual home computers that either came in kit form or pre-assembled. That said, they were manufactured in very small numbers. Going further back to 1971, we get a few oddities. One notable machine is the Kinback. This machine used TTL logic since

microprocessors did not exist yet. It was a neat computer and it was cheap, but only 50 were made. That's a sign of a bleeding edge to be sure. And that takes us all the way back to 1970, an era before any microprocessor existed even in a lab. This is before any home computer was practical. To go back any further really gets us into the weeds. We can pick up dangling threads of machines that either look like computers or might be somewhat personal. I'm talking things like the LGP30, a machine built in the 50s that was arguably one of the first personal computers. But this is really old vacuum tube stuff, not something that you could put on a desk for a kid to tinker with. There are other machines, like programmable desktop calculators, that

may have been simple enough to fit on a desk, but you have to argue to classify them as true computers. The point is that 1970 is really early in the timeline of home computing. Very few people were thinking along those lines, and very few were imagining educational computers. It's in this period that Weisbecker designs a machine he calls FRED, the Flexible Recreational and Educational Device. Now, I may not have made it clear by now, but I really like Joe's work. His papers are among the few that, taken in context, are shocking. He describes FRED as a cheap and accessible machine.

That, on its own, has a certain cool factor to it. But here's the shock. Weisbecker gets to a cheap machine by reducing its capability. He explains in A Practical Low-Cost Homeschool Microcomputer that FRED isn't a full-on system. It doesn't have buffered I.O. for interfacing with punch card readers. It can't run massive programs, communicate over a network, or handle complex peripheral devices. FRED is a reduced computer, a simplification of what large systems have become. It's a return to an older form. Simplicity was just one way that Weisbecker strove to reduce costs. He ends up taking an interesting route to get to a cheap machine. To quote, the approach described here involved defining a minimum cost, non-trivial hardware system that could easily meet a low price goal and then testing its usefulness. End quote.

In other words, just try building a cheap machine until you reach a point where it doesn't suck. This gave Joe a way to experiment with all kinds of cost-cutting measures. Simplicity is the most obvious result here. Fred was a very simple machine. It didn't really do anything fancy. Another way this cutting is manifest is the fact that Fred wasn't designed for performance. Another way this cutting is manifest is the fact that FRED wasn't designed for performance. It's not meant to run a factory or crunch statistical data, so it doesn't have to be all that fast, actually.

Its performance just needs to be fine. Nothing needs to be stellar. The final pillar to this design approach was to skimp on reliability. FRED wouldn't be running 24-7, far from it. It's not a mission-critical device. It's a fun little computer for use in schools and at home. So it's fine if the machine glitches out sometimes. It's not going to destroy anything or kill anyone.

It might elicit a curse at the most. Now, these choices may all seem trivial to us. I mean, I know consumer versions of machines tend to be a little worse than pro-grade equipment. My home computer isn't nearly as fancy as the servers I use at work, just like how my stove isn't nearly as nice as the one used at my favorite restaurant. But in this era, in the 1970s, there wasn't this kind of divide for computers. There were only professional machines. Even if you weren't a professional, you had to use a big pro-grade computer. In these early articles,

Joe was coming to grips with what it would mean to make a consumer-grade computer. That means you could use cheaper and less reliable parts. A home user is going to be tinkering around with a computer, playing games, maybe doing a little hobby programming. They aren't making a living using their desktop thread. More likely, thread will serve as a jumping off point. It's a way to get people interested and better versed in computing. It doesn't really matter if the thing breaks down on occasion. That's something that a consumer can live with.

The same goes for performance. A neophyte using FRED has never seen the raw power of an IBM System 360 mainframe. They've never bashed bits in a timesharing environment, or even heard of a programming language. They probably won't even notice if Fred is kind of slow on the uptake. By the end of 1970, or somewhere thereabouts, Weisbecker finishes the first working model of Fred, and it's all made in his home basement. It ran, it was programmable, and he even got his kids to use the things. His daughter, Joyce, would even program games for the platform. I can't think of a better proof of concept for an educational computer.

The machine was refined and tweaked over the next few years. But up to this point, Fred was a solo project, something that Weisbecker was dealing with on his own. But in 73, as the story goes, Fred was brought into the RCA fold. Now, I won't lie to you, dear listener, we are missing a bit of a bridge here. At some point, RCA took interest in the Fred computer. What caused RCA to look into Weisbecker's machine is unknown, at least to me. There may be a scrap of paper somewhere that has the reason for this, but I don't have it handy. I have a story in my head that I want to be real, but I'm pretty sure it's just a daydream.

In 1971, RCA actually sold off their whole computing division to Sperry Rand. It seems like RCA was just kind of sick of spinning their wheels with the Spectra, so they got rid of it. From there, RCA computers just slip away into the mist. Then, in 1973, the Radiocorp decides they want back in. My daydream, my Weisbecker fan theory, is that he spent the previous years pushing RCA to get into small systems. Weisbecker saw the way the winds were blowing. He knew that RCA could catch the breeze, so he lobbied the company to take up FRED. There are similar sagas in this period. It wasn't uncommon for engineers with their feet so close to the ground,

to try and steer the corporate ship in the right direction. But this is my speculation. We ultimately don't know why RCA wanted back into the computing market. What we do know is that in 1973, the company did want a new computer. They had all the tooling, all the know-how, and one of their engineers had a design waiting in his basement. And so Fred was brought into the fold. But the name didn't exactly stick. Rather, it evolved. This is one of the fun and impenetrable parts of the story. Fred would be used as the name for a theoretical low-cost computer developed at RCA. The architecture, which Weisbecker started in his basement, would now be called COSMAC. This new architecture, based off of the FRED prototype, is wild compared to what was out there.

Something interesting to note is that Cosmec wasn't initially designed as a microprocessor architecture, at least not in the sense we understand it. When Weisbecker started this whole thing, microprocessors didn't exist in the market. In 73, there were some microprocessors out there, but this was the very first generation of the technology. FRED, the prototype FRED, was made of discrete chips, discrete transistors. The first implementation of COSMAC, the 1801, was actually two chips that worked together to make one computer. It would take a good number of years before the 1802, a one-chip CO Cosmac, ever made it out of the lab. So right from the jump, this is a different path than contemporary chips. Alright, I think it's high time we talk

architecture. I've talked a pretty big game about how Cosmac and FRED were these little simple machines, but what does that actually mean? How do you implement simplicity? My first step in sussing out a processor is usually the block diagram. This is a big, gnarly chart that shows where all the data is stored in a processor, and how data flows through the chip from its storage locations into things like arithmetic circuits. In most cases, these charts are pretty hard to read. They end up looking like a mix between a circuit board and a spider's web, with arching lines and morasses of little boxes. For the COSMAC, however, that's just not the case. The diagram here is shockingly simple, so I want to go over the major parts of its anatomy and try to break down the technobabble.

The backbone of this chip is a bidirectional 8-bit data bus. A data bus is, simply, a bundle of wires that signals are sent down. Anything can plug into the bus and read or write those signals. The bidirectional part just means that anything connected to the bus can read and write. 8-bit, well, that's just the size. The bus can only handle 8-bit numbers at a time, which means that it's physically implemented as a bundle of eight wires, one for each binary digit. On the block diagram, this bus is represented as a line that encircles all the other parts of the computer. By following this line, we can see how everything's wired up. And in general,

most components are connected directly to this one bus. That, on its own, tells you something. directly to this one bus. That, on its own, tells you something. Cosmic is a very flexible architecture. Data can flow in a number of ways through this single bus. That's not only neat, it's also a nice simplification. Context here is what makes the Cosmic all the more unique. all the more unique. Perhaps it's not unreasonable to compare Cosmic to the IBM System 360. Now, stick with me. The 360 is a mainframe, one of IBM's biggest computers. That's pretty far from a little microprocessor, but recall that RCA had been manufacturing a machine that was nearly compatible with the 360. So this is an architecture that Weisbecker would have likely been familiar with, at least in passing. If you pull up a block diagram for a 360, you're immediately met with a rat's nest of components. As you break down the diagram, you start to notice something strange. Once again,

lines represent pathways that data can flow, with blocks representing where data can be held, and where operations can occur. In the 360, data has this rigid set of paths that it has to follow. To get a number from memory to its adding circuits, for instance, that data has to flow either through one or two registers. There are all these short lines that represent where data is forced to flow from one box to another, from one register to another. It's not flexible, it's rigid and it's complex. It's showing that there are rules that you have to follow to do specific things on a 360. And those rules are kind of hard to remember and hard to understand unless you're very familiar with the platform. By contrast, Cosmax data just kind of flows around.

Let's stick with the math example here. The circuit used to perform math in a processor is called an ALU, an arithmetic logic unit. In CosMac, the ALU is wired directly into the data bus. That means that it's a very short jump from memory to math. You can directly throw a number from memory into the ALU. You can operate on a number stored in RAM. The same goes for a number pulled from some input or output device. If I'm reading the chart right, you can actually plug in a keypad and type directly into Cosmax math circuits.

Not only is that simple to manufacture, it's also really easy to understand. If you have a number, you can perform mathematics on it. Easy. Not only is that simple to manufacture, it's also really easy to understand. If you have a number, you can perform mathematics on it. Easy. If you thought that was cool, then wait till you get a load of the registers. In the past, I've usually explained registers as little chunks of memory that live inside the processor. They hold data that the processor is currently processing or some kind of state information that the processor needs to keep track of. In practice, registers aren't

exactly memory. The distinction here is a little fine, to say the least. In conventional memory, as in RAM, data is stored at addresses. You call up some memory by address. When it comes to registers, data isn't addressed. It's stored in discrete segments with unique names. The Intel 8008, for instance, has registers named things like A, B, and C. Now, technically in machine code, you will reference a register by number, but that isn't going through addressing circuitry. It's just a convention that the chip knows about. Now, there are also physical differences to consider. The actual circuits that make up registers are often slightly different than bulk memory circuits. This is just because registers serve a slightly different purpose than conventional memory.

There are different tricks and optimizations for each use case. There's different things you need to be aware of. Okay, so here's where Weisbecker pulls a really big brain move, I think. The COSMAC architecture has a register set that seems really weird on the surface. It has 16 general purpose registers that are each 16 bits wide. It has one 8-bit register called D. The set is filled out with four tiny 4-bit registers called P, X, N, and I. That, dear listener, is weird. Cosmic is supposed to be an 8-bit computer. That's what it says all over the marketing material. So why does it have

16-bit registers? And why does it have 4-bit registers? Let me melt your mind a little bit. The set of 16-bit registers is actually just a chunk of memory. You can see it on the etching of the CPU itself. There's this big rectangular region that's just straight up normal computer memory hidden inside the chip. Those general purpose registers don't just look like memory, they're also accessed and used like memory. You can pull up these registers by their addresses, from 0 to 15. This is done using 4-bit registers. Now, something to note if you aren't used to binary convention. You only need a 4-bit number to represent 16 possible values. So these weird 4-bit registers are hanging around because that's how you need to address the tiny chunk of in-chip memory.

This leads to a weird maneuver. To work with a general register, you first load up one of those 4-bit registers with an address. I'm inclined to just call these pointer registers, since they're used as a way to point to somewhere in onboard memory. Once loaded, you can pull up a register by that address. So in practice, to access register number 5, you would first set p to the value 5. Then you tell CosMac to pull from the register that p points to. Now, that sounds very convoluted, right? Well, there is a purpose to this. It's all part of a larger sleight of hand going on inside CosMac.

The next part of the trick comes down to the instruction set. That is, the binary code the computer speaks. So hold this pointer register stuff in your head for a few minutes, because we're going to have to circle back to the weirdness and why it matters. Most instruction sets are actually quite sophisticated, even on early microprocessors and early computers. Since the processor speaks binary, most instructions are packed pretty tightly. I'm going to stick with the 8008 as an example, since it's close to what I know. Each of the 8008's instructions are 8 bits wide, which makes sense. 008's instructions are 8 bits wide, which makes sense. The thing is an 8-bit computer. It has an 8-bit data bus, so an instruction is just a single slurp off the bus. That all lines up.

The annoyance is in how those bits are packed together. Take the load instructions as an example. Those all use 3-bit numbers to represent sources and destinations. You'll note that 3 is not a very computer number. It's an awkward size to work with and an awkward thing to remember. It's one of those little gotcha rules that only applies to a very specific case. Calling up a subroutine is even more, well, weird on the 8008. To call a subroutine, you specify the code's address as a 3-bit number. The processor then adds three more zeros to the end of that number, getting a 6-bit number, and uses that as the final subroutine address.

and uses that as the final subroutine address. Once again, we get this mess of weird and confusing rules. You just have to know exactly how calling conventions work on the 8008. You can't guess that off the top of your head. You just have to know it. You have to learn by rote. By contrast, Cosmac is dead simple. Its instructions are 8 bits wide, which matches the internal bussing. So far, so good. During execution, an instruction is pulled into two of the chip's 4-bit registers. One register, I, gets the first 4 bits. The register, N, gets the final 4 bits.

There are 16 main types of instructions as specified by the part in I. The end part of the instruction gives more specifics on what to do. It gives arguments. And that, well, that's it. That's just kind of how the instruction set works. There aren't very many gotchas or weird rules. It's just two hexadecimal digits. For instance, let's say I want to increment the value in general purpose register number five. I can actually spit the machine code for that right off the top of my head. It is one five. One is the code for increment, and 5 is the code for register number 5. And that's it. That is shockingly simple and easy to remember compared to Intel's weirdness. This is also why we have this wonky register setup going on.

These 4-bit registers are just right for addressing the weird internal block of RAM, and that lines up perfectly with the machine code. N is one of those pointer registers. It's one of the registers that can be used to address the internal general-purpose RAM. It's a very simple instruction set that's designed very well to work with the rest of the computer. It's also really basic. I mean, there's only 16 instructions. That means that Cosmac only needs to know how to do 16 things. Now, there are a few outcomes here. The most basic one is that Cosmac's machine code is a lot closer to human readable. It's just a whole lot easier to understand than, say, the tongues over at Intel. After consulting some charts, I think I could actually work up a simple program for the chip.

I have actually never felt that confident about any kind of machine code before, so this is, believe me, a big deal. This tiny instruction set also means easy decoding. When a processor gets an instruction, it has to first decode it. The chip has to figure out what the instruction actually means, what the user wants. For a chip like the 8008, this is a somewhat complex process. There are a pile of different possible instructions and arguments that are just kind of embedded in those instructions in weird and not always consistent ways. For Cosmac, well,

this couldn't be easier. There are 16 instructions, so you just need to check for 16 possible patterns. Arguments and modifiers are separate. That's shockingly simple. What you get from all this is, and I know I keep repeating myself, just a simple little chip. The slightly non-standard approach to registers meshes perfectly with the slightly non-standard instruction set. Another benefit here is that code for Cosmic can tend to be smaller than code for competing microprocessors This was one of the benefits that Weisbecker discussed at length Now, I personally think this might be a bit of a dubious claim Weisbecker says that since each instruction is only a byte long

You can pack more code into a limited amount of RAM But this gets kind of weird. Yes, instructions are all a single byte, but some instructions expect the following byte to be another argument. This is the case for instructions that deal with numeric literals. In plain English, if you tell Cosmac to add a number to a register, then it expects the next byte of the program to be an actual number. Those type of operations aren't entirely uncommon, so in practice, I think instruction size on the Cosmac is about 1.1 bytes or something if you do an average.

That's not a huge deal, but it's something to point out. When it comes to competition, well, they tend to follow a similar pattern, at least on the large scale. The 8008 does the whole byte plus optional number thing for instructions. So does the MOS6502. Some larger computers had more exotic instruction set sizes, so I guess there's that. In reality, I don't think code size is really a huge benefit of Cosmex design. This is one of those arguments that I've seen come up a number of times when discussing computers, and I don't think it's ever actually mattered. From what I gather, it's a bit of an academic argument. The final part of Cosmex architecture that I want to discuss is direct memory access,

or what us nerds call DMA. Now, this is one of those things that I always assumed was just really complicated in principle. I've spent a lot of my youth programming x86 chips down at a low level, and on that platform, DMA is frustrating and confusing. The general idea is this. You set the computer into a special state where a program can keep running while a peripheral device directly manipulates memory. This is useful for, say, reading data from a disk drive without interrupting the current program. On the PC platform, at least in real mode, that's done using a separate DMA controller chip,

so you have to program a chip inside your program. It's weird and messy, and I never have good luck doing it. Now, DMA is a really neat feature which usually goes hand-in-hand with multitasking. Take the beautiful classic Macintosh as a counter-example. That platform, initially, didn't use DMA for moving around data on disks. As a result, when you want to copy a file from one floppy disk to another, the system tends to seize up for a while. DMA is a thing of beauty, and without it, stuff gets fouled up. Cosmac had very low-level support for DMA. For a simple chip, for a really basic design, that should sound strange. But hey, we're dealing with a strange chip today. Here's how it works on CosMac.

An external device simply tells the chip that it needs to do a DMA transfer. This is communicated by setting a flag on one of the chip's pins. Between instructions, the CosMac falls into this idle state, during which it checks for things like DMA requests. When it finds a request, it tells the peripheral, okay, I'm not touching memory right now, so go ahead and do a transfer. The actual data flows through the processor on the internal bus, which, going back to the fun diagram, actually connects the I-O interface directly to the memory interface. In other words, DMA will let another device throw data directly into memory. The major use case here is, of course, reading data off of media.

But Weisbecker also mentioned something cryptic about televisions. I'm sure that won't have any bearing on the rest of the story, though, right? Alright, take a deep breath, because that's all the big architectural stuff about the Cosmac. In general, we're looking at a chip that's really simplified. This has impacts on cost and manufacturing, and on the understandability of the platform. Cosmac, at least the way I see it, is uniquely designed to be educational. Its entire design is informed by this goal of simplicity, and as near as I can tell, Cosmac smashes that goal out of the park. This architecture was first implemented in the RCA-1801, as I mentioned before, the 2-chip processor. That

was replaced by the 1802 in 1974, itself a single-chip rendition. From there, the processor would find its way into small computers and embedded applications. It may do. There are some interesting articles from this period about how the 1802 could be the centerpiece of a small machine. I believe RCA even built a video game cabinet around a CosMac chip. But the big hook, what everyone seems to get excited about, comes in 1976 with the CosMac Elf. The Elf has been one of those computers that I've known about, but I've never actually known that much about it. I've heard the name, basically, and that's about it. It's one of those little systems that still has a following, so you still run into sites online where people are discussing and building elf computers. If

you've ever attended one of the many Vintage Computer Federation get-togethers, then you'll invariably see an elf or two on display. But elves can be slippery little machines. But ELFs can be slippery little machines. Back in the day, you couldn't actually buy an ELF, at least not at first. It was a kit, or rather, a set of instructions that was passed around via the pages of popular electronics. As such, ELF computers aren't identical. They're each these little handmade wonders. But yet again, I'm starting to get ahead of myself.

We should first discuss what kind of computer the elf was. We're dealing with what's known as a computer trainer, or a training computer. At least, that's how I'd classify the little elf. Trainers are one of those extinct breeds of systems. At least, any trainer that exists today are pretty different from their progenitors and pretty scarce. A trainer was a simple computer, usually consisting of a single board and only the bare essential chips. It was meant as a way to introduce people to a new microprocessor. Training here means actual training, as in learning. You'd get your hands on a trainer, usually accompanied by a pile of documentation,

and then set to work learning how the chip could be used. These were meant as simple systems, and often cheap systems. The simplicity here is intentional. As learning platforms, it's better to start off simple, to showcase the actual microprocessor at the heart of the computer. Trainers could also be used to jumpstart third-party software development. A chip manufacturer could quickly throw together a trainer or a development board, send it out to programming houses, and start the flow of software earlier, before manufacturers even had completed full-on computers. Trainers often had this strange dual audience for them. The CHEM-1 is a great example here.

That was a training system developed by MOS Technology. It was initially meant to be sent to software and hardware companies as a way to get folk using the new 6502 processor. It was also cheap and simple, so hobbyists very quickly adopted the machine. Thus, you could find Kim 1s at brand name computer companies and in random garages out in the suburbs. Just keep in mind that the hobby market wasn't really intentional for the Kim 1. But the Elf, well, that's a different story. It was a consummately hobby machine.

It was released, if we can call it a release, in August of 1976. Maybe it would be better termed as a debut. That month's issue of Popular Electronics ran a very, very exciting cover story. Quote, That's in boldface, as befits such a wonder. Let me put that in context, because that $80 figure can seem kind of meaningless on its own. context, because that $80 figure can seem kind of meaningless on its own. The Kim one, the 6502 trainer of hobbyist streams, was released that same year. It was seen as a low-priced machine, that's why nerds scooped it up. A Kim would set you back $245. Another fun comparison here is the Altair 8800. That computer was also a cover story in

Popular Electronics, with its article running in 1975. The machine sold either assembled or as a kit. The cheapest option, the unassembled kit, came in at $439. An $80 computer was, frankly, a wild thing to see in print. That's the kind of headline that should be in boldface, and maybe topped off with a few exclamation marks. That said, the price tag for the Elf does not include manual labor. There were some computers in this era, like the Altair, that could be ordered as a kit. You'd get a box full of components, printed circuit boards, and even a case in some cases. The ELF was just a set of instructions, a circuit schematic, and a parts list. The heart of that list was an 1802 microprocessor, the one-chip CosMac.

At the time, one of those chips retailed for $30. Now, what's interesting here is that $30 was actually very in line with contemporary chips. The 6502, for instance, sold retail for about $25. In this case, CosMac is competitive, but it's not a massive cost saver. The ELF is rounded out with 256 bytes of RAM, some support chips for holding everything together, a fancy flashing LED light, a two-digit hexadecimal display, some buttons, and eight toggle switches. Everything is mounted onto a single circuit board. You could, in theory, make a nice printed board, but from what I've seen, most ELFs are just soldered directly onto a prototype board or perforated board. On that list are a few things that may

stand out. The first one is probably the fact that the ELF only had 256 bytes of RAM. But really, what do you expect for an $80 project? Memory has always been one of the most expensive components in a computer, especially in this period. But once again, the competition makes this all pretty reasonable. So here's a pop quiz. How much memory did a stock Altair 8800 shift with? The correct answer is 256 bytes. Many of these early hobbyist machines just didn't have that much RAM. For the Altair, this would become something of a storied sticking point. There were expansion boards, but there were all kinds of issues with them. But for the ELF, well, this wasn't such a big deal. The computer described in the August 76 article was simple enough that anything more than 256 bytes would have probably been a waste, at least at

first, but we'll get back to that. The first factor to consider here is the ELF's user interface, or what one could call its user interface. Lights and buses aside, you've got eight toggle switches and a two-digit display. Your window into the machine is pretty small, to say the least. Programs have to be entered one byte at a time by toggling the front switches and hitting the big input button. Data is read out, likewise, a byte at a time. It would be almost a detriment to have too much RAM. Also, just to note, there's no address indicator, so you have nothing to guide you as you surf memory. 256 is already a lot of addresses to look at without any way of telling where you are. That said, the ELF would have been kind of fun to program. At least, I think it would be. I may have to look at building one of these for myself.

Recall that the machine code goes 4-bit operation, 4-bit argument. So toggling in an instruction would be pretty straightforward. The first four toggles are the operation code. The last four are the argument. Likewise, the two-digit display is just the right size and arrangement to show the operation next to the argument. The ELF really just comes together in a really nice way. I like seeing that, it's just neat. For all the cohesiveness, the basic version of the elf was still a very limited machine, to say the least. But that's only the start. You see, Weisbecker would fall back on his educational roots here. As 1976 ended and 77 rolled in, he published a number of follow-up articles to the original ELF article. You can actually follow an interesting pattern

just by going through back issues of Popular Electronics. In September, the first follow-up hits print, which gets more into the details of programming the EL elf. There's a bit of a gap during which ads for kit forms of the elf and reader letters about the computer start appearing in the magazine. Then Weisbecker returns in early 77 with a real banger. Article number three discusses some more programs and how to extend the elf's memory. Following Weisbecker's schematics and adding $20 in parts, you get one kilobyte of fresh RAM.

That's enough to write some serious software, especially in this period. But you're still hampered by the limited interface of the elf. Weisbecker does provide some plans for adding a hexadecimal keypad and code for a simple operating system, but you're still left with a two-digit window into the world. That's where Article 4 comes in. The final piece of the series adds the biggest upgrade to the ELF. Using another RCA chip, this one called Pixie,

Weisbecker explains how to get the ELF to output images to a standard CRT TV. This is really true home computing at its finest. You may not have a keyboard or a disk drive, but you have a TV. The Pixie chip itself is interesting, but I want to focus on how it works with the ELF. The setup here uses something similar to memory mapping, but it's facilitated over DMA. Let me slow down if that glazed your eyes over a little bit. One way to handle input-output operations is a technique known as memory mapping. This is how displays work on the PC, for instance.

The computer specifies a chunk of memory that, when written to or read from, actually does some kind of I.O. operation. Take low-res display modes on the PC as an easy example, since that's what I'm familiar with. To display text on a PC, you can actually just write text to a special region in memory. That automatically puts text into a display buffer, which then winds its way out to a nice bright CRT. Now, the actual buffer chip where the data is physically stored is actually on the display adapter. It's on a separate card plugged into the PC. That chunk of memory is

physically wired up to the CPU. To a programmer, it just looks like any old memory, but in reality, it's this special memory that exists outside of conventional RAM. So basically, you get a way to write directly to a peripheral instead of to RAM. The Pixie isn't wired up to do this exact trick, but it does something kind of similar. As Weisbecker explains, the Pixie uses the Cosmax DMA channel to slurp data right from RAM and throw that onto the TV screen. This is, of course, less efficient than memory mapping, but it's really simple. One of the upsides here is you also get a pretty cheap interface chip, and the circuits are also very straightforward. For memory map devices, that device itself needs to have, well, it just has to have memory.

That would make the device more expensive. The Pixy chip has no RAM on board, or minimal at least, and it only cost $20 in 1977. Adding RAM to that would've bumped that price up quite a bit. Once things are wired up, outputting to a TV is really easy. What's more, it's all done under software control. Weisbecker provides a simple program as a demonstration. You basically just load an image into memory, then you flip on the Pixie. The chip starts requesting data over DMA one byte at a time. It takes 256 bytes to fill a TV screen. So in the demo program, the first 256 bytes of RAM are used as a buffer. And that's it.

Once RAM is set up and the Pixie is started, an image appears on the tube. Simple as that. Now, here's some of the weirdness. While it was possible to expand an elf's memory, the example program was designed to work on a base 256-byte elf. As such, the entirety of memory has to be used as a buffer. If you run the example program, you end up with a few lines of junk at the top of your CRT. That's the display program itself, rendered as a bitmap image. Below is the actual demo. You get the letters COSMAC spelled out in big blocky pixels and a chunky rendition of the Starship Enterprise. This is

probably the most recognizable image related to the Elf. If you haven't seen a Cosmic computer, you may have seen this little pixel starship floating around in retro circles. And that's it. That's the entire Elf. Once again, it's a simple computer built around a very simple chip. Everything fits together very well, and there's a neat reason for this coherence. I'd really recommend going and reading the Popular Electronics articles if you're at all interested in the ELF. Someone online has typeset them all into a single document, and I'll link to that in the episode's description. This collection of articles isn't just a fun little project, it's more like a class in

microcomputing. It explains in every detail how the system works, how the processor works, and how to program it. And more importantly, how to expand the machine. By the time you read the end of Article 4, you know the system inside and out. You know just what you can do with your elf, how you can do it, and how you can make it do more. It's a testament to Weisbecker's educational flair. That's what he was bringing to the table when he entered the digital arena. So I think it's only fitting that people are still building and playing with Elf computers today. All right, that closes out our discussion of CosMac.

It's a little tale about how dedication to education and concerns about the direction of the industry led to a neat little computer. And to be blunt, I think that's the best description of the Elf and of any other CosMac-powered machine. They're all these neat little computers. Weisbecker's design is simple, but that simplicity in itself feels very fresh. That's the best way I can put it. When you look at Cosmac from the outside, just from the programming perspective, it seems like any other chip. Sure, it may look a little odd, but that will appear as just quirks of a different platform. But once you get under the lid, all those little quirks make a lot of sense. The architecture was designed to be small and simple. It was built as a computer that anyone

can understand while still being useful. That's an approach I don't think I've ever seen before. And at the end, CosMac really delivered on its promises. It's a neat little chip that you can learn in an afternoon, and it can even get some work done. Honestly, I wish there were more chips like CosMac. I'm very much tempted to build my own elf computer. Maybe that'll be a fun project now that winter is fast approaching. Thanks for listening to Advent of Computing. I'll be back in two weeks' time with another piece of computing's past. And hey, if you like the show, there are now a few ways you can support it.

If you know someone else who'd be interested in the podcast, then please take a minute to share it with them. You can also rate and review the show on Apple Podcasts. And if you want to be a super fan, you can support the show directly through Advent of Computing merch or signing up as a patron on Patreon. Patrons get early access to episodes, polls for the direction of the show, and bonus content. You can find links to everything on my website, adventofcomputing.com. If you have any comments or suggestions for a new episode, then please shoot me a tweet. I'm at Advent of Comp on Twitter. And as always, have a great rest of your day.