> A couple of corrections... > ...
>> There is even an EMM286.EXE driver for machines with a 286 CPU floating >> around >> the Internet that basically does the same thing EMM386 from MS does >> (including >> providing virtualized EMS). > > Never seen that one. But the 286 memory managers I saw, such as > BlueMax, used the _chipset_ to map RAM into UMBs, not the CPU. The 286 > doesn't have a hardware MMU and can't do this. This meant that 286 > memory managers were specific to the motherboard chipset. BlueMax > worked on IBM 286 PS/2s and nothing else. There was also a Chips & > Technologies one I read about. I don't know exactly how EMM286 works -- it may be in fact be quite different than EMM386. I do know that it provides essentially the same functionality as EMM386. Also, if you use the EMS provided by EMM286, it seems to reboot the CPU to exit the Page Frame (i.e., it is VERY slow and isn't as useful as it is with EMM386). > ... > You do not mention the big one though. > > 286 protected mode is still segmented, just like the 8088/8086 with > its 16 segments of 64kB. Sort of. 16-bit Protected Mode uses Selectors instead of Segments, and it also has Descriptor Tables (like the GDT) similar to 32-bit Protected Mode. E.g, you can't do straight math to calculate the linear or physical memory address of a Selector like you can with a Segment. A Selector is simply an "index" to an entry in a Descriptor Table where the actual memory addresses (and other details) are stored. But a 16-bit PM Selector is still limited to 64k in size (but can also be less than 64k) while a 32-bit Selector can be up to 4G (but can also be less). So 16-bit PM is not really "segmented", at least not in quite the same sense that Real Mode is, though it's similar in some respects. Another difference between Segments and Selectors is that a Code Segment (CS) is never writable, so you can't do things like use a CS: override prefix or simply copy CS to one of the data Selectors (DS, ES, FS, or GS) in your code if you intend to write to that memory (but you can read from it). > ... > x86-64 removes support for V86 mode, and I believe, for 286 protect mode too. I don't doubt that is true -- 64-bit CPU's seem to really be trying hard to remove all legacy support, except through Software Virtualization. >> Just as an FYI, in 16-bit PM you can access the entire 4 GB of addressable >> memory just like 32-bit PM > > No, that's wrong. > > The 80286 has a 24-bit address bus and can access a maximum of 16MB of > RAM directly. > > Its _virtual_ address space was much bigger. I think, but am not sure, > that the 80286 supported 16k of segments instead of 16 -- so a total > of 16384 segments of 64kB, meaning a _virtual_ address space of 1GB. > But 16GB of real physical RAM was the max, as with the 386SX. You're conflating the 286 CPU with 16-bit PM. They are not the same thing. 16-bit PM is fully supported on 32-bit CPU's -- you just need to set up the Selectors with the correct Rights & Extended Rights. A 16-bit Selector on a 32-bit CPU can address any part of the 4G memory, but the size is always limited to 64k. >> Let me first address the comment about leaving room for MS LANManager (or >> other big TSR's) in Upper Memory. > > LAN Manager was not a TSR. It was a whole network stack. > > The LanMan _client_ was not one TSR: it was about 3 or 4 of them. A > card driver, then a protocol, then a client... Which was good as > different bits could go into different UMBs. I think they all could have also gone into different EMS pages -- I don't think _ALL_ the code needed to be in Conventional or Upper Memory (though, undoubtedly, some of it probably did). > ... >> I actually starting investigating what EMS actually was and discovered it >> certainly doesn't deserve the bad reputation it has garnered. > > Agreed. It was very useful in its time. And I think it still is -- I am certainly finding it useful, thought I think DPMS is an even better alternative, at least for TSR's and Device Drivers. > ... > > Handy! I had almost forgotten about DPMS, TBH. I think most people have, if they ever even knew about it in the first place. It certainly wasn't very well publicized. I've also seen references in RBIL to a DPMS VxD in early versions of Windows DOS boxes, but have never experimented with it and am not even sure it's quite the same DPMS (though according to RBIL it is the same as Novell). The DPMS acronym is also used in VESA video contexts (Display Power Management Signaling). _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
