Advent of Computing - Episode 176 - Is That Even UNIX?

Episode Date: February 9, 2026

UNIX is beloved by many. It's the classic minicomputer operating system. It's big, it's powerful, it's multitasking, and it has some very specific memory requirements. So what happens when you try and get UNIX to run on a microcomputer? Hilarity ensues. Today we are looking at 3 small versions of UNIX: OMNIX, LSX, and CROMIX. And, I'll tell you, one of these is closer to vaporware than the others.

One of the most considerate gifts I've ever received was a big crate full of e-waste. Now, I know, that's probably a nerd filter, right? When I was in middle school, I had a close friend whose father did IT for the school district. He would squirrel away old hardware that the district was throwing out. And once, I was lucky enough to be given a curated selection of that hardware. This crate had all the hits. We're talking old, mostly functional laptops, lenses that had been orphaned from their projectors, even one or two credit card terminals, and lots and lots of random wires that went to nothing I could even imagine.

For young Sean, well, that's a gold mine. I mean, even today, I probably pretty hyped to get a random box of junk, given I had the time to work my way through it. In middle school, I definitely had the free time. This gift, in part, ended up introducing me to the more strange side of Linux. For those unaware, Linux, the free and open source operating system, has a reputation for running on just about anything. The trick is you have to find the right version, the right distribution, to run on your small or strange hard. I had just been given a box of small, strange, and slightly compromised hardware.

As such, well, I was off to the races. Did you know you can boot Linux, a very modern operating system, off a single floppy disk? Or run it on a computer that has almost no RAM? If you're desperate or just have some time on your hands, you can get almost any machine to run Linux. The reason Linux can do this is its open source nature and partly the culture that's grown up around it. The code for Linux is out there, and distributions of Linux are really just curated packages of software

wrapped around a center of Linux goodness. And there are thousands upon thousands of different distributions to try out, so you can usually find one that fits your exact niche. This also has the feel of a very modern phenomenon. The culture around Linux and open source software is relatively new, all things considered. If you go back in time, you'd be hard pressed to find such digital diversity in a single family of software. That is, unless you know exactly where to look, Unix, the forefather of Linux, didn't have

the same type of ecosystem around it. It wasn't exactly open source. That said, there was a phenomenon centered around Unix that seems oddly similar to the wild explosion of distros that's formed around Linux. Welcome back to Advent of Computing. I'm your host, Sean Hass, and this is episode 176. Is that even Unix? Today, you're in for a grab bag episode, which I haven't gotten to do in a world.

while. So let me give you the skinny. Back when I put together my episode on Xenix, I came across this paper called Unix on a Micro. Well, it's not really a paper. It's an article in an ACM newsletter from 1981. It's just a little piece talking about a few different kinds of Unix-like things made from microcomputers. I started working up an episode on some of these Unix's like things quite a while ago, I'd planned to talk about a number of them, but got sidetracked. One of the reasons I wanted to do a grab bag about these small Unix likes is because none of them have a whole lot of information to back up the story. However, that assumption proved wrong in one case.

As I was putting together that outline, I got completely sidetracked and ended up writing an episode on Idris. That's episode 149. That turned out to be a really fun project, but this odd ACM article has been stuck in my head for quite a while. Part of the reason for that is it's not a super well-written article. There are even typos in it, which, I don't know, for some reason, articles in even newsletters that have typos and just are kind of odd are very endearing to me. On a more practical note, I keep thinking about this article because it's full of weird software and even vaporware. And it's pretty open about this. For instance, here's one of the items.

Quote, Jordan Software Products Group also of New York were offering a Unix-like operating system for Z80 microcomputer systems earlier this year. Unfortunately, this product, Omnix, had to be withdrawn. when Yorden were let down by its developers, end quote. Now, that, dear listener, that's a surefire way to get my attention. This article seems pretty incredulous about most of these Unix likes. Omnix? Well, that one died on the vine. Onyx? Well, it's claimed to be Unix compatible. LSX? It exists.

for a small number of licensees. My plan for this episode is to, well, go back to where I started. I'm doing take two of correctly writing an outline without getting sidetracked. I'm going to pick three Unix likes to dive into. There's no big goal here, just a little fun looking at some weird software. Before we get started, however, I should set expectations, since, you know, Not everyone is familiar with Unix. In short, Unix is an operating system that was developed at Bell Labs at the end of the 1960s.

Almost all computers in the world today, Sands, Windows machines, and a few weird exceptions run something based off or inspired by Unix. That includes cell phones, servers, tiny embedded systems, cars, washing machines, even mainframes, and the majority of supercomputers. The important features of Unix are that it's multitasking, multi-user, and that software that runs on one form of Unix can run on some other form of Unix. Usually the word used there is portability. Unix is the heartland of the C programming language. So portability is a big deal here.

One of the more fascinating aspects of Unix, and part of its appeal, is the portability. or to look at it another way, an almost chamelean nature. In its original form, Unix was portable, able to be modified to run on many different kinds of computers. Over the years, it's broken up into lineages. This includes versions like BSD, which contain code from Unix proper. It also includes Linux and its derivatives, which contain no Unix code, but are compatible with the Unix way of working. There's a rich history of programmers recreating Unix for different niches, different computers, or just for fun and profit. Thus, looking at the wider world of Unix is almost like

gazing upon a fractal. Today, we're going to be viewing, let's say a strange part of that fractal. And who knows. Maybe even a fake part. We'll just have to find out. We will start today's adventure with the aforementioned Omnix. This was supposedly an 8-bit Unix clone that was compatible with CPM software, but was withdrawn from the market for some unknown factor. That's the star of the trail, but where does it lead? To start with, we know Omnix was at least advertised. In January of 1980, Yorden Software took out a full-page ad in Byte magazine for Omnix. It claimed to be a Unix-like operating system that had a pile of Unix-like features. It claimed you could run older CPM software under Omnix. It also claimed to run on Z-80 computers.

So we are looking at theoretically an 8-bit Unix clone. That sizing on its own is weird and interesting. Unix, by its heritage, accepts no less than 16-bit computers. Now, this isn't exactly a hard and fast requirement, but more has to do with memory space. So the usual talk goes here, I guess. Unix needs a memory management unit to handle process isolations. correctly. That's required for multitasking. For that to work in a, well, in a reasonable way, you need a reasonable amount of RAM. For it to even make sense to multitask, you have to have

enough memory to fit more than one program in memory at one time. So it doesn't make a whole lot of sense if you only have a few kilobytes of RAM to work with. Most 8-bit computers can't support a lot memory. The Z80 supports 64 kilobytes of RAM, which isn't a heck of a lot. Just for context, the PDP 11, which is the traditional home of early Unix, could handle 4 megabytes of RAM. The other reason that Unix doesn't really show up on 8 bits is that very few 8-bit machines had anything like a memory management unit. The hardware just wasn't really sophisticated enough for Unix. It also just kind of wasn't big enough to warrant something as complex as Unix. So how do we get to Omnix? Well, the story has an interesting intersection with another small

Unix, specifically Idris. In 1974, Ed Yorden founded Yorden Incorporated. This was a consulting firm that published books and held seminars. Yorden, the man, had previously worked. worked at DEC and done some consulting for other firms, but by 1974, he was ready to set up his own shop. Around this time, PJ Plager was working at Bell Labs as a programmer. More specifically, he was working with Brian Kerrigan. You may know that name because it is the K in K&R C. That's the first definitive reference to the C programming language, and it's often used as a

shorthand for the first actual published specification for C. Plager is basically at ground zero for C, and for Unix for that matter. In 1976, he would leave Bell and take a job at Yorden, where he ends up writing another C compiler, possibly the first C compiler written outside of Bell. To quote Plager via the book A Quarter Century of Unix, quote, Ed Yorden had an opportunity to get a contract to write a commercial C compiler, and I talked him into doing it. I worked around the clock for a week. It wasn't the greatest compiler in the world, but it was adequate. And along the way, I learned where the market was, because people

would come to me and say, we don't want all that Unix stuff, we just want C. Ed understood the seminar business, but not the software business, and I decided to quit and start my own company. end quote. That new company was called Whitesmiths, and it would sell AAC compiler and eventually Idris, one of the first Unix clones for microcomputers. I bring up this tale because it paints an interesting picture. Plager leaves Jordan in 1978 and releases Idris in 79. He characterized Jordan as not exactly a software company. They did contracting and seminars, but they didn't really sell software on the open market. It's also been implied in at least one old Usenet post that Plager knew nothing about Omnix.

So somehow, Yorden whipped up a Unix clone in maybe a year, maybe two. Details on Omnix are, sadly, pretty scant. What we do know is Yorden likely didn't actually add. actually develop this operating system. The speculation here comes from, well, context clues. In the Unix on the micro article, when discussing Omnix, it says, to quote again, Yorden were let down by its developers, end quote. That seems to suggest that Yorden was using someone else to develop Omnix.

The, its developers, is of course referencing Omnix. self. This also seems to be a pattern at Yorden. By that I mean the outsourcing or reselling of software. Not so much the disappointment. By 1980, Yorden is selling prepackaged distributions of Unix version 6. So I think Plager is exactly correct when he says Yorden is not a software company. So then, where does Omnix come from? This is the interesting thing. We, actually only have rumors. A 1980 article in InfoWorld has this piece of juicy speculation, quote, rumor has it. The authors of Omnics live in London and are eccentric. Rumors also indicate that Yorden could not make the system operate properly, end quote. Where does this rumor come from? Not sure. However,

I have a theory. The manager of Jordan's software group was named Mark Pearson. Now, I'm not sure he came from London. I have found a letter that he wrote to the Usenik's journal that somewhat cryptically says he immigrated from, quote, across the Atlantic. It's entirely possible that Pearson was a Brit, or maybe he was from Portugal? It's a little, oddly ambiguous for no apparent reason. Anyway, Pearson was the one to present Omnics in public, both talking about the new operating system and writing short press blurbs. Because of that, I've seen a number of articles that just say Pearson's Omnics,

or something like Pearson's new C compiler when he's talking about a later C compiler, Yorden sells. To me, it makes sense that things get twisted up here. Pearson is possibly from London. He's talking about Omnix. There's this convolution of Pearson and Omnix, and Yorden doesn't write their own software. Therefore, the rumor is that Omnix was written in London. I think that might be enough detail to lead to that rumor specifically. What we can say for sure is why there is such a drought of information. Omnix was only on the market for a very, very short time.

Yorden announced Omnix, shipped it, and then retracted it. Why? Well, the software was defective. It was too buggy to actually sell. According to that same info world piece, quote, Omnix is reportedly floating around in New England and may float back to Old England if a certain Z-80 wizard has no more luck than Yorden. end quote. As a result of these bugs and this short market life cycle, we don't get anything on

Omnix. This is a funny case because it's not strictly speaking vaporware. It was apparently delivered. It just didn't work. It's also unlikely that Omnix could have ever worked all that well. The big issue was memory. Omnics took up 32 kilobytes of RAM for the base system. and then 12K for each user. That adds to a slick 44 kilobytes just to start it up in a single user mode. Remember, the max memory space for Z80 is 64 kilobytes. So you don't have all that much space to breathe, especially if you have more than one user.

As a result, there were very few computers that could actually use Omnix. You needed a Z80 and the maximum, amount of RAM and a disc drive. That was not very common in the period. Omnix may have also been something of a cynical play. Now, this is me reading tea leaves, so don't trust a single word I say, please. Omnix was set to release around the same time as Idris. In fact, I found articles that talk about the two in the same breath.

Yorden could have been trying to steal some of Plagher's thunder. Or, looked at another way, they could have been trying to take advantage of the hype around Unix-like systems that would come with Idris. But things went poorly. Yorden was delivered bad code. It sounds like the classic case of getting surprised by a contractor. What we get is a weird void. Omnix has ads.

It has listings about... where to buy it, and where to go and get licenses and support contracts. There are even products that claim to be compatible with Omnix. We have derivative markets. When it hit the streets, it just fell to bits. I'd love to get my hands on the code and see just how bad things were, but Omnix will likely remain a mystery for years to come. The next small Unix that I want to cover is much more well documented.

Heck, it's even first party. In my past coverage of small versions of Unix, I tend to harp on the whole MMU thing, the memory management unit. For Unix to run normally, its host computer needs an MMU. That's just how the software is written. Without it, Unix can't do any of the memory tricks needed for safe multitasking. That restricts the field of what can run honest-to-goodness Unix. This was a bigger deal back in the day when MMU's

weren't as common. Microcomputers were slow to adopt MMUs as standard. As a result, most early micros couldn't run genuine Unix. That's exactly what makes Unix on micros so interesting. It's a game of how different programmers skirted around this one restriction, or what kind of wacky hardware was used to cobble up MMUs. It's truly hackery at its finest. You get to see things like software-emulated memory management, which is wild.

Or you get things like Xenix, which drop multitasking and thus make it so you don't need an MMU to run. But these are all Unix-like things, created by outside companies. Unix is technically owned by Bell Labs. We only really see these aberrations, either from folk with a license to Unix's source code, or people making from scratch recreations of Unix. As the mothership, well, Bell would never make a version of Unix that ran without an MMU. They would never have to hack something together that would be so grisly, right? Well, about that.

In 1975, Deck launched the LSI 11. This was a microprocessor version of the PDP 11. Any software that could run on the trusty old 11 could run on this new LSI variant. And like that, a much-beloved mini-computer jumped into the micro-realm. It was now possible to build a PDP11 compatible microcomputer. What all do you run on your new microcomputer? Well, Unix, for one. The PDP 11 wasn't the birthplace of Unix, but in the 1970s, it became a new computer.

the operating system's home. This was true in part because the Department Inside Bell that worked on Unix was a firm deck shop. Thompson, Richie, and all those around them loved the PDP 11, or at least used 11s so much that there's this indelible connection. But early LSI 11 boards had an issue. There was no MMU. That led to a problem.

It was possible to have a personal PDP 11 sitting on your desk, but you couldn't run Unix on the thing. The issue with the MMU, or lack thereof, isn't just a matter of multitasking. An MMU lets you expand your memory space beyond what your computer could normally access. The LSI-11 could only address 28 kilobytes of memory. That's limited by the size of the memory bus on the processor. By using an MMU, you can map a larger amount of physical memory to that bus. This is accomplished by only presenting a limited amount of RAM to the computer's bus, just 28 kilobytes at a time. You tell the MMU which 28 kilobytes of memory to present to the computer.

By doing so, you can actually have access to way more RAM. That enabled Unix to be pretty large and pretty sophisticated. In this period, Unix took up 20 kilobytes of RAM just on its own. This is one of the reasons that Unix uses the MMU so aggressively. It was thanks to that chips shuffling and dealing that multiple users could load and run programs. Without the MMU, there would only be 8 kilobytes of space to work with. That's just not quite enough. So this is a pretty nifty puzzle to solve, and it's actually very similar to the puzzle that many small Unix-likes solved.

It would be taken up almost immediately by one Heinz-like-Lama, a programmer within Bell itself. His solution is detailed in a paper fittingly called Unix on a microprocessor. Very to the point. The variant he develops is called LSI U.S.I. Unix, which is almost always shortened to LSX. Here, I'm going off of his paper published in 1976, and part of an email thread that was preserved by the Unix Heritage Society. One thing that immediately stands out is that Leichlma presents LSX as Unix for a personal

computer. He uses the term personal specifically in his paper. That means that LSX may be the first version of Unix designed. for personal use? Was 1976 the year of Unix on the desktop? Well, perhaps so. This also has a more serious implication. LSX is conceived of as a version of Unix that would be used on a personal microprocomputer.

It's not a multi-user machine. It's a computer that would sit on someone's desk and let them run their favorite Unix software in peace and isolation. that would also let you, say, write Unix software that could be passed off and used on a larger computer. LSX needs to be compatible with Unix, but it doesn't need every single bell and whistle that a larger version of Unix has. That was how Lichlma was able to make LSX fit into a smaller space. From that prompt alone, it should be clear to see some of what could be dropped from Unix. First of all, LSX only supports a single user. That actually removes a lot of code right off the top.

There are no more permission checks for files, since, well, there's only one user. You don't need to check if that one user can access a file. Multitasking also takes a hit. I've seen some places that claim LSX can only run two processes at once, one in the foreground and one in the background. In Munich's terms, a foreground process is just one that's attached to the terminal. It's whatever the user is interacting with at the time. In truth, LSX is slightly more capable than that.

Leichlema explains that you can actually have three processes at any one time. But that's a bit of an edge case. To get there, you have to start a process, have that process fork a new process, and then have that child process fork again. That's not very normal as far as usage patterns go, but it's possible. LSX can also have one special background process, so you get four processes in total. When you get down to it, however, just how many processes does a single user need? That's a question that can be answered pretty simply.

When you look at the early history of personal computing, almost everyone was fine with a single process. From the Altair 8800, all the way up into the DOS era, users got by without multitasking. From a purely period perspective, one task is all you need. Xenix, Microsoft's version of Unix, is another example of single-tasking being good enough. Zenix initially targeted the IBM PC. That machine lacked an MMU, so we get the whole memory dance. To get around the issue, Xenix only supported one process at a time. It was single-tasking Unix.

It's not ideal, but it is workable. LSX is doing the same trick, but with a little more finesse. I believe the actual trick used here involved Swap. So, swap. This is a crucial tool in Unix's belt. When Unix needs more memory than the computer, actually has, it will take a chunk of data stored in RAM, write that chunk to disk, and thus make more memory. That's called a swap. This is usually done with whole processes. In Unix terms,

a process is treated as an image. Think of it as this indivisible unit of data that makes up a process's footprint in RAM. That allows it to be thrown onto disk and pulled off of disk later. The swapping will normally only happen occasionally. It's basically treating disk like RAM, and that leads to performance issue, so it's best avoided. It may not even happen until your PDP 11 is really bogged down with a whole pile of users. LSX, on the other hand, swaps all the time.

When multiple processes are running, it will swap every time execution passes from one process to another. In that sense, the process restriction is actually a matter of performance. A weird upside here is that processes can always be loaded into the same spot in physical memory. That actually breaks the final reliance on the MMU. At the same time, this limited tasking model makes LSX even smaller. It takes more code to write general purpose features. and when you have big tables like a list of process images, that takes up more memory.

So limiting things down to four processes is another one of these size optimizations. What else was trimmed out? Well, LXS also drops a lot of device drivers. That, on its own, saves a lot of space. And it's a pretty reasonable omission all things considered. The LSI 11 used a different expansion bus than the PDP 11. That, on its own, meant that early on, LSI 11 machines just had access to fewer devices.

So why keep those old drivers kicking around inside Unix? There were also a number of debugging features that were dropped. Notably, P-Trace, the ability to trace system calls, was stripped out. That's a feature that's nice to have, but I bet most present. Programmers don't even know how to use it. One of the more interesting omissions is actually the pipe. So one of the cool features of Unix is the concept of piping. It allows you to take the output of one process and use it as the input to another process.

Pipe is also a Unix system call that can be used to establish one-way communication between programs. It's really useful, but LSX has. limited multi-processing. So that becomes less useful. The more visible use case is on the command line. All Unix shells let you pipe the output of one command to the input of some other command. This is done by putting the pipe symbol, the weird vertical line on your keyboard, between two commands. It's a super powerful feature because it lets you construct very complex one-liners. You can print the contents of a file, filters for a specific strings and then count them, for instance. You basically get to use Unix itself like a programming

language. The issue with supporting pipes inside LSX comes down to performance. For a pipe to work, you need more than one process running. And LSX really, really doesn't want to be in that situation. Remember, a switch between processes in LSX uses a swap, so it's very slow. So LSX just doesn't do pipes. That said, you can do pipes between commands. LSX uses temporary files to make that happen. If you type a pipe symbol, then the output from the first command goes into a file, and once that command's done, the files contents are then fed as the input to the next command. That just uses existing features of Unix, requiring no new code, which is pretty funny. So it means that pipes can totally be dropped, at least pipes as a first-party feature inside the Unix kernel.

After this process of cutting, Lichlma arrived at, drum roll please, an 8-kilabyte version of Unix. That's down from the 20K weight of contemporary Unix's. Now, to be specific here, that's the kernel size. This is the amount of memory that Unix has to keep reserved. for itself. But still, that's really, really small. Also to be clear, this wasn't some evil hack job. In fact, this was sanctioned. Dennis Ritchie even helped Lichlamam make those cuts. And Ritchie was the co-author of the first version of Unix. In a strange way, the results of all of these cuts is actually something closer to Microsoft DOS than Unix.

This is really the interesting thing, to me at least. LSX ends up being almost a preview of Microsoft DOS. Let me explain, because I know this does sound a little crazy. LSX was designed to be used with an LSI 11 with two floppy disk drives. One disk would hold the system, the second the user's files. That's very similar to how DOS would later be used on the original IBM PC. LSX is, strictly speaking, single-tasking. It's single user, and it's meant for a computer that only a single person can use.

That is very much in line with Microsoft DOS. And actually, LSX is smaller than the DOS kernel. DOS 3.3, one of the older but more popular versions of the system, required a full 30 kilobytes of memory to load its kernel. That means, purely by numbers, LSX is less sophisticated than microslop DOS. But that's not really true. Despite the size, LSX is a good deal more sophisticated than the larger DOS. Larger DOS. What a phrase.

What I'm just trying to point out here is that the usage patterns for LSX are actually really similar to Microsoft DOS. There's also something funny here about the LSI 11 and the 8086 family of processors, both being derivatives of the PDP 11 to a certain extent. There's a family tree here. They might not be close relatives, but the branches touch at some points. But even with so much stripped out, LSX provided a very rich environment for the programmer. That's always been the actual draw of Unix. LSX shows that the important features are very core to Unix itself.

And, hey, maybe there's some things you can drop out and still have a recognizable experience. Hopefully, we've established a few key things at this point. Could even say we've busted a few misconceptions. Unix doesn't have to be multitasking. Unix doesn't have to support multiple users. Unix doesn't have to be so big. Then what even makes Unix Unix? Can I just say it's a feeling?

No, probably not. That's not quite good enough. What exactly doesn't mean for an operating system to be Unix-like? We have a few categories. LXS is Unix-like because it uses source code derived from Unix itself. LSX is Unix-like because it can run software developed for Unix. That is the most clear possible case. Things get fuzzier as we get further afield. Omnix was advertised as a Unix-like because it had certain features that were similar to Unix.

Those included multitasking, although I have no idea how they practically implemented that. It included a C compiler and a hierarchical file system, plus a command line interface that sounds similar to the Unix shell. However, Omnix never made the claim to run Unix software, and it never used any Unix source code. Other systems like Idris and Coherent were Unix-like because they were designed to be source code compatible with Unix. You could take a program written in C and compile it to run under Idris or Coherent just the same as if you were using Unix itself. It also helps that Idris and coherent were both designed.

to look and feel as close to Unix as possible. You see, it kind of is just a feeling. I'm going to pull out a few points of similarity here. The first is the primacy of the C programming language. For a system to be Unix-like, it has to have a C compiler. Early on in the market, Unix was viewed by many as a vehicle for C. That is especially true for microcomputer systems like Idris, coherent, and even Xenix. The draw was C and a nice environment to use it in. The second is the look

and feel. This is one of those spots where I can be annoying for fun. Technically speaking, Unix, the operating system is kind of just the kernel. It's only things that a programmer would see. The look and feel of Unix to the user are all due to software built to run on top of that operating system. That includes the shell, which is the user's default textual interface. That includes all the commands you run, which themselves are just small programs. The point is, the look and feel is actually a pile of small features that the user is exposed to. To be Unix-like, you have to have that set of features. It's things like pipes that use the pipe character, a command to list files that's called

LS, user programs stored in a directory called bin, disk drives mounted to directories instead of drive letters. This is the reason that you can't say DOS is a Unix-like, even though it has a C-compiler. I think this works as a very minimal definition because it does encompass all the weird Unix-like things we've seen on the show. You'll note it's not expansive. This doesn't make any technical distinction. If something can look and act like Unix and you can compile C on it, then that's all you need. So, how low can we go? Did you know there actually was a working Unix-like written for 8-bit microcomputers? With our Yardstick, that shouldn't be too surprising. The system I'm talking about was called ProMix. It was developed at Chromimco for use on Z80 computers, and it wasn't

paperware. This one actually existed and was actually sold. There is even evidence of the very disks used to install chromics. But we're not talking about fake software here, folks. What makes this all the more neat is the time period. Chromix appears around the tail into the 70s. This is the same time as other tiny eunxes like, well, Omnix, Idris, and even Xenix. So what's the story? This one is a little different than the other tales we've covered due to the key player. Chromix is developed at Cromimco. That name may sound vaguely familiar. Cromimco was a hardware company. We've touched on them before when we talked about the Cyclops, one of the first digital cameras. Cromimco started out creating peripherals like the Cyclops for use with the Altair 8800 computer.

But that wouldn't last too long. The Altair was built around this thing called the S-100 bus. It's a backplane the cards slotted into. Those cards would include everything from the processor all the way up to interface cards for the Cyclops Digital Camera. As Cromimco started making more and more cards and even backplanes, they reached a point where they could just make their own computers. So they did. Their first machine, the Z1, launched in 1976. This is just a few years after the Altair 8800 jump started the microcomputer revolution. Now, this is a very, very abridged corporate history. But even from this short version, it's plain to see that Cromimco isn't a software company. They sell hardware. Software only really enters the picture

as a byproduct. One of the first of these byproducts was C-DOS, the C-MIMCO, disk operating system. Now, I think I should do a whole episode on C-DOS just because it's an interesting tangent. Basically, this all started with C-MMECO's second machine, the Z-2. That computer came with two disc drives,

two floppies bolted right into the chassis. And if you have disk, you need a disk operating system to use them. At the time, the only option with any weight behind it was Digital Research's CPM. That operating system spread far and wide because it was easy to port and easy to adapt. At least, it's easy to port between computers that use the Xilog Z80 or Intel 8080 processors. The trick was that CPM was just slightly modular. It was broken into two parts. One was the kernel, the heart of CPM itself, and the other, was just drivers. Early 8-bit micros were all a little bit different, so to get CPM up and running on a new machine,

you'd just need to adjust the drivers. Digital research supported this by licensing CPM, source code and all, to manufacturers. If you wanted CPM on your new machine, well, there was a pretty easy legal path forward. This also opened the gate for improved versions of CPM, and it let hardware companies that weren't super specialized in software ship custom operating systems. C-DOS was one of those. It was adapted from a licensed version of CPM, ported to the Z2, and expanded with a few new features. Crucially, it could still run CPM software. So Cromimco, despite being a hardware company, has this history of adapting or developing their own operating system. This would lead, in part, to Chromix.

The issue here was that CDOS just didn't have oomph behind it. That was partly an issue of lineage. CPM was a very, very primitive operating system. It couldn't do multitasking. It couldn't deal with really complex storage at all. It just let you load files off a floppy disk. So, Cromco management went out looking for a better option, something for a series of higher-end machines they were planning.

They would land on Unix. How cool would it be to have a customized version of Unix for Cromimco hardware? Well, that idea immediately had some big issues. Cromimco had been in talks with Motorola around this time over the upcoming 68,000 CPU. That chip ends up powering the first Macintosh and a whole lot of Unix workstation. in the 1980s. Cromimco wanted to make a machine that ran with that chip and a custom version of Unix all the way back in the mid to late 70s.

That would have been really, really cool, but the 68,000 kept getting delayed, so much so that it stopped being an option anytime soon. That was the hardware front, and it was pretty bleak. Things weren't much better on the software side. Roger Sipple, an employee of Cromimco at the time, recounts the saga like this. Quote, Cromimco was too cheap to license Unix from AT&T. They got AT&T to agree to license it, and that was a miracle in itself.

But AT&T wanted $100 a copy royalty or something. Cromimco was accustomed to putting the operating system on the boot track of every disc, end quote. Practicality of boot sector Unix aside, that's eye-wateringly expensive. Adjusting for inflation means that each Crememco floppy disk would cost $500 in royalty fees alone. It's a classic case of AT&T, not knowing what to do with Unix and constantly flip-flopping around the fringes of their antitrust issues. It seems like one month AT&T would give away Unix for free in the next month.

would want a million dollars for a license. Now, practically speaking, the delays with the 68,000 meant that any deal with AT&T would have been useless. Without a new processor, Crememco was set on their old Z80 chips. Unix simply can't run on that kind of hardware. That's just not what Unix was designed for. So it was back to the drawing board. And this is where things get wacky.

from Sipuligan, quote, I was trying to tell these guys, no, you gotta stop thinking that way. You're talking about a multi-user machine. You're going to start selling a super micro server. You've got to start thinking that the operating system's going to come on 10 disks and it's going to come with a manual in training classes. They were like, oh no, I don't think we want that. So they had Roy write a scaled down version of that operating system

that they could distribute freely. That was Chromex. end quote. Two immediate questions arise here. Who is Roy? And what kind of hardware are we talking about? Let's do hardware first. Krammco didn't release any 68,000 products until 1982. That means we're stuck in the 8-bit world, specifically the Xilog Z80 was the chip of choice. That leads to us back to the whole memory issue. That's always central. The Z80 can only address 64 kilobytes of RAM. As we saw with LSX, that's actually enough to run honest to goodness Unix, but it's not a whole lot. By 1979, Krammco was shipping a machine called the System 3,

which is pretty indicative of their lineup. It also has readily available docs. That machine supported up to 16 megabytes of memory. That's crazy. That's cuckoo bananas crazy for this period. The PDP 11 is an older machine, but I think it's a reasonable point of comparison. That computer supported four megabytes. So we have a weaker processor, perhaps, but we have enough memory to warrant a big multitasking system like Unix.

then how was Cromimco doing this? The Z80 has a limited memory space. Well, they were using an MMU, at least almost an MMU. All these machines were built around the S-100 bus. That bus also has a limited number of address lines, so it can only deal with a certain amount of memory. That's on top of the aforementioned limits of the Z80s memory. space. Ram, just like everything else, lives on cards. They're slotted into that bus. So there's these

two bottlenecks working against Crememco. The trick starts with the RAM expansion cards that you can throw on the bus. To add more RAM, you just slot in a new card. Crucially, you have to identify each card with a number. A Cromimco memory card had a set of dip switches used to set something called the bank number. The idea here is that each RAM expansion card formed a bank of memory that wasn't always active. So you could have a megabyte worth of RAM just sitting on the bus waiting for its time to shine. A separate card called the MCU, or Memory Control Unit, determined which banks should be turned on. In this way, it was possible for the computer to use way more RAM.

This specific method of switching out banks of RAM is called bank switching, and here it's used to fantastic effect. It should also be plain to see how close this is to an MMU. This is actually just one step more primitive than the PDP11's MMU. That bigger computer could shuffle around how it composed the memory space. The MCU could only swap out a part of memory. The point is, these later Z-80 computers were actually capable enough to run Unix. At least, maybe.

Speed aside, this is a pretty high level of sophistication. In order to use all this cool new hardware, better software was needed. And this is where Chromex comes into the picture. C-DOS, being CPM-based, didn't really have a concept of bank switching. These early disk operating systems were just that disk operating system. They provide an interface for dealing with floppy disks and basically nothing else. You don't get any code to handle memory or process control or bank switching. Now, to the second question, who is Roy?

In short, he's the Chromix guy. As he described his work at ChromeMCO during an oral history panel, quote, I was there for three years, and my main thing was to get off of CPM operating system to something a little bit big, I worked on a program called Chromix, which was a Unix-like operating system, written for the Z80, an assembly language. That was my project pretty much the entire time. Emphasis, my own, of course. Now, that should sound instantly funny. The short story here is that Crememco wanted a way to make better use of their hardware, and with the AT&T deal not working, they chose, you know, to write their own Unix. What's so funny is the language?

of choice and the processor of choice. This makes Chromix odd as it's a Unix clone written in assembly language instead of C. A lot of people are going to Unix specifically to work in C. So this is, I don't know, I think this is pretty weird and funny. Let's get down to Brass tax, though. We know that Cromimco was producing an operating system that looked like Unix and could run on these neat Zee.

80 computers. When did this become public and how similar to Unix was it? Does it have the right look and feel to match? Those questions are a lot harder to answer. The reason is Chromics is actually a pretty long-lived operating system. I've seen versions of it from as late as 1988. There are also some quirks to its preservation. It's easy to find manuals for latter versions of Chromics that reported to the Motorola 68,000 computers. Recall, Cromimco does eventually get better processors. That version of Chromics, I believe, was more popular, judging by the amount of documents out there, and it doesn't show up until 1982 or 83.

I think the Z80 version of Chromics was released in early 1980 or maybe very late 1979. This comes down to a classic issue with software release dates. There was most definitely a press release that Cromimco put out when Chromix was launched. That would have been sent out to magazines and newspapers and such. The issue is that, barring a quirk of fate, those press releases usually aren't preserved. So I end up having to read tea leaves and try to find articles that were written about that press release. I'm able to find a few articles. saying Chromex was new in 1980, but nothing like a big grand announcement. The other source of information here are from ads from resellers.

Old magazines are full of these. A reseller will give a list of all the software they sell, plus prices and then a mailing address. In 1982, the price lists start showing software for Chromex and software for Chromex Z80A version. That's why I'm fairly certain that the 68K version of Chromex, the one we have manuals for, comes out around 1982, maybe early 83, depending on if resellers were ahead of the game. Sometimes they are. Long-winded way of saying, I'm working from a manual released after Chromix 68K, and backing up my assumptions. with a few earlier notices and magazines. The Z80 version may have been much less capable for all I know.

Even with those caveats, we can see an interesting picture. Chromix is Unix-like, but that's very heavy on the like part. The most obvious way this can be seen is actually right in the shell. Chromix has all the commands that Unix does, but they don't always have the same names. One of the most used commands in Unix is LS. It lists the files in your current working directory. Chromix has an equivalent command, but it's called L.

Just L. Another standard Unix command is Cat. Now, Cat actually does a whole lot, but it's most commonly used to print the contents of a file to the screen. It's short for concatenate, and it can also be used to chain together fancy operations using pipes and redirects. The equivalent in Chromics is TY,

which is short for type. This change is particularly telling, at least I think you can read into it a little bit. In CPM, the traditional microprocessor operating system in this period, the command to display the contents of a file is called type. There are a number of commands in Chromics that follow the CPM tradition. The Unix command to rename a file is MV or Move. This is another case of a multipurpose command.

Since MV actually moves files around, it doesn't just change names. Chromix has a single-purpose rename command called REN, REN, which is the same name used in CPM. It's almost Unix, but with this odd micro flavor. Another odd spot is how Chromix handles file paths. Unix ends up establishing how file paths are structured and what symbols are used to describe paths. Crucially, Unix supports a hierarchical file system, as in you can have nested directories that contain files.

Unix didn't invent that feature, but it would spread it pretty far and would set the nomenclature. In Unix, you can use a single period to refer to, to your current working directory. That's like saying here and pointing to the ground in whatever room you're in. You use two periods to refer to the parent of your current directory. If you're in slash home slash Sean, then dot refers to the directory name Sean. Dot dot refers to the directory home. One more symbol, then we can get to the weird part. Every Unix user has a home directory. This is where you're dumped

when you log in, and it's where you're supposed to keep all your personal files if you're a good user. That gets a special character, the tilda. So no matter what directory you're in, the tilda will always refer to your home. In my case, if I type tilda, it will always be replaced with slash home slash Sean. Simple. What does Chromix do with this information? Well, it jumbles it up for no apparent reason. CPM didn't support hierarchical file systems, so there's no precedent to draw on. In Chromics world, a single period refers to the current working directory.

Fine. Two periods means your user's home directory for some reason, and a carrot refers to the current working directory's parent. That's different. It's also odd because Chrome has, Chromex follows Unix convention for basically every other aspect of its file system. It's just those two symbols that are flipped around. And I have no idea why.

There are more examples, but this is a representative sample. Chromics is very similar to Unix, with a number of just weird differences. As a professional Unix user, I could totally use and understand Chromex, but I'd get tripped up, you know? This is just, it's almost like an uncanny valley version of Unix. However, we have to think about this in context. Chromix would have been a huge step up from CDOS or CPM. It's multitasking, it's multi-user,

and even just the fact that it has directories on a Z80 would have been something to behold. As far as performance, well, I think the jury on that, matter is still a little bit out. But hey, that would have been the case for most of these small versions of Unix that run on small computers. All right, that does it for a look into three more tiny Unix-like things. I think this has given us a pretty good cross-section of the field. On one side of the spectrum, we have Omnix, an operating system that's fairly more real than Vapor. There's a lot of software like Omnix. It

comes out of the gate swinging, it sounds amazing, then it disappears instantly. We get only rumors and speculation. And who knows, maybe someone in New England, or Old England, perhaps, still has an Omnix floppy disk tucked away in their filing cabinet waiting to be rediscovered. On the other side of the spectrum, we have LSX, a very specialized version of Unix developed at Bell Labs itself. The effort was even aided by Dennis Ritchie, creator of C, and co-creator of Unix.

As far as small Unix goes, you can't get more official than LSX. It proves that Unix can, with some restrictions, be made to run without an MMU and on a very small machine. I think, for me, LXX kind of redefines my thinking around what it takes to run Unix. In the middle, we have Chromix, something that's definitely not Unix, but it is, like Unix in many, many ways. Chromix is interesting on a lot of levels for me. It's almost like an operating system inspired by Unix that went a little too far.

Or maybe better put, it's like if someone used Unix and then 10 years later, without reading a manual again, decided to recreate it. This is another case where I love more information. Wouldn't it be wild to see the Z-80-Rexamination? version running in real life. But that's probably far in the future, or who

knows, there might not even be a Z80 disk of chromics still in existence. If there is, well, please get in touch. With that, we've come to the end. Thanks so much for listening to Avern of Computing. I'll be back in two weeks with another episode of

Computing's past. Until then, well, I'll actually be at VCF, SoCal next weekend. I'd love to see you. I'm going to be giving a talk about my intercal restoration project. You can find links and all the information you'd ever want about VCF SoCal at vcfsocal.com. And as always, have a great rest of your day.