github.com/pkimpel.retro-b5500
1
0
Fork 0
mirror of https://github.com/pkimpel/retro-b5500.git synced 2026-04-27 04:37:49 +00:00
Code Releases Activity

Reconstruct Google Code wiki history from r353 on 2013-09-02.

Browse Source
This commit is contained in:
Paul Kimpel
2015-04-04 09:36:52 -07:00
parent 2505c76849
commit afb4780744
15 changed files with 666 additions and 644 deletions
Download Patch File Download Diff File Expand all files Collapse all files

428
WebUIGettingStarted.wiki
View File

@@ -1,214 +1,216 @@
#summary Instructions for setting up the retro-B5500 emulator in a web browser.
#labels Phase-Deploy
= WebUI Getting Started =
<wiki:toc max_depth="2"/>
= Introduction =
This page describes how to set up the retro-B5500 emulator to run in a web browser.
The emulator consists of a common Javascript core for the mainframe components of the system -- Processor, Central Control, Memory Modules, and Input/Output Units (channels), plus one or more user interfaces. The user interfaces are designed to be pluggable, so it is possible that the common emulator core could be used in multiple environments, each with their own characteristics and facilities for hosting a B5500 emulation.
A user interface (UI) presents the external representation the system and provides the means for you to interact with it. Because the implementation of I/O devices depends heavily on the environment in which the UI operates, a UI also includes all of the I/O devices (disk, card readers, line printers, SPO, etc.) The first UI designed for the emulator is the "WebUI," which designed to run in a web browser. This page describes the setup procedures for that UI.
== Quick-start Overview ==
To set up and use the web-based emulator, you will need to do the following things, which are discussed in more detail below:
* Use a suitable web browser, currently Mozilla Firefox or Google Chrome. See [WebUIGettingStarted#The_Web_Browser The Web Browser] below for details.
* Download and set up the emulator files on a web server. Alternatively, you can use our hosting service at http://www.phkimpel.us/B5500/. See [WebUIGettingStarted#The_Web_Server The Web Server] and [WebUIGettingStarted#The_Emulator_Files The Emulator Files] below for details.
* Download a copy of the Burroughs B5500 system software tape images from http://www.phkimpel.us/B5500/webSite/SoftwareRequest.html. See [WebUIGettingStarted#The_Burroughs_B5500_Software The Burroughs B5500 Software] below for details.
* Run the Cold Loader utility script to initialize the emulated disk subsystem and load the system software to it. See [WebUIGettingStarted#Initialize_the_Disk_Subsystem Initialize the Disk Subsystem] below for details.
* In your web browser, access the *`webUI/B5500Console.html`* page from the web server to run the emulator.
= What You Will Need =
To use the web-based emulator, you will need four things:
# A suitable web browser.
# A web server configured to deliver files from the emulator directories (our hosting site is set up to do this).
# A copy of the files in the `emulator/` and `webUI/` directories from the emulator release (our hosting site already has the current version of these, ready to use).
# A copy of the Burroughs B5500 system software.
Each of these is described in more detail in the following sections.
== The Web Browser ==
The retro-B5500 emulator pushes the limits in several areas of current web-browser technology. We are taking advantage of many features in HTLM5, its related DOM APIs, and CSS 3. As a result, not every web browser is capable of hosting the emulator. We rely, at a minimum, on the following advanced features:
* `IndexedDB` API (used to support the Head-per-Track disk subsystem)
* `ArrayBuffer`, `DataView`, and `Blob` APIs
* `File`, `FileList`, and `FileReader` APIs
* 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.
== The Web Server ==
The emulator must be hosted on a web server. You will not be able to run the emulator simply by opening files in your browser from your local file system. The web server can run on your local system and serve files from there, but the emulator files must be served to the browser over HTTP and not simply opened as files within the browser.
See [WebUIGettingStarted#Establish_the_Web_Server Establish the Web Server]
below for more details.
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:
http://www.phkimpel.us/B5500/
If you choose to use this web site, or any other site that is already set up to serve the emulator files, rather than your own web server, you can skip the next section on downloading the emulator files.
== The Emulator Files ==
The web-based emulator is hosted in two directories (folders) of files:
* *`emulator/`* contains the core mainframe modules. These are Javascript objects for the Processor, Central Control, and I/O Unit, plus a simple object that defines the configuration of the system to be emulated.
* *`webUI/`* contains everything else you need to run the system. In particular, it contains the Console UI, the peripheral device drivers, a Cold Loader utility used to initialize the disk subsystem, and a Syllable Debugger utility that can be used to examine the state of Processor 1 and memory while running programs, including the MCP.
An optional third directory, *`tools/`* contains some standalone utilities that can be used to examine and maintain the emulator environment.
Recent releases of the emulator files can be downloaded from
[https://drive.google.com/folderview?id=0BxqKm7v4xBswM29qUkxPTkVfYzg&usp=sharing our download site]. Each release is packaged as a separate `.zip` file.
If you use a web server where the emulator files are already set up, you do not need to download a separate copy of a release. Unless you are running your web server on the same workstation as your web browser, you do not need to store the emulator files on your workstation.
== The Burroughs B5500 Software ==
The emulator files implement only the hardware portion of a B5500 system. To make the emulator useful, you also need the system software developed by Burroughs.
Burroughs became part of Unisys Corporation in 1986. Unisys still owns and maintains copyrights the B5500 system software. We have acquired an educational/hobbyist license to use the Mark XIII release of that software and make it available to others. It is _not_ open source software, however, and not officially part of this project, so we cannot include it on this open-source project site with the rest of emulator files.
The Burroughs Mark XIII software consists of three binary tape image files from a release in 1971. We are making these files available through a
[http://www.phkimpel.us/B5500/webSite/SoftwareRequest.html page on our hosting service]. Go to that page, review and accept the licensing terms (they are not onerous), and download one or more of the tape images. See
[WebUIGettingStarted#Download_the_B5500_System_Software Download the B5500 System Software] below for more instructions.
You will need to download at least the `SYSTEM` tape image, which contains the MCP operating system, compilers, and utilities. The other two images, `SYMBOL1` and `SYMBOL2`, contain source code for the Mark XIII release and are not necessary to run the emulator.
Note that while the emulator files are stored on the web server, the system software (and any other B5500 files you create within the emulator) will be stored locally on your workstation in a browser database, not on the web server. The Cold Loader utility,
[WebUIGettingStarted#Initialize_the_Disk_Subsystem discussed below],
is used to read these images and load them to the emulated disk subsystem within your web browser. We have also developed some utilities that will read and decode the data on these tape images. Those can be found in the *`tools/`* directory.
= Setting Up the Emulator =
This section describes how to set up the emulator and prepare it for use. If you do not already have one of the suitable browsers discussed above, acquire and install one of them before proceeding further.
== Establish the Web Server ==
When first starting out, the easiest thing to do is use our hosting service at http://www.phkimpel.us/B5500/. If you choose this option, nothing else needs to be done to set up a web server, and you can proceed with the next section.
If you want to use your own web server, however, the general steps to set up the emulator files are:
# Create a new virtual directory, say, `/B5500/`, to hold the emulator files.
# Download one of the emulator releases (the one with the highest release-number suffix is usually best) from [https://drive.google.com/folderview?id=0BxqKm7v4xBswM29qUkxPTkVfYzg&usp=sharing our download site].
# Unzip the release into the directory on your server's file system where the virtual directory is mapped. You will need at least the `emulator/` and `webUI/` directories, and they must be at the root of the virtual directory.
== Download the B5500 System Software ==
With a web browser, go to our hosting site at
http://www.phkimpel.us/B5500/webSite/SoftwareRequest.html,
review and accept the Unisys licensing terms, and download the `SYSTEM` tape image to your local workstation. You may also download the `SYMBOL1` and `SYMBOL2` tape images, but these are not required to run the emulator.
Unzip the downloaded files and store the resulting `.bcd` image files somewhere on your local workstation. You will need these files to initialize the disk subsystem, but they are not needed to run the emulator once the disk subsystem has been loaded.
== Initialize the Disk Subsystem ==
The web-based emulator uses the HTML5 IndexedDB API to implement disk storage. This is essentially a small database server embedded within the web browser. The database data is stored on your local workstation, but is usually hidden deep within the profile directory your browser maintains on the workstation for your user account. It typically is not easy to access the physical files for this database, nor is there any need to do so.
=== Default Disk Configuration ===
By default, the emulator is configured to use two B5500 disk Electronic Units (EUs) with 200,000 segments of disk storage each. This is equivalent to a full complement of five Model I Storage Units (SUs) on each EU. That translates to a maximum of 12 million B5500 words (96 million 6-bit characters) of disk storage, or about 100MB of disk space on your workstation.
The emulator will use only the disk space needed to support the disk subsystem, but that space will grow as you add more B5500 files in the disk subsystem. Once disk space on your workstation is allocated to the emulator, it will persist until the next time the disk subsystem is cold-started. Deleting files in the B5500 environment will not reduce the amount of disk space used by the emulator on your workstation, but it will free up space within the disk subsystem that other B5500 files can occupy.
The default configuration also has two Disk File Controls, DKA and DKB, and assumes the presence of a Disk File Exchange between those two controls. If you don't know what this means, don't worry about it -- it just means that the system is capable of supporting two simultaneous I/Os to disk if the I/Os address different EUs.
=== 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.
The Cold Loader script is `B5500ColdLoader.html` in the `webUI/` directory. If you are running the emulator from our hosting site, simply open
http://www.phkimpel.us/B5500/webUI/B5500ColdLoader.html.
The Cold Loader will attempt to open the IndexedDB database used by the emulated subsystem, if one already exists. If no database currently exists, it will create an empty one. After successfully opening or initializing the database, it will display this dialog box:
https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/ColdLoader-Disk-Database-Opened.png
<wiki:comment>
After you dismiss the dialog box, the page will dump the contents of the first 2100 disk segments in the database to your screen. If the database has just been initialized, the display will simply indicate that 2100 segments are available.
</wiki:comment>
_NOTE: You *must* run the Cold Loader from the same web site as you will run the emulator._ You must also use the same web browser.
The IndexedDB API is subject to the "same origin" policy used by many other web browser features. That means that the database used for the disk subsystem is restricted for use only by web pages and scripts from the same Internet host name as the one that created the database. Even though the database is physically stored on your workstation, if you run the Cold Loader from one web site and the emulator from another, they will access two separate databases on that workstation.
This separation due to the same-origin policy also applies to a web server with multiple host names. For example, it is possible to run the Cold Loader using two different URLs for our hosting site, http://www.phkimpel.us/B5500/webUI/B5500ColdLoader.html and http://phkimpel.us.B5500/webUI/B5500ColdLoader.htlm. Both URLs address the same physical script, but accessing the Cold Loader through the two URLs will create two separate databases. We recommend you use the `www.phkimpel.us` hostname when accessing our hosting service.
Finally, different web browsers store their IndexedDB databases differently. A database created by one browser will be inaccessible to another, so you must use the same browser to run the emulator as the one you used to run the Cold Loader.
=== 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.
To cold-start the emulator disk subsystem, click the *Cold Start* button at the top of the browser page:
https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/ColdLoader-Heading.png
The page will request a confirmation that you want to cold-start. If you click *OK*, any previous database for the disk subsystem will be discarded, a new empty one created, and an empty disk directory created. The page will write the initial MCP configuration data and the KERNEL bootstrap program to the disk. It will also establish an initial set of MCP run-time options. These settings can be inspected with the `TO` SPO command and modified with the `RO` and `SO` SPO commands once the MCP is loaded and running.
Note that this process affects only the IndexedDB database used by the emulator. It does not modify, remove, or otherwise affect anything else in your workstation's file system.
If you wish to remove the emulator's disk subsystem from your workstation, you can run the Cold Loader and click the *Delete Disk Subsystem* button on the page. This will remove the IndexedDB database. This operation should be done immediately after initiating the Cold Loader.
=== Loading the System Files ===
The next step is to load the necessary files from the `SYSTEM` tape image. Click the *Browse* or *Choose File* button (which one depends on the browser you are using) in the upper-right corner of the page. That will open a file selection dialog. Navigate to the folder where you have stored the previously-downloaded file for the `SYSTEM` tape image and select that file.
The page will read the directory of files on the tape image and display a list of those files, similar to the following:
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:
* `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.
* `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.
You may wish to select some of the following additional files, depending on how you plan to use the system:
* `BASIC/DISK` -- the BASIC language compiler.
* `COBOL/DISK` -- the original COBOL compiler.
* `COBOL68/DISK` -- the ANSI COBOL-68 compiler.
* `ESPOL/DISK` -- the ESPOL compiler, used to compile the MCP and standalone utility programs.
* `FORTRAN/DISK` -- the FORTRAN-66 compiler.
* `XALGOL/DISK` -- the Compatible Algol compiler. This was a version of Algol designed to ease transition from the B5500 to B6500/6700/7700 systems.
* `AFILTER/DISK` -- the Algol Filter program.
* `CFILTER/DISK` -- the COBOL Filter program.
* `DUMP/ANALYZE` -- the system dump analyzer.
* `FORTRAN/TRANS` -- the FORTRAN-to-Algol translator program.
* `MAKCAST/DISK` -- a program to maintain CAST source library files.
* `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.
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.
= Next Steps =
Once the disk subsystem has been established and cold-started, and at least the minimal set of system files loaded to it, you are ready to run the emulator and "halt/load" (boot) the MCP.
The emulator is initiated from the `B5500Console.html` page in the `webUI/` directory. If you are running the emulator from our hosting site, simply go to
http://www.phkimpel.us/B5500/webUI/B5500Console.html
#summary Instructions for setting up the retro-B5500 emulator in a web browser.
#labels Burroughs,B5500,emulator,retro-b5500,setup,install,getting started
= WebUI Getting Started =
<wiki:toc max_depth="2"/>
= Introduction =
This page describes how to set up the retro-B5500 emulator to run in a web browser.
The emulator consists of a common Javascript core for the mainframe components of the system -- Processor, Central Control, Memory Modules, and Input/Output Units (channels), plus one or more user interfaces. The user interfaces are designed to be pluggable, so it is possible that the common emulator core could be used in multiple environments, each with their own characteristics and facilities for hosting a B5500 emulation.
A user interface (UI) presents the external representation the system and provides the means for you to interact with it. Because the implementation of I/O devices depends heavily on the environment in which the UI operates, a UI also includes all of the I/O devices (disk, card readers, line printers, SPO, etc.) The first UI designed for the emulator is the "WebUI," which designed to run in a web browser. This page describes the setup procedures for that UI.
== Quick-start Overview ==
To set up and use the web-based emulator, you will need to do the following things, which are discussed in more detail below:
* Use a suitable web browser, currently Mozilla Firefox or Google Chrome. See [WebUIGettingStarted#The_Web_Browser The Web Browser] below for details.
* Download and set up the emulator files on a web server. Alternatively, you can use our hosting service at http://www.phkimpel.us/B5500/. See [WebUIGettingStarted#The_Web_Server The Web Server] and [WebUIGettingStarted#The_Emulator_Files The Emulator Files] below for details.
* Download a copy of the Burroughs B5500 system software tape images from http://www.phkimpel.us/B5500/webSite/SoftwareRequest.html. See [WebUIGettingStarted#The_Burroughs_B5500_Software The Burroughs B5500 Software] below for details.
* Run the Cold Loader utility script to initialize the emulated disk subsystem and load the system software to it. See [WebUIGettingStarted#Initialize_the_Disk_Subsystem Initialize the Disk Subsystem] below for details.
* In your web browser, access the *`webUI/B5500Console.html`* page from the web server to run the emulator.
= What You Will Need =
To use the web-based emulator, you will need four things:
# A suitable web browser.
# A web server configured to deliver files from the emulator directories (our hosting site is set up to do this).
# A copy of the files in the `emulator/` and `webUI/` directories from the emulator release (our hosting site already has the current version of these, ready to use).
# A copy of the Burroughs B5500 system software.
Each of these is described in more detail in the following sections.
== The Web Browser ==
The retro-B5500 emulator pushes the limits in several areas of current web-browser technology. We are taking advantage of many features in HTLM5, its related DOM APIs, and CSS 3. As a result, not every web browser is capable of hosting the emulator. We rely, at a minimum, on the following advanced features:
* `IndexedDB` API (used to support the Head-per-Track disk subsystem)
* `ArrayBuffer`, `DataView`, and `Blob` APIs
* `File`, `FileList`, and `FileReader` APIs
* 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.
== The Web Server ==
The emulator must be hosted on a web server. You will not be able to run the emulator simply by opening files in your browser from your local file system. The web server can run on your local system and serve files from there, but the emulator files must be served to the browser over HTTP and not simply opened as files within the browser.
See [WebUIGettingStarted#Establish_the_Web_Server Establish the Web Server]
below for more details.
If you need a small, simple web browser 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:
http://www.phkimpel.us/B5500/
If you choose to use this web site, or any other site that is already set up to serve the emulator files, rather than your own web server, you can skip the next section on downloading the emulator files.
== The Emulator Files ==
The web-based emulator is hosted in two directories (folders) of files:
* *`emulator/`* contains the core mainframe modules. These are Javascript objects for the Processor, Central Control, and I/O Unit, plus a simple object that defines the configuration of the system to be emulated.
* *`webUI/`* contains everything else you need to run the system. In particular, it contains the Console UI, the peripheral device drivers, a Cold Loader utility used to initialize the disk subsystem, and a Syllable Debugger utility that can be used to examine the state of Processor 1 and memory while running programs, including the MCP.
An optional third directory, *`tools/`* contains some standalone utilities that can be used to examine and maintain the emulator environment.
Recent releases of the emulator files can be downloaded from
[https://drive.google.com/folderview?id=0BxqKm7v4xBswM29qUkxPTkVfYzg&usp=sharing our download site]. Each release is packaged as a separate `.zip` file.
If you use a web server where the emulator files are already set up, you do not need to download a separate copy of a release. Unless you are running your web server on the same workstation as your web browser, you do not need to store the emulator files on your workstation.
== The Burroughs B5500 Software ==
The emulator files implement only the hardware portion of a B5500 system. To make the emulator useful, you also need the system software developed by Burroughs.
Burroughs became part of Unisys Corporation in 1986. Unisys still owns and maintains copyrights the B5500 system software. We have acquired an educational/hobbyist license to use the Mark XIII release of that software and make it available to others. It is _not_ open source software, however, and not officially part of this project, so we cannot include it on this open-source project site with the rest of emulator files.
The Burroughs Mark XIII software consists of three binary tape image files from a release in 1971. We are making these files available through a
[http://www.phkimpel.us/B5500/webSite/SoftwareRequest.html page on our hosting service]. Go to that page, review and accept the licensing terms (they are not onerous), and download one or more of the tape images. See
[WebUIGettingStarted#Download_the_B5500_System_Software Download the B5500 System Software] below for more instructions.
You will need to download at least the `SYSTEM` tape image, which contains the MCP operating system, compilers, and utilities. The other two images, `SYMBOL1` and `SYMBOL2`, contain source code for the Mark XIII release and are not necessary to run the emulator.
Note that while the emulator files are stored on the web server, the system software (and any other B5500 files you create within the emulator) will be stored locally on your workstation in a browser database, not on the web server. The Cold Loader utility,
[WebUIGettingStarted#Initialize_the_Disk_Subsystem discussed below],
is used to read these images and load them to the emulated disk subsystem within your web browser. We have also developed some utilities that will read and decode the data on these tape images. Those can be found in the *`tools/`* directory.
= Setting Up the Emulator =
This section describes how to set up the emulator and prepare it for use. If you do not already have one of the suitable browsers discussed above, acquire and install one of them before proceeding further.
== Establish the Web Server ==
When first starting out, the easiest thing to do is use our hosting service at http://www.phkimpel.us/B5500/. If you choose this option, nothing else needs to be done to set up a web server, and you can proceed with the next section.
If you want to use your own web server, however, the general steps to set up the emulator files are:
# Create a new virtual directory, say, `/B5500/`, to hold the emulator files.
# Download one of the emulator releases (the one with the highest release-number suffix is usually best) from [https://drive.google.com/folderview?id=0BxqKm7v4xBswM29qUkxPTkVfYzg&usp=sharing our download site].
# Unzip the release into the directory on your server's file system where the virtual directory is mapped. You will need at least the `emulator/` and `webUI/` directories, and they must be at the root of the virtual directory.
== Download the B5500 System Software ==
With a web browser, go to our hosting site at
http://www.phkimpel.us/B5500/webSite/SoftwareRequest.html,
review and accept the Unisys licensing terms, and download the `SYSTEM` tape image to your local workstation. You may also download the `SYMBOL1` and `SYMBOL2` tape images, but these are not required to run the emulator.
Unzip the downloaded files and store the resulting `.bcd` image files somewhere on your local workstation. You will need these files to initialize the disk subsystem, but they are not needed to run the emulator once the disk subsystem has been loaded.
== Initialize the Disk Subsystem ==
The web-based emulator uses the HTML5 IndexedDB API to implement disk storage. This is essentially a small database server embedded within the web browser. The database data is stored on your local workstation, but is usually hidden deep within the profile directory your browser maintains on the workstation for your user account. It typically is not easy to access the physical files for this database, nor is there any need to do so.
=== Default Disk Configuration ===
By default, the emulator is configured to use two B5500 disk Electronic Units (EUs) with 200,000 segments of disk storage each. This is equivalent to a full complement of five Model I Storage Units (SUs) on each EU. That translates to a maximum of 12 million B5500 words (96 million 6-bit characters) of disk storage, or about 100MB of disk space on your workstation.
The emulator will use only the disk space needed to support the disk subsystem, but that space will grow as you add more B5500 files in the disk subsystem. Once disk space on your workstation is allocated to the emulator, it will persist until the next time the disk subsystem is cold-started. Deleting files in the B5500 environment will not reduce the amount of disk space used by the emulator on your workstation, but it will free up space within the disk subsystem that other B5500 files can occupy.
The default configuration also has two Disk File Controls, DKA and DKB, and assumes the presence of a Disk File Exchange between those two controls. If you don't know what this means, don't worry about it -- it just means that the system is capable of supporting two simultaneous I/Os to disk if the I/Os address different EUs.
=== 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.
The Cold Loader script is `B5500ColdLoader.html` in the `webUI/` directory. If you are running the emulator from our hosting site, simply open
http://www.phkimpel.us/B5500/webUI/B5500ColdLoader.html.
The Cold Loader will attempt to open the IndexedDB database used by the emulated subsystem, if one already exists. If no database currently exists, it will create an empty one. After successfully opening or initializing the database, it will display this dialog box:
https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/ColdLoader-Disk-Database-Opened.png
<wiki:comment>
After you dismiss the dialog box, the page will dump the contents of the first 2100 disk segments in the database to your screen. If the database has just been initialized, the display will simply indicate that 2100 segments are available.
</wiki:comment>
_NOTE: You *must* run the Cold Loader from the same web site as you will run the emulator._ You must also use the same web browser.
The IndexedDB API is subject to the "same origin" policy used by many other web browser features. That means that the database used for the disk subsystem is restricted for use only by web pages and scripts from the same Internet host name as the one that created the database. Even though the database is physically stored on your workstation, if you run the Cold Loader from one web site and the emulator from another, they will access two separate databases on that workstation.
This separation due to the same-origin policy also applies to a web server with multiple host names. For example, it is possible to run the Cold Loader using two different URLs for our hosting site, http://www.phkimpel.us/B5500/webUI/B5500ColdLoader.html and http://phkimpel.us.B5500/webUI/B5500ColdLoader.htlm. Both URLs address the same physical script, but accessing the Cold Loader through the two URLs will create two separate databases. We recommend you use the `www.phkimpel.us` hostname when accessing our hosting service.
Finally, different web browsers store their IndexedDB databases differently. A database created by one browser will be inaccessible to another, so you must use the same browser to run the emulator as the one you used to run the Cold Loader.
=== 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.
To cold-start the emulator disk subsystem, click the *Cold Start* button at the top of the browser page:
https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/ColdLoader-Heading.png
The page will request a confirmation that you want to cold-start. If you click *OK*, any previous database for the disk subsystem will be discarded, a new empty one created, and an empty disk directory created. The page will write the initial MCP configuration data and the KERNEL bootstrap program to the disk. It will also establish an initial set of MCP run-time options. These settings can be inspected with the `TO` SPO command and modified with the `RO` and `SO` SPO commands once the MCP is loaded and running.
Note that this process affects only the IndexedDB database used by the emulator. It does not modify, remove, or otherwise affect anything else in your workstation's file system.
If you wish to remove the emulator's disk subsystem from your workstation, you can run the Cold Loader and click the *Delete Disk Subsystem* button on the page. This will remove the IndexedDB database. This operation should be done immediately after initiating the Cold Loader.
=== Loading the System Files ===
The next step is to load the necessary files from the `SYSTEM` tape image. Click the *Browse* or *Choose File* button (which one depends on the browser you are using) in the upper-right corner of the page. That will open a file selection dialog. Navigate to the folder where you have stored the previously-downloaded file for the `SYSTEM` tape image and select that file.
The page will read the directory of files on the tape image and display a list of those files, similar to the following:
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:
* `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.
* `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.
You may wish to select some of the following additional files, depending on how you plan to use the system:
* `BASIC/DISK` -- the BASIC language compiler.
* `COBOL/DISK` -- the original COBOL compiler.
* `COBOL68/DISK` -- the ANSI COBOL-68 compiler.
* `ESPOL/DISK` -- the ESPOL compiler, used to compile the MCP and standalone utility programs.
* `FORTRAN/DISK` -- the FORTRAN-66 compiler.
* `XALGOL/DISK` -- the Compatible Algol compiler. This was a version of Algol designed to ease transition from the B5500 to B6500/6700/7700 systems.
* `AFILTER/DISK` -- the Algol Filter program.
* `CFILTER/DISK` -- the COBOL Filter program.
* `DUMP/ANALYZE` -- the system dump analyzer.
* `FORTRAN/TRANS` -- the FORTRAN-to-Algol translator program.
* `MAKCAST/DISK` -- a program to maintain CAST source library files.
* `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.
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.
= Next Steps =
Once the disk subsystem has been established and cold-started, and at least the minimal set of system files loaded to it, you are ready to run the emulator and "halt/load" (boot) the MCP.
The emulator is initiated from the `B5500Console.html` page in the `webUI/` directory. If you are running the emulator from our hosting site, simply go to
http://www.phkimpel.us/B5500/webUI/B5500Console.html
See [WebUIRunningTheEmulator WebUI Running the Emulator] for detailed instructions on how to start the emulator and run the emulated B5500 system.

316
WebUIRunningTheEmulator.wiki
View File

@@ -1,159 +1,159 @@
#summary Instructions for running the retro-B5500 emulator in a web browser.
#labels Phase-Deploy
= 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].
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.
= "Powering Up" the Emulator =
The emulator is initiated from the `B5500Console.html` page in the `webUI/` directory of the emulator files on your web server. If you are running the emulator from our hosting site, simply go to
http://www.phkimpel.us/B5500/webUI/B5500Console.html
This page displays a simulated B5500 operator console. The *HALT*, *LOAD SELECT*, *LOAD*, *POWER ON*, and *POWER OFF* indicators are push buttons you can use to control the system. The rest of the indicators are lights controlled by the emulator. For a full description of the console, see [WebUIUsingTheConsole Using the B5500 Console].
https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Console.png
To initialize the emulator, click the *POWER ON* button. The *A CONTROL* light will turn on, and several windows will open for the peripheral devices configured for the system -- SPO, card reader, line printer, etc.
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.
= Halt/Loading the MCP =
The process of loading an operating system into a computer and initiating it is commonly referred to as "booting" the system. On the B5500 (and all Burroughs/Unisys systems that followed it), the process is termed a "halt/load," after the two eponymous buttons on the console. *HALT* stops the system. *LOAD* clears the registers and reads a bootstrap program into memory. The bootstrap for the MCP is known as the KERNEL. For the web-based emulator, the KERNEL is placed on disk by the Cold Loader utility script.
The B5500 supported two types of load. The primary one is from disk and the alternate is from cards, as controlled by the *LOAD SELECT* push button. In its normal position, *LOAD SELECT* causes the system to load 63 segments starting at segment 1 of Electronics Unit (EU) 0. When *LOAD SELECT* is activated (indicated on a real B5500 by being in a depressed position, but on this console by a yellow border) the system loads one binary card from the primary card reader, CRA.
When the SPO window opens, it will print a short message indicating the emulator version. Please wait for this message to finish printing before attempting to load any program, including the MCP.
To load the MCP, make sure the *LOAD SELECT* button is not activated (no yellow border), then click the *LOAD* button. Several white annunciator lights on the lower portion of the console should blink. These annunciators are unique to the emulated console and were not present on a real B5500.
After a few seconds, a message similar to the following should start to appear on the SPO:
{{{
-H/L WITH MCP/DISK MARK XIII MODS RRRRRRRR-
}}}
The string of "`R`"s indicates which of the eight memory modules is on line and ready. After several more seconds, you should see time and date messages appear:
{{{
TIME IS 0814
DATE IS SATURDAY, 7/ 9/83
}}}
Depending on the state of two MCP options (`USE DATE` and `USE TIME`) stored in the configuration data on disk, one or more of the following messages may also appear:
{{{
#DT PLEASE
#TR PLEASE
}}}
= Setting the Date and Time =
The B5500 did not have a persistent clock, just an interval timer. As a result, it was necessary to set the time, and perhaps the date, each time the system was halt/loaded. The two MCP options mentioned above could be set to require the operator to set the time and/or date before the MCP would exit its initialization mode and be ready to run user programs. The messages above indicate which of those options was set. Regardless of those option settings, it is always a good idea to set at least the time immediately after halt/loading the system.
The time is set with the `TR` command. To enter a command, click the *INPUT REQUEST* button on the SPO window. The button will illuminate. When that light goes out and the *REMOTE* button lights (which may take a second or so -- the MCP must first initiate an I/O to the SPO) enter the following, substituting your current time in 24-hour format.
{{{
TR 1457
}}}
The SPO will translate lower-case characters to upper case as you enter them -- you do not need to type commands in upper case. When you have finished entering the command, click the *END OF MESSAGE* button on the SPO window to terminate it. The system will respond by printing the new time on the SPO.
The date is set using the `DT` command. The B5500 was not Year-2000 compliant -- almost no one was looking that far ahead in the 1960s. You can, of course, set a date using the last two digits of the current year (e.g., `13` for 2013), but the system will interpret that as 1913, and the Mark XIII files on disk have dates in the 1970s, so they would appear to have been created some 60 years in the future.
We recommend that you subtract 30 or 40 years from the current date (yielding one in the 1970s or '80s) and use that, but the day of week will be incorrect. It turns out that if you subtract 50 years from the current date, the day of week will be correct, but the system files will still appear to have been created in the future. To set the date, enter a `DT` command with the date in month/day/year format:
{{{
DT 7/13/83
}}}
You can also use hyphens (`-`) instead of slashes (`/`) to separate the fields of the dates. The MCP stores the date on disk and will remember the date across halt/loads.
= Exploring the B5500 Environment =
Once the date and time are properly set, you can begin to use the system. A number of documents on bitsavers.org have useful information:
* The [http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/1031986_B5500_Handbook_Aug70.pdf B5500 Handbook (April 1970)] describes:
* SPO output messages starting on page 4-1.
* SPO commands starting on page 4-23.
* The [http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/1024916_B5500_B5700_OperMan_Sep68.pdf B5500 Operation Manual (September 1968)] has somewhat older information:
* MCP run-time options starting on page 3-26.
* Control card syntax starting on page 4-1.
* Compiler option card ("$-cards") starting on page 4-26.
* SPO output messages starting on page C-1.
* SPO commands starting on page C-40.
* The [http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1023579_Narrative_Description_Of_B5500_MCP_Oct66.pdf Narrative Description of the B5500 MCP] gives a good overview of the MCP and how it operates.
* The [http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/ bitsavers index page for the B5000/B5500/B5700] lists a number of other documents, including reference manuals for the hardware and the compilers.
For more information on operating the SPO, and an overview of MCP commands for the SPO, see the [WebUIUsingTheSPO Using the SPO] page.
You can prepare "card decks" as ordinary text files on your workstation and read them using one of the card reader peripherals, `CRA` or `CRB`. The 64 valid ASCII characters you can use with the emulator are:
{{{
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, so we have chosen the following ASCII equivalents for them:
* `~` for left-arrow
* `|` for "×" (the multiplication sign)
* `{` for less-than-or-equal
* `}` for greater-than-or-equal
* `!` for not-equal
Lower-case letters will be translated to upper case by the card reader. 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 as a control card) but will be allowed as a valid character in any other position. Lines of text longer than 80 characters will be truncated to a length of 80; lines of text shorter than 80 characters will be padded with spaces to a length of 80.
Your "card deck" text files should 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. Here is a sample deck to compile and run a very simple Algol program. The program's output will go to the line printer:
{{{
? COMPILE FIRST/TRY WITH ALGOL GO
? DATA CARD
$ CARD LIST SINGLE
BEGIN
FILE LINE 18 (1, 17);
INTEGER I;
REAL X;
I ~ 7;
X ~ I/30;
WRITE (LINE, <"X = ",F8.5>, X);
END.
? END
}}}
To use the card reader:
* Click the *Browse* or *Choose File* button in the card reader window and select the file you want to read. This will append the text file to the reader's "input hopper."
* Repeat as desired to add more "decks" to the input hopper.
* Click the *START* button to make the reader ready. The *NOT READY* light will go out.
* The MCP should sense the change in status within a second or two and start reading cards. The progress bar below the file selector indicates the relative number of cards remaining in the "input hopper." The last two cards that were read are shown in the box at the bottom of the card reader window.
* After the last card is read from the "input hopper" the reader will go not-ready and the *NOT READY* light will again illuminate.
* You can add more "decks" to the "input hopper" of the reader at any time. If the reader is currently reading cards, simply click the *STOP* button to make it not-ready, add more files to the input hopper, and then click *START* to make it ready again.
* If a deck has control card errors, the MCP will stop reading cards and issue a message on the SPO. You have two choices:
* Enter "`CL CRA`" on the SPO to abort the current "deck." The MCP will read cards without processing them until the next control card and then resume processing the cards normally.
* Click *STOP* to make the reader not ready, then click the progress bar below the file selector. The reader will ask if you want to "empty the input hopper." If you click *OK*, the entire contents of the "input hopper" will be discarded.
= Shutting Down the Emulator =
When you are finished using the emulator, click the *HALT* button on the Console, then click *POWER OFF*. When *POWER OFF* is clicked, the emulator will close all peripheral device windows, but will leave the Console window open.
These steps are not strictly necessary (you can just quit the browser), but they will insure that all outstanding I/Os are completed and the emulator comes to an orderly halt. It will also save you the trouble of closing all of those peripheral device windows.
#summary Instructions for running the retro-B5500 emulator in a web browser.
#labels Burroughs,B5500,emulator,retro-b5500,run,running,operate,start
= 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].
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.
= "Powering Up" the Emulator =
The emulator is initiated from the `B5500Console.html` page in the `webUI/` directory of the emulator files on your web server. If you are running the emulator from our hosting site, simply go to
http://www.phkimpel.us/B5500/webUI/B5500Console.html
This page displays a simulated B5500 operator console. The *HALT*, *LOAD SELECT*, *LOAD*, *POWER ON*, and *POWER OFF* indicators are push buttons you can use to control the system. The rest of the indicators are lights controlled by the emulator. For a full description of the console, see [WebUIUsingTheConsole Using the B5500 Console].
https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Console.png
To initialize the emulator, click the *POWER ON* button. The *A CONTROL* light will turn on, and several windows will open for the peripheral devices configured for the system -- SPO, card reader, line printer, etc.
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.
= Halt/Loading the MCP =
The process of loading an operating system into a computer and initiating it is commonly referred to as "booting" the system. On the B5500 (and all Burroughs/Unisys systems that followed it), the process is termed a "halt/load," after the two eponymous buttons on the console. *HALT* stops the system. *LOAD* clears the registers and reads a bootstrap program into memory. The bootstrap for the MCP is known as the KERNEL. For the web-based emulator, the KERNEL is placed on disk by the Cold Loader utility script.
The B5500 supported two types of load. The primary one is from disk and the alternate is from cards, as controlled by the *LOAD SELECT* push button. In its normal position, *LOAD SELECT* causes the system to load 63 segments starting at segment 1 of Electronics Unit (EU) 0. When *LOAD SELECT* is activated (indicated on a real B5500 by being in a depressed position, but on this console by a yellow border) the system loads one binary card from the primary card reader, CRA.
When the SPO window opens, it will print a short message indicating the emulator version. Please wait for this message to finish printing before attempting to load any program, including the MCP.
To load the MCP, make sure the *LOAD SELECT* button is not activated (no yellow border), then click the *LOAD* button. Several white annunciator lights on the lower portion of the console should blink. These annunciators are unique to the emulated console and were not present on a real B5500.
After a few seconds, a message similar to the following should start to appear on the SPO:
{{{
-H/L WITH MCP/DISK MARK XIII MODS RRRRRRRR-
}}}
The string of "`R`"s indicates which of the eight memory modules is on line and ready. After several more seconds, you should see time and date messages appear:
{{{
TIME IS 0814
DATE IS SATURDAY, 7/ 9/83
}}}
Depending on the state of two MCP options (`USE DATE` and `USE TIME`) stored in the configuration data on disk, one or more of the following messages may also appear:
{{{
#DT PLEASE
#TR PLEASE
}}}
= Setting the Date and Time =
The B5500 did not have a persistent clock, just an interval timer. As a result, it was necessary to set the time, and perhaps the date, each time the system was halt/loaded. The two MCP options mentioned above could be set to require the operator to set the time and/or date before the MCP would exit its initialization mode and be ready to run user programs. The messages above indicate which of those options was set. Regardless of those option settings, it is always a good idea to set at least the time immediately after halt/loading the system.
The time is set with the `TR` command. To enter a command, click the *INPUT REQUEST* button on the SPO window. The button will illuminate. When that light goes out and the *REMOTE* button lights (which may take a second or so -- the MCP must first initiate an I/O to the SPO) enter the following, substituting your current time in 24-hour format.
{{{
TR 1457
}}}
The SPO will translate lower-case characters to upper case as you enter them -- you do not need to type commands in upper case. When you have finished entering the command, click the *END OF MESSAGE* button on the SPO window to terminate it. The system will respond by printing the new time on the SPO.
The date is set using the `DT` command. The B5500 was not Year-2000 compliant -- almost no one was looking that far ahead in the 1960s. You can, of course, set a date using the last two digits of the current year (e.g., `13` for 2013), but the system will interpret that as 1913, and the Mark XIII files on disk have dates in the 1970s, so they would appear to have been created some 60 years in the future.
We recommend that you subtract 30 or 40 years from the current date (yielding one in the 1970s or '80s) and use that, but the day of week will be incorrect. It turns out that if you subtract 50 years from the current date, the day of week will be correct, but the system files will still appear to have been created in the future. To set the date, enter a `DT` command with the date in month/day/year format:
{{{
DT 7/13/83
}}}
You can also use hyphens (`-`) instead of slashes (`/`) to separate the fields of the dates. The MCP stores the date on disk and will remember the date across halt/loads.
= Exploring the B5500 Environment =
Once the date and time are properly set, you can begin to use the system. A number of documents on bitsavers.org have useful information:
* The [http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/1031986_B5500_Handbook_Aug70.pdf B5500 Handbook (April 1970)] describes:
* SPO output messages starting on page 4-1.
* SPO commands starting on page 4-23.
* The [http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/1024916_B5500_B5700_OperMan_Sep68.pdf B5500 Operation Manual (September 1968)] has somewhat older information:
* MCP run-time options starting on page 3-26.
* Control card syntax starting on page 4-1.
* Compiler option card ("$-cards") starting on page 4-26.
* SPO output messages starting on page C-1.
* SPO commands starting on page C-40.
* The [http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1023579_Narrative_Description_Of_B5500_MCP_Oct66.pdf Narrative Description of the B5500 MCP] gives a good overview of the MCP and how it works.
* The [http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/ bitsavers index page for the B5000/B5500/B5700] lists a number of other documents, including reference manuals for the hardware and the compilers.
For more information on operating the SPO, and an overview of MCP commands for the SPO, see the [WebUIUsingTheSPO Using the SPO] page.
You can prepare "card decks" as ordinary text files on your workstation and read them using one of the card reader peripherals, `CRA` or `CRB`. The 64 valid ASCII characters you can use with the emulator are:
{{{
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, so we have chosen the following ASCII equivalents for them:
* `~` for left-arrow
* `|` for "×" (the multiplication sign)
* `{` for less-than-or-equal
* `}` for greater-than-or-equal
* `!` for not-equal
Lower-case letters will be translated to upper case by the card reader. 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 as a control card) but will be allowed as a valid character in any other position. Lines of text longer than 80 characters will be truncated to a length of 80; lines of text shorter than 80 characters will be padded with spaces to a length of 80.
Your "card deck" text files should 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. Here is a sample deck to compile and run a very simple Algol program. The program's output will go to the line printer:
{{{
? COMPILE FIRST/TRY WITH ALGOL GO
? DATA CARD
$ CARD LIST SINGLE
BEGIN
FILE LINE 18 (1, 17);
INTEGER I;
REAL X;
I ~ 7;
X ~ I/30;
WRITE (LINE, <"X = ",F8.5>, X);
END.
? END
}}}
To use the card reader:
* Click the *Browse* or *Choose File* button in the card reader window to open a standard file-picker dialog and select the file you want to read. This will append the text file to the reader's "input hopper." You can select multiple files at one time on the open dialog, but the order that the files will be loaded into the reader is indeterminate.
* Repeat as desired to add more "decks" to the input hopper.
* Click the *START* button to make the reader ready. The *NOT READY* light will go out.
* The MCP should sense the change in status within a second or two and start reading cards. The progress bar below the file selector indicates the relative number of cards remaining in the "input hopper." The last two cards that were read are shown in the box at the bottom of the card reader window.
* After the last card is read from the "input hopper" the reader will go not-ready and the *NOT READY* light will again illuminate.
* You can add more "decks" to the "input hopper" of the reader at any time. If the reader is currently reading cards, simply click the *STOP* button to make it not-ready, add more files to the input hopper, and then click *START* to make it ready again.
* If a deck has control card errors, the MCP will stop reading cards and issue a message on the SPO. You have two choices:
* Enter "`RY CRA`" (ready the reader) or "`CL CRA`" (clear the reader) on the SPO to abort the current "deck." The MCP will read cards without processing them until the next control card and then resume processing the cards normally.
* Click *STOP* to make the reader not ready, then click the progress bar below the file selector. The reader will ask if you want to "empty the input hopper." If you click *OK*, the entire contents of the "input hopper" will be discarded.
= Shutting Down the Emulator =
When you are finished using the emulator, click the *HALT* button on the Console, then click *POWER OFF*. When *POWER OFF* is clicked, the emulator will close all peripheral device windows, but will leave the Console window open.
These steps are not strictly necessary (you can just quit the browser), but they will insure that all outstanding I/Os are completed and the emulator comes to an orderly halt. It will also save you the trouble of closing all of those peripheral device windows.
If you want to restart the emulator later, you can leave the Console window open and simply click *POWER ON* when you are ready to resume. All of the other windows are reopened when the emulator is reinitialized by the *POWER ON* button.

20
WebUIUsingTheCardPunch.wiki
View File

@@ -1,9 +1,11 @@
#summary Instructions for using the card punch with the retro-B5500 emulator in a web browser.
= WebUI Using the Card Punch =
<wiki:toc max_depth="2"/>
= Under Construction =
https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-CardPunch.png
#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
= WebUI Using the Card Punch =
<wiki:toc max_depth="2"/>
= Under Construction =
https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-CardPunch.png

20
WebUIUsingTheCardReader.wiki
View File

@@ -1,9 +1,11 @@
#summary Instructions for using the card reader with the retro-B5500 emulator in a web browser.
= WebUI Using the Card Reader =
<wiki:toc max_depth="2"/>
= Under Construction =
https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-CardReader.png
#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
= WebUI Using the Card Reader =
<wiki:toc max_depth="2"/>
= Under Construction =
https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-CardReader.png

231
WebUIUsingTheConsole.wiki
View File

@@ -1,113 +1,120 @@
#summary Instructions for using the Operator Console of the retro-B5500 emulator in a web browser.
= 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).
https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Console.png
There were lots of lights, buttons, and switches on the maintenance panels in the Display and Distribution (D&D) Unit, but those were intended for use in diagnosing hardware problems, not operating the system. They were usually behind the D&D cabinet door, out of sight, and thanks to an interlock switch on the door, powered off.
The console is the gateway to the web-based emulator. It is initiated from the `B5500Console.html` page in the `webUI/` directory of the emulator files on your web server. If you are running the emulator from our hosting site, simply go to
http://www.phkimpel.us/B5500/webUI/B5500Console.html
= Layout of the Console =
The console was used to power the system on and off, initiate a load (boot) of the operating system, and halt the system. All other operations were handled through the SPO.
From left to right, the controls on the console are:
* *HALT* button -- pressing this black pushbutton halted the system. This initiated a complete termination of all processing. The only way to continue after halting was to press *LOAD* and reboot the system.
* *NOT READY* light -- this yellow indicator was lit when one of the components of the system that did not have its own ready/not ready indicator was in a not-ready or off-line state. It applied to processors, I/O units, memory modules, and the first drum (if present).
* *LOAD SELECT* -- this black button/light controlled whether a load operation read from the first disk^1^ or the first card reader. In its normal position, load was from disk. When pressed, the button latched inward and lit, causing load from cards. For the web-based console, the depressed position is indicated by a yellow border around the button.
* *LOAD* -- pressing this black pushbutton cleared all registers in the system and initiated a load operation. When loading from disk, 63 sectors (1890 words) were read into memory starting at location 20 octal. When loading from cards, one binary card was read starting at location 20 octal. If the read was successful, Processor 1 then started executing at that address.
* *MEMORY CHECK* -- this yellow light illuminated when a memory parity error was detected by either processor.
* *A NORMAL* -- this yellow light illuminated when Processor A was operating in Normal State (i.e., running user code).
* *A CONTROL* -- this yellow light illuminated when Processor A was operating in Control State (i.e., running MCP code).^2^
* *B NORMAL* -- this yellow light illuminated when Processor B was operating in Normal State.
* *B CONTROL* -- this yellow light illuminated when Processor B was operating in Control State.
* *POWER ON* -- pressing this white light/button initiated a power-up sequence for the system. The button was illuminated when power was applied to the system. In the web-based emulator, pressing this button initializes the internal emulator components and opens a series of sub-windows for the peripheral devices configured for the system -- SPO, card reader, card punch, line printer, etc..
* *POWER OFF* -- pressing this black pushbutton initiated a power shutdown sequence for the system. In the web-based emulator, pressing this button halts the processor(s) and closes the peripheral sub-windows.
When the emulator is first loaded into a browser, only the *POWER ON* button is activated. Once power is applied and the emulator is initialized, the *POWER OFF* and *LOAD* buttons become active and *POWER ON* is disabled. Once *LOAD* is pressed, *HALT* becomes active and *LOAD* is deactivated. When power is applied, *POWER OFF* can be pressed at any time, even when the system is running programs.
When the SPO window opens, it will print a short message indicating the emulator version. Please wait for this message to finish printing before attempting to press the *LOAD* button.
Once you load the system, there is nothing you need to do with the console, except watch the pretty lights, until you are ready to halt the system. The SPO window will probably be the one you use the most.
The emulator, like the B5500, is fairly robust. You can halt or power off the system at any time. You can even just quit the browser at any time. We recommend, however that you do an orderly shutdown when you are finished with the system -- press *HALT*, then *POWER OFF*, then quit the browser if desired.
You may move and resize the emulator windows in any way you wish, including the console window. You may also minimize any of the windows, but _do not close the peripheral windows._ Closing one of these will render that device inoperable until the emulator is reinitialized with the *POWER ON* button.
Some web browsers, particularly Firefox, slow the execution of Javascript scripts when they run in a non-active tab of a window. The emulator has a performance throttling mechanism that attempts to run the B5500 processor at its real speed. To keep this mechanism from falling behind in terms of real time, do not open the B5500 Console in a window with multiple tabs where one of the other tabs is the active one. It is best to open the Console in its own window, or at least keep it as the active tab in a window. If you need to use the browser to access other web sites at the same time the emulator is running, it is best to open separate browser windows to do so.
See the [WebUIRunningTheEmulator Running the Emulator] page for more information on using the console to start the emulator and operate it.
= Emulator Features Added to the Console =
Since the emulator is not a physical system, it is often difficult to tell exactly what is happening with it. 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 this additional information, you can toggle its display off and on by clicking the Burroughs logo.
The console displays the current version of the emulator below the Burroughs logo and to the left of the retro-B5500 logo.
The console attempts to update its display every 50 milliseconds. This update period applies not only to the annunciators below, but also to the A/B Normal/Control lights described above. Generally, an annunciator is lit if the corresponding element of the system had any activity since the last update of the display.
The top row of annunciators displays activity for the I/O Units (channels) and external interrupts for the system:
* `IOU1` -- I/O unit 1 busy (i.e., an I/O was active on this unit)
* `IOU2` -- I/O unit 2 busy
* `IOU3` -- I/O unit 3 busy
* `IOU4` -- I/O unit 4 busy
* `TIMR` -- Interval timer interrupt (every 1.067 [64/60] second)
* `IOBZ` -- I/O busy interrupt (i.e., no I/O unit available)
* `KBD ` -- Keyboard request interrupt
* `PR1F` -- Printer 1 finished interrupt
* `PR2F` -- Printer 2 finished interrupt
* `IO1F` -- I/O unit 1 finished interrupt
* `IO2F` -- I/O unit 2 finished interrupt
* `IO3F` -- I/O unit 3 finished interrupt
* `IO4F` -- I/O unit 4 finished interrupt
* `P2BZ` -- Processor 2 busy interrupt
* `INQ ` -- Remote inquiry request interrupt
* `SPEC` -- Special interrupt #1 (not used)
* `DK1F` -- Disk file #1 read check finished
* `DK2F` -- Disk file #2 read check finished
The second row of annunciators displays activity for the peripheral devices in the system:
* `DRA` -- Drum #1
* `DRB` -- Drum #2
* `DKA` -- Head-per-Track disk control #1
* `DKB` -- Head-per-Track disk control #2
* `SPO` -- Supervisory keyboard/printer
* `CPA` -- Card punch
* `CRA` -- Card reader #1
* `CRB` -- Card reader #2
* `LPA` -- Line Printer #1
* `LPB` -- Line Printer #2
* `DCA` -- Data Communications Adapter
* `PRA` -- Paper tape reader #1
* `PRB` -- Paper tape reader #2
* `PPA` -- Paper tape punch #1
* `PPB` -- Paper tape punch #2
* `MTA`-`MTT` Magnetic tape units 1-16 (letters `G`, `I`, `O`, `Q` are not used)
At the far right of the lower portion of the console are two statistics that indicate how well the emulator for Processor 1 is performing:
* *P1 Slack*: the average percentage of time the emulated processor is delaying its execution in order to throttle its performance to that of a real B5500. Numbers closer to 100% indicate the processor emulation is using relatively small amounts of your workstation's physical processor. Numbers closer to zero indicate the emulator is barely able (or perhaps unable) to run at the speed of a real B5500.
* *P1 Delay* the average amount of time (in milliseconds) the processor emulation is delayed during throttling _in excess of_ the amount of time it requested to be delayed. This is a running average over the last 1000 delays, and is an indication of how precise the Javascript `setTimeout()` implementation is for your browser.
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 processing takes place on one Javascript thread, and shorter delays allow the emulation to switch among processor and I/O tasks more efficiently.
Note that on most Windows systems, at least through Windows 7, the default precision is about 15ms, and you will typically see average delays in the 7-8ms range. Google Chrome is known to mess with the Windows timer mechanism beneficially, however, and typically meets the HTML5 requirement. Curiously, Chrome's effect on the Windows timer is system-wide -- if you run the emulator in Firefox at the same as Chrome is active in your workstation, the average delay in Firefox will be about the same as it is for Chrome.
`____________`
^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.
#summary Instructions for using the Operator Console of the retro-B5500 emulator in a web browser.
#labels Burroughs,B5500,emulator,retro-b5500,operator,console
= WebUI Using the B5500 Console =
<wiki:toc max_depth="2"/>
Compared to virtually ever other computer system of the 1960s, the Burroughs B5500 had an extraordinarily minimalist operator console -- just five buttons and six lights, plus a few more on the Teletype SPO (supervisory keyboard/printer). The best image we have of the console is from a 1964 Burroughs brochure for the system:
https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Console-Image.jpg
That image shows the original device used for the SPO, a Smith-Corona electric typewriter, which was replaced later by a Teletype Model 33 KSR device.
We have tried to be faithful to the design of the console in our representation of it for the web-based user interface:
https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Console.png
There were lots more lights, buttons, and switches on the maintenance panels in the Display and Distribution (D&D) Unit, but those were intended for use in maintenance and diagnosing hardware problems, not operating the system. They were usually behind the D&D cabinet door, out of sight, and thanks to an interlock switch on the door, powered off.
The console is the home page for the web-based emulator. It is initiated from the `B5500Console.html` page in the `webUI/` directory of emulator files on your web server. If you are running the emulator from our hosting site, simply go to
http://www.phkimpel.us/B5500/webUI/B5500Console.html
= Layout of the Console =
The console was used to power the system on and off, initiate a load (boot) of the operating system, and halt the system. All other operations were handled through the SPO.
From left to right, the controls on the console are:
* *HALT* button -- pressing this black pushbutton halted the system. This initiated a complete termination of all processing. The only way to continue after halting was to press *LOAD* and reboot the system.
* *NOT READY* light -- this yellow indicator was lit when one of the components of the system that did not have its own ready/not ready indicator was in a not-ready or off-line state. It applied to processors, I/O units, memory modules, and the first drum (if present).
* *LOAD SELECT* -- this black button/light controlled whether a load operation read from the first disk^1^ or the first card reader. In its normal position, load was from disk. When pressed, the button latched inward and lit, causing load from cards. For the web-based console, the depressed position is indicated by a yellow border around the button.
* *LOAD* -- pressing this black pushbutton cleared all registers in the system and initiated a load operation. When loading from disk, 63 sectors (1890 words) were read into memory starting at location 20 octal. When loading from cards, one binary card was read starting at location 20 octal. If the read was successful, Processor 1 then started executing at that address.
* *MEMORY CHECK* -- this yellow light illuminated when a memory parity error was detected by either processor.
* *A NORMAL* -- this yellow light illuminated when Processor A was operating in Normal State (i.e., running user code).
* *A CONTROL* -- this yellow light illuminated when Processor A was operating in Control State (i.e., running MCP code).^2^
* *B NORMAL* -- this yellow light illuminated when Processor B was operating in Normal State.
* *B CONTROL* -- this yellow light illuminated when Processor B was operating in Control State.
* *POWER ON* -- pressing this white light/button initiated a power-up sequence for the system. The button was illuminated when power was applied to the system. In the web-based emulator, pressing this button initializes the internal emulator components and opens a series of sub-windows for the peripheral devices configured for the system -- SPO, card reader, line printer, etc..
* *POWER OFF* -- pressing this black pushbutton initiated a power shutdown sequence for the system. In the web-based emulator, pressing this button halts the processor(s) and closes the peripheral sub-windows.
When the emulator is first loaded into a browser, only the *POWER ON* button is activated. Once power is applied and the emulator is initialized, the *POWER OFF* and *LOAD* buttons become active and *POWER ON* is disabled. Once *LOAD* is pressed, *HALT* becomes active and *LOAD* is deactivated. When power is applied, *POWER OFF* can be pressed at any time, even when the system is running programs.
When the SPO window opens, it will print a short message indicating the emulator version. Please wait for this message to finish printing before attempting to press the *LOAD* button.
Once you load the system, there is nothing you need to do with the console, except watch the pretty lights, until you are ready to halt the system. The SPO window will probably be the one you use the most.
The emulator, like the B5500, is fairly robust. You can halt or power off the system at any time. You can even just quit the browser at any time. We recommend, however that you do an orderly shutdown when you are finished with the system -- press *HALT*, then *POWER OFF*, then quit the browser if desired.
You may move and resize the emulator windows in any way you wish, including the console window. You may also minimize any of the windows, but _do not close the peripheral windows._ Closing one of these will render that device inoperable until the emulator is reinitialized with the *POWER ON* button.
Some web browsers, particularly Firefox, slow the execution of Javascript scripts when they run in a non-active tab of a window. The emulator has a performance throttling mechanism that attempts to run the B5500 processor at its real speed. To keep this mechanism from falling behind in terms of real time, do not open the B5500 Console in a window with multiple tabs where one of the other tabs is the active one. It is best to open the Console in its own window, or at least keep it as the active tab in a window. If you need to use the browser to access other web sites at the same time the emulator is running, it is best to open separate browser windows to do so.
See the [WebUIRunningTheEmulator Running the Emulator] page for more information on using the console to start the emulator and operate it.
= Emulator Features Added to the Console =
Since the emulator is not a physical system, it is often difficult to tell exactly what is happening when it runs. To give a better view of what is happening within the system (and just because it was kind of a cool thing to do), the emulator displays a series of white annunciator lights in two rows below the standard buttons and lights. If you are a purist and don't want to see these additional lights, you can toggle their display off and on by clicking the Burroughs logo.
The console displays the current version of the emulator below the Burroughs logo and to the left of the retro-B5500 logo.
The console attempts to update its display every 50 milliseconds. This update period applies not only to the annunciators below, but also to the A/B Normal/Control lights described above. Generally, an annunciator is lit if the corresponding element of the system had any activity since the last update of the display.
The top row of annunciators displays activity for the I/O Units (channels) and external interrupts for the system:
* `IOU1` -- I/O unit 1 busy (i.e., an I/O was active on this unit)
* `IOU2` -- I/O unit 2 busy
* `IOU3` -- I/O unit 3 busy
* `IOU4` -- I/O unit 4 busy
* `TIMR` -- Interval timer interrupt (every 1.067 [64/60] second)
* `IOBZ` -- I/O busy interrupt (i.e., no I/O unit available)
* `KBD ` -- Keyboard request interrupt
* `PR1F` -- Printer 1 finished interrupt
* `PR2F` -- Printer 2 finished interrupt
* `IO1F` -- I/O unit 1 finished interrupt
* `IO2F` -- I/O unit 2 finished interrupt
* `IO3F` -- I/O unit 3 finished interrupt
* `IO4F` -- I/O unit 4 finished interrupt
* `P2BZ` -- Processor 2 busy interrupt
* `INQ ` -- Remote inquiry request interrupt
* `SPEC` -- Special interrupt #1 (not used)
* `DK1F` -- Disk file #1 read check finished
* `DK2F` -- Disk file #2 read check finished
The second row of annunciators displays activity for the peripheral devices in the system:
* `DRA` -- Drum #1
* `DRB` -- Drum #2
* `DKA` -- Head-per-Track disk control #1
* `DKB` -- Head-per-Track disk control #2
* `SPO` -- Supervisory keyboard/printer
* `CPA` -- Card punch
* `CRA` -- Card reader #1
* `CRB` -- Card reader #2
* `LPA` -- Line Printer #1
* `LPB` -- Line Printer #2
* `DCA` -- Data Communications Adapter
* `PRA` -- Paper tape reader #1
* `PRB` -- Paper tape reader #2
* `PPA` -- Paper tape punch #1
* `PPB` -- Paper tape punch #2
* `MTA`-`MTT` Magnetic tape units 1-16 (letters `G`, `I`, `O`, and `Q` are not used)
At the far right of the lower portion of the console are two statistics that indicate how well the emulator for Processor 1 is performing:
* *P1 Slack:* the average percentage of time the emulated processor is delaying its execution in order to throttle its performance to that of a real B5500. Numbers closer to 100% indicate the processor emulation is using relatively small amounts of your workstation's physical processor. Numbers closer to zero indicate the emulator is barely able (or perhaps unable) to run at the speed of a real B5500.
* *P1 Delay:* the average amount of time (in milliseconds) the processor emulation is delayed during throttling _in excess of_ the amount of time it requested to be delayed. This is a running average over the last 1000 delays, and is an indication of how precise the Javascript `setTimeout()` implementation is for your browser.
The delay number is typically about half the browser's actual precision, plus one or two milliseconds. HTLM5 standards specify that browsers must have a precision of at least four milliseconds, so you should see values in the 3-4ms range for a compliant browser. Lower values are better, as all of the emulation takes place on one Javascript thread, and shorter delays allow the emulation to switch among processor and I/O tasks more efficiently.
Note that on most Windows systems, at least through Windows 7, the default timer precision is about 15ms, and you typically should see average delays in the 7-8ms range. Google Chrome is known to mess with the Windows timer mechanism beneficially, however, and meets the HTML5 requirement. Curiously, Chrome's effect on the Windows timer is system-wide -- if you run the emulator in Firefox at the same as Chrome is active in your workstation, the average delay in Firefox will be about the same as it is for Chrome.
`____________`
^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.

295
WebUIUsingTheSPO.wiki
View File

@@ -1,143 +1,152 @@
#summary Instructions for using the SPO (supervisory keyboard/printer) with the retro-B5500 emulator in a web browser.
= WebUI Using the SPO =
<wiki:toc max_depth="2"/>
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 persisted with Burroughs systems long after the mechanical keyboard/printers were no longer used and the operator interface transitioned to a video terminal.
= Background =
Initially on the B5000 and early B5500s the SPO was a Smith-Carona electric typewriter, modified to interface with the system's I/O Control Units. Later, Burroughs started using a standard Teletype Model 33 KSR device, with a panel of control buttons installed where a modem would normally be. The printer and control buttons looked very similar to the interface we have developed for the web-based emulator:
https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-SPO.png
The SPO was intended solely as an operational control device and not as a timesharing terminal. Programs could communicate with the SPO, but since the system typically ran multiple jobs at once, access to the SPO had to be shared on a non-conflicting basis. While it was possible to compile and run programs from the SPO (assuming the source or object code was already on disk), one did not sit at the SPO to, say, edit source code.
The SPO was a peripheral device, and interfaced both physically and electronically to the rest of the system the same way that a tape drive or card reader would. It sat on the short end of the L-shaped operator console desk. Below it was a logic rack that adapted the Teletype interface signals to those of the system's I/O Units.
Since the SPO was very slow -- 10 cps -- 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 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 the whole system or a specified task.
In order to read from the SPO keyboard, the system had to select an I/O unit and initiate a read operation to the SPO. To signal the MCP when this was needed, there was a special Keyboard Request interrupt, triggered by the *INPUT REQUEST* button one the SPO control panel, as discussed below.
= SPO Control Panel =
The Model 33 teletype had a rotary off/local/remote switch on its front bezel, below the keyboard. This was typically left in the "remote" position unless the system was being powered down completely. The emulator does not implement this.
The Model 33 had a space on the right side of its case where interface equipment could be installed. This was often used for a dial modem. The units for the B5500 had a special panel installed in this space that had ten button/light controls in two columns of five. Three of the button/lights were blank and unused. The rest were labeled as follows:
* *POWER* -- this black light illuminated when power was applied to the device.
* *READY* -- this yellow light illuminates when the system initiates a read operation in response to the *INPUT REQUEST* button being pressed.
* *REMOTE* -- this yellow button/light indicates the device is on-line to the rest of the system. If the device is off-line, pressing the button makes it on-line.
* *LOCAL* -- this yellow button/light indicates the device is off-line to the rest of the system. If the device is on-line, pressing the button makes it off-line. When the device was off-line, the operator could type comments onto the paper, which would not be transmitted to the system.
* *INPUT REQUEST* this yellow button/light was used to set the Keyboard Request interrupt. This in turn would request attention from the MCP so that it would initiate a read operation for the keyboard. When pressed, the button would light, and remain lit until the system initiated the read operation, at which point the light would go out and the *READY* light would come on.
* *END OF MESSAGE* -- after entering a command on the keyboard, the operator pressed this yellow button to terminate the input and signal the system that the command was complete. This would also extinguish the *READY* light.
* *ERROR* -- if the operator made a mistake while entering a command, they could press this yellow button to cancel what had been entered. The MCP would ignore what had been typed to that point and reinitiate a read operation to the device. To cancel a partially-entered command and not reenter it, press *ERROR*, and then when *READY* comes back on, press *END OF MESSAGE*.
The emulated SPO supports a few user-interface features that the Teletype Model 33 device did not:
# When the SPO window has the focus, you can press the ESC key instead of the *INPUT REQUEST* button to request input to the system. The *INPUT REQUEST* button will light as if it had been pressed.
# You can press the Enter key on your keyboard instead of the *END OF MESSAGE* button to end a message.
# When the *READY* light is on and the SPO window has the focus, you can press the ESC key to cancel your input instead of the *ERROR* button. In either case, the carriage will start a new line and the *READY* light will eventually come on again to allow you to reenter your command.
# Lower-case letters will be translated to upper case as you type them. Neither the B5500 nor the Model 33 supported lower case.
# When entering a command, you can press the Backspace key to correct errors. The Model 33 could not backspace.
# You can type faster than 10 characters per second. The SPO only prints at 10 cps, but it will eventually catch up.
= Tips for Using the SPO =
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.
The frame for 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 of 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 either need to click on the SPO window itself before pressing ESC, or click the *INPUT REQUEST* button with your pointing device.
= An Overview of MCP SPO Commands =
The basic commands you will need to operate the B5500 emulator in a batch environment are listed below. This list does not include any of the data communications or timesharing-specific commands. More complete documentation for the SPO commands and output messages can be found in a couple of documents on bitsavers.org:
* [http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/1031986_B5500_Handbook_Aug70.pdf B5500 Handbook (April 1970)] describes:
* SPO commands starting on page 4-23
* SPO output messages starting on page 4-1.
* [http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/1024916_B5500_B5700_OperMan_Sep68.pdf B5500 Operation Manual (September 1968)] has somewhat older information:
* SPO commands starting on page C-40
* SPO output messages starting on page C-1
The B5500 MCP used a terse set of operator commands based on two letter mnemonic codes. Some commands consisted only of their mnemonic code; other commands required operands after the mnemonic.
In the discussion below, the term _program_ refers to a executable file, i.e., a codefile. The term _job_ refers to an instance of a program executing (or having been scheduled for execution) in the "mix" -- the collection of tasks currently executing in the system. One program could be associated with multiple jobs in the mix and/or the schedule at the same time.
Commands that affected a specific job in the system must be prefixed by that job's "mix number," a one- or two-digit integer assigned to the job by the MCP when the job initiates. This mix number is identified as `<mix>` in the descriptions below.
Peripheral devices are referred to by a three letter mnemonic:
* `SPO` -- the SPO
* `CRA`, `CRB` -- card readers 1 and 2
* `CDA`-`CD9` -- pseudo readers 1-32 (for spooled card decks -- letters `I` and `O`, and digits `0` and `1` not used)
* `CPA` -- the card punch
* `LPA`, `LPB` -- line printers 1 and 2
* `MTA`-`MTT` -- magnetic tape units 1-16 (letters `G`, `I`, `O`, and `Q` not used)
* `DCA` -- data communications adapter
* `PRA`, `PRB` -- paper tape readers 1 and 2
* `PPA`, `PPB` -- paper tape punches 1 and 2
* `DKA`, `DKB` -- head-per-track disk control units 1 and 2
* `DRA`, `DRB` -- drum units 1 and 2
If you enter an invalid SPO command, or one that has errors in its syntax or operands, the MCP typically responds with just `INV KBD` -- invalid keyboard entry.
|| `<mix>AX` || "Accept" -- reply to an `ACCEPT` statement executed by the specified mix index, e.g., `3AXNO`. The text following `AX` is made available to the program. ||
|| `<mix>BK` || 'Break" -- clear messages queued only for the specified mix number, e.g., `5BK`. When used without a mix number, clears the SPO output queue for the entire system. ||
|| `CC` || "Control Card" -- enter control card syntax directly on the SPO. "`?`" can be used instead of `CC`. Semicolons (`;`) can be used to delimit multiple control statements on one line (72 character, max). The MCP will continue issuing reads to the SPO until and `END` statement or a syntax error is encountered. ||
|| `CD` || "Card Decks" -- list deck number and first card image of each "pseudo" card deck currently queued on disk by the `LDCNTRL/DISK` input spooler, e.g., `CD`. ||
|| `CL` || "Clear Unit" -- reset the MCP status of the specified unit mnemonic (e.g., `CL CRA`, `CL MTB`) and DS-es (aborts) any job to which the unit is currently assigned. In the case of card readers, the MCP will read and ignore all cards until the next control card (one with an invalid character in column 1). ||
|| `<mix>CT` || "Change Times" -- change the processor and I/O time limits for the specified mix number, e.g., "`3CT 300,60`". The integers specify limits for processor and I/O time, respectively, in seconds. Either time may be omitted, but the comma is required if the I/O time is specified. ||
|| `<mix>CU` || "Core Usage" -- display memory use in words for the specified mix number, e.g., `3CU`. When used without a mix number, displays memory use for all jobs in the system. ||
|| `<mix>DS` || "Discontinue" -- abort the job with the specified mix number, e.g. `2DS`. Pronounced "dee ess." ||
|| `DT` || "Date" -- change the system date, e.g., `DT 7/20/83. The date must be written in month/day/year format, using either "`/`" or "`-`" as a delimiter between the date parts. The year must be two digits, and will be interpreted as a 1900-relative year. The B5500 was not Y2K compliant, as no systems were known still to be running in 2000. ||
|| `ED` || "Eliminate Deck" -- discard a spooled card deck that has been assigned to the specified pseudo reader, e.g., `ED CDA`. ||
|| `<mix>ES` || "Eliminate from Schedule" -- terminate a job that has been scheduled but not yet begun execution. `DS` cannot be used in this case because the job is in the schedule, not yet in the mix. The mix number is actually a schedule index, e.g., `3ES`. ||
|| `<mix>FM` || "Form Message" -- reply to a `#FM RQD` message when output is to be printed on special forms by assigning a printer to the specified mix number, e.g., `5FM LPA`. Presumably the operator previously loaded the necessary forms into that printer. ||
|| `<mix>FR` || "Final Reel" -- reply to a `#NO FIL` message for an unlabeled tape file to inform the system that no more reels of tape are to be read, e.g., `4FR`. This causes the job for the specified mix number to receive an EOF result on the pending read. ||
|| `<mix>IL` || "Ignore Label" -- reply to a `#NO FIL` or `#DUP FIL` message when the system cannot find a peripheral unit with media labeled to match the file name requested by the job with the specified mix number. Assigns a specified unit to that job regardless of how the media on that unit is labeled, e.g., `3IL MTB` or `2ILCRA`. ||
|| `<mix>IN` || "Insert Number" -- store a one-word binary unsigned integer value into a PRT location (designated in octal) for the specified mix number, e.g., `4IN 25=33`. This was typically used to asynchronously supply a dynamic parameter to a job, but the job had to sample the PRT location periodically in order to get the value. ||
|| `LD` || "Load Decks" -- initiate the `LDCNTRL/DISK` input spooler to read decks from a card reader or magnetic tape labeled `CONTROL/DECK` and store them either on disk or another magnetic tape for ultimate use by a pseudo reader. `LD DK` stores decks on disk; `LD MT` stores decks on tape. See [WebUIUsingTheCardReader Using the Card Reader] for more information on how to label a card reader for use with this command. ||
|| `LN` || "Log New" -- transfer the contents of the `SYSTEM/LOG` file to a new file, e.g., `LN`. The new file is named _mmddccc_`/SYSLOG`, where _mm_ is the current month, _dd_ is the current date of month, and _ccc_ is a log sequence number assigned by the MCP. ||
|| `MX` || "Mix" -- list all of the jobs currently running in the mix, e.g., `MX`. Each job is listed as _p_`:`_mfid_`/`_fid_`=`_mm_, where _p_ is the priority (0=highest, 9=lowest), _mfid_`/`_fid_ is the program name, and _mm_ is the mix number. ||
|| `<mix>OF` || "Optional File" -- reply to a `#NO FIL` message from a COBOL job when the requested file is not present and will not be provided to the job, e.g., `7OF`. This causes the `OPEN` statement in the COBOL program to succeed and for the program to receive an EOF result on the first read of the file. ||
|| `<mix>OK` || "Okay, Try Again" -- reply to a job that has been suspended by the operator, or is waiting for some resource (such as a file or available space on disk) to be made available, e.g., `4OK`. If the program was suspended by the operator with a `ST` command, it resumes execution. If the program was suspended due to an unavailable resource, the system checks again for the resource. If it is available, the program resumes execution, otherwise it remains suspended. The system typically recognized newly-available resources and resumed suspended programs automatically, so this command was seldom required except to resume after an `ST` command. ||
|| `OL` || "Observe Label" -- display the current status of the specified peripheral device, including the name of any media currently mounted on it, e.g., `OL MTD`. ||
|| `<mix>OT` || "Output Value" -- display the value of a PRT location (specified in octal) for the specified mix number, e.g., `3OT26`. The first location available for variables declared in a program was octal 25. When compiling a program, `OT25` indicates the number of syntax errors encountered thus far. For most compilers, `OT27` indicates the sequence number of the record currently being scanned. ||
|| `<mix>OU` || "Output Unit" -- reply to a `#LP RQD` or `#LP PBT MT RQD` message from the specified mix number to supply the physical output medium for a job's printer file if the `PBDONLY` option is not set and no line printer is currently available, e.g., `5OU MT` for a printer-backup tape. ||
|| `PB` || "Print Backup" -- initiate printing of printer or punch data that has been spooled to disk or tape, e.g., `PB MTC` for a printer-backup tape, or `PB 231` for a backup file on disk. Printer- and punch-backup files on disk are named `PBD/`_nnnnsss_ and `PUD/`_nnnnsss_, respectively, where _nnnn_ is a backup-file number assigned by the MCP and _sss_ is a sequence number also assigned by the MCP. The _nnnn_ number is the one used with a `PB` command. Large printer files were broken up into multiple physical files on disk, all having the same _nnnn_ value but different _sss_ values. The MCP automatically prints all files having the same _nnnn_ value. ||
|| `PD` || "Print Directory" -- list the names of files on disk matching the pattern specified by the operand. Disk files have two-level names, termed the multiple-file ID (MFID) and file ID (FID). Possible search patterns are `PD `_mfid_`/`_fid_, `PD `_mfid_`/=` (or `PD `_mfid_`=` or just `PD `_mfid_), `PD =/`_fid_ (or `PD =`_fid_), or `PD =/=` (or just `PD =`. ||
|| `PG` || "Purge" -- purge a magnetic tape volume (reel) by writing a "scratch" label on it, and optionally assign a five-digit volume number in the process, e.g., `PG MTA` or `PG MTD-12345`, where `12345` is the volume number and the dash is required. ||
|| `<mix>PR` || "Priority" -- change the priority of a job in the mix, e.g., `4PR=6`. The highest priority is 0 and the lowest is 9. ||
|| `<mix>PS` || "Priority in Schedule" -- change the priority of a job that is in the schedule, similar to the `PR` command, e.g., `5PS=7`. The mix number is actually a schedule index. ||
|| `QT` || "Quit Output" -- stop printing or punching the spooled file being output to the designated peripheral unit, e.g., `QT LPB` or `QT CPA`. Can also be entered with the mix number of the spooler job, e.g., `3QT`. The backup file on disk or tape is merely skipped, not purged. ||
|| `RD` || "Remove Decks" -- removes spooled card decks from disk if they have not yet been assigned to a pseudo reader. The decks are identified by their deck number, as displayed by the `CD` command, e.g., `RD #203, #207, #216`. ||
|| `<mix>RM` || "Remove" -- resolve a duplicate-file condition, where a job is attempting to lock a new file into the disk directory, but a file of the same name already exists on disk. If the command is entered in response to this condition (e.g., `3RM`), the existing file on disk will be replaced by the new one. The alternative is to `DS` the program, which will leave the existing file in place. ||
|| `RN` || "Reader Number" -- set the number of active pseudo readers (input deck de-spoolers) for the system, e.g., `RN 2`. Setting the number to zero inhibits further decks from being de-spooled. Can also be entered with a deck number, e.g., `RN #204`, to load the specified deck into a pseudo reader. This latter form is normally used only with shared-disk systems. ||
|| `RO` || "Reset Option" -- reset one of the MCP options, e.g., `RO USE AUTOPRNT` ||
|| `RW` || "Rewind Unit" -- rewind and logically "lock" the tape drive designated by the operand, e.g., `RW MTB`. The unit must not currently be assigned to a job. A "locked" unit cannot be assigned to a job by the system until either the operator enters an `RY` command referencing the unit, or the unit is made not-ready and then ready again (so that the MCP would sense the status change). `RW` was often used to keep the system from using a mounted scratch tape until the operator was ready for it to be assigned to a specific job. ||
|| `RY` || "Ready Unit" -- force the MCP to recognize a change in the status of the designated units, as if the units had been made not-ready and then ready again, so that the MCP would sense the status change, e.g., `RY MTD`, `RY CRA CRA CPA`. Readying a card reader that has been labeled but not yet referenced causes the `LABEL` or `?DATA` card to be ignored. ||
|| `SF` || "Set Factor" -- set the Multiprocessing Factor for the system, a real number with at most two digits before and two digits after the decimal point, e.g., `SF 1.25`. This is essentially a fudge factor by which the amount of available physical memory is multiplied when determining whether a job can be moved out of the schedule and into the mix. ||
|| `SO` || "Set Option" -- set one of the MCP options, e.g., `SO USE TIME` ||
|| `<mix>ST` || "Suspend Task" -- suspend the job for the specified mix number, e.g., `5ST`. The job stays in the mix, but does not consume any processor time. The job may be resumed with an `OK` command or terminated with a `DS` command. ||
|| `SV` || "Save Unit" -- mark a peripheral device as unavailable for assignment to a job. If the unit is currently assigned to a job, it becomes unavailable for further assignment when it is released by that job. ||
|| `TF` || "Type Factor" -- display the current Multiprocessing Factor as set by the `SF` command. ||
|| `<mix>TI` || "Times" -- display the running times for the job with the specified mix number, e.g., `3TI`. The processor, I/O (channel), and elapsed times, respectively, are displayed in _hours_:_minutes_:_seconds_ format, e.g., `CP= 1:41, IO= 8 IN 1:44` ||
|| `<mix>TL` || "Time Limits" -- display the processor and I/O time limits for the job with the specified mix limit, e.g., `5TL`. ||
|| `TO` || "Type Options" -- list all of the MCP run-time options and their current setting, e.g., `TO`. ||
|| `TR` || "Time Reset" -- set the system time of day in 24-hour notation, e.g., `TR 1345`. ||
|| `TS` || "Type Schedule" -- list all jobs currently in the schedule, e.g., `TS`. ||
|| `UL` || "Unlabeled" -- reply to a `#NO FIL` message and assign a peripheral unit with unlabeled media to the job with the specified mix number, e.g., `4UL MTD`. ||
|| `WD` || "What Date" -- display the current system date, e.g., `WD`. ||
|| `WI` || "What Intrinsics" -- display the name of the current System Intrinsics file being used by the system, e.g., `WI`. ||
|| `WM` || "What MCP" -- display the name of the current MCP file being used with the system and the compile-time options that are enabled for it, e.g., `WM`. ||
|| `WT` || "What Time" -- display the current time of day, e.g., `WT`. ||
|| `<mix>WY` || "Why Stopped" -- display the reason that the job with the specified mix index has suspended execution and the command mnemonics the MCP will accept to resolve the suspension, e.g., `5WY`. When used without a mix number, displays all of the jobs that are suspended and waiting for operator intervention. ||
|| `<mix>XS` || "Execute from Schedule" -- force the job with the specified mix number from the schedule into the running mix, even though the MCP does not think it has sufficient memory to run that job, e.g., `2XS`. The mix number is actually a schedule index. ||
|| `<mix>XT` || "Extend Times" -- extend the time limits for the job with the specified mix index, e.g., `5XT 360,190`. This command is similar to `CT`, but specifies the new limits relative to the existing ones, instead of setting absolute limits. The times are specified in seconds for the processor and I/O limits, respectively. Either time may be omitted, but if the I/O time is specified, it must be preceded by a comma. ||
#summary Instructions for using the SPO (supervisory keyboard/printer) with the retro-B5500 emulator in a web browser.
#labels Burroughs,B5500,emulator,retro-b5500,operator,console,SPO,keyboard
= WebUI Using the SPO =
<wiki:toc max_depth="2"/>
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."
= Background =
Initially on the B5000 and early B5500s, the SPO was a Smith-Carona electric typewriter, modified to interface with the system's I/O Control Units. Later, Burroughs started using a standard Teletype Model 33 KSR device, with a panel of control buttons installed where a modem would normally be. This was termed the B495 Supervisory Printer. The best picture we have of the B495 comes from the B100/200/300 Reference Manual:
https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-SPO-Image.png
The printer and control buttons looked very similar to the interface we have developed for the web-based emulator:
https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-SPO.png
The SPO was intended solely as an operational control device and not as a timesharing terminal. Programs could communicate with the SPO, but since the system typically ran multiple jobs at once, access to the SPO had to be shared on a non-conflicting basis. While it was possible to compile and run programs from the SPO (assuming the source or object code was already on disk), one did not sit at the SPO to, say, edit source code.
The SPO was a peripheral device, and interfaced both physically and electronically to the rest of the system the same way that a tape drive or card reader would. It sat on the short end of the L-shaped operator console desk. Below it was a logic rack that adapted the Teletype interface signals to those of the system's I/O Units.
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.
= SPO Control Panel =
The Model 33 teletype had a rotary off/local/remote switch on its front bezel, below the keyboard. This was typically left in the "remote" position unless the system was being powered down completely. The emulator does not implement this.
The Model 33 had a space on the right side of its case where interface equipment could be installed. This was often used for a dial modem. The units for the B5500 had a special panel installed in this space that had ten button/light controls in two columns of five. Three of the button/lights were blank and unused. The rest were labeled as follows:
* *POWER* -- this black light illuminates when power is applied to the device.
* *READY* -- this yellow light illuminates when the system initiates a read operation in response to the *INPUT REQUEST* button being pressed.
* *REMOTE* -- this yellow button/light indicates the device is on-line to the rest of the system. If the device is off-line, pressing the button makes it on-line.
* *LOCAL* -- this yellow button/light indicates the device is off-line to the rest of the system. If the device is on-line, pressing the button makes it off-line. When the device is off-line, you can type comments onto the paper, which will not be transmitted to the system.
* *INPUT REQUEST* this yellow button/light is used to set the Keyboard Request interrupt. That interrupt in turn requests attention from the MCP so that it will initiate a read operation for the keyboard. When pressed, the button lights, and remains lit until the system initiates the read operation, at which point the light goes out, the *READY* light comes on, and the keyboard is enabled for input.
* *END OF MESSAGE* -- after entering a command on the keyboard, press this yellow button to terminate the input and signal the system that the command is complete. This also extinguishes the *READY* light.
* *ERROR* -- if you makde a mistake while entering a command, press this yellow button to cancel what had been entered. The MCP will discard your input to that point and reinitiate a read operation to the device. To cancel a partially-entered command and not reenter it, press *ERROR*, and then when *READY* comes back on, press *END OF MESSAGE*.
The emulated SPO supports a few user-interface features that the Teletype Model 33 device did not:
# When the SPO window has the focus, you can press the ESC key instead of the *INPUT REQUEST* button to request input to the system. The *INPUT REQUEST* button will light as if it had been pressed.
# You can press the Enter key on your keyboard instead of the *END OF MESSAGE* button to end a message.
# When the *READY* light is on and the SPO window has the focus, you can press the ESC key to cancel your input instead of the *ERROR* button. In either case, the carriage will start a new line and the *READY* light will eventually come on again to allow you to reenter your command.
# Lower-case letters will be translated to upper case as you type them. Neither the B5500 nor the Model 33 supported lower case.
# When entering a command, you can press the Backspace key to correct errors. The Model 33 could not backspace.
# You can type faster than 10 characters/second, which was physically impossible with a Model 33. The SPO echos your keystrokes at only 10 cps, but it will eventually catch up to what you have entered.
= Tips for Using the SPO =
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.
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.
= An Overview of MCP SPO Commands =
The basic commands you will need to operate the B5500 emulator in a batch environment are listed below. This list does not include any of the data communications or timesharing-specific commands. More complete documentation for the SPO commands and output messages can be found in documents on bitsavers.org:
* [http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/1031986_B5500_Handbook_Aug70.pdf B5500 Handbook (April 1970)] describes:
* SPO commands starting on page 4-23
* SPO output messages starting on page 4-1.
* [http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/1024916_B5500_B5700_OperMan_Sep68.pdf B5500 Operation Manual (September 1968)] has somewhat older information:
* SPO commands starting on page C-40
* SPO output messages starting on page C-1
* [http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/1058583_B5700_TSS_RefMan_Sep72.pdf B5700 Timesharing System Manual (September 1972)] has information relating to operation of the Timesharing MCP:
* SPO commands starting on page 1-15
The B5500 MCP used a terse set of operator commands based on two-letter mnemonic codes. Some commands consisted only of their mnemonic code; other commands required operands after the mnemonic.
In the discussion below, the term _program_ refers to a executable file, i.e., a codefile. The term _job_ refers to an instance of a program executing (or having been scheduled for execution) in "the mix" -- the collection of jobs currently executing in the system. One program could be associated with multiple jobs in the mix and/or the schedule at the same time.
Commands that affected a specific job in the system must be prefixed by that job's "mix number," a one- or two-digit integer assigned to the job by the MCP when the job initiates. This mix number is identified as "<mix>" in the descriptions below.
Peripheral devices are referred to by a three letter mnemonic:
* `SPO` -- the SPO
* `CRA`, `CRB` -- card readers 1 and 2
* `CDA`-`CD9` -- pseudo readers 1-32 (for spooled card decks -- letters `I` and `O`, and digits `0` and `1` not used)
* `CPA` -- the card punch
* `LPA`, `LPB` -- line printers 1 and 2
* `MTA`-`MTT` -- magnetic tape units 1-16 (letters `G`, `I`, `O`, and `Q` not used)
* `DCA` -- data communications adapter
* `PRA`, `PRB` -- paper tape readers 1 and 2
* `PPA`, `PPB` -- paper tape punches 1 and 2
* `DKA`, `DKB` -- head-per-track disk control units 1 and 2
* `DRA`, `DRB` -- drum units 1 and 2
If you enter an invalid SPO command, or one that has errors in its syntax or operands, the MCP typically responds with just `INV KBD` -- invalid keyboard entry.
|| <mix>`AX` || "Accept" -- reply to an `ACCEPT` statement or a SPO file read executed by the specified mix index, e.g., `3AXNO`. The text following `AX` after stripping any leading spaces is made available to the program. ||
|| <mix>`BK` || 'Break" -- clear messages queued only for the specified mix number, e.g., `5BK`. When used without a mix number, clears the SPO output queue for the entire system. ||
|| `CC` || "Control Card" -- enter control card syntax directly on the SPO. "`?`" can be used instead of `CC`. Semicolons (`;`) can be used to delimit multiple control statements on one line (72 character, max). The MCP will continue issuing reads to the SPO until and `END` statement or a syntax error is encountered. ||
|| `CD` || "Card Decks" -- list deck number and first card image of each "pseudo" card deck currently queued on disk by the `LDCNTRL/DISK` input spooler, e.g., `CD`. ||
|| `CL` || "Clear Unit" -- reset the MCP status of the specified unit mnemonic (e.g., `CL CRA`, `CL MTB`) and DS-es (aborts) any job to which the unit is currently assigned. In the case of card readers, the MCP will read and ignore all cards until the next control card (one with an invalid character in column 1). ||
|| <mix>`CT` || "Change Times" -- change the processor and I/O time limits for the specified mix number, e.g., "`3CT 300,60`". The integers specify limits for processor and I/O time, respectively, in seconds. Either time may be omitted, but the comma is required if the I/O time is specified. ||
|| <mix>`CU` || "Core Usage" -- display memory use in words for the specified mix number, e.g., `3CU`. When used without a mix number, displays memory use for all jobs in the system. ||
|| <mix>`DS` || "Discontinue" -- abort the job with the specified mix number, e.g. `2DS`. Pronounced "dee ess." ||
|| `DT` || "Date" -- change the system date, e.g., `DT 7/20/83. The date must be written in month/day/year format, using either "`/`" or "`-`" as a delimiter between the date parts. The year must be two digits, and will be interpreted as a 1900-relative year. The B5500 was not Y2K compliant, as no systems were known still to be running in 2000. ||
|| `ED` || "Eliminate Deck" -- discard a spooled card deck that has been assigned to the specified pseudo reader, e.g., `ED CDA`. ||
|| <mix>`ES` || "Eliminate from Schedule" -- terminate a job that has been scheduled but not yet begun execution. `DS` cannot be used in this case because the job is in the schedule, not yet in the mix. The mix number is actually a schedule index, e.g., `3ES`. ||
|| <mix>`FM` || "Form Message" -- reply to a `#FM RQD` message when output is to be printed on special forms by assigning a printer to the specified mix number, e.g., `5FM LPA`. Presumably the operator previously loaded the necessary forms into that printer. ||
|| <mix>`FR` || "Final Reel" -- reply to a `#NO FIL` message for an unlabeled tape file to inform the system that no more reels of tape are to be read, e.g., `4FR`. This causes the job for the specified mix number to receive an EOF result on the pending read. ||
|| <mix>`IL` || "Ignore Label" -- reply to a `#NO FIL` or `#DUP FIL` message when the system cannot find a peripheral unit with media labeled to match the file name requested by the job with the specified mix number. Assigns a specified unit to that job regardless of how the media on that unit is labeled, e.g., `3IL MTB` or `2ILCRA`. ||
|| <mix>`IN` || "Insert Number" -- store a one-word binary unsigned integer value into a PRT location (designated in octal) for the specified mix number, e.g., `4IN 25=33`. This was typically used to asynchronously supply a dynamic parameter to a job, but the job had to sample the PRT location periodically in order to get the value. ||
|| `LD` || "Load Decks" -- initiate the `LDCNTRL/DISK` input spooler to read decks from a card reader or magnetic tape labeled `CONTROL/DECK` and store them either on disk or another magnetic tape for ultimate use by a pseudo reader. `LD DK` stores decks on disk; `LD MT` stores decks on tape. See [WebUIUsingTheCardReader Using the Card Reader] for more information on how to label a card reader for use with this command. ||
|| `LN` || "Log New" -- transfer the contents of the `SYSTEM/LOG` file to a new file, e.g., `LN`. The new file is named _mmddccc_`/SYSLOG`, where _mm_ is the current month, _dd_ is the current date of month, and _ccc_ is a log sequence number assigned by the MCP. ||
|| `MX` || "Mix" -- list all of the jobs currently running in the mix, e.g., `MX`. Each job is listed as _p_`:`_mfid_`/`_fid_`=`_mm_, where _p_ is the priority (0=highest, 9=lowest), _mfid_`/`_fid_ is the program name, and _mm_ is the mix number. ||
|| <mix>`OF` || "Optional File" -- reply to a `#NO FIL` message from a COBOL job when the requested file is not present and will not be provided to the job, e.g., `7OF`. This causes the `OPEN` statement in the COBOL program to succeed and for the program to receive an EOF result on the first read of the file. ||
|| <mix>`OK` || "Okay, Try Again" -- reply to a job that has been suspended by the operator, or is waiting for some resource (such as a file or available space on disk) to be made available, e.g., `4OK`. If the program was suspended by the operator with a `ST` command, it resumes execution. If the program was suspended due to an unavailable resource, the system checks again for the resource. If it is available, the program resumes execution, otherwise it remains suspended. The system typically recognized newly-available resources and resumed suspended programs automatically, so this command was seldom required except to resume after an `ST` command. ||
|| `OL` || "Observe Label" -- display the current status of the specified peripheral device, including the name of any media currently mounted on it, e.g., `OL MTD`. ||
|| <mix>`OT` || "Output Value" -- display the value of a PRT location (specified in octal) for the specified mix number, e.g., `3OT26`. The first location available for variables declared in a program was octal 25. When compiling a program, `OT25` indicates the number of syntax errors encountered thus far. For most compilers, `OT27` indicates the sequence number of the record currently being scanned. ||
|| <mix>`OU` || "Output Unit" -- reply to a `#LP RQD` or `#LP PBT MT RQD` message from the specified mix number to supply the physical output medium for a job's printer file if the `PBDONLY` option is not set and no line printer is currently available, e.g., `5OU MT` for a printer-backup tape. ||
|| `PB` || "Print Backup" -- initiate printing of printer or punch data that has been spooled to disk or tape, e.g., `PB MTC` for a printer-backup tape, or `PB 231` for a backup file on disk. Printer- and punch-backup files on disk are named `PBD/`_nnnnsss_ and `PUD/`_nnnnsss_, respectively, where _nnnn_ is a backup-file number assigned by the MCP and _sss_ is a sequence number also assigned by the MCP. The _nnnn_ number is the one used with a `PB` command. Large printer files were broken up into multiple physical files on disk, all having the same _nnnn_ value but different _sss_ values. The MCP automatically prints all files having the same _nnnn_ value. ||
|| `PD` || "Print Directory" -- list the names of files on disk matching the pattern specified by the operand. Disk files have two-level names, termed the multiple-file ID (MFID) and file ID (FID). Possible search patterns are `PD `_mfid_`/`_fid_, `PD `_mfid_`/=` (or `PD `_mfid_`=` or just `PD `_mfid_), `PD =/`_fid_ (or `PD =`_fid_), or `PD =/=` (or just `PD =`. ||
|| `PG` || "Purge" -- purge a magnetic tape volume (reel) by writing a "scratch" label on it, and optionally assign a five-digit volume number in the process, e.g., `PG MTA` or `PG MTD-12345`, where `12345` is the volume number and the dash is required. ||
|| <mix>`PR` || "Priority" -- change the priority of a job in the mix, e.g., `4PR=6`. The highest priority is 0 and the lowest is 9. ||
|| <mix>`PS` || "Priority in Schedule" -- change the priority of a job that is in the schedule, similar to the `PR` command, e.g., `5PS=7`. The mix number is actually a schedule index. ||
|| `QT` || "Quit Output" -- stop printing or punching the spooled file being output to the designated peripheral unit, e.g., `QT LPB` or `QT CPA`. Can also be entered with the mix number of the spooler job, e.g., `3QT`. The backup file on disk or tape is merely skipped, not purged. ||
|| `RD` || "Remove Decks" -- removes spooled card decks from disk if they have not yet been assigned to a pseudo reader. The decks are identified by their deck number, as displayed by the `CD` command, e.g., `RD #203, #207, #216`. ||
|| <mix>`RM` || "Remove" -- resolve a duplicate-file condition, where a job is attempting to lock a new file into the disk directory, but a file of the same name already exists on disk. If the command is entered in response to this condition (e.g., `3RM`), the existing file on disk will be replaced by the new one. The alternative is to `DS` the program, which will leave the existing file in place. ||
|| `RN` || "Reader Number" -- set the number of active pseudo readers (input deck de-spoolers) for the system, e.g., `RN 2`. Setting the number to zero inhibits further decks from being de-spooled. Can also be entered with a deck number, e.g., `RN #204`, to load the specified deck into a pseudo reader. This latter form is normally used only with shared-disk systems. ||
|| `RO` || "Reset Option" -- reset one of the MCP options, e.g., `RO USE AUTOPRNT` ||
|| `RW` || "Rewind Unit" -- rewind and logically "lock" the tape drive designated by the operand, e.g., `RW MTB`. The unit must not currently be assigned to a job. A "locked" unit cannot be assigned to a job by the system until either the operator enters an `RY` command referencing the unit, or the unit is made not-ready and then ready again (so that the MCP would sense the status change). `RW` was often used to keep the system from using a mounted scratch tape until the operator was ready for it to be assigned to a specific job. ||
|| `RY` || "Ready Unit" -- force the MCP to recognize a change in the status of the designated units, as if the units had been made not-ready and then ready again, so that the MCP would sense the status change, e.g., `RY MTD`, `RY CRA CRA CPA`. Readying a card reader that has been labeled but not yet referenced causes the `LABEL` or `?DATA` card to be ignored. ||
|| `SF` || "Set Factor" -- set the Multiprocessing Factor for the system, a real number with at most two digits before and two digits after the decimal point, e.g., `SF 1.25`. This is essentially a fudge factor by which the amount of available physical memory is multiplied when determining whether a job can be moved out of the schedule and into the mix. ||
|| `SO` || "Set Option" -- set one of the MCP options, e.g., `SO USE TIME` ||
|| <mix>`ST` || "Suspend Task" -- suspend the job for the specified mix number, e.g., `5ST`. The job stays in the mix, but does not consume any processor time. The job may be resumed with an `OK` command or terminated with a `DS` command. ||
|| `SV` || "Save Unit" -- mark a peripheral device as unavailable for assignment to a job. If the unit is currently assigned to a job, it becomes unavailable for further assignment when it is released by that job. ||
|| `TF` || "Type Factor" -- display the current Multiprocessing Factor as set by the `SF` command. ||
|| <mix>`TI` || "Times" -- display the running times for the job with the specified mix number, e.g., `3TI`. The processor, I/O (channel), and elapsed times, respectively, are displayed in _hours_:_minutes_:_seconds_ format, e.g., `CP= 1:41, IO= 8 IN 1:44` ||
|| <mix>`TL` || "Time Limits" -- display the processor and I/O time limits for the job with the specified mix limit, e.g., `5TL`. ||
|| `TO` || "Type Options" -- list all of the MCP run-time options and their current setting, e.g., `TO`. ||
|| `TR` || "Time Reset" -- set the system time of day in 24-hour notation, e.g., `TR 1345`. ||
|| `TS` || "Type Schedule" -- list all jobs currently in the schedule, e.g., `TS`. ||
|| `UL` || "Unlabeled" -- reply to a `#NO FIL` message and assign a peripheral unit with unlabeled media to the job with the specified mix number, e.g., `4UL MTD`. ||
|| `WD` || "What Date" -- display the current system date, e.g., `WD`. ||
|| `WI` || "What Intrinsics" -- display the name of the current System Intrinsics file being used by the system, e.g., `WI`. ||
|| `WM` || "What MCP" -- display the name of the current MCP file being used with the system and the compile-time options that are enabled for it, e.g., `WM`. ||
|| `WT` || "What Time" -- display the current time of day, e.g., `WT`. ||
|| <mix>`WY` || "Why Stopped" -- display the reason that the job with the specified mix index has suspended execution and the command mnemonics the MCP will accept to resolve the suspension, e.g., `5WY`. When used without a mix number, displays all of the jobs that are suspended and waiting for operator intervention. ||
|| <mix>`XS` || "Execute from Schedule" -- force the job with the specified mix number from the schedule into the running mix, even though the MCP does not think it has sufficient memory to run that job, e.g., `2XS`. The mix number is actually a schedule index. ||
|| <mix>`XT` || "Extend Times" -- extend the time limits for the job with the specified mix index, e.g., `5XT 360,190`. This command is similar to `CT`, but specifies the new limits relative to the existing ones, instead of setting absolute limits. The times are specified in seconds for the processor and I/O limits, respectively. Either time may be omitted, but if the I/O time is specified, it must be preceded by a comma. ||

BIN
images/B495-SPO-Image.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 95 KiB

BIN
images/B5500-CardPunch.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 27 KiB

BIN
images/B5500-CardReader.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.6 KiB

BIN
images/B5500-Console-Image.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 25 KiB

BIN
images/B5500-Console.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 14 KiB

BIN
images/B5500-SPO.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 35 KiB

BIN
images/ColdLoader-Disk-Database-Opened.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.7 KiB

BIN
images/ColdLoader-Heading.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.8 KiB

BIN
images/ColdLoader-Tape-File-List.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 23 KiB