The RM Nimbus range of computers were popular in British schools during the late 80s and into the 90s. When I was at high school Nimbus PC-186 machines were all over the place. Many web pages that discuss these machines (such as Wikipedia's article) note that they are not IBM PC compatible.

However they have an Intel x86 CPU, a BIOS, and can run MS-DOS 3.1, Windows 3.0 and MS-NET. They shared several hardware components and port standards.

So why are they commonly described as not PC compatible? What are they missing that means they are incompatible?

  • 4
    In the early days of the IBM PC, compatibility seemed to involve 3 things: 1) BIOS compatibility, 2) ability to run Lotus 1-2-3, and 3) ability to run Microsoft Flight Simulator. IIRC, the DEC Rainbow 100 (1982) failed being accepted by critics as compatible because its graphics were too good, and it would not run Flight Simulator.
    – RichF
    Nov 28, 2017 at 9:40
  • 4
    Thanks to all the answerers on this question. The core of my misunderstanding is a false assumption that if it can run MS-DOS then surely it is PC compatible. In reality MS-DOS was modified for the different hardware so it worked, but most apps did not use MS-DOS services and went to the hardware directly, so they would not work unless specifically modified like MS-DOS was. Dec 7, 2017 at 22:54
  • 1
    We had these in college. A right pain. Some MS-DOS stuff worked, some didn't.
    – Alan B
    Mar 5 at 14:27

5 Answers 5


While the NM-186 was based on a standard x86-compatible 80186, its architecture was very different compared to the IBM PC’s. The major differences are the firmware, which isn’t PC BIOS-compatible, and the memory map, which enabled the NM-186 to make more memory available to applications than was possible in real mode on the IBM PC: as far as I can determine, up to 708KiB for applications, and an additional 512KiB in a RAM drive (the system officially supported up to 1.5MiB of RAM, and I’ve seen claims that up to 925KiB could be made available for applications). The NM-186 also had a different floppy disk controller and graphics controller, providing higher-resolution graphics (up to 640×350 with four colours), and it included a sound chip, the AY-8910. Software written specifically for the Nimbus could take advantage of all that; as you’d imagine, it was mostly educational software.

As standard the NM-186 ran an OEM version of MS-DOS, specifically adapted to its architecture; this was DOS 3.10 (3.05 on early models). It also had various custom versions of Windows, starting with 1.0 and going up to 3.0 (which was adapted for use in schools: icons and groups couldn’t be moved around in Program Manager). Other titles were ported as well. The base system sold in education environments included an “IBM mode” with an “IBMulator” which was supposed to handle well-behaved PC software, at least software which could work on MDA or CGA.

There was an expansion board which provided better PC compatibility, the IBM Mode Utility Board. This added a PC speaker, RTC and various other components necessary to provide hardware PC compatibility.

  • 1
    "The base system sold in education environments included an “IBM mode” with an “IBMulator” which was supposed to handle well-behaved PC software, at least software which could work on MDA or CGA." -- if this refers to the "SETPC.EXE" utility that came with them, it didn't work. The CGA emulation was utterly broken, mostly IIRC because you need to choose which palette of 4 colours it was able to use in advance, rather than let the application switch between them as required.
    – Jules
    Nov 27, 2017 at 13:49
  • 2
    "It also had various custom versions of Windows" - I'm curious how this was arranged. Did RM somehow convince Microsoft to make them a custom build, or did they just tweak the base configuration (or manually alter some binaries themselves)?
    – Dai
    Nov 27, 2017 at 17:28
  • 3
    Lots of not quite compatible 186 based systems seemed to have a DOS with more than 640k ... like the siemens taylorix pcd with DOS 2.11 that still waits for restauration in my basement with the 896k ...
    – PlasmaHH
    Nov 27, 2017 at 22:42
  • 3
    @Dai selling OSes (and parts of OSes) to OEMs was pretty much Microsoft's business model at the time, so I think the only convincing required was money.
    – hobbs
    Nov 29, 2017 at 5:09
  • 2
    @hobbs - and not much of that, either. Around that time period, there were several competing operating systems (CP/M86 or DR DOS, Quarterdeck's DESQview, etc -- and with the complexity of an operating system being much less at the time than today, the ever present worry of new viable competitors being introduced) so MS would generally rather not drive customers to those alternatives by charging too much or being too inflexible.
    – Jules
    Nov 29, 2017 at 18:41

This question is a bit hard, as 'IBM-Compatibility' isn't as clearly defined as advertisement wants to make us believe. In fact, almost any IBM machine could be classified as not compatible, starting with the AT.

Short answer: All PCs are some kind of quantum mechanical device: they are compatible and not compatible at the same time. Only if the system gets observed (aka a program gets started), a definite state emerges. A different state is possible for each program.

Long Answer: Compatibility usually falls into two categories: Hardware and software compatibility. Although these are simple categories, they often get mixed up by hardware being blamed for software problems.

Hardware compatibility describes the fact that a certain (third party or extension) hardware is compatible with a machine. Usually this is defined by interfaces available on the basic unit, such as serial or parallel ports and especially any extension ports. With a different extension bus system (unlike ISA, as defined by the original PC) it will be hard to use such ISA cards, thus hardware compatibility is not given.

Software compatibility defines whether a certain program, written for a certain environment can run or not. For example, an original IBM PC-XT without any video card will still boot and run quite well. That machine is by no doubt IBM compatible, still, running Windows 3.0 is somewhat fruitless - if it comes up at all. Too exotic? Well, plug in an MDA and you'll get the same result.

Maybe you remember the often lengthy list of sound cards, graphic cards, keyboards, mice and joysticks that PC games mentioned on the boxes during the '90s. All claimed to be PC games, but the user still had to verify a long list of features versus his machine.

Software relies on what parts of the environment it accesses. Most obviously it's the instruction set written/compiled for. A program compiled for a 80186 processor may not run on a 8088, but quite well on a 80286. Next it's how it interacts with other features; this may be more hardware (like above games) or other software. Generally there are three basic variations within the PC World:

a) Hardware compatible

Here a program accesses specific hardware at the lowest possible level. A program written to run directly with a CGA won't deliver any (useful) result without that card (or a close emulation).

b) BIOS compatible

BIOS-compatible programs do all their machine specific bidding (beyond the CPU) via BIOS calls. Such programs may run on all machines that offer a BIOS with compatible calls to what the programmer expects, read an IBM-PC BIOS of a certain level. Since the PC-BIOS offers next to everything a character mode program needs, from keyboard and screen handling all the way to disk read and write, this is in some ways equal to what early home computers offered.

c) OS compatible

Here a program does all its machine handling (I/O) via a certain OS, such as DOS or Windows. In reality, there's a split between these examples calling for two subclassifications:

c.1) DOS compatible

A program running on DOS or similar operating systems can rely on a number of additional services, including its eponymous disk management (working with files instead of devices).

c.2) WINDOWS compatible

These are programs that rely on Windows (*1) services. Unlike DOS, Windows includes not only more than rudimentary process support, but also independent interfaces for graphics, sound and a wide variety of input devices.

(*1 - This is also true for other environments, e.g. GEM or GEOS)

In general, a program written for either of the above compatibility layers and following its rules will run on any machine offering the same kind of compatible interface. A DOS program written for an IBM XT does as well run on a Sirius 1, a SIEMENS PC-D, a Tandy 1000 or a Nimbus PC-186. All these machines have been accused of being non-compatible at some point.

One major problem with real world applications is that the programmers did not really care much for clean interfaces - or couldn't because they needed certain capabilities. For example, a game asking for a DOS environment and a EGA. Depending on that made it unable to run on a PC with MDA.

(Grandpa story: One nice example I 'converted' was Multi Edit 5.0 for the SIEMENS PC-D. Eventually the best-ever editor of all time to the best-ever PC. The PC_D was originally developed as a Unix workstation, but later made fully BIOS and DOS compatible - on hardware similar to the NM-186. Multi Edit was well written, except for two minor quirks. It expected a memory-mapped character display much like the MDA (or later) and it accessed the PC speaker directly. Everything else ran via BIOS or DOS calls. Thanks to the nice hardware debugging features of the PC-D it took me about half an hour to find and patch the two words used. Lucky me, the software was extremely clean and only had those two references.)

With restrictions like that, programs needed to be ported, or, if their architecture was advanced enough, a driver for different hardware on different machines compositions had to be added. Even for 'standard' machines, separate drivers were needed for CGA, EGA and VGA (and more) where needed, as the publisher wanted to cover more variations than only his 'standard'.

The major goal in the Windows (and GEM) development was to add abstraction layers for devices like human input (aka keyboards, mice, joysticks etc.), graphics and sound. So a all driver handling was taken away from the applications and bundled with the OS. Porting Windows (or GEM) thus didn't require porting the OS, but just adding new branches of machine/hardware detection and appropriate drivers. Application programs did not need to be changed in any way - as long as they are coded according to the OS guidelines. There were still programs that bypassed Windows or assumed specific settings without checking, but usually not from major developers.

A clean Windows 3.0 program could run anywhere from an IBM-XT with 512 KiB and CGA to a PC-D with 960 KiB usable RAM, 720x350 B&W graphics and a 80186 or any Pentium, 15 years later.

So-called 'special' versions of Windows were not special at all, just the result of Microsoft marketing. For one thing, MS offered the ability to customize loading screens so manufacturers could present 'their' Windows making the buyer believe he got something special. Second, MS offered deals to manufacturers. They got Windows at a greatly reduced price but it only included drivers for the hardware these companies offered. Special machines got even bigger discounts - like the NM-186.

Bottom line The PC-186 was fully compatible with BIOS (AFAIK; there seem to be other information available), DOS and Windows. All clean applications written for either would run right away. Applications that access hardware not available on the PC-186 would fail.

  • 2
    This answer hits the nail on the head! Nov 27, 2017 at 15:57
  • PC-186 isn’t BIOS-compatible though... Nov 27, 2017 at 16:13
  • 1
    @StephenKitt Do you got any good pointer for detailed information here?
    – Raffzahn
    Nov 27, 2017 at 16:22

The 80186 contains a CPU and several peripheral units, including a two-channel DMA Controller, a Programmable Interrupt Controller and three 16-bit timers.

The IBM PC-AT and PC-XT also have a DMAC, PIC and timers but with more DMAC channels and timer channels and all at different I/O addresses to those in the 80186.

The BIOS did not have a full range of function calls for configuring and using these devices, so some programs would write to them directly. Such programs would therefore not work on an 80186-based PC, or an 80188 one for that matter. This lack of compatibility with the PC XT/AT architecture was a major reason for the very limited uptake of the 80186/80188 for PCs.

Programs that don't access I/O devices directly could run fine, which seemed to cover a majority of application software in those days. Such a PC would need a modified BIOS that uses the peripherals available in the 8018x, instead of expecting one of the standard I/O maps of the PC XT or AT. However, things like games were more likely to manipulate hardware directly to squeeze more performance out of the machine, so that wouldn't run on an 80186.

I used the 80186-based Tube board for the BBC Master back in the day and you were fine if you stuck to the right list of programs to run. We didn't use it for long though.

  • 2
    This is I think the more "correct" answer here. I was going to do a full "Why is an 80186" not PC compatible post but all the docs I could find were going to require a lot of reading. From memory the biggest pains were that some of the PC interrupt vectors were reused on the 80186 and the interrupt controller was at a different address.
    – PeterI
    Nov 29, 2017 at 9:40
  • I think the unique graphics adapter was a more user-visible difference, but for lower level applications (not to mention operating systems), this was probably pretty critical. If you tried to run a PC-targeted 16-bit Unix-like system on the Nimbus (e.g. QNX, which I read recently was running on hardware very similar to the Nimbus 186 at a similar time), this would seriously trip you up, likely resulting in needing to make OS modifications to make it run.
    – Jules
    Nov 29, 2017 at 18:34

The Research Machines Nimbus didn't run Standard Windows 3.10. It ran a custom variant which was not interoperable with the standard version used on "Compatible PCs".

The differences lay in the sound, graphics and networking of the Nimbus. These were not to the same standards as "Compatible PCs". The Nimbus came equipped with Ethernet and Piconet ports as standard and a screen resolution (320x250x16 colours) that didn't match CGA, VGA or the other PC formats of the time.
(Note that RM Piconet is not the same as the current Bluetooth network standard)

Some of the differences were to enable backwards compatibility with the earlier RM 380Z and 480Z. These were very common in schools and had a lot of software in common use. The Nimbus was also supplied with an x86 version of BBC Basic, enabling another very popular educational codebase.

It is not just Windows that was adapted for the Nimbus, some other Microsoft software, e.g. Word, was supplied in a Nimbus format. There was also a third party emulation package that would enable certain standard PC software to run.

  • 1
    @Raffzahn: That is not my logic at all. The whole point of the RM system differences is that it did not have a machine-independent interface. As the question states - it is not compatible. That was its ultimate downfall.
    – Chenmunka
    Nov 27, 2017 at 13:14
  • 2
    I have to say, I ran a lot of Windows 3 software that wasn't designed specifically for RM machines on my school's PCs, and never encountered any that had more than slight trouble with the oddness of the system (I did find one program that generated a bug due to the odd screen resolution, attempting to pick a size for displaying icons that wasn't actually available, and ending up drawing only half of each icon because the larger ones it picked as replacement didn't fit in the space it allocated to them, but that's not really a hardware interop problem). The Nimbus struggled with standard ...
    – Jules
    Nov 27, 2017 at 13:56
  • 1
    DOS software, but had little issue with typical Windows software that I could see.
    – Jules
    Nov 27, 2017 at 13:56
  • 2
    @Chenmunka Windows IS the machine independant interface. As soon as it gets loaded every Windows programm will run on the PC-186. Thats on purpose. Isn't it?
    – Raffzahn
    Nov 27, 2017 at 15:46
  • 5
    16-bit windows did not effectively FORCE programs to use the abstraction layers for everything. Software that, for some reason, directly accessed hardware behind the scenes for whatever reason could still have been incompatible. Nov 27, 2017 at 17:03

While it would be possible for text-based programs that don't do anything unusual with the keyboard to run using only features provided by MS-DOS, perhaps with the aid of the ANSI.SYS driver, many programs use features that are provided by the underlying machine for a few reasons:

  1. MS-DOS doesn't provide any graphics functionality at all.

  2. The text-based operations MS-DOS does provide are often more than an order of magnitude (literally) slower than what could be accomplished by accessing screen hardware directly.

  3. MS-DOS doesn't provide any way of determining which keys are pressed at any given time, nor of detecting any key combinations other than those which it is explicitly coded to handle. By contrast, code which installs its own keyboard interrupt handler can detect key combinations like control-shift-X or alt-shift-J.

A machine that can run MS-DOS would be able to run programs that don't attempt to access the underlying platform for any of the above purposes, but many people writing interactive programs didn't want to be bound by the above limitations. Further, many popular language implementations would automatically perform things like screen I/O using the underlying platform functions rather than the ones provided by MS-DOS because of improved performance, so programs written using those implementations would also have trouble on machines that didn't support them the same way as the PC.

You must log in to answer this question.

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