26

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?

DrSheldon
  • 15,979
  • 5
  • 49
  • 113
Richard Downer
  • 5,531
  • 1
  • 26
  • 59
  • 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 '17 at 09: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. – Richard Downer Dec 07 '17 at 22:54
  • 1
    We had these in college. A right pain. Some MS-DOS stuff worked, some didn't. – Alan B Mar 05 '24 at 14:27

5 Answers5

29

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.

Stephen Kitt
  • 121,835
  • 17
  • 505
  • 462
  • 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 '17 at 13:49
  • Thanks @Jules, I couldn’t remember specifics, hence the “supposed to” — apparently it wasn’t much use (see also the RM Nimbus talk page on Wikipedia where someone claiming to have worked on the system says it simply couldn’t be used as an IBM compatible). I’ve seen other references to SETMODE as well but that might have been for later systems. – Stephen Kitt Nov 27 '17 at 14:09
  • 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 '17 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 '17 at 22:42
  • @PlasmaHH You're talking about the PC-D? Well, that baby did even run DOS 4.01 at some point. And it offered 960 Kib RAM to DOS - eventually even 992 with the latest BIOS versions - early versions reserved 64 KiB of the existing 1 MiB RAM for a never released colour graphics card, but the B&W card only needed the upmost 32KiB. Eventually I may help if your restauration ever runs into trouble :)) – Raffzahn Nov 27 '17 at 23:18
  • @Raffzahn: Maybe with the bios versions, it needs new eproms (and a lot of other things too, but those are the hardest to get). Also I can't remember if part of it was on the dos bootdisk or so, at least I have two floppys with dos 2.11 from the siemens computer museum that are both for (or contain parts of?) different bios versions... but first I need the hardware to run, maybe look out for questions here, do we have pc-d/pc-x tags? – PlasmaHH Nov 28 '17 at 08:53
  • @PlasmaHH The ROMs d not contain any PC-Alike BIOS, but a monitor software and boot loader. The PC-BIOS is wholy contained in the disk BIOS file. The hardware is rather straight foreward. There shouldn't be much to worry. Well, as soon as you put up some questions, I will add a tag :)) – Raffzahn Nov 28 '17 at 10:08
  • 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 '17 at 05: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 '17 at 18:41
  • "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)" -- either there were two versions, or this was an option, because a common passtime in my school.was rearranging your program manager settings to be as weird as you could. I had mine set up like a menu with each group resized so you couldnt see its contents and youd hit maximize or double click its title to get to them. – occipita Jun 30 '20 at 10:48
16

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.

Toby Speight
  • 1,611
  • 14
  • 31
Raffzahn
  • 222,541
  • 22
  • 631
  • 918
8

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.

TonyM
  • 3,704
  • 1
  • 19
  • 31
  • 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 '17 at 09: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 '17 at 18:34
4

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.

Chenmunka
  • 8,141
  • 3
  • 39
  • 65
  • Sorry, but that's total rubbish. Of course every standard Windows programm could run on the PC-128. Offering a machine independent interface is the whole deal of running Windows. And naturally does each machine need machine specific drivers. Using your logic, any windows with some hardware specific drivers is a 'custom Version' – Raffzahn Nov 27 '17 at 13:09
  • 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 '17 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 '17 at 13:56
  • 1
    DOS software, but had little issue with typical Windows software that I could see. – Jules Nov 27 '17 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 '17 at 15:46
  • 1
    @Raffzahn: Yes, that is the purpose. It is just that in the days of the old RM computers, and also some Amstrads and Philips machines, they hadn't quite got it right yet. – Chenmunka Nov 27 '17 at 16:16
  • @Chenmunka I think I would need more information to agree here. There may be quite some applications that did not fully go along with Windows, but that doesn't prove anything. – Raffzahn Nov 27 '17 at 16:24
  • 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. – rackandboneman Nov 27 '17 at 17:03
  • @rackandboneman - While that's true, I believe that such software was pretty rare, and would also have failed to run on NT or (later) on Windows 95. I don't recall there being huge problems switching to those systems, except possibly for games, but games that run under Windows 3 were very definitely the exception rather than the rule -- almost everything ran in DOS instead. – Jules Nov 27 '17 at 17:08
  • 1
    @Jules 16-bit Windows software that made direct access to hardware or the BIOS would still work under Windows NT or Windows 95. The 16-bit Windows emulation under NT (up to and including 32-bit versions of Windows 10) uses the same NTVDM emulator used to run MS-DOS programs. This is necessary because 16-bit Windows programs use MS-DOS functions for file access. Windows 95 on the other hand is just 386 enhanced mode Windows 3 with Win32 support built in, so 16-bit programs are run the exact same way and can access real hardware directly. –  Nov 27 '17 at 18:40
  • @rackandboneman True, but tha's neither the fault of Windows nor the Nimbus PC-186. Badly writen software is badly wrtitten software. No matter what environment is used. – Raffzahn Nov 27 '17 at 23:10
  • 1
    @RossRidge direct hardware access and using DOS for file operations are two different issues. The DOS interface is part of Windows. The Hardware is not. There are plenty 16 Bit Windows programs that won't run under NT. Just because for some the emulation layer does work doesn't change the fact. – Raffzahn Nov 27 '17 at 23:13
  • @Raffzahn NTVDM provides both MS-DOS and PC hardware emulation for both MS-DOS and 16-bit Windows programs. I never said it was perfect or that all 16-bit Windows applications would work. The DOS interface isn't a part of Windows 3. Instead it uses whatever version of DOS that invokes it. –  Nov 27 '17 at 23:58
  • @RossRidge I'm glad noone told that to the guys in Redmond when they wrote the guidelines for writing Windows software. Cause they define DOS calls as part of the Windows programming environment. Duh. – Raffzahn Nov 28 '17 at 00:09
  • 1
    @Raffzahn If they did in fact make that claim about the Windows 3 16-bit programming environment then they were simply wrong. If you were running Windows under DR-DOS, as some people did, then Windows applications used DR-DOS for file access. –  Nov 28 '17 at 00:20
  • @RossRidge - well, yes. Windows itself also would use DR-DOS for file access in that case, so that's hardly unsurprising. This fact is part of the reason why some versions of Windows actually refused to run under non-MS DOS versions: Windows ties in to the underlying operating system at a very low level, and they didn't want to guarantee compatibility. (Of course there may have been other reasons, too.) – Jules Nov 28 '17 at 22:35
  • 1
    @Raffzahn "badly written software" is a very subjective term especially when it comes to DOS-era software - the BIOS and even direct hardware interfaces were considered very much legitimate parts of the API if there was a good reason to use them. Mind that resources were limited and that DOS and BIOS routines were very slow and bloated for some usage scenarios. – rackandboneman Nov 29 '17 at 17:46
  • @rackandboneman A software is badly writen if it doesn't adhere to certain standards. And using hardware dependant calls, maybe even spread them all arround the code, is a sure sigen of bad software. Furthermore neither DOS nor BIOS was anything I would call bloaty or slow. There where many successful and comprehensive programs that could do the job using only the standard interfaces. Much has been blames on the PC, Intel or Microsof here wich is, when looking close, nothing else than an excuse for badly written software. – Raffzahn Nov 29 '17 at 18:07
  • 1
    @Raffzahn if "Software is expected to run on the IBM PC and 100% compatibles, no more no less" , how is direct access to hardware a nonadherence to standards? ... Example of slow: Saving and restoring screen state, esp in text modes, to display eg a pop-up window in a TUI, was brutally faster copying the whole 4K page of video memory than using thousands of BIOS calls... – rackandboneman Nov 29 '17 at 19:36
  • @Raffzahn, when Windows came along, people didn't throw away all of their DOS programs and replace with Windows ones (weren't available anyway). Windows had to support existing DOS software to be successful - a strict, fully protected Windows wasn't acceptable to the market. Games were the main ones that accessed hardware directly and used any BIOS calls or tricks that'd speed them up and give them an advantage. The parallel paths of lenient-Windows-for-home, strict-Windows-for-work were what 95/98 and NT started to lay out. Merging of those happened most definitively with Win2k, years later. – TonyM Dec 01 '17 at 07:51
1

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.

supercat
  • 35,993
  • 3
  • 63
  • 159