liberato@dri.com (Jimmy Liberato) (06/24/91)
act@softserver.canberra.edu.au (Andrew Turner) writes: >4. You will not be able to use your 384 Kb on the 286 as this requires >EMM386.EXE to be loaded. >5. To quote Microsoft: > "UMA support for 80286 class machines is not supplied in MS-DOS 5.0. > The choice to use EMM386.EXE as the engine for using Upper Memory > Blocks has been motivated by two major factors. > 1. High Memory is available on both 80386 and 80286 machines. To > prevent having two drivers, one for each machine. > 2. Development research indicated that UMB savings on 80286 class > machines did not offset the memory costs of the UMB driver nor > development time. > MS-DOS 5.0 OEMs have shown interest in developing UMA capabilities > into their releases. OEMs do have options that were not addressed > by Microsft's project, options such as Hardware and Firmware > solutions." Does this mean that all those 286 systems of recent vintage with the Chips & Technologies memory control chipset are out of luck? Why would an XMS driver for the upper memory area on a 286 C&T system have more "memory costs" than EMM386 on a 386 system? In any case, I would at least be able to use ~64K of the above memtioned 384K (assuming it was extended and not dedicated shadow ram) as HMA, is that correct? Can anyone with MSDOS 5.0 and a 286 class machine elaborate on the above quotes from Microsoft? -- Jimmy Liberato liberato@dri.com ...uunet!drivax!liberato
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (06/25/91)
I think you are confusing high memory with upper memory. High memory starts at FFFF:0000 and goes up, on both [23]86. UMA is between C000 and F000 (or maybe B000 is the manager is smart enough to sneak under the VGA). So on a 286 you get 64k for the DOS, but not the memory space for the UMA. Since the 286 doesn't have the right hardware to do UMA, it would have to be faked in software. The software would take about as much space as it saved. No gain, so they didn't do it. I think you could do it in less, but that's the condition which prevails. You still save 64k, which would seem useful. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) GE Corp R&D Center, Information Systems Operation, tech support group Moderator comp.binaries.ibm.pc and 386-users digest.
jaaps@dbf.kun.nl (Jaap Shane) (06/26/91)
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: > I think you are confusing high memory with upper memory. High memory >starts at FFFF:0000 and goes up, on both [23]86. UMA is between C000 and >F000 (or maybe B000 is the manager is smart enough to sneak under the >VGA). So on a 286 you get 64k for the DOS, but not the memory space for >the UMA. > Since the 286 doesn't have the right hardware to do UMA, it would have >to be faked in software. The software would take about as much space as >it saved. No gain, so they didn't do it. I think you could do it in >less, but that's the condition which prevails. You still save 64k, which >would seem useful. Most modern 286's with C&T or other chipsets actually do have the hardware for upper memory access. Since there is no standard on this, you cannot make a generic driver for it, as you can with a 386. However there does exist a shareware package which provides access to the upper memory on many 286's with C&T or other chipsets. It's called LASTBYTE and it is available as TLB-V119.ZIP on simtel20 and others. I've been using it for a year with MSDOS 4.01, and since a week with MSDOS 5.0. On my computer, a 20 MHz 286 with 2MB os memory, with LASTBYTE I can use the devicehigh and loadhigh features of MSDOS 5.0 to get up to 685Kb of available conventional memory, by loading MSDOS high, loading all drivers and TSR's high using either LASTBYTE's HIGHDRVR or HIGHTSR programs, and its HIGHAPND program to reclaim the memory from A000 - B000, which my Hercules board doesn't use, for conventional memory. The good part is, it even works for non-MSDOS 5.0 users, although you lose about 40-50 K to MSDOS 4.01 or 30-40 K for MSDOS 3.3 >-- >bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) > GE Corp R&D Center, Information Systems Operation, tech support group > Moderator comp.binaries.ibm.pc and 386-users digest. Jaap Shane ----------------------------+------------------------------------------------ Jaap Shane | Department of Physical Chemistry, Internet : jaaps@sci.kun.nl | Catholic University of Nijmegen Bitnet : U627008@HNYKUN11 | Toernooiveld, 6525ED, Nijmegen, The Netherlands -- ----------------------------+------------------------------------------------ Jaap Shane | Department of Physical Chemistry, Internet : jaaps@sci.kun.nl | Catholic University of Nijmegen Bitnet : U627008@HNYKUN11 | Toernooiveld, 6525ED, Nijmegen, The Netherlands