Did any 8-bit computer system / OS have concepts for concurrency and multitasking like we know from today?

Question

So, today all major OS support multitasking and concurrency in languages like for instance threading.

The Amiga seems to be the first home computer which has advanced concepts in this area. But had any 8-bit home-computer rudimentary capabilities already before the Amiga ? Be it in the ROM or emulated by any software (additional OS or an available programming language) does not matter.

Regarding the Commodore 64 for instance there were hardware interrupts (e.g. for I/O and timer). But I'm thinking more about higher-level approaches here.

Answer 1

In fact, quite a lot did.

Ignoring the 'home computer' restriction, but going with micro processors (*1), then there is of course MP/M - the multi-user and multi-program environment for CP/M. MP/M was published in 1979 by Digital Research for 8080/85/Z80 machines. Terminals, users and programs were handled separately, thus one user could have several programs run in parallel and switch between them (called "detach" and "attach") on a single terminal, or change terminal and attach from there. Also, several users could (in sequence) share one terminal. Programs could run attached (in foreground on a terminal) or detached (in background). In addition, there was a scheduler process starting (and stopping) programs at specific times and conditions (like cron). Last but not least there was a separate spool process, so programs were not blocked while printing.

MP/M also included functions for inter-process communication (queues) and process synchronization. Soon a network level (CP/NET and CP/NOS) was added to connect multiple MP/M machines to a kind of cluster (very rough term, but it was more than a simple client/server structure and I don't know how to explain its workings in less than a few pages :))

All features could be controlled using the MP/M extension of the CP/M API.

In theory, MP/M could have been used on every computer capable of running CP/M, especially where CP/M 3.0 memory management was available (which in itself was a backport from MP/M II to CP/M), but other than some Tandy Model II and 4, I don't remember any home computer with explicit MP/M support.

Another very common multiuser/multiprocess system was OS/9 created for Motorola's 6809 CPU. The 6809 offered great support for position independent code and data, as well as OS support and module linking in Hardware. Thus it was easy to load not only several programs at once, but also to support re-entrant code, thus resulting in a great reusability for libraries (shared code).

Another multiprocess OS for the 6809 was UniFlex. Flex was originally written as a single-user single-program OS for the SWTPC 6800 machine. Later iterations included a port for the 6809 and integration of Unixoide functionality, then called UniFlex.

For home computers there have been dozens of variations of multitasking/multiprocessing environments. From 1984s M.O.S for Schneider/Amstrad computers, distributed by StarDivision to 1986s GEOS for the C64, a seemingly endless plethora of OS and OS-like environments have been created. I might need a book to list and qualify them all.

The most remarkable piece might have been the Sinclair QL from 1984. With a 68008 CPU, it might be seen somewhere at the edge, but I'd still consider it an 8-bit machine. The QL included a pre-emptive multi-tasking OS in ROM called QDOS. The built-in SuperBASIC offered the full QDOS interface for process creation and control to any BASIC program, thus allowing concurrent processes and threads. It is said that Linus Torvalds took much inspiration for Linux from QDOS, as he owned a QL before switching to a PC.

(Oh, just to brag about: ca 1979/80 I wrote a small multi-process kernel for the Apple II, able to run up to 8 tasks, but I guess that's way below the threshold the OP asked for :))

---

*1 - There have been of course 8 bit mini computers which not only had multi tasking operating systems, but were also designed with hardware support for such. The Dietz 600 series might give the clearest example. A TTL based CPU, with hardware support for task switching. One might compare it to a 6502 with an interrupt handling system that would, in case of an interrupt, switch ZP, Stack and a memory base address to an interrupt task. When the interrupt finishes (RTI), it doesn't return to the interrupted task, but the task with the highest priority able to execute. Very handy.

Answer 2

Back in the mid 70s I wrote, and in 1982 I stopped shipping an 8 bit OS ("SDOS") for Motorola 6800/6801/6809. Those OSes came in several flavors:

• SDOS/RT: Real Time multithreaded (2Kb ROM + whatever small bit of RAM you needed). It was was always included as a part of the others in this list
• (plain) SDOS: Single user Disk Operating System (64K memory max) (see SDOS in action in 2023 here: https://www.youtube.com/watch?v=8laYFP3ZbcQ)
• SDOS/MT: Multiuser Timesharing (15 users in 1Mb of RAM using 65Kb banks of memory, one per user)
• SDNET: Distributed OS (Single or Multiuser system with access to remote disks)

One of the earliest 6800 systems (on which SDOS was developed) was the WaveMate Jupiter II (https://www.computerhistory.org/collections/catalog/102645038). The other variants were developed on that initial SDOS base.

One of the distributed OS versions managed 256x512 bit mapped graphics on the most trivial hardware you can imagine. For the hell of it, I wrote a Chess Program in the compiled-BASIC I implemented as our application programming language.

I wrote a variety of RTOSes for other 8/16 bit computers in the 70s (including Z80 and 68000), but there were definitely others before me.

While I was at TRW Advanced Product Labs in 1974, John Liberty implemented a dual processor 6800 (each CPU used one half the 1Mhz symmetric bus clock to do its memory access); one CPU did general purpose work, the other often did real time single bit I/O streams to things like read/write magnetic tape heads. A fellow named Dick Moran wrote the multitasking, real multiprocessor "BKOS" (Basic Kernal OS) that handled both CPUs using atomic locks and the whole bit. These CPU boards went on to become the minimalist hardware core of May Company POS terminals. (My job was to use this OS to write the real time mag tape drivers and the print head drivers for a 7 pin vertical printer that swept across the paper roll to produce printed text for sales receipts. Even with holly borders at Christmas :).

IIRC, the Intel 8080 came out before the 6800. It had a truly horrible scheme requiring hardware assist to take an interrupt and most of the CPU boards didnt bother with this. Most couldn't take an interrupt to save their lives, so it didn't make much sense to build an RTOS for those... but ... some did. I'm sure some soul wrote a multitasking OS for the 8080 for conventional embedded use. I remember talking to a Brunswick ("we don't just do bowling") cruise missile engineer who had done this onboard the missile. Late 70s, I did what I thought was a pretty nice multitasking OS for the Z80 using the SDOS/RT design but by that point I was probably just one of a crowd of guys who had done that.

A good part of the reason I chose to build the SDOS systems on the Motorola family chips is because they had built-in interrupt support that the 8080 lacked.

One of the slick things I did for multitasking on these small machines was effectively expand the register set. These 8 bit machines had only a few registers; talk about register pressure! What I did was define a fixed set of addresses (on the 6800, 8 bytes down in page zero where they were easy to access) called the "context" and made them part of the CPU state that the OS thread scheduler switched. This means your thread could use the registers, and the context, safely, giving it a little a little scratchpad it could work in. That made the code actually smaller than trying save things in the stack, way safer than having global variables all over the place, and remarkably it made the programs faster. [On Windows and Linux, this is called "Thread local storage", but its stored in a place you have to access with long complicated index operations, blech.]

Programming 8 bit machines from the bare metal up was fun.

Answer 3

Since it ran on the Tandy Color Computer and similar Dragon computers in the UK, I guess it's fair to throw OS-9 into the mix. OS-9 was originally written for 6809 CPUs (hence the name). The linked Wikipedia article begins by calling it a "family of real-time, process-based, multitasking, multi-user operating systems".

I remember before it was available for home systems, a commercial development license cost many thousands of dollars per year. It certainly wasn't cheap, and I remember the up-front costs made it a non-starter environment at the company where I worked in the early to mid-80s. I'm pretty sure I would have loved it, though. Everything I heard was pretty sweet -- except the cost.

It was later ported to other Motorola chips in the 68000 family.

---

Trivia 🤷 - feel free to skip.

In 1999, OS-9's owner sued Apple for trademark infringement about Apple's own operating system, "OS 9" (no dash). The OS-9 trademark had existed for 19 years before Apple started using it. The case was decided in Apple's favor, with the judge saying no one would get them confused. Huh? Try doing a simple internet search for os-9. All you see are Apple-related links unless you specifically exclude Apple terms such as -Macintosh.

The OS-9 version 2.4 manual in 1991 included a glossary containing an entry for Unix:

An operating system similar to OS-9, but with less functionality and special features designed to soak up excess memory, disk space and CPU time on large, expensive computers.

Answer 4

The Sinclair QL was most probably the first truly multi-tasking home computer. It's QDOS is a fully-featured preemptive multi-tasking OS. Whether it matches your definition of an 8-bit computer with its 68008 is , however, debatable (and was debated a lot when it entered the market)

Answer 5

It wasn't multitasking in any way, but Locomotive BASIC on the Amstrad CPC series (Z80, 1984) had software interrupts for calling subroutines based on timers. There were four 50 Hz timers, 0–3, with timer 3 having the highest priority. Timers could be set one-shot (AFTER ‹time delay›[,‹timer number›] GOSUB ‹line number›), repeating (EVERY i[,t] GOSUB ‹line number›) or based on the sound queue status (ON SQ(x) GOSUB ‹line number› x1, x2, x3, x4, …). Interrupts could be disabled (DI) and re-enabled (EI). Combined with Locomotive BASIC's screen viewport definitions (WINDOW … — somewhat different from how we'd define a window today) you could have the appearance of multiple programs running at the same time.

Of course, arbitration was pretty much up to the programmer, and it was too easy to create a program that would lock up beyond the reach of even a soft reset. But as a limited form of high-level interrupt-driven code it worked quite well.

Answer 6

Intel's iRMX worked on the 8080 and above. We used it on GRiD Compasses in the early 1980s, though the GRiD could hardly be called a "home computer"!

iRMX (and the GRiDOS file system & GUI that GRiD built on top of it) were fully multi-tasking.

Answer 7

A great many Atari-era games ran in two threads.

The first thread attended to gameplay, listening to controller input, keeping score, arranging the playfield, cueing sounds.

The second thread was responsible for sprite-juggling to render the playfield in a more complex way than the hardware designers imagined. The purpose of the added complexity was to be more competitive to other games, or emulate the better hardware in arcade machines. This thread effectively "followed the raster".

This was preemptive/cooperative. At a certain point in the sweep/scan, the display hardware fired a hardware interrupt which (preemptively) launched the raster thread. It quit voluntarily (cooperatively) when the raster reached the last point of its concern. If it failed to quit, the game would crash.

If the gameplay module was unable to complete an entire "cycle" of tasks in a single display sweep, that wasn't the end of the world. You could intentionally run the gameplay module on a 2-frame or 3-frame cycle if that made sense, or let it roll asynchronous. Animation or polling tasks that didn't like being asynchronous could also be off-loaded onto the end of the raster thread.

During debugging, you would set the screen border color to different colors for different tasks, e.g. blue for raster-chasing work, red for gameplay tasks handled by the raster interrupt, and green or rotating colors for the main thread. You could watch the colors dance up and down the screen while you playtested, and watch for conditions that overloaded the game.

Answer 8

For the sake of completeness, there is SymbOS, which advertises itself as a graphical Z80 multitasking operating system. It didn't exist at the time, but it works for a variety of 8bit machines (MSX2 and better, Amstrad CPC, Enterprise 64/128, PCW Joyce).

Answer 9

In the early 90s, I worked for a division of GEC Alsthom who had based their control electronics on the transputer. The transputer was obsolete by then, but they had not yet bitten the bullet to do a full redesign of their controls.

Transputers were explicitly designed to run as a massively parallel system. Because designs had to be parallel, they also allowed multithreading within the processor as well (and in fact for efficiency there was some comms buffering which had to be coded as parallel tasks, because that's how the processor worked).

Sadly of course the transputer suffered from the same fate as most other UK technology companies, namely underinvestment. Historically, major UK investors have been extremely reluctant to fund UK technology companies because they are seen as higher-risk; but of course this is a self-fulfulling prophecy when the companies fail because they cannot get the resources they need to grow. In the case of the transputer, Intel and other US manufacturers put investment into mass-manufacture of single-core x86 processors which allowed single-threading processors to progress at a rate Inmos could not compete with.

The occam language was designed to handle multithreading and multicore processing. Because occam was tied to the transputer platform, the detailed implementation of semaphores and shared data could be delegated to the language instead of having to be set up explicitly by the coder. This made it trivial to implement multithreaded designs.

Of course the transputer was not an 8-bit processor. But your question seems more about "early" processors rather than being specifically tied to a processor word length, and "8-bit" seems to be more about the era than the processor.

Answer 10

Tom Hunt created MTOS for Atari 8-bit computers in 1987. Details here: www.umich.edu/~archive/atari/8bit/Os/mtos.doc

Answer 11

You are asking about, and the answers are covering, commercial/mass-market OS's, but it was very common for a programmer of an embedded 8-bit device to cook up either cooperative or interrupt driven multi-tasking when the device needed it. Neither is very difficult in their basic form; cooperative is especially easy. Primitives like queues and semaphores aren't terribly difficult either, so we would often just cook those up when we needed them. However, being mostly comprised of soft tissue, these one-off OS's won't show up in the fossil record.

Answer 12

What about Cromix? Cromemco had a complete multitasking system running on a Z80.

Or TurboDOS? Back in the day I had an IMS TurboDOS S-100 system. More multiprocessing than multitasking, but it supported concurrency. It even had networking (arcnet).

Answer 13

When we say "8 bit microcomputer", really we might be talking about 16 bit machines, if we go by address bus size: 8080, Z80, 6502, ...

If we give ourselves some leeway to by that rather than data register size, we might include the DEC LSI-11 in the same category.

Douglas Comer's Xinu operating system first ran on the LSI-11.

Xinu supports concurrency and all that. From the old Xinu FAQ:

Xinu is a small, elegant, multitasking Operating System supporting the following features:

• Concurrent Processing
• Message Passing
• Ports
• Semaphores
• Memory Management
• Buffer Pools
• Uniform Device I/O
• Shell
• Tcl
• TCP/IP

Answer 14

Both Minix (1988) (and the ELKS fork of Linux though that wasn't around until 1999) ran on the 8088 Microprocessor which had an 8 bit external data bus so is at least by some definitions an 8 bit processor; many 8 bit processors such as the Z80 had one way or another 16 bit registers at least by combining registers for addressing purposes, so I don't think this is too much of a stretch. Both Linux and Minix supported preemptive multitasking and concurrency. Neither Minix nor Linux originally (from memory - though it did by the time ELKS came out) supported threading but both did at some later point and could run it on an 8086.

Did home computers that support the 8088? Well the IBM XT and some cheap PC clones were certainly sold into homes, so I would guess these count. But the IBM PCjr was 8088 based and definitely marketed towards the home ("IBM's first attempt to enter the home computer market"). See also this link.

Answer 15

One I personally had some experience with, however little, was Morrow's Micronix, a Unix that ran in 1983 on their Z-80 CPU card for the S-100 bus system.

Answer 16

It's important to understand from a historical perspective that early multitasking and multi-user systems were designed around that reasonably fast hard disk capacity was much cheaper than RAM. Early multi-user systems didn't keep multiple users' programs in memory at once; instead, they would run one person's program until it needed to perform I/O or it used up its time slice, swap the entire user memory space of the machine out to disk, load someone else's program, and start running that. As such, the ability to perform complex memory management tasks or support lots of memory wasn't really important. An 8-bit CPU coupled with a reasonably fast hard drive that could quickly swap 4K blocks of data between RAM and disk could be minimally adequate for multi-user applications with even 16K of RAM, though more would be better. In an era where RAM was expensive, such a design might have been practical for multi-user use. I don't know whether the cost of the CPU would have been relevant, though, given the cost of a hard drives.

Answer 17

A niche example:

The 8-bit BBC Micro attracted a huge range of peripherals and add-ons, one of which was the Music 500 synthesiser unit.  This provided 16 digital oscillators, usually grouped into 8 voices, with features such as digital waveform generation, FM, ring mod, and oscillator sync.

The supplied software included a dedicated programming language called AMPLE (‘Advanced Music Production Language and Environment’), similar to FORTH but with many music- and synthesis-related keywords and features.  (It had a few similarities to LilyPond, though of course major differences too.)

To control all the voices, it used co-operative multitasking to provide up to 9 different ‘players’ (i.e. threads): one to handle the keyboard, screen, etc. and start the others off, and up to 8 more to make music.

This made writing complex pieces much easier: one player could set up and sequence an entire bass part, another the chords, another a lead line, and so on, independently.  (Of course, each player's code would have to use the right note durations so as not to get ahead or behind the other players — though if you used bar lines, the language would check that for you.)

The multitasking was mostly transparent.  Words that played notes, or waited for user input, would automatically pass control to the other players, so it felt like up to 9 CPUs running simultaneously. (There was also an IDLE keyword for use in e.g. tight loops so as not to ‘starve’ the other players, though that was rarely needed.)

Back in 1984, on a home micro, this all seemed like magic!

Answer 18

Interrupts are co-operative multitasking - the hardware interrupts, it runs code to handle it, it returns to the (single) background loop (or a lower priority interrupt) by popping the stack. Most 8-bit home computers used this extensively - on a C-64, you could get an interrupt when two sprites in the video system collided (I think).

Operating systems like Unix have pre-emptive multi-tasking - a process gets scheduled to run when it has nothing to wait for and has reached the top of a priority/round-robin system. Under the hood, this is (usually) done by servicing a (timer or peripheral) interrupt and deciding which process gets the CPU. Mostly, each process will need its own stack.

So you need RAM for the stacks and CPU for the context switches - which is why a lot of 8-bit systems didn't bother. You can actually have a fairly sophisticated user environment with no co-operative multitasking - e.g. Windows 3.x.

Answer 19

If you want to count somewhat more primitive approaches, there was once a product called 'Sidekick'. This program supported what was known as 'terminate and stay resident' programs; essentially, the code for several programs would be loaded into memory at once, and each was in a partial state of execution, with one 'running' and the others temporarily paused. There was no automatic process switching as in a proper OS, but the user could switch from one to another via special keystrokes. I don't remember if this was only for the IBM PC or anything earlier, though.