[_CD8_]<doradosource>DoradoMidasManual.dm!10>midas3.bravo

The "Ld", "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 "Ld" or "LdSyms" (typing ";L" is equivalent to bugging "Ld"). 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.

"LdData", (in command files but not available interactively), loads only the data blocks from the .mb file. "LdData" is provided so that a microprogram can be loaded without cluttering the symbol table--this is primarily for Midas initialization and should not be of frequent use to users.

Midas uses several 1024-word core buffers (about 8 on Dorado 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 25 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 "RunProg" to reset the symbol table, then do the "Ld". 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, BR, DEVICE, and TASK address symbols, 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 4.7 seconds for the largest program thus far. However, since best matches for the five most important memories are obtained quickly, it will rarely be necessary to wait for a search.

In most situations where a "Ld" is going to be done, many other actions will also be carried out to setup the display appropriately for the program and to initialize the hardware by doing "Reset" or whatever. For this reason, you will ordinarily want to define a command file that does all these other actions as well as the "Ld" and you will ordinarily do "RunProg" on this command file; direct use of "Ld" in the command menu will be rare.

Both "Dump" and "Cmpr" 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 Dolphin because MicroD does these) and compacts both data and addresses to use less disk space and load more quickly later.

Note that only memory words loaded by Load are dumped--you cannot patch unused locations, dump the program, and expect the patches to survive. (Suggestion: assemble extra locations as a patch area with your microprogram, so that you can patch and dump during debugging.)

In microprograms, avoid loading initial values into memory words modified during execution. The usefulness of "Cmpr" is enhanced when programs are clean, because no fictitious errors will be reported.

On Dorado breakpoints are created by deliberately storing bad parity in both halves of a microinstruction. Since double parity failures are highly unlikely, there is usually no ambiguity between deliberately set breakpoints and hardware failures.

Since the two parity-bad bits are part of the value displayed for an instruction, it would be possible to insert or remove a breakpoint by examining an instruction and storing 3 or 0 into the parity-bad field; however breakpoints are inserted and removed often enough to warrant an easier method for doing this. The "Brk" and "UnBrk" actions are provided for this purpose.

"Brk" 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.

"UnBrk" 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.

These are actions that result in the microprocessor executing instructions from the control store starting at the selected address; "SimGo", which will be discussed later, also does this. Each of these accepts an input argument (optional except on "Call") 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.

When you start at a new address, the value in TASK (lower left-hand corner of the normal display) is the task activated. TASK is initialized to the value in CTASK (i.e., to the task for which an instruction was about to be executed) when Dorado halts or when you abort. You must change TASK on the display to initiate execution for a different task.

"Go" and "Proceed" will start the machine running and wait either for it to halt or for you execute the "Abort" or "Dtach" actions which are displayed during the "Go". When going or proceeding at a new address (as opposed to continuing from the last break), "Go" will reset io devices and the control section, while "Proceed" does not do this; in other respects these actions are identical.

Although "Go" and "SS" (single-step) appear in the command menu, you will probably discover that it is faster to type "address;G" to Midas, an alternative to "Go", or "address:", an alternative to "SS"; "Proceed" is only executable by typing "address;P." Similarly, ":" is equivalent to a continue-"SS" and ";G" or ";P" (proceed) to a continue-"Go".

"OS" (opcode-step) keeps single-stepping the machine until either you execute the "Abort" action, a halt condition occurs, or an IFUJump has been executed. In other words, it simulates a "Go" with repeated single-steps, but stops after the next IFUJump. This is intended to facilitate debugging emulators that use the IFU.

There are some hardware restrictions on single-stepping discussed in the next section. The most serious of these is that it is illegal to single-step across an instruction that does Fetch← and ←Md. Since this is expected to be common in emulators, there will be many times when OS doesn’t work.

"Call" allows a microprogrammed subroutine to be called with an optional argument passed in T. By convention both the microassembler and the "Reset" action plant a "FreezeBC, Breakpoint, Return" microinstruction at IMX 7776. A call is initiated by typing "SUBR(ARG)" or "SUBR()". This causes ARG (if any) to be evaluated and stored in T; LINK is loaded with 7776; then "SUBR;G" is done. If the subroutine returns (to 7776) Midas prints an appropriate message.

Ready flipflops, CTASK, CTD, etc. are cleared by executing "TaskingOn", "No-op", and then "Goto[7777], Block" for each task. Your microprogram should probably load IMX 7777 with some instruction to handle bogus task wakeups.

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.

The primary error indicators for a break are in ESTAT; Midas analyzes these and other DMux signals such as "Task2Back", "Task3Back", "←MDSaved", etc. and pretty-prints a message about the reason for halting and the task that executed the instruction that caused the halt.

There are many 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. When these complications are insurmountable, "passive mode" may be used as discussed later.

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. The methods for reading machine state are detailed in the "Dorado Debugging Interface" document and outlined here.

Midas first reads the DMux (which includes MIR, MCR, and some other items), BMUX, and ESTAT (error status); these are read first to capture their values before they change. Since all of these items are readable without issuing any clocks to the Dorado microprocessor, Midas can still continue execution of the microprogram in ordinary situations. In passive mode (discussed later), these are the only items which Midas reads from the hardware.

In active (i.e., normal) mode, Midas next executes a no-op, clears the hold and task simulator, does 30 no-op’s, and then saves values of (current task) registers as follows: LINK, T, Q, TIOA, STKP, ALUFM 0, ALUFM 16, RBASE, MEMBASE, PROCSRN, and RM 0; these might get smashed while reading registers that the user has put or will put on the display.

Finally, Midas reads all registers displayed going top-to-bottom through the name-value menu lines and left-to-right through the columns within each line. In passive mode, only those items whose values were obtained passively will be updated; others will be marked with a "~" indicating that Midas couldn’t obtain the current value. In active mode, many microinstructions will be executed to correctly address each item, route its value onto BMux, where Midas can read it, and then restore registers smashed while doing this.

When Dorado is not running, Midas loads ALUFM 0 and 16 with the "B" and "NOT A" alu operations, and TPC (i.e., CIA) is always in a smashed state. If one of these three items is displayed, the value in the Alto static is read; if written, the static is written. The value in the static is not written into the hardware until either a "Go", "SS", "OS", etc. action occurs or the "Dtach" or "RunProg" actions are executed. ALUFM 0 and 16 are effectively untestable from Midas (sorry). TPC will get read for the new task and restored for the old task whenever Midas has to do a SelectTask, as discussed in the "Dorado Debugging Interface" document. Midas has no trouble testing TPC, but if you examine a particular TPC register several times on the display, there is no guarantee that the values displayed will be ones independently read from the hardware.

With the exception of these three items and the DMux, Midas always reads values from the hardware--other saved values are only used for restoration purposes. In other words, if "SHC" is displayed 10 times, it will be read 10 times from the hardware.

MIR, MCR, Q, T, RBASE, MEMBASE, TLINK, STKP, RM 0, and PROCSRN are smashed and restored while reading other stuff; these are read from the hardware independently each time they appear on the display, but Midas might rewrite these registers from the saved values, so if one of these isn’t working correctly, the exact nature of the failure may be obscured.

Several memories and registers are "always updated" when they appear on the display, which means that they will be reread at frequent intervals by the Midas main loop, and if the value has changed the display will be updated. The UPTIME and TGLITCH registers and the MSTAT memory, which show items continuously recomputed by the baseboard microcomputer, are treated this way; and COMM-ERRS and MIR-PES (in the fake MADDR memory), which report errors detected by the Midas hardware interface, are always updated.

Values in other registers and memories are only reexamined when you do some "dirty" action. When you write a value into some register on the display, for example, Midas tries to restore any other registers and memories that were clobbered as a side effect; then it rereads the DMux and all registers on the display.

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:

The machine stopped at t2 of an instruction that both started a new fetch and either read Md onto A or B or used Md in a shift-and-mask operation; the value of Md for the new fetch will be erroneously used in completing the Md read.

Your microprogram is relying upon the exact timing of the memory system to write the cache flags for a reference--the moment will have passed when continuation occurs (There are probably other situations when the memory system is operated in unusual ways that will prevent continuation.).

You have displayed some address in BR, BRX, ROW, CACHEA, CACHED, MAP, or VM; Midas will use task 17 and pipe entry 1 to access these, and if the break occurred in task 17, Midas will warn you that continuation is impossible because Pipe entry 1 and (for CACHED and VM) task 17 MD are smashed.

You broke on or single-stepped across an instruction that did both a Fetch← and either a T←Md or RM/Stk←Md; if you continue, data from the new fetch rather than data from the preceding fetch will be used to complete the T←Md or RM/Stk←Md operation.

Midas checks for several kinds of hardware errors and reports them in MIR-PES and COMM-ERRS, which are addresses in the MADDR memory; these are shown in the upper right-hand name-value menus by the normal Midas display. MIR-PES is shown on the display as two 16-bit fields; the first field counts parity errors detected in MIR[0:20] and the second, parity errors in MIR[21:41]. MIR-PE’s is zeroed when you start Midas, "Dtach", or "Reset", or when you start a "Ld". Whenever Midas loads a microinstruction into MIR, it checks for good parity in MIR before executing it and counts MIR-PES if the parity is no good; however, even if the parity is bad, Midas goes ahead and executes the microinstruction. If any MIR parity errors occur during a load, the message "**MIR-PE’s occurred**" is printed on the comment lines after the load; however, except for that message, Midas does not print any special messages after these errors--the user will have to notice when MIR-PES changes at other times.

COMM-ERRS is also shown as two 16-bit fields. The first field counts glitches in the "Stopped" line, which Midas samples repeatedly during "Go" (The serial 1 Dorado seemed to report "Stopped" when the microprocessor did not have any reason for stopping, so some glitch detection software was added to Midas to detect this situation.); the second field counts microcomputer timeouts. Midas initializes these error counters to 0 after initially connecting to a Dorado, during "Reset", and during "Dtach". Midas allows about 2 msec for the baseboard microcomputer to service interrupt requests; if this timeout is exceeded, the right-hand field of COMM-ERRS is counted.

Midas also shows a number of hardware conditions collected by the baseboard microcomputer; these include power supply information summarized in PROBLEMS, OUTOFSPEC, BADSUPPLYSPEC, and TGLITCH as discussed later.

The LDRtest action must be preceded by the "Debug" command file (in the "RunProg" submenu), which loads the LDR memory addresses needed for LDRtest. The "Debug" command file should not be needed in any other cases.

With diagnostic microprograms, you can use the PROC, CONTROL, MMC, MMD, MMX, IFUD, DSKETH, and DSP command files (in the submenu put up by RdCmds) to display DMux addresses for various hardware sections.

The "PEscan" action scans memories and reports parity errors. It presents a submenu consisting of "Scan-and-report" and "Scan-for-totals" actions followed by the names of the memories that can be scanned for errors. The user interacts with the submenu, selecting and deselecting memories to be scanned; then he bugs either "Scan-and-report" or "Scan-for-totals".

"Scan-and-report" will sequence through all the words in the selected memories, reporting on the comment lines the first 20 addresses that have parity errors and the total number of parity errors for each memory. "Scan-for-totals" reports only the parity error count for each memory.

"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 Dolphin 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.

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. Most, but not all, items are handled this way.

On Dorado, the exceptions are as follows: IMX, IMBD, and MIR have the parity-bad bits displayed left-most but stored internally right-most in the data vectors. The parity bits do not participate in determining the data pattern for CYC0, CYC1, and SEQUENTIAL patterns; i.e., the two parity-bad bits will always be tested with 1’s (i.e., bad parity) for CYC0 or always with 0’s (i.e., good parity) for CYC1 and SEQUENTIAL patterns.

ALUFM, CACHEA, MAP, BR, and MCR have holes between bit 0 and the right-most bit of the data vector. The CYC0, CYC1, and SEQUENTIAL patterns for these are generated as though these holes didn’t exist. I.e., ALUFM has an 8-bit data vector in which bits 1:2 are unused; CACHEA has flags in bits 0:3 and VA[4:n] in subsequent bits, but the leading bits of VA are not actually stored in the address section for most cache configurations, so the unstored bits are a hole; MAP has RP in bits 16:31 of the data vector and various flags in bits 12:15, so bits 0:11 are a hole; BR uses 4:31 of the data vector, so bits 0:3 are a hole; and MCR uses 0:15 with several unused bits in its interior.

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.

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.

<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. It is a good idea to run "TestAll" whenever the hardware is in a suspicious state.

On Dorado and Maxc2, the "LDRtest" action should only be used when the "DEBUG" command file has been executed. This requires a sophisticated understanding of the hardware and of the innards of Midas and is not recommended for novices.

Dorado Midas stores many microinstructions in a fake memory called LDR (see LOADER.MC). These are used by various actions to operate the hardware. "LDRtest" allows these to be executed in non-standard sequences to beat on particular hardware problems.

"LDRtest" accepts a list of LDR addresses separated by commas as input text. If only one LDR address is typed, the CPREG register is loaded once with the selected data pattern, then the LDR instruction is repeatedly executed with UseCPReg true for a scope loop.

When two, three, etc., up to five LDR addresses are typed, a test loop occurs whereby CPREG is loaded with the next data pattern, the first instruction is executed with UseCPReg true, then the rest of the instructions are executed, and then the BMux is read back and compared against the original data under control of BITS-CHECKED. The loop stops when (data-read-back xor data-sent-out) & BITS-CHECKED is non-zero.