From ad845019b1b71afbb30bf3e51e0f2e272273ea37 Mon Sep 17 00:00:00 2001 From: Paul Kimpel Date: Sat, 4 Apr 2015 09:46:52 -0700 Subject: [PATCH] Reconstruct Google Code wiki history from r366 on 2013-11-14: release 0.15. --- WebUIGettingStarted.wiki | 37 ++++++++++--- WebUIRunningTheEmulator.wiki | 4 +- WebUIUsingDatacom.wiki | 76 +++++++++++++++++++++++++++ WebUIUsingTheCardPunch.wiki | 57 +++++++++++++++++++- WebUIUsingTheCardReader.wiki | 83 +++++++++++++++++++++++++++++- WebUIUsingTheConsole.wiki | 14 ++--- WebUIUsingTheLinePrinter.wiki | 62 ++++++++++++++++++++++ WebUIUsingTheMagTapeDrive.wiki | 67 ++++++++++++++++++++++++ WebUIUsingTheSPO.wiki | 10 ++-- images/B5500-CardPunch.png | Bin 28041 -> 13762 bytes images/B5500-CardReader.png | Bin 8763 -> 5719 bytes images/B5500-Datacom-Terminal.png | Bin 0 -> 17696 bytes images/B5500-MagTapeDrive.png | Bin 0 -> 15120 bytes images/B5500-at-Stanford.jpg | Bin 0 -> 19553 bytes images/MagTape-Drive-burr0136.jpg | Bin 0 -> 98456 bytes 15 files changed, 386 insertions(+), 24 deletions(-) create mode 100644 WebUIUsingDatacom.wiki create mode 100644 WebUIUsingTheLinePrinter.wiki create mode 100644 WebUIUsingTheMagTapeDrive.wiki create mode 100644 images/B5500-Datacom-Terminal.png create mode 100644 images/B5500-MagTapeDrive.png create mode 100644 images/B5500-at-Stanford.jpg create mode 100644 images/MagTape-Drive-burr0136.jpg diff --git a/WebUIGettingStarted.wiki b/WebUIGettingStarted.wiki index c91530b..8b01ea9 100644 --- a/WebUIGettingStarted.wiki +++ b/WebUIGettingStarted.wiki @@ -45,7 +45,7 @@ The retro-B5500 emulator pushes the limits in several areas of current web-brows * Window `postMessage` API * HTML `` 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 = diff --git a/WebUIRunningTheEmulator.wiki b/WebUIRunningTheEmulator.wiki index 9a0c478..be97a9e 100644 --- a/WebUIRunningTheEmulator.wiki +++ b/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 diff --git a/WebUIUsingDatacom.wiki b/WebUIUsingDatacom.wiki new file mode 100644 index 0000000..8d036f6 --- /dev/null +++ b/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 = + + + +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 `