Reconstruct Google Code wiki history from r410 on 2014-01-10: release 0.20.

WebUIRunningTheEmulator.wiki

@@ -4,9 +4,9 @@
 = WebUI Running the Emulator =
 <wiki:toc max_depth="2"/>
 
-This page describes how to operate the retro-B5500 emulator in a web browser. In order to run the emulator, it must first have been set up as described in [WebUIGettingStarted WebUI Getting Started].
+This page describes how to operate the retro-B5500 emulator in a web browser. In order to use the emulator, it must first have been set up as described in [WebUIGettingStarted WebUI Getting Started].
 
-Note that some web browsers, particularly Firefox, slow the execution of their web pages when those pages are running in a non-active tab of a window. The emulator runs continuously, and has a performance throttling mechanism that attempts to run the emulated processor at its real B5500 speed. To keep this mechanism synchronized with real time, do not open the B5500 Console in a window where one of the other tabs is active. It is best to open the Console in its own window, or at least keep it as the active tab in its window. If you need to use the browser to access other sites at the same time the emulator is running, open separate browser windows to do so.
+Note that some web browsers, particularly Firefox, may slow the execution of their web pages when those pages are running in a non-active tab of a window. The emulator runs continuously, and has a performance throttling mechanism that attempts to run the emulated processor at its real B5500 speed. To keep this mechanism synchronized with real time, do not open the B5500 Console in a window where one of the other tabs is active. It is best to open the Console in its own window, or at least keep it as the active tab in its window. If you need to use the browser to access other sites at the same time the emulator is running, it is best to open separate browser windows to do so.
 
 
 = "Powering Up" the Emulator =
@@ -23,7 +23,7 @@ To initialize the emulator, click the *POWER ON* button. The *A CONTROL* light w
 
 You may move and resize these windows in any way you wish, including the console window. You may also minimize any of the windows, but *_do not close them_*. Closing one of the peripheral device windows will render that device inoperable until the emulator is reinitialized with the *POWER ON* button.
 
-The SPO (Supervisory Printer) window is the one you will typically use the most. It will give itself the focus whenever a message begins output, so it is usually pointless to minimize or hide it while the system is running. The console window is also useful, as its lights give you information about how the system is running.
+The SPO (Supervisory Printer) window is the one you will typically use the most. The console window is also useful, as its lights give you information about how the system is running.
 
 
 = Halt/Loading the MCP =

WebUIUsingDatacom.wiki

@@ -19,17 +19,17 @@ The second iteration was a "data transmission" system, which consisted of the B2
 
 Each B487 supported up to 15 communications circuits. Each circuit was terminated in an adapter card that plugged into the B487. There were different adapter cards for different types of circuits (e.g., teletype current-loop, Bell 103A modem, TWIX, etc.). The B487 buffered characters from each circuit to assemble messages, sending blocks of message data instead of individual characters through the B249 to the I/O Control Unit.
 
-The B487 was limited, however, by a very small buffer memory -- 420 characters total for all circuits. 28 characters of this was allocated to each adapter slot, but multiple 28-character units could be assigned to an adapter by leaving the appropriate number of adapter slots following it unoccupied. Thus, you could configure lots of adapters with small buffers, or fewer adapters with larger buffers, on one B487.
+The B487 was limited, however, by a very small buffer memory -- 420 characters total for all circuits. 28 characters of this was allocated to each adapter slot, but multiple 28-character chunks could be assigned to an adapter by leaving the appropriate number of adapter slots following that adapter unoccupied. Thus, on one B487 you could configure lots of adapters with small buffers, or fewer adapters with larger buffers.
 
 One problem with implementing a datacom interface in the web-based emulator is that web browsers act strictly as clients in a network connection, and what the emulator needs to do is act as a server. As a result, the web-based emulator cannot support something obvious, such as the Telnet protocol -- there just is not any way to get a browser to accept those connections as a server.
 
 Therefore, we have decided to punt and implement a datacom interface for a _single_ terminal within the browser environment itself. While internally this terminal implements much of the mechanism of the B487 and B249, on the surface it works somewhat like the SPO device. It has a terminal-like window that emulates a teletype device. The device has been assigned four buffer segments, or 112 characters of buffer memory. Ping-pong buffering is not currently supported.
 
-The windor for the terminal interface we have developed for the web-based emulator looks like this:
+The window for the terminal interface we have developed for the web-based emulator looks like this:
 
     https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Datacom-Terminal.png
 
-You type messages into this window, and the window displays the system's responses -- all at ten characters per second -- just like any good 1960s terminal would do. If you think this is too slow to do any useful work, it just means you are spoiled by current Internet technology. Get over it.
+You type messages into this window, and the window displays the system's responses -- all at ten characters per second -- just like any good 1960s terminal would do.
 
 
 = Terminal Control Panel =
@@ -49,7 +49,7 @@ The B249 DTCU and B487 DTTU do not have a user interface. The terminal itself is
 
 = Using the Datacom Terminal =
 
-The *Connect* button is used to initiate a connection between the terminal and the DTTU, similar to dialing a telephone number and establishing a modem connection. Simply click the button to connect. It will light. Click again to disconnect. After connecting, the system should respond with an identification message within a few seconds:
+The *Connect* button is used to initiate a connection between the terminal and the DTTU, similar to dialing a telephone number and establishing a modem connection. Simply click the button to connect. It will light. Click again to disconnect. After connecting, a system running the Datacom MCP should respond with an identification message within a few seconds:
 
     {{{
     B-5500 01/00
@@ -60,7 +60,7 @@ The numbers following "`B-5500`" are the DTTU number and buffer number within th
 Because the B5500 had a character set consisting of only 64 printable characters, it had no native provision for the types of control characters (carriage-return, backspace, etc.) we are now accustomed to using with ASCII. Therefore, certain of the Model 33 printable characters were reserved for this purpose. On input, the following characters have special meaning:
 
     * `<` -- backspace.
-    * (left-arrow) -- end of message. For the web-based emulator, we use the tilde (~) to represent the left arrow. The ASCII DC1 character (also known as X-on or control-Q) will also end an input message.
+    * (left-arrow) -- end of message. The Model 33 Teletype had this character, but on modern keyboards this is represented by the underscore character (`_`). For the web-based emulator, we use both underscore and the tilde (`~`) to represent the left arrow. The ASCII DC1 character (also known as X-on or control-Q) will also end an input message.
     * (control-B) -- also known as ASCII STX, this is the equivalent of sending a Break signal from the terminal.
     * (control-E) -- also known as ASCII ENQ, this is the WRU (who-are-you) character.
     * (control-L) -- also known as ASCII FF, this character would clear the input buffer after the user started entering a message, but leave the buffer in an Input Busy state.
@@ -68,8 +68,8 @@ Because the B5500 had a character set consisting of only 64 printable characters
 
 The emulated terminal supports two user-interface features that the DTTU Teletype adapter did not:
 
-    # You can press the Enter key on your keyboard instead of the "~" to end a message. The terminal will print a "~".
-    # You can press the Backspace key to correct errors. The terminal will print a "<".
+    # You can press the Enter key on your keyboard instead of the "`~`" to end a message. The terminal will print a "`~`".
+    # You can press the Backspace key to correct errors. The terminal will print a "`<`".
 
 See pages 3-15 and 3-16 in the [http://bitsavers.org/pdf/burroughs/1031986_B5500_Handbook_Aug70.pdf B5500 Handbook] for information on the character substitutions used by the B249/B487.
 

WebUIUsingTheConsole.wiki

@@ -28,8 +28,8 @@ The console was used to power the system on and off, initiate a load (boot) of t
 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.
+    * *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). The emulator does not presently illuminate this indicator at all.
+    * *MEMORY CHECK* -- this red light illuminates when a memory parity error is detected by either processor. The emulator does not presently generate memory parity errors, however. Clicking this button when "power" is on will produce a complete dump of processor state and memory in a separate browser window. This dump can be generated at any time, even while the system is running.
     * *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).
@@ -66,7 +66,7 @@ The `NOT READY` indicator was also a simple lamp on the B5500. As a temporary me
 
 The console attempts to update its display every 50 milliseconds. This update period applies not only to the additional 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:
+The top row of annunciators displays activity for the I/O Units (channels), external interrupts, and Processor 2 control 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
@@ -84,8 +84,10 @@ The top row of annunciators displays activity for the I/O Units (channels) and e
     * `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
+    * `DK1F` -- Disk file control #1 read check finished
+    * `DK2F` -- Disk file control #2 read check finished
+    * `P2BF` -- Processor 2 busy flip-flop^3^
+    * `HP2F` -- Halt Processor 2 flip-flop
 
 The second row of annunciators displays activity for the peripheral devices in the system:
 
@@ -109,7 +111,7 @@ The second row of annunciators displays activity for the peripheral devices in t
 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 exponential moving average for the 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 exponential moving 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.
+    * *P1 Delay:* the exponential moving average amount of time (in milliseconds) that processor emulation is delayed during throttling, _in excess of_ the amount of time it requested to be delayed. This is somewhat 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.
 
@@ -123,4 +125,6 @@ Starting with version 23, Firefox under Windows appears to handle timers more pr
 
 ^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 in Normal State, and was essentially a slave to Processor 1.
+^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 in Normal State, and was essentially a slave to Processor 1.
+
+^3^ P2BF served primarily to inhibit initiating a program on P2, so it is always lit for a system where a second processor is not configured.