On Fri, 24 Jan 2025 at 16:10, Bret Johnson <bretj...@juno.com> wrote:
A couple of corrections... > In fact, the 286 had a Protected Mode, but it was 16-bit PM instead of 32-bit. True. > 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. > HIMEM from MS also works with 286 CPU's. Yes it does. XMS works on both 286 and 386+ PCs, and so does the HMA. > Unfortunately, PM in a 286 has some issues. The story is told that Intel > thought Protected Mode was so superior to Real Mode that no one would ever > want to use Real Mode again (I don't know if that's actually true or not, but > it sounds plausible based on what Intel did with the 286). In the 286, Intel > provided a method to switch the CPU into Protected Mode but didn't provide a > way to switch it back into Real Mode again (386+ CPU's, of course, have a way > to do it). People found a way to work around this by triple-faulting the CPU > and forcing it to reset (do a partial reboot) since the CPU always boots into > Real Mode. Unfortunately, this takes a long time (in computer terms) to do > so switching back and forth between Real and Protected Mode on a 286 should > only be done sparingly. All true. 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. > It also turns out that 16-bit protected mode is EXTREMELY useful, especially > for things like TSR's. AFAIK, all CPUs that support 32-bit PM also support > 16-bit PM, and it's possible to take advantage of that fact to do some > interesting things. A little more on that further below. Correct. *But* 64-bit chips in 64-bit mode do not. x86-64 removes support for V86 mode, and I believe, for 286 protect mode too. > 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. > 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. Otherwise, agreed. > Pretty much throughout my history of programming, I had always heard that EMS > was "bad" but never really took the time to understand why. I even remember > seeing a program a long time ago called HYPEREAL which could take "regular" > TSR's and load them into EMS using some sort of "wrapper" mechanism. You can > still find it at some of the Simtel.Net archives, like > https://ftp.sunet.se/mirror/archive/ftp.sunet.se/pub/simtelnet/msdos/tsrutil/ > (the file is called hyper_01.zip if you want to download and check it out). > The program is not free and the source isn't available AFAIK, but is still > interesting. I pretty much blew it off back when I came across it because of > all the bad stuff I'd heard about EMS (and because of the 64k Page Frame that > at the time *thought* was an insurmountable problem but now think > differently). Interesting. I'd not heard of that before. > > 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. > As I noted above, I think the fact that it needs a 64k Page Frame is just > sort of an "automatic" turn-off because you could be using that memory for > something else (even though on many machines it isn't actually used for > anything at all). True. > The other useful "mechanism" I discovered in the research is DPMS (DOS > Protected Mode Services). You can think of DPMS sort of like "DPMI for TSR's > and Device Drivers". What DPMS does is to temporarily switch the CPU into > protected mode, run your TSR code from Protected Mode (either (16-bit or > 32-bit PM) and then switch back to Real Mode again (or V86 mode if you have > something like HIMEM/EMM386 loaded). This essentially lets you put your TSR > code in XMS since DPMS handles the switch to PM for you. Handy! I had almost forgotten about DPMS, TBH. > The reason I mentioned 16-bit PM above comes into play here. The way I'm > writing the programs, they can run in either Real (or V86) Mode, from EMS, or > from DPMS, all using the exact same code. When I start DPMS, I tell it I > want the CPU to be in 16-bit PM when my TSR code runs. The "stub" of the TSR > that remains in conventional or upper memory contains the set up and tear > down code to switch to DPMS, EMS, or not switch at all, depending on how > things are configured and how the user wants to use their memory. You can > also have both an EMS and a DPMS server installed at the same time. > > A little history on DPMS. I believe DPMS was originally written by Novell > when they owned DR-DOS, and the DPMS servers are included with various > releases of DR-DOS. DR-DOS also included a couple of utilities that were > compatible with DPMS (IIRC they were a disk caching program and an MSCDEX > alternative, and maybe some others too). Some later versions of IBM's PC-DOS > also supposedly included a DPMS server (never tried it myself, and I think it > works a little differently than the Novell version). AFAIK the Novell DPMS > source code has never been released, but Novell said you could distribute the > DPMS server with any DPMS client. The DPMS server only uses about 2k of > memory, so is much more efficient than EMS (which needs a 64k page frame plus > some "overhead" memory somewhere to manage everything). The DPMS server also > works on 286 CPU's, though I know most people won't care about that. > > Anyway, that's the story for TSR's, EMS, DPMS, and USB. Also, I didn't start > the EMS/DPMS experiments with the USB drivers, but started with some simpler > TSR's as a proof of concept to prove to myself that it was all viable -- and > it is. There are still some issues with slower CPU's (286 and earlier) > because of the Protected Mode => Real Mode switching speeds mentioned above > (and other items), but I'm working on ways around that. Good stuff. Thanks for all this! -- Liam Proven ~ Profile: https://about.me/liamproven Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven IoM: (+44) 7624 227612: UK: (+44) 7939-087884 Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
