pkimpel.retro-b5500/WebUIUsingTheConsole.wiki

#summary Instructions for using the Operator Console of the retro-B5500 emulator in a web browser.
#labels Burroughs,B5500,emulator,retro-b5500,operator,console

= WebUI Using the B5500 Console =
<wiki:toc max_depth="2"/>

Compared to virtually ever other computer system of the 1960s, the Burroughs B5500 had an extraordinarily minimalist operator console -- just five buttons and six lights, plus a few more on the Teletype SPO (supervisory keyboard/printer). The best image we have of the console is from the 1968 Burroughs Corporation annual report:

    https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Console-Image.png

That image shows the B5500 at the City of Montreal, Canada. It shows the L-shaped console desk, with the Teletype Model 33 SPO.

We have tried to be faithful to the design of the console in our representation of it for the web-based user interface:

    https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Console.png

There were lots more lights, buttons, and switches on the maintenance panels in the Display and Distribution (D&D) Unit, but those were intended for use in maintenance and diagnosing hardware problems, not operating the system. They were usually behind the D&D cabinet door, out of sight, and thanks to an interlock switch on the door, powered off.

The console is the home page for the web-based emulator. It is initiated from the `B5500Console.html` page in the `webUI/` directory of emulator files on your web server. If you are running the emulator from our hosting site, simply go to

    http://www.phkimpel.us/B5500/webUI/B5500Console.html


= Layout of the Console =

The console was used to power the system on and off, initiate a load (boot) of the operating system, and halt the system. All other operations were handled through the SPO.

From left to right, the controls on the console are:

    * *HALT* button -- pressing this red pushbutton halts the system. This initiates a complete termination of all processing. The only way to continue after halting is to press *LOAD* and reboot the system. The button illuminates when power is on and the system is halted.
    * *NOT READY* light -- this white indicator illuminates when one of the components of the system that did not have its own ready/not ready indicator is in a not-ready or off-line state. It applies to processors, I/O units, memory modules, and the first drum (if present).
    * *MEMORY CHECK* -- this red light illuminates when a memory parity error is detected by either processor.
    * *LOAD* -- pressing this black pushbutton clears all registers in the system and initiates a load operation. When loading from disk, 63 sectors (1890 words) are read into memory starting at location 20 octal. When loading from cards, one binary card is read starting at location 20 octal. If the read is successful, Processor 1 then starts executing at that address.
    * *CARD LOAD SELECT* -- this yellow button/light controls whether a load operation reads from the first disk^1^ or the first card reader. In its normal position, load is from disk. When pressed, the physical button latched inward and lit, enabling load from cards. In the web-based emulator, the state of the button toggles each time you click it, but the button only lights.
    * *A NORMAL* -- this yellow light illuminates when Processor A is operating in Normal State (i.e., running user code).
    * *A CONTROL* -- this yellow light illuminates when Processor A is operating in Control State (i.e., running MCP code).^2^
    * *B NORMAL* -- this yellow light illuminates when Processor B is operating in Normal State.
    * *B CONTROL* -- this yellow light illuminates when Processor B is operating in Control State.
    * *POWER ON* -- pressing this green light/button initiates a power-up sequence for the system. The button is illuminated when "power" is applied to the system. In the web-based emulator, pressing this button initializes the internal emulator components and opens a series of sub-windows for the peripheral devices configured for the system -- SPO, card reader, line printer, etc.
    * *POWER OFF* -- pressing this black pushbutton initiates a power shutdown sequence for the system. In the web-based emulator, pressing this button halts the processor(s) and closes the peripheral sub-windows.

When the emulator is first loaded into a browser, only the *POWER ON* button is activated. Once power is applied and the emulator is initialized, the *POWER OFF* and *LOAD* buttons become active and *POWER ON* is disabled. Once *LOAD* is pressed, *HALT* becomes active and *LOAD* is deactivated. When power is applied, *POWER OFF* can be pressed at any time, even when the system is running programs.

When the SPO window opens, it will print a short message indicating the emulator version. Please wait for this message to finish printing before attempting to press the *LOAD* button.

Once you load the system, there is nothing you need to do with the console, except watch the pretty lights, until you are ready to halt the system. The SPO window will probably be the one you use the most.

The emulator, like the B5500, is fairly robust. You can halt or power off the system at any time. You can even just quit the browser at any time. We recommend, however that you do an orderly shutdown when you are finished with the system -- press *HALT*, then *POWER OFF*, then quit the browser if desired.

You may move and resize the emulator windows in any way you wish, including the console window. You may also minimize any of the windows, but _do not close the peripheral windows._ Closing one of these will render that device inoperable until the emulator is reinitialized with the *POWER ON* button.

Some web browsers, particularly Firefox, slow the execution of Javascript scripts when they run in a non-active tab of a window. The emulator has a performance throttling mechanism that attempts to run the B5500 processor at its real speed. To keep this mechanism from falling behind in terms of real time, do not open the B5500 Console in a window with multiple tabs where one of the other tabs is the active one. It is best to open the Console in its own window, or at least keep it as the active tab in a window. If you need to use the browser to access other web sites at the same time the emulator is running, it is best to open separate browser windows to do so.

See the [WebUIRunningTheEmulator Running the Emulator] page for more information on using the console to start the emulator and operate it.


= Emulator Features Added to the Console =

Since the emulator is not a physical system, it is often difficult to tell exactly what is happening when it runs. To give a better view of what is happening within the system (and just because it was kind of a cool thing to do), the emulator displays a series of white annunciator lights in two rows below the standard buttons and lights. If you are a purist and don't want to see these additional lights, you can toggle their display off and on by clicking the Burroughs logo.

The console displays the current version of the emulator below the Burroughs logo and to the left of the retro-B5500 logo.

The console attempts to update its display every 50 milliseconds. This update period applies not only to the annunciators below, but also to the A/B Normal/Control lights described above. Generally, an annunciator is lit if the corresponding element of the system had any activity since the last update of the display.

The top row of annunciators displays activity for the I/O Units (channels) and external interrupts for the system:

    * `IOU1` -- I/O unit 1 busy (i.e., an I/O was active on this unit)
    * `IOU2` -- I/O unit 2 busy
    * `IOU3` -- I/O unit 3 busy
    * `IOU4` -- I/O unit 4 busy
    * `TIMR` -- Interval timer interrupt (every 1.067 [64/60] second)
    * `IOBZ` -- I/O busy interrupt (i.e., no I/O unit available)
    * `KBD ` -- Keyboard request interrupt
    * `PR1F` -- Printer 1 finished interrupt
    * `PR2F` -- Printer 2 finished interrupt
    * `IO1F` -- I/O unit 1 finished interrupt
    * `IO2F` -- I/O unit 2 finished interrupt
    * `IO3F` -- I/O unit 3 finished interrupt
    * `IO4F` -- I/O unit 4 finished interrupt
    * `P2BZ` -- Processor 2 busy interrupt
    * `INQ ` -- Remote inquiry request interrupt
    * `SPEC` -- Special interrupt #1 (not used)
    * `DK1F` -- Disk file #1 read check finished
    * `DK2F` -- Disk file #2 read check finished

The second row of annunciators displays activity for the peripheral devices in the system:

    * `DRA` -- Drum #1
    * `DRB` -- Drum #2
    * `DKA` -- Head-per-Track disk control #1
    * `DKB` -- Head-per-Track disk control #2
    * `SPO` -- Supervisory keyboard/printer
    * `CPA` -- Card punch
    * `CRA` -- Card reader #1
    * `CRB` -- Card reader #2
    * `LPA` -- Line Printer #1
    * `LPB` -- Line Printer #2
    * `DCA` -- Data Communications Adapter
    * `PRA` -- Paper tape reader #1
    * `PRB` -- Paper tape reader #2
    * `PPA` -- Paper tape punch #1
    * `PPB` -- Paper tape punch #2
    * `MTA`-`MTT` Magnetic tape units 1-16 (letters `G`, `I`, `O`, and `Q` are not used)

At the far right of the lower portion of the console are two statistics that indicate how well the emulator for Processor 1 is performing:

    * *P1 Slack:* the average percentage of time the emulated processor is delaying its execution in order to throttle its performance to that of a real B5500. Numbers closer to 100% indicate the processor emulation is using relatively small amounts of your workstation's physical processor. Numbers closer to zero indicate the emulator is barely able (or perhaps unable) to run at the speed of a real B5500.
    * *P1 Delay:* the average amount of time (in milliseconds) the processor emulation is delayed during throttling _in excess of_ the amount of time it requested to be delayed. This is a running average over the last 1000 delays, and is an indication of how precise the Javascript `setTimeout()` implementation is for your browser.

In our experience with Mozilla Firefox and Google Chrome, the delay number is typically about half the browser's actual precision, plus one or two milliseconds. HTLM5 standards specify that browsers must have a precision of at least four milliseconds, so you should see values in the 3-4ms range for a compliant browser. Lower values are better, as all of the emulation takes place on one Javascript thread, and shorter delays allow the emulation to switch among processor and I/O tasks more efficiently.

Note that on most Windows systems, at least through Windows 7, the default timer precision is about 15ms, and you typically should see average delays in the 7-8ms range. Google Chrome is known to mess with the Windows timer mechanism beneficially, however, and meets the HTML5 requirement. Curiously, Chrome's effect on the Windows timer is system-wide -- if you run the emulator in Firefox at the same as Chrome is active in your workstation, the average delay in Firefox will be about the same as it is for Chrome.

Starting with version 23, Firefox under Windows appears to handle timers more precisely as well.



`____________`

^1^ On the B5000 and early B5500s, hardware load operated from sector 0 of the first drum device (DRA). Later B5500s were modified to load from sector 1 of the first Head-per-Track disk device (DKA). Systems wired to load from drum but without a drum device used a one-card bootstrap program to load the KERNEL bootstrap program from sector 1 of the disk, which in turn loaded the MCP. Such systems were thus effectively always booted from cards.

^2^ The B5000 and B5500 could have two processors, which were physically identified as Processor A and Processor B. Both processors were identical, with their identification determined by where they were plugged into the D&D. Based on a manual switch in the Central Control Unit, one processor could be designed as Processor 1, the control processor. The other (if present) would then be Processor 2. Only Processor 1 could run in control state, execute MCP code, and respond to interrupts. Processor 2 could run only user programs, and was essentially a slave to Processor 1.