[_CD8_]<doradosource>MidasInternal.Dm!4>MidasInt1.Bravo

Midas initialization creates a stack (44008 words) and sysZone (64008 words); these sizes are controlled by parameters in Midas.Bcpl. Initialization also creates all temporary files needed by Midas and builds file pointers (FP’s) for these and for all of the command and other files enumerated in Midas.Programs; the FP’s allow the files to be opened quickly, improving response time.

Open files use storage in sysZone consisting of a one page buffer and a disk stream structure; this requires approximately 4508 words per open file. In addition, OS directory management procedures use about 12008 words for buffering sysDir (the system directory) when files are opened for which FP’s are not given. During normal operation of Midas, it is possible for the following files to be open simultaneously:

One command file;
One file on which commands are being written (WrtCmds action);
One output file on which text is being written (OpenOutput action);
Two files during Ld, Dump, or Cmpr actions.

This means that the worst case storage requirement, ignoring fragmentation of sysZone, is about 41008 words; it was experimentally determined that a minimum sysZone size of about 50008 words is needed. Dorado Midas uses a 64008-word sysZone because of the extra storage needs of its simulator (StartLargeOverlay action). It would be possible for the first three of the five files mentioned above to be opened and closed in an unfavorable order such that sysZone becomes fragmented, and if this were to happen a sysZone somewhat larger than 50008 words would be needed, but in practice this has never happened.

OpenFile also consumes considerable stack space, and it has been experimentally determined that a stack size of 44008 words is not much more than the minimum needed by Midas.

Note that Midas Junta’s to levStreams; the OS keyboard module is loaded with the Midas resident, and the OS directory module is loaded as a Midas overlay. If Midas.Programs and Midas.UserPrograms are setup correctly, it is seldom necessary to swap in the directory module because FP’s will exist for the files normally touched by users.

Impossible conditions detected by Midas, that should properly result in a crash of the Midas program, result in the MidasSwat(ErrNo,A1, ..., A5) procedure being called, where ErrNo is the number of a string in the Midas.Errors file. MidasSwat is discussed in the Midas.Bcpl section later.

Other error conditions resulting from hardware malfunctions or user mistakes, result in an error diagnostic being printed by Midas and unwinding of the stack as discussed below.

All Action procedures are called via the ErrorProtect(lvProc,A1,A2,...) procedure. ErrorProtect saves the stack position in AbortLabel and AbortFrame and establishes an errorset to which calls to DisplayError(..), ErrorExit(..), or ErrorAbort(..) come back. In addition, iff either there was no OverlayZone or OverlayZone was empty at the time ErrorProtect was called, it will call KillOverlays() before returning. In other words, the errorset established by ErrorProtect will clean up everything except the display on/off condition before returning.

OverlayFaultProc in MOverlay.Bcpl intercepts calls to not-in-core procedures and ReadOverlay(..) assigns storage for the overlay, reads it from the disk, and fixes up the procedure statics. Unless OverlayZone already exists, ReadOverlay converts all name-value bit buffers into an OverlayZone. For the present Dorado Midas, with 20 lines of name-value buffers, OverlayZone winds up at 20,6428 words, the size limit for overlays.

On Dorado Midas, the hardware simulator required more storage than this, so StartLargeOverlay in MCmd.Bcpl and StartBigOvlWithAddr in MGo.Bcpl were added. These procedures scrounge an additional 51008 words from sysZone and 33008 words from the stack and are available for command overlays that are too large to use StartCmdOverlay and StartWithAddr.

On other Midas implementations, the Load overlay will probably impose the largest storage requirement. When the FP for a file being loaded is unknown, this can result in the Load and Directory overlays being simultaneously in core together with the Load module’s read buffer (presently 34008 words), which uses up nearly all of OverlayZone.

Unless called by ErrorProtect, the non-resident procedure will remain in OverlayZone until KillOverlays() is called. If procedures in different overlays are called, subsequent calls will also use OverlayZone.

Most overlays can’t know whether they are running in OverlayZone or in left-over space between Midas resident and symbol Blocks (in which case no OverlayZone exists). In this situation, only sysZone is available for storage (64008 words). However, not all sysZone space is necessarily available, because of open file buffers discussed in the previous section.

A special exception is made for the Init2, Load, and Test overlays, which must be the first three overlays in the xxLoad.Cm command file. These are never preloaded and will always be in OverlayZone when running. The Init2, Load, and Test overlays are exempted from preloading by code in MInit2.Bcpl.

When KillOverlays() is called, all overlays in OverlayZone are flushed, and, if the display is on, OverlayZone is destroyed and the display rebuilt. If the display is off, KillOverlays() flushes the overlays, but the display is not rebuilt until the display is turned on again.

The ValSize parameter in MAsmCommon.D should be set to the number of 16-bit Alto words required to hold the largest register or memory value, currently 4. ValSize must not be made smaller than 2. TValSize should be set to the number of 16-bit Alto words required to hold the largest testable register or memory value, currently 3. If ValSize or TValSize are changed, the machine-independent part of Midas must be recompiled.

D1Actions.Asm contains a 5-word entry for each permanently-defined Action. This includes both machine-independent and dependent Actions. This file has to be edited appropriately and should be renamed xxActions.Asm (where xx = D1, D0, M68, ...).

You may want to change some of the flags in the action table entries. FormCmdmenuText(..) in MCmd.Bcpl has to be edited if flags controlling the command menu are changed.

You will want to delete the DWatch, MCTimeOut, MIRlhPE, MIRrhPE, and possibly the CheckStoppedGlitches statics and the associated two-word vectors in MData.Asm; you may wish to add some other items to this table (which is the MADDR memory) for your machine or to the MDATA memory.

The machine-independent modules are supposed to manage all interaction between the user and Midas. They handle mouse and keyboard input, symbol table, menu formation, overlay management, etc. Machine-dependent subroutines are called to carry out specific interactions with the hardware.

Generally, machine-dependent procedures implement specific functions required by the machine-independent section; they do not call any complicated procedures in the machine-independent section.

Utility procedures:
ErrorProtect, DummyCall, DummyCall1, MBlock, MoveUp, GetField, PutField, MoveLongField, OddParity, VUsc, SelfRel, Mag, LCycle, DoubleNeg, DoubleAdd

Print stuff on streams:
Wss, Puts, Wns, DWns, DatatoStream, SearchBlocks
WssCSS, PutsCSS, ResetsCSS, WnsCSS, WnsCSSD
WssCS1, PutsCS1, ResetsCS1, WnsCS1, WnsCS1D
NWss, NWss1, PrinV0, PrinV1

D1i0.BcplDefines the InitHardware1() procedure called by Init0(). This should load special Alto microcode (if any) and allocate big blocks of storage that do not have to be saved on the state file. The DoradoMC.Br microcode can be used for implementations that do not need their own special microcode; this contains the bcplruntime microcode which will speed execution (and some other microcode useful only on Dorado but harmless if not used).

D1i1.BcplDefines InitMPInterface() called by Init1() and the zrel statics ScreenHeight and ScreenWidth. ScreenHeight contains 12+the number of lines in the name-value area. InitMPInterface() is only called for Midas/I initialization. It should make calls on NewMPDispBlock to define the name-value areas. It should call SaveStatics(..) for any zrel statics initialized.

D1i2.BcplDefines InitHardware() called by Init2(). InitHardware() should do whatever initialization is necessary to ensure that GetRegData, GetMemData, PutRegData, and PutMemData, discussed below, will deliver accurate values. On the Dorado implementation of Midas, there is also code for determining the serial numbers of machines that are accessible to Midas and for selecting among these with a menu.

D1res.BcplResident code defining FormHWMenu, HWShowAddr, HWAlwaysUpdate, FinishHardware, DetachHardware, and HWEveryTime is discussed below. FormHWMenu builds conditional parts of the command menu. FinishHardware is called before exit from Midas; it should do a silent boot (if special Alto microcode requires this), and do any other cleanup. DetachHardware is called before detaching Midas from one machine and connecting it to another.

D1Go.BcplResident procedures called from MGo.Bcpl, MRGo.Bcpl, and MGoOvl.Bcpl. Defines SetupIMA(..), ContinueProgram(..), Stop(), CheckStopped(), MStopped(..), and OneStep(..). See sample code. On Dorado Midas, CheckStopped(..), ContinueProgram(..), and Stop() are hand-coded and appear in D1Asm.Asm rather than in D1Go.Bcpl.

@MEMNAMMemory names
@MEMWIDMemory widths
@MEMLENDouble precision memory lengths
@MEMFORMSMemory print format vectors for MTexttoData
AltMFormsMemory alternate print routines
AltMInputMemory alternate typein routines
@MEMCONMemory control bits
@NMEMSNumber of memories in the tables

@REGNAMRegister names
@REGWIDRegister widths
@REGFORMSRegister print format vectors for RTexttoData
AltRFormsRegister alternate print routines
AltRInputRegister alternate typein routines
@REGCONRegister control bits
@NREGSNumber of registers in the tables.

The @’s indicate zrel statics. Each memory table is NMEMS words long (except MEMLEN, which is 2*NMEMS long), and each register table NREGS words long. The MEMNAM, REGNAM, MEMFORMS, and REGFORMS tables contain self-relative pointers to the name strings or format vectors. These self-relative pointers are converted to real pointers by Init0(). See D1Tables.Asm file for examples of how these tables are setup. The order of the tables must be preserved faithfully because of the length error checks in MInit0.Bcpl.

The MEMFORMS and REGFORMS tables control printing/typein of values in the name-value displays. If the table entry contains a 0, the value is printed as a single octal number. Otherwise, the table points at a vector interpreted as follows:

word -2:lv Procedure for symbolic display mode (0 if none)
word -1:MemX used in SearchBlocks display mode (-1 if none)
word 0:number of groups for numeric display
word 1:first bit of group 0
word 2:number of bits in group 0
words (3,4), etc. up to (2n,2n+1):more groups

If word 0 is negative, then it counts the number of extensions for the register or memory, each of which contains its own format vector in the above format, and the format table entry points to a structure as follows:

Each of the groups is printed as an octal number followed by a blank. The format vector also controls evaluation of keyboard input for change-value actions. Keyboard input must be divided into groups bearing a one-for-one correspondence to the printout format.

Each group in formatted input or the single group for unformatted input may consist of an octal number, negative octal number, or address/memory name symbol +/- offset. If the input value won’t fit in the register, the left-most bits of input are truncated. When the keyboard input cannot be evaluated in one of these ways, the routine named in the AltMInput or AltRInput table for the memory/register is called. Again, see D1Tables.Asm for examples. If this routine cannot evaluate the input, then it gives an error.

AltMForms and AltRForms contain pointers to procedures that pretty-print values on the comment lines. The pretty-print procedures are called as ErrorProtect(AltMForms!X,X,DVec,AVec,Radix+(Extension lshift 8)), where X is MemX or RegX, AVec is only relevant for memories, and Extension is non-zero only for multi-row items such as ROW on Dorado Midas. They are supposed to pretty-print the data in DVec on CmdCommentStream and/or CmdCS1 (which have already been reset) in some meaningful way.

The MEMCON and REGCON tables contain for each memory/register an assortment of bits that determine how it should be handled by various Actions. The bits are defined in the MRType structure in MCommon.D. Included in the MEMCON/REGCON entry for each register and memory are the default printout mode and default radix that control input/output of values in the name-value menu area. The print out modes in the main display may be defaulted to either numeric, search-blocks, or symbolic.

Octal, decimal, and hexadecimal radices are implemented, with the overall default radix (8, 10, or 16) in the static DefRadix in D1I0.Bcpl overruled by the radix declared for each register and memory in MEMCON/REGCON.

MEMMaskMemory mask DVecs for Test and Test-All actions
MEMAnalyzeMemory lv Procedure for test failure analysis
MEMTSTMemory test conditions: pointers to statics that are true or false or to
procedures that return true if the test is possible or false if impossible
MEMOneMemory DVecs of value 1
REGMaskRegister mask DVecs
REGAnalyzeRegister lv Procedure for failure analysis
REGTSTRegister test conditions
REGOneRegister DVecs of value 1
OtherNAMNames of extra tests
OtherWIDExtra test widths
OtherProcExtra test procedures
OtherPrintProcedures to setup and print what the test is
OtherMaskPointers to data-compare mask vectors
OtherTSTExtra test conditions
OtherOneExtra test DVecs of value 1

The Debug overlay contains all of the pattern generation and data checking procedures used by other overlays during hardware checkout. This overlay is used on Dorado by the Field, LDRtest, Test, and SimTest overlays.

ZEROESall 0’s data
ONESall 1’s data
CYC1left-cycled 1 in DVec of zeroes
CYC0left-cycled 0 in DVec of ones
RANDOMrandom numbers
SEQUENTIALsequential numbers starting at 0
SHOULD-BEconstant pattern equal to value in ShouldBe
ALTZOalternating all-zeroes and all-ones
ALT-SHOULD-BEalternates ShouldBe with its complement

Successive patterns are generated by the NextData() subroutine in MDebugAsm.Asm. CheckData() is used to check the results. SaveDGen() and RestoreDGen() subroutines are used to save the state of the pattern generator and restore it.

The memory tables in xxTables.Asm should define the MDATA and MADDR memories, as in the sources. The Put and Get routines should, for this memory, move data to/from these tables and the DVecs.

DataTest() displays a menu of all testable register and memory names. The MEMTST and REGTST tables determine whether or not a particular memory/register appears in this menu; these tables contain pointers to statics that are 0 (no test), -1 (always testable), or other (procedure that is evaluated to return 0 or -1). For registers PutRegData and GetRegData carry out the test. For memories, PutMemData is used to write consecutively all words in the address range being tested; then the pattern generator is restored and the words are read with GetMemData and checked. MEMMask and REGMask tables contain pointers to DVec’s that mask the data being checked; the DVec’s may be modified by the procedure in MEMTST/REGTST. Errors are reported when (data written xor data read) & BITS-CHECKED & Mask is non-zero.

For Test, the value originally in BITS-CHECKED is masked initially by a vector of ones of size equal to the register/memory width. Then if the RTAllTab/MTallTab entry (in xxTestAsm.Asm) for the register/memory is non-zero, it is a self-relative pointer to a vector of length ValSize in DVec format; this vector is and’ed with BITS-CHECKED.

FieldTest() allows any microinstruction field to be repeatedly executed from the Alto and modified under mouse control for scope loops. Values for all fields except the one selected are taken from the NOP (no-operation) microinstruction. The instruction is repeatedly executed through the hardware interface. When the loop is stopped, the final instruction tested is left in TSTINS.

The PE Scan overlay selectively scans memories for parity errors, allowing various options taken from a subsidiary menu. The memories which contain checkable parity and should appear in this menu are indicated by a bit in the MEMCON table.

The machine-independent code calls the machine-dependent ScanForPE procedure to do the actual scan and provides a ReportPE procedure by which errors are reported.