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

The "Fields" action exercises signal decoding for particular fields of the microinstruction for scope loops. A microinstruction is fabricated from a no-op microinstruction in which the field selected from the first sub-menu is replaced by various values. The second subsidiary menu allows the value in the selected field to be incremented, decremented, and shifted.

On Dorado, the task for the original Go or SS is taken from the TASK register; subsequent restarts do not reselect the task. The control section’s Ready register is reset before the first Go or SS, but is not reset each time through the loop.

On Dorado, "RepT2" endlessly executes the instruction in MIR and reloads that value into MIR. Unlike "RepSS", "RepT2" doesn’t issue extraneous clocks while looping, so it is ordinarily more convenient for scoping.

The "HWChk" action puts up a submenu that contains several test and scope loop actions. Once started, one of these actions runs until you abort it; the iteration count will be in LOOP-COUNT when the test is aborted. The HWChk submenu currently contains the following actions:

"Read-DMux-Signal" requires a non-zero value in DWATCH; a scope loop is generated in which the DMux address selected by DWATCH is strobed out to the hardware and then the value read. A count of the number of times the value is 0 and the number of times it is 1 are showed on the comment lines. Microcomputer DMux reading is disabled during this action.

"Read-All-DMux" repeats the following sequence indefinitely: (1) Execute an almost-random microinstruction as in SimTest; (2) Read all 40008 DMux signals three times, accumulating in DWrong the union of signals which had inconsistent readout. A count of the number of inconsistent signals is displayed. Microcomputer DMux reading is disabled during this action. Also, signals which legitimately may change value (primarily Ethernet and Disk signals) are not reported as inconsistencies. This action can be used to test the reliability of the DMux and strobe data paths, which are known to become unreliable for sufficiently long Midas cables. It can also be used as a scope loop for observing DMux data paths. If this action reports no inconsistencies, then one can be fairly confident that the simulator will report Dorado hardware failures rather than failures in the Midas communication data paths.

"Connect-Disconnect" first evaluates the input text line, which must contain a valid Dorado serial number (0 to 3778). A scope loop is generated in which Midas alternately connects to the selected serial number and to that serial number xor 3778 (= disconnects). A count of successful and unsuccessful connects is displayed on the comment lines.

The DMux consistency checker, or simulator, used with the "SimGo" and "SimTest" actions examines all of the DMux signals (or mufflers), checking for inconsistencies. The simulation verifies consistency of signals from the previous readout (call this "t0") to the current readout (call this "t2").

In all cases, only passively-accessible DMux signals and BMUX and ESTAT are involved in the simulation--registers that can be read only by issuing clocks to the hardware are not checked.

The simulation subroutine behaves differently based upon the time at which the DMux was read (t even or t odd) and upon whether or not the DMux readout at tn-2 is available. Currently, the simulator is only called by "SimGo" and "SimTest", and for these the simulation subroutine is always called with the t0 and t2 DMux tables.

Setup for the simulator begins during initialization, when the "Config" action is executed. At that time, DCheck is initialized to reasonable values for the hardware configuration. In other words, if a particular section of the machine is not in the chasis, then the signals in that section cannot be checked, so they are zeroed in DCheck. In addition, other signals whose simulated values depend upon signals from the missing section cannot be checked. "Config" sets up DCheck so that only signals which can be checked will be examined for error. Finally, "Config" also zeroes the DCheck bits for signals known to be simulated incorrectly.

4) Execute the simulation program which will predict many signals as functions of values in OldDMuxTab and DMuxTab. The predicted values overwrite values in DWrong. Unsimulated signals are not modified in DWrong.

"SimTest" is executed with IOReset, RunRefresh, and EnRefreshPeriod false. It loads MIR with a randomly chosen microinstruction (except that some illegal microinstructions are weeded out--presently, the Output←, UseDMD, MidasStrobe←, and IFUTest← functions are illegal; also, the Block bit in the next microinstruction is chosen to equal whatever was coming from IMX just before t2 of the last microinstruction to avoid screwing up the control section); then it reads the DMux and steps the microinstruction through t2. This is repeated, and after each repetition the previous and current DMux readout are checked for consistency.

"SimGo" is similar, but a microprogram stored in IM is executed one step at-a-time rather than random microinstructions; there are no illegal microinstructions for SimGo. When a diagnostic or other microprogram is known to fail, it can be run full speed up to a breakpoint a little before the sequence that fails; then the program can be continued with "SimGo" which might pinpoint the hardware failure. However, since RunRefresh and EnRefreshPeriod are false during "SimGo", any microprogram that uses Storage or the Map might not run correctly. "SimGo" continues until either a simulation error is detected or ESTAT contains a halt condition; the halt conditions for "SimGo" are identical to those for "Go" (The halt conditions can be modified by the user with the "Reset" action.).

For the most part, mufflered signals in the different hardware sections relate to control paths rather than to data paths, so the consistency checker will be less effective in finding failures in data paths. However, Midas register and memory tests and diagnostic firmware can usually pinpoint data failures, so this limitation is not too serious.

When the simulator detects one or more failures, it reports a message like "2 DMux errors". You can find out which signals are believed inconsistent by executing the "DMux" action in the command menu with the middle button. When the middle button is released, the names of the first 11 signals that were incorrect are printed on the comment lines; each name is followed by a suffix such as "/A" indicating the section in which the error was detected; possible suffices are:

/B BaseboardNo signals are currently simulated.
/A ContA
/B ContB
/L ProcL
/H ProcH
/I IFU
/C MemC
/D MemD
/X MemX
/K Disk controllerNo signals are currently simulated.
/E Ethernet controllerNo signals are currently simulated.
/V Display controllerNo signals are currently simulated.

The next step is to display the DMux words associated with one of the hardware sections that failed; this is done by executing the "RdCmds" action and selecting the command file that displays that section (PROC, CONTROL, MMC, MMD, MMX, IFUD, DSKETH, or DSP).

Then find the source for a signal that failed in the hardware drawings; you will probably be able to deduce its dependency upon other DMux signals and can then determine where the failure occurred. You can view the signals relevant to the simulation by viewing the OldDMuxTab or DMuxTab signals on the display, as was discussed in the "Memories and Registers Associated With the DMux" section.

Normally, DMux addresses and registers derived directly from DMux readout (i.e., MIR, IMOUT, MCR, IMBD, DHIST, VH) show values taken from DMuxTab. However, the user may execute the "DMux" action with various button combinations to view the other three tables; the name printed for this action in the command menu will then show the selected memory. The button combinations for this are as follows:

Only when DCheck is displayed is it legal to write words in the DMux memory; the other forms are read-only. DCheck can be modified to remove signals from the checking process (or to add them back).

The "T1", "T2", and "T3" actions allow the instruction currently in MIR to be executed exactly as though it were spliced into the execution flow of the program. The DMux is read after t1, t2, or t3 of the instruction, then, for "t1" and "t3", the machine is clocked once more (to t2 or t4). MIR is restored after execution.

Midas implements three "states" called active, prepassive, and passive. The command menu always prints the current state; bugging "active" will change the state to "prepassive"; bugging "prepassive" will change to "passive"; and bugging "passive" will change to "active"--in other words, these three states are sequenced through in a "ring."

In active mode, Midas will jam instructions into MIR and execute them to obtain the contents of various Dorado register or memory words or to restore registers incidentally smashed while doing something else; as discussed earlier, there are some situations when continuation is impossible after doing this, and some hardware problems are difficult to observe when Midas is interfering to this extent.

PrePassive mode is identical to active mode, but if you start the machine with "Go," "SS,", "SimGo", "SimTest", or whatever, then Midas will automatically flip into passive mode the next time the machine halts.

When you enter passive mode from the keyboard action, the state of the hardware is restored as though it were about to continue from a step or breakpoint and TASK is restored to its value at the last step or breakpoint. After this, no further clocks are given to the hardware except those explicitly initiated by the user.

After becoming passive, Midas doesn’t update registers on the display unless their values can be read without issuing clocks. Since only DMux locations (includes MIR, IMOUT, IMBD, MCR, TESTSYN, PROCSRN, TASK) can be read without clocks, only their values change while passive.

Similarly, only registers whose values can be modified without issuing clocks may be written while passive--these are MIR, CPREG, STROBE, and D1OUT (plus the artificial registers and memories). Midas rejects attempts to modify other registers on the display. Of the writable registers, only MIR, CPREG, and IMBD can be read, and only MIR can be read passively. Consequently, if you write into CPREG, STROBE, or D1OUT by clicking the mouse over its value, it will be written but the display will show the contents of a static, not something read from the hardware--since other parts of Midas don’t update the statics, the value displayed only means something immediately after the write.

While passive, "SS" and "Go" at new addresses work as usual, so extra clocks are issued to do these. However, "SS" and "Go" to continue a program do not issue any extraneous clocks--all of the setup to continue took place at the time passive mode was entered; or after a step or breakpoint, no clocks are issued to readout the machine state, so it is possible to continue simply by modifying Stop, SetRun, and SetSS.

To do the most primitive kind of debugging while passive, it is expected that users will work as follows: First, the POKE command file will be executed to become prepassive and display STROBE, D1OUT, and CPREG, not ordinarily on the display. The user will then either do a Go or SS, becoming passive at the break, or will bug prepassive to become passive immediately. Next, MIR and CPREG will be written by modifying the displayed value. Then the Clock and Control registers and Strobe can be manipulated by storing values into STROBE and D1OUT.

STROBE is displayed as two fields and D1OUT as three fields; when storing into these, you must partition the input into fields as well. For STROBE the two fields are the address field (3 bits) and data field (9 bits). Storing into STROBE will give a three-step strobing sequence using the value of address and data you have selected. For D1OUT the three fields are the Strobe bit, address, and data. (Note: The DMux will be read after writing MIR, but it is not read after writing CPREG, STROBE, or D1OUT, used for lowest level debugging of the Midas communication interface.).

During ordinary operation, an IMX parity error or breakpoint halts Dorado after t2 of the instruction affected by the parity error. Since MIR is loaded at t2, the MIR value with bad parity has been overwritten when the machine stops, so if the path between the microstore and MIR is experiencing intermittent failures, it will be difficult to diagnose what has gone wrong.

To aid checkout in this case, the control section has a debugging aid called MIRdebug, which will disable the clock to MIR at t2 of an instruction with bad parity. When this aid is enabled, MIR will still contain the bad data after the error-halt. This feature can be invoked by enabling "MIRdebug" in the sub-menu put up by the "Reset" action. If a parity error halt occurs while MIRdebug is enabled, then Midas will print the value read from IMX[CIA] so that you can compare this with the value in MIR on the display to find out which bits are not propagating from IMX into MIR.

The liability of this debugging aid is that you will not be able to continue from a breakpoint or IMX parity error halt, so you should not enable MIRdebug unless you are searching for this type of hardware failure.

The Alto can communicate directly with the Baseboard section of any Dorado connected to it through its Diablo Printer interface as detailed in the "Dorado Debugging Interface" document. It can:

(a) Select any one of the connected Dorados;
(b) Control the muffler/manifold system or give control to the baseboard microcomputer
(c) Interrupt the baseboard microcomputer;
(d) Pass information to the microcomputer through CPREG; and
(e) Read 8 bits of information from the microcomputer through the DoradoIn mechanism.

Midas does (a) and (b) during initialization and during the "Dtach" action, as discussed in the "Starting Midas" section; Midas uses (c), (d), and (e) together with a large set of communication conventions to exchange information with a program running on the baseboard microcomputer.

$ABSOLUTE is the fundamental microcomputer memory, 8 bits wide. It contains all information other than mufflers which Midas can access on the baseboard. This memory is divided into a RAM (addresses 0 to 7778 or 0 to 1FF16) and a ROM (addresses 1000008 to 1777778 or 800016 to FFFF16). The amount of ROM is adjustable; current Dorados have storage only for addresses 1400008 to 1777778. The microcomputer stores its internal registers and other information of interest in the lowest approximately 2008 bytes of $ABSOLUTE.

The $ABS memory is identical to $ABSOLUTE except that it shows the information 16 bits wide rather than 8 bits wide. The MSTAT memory and the UPTIME and TGLITCH registers present special information from $ABSOLUTE in human-readable form. The initial Midas display shows this information. The information in the main display is easily interpretable once you get used to it, or you can pretty-print the values in expanded form.

UPTIME is a six-byte counter that counts time in 102.4 msec ticks, starting at 0 after a boot. TGLITCH holds the value that was in UPTIME at the end of the last power transient in which some voltage or current was outside its specified range. Midas prints these items like "1 day 2:23:32", i.e., in standard day hours:minutes:seconds form, when they appear on the display.

MSTAT contains the current, maximum, minimum, and first values for each of the four power supply voltages and currents and for temperatures on each of the 12 boards in the main frame. The "first" items are recorded at completion of the power-up sequence; the maximum (minimum) items are initialized to 0 (infinity) and then increased (decreased) when the current values exceed (are less than) the previous maximum (minimum); the current values are updated repetitively by the microcomputer main program. Each word in MSTAT contains four one-byte items: Voltage and Current items have one byte for each of the four power supplies, and the printout is in volts or amperes; temperature items are shown in degrees centigrade, and there is one of these for each of the 12 boards in the main frame, arranged four-per-word in MSTAT.

The microcomputer can update power supply information and temperatures for itself and for ContB irrespective of whether or not it controls the muffler/manifold system, but other board temperatures can only be determined when the microcomputer controls the muffler/manifold system. Board temperatures can only be read when the -5 volt power supply is up.

When Dorado is running (i.e., SetRun is true), Dorado controls the muffler/manifold system and neither Midas nor the microcomputer can access it; when the boot button is pushed or when Midas detaches from a particular Dorado, the microcomputer controls the muffler/manifold system, so its main program can read temperatures unless that Dorado is running. Finally, when Midas is attached to a machine, it controls the muffler/manifold system but releases control to the baseboard at regular intervals unless DWATCH is non-zero; when DWATCH (an address in the fake MADDR memory) is non-zero, Midas will retain control of the muffler/manifold system and arrange to select the muffler signal whose number is in DWATCH whenever possible.

The main breaker switch on the Dorado environmental carrier (near the floor) will turn on the 5 volt supply and one fan. The baseboard microcomputer automatically boots itself from ROM whenever this main breaker is turned on, and then follows (approximately) the sequence discussed below to bootstrap the rest of Dorado into operation:

turn on disk logic power and wait 20 seconds;
turn on disk spindle motor and wait 20 seconds;
turn on fans and +12, -5, and -2 volt supplies and wait 20 seconds;
initialize machine status information (discussed below);
load and execute Dorado boot microcode, which loads and starts the system microcode.

During this sequence and afterwards, the microcomputer reports what is happening on its status light, which will repeat a sequence of blinks followed by a pause during any problem condition. The light sequences are interpreted as follows (the light blink information is also in PROBLEMS on the Midas display):

3 blinkstransient power problemPower supply voltages went bad, now good again (details in BADSUPPLYSPEC on display; TGLITCH shows the time when this transient ended; MAXVOLTS or MINVOLTS reveals the magnitude of the transient). Presently, only voltage variations cause this condition, but eventually amperage variations may also cause it (MAXAMPS and MINAMPS on the display).

solid greenAOKBootstrap sequence is believed to have completed successfully, there have been no occurrences of the error conditions indicated by 3 through 6 blinks., and the baseboard microcomputer gets regular CP control.

As mentioned above, the main breaker switch on the Dorado turns on only the +5 volt supply and one fan. The basic "on" state minimizes power consumption, and enables the baseboard microcomputer to turn on other power supplies and fans.

When the user depresses the boot button on the back of the keyboard for at least 0.2 seconds and not more than 2.5 seconds, the microcomputer records an event called a "button push"; depressing for less than 0.2 seconds or longer than 2.5 seconds is ignored; depressing for longer than 2.5 seconds will nullify the entire boot sequence. The microcomputer will count button pushes until 1.5 seconds has elapsed with the button up; then it will carry out an action as follows:

1 push--ignored; standard emulators also monitor the raw boot button and may take some action. Currently, they go through a software bootstrap sequence under the assumption that currently loaded microcode is correct and running normally.

2 pushes--stops and resets the microprocessor and starts it in task 0 with tasking turned off at location 10678 (which is "InitMap" for the Alto emulator). This is intended to be a forcible restart of currently-loaded microcode.

3 pushes--load IM from the Dorado boot loader and start it running as for 2 pushes. This initiates a complete microcode bootstrap sequence, similar to the automatic power-on boot. It assumes nothing about the current state of the machine.

7 pushes--power down; all of the supplies and fans except the 5 volt supply and 1 fan are powered down in a safe sequence, taking about 30 seconds. The 5 volt supply can then be shut down from the main breaker switch; avoid turning off the main breaker switch until the microcomputer has completed shutting down the disk and other supplies because you will invoke the power failure safety circuits in the disk drives.

Under normal conditions, in response to the boot button being pushed or the main breaker being turned on, the microcomputer will show 1 blink for about 60 seconds and then show solid green; if Midas attaches to the machine, the status light will usually show solid green, but will show 7 blinks (Midas hogging CP bus) during long-running Midas actions.

Note: it is unsafe to turn on disk power when the -5 volt, -2 volt and +12 volt supplies are on because, the resulting power surge will blow breakers in the building wall circuits. For this reason, be sure to power down the Dorado logic supplies (7 push sequence discussed above) before turning on the disks; then go through the complete power up sequence with a normal boot sequence (1 to 3 pushes).

Note: Since the microcomputer uses the +5 volt supply itself, it will crash if that supply fails and might subsequently auto-boot itself if the +5 volt supply starts working again. An over-temperature shutdown never turns off the +5 volt supply.

Note: If the Dorado is alreay powered-on, the full bootstrap sequence can also be initiated by pressing the reset button on the front panel of the Dorado chassis (inside the cabinet, if the Dorado is cabinet-mounted). However, if the Dorado is in the shut down state, pushing the reset button has no effect.

For full user-level details on booting, consult "Dorado Booting" by Ed Taft ([Indigo]<DoradoDocs>DoradoBooting.press) and "Dorado Booting--Implementation" by Ed Taft ([Indigo]<DoradoDocs>DoradoBootingImple.press).