BitWrangler wrote on 2023-10-05, 23:24:

Well when 286 boards first got SIMM or SIPP, the "normal" size was probably the 256kB and the special order "Holy heck are you running a shuttle mission" 1MBs maybe just existed for near the price of the whole system unit. So boards may have got 8 slots with the idea they could be filled eventually with a whopping 2MB. Though most are probably wired to take at least 1MB SIMM. But anyway, huge amount of slots was initially expecting user to buy the affordable smaller SIMM most likely. But what the heck, 1MBs haven't gone to stupid pricing so fill 'em if all if you like. 9 chip modules are probably "safest" for 286 and older 386, may only need 100 or 8ons, but if you buy 70, they at least won't slow your 486 to a crawl if you wanna use them elsewhere later.

Interesting! I didn't know that "9 chips" thing! Thanks!!

Robbbert wrote on 2023-10-05, 22:25:

Another way to look at is, if the computer has the slots for extra memory, there must be a way to use it, so put in as much RAM as you can.

After all, the slots wouldn't be there if they didn't do anything.

Good point!

mkarcher wrote on 2023-10-05, 23:01:

Robbbert wrote on 2023-10-05, 22:25:

After all, the slots wouldn't be there if they didn't do anything.

"Creating demand for RAM modules" is also "doing something" 😉

🤣

jakethompson1 wrote on 2023-10-05, 23:10:

mkarcher wrote on 2023-10-05, 23:01:

Robbbert wrote on 2023-10-05, 22:25:

After all, the slots wouldn't be there if they didn't do anything.

"Creating demand for RAM modules" is also "doing something" 😉

Would 286 board vendors have had OS/2 in mind when deciding how many memory expansion to put on their boards?

Good point!

digger wrote on 2023-10-05, 23:33:

Dune II requires at least 2MB of memory (conventional memory + XMS, not EMS) for PCM audio playback. When only conventional memory (or not enough extended mory) is available, only music and non-digitally-sampled sound effects can be heard in the game. The installer will warn the user about this when no extended memory is detected.

It's a real mode game, so it runs on a 286. So that's at least one game that you can only play in its full glory on a 286 when you have at least 2MB of RAM installed. 🙂

Sounds thrilling! I never played Dune II in the joyful days, but you succeeded in transmitting me the feeling!

douglar wrote on 2023-10-06, 00:34:

Maybe. However you would have to use OS/2 1.3, which was, uhh, spartan to say the least on a 286 unless you had 16 bit OS/2 app […]
Show full quote

jakethompson1 wrote on 2023-10-05, 23:10:

Would 286 board vendors have had OS/2 in mind when deciding how many memory expansion to put on their boards?

Maybe. However you would have to use OS/2 1.3, which was, uhh, spartan to say the least on a 286 unless you had 16 bit OS/2 apps. With no virtual 8086 support, it was not a better DOS than DOS. I remember getting lemmings to run in its single tasking DOS compatibility session once upon a time, but it wasn’t really stable.

But if you want to put 8mb in your 286, I say do it, as long as you dont mind the longer mem check post time. It is pretty much a free upgrade compared to how much it would have cost in 1988, so have at it. Maybe it makes windows 3.1 better.

Is it possible to use the extra ram for smart drive without XMS?

Gotcha, thanks.
Yes, indeed, I also wondered things like that: Smartdrv and/or Ramdrive

Jo22 wrote on 2023-10-06, 09:57:

I know it's a bit annoying, but.. I've did some testing 286 vs OS/2 1.x over here. (^We weren't always dead serious in that thre […]
Show full quote

I know it's a bit annoying, but.. I've did some testing 286 vs OS/2 1.x over here.
(^We weren't always dead serious in that thread, btw. A bit of poking fun at each others..)

The OS/2 compatibility box is quite limiting, but it has good technical reasons here for.
The whole first 640KB (default setting) are essentially being exclusive for the synthetic DOS.

That's why 640KB are being "lost" for OS/2 and OS/2 needs more memory than DOS without any further doing.
In addition, a small HDD cache is being running, too.

If OS/2 is running, it can use its own drivers for networking and filesystem (in theory).
It's not needed to load any DOS drivers for this into first 640KB.
So ideally, those 640KB in the DOS "penalty box" are usually free to DOS applications.

On a contemporary 286 PC running PC-DOS 3.30, even less memory would be available.

On the other hand, the latest 16-Bit OS/2 (v1. 3) was around when MS-DOS 5/6 and memory managers like QEMM/EMM386 were available.
And they could "out source" parts of DOS and applications beyond 640KB, liquidishing the need for 16-Bit OS/2 here.

But then, there's the filesystem. The latest 16-Bit OS/2 supported HPFS, which had advantages over FAT.
And like with Windows NT, OS/2 could run DOS applications on a foreign filesystem.

Very interesting, thanks!

@everyone else

Wow guys, so much interesting stuff you added which I missed and I can't find a moment to finish reading, I will... Thanks all

I do vaguely remember from the Pentium days that a higher amount of RAM could sometimes lead to lower performance, due to the cache (COAST) module not "covering" all of it. Or maybe I remember it incorrectly or incompletely?

And maybe this doesn't apply to the way how 286 CPUs access and cache the RAM?

digger wrote on 2023-10-09, 18:07:

I do vaguely remember from the Pentium days that a higher amount of RAM could sometimes lead to lower performance, due to the cache (COAST) module not "covering" all of it. Or maybe I remember it incorrectly or incompletely?

Yes, this is true. The issue of a limited cachable area existed in on-mainboard caches since they were invented, but before the times of socket-7 boards, it was unusual to be able to afford a sufficient amount of memory to run into this issue. Typcial L2 caches since around 1992 are "direct mapped", and have a tag RAM containing 8 bits. One of the 8 bits of the tag RAM can be re-purposed with many chipsets as "this cache line has been modified, and still needs be written to RAM" flag (aka "dirty bit").

In a standard direct-mapped cache, the address in the cache is taken from the low part of the address, so with 256KB of cache, the main memory can be thought as a sequence of 256KB blocks. A memory location at a specific offset inside one of these blocks will always be cached in the same at the same offset. So the house-keeping algorithm just needs to note for each cache location, which memory block the data in this cache location is mirroring. With 8 bits in the tag RAM, this means that you may only have 256 blocks of memory, which means (at a cache size of 256KB) that the cache can only cover 64MB. If a bit of the tag is re-claimed as "dirty bit", you can only cache 32MB.

More than 8 bits of tag RAM are very uncommon with 486 and Pentium/(Super) Socket 7 boards, although the Intel 430HX chipset is famous for being able to support up to 11 tag bits, increasing the cacheable are by a factor of 8. Even with that chip set, a lot of boards just connect 8 tag bits to the chipset, so having a 430HX chipset is no guaranteed escape from this "cachable area" restriction.

digger wrote on 2023-10-09, 18:07:

And maybe this doesn't apply to the way how 286 CPUs access and cache the RAM?

Most 286 systems were uncached, anyway. And even if they were cached, the limited addressable area of the 286 processor (just 16MB) made the cacheable area limit mostly a non-issue. At 64KB cache, 8 tag bits are still enough to cover 16MB without a borrowed dirty tag bit.

On that note, has anyone actually found a (desktop/mainstream/non-bespoke mainframe style) 286 system with cache? I know we dig up some old adverts from time to time which detail a 286 CPU cache, but no-one seems to have found any conclusive proof of a physical thing that existed, or have one in their possession, anyway.

mac57mac57 wrote on 2023-10-06, 14:40:

I may have missed it but the original poster (OP) mentioned UMB as well. There is no restriction around the 286 and UMB. This is […]
Show full quote

I may have missed it but the original poster (OP) mentioned UMB as well. There is no restriction around the 286 and UMB. This is purely a software matter. I am running 128 KB of UMB on a PC XT, powered by an 8088! UMBs came into formal existence with MS-DOS 5.0. There may have been other DOS variants that did it sooner, but with MS-DOS 5.0, I have a healthy set of UMBs running on both of my PC XTs, one of which is an enhanced clone with an 8086 @ 8 MHz vs. the usual PC XT 8088 @ 4.77 MHz.

So while this isn't a reason to go beyond the 1MB limit, it IS something else you can do with extra RAM in an up to 286 PC.

I agree with all the other posters: Windows, either 3.0 or 3.1, is a compelling reason to add extra eXtended Memory to a 286. The 286 can address up to 16 MB, so there is no issue there AND you get the use of the High Memory Area (HMA), the first 64KB above 1 MB, which, due to a quirk in the way the x86 architecture addresses RAM, becomes available and is addressable in a 286 architecture.

Quite aside from eXtended Memory (XMS) however, Expanded Memory (EMS) can also be very useful. All the major disk cache programs of the day support placing the cache into EMS, and I can tell you from real experience that it makes a perceptible speed difference. Almost all the major RAMDisk programs of the day support EMS-based RAM disks, and that too can be used to achieve a substantial speed up of your 286 machine, by placing all your most commonly used programs into an EMS-based RAM disk and then making the drive letter for that disk the first element on your PATH statement.

Oh wow useful! And wow! I did experiment with RAM DRIVES a lot in the past, but never thought about the importance of the 'order' of the entries in the PATH statement! 😳 Right!!!! Thank you!!!

alvaro84 wrote on 2023-10-06, 16:39:

digger wrote on 2023-10-06, 14:29:

Let us know how well it runs! I remember recently reading somewhere that at the same clock speed, 286 CPUs were actually faster than 386sx CPUs. 🙂

I tried and it kinda crawled. It worked but, especially with a dozen units on screen, the controls had inconveniently big delay, the frame rate was horrible (not that important here) and even time slowed down.

I have a 386sx-25 in stock that I can compare it to. Which seems to run at 1WS at that so Landmark shows it slower than this 286-20. Wolfenstein didn't agree that much but IIRC it was very similar clock-for-clock. So, this will by me next experiment.

😳 Whoa! A simple wait state can be that bad!!! 😳

Jo22 wrote on 2023-10-06, 21:09:

EMU386 emulates a few 386 specific real-mode instructions, btw..
That way, some newer DOS applications can run on an 286 PC.

😳 I never heard of it! How couldn't I!? Sounds useful! Thanks! I'll look it up

BitWrangler wrote on 2023-10-06, 21:33:

25Mhz Harris o/c 33Mhz, 16MB 0ws RAM EMU386, EMU387 and half a frame per second on Quake with 4 levels of screen reduction 🤣

(Still probably more FPS than OG 6mhz 286 IBM AT on MS Flight Simulator 🤣 🤣 )

😳 😳 🤣🤣🤣🤣🤣🤣

GG brotha!!!!!

PS: Where do I download EMU387? Thanks!

mkarcher wrote on 2023-10-07, 09:47:

...The "virtual 8086 environment" provided by EMM386 is slightly slower than running the 386 in real mode...

Wait... what what? What's this virtual environment and this 386 real mode???

AlexZ wrote on 2023-10-07, 18:03:

EMS or XMS for games? is relevant for this discussion. […]
Show full quote

EMS or XMS for games? is relevant for this discussion.

Install more than 1MB RAM if your board allows it and you can get it cheap. Finding applications that utilize that memory will be another matter. Since memory was very expensive in 286 era, very few applications made use of it. Certainly not games as those were targeting home users.

Since ISA bus is quite slow and usually not overclockable in BIOS on 286 (unlike 386), using EMS cards would be a bad idea. EMS boards may be ok for a 12Mhz 286. Originally their purpose was expanding memory on 8086/8088 which could only address 1MB RAM.

286 is capable of running in unreal mode and modern himem.sys takes advantage of that. This means no switching to protected mode is necessary. On 386 the application could in theory just switch to unreal mode and directly access the whole extended memory without relying on XMS driver and without having to switch to protected mode. That is not the case on 286 though. XMS is a copying API unfortunately. The original spec can be found here https://www.phatcode.net/res/219/files/xms20.txt. The key API function is Bh) Move Extended Memory Block. XMS driver basically uses extended memory as a form of in memory swap file that is not meant to be directly accessed by the application. EMS vs XMS differences are also well explained here http://computer-programming-forum.com/46-asm/ … 0a3b819222f.htm . Emulated EMS on 286 isn't a great idea as it will consume 64kb of memory (for the window) and it will do copying just like XMS driver thus being inferior solution. With XMS driver the application decided how many windows it needs and they could take up more than 64kb. Emulated EMS on 386 isn't bad at all as memory is remapped rather than copied, the main downside is just 64kb window limit and slower V86 mode. Typically useful for applications that need a moving window - e.g. audio playback or spreadsheet window but you wouldn't store there data that is accessed frequently and randomly. In general you should avoid EMS unless you need it and run emm in NOEMS mode.

You typically need config.sys with multiple boot options depending on what application requirements.

Mmm... lots of info! I lack the necessary background: E.g. the difference between real and protected mode, and stuff. Thanks for the info and for the references! I'll have to study.

mkarcher wrote on 2023-10-09, 19:00:

Yes, this is true. The issue of a limited cachable area existed in on-mainboard caches since they were invented, but before the […]
Show full quote

digger wrote on 2023-10-09, 18:07:

I do vaguely remember from the Pentium days that a higher amount of RAM could sometimes lead to lower performance, due to the cache (COAST) module not "covering" all of it. Or maybe I remember it incorrectly or incompletely?

Yes, this is true. The issue of a limited cachable area existed in on-mainboard caches since they were invented, but before the times of socket-7 boards, it was unusual to be able to afford a sufficient amount of memory to run into this issue. Typcial L2 caches since around 1992 are "direct mapped", and have a tag RAM containing 8 bits. One of the 8 bits of the tag RAM can be re-purposed with many chipsets as "this cache line has been modified, and still needs be written to RAM" flag (aka "dirty bit").

In a standard direct-mapped cache, the address in the cache is taken from the low part of the address, so with 256KB of cache, the main memory can be thought as a sequence of 256KB blocks. A memory location at a specific offset inside one of these blocks will always be cached in the same at the same offset. So the house-keeping algorithm just needs to note for each cache location, which memory block the data in this cache location is mirroring. With 8 bits in the tag RAM, this means that you may only have 256 blocks of memory, which means (at a cache size of 256KB) that the cache can only cover 64MB. If a bit of the tag is re-claimed as "dirty bit", you can only cache 32MB.

More than 8 bits of tag RAM are very uncommon with 486 and Pentium/(Super) Socket 7 boards, although the Intel 430HX chipset is famous for being able to support up to 11 tag bits, increasing the cacheable are by a factor of 8. Even with that chip set, a lot of boards just connect 8 tag bits to the chipset, so having a 430HX chipset is no guaranteed escape from this "cachable area" restriction.

digger wrote on 2023-10-09, 18:07:

And maybe this doesn't apply to the way how 286 CPUs access and cache the RAM?

Most 286 systems were uncached, anyway. And even if they were cached, the limited addressable area of the 286 processor (just 16MB) made the cacheable area limit mostly a non-issue. At 64KB cache, 8 tag bits are still enough to cover 16MB without a borrowed dirty tag bit.

Wow! So much stuff I don't know!

megatron-uk wrote on 2023-10-09, 19:10:

On that note, has anyone actually found a (desktop/mainstream/non-bespoke mainframe style) 286 system with cache? I know we dig up some old adverts from time to time which detail a 286 CPU cache, but no-one seems to have found any conclusive proof of a physical thing that existed, or have one in their possession, anyway.

Indeed! I never heard of nor seen 286 PCs with L2 cache, at least none that I remember. Maybe, on the magazines I browsed as a kid, somewhere, there was an ad of a 286 mentioning "cache" in its specs... but who can remember! But let's see what the others have to say.

megatron-uk wrote on 2023-10-09, 19:10:

On that note, has anyone actually found a (desktop/mainstream/non-bespoke mainframe style) 286 system with cache? I know we dig up some old adverts from time to time which detail a 286 CPU cache, but no-one seems to have found any conclusive proof of a physical thing that existed, or have one in their possession, anyway.

That is an interesting question and I don't know the answer but here are some thoughts.
The Compaq Deskpro 386 was the first PC-compatible 386 and instead of a cache it had static column DRAM. Here is a nice write-up about it that also gives some historical context I don't have about why they didn't add a cache: https://archive.org/details/PC_Tech_Journal_v … ge/n55/mode/2up
They mention the possibility of a cache in passing, and also mention that 60ns DRAM is too expensive. There isn't enough context to guess whether they are talking about cache in computer design overall, or that unlike other PC compatibles, this one doesn't use a cached design. The article claims a 60% "hit rate" for this static column DRAM. It sounds like static column DRAM is something like "even-faster page mode" where changing the column only is virtually free?

There are so many other factors like--when did 286 systems even get fast enough that the speed of affordable DRAM chips even starts to bind? i.e. would it have ever made sense to pair a 12 or 16 MHz 286 with 150ns DRAM plus a cache, rather than just going to faster DRAM by the time they were economical to sell in the first place.

16 MHz seems in other ways to be the borderline where cache doesn't make sense, as some 486 chipsets can even be put into a special "slow clock" mode described in their datasheets to use a tighter DRAM memory cycle when operating at 16 MHz.

While 16 MHz is 62.5 us cycle for both 286 and 386, one or the other could be more forgiving with regard to slower DRAM chips, as mkarcher has mentioned elsewhere the 386 has an address pipelining feature to give the memory controller/DRAM more slack time for seeing the address.

"Static column" technique. Not static ram memory.

I think the article meant fast page memory chips. That board 386 16 board used 100ns fast page dram for 16MHz 386. Faster models started to use 80ns dram as well. 60ns was not available in quantity at reasonable price till later than 1993 or later.

Cheers,

Those 4x 1MB SIMMs in my 12 MHz 286 were 70ns, I believe.
My father and me got the PC second-hand from a company dissolution (?), with everything but the floppy, PSU and motherboard (+VGA, bus mouse port) removed.

It was a disk less station, I assume. There wasn't even a HDD frame available.
As a workaround, the HDD could be mounted vertically on a support frame, which also held the ISA riser card in place.

Since Windows 3.1 was already available to us, but not MS-DOS 6.22, I assume it roughly was somewhere in the 1992-1994 time frame.

At this time, 286/386 PCs were still in common use, and 1 MB SIMMs were around, as well.
Simultaneously, 80ns SIMMs were a bit dated by then, as well. But still usable. 120ns and 150ns (God beware!) were ready for the museum.

That's why I had never much interest in SIPPs and 256KB SIMMs, I suppose. They were a bit before my time. And too old, merely usable with waitstates, at best.

Edit: 150ns were EPROM territory, speed wise.
That's not exactly a level that RAM should operate at (it should be quicker).

pentiumspeed wrote on 2023-10-09, 23:18:

"Static column" technique. Not static ram memory.

I think the article meant fast page memory chips.

Static column RAM is slightly different from FPM RAM. FPM RAM dominated the market in the end, and static column RAM was a only used in a small number of "mainstream" computers.

With FPM RAM, you need to toggle /CAS every time you supply a new address. The address is latched only at the falling edge of /CAS (+/- hold/setup time). On the other hand, static column RAM behaves like SRAM for the currently opened page. When you change the supplied address on the address pins, some time later the data output pins present the data of the newly selected column. I'm unsure whether these RAMs have a /CAS pin at all.

The ultimate goal of FPM, EDO and static column RAM is the same, though: It allows the chipset to access data within one open page at a speed that apptoaches SRAM performance.

By the way, I once had the successor of the Deskpro 386, the Deskpro 386/20. This computer has (obviously) 20MHz instead of 16MHz, and it uses the Intel 82385 cache controller to implement a two-way cache. I don't remember the details, but I expect the RAM to be standard FPM. Detailed technical reference manuals including schematics for both the Deskpro 386 and the 386/20 are available at PCjs.org. They are a very interesting read for technology affine people!

aries-mu wrote on 2023-10-09, 20:06:

mkarcher wrote on 2023-10-07, 09:47:

...The "virtual 8086 environment" provided by EMM386 is slightly slower than running the 386 in real mode...

Wait... what what? What's this virtual environment and this 386 real mode???

Short version: The 8086 processor just has a single mode of operation, and when the 286 processor introduced a different mode of operation, the old "normal" mode of operation was given the name "real mode".

Long version: The 8086 is a 16-bit processor. It uses 16-bit data registers and 16-bit pointers. 16 bits are enough to represent 65536 values, but no more. If a pointer is meant to address a specific byte, a 16-bit pointer can address only 64KB. When the 8086 was designed, people were not expecting that any single data block that an 8086-based system is going to operate on will exceed 64KB, so they introduced "segmented memory": Different data blocks can be in different "memory semgents". Before you are going to address memory, you have to choose the segment you are going to use by loading a segment number into a segment register. The 8086 provided 4 segment register: One is used to access code (CS), a second one is used to access the stack (SS). The third one is used by default to address data (DS), and the fourth one is a secondary segment that can be used to access a second data object without needing to re-load DS. This extra data segment register is called ES. The way the segmentation model on the 8086 works is that it can address up to 1MB of RAM. A "segment" can start on any 16-byte aligned address in that 1MB area. As you can easily calculate, there are exactly 65536 possible 16-byte aligned addresses in 1MB. The segment register just contained the start address of the segment divided by 16. If any memory access happened, the 8086 calculated the sum of the segment start address (that is the segment register value multiplied by 16) and the pointer used to address the memory location. That's all to it.

When the 286 was introduced, the addressable memory range should be increased, and furthermore, the 286 processor should support memory protection. Memory protection means that there is an operating system kernel that manages memory and assigns memory to tasks. Each task can only access memory it is allowed to access, so that one task can not cause a different task to crash (or even steal data of a different task). This means the 80286 needed some new abstraction mechanism that enabled an operating system to control which memory is visible to a program. So the processor got a mechanism to look up "segment descriptions". While on the 8086, the program loaded the real base address of the segment into a segment register, in the new operation mode of the 80286, the program loaded a segment number into the segment register which was then used to look up the segment in a table of segment descriptions. This segment description contained the start address of the segment (which could be anywhere in the total 16MB address space), the number of bytes that are allowed to be accessed in that segment, and the operations that are allowed in that segment: For code segments, execution was always allowed, and the OS controlled whether reading was allowed. For data segments, reading was always allowed, and the operating system controlled whether writing was also allowed. Furthermore, the new feature of a "segment limit" caused the processor to reject any memory address made into a segment that is above this limit. While the 8086 allowed any 16-bit value to be used with any segment register, the operating system on a 286 processor can control how much memory is actually allocated to a segment. This new operation mode of the 286 virtualized memory addressing by putting the "descriptor table" between the application program that just uses segment numbers and the memory interface that uses physical addresses. This address virtualization is the base for memory protection. Thus the mode was originally named protected virtual-address mode. On the other hand, to be compatible with the 8086, to execute DOS software, the processor also supported a mode in which there is no memory address virtualization, and segment registers work the same as on the 8086: Every segment can be used to read, write and execute data; the limit is alway 64KB; and the segment number multiplied by 16 is directly the start address of that segment. As the real addresses of the segments (not just an abstract number) had to be loaded into the segment register, this mode was originally named real-address mode. These mode names "protected virtual-address mode" and "real-address mode" were so long, that people started shortening them to "protected mode" and "real mode". The 80286 thus can execute DOS and software designed to run in DOS when it is operating in real mode, but it can not access (significantly) more memory than 1MB in this mode, as the segment start address is still limited by a 16-bit value in the segment register multiplied by 16, and the segment size is also limited to 64KB. On the other hand, when running a modern multi-tasking system, like Xenix/286 or Microsoft Windows 3.0 with software that is designed to run in protected mode, it can access the complete range of 16MB. If you run software designed for the real mode in protected mode, this software will fail as soon as it attempts to change segments to new base addresses the program got from calculations based on the fact that increasing a segment register by one is shifting the visible segment by 16 bytes. A lot of DOS software contains logic to calculate segment numbers, so DOS software can usually not be executed in protected mode.

After the 286 was released, software was not re-written to be protected-mode compatible as fast as Intel expected, but people kept using the standard real-mode software they were used to. At the same time, as the amount of available RAM started to allow it, people wanted multitasking including multitasking of DOS software. Furthermore, while the table-based segment allocation seems like a good idea, it gets a nightmare for the memory management of an operating system if you want to dynamically add and remove segments. As segments can be any size, after allocating and freeing a lot of segments, you will have a severly fragmented map of allocated and free memory ranges. While the model of segment descriptors allows the operating system to rearrange the segments to defragment the memory, this means you would need to copy data around and then adjust the segment descriptions, so they now refer to the new copy. Copying data is a slow operation and best avoided. So when Intel introduced the 386 processor, they added a new instrument for memory management, called "paging". This allowed memory to be managed in fixed-size chunks. Each of these chunks is 4KB. Each of these chunks can be available to the application program, or "forbidden". This allows the operating system to load only parts of segments into RAM and forbid access to other parts. When a program accesses a forbidden part of the segment, the operating system is notified about a "page fault" and can load that part (maybe writing some other page to the swap file first), to make the required page available to the application program. This was especially important since the 386 is a 32-bit processors, so segments are no longer limited to 64KB in size, and you would not want to be able to load/unload a 500KB segment only as one single piece. The capability to re-map memory access on a per-page basis allowed the 386 processor to support a special new "hybrid" operation mode. This new mode can be activated for a user-mode task by an operating system running in protected mode. This new mode "feels" like the "real-address" mode in that segment registers contain the start address of the segment to use, so this mode is fully compatible with DOS software. On the other hand, paging is still active and controlled by the protected mode operating system. The protected mode operating system can thus instruct the processor to re-direct memory access from what looks like 1MB of 8086 address space into any location of the conventional or extended memory as the operating system seems fit. You can even have multiple tasks that use different mapping for multitasking of DOS applications. Because this mode that "feels" like 8086 real mode to a user-space program, but is still under control of a protected mode operating system, provides a "virtualized 8086" to the user-space program, this mode is called "virtual 8086 mode", often shortened to "virtual mode" or "VM86".

If you undertand this background, understanding EMM386 is easy: EMM386 is a minimalistic 32-bit protected mode operating system that sets up a virtualized 8086 environment, so it can redirect memory access that seems to address an EMS card or UMBs into extended memory. Whenever a DOS program calls the EMS driver integrated in EMM386, EMM386 takes control and modifies the translation table, so the virtualized 8086 environment will see the updated mapping. There are some complicated details making EMM386 not as simple as it might seem at the first impression: For example, DOS software programming the DMA controller sends supposed physical memory addresses to the DMA controller, but as EMM386 re-maps memory addresses, the addresses sent to the DMA controller by DOS software might be "wrong", and need to be translated by EMM386. So EMM386 does not only virtualize memory addressing, but it also needs to virtualize the DMA controller. The 80386 includes all the required hardware support to run virtualized 8086 real mode software. It does not include hardware support to virtualize the kernel mode operation of protected-mode operating systems, though. This is what is actually new in the "hardware virtualization support" by Intel (VT-x) and AMD (SVM). The virtualization of real-mode environments was already present with the 80386, and used by both Windows 3.0 for the DOS box in enhanced 386 mode, as well as OS/2 to run DOS tasks. The Linux "DOS emulator" dosemu also uses a kernel feature of i386 Linux to be able to switch from normal protected mode userspace handling into VM86 mode to be able to execute real-mode software.

Great write up. Can I talk you into giving your version of the classic story about A20, himem, and the keyboard controller?

douglar wrote on 2023-10-11, 02:08:

Great write up. Can I talk you into giving your version of the classic story about A20, himem, and the keyboard controller?

Along with how the 286 changed from 1984 to 1988 making mode switches easier without extra circuitry

^Speaking of the 80286..
It was released in February 1982, roughly half a year after the IBM PC Model 5150.

At this point in time, both DOS and the IBM PC were still irrelevant.
The majority of Model 5150 users likely ran ROM BASIC and were stuck with roughly 64 KB of RAM.

And considering development times of such complex circuits,
the development of the 80286 maybe had started in same year of which the IBM PC was released (1981),
or maybe a year before the IBM PC was released (1980).

That's maybe important to keep in mind if we're wondering why the 286 wasn't so great at multi-tasking DOS applications: DOS itself wasn't such a factor yet, neither was the IBM PC.

Especially if we understand that the 8086/80286 weren't PC processors yet.
At least not exclusively.
The x86 processors were generic "general-purpose" processors, used in all sorts of applications. Like the Z80 or 6502 were used.

Edited.

douglar wrote on 2023-10-11, 02:08:

Great write up.

I think the same, well written. Kudos. 😎

wow this is very interesting thread. It'd probably have helped me out a few months ago.

Anyways the big reasons to get extra ram is basically if you are going to use it for anything 'big'. It helps a LOT with Windows, as apps can actually load into RAM. Add in a ram drive & emm286 and Windows 2 apps are so much more responsive. And of course Windows 3.0/3.1 can use all that ram in standard mode for things like Sim City/Earth, or even Word & Excel.

For me it was OS/2 & compilers, although building stuff at 10Mhz is astoundingly slow.

I'd always wanted a PS/2 model 60 as a kid, so for me it's great to have one now. I'd run a simple video demo of Wing Commander EGA mode with and without emm286, and yeah its way slower using emm286. I haven't tried VGA yet, although Im out of town for the moment so I can't say for sure.

https://virtuallyfun.com/wp-content/uploads/2 … lapp_ffmpeg.mp4

I tried to sync them up manually but you can clearly see which one has EMM286 running.

One thing is for sure, going in with SCSI and a BlueSCSI disk emulator brings in some fantastic performance! I need to try some other experiments with EGA/VGA & dos versions + Stacker to see if any of it matters. Also trying various 286 dos extenders, and seeing how they perform on an IBM PS/2.

Secretly I've already ordered an 8580 motherboard, as much fun as the 286 has been, being stuck at 16bit just sucks, going full 32bit for at least stuff like Wing Commander seems to be the way to go, although from experience going from a 16mhz 286 to a 16mhz 386 DX was such a letdown performance wise, but capabilities it was great to have that 'personal minicomputer' experience.

Of course, everyone has missed one very important reason to have as much RAM as your motherboard can handle. The bragging rights 😀

@neozeed Tips: The Himem.sys of Novell DOS 7 supports features of a few 286 chipsets.
The spiritual predecessor to QEMM was QRAM, which supports some memory tricks on 286.

debs3759 wrote on 2023-10-11, 09:37:

Of course, everyone has missed one very important reason to have as much RAM as your motherboard can handle. The bragging rights 😀

😂

megatron-uk wrote on 2023-10-09, 19:10:

On that note, has anyone actually found a (desktop/mainstream/non-bespoke mainframe style) 286 system with cache? I know we dig up some old adverts from time to time which detail a 286 CPU cache, but no-one seems to have found any conclusive proof of a physical thing that existed, or have one in their possession, anyway.

Generally speaking if Intel never made a reference system with a cache controller we can say it never happened.

http://www.bitsavers.org/components/intel/802 … Manual_1987.pdf

What you do find is Intel continuously talking about in place of cache is
dual port memory
And they really brag about pipelining in the 286 and all the added multiple processing support built in to the 286 architecture.

Intel did build a massively parallel 286 server, sadly it’s a lost history scenario since the online descriptions of it have disappeared from the internets (on my list to find again but having no luck). The 286 multiple processor server was a bit of a black eye for Intel since it didn’t sell.

Back to cache, there are only 3 fringe cases where the 286 used sram
Before 1986 a few people would legitimately use only SRAM as their only system ram to remove dram overhead. As memory requirements went up the number of folks doing it went down.

Fringe case 2
386sx “chipset cache”
There are no meaningful differences between SX and 286 buses and there were many 3rd party chipsets that supported both chips.
Any late 286 built on a 386sx bus could use the cache when built into the chipset as no additional logic was used.

If people have links to the adds mentioning cache + 286 I would like to see them

I’m guessing Harris + Chips and Tech probably had one

Fring case 3
286 overdrives (upgrade your XT)

https://www.minuszerodegrees.net/manuals/Accelerator_286.pdf

I just like this article and what it links to
https://hackaday.com/2022/08/13/the-286-gives … -final-secrets/

Looks like you already got lots of responses, but I have 8MB in my 286, because I can. And I like to think about how ridiculous this would have been in its heyday..

Back then, memory was exceedingly expensive. But things get more useful when XT came out due to more slots and people were starting to use PC more often and software more easier to get.

Cheers,

rmay635703 wrote on 2023-10-11, 12:56:

Fring case 3
286 overdrives (upgrade your XT)

https://www.minuszerodegrees.net/manuals/Accelerator_286.pdf

That's the one!

I am sure I also saw a YouTube clip of that very CPU... it must be exceedingly rare! ... but the owner could not get it to work. I suspect because the driver disk has been lost to the passage of time.