Programmer 7500

home *** CD-ROM | disk | FTP | other *** search

/ Programmer 7500 / MAX_PROGRAMMERS.iso / PROGRAMS / UTILS / MEMORIA / 3COMEMM.ZIP / 3COMEMM.TXT

Wrap

Text File | 1990-03-15 | 40.9 KB | 736 lines

Using 3ComEMM Effectively ========================= Beginning with the release of 3+Share version 1.3.1, 3Com has provided an 80386 memory management program called 3ComEMM with 3+Share. Current versions of 3+Share and 3+Open are provided with 3ComEMM. Current licensing provides for the use of 3ComEMM on 80386-based 3+Share PC servers and 3+Open 80386-based DOS netstations. 3ComEMM requires an 80386 CPU and therefore will not function on a machine based on an 80286 or 8086/8088 processor. This article provides information on the following five areas: * An overview of the Intel 80x86 processor family and its evolution * A description of 80386 memory management * An overview of 3ComEMM * The use of 3ComEMM on a 3+Share server * The use of 3ComEMM on a 3+Open DOS netstation The Intel 80x86 Processor Family ================================ There are three modes of operation in Intel's 80x86 family of processors: real mode, protected mode, and virtual mode. Each addition to the family included the addition of a new mode. The 8086/8088 started with only one mode, or as it later came to be called with the release of the 80286, real mode. In this mode, the processor can address one megabyte of physical memory. When Microsoft wrote MS-DOS, they dedicated the first 640 KB of this to user memory, known as conventional memory, and the top 384 KB from 640 KB - 1 MB as system memory for ROMs, address space for adapter cards, etc. Hence the '640 KB barrier' of DOS. With the protected mode introduced with the 80286, the processor can address up to 16 MB of physical memory. Memory above one MB is called extended memory, not to be confused with expanded memory covered later. Unfortunately, programs written in real mode cannot run in protected mode or access extended memory. Therefore, most programs just use the 80286 as a fast 8086 and run in real mode with the same 1 MB limitation of the 8086 processor. Although OS/2 is designed for the protected mode of the 80286, it is a very new operating system and DOS is still the dominant operating system used on IBM and compatible PCs today. Something is needed, therefore, to work around the 640 KB barrier with the additions of networks and larger application programs to today's office environment. Programs such as VDISK and disk caches can use extended memory, but the use of extended memory is very limited and can reduce system performance. The original solution to the 640 KB barrier was the Lotus/Intel/Microsoft (LIM) Expanded Memory Specification (EMS) version 3.2. This is a hardware implementation of memory bank switching where a 64 KB page frame is placed in 'high memory' between 640 KB and 1 MB, and EMS memory is swapped in and out of that area from the EMS board. The driver that manages this is called an Expanded Memory Manager (EMM), and one of 3ComEMM's primary functions is to act as an EMM to provide EMS. The original EMS 3.2 specification was used strictly for data storage with programs such as Lotus 1-2-3. The specification was then enhanced into the AST/Quadram/Quarterdeck Enhanced Expanded Memory Specification (EEMS) to allow storage of program code for multitasking. The EEMS specification was then enhanced and expanded into the current LIM EMS 4.0 specification. Both new specifications require additional hardware support above and beyond that required with EMS 3.2. The 4.0 specification no longer uses bank switching but uses hardware registers to point the 64 KB page frame to a location on the EMS board, much the same way 3ComEMM accomplishes this through emulation. With the release of the 80386, Intel added a new mode called virtual mode while still supporting the previous real and protected modes. The result is a new level of functionality for memory management although the 80386 remains completely binary-compatible with the earlier members of the 80x86 family in real and protected modes. Intel recently released a new member of the 80x86 family, the 80486, officially called the i486. This chip combines the functions of the 80386, 80387, and 82385 processors and 8 KB of cache memory, but remains completely compatible with the 80386 and earlier processors. The 80486, in fact, provides no new operating modes as with earlier processors, but adds the functionality of the math coprocessor and cache controller and streamlines many instructions for faster operation. Because operation of the 80486 is no different from the 80386, the term 80386 is used throughout this article. All discussion, however, applies equally well to either processor. 80386 Memory Management ======================= The virtual mode adds memory management capabilities to the system that allow 3ComEMM to provide two major capabilities to the operation of 3Com software. For 3+Share, 3ComEMM converts extended memory to expanded memory. This is used by TurboShare on PC Servers for CIOSYS buffers. 3ComEMM also allows certain services to be loaded into the unused area between 640 KB and 1 MB. For 3+Open, 3ComEMM can use the unused area between 640 KB and 1 MB to allow network software to be moved from user memory to high memory and therefore reduce the RAM required for the network software on 3+Open DOS netstations. The method the 386 uses to manage memory, called paging, makes these two functions, among others, possible. The 80386 keeps two internal tables, called descriptor tables, to keep track of memory. In real mode, these tables are not used, and therefore, the capabilities of the 80386 are not being fully utilized. In virtual mode, however, paging is enabled, and the use of descriptor tables becomes vital. The descriptor tables provide mapping between logical addresses and actual physical addresses. In virtual mode the logical table points to the actual physical address at which the memory resides. DOS always goes to the logical table to find memory. If the 386 has been told by a 386 control program such as 3ComEMM, however, that a logical address actually points to a different physical address, the 386 automatically provides the memory at that location, and DOS is totally oblivious to the fact. This capability allows an 80386 memory manager such as 3ComEMM make use of the unused memory between 640 KB and 1 MB. Those unused areas, however, contain no physical memory whatsoever. The memory manager makes the logical table for locations C600-DFFF, for example, point to actual physical addresses above the 1 MB mark in extended memory. Then when DOS goes to access a program that is loaded into that area, it thinks it is actually accessing address C600. The 80386 transparently translates the addresses to those in extended memory by table lookup to find where the code actually resides. The same capability allows an 80386 memory manager to convert the extended (or 80286) memory to expanded (or paged) memory. This provides the same 64 KB page frame as hardware implementations do, typically at address E000. Instead of that 64 KB actually being physical memory at that location, the memory manager uses the descriptor tables and points that 64 KB to a location in extended memory. When a call is made to the EMM driver, which in this case is a software and not a hardware driver, instead of using hardware registers to point to memory on an EMS board, the manager changes the pointers in the logical descriptor table to point to a new address in extended memory. Therefore no physical memory is moved; only pointers are changed. An Overview of 3ComEMM ====================== 3ComEMM is an 80386 memory manager that can perform the above two functions, among others. It is licensed only for use and will only operate on 3+Share servers with 3+Share versions 1.3.1 and 1.5 and on 3+Open DOS netstations. If you want similar capabilities on other platforms, Qualitas, Inc. of Bethesda, Maryland offers software with similar functionality for use on almost any 80386 based personal computer. There are many files provided with 3ComEMM. There are two pairs of programs that make up the major part of 3ComEMM, and there are some miscellaneous drivers provided to fix certain problems with different hardware configurations. In most cases, these drivers will not be used, but they are documented here for the sake of clarity. The base programs, 3COMEMM.SYS and 3COMEMM.COM, are used both for 3+Share servers and 3+Open DOS netstations. 3COMEMM.SYS is the 386 control program containing all of the functionality of 3ComEMM. 3COMEMM.COM is an executable program used to load services into high memory for 3+Share and get status from the control program for both environments. The other major pair of programs is 3COMLOAD.SYS and 3COMLOAD.COM. These programs allow you to load 3+Open DOS netstation drivers into the memory between 640 KB and 1 MB. They are provided for and will only function with 3+Open DOS netstations. Distributed with 3+Open are README files and specific hardware drivers that are required in some situations. If you need them for a 3+Share server, contact 3Com Technical Support. On IBM PS/2s and newer Compaq 386 systems, there resides a 1 KB block of ROM at 639 KB. This prevents proper EMS mapping and low memory backfilling. The XBIOS.SYS driver is used to move this 1 KB of ROM to low memory to allow proper mapping and backfilling. The Ultimate EGA Adapter also puts a 1 KB ROM at the top of conventional memory. The ULTIMATE.SYS driver moves this ROM to a more acceptable location. The OMTI 8620 hard drive controller needs a ROM moved as well. The driver OMTIFIX.SYS does this. 3ComEMM manages all the memory in your system. No other memory managers may be present in your system when 3ComEMM is used. This includes other 80386 control programs and EMM drivers for actual EMS boards. If you have an EMS board in your system, reconfigure it for extended instead of expanded memory. 3ComEMM needs to manage extended memory and true expanded memory goes unused. When the device driver loads, you can have 3ComEMM do many things such as convert all, some, or no extended memory to expanded, have it cache the ROMs into RAM, automatically backfill DOS memory on monochrome or CGA systems, manually backfill DOS memory on EGA/VGA systems, recover unused memory on many systems, and leave specific areas of memory alone. You must consider several factors when 3ComEMM is used on either a 3+Share PC server or a 3+Open DOS netstation. For example, all ESDI and many RLL hard drive controllers have an extra ROM that is placed in high memory between 640 KB and 1 MB that 3ComEMM often cannot recognize. If you do not tell 3ComEMM that the ROM there it will interfere with the operation of 3ComEMM. Not all controllers, however, use the same address space. So it is up to the person installing the system to determine the address that the ROM will use. Many controller manufacturers document this in the controller's manual, and if the information is not there, you must contact the manufacturer. Once the address range is determined, 3ComEMM must be set up to recognize it. The way to do this is to use the RAM= parameter of 3COMEMM.SYS. If, for example, the address of the ROM is C800-CBFF, the statement in CONFIG.SYS would look like: DEVICE=3COMEMM.SYS RAM=C800-CBFF The RAM= parameter means that there is something at that address, whether a ROM as in this case or actual RAM as described below, that 3ComEMM should leave entirely alone. SCSI is an alternative to ESDI and is becoming quite popular. 3ComEMM is incompatible with many SCSI drives because either the SCSI controller's ROMs or device drivers cannot operate in virtual mode. The SCSI controller manufacturer must provide a ROM or device driver update if this is the case. If you have a SCSI adapter that works with 3ComEMM in virtual mode, the information on ESDI ROMs will apply because SCSI drives will have a similar additional ROM as well. The same principle applies to other boards that use areas of high memory, for example, the 3Com EtherLink II Ethernet adapter. If set for shared memory mode, this board uses a 16 KB block of memory at one of four areas of high memory. If the EtherLink II is set to use address DC00 by jumper, CONFIG.SYS looks like this: DEVICE=3COMEMM.SYS RAM=DC00-DFFF If you are having problems getting 3ComEMM to operate, a good way to determine if there is something in high memory that conflicts with 3ComEMM is to use the NOHIGH parameter in CONFIG.SYS. This tells 3ComEMM not to use high memory at all, and other 3Com software will not be loaded high. If this works, it is a good indication that there is a conflict in high memory. 3ComEMM can also recover some or all of the missing 384 KB of the first megabyte of memory on many systems. On most 1 MB systems, the manufacturer will only give you access to 640 KB and reserve the other 384 KB whether it is used or not. Many systems use some of this memory, but 3ComEMM can almost always do this more efficiently and give you more memory for other uses. To make use of this functionality, you must allow 3ComEMM to remap ROMs into RAM. ROM caching is enabled by default and disabled by NOROM. Therefore, if the installation program puts the parameter NOROM on the 3COMEMM.SYS command line you must remove it. 3ComEMM automatically recognizes many of the systems it can recover memory from. These include AST, AT&T, Compaq, Hewlett Packard, and IBM. On other systems a parameter is needed in CONFIG.SYS. There are generally two methods manufacturers use to place the memory. The first type of system uses the TOP384 parameter in CONFIG.SYS. In this method, the 384 KB is put at the top of physical memory, at the top of 16 MB. In these systems, including those based on the Micronics system board, 3ComEMM can recover all 384 KB. The other method maps the 384 into the physical address at 640 KB to 1 MB. In this case use the SHADOWRAM parameter in CONFIG.SYS. Since physical RAM addresses cannot overlap, only some of the 384 KB on these systems is recoverable; the actual amount depends on the individual system. Systems that use this method are those based on the Chips and Technology chip set including NEC, Samsung, and Tandy. The best way to determine if your system is one that 3ComEMM can recover memory on is to try each of the two parameters individually. To then see if shadow RAM was recovered, execute the 3COMEMM.COM program. After the amount of 'Total extended memory', will be a statement of shadow RAM recovered. The following is sample output from the 3COMEMM.COM when either no parameter or the LIST parameter is used. Notice that when shadow RAM is recovered, it is shown toward the bottom of the output. Other helpful information displayed includes what areas of ROM are being remapped, the total amount of extended and expanded memory, the amount of added low DOS memory, and the total and available amounts of high DOS memory. To find out specifically what regions of high DOS memory are being used and are free, use the 3COMEMM MAPMEM command described in the section on 3+Open DOS netstations. 3COMEMM -- Version 4.05 -- A Memory Manager for 386 Systems (C) Copyright 1987-9 Qualitas, Inc. All rights reserved. ╒═ 3Com DOS Maximizer/386 ═══ Version 4.05 ═════════ Memory Usage ═╕ │┌───────────── The First Megabyte of Address Space ──────────────┐│ ││████████████████████████████████████████≈≈≈≈▒▒≈≈■■▒▒▒▒▒▒░░░░■■■■││ │└┼─Conventional memory───────────────────┼EGA┼H┼E┼┼High──┼EMS┼ROM┘│ │ │ │ New top of DOS memory = 640 KB █ DOS ≈ Video │ │ Added low DOS memory = 0 KB ▓ Low ■ ROM │ │ Added high DOS memory = 136 KB ▒ High │ │ Available extended memory = 68 KB Φ Other # Unused│ │ Available expanded memory = 5072 KB in segment E000 ░ EMS │ ╘══════════════════════════════════════════════════════════════════╛ Extended memory usage... ROM mapping region = 88 KB, C000-C600, F000-10000 Program storage = 140 KB EMS memory = 5072 KB Remaining ext memory = 68 KB High DOS memory = 136 KB, B000-B800, C600-E000 Low DOS memory = 0 KB Total extended memory = 5504 KB, shadow RAM recovered = 384 KB Total expanded memory = 5648 KB, in use = 592 KB, available = 5056 KB ══> Loading programs in LOW memory... ══> 56 KB available in HIGH memory, largest block is 42 KB. The current state is ON. 3ComEMM with 3+Share PC Servers =============================== 3ComEMM allows 80386 based PC servers to use TurboShare to put CIOSYS buffers into expanded memory without a dedicated expanded memory board. It also lets you take certain services, depending on available high memory, out of low DOS memory and move them into high DOS memory, therefore conserving valuable low DOS RAM. The area from the top of DOS memory at A000 (640 KB) to C000 is reserved for video memory. Not all of this address space is used at all times, however, and can, in many instances, be recovered by 3ComEMM and added to low DOS memory, thereby increasing the amount of low DOS memory above 640 KB. CGA systems only use the video area at B800-C000, and 3ComEMM can, therefore, recover the most amount of memory. On CGA systems, 96 KB is recovered from A000-B7FF giving you 736 KB of DOS memory. Running CHKDSK will show 736 KB of total memory. Monochrome systems use memory at B000- B800, and the memory at A000-B000 can be recovered giving DOS 704 KB. This happens automatically if you have either of these types of video. EGA and VGA systems are slightly different, however. They use the same text area as CGA at B800-C000. They also reserve the area at A000-B000 for high resolution graphics, leaving B000-B800 unused. Unfortunately, this does not allow 3ComEMM to backfill DOS memory because DOS memory must be contiguous. Since graphics will obviously not be used on a server, the area at A000-B800 can be recovered as with a CGA system. The VIDMEM= parameter in CONFIG.SYS controls backfilling low DOS memory below video memory. With this parameter, you tell 3ComEMM what range of memory to reserve as video memory and allow 3ComEMM to backfill below it. On an EGA/VGA system, use the parameter VIDMEM=B800-C000. This tells 3ComEMM to reserve only the CGA area as video memory. 3ComEMM then recovers the 96 KB from A000-B800 for a total of 736 KB of DOS memory. 3ComEMM's USE= parameter (which would normally be used with 3+Open DOS netstations) is very similar to VIDMEM=, but does not allow backfilling of low DOS memory. If you were to use the parameter USE=A000-B7FF instead of VIDMEM=B800-C000 in the previous example, 3ComEMM would designate the area at A000-B7FF as high memory instead of adding it to low DOS memory. The next RAM recovery method is to allow certain services to load into the high DOS memory that 3ComEMM provides. The key is to configure your system to give you the largest contiguous block of memory available between the end of video memory and the beginning of the system ROM. There are no specific system configurations here because of the wide variety of available configurations; instead, general guidelines and standard locations are described. The one exception will be the IBM PS/2 Model 80 because it requires a very specific configuration. The layout of most systems is as follows: 0000-9FFFH Conventional memory (0-640K) A000-AFFFH EGA/VGA graphics area B000-B7FFH Monochrome video B800-BFFFH CGA Text/low res. graphics C000-EFFFH Dependent on system F000-FFFFH System ROM The unused area between C000-EFFF is used as high DOS memory. There is 192 KB between C000 and F000, but, unfortunately, there are things that reside in this area that decrease the amount of high DOS memory that 3ComEMM can provide. The first is the EMS page frame. As stated earlier, to use EMS memory you must have a 64 KB page frame located between 640 KB and 1 MB. 3ComEMM, therefore, allocates 64 KB of memory for this purpose. If there is not enough contiguous memory to provide 64 KB for a page frame, 3ComEMM will allocate the page frame in conventional memory, therefore decreasing the 640 KB (or more, depending on video) available. It is generally put at E000-EFFF, decreasing available high memory to 128 KB. If the system has a monochrome video adapter, there will be no additional video ROM. If, however, you are using any other type of video board, there will be an additional video ROM residing at C000. This usually extends to C600 or C800, and high resolution boards can require even more. A high resolution video board should not be wasted in a file server anyway, so, for the purpose of this article the assumption is that the video ROM extends from C000-C600. Note that this is dependent on the brand of video board used. This takes 24 KB more away from high memory, leaving 104 KB in this example. Many high performance file servers use a large, fast hard drive. This means, most likely, an ESDI drive. As stated above ESDI drives have an additional ROM that is put into high memory. Many controllers let you choose from two or more locations for this ROM while some offer no choices. Since, to be useful, high DOS memory must be contiguous, it is extremely important where this ROM will be placed if there is a choice of locations. If the ROM is put in the middle of this memory, it splits the memory into two small regions that are unusable to load services into. It is therefore important to put the ROM as close to the top or bottom of this area of C600 to DFFF (in this example) as possible. If, for example, the controller gives you a choice of putting the ROM at C800 or CC00, it would be a much better choice to select C800. If you select CC00, there will be a small block of memory between C600 and CC00, and another above the ROM. Selecting the C800 address, however, leaves a larger block of memory above the ROM. If the ROM is 16 KB, then, the ROM resides at C800-CC00, leaving the area between CC00 and DFFF free for use as high DOS memory. This leaves 80 KB of high memory. The programs that can be loaded high are CIOSYS and Locator, so the 80 KB might be enough for CIOSYS, but certainly not both, and possibly not even for CIOSYS, depending on how it is configured. Without an ESDI drive, you might have as much as 104-128 KB available. The shared memory mode of the EtherLink II will also use memory in this area and therefore decrease available high DOS memory. The indicator that tells 3PLUS_ON.BAT to attempt to load these services high are files located in the directory C:\3PLUS\3CONFIG\SWITCHES. In this directory there will be CIOSYS.HI for CIOSYS and LOCATOR.HI for the Locator. If both services cannot fit into high memory, you can rename one or both of these files and 3PLUS_ON.BAT will not attempt to load the appropriate service(s) into high memory. A typical error message that occurs as CIOSYS is loading is 'No room for buffers'. This generally occurs if you either overuse high DOS memory or have an unidentified ROM or RAM area. If this message appears, determine if high DOS memory is being overused. If you are not overusing high memory, there is probably something in high memory that is not being identified. The addresses and numbers discussed above are only examples, and will not necessarily be accurate for your system. Since very specific information is required the specific configuration for the IBM PS/2 Model 80 is included below. The IBM PS/2 Model 80 as a PC Server ------------------------------------ The IBM PS/2s do not have 64 KB of ROM as previous systems have had; instead they have 128 KB of ROM. The video ROM is also contained in this area instead of at C000 like other systems. In addition, every board you have in the machine including the hard drive controller will use an area of high memory. This takes away enough memory that there is not enough address area available for 3ComEMM to provide high DOS memory. You must, therefore, choose another configuration. The Model 80 will be configured to give 736 KB low DOS memory and no high memory. CONFIG.SYS should be configured as follows: DEVICE=XBIOS.SYS DEVICE=PRO.SYS DEVICE=BUF.SYS DEVICE=3COMEMM.SYS VIDMEM=B800-C000 NOHIGH FRAME=C000 DEVICE=ETH523.SYS or TOKIBM.SYS etc. This uses XBIOS.SYS to move the 1 KB of ROM the device driver area of memory and therefore allows the VIDMEM= parameter to provide 96 KB of contiguous low DOS memory yielding 736 KB. The FRAME=C000 parameter puts the EMS page frame at location C000. When configuring boards using the Reference disk, the best configuration is as follows: 3Com EtherLink/MC IBM TokenRing ----------------- ------------- RAM address=D800 ROM=D400 or above ESDI ROM=D000 or above RAM=D800 or above ESDI ROM=D000 or above This leaves the area at C000-D000 for use as the EMS page frame. 3ComEMM with 3+Open DOS Netstations =================================== 3ComEMM supports many industry standard specifications that can be important on 3+Open DOS netstations. Of course 3ComEMM supports both the EMS 3.2 and 4.0 specifications, but it also supports two specifications that are important for application memory usage: the Microsoft Extended Memory Specification (XMS) and the Quarterdeck-PharLap Virtual Control Program Interface (VCPI). The XMS specification allows 80286 and 80386 computers with at least 64 KB of extended memory to provide 64 KB of that memory to real mode applications. This functionality is provided by Microsoft in their HIMEM.SYS driver. 3ComEMM fully supports the specification, so the HIMEM.SYS driver is not required. You will find that, by default, 3ComEMM leaves at least 64 KB extended memory available to support this specification. Applications must be specifically written to take advantage of this and move up to 64 KB of their code into this XMS area. The Enhanced DOS Redirector that ships with 3+Open 1.1 and later takes advantage of this specification. Run HIMEM.SYS on 286 computers, 3COMEMM.SYS on 386 computers, and leave at least 64 KB extended memory free. Change the HIMEM=NO parameter in LANMAN.INI to HIMEM=YES to allow the Enhanced Redirector to load part of its code into extended memory. To receive XMS support from 3ComEMM you need version 2.67 or later. Version 2.67 ships with 3+Open 1.0, and version 4.05 ships with 3+Open version 1.1. Only one protected or virtual mode program can run at a time. This would prevent you from using certain applications with 3ComEMM installed. The VCPI specification was designed to overcome this limitation and allow certain protected and virtual mode programs to co-exist. VCPI allows you to use programs that use DOS extenders to run in protected mode such as Paradox/386, IBM's Interleaf Publisher, and Lotus 1-2-3 Release 3 without interfering with 3ComEMM. To provide VCPI support, you need version 4.05 or later of 3ComEMM. Using the general installation instructions above for installing 3COMEMM.SYS, place 3COMEMM.SYS in your CONFIG.SYS. By default, 3ComEMM will convert all extended memory except 64 KB to expanded memory. You can control this amount in two ways. You can specify the EMS=nnnn parameter to tell 3ComEMM to convert nnnnK of extended memory to expanded. Conversely, you can specify EXT=nnnn to tell 3ComEMM to leave nnnnK as extended memory. These two parameters have basically the same effect, but accomplish it in opposite fashion. You can also specify EMS=0 or EXT=0 to tell 3ComEMM to make no EMS available or leave no extended memory, respectively. You may notice that if you specify EXT=0 you may have a small amount of extended memory left or if you specify neither of these options you may have slightly more than 64 KB extended memory available. This is because expanded memory can only be allocated in 16 KB blocks. If there is any memory left after converting extended to expanded in 16 KB blocks, the remainder must be left as extended. 3ComEMM will, of course, automatically recognize a CGA or monochrome system and backfill conventional memory automatically. You may prevent this by specifying NOLOW on the 3COMEMM.SYS line. This prevents 3ComEMM from adding the memory between 640 KB and the bottom of video memory to low DOS memory; instead, it is converted to high DOS memory. To prevent the backfilling from occurring at all, you can use the parameter VIDMEM=A000- C000 to tell 3ComEMM to leave the video area alone. You may also use the method described in the 3+Share server section of this article to backfill low memory on EGA or VGA systems. This prevents the use of EGA or VGA graphics, however, and 3Com does not recommend this if you plan to use graphics applications. If you are using 3ComEMM on an EGA or VGA system with no secondary monochrome monitor, the 32 KB area at address B000-B7FF is typically unused. You may use the parameter USE=B000-B7FF to reclaim this area as high memory for use by 3ComLoad. 3ComLoad has five parameters that you will need to make good use of high memory. They are GETSIZE, SIZE=, PROG=, SUMMARY, and PRGREG=. These parameters apply to both 3COMLOAD.SYS in CONFIG.SYS for loading device drivers and 3COMLOAD.COM in AUTOEXEC.BAT for loading TSRs. The usage of the 3ComLoad program in both device driver and executable forms is identical. The only difference is in how you invoke each one. To load device drivers high, use DEVICE=3COMLOAD.SYS [parameters] in your CONFIG.SYS, and to load TSRs high, specify 3COMLOAD [parameters] in your AUTOEXEC.BAT. For simplicity, the form 3COMLOAD [parameters] is used in the following examples. Keep in mind, however, that this applies equally well to the device driver. The first time you want to load a piece of network software high, you must let 3ComLoad determine its size so that it may fit it into high memory. To do this, use the following: 3COMLOAD GETSIZE PROG=program [program parameters] It is VERY important to specify the same parameters after the program or device driver name just as you would if you were not using 3ComLoad. If you do not do so, 3ComLoad cannot make an accurate determination of memory usage. When you use the GETSIZE= parameter, 3ComLoad loads the program specified into low memory and watches it run to determine its size. It then stops and tells you if you have to use the SIZE= parameter when you load it and, if so, what SIZE= must be. 3ComLoad obtains three values when you use GETSIZE, and from these it determines if you will need to use SIZE=. These are the load, initialize, and resident sizes. The load size is how much memory the program takes to actually load from the disk into memory, the initialize size is how much memory the program uses as it is initializing, and, of course, the resident size is how much memory the program uses when it finishes initializing, issues its remain resident request, and terminates. The larger of these three numbers is the amount of memory 3ComLoad must reserve to be able to handle whatever program you are trying to load high. The following ratio determines if you will need to specify SIZE=, and if it is followed by the program you are attempting to load, no SIZE= parameter is needed: Load size >= Initialize size >= Resident size There must be enough memory available in high memory to perform all three of the above operations (load, initialize, and make resident), and 3ComLoad can only determine if there is enough room in two ways. First, by the SIZE= parameter and, if there is no SIZE= parameter, secondly, by the load size. If you do not specify SIZE=, the load size is less than available high memory, and either the initialize or resident sizes are greater than available high memory, the computer will most likely crash. Give the preceding load command for all network drivers and programs you wish to load high. The computer pauses after each and tells you if SIZE= is required. It is not necessary to write the required SIZE= parameters down at this time, however, because you can use the SUMMARY command by typing 3COMLOAD SUMMARY and the program will give you the following summary: 3COMLOAD -- Version 3.00 -- A Program Loader for 3COMEMM (C) Copyright 1988-9 Qualitas, Inc. All rights reserved. ╒═════════════════════════════════════════════════════════════════════════════╕ │ RESIDENT PROGRAM MEMORY USAGE │ ├──────────────┬─────────────────────────────┬────────────────────────────────┤ │ │ Size Parameters │ │ │ Device or ├─────────┬─────────┬─────────┤ │ │ Program Name │ Load │ Initial │ Resident│ Suggested Action │ ├──────────────┼─────────┼─────────┼─────────┼────────────────────────────────┤ │ ANSI.SYS │ 3,008 │ 3,516 │ 2,544 │ You *MUST* use SIZE=3516 │ │ Dev=ELNKII$ │ 10,016 │ 10,016 │ 8,464 │ No SIZE= parameter needed │ │ Dev=MINDSIDP │ 7,744 │ 7,740 │ 3,296 │ No SIZE= parameter needed │ │ XNSTP.EXE │ 49,664 │ 49,920 │ 63,456 │ You *MUST* use SIZE=63456 │ │ PRTSC.EXE │ 672 │ 920 │ 752 │ You *MUST* use SIZE=920 │ ╘══════════════╧═════════╧═════════╧═════════╧════════════════════════════════╛ In the illustration above, the programs ANSI.SYS, XNSTP.EXE, and PRTSC.EXE require SIZE= because either their initialize or resident sizes are greater than their load size. ELNKII.DOS and XNSTP.DOS's initialize and resident sizes are equal to or less than the load size, so no SIZE= is needed. To complete the example, here are the lines as they would appear exactly in CONFIG.SYS: DEVICE=3COMLOAD.SYS SIZE=3516 PROG=C:\DOS\ANSI.SYS DEVICE=3COMLOAD.SYS PROG=3OPEN\DOSWKSTA\LANMAN\DRIVERS\ELNKII.DOS DEVICE=3COMLOAD.SYS PROG=3OPEN\DOSWKSTA\LANMAN\DRIVERS\XNSTP.DOS and AUTOEXEC.BAT: 3COMLOAD SIZE=63456 PROG=XNSTP 3COMLOAD SIZE=920 PROG=PRTSC These are, of course, only examples, and you should not use these numbers on your system. Rather, use the ones generated by GETSIZE. Use the last 3ComLoad parameter, PRGREG=, to gain the maximum efficiency when loading programs high. It is quite possible to get two or more non- contiguous areas of free high memory. Programs, when loaded, of course need to be contiguous. So what you can attempt to do to gain the most efficient loading, although it will take some time, is use the PRGREG= parameter of 3ComLoad and the MAPMEM parameter of 3COMEMM.COM to squeeze programs into memory. If, for example, you have a 32 KB block of high memory, which would be quite possible on EGA/VGA systems using the monochrome area at B000-B7FF as high memory, and a large 96 KB block at C800-DFFF, the top of many video ROMs to the bottom of the typical EMS page frame, you could use PRGREG= to tell a program exactly where to load. PRGREG stands for program region. If you have two blocks of high memory as in the above example, you have two program regions. B000-B7FF is PRGREG=1, and C800-DFFF is PRGREG=2. If, for some reason, you have three or more areas, the lowest address would be one, the next highest would be two, and so forth. 3ComLoad, without the PRGREG= parameter, always puts the program it's loading into the first available region it fits into. If, for example, you have the ESDI or other ROM as described in the third section of this article that existed at C800-CBFF and your video ROM ended at C600, you would have an 8 KB hole between the video ROM and the ESDI ROM. Instead of wasting space putting the small ANSI.SYS and PRTSC.EXE from above into one of the large areas, you could specify PRGREG=2 to put them in that small area, ie.: DRIVER=3COMLOAD.SYS PRGREG=2 SIZE=3516 PROG=C:\DOS\ANSI.SYS . . and leave the large areas open for larger programs. The way to find out what areas of memory you have free is to execute the 3COMEMM.COM program with the MAPMEM parameter. This gives you a detailed memory map and allows you to view what regions are available. For example: 3COMEMM -- Version 4.05 -- A Memory Manager for 386 Systems (C) Copyright 1987-9 Qualitas, Inc. All rights reserved. ╒═════════════════════════════════════════════════════════════════════════════╕ │ MEMORY MAP for RESIDENT PROGRAMS │ ├──────────────┬──────┬──────┬──────┬─────────┬───────────────────────────────┤ │ │ Hex │ Hex │ Hex │ Decimal │ │ │ Name │ Start│ End │ Owner│ Length │ Text or Interrupt Numbers │ ├──────────────┼──────┼──────┼──────┼─────────┼───────────────────────────────┤ │ DOS & drvrs │ 09F9 │ 0C57 │ │ 9,680 │ 02 0A 0C 0D 0E 20 70 72 73 74 │ │ │ │ │ │ │ 76 77 │ │ COMMAND.COM │ 0C57 │ 0D2B │ 0C58 │ 3,376 │ 22 23 24 2E │ │ │ 0D2B │ 0D2F │ -Avl-│ 48 │ │ │ COMMAND.COM │ 0D2F │ 0D50 │ 0C58 │ 512 │COMSPEC=C:\DOS\COMMAND.COM│PATH│ │ │ 0D50 │ 0D5F │ -Cur-│ 224 │ │ │ │ 0D5F │ 0D60 │ -Avl-│ 0 │ │ │ │ 0D60 │ 178A │ 0D61 │ 41,616 │ 5C F4 │ │ │ 178A │ 1893 │ -Avl-│ 4,224 │ │ │ │ 1893 │ 1E0C │ 1894 │ 22,400 │ 05 08 17 2F │ │ │ 1E0C │ A000 │ -Cur-│ 532,272 │ │ ╞═High DOS Mem═╪══════╪══════╪══════╪═════════╪═══════════════════════════════╡ │ Dev=EMMXXXX0 │ B000 │ B0D7 │ B001 │ 3,424 │ 15 19 27 40 67 │ │ Dev=3COMEMM$ │ │ │ │ │ │ │ Dev=ELNKII$ │ B0D7 │ B2E9 │ B0D8 │ 8,464 │ 1C │ │ Dev=MINDSIDP │ B2E9 │ B3B8 │ B2EA │ 3,296 │ 0B 2A │ │ Dev=MINDSPRO │ │ │ │ │ │ │ Dev=MINDSBUF │ │ │ │ │ │ │ Dev=MINDSLGL │ │ │ │ │ │ │ Dev=MINDSSPP │ │ │ │ │ │ │ Dev=MINDSCOU │ │ │ │ │ │ │ Dev=MINDSETH │ │ │ │ │ │ │ PRTSC.EXE │ B3B8 │ B3E8 │ B3B9 │ 752 │ 09 28 │ │ │ B3E8 │ B488 │ B3E9 │ 2,544 │ 16 21 29 │ │ │ B488 │ B7E7 │ -Avl-│ 13,792 │ │ │ │ B7E7 │ B7EB │ B3E9 │ 48 │ │ │ PRTSC.EXE │ B7EB │ B7FF │ B3B9 │ 304 │COMSPEC=C:\DOS\COMMAND.COM│PROM│ ╞═ RAM or ROM ═╡ B7FF │ C600 │ 0A3E │ 57,344 │ 10 1F 43 │ │ │ C600 │ D57F │ C601 │ 63,456 │ │ │ │ D57F │ DFFC │ -Avl-│ 42,944 │ │ │ │ DFFC │ E000 │ C601 │ 48 │ │ ╘══════════════╧══════╧══════╧══════╧═════════╧═══════════════════════════════╛ The above memory map shows that in low DOS memory, there are 532,272 bytes free. This is the same number that appears if CHKDSK is executed. It also shows that there are two regions in high memory, one from B000-B7FF, and one from C600-E000. It also shows that there are 13,792 bytes free in the first region and 42,944 bytes free in the second region. Each program loaded has its start and end addresses listed, along with any environment space it uses. Unfortunately, 3ComEMM cannot ascertain the name of every program that is loaded high. You can tell by the size, however. The program that is 63,456 bytes in the second region of the above example is the XNSTP.EXE from the previous example. The size next to each program corresponds to the resident size when you execute 3COMLOAD SUMMARY. It is VERY important to note the following: If you choose the protocol XNS with LPO in Netsetup, you must NOT use 3ComLoad to load the two drivers placed into CONFIG.SYS, PSH.SYS and PTH.SYS, into high memory. They will not execute properly from high DOS memory. You must also NOT use 3ComLoad to load PROTMAN.DOS into high memory, because it also will not function from high memory.