AtariOS, AmigaOS, and NewtonOS: Why Good Operating Systems Fail


The more one looks at old, nonexistent operating systems, the more one understands exactly why the popular operating systems we enjoy today are still in general use. Older operating systems share a large amount of similarities with current operating systems; the theory and patterns older operating systems incorporated are still in use in most modern-day operating systems. The programming languages used to create the system internals are again often the same. Even the high-level hardware architecture that many of these systems lived on (CPU, main memory, permanent memory) have stayed nearly constant. Yet despite all these similarities, many older operating systems are no longer used as much as they were in their heyday. These operating systems, once used by large swaths of the population, are now relegated to use by people running legacy systems for hobby or for profit. Three such operating systems, AtariOS, AmigaOS, and NewtonOS, exemplify all these characteristics. This paper will detail their fascinating history, their intricate internals, and why they failed to gain the continued mass adoption that most modern operating systems enjoy today.

In 1985, Atari released their Atari ST computer. The ST was designed to be a cheap, affordable computer that brought all the features of a more expensive alternative to the homes of the middle class. With a full-sized keyboard, a two-button mouse, and a high-resolution display, the ST was the machine to beat. That competitive design didn't stop at the exterior though; under the hood, the ST boasted a blazing-fast processor based on the Motorola 6800, a graphics chip, DMA support, fast support for floppy drives, and MIDI support, among other features. This hardware was designed to compete directly with the likes of Apple and IBM with their Macintosh and PC machines. Atari wanted to be known as a computer company instead of just a gaming company, so this device was their ticket to getting that recognition.

A competitive computer is useless without good software to go with it, so Atari needed an equally capable and competitive operating system; thus, AtariOS was born. AtariOS, officially called AtariTOS, was the operating system designed for launch on the ST, but went on to be used in many other Atari computers, such as the Atari Falcon. Inspired by the mouse and window system created by Xerox and popularized by the Macintosh, TOS included a windowing system and a mouse. Instead of building the OS from scratch, Atari worked with the company Digital Research to build a GUI shell on top of CP/M, an OS created previously by Digital Research. The duo customized CP/M to fit Atari's needs and developed GEM (Graphical Environment Manager), the GUI shell that the user would interact with. Developers were able to write applications for the system in the accessible C language with plenty of exposed API surfaces.

Under the hood, TOS was equally complex. Consisting of five main modules (Desktop, DOS manager, BDOS, BIOS, VDI, and AES), TOS is a beast to understand. Most models TOS ran on had a linear address space and could only have around 16MB worth of addresses. TOS also used a modified FAT file system for its disks, removing some features and protection methods. Details on the implementation of TOS other than these are sparse and nearly nonexistent.

TOS was hailed by critics as a success and constantly compared to the Macintosh operating system. however, sales of the Atari ST were not very high, peaking at 400 thousand in 1987 according to an Ars Technica article on the subject. Atari failed to push forward and continue innovating as it had before the computer space, so Apple eventually copied features that made the ST so successful and stole a significant portion of its market share. Because TOS was bound to the platform it was made for, TOS eventually faded into obscurity as the Atari company went down with it. Atari as a company ceased to exist when it merged with JTS in 1996, now being sold from company to company as it fails to embody even a sliver of its former reputation.

The Commodore Amiga was one of the Atari ST's main competitors, and it surprisingly got its start through Atari. Jay Miner and Larry Kaplan, two ex-Atari employees, founded Hi-Toro, a company whose goal was to create a 16-bit gaming console. Similarly to the ST, this machine was to use the Motorola 68000 processor and have gorgeous graphics, with it being capable of displaying over 4096 colors. The machine was to also be bundled with a keyboard and a floppy drive, which made it much easier for developers to write applications for. After a small legal dispute, Hi-Toro rebranded its company and console to Amiga and was acquired by Commodore a few years later. Commodore was known as a computer company, not as a gaming company like Atari was, so it turned the Amiga into a home computer, a successor to its Commodore 64, instead of a gaming console.

While the Amiga hardware might have been a decent fit for a home computer, the operating system was not; Commodore, much like Atari, needed a better OS for its computer, and it needed it fast. After some searching, Commodore decided to take the same route Atari took and adapt existing software. it found TRIPOS from MetaComCo (which stands stands for TRivial Portable Operating System) and adapted it to fit its needs. Ease-of-development was a focus; according to the official AmigaOS documentation wiki, development was primarily done in the accessible C language. Development could also happen on-machine because the device had a keyboard, removing the need for an external environment.

AmigaOS's internals were not nearly as complex or as hard to understand as the TOS internals. AmigaOS was made up of three primary parts: Exec, Amiga's kernel, AmigaDOS, which gave the Amiga its file system and command line interface, and Intuition, the GUI layer that the user interacted with the most. Out of these three, Exec was likely the most advanced; it was object-oriented and had liberal use of inheritance, which made it smaller, faster, and easier to upgrade than the competition. Exec also used a pre-emptive, priority-driven scheduler, which made the system feel fast and snappy. This was revolutionary for the time.

AmigaOS' file system, however, was not as easy to understand. It supported five of them. These file systems included an older file system, an 'international' file system (where a bug was fixed so letters in file names were case insensitive), the Fast File System, the original file system with directory cache, and the Fast File System with directory cache. The file systems supported block sizes ranging from 512 bytes to 32 kilobytes. Larger blocks were of course faster but limited the amount of hard drive space available. Amiga listed separate root directories for each individual file system, or volume, in the same way that Windows does today. There are also quite a few other quirks with the file system. Filenames were limited to 30 characters by default, it is physically impossible to execute programs in the old file systems due to a memory mapping error, and if the filesystem crashed and the bitmap valid flag in the Fast File System was inaccurate, there was no way to recover the disk without an Amiga Disk Validator or by fixing the problem manually. Fast File System was notorious for being prone to invalidation, holding too much data, and having a slow directory structure with no support for multi-user environments. FFS did have one small, revolutionary idea though: its Rigid Disk Block, a part of the drive reserved for storing all the code for reading the file system.

AmigaOS managed to use one half to one fourth of the memory that Apple and IBM computers used, but this came with a series of tradeoffs in memory management techniques. AmigaOS maintained a free memory list; the OS could easily see where memory was free and map incoming requests to free chunks at lightning speed. However, AmigaOS did not have memory protection for processes. There was nothing in the kernel to stop one process from accessing the memory of another process, which meant that accessing memory was cooperative. Each process had to assume the other processes in the system were all good actors. The OS also didn't have a memory-in-use list. This meant that if the operating system crashed, any program that failed to clean up its memory properly had all its data lost. Not a lot of work was done for processes; memory management was very barebones. This allowed the operating system of the Amiga to use much less memory, but also meant that developers had to do much more work in order to create a well-functioning app.

AmigaOS' threading support was much more robust, however. AmigaOS had support for Tasks, which was basically its word for OS threads. Tasks and processes were scheduled using a preemptive, priority-based scheduler that used time slice dispatching. However, this algorithm was customizable for threads and could be replaced with something more robust if application developers needed it. The OS also supported multiple CPU cores, which was very forward thinking; the operating system could take full advantage of whatever hardware it was given. Last, race conditions could be prevented through two types of semaphores: SignalSemaphores, which were used for a few edge cases where performance mattered, and regular semaphores, which were for almost all other use cases.

AmigaOS faced the same sort of moderate success AtariTOS experienced, but that success was relatively short-lived. The Amiga went on to eventually outsell the Atari ST according to an Ars Technica article on the subject. However, Commodore ultimately collapsed due to poor leadership and bad management. Assets were sold off, including the rights to AmigaOS. Hyperion Entertainment received the rights to the 3.1 version of AmigaOS and Cloanto received sales rights to legacy 68K ROM files. Acer apparently is the current owner of all other assets, as they likely acquired them from Escom after it went under. Hyperion and Cloanto are currently engaged in one of the longest, most frivolous lawsuits in computing history over rights and assets related to AmigaOS, which has effectively paused most development by Hyperion on the operating system. The OS is now effectively dead, killed by bad management and useless corporate politics.

The last dead operating system in this paper is NewtonOS, an operating system created for Apple's MessagePad series of devices. The original Newton MessagePad 100, released in 1993, was a weird device. It was built into a smaller form factor, had a display, and had no physical keyboard. Instead, users were to write directly on the MessagePad using a pen. The OS would translate a user's pen strokes into text recognizable by the computer and then display it on the screen. The device was called a 'PDA' by Apple, or a Personal Digital Assistant, and was to function as a complement to a desktop computer, not a replacement of it. There were no competitors in this market; Apple aimed to create it. Some hardware tradeoffs were made in order to make the device as small as it was. Mainly the system had a small amount of main memory, and it had no secondary permanent storage. Everything was to be stored in RAM.

Apple, much like Commodore and Atari, needed an operating system to run on its new device, so it created NewtonOS. NewtonOS needed to handle the severe hardware limitations of the MessagePad hardware and run fast and efficiently. To handle this, a team of Apple engineers designed a lightweight, concurrent operating system centered around a microkernel architecture. The microkernel was to handle scheduling and provide the basic units of race condition defense and focus on nothing more. Memory management, storage, device management, and other functions of the operating system were to be built on top of this. All applications were to be written in a simple, object-oriented language called NewtonScript that was similar to Pascal. Developers would use a program for the Macintosh called "Newton Toolkit" to design and create the logic of their Newton program.

NewtonOS was different from most operating systems in that it didn't have a file system. Instead, developers stored in database-like structures called soups. Each soup could hold multiple slots, which are basically records in a database. Soups were grouped together in stores, which were the individual volumes on the Newton (either main memory or some attached memory card). If developers didn't want to worry about putting their soup in a store, they could simply create a union soup, which grouped all data stored on any volume into one soup that could be used by the application. Soups could be queried for cursors which could then be used to get copies of the data stored in slots. This elegant abstraction made it possible for Apple developers to highly optimize soup storage, making the most of the little available space they had.

Memory management in NewtonOS was very lax like in AmigaOS. There was no memory protection in place to prevent one process (or Task, as discussed later) from accessing the data of another. This was done to limit the overhead that a true memory management system would add; the MessagePad only had 640 kilobytes of RAM and it had to use it well. However, this model did have some advantages. When a task needed to communicate with another task, it could simply send the address of an object in memory to the second task instead of creating a copy of that object. This made communication between tasks much more lightweight, but also made tasks cooperative, making it possible for one task to corrupt the state of another.

NewtonOS didn't have processes or threads; instead it had an alternative called tasks. Tasks were lightweight, basic units of concurrency in NewtonOS provided by the microkernel. They were as close to the core of the OS as possible. The overhead for tasks was incredibly low; they only needed enough information to save the processor state and store some extra information on whether a task was blocked or not. The microkernel scheduled tasks preemptively using a strict, priority-based scheduler that switched between them lightning fast. The data structures for concurrency were also very stable and rich. Tasks could pass messages synchronously to each other, could control access to shared memory using several different types of semaphores, and could use monitors to queue up a task's access to certain resources. This, combined with the decisions made about memory management, made NewtonOS a fast, cooperative operating system.

NewtonOS, like the two previous operating systems mentioned in this paper, went on to experience slight success before a sudden end. The original MessagePad didn't sell extremely well, with Apple only selling 50,000 devices in the product's first quarter. Apple went on to create six other Newton devices, including the eMate 300, a device built for the education market. Eventually, Steve Jobs returned to Apple and axed the product line in 1997 to reorganize the company and simplifying its offerings. Apple's first touchscreen device, and the operating system that arguably made it the most successful, were no more.

These three operating systems were not simple pieces software and were each, in their own small way, inventive or revolutionary. AmigaOS brought the concept of a Rigid Disk Block to the file system world, allowing file systems to be more portable and OSes to be slightly smaller. NewtonOS presented a different and refreshing alternative to filesystems in its lovably named ‘soups’ format. AtariTOS brought flexibility to developers by offering three different runtimes with different API surfaces. Each of these operating systems was likely built by a team of intelligent engineers working with hardware restrictions to produce something amazing that became moderately successful for a time. And yet somehow, each of these operating systems failed. Most of them no longer exist currently or are no longer in use. Why is that the case?

First, each of these operating systems was tied to a single set of devices and not built to work on multiple other devices. AtariTOS was tied to Atari’s family of devices, AmigaOS to Commodore’s Amiga family, and NewtonOS to Apple’s Newton family. This was a doubly edged sword. On one hand, success of the individual devices meant a success of the operating system as a whole. If a device was selling well, that meant an operating system’s user base grew. However, if a device was selling poorly or was cancelled, as was the case with Apple’s Newton family, that meant the OS could no longer continue to grow its user share. These devices would eventually die, and with it would go the OS; it had nowhere else to go.

Second and last, each of these operating systems was backed mainly by a single corporation: AtariTOS by Atari, AmigaOS by Commodore, and NewtonOS by Apple. If that corporation went under, as was the case with Atari and Commodore, or made decisions that harmed the development of the OS, as was the case with Apple, that would ultimately mean the end of the operating system’s lifespan. Having a large backing organization gave the operating systems their start, but it also meant that if that organization went down, the operating system went down with it too well.

Second and last, each of these operating systems was backed mainly by a single corporation: AtariTOS by Atari, AmigaOS by Commodore, and NewtonOS by Apple. If that corporation went under, as was the case with Atari and Commodore, or made decisions that harmed the development of the OS, as was the case with Apple, that would ultimately mean the end of the operating system’s lifespan. Having a large backing organization gave the operating systems their start, but it also meant that if that organization went down, the operating system went down with it too well.

Operating systems don’t just fail because of a lack of technical features; they don’t die solely because of issues with implementation. Sometimes, they fail because of things beyond their control. Corporate warfare, hardware issues or exclusivity, and shaky backing organizations can all lead to an operating system’s demise. Failure does not happen in a vacuum. Things outside of a programmer or user’s control can help or hurt the standing of a piece of software. AtariTOS, AmigaOS, and NewtonOS are perfect examples of this, a cautious omen to OSes that putting trust in the wrong structure, making the wrong decision, or just being unlucky could lead to their demise.