LIM Expanded Memory Specification V4: Appendix C

From Lo-tech Wiki
Revision as of 22:11, 11 February 2014 by Lo-tech>James (Initial content (source: http://www.phatcode.net/res/218/files/limems40.txt))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

EXPANDED MEMORY MANAGER IMPLEMENTATION GUIDELINES

In addition to the functional specification, the expanded memory manager should provide certain resources. The following guidelines are provided so required resources are present in expanded memory managers which comply with this version of the LIM specification.

  • The amount of expanded memory supported:
    • Up to a maximum of 32M bytes of expanded memory should be supported.
  • The number of handles supported:
    • The maximum number expanded memory handles provided should be 255, the minimum should be 64.
  • Handle Numbering:
    • Although a handle is a word quantity, there is a maximum of 255 handles, including the operating system handle. This specification defines the handle word as follows: the low byte of the word is the actual handle value, the high byte of the handle is set to 00 by the memory manager. Previous versions of this specification did not specify the value of handles.
  • New handle type: Handles versus Raw Handles:
    • The difference between a raw handle and a regular handle is slight. If you use Function 27 to "Allocate raw pages to a handle", what is returned in DX is termed a raw handle. The raw handle does not necessarily refer to 16 Kbyte pages. Instead it refers to the "raw" page size, which depends on the expanded memory hardware.
    • An application program can use Function 26 to find the raw page size, and by using the raw handle Function 27 returns, it can access them with the finer resolution that a particular expanded memory board may allow.
    • On the other hand, applications which use Function 4 to "allocate pages to handle" receive a handle which always refers to 16K-byte pages. On expanded memory boards with smaller raw pages, the EMM driver will allocate and maintain the number of raw pages it takes to create a single composite 16K-byte page. The difference between the expanded memory boards raw page size and the 16K-byte LIM page size is transparent to the application when it is using a handle obtained with Function 4.
    • The memory manager must differentiate between pages allocated to handles and pages allocated to raw handles. The meaning of a call to the driver changes depending on whether a handle or a raw handle is passed to the memory manager. If, for example, a handle is passed to Function 18 (Reallocate), the memory manager will
    • increase or decrease the number of 16K-byte pages allocated to the handle. If Function 18 is passed a raw handle, the memory manager will increase or decrease the number of raw (non-16K-byte) pages allocated to the raw handle. For LIM standard boards, there is no difference between pages and raw pages.
  • The system Raw Handle (Raw Handle = 0000):
    • For expanded memory boards that can remap the memory in the lower 640K-byte address space, managing the pages of memory which are used to fill in the lower 640K can be a problem. To solve this problem, the memory manager will create a raw handle with a value of 0000 when DOS loads the manager. This raw handle is called the system handle.
    • At power up, the memory manager will allocate all of the pages that are mapped into the lower 640K bytes to the system handle. These pages should be mapped in their logical order. For example, if the system board supplies 256K bytes of RAM, and the 384K bytes above it is mappable, the system handle should have its logical page zero mapped into the first physical page at 256K, its logical page one mapped into the next physical page, and so on.
    • The system handle should deal with raw pages. To release some of these pages so application programs can use them, an operating system could decrease the number of pages allocated to the system handle with the "Reallocate" function. Invoking the "Deallocate" function would decrease the system handle to zero size, but it must not deallocate the raw handle itself. The "Deallocate" function treats the system handle differently than it treats other raw handles. If the operating system can ever be "exited" (for example, the way Windows can be exited), it must increase the size of the system handle back to what is needed to fill 640K and map these logical pages back into physical memory before returning to DOS.
    • There are two functional special cases for this handle:
      • The first special case deals with Function 4 (Allocate Pages). This function must never return zero as a handle value. Applications must always invoke Function 4 to allocate pages and obtain a handle which identifies its pages. Since Function 4 will never return a handle value of zero, an application will never gain access to this special handle.
      • The second special case deals with Function 6 (Deallocate Pages). If the operating system uses Function 6 to deallocate the pages which are allocated to the system handle, the pages will be returned to the manager for use, but the handle will not be available for reassignment. The manager should treat a "deallocate pages" function request for this handle the same as a "reallocate pages" function request, where the number of pages to reallocate to this handle is zero.
  • Terminate and Stay Resident (TSR) Program Cooperation In order for TSR's to cooperate with each other and with other applications, TSR's must follow this rule: a program may only remap the DOS partition it lives in.
    • This rule applies at all times, even when no expanded memory is present.
  • Accelerator Cards: To support generic accelerator cards, the support of Function 34, as defined by AST, is encouraged.

LIM Expanded Memory Specification V4 Contents

See Also