Re: DPMI/EMS/XMS/VCPI/etc... Discussion -- Note on DOS "HIGH"/"UMB"
"Bryan J. Smith" wrote: > Many 386+ memory managers ... > These techniques are just "memory access" methods ... > Some memory managers that got excellent >640KB "packing" > used VCPI to do so. QuarterDeck's QEMM386 was one such > program ... > My favorite extender was always 386Max. You _could_ > do some of the stuff QEMM386 did, but it stuck with a > "dynamic" DPMI manager by default, and "got out of the > way" of VCPI. [ Most of you already know a lot of this. I'll just make it for "yet another post for the archives that we already have." ;-P ] Couple of things I wanted to clarify about my last post on "Memory Managers" and "Extenders": 1. I called [Qualitas'] 386Max an "extender". It was a DPMI-capable DOS memory "manager", not an "extender" (used by programs). Sorry about the "symmantics slip" there. 2. The "focus" I talked about "protected mode" -- i.e. greater than 1MB memory access. This is outside of the 20-bit addressing of the original 8086. With exception of the "brief mention" of "memory managers" like QEMM386 and 386Max, I wasn't discussing how to "maximize" memory under 1MB. 3. DOS=HIGH -- "real-mode" trick to get an extra 64KB. The 8086's 20-bit addressing is, mathematically, capable of addressing 1088KB (10FFF0h), an extra ~64KB. The 20-bit addressing mode of the original 8086/88 uses a 16-bit "segment" register with a 4-bit "shift" (i.e. multiply number by 16 to get the actual address), and add with a 16-bit "offset" register. E.g., the "maximum" physically addressable on the 8086 should be FFFF (seg) + 000F (off) = FFFFFh (1024KB), which is the same as FFF0+00FF, FF00+0FFF and F000+FFFF. Well, what if you use FFFF (seg) + greater than 000F (off)? You get >1,024KB/1MB. This breaks the 8086 processor. But with even the most simple XMS >memory managers running on the 286 (e.g., even early HIMEM.SYS versions), there is a >simple hardware/software combo that can net that addressable range of 1,024-1,088KB, >an extra 64KB. The trick is to use the 286+'s A20 (address 20) line as a "flag" to >say, use that extra 64KB that is really addressable, when the 286+ processor is in >"real-mode". The only "issue" with this address range is when accessing it in software that"normalizes" the seg+off. So you only want to put things in that area that is "aware" of what it's doing. E.g., DOS itself, which is not pre-emptable (or not supposed to be ;-)! Hence, DOS=HIGH. It gets "trickier" if you start putting DOS structures in there, structures that can be addressed by programs (e.g., BUFFERS, FILES, etc...). 4. DOS=UMB, Upper Memory Block (A0000-FFFFFh) Using the 20-bit "real" addressing mode of the 8086, you _can_ address A0000-FFFFFh. In fact, this was reserved and used for various BIOS and memory mappings. E.g., for various physical BIOS: XT-AT System BIOS F0000-FFFFFh (to 64KB) AT-PS/2 Extended BIOS E0000-FFFFFh (to 128KB) VGA BIOS C0000-C7FFFh (to 32KB) E.g., for video memory mappings: EGA/VGA "pages" A0000-AFFFFh (to 64KB) Mono/MGA B0000-B7FFFh (to 32KB) CGA, EGA/VGA text B7000-BFFFFh (to 32KB) And countless other BIOS/memory mappings. When Lotus/Intel/Microsoft (LIM) EMS was introduced with the 286, which could address the 286-PC/AT's 24-bit/16MB bus, they used upto a 64KB "window" in the UMB to map/swap in/out from >1MB memory. Most of these early capabilities were on 16-bit ISA boards (which could address upto the PC/AT 24-bit). It wasn't long before system designers started putting the >640KB/>1MB memory on the system board itself. Intel introduced the XMS spec, with >physical BIOS services (Int15h). Some vendors got "fancy" and devised a way to map >this unused "faster" memory as a "shadow/cache" for slower BIOS/ROM at the same >address. And then some found a way to just turn that into directly addressable RAM, >via EMS, XMS, etc... With the 386, you got a whole memory management unit (MMU). It could play all kinds of tricks here. Backfill XMS as UMB blocks, reserving 64KB for EMS page frames, or not (e.g., EMM386.SYS' "noems" option, giving another 64KB of "usable" UMB for TSRs/programs). For the most part, the 8086/real-mode addressing is "normal" so there are _no_issues_ with the _great_majority_ legacy programs. And there are countless "tricks" (and "issues") with loading, addressing even "moving/remapping" BIOS/memory in this range. Hence where different memory managers come in. And, again, some tried to "squeeze more" by using either VCPI (QEMM386) or DMPI (386Max, DR-DOS), often in semi-incompatible ways with programs that needed VCPI and/or DPMI. [ Side note: On the opposite end, even some programs expect the 64KB .COM DOS kernel _always_ be located in the first 64KB of memory, 00000-0FFFFh, so they load at 64KB+, 10000h. I.e., they actually don't like _more_ than 576KB to be "free." Hence the simple "loadfix" program that loads a program at 10000h, even though there is free memory below. ] 5. How DOSEmu plays "tricks" like #3 and #4 When I load DR-DOS 7.03 in DOSEmu (with all DPMI/XMS/EMS support), it says 153KB is being used for DOS, 623KB of 640KB is free. I assume it is using both the A20/HIGH line for 64KB of that, and some various UMB blocks outside of common BIOS/memory maps as well as the EMS page frames give a little more. 623KB seems to be the "safe maximum" for compatibility, with the software interrupt table (4KB), XBIOS data area (1KB), various structures (varies) in sub-640KB area. Is there a technical document on all this? Or does it vary by actual DOS implementation/image/boot used? I assume it is a combo, with DOSEmu's technical documentation stating _what_ can be used, and the individual DOS implementations taking advantage of it or not. -- Bryan -- Bryan J. Smith, Engineer mailto:[EMAIL PROTECTED] AbsoluteValue Systems, Inc. http://www.linux-wlan.org SmithConcepts, Inc. http://www.SmithConcepts.com - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
