70

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.

  • 14
    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. – Thorbjørn Ravn Andersen Aug 22 '17 at 20:41
  • 4
    @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 Aug 23 '17 at 1:56
  • 1
    If you go back before 8-bit architectures, you could include the DEC PDP-11, based on 16-bit words. Unix was running on this early on, and AFAIK it had multitasking although by another name. – Walter Mitty Aug 23 '17 at 7:45
  • 6
    @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 Aug 23 '17 at 12:56
  • 3
    Do you consider "modern" 8-bit like the AVR? There are RTOSes for it. – chrylis Aug 23 '17 at 13:06

13 Answers 13

69

In fact, quite a lot did.

Ignoring the 'home computer' restriction 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. Since 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 did include a pre-emptive multi tasking OS in ROM called QDOS. The built-in SuperBASIC did offer 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 did take many inspirations 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
    I don't believe GEOS for the C64 was multitasking. At best you could freeze one application and start another. – snips-n-snails Aug 22 '17 at 20:19
  • 2
    @Raffzahn Fair enough. True multitasking, and being able to freeze one program to run another, are very similar use cases. As is a systemwide clipboard or equivalent. – snips-n-snails Aug 23 '17 at 5:56
  • 2
    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 Aug 25 '17 at 22:47
  • 3
    @rich The 68008 had an 8-bit bus. – Thorbjørn Ravn Andersen Aug 25 '17 at 22:55
  • 2
    @Jules Even though the PC XT was an 8-bit machine with a 16-bit processor (which was heavily marketed at the time) it was just an expensive machine in a vast sea of other computers. It was not until the PC AT which was much better that the clone makers got good enough that the trend was established. So, the reason you haven't heard it is because you probably only heard marketing. – Thorbjørn Ravn Andersen Aug 29 '17 at 14:18
59

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

  • 1
    "I wrote a variety of RTOS for 8 bit computers in the 70s" <-- you are referring to SDOS, right? – snips-n-snails Aug 22 '17 at 20:14
  • 3
    My company was "Software Dynamics". We used "SDOS" for all the OS variants. Frankly they were all the same architecture :-} – Ira Baxter Aug 22 '17 at 20:56
  • 13
    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 Aug 22 '17 at 22:29
  • 3
    @traal: Yes, that SDOS. That was me and my ragged band of 3 helpers. – Ira Baxter Aug 23 '17 at 4:06
  • 2
    @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 Aug 23 '17 at 15:36
20

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 Aug 27 '17 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 Aug 27 '17 at 20:06
  • The test for whether one trademark can be confused with another is not based on internet search results. – nekomatic Aug 23 '18 at 12:58
11

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)

  • 6
    The 68008 is a 16-bit CPU with a 32-bit command set, running on an 8-bit bus. Duh! – Zac67 Aug 22 '17 at 20:52
  • 2
    @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 Aug 22 '17 at 21:13
  • 2
    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 Aug 23 '17 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 Aug 25 '17 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 Sep 13 '17 at 8:07
10

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? – Wilson Aug 16 '18 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 Aug 16 '18 at 11:04
6

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 Aug 23 '17 at 9:35
6

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 Aug 27 '17 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. – Harper Aug 28 '17 at 3:14
  • 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 Dec 18 '17 at 0:02
5

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.

4

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 Aug 23 '17 at 11:33
  • 1
    @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 Aug 23 '17 at 13:05
  • 2
    The 8 bit era began life support around 1984-1985.. – snips-n-snails Aug 23 '17 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 Aug 23 '17 at 16:52
  • 1
    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 Aug 25 '17 at 9:08
3

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 Aug 24 '17 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 Aug 24 '17 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 Aug 24 '17 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 Aug 24 '17 at 20:40
  • 1
    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. – Harper Aug 27 '17 at 21:02
3

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

  • 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 Aug 26 '17 at 8:24
1

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.

  • 8
    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 Aug 24 '17 at 7:05
  • 2
    @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 Aug 24 '17 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 Aug 24 '17 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 Aug 24 '17 at 19:45
  • 5
    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 Aug 29 '17 at 10:03
1

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. – Radovan Garabík Aug 25 '17 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 Aug 25 '17 at 15:04
  • Any decent multitasking OS needs a CPU capable of memory protection. Otherwise fuggedaboutit... – Harper Aug 27 '17 at 21:06
  • 3
    @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 Aug 27 '17 at 22:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.