+1
I think it's a bit unfair how in history the 80286 went under the radar, so to speak.
Because in practice, it just worked and got the job done, quietly.
It was the kind of piece of equipment that had never stood out but kept things going, without demanding for attention.
It also needed no fancy cooling or fans, no special power supply.
The CMOS versions drew little power, too.
In a time when NMOS versions of 808x were still the norm (there was one maker of an CMOS 8086/8086 ?).
When I think about it, things like CPU accelerators, later Tandy 1000 PCs or OS/2 1.x come to my mind.
Xenix also had a 286 and 386 version, I think.
The 80286 was used behind the curtain to make things possible that the 8088/8086 weren't up to.
It allowed 8087 emulation in software for example, which the 808x or NECs couldn't do.
So users of a PC/AT or XT+286 accelerator could run scientific or financial software before buying an mathematic co-processor.
That was like a bonus feature that came for free with the improved performance, basically.
Due to the limits of the 80286, mainboards got their smart chips (-> NEAT).
Suddenly, the motherboards featured shadow memory and a dedicated MMU (-> EMS bank-switching logic).
Which in retrospect was much cleaner approach than using CEMM and V86.
Hardware EMS was fully compatible with Real-Mode software and worked in any processor state.
So even in 16-Bit Protected Mode as used by OS/2 (I read there were a few software solutions to get EMS to work in DOS pealty box of OS/2 1.2 or 1.3).
Hardware EMS also didn't have the overhead associated to V86 (386 and early 486 were slowed down by V86; VME later solved the issue).
Of course, Windows was sort of an exception here.
While Windows 1.x was developed on a Tandy 2000 (80186) with an IBM PC 5150/5160 with EGA graphics in mind (though GUI elements still being 640x200/CGA friendly),
Windows 2.x stepped quite up a bit and did target the 386 from the start.
Windows/386 was the full version, with its own VM/EMS manager.
So it made sense that Windows 2.x applications were tested/written with its capabilities in mind the foremost.
Sure, the retail release of Windows 2.03 was best known,
it was sold to attract the masses of PC and AT users, but it did little to Windows applications.:
Multitasking DOS applications barely worked due to memory limits,
rendering it into a runtime for Windows applications and a small collection of useful desktop utilities (calculator, paint program, word processor, card file, terminal).
The equivalent of a cut-down version of the later to be released GeoWorks Ensemble 1.x, basically.
To get Windows 2.x to work seriously, an optional, LIM4 software compatible memory expansion was needed.
Such as the EMS provided by 80286 chipsets. Or an AST Rampage AT/286.
(Or any PC with a quick Fixed-Disk to hold an EMS swap file.)
Edit: Of course, plain Windows 2.x could also make use of emulated EMS provided by CEMM or EMM386 (MemMaker!) on 386+ PCs (just remember to load SETVER on modern DOSes to avoid crashing win.com).
That was sufficient to have WinWord, Excel or Page Maker and other EMS aware applications have enough working RAM.
With such an configuration, Windows 2.x was almost on eye-level to Windows/386 on, say, a Compaq Deskpro 386.
Windows/286.. It basically was same as Windows and Windows/386,
except that it could use the HMA of a PC/AT in a similar way that was used by DR-DOS 5 later on.
Thus, there's a conflict if both Windows/286 and MS-DOS 5/6 try to use HMA (DOS=HIGH).
(All versions of 2.x could still run on an 8086 CPU by running win86.com executable;
Windows/386 perhaps needed different graphics drivers than plain Windows 2.x because of the grabbers and the V86 VM manager.)
Long story short, Windows 3.x made better use of the 80286 capabilities,
such as Protected-Mode, various x86 memory models for executables (small, medium, large etc) and also Extended Memory.
By comparison, Windows 2.x did use the 80286 based PC/AT more like a Turbo XT with EMS.
That's interesting, because the hardware support of Windows 2/3 was basically reversed.
a) 80386 PC such as Deskpro 386 (most important)
b) PC/XTs with upgrades. EMS, CPU accelerators such as Mach 10, Mach 20, Tiny Turbo 286 (second important)
c) PC/ATs (least important)
This was quite different to Windows 1.x which was made for fast 8086 and 80186 PCs. All being XT class, basically.
Say, Olivetti M24 (AT&T 6300) or Tandy 2000 or Siemens PC-D.
Windows 3.0 also focused on better XT compatibility (Real-Mode kernal was enhanced to be a client for EMS LIM4, ideally with 256KB page frame).
The Standard-Mode for 80286 and 16-Bit Protected-Mode was youngest addition, while the 386 Enhanced Mode was the star of the show.
Early on, 32-Bit Extenders like Watcoms WIN386 offered a 32-Bit Windows API on top of Win16 API.
Windows 3.0 applications compiled with WIN386 extender fully took advantage of Windows 3.x in 386 Enhanced Mode (still worked on Win 9x).
Edit: Sorry for the long monologue here. Today's not my best day, I have trouble wording things. Hope you don't mind. 😅
PS: Here's a curiosity. An 286 based accelerator from former East Germany, BK600.
No one really knows what it's really good for, apparently.
https://www.robotrontechnik.de/html/forum/thw … ?threadid=13351
Then, in USSR, there were attempts to clone the 80286 functionality using discreet parts. Very interesting.
https://www.youtube.com/watch?v=uYT0shUtqhY
In former East Germany, torwards near its end, the U80601 was a succesfully made 80286 compatible CPU.
https://en.wikipedia.org/wiki/U80601
Last but not least, PC-MOS/386 and other OSes supported third-party MMUs made for 80286 systems.
Such as the ALL Chargecard. Very fascinating piece of technology!
https://www.youtube.com/watch?v=xgMIbo6QoM4
PS: Oh, and then there's a fine little detail that the 80286 had but that the old 8086/8088 hadn't. String operations.
The 80286 could do INS/OUTS, which could accelerate applications and i/o routines a lot!
The NEC V20/V30 supported that, too. And likely the 8018x, as well.