Page Numbers: Yes X: 527 Y: -.5" First Page: 15
Heading:
D0 Midas ManualEdward R. Fiala3 January 1980
10. Registers and Memories Known to Midas
Table 4: Memories
MemoryWidthLengthNotesComments
(octal)(octal)
IM10010000Control store (virtual).
IMX 44100004,5Control store (absolute).
RM 20 4004,5
T 20 201Primary task-specific temporary register.
TPC 20 201,2Task-specific subroutine return link.
VM 20 2224Main storage (addressed through the MAP)
MAP 20 2144Maps VM to absolute storage.
BP100 4023Breakpoint information used by Midas.
MIM 60 10003Holds microinstructions used by Midas.
MDATAund. 103BITS-CHECKED etc. for testing.
MADDR 40 203LOOP-COUNT etc. for testing.
1.Task-specific register
2.Virtual/absolute stuff applies
3.Fake memory--artifact of stuff in Midas
4.Appears in Test menu.
5.Appears in TestAll menu.
Table 5: Registers
RegisterWidthNotesComments
(octal)
APCTASK 4Next task.
APC142Current task’s subroutine return link or next task’s PC.
CTASK 43Task for which "T 20" and "TPC 20" apply.
CIA142Current instruction address.
CYCLECONTROL10See HW manual.
PAGE 4Current IMX page.
PARITY 41See HW manual.
BOOTREASON101See HW manual.
PCXREG 4See HW manual.
PCFREG 4See HW manual.
DBREG 6See HW manual.
SBREG 6See HW manual.
MNBR20See HW manual.
ALURESULT 4See HW manual.
SALUF10See HW manual.
SSTKP10See HW manual.
STKP10See HW manual.
MEMSYNDROME20See HW manual.
CALLER142Shows contents of APC-1, (address of last subroutine call); cannot infer this from APC in virtual mode.
AATOVA203Translate absolute address to virtual
1.Read-only to Midas.
2.Virtual/absolute stuff applies
3.Fake register--artifact of stuff in Midas
Most registers and memories listed above correspond to ones discussed in the "D0 Hardware Manual". Others are discussed in the sections which follow.
MDATA and MADDR memories contain words used to report or control the activity of the "Test" and "Test-All" actions discussed later. MADDR also contains COMM-ER0, COMM-ER1, COMM-ER2, and BOOT-ERR (error-reporting), which will be discussed later.
The BP and MIM memories are not expected to be of interest to programmers. BP holds the information about breakpoints that is manipulated by the breakpoint actions discussed later. MIM holds microcode overlays that are written into the D0 microstore to operate the hardware.
For approximately all registers and memories that contain 16-bit quantities, Midas will evaluate input of the form "m,,n", storing the value of "m" into bits 0:7 of the word and the value of "n" into bits 8:15.
On D0, the items that accept "m,,n" are RM, T, VM, MAP, and MNBR.
11. The IM Memory and Virtual Addresses
Because the placement transformations performed by MicroD make it difficult to correlate microstore locations with positions in microprogram source files, the Dorado and D0 Midas implementations use a map to transform virtual addresses produced by Micro into absolute microstore locations produced by MicroD.
Two memories, IMX and IM, each show the microstore. IMX is absolutely addressed; IM virtually addressed. When you fire up Midas, IM is "empty"; when you load a microprogram, IM is filled with consecutive instructions from your source file, irrespective of where MicroD decides to place these; the "value" displayed for an IM word includes both the absolute address assigned to it and the microinstruction.
In other words, if your microprogram is 10 words long, the meaningful part of IM is only 10 words long. In this case, if you examine IM addresses greater than 7, the printout will show an absolute address of 7777 and zeroes for the rest of the value.
Midas will not allow you to modify the mapping between virtual and absolute addresses interactively--you can only do this by loading a microprogram.
To facilitate dealing with virtual/absolute correspondences, Midas has a mode switch that controls handling of registers and memories that normally contain microstore addresses. When you fire up Midas, the display is in absolute mode and the "Absolute" action appears in the command menu; when you load a microprogram, the display switches to virtual mode and the "Virtual" action appears in the command menu. Test actions will switch to absolute mode. The current mode always appears in the command menu.
In virtual mode, the display shows the virtual equivalent for the value in any register that normally contains a microstore address. When the value is outside the virtual memory, it prints as 7777. To find the absolute value in this case, you have to switch to absolute mode.
On D0 the registers affected by this are TPC, APC, CIA, and CALLER.
The general idea is that, if you suspect a hardware problem in the control section, you might work in absolute mode, but in all other situations when a program is loaded you will work in virtual mode, and the complications created by scrambled instruction placement will be concealed.
A fake register called AATOVA converts absolute addresses to virtual. For example, copying the value in some RM word into AATOVA will show the virtual equivalent; this is useful when return links are saved in RM words.
The convenient way to use AATOVA is to first right-button the value from an RM word that contains a return link (which puts the value on the input text line); then left-button the value into AATOVA, which will prettyprint the virtual address on the comment lines.
12. Registers and Memories that Contain Microinstructions
The IMX, IM, and MIM memories all contain microinstructions. A middle-button action over the value will print these symbolically on the comment lines.
The value for an IM word is shown as four fields on the display:
148-bit absolute address;
bits 40-438 of microinstruction;
bits 0-178 of microinstruction;
bits 208-378 of microinstruction.
The format of the bits is as shown in the hardware manual. You will note that the RSEL and JA fields are scrambled in this arrangement; each of these has two bits in the main part of the microinstruction and two other bits in the 4-bit extension, and two of the RSEL bits are inverted. This, together with the numerous fields in each microinstruction, makes octal interpretation and modification of microinstructions somewhat tedious, so the symbolic pretty-print and input forms discussed below should generally be used.
IMX and MIM are like IM, but the 148-bit absolute address field is absent from IMX.
The MIM memory is an array in Alto core that contains microinstructions used by Midas when operating the hardware; it should ordinarily be of no interest to users.
Note that the microinstruction pretty-print procedure does not have available all of the information that the microassembler had when you assembled your program, so the printout is not always beautiful. The following are deficiencies you should be aware of:
From the hardware manual, you will remember that the interpretation of some instruction fields depends upon the task executing the instruction, so Midas will disassemble correctly only when it is able to deduce the task that executes the microinstruction.
There are many possible assembler macros that you might use to generate constants to control the shifter; for an instruction that does this, Midas might not choose the form you used in the source file.
When you want to modify a microinstruction, a special form of input is available as follows: The first character on the input text line should be "(" to change the values of several fields in the instruction without clobbering other fields, or "[" to reconstruct the value beginning with a no-op microinstruction. This is followed by a number of clauses of the form "Field←integer" separated by blanks and/or commas. The legal field names are:
RSEL, JA, MEMINST, F2, and JC for all instructions;
RMOD, ALUF, BSEL, F1, LR, and LT for regular instructions only; and
DF2, TYPE, and SRCDEST for memory instructions only.
In addition to "field←value" clauses, Midas interprets the standalone clause RETURN, and branch clauses of the form GOTO[addr], CALL[addr], GOTO[addr,bc], GOTOP[addr], or CALLP[addr]. In these "addr" is interpreted as a virtual IM address in virtual mode or as an absolute IMX address in absolute mode; "bc" is a symbolic branch condition.
The "addr" argument to GOTO, CALL, GOTOP, and CALLP will usually be a simple integer in absolute mode but may be an expression such as FOO+3, where FOO is an IM address, in virtual mode. Midas will give an error if the target for GOTO or CALL is off-page; in the event that an off-page branch is legitimate because the predecessor did a LOADPAGE, then this error check will thwart you--you have to use GOTOP or CALLP, which do not check for off-page, in this situation.
On a conditional GOTO, Midas will check that the target is at an odd location for a "regular" branch condition, or at an even location for an "inverted" branch condition. The branch conditions are as follows:
Regular: ALU#0, CARRY, ALU<0, NOH2BIT8, R<0, RODD, NOATTN, MB, INTPENDING, NOOVF, BPCCHK, SPARE, QW0, and TIMEOUT;
Inverted: ALU=0, NOCARRY, ALU>+0, H2BIT8, R>=0, REVEN, IOATTN, NOMB, NOINTPENDING, OVF, NOBPCCHK, NOSPARE, NOQW0, and NOTIMEOUT.
For parts of the microinstruction other than the control clause, Midas requires you to use the awkward "field←value" form.
13. Task-Specific Registers
Midas treats all task-specific registers (T and TPC) as 20-word memories. In other words, "T 6" is the T-register for task 6.
In addition, a special kludge allows you to display the 21st word (i.e., "T 20" or "TPC 20") and have that be interpreted as the register for the currently selected task. The currently selected task is the value in CTASK; CTASK is initialized to the task which broke at breakpoints.
In other words, when a microprogram halts at a breakpoint or because of a mouse-abort, CTASK becomes the word number for the "T 20" and "TPC 20" items on the display; if CTASK contains 6, these will show values for task 6. You can see the registers for another taks by modifying CTASK on your display. CTASK is also the task started by "Go", "SS", etc. as discussed later.
APC contains either the subroutine return link for the current task or the PC for a task about to be reactivated; when it is a subroutine return link, it holds the location of the last CALL or’ed with 1. In virtual mode, because of the scrambled instruction placement, this will not readily translate into the location of the caller, so Midas provides a variant of APC named CALLER, which holds the value in APC less 1; in virtual mode this will show the IM address of the last CALL.
14. Memory System Registers and Memories
VM accesses the virtual memory using the current contents of the MAP. Midas does not provide any direct method of accessing storage; the user has to setup MAP with appropriate values and then use VM to do this.
MAP, MEMSYNDROME, etc. to be filled in
15. Loading Programs
The "Load", "LdSyms", and "LdData" actions are used to load micro-binary files into the machine. These actions are executed by first typing a list of file names (default extension ".mb") separated by commas, then bugging "Load" or "LdSyms" (typing ";L" is equivalent to bugging "Load"). These actions require confirmation by <cr>, "Y", or "." iff a previously-loaded program is being overwritten; in a command file where it is not known whether or not another program is being overwritten, a "Confirm" action should precede the load action, as discussed earlier.
"Load" loads the entire .mb file--symbols into the Midas symbol table, data into the hardware, and breakpoints into the BP memory.
"LdSyms" loads only the address symbols and IM mapping table from the .mb file; the BP memory is not loaded and data are not loaded into the hardware.
"LdData", (in command files but not available interactively), loads data blocks and the BP memory from the .mb file; symbols and the IM mapping table are not loaded.
On D0, the MADDR and MDATA memories are treated as exceptions by "LdData"--symbols for these are loaded anyway.
Midas uses several 1024-word core buffers (about 12 on D0 Midas) and the Swatee file to manage its symbol table and virtual memory mapping information; the largest existing programs use 10 buffers for VM information and about 20 more (out of 64 available on Swatee) for symbols. For nearly all symbol and VM accesses, Midas will reference only one or two symbol blocks, so there should be no appreciable slow down when handling large programs.
The symbol table management algorithm used by Midas is an extremely fast merge that works well when the symbol table is nearly empty at the onset of a load but suffers somewhat from block fragmentation when the initial symbol table has many items.
To avoid fragmentation, don’t load one microprogram on top of another--use "Run-Prog" to reset the symbol table, then do the "Load". It is also a good idea to assemble microprograms as a single .MB file. Although Midas can load multiple .MB files (typed as a list separated by commas), this will fragment the symbol table and cause extra thrashing.
These recommendations follow because Midas takes advantage of alphabetical address ordering in .MB files to pack its symbol buffers nearly full. But when subsequent files are loaded, the symbol buffers will fragment to about half-full, symbol buffer swapping will result, and symbol searches will be longer.
Midas uses the symbol table in two ways: looking up the value of a symbol, requiring at most one disk access; and searching for the symbol in a particular memory which best matches a value, requiring at most one access for RM or at most two accesses for IM address symbols; the best matching value for addresses in all other memories is determined by scanning every block. Searching every block requires about (.22 seconds * no. symbol blocks) - (.15 seconds * no. blocks in core) or about 2.9 seconds for the largest program thus far. However, since best matches for the two most important memories are obtained quickly, it will rarely be necessary to wait for a search.
In most situations where a "Load" is going to be done, many other actions will also be carried out to setup the display appropriately for the program. For this reason, you will ordinarily want to define a command file that does all these other actions as well as the "Load" and you will ordinarily do "Run-Prog" on this command file; direct use of "Load" in the command menu will be rare.
Midas/MicroD do not handle microprograms with overlays conveniently. At present, the system microcode consists of an initial microstore image that contains both some resident code and initialization code; the initialization code is executed and then overwritten by the rest of the resident system. Midas/MicroD do not provide any clever features for setting up the symbol table and IM mapping table correctly in this situation. One method of handling this situation is to create a "Run-Prog" command file which does the following:
1) A "Load" on the resident+initialization; then a "Go" at the starting address, which runs up to a breakpoint at the end of initialization.
2) A "Run-Prog" on another command file; this clears the breakpoint, IM mapping, and symbol tables. The command file does a "Load" on the original resident+rest of resident that replaces the initialization code and returns to the outer command file.
3) A "Go" at the starting address (or a "Continue" from the initialization breakpoint) to start the system which then runs until it fails or halts.
Assuming that you are somehow able to build the two .Mb files needed by this sequence (It is unclear how you will do this.), you will wind up with Midas containing the correct symbols and IM mapping table for debugging.
16. Dump and Compare
Both "Dump" and "Compare" require confimation by <cr>, Y, or "." They accept the name of a microprogram (default extension ".mb") on the input text line. If the input text line is empty, then the file name is defaulted to the name of the program last loaded.
"Dump" deletes forward reference fixups left by Micro (which never occur on Dorado or D0 because MicroD does these) and compacts both data and addresses to use less disk space and load more quickly later. Dumped files are about 20% smaller and can be loaded 10% to 15% faster than undumped files, so it is desirable to load and then dump .mb files that will be used widely.
Also, if undumped .MB files contain forward references, they cannot be used with "Compare" (no problem on Dorado or D0).
Note that only memory words loaded by Load are dumped--you cannot patch unused locations, dump the program, and expect the patches to survive. (You might assemble extra locations as a patch area with your microprogram, so that you can patch and dump during debugging, but placement constraints will be difficult to satisfy.)
"Compare" compares data currently in storage against data in the file and reports differences on the Midas.Compare file.
In microprograms, avoid loading initial values into memory words modified during execution. The usefulness of "Compare" is enhanced when programs are clean, because no fictitious errors will be reported.
For diagnostics, "Compare" can report what has been smashed when something goes off the deep end--this has frequently been helpful.
Following system microcode crashes, "Compare" may provide the only clue about the nature of an intermittent storage failure.
17. Break, UnBreak, ClrAddedBPs, ClrAllBPs, and ShowBPs
"Break" inserts a breakpoint in the IM or IMX address typed on the input text line. The address must be typed--there is no default break address. You will normally find it faster to type "address;B" to insert a breakpoint.
"UnBreak" removes a breakpoint. If no text is typed, the address defaults to the breakpoint that caused the last program halt or to the address of the last breakpoint inserted. You will normally find it faster to type "address;K" or ";K" to remove a breakpoint.
"ClrAddedBPs" removes all the breakpoints inserted since the last "Load" and prettyprints the addresses of the first 10 removed. "ClrAllBPs" clears all breakpoints, including those that were loaded witht he program. "ShowBPs" prettyprints the addresses of all breakpoints added since the last "Load."
Breakpoints are implemented by replacing the broken instruction by a special breakpoint instruction. When the D0 is halted, IMX contains the unbroken instructions, and Midas remembers which places contain breakpoints; when you continue your program with "SS," "Go," or "Continue," Midas saves the instructions in its table (the BP memory), and stores breakpoint instructions at those places; when the program halts, Midas restores the contents of IMX.
Single-stepping is also implemented with breakpoints; Midas determines one or both possible successors to the instruction being single-stepped, plants breakpoints there, starts the machine, and then undoes the breakpoints after the machine halts; BP’s 0 and 1 are used for this purpose.
A breakpoint can be put on any instruction. However, there is a limit of 254 user breakpoints; also, there are some restrictions on continuing discussed in a later section. You may be unable to continue from breakpoints on some instructions.
18. Go, SS, and Continue
These are actions that result in the microprocessor resuming or starting execution at the selected address. "Go" and "SS" accept an optional address argument on the input line that must evaluate to an IM or IMX address; a simple number is defaulted to an IMX address in absolute mode or an IM address in virtual mode. If the optional argument is omitted, Midas will continue from the last break. "Continue" always continues from the last break, ignoring any text on the input text line.
The keyboard equivalents for these commands are ";G" for "Go"; ";S" or ":" for "SS"; and ";P" or ";C" for "Continue."
When you start at a new address, the value in CTASK (lower left-hand corner of the normal display) is the task activated. You must change CTASK on the display before initiating execution for a different task.
When the microprocessor halts after a breakpoint, due to an error, or because you aborted, Midas prints the location of and reason for the halt and saves the information that it needs to continue. The form of the printout is "task:address". Subsequently, if you attempt to continue, Midas restores the hardware as nearly as possible to its state at the break before continuing.
There are some complications surrounding Midas’ ability to restore the state of the program, after doing other things, so that continuation is possible. These are discussed in the next section.
19. When Registers are Read/Written--Restrictions on Continuing
When a microprogram halts at a breakpoint or due to a mouse-halt, Midas has two objectives: to read the contents of registers and memory addresses so that they may be shown to the user, and to be able to continue from the interrupt or breakpoint. In terms of how the Midas read/write procedures work, there are three cases:
Registers: The Kernel program running on D0 saves registers in RM words reserved for the purpose; Midas reads these special RM locations into a block of Alto storage when the machine halts or when you do a "Boot" action. Subsequently, Midas displays the values from Alto storage, and, when a register is written, modifies the Alto storage. The D0 hardware is not affected by any change in register values until you resume or start your D0 program. At that time, the block of Alto storage is rewritten into the Kernel’s special RM locations, and the Kernel will transfer these values into the registers just before releasing control to your program.
Memories: IM/IMX, RM, T, TPC, MAP, and VM addresses are read and written directly; whenever you modify a word in one of these memories, Midas will write it (through the Kernel); Midas always reads the values from the hardware, never from remembered values in Alto core.
Artificial registers and memories: For CTASK, AATOVA, BP, MIM, MDATA, and MADDR, Midas modifies/reads the Alto storage containing the value, so the D0 hardware is not affected.
However, whenever any register, memory word, or artificial register or memory word is modified, Midas rereads the value for every item on the display, going left-to-right and top-to-bottom through the display. This is unimportant as long as the D0 hardware is functioning correctly, but if the hardware is unreliable, then displayed values of memory words may change, so be wary.
There are a number of situations that may prevent continuation from a breakpoint or interrupt; Midas warns you about some of these when you try to continue but does not warn you about others. Some of the ones that Midas does not warn you about are as follows:
Input/output tasks were not serviced properly due to the delay at the breakpoint, so these are not continued correctly;
You break on any of the three instructions involved in the "bypass kludge," when the instruction after a memory operation expects to read the result of the memory addition instead of the value for which write is pending into T or RM.
Some situations that Midas does warn you about are as follows:
You broke at the instruction after a LoadPage. This happens either because you break on the instruction after a LoadPage or because you break on the LoadPage instruction itself and Midas breaks on the instruction after the LoadPage when restarting.
20. Hardware Failure Reporting
Midas checks for several kinds of hardware errors and reports them in COMM-ER0, COMM-ER1, and COMM-ER2, which are addresses in the MADDR memory; these are shown in the upper right-hand name-value menus of the normal Midas display. Values have two 16-bit fields; each field counts errors of some type and can be prettyprinted for interpretation. Midas does not print any special messages after these errors--the user will have to notice when they change.
A "Boot" action is carried out by first loading selected IMX words from a ROM; Midas can cause the D0 hardware to do this through its Diablo Printer interface, as discussed in the hardware manual. When this part of the boot finishes, Midas transmits the Kernel into IMX by communicating with the boot loader. If Kernel transmission is successful, Midas then starts the Kernel.
Four possible communication errors may be detected during Kernel transmission. If one of these failures occurs, Midas reports the failure in BOOT-ERR (an address in the MADDR memory) and reattempts the boot, not giving up until the boot has failed 10 times. BOOT-ERR is shown on the display as two 16-bit fields; the left-most field shows how many words were transmitted before the (last) failure occurred; the right-most field contains four four-bit nibbles that count the number of failure occurrences for each of the four reasons.
As soon as the Kernel has been successfully transmitted, Midas will attempt to start it running; if this fails Midas will immediately report a failure without retrying.
MEMSYNDROME and BOOTREASON registers report failures detectd by the D0 hardware, as discussed in the hardware manual.
21. Testing Directly From Midas
"Test" and "TestAll" allow the target machine to be tested directly from Midas. Although diagnostic firmware can test faster and more thoroughly than is practical from Midas, Midas direct testing permits the hardware to be checked out well enough to get basic diagnostics loaded and started. On Maxc1, which had no direct testing in Midas, many hardware failures of the "nothing works" variety were harder to fix than on Maxc2 and Dorado, where Midas test software is available.
However, on D0 and M68 implementations of Midas, the test features in Midas are of doubtful usefulness because the hardware is accessed through communication with a small "Kernel" microprogram that only works when most of the hardware is functional.
On D0, only IMX and RM are presently testable, but the address ranges are limited so as not to overwrite the parts of these memories used by the Kernel. Neither of these actions is expected to be useful because most failures in these memories will prevent the Kernel from running. They are described here anyway.
Data patterns for test actions are determined from the first subsidiary menu, as follows:
Table 6: Test Data Pattern Actions
ZEROESAll-zeroes data
ONESAll-ones data
SHOULD-BEConstant test pattern equal to value in SHOULD-BE
CYC1Vector of the same size as the register containing zeroes with a single one-bit cycled left one position each iteration
CYC0Cycled zero in vector of ones
RANDOMRandom numbers
SEQUENTIAL0, 1, ..., sequential numbers
ALTZOAlternating all-ones and all-zeroes patterns
ALT-SHOULD-BEAlternating contents of SHOULD-BE with its ones-complement
The CYC0, CYC1, and SEQUENTIAL patterns vary according to the size and arrangement of the data vector for the item being tested. CYC0, for example, starts off with leading 1’s and a 0 in the right-most bit of the data vector. The 0 is shifted left (bringing in 1’s to its right) each iteration; when the 0 is shifted out of the left-most bit in the data vector, the vector is reinitialized to leading 1’s and a 0 in the right-most bit. The CYC1 pattern is like CYC0 with 1’s and 0’s interchanged. The SEQUENTIAL pattern is initialized to 0 and is incremented by 1 in the right-most bit of the data vector each iteration.
This treatment of CYC0, CYC1, and SEQUENTIAL patterns is conceptually correct for items that are described inside Midas by dense, left-justified data vectors whose bits are displayed left-to-right on the screen. On D0 all testable items are handled this way.
Testing is controlled/described by 12 addresses on the display as follows:
Table 7: Test Items in the Name-Value Display
SHOULD-BEOn a failure, the correct data; after control-C or Abort, the next pattern.
DATA-WASOn a failure, what the data was; after control-C or Abort, the data read last time.
BITS-CHECKEDMask of bits checked (see below).
BITS-PICKEDUnion of bits that should have been 0 but were erroneously 1 during testing. This accumulates failure information when you continue a Test using <escape> or <cr>.
BITS-DROPPEDUnion of bits that should have been 1 but were erroneously 0.
LOOP-COUNT32-bit iteration count at which failure occurred or after which the test was aborted.
NFAILURES32-bit count of test failures.
Memory tests only
LOW-ADDR
HIGH-ADDR
CURRENT-ADDR
ADDR-INC32-bit addresses: If ADDR-INC (normally 1) is positive, the test starts at LOW-ADDR and advances through the memory in steps of ADDR-INC until CURRENT-ADDR is greater than HIGH-ADDR. If ADDR-INC is negative, the test starts at HIGH-ADDR and goes by steps of ADDR-INC until CURRENT-ADDR is below LOW-ADDR. CURRENT-ADDR contains the last address tested.
ADDR-INTERSIntersection of address bits where failures were detected.
ADDR-UNIONUnion of address bits where failures were detected.
SHOULD-BE, DATA-WAS, BITS-CHECKED, BITS-PICKED, and BITS-DROPPED are addresses in the MDATA memory; LOOP-COUNT, NFAILURES, LOW-ADDR, etc. are addresses in the MADDR memory. These two memories (which are tables in Alto storage) exist on all versions of Midas that implement the test actions.
The handling of the MDATA memory is complicated by the fact that items in this memory have to be shown in the same format as the memory or register being tested. This is accomplished as follows: When the selected test item is different from the last, the width and print-format of MDATA are set to be identical to the new item; in this case BITS-CHECKED is initialized to test all bits in the new item. Then when the test is aborted or halts due to a failure, the display of BITS-CHECKED, etc. is identical to that of the item tested. The user may then modify BITS-CHECKED and continue, restart, or free-run the test, as discussed below; in this case the item tested is identical to the last item tested, so BITS-CHECKED is not reset.
The handling of MADDR is also tricky. ADDR-INC is allowed to be any value except 0; if it is 0, Midas will reset it to 1 before testing. When HIGH-ADDR is initially greater than the largest legal address in the memory, it is reset to memlength-1 prior to testing. Then if LOW-ADDR is greater than HIGH-ADDR, it is reset to 0 before testing. When the selected memory differs from the last item tested, and when the length of the memory is less-than-or-equal to 100008 words long, Midas will reset LOW-ADDR to 0 and HIGH-ADDR to memlength-1 prior to testing. This is done because a common operational error is failure to reset the address range when switching from one memory test to another. However, Midas does not reset the address range for very long memories because they are normally tested with small address ranges that cannot be predicted in advance--full-length testing of long memories from the Alto is so slow as to be impractical.
"Test", after showing the data-pattern menu, shows a menu of register and memory names and other test names, and executes a test of the one you select until the test fails or you halt the test from the keyboard.
The testable registers and memories appear in the second sub-menu for the "Test" action. Provision is also made for other machine-dependent tests, but there aren’t any implemented for the D0.
<esc> will continue a register or memory test that has halted; it restarts an OtherTest that has halted.
<cr> will continue a register or memory test that has halted but will free-run the test rather than halting on the next failure. While free-running, LOOP-COUNT and NFAILURES are reported continuously on the display, and BITS-DROPPED, BITS-PICKED, ADDR-INTERS, and ADDR-UNION accumulate failure information. When you stop the test by bugging "Abort" or typing control-C, the accumulated failure information is displayed in these registers.
"TestAll" automatically loads BITS-CHECKED with a full-sized comparison mask prior to testing each item; memories are tested with LOW-ADDR = 0, HIGH-ADDR = memory length-1, and ADDR-INC = 1. It tests each register 200 times and makes 4 passes through each memory and each OtherTest.
22. Command Files Used With "RdCmds"
At the time this was written, the following command files were in use:
Table 8: Command Files
midas-testsrestore "normal" Midas display with the hardware testing items in the right display column.
svcrashwrite the Midas display followed by a pretty-print of most registers on the file Crash.Report.
tpcshow 208 TPC registers in middle column.
tshow 208 T registers in middle column.