Reconstruct Google Code wiki history from r366 on 2013-11-14: release 0.15.

WebUIGettingStarted.wiki

@@ -45,7 +45,7 @@ The retro-B5500 emulator pushes the limits in several areas of current web-brows
     * Window `postMessage` API
     * HTML `<progress>` element
 
-As of this writing, the emulator has been tested with and works with Mozilla Firefox 21 and Google Chrome 27. Somewhat earlier versions of these browsers may also work. Our next priority is to get it to work in Apple Safari. Microsoft Internet Explorer (at least through IE9) will _not_ support the emulator. We have not yet tried IE10.
+As of this writing, the emulator has been tested with and works with Mozilla Firefox (version 21 and above) and Google Chrome (version 27 and above). Somewhat earlier versions of these browsers may also work. Apple Safari will not support the emulator, because it does not as yet support the IndexedDB API (the emulator runs fine under Firefox on a Macintosh, however). Microsoft Internet Explorer (at least through IE10) will not support the emulator. We have not yet tried Opera.
 
 == The Web Server ==
 
@@ -53,7 +53,7 @@ The emulator must be hosted on a web server. You will not be able to run the emu
 See [WebUIGettingStarted#Establish_the_Web_Server Establish the Web Server]
 below for more details.
 
-If you need a small, simple web server to host the emulator locally, we have had good success with mongoose (https://github.com/valenok/mongoose). It can run on the same workstation as your browser to serve the emulator files using the loop-back port (localhost or 127.0.0.1). Versions are available that run under Windows, Linux, UNIX, Mac OS, and others. It is extremely easy to set up. Under Windows, it can run as either a regular program or as a service.
+If you need a small, simple web server to host the emulator locally, we have had good success with `mongoose` (https://github.com/valenok/mongoose). It can run on the same workstation as your browser to serve the emulator files using the loop-back port (localhost or 127.0.0.1). Versions are available that run under Windows, Linux, UNIX, Mac OS, and others. It is extremely easy to set up. Under Windows, it can run as either a regular program or as a service.
 
 As an alternative to setting up and operating your own web server, you are welcome to use a web site we have set up on a hosting service. Just point your browser to the following URL:
 
@@ -128,7 +128,9 @@ The default configuration also has two Disk File Controls, DKA and DKB, and assu
 
 === Running the Cold Loader ===
 
-Initializing the disk subsystem on a real B5500 involved loading a couple of bootstrap programs from cards and loading the system software from tape. The emulator does not yet boot programs from cards nor support tape drives, so in the interim, we have developed a standalone web page, the Cold Loader, to initialize the IndexedDB database structures, create an initial disk directory, and load files from the tape images. Before proceeding with this section, you must have the emulator files set up on a web server and have downloaded at least the `SYSTEM` tape image, as described in the previous sections.
+Initializing the disk subsystem on a real B5500 involved loading a couple of bootstrap programs from cards and loading the system software from tape. Initially, the emulator did not boot programs from cards or support tape drives, so in the interim, we developed a standalone web page, the Cold Loader, to initialize the IndexedDB database structures, create an initial disk directory, and load files from the tape images. That is no longer the case, and in theory you could cold-start the system the old-fashioned way with card decks, but the Cold Loader is still the easier way to do it.
+
+Before proceeding with this section, you must have the emulator files set up on a web server and have downloaded at least the `SYSTEM` tape image, as described in the previous sections.
 
 The Cold Loader script is `B5500ColdLoader.html` in the `webUI/` directory. If you are running the emulator from our hosting site, simply open
 
@@ -152,7 +154,7 @@ Finally, different web browsers store their IndexedDB databases differently. A d
 
 === Cold-starting the System ===
 
-In B5500 parlance, a "cold start" is an initialization of the system that assumes there is nothing of value in the disk subsystem. A cold start creates an empty disk directory and initializes some MCP configuration data on the disk. It it similar to formatting a disk in Microsoft Windows or creating a file system in Linux. Any prior contents of the disk subsystem are, of course, lost when you do this.
+In B5500 parlance, a "cold start" is an initialization of the system that assumes there is nothing of value in the disk subsystem. A cold start creates an empty disk directory and initializes some MCP configuration data on the disk. It it similar to formatting a disk in Microsoft Windows or creating a file system in Linux. Any prior contents of the disk subsystem are, of course, lost when you do this. The Cold Loader does not merely overwrite the disk space when cold-starting, it deletes the database structures and recreates them.
 
 To cold-start the emulator disk subsystem, click the *Cold Start* button at the top of the browser page:
 
@@ -172,10 +174,13 @@ The page will read the directory of files on the tape image and display a list o
 
     https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/ColdLoader-Tape-File-List.png
 
-In the *Load* column of this list are checkboxes. Check the corresponding boxes for the files you wish to load. You can load as many files at one time as you wish. There should be plenty of disk space -- the entire `SYSTEM` tape is only 12.4 million characters. We recommend that you select at least the following files initially:
+In the *Load* column of this list are checkboxes. Check the corresponding boxes for the files you wish to load. You can load as many files at one time as you wish. There should be plenty of disk space -- the entire `SYSTEM` tape is only 12.4 million characters. You _must_ select at least the following files initially:
 
     * `MCP/DISK` -- the Master Control Program operating system. *Important!* also tick the radio button in the *As MCP* column. This will cause the Cold Loader to set the MCP bootstrap address in segment zero to point to this file.
     * `INT/DISK` -- the System Intrinsics, a library of dynamically-bound subroutines used by all programs. *Important!* also tick the radio button in the *As INT* column. This will cause the Cold Loader to set the Intrinsics address in segment zero to point to this file.
+
+We recommend that you select these additional files when cold-starting as well:
+
     * `PRNPBT/DISK` -- the spooler for printer output.
     * `LDNCTRL/DISK` -- the spooler for card reader input (known as "pseudo" readers).
     * `ALGOL/DISK` -- the Extended Algol compiler.
@@ -196,13 +201,31 @@ You may wish to select some of the following additional files, depending on how
     * `PATCH/MERGE` -- a program to merge multiple source patch files into one and resolve conflicts among patches.
     * `XREF/JONES` -- a program for documentation and cross-referencing identifiers in program source files.
 
-Feel free to select any additional files from the `SYSTEM` tape, but note that `NDL/DISK`, `TSPOL/DISK`, the TSS/MCP (time-sharing MCP), and related `CANDE` files will not be very useful until the data communications interface is supported in the emulator.
+Feel free to select any additional files from the `SYSTEM` tape when you are cold-starting, but it is now generally better to wait until the MCP is up and running and load any additional files using the Library/Maintenance feature of the MCP. See below for more on this.
 
 After selecting files from the list for the `SYSTEM` tape image, click the *Load* button at the bottom of the list. The page will read the tape image, extract the selected files, and store them in the disk subsystem, updating the disk directory as necessary.
 
 Once files from the `SYSTEM` tape image have been loaded, you can click the *Browse* or *Choose File* button again and repeat the steps above to select and load files from the `SYMBOL1` and `SYMBOL2` tape images. Those two tape images contain only source code files.
 
-    _NOTE:_ It is possible to run the Cold Loader again at a later time to load additional files to an existing disk subsystem without cold-starting it first, but we do not recommend doing this. The disk directory update facilities in the Cold Loader are not very robust at this point, and subsequent load runs may corrupt the disk directory, especially if a file is loaded that replaces one that is already in the directory with the same name.
+    _NOTE:_ It is possible to run the Cold Loader again at a later time to load additional files to an existing disk subsystem without cold-starting it first, but we do not recommend doing this. The disk directory update facilities in the Cold Loader are not very robust at this point, and subsequent load runs may corrupt the disk directory, especially if you attempt to replace a file name that is already in the directory.
+
+We now recommend that you load only a minimum set of files to disk using the Cold Loader (i.e., the two mandatory and three recommended files above), and load any additional files using Library/Maintenance once the MCP is up and running. The MCP does a much better job of disk space allocation and directory maintenance than the Cold Loader. In particular, the MCP will replace existing files safely. It will also try to evenly distribute files across the available disk EUs, which will tend to more evenly distribute I/Os across the EUs and increase the probability of multiple simultaneous I/Os taking place.
+
+Library/Maintenance is the portion of the MCP that manages disk files and maintains the disk directory. Among its features is the capability to dump disk files to and load disk files from magnetic tape. This was typically used for file backup, archiving, and transferring files among systems.
+
+Files can be loaded from Library/Maintenance volumes such as the `SYSTEM`, `SYMBOL1`, and `SYMBOL2` tape images using the `LOAD` and `ADD` control card commands, e.g.,
+
+    {{{
+    ?LOAD FROM SYSTEM ESPOL/DISK, COBOL/DISK, DUMP/ANALYZE
+    }}}
+
+A control card command can be continued across multiple card images by terminating a card with a hyphen (-) wherever a word or other punctuation character might appear. The following continuation card(s) must not have an invalid character in column 1.
+
+All files having the same first or last identifier in their file name may be loaded by specifying `MFID/=` or `=/FID`. All files from a tape can be loaded by specifying `=/=`.
+
+The `ADD` command works the same as `LOAD`, except that loads only files that are not already in the disk directory.
+
+See [WebUIUsingTheMagTapeDrive Using the Magnetic Tape Drive] for more information on how to mount tape images onto a tape drive. See Section 4 in http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1024916_B5500_B5700_OperMan_Sep68.pdf for more information on control card syntax and the Library/Maintenance commands.
 
 
 = Next Steps =

WebUIRunningTheEmulator.wiki

@@ -110,10 +110,10 @@ You can prepare "card decks" as ordinary text files on your workstation and read
     Y Z , % ! = } "
     }}}
 
-The B5500 used five special Algol characters that do not have ASCII equivalents, so we have chosen the following ASCII equivalents for them:
+The B5500 used five special Algol characters that do not have ASCII equivalents, so we have chosen the following ASCII substitutions for them:
 
     * `~` for left-arrow
-    * `|` for "×" (the multiplication sign)
+    * `|` for "×" (the multiplication sign)
     * `{` for less-than-or-equal
     * `}` for greater-than-or-equal
     * `!` for not-equal

WebUIUsingDatacom.wiki

@@ -0,0 +1,76 @@
+#summary Instructions for using the datacom interface with the retro-B5500 emulator in a web browser.
+#labels Burroughs,B5500,emulator,retro-b5500,datacom,terminal,B249,DTCU,B487,DTTU
+
+= WebUI Using Datacom =
+<wiki:toc max_depth="2"/>
+
+
+Data communications interfaces for computers were at a primitive state when the B5000 and B5500 were designed, and it shows in the equipment and software available with the B5500. Datacom was an I/O device. It multiplexed the traffic for multiple terminals onto one data path to and from the I/O Control Units.
+
+The B5500 initially supported teletypes and other low-speed devices, but eventually supported the Burroughs line of poll-select video terminals, the TC500 (a programmable keyboard/printer device), and RJE through satellite B300 or IBM 1050 systems.
+
+
+
+= Background =
+
+There was an early "inquiry" system based on the B5480 Data Communications Control Unit (DCCU). This was somewhat limited, as it could not initiate messages to a remote terminal -- it could only send responses to messages from a terminal.
+
+The second iteration was a "data transmission" system, which consisted of the B249 Data Transmission Control Unit (DTCU) plus up to 15 B487 Data Transmission Terminal Units (DTTU). The DTCU connected to the B5500 I/O Control Unit. It provided a multiplexed interface for the B487s, along with translation circuitry to convert ASCII and Baudot character sets to the BCL encoding used with the B5500.
+
+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.
+
+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.
+
+The windor 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.
+
+
+= Terminal Control Panel =
+
+The B249 DTCU and B487 DTTU do not have a user interface. The terminal itself is all that appears, and roughly models a Teletype Model 33 KSR unit. Across the top of its window are a *Connect* button and a series of red indicators reflecting the status of the terminal's buffer in the DTTU:
+
+    * *NR* -- Not Ready -- the buffer and/or DTCU/DTTU is not ready.
+    * *IDLE* -- the buffer is in an idle state, ready to receive input from the user or output from the system.
+    * *RR* -- Read Ready -- The user has entered a message into the buffer that is ready to be sent to the system. A buffer becomes Read Ready when the user enters an end-of-message character (see below) or the buffer becomes completely full. The buffer signals the system that it has data to send. The state reverts to Idle once the system reads the buffer.
+    * *WR* -- Write Ready -- this state is normally set after the system sends data to the buffer without an end-of-message character. Once the buffer sends the all of data to the terminal, the buffer enters the Write Ready state and signals the system that it is ready for more output.
+    * *IBZ* -- Input Busy -- the buffer enters this state when the user types the first character of a message. It stays in this state until either the user enters an end-of-message character or the buffer becomes full, at which point it enters the Read Ready state.
+    * *OBZ* -- Output Busy -- the buffer enters this state after receiving an output message from the system. It stays in this state while it is transmitting the data to the terminal. Once the buffer is empty, it enters either the Idle or Write Ready state, depending on whether it has seen an end-of-message character from the system or the buffer has become full.
+    * *AB* -- Abnormal -- this is a flag that has different meaning depending on the state of the buffer. For example, Input Busy Abnormal indicates that the user has entered a "?" in the message (used to indicate a control message to the MCP). Write Ready Abnormal indicates that either the terminal has just connected to the DTTU or the user has entered the WRU (who-are-you) character. It is generally reset the next time the buffer changes state.
+    * *INT* -- Interrupt Requested -- this is another flag that can be set for several states when the buffer requires attention from the system. It indicates than an Inquiry Request interrupt has been sent to the B5500. It will be reset once the B5500 performs an Interrogate operation to determine the status of the highest-priority buffer that initiated the interrupt.
+    * *FB* -- Full Buffer -- this flag indicates that the buffer has been filled on either input or output without sensing an end-of-character message. It will be reset once the buffer is emptied.
+
+
+= 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:
+
+    {{{
+    B-5500 01/00
+    }}}}
+
+The numbers following "`B-5500`" are the DTTU number and buffer number within that DTTU. Since the emulator currently supports only one terminal buffer, these numbers are constant.
+
+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.
+    * (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.
+    * `!` -- disconnect -- entered on input, this character will disconnect the terminal from the DTTU.
+
+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 may move and resize the terminal window, and minimize it, but _do not close the window_. The system will warn you if you attempt to do this. Closing the window will render the terminal inoperable until the emulator is reinitialized with the *POWER ON* button.
+
+The frame representing the "paper" for the terminal has a 1500-line scrollback. It is implemented as an HTML `<iframe>` element, so most browsers will allow you to save or print the contents of the window. You can also select text within the window and copy/paste it into another application on your workstation.

WebUIUsingTheCardPunch.wiki

@@ -1,11 +1,64 @@
 #summary Instructions for using the card punch with the retro-B5500 emulator in a web browser.
-#labels Burroughs,B5500,emulator,retro-b5500,operator,card,punch
+#labels Burroughs,B5500,emulator,retro-b5500,operator,card,punch,B304
 
 = WebUI Using the Card Punch =
 <wiki:toc max_depth="2"/>
 
 
-= Under Construction =
+The B5500 supported a couple of card punch models, with speeds ranging from 100 to 300 cards per minute. A B5500 system could support one card punch, identified as `CPA`.
+
+
+= Background =
+
+The card punch interface we have developed for the web-based emulator is modeled after the 300 card-per-minute B304. This interface opens in a separate window when the <b>Power On</b> button is activated on the emulator console:
 
     https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-CardPunch.png
 
+The B304 had additional buttons and lights related to the mechanical issues of punching cards (e.g., feed and punch check indicators), but these controls are not relevant to operation under the emulator.
+
+The unit had three output stackers, primary (Stacker 1), auxiliary (Stacker 2) and error. The error stacker was used for cards detected to be in error after punching, cards left in the punch area too long and ejected automatically by the unit, and "runout" cards that were manually cleared from the feed path. This stacker is not modeled by the emulator.
+
+Stackers 1 and 2 each have an output capacity of 850 cards. When either stacker becomes "full" (i.e., the number of cards reaches that limit), the unit goes into a not-ready state.
+
+The last few cards punched to each stacker are shown in text areas on the window for the card punch user interface. The B5500 character codes are translated to ASCII lines of text before being displayed in these text areas. Each line of text represents one card. You can virtually remove "cards" from the "stacker" by selecting and copying lines of text from these areas and then pasting them into another application (such as a text editor) from which they can be saved to permanent storage. This copy/paste technique is the only reasonably convenient way to remove data from the browser-based emulator.
+
+Cards can only be punched in alpha mode, i.e., ordinary alphanumeric keypunch hole patterns. Binary punching is not supported. Lines are composed using the emulator's version of the B5500 64-character set:
+
+    {{{
+    0 1 2 3 4 5 6 7
+    8 9 # @ ? : > {
+    + A B C D E F G
+    H I . [ & ( < ~
+    | J K L M N O P
+    Q R $ * - 0 ; {
+      / S T U V W X
+    Y Z , % ! = } "
+    }}}
+
+The B5500 used five special Algol characters that do not have ASCII equivalents. The emulator uses the following ASCII substitutions for them:
+
+    * `~` for left-arrow
+    * `|` for "&times;" (the multiplication sign)
+    * `{` for less-than-or-equal
+    * `}` for greater-than-or-equal
+    * `!` for not-equal
+
+
+= Card Punch Control Panel =
+
+The user interface for the emulated card punch consists of the following controls and indicators:
+
+    * *NOT READY* -- this red indicator lights when the punch is in a not-ready status. The punch becomes ready when either output stacker is not full and the *START* button is pressed. It becomes not-ready when either output stacker becomes full or when the *STOP* button is pressed.
+    * *RUNOUT* -- This red button/indicator is used to "empty" the output stackers of the punch. This is a different use than the button had on the B304 punch unit. The button only responds to clicks when the punch is in a not-ready status. Clicking the button in a not-ready status toggles the state of the button. When this button is activated (the indicator is lit), pressing the *START* button will display a confirmation box asking if it is okay to empty both stackers of the punch. If you reply OK, the lines of text in both stackers will be erased. If you want to retain the data for the cards in either of the stackers, you much select and copy their lines of text before emptying the stacker.
+    * *STOP* -- pressing this red button will stop the punch and place it in a not-ready status. The *NOT READY* button will light.
+    * *START* -- pressing this green button when both output stackers are not full will place the punch in a ready status. The *NOT READY* light will go out. The MCP should sense the status change within a second or two and begin (or resume) punching cards if any I/Os to the punch are currently queued.
+
+
+Below the buttons are text areas and progress bars for each stacker. These show the relative number of cards currently in each output stacker. Each time you empty the stackers, this bar resets all the way to the left. As cards are punched, the length of the bar will increase towards to right in proportion to the number of cards in the output stacker.
+
+Below each progress bar, the punch shows the last card images that were punched.
+
+= Operating the Card Punch =
+
+As mentioned above, you can stop the punch at any time and make it not-ready by pressing the *STOP* button. Restart it by pressing the *START* button. Whenever the punch is stopped and in a not-ready status, you can copy/paste the lines of text in each stacker and/or clear the stackers using the *RUNOUT* button.
+*STOP* between each file selection.

WebUIUsingTheCardReader.wiki

@@ -1,11 +1,90 @@
 #summary Instructions for using the card reader with the retro-B5500 emulator in a web browser.
-#labels Burroughs,B5500,emulator,retro-b5500,operator,card,reader
+#labels Burroughs,B5500,emulator,retro-b5500,operator,card,reader,B129
 
 = WebUI Using the Card Reader =
 <wiki:toc max_depth="2"/>
 
 
-= Under Construction =
+The B5500 supported several card reader models, with speeds ranging from 200 to 1400 cards per minute. The higher-speed models had a design and a belt-driven feeding mechanism that was similar to the Burroughs check sorting equipment, and was probably derived from it.
+
+A B5500 system could support one or two card readers, identified as `CRA` and `CRB`.
+
+Here is a good view of either a B124 or B129 reader (they were physically identical, differing only in speed) at Standford University in California, probably during the mid-1960s:
+
+    https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-at-Stanford.jpg
+
+
+= Background =
+
+The card reader interface we have developed for the web-based emulator is modeled after the 1400 card-per-minute B129. This interface opens in a separate window when the <b>Power On</b> button is activated on the emulator console:
 
     https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-CardReader.png
 
+The B129 had additional buttons and lights related to the mechanical issues of reading cards (e.g., feed and read check indicators), but these controls are not relevant to operation under the emulator.
+
+Card "decks" used with the emulator are ordinary ASCII text files, which can be prepared with any text editor. The files can have any file-name extension. Lines of text in the file may be delimited with carriage return (hex 0D), line feed (hex 0A), or a carriage-return, line-feed pair.
+
+Each line of text represents one 80-column card image. Lines of text shorter than 80 characters will be padded on the right with spaces to a length of 80; lines longer than 80 characters will be truncated on the right to a length of 80. Lines should be composed using the emulator's version of the B5500 64-character set:
+
+    {{{
+    0 1 2 3 4 5 6 7
+    8 9 # @ ? : > {
+    + A B C D E F G
+    H I . [ & ( < ~
+    | J K L M N O P
+    Q R $ * - 0 ; {
+      / S T U V W X
+    Y Z , % ! = } "
+    }}}
+
+The B5500 used five special Algol characters that do not have ASCII equivalents. The emulator uses the following ASCII substitutions for them:
+
+    * `~` for left-arrow
+    * `|` for "&times;" (the multiplication sign)
+    * `{` for less-than-or-equal
+    * `}` for greater-than-or-equal
+    * `!` for not-equal
+
+The card reader interface will translate lower-case ASCII letters to upper case. All other ASCII or Unicode characters will be considered to be "invalid punches" in a card. A "`?`" in the first position in a line of text will be considered to be an invalid punch (for the purpose of identifying the line to the MCP as a control card) but will be allowed as a valid character in any other position.
+
+Your card-deck text files should normally have the necessary control cards on the front (with a "`?`" or other invalid character in the first column) and a `?END` control card at the end, but this is not a requirement. A text file can represent a complete deck, multiple decks, or a partial deck. While the physical card readers had an input hopper capacity of about 2400 cards, there is no limit to the size of a text file that can be loaded into the emulated reader.
+
+
+= Card Reader Control Panel =
+
+The user interface for the emulated card reader consists of the following controls and indicators:
+
+    * *NOT READY* -- this red indicator lights when the reader is in a not-ready status. The reader becomes ready when the "input hopper" is not empty and the *START* button is pressed. It becomes not-ready after the last card is read from the input hopper or when the *STOP* button is pressed.
+    * *EOF* -- This red button/indicator is used to signal end-of-file to the host system. When this button is activated (the indicator is lit), pressing the *START* button with an empty input hopper will set an EOF indication in the B5500 result descriptor. The MCP ignores this indication, however, so the button is effectively non-functional with the B5500.
+    * *STOP* -- pressing this red button will stop the reader and place it in a not-ready status. The *NOT READY* button will light.
+    * *START* -- pressing this green button when the input hopper is non-empty will place the reader in a ready status. The *NOT READY* light will go out. The MCP should sense the status change within a second or two and begin (or resume) reading cards.
+
+Below the buttons is a file picker control. Clicking its *Browse...* or *Choose File* button will open a dialog box from which you can select files to load as card decks into the reader. This control is enabled only when the reader is in a not-ready status. You can select multiple files at a time, which will cause all of the files selected to be appended to the input hopper. The order in which they are appended depends on your browser and underlying operating system, however.
+
+You can append additional files to the reader's input hopper at any time. If the system is currently reading cards, simply press *STOP* to make the reader not-ready, select the files you want to load, and then press *START* to resume reading.
+
+Below the file picker control is a progress bar. This shows the relative size of the stack of cards remaining in the reader's input hopper. Each time you load one or more files into the reader, this bar advances to its full width. As cards are read, the length of the bar will decrease towards to left in proportion to the number of cards left to be read. See below on how the progress bar can be used to "empty the hopper."
+
+Below the progress bar, the reader shows the last two card images that were read. The most recently-read card image is on the bottom. This can be useful if the MCP stops the reader due to a control-card error or an invalid character detected in a card.
+
+
+= Operating the Card Reader =
+
+The basic technique with the card reader is simple -- use the file picker control to load one or more files into the reader, then press the *START* button to make the reader ready. The MCP should recognize the ready status and begin reading cards automatically. The reader will become not-ready after the last card has been read.
+
+As mentioned above, you can stop the reader at any time and make it not-ready by pressing the *STOP* button. Restart it by pressing the *START* button. Whenever the reader is stopped and in a not-ready status, you can load additional files into it.
+
+You can also "empty the hopper" while the card reader is in a not-ready status. To do this, click the progress bar. An alert box will pop up asking you to confirm that you want to empty the hopper.
+
+Note that it is not possible to remove just one of your decks from the reader's input hopper. Once files are loaded into the reader, they lose their individual identity as files and become just a part of the stack of cards to be read. When you empty the hopper, everything goes, regardless of the file or files from which it came.
+
+When the MCP encounters a control card with an error, or a card with an invalid character in other than the first column, it will stop reading cards and display the card in error on the SPO. The reader will remain in a ready status. When this happens, you generally have two choices:
+
+    # Stop the reader, empty the input hopper, correct the file with the card in error off-line, then reload the corrected file into the reader.
+    # On the SPO, enter "`CL CR`_x_" or "`RY CR`_x_" (where "_x_" indicates the reader, `A` or `B`) to clear the MCP's error status. The MCP will resume reading cards, but will not process them until after the next `?END` card is encountered. This is a convenient way to bypass just the deck that has an error.
+
+The reader shows the last two cards that were read in the bottom panel of its window. This should help you locate the card in error so that you can correct it.
+
+On some browsers, attemting to load the same file twice in succession into the reader may not work. The technical reason is that the emulator relies on the file picker control's "onChange" event to detect when you have selected a file. If you reselect the same file you just previously selected, the browser may not consider the value of the file picker control to have changed, and hence no event is fired.
+
+The browser resets the file picker control whenever the reader goes not ready due to you pressing the *STOP* button or the input hopper becomes empty. Thus, to load the same file multiple times in succession into the reader, simply press *STOP* between each file selection.

WebUIUsingTheConsole.wiki

@@ -4,11 +4,11 @@
 = 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:
+Compared to virtually every 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.
+That image shows the B5500 at the City of Montreal, Canada, ca. 1968. In the foreground is the L-shaped console desk, with the Teletype Model 33 SPO. You can see part of a card reader behind the SPO and magnetic tape drives in the background.
 
 We have tried to be faithful to the design of the console in our representation of it for the web-based user interface:
 
@@ -47,18 +47,18 @@ Once you load the system, there is nothing you need to do with the console, exce
 
 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.
+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 those 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.
+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, avoid opening 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, we recommend that you 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.
+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 in the upper-right corner of the console.
 
-The console displays the current version of the emulator below the Burroughs logo and to the left of the retro-B5500 logo.
+In non-purist mode, 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.
 
@@ -119,4 +119,4 @@ 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, 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.

WebUIUsingTheLinePrinter.wiki

@@ -0,0 +1,62 @@
+#summary Instructions for using the line printer with the retro-B5500 emulator in a web browser.
+#labels Burroughs,B5500,emulator,retro-b5500,operator,printer,B329
+
+= WebUI Using the Line Printer =
+<wiki:toc max_depth="2"/>
+
+
+The B5500 supported several line printer models, with speeds ranging from 475 to 1040 lines per minute. A B5500 system could support one or two line printers, identified as `LPA` and `LPB`.
+
+
+= Background =
+
+The preliminary line printer interface we have developed for the web-based emulator is modeled after the 1040 line-per-minute B329. This interface opens in a separate window when the <b>Power On</b> button is activated on the emulator console.
+
+Lines are printed in the window as they are received from one of the B5500's I/O Control Units. The window will scroll as lines are added to the end. The capacity of the window is 150,000 lines, which is roughly equivalent to about a case of the "green bar" pin-feed paper that was used with these printers. Once this limit is reached, earlier lines are deleted from the window to make room for new ones. See below for how you can clear existing lines from the window.
+
+Single- and double-spacing of output is supported. Any skip-to-channel command results in a horizontal line being placed at that point in the output. Zero-spaced printing (overprinting) is not supported; and such lines are printed with single spacing. The channel-12 "skip over perforation" feature of the printer is not supported.
+
+B5500 character codes are translated to ASCII lines of text before being displayed in the printer window. You can select and copy lines of text from the window and paste them into another application (such as a text editor) from which they can be saved to permanent storage. This copy/paste technique is the only reasonably convenient way to remove data from the browser-based emulator. Some browsers may also allow you to save the window contents to a file or print the window to your local printer.
+
+Lines of text are composed using the ASCII equivalent of the emulator's version of the B5500 64-character set:
+
+    {{{
+    0 1 2 3 4 5 6 7
+    8 9 # @ ? : > {
+    + A B C D E F G
+    H I . [ & ( < ~
+    | J K L M N O P
+    Q R $ * - 0 ; {
+      / S T U V W X
+    Y Z , % ! = } "
+    }}}
+
+The B5500 used five special Algol characters that do not have ASCII equivalents. The emulator uses the following ASCII substitutions for them:
+
+    * `~` for left-arrow
+    * `|` for "&times;" (the multiplication sign)
+    * `{` for less-than-or-equal
+    * `}` for greater-than-or-equal
+    * `!` for not-equal
+
+
+= Line Printer Control Panel =
+
+This preliminary printer does not have any user interface controls. If you wish to prevent the printer from printing, you can "save" it (make it unavailable to the MCP) using this SPO command:
+
+     {{{
+     SV LPA
+     }}}
+
+Use `LPB` instead of `LPA` for the second printer. Make the printer "ready" (available) again using this command:
+
+    {{{
+    RY LPA
+    }}}
+
+
+= Operating the Line Printer =
+
+As the printer has no controls, the only things you can do with it are watch the lines go by as they are printed, and copy or print all or part of the window contents.
+
+You can "rip the paper" (i.e., erase the contents of the window) by double-clicking anywhere in the window area. A dialog box will pop up asking you to confirm that the "paper" should be cleared.

WebUIUsingTheMagTapeDrive.wiki

@@ -0,0 +1,67 @@
+#summary Instructions for using the magnetic tape drive with the retro-B5500 emulator in a web browser.
+#labels Burroughs,B5500,emulator,retro-b5500,operator,magnetic tape,B425
+
+= WebUI Using the Magnetic Tape Drive =
+<wiki:toc max_depth="2"/>
+
+
+The B5500 supported several 7-track tape drive models, with recording densities of 200, 555, and 800 bits per inch. Not all drives supported all densities. Tape speed ranged from 83 to 120 inches per second, with data transfer ranges ranging in concert from 66,000 to 96,000 characters per second. Blocks of data on the tape were delimited by a 0.75-inch unrecorded gap. Rewind speed was 320 inches/second, taking about 90 seconds for a full 2400-foot reel of tape.
+
+All drives could record in even or odd parity. With even parity (also termed alpha mode), characters were translated to and from BCL (Burroughs Common Language), which was very similar to the character codes used with IBM 1401 tape drives. With odd parity (binary mode), bits were recorded without translation from their internal representation in the B5500 core memory.
+
+A B5500 system could support 16 tape drives, identified as `MTA` through `MTT` (with letters `G`, `I`, `O`, and `Q` not used).
+
+Here is a view of a B42x-series drive with its front door open, showing the tape head, pinch-roller mechanisms, and tape columns:
+
+    https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/MagTape-Drive-burr0136.jpg
+
+
+= Background =
+
+The tape drive interface we have developed for the web-based emulator is modeled after the 90 inch-per-second B425, operating at 800 bpi. This interface opens in a separate window when the <b>Power On</b> button is activated on the emulator console:
+
+    https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-MagTapeDrive.png
+
+The B425 had additional buttons and lights for power on/off, but these controls are not relevant to operation under the emulator.
+
+A 2400-foot reel of tape could hold approximately 2-20 million characters depending on the size of the blocks recorded. A typical capacity was 10-15 million characters.
+
+This initial tape drive implementation is read-only, and supports only "`.bcd`" tape image data. In this format, each 7-bit frame on the tape is stored in one 8-bit byte. The low-order six bits of the byte contain the data, low-order bit last. The seventh bit is parity. The high-order bit in the byte is a one if this frame starts a physical block on the tape. A tape mark (end-of-file indicator) is represented by a single-frame block with the hexadecimal value 8F (i.e., an even-parity greater-than-or-equal character). The same tape mark encoding was used with both even and odd parity recording.
+
+By default, the B5500 MCP brackets each file on the tape with 80-character label records. These label records serve to identify the tape reel and file names, and to provide record size and block size information, plus creation and expiration dates for the tape.
+
+Tape files have a two-part name, the MFID (multi-file identifier) which is the same for all files on one logical volume, and the FID (file identifier), which is intended to uniquely identify the file within the logical volume. Each of these names can be up to seven characters in length. A logical tape volume can extend across multiple physical reels of tape.
+
+This two-level naming convention was first established for tapes on the B5000, and later carried into the design of the B5500 MCP disk directory. It eventually made its way into the design of the disk directory for Gary Kildall's CPM operating system.
+
+When a tape is mounted on a drive and the drive made ready, the MCP will automatically read the label and automatically assign the drive to a program that has asked for a file by the names specified on the label. If only the MFID matches, the MCP will automatically search up-tape for a file with the matching FID. Unlabeled tapes are also supported by the MCP, but are less convenient, as they usually need to be assigned manually to a program using the SPO `UL` command.
+
+
+= Tape Drive Control Panel =
+
+The user interface for the emulated tape drive consists of the following controls and indicators:
+
+    * *UNLOAD* -- this black button is used to unload a tape image from the drive. This button is active only when an image is currently loaded and the drive is in local status.
+    * *LOAD* -- this black button is used to load a tape image into the drive as if it were a reel of tape. The button is active only when no image is currently loaded into the drive. Clicking this button will bring up a dialog for the file picker to select an image file, as described below.
+    * *LOCAL* -- this yellow button/indicator lights when the drive is in a not-ready status. The drive becomes ready when a tape image is loaded and the *REMOTE* button is pressed. It becomes not-ready when this button is pressed.
+    * *REMOTE* -- this yellow button/indicator lights when the drive is in a ready status. The drive becomes ready when a tape image is loaded and this button is pressed. It becomes not-ready when the *LOCAL* button is pressed.
+    * *WRITE RING* -- This red button/indicator is used to signal and control whether the tape image that is currently mounted is enabled for writing. When this button is activated (the indicator is lit), the image is writable. Writable status can only be set (i.e., the ring can be inserted) when a tape image is loaded and the drive is in local status. Writable status can be reset (i.e., the ring can be pulled) at any time while an image is loaded.
+    * *REWIND* -- pressing this black button will rewind the tape image to its load point at the beginning of the image. The button is active only when a tape image is loaded into the drive and the drive is in local status.
+
+When a tape image is loaded into the drive, an icon representing a reel of tape will appear next to the rewind button.  While not shown on the picture above, there are white annunciators along the right edge of the panel showing the status of the tape image:
+
+    * *UNLOADED* -- indicates that no tape image is currently loaded into the drive.
+    * *AT BOT* -- indicates that a tape image is loaded and is currently positioned at the beginning of the tape or "load point."
+    * *AT EOT* -- indicates that a tape image is loaded and is currently positioned at its end. No tape movement forward from this position is permitted.
+    * *REWINDING* -- indicates that the drive is currently rewinding to the load point of the image.
+
+Below the buttons is a file picker control. Clicking the *LOAD* button will open a dialog box from which you can select a tape image file to load into the drive. This control is enabled only when the drive is in a not-ready status and no tape image is presently loaded. You can select only one file at a time to load into the drive. The drive does not attempt to verify that any file you load is a valid tape image.
+
+Below the file picker control is a progress bar. This shows the relative amount of data from the tape image remaining on the "input reel." When you load a tape image into the drive, this bar is set to 100% at its far right edge. As the tape moves in the forward direction, the length of the bar will decrease towards the left; as the tape moves backward, the length of the bar will increase towards the right.
+
+
+= Operating the Magnetic Tape Drive =
+
+The basic technique used with the tape drive is simple -- use the *LOAD* button to select a tape image file for loading into the drive, then press the *REMOTE* button to make the drive ready. The MCP should recognize the ready status and attempt to read the tape label. If the file names in the label match names requested by a program, the drive will be assigned to the program automatically. Automatic name matching can be overridden using the SPO `IL` and `UL` commands.
+
+You can stop the drive at any time and make it not-ready by pressing the *LOCAL* button. Restart it by pressing the *REMOTE* button. Whenever the drive is in a not-ready status, you can rewind or unload the tape image.

WebUIUsingTheSPO.wiki

@@ -7,7 +7,9 @@
 
 Virtually all operational control of a B5500 system was done through the supervisory keyboard/printer, or SPO.
 
-The term "SPO" is presumably an acronym for "supervisor print out" or "supervisory printer for operators," or something like that. Its use persisted with Burroughs systems long after the mechanical keyboard/printers were no longer used and the operator interface transitioned to a video terminal. Modern Unisys MCP system now refer to the SPO as the Operator Display Terminal, or "ODT."
+The term "SPO" (pronounced "spoh") apparently comes from the Burroughs 220, a mid-1950s vacuum-tube computer system that preceded the B5500. The 220 had a Supervisory Print Out instruction, the assembly-language mnemonic for which was SPO. This instruction would cause a specified number of words to be printed from memory to the system's console keyboard/printer.
+
+Use of the term SPO persisted with Burroughs systems long after mechanical keyboard/printers were no longer used on the console and the operator interface transitioned to a video terminal. Modern Unisys MCP systems now refer to the SPO as the Operator Display Terminal, or ODT.
 
 
 = Background =
@@ -26,7 +28,7 @@ The SPO was a peripheral device, and interfaced both physically and electronical
 
 Since the SPO was very slow -- 10 characters/second -- and completely unbuffered, it tied up an I/O unit for the entire time that it was either printing or waiting for the operator to finish entering a command. There were a maximum of four I/O units on a system (three was a more typical number), so continuous SPO activity could have a significant impact on overall system I/O performance. The MCP went to some trouble to compress SPO output by stripping multiple blanks, and limited the number of output messages that could be queued for printing. There was also an operator command (`BK` or `<mix>BK`) to flush the output queue for either the whole system or a specified job.
 
-In order to read from the SPO keyboard, the system must to select an I/O unit and initiate a read operation to the SPO. To signal the MCP when this is needed, there is a special Keyboard Request interrupt, triggered by the *INPUT REQUEST* button on the SPO control panel, as discussed below.
+In order to read from the SPO keyboard, the system must select an I/O unit and initiate a read operation to the SPO. To signal the MCP when this is needed, there is a special Keyboard Request interrupt, triggered by the *INPUT REQUEST* button on the SPO control panel, as discussed below.
 
 
 = SPO Control Panel =
@@ -57,9 +59,9 @@ The emulated SPO supports a few user-interface features that the Teletype Model
 
 When the system is powered on and the SPO window opens, the SPO will print a short message indicating the emulator version. Please wait for this message to finish printing before attempting to press the *LOAD* button on the operator console.
 
-You may move and resize the SPO window, and minimize it, but _do not close the window._ The system will warn you if you attempt to do this. Closing the window will render the SPO inoperable until the emulator is reinitialized with the *POWER ON* button.
+You may move and resize the SPO window, and minimize it, but _do not close the window_. The system will warn you if you attempt to do this. Closing the window will render the SPO inoperable until the emulator is reinitialized with the *POWER ON* button.
 
-The frame representing the "paper" for the SPO has a 500-line scrollback. It is implemented as an HTML `<iframe>` element, so most browsers will allow you to save or print the contents of the window. You can also select text within the window and copy/paste it into another application on your workstation. Note, however, that when text from the "paper" is selected, the input focus is on the paper's frame, not the SPO window, so pressing ESC to request input will not work. In this case, you need to click the *INPUT REQUEST* button with your pointing device, or click somewhere on the SPO window outside of the "paper" frame before pressing ESC.
+The frame representing the "paper" for the SPO has a 1500-line scrollback. It is implemented as an HTML `<iframe>` element, so most browsers will allow you to save or print the contents of the window. You can also select text within the window and copy/paste it into another application on your workstation.
 
 
 = An Overview of MCP SPO Commands =