Heading:qjk40(635)
Mesa 6.0 XMesa Updatey756qjk40\b21B
Page Numbers: Yes  X: 527  Y: 10.5"qjk40
Copyright c Xerox Corporation 1979, 1980z18592l4445y45c\10f3 1f0
Inter-Office Memorandumz18592l4445y762\f5b
To	Mesa Users	Date	October 27, 1980z18592l4445d2998e21(0,65535)(1,4445)(5,11684)(6,14146)\f7 2f0t2 1t0 10t6 1f7t0 4f0t7 1t0
From	Jim Sandman, John Wick	Location	Palo Altoz18592l4445d2998y716e25\f7 4f0t2 1t0 22t6 1f7t0 8f0t7 1t0
Subject	Mesa 6.0 XMesa Update	Organization	SDD/SS/Mesa
z18592l4445d2998e25\f7 7f0t2 1t0b21t6B1f7t0 12f0t7 1t0
XEROX       z18592l508y644e14(2116)\f2 5f0
Filed on: [Iris]<Mesa>Doc>XMesa60.bravo (and .press)e30(0,16265)(1,65535)(5,65535)(6,65535)\f7 52f1
x2e12(2116)
This memo describes the changes in Mesa 6.0 runtime support which incorporate the facilities of XMesa 5.0 into the standard system.x2e12jk40(1799)
Overview of Extended Memory Supportx2e18jk80\b35B
Mesa now uses the extended memory of Alto II XMs as additional swapping space for code.  This means that code and data need not co-exist in the MDS, the primary 64K of memory.  Mesa takes advantage of any available extra space automatically; standard Alto programs do not need to be modified to run.  Support is provided for up to one million words of memory in blocks of 64K words. x2e12jk40
Because Mesa uses extended memory for code segments, it includes a page-level storage allocator for the additional banks.  Client programs may request storage in the additional banks by using extensions of the standard procedures in SegmentDefs.  Mesa provides primitive mechanisms to read and write words in extended memory and to copy blocks of data between banks of memory, but gives no other assistance in accessing information in the extended memory.  In particular, arbitrary use of LONG POINTERs is not supported on the Alto.x2e12jk40\233f6b11f0B245f7b12f0B5i3I
Public Interfacesx2e18jk80\b17B
Unless otherwise stated, all of the facilities in this section are defined in SegmentDefs.x2e12jk40\78f6b11f0B1i
Configuration Informationx2e18k80\i
The Mesa runtime system has an internal data structure that contains information about the hardware configuration of the machine on which it is running.  Clients may obtain a copy of this data structure by calling GetMemoryConfig and should normally test for the existence of extended memory by examining the useXM field.  The extant banks of memory are indicated by MemoryConfig.banks, which is a bit mask (e.g., MemoryConfig.banks=140000B implies that banks zero and one exist).  Note that this bit mask has been expanded to allow for up to sixteen banks; constants used to test against it must be changed.x2e12jk40\214f6b15f0B80f6b5f0B53f6b12f0 1f6 5f0B23i5I1f6b12f0 1f6 5f7 1f6 7f0B118i49I
BankIndex: TYPE = [0..17B];l3872x2e12k80\f6b9f7 6f6 5f7 2f6
ControlStoreType: TYPE = {Ram0, RamandRom, Ram3k, unknown};l3872x2e12k80\f6b16f7 6f6
MachineType: TYPE = {unknown0, AltoI, AltoII, AltoIIXM, . . . };l3872x2e12k80\f6b11f7 6f6 12f7 1f6 6f7 1f6 7f7 1f6
MemoryConfig: TYPE = MACHINE DEPENDENT RECORD [
  reserved: [0..37B],
  AltoType: MachineType,
  xmMicroCode: BOOLEAN,
  useXM: BOOLEAN,
  mdsBank: BankIndex,
  controlStore: ControlStoreType,
  banks: [0..177777B],
  mesaMicrocodeVersion: [0..177777B]];l3872x2e12k80\f6b12f7 6f6 3f7 24f6 65f7 7f6 11f7 7f6
memConfig: PUBILC READONLY MemoryConfig;l3872x2e12k80\f6b9f7 18f6 12f7 1f6
GetMemoryConfig: PROCEDURE RETURNS [MemoryConfig] = INLINE
  BEGIN RETURN[memConfig] END;l3872x2e12k80\f6b15f7 19f6 18f7 7f6 2f7 12f6 11f7 5f6
The field memConfig.useXM is true if and only if the following conditions hold:x2e12jk40\10f6b15f0B
1)	the machine is an Alto II with XM modifications (AltoType = AltoIIXM),l4576d3872x2e12jk40(0,4576)\52f6b8f0B1f7b1f0B1f6b8f0B
2)	the Alto has more than one memory bank installed (banks ~= 100000B),l4576d3872x2jk40\53f6b5f0B1f7b2f0B1f6b7f0B
3)	the Alto has a 3K RAM, or it has a second ROM containing an appropriate version of the XMesa microcode.l4576d3872x2jk40
The microcode version field tells only the microcode version, not the Mesa release number.  (For example, for Mesa 6.0, mesaMicrocodeVersion is 41; Mesa 5.0 version 39 microcode is also supported, although not all features are available.)x2e12jk40(1799)\43i9I10i3I55f6b20f0B
Extended Memory Managementx2e18k80\i
The facilities described in this section can be used regardless of the state of useXM.x2e12jk40\80f6b5f0B
Segments in extended memory are created with the usual primitives in SegmentDefs.  However, additional "default" parameter values for those procedures that expect a VM base page number have been provided.  DefaultMDSBase requests allocation anywhere in the MDS.  DefaultXMBase requests allocation anywhere in the extended memory banks but not in the MDS.  DefaultBase0, DefaultBase1, DefaultBase2 and DefaultBase3 request allocation in particular banks.  DefaultANYBase requests allocation anywhere in the extended memory banks or the MDS.  DefaultBase is equivalent to DefaultANYBase if the segment is a code segment, otherwise, it is equivalent to DefaultMDSBase.x2e12jk40\69f6b11f0B126f6b14f7 1f0B42f6b13f7 1f0B79f6b12f0B2f6b12f0B2f6b12f0B5f6b12f0B42f6b14f7 1f0B71f6b11f0B18f6b14f0B1i32I33f6b14f0B
The following procedures convert between segment handles and long pointers, and work for segments anywhere in the 20-bit address space.x2e12jk40
LongVMtoSegment: PROCEDURE [a: LONG POINTER] RETURNS [SegmentHandle];l5088d3872x2e12k80\f6b15f7 1f6 1f7 9f6 3f7 1f6 1f7 12f6 2f7 7f6 16f7 1f6
LongSegmentAddress: PROCEDURE [seg: SegmentHandle] RETURNS [LONG POINTER];l5088d3872x2e12k80\f6b18f7 1f6 1f7 9f6 5f7 1f6 16f7 7f6 2f7 12f6 1f7 1f6
LongVMtoDataSegment: PROCEDURE [a: LONG POINTER] RETURNS [DataSegmentHandle];l5088d3872x2e12k80\f6b19f7 1f6 1f7 9f6 3f7 1f6 1f7 12f6 2f7 7f6 20f7 1f6
LongDataSegmentAddress: PROCEDURE [seg: DataSegmentHandle]
RETURNS [LONG POINTER];l5088d3872x2e12k80\f6b22f7 1f6 1f7 9f6 5f7 1f6 20f7 7f6 2f7 12f6 1f7 1f6
LongVMtoFileSegment: PROCEDURE [a: LONG POINTER] RETURNS [FileSegmentHandle];l5088d3872x2e12k80\f6b19f7 1f6 1f7 9f6 3f7 1f6 1f7 12f6 2f7 7f6 20f7 1f6
LongFileSegmentAddress: PROCEDURE [seg: FileSegmentHandle]
RETURNS [LONG POINTER];l5088d3872x2e12k80\f6b22f7 1f6 1f7 9f6 5f7 1f6 20f7 7f6 2f7 12f6 1f7 1f6
The following definitions have been added to AltoDefs; they define parameters of the extended memory system.x2e12jk40\45f6b8f0B
MaxVMPage: CARDINAL = 7777B;
MaxMDSPage: CARDINAL = 377B;
PagesPerMDS: CARDINAL = MaxMDSPage+1;l3872x2e12k80\f6b9f7 1f6 1f7 8f6 1f7 1f6 6f7 1f6 11f7 1f6 1f7 8f6 1f7 1f6 5f7 1f6 12f7 1f6 1f7 8f6 1f7 1f6 13f7 1f6
The following procedures convert between page numbers and long pointers, and are analogous to AddressFromPage and PageFromAddress.x2e12jk40\94f6b15f0B5f6b15f0B1f6b
LongAddressFromPage: PROCEDURE [page: AltoDefs.PageNumber]
RETURNS [lp: LONG POINTER];l5088d3872x2e12k80\f6b19f7 11f6 28f7 8f6 4f7 14f6 1f7 1f6
PageFromLongAddress: PROCEDURE [lp: LONG POINTER]
RETURNS [page: AltoDefs.PageNumber];l5088d3872x2e12k80\f6b19f7 11f6 4f7 14f6 1f7 8f6 6f7 1f6 21f7 1f6
The following procedures check the validity of long pointers and page numbers and raise the indicated errors.x2e12jk40\109f6b
ValidateVMPage: PROCEDURE [page: UNSPECIFIED];l5088d3872x2e12k80\f6b14f7 12f6 5f7 1f6 1f7 11f6 1f7 1f6
InvalidVMPage: ERROR [page: UNSPECIFIED];l5088d3872x2e6k80\f6b13f7 8f6 5f7 1f6 1f7 11f6 1f7 1f6
ValidateLongPointer: PROCEDURE [a: LONG UNSPECIFIED];l5088d3872x2e12k80\f6b19f7 12f6 2f7 1f6 1f7 16f6 1f7 1f6
InvalidLongPointer: ERROR [lp: LONG UNSPECIFIED];l5088d3872x2e6k80\f6b18f7 8f6 3f7 18f6 1f7 1f6
The signal ImmovableSegmentInXM is raised when MakeImage (or CheckPoint) discovers a segment in the extended memory banks that cannot be swapped out.  (See the section on restrictions, below, for more information about image files).x2e12jk80\11f6b20f0B16f6b9f0B5f6b10f0B160f1 1f6b
Long Pointer Supportx2e18k80\i
The facilities described in this section should be used only when useXM (see above) is TRUE.x2e12jk40\66f6b5f0B16f7 4f0
XCOPY is no longer implemented; clients should use InlineDefs.LongCOPY.  It may only be called when memConfig.xmMicrocode is TRUE.x2e12jk40\f6b5f0B46f6b19f0B1f6b2f0B27f6b21f0B4f7 4b1f6
LongCOPY: PROCEDURE [from: LONG POINTER, nwords: CARDINAL, to: LONG POINTER];l5088d3872x2e12k80\f6b10f7 9f6 6f7 16f6 6f7 11f6 3f7 14f6 1f7 1f6
LongCOPY makes no attempt to validate the long pointers; if they exceed 20 bits or reference non-existent memory, LongCOPY will produce unpredictable results.x2e12jk40\f6b8f0B106f6b8f0B36f6b
XBitBlt is no longer implemented; the following extension is not supported by XMesa 5.0 ROMs.  The normal AltoIIXM sourcealt and destalt fields of the BitBlt record (BitBltDefs.BBTable) should be used (do not use the long pointer options).  In addition, if the unused word in the BBTable is nonzero, the microcode sets the emulator bank register to that value for the duration of the BitBlt.  In effect, BitBlt can only be used to move data within a single bank or between the MDS (bank zero) and some other bank.x2e12jk40\f6b7f0B108f6b9f0B5f6b7f0B30f6b18f0B18i35I24f6b6f0B13f6b7f0B
Restrictions, Limitations, and "Features"x2e18jk80\b41B
Images and Checkpoints.  MakeImage cannot preserve the contents of extended memory in the image file it constructs.  If MakeImage is invoked when useXM is TRUE, it will swap out all unlocked file segments in extended memory.  (It will also move any locked code segments to the MDS.)  If any segments then remain in extended memory, MakeImage will refuse to build the image file.  Analogous comments apply to CheckPoint.x2e12jk40\i25f6bI9f0B86f6b9f0B17f6b5f0B4f7 4f0 173f6b9f0B67f6b10f0B
Bank Registers.  Mesa assumes it has exclusive control of the emulator bank register on AltoIIXMs.  Client programs must not attempt to alter the bank register, but rather must use the public interfaces for moving data to and from extended memory (see LongCOPY and BitBlt, above).x2e12jk40\i15I237f6b8f0B5f6b6f0B
Segment Alignment.  Segments may not cross bank boundaries.  The first page of each non-MDS bank is reserved for internal allocation tables.x2e12jk40\i18I
Swapper Algorithms.  The swapper loads a segment into extended memory by first swapping it into primary memory, then copying it to extended memory and releasing the MDS memory space.  Thus, if the MDS is so full that the requested segment cannot be swapped in, InsufficientVM will be raised, even though sufficient space for the segment may exist in other banks.  (Analogous comments apply when swapping out segments that must be written to disk.)x2e12jk40\i19I242f6b14f0B
x2e12jk40(2116)
Distribution:
Mesa Users
Mesa Group
SDSupportl3528d2998x2e12j