Inter-Office MemorandumToFileDateOctober 20, 1978FromRoy Levin, Chuck Geschke, Jim MitchellLocationPalo AltoSubjectMesa for Extended Memory AltosOrganizationCSL(version 3)XEROX Filed on: [Ivy]Doc>XMesa.bravoA version of the Mesa system that exploits in certain ways the extended memory features of AltoIIs is now available. This document describes the facilities provided by this system, its limitations,and its compatibility with other current Mesa systems.The system described in this document is functionally compatible with Mesa 4.1, except as explicitlynoted below. However, we have no plans to maintain compatiblity with future releases of the Mesasystem.Overview of XMesaXMesa uses the extended memory of an Alto II XM as additional swapping space for code. Thismeans that code and data need not co-exist in the primary 64K of memory. XMesa takesadvantage of any available extra space automatically; standard Alto programs do not need to bemodified to run with XMesa. XMesa does not simplify the task of managing data structures thatare too large to fit in 64K, but it does free (most of) the 64K primary address space for use by data. Because XMesa uses extra memory for code segments, it includes a page-level storage allocator forthe additional banks. Client programs may request storage in the additional banks by using thisallocator; the interface is public. XMesa provides a primitive mechanism to permit blocks of datato be copied between banks of memory, but gives no other assistance in accessing information inthe extended memory banks.Clients should understand that, while XMesa is interface-compatible with Mesa 4.1, the implementation of certain systemcomponents (e.g., the page-level memory allocator and segment swapper) has changed substantially. Client programs thatassume undocumented properties of these components do so at their peril. Information about incompatibilities in theimplementation appears later in this document.Compatibility with Mesa 4.1Considerable efforts have been made to ensure that XMesa is compatible with Mesa 4.1.Exceptions are minor and typically affect only those programs that depend upon the format ofglobal frames (details appear below). To enhance the value of compatibility and because wide-bodied Altos are relatively scarce, XMesa will execute properly (though with some performancedegradation) on a normal Alto (I or II) without recompilation or rebinding. Indeed, XMesarequires no special compiler or binder. Both BCDs and image files are compatible across machines.Thus a Mesa disk containing the XMesa versions of RunMesa.run, XMesa.image (orBasicXMesa.image and XImageMaker.bcd), and the debugger can be used without alterationon any Alto, XM or otherwise. Specifically,Н]Оg║pТ·НІОc8qН]rН-єqН7BrТ└НІО]ЭqН]rП&Н-єqН7BrНІОYqН]rН-єqН7BrН]ОW│ НЭОSЛsrНЇОN"qТiП%НЇОG╗rТ═П:Т║П%НЇОFТ√ПVТ≈НЇОDXТП6НЇОA tТ╒П(ТёП<НЇО?aТєТ╔ПCНЇО=╧НЇО9√uТНЇО6GrТ⌡ Т°ПRНЇО4÷ТФПOТГНЇО2ВТЄП5Т╣П)НЇО1OТ═Т║ПOНЇО/їТ─Т│ПRТНЇО,XТ≈П(Т≤П9НЇО*╟Т╛ПLТґНЇО)Т⌡ПIТ°НЇО'`ТїПCТ╗НЇО%╦ТНЇО"▄vТ▀П%Т▄ПRНЇО!+Т┤ПbТ┬НЇОйТ║Т╒ПVНЇОiТП.НЇО>tНЇООrТПFТНЇОGТцП)ТдП3НЇО÷Т╪ПLТҐНЇОВТбП)ТцП4НЇОOТчП#ТъП7НЇОїТ┤ПXТ┬ НЇО ЪТ/П%Т0w rw rНЇОWwrТ⌡wrТ°НЇО ╞ТП,Ъ хЭ h>Г^ +Mesa for Extended Memory Altos21)Mesa 4.1 BCDs will load and execute under XMesa,2)Mesa 4.1 image files will run correctly under XMesa,3)Image files created with XMesa will run (under XMesa) on any Alto,4)Files created with Mesa 4.1 and XMesa may be debugged (under XMesa) on any Alto.Of course, these properties can be guaranteed only for programs that do not assume the existence ofextended memory.Note! Compatibility is assured only for Mesa 4.1. BCDs compiled or bound by previous releases ofthe Mesa system, including Mesa 4.0, will NOT work properly under XMesa.The Public Interface to XMesaTo preserve compatibility with Mesa 4.1, XMesa provides its services exclusively through a newinterface, XMESADEFS. However, the facilities supplied logically belong in other existing interfaces,notably SEGMENTDEFS and ALTODEFS. Thus, XMESADEFS actually includes several semi-independent interfaces. Unless otherwise stated, everything defined in this section comes fromXMESADEFS.Extended Memory ManagementSegments in extended memory are created with the usual primitives in SEGMENTDEFS. However,XMesa recognizes additional "default" parameter values for those procedures that expect a VM basepage number. DefaultBase0, DefaultBase1, DefaultBase2, and DefaultBase3 requestallocation in a specific memory bank. DefaultXMBase requests allocation anywhere in theextended memory banks (banks 1-3). DefaultBase (defined in SEGMENTDEFS) requests allocationanywhere in memory (banks 0-3) if the segment is a code segment, otherwise, it is equivalent toDefaultBase0.The following procedures logically belong in SEGMENTDEFS. They convert between segmenthandles and long pointers, and work for segments anywhere in the 18-bit address space.XVMtoSegment: PROCEDURE [a: LONG POINTER] RETURNS [SegmentHandle];XSegmentAddress: PROCEDURE [seg: SegmentHandle] RETURNS [LONG POINTER];XVMtoDataSegment: PROCEDURE [a: LONG POINTER] RETURNS [DataSegmentHandle];XDataSegmentAddress: PROCEDURE [seg: DataSegmentHandle]RETURNS [LONG POINTER];XVMtoFileSegment: PROCEDURE [a: LONG POINTER] RETURNS [FileSegmentHandle];XFileSegmentAddress: PROCEDURE [seg: FileSegmentHandle]RETURNS [LONG POINTER];The following definitions logically belong in ALTODEFS. They define parameters of the extendedmemory system.ЪНЇОfПuТНGОНюОbrНЮП0НюО`0НЮП4НюО^BНЮПBНюО\TНЮТєП<Т╔НЇОYТ┌П`Т┐НЇОW]ТНЇОTtТ√ПAТ≈П!НЇОRfТПHНЇОNCuНЇОJТrТ╩П^НЇОILТ≈ v rПQНЇОGєТ9v rТ:v rvrНЇОEЭТлТмПHНЇОDTvrН ▌О?^tТ÷НЇО<rТіТїП&v r НЇО:gТ┌П:Т┐П'НЇО8©ТоТпxyxyxyrxrНЇО7ТЮТАxyrП#НЇО5oТ█П#Т▌x rv rНЇО3гТЇtТ╦rНЇО2xrНЇО.пТПП)ТЯv rНЇО-(ТПVН О)ыxyxТ└yxyxyxyТjxТ└yxyxyН О&┼xyxyxyxyx yxyxyТjН О#;xyxТ└yxyxyxyТjxТ└yxyxyН ОЛxyxyxyxyxyНЮОDxyТjН ОУxyxТ└yxyxyxyТjxТ└yxyxyН ОіxyxyxyxyxyНЮОЧxyТjНЇО╞rТ╙П.vr Т╚НЇОТ ЪПЇю=ГWJaMesa for Extended Memory Altos3BankIndex: TYPE = [0..3];PagesPerBank: PageCount = . . . ;MaxXPage: PageNumber = 1777B;-- analogous to MaxVMPageThe following signal logically belongs in IMAGEDEFS, and is raised when MakeImage discovers asegment in banks 1-3 that cannot be swapped out. (See the section on restrictions, below, for moreinformation about image files). If this signal is RESUMEd, MakeImage assumes that the segment inquestion has been removed from high memory by the client; failure to do so may result in animage file that cannot be restarted.ImmovableSegmentInHighBank: SIGNAL [SegmentDefs.FileSegmentHandle];Long Pointer SupportThe following (machine code) procedures return the high and low halves of a long pointer.HighHalfPtr: PROCEDURE [LONG POINTER] RETURNS [CARDINAL] ;LowHalfPtr: PROCEDURE [LONG POINTER] RETURNS [POINTER] ;XCOPY is analogous to COPY in INLINEDEFS, but accepts long pointers instead of pointers andmoves data across memory bank boundaries. However, not all possible pairs of pointers arepermitted. XCOPY raises InvalidXCOPY if the long pointers specify transmission between bankstobank and frombank such that tobank = frombank and tobank, frombank = 0. (In other words,XCOPY can only handle one bank other than bank 0 at a time.) XCOPY raisesXMNotAvailable if the pointers are legal but the requested extended memory bank does notexist. (Note: XCOPY is a machine code procedure.)XCOPY: PROCEDURE[from, to: LONG POINTER, nwords: CARDINAL] ;InvalidXCOPY: ERROR;XMNotAvailable: ERROR;The implementation of XMesa prohibits client programs from manipulating the emulator bankregister directly (see section on restrictions, below). Clients wishing to perform a BitBlt across bankboundaries must therefore use the XBitBlt procedure, which verifies that the requested extendedmemory bank is available (raising XMNotAvailable if it isn't), then loads the emulator's alternatebank register with bank and performs a BitBlt.XBitBlt: PROCEDURE[bbt: BitBltDefs.BBptr, bank: XMesaDefs.BankIndex];The following procedures convert between page numbers and long pointers, and are analogous toAddressFromPage and PageFromAddress in SEGMENTDEFS. Illegal parameters are detectedand cause the indicated signals to be raised.LongAddressFromPage: PROCEDURE[page: AltoDefs.PageNumber]RETURNS[lp: LONG POINTER];НЇОfПuТНGОН ОbxyxТ└yxyxyxyН О`vxyx yxyТjН О^нxyxТ└yxyН5АtТ÷НЇО[rТ╠Т╡vrП*НЇОYвТ┼Т▀ПJНЇОX/Т▒Т▓vxryrП(НЇОV┤Т╩П9Т╪П"НЇОTъТП$Н ОQ░xyxТ└yxyxyН#┴ОL tТ÷НЇОIKrТЙТКПCН ОEЭx yТjП/Н ОBґx yП.НЇО?^xrТ╔xrv rТіП&НЇО=ІТщП)ТчП1НЇО<Т┤ Т┬xrxrП8НЇО:furТ╔ur urzrurururzrurТіНЇО8ЎxrТ/П$Т0xrНЇО7x rТдТеП0НЇО5nТxrН О2xТ└y xyxyТjxyН О.пxyН О+│x yНЇО(2rТрП5ТсП$НЇО&┼Т┴ПHТ┼НЇО$БТ╗П!Т╘xrП6НЇО#:Т░П!Т▒x rП2НЇО!▓ТxrН ОCxyТjxyxТ└yxyxyНЇОТrТіП-ТїП0НЇОLxrТ░xrТ▒v rП"НЇОєТП-Н ОUxyТjxТ└yНЮОґxyТj Їf=ГUєaMesa for Extended Memory Altos4InvalidXMPage: ERROR [page: AltoDefs.PageNumber];PageFromLongAddress: PROCEDURE[lp: LONG POINTER]RETURNS[page: AltoDefs.PageNumber];InvalidLongPointer: ERROR [lp: LONG POINTER];Configuration InformationXMesa has an internal data structure containing information about the hardware configuration ofthe Alto on which it is running. Clients may obtain a copy of this data structure by writingmemoryConfig: MemoryConfig _ GetMemoryConfig[];and should normally test for the existence of extended memory by examiningmemoryConfig.useXM. The extant banks of memory are indicated by memoryConfig.banks,which is a bit mask (e.g. memoryConfig.banks =14B => banks 0 and 1 exist).MachineType: TYPE = {unknown, AltoI, AltoII, AltoIIXM, D0, Dorado};MemoryConfig: TYPE = MACHINE DEPENDENT RECORD[reserved: [0..37B],AltoType: MachineType,useXM: BOOLEAN,unused: [0..3],secondROM: BOOLEAN,banks: [0..17B],mesaMicrocodeVersion: [0..377B],XMMicrocodeVersion: [0..377B]];GetMemoryConfig: PROCEDURE RETURNS[MemoryConfig];useXM is true if and only if the following conditions hold:1)the machine is an Alto II with XM modifications (AltoType = AltoIIXM),2)the Alto has more than one memory bank installed (banks ~= 10B),3)the Alto has a second ROM (secondROM is true), and4)the second ROM contains the current version of the XMesa microcode.The microcode version fields tell only the microcode version, not the Mesa release number. (Forexample, for Mesa 4.1, mesaMicrocodeVersion is 34.) XMMicrocodeVersion will be non-zero if and only if XMesa microcode is installed in the second ROM.If AltoType is unknown, all other fields of the record are unreliable. This can happen only if XMesais initialized by an obsolete version of RunMesa.НЇОfПuТНGОН ОbxyТjxyxТ└yН О^оxyТjxyНЮО]'xyxТ└yН ОYьxyТjxyН"?ОTБtТ÷НЇОQ⌠rТґП$ТўП;НЇОOКТйП)ТкП4Н ОL°xyТjxТ└yxyНЇОIMrТцТдП2НЇОG╔xuxrТ┌П/xuxrНЇОEЩТtrxuxyxrН ОBўx yТj xyxТ└yxyxyxyxyН О?_xyТjП"НЮО=ЇxyxyНЮО<xyx yНЮО:gxy НЮО8©xyxyНЮО7xy НЮО5oxyxyНЮО3гxyxyНЮО2xyxyН О.пxyxyНЇО+│xrТП6Н О(2НЮП1xryrxrН О&┼НЮП2xryrxrН О$БНЮxr Н О#:НЮПCНЇОКТїП+tr trТ╗НЇОCТ╔xrТіxrНЇО⌡ТПCНЇОLТ▀xrxrП0vТ▄НЇОєТП1рЇ]=ГPґ.Mesa for Extended Memory Altos5How to Obtain and Use XMesaThe files for XMesa reside on [Ivy]. The subdirectory structure parallels that used on[Iris], but only those files that supersede Mesa 4.1 are stored on . The files on are organized as follows:RunMesa.runXMesa.image, .symbols, and .signalsBasicXMesa.image,. symbols, and .signalsXMesa.cm, BasicXMesa.cm, and MakeXMDebug.cmmiscellaneous command filesSystem>XImageMaker.bcd and .symbolssystem definitions and program modules (.mesa and .bcd)source and object code for RunMesa and microcode (mostly in .dm files)miscellaneous command filesDoc>documentation for XMesaXDebug>modules to be installed in the Mesa 4.1 debugger (.mesa and .bcd)RunMesa.run is required by all XMesa programs and will also run Mesa 4.1 programs withoutalteration. Failure to use the XMesa version of RunMesa will cause XMesa programs to behave inunpredictable ways.The microcode that must be installed in the second control ROM is stored inSystem>XMesaROM.mb. This file is in suitable form for use by the PROM blaster.XMesa.cm and BasicXMesa.cm retrieve the corresponding image files, the debugger, and relatedsupporting files. MakeXMDebug.cm installs the debugger, including the modules required fordebugging the XMesa environment. (XMesa.cm and BasicXMesa.cm implicitly executeMakeXMDebug.cm as well.)Restrictions, Limitations, and "Features"Images and Checkpoints. MakeImage cannot preserve the contents of extended memory in theimage file it constructs. If MakeImage is invoked on an Alto II XM, it will swap out all unlockedfile segements in extended memory. (It will also move any locked code segments to primarymemory.) If any segments then remain in extended memory, MakeImage will refuse to build theimage file. Analogous comments apply to CheckPoint.Bank Registers. XMesa assumes it has exclusive control of the emulator bank register. Clientprograms must not attempt to alter the bank register, but rather must use the public interfaces formoving data to and from extended memory (see XCOPY and XBitBlt, above).Global Frame Format. The format of global frames and segment objects has changed slightly,although (for compatibility) CONTROLDEFS and SEGMENTDEFS have not been recompiled. Theformats assumed by XMesa appear in GLOBALFRAMEDEFS and XMESAPRIVATEDEFS, respectively.The only change likely to affect client programs is the removal of the code segment handle from theНЇОfПuТНGОНЇОbНЇО^оrТіПGТїНЇО]'Т┬П"Т┴П=НЇО[ТП!Н ЮОX0Н═ОV┬w Н═ОTЮ rwrwН═ОS8rwrwН═ОQ░rw rwН═ОOХrН ЮОL≥ Н═ОJЯwrwН═ОIIrП(wrwrН═ОG║ПГ].Mesa for Extended Memory Altos6third word of a global frame. Programs that previously assumed this pointer's presence in theframe should now import CODEDEFS and replaceframe.codesegmentbyCodeDefs.CodeHandle[frame] .Segment Alignment. Segments may not cross bank boundaries.Resident Code. The amount of resident code in XMesa is 6 pages greater than in Mesa 4.1.Accordingly, XMesa may exhibit poorer swapping performance on non-XM Altos than Mesa 4.1does.Old Mesa System Modules. Any Mesa BCD for which an XMesa version exists must not be usedunder XMesa. No check for inappropriate BCDs is made and unpredictable results may occur.BasicXMesa users: if you make image files, be certain to obtain XImageMaker.bcd.Debugger Incompatibilities. The Mesa 4.1 version of XDebug cannot be used with XMesa unlessthe module XMDebug.bcd is loaded when the debugger is installed. In addition, the debugger'sCoreMap command does not work at all under XMesa. The UserProc XCoreMap should beinstalled in the debugger and used instead. The command file MakeXMDebug.cm will install thedebugger properly for use with XMesa.Microcode ROMs. RunMesa determines whether the microcode contained in the Alto's secondcontrol ROM (if any) is suitable to run XMesa, and will set memoryConfig.useXM accordingly.(See the section entitled Configuration Information, above.) However, old versions of RunMesa(before 29.16.3) do not contain the necessary safety checks, and will cause XMesa to executeincorrectly on a machine that contains improper microcode (useXM will erroneously be TRUE).This will cause unpredictable results. XMesa clients should ensure that they have an up-to-dateversion of RunMesa.run. In particular, if XMesa is loaded by RunMesa 29.16.3, it can execute successfully on anAlto II XM with standard Mesa 4.1 microcode in the second ROM, but it cannot take advantage of the additionalmemory banks. If XMesa is loaded by an older version of RunMesa on such a machine, it will behave unpredictably.Microcode in the RAM. The microcode to support XMesa occupies slightly more than 1K ofcontrol memory space. Most of it resides in the second 1K of control ROM (ROM1), with theexcess overflowing into the RAM. The remaining RAM space is available to users who wish towrite their own microcode, but certain conventions must be observed. Those who need to executespecial microcode from Mesa programs should consult [Ivy]Doc>Microcode.press (and.bravo).Swapper Algorithms. The XMesa swapper loads a segment into extended memory by first swappingit into primary memory, then copying it to extended memory and releasing the primary memoryspace. Thus, if primary memory 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 otherbanks. (Analogous comments apply when swapping out segments that must be written to disk.)Distribution:CSLMesa GroupНЇОfПuТНGОНЇОbrТцП^НЇО`vТvrН О^AxНЇО\rН ОYвxyxyrНЇОV┬trП)НЇОS9tТп rТяП3НЇОQ▒ТЄТ╣ПFНЇОOИНЇОL tТ⌡rТ°П<НЇОJРТ╩ПGТ╪НЇОIJТПAwrНЇОEШtТіrП*ТїНЇОDSТє w r Т╔П=НЇОB╚ТсП1Ттwr НЇОAТ·Т÷П!w rНЇО?[ТП%НЇО<tТхrПBТиНЇО:dТ▐П7Т░xrНЇО8╪ТҐtrТЎНЇО7ТшП-ТэП/НЇО5lТаП;xrТбyrНЇО3дТЄП<Т╣П$НЇО2Т│ w rvП8Т┌НЇО0≈Т╠П!Т╡ПLНЇО/Т⌠ПqНЇО+дtТмrП<ТнНЇО*Т╠ПIТ╡НЇО(tТ╞ПXТ╟НЇО&лТ√П2Т≈П-НЇО%$ТўТ╞ПGНЇО#|vНЇО -tТ┘rП(Т├П"НЇО┘Т╚П$Т╛П7НЇОщТлПEТмНЇО5x rТ╞Т╟П;НЇО█Т╣П3ТІП(НІООН хОGН хО÷Т└ └ІX>ГX╡> TIMESROMAN HELVETICA TIMESROMAN LOGO TIMESROMAN TIMESROMAN TIMESROMANGACHA HELVETICA HELVETICA MATH у÷÷рр#б+ЪЪj/.,▓W{═ЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪxmesa.bravoLevinOctober 20, 1978 10:53 AM