dhosek@freke.claremont.edu (Don Hosek) (05/31/91)
What is it about the first 64K of extended mem that makes it so special to DOS 5.0, DESQview, et alia? It seems that there should be no more trouble accessing any other 64K block of extended mem than the UMB, but I'm acknowledgedly ignorant of such things... -dh -- Don Hosek dhosek@ymir.claremont.edu Quixote Digital Typography 714-625-0147
nelson@sun.soe.clarkson.edu (Russ Nelson) (05/31/91)
In article <1991May30.213856.1@freke.claremont.edu> dhosek@freke.claremont.edu (Don Hosek) writes:
What is it about the first 64K of extended mem that makes it so
special to DOS 5.0, DESQview, et alia? It seems that there should
be no more trouble accessing any other 64K block of extended mem
than the UMB, but I'm acknowledgedly ignorant of such things...
It's a consequence of Intel's segment/offset address calculation. You see,
if you add a segment of 0ffffh and an offset of 10h, you get a linear address
of 100000h. That's more than one meg. In fact, it's the first byte of the
UMB. Now, the 8088 didn't keep that bit, and so some programs might make use
of that wrap-around. To be safe, IBM's AT design has a provision for forcing
address bit A20 to a zero.
Basically, accessing the HMA is just a matter of setting up the right segment,
and changing the hardware so that it respects A20. That's what HIMEM.SYS
does.
--
--russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker.
Clear cutting is criminal, spiking trees is criminal, and using hyperbole of
this magnitude in a serious discussion is criminal. -- Irv Chidsey
jwbirdsa@amc.com (James Birdsall) (06/01/91)
In article <1991May30.213856.1@freke.claremont.edu> dhosek@freke.claremont.edu (Don Hosek) writes: >What is it about the first 64K of extended mem that makes it so >special to DOS 5.0, DESQview, et alia? It seems that there should >be no more trouble accessing any other 64K block of extended mem >than the UMB, but I'm acknowledgedly ignorant of such things... First, terminology: what you are talking about is normally referred to as the HMA (high memory area); it is the first 64K - 16 bytes of extended memory. UMBs (upper memory blocks) are random blocks of memory that may exist between 640K and 1M. The HMA, UMBs (if any), and extended memory are all covered in the XMS specification. What's so special about it? Well, due to a bug in the 286, it is possible to access the HMA from real mode. When adding a segment and offset, the overflow (21st bit) is supposed to be thrown away in real mode. On the 286, it isn't necessarily. Therefore, if the A20 line (21st address line) is enabled and the segment and offset values are set up properly, it is possible to get at nearly the first 64K of extended memory. I forget whether this bug was deliberately kept in the 386, or whether it is emulated in another way, but nearly all 386-and-up systems can perform this trick as well. -- James W. Birdsall WORK: jwbirdsa@amc.com {uunet,uw-coco}!amc-gw!jwbirdsa HOME: {uunet,uw-coco}!amc-gw!picarefy!jwbirdsa OTHER: 71261.1731@compuserve.com "The OS shouldn't die every time the controller drools on a sector." -- a sysop =========== "For it is the doom of men that they forget." -- Merlin ===========
eric@cs.fau.edu (Eric Thav) (06/06/91)
In article <1991May30.213856.1@freke.claremont.edu> dhosek@freke.claremont.edu (Don Hosek) writes: >What is it about the first 64K of extended mem that makes it so >special to DOS 5.0, DESQview, et alia? It seems that there should >be no more trouble accessing any other 64K block of extended mem >than the UMB, but I'm acknowledgedly ignorant of such things... From what I understand, they don't access it as extended memory. Rather, with HIMEM.SYS (or QEMM's appropriate drivers), programs that know about this area can access that 64K block as CONVENTIONAL MEMORY. Microsoft, when Windows 2.0 was introduced, "discovered" this area suddenly and developed the HIMEM.SYS driver to access it. So, when you load programs into it, you are not exactly loading it into extended memory (even though it is located in extended memory), but I believe the programs are just specifying that it be located in an additional area of conventional memory (that just happens to reside in the first 64K of extended memory). Understand? -- .signature not found, format hard disk instead? (Y/N)_ Eric L. Thav Florida Atlantic University - Boca Raton, FL INTERNET: eric@acc.fau.edu GEnie: E.THAV | PRODIGY: Lots of ads BITNET: eric@fauvax PRODIGY: NMVG80A | and we read your mail!
usenet@nlm.nih.gov (usenet news poster) (06/06/91)
In article <1991Jun06.030024.1439@cs.fau.edu> eric@cs.fau.edu (Eric Thav) writes: >In article <1991May30.213856.1@freke.claremont.edu> dhosek@freke.claremont.edu (Don Hosek) writes: >>What is it about the first 64K of extended mem that makes it so >>special to DOS 5.0, DESQview, et alia? It seems that there should > >area can access that 64K block as CONVENTIONAL MEMORY. Microsoft, when >Windows 2.0 was introduced, "discovered" this area suddenly and developed the >HIMEM.SYS driver to access it. Actually, Quarterdeck "discovered" this area. Microsoft just made more of a big deal about it, and seems to have gotten most of credit, which is typical.