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.

  • 17
    Note that modern operating systems enforce process isolation from one another using hardware which 8-bit systems didn't have. This meant that everything had to be much more well behaved in order not to bring anything down. With CP/M it was not unusual to reboot the machine if a program went into an infinite loop. Commented Aug 22, 2017 at 20:41
  • 7
    @ThorbjørnRavnAndersen In the modern networked age, systems which could not enforce memory isolation between tasks would be unworkable. But the late 70s, 80s, and early 90s was a different age. Cooperative multitasking + multi-user systems were quite workable and effective. The "hackers" were part of the team, and the fun was seeing what the team could accomplish together. Intentionally destroying the work of others was just rude and childish. Yes, an errant program could cause problems for everyone, but that occurred a lot less frequently than you might imagine.
    – RichF
    Commented Aug 23, 2017 at 1:56
  • 10
    @IraBaxter: If you think that today's programs are any more well-behaved than "back then", you are sadly mistaken. To the contrary; just like people "back then" blithely assumed that "all the world is a VAX", today they assume that unreleased resources will be cleaned up at process termination. In a non-protected system (like the AmigaOS "back then"), every unreleased memory hunk and every unclosed file will remain that way until system reboot, because the system does not have any means to "clean up" after you. I'd daresay programs "back then" were better behaved than today.
    – DevSolar
    Commented Aug 23, 2017 at 12:56
  • 3
    Do you consider "modern" 8-bit like the AVR? There are RTOSes for it. Commented Aug 23, 2017 at 13:06
  • 4
    @RichF The 'late 70s, 80s, and early 90s was a different age' only in the microprocessor world. I was using microprocessors with memory protection in 1979, and I was using minis and mainframes with full process isolation from 1971. The micro world took several steps back, and took until at least 1990 to catch up with where everybody else had been since about 1957.
    – user207421
    Commented Aug 27, 2017 at 8:26

19 Answers 19


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.

  • 5
    "With a 68008 CPU it might be seen somewhere at the edge, but I'd still consider it an 8-bit machine." Wrong. It cannot in any way be considered 8-bit, just as it cannot be considered 4-bit or cow-bit or hat-bit. It's 16-bit. There is no "consider" to it.
    – Rich
    Commented Aug 25, 2017 at 17:38
  • 8
    The 68000 has a 32-bit architecture; the fact that some 32-bit operations take longer than 16-bit operations doesn't change that. Nearly all ALU operations that can be performed upon 16-bit quantities using a single instruction can also be performed upon 32-bit ones using a single instruction. By contrast, something like the Z80 includes some 16-bit registers and some instructions that can perform 16-bit arithmetic upon them, but most operations can only be performed using an 8-bit accumulator.
    – supercat
    Commented Aug 25, 2017 at 22:47
  • 6
    @rich The 68008 had an 8-bit bus. Commented Aug 25, 2017 at 22:55
  • 12
    @ThorbjørnRavnAndersen - so did the Intel 8088, but I've never heard anyone call the IBM PC an 8-bit machine.
    – Jules
    Commented Aug 28, 2017 at 7:45
  • 6
    wikipedia has a "hands off approach" in this discussion: "The Motorola 68008 is an 8/16/32-bit microprocessor" :) I myself wouldn't consider the 68008 an 8 bit CPU, since it's a 68000 (which is 32bit) with just smaller "doors" to the outer world
    – Tommylee2k
    Commented Oct 3, 2018 at 8:52

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.

  • 3
    My company was "Software Dynamics". We used "SDOS" for all the OS variants. Frankly they were all the same architecture :-}
    – Ira Baxter
    Commented Aug 22, 2017 at 20:56
  • 16
    I don't know what you call a computer you have at home, except a "home computer". I hand built a custom 12 bit computer in 1973 (and ran complex wire-routing problems with over 10K wires on it). I had my SDOS boxes at home in 1975. DEC's president famously asked, "Who'd need a home computer" in that same time frame, thinking the answer was nobody. DEC is dead.
    – Ira Baxter
    Commented Aug 22, 2017 at 22:29
  • 4
    @traal: Yes, that SDOS. That was me and my ragged band of 3 helpers.
    – Ira Baxter
    Commented Aug 23, 2017 at 4:06
  • 2
    I suppose that if you make "whatever RAM you wanted" more specific, the claim becomes a lot less impressive, at least for today's audience :) Commented Aug 23, 2017 at 14:12
  • 3
    @HagenvonEitzen: Well, for the baseline RTOS, "Whatever RAM you wanted" tended to be 1KB to 16KBytes. Frankly, that makes these devices more impressive; its amazing what you can do with a small amount of resources if you have an organized attack.
    – Ira Baxter
    Commented Aug 23, 2017 at 15:36

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.

  • FWIW, SDOS ran on the Color Computer, too. And in spite of the halt-and-wait hardware design for the floppy disk, SDOS ran the disk and the keyboard with full dynamic interrupts, meaning you could actually type ahead while the disk was running and nothing got lost. I don't think OS9 although capable of this on good hardware accomplished this on the CC; when the disk was spinning, you couldn't type and vice versa.
    – Ira Baxter
    Commented Aug 27, 2017 at 19:51
  • @IraBaxter Thank you for the info, both in your answer and this comment. I never actually used either OS-9 or SDOS, but I had a lot of hands-on experience with the CoCo and its Extended Color BASIC. I was attracted to the 6809 CPU because of its elegance.
    – RichF
    Commented Aug 27, 2017 at 20:06
  • 2
    The test for whether one trademark can be confused with another is not based on internet search results.
    – nekomatic
    Commented Aug 23, 2018 at 12:58
  • I think OS-9 is the best example of a contemporary multitasking OS for this class of machine. However, the 6809 was technically a 16-bit CPU, if you go by the width of natively supported arithmetic operations, even though the address space was just as limited as a typical 8-bit machine.
    – Chromatix
    Commented Jan 19, 2020 at 5:06

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)

  • 7
    The 68008 is a 16-bit CPU with a 32-bit command set, running on an 8-bit bus. Duh!
    – Zac67
    Commented Aug 22, 2017 at 20:52
  • 4
    @Zac67 - right... if the 68008 is 8-bit, then so's the 8088 and therefore the IBM PC counts, so TopView and/or PC DOS 4.0 are candidates.
    – Jules
    Commented Aug 22, 2017 at 21:13
  • 3
    Careful about using "ALU size". The Thinking Machines CM-1 parallel supercomputer had one bit wide CPUs, but it had 65536 of them. People programmed 64 bit floating point as a long string of one-bit-CPU operations. A 64x serial slowdown still meant 1000x faster overall.
    – Ira Baxter
    Commented Aug 23, 2017 at 8:05
  • 2
    @Rich because when the QL entered the market, Sinclair claimed it to be a 32-bit-computer, Motorola said it was a 16-bit one and some magazine claimed it was an 8-bit computer due to its data bus size. There is no fixed definition of what it really is. In case you have a citation, don't hesitate to bring it across.
    – tofro
    Commented Aug 25, 2017 at 21:31
  • 3
    @Rich "most registers are 16-bit" is wrong. All 16 address and data registers in the 68008 are 32-bit. There's only one 16-bit register, the CCR. And note I don't "believe" anything over anything else. I have just stated it was debated a lot. Please read my statements with a bit more care.
    – tofro
    Commented Sep 13, 2017 at 8:07

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.

  • Your answer seems to imply that di and ei are available from inside Locomotive BASIC! Is that right? Commented Aug 16, 2018 at 7:14
  • 1
    Yes, that's right. Note that these BASIC interrupts were soft interrupts, and unrelated to the CPU's interrupt handling
    – scruss
    Commented Aug 16, 2018 at 11:04

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.


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.

  • Nice description of VCS development. But I'm not realy sure if this Answer applies. The OP was asking for mechanics ready supplied in software with any system, not if it's possible att all, as this in principl it can be done with any machine.
    – Raffzahn
    Commented Aug 27, 2017 at 21:23
  • I was referring to the Atari 400/800 PCs as well, also the Commodore VIC, C64, Colecovision, yadayada. Those PCs pretty much dominated the market at the time. It's really about the architecture of the machine moreso than the CPU proper, obviously CPUs of that age did not contain video cards. Commented Aug 28, 2017 at 3:14
  • 1
    On the Atari 2600, there aren't any hardware interrupts, but some games still use a cooperative multitasking approach by having the "game logic" code poll the timer to see if it's almost expired and, if it has, wait for it to expire fully and then generate a vertical sync or a display frame as appropriate. Strat-O-Gems used that technique, for example, to handle the fact that identifying all the matches might take a variable mount of time that could exceed what was available in a single vertical blank.
    – supercat
    Commented Dec 18, 2017 at 0:02

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).

  • SymbOS is a very nice pice of Software. Z80 users should give it a try. But as it has been said, it's contemporary, created after 2000, so not realy an answer here.
    – Raffzahn
    Commented Aug 23, 2017 at 9:35

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.

  • Serious? When the Transputers cam in like 84/85, the 8 Bit era was already ending
    – Raffzahn
    Commented Aug 23, 2017 at 11:33
  • 2
    @Raffzahn The first transputers went on sale in 1984. That's right in the middle of the home computing boom, and it was all about 8-bit machines like the Spectrum and Commodore 64. The 8-bit era wasn't even close to ending at that point.
    – Graham
    Commented Aug 23, 2017 at 13:05
  • 2
    The 8 bit era began life support around 1984-1985.. Commented Aug 23, 2017 at 13:57
  • 2
    @Graham sure, but claimingth 8 Bit title for a new 16 Bit CPU in 1984 is a bit off track, isn't it? All the other 16 Bit CPUs that became real machines during the mit 80s, where all developed in the 70s. Are they now also 8 bit era? Come on don't bend it too much. The Transputers where great machiens, and I had a lot fun figuring out how to programm something useful, but they are just neither 8 bit machines nor 8 bit era.
    – Raffzahn
    Commented Aug 23, 2017 at 16:52
  • 3
    I'm not claiming it's 8-bit - I even explicitly said that it isn't 8-bit. However it is very much the era in which 8-bit machines were dominant. Contrary to your assertion, 8-bit machines in 1984 were flourishing, utterly dominant in all markets except high-end number-crunching, and not even close to "life support". If you can think of a 16-bit machine in the same era which had novel multicore/multithreading capabilities, I'm sure the OP would be interested in that too. I personally can't think of one though.
    – Graham
    Commented Aug 25, 2017 at 9:08

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

  • 1
    Welcome to Retrocomputing! Welcome to Retrocomputing. This is a link-only answer, meaning that most of its information is elsewhere. Please quote the relevant portions of that link in your answer using the blockquote syntax (put "> " at the beginning of each line). For more information, see How do I write a good answer?.
    – wizzwizz4
    Commented Aug 26, 2017 at 8:24

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.


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
  • This, like some other answers, has gone beyond 8-bit computers. (I don't follow your first sentence at all...) I can help out somewhat in the "home computer" constraint of the question, though. The Heathkit H-11 was an LSI-11 kit or fully-built system sold from 1978 to 1982. // Another multi-user, multi-tasking system available on PDP-11 systems was Forth, from Forth, Inc.
    – RichF
    Commented Aug 24, 2017 at 0:45
  • @RichF Many of the so-called "8 bit" microcomputers had 16 bit address spaces. They were able to form 16 bit addresses as immediate operands, or with various addressing modes.
    – Kaz
    Commented Aug 24, 2017 at 2:58
  • 2
    Thanks for the explanation, but i don't agree that address bus size is a determining factor on what category the CPU is. I think it is more accepted to use the accumulator size in specifying the "bitness" size of a CPU. Admittedly even this could get fuzzy -- e.g. consider that the HL register pair of the Z80 could act as an extended accumulator. But even then when you compare the 1 M cycle for ADC A, B with the 4 M cycles of ADC HL, DE, it is pretty clear that 8-bit stuff is going on internally.
    – RichF
    Commented Aug 24, 2017 at 20:35
  • @Richf you made an unfair comparison. Adding an 8-bit register with A is a 1-byte command, but adding a "16-bit" register with HL takes two bytes. Better would be an immediate data ADC, such as ADC A, 17. That takes 2 M cycles, compared with the 4 for ADC HL, DE. It is still indicative that 8-bit stuff happens internally, but does so more fairly.
    – RichF
    Commented Aug 24, 2017 at 20:40
  • 3
    I call the 6502, 6800, Z80 and the like 8-bit, because when you did a memory fetch, you got 8 bits, and the CPU was engineered around that concept with many 8-bit registers. This differs from an 8086, a true 16-bit bus and engineered around that, despite the hack of the 8088 to double-fetch on an 8-bit bus. Address bus has nothing to do with it, because a 256 byte memory space would be nigh useless. Commented Aug 27, 2017 at 21:02

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).


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.

  • 2
    Linux could not run on 8088 - the minimum was 386. If you are thinking about ELKS, it's not Linux. There were other unices (or similar) capable of running on 8088 (e.g. QNX), but these were very commercial and certainly not aimed at home computer users. Commented Aug 25, 2017 at 12:43
  • @RadovanGarabík you are entirely correct. I'd misremembered that early Linux didn't require 386 and above. I have edited the post.
    – abligh
    Commented Aug 25, 2017 at 15:04
  • Any decent multitasking OS needs a CPU capable of memory protection. Otherwise fuggedaboutit... Commented Aug 27, 2017 at 21:06
  • 6
    @Harper I pretty much disagree - Even modern real-time multi-tasking systems (RTOS) can very well multi-task without memory protection. Memory protection is just some safety net against misbehaving applications.
    – tofro
    Commented Aug 27, 2017 at 22:26
  • 2
    The 8088 was not an 8-bit CPU. It could perform 16-bit arithmetic natively, so it should be described as a 16-bit CPU, regardless of the width of the external data bus.
    – Chromatix
    Commented Jan 19, 2020 at 5:01

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.


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.

  • Do you know of any commercial operating systems that actually worked that way in the 8-bit days? My experience was primarily with MP/M family, and they did not work that way - everything was in RAM. This sounds vaguely familiar - I think I have heard of such things in relatively early mainframe days, but that would not have been 8-bit. Commented Oct 10, 2023 at 1:23
  • @manassehkatz-Moving2Codidact: I think some RAM expansion packages for the Apple offered a means of switching applications by swapping the contents of main and expansion RAM, but code always being at its normal address whenever it was running, but my point was that professional computers did multitasking without any kind of virtual memory hardware, so the existence of such hardware is not a prerequisite for multitasking. Additionally, while I don't know if anyone used it in such fashion, one could have done something similar using something like The Final Cartridge for the C64.
    – supercat
    Commented Oct 10, 2023 at 15:07
  • @manassehkatz-Moving2Codidact: If you're working on one program, and want to momentarily work on something else, one could hit the "freeze" button, save a memory snapshot to disk, load the other program, and then reload the memory snapshot and resume what one was doing. I never actual owned a TFC, so I don't know if it accelerated write performance as well as read performance, but it could certainly have been designed to do so.
    – supercat
    Commented Oct 10, 2023 at 15:08

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!


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.

  • 11
    I think "Interrupts are co-operative multitasking" is pushing the definition a bit far. Having interrupts and (necessarily short/fast) ISRs allows asynchronous events to be handled more easily, but aren't in themselves sufficient for what I'd call multi-tasking: for that, you really need support from the OS to switch context between multiple tasks. Such switching might happen on interrupts (e.g. timer-driven, preemptive multitasking) or in a cooperative fashion (e.g. early Windows).
    – TripeHound
    Commented Aug 24, 2017 at 7:05
  • 3
    @TripeHound: Interrupts may be used for pre-emptive multitasking on systems which can arrange to have multiple programs loaded at different physical addresses simultaneously. The code for that isn't complicated in cases where different processes use completely disjoint resources. The only complicated part is handling shared resources. On the other hand, even if shared resources are the only complicated part, they can be a doozy.
    – supercat
    Commented Aug 24, 2017 at 19:15
  • 2
    @supercat Agree with what you say; my point is that interrupts on their own aren't sufficient for multitasking; you also need the OS to handle memory and shared resources.
    – TripeHound
    Commented Aug 24, 2017 at 19:33
  • 1
    @TripeHound: It's pretty easy to make one program multi-task with another if they use disjoint resources and address ranges; it doesn't require a full-fledged OS. On the Z80, a timer-tick interrupt would primarily have to exchange the stack pointer with a stored SP value and then return from interrupt after swapping. Less than a couple dozen bytes of code.
    – supercat
    Commented Aug 24, 2017 at 19:45
  • 8
    The first sentence is wrong. Cooperative multi-tasking is when a thread voluntarily gives up the CPU (by making a system call, for example). Preemptive mutli-tasking is when an interrupt preempts a thread and switches to a different thread. The clue is in the name.
    – JeremyP
    Commented Aug 29, 2017 at 10:03

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .