From 8a124269372d70d97e4a8f7c87c7613f0da810df Mon Sep 17 00:00:00 2001 From: Paul Kimpel Date: Sat, 4 Apr 2015 11:00:04 -0700 Subject: [PATCH] Reconstruct Google Code wiki history: Apply the *.md "markdown" files generated by the conversion from Google Code to GitHub on top of the reconstructed *.wiki files from the Google Code Subversion repository and delete the *.md files. Log of the history of wiki development on Google Code prior to conversion from *.wiki to GitHub *.md format: Revision: 476 Author: paul.kimpel@digm.com Date: 2/8/2015 10:32:05 PM Message: Commit wiki changes for Release 1.01. ---- Modified : /wiki/WebUIGettingStarted.wiki Modified : /wiki/WebUIRunningTheEmulator.wiki Modified : /wiki/WebUIUsingDatacom.wiki Modified : /wiki/WebUIUsingTheConsole.wiki Modified : /wiki/WebUIUsingTheSPO.wiki Modified : /wiki/images/B5500-Console.png Added : /wiki/images/B5500-Home-Page.png Modified : /wiki/images/B5500-SPO.png Revision: 466 Author: paul.kimpel@digm.com Date: 9/29/2014 8:25:38 AM Message: Commit wiki updates for release 1.00. ---- Modified : /wiki Modified : /wiki/WebUIGettingStarted.wiki Modified : /wiki/WebUIRunningTheEmulator.wiki Modified : /wiki/WebUIUsingDatacom.wiki Modified : /wiki/WebUIUsingTheConsole.wiki Modified : /wiki/WebUIUsingTheSPO.wiki Modified : /wiki/images/B5500-Console.png Modified : /wiki/images/B5500-SPO.png Added : /wiki/0.20-WebUIGettingStarted.wiki (Copy from path: /branches/alpha/wiki/0.20-WebUIGettingStarted.wiki, Revision, 465) Modified : /wiki/TableOfContents.wiki Added : /wiki/WebUIConfiguringTheSystem.wiki (Copy from path: /branches/alpha/wiki/WebUIConfiguringTheSystem.wiki, Revision, 465) Modified : /wiki/WebUIHowToSetUpCANDE.wiki Modified : /wiki/WebUIUsingTheCardPunch.wiki Modified : /wiki/WebUIUsingTheCardReader.wiki Modified : /wiki/WebUIUsingTheLinePrinter.wiki Modified : /wiki/WebUIUsingTheMagTapeDrive.wiki Modified : /wiki/images/B5500-CardPunch.png Modified : /wiki/images/B5500-CardReader.png Added : /wiki/images/B5500-LinePrinter.png (Copy from path: /branches/alpha/wiki/images/B5500-LinePrinter.png, Revision, 465) Modified : /wiki/images/B5500-MagTapeDrive.png Modified : /wiki/images/B5500-MagTapeLoader.png Added : /wiki/images/B5500-Word-DP.png (Copy from path: /branches/alpha/wiki/images/B5500-Word-DP.png, Revision, 465) Added : /wiki/images/B5500-Word-SP.png (Copy from path: /branches/alpha/wiki/images/B5500-Word-SP.png, Revision, 465) Added : /wiki/images/Configuration-Default-Created.PNG (Copy from path: /branches/alpha/wiki/images/Configuration-Default-Created.PNG, Revision, 465) Added : /wiki/images/Disk Schema Update.png (Copy from path: /branches/alpha/wiki/images/Disk Schema Update.png, Revision, 465) Added : /wiki/images/Disk-Config-Created.PNG (Copy from path: /branches/alpha/wiki/images/Disk-Config-Created.PNG, Revision, 465) Added : /wiki/images/Disk-Config-Deleted.PNG (Copy from path: /branches/alpha/wiki/images/Disk-Config-Deleted.PNG, Revision, 465) Added : /wiki/images/Disk-Config-Dialog.PNG (Copy from path: /branches/alpha/wiki/images/Disk-Config-Dialog.PNG, Revision, 465) Added : /wiki/images/Disk-Config-Does-Not-Exist.PNG (Copy from path: /branches/alpha/wiki/images/Disk-Config-Does-Not-Exist.PNG, Revision, 465) Added : /wiki/images/System-Config-Delete-Confirm.PNG (Copy from path: /branches/alpha/wiki/images/System-Config-Delete-Confirm.PNG, Revision, 465) Added : /wiki/images/System-Config-Deleted.PNG (Copy from path: /branches/alpha/wiki/images/System-Config-Deleted.PNG, Revision, 465) Added : /wiki/images/System-Config-Dialog.PNG (Copy from path: /branches/alpha/wiki/images/System-Config-Dialog.PNG, Revision, 465) Added : /wiki/images/System-Config-Does-Not-Exist.PNG (Copy from path: /branches/alpha/wiki/images/System-Config-Does-Not-Exist.PNG, Revision, 465) Revision: 427 Author: paul.kimpel@digm.com Date: 8/5/2014 12:23:33 PM Message: Create initial Table of Contents sidebar page. ---- Added : /wiki/TableOfContents.wiki Revision: 410 Author: paul.kimpel@digm.com Date: 6/29/2014 1:39:38 PM Message: Minor wiki updates for release 0.20 ---- Modified : /wiki/WebUIRunningTheEmulator.wiki Modified : /wiki/WebUIUsingDatacom.wiki Modified : /wiki/WebUIUsingTheConsole.wiki Revision: 394 Author: paul.kimpel@digm.com Date: 1/19/2014 4:57:05 AM Message: Commit updates and corrections to the Using the Magnetic Tape Drive wiki for 0.19. ---- Modified : /wiki/WebUIUsingTheMagTapeDrive.wiki Revision: 393 Author: nw@retrocomputingtasmania.com Date: 1/10/2014 3:41:11 PM Message: Edited wiki page B5500maxconfig through web user interface. ---- Modified : /wiki/B5500maxconfig.wiki Revision: 392 Author: paul.kimpel@digm.com Date: 1/10/2014 2:46:41 PM Message: Correct tape drive loader wiki image extension from jpg to png. ---- Modified : /wiki/WebUIUsingTheMagTapeDrive.wiki Revision: 390 Author: paul.kimpel@digm.com Date: 1/10/2014 2:17:55 PM Message: Wiki updates for release 0.19. ---- Modified : /wiki/WebUIUsingTheSPO.wiki Modified : /wiki/WebUIUsingTheMagTapeDrive.wiki Modified : /wiki/images/B5500-MagTapeDrive.png Added : /wiki/images/B5500-MagTapeLoader.png Revision: 385 Author: paul.kimpel@digm.com Date: 12/30/2013 11:10:05 AM Message: Minor wiki updates for release 0.18. ---- Modified : /wiki/WebUIUsingTheConsole.wiki Modified : /wiki/WebUIUsingTheSPO.wiki Revision: 381 Author: paul.kimpel@digm.com Date: 11/25/2013 10:08:49 PM Message: Commit further revisions to Tim Sirianni's initial TSMCP/CANDE setup wiki page. ---- Modified : /wiki/WebUIUsingDatacom.wiki Modified : /wiki/WebUIHowToSetUpCANDE.wiki Revision: 380 Author: paul.kimpel@digm.com Date: 11/25/2013 9:57:01 PM Message: Commit further revisions to Tim Sirianni's initial TSMCP/CANDE setup wiki page. ---- Modified : /wiki/WebUIHowToSetUpCANDE.wiki Revision: 379 Author: paul.kimpel@digm.com Date: 11/25/2013 9:49:29 PM Message: Commit revisions to Tim Sirianni's initial TSMCP/CANDE setup wiki page. ---- Modified : /wiki/WebUIHowToSetUpCANDE.wiki Revision: 378 Author: nw@retrocomputingtasmania.com Date: 11/23/2013 3:33:32 PM Message: typo and verbalize note. ---- Modified : /wiki/WebUIHowToSetUpCANDE.wiki Revision: 377 Author: nw@retrocomputingtasmania.com Date: 11/23/2013 3:29:12 PM Message: couple of minor edits. ---- Modified : /wiki/WebUIHowToSetUpCANDE.wiki Revision: 376 Author: paul.kimpel@digm.com Date: 11/23/2013 2:31:52 PM Message: Commit Tim Sirianni's initial TSMCP/CANDE setup wiki page. ---- Added : /wiki/WebUIHowToSetUpCANDE.wiki Revision: 375 Author: paul.kimpel@digm.com Date: 11/20/2013 8:31:56 PM Message: Release wiki updates for version 0.16. ---- Modified : /wiki/WebUIGettingStarted.wiki Modified : /wiki/WebUIUsingDatacom.wiki Modified : /wiki/WebUIUsingTheCardReader.wiki Modified : /wiki/WebUIUsingTheMagTapeDrive.wiki Modified : /wiki/images/B5500-Datacom-Terminal.png Modified : /wiki/images/MagTape-Drive-burr0136.jpg Revision: 368 Author: paul.kimpel@digm.com Date: 11/14/2013 10:01:36 PM Message: Fix mark-up error in WebUIUsingDatacom.wiki. ---- Modified : /wiki/WebUIUsingDatacom.wiki Revision: 366 Author: paul.kimpel@digm.com Date: 11/14/2013 9:32:55 PM Message: Wiki updates for emulator release 0.15. ---- Modified : /wiki/WebUIGettingStarted.wiki Modified : /wiki/WebUIRunningTheEmulator.wiki Added : /wiki/WebUIUsingDatacom.wiki (Copy from path: /wiki/WebUIUsingTheSPO.wiki, Revision, 356) Modified : /wiki/WebUIUsingTheConsole.wiki Modified : /wiki/WebUIUsingTheSPO.wiki Modified : /wiki/WebUIUsingTheCardPunch.wiki Modified : /wiki/WebUIUsingTheCardReader.wiki Added : /wiki/WebUIUsingTheLinePrinter.wiki (Copy from path: /wiki/WebUIUsingTheCardPunch.wiki, Revision, 353) Added : /wiki/WebUIUsingTheMagTapeDrive.wiki (Copy from path: /wiki/WebUIUsingTheCardReader.wiki, Revision, 353) Modified : /wiki/images/B5500-CardPunch.png Modified : /wiki/images/B5500-CardReader.png Added : /wiki/images/B5500-MagTapeDrive.png Added : /wiki/images/B5500-Datacom-Terminal.png Added : /wiki/images/MagTape-Drive-burr0136.jpg Added : /wiki/images/B5500-at-Stanford.jpg Revision: 356 Author: paul.kimpel@digm.com Date: 9/30/2013 5:19:36 AM Message: Wiki updates for version 0.13 UI changes. ---- Modified : /wiki/WebUIUsingTheConsole.wiki Modified : /wiki/WebUIUsingTheSPO.wiki Modified : /wiki/images/B5500-Console.png Modified : /wiki/images/B5500-SPO.png Added : /wiki/images/B5500-Console-Image.png Revision: 354 Author: paul.kimpel@digm.com Date: 9/2/2013 8:44:26 AM Message: Commit minor wiki corrections. ---- Modified : /wiki/WebUIGettingStarted.wiki Modified : /wiki/WebUIUsingTheSPO.wiki Revision: 353 Author: paul.kimpel@digm.com Date: 9/2/2013 8:09:49 AM Message: Commit accumulated wiki page updates as of 2013-09-02. ---- Modified : /wiki/WebUIGettingStarted.wiki Modified : /wiki/WebUIRunningTheEmulator.wiki Modified : /wiki/WebUIUsingTheConsole.wiki Modified : /wiki/WebUIUsingTheSPO.wiki Added : /wiki/images Added : /wiki/images/B5500-Console.png Added : /wiki/images/B5500-SPO.png Modified : /wiki/WebUIUsingTheCardPunch.wiki Modified : /wiki/WebUIUsingTheCardReader.wiki Added : /wiki/images/B5500-CardPunch.png Added : /wiki/images/B5500-CardReader.png Added : /wiki/images/B495-SPO-Image.png Added : /wiki/images/B5500-Console-Image.jpg Added : /wiki/images/ColdLoader-Disk-Database-Opened.png Added : /wiki/images/ColdLoader-Heading.png Added : /wiki/images/ColdLoader-Tape-File-List.png Revision: 346 Author: paul.kimpel@digm.com Date: 7/21/2013 12:23:29 PM Message: Created initial WebUIUsingTheSPO wiki page. ---- Added : /wiki/WebUIUsingTheSPO.wiki Revision: 345 Author: paul.kimpel@digm.com Date: 7/21/2013 12:13:31 PM Message: Create initial WebUIUsingTheConsole wiki page. ---- Added : /wiki/WebUIUsingTheConsole.wiki Revision: 344 Author: paul.kimpel@digm.com Date: 7/21/2013 12:00:36 PM Message: Miscellaneous revisions and corrections to WebUIUsingTheEmulator. ---- Modified : /wiki/WebUIRunningTheEmulator.wiki Revision: 343 Author: paul.kimpel@digm.com Date: 7/21/2013 11:28:57 AM Message: Miscellaneous revisions and corrections to WebUIGettingStarted. ---- Modified : /wiki/WebUIGettingStarted.wiki Revision: 342 Author: paul.kimpel@digm.com Date: 7/21/2013 11:26:24 AM Message: Created initial WebUIUsingTheCardReader wiki page stub. ---- Added : /wiki/WebUIUsingTheCardReader.wiki Revision: 341 Author: paul.kimpel@digm.com Date: 7/21/2013 11:25:23 AM Message: Created initial WebUIUsingTheCardPunch wiki page stub. ---- Added : /wiki/WebUIUsingTheCardPunch.wiki Revision: 336 Author: paul.kimpel@digm.com Date: 7/13/2013 9:13:20 PM Message: Create initial wiki page. ---- Added : /wiki/WebUIRunningTheEmulator.wiki Revision: 335 Author: paul.kimpel@digm.com Date: 7/13/2013 2:14:42 PM Message: Corrected link problems and minor typos. ---- Modified : /wiki/WebUIGettingStarted.wiki Revision: 334 Author: paul.kimpel@digm.com Date: 7/13/2013 1:49:23 PM Message: Created initial wiki page for webUI based on release 0.10. ---- Added : /wiki/WebUIGettingStarted.wiki Revision: 12 Author: nw@retrocomputingtasmania.com Date: 4/3/2012 2:48:03 AM Message: Created wiki page through web user interface. ---- Added : /wiki/B5500maxconfig.wiki Revision: 1 Author: Date: 3/4/2012 5:39:24 PM Message: Initial directory structure. ---- Added : /wiki Added : /branches Added : /tags Added : /trunk --- 0.20-WebUIGettingStarted.md | 245 ------------ 0.20-WebUIGettingStarted.wiki | 491 ++++++++++++------------ B5500maxconfig.md | 21 - B5500maxconfig.wiki | 4 +- TableOfContents.md | 0 TableOfContents.wiki | 28 +- WebUIConfiguringTheSystem.md | 175 --------- WebUIConfiguringTheSystem.wiki | 353 +++++++++-------- WebUIGettingStarted.md | 358 ----------------- WebUIGettingStarted.wiki | 677 ++++++++++++++++----------------- WebUIHowToSetUpCANDE.md | 469 ----------------------- WebUIHowToSetUpCANDE.wiki | 166 ++++---- WebUIRunningTheEmulator.md | 173 --------- WebUIRunningTheEmulator.wiki | 295 +++++++------- WebUIUsingDatacom.md | 77 ---- WebUIUsingDatacom.wiki | 155 ++++---- WebUIUsingTheCardPunch.md | 75 ---- WebUIUsingTheCardPunch.wiki | 137 ++++--- WebUIUsingTheCardReader.md | 101 ----- WebUIUsingTheCardReader.wiki | 189 +++++---- WebUIUsingTheConsole.md | 173 --------- WebUIUsingTheConsole.wiki | 348 +++++++++-------- WebUIUsingTheLinePrinter.md | 83 ---- WebUIUsingTheLinePrinter.wiki | 153 ++++---- WebUIUsingTheMagTapeDrive.md | 168 -------- WebUIUsingTheMagTapeDrive.wiki | 319 ++++++++-------- WebUIUsingTheSPO.md | 178 --------- WebUIUsingTheSPO.wiki | 358 +++++++++-------- 28 files changed, 1819 insertions(+), 4150 deletions(-) delete mode 100644 0.20-WebUIGettingStarted.md delete mode 100644 B5500maxconfig.md delete mode 100644 TableOfContents.md delete mode 100644 WebUIConfiguringTheSystem.md delete mode 100644 WebUIGettingStarted.md delete mode 100644 WebUIHowToSetUpCANDE.md delete mode 100644 WebUIRunningTheEmulator.md delete mode 100644 WebUIUsingDatacom.md delete mode 100644 WebUIUsingTheCardPunch.md delete mode 100644 WebUIUsingTheCardReader.md delete mode 100644 WebUIUsingTheConsole.md delete mode 100644 WebUIUsingTheLinePrinter.md delete mode 100644 WebUIUsingTheMagTapeDrive.md delete mode 100644 WebUIUsingTheSPO.md diff --git a/0.20-WebUIGettingStarted.md b/0.20-WebUIGettingStarted.md deleted file mode 100644 index 2971b4a..0000000 --- a/0.20-WebUIGettingStarted.md +++ /dev/null @@ -1,245 +0,0 @@ -# WebUI Getting Started # - - - -# 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. - -> _Note:_ The procedures described below, including use of the `B5500ColdLoader.html` page, are deprecated as of release 1.00. New procedures for setup and initialization of the system can be found at [WebUIGettingStarted](WebUIGettingStarted.md). - -## 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 [The Web Browser](WebUIGettingStarted#The_Web_Browser.md) 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 [The Web Server](WebUIGettingStarted#The_Web_Server.md) and [The Emulator Files](WebUIGettingStarted#The_Emulator_Files.md) below for details. - * Download a copy of the Burroughs B5500 system software tape images from http://www.phkimpel.us/B5500/webSite/SoftwareRequest.html. See [The Burroughs B5500 Software](WebUIGettingStarted#The_Burroughs_B5500_Software.md) below for details. - * Run the Cold Loader utility script to initialize the emulated disk subsystem and load the system software to it. See [Initialize the Disk Subsystem](WebUIGettingStarted#Initialize_the_Disk_Subsystem.md) 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: - - 1. A suitable web browser. - 1. A web server configured to deliver files from the emulator directories (our hosting site is set up to do this). - 1. 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). - 1. 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 - * `performance.now()' API - * HTML `` element - -As of this writing, the emulator has been tested with and works with Mozilla Firefox (version 21 and above) and Google Chrome (version 35 and above).1 Somewhat earlier versions of these browsers may also work. Apple Safari will not support the emulator, because it does not as yet support the IndexedDB API. The emulator runs fine on a Macintosh, however, under Firefox or Chrome. Microsoft Internet Explorer (at least through IE10) will not support the emulator. We have not yet tried Opera. - -## 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 [Establish the Web Server](WebUIGettingStarted#Establish_the_Web_Server.md) -below for more details. - -If you need a small, simple web server to host the emulator locally, we have had good success with `mongoose` (https://github.com/valenok/mongoose). It can run on the same workstation as your browser to serve the emulator files using the loop-back port (localhost or 127.0.0.1). Versions are available that run under Windows, Linux, UNIX, Mac OS, and others. It is extremely easy to set up. Under Windows, it can run as either a regular program or as a service. - -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 -[our download site](https://drive.google.com/folderview?id=0BxqKm7v4xBswM29qUkxPTkVfYzg&usp=sharing). 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 -[page on our hosting service](http://www.phkimpel.us/B5500/webSite/SoftwareRequest.html). Go to that page, review and accept the licensing terms (they are not onerous), and download one or more of the tape images. See -[Download the B5500 System Software](WebUIGettingStarted#Download_the_B5500_System_Software.md) 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, -[discussed below](WebUIGettingStarted#Initialize_the_Disk_Subsystem.md), -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: - - 1. Create a new virtual directory, say, `/B5500/`, to hold the emulator files. - 1. Download one of the emulator releases (the one with the highest release-number suffix is usually best) from [our download site](https://drive.google.com/folderview?id=0BxqKm7v4xBswM29qUkxPTkVfYzg&usp=sharing). - 1. 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. Initially, the emulator did not boot programs from cards or support tape drives, so in the interim, we developed a standalone web page, the Cold Loader, to initialize the IndexedDB database structures, create an initial disk directory, and load files from the tape images. That is no longer the case, and in theory you could cold-start the system the old-fashioned way with card decks, but the Cold Loader is still the easier way to do it. - -Before proceeding with this section, you must have the emulator files set up on a web server and have downloaded at least the `SYSTEM` tape image, as described in the previous sections. - -The Cold Loader script is `B5500ColdLoader.html` in the `webUI/` directory. If you are running the emulator from our hosting site, simply open - -> 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](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/ColdLoader-Disk-Database-Opened.png) - - - -> _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. The Cold Loader does not merely overwrite the disk space when cold-starting, it deletes the database structures and recreates them. - -To cold-start the emulator disk subsystem, click the **Cold Start** button at the top of the browser page: - -> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/ColdLoader-Heading.png](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](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. You _must_ select at least the following files initially to load the Data Communications MCP (DCMCP): - - * `MCP/DISK` -- the Master Control Program operating system. **Important!** also tick the radio button in the **As MCP** column. This will cause the Cold Loader to set the MCP bootstrap address in segment zero to point to this file. - * `INT/DISK` -- the System Intrinsics, a library of dynamically-bound subroutines used by all programs. **Important!** also tick the radio button in the **As INT** column. This will cause the Cold Loader to set the Intrinsics address in segment zero to point to this file. - -We recommend that you select these additional files when cold-starting as well: - - * `PRNPBT/DISK` -- the spooler for printer output. - * `LDNCTRL/DISK` -- the spooler for card reader input (known as "pseudo" readers). - * `ALGOL/DISK` -- the Extended Algol compiler. - -Feel free to select any additional files from the `SYSTEM` tape when you are cold-starting, but it is now generally better to wait until the MCP is up and running, and then load any additional files using the Library/Maintenance feature of the MCP. See below for more on this. - -The following are good candidates for additional files to load, 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. - -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 you attempt to replace a file name that is already in the directory. - -We now recommend that you load only a minimum set of files to disk using the Cold Loader (i.e., the two mandatory and three recommended files above), and load any additional files using Library/Maintenance once the MCP is up and running. The MCP does a much better job of disk space allocation and directory maintenance than the Cold Loader. In particular, the MCP will replace existing files safely. It will also try to evenly distribute files across the available disk EUs, which will tend to more evenly distribute I/Os across the EUs and increase the probability of multiple simultaneous I/Os taking place. - -Library/Maintenance is the portion of the MCP that manages disk files and maintains the disk directory. Among its features is the capability to dump disk files to and load disk files from magnetic tape. This was typically used for file backup, archiving, and transferring files among systems. - -Files can be loaded from Library/Maintenance volumes such as the `SYSTEM`, `SYMBOL1`, and `SYMBOL2` tape images using the `LOAD` and `ADD` control card commands, e.g., - -``` - ?LOAD FROM SYSTEM ESPOL/DISK, COBOL/DISK, DUMP/ANALYZE; END -``` - -A control card command can be continued across multiple card images by terminating a card with a hyphen (`-`) wherever a word or other punctuation character might appear. The continuation card(s) that follow must not have an invalid character in column 1. The command must be terminated either by appending `;END` on the last line or by a final line with `?END` beginning in column 1. - -All files having the same first or last identifier in their file name may be loaded by specifying `MFID/=` or `=/FID`. All files from a tape can be loaded by specifying `=/=`. Library/Maintenance will not overwrite certain critical system files, such as the currently running MCP and Intrinsics. - -The `ADD` command works the same as `LOAD`, except that it loads only files that are not already in the disk directory. - -See [Using the Magnetic Tape Drive](WebUIUsingTheMagTapeDrive.md) for more information on how to mount tape images onto a tape drive. See Section 4, and in particular page 4-15 ff, in http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1024916_B5500_B5700_OperMan_Sep68.pdf for more information on control card syntax and the Library/Maintenance commands. - - -# Next Steps # - -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 [WebUI Running the Emulator](WebUIRunningTheEmulator.md) for detailed instructions on how to start the emulator and run the emulated B5500 system. - - - -`____________` - -1 Earlier versions of the emulator ran fine on Chrome 27 (the earliest version we tested), but somewhere around Chrome 30 the browser started crashing ("Aw, Snap!") while running the emulator. This appears to have been a problem with garbage collection, resulting in the browser running out of memory. The problem was resolved in mid-2014 with Chrome 35. \ No newline at end of file diff --git a/0.20-WebUIGettingStarted.wiki b/0.20-WebUIGettingStarted.wiki index d90cb05..2971b4a 100644 --- a/0.20-WebUIGettingStarted.wiki +++ b/0.20-WebUIGettingStarted.wiki @@ -1,248 +1,245 @@ -#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 = - - - -= 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. - - _Note:_ The procedures described below, including use of the `B5500ColdLoader.html` page, are deprecated as of release 1.00. New procedures for setup and initialization of the system can be found at [WebUIGettingStarted]. - -== 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 - * `performance.now()' API - * HTML `` element - -As of this writing, the emulator has been tested with and works with Mozilla Firefox (version 21 and above) and Google Chrome (version 35 and above).^1^ Somewhat earlier versions of these browsers may also work. Apple Safari will not support the emulator, because it does not as yet support the IndexedDB API. The emulator runs fine on a Macintosh, however, under Firefox or Chrome. Microsoft Internet Explorer (at least through IE10) will not support the emulator. We have not yet tried Opera. - -== 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 server to host the emulator locally, we have had good success with `mongoose` (https://github.com/valenok/mongoose). It can run on the same workstation as your browser to serve the emulator files using the loop-back port (localhost or 127.0.0.1). Versions are available that run under Windows, Linux, UNIX, Mac OS, and others. It is extremely easy to set up. Under Windows, it can run as either a regular program or as a service. - -As an alternative to setting up and operating your own web server, you are welcome to use a web site we have set up on a hosting service. Just point your browser to the following URL: - - 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. Initially, the emulator did not boot programs from cards or support tape drives, so in the interim, we developed a standalone web page, the Cold Loader, to initialize the IndexedDB database structures, create an initial disk directory, and load files from the tape images. That is no longer the case, and in theory you could cold-start the system the old-fashioned way with card decks, but the Cold Loader is still the easier way to do it. - -Before proceeding with this section, you must have the emulator files set up on a web server and have downloaded at least the `SYSTEM` tape image, as described in the previous sections. - -The Cold Loader script is `B5500ColdLoader.html` in the `webUI/` directory. If you are running the emulator from our hosting site, simply open - - 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 - - -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. - - - _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. The Cold Loader does not merely overwrite the disk space when cold-starting, it deletes the database structures and recreates them. - -To cold-start the emulator disk subsystem, click the *Cold Start* button at the top of the browser page: - - 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. You _must_ select at least the following files initially to load the Data Communications MCP (DCMCP): - - * `MCP/DISK` -- the Master Control Program operating system. *Important!* also tick the radio button in the *As MCP* column. This will cause the Cold Loader to set the MCP bootstrap address in segment zero to point to this file. - * `INT/DISK` -- the System Intrinsics, a library of dynamically-bound subroutines used by all programs. *Important!* also tick the radio button in the *As INT* column. This will cause the Cold Loader to set the Intrinsics address in segment zero to point to this file. - -We recommend that you select these additional files when cold-starting as well: - - * `PRNPBT/DISK` -- the spooler for printer output. - * `LDNCTRL/DISK` -- the spooler for card reader input (known as "pseudo" readers). - * `ALGOL/DISK` -- the Extended Algol compiler. - -Feel free to select any additional files from the `SYSTEM` tape when you are cold-starting, but it is now generally better to wait until the MCP is up and running, and then load any additional files using the Library/Maintenance feature of the MCP. See below for more on this. - -The following are good candidates for additional files to load, 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. - -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 you attempt to replace a file name that is already in the directory. - -We now recommend that you load only a minimum set of files to disk using the Cold Loader (i.e., the two mandatory and three recommended files above), and load any additional files using Library/Maintenance once the MCP is up and running. The MCP does a much better job of disk space allocation and directory maintenance than the Cold Loader. In particular, the MCP will replace existing files safely. It will also try to evenly distribute files across the available disk EUs, which will tend to more evenly distribute I/Os across the EUs and increase the probability of multiple simultaneous I/Os taking place. - -Library/Maintenance is the portion of the MCP that manages disk files and maintains the disk directory. Among its features is the capability to dump disk files to and load disk files from magnetic tape. This was typically used for file backup, archiving, and transferring files among systems. - -Files can be loaded from Library/Maintenance volumes such as the `SYSTEM`, `SYMBOL1`, and `SYMBOL2` tape images using the `LOAD` and `ADD` control card commands, e.g., - - {{{ +# WebUI Getting Started # + + + +# 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. + +> _Note:_ The procedures described below, including use of the `B5500ColdLoader.html` page, are deprecated as of release 1.00. New procedures for setup and initialization of the system can be found at [WebUIGettingStarted](WebUIGettingStarted.md). + +## 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 [The Web Browser](WebUIGettingStarted#The_Web_Browser.md) 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 [The Web Server](WebUIGettingStarted#The_Web_Server.md) and [The Emulator Files](WebUIGettingStarted#The_Emulator_Files.md) below for details. + * Download a copy of the Burroughs B5500 system software tape images from http://www.phkimpel.us/B5500/webSite/SoftwareRequest.html. See [The Burroughs B5500 Software](WebUIGettingStarted#The_Burroughs_B5500_Software.md) below for details. + * Run the Cold Loader utility script to initialize the emulated disk subsystem and load the system software to it. See [Initialize the Disk Subsystem](WebUIGettingStarted#Initialize_the_Disk_Subsystem.md) 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: + + 1. A suitable web browser. + 1. A web server configured to deliver files from the emulator directories (our hosting site is set up to do this). + 1. 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). + 1. 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 + * `performance.now()' API + * HTML `` element + +As of this writing, the emulator has been tested with and works with Mozilla Firefox (version 21 and above) and Google Chrome (version 35 and above).1 Somewhat earlier versions of these browsers may also work. Apple Safari will not support the emulator, because it does not as yet support the IndexedDB API. The emulator runs fine on a Macintosh, however, under Firefox or Chrome. Microsoft Internet Explorer (at least through IE10) will not support the emulator. We have not yet tried Opera. + +## 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 [Establish the Web Server](WebUIGettingStarted#Establish_the_Web_Server.md) +below for more details. + +If you need a small, simple web server to host the emulator locally, we have had good success with `mongoose` (https://github.com/valenok/mongoose). It can run on the same workstation as your browser to serve the emulator files using the loop-back port (localhost or 127.0.0.1). Versions are available that run under Windows, Linux, UNIX, Mac OS, and others. It is extremely easy to set up. Under Windows, it can run as either a regular program or as a service. + +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 +[our download site](https://drive.google.com/folderview?id=0BxqKm7v4xBswM29qUkxPTkVfYzg&usp=sharing). 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 +[page on our hosting service](http://www.phkimpel.us/B5500/webSite/SoftwareRequest.html). Go to that page, review and accept the licensing terms (they are not onerous), and download one or more of the tape images. See +[Download the B5500 System Software](WebUIGettingStarted#Download_the_B5500_System_Software.md) 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, +[discussed below](WebUIGettingStarted#Initialize_the_Disk_Subsystem.md), +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: + + 1. Create a new virtual directory, say, `/B5500/`, to hold the emulator files. + 1. Download one of the emulator releases (the one with the highest release-number suffix is usually best) from [our download site](https://drive.google.com/folderview?id=0BxqKm7v4xBswM29qUkxPTkVfYzg&usp=sharing). + 1. 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. Initially, the emulator did not boot programs from cards or support tape drives, so in the interim, we developed a standalone web page, the Cold Loader, to initialize the IndexedDB database structures, create an initial disk directory, and load files from the tape images. That is no longer the case, and in theory you could cold-start the system the old-fashioned way with card decks, but the Cold Loader is still the easier way to do it. + +Before proceeding with this section, you must have the emulator files set up on a web server and have downloaded at least the `SYSTEM` tape image, as described in the previous sections. + +The Cold Loader script is `B5500ColdLoader.html` in the `webUI/` directory. If you are running the emulator from our hosting site, simply open + +> 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](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/ColdLoader-Disk-Database-Opened.png) + + + +> _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. The Cold Loader does not merely overwrite the disk space when cold-starting, it deletes the database structures and recreates them. + +To cold-start the emulator disk subsystem, click the **Cold Start** button at the top of the browser page: + +> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/ColdLoader-Heading.png](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](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. You _must_ select at least the following files initially to load the Data Communications MCP (DCMCP): + + * `MCP/DISK` -- the Master Control Program operating system. **Important!** also tick the radio button in the **As MCP** column. This will cause the Cold Loader to set the MCP bootstrap address in segment zero to point to this file. + * `INT/DISK` -- the System Intrinsics, a library of dynamically-bound subroutines used by all programs. **Important!** also tick the radio button in the **As INT** column. This will cause the Cold Loader to set the Intrinsics address in segment zero to point to this file. + +We recommend that you select these additional files when cold-starting as well: + + * `PRNPBT/DISK` -- the spooler for printer output. + * `LDNCTRL/DISK` -- the spooler for card reader input (known as "pseudo" readers). + * `ALGOL/DISK` -- the Extended Algol compiler. + +Feel free to select any additional files from the `SYSTEM` tape when you are cold-starting, but it is now generally better to wait until the MCP is up and running, and then load any additional files using the Library/Maintenance feature of the MCP. See below for more on this. + +The following are good candidates for additional files to load, 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. + +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 you attempt to replace a file name that is already in the directory. + +We now recommend that you load only a minimum set of files to disk using the Cold Loader (i.e., the two mandatory and three recommended files above), and load any additional files using Library/Maintenance once the MCP is up and running. The MCP does a much better job of disk space allocation and directory maintenance than the Cold Loader. In particular, the MCP will replace existing files safely. It will also try to evenly distribute files across the available disk EUs, which will tend to more evenly distribute I/Os across the EUs and increase the probability of multiple simultaneous I/Os taking place. + +Library/Maintenance is the portion of the MCP that manages disk files and maintains the disk directory. Among its features is the capability to dump disk files to and load disk files from magnetic tape. This was typically used for file backup, archiving, and transferring files among systems. + +Files can be loaded from Library/Maintenance volumes such as the `SYSTEM`, `SYMBOL1`, and `SYMBOL2` tape images using the `LOAD` and `ADD` control card commands, e.g., + +``` ?LOAD FROM SYSTEM ESPOL/DISK, COBOL/DISK, DUMP/ANALYZE; END - }}} - -A control card command can be continued across multiple card images by terminating a card with a hyphen (`-`) wherever a word or other punctuation character might appear. The continuation card(s) that follow must not have an invalid character in column 1. The command must be terminated either by appending `;END` on the last line or by a final line with `?END` beginning in column 1. - -All files having the same first or last identifier in their file name may be loaded by specifying `MFID/=` or `=/FID`. All files from a tape can be loaded by specifying `=/=`. Library/Maintenance will not overwrite certain critical system files, such as the currently running MCP and Intrinsics. - -The `ADD` command works the same as `LOAD`, except that it loads only files that are not already in the disk directory. - -See [WebUIUsingTheMagTapeDrive Using the Magnetic Tape Drive] for more information on how to mount tape images onto a tape drive. See Section 4, and in particular page 4-15 ff, in http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1024916_B5500_B5700_OperMan_Sep68.pdf for more information on control card syntax and the Library/Maintenance commands. - - -= Next Steps = - -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. - - - -`____________` - -^1^ Earlier versions of the emulator ran fine on Chrome 27 (the earliest version we tested), but somewhere around Chrome 30 the browser started crashing ("Aw, Snap!") while running the emulator. This appears to have been a problem with garbage collection, resulting in the browser running out of memory. The problem was resolved in mid-2014 with Chrome 35. \ No newline at end of file +``` + +A control card command can be continued across multiple card images by terminating a card with a hyphen (`-`) wherever a word or other punctuation character might appear. The continuation card(s) that follow must not have an invalid character in column 1. The command must be terminated either by appending `;END` on the last line or by a final line with `?END` beginning in column 1. + +All files having the same first or last identifier in their file name may be loaded by specifying `MFID/=` or `=/FID`. All files from a tape can be loaded by specifying `=/=`. Library/Maintenance will not overwrite certain critical system files, such as the currently running MCP and Intrinsics. + +The `ADD` command works the same as `LOAD`, except that it loads only files that are not already in the disk directory. + +See [Using the Magnetic Tape Drive](WebUIUsingTheMagTapeDrive.md) for more information on how to mount tape images onto a tape drive. See Section 4, and in particular page 4-15 ff, in http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1024916_B5500_B5700_OperMan_Sep68.pdf for more information on control card syntax and the Library/Maintenance commands. + + +# Next Steps # + +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 [WebUI Running the Emulator](WebUIRunningTheEmulator.md) for detailed instructions on how to start the emulator and run the emulated B5500 system. + + + +`____________` + +1 Earlier versions of the emulator ran fine on Chrome 27 (the earliest version we tested), but somewhere around Chrome 30 the browser started crashing ("Aw, Snap!") while running the emulator. This appears to have been a problem with garbage collection, resulting in the browser running out of memory. The problem was resolved in mid-2014 with Chrome 35. \ No newline at end of file diff --git a/B5500maxconfig.md b/B5500maxconfig.md deleted file mode 100644 index c75d8ef..0000000 --- a/B5500maxconfig.md +++ /dev/null @@ -1,21 +0,0 @@ -A maximum configuration of the Burroughs B5500 allows for: - - * Two central processing units. - * Eight independent memory modules (each 4,096 48-bit words). - * Four floating input/output channels. - * Sixteen magnetic tape drives. - * Two billion characters (2GB) of on-line disk storage. - * Two line printers. - * Two card readers. - * Two paper tape readers. - * One card punch. - * One paper tape punch. - * One supervisory console. - * 240 communication line buffers. - -In October-1970, Burroughs renamed the B5500 to B5700 as part of the introduction of the 700-series family (that inluded the B6700 and B7700) and added new capabilities: - - * Support for B6700 DataComm for communications - * Support for adding B6700 memory modules as auxiliary memory. - -B5700 AuxMem was implemented primarily as an overlay mechanism, and the extra memory appeared as the deprecated B5000-era drum storage devices. These appear as devices DRA and DRB in the MCP. Use of the drum device interface limited the auxiliary memory to 32kWords each, for a total of 64kWords of AuxMem. \ No newline at end of file diff --git a/B5500maxconfig.wiki b/B5500maxconfig.wiki index 4cc7659..c75d8ef 100644 --- a/B5500maxconfig.wiki +++ b/B5500maxconfig.wiki @@ -1,5 +1,3 @@ -#summary B5500 maximum configuration. - A maximum configuration of the Burroughs B5500 allows for: * Two central processing units. @@ -20,4 +18,4 @@ In October-1970, Burroughs renamed the B5500 to B5700 as part of the introductio * Support for B6700 DataComm for communications * Support for adding B6700 memory modules as auxiliary memory. -B5700 AuxMem was implemented primarily as an overlay mechanism, and the extra memory appeared as the deprecated B5000-era drum storage devices. These appear as devices DRA and DRB in the MCP. Use of the drum device interface limited the auxiliary memory to 32kWords each, for a total of 64kWords of AuxMem. +B5700 AuxMem was implemented primarily as an overlay mechanism, and the extra memory appeared as the deprecated B5000-era drum storage devices. These appear as devices DRA and DRB in the MCP. Use of the drum device interface limited the auxiliary memory to 32kWords each, for a total of 64kWords of AuxMem. \ No newline at end of file diff --git a/TableOfContents.md b/TableOfContents.md deleted file mode 100644 index e69de29..0000000 diff --git a/TableOfContents.wiki b/TableOfContents.wiki index fd2606f..718ae0b 100644 --- a/TableOfContents.wiki +++ b/TableOfContents.wiki @@ -1,15 +1,15 @@ -#summary retro-b5500 project wiki table of contents page - - * Set Up - * [WebUIGettingStarted Getting Started] - * [WebUIConfiguringTheSystem Configuring the System] - * [WebUIHowToSetUpCANDE Set up CANDE Timesharing] - * Operations - * [WebUIRunningTheEmulator Running the Emulator] - * [WebUIUsingTheConsole Using the Operator Console] - * [WebUIUsingTheSPO Using the SPO] - * [WebUIUsingTheCardReader Using the Card Reader] - * [WebUIUsingTheCardPunch Using the Card Punch] - * [WebUIUsingTheLinePrinter Using the Line Printer] - * [WebUIUsingTheMagTapeDrive Using Magnetic Tape] +Table of Contents + + * Set Up + * [WebUIGettingStarted Getting Started] + * [WebUIConfiguringTheSystem Configuring the System] + * [WebUIHowToSetUpCANDE Set up CANDE Timesharing] + * Operations + * [WebUIRunningTheEmulator Running the Emulator] + * [WebUIUsingTheConsole Using the Operator Console] + * [WebUIUsingTheSPO Using the SPO] + * [WebUIUsingTheCardReader Using the Card Reader] + * [WebUIUsingTheCardPunch Using the Card Punch] + * [WebUIUsingTheLinePrinter Using the Line Printer] + * [WebUIUsingTheMagTapeDrive Using Magnetic Tape] * [WebUIUsingDatacom Using Datacom] \ No newline at end of file diff --git a/WebUIConfiguringTheSystem.md b/WebUIConfiguringTheSystem.md deleted file mode 100644 index e778582..0000000 --- a/WebUIConfiguringTheSystem.md +++ /dev/null @@ -1,175 +0,0 @@ -# WebUI Configuring the System # - - -From its initial release, the retro-B5500 emulator has had a configuration mechanism that allowed you to select the system components and I/O peripherals that make up the emulated environment. Prior to release 1.00, though, that configuration was specified by a static Javascript file. If you were running your own web server, you could change that file quite easily, but if you were relying on an external web site to host the emulator, you were limited to whatever configuration was hosted on that server. - -Starting with release 1.00, the emulator now has a more flexible configuration mechanism. Individual users can specify the system and I/O components they wish to have for their local instance. They can also have multiple, named configurations, and easily switch among them. In addition, users can now create multiple disk subsystems with different configurations and assign a disk subsystem to a system configuration. Multiple system configurations may share the same disk subsystem, and the disk subsystem assigned to a given configuration can be easily changed. - -This wiki page describes the new configuration mechanism for both system components and disk subsystems. - - -# Overview of Configuration Components # - -This section gives a brief overview of the components of system configurations and disk subsystems. - -## System Components ## - -A B5500 computer system is made up from some combination of the following components and peripheral I/O units: - - * A Central Control Unit. This is required. It connects the major system components -- processors, I/O Control Units, and memory modules. It also provides an exchange to connect the I/O Control Units to the peripheral devices. - * One or two processors, PA and PB. One of the selected processors must be designated as the control processor, P1. - * One to four Input/Output Control Units, IO1 through IO4. Most systems had at least three of these. They are I/O channels, and have direct access to memory through Central Control. - * One to eight 4K-word memory modules. Most systems eventually had a full complement of eight modules, totaling 32K-words of memory. - * A Teletype printer/keyboard unit, known as the SPO. This is required in order for the system to run the MCP. - * One or two card readers, CRA and CRB. - * One card punch, CPA. - * One or two line printers, LPA and LPB. - * One or two paper-tape readers, PRA and PRB. - * One or two paper-tape punches, PPA and PPB. A system can have a maximum of three paper-tape devices, either two readers and one punch, or one reader and two punches. The emulator does not presently support paper tape devices, however. - * One to 16 7-track magnetic tape units, MTA through MTT, with letters G, I, O, and Q not used. - * One or two 32K-word high-speed drums, DRA and DRB. These were a standard feature of B5000 systems that were converted to B5500s, but most later systems did not have them. The emulator does not presently support drum devices. - * One or two Disk File Control Units (DFCU), DKA and DKB. DKA is required to boot the system from Head-per-Track disk. The DFCU can also be associated with a Disk File Exchange (DFX), which allows it to connect to multiple EUs (disk units). The DFX also allows two DFCUs to service a common set of EUs. See the Disk Subsystem section next for more detail on disk configurations. - -A system configuration specifies the subset of these components that will be used by the emulator in a given instance. On a real B5500, changing the set of system components generally required the system to be powered off first. The emulator also requires that configuration changes take place only when the system is in a powered-off state. - -## Disk Subsystem ## - -One of the elements that distinguished the B5500 from its B5000 predecessor was the Head-per-Track disk subsystem. A disk subsystem can be configured in a number of ways, using the following components: - - * Disk File Control Units (DFCUs). As mentioned above, a B5500 can have one or two of these, DKA and DKB. These contain the logic to interface the disk units to the I/O Control Units. A DFCU can connect directly to a single Electronics Unit (EU), or through a Disk File Exchange (DFX) to a maximum of five EUs. One DFCU can support up to two DFX units, or a maximum of ten EUs. - * Electronics Units (EUs), numbered `EU0` through `EU19`. An EU contains the common electronics and air pressure controls for up to five Storage Units. - * Storage Units (SUs), numbered 1 through 5. An SU contains four 30-inch aluminum disk platters that are the storage medium. These disk platters rotate within a framework that holds fixed heads. As there is no head movement, the only components of access time are rotational latency and data transfer time. There are two models of SU, but all SUs for an EU must be the of same type: - * Model-I units rotate at 1500 RPM and hold 40,000 30-word sectors of data. Thus, each SU holds 1.2M 48-bit words or 9.6M 6-bit characters of data. A fully-configured EU can therefore hold 48M 6-bit characters of data. - * Model-IB units have twice the storage capacity of Model-I disks, but accomplish that by rotating at half the speed, 750 RPM. These are sometimes referred to as "bulk" or "slow" disks. - -A DFCU can support up to ten EUs, for a total of 480M 6-bit characters using Model-I SUs. If you have two DFCUs, you have a choice on how they can be associated with EUs: - - * You can support up to 20 EUs, but each EU can be accessed by only one DFCU. `EU0`-`9` will be addressed by DKA; `EU10`-`19` will be addressed by DKB. - * You can support up to 10 EUs, numbered `EU0`-`9`, with both DFCUs able to access any EU through the DFX. Unless you need the storage capacity of more than ten EUs, this second approach is the one you should choose, as it generally allows more disk I/Os to operate in parallel. - -The EUs are the addressable I/O unit. An I/O operation can cross SU boundaries, but not an EU boundary. The MCP always allocates a disk area (row, extent) wholly within the address range for a single EU. - -The MCP considers the disk subsystem, however it was configured, to be a monolithic storage space. Programs running under the MCP do not address any of the physical components of the disk subsystem. From the perspective of user-level software, there is just "disk." - - -# Configuring System Components # - -To establish a system configuration for the emulator, you first configure the system components you need, and then add a disk subsystem to that configuration. This section discusses configuring the system components. - -The emulator stores system configurations in a small IndexedDB database named "`retro-B5500-Config`". This database is separate from the ones used for disk subsystems. It is managed entirely by the configuration interface. - -To modify the system configuration, create a new configuration, or select a previously-defined configuration for use, the emulator must be in a powered-off state. It is in this state when you first open the Console window, and after you click the **POWER OFF** button on the Console. - -To open the system configuration interface, simply click the B5500 logo on the right side of the Console, under the Burroughs logo, when the emulator is in a powered-off state. Normally this logo reads "retro-B5500," but if you have previously clicked the Burroughs logo to put the Console in "purist" mode, the logo will simply read "B 5500". The configuration interface will open the System Configuration dialog window that will look similar to this: - -> https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/System-Config-Dialog.PNG - -At the top of the dialog is a pull-down list of system configurations you can choose from. Initially, the only name listed will be "`Default`", which is the configuration that the emulator creates automatically the first time you load it. See [WebUI Getting Started](WebUIGettingStarted.md) for a description of this default configuration. - -When you first open the configuration dialog, the "current" configuration will be loaded into the window. This is the configuration that will be used by the emulator when the system is next powered on. To load a different configuration into the dialog window, simply select it from the pull-down list. - -There are four buttons on the dialog that you use to control maintenance of the configurations: - - * **NEW** -- Click this button to initiate the creation of a new system configuration. The dialog will prompt you for a name for the new configuration. Configuration names may contain any combination of characters and are case-sensitive. After supplying the new name, select the configuration components as described below and click the **SAVE** button to store the new configuration in the emulator's configuration database. - * **DELETE** -- Click this button to delete the configuration currently selected in the pull-down list to its left. The dialog will prompt you for confirmation before deleting the configuration, but once accomplished, the delete cannot be undone. - * **CANCEL** -- Click this button to discard any changes you have made on the configuration dialog (except deletion of one or more configurations) and close the dialog window. - * **SAVE** -- Click this button to save any changes you have made on the configuration dialog and close the dialog window. Clicking this button will also establish the configuration being saved as the "current" configuration. To make another previously-defined configuration the current one, simply open the configuration dialog, select the desired configuration from the pull-down list, and click **SAVE**. - -The remaining buttons on the dialog apply to disk subsystems, and will be discussed in the next section. - -You may have as many system configurations as you wish. You may modify and switch among them at any time the emulator is in a powered-off state. - -You select components for a system configuration by simply checking their corresponding boxes on the configuration dialog. Central Control is implicitly included in every configuration; it does not have a selection on the dialog. There are a few constraints to keep in mind when selecting components for a configuration: - - * At least one processor must be selected in order for the system to run. - * One of the selected processors must be designated as the control processor, P1. If only PA is selected, leave the **PB is P1** checkbox unchecked, designating PA as P1. If only PB is selected, check the **PB is P1** checkbox, designating PB as P1. If both processors are selected, it is your choice which should be P1. - * At least one I/O Control Unit must be selected in order for the system to run. The MCP generally runs best with at least three I/O units. - * At least memory module M0 must be selected. The system will not boot without M0 present. In most cases, you will want to run with all eight memory modules. It is possible to run with "holes" in the module configuration; the MCP will allocate memory around the holes. Attempting to run the MCP without module M1, or with fewer than a total of six memory modules, may prove to be problematic. - * The SPO must be selected in order to run the MCP. - * Paper tape and drum units are not presently supported by the emulator. Their checkboxes are disabled. - * Disk File Control Unit DKA must be selected in order to load from disk, and therefore to run the MCP. DKB is optional, as is the DFX. File Protect Memory (FPM) is presently not supported by the emulator; its checkbox is disabled. See the next section for more information on configuring disk subsystems and components. - * If disk is included in the configuration, you must select a disk subsystem from the **Storage name** pull-down list. - * The Data Communications adapter, DCA, is optional, but should be included if you want to run the Timesharing MCP and CANDE. At present, the emulator supports only one fixed teletype station; thus the additional controls under the DCA checkbox are disabled. - -The SPO, line printers, and card punch have an additional option labeled "Algol Glyphs." These checkboxes set the default mode of those devices for translating the five special Algol characters on output. When the checkbox is checked, the special Algol characters will be output as their corresponding Unicode glyphs. When the box is unchecked, those characters will be output using their ASCII substitutions. This setting can be overridden temporarily on the individual devices. See the respective wiki pages for the devices for details on how to do this. - -Note that you can easily create a system configuration that is either non-functional (e.g., no processor) or that will not support the MCP. The emulator will refuse to perform a load if the minimum components necessary for a running system are not present. - - -# Configuring Disk Subsystems # - -Prior to release 1.00, the emulator supported a single disk subsystem using an IndexedDB database named "`B5500DiskUnit`". This subsystem had a fixed configuration of two EUs, each with five Model-I SUs, for a total of 200,000 30-word sectors, or 96M 6-bit characters of storage. - -As part of the new configuration mechanism introduced in release 1.00, you can now modify the configuration of a disk subsystem to provide more storage. You can select between Model-I and Model-IB SUs to trade off access time vs. storage space. You can also create multiple disk subsystems and associate them with one or more system configurations. Only one disk subsystem can be associated and used with a given system configuration at a time, however. - -A disk subsystem from an earlier release can be used with 1.00 and later releases. Such a subsystem can continue to be used with earlier releases as well, subject to the constraints discussed in [Upgrading from Earlier Emulator Versions](WebUIConfiguringTheSystem#Upgrading_from_Earlier_Emulator_Versions.md), below. - -Each disk subsystem is implemented as a separate IndexedDB database. Each subsystem has a name you assign when the subsystem is created. That name is also the name of the IndexedDB database for the subsystem. Disk subsystems from earlier versions of the emulator continue to have the name `B5500DiskUnit`. - -Disk subsystems are associated with system configurations by means of the pull-down list on the System Configuration dialog window labeled **Storage name**. This list contains the names of all disk subsystems known to the emulator. The entry selected in this list will become the subsystem that is associated with the configuration when the **SAVE** button on the configuration dialog is clicked. - -Next to the pull-down list are two buttons that allow you to access the disk subsystem configuration interface: - - * **NEW** -- Click this button to create a new disk subsystem and its IndexedDB database. The dialog will prompt you for the name of the new subsystem and then display the Disk Storage Configuration dialog discussed below. If you supply the name of an existing disk subsystem, that subsystem will be updated as if you had clicked the **EDIT** button for it instead. - * **EDIT** -- Click this button to view or modify the subsystem currently selected in the pull-down list. - -Clicking either of these buttons will open the Disk Storage Configuration dialog, which will look similar to this: - -> https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU//Disk-Config-Dialog.PNG - -The name of the new or selected disk subsystem is shown in the area labeled **Subsystem**. The storage configuration dialog is controlled using three buttons: - - * **DELETE** -- Click this yellow button after opening an existing disk subsystem configuration to delete that subsystem and its IndexedDB database. The dialog will ask for confirmation that you want to delete the subsystem. Once accomplished, the delete cannot be undone. After deleting the database, the dialog window will close. Note that if you attempt to delete a subsystem that was opened as new, the dialog window will simply close without creating the new subsystem. - * **CANCEL** -- Click this button to close the dialog window without modifying or creating the disk subsystem. - * **SAVE** -- Click this button to save the current disk subsystem configuration, close the dialog window, and return to the System Configuration dialog window. - -The remainder of the dialog has a set of 20 groups of controls, labeled `EU0` through `EU20`. Each of these represents one Disk Electronics Unit in the configuration, and each has the following controls: - - * A checkbox. Checking the box will include the EU in the configuration. If the box is not checked, the other controls are ignored. - * A pull-down list to select the number of SUs, `1` to `5`, to be configured for this EU. - * A pull-down list to select to the model of SU to be configured for this EU, "`I`" or "`IB`". The model selection applies to all of the SUs for that EU. - -The primary constraint on configuration of a disk subsystem is that once storage space has been assigned to a disk subsystem, it cannot be removed. Once you click the **SAVE** button, any items you have selected on the Disk Subsystem Configuration dialog become a permanent part of the subsystem. The primary reason for this constraint is that, since the B5500 MCP considers disk to be a monolithic resource, parts of files could be spread across multiple EUs and located anywhere on the respective disk units. Removing storage space from the configuration may cause parts of files to disappear, so the emulator does not allow this. - -This constraint manifests itself in three ways on the configuration dialog window: - - 1. Once an EU is included in a subsystem, it may not be removed. Its checkbox will be disabled. - 1. The number of SUs specified for an EU may be increased, but not decreased. Selections for smaller numbers of SUs are disabled in the pull-down list. - 1. An EU with Model-I SUs may be changed to Model-IB SUs, but not the reverse. Since Model-IB SUs have twice the storage capacity of Model-Is, switching from Model-IB to Model-I would reduce the space allocated to the subsystem. If "`IB`" is selected in the pull-down list, the "`I`" selection is disabled. - -If you absolutely must reduce the size of a disk subsystem, the only way to do this that the emulator supports is to dump the files to tape using the MCP `?DUMP` or `?UNLOAD` control-card command, delete the disk subsystem, recreate it, Cold Start the new subsystem, and reload the files using the MCP `?LOAD` or `?ADD` command. - -Another constraint on disk subsystem configuration concerns the number of DFCUs in the system configuration, whether a DFX is included in the system configuration, and the EU numbers selected for the disk subsystem: - - * A configuration with a single DFCU (i.e., DKA) can support up to 10 EUs. These must be numbered in the range of `EU0`-`9`. - * A configuration with two DFCUs and no DFX can support up to 20 EUs, with `EU0`-`9` being addressed by DKA and `EU10`-`19` addressed by DKB. - * A configuration with two DFCUs and the DFX enabled can support up to 10 EUs, numbered in the range `EU0`-`9`. Either DFCU can address any EU, although a given EU can be addressed by only one DFCU at a time. `EU10`-`19` are not addressable in this configuration. This choice generally gives the best performance, as it increases the chance that multiple disk I/Os can occur in parallel. - -IndexedDB implementations in web browsers generally allocate physical disk space on the workstation incrementally, as sectors that had previously been unwritten are written for the first time. Thus, there is generally little, if any, penalty for configuring a disk subsystem that is significantly larger than you initially need. - -Also note that most browsers have a limit on the amount of physical disk space an IndexedDB database may use without approval from the user. This limit varies, but is often in the range of 10-50MB. If you are loading files from tape, or running programs under the emulator that are creating new disk files, and notice that the emulator appears to hang -- check the Console window for an alert requesting permission to use more disk space. Since other windows, such as the SPO, are often on top of the Console window, this alert may not be visible until the Console window is brought to the top and given the focus. - -Finally, note that IndexedDB databases are subject to the "same-origin" policy within the browser. This means that access to an IndexedDB database is constrained in two ways: - - 1. You must use the same browser. IndexedDB implementations vary from browser to browser, and are likely incompatible with each other. An IndexedDB database created by Google Chrome cannot be accessed by Mozilla Firefox. - 1. You must access the web site hosting the emulator using the same host name and port number. For example, our hosting site for the emulator can be accessed using either `phkimpel.us` or `www.phkimpel.us` (we recommend the latter). Even though those two host names reference the same set of files on the same server, they are considered to be separate origins, and will have separate sets of IndexedDB databases. A disk subsystem created using the emulator loaded from one host name will be inaccessible to an emulator loaded from the other. - - -# Creating an Initial Configuration # - -When you load the emulator into a browser on a workstation for the first time, the emulator will automatically create a default system configuration and disk subsystem when the emulator is first powered on. This configuration is generally adequate for most people in their initial use of the emulator. - -See [Create the Initial System Configuration](WebUIGettingStarted#Create_the_Initial_System_Configuration.md) for details on how this occurs and [Default System Configuration](WebUIGettingStarted#Default_System_Configuration.md) for a description of the components in the default configuration. - -You can, of course, use the configuration mechanism described above in this wiki to modify that default configuration and create one that is more suited to your needs. You can also leave that default configuration as is and create one or more additional configurations with different components and disk subsystems. - -If you want to inhibit establishment of that default configuration and create your own from scratch, however, you must create that configuration before you power on the emulator for the first time. After loading the emulator into the browser, simply click the B5500 logo to open the System Configuration dialog. That dialog will show a configuration entry for `Default` and a disk subsystem entry for `B5500DiskUnit`. The default system configuration will have been created, but the disk subsystem at this point will not have been created yet. You can proceed to create a new system configuration by clicking the **NEW** button. Afterwards, you can delete the original `Default` configuration or not, as you prefer. - - -# Upgrading from Earlier Emulator Versions # - -The static system configuration used in emulator releases before 1.00 cannot be brought forward into later versions of the emulator, although you can modify the default configuration or create a new one to reproduce its characteristics. Disk subsystems are persistent, however, and the IndexedDB databases from earlier versions of the emulator can still be used without change on release 1.00 and later versions. - -Disk subsystems created by release 1.00 and later versions of the emulator cannot be used by earlier versions. The format of the configuration data stored within the subsystem database has changed in a way that earlier versions cannot use. - -Disk subsystems created by versions prior to 1.00 can be used by 1.00 and later versions. Such subsystems can also continue to be used by versions of the emulator earlier than 1.00, _provided the configuration of the disk subsystem is not changed_. Once you modify the configuration of a disk subsystem, the configuration data stored in its database is converted to the new format and the subsystem is no longer usable by earlier versions of the emulator. If you plan to run multiple versions of the emulator from the same host server, you should keep this restriction in mind. \ No newline at end of file diff --git a/WebUIConfiguringTheSystem.wiki b/WebUIConfiguringTheSystem.wiki index d08c1e2..e778582 100644 --- a/WebUIConfiguringTheSystem.wiki +++ b/WebUIConfiguringTheSystem.wiki @@ -1,178 +1,175 @@ -#summary Instructions for configuring system components in the web browser-based retro-B5500 emulator. -#labels Burroughs,B5500,emulator,retro-b5500,configuration,disk subsystem - -= WebUI Configuring the System = - - -From its initial release, the retro-B5500 emulator has had a configuration mechanism that allowed you to select the system components and I/O peripherals that make up the emulated environment. Prior to release 1.00, though, that configuration was specified by a static Javascript file. If you were running your own web server, you could change that file quite easily, but if you were relying on an external web site to host the emulator, you were limited to whatever configuration was hosted on that server. - -Starting with release 1.00, the emulator now has a more flexible configuration mechanism. Individual users can specify the system and I/O components they wish to have for their local instance. They can also have multiple, named configurations, and easily switch among them. In addition, users can now create multiple disk subsystems with different configurations and assign a disk subsystem to a system configuration. Multiple system configurations may share the same disk subsystem, and the disk subsystem assigned to a given configuration can be easily changed. - -This wiki page describes the new configuration mechanism for both system components and disk subsystems. - - -= Overview of Configuration Components = - -This section gives a brief overview of the components of system configurations and disk subsystems. - -== System Components == - -A B5500 computer system is made up from some combination of the following components and peripheral I/O units: - - * A Central Control Unit. This is required. It connects the major system components -- processors, I/O Control Units, and memory modules. It also provides an exchange to connect the I/O Control Units to the peripheral devices. - * One or two processors, PA and PB. One of the selected processors must be designated as the control processor, P1. - * One to four Input/Output Control Units, IO1 through IO4. Most systems had at least three of these. They are I/O channels, and have direct access to memory through Central Control. - * One to eight 4K-word memory modules. Most systems eventually had a full complement of eight modules, totaling 32K-words of memory. - * A Teletype printer/keyboard unit, known as the SPO. This is required in order for the system to run the MCP. - * One or two card readers, CRA and CRB. - * One card punch, CPA. - * One or two line printers, LPA and LPB. - * One or two paper-tape readers, PRA and PRB. - * One or two paper-tape punches, PPA and PPB. A system can have a maximum of three paper-tape devices, either two readers and one punch, or one reader and two punches. The emulator does not presently support paper tape devices, however. - * One to 16 7-track magnetic tape units, MTA through MTT, with letters G, I, O, and Q not used. - * One or two 32K-word high-speed drums, DRA and DRB. These were a standard feature of B5000 systems that were converted to B5500s, but most later systems did not have them. The emulator does not presently support drum devices. - * One or two Disk File Control Units (DFCU), DKA and DKB. DKA is required to boot the system from Head-per-Track disk. The DFCU can also be associated with a Disk File Exchange (DFX), which allows it to connect to multiple EUs (disk units). The DFX also allows two DFCUs to service a common set of EUs. See the Disk Subsystem section next for more detail on disk configurations. - -A system configuration specifies the subset of these components that will be used by the emulator in a given instance. On a real B5500, changing the set of system components generally required the system to be powered off first. The emulator also requires that configuration changes take place only when the system is in a powered-off state. - -== Disk Subsystem == - -One of the elements that distinguished the B5500 from its B5000 predecessor was the Head-per-Track disk subsystem. A disk subsystem can be configured in a number of ways, using the following components: - - * Disk File Control Units (DFCUs). As mentioned above, a B5500 can have one or two of these, DKA and DKB. These contain the logic to interface the disk units to the I/O Control Units. A DFCU can connect directly to a single Electronics Unit (EU), or through a Disk File Exchange (DFX) to a maximum of five EUs. One DFCU can support up to two DFX units, or a maximum of ten EUs. - * Electronics Units (EUs), numbered `EU0` through `EU19`. An EU contains the common electronics and air pressure controls for up to five Storage Units. - * Storage Units (SUs), numbered 1 through 5. An SU contains four 30-inch aluminum disk platters that are the storage medium. These disk platters rotate within a framework that holds fixed heads. As there is no head movement, the only components of access time are rotational latency and data transfer time. There are two models of SU, but all SUs for an EU must be the of same type: - * Model-I units rotate at 1500 RPM and hold 40,000 30-word sectors of data. Thus, each SU holds 1.2M 48-bit words or 9.6M 6-bit characters of data. A fully-configured EU can therefore hold 48M 6-bit characters of data. - * Model-IB units have twice the storage capacity of Model-I disks, but accomplish that by rotating at half the speed, 750 RPM. These are sometimes referred to as "bulk" or "slow" disks. - -A DFCU can support up to ten EUs, for a total of 480M 6-bit characters using Model-I SUs. If you have two DFCUs, you have a choice on how they can be associated with EUs: - - * You can support up to 20 EUs, but each EU can be accessed by only one DFCU. `EU0`-`9` will be addressed by DKA; `EU10`-`19` will be addressed by DKB. - * You can support up to 10 EUs, numbered `EU0`-`9`, with both DFCUs able to access any EU through the DFX. Unless you need the storage capacity of more than ten EUs, this second approach is the one you should choose, as it generally allows more disk I/Os to operate in parallel. - -The EUs are the addressable I/O unit. An I/O operation can cross SU boundaries, but not an EU boundary. The MCP always allocates a disk area (row, extent) wholly within the address range for a single EU. - -The MCP considers the disk subsystem, however it was configured, to be a monolithic storage space. Programs running under the MCP do not address any of the physical components of the disk subsystem. From the perspective of user-level software, there is just "disk." - - -= Configuring System Components = - -To establish a system configuration for the emulator, you first configure the system components you need, and then add a disk subsystem to that configuration. This section discusses configuring the system components. - -The emulator stores system configurations in a small IndexedDB database named "`retro-B5500-Config`". This database is separate from the ones used for disk subsystems. It is managed entirely by the configuration interface. - -To modify the system configuration, create a new configuration, or select a previously-defined configuration for use, the emulator must be in a powered-off state. It is in this state when you first open the Console window, and after you click the *POWER OFF* button on the Console. - -To open the system configuration interface, simply click the B5500 logo on the right side of the Console, under the Burroughs logo, when the emulator is in a powered-off state. Normally this logo reads "retro-B5500," but if you have previously clicked the Burroughs logo to put the Console in "purist" mode, the logo will simply read "B 5500". The configuration interface will open the System Configuration dialog window that will look similar to this: - - https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/System-Config-Dialog.PNG - -At the top of the dialog is a pull-down list of system configurations you can choose from. Initially, the only name listed will be "`Default`", which is the configuration that the emulator creates automatically the first time you load it. See [WebUIGettingStarted WebUI Getting Started] for a description of this default configuration. - -When you first open the configuration dialog, the "current" configuration will be loaded into the window. This is the configuration that will be used by the emulator when the system is next powered on. To load a different configuration into the dialog window, simply select it from the pull-down list. - -There are four buttons on the dialog that you use to control maintenance of the configurations: - - * *NEW* -- Click this button to initiate the creation of a new system configuration. The dialog will prompt you for a name for the new configuration. Configuration names may contain any combination of characters and are case-sensitive. After supplying the new name, select the configuration components as described below and click the *SAVE* button to store the new configuration in the emulator's configuration database. - * *DELETE* -- Click this button to delete the configuration currently selected in the pull-down list to its left. The dialog will prompt you for confirmation before deleting the configuration, but once accomplished, the delete cannot be undone. - * *CANCEL* -- Click this button to discard any changes you have made on the configuration dialog (except deletion of one or more configurations) and close the dialog window. - * *SAVE* -- Click this button to save any changes you have made on the configuration dialog and close the dialog window. Clicking this button will also establish the configuration being saved as the "current" configuration. To make another previously-defined configuration the current one, simply open the configuration dialog, select the desired configuration from the pull-down list, and click *SAVE*. - -The remaining buttons on the dialog apply to disk subsystems, and will be discussed in the next section. - -You may have as many system configurations as you wish. You may modify and switch among them at any time the emulator is in a powered-off state. - -You select components for a system configuration by simply checking their corresponding boxes on the configuration dialog. Central Control is implicitly included in every configuration; it does not have a selection on the dialog. There are a few constraints to keep in mind when selecting components for a configuration: - - * At least one processor must be selected in order for the system to run. - * One of the selected processors must be designated as the control processor, P1. If only PA is selected, leave the *PB is P1* checkbox unchecked, designating PA as P1. If only PB is selected, check the *PB is P1* checkbox, designating PB as P1. If both processors are selected, it is your choice which should be P1. - * At least one I/O Control Unit must be selected in order for the system to run. The MCP generally runs best with at least three I/O units. - * At least memory module M0 must be selected. The system will not boot without M0 present. In most cases, you will want to run with all eight memory modules. It is possible to run with "holes" in the module configuration; the MCP will allocate memory around the holes. Attempting to run the MCP without module M1, or with fewer than a total of six memory modules, may prove to be problematic. - * The SPO must be selected in order to run the MCP. - * Paper tape and drum units are not presently supported by the emulator. Their checkboxes are disabled. - * Disk File Control Unit DKA must be selected in order to load from disk, and therefore to run the MCP. DKB is optional, as is the DFX. File Protect Memory (FPM) is presently not supported by the emulator; its checkbox is disabled. See the next section for more information on configuring disk subsystems and components. - * If disk is included in the configuration, you must select a disk subsystem from the *Storage name* pull-down list. - * The Data Communications adapter, DCA, is optional, but should be included if you want to run the Timesharing MCP and CANDE. At present, the emulator supports only one fixed teletype station; thus the additional controls under the DCA checkbox are disabled. - -The SPO, line printers, and card punch have an additional option labeled "Algol Glyphs." These checkboxes set the default mode of those devices for translating the five special Algol characters on output. When the checkbox is checked, the special Algol characters will be output as their corresponding Unicode glyphs. When the box is unchecked, those characters will be output using their ASCII substitutions. This setting can be overridden temporarily on the individual devices. See the respective wiki pages for the devices for details on how to do this. - -Note that you can easily create a system configuration that is either non-functional (e.g., no processor) or that will not support the MCP. The emulator will refuse to perform a load if the minimum components necessary for a running system are not present. - - -= Configuring Disk Subsystems = - -Prior to release 1.00, the emulator supported a single disk subsystem using an IndexedDB database named "`B5500DiskUnit`". This subsystem had a fixed configuration of two EUs, each with five Model-I SUs, for a total of 200,000 30-word sectors, or 96M 6-bit characters of storage. - -As part of the new configuration mechanism introduced in release 1.00, you can now modify the configuration of a disk subsystem to provide more storage. You can select between Model-I and Model-IB SUs to trade off access time vs. storage space. You can also create multiple disk subsystems and associate them with one or more system configurations. Only one disk subsystem can be associated and used with a given system configuration at a time, however. - -A disk subsystem from an earlier release can be used with 1.00 and later releases. Such a subsystem can continue to be used with earlier releases as well, subject to the constraints discussed in [WebUIConfiguringTheSystem#Upgrading_from_Earlier_Emulator_Versions Upgrading from Earlier Emulator Versions], below. - -Each disk subsystem is implemented as a separate IndexedDB database. Each subsystem has a name you assign when the subsystem is created. That name is also the name of the IndexedDB database for the subsystem. Disk subsystems from earlier versions of the emulator continue to have the name `B5500DiskUnit`. - -Disk subsystems are associated with system configurations by means of the pull-down list on the System Configuration dialog window labeled *Storage name*. This list contains the names of all disk subsystems known to the emulator. The entry selected in this list will become the subsystem that is associated with the configuration when the *SAVE* button on the configuration dialog is clicked. - -Next to the pull-down list are two buttons that allow you to access the disk subsystem configuration interface: - - * *NEW* -- Click this button to create a new disk subsystem and its IndexedDB database. The dialog will prompt you for the name of the new subsystem and then display the Disk Storage Configuration dialog discussed below. If you supply the name of an existing disk subsystem, that subsystem will be updated as if you had clicked the *EDIT* button for it instead. - * *EDIT* -- Click this button to view or modify the subsystem currently selected in the pull-down list. - -Clicking either of these buttons will open the Disk Storage Configuration dialog, which will look similar to this: - - https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU//Disk-Config-Dialog.PNG - -The name of the new or selected disk subsystem is shown in the area labeled *Subsystem*. The storage configuration dialog is controlled using three buttons: - - * *DELETE* -- Click this yellow button after opening an existing disk subsystem configuration to delete that subsystem and its IndexedDB database. The dialog will ask for confirmation that you want to delete the subsystem. Once accomplished, the delete cannot be undone. After deleting the database, the dialog window will close. Note that if you attempt to delete a subsystem that was opened as new, the dialog window will simply close without creating the new subsystem. - * *CANCEL* -- Click this button to close the dialog window without modifying or creating the disk subsystem. - * *SAVE* -- Click this button to save the current disk subsystem configuration, close the dialog window, and return to the System Configuration dialog window. - -The remainder of the dialog has a set of 20 groups of controls, labeled `EU0` through `EU20`. Each of these represents one Disk Electronics Unit in the configuration, and each has the following controls: - - * A checkbox. Checking the box will include the EU in the configuration. If the box is not checked, the other controls are ignored. - * A pull-down list to select the number of SUs, `1` to `5`, to be configured for this EU. - * A pull-down list to select to the model of SU to be configured for this EU, "`I`" or "`IB`". The model selection applies to all of the SUs for that EU. - -The primary constraint on configuration of a disk subsystem is that once storage space has been assigned to a disk subsystem, it cannot be removed. Once you click the *SAVE* button, any items you have selected on the Disk Subsystem Configuration dialog become a permanent part of the subsystem. The primary reason for this constraint is that, since the B5500 MCP considers disk to be a monolithic resource, parts of files could be spread across multiple EUs and located anywhere on the respective disk units. Removing storage space from the configuration may cause parts of files to disappear, so the emulator does not allow this. - -This constraint manifests itself in three ways on the configuration dialog window: - - # Once an EU is included in a subsystem, it may not be removed. Its checkbox will be disabled. - # The number of SUs specified for an EU may be increased, but not decreased. Selections for smaller numbers of SUs are disabled in the pull-down list. - # An EU with Model-I SUs may be changed to Model-IB SUs, but not the reverse. Since Model-IB SUs have twice the storage capacity of Model-Is, switching from Model-IB to Model-I would reduce the space allocated to the subsystem. If "`IB`" is selected in the pull-down list, the "`I`" selection is disabled. - -If you absolutely must reduce the size of a disk subsystem, the only way to do this that the emulator supports is to dump the files to tape using the MCP `?DUMP` or `?UNLOAD` control-card command, delete the disk subsystem, recreate it, Cold Start the new subsystem, and reload the files using the MCP `?LOAD` or `?ADD` command. - -Another constraint on disk subsystem configuration concerns the number of DFCUs in the system configuration, whether a DFX is included in the system configuration, and the EU numbers selected for the disk subsystem: - - * A configuration with a single DFCU (i.e., DKA) can support up to 10 EUs. These must be numbered in the range of `EU0`-`9`. - * A configuration with two DFCUs and no DFX can support up to 20 EUs, with `EU0`-`9` being addressed by DKA and `EU10`-`19` addressed by DKB. - * A configuration with two DFCUs and the DFX enabled can support up to 10 EUs, numbered in the range `EU0`-`9`. Either DFCU can address any EU, although a given EU can be addressed by only one DFCU at a time. `EU10`-`19` are not addressable in this configuration. This choice generally gives the best performance, as it increases the chance that multiple disk I/Os can occur in parallel. - -IndexedDB implementations in web browsers generally allocate physical disk space on the workstation incrementally, as sectors that had previously been unwritten are written for the first time. Thus, there is generally little, if any, penalty for configuring a disk subsystem that is significantly larger than you initially need. - -Also note that most browsers have a limit on the amount of physical disk space an IndexedDB database may use without approval from the user. This limit varies, but is often in the range of 10-50MB. If you are loading files from tape, or running programs under the emulator that are creating new disk files, and notice that the emulator appears to hang -- check the Console window for an alert requesting permission to use more disk space. Since other windows, such as the SPO, are often on top of the Console window, this alert may not be visible until the Console window is brought to the top and given the focus. - -Finally, note that IndexedDB databases are subject to the "same-origin" policy within the browser. This means that access to an IndexedDB database is constrained in two ways: - - # You must use the same browser. IndexedDB implementations vary from browser to browser, and are likely incompatible with each other. An IndexedDB database created by Google Chrome cannot be accessed by Mozilla Firefox. - # You must access the web site hosting the emulator using the same host name and port number. For example, our hosting site for the emulator can be accessed using either `phkimpel.us` or `www.phkimpel.us` (we recommend the latter). Even though those two host names reference the same set of files on the same server, they are considered to be separate origins, and will have separate sets of IndexedDB databases. A disk subsystem created using the emulator loaded from one host name will be inaccessible to an emulator loaded from the other. - - -= Creating an Initial Configuration = - -When you load the emulator into a browser on a workstation for the first time, the emulator will automatically create a default system configuration and disk subsystem when the emulator is first powered on. This configuration is generally adequate for most people in their initial use of the emulator. - -See [WebUIGettingStarted#Create_the_Initial_System_Configuration Create the Initial System Configuration] for details on how this occurs and [WebUIGettingStarted#Default_System_Configuration Default System Configuration] for a description of the components in the default configuration. - -You can, of course, use the configuration mechanism described above in this wiki to modify that default configuration and create one that is more suited to your needs. You can also leave that default configuration as is and create one or more additional configurations with different components and disk subsystems. - -If you want to inhibit establishment of that default configuration and create your own from scratch, however, you must create that configuration before you power on the emulator for the first time. After loading the emulator into the browser, simply click the B5500 logo to open the System Configuration dialog. That dialog will show a configuration entry for `Default` and a disk subsystem entry for `B5500DiskUnit`. The default system configuration will have been created, but the disk subsystem at this point will not have been created yet. You can proceed to create a new system configuration by clicking the *NEW* button. Afterwards, you can delete the original `Default` configuration or not, as you prefer. - - -= Upgrading from Earlier Emulator Versions = - -The static system configuration used in emulator releases before 1.00 cannot be brought forward into later versions of the emulator, although you can modify the default configuration or create a new one to reproduce its characteristics. Disk subsystems are persistent, however, and the IndexedDB databases from earlier versions of the emulator can still be used without change on release 1.00 and later versions. - -Disk subsystems created by release 1.00 and later versions of the emulator cannot be used by earlier versions. The format of the configuration data stored within the subsystem database has changed in a way that earlier versions cannot use. - -Disk subsystems created by versions prior to 1.00 can be used by 1.00 and later versions. Such subsystems can also continue to be used by versions of the emulator earlier than 1.00, _provided the configuration of the disk subsystem is not changed_. Once you modify the configuration of a disk subsystem, the configuration data stored in its database is converted to the new format and the subsystem is no longer usable by earlier versions of the emulator. If you plan to run multiple versions of the emulator from the same host server, you should keep this restriction in mind. +# WebUI Configuring the System # + + +From its initial release, the retro-B5500 emulator has had a configuration mechanism that allowed you to select the system components and I/O peripherals that make up the emulated environment. Prior to release 1.00, though, that configuration was specified by a static Javascript file. If you were running your own web server, you could change that file quite easily, but if you were relying on an external web site to host the emulator, you were limited to whatever configuration was hosted on that server. + +Starting with release 1.00, the emulator now has a more flexible configuration mechanism. Individual users can specify the system and I/O components they wish to have for their local instance. They can also have multiple, named configurations, and easily switch among them. In addition, users can now create multiple disk subsystems with different configurations and assign a disk subsystem to a system configuration. Multiple system configurations may share the same disk subsystem, and the disk subsystem assigned to a given configuration can be easily changed. + +This wiki page describes the new configuration mechanism for both system components and disk subsystems. + + +# Overview of Configuration Components # + +This section gives a brief overview of the components of system configurations and disk subsystems. + +## System Components ## + +A B5500 computer system is made up from some combination of the following components and peripheral I/O units: + + * A Central Control Unit. This is required. It connects the major system components -- processors, I/O Control Units, and memory modules. It also provides an exchange to connect the I/O Control Units to the peripheral devices. + * One or two processors, PA and PB. One of the selected processors must be designated as the control processor, P1. + * One to four Input/Output Control Units, IO1 through IO4. Most systems had at least three of these. They are I/O channels, and have direct access to memory through Central Control. + * One to eight 4K-word memory modules. Most systems eventually had a full complement of eight modules, totaling 32K-words of memory. + * A Teletype printer/keyboard unit, known as the SPO. This is required in order for the system to run the MCP. + * One or two card readers, CRA and CRB. + * One card punch, CPA. + * One or two line printers, LPA and LPB. + * One or two paper-tape readers, PRA and PRB. + * One or two paper-tape punches, PPA and PPB. A system can have a maximum of three paper-tape devices, either two readers and one punch, or one reader and two punches. The emulator does not presently support paper tape devices, however. + * One to 16 7-track magnetic tape units, MTA through MTT, with letters G, I, O, and Q not used. + * One or two 32K-word high-speed drums, DRA and DRB. These were a standard feature of B5000 systems that were converted to B5500s, but most later systems did not have them. The emulator does not presently support drum devices. + * One or two Disk File Control Units (DFCU), DKA and DKB. DKA is required to boot the system from Head-per-Track disk. The DFCU can also be associated with a Disk File Exchange (DFX), which allows it to connect to multiple EUs (disk units). The DFX also allows two DFCUs to service a common set of EUs. See the Disk Subsystem section next for more detail on disk configurations. + +A system configuration specifies the subset of these components that will be used by the emulator in a given instance. On a real B5500, changing the set of system components generally required the system to be powered off first. The emulator also requires that configuration changes take place only when the system is in a powered-off state. + +## Disk Subsystem ## + +One of the elements that distinguished the B5500 from its B5000 predecessor was the Head-per-Track disk subsystem. A disk subsystem can be configured in a number of ways, using the following components: + + * Disk File Control Units (DFCUs). As mentioned above, a B5500 can have one or two of these, DKA and DKB. These contain the logic to interface the disk units to the I/O Control Units. A DFCU can connect directly to a single Electronics Unit (EU), or through a Disk File Exchange (DFX) to a maximum of five EUs. One DFCU can support up to two DFX units, or a maximum of ten EUs. + * Electronics Units (EUs), numbered `EU0` through `EU19`. An EU contains the common electronics and air pressure controls for up to five Storage Units. + * Storage Units (SUs), numbered 1 through 5. An SU contains four 30-inch aluminum disk platters that are the storage medium. These disk platters rotate within a framework that holds fixed heads. As there is no head movement, the only components of access time are rotational latency and data transfer time. There are two models of SU, but all SUs for an EU must be the of same type: + * Model-I units rotate at 1500 RPM and hold 40,000 30-word sectors of data. Thus, each SU holds 1.2M 48-bit words or 9.6M 6-bit characters of data. A fully-configured EU can therefore hold 48M 6-bit characters of data. + * Model-IB units have twice the storage capacity of Model-I disks, but accomplish that by rotating at half the speed, 750 RPM. These are sometimes referred to as "bulk" or "slow" disks. + +A DFCU can support up to ten EUs, for a total of 480M 6-bit characters using Model-I SUs. If you have two DFCUs, you have a choice on how they can be associated with EUs: + + * You can support up to 20 EUs, but each EU can be accessed by only one DFCU. `EU0`-`9` will be addressed by DKA; `EU10`-`19` will be addressed by DKB. + * You can support up to 10 EUs, numbered `EU0`-`9`, with both DFCUs able to access any EU through the DFX. Unless you need the storage capacity of more than ten EUs, this second approach is the one you should choose, as it generally allows more disk I/Os to operate in parallel. + +The EUs are the addressable I/O unit. An I/O operation can cross SU boundaries, but not an EU boundary. The MCP always allocates a disk area (row, extent) wholly within the address range for a single EU. + +The MCP considers the disk subsystem, however it was configured, to be a monolithic storage space. Programs running under the MCP do not address any of the physical components of the disk subsystem. From the perspective of user-level software, there is just "disk." + + +# Configuring System Components # + +To establish a system configuration for the emulator, you first configure the system components you need, and then add a disk subsystem to that configuration. This section discusses configuring the system components. + +The emulator stores system configurations in a small IndexedDB database named "`retro-B5500-Config`". This database is separate from the ones used for disk subsystems. It is managed entirely by the configuration interface. + +To modify the system configuration, create a new configuration, or select a previously-defined configuration for use, the emulator must be in a powered-off state. It is in this state when you first open the Console window, and after you click the **POWER OFF** button on the Console. + +To open the system configuration interface, simply click the B5500 logo on the right side of the Console, under the Burroughs logo, when the emulator is in a powered-off state. Normally this logo reads "retro-B5500," but if you have previously clicked the Burroughs logo to put the Console in "purist" mode, the logo will simply read "B 5500". The configuration interface will open the System Configuration dialog window that will look similar to this: + +> https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/System-Config-Dialog.PNG + +At the top of the dialog is a pull-down list of system configurations you can choose from. Initially, the only name listed will be "`Default`", which is the configuration that the emulator creates automatically the first time you load it. See [WebUI Getting Started](WebUIGettingStarted.md) for a description of this default configuration. + +When you first open the configuration dialog, the "current" configuration will be loaded into the window. This is the configuration that will be used by the emulator when the system is next powered on. To load a different configuration into the dialog window, simply select it from the pull-down list. + +There are four buttons on the dialog that you use to control maintenance of the configurations: + + * **NEW** -- Click this button to initiate the creation of a new system configuration. The dialog will prompt you for a name for the new configuration. Configuration names may contain any combination of characters and are case-sensitive. After supplying the new name, select the configuration components as described below and click the **SAVE** button to store the new configuration in the emulator's configuration database. + * **DELETE** -- Click this button to delete the configuration currently selected in the pull-down list to its left. The dialog will prompt you for confirmation before deleting the configuration, but once accomplished, the delete cannot be undone. + * **CANCEL** -- Click this button to discard any changes you have made on the configuration dialog (except deletion of one or more configurations) and close the dialog window. + * **SAVE** -- Click this button to save any changes you have made on the configuration dialog and close the dialog window. Clicking this button will also establish the configuration being saved as the "current" configuration. To make another previously-defined configuration the current one, simply open the configuration dialog, select the desired configuration from the pull-down list, and click **SAVE**. + +The remaining buttons on the dialog apply to disk subsystems, and will be discussed in the next section. + +You may have as many system configurations as you wish. You may modify and switch among them at any time the emulator is in a powered-off state. + +You select components for a system configuration by simply checking their corresponding boxes on the configuration dialog. Central Control is implicitly included in every configuration; it does not have a selection on the dialog. There are a few constraints to keep in mind when selecting components for a configuration: + + * At least one processor must be selected in order for the system to run. + * One of the selected processors must be designated as the control processor, P1. If only PA is selected, leave the **PB is P1** checkbox unchecked, designating PA as P1. If only PB is selected, check the **PB is P1** checkbox, designating PB as P1. If both processors are selected, it is your choice which should be P1. + * At least one I/O Control Unit must be selected in order for the system to run. The MCP generally runs best with at least three I/O units. + * At least memory module M0 must be selected. The system will not boot without M0 present. In most cases, you will want to run with all eight memory modules. It is possible to run with "holes" in the module configuration; the MCP will allocate memory around the holes. Attempting to run the MCP without module M1, or with fewer than a total of six memory modules, may prove to be problematic. + * The SPO must be selected in order to run the MCP. + * Paper tape and drum units are not presently supported by the emulator. Their checkboxes are disabled. + * Disk File Control Unit DKA must be selected in order to load from disk, and therefore to run the MCP. DKB is optional, as is the DFX. File Protect Memory (FPM) is presently not supported by the emulator; its checkbox is disabled. See the next section for more information on configuring disk subsystems and components. + * If disk is included in the configuration, you must select a disk subsystem from the **Storage name** pull-down list. + * The Data Communications adapter, DCA, is optional, but should be included if you want to run the Timesharing MCP and CANDE. At present, the emulator supports only one fixed teletype station; thus the additional controls under the DCA checkbox are disabled. + +The SPO, line printers, and card punch have an additional option labeled "Algol Glyphs." These checkboxes set the default mode of those devices for translating the five special Algol characters on output. When the checkbox is checked, the special Algol characters will be output as their corresponding Unicode glyphs. When the box is unchecked, those characters will be output using their ASCII substitutions. This setting can be overridden temporarily on the individual devices. See the respective wiki pages for the devices for details on how to do this. + +Note that you can easily create a system configuration that is either non-functional (e.g., no processor) or that will not support the MCP. The emulator will refuse to perform a load if the minimum components necessary for a running system are not present. + + +# Configuring Disk Subsystems # + +Prior to release 1.00, the emulator supported a single disk subsystem using an IndexedDB database named "`B5500DiskUnit`". This subsystem had a fixed configuration of two EUs, each with five Model-I SUs, for a total of 200,000 30-word sectors, or 96M 6-bit characters of storage. + +As part of the new configuration mechanism introduced in release 1.00, you can now modify the configuration of a disk subsystem to provide more storage. You can select between Model-I and Model-IB SUs to trade off access time vs. storage space. You can also create multiple disk subsystems and associate them with one or more system configurations. Only one disk subsystem can be associated and used with a given system configuration at a time, however. + +A disk subsystem from an earlier release can be used with 1.00 and later releases. Such a subsystem can continue to be used with earlier releases as well, subject to the constraints discussed in [Upgrading from Earlier Emulator Versions](WebUIConfiguringTheSystem#Upgrading_from_Earlier_Emulator_Versions.md), below. + +Each disk subsystem is implemented as a separate IndexedDB database. Each subsystem has a name you assign when the subsystem is created. That name is also the name of the IndexedDB database for the subsystem. Disk subsystems from earlier versions of the emulator continue to have the name `B5500DiskUnit`. + +Disk subsystems are associated with system configurations by means of the pull-down list on the System Configuration dialog window labeled **Storage name**. This list contains the names of all disk subsystems known to the emulator. The entry selected in this list will become the subsystem that is associated with the configuration when the **SAVE** button on the configuration dialog is clicked. + +Next to the pull-down list are two buttons that allow you to access the disk subsystem configuration interface: + + * **NEW** -- Click this button to create a new disk subsystem and its IndexedDB database. The dialog will prompt you for the name of the new subsystem and then display the Disk Storage Configuration dialog discussed below. If you supply the name of an existing disk subsystem, that subsystem will be updated as if you had clicked the **EDIT** button for it instead. + * **EDIT** -- Click this button to view or modify the subsystem currently selected in the pull-down list. + +Clicking either of these buttons will open the Disk Storage Configuration dialog, which will look similar to this: + +> https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU//Disk-Config-Dialog.PNG + +The name of the new or selected disk subsystem is shown in the area labeled **Subsystem**. The storage configuration dialog is controlled using three buttons: + + * **DELETE** -- Click this yellow button after opening an existing disk subsystem configuration to delete that subsystem and its IndexedDB database. The dialog will ask for confirmation that you want to delete the subsystem. Once accomplished, the delete cannot be undone. After deleting the database, the dialog window will close. Note that if you attempt to delete a subsystem that was opened as new, the dialog window will simply close without creating the new subsystem. + * **CANCEL** -- Click this button to close the dialog window without modifying or creating the disk subsystem. + * **SAVE** -- Click this button to save the current disk subsystem configuration, close the dialog window, and return to the System Configuration dialog window. + +The remainder of the dialog has a set of 20 groups of controls, labeled `EU0` through `EU20`. Each of these represents one Disk Electronics Unit in the configuration, and each has the following controls: + + * A checkbox. Checking the box will include the EU in the configuration. If the box is not checked, the other controls are ignored. + * A pull-down list to select the number of SUs, `1` to `5`, to be configured for this EU. + * A pull-down list to select to the model of SU to be configured for this EU, "`I`" or "`IB`". The model selection applies to all of the SUs for that EU. + +The primary constraint on configuration of a disk subsystem is that once storage space has been assigned to a disk subsystem, it cannot be removed. Once you click the **SAVE** button, any items you have selected on the Disk Subsystem Configuration dialog become a permanent part of the subsystem. The primary reason for this constraint is that, since the B5500 MCP considers disk to be a monolithic resource, parts of files could be spread across multiple EUs and located anywhere on the respective disk units. Removing storage space from the configuration may cause parts of files to disappear, so the emulator does not allow this. + +This constraint manifests itself in three ways on the configuration dialog window: + + 1. Once an EU is included in a subsystem, it may not be removed. Its checkbox will be disabled. + 1. The number of SUs specified for an EU may be increased, but not decreased. Selections for smaller numbers of SUs are disabled in the pull-down list. + 1. An EU with Model-I SUs may be changed to Model-IB SUs, but not the reverse. Since Model-IB SUs have twice the storage capacity of Model-Is, switching from Model-IB to Model-I would reduce the space allocated to the subsystem. If "`IB`" is selected in the pull-down list, the "`I`" selection is disabled. + +If you absolutely must reduce the size of a disk subsystem, the only way to do this that the emulator supports is to dump the files to tape using the MCP `?DUMP` or `?UNLOAD` control-card command, delete the disk subsystem, recreate it, Cold Start the new subsystem, and reload the files using the MCP `?LOAD` or `?ADD` command. + +Another constraint on disk subsystem configuration concerns the number of DFCUs in the system configuration, whether a DFX is included in the system configuration, and the EU numbers selected for the disk subsystem: + + * A configuration with a single DFCU (i.e., DKA) can support up to 10 EUs. These must be numbered in the range of `EU0`-`9`. + * A configuration with two DFCUs and no DFX can support up to 20 EUs, with `EU0`-`9` being addressed by DKA and `EU10`-`19` addressed by DKB. + * A configuration with two DFCUs and the DFX enabled can support up to 10 EUs, numbered in the range `EU0`-`9`. Either DFCU can address any EU, although a given EU can be addressed by only one DFCU at a time. `EU10`-`19` are not addressable in this configuration. This choice generally gives the best performance, as it increases the chance that multiple disk I/Os can occur in parallel. + +IndexedDB implementations in web browsers generally allocate physical disk space on the workstation incrementally, as sectors that had previously been unwritten are written for the first time. Thus, there is generally little, if any, penalty for configuring a disk subsystem that is significantly larger than you initially need. + +Also note that most browsers have a limit on the amount of physical disk space an IndexedDB database may use without approval from the user. This limit varies, but is often in the range of 10-50MB. If you are loading files from tape, or running programs under the emulator that are creating new disk files, and notice that the emulator appears to hang -- check the Console window for an alert requesting permission to use more disk space. Since other windows, such as the SPO, are often on top of the Console window, this alert may not be visible until the Console window is brought to the top and given the focus. + +Finally, note that IndexedDB databases are subject to the "same-origin" policy within the browser. This means that access to an IndexedDB database is constrained in two ways: + + 1. You must use the same browser. IndexedDB implementations vary from browser to browser, and are likely incompatible with each other. An IndexedDB database created by Google Chrome cannot be accessed by Mozilla Firefox. + 1. You must access the web site hosting the emulator using the same host name and port number. For example, our hosting site for the emulator can be accessed using either `phkimpel.us` or `www.phkimpel.us` (we recommend the latter). Even though those two host names reference the same set of files on the same server, they are considered to be separate origins, and will have separate sets of IndexedDB databases. A disk subsystem created using the emulator loaded from one host name will be inaccessible to an emulator loaded from the other. + + +# Creating an Initial Configuration # + +When you load the emulator into a browser on a workstation for the first time, the emulator will automatically create a default system configuration and disk subsystem when the emulator is first powered on. This configuration is generally adequate for most people in their initial use of the emulator. + +See [Create the Initial System Configuration](WebUIGettingStarted#Create_the_Initial_System_Configuration.md) for details on how this occurs and [Default System Configuration](WebUIGettingStarted#Default_System_Configuration.md) for a description of the components in the default configuration. + +You can, of course, use the configuration mechanism described above in this wiki to modify that default configuration and create one that is more suited to your needs. You can also leave that default configuration as is and create one or more additional configurations with different components and disk subsystems. + +If you want to inhibit establishment of that default configuration and create your own from scratch, however, you must create that configuration before you power on the emulator for the first time. After loading the emulator into the browser, simply click the B5500 logo to open the System Configuration dialog. That dialog will show a configuration entry for `Default` and a disk subsystem entry for `B5500DiskUnit`. The default system configuration will have been created, but the disk subsystem at this point will not have been created yet. You can proceed to create a new system configuration by clicking the **NEW** button. Afterwards, you can delete the original `Default` configuration or not, as you prefer. + + +# Upgrading from Earlier Emulator Versions # + +The static system configuration used in emulator releases before 1.00 cannot be brought forward into later versions of the emulator, although you can modify the default configuration or create a new one to reproduce its characteristics. Disk subsystems are persistent, however, and the IndexedDB databases from earlier versions of the emulator can still be used without change on release 1.00 and later versions. + +Disk subsystems created by release 1.00 and later versions of the emulator cannot be used by earlier versions. The format of the configuration data stored within the subsystem database has changed in a way that earlier versions cannot use. + +Disk subsystems created by versions prior to 1.00 can be used by 1.00 and later versions. Such subsystems can also continue to be used by versions of the emulator earlier than 1.00, _provided the configuration of the disk subsystem is not changed_. Once you modify the configuration of a disk subsystem, the configuration data stored in its database is converted to the new format and the subsystem is no longer usable by earlier versions of the emulator. If you plan to run multiple versions of the emulator from the same host server, you should keep this restriction in mind. \ No newline at end of file diff --git a/WebUIGettingStarted.md b/WebUIGettingStarted.md deleted file mode 100644 index 2fab0b4..0000000 --- a/WebUIGettingStarted.md +++ /dev/null @@ -1,358 +0,0 @@ -# WebUI Getting Started # - - - -# 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) is the external representation the system and provides the means by which you interact with it. Because the implementation of I/O devices depends heavily on the environment in which the UI operates, a UI for this emulator 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 is designed to run in a web browser. This page describes the setup procedures for that UI. - -> _Note:_ The setup and initialization process for the emulator changed dramatically in release 1.00. This page describes the new process that started with that release. Prior to that time, this process was done by a special web page, `B5500ColdLoader.html`, which initialized the disk subsystem, performed the functions of a Cold Start, and loaded an initial set of system files. That script will still work, but it is now deprecated and will be removed in a future release. Instructions for the prior process are still available in [0.20-WebUIGettingStarted]. We strongly recommend you use the new process described below when using release 1.00 or later. - -## 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 in the following sections: - - * Use a suitable web browser -- at present, that means Mozilla Firefox or Google Chrome. See [The Web Browser](WebUIGettingStarted#The_Web_Browser.md) 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 [The Web Server](WebUIGettingStarted#The_Web_Server.md) and [The Emulator Files](WebUIGettingStarted#The_Emulator_Files.md) below for details. - * Download a copy of the Burroughs B5500 system software tape images from http://www.phkimpel.us/B5500/webSite/SoftwareRequest.html. See [The Burroughs B5500 Software](WebUIGettingStarted#The_Burroughs_B5500_Software.md) below for details. - * Configure the system components and create the disk subsystem. See [Configure the System](WebUIGettingStarted#Configure_the_System.md) below for details. - * Cold Start the disk subsystem and load the system software to it. See [Initialize the System](WebUIGettingStarted#Initialize_the_System.md) below for details. - * In your web browser, access the **`webUI/B5500Console.html`** home page from the web server to run the emulator. - - -# What You Will Need # - -To use the web-based emulator, you will need four things: - - 1. A suitable web browser. - 1. A web server configured to deliver files from the emulator directories (our hosting site is set up to do this). - 1. 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). - 1. 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 - * `performance.now()` API - * HTML `` element - -As of this writing, the emulator has been tested with and works with Mozilla Firefox (version 21 and above) and Google Chrome (version 35 and above).1 Somewhat earlier versions of these browsers may also work. Apple Safari will not support the emulator, because it does not as yet support the IndexedDB API.2 The emulator runs fine under Firefox or Chrome on a Macintosh, however. Microsoft Internet Explorer (at least through IE10) will not support the emulator. We have not yet tried Opera. - -## The Web Server ## - -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. -See [Establish the Web Server](WebUIGettingStarted#Establish_the_Web_Server.md) -below for more details. - -If you need a small, simple web server to host the emulator locally, we have had good success with **`mongoose`** (https://github.com/valenok/mongoose). It can run on the same workstation as your browser to serve the emulator files using the loop-back port (localhost or 127.0.0.1). Versions are available that run under Windows, Linux, UNIX, and Mac OS. It is extremely easy to set up. Under Windows, it can run as either a user 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. - -Beginning with release 1.00, the emulator can now run off-line, without access to the web server from which it is hosted. Off-line operation is automatic when the browser supports the HTML5 "application cache" standard and is operating without a network connection or cannot contact the web server. See the discussion on off-line operation in [Using the Console](WebUIUsingTheConsole.md) for details on how this works. - -## 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 script that defines the configuration of the system components. - * **`webUI/`** contains everything else you need to run the system. In particular, it contains the Console UI, the peripheral device drivers, and a Syllable Debugger utility that can be used to examine the state of the processors and memory while running programs under its control, including the MCP. - -A third directory, **`tools/`** contains standalone utilities that can be used to maintain and examine the emulator environment. This directory also contains a few standard card decks that are used with the emulator: - - * **[COLDSTART-XIII.card](http://www.phkimpel.us/B5500/tools/COLDSTART-XIII.card)**: This contains the card images necessary to Cold Start the disk subsystem and load an initial set of system files. It consists of two standalone card-load programs and their parameter cards. You may use this as is, or as a base to create a customized load deck. See [Initialize the System](WebUIGettingStarted#Initialize_the_System.md) below for details on its use. - * **[ESPOL-Binary-Card-Loader.card](http://www.phkimpel.us/B5500/tools/ESPOL-Binary-Card-Loader.card)**: This is a single binary-card image for the boot loader used with several card-load decks. Copies of this are already included in the Cold Start deck above. - * **[CONTROL.DECK.card](http://www.phkimpel.us/B5500/tools/CONTROL.DECK.card)**: This is a single card image used to label a card reader for the MCP's "Load Control" (input spooling) utility. - * **[END.CONTROL.card](http://www.phkimpel.us/B5500/tools/END.CONTROL.card)**: This is a single card image used to terminate use of Load Control on a card reader. - -Recent releases of the emulator files can be obtained from -[our download site](https://drive.google.com/folderview?id=0BxqKm7v4xBswM29qUkxPTkVfYzg&usp=sharing). Each release is packaged as a separate `.zip` file. - -If you use a web server that already has the emulator files set up, you do not need to download a separate copy of an emulator release. Unless you are running your web server on the same workstation as your web browser, you do not need to store the emulator scripts on your workstation. You will need to download at least the Cold Start deck, though, which can be done using the link in the bullet list above. - -## 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 for the B5500 system software. We have acquired an educational/hobbyist license from Unisys 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 the open-source project site with the rest of the 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 -[page on our hosting service](http://www.phkimpel.us/B5500/webSite/SoftwareRequest.html). Go to that page, review and accept the licensing terms (they are not onerous), and download one or more of the tape images. See -[Download the B5500 System Software](WebUIGettingStarted#Download_the_B5500_System_Software.md) 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 Start process, discussed below](WebUIGettingStarted#Cold-Starting_the_System.md), 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 wish to use your own web server, however, the general steps to set up the emulator files are: - - 1. Create a new virtual directory for the web server, e.g., `/B5500/`, to hold the emulator files. - 1. To support the off-line "application cache" capability, you may need to create a mapping in the server between the "`.appcache`" file extension and the "`text/cache-manifest`" MIME type. - 1. Download one of the emulator releases (the one with the highest release-number suffix is usually best) from [our download site](https://drive.google.com/folderview?id=0BxqKm7v4xBswM29qUkxPTkVfYzg&usp=sharing). - 1. Unzip the release into the directory on your server's file system where the virtual directory is mapped. You will need the files from at least the **`emulator/`** and **`webUI/`** directories. Those directories should be created 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. - -Even though the `.bcd` files are not needed to run the emulator, you will probably want to keep them available on your workstation. Not all of the files from these tapes need to be loaded when the system is initialized. You may load a minimal set of files at first, and then incrementally load additional files as needed using MCP `?LOAD` or `?ADD` control cards as discussed under [Loading the System Files](WebUIGettingStarted#Loading_the_System_Files.md) below. - -## Initialize the System ## - -The web-based emulator uses HTML5 IndexedDB databases to implement disk storage, plus a small database for system configuration data. IndexedDB is essentially a small database server embedded within the web browser. The database data is stored in one or more files on your local workstation, but is usually hidden deep within the profile directory your browser maintains for your user account on the workstation. It generally is not easy to access the physical files for these databases, nor is there any need to do so. - -> _Note:_ You _must_ run the emulator consistently from the same web site in order to access the same IndexedDB database. You must also consistently 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 load the emulator from different web sites, the browser will access separate databases for each web site. - -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 emulator using two different URLs for our hosting site, - - * `http://www.phkimpel.us/B5500/webUI/B5500Console.html` - * `http://phkimpel.us.B5500/webUI/B5500Console.html` - -Both URLs reference the same physical server and web pages, but accessing the emulator 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 a given instance of the emulator. You may, of course, use different browsers to run separate instances of the emulator. - -### Create the Initial System Configuration ### - -When first starting out with the emulator, the easiest approach is to allow the emulator to create a default system and disk configuration. This will occur automatically the first time you "power on" the emulator unless you take specific steps beforehand to set up a non-default configuration. The default configuration can be easily changed after it is created. In addition, you can create and maintain multiple configurations, and switch among them. - -See the [Configuring the System](WebUIConfiguringTheSystem.md) page for information on establishing a non-default configuration and modifying a configuration once it is established. The remainder of this section will describe how to proceed with a default initial configuration, and assumes you are installing the emulator on your workstation for the first time. - -To begin, load the emulator home page into your web browser. If you are running your own web server, access 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 - -The home page will look similar to this: - -> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Home-Page.png](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Home-Page.png) - -The home page has two buttons, each of which will start the emulator and open a window for the Operator Console: - - * **Start & Power On** will display the Console window and automatically power up the emulator, as if you had clicked the Console's green **POWER ON** button. - * **Start - Powered Off** will simply display the Console window without powering up the emulator. This button is useful if you want to make configuration changes to the emulator, as those can only be made while the emulator is in a powered-off state. - -The Console is a small control panel with several buttons and lights. The layout and function of this panel is described in the [Using the B5500 Console](WebUIUsingTheConsole.md) page. - -Next, if you did not choose to power on the emulator when opening the Console window, click the green **POWER ON** button on the Console. It will illuminate. - -Regardless of the method that was used to power on the emulator, it will now attempt to open its configuration database, and finding that it does not exist, will display an alert similar to this: - -> https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/System-Config-Does-Not-Exist.PNG - -In order to proceed with the initialization, click the **OK** button. The emulator will create its configuration database, store a default configuration named `Default` in it, and then display the following confirmation: - -> https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/Configuration-Default-Created.PNG - -When you click the **OK** button on this confirmation to continue, the emulator will proceed with its internal initialization and open several sub-windows for the peripheral I/O devices. When it attempts to initialize the disk subsystem (which does not have a window), it will find that the IndexedDB database for that subsystem does not exist and display the following alert: - -> https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/Disk-Config-Does-Not-Exist.PNG - -> Note that this alert is posted to the main Operator Console window and may be obscured by other windows which have opened. You may need to bring the Operator Console window to the foreground in order to see this alert. - -Click the **OK** button on this alert to continue. The emulator will create a default disk subsystem named `B5500DiskUnit` and display this confirmation: - -> https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/Disk-Config-Created.PNG - -Clicking **OK** on the confirmation will allow the emulator to finish its initialization and open any additional windows for the peripheral I/O devices. The entire process should take only a few seconds. You are now ready to Cold Start the disk subsystem and load the system software. - -### Default System Configuration ### - -The default configuration created by the emulator will consist of the following system components: - - * One Processor, PA, set to operate as the control processor, P1. - * Three Input/Output Control Units, IO1, IO2, IO3. - * Eight 4K-word memory modules, for a total of 32K words (the maximum). - * The Supervisory Printer, SPO. - * One line printer, LPA. - * One card reader, CRA. - * One card punch, CPA. - * One magnetic tape drive, MTA. - * One Disk File Control Unit, DKA, with the Disk File Exchange (DFX) enabled. - * One Data Communications Control Unit, DCA, with a single teletype terminal. - -By default, the initial disk configuration for the emulator has a single Electronics Unit (EU) with 200,000 segments of disk storage. This is equivalent to a full complement of five Model I Storage Units (SUs) on the EU. That translates to six million B5500 words, or 48 million 6-bit characters of disk storage. - -The amount of physical disk space used on your workstation for the emulated disk subsystem will vary depending on the number and size of B5500 files you store while running the emulator. It will also depend on the manner in which IndexedDB has been implemented by your browser. The physical disk space used may be many times the virtual space occupied by B5500 files. - -The IndexedDB database will generally use only the physical disk space needed to support the disk subsystem, but that space will grow as you add more B5500 files in the emulated disk subsystem. Once physical disk space on your workstation is allocated to the database, it will persist until the disk subsystem is deleted. Deleting files in the B5500 environment will not reduce the amount of physical disk space used by the emulator on your workstation, but it will free up space within the emulated disk subsystem that other B5500 files can occupy. - -Additional EUs, to a maximum of 20, may be added to the disk subsystem. The default system configuration has one Disk File Control, DKA. A second control, DKB may be added to the configuration, which will allow two disk I/Os to take place simultaneously, as long as they are to different EUs. Systems with two controls and multiple EUs may also include a Disk File Exchange (DFX), which will allow either control to access any EU. Enabling the DFX will limit the usable number of EUs to a maximum of 10, however. - -See the [Configuring the System](WebUIConfiguringTheSystem.md) page for more information on configuring additional disk units and system components, creating multiple system configurations, and creating multiple disk subsystems. - -### 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 the MCP configuration data on the disk. It it similar in concept 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. - -A real B5500 computer system arrived from the factory with nothing recorded on the disk units. A Cold Start is therefore necessary to create the MCP file system on the disk, establish an initial set of system operational settings, and load the MCP and its bootstrap program to the disk. In addition to initializing a new system, the Cold Start process can be used to reinitialize the disk for an existing system, or to recover from serious disk corruption. "Recover" in this case implies wiping out all of the data and reloading it from backup tapes. - -> _Note:_ The Cold Start process _does not check for a previously existing file system_. It unconditionally creates a new file system, destroying any previously-existing one. You must use the following process with care, especially when you have multiple disk subsystems defined. Make sure you are Cold Starting the correct one. - -Initializing the disk subsystem on a real B5500 involved loading two bootstrap programs from cards, the COLD loader and Tape-to-Disk loader. The COLD loader initialized the file system; the Tape-to-Disk loader copies the MCP operating system file from tape to the new file system and configures the bootstrap mechanism to find it. The emulator uses exactly the same process. - -Before proceeding with this section, you must have completed the following: - - * You must have established an initial system configuration and disk subsystem, as described above under [Initialize the System](WebUIGettingStarted#Initialize-the-System.md). You can use the automatically-created default configuration or a custom one you have created, but it must exist first. If you just initialized the system as described in the previous sections, simply continue from that point. - * You must have downloaded at least the `SYSTEM` tape image, as described in earlier sections, and have that tape image available on your workstation. The name of this tape image as downloaded from our hosting site is `B5500-XIII-SYSTEM-adc00257.bcd`. - * You must have the Cold Start deck available on your workstation. You can copy this file from the `tools/` directory of the emulator files, or [download it from our hosting site](http://www.phkimpel.us/B5500/tools/COLDSTART-XIII.card). - -If you wish to customize the parameter cards in the Cold Start deck, do so before proceeding further. A description of the parameter cards can be found in the [B5500 MCP Operations Manual](http://bitsavers.org/pdf/burroughs/B5000_B5500_B5700/1024916_B5500_B5700_OperMan_Sep68.pdf), starting on page 3-14 ("Card Load Select Programs"). Be careful not to alter the card images containing object code for the programs. Note that the two binary bootstrap card images in this deck are each 160 characters long, and each must be fully contained on one text line. - -The following steps accomplish the Cold Start: - - 1. If the emulator is not already powered on, do so now. - 1. Load the Cold Start deck into the card reader, CRA, and make it ready. See the [Using the Card Reader](WebUIUsingTheCardReader.md) page for instructions on how to load a file from your workstation as a card deck into the reader and make the reader ready. - 1. Load the `SYSTEM` tape into the tape drive and make it ready. See [Using the Magnetic Tape Drive](WebUIUsingTheMagTapeDrive.md) for instructions on how to load a tape image file into a tape drive and make the drive ready. If your configuration has more than one tape drive, the image may be loaded into any of them. - 1. On the Operator Console window, click the yellow **CARD LOAD SELECT** button so that it is illuminated. - 1. On the Operator Console window, click the black **LOAD** button. You should see the reader begin reading cards. If nothing happens, make sure you have the correct deck loaded into the reader and that the reader is in a ready status. If necessary, fix any problems, click **HALT** on the Console, and click **LOAD** again. - 1. The reader will stop about half-way through the deck, after reading the COLD loader program and its parameter cards. It will create the new file system on the disk, store the options specified on the parameter cards, print the message "`DIRECTRY BUILT`" on the SPO, and halt. This completes the first phase of the Cold Start, which should take less than 30 seconds. - 1. To continue, click **HALT** and then **LOAD** on the Operator Console. Make sure that the **CARD LOAD SELECT** button is still illuminated. This reads the Tape-to-Disk loader program into memory and begins executing it. You should see the tape reel icon on the tape drive window spin as it searches the tape and loads the MCP object code to disk. When the load completes successfully, the tape will rewind and the program will print "`MCP FILE LOADED`" on the SPO. - 1. The Tape-to-Disk loader will then halt/load (boot) the system using the MCP file just loaded. - -### The First Halt/Load ### - -This completes the Cold Start process itself, but some additional steps are still necessary to make the system operational. After the halt/load initiated by the Tape-to-Disk loader, the MCP will almost immediately print a message on the SPO: - -``` - -H/L WITH MCP/DISK MARK XIII MODS RRRRRRR@- -``` - -The MCP will spend several seconds preparing its internal tables and initializing its private area of the disk, then print messages similar to the following on the SPO: - -``` - DKA EU0 SU 1,2,3,4,5 WENT READY - TIME IS 0000 - DATE IS SATURDAY, 9/ 1/84 - #TR PLEASE -``` - -The `DKA EU0`... message indicates the MCP has seen EU0 and its five SUs for the first time. You will not see this message after subsequent halt/loads. The time is zero, indicating it has not yet been set. The date comes from one of the parameter cards for the COLD loader in the Cold Start deck. The `#TR PLEASE` message indicates that the MCP will not finish its initialization phase and begin normal operations until the time is set. This behavior is an option specified by one of the parameter cards in the Cold Start deck, and may be changed if desired. It can also be changed using the `RO` SPO command. - -Before setting the time, you should set the date. The B5500 MCP ceased to be supported long before the year 2000 and is not Y2K-compatible. You may enter any date you wish, but it will be a 1900-based date. Hence, the days of the week output by the system may appear to be wrong, as they are being computed using years in the 1900s. We recommend that you choose a year in the 1970s or 1980s. - -To set the date, use the `DT` command, specifying the date in mm/dd/yy format. Click the **INPUT REQUEST** button on the SPO. After the **READY** light illuminates, enter the following on your keyboard, substituting your date. - -``` - DT 9/4/84 -``` - -To terminate the command, either click the **END OF MESSAGE** button on the SPO or press **Enter** on your keyboard. The MCP will respond with a message indicating the new date. - -The time is set in a similar manner using the `TR` command, specifying the time as a four-digit number in 24-hour format: -000000000000............ -``` - TR 1936 -``` - -Once the time has been entered, the MCP is ready for normal operations. You will immediately see the following message, which will be explained shortly. - -``` - ##LOAD INTRNSC/DISK NOW.... -``` - -The standard Cold Start deck has a short sequence of control cards following the Tape-to-Disk loader that will copy a minimal set of files from the `SYSTEM` tape. The card reader should still be ready from its use with the Tape-to-Disk loader, so once you set the time, you should see these cards being read, the `SYSTEM` tape begin to spin again, and a series of messages similar to the following print on the SPO: - -``` - 5:LIBMAIN/DISK= 1 BOJ 1936 - MTA IN 0 SYSTEM 1:LIBMAIN/DISK= 1 - INT/DISK LOADED,MTA - PRNPBT/DISK LOADED,MTA - LDCNTRL/DISK LOADED,MTA - ALGOL/DISK LOADED,MTA - COBOL/DISK LOADED,MTA - FORTRAN/DISK LOADED,MTA - XALGOL/DISK LOADED,MTA - LOGOUT/DISK LOADED,MTA - LIBMAIN/DISK= 1 EOJ 1937 -``` - -This loads the System Intrinsics (`INT/DISK`), the printer output spooler (`PRNPBT/DISK`), the card input spooler (`LDCNTRL/DISK`), four compilers, and a program to print the system log file. You can edit the control cards at the end of the Cold Start deck to load more or fewer files, or add and remove files later using the SPO or another card deck. We recommend that you load at least the `INT/DISK` file at this point, however. - -The System Intrinsics is a library of common routines that can be dynamically bound to user programs. It contains the math functions, input/output formatting routines, and a variety of other support routines used by various programming languages. Its name must be specified to the MCP, and since this is the first time the system has been booted since the Cold Start, the MCP does not yet have that name. Hence the "`##LOAD`..." message above. - -To specify the name of the Intrinsics file, use the `CI` SPO command, thus: - -``` - CI INT/DISK -``` - -You should only need to do this once. The MCP will store the name with the other system options on disk and automatically load the Intrinsics from that file after subsequent halt/loads. - -The system and MCP are now ready for use. For additional information on using the SPO, see the [Using the SPO](WebUIUsingTheSPO.md) page. For a general overview of emulator and MCP operations, see the [Running the Emulator](WebUIRunningTheEmulator.md) page. - -### Loading Additional System Files ### - -You may wish to load additional files from the `SYSTEM` tape once the Cold Start process is completed and the MCP is operational. The following are good candidates for additional system files to load, 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 formatting documentation and cross-referencing identifiers in source files. - -"Library/Maintenance" is the portion of the MCP that manages disk files and maintains the disk directory. Among its features is the capability to dump disk files to and load disk files from magnetic tape. This was typically used for software distribution, file backup, archiving, and transferring files between systems. - -Files can be loaded from Library/Maintenance volumes such as the `SYSTEM`, `SYMBOL1`, and `SYMBOL2` tape images using the `LOAD` and `ADD` control card commands, e.g., - -``` - ?LOAD FROM SYSTEM ESPOL/DISK, COBOL/DISK, DUMP/ANALYZE; END -``` - -The `ADD` command works the same as `LOAD`, except that it loads only those files that are not already in the disk directory. - -A control card command can be continued across multiple card images by terminating a card with a hyphen (`-`) wherever a word or punctuation character might appear. The continuation line(s) that follow must not have an invalid character in column 1. The command must be terminated either by appending `;END` on the last line or by a final line with `?END` beginning in column 1. - -All files having the same first or last identifier in their file name may be loaded by specifying _MFID_`/=` or `=/`_FID_, where _MFID_ is the "multi-file identifier" and _FID_ is the "file identifier" portion of a file name, respectively. All files from a tape can be loaded by specifying `=/=`. Library/Maintenance will not overwrite certain critical system files, such as the currently running MCP, the Intrinsics, or the system log. - -See [Using the Magnetic Tape Drive](WebUIUsingTheMagTapeDrive.md) for more information on how to mount tape images onto a tape drive. See Section 4, and in particular page 4-15 ff, in http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1024916_B5500_B5700_OperMan_Sep68.pdf for more information on control card syntax and the Library/Maintenance commands. - - -# Next Steps # - -See [WebUI Running the Emulator](WebUIRunningTheEmulator.md) for detailed instructions on how to start the emulator and run the emulated B5500 system. - -See [the Burroughs documents at bitsavers.org](http://bitsavers.org/pdf/burroughs/B5000_5500_5700/) for copies of the original Burroughs manuals and other reference information on the B5500 system. - - - -`____________` - -1 Earlier versions of the emulator ran fine on Chrome 27 (the earliest version we tested), but somewhere around Chrome 30 the browser started crashing ("Aw, Snap!") while running the emulator. This appears to have been a problem with garbage collection, resulting in the browser running out of memory. The problem was resolved in mid-2014 with Chrome 35. - -2 Apple Safari is rumored to have support for IndexedDB in version 8. See http://caniuse.com/#feat=indexeddb for the current status. \ No newline at end of file diff --git a/WebUIGettingStarted.wiki b/WebUIGettingStarted.wiki index 214a29a..2fab0b4 100644 --- a/WebUIGettingStarted.wiki +++ b/WebUIGettingStarted.wiki @@ -1,289 +1,286 @@ -#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 = - - - -= 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) is the external representation the system and provides the means by which you interact with it. Because the implementation of I/O devices depends heavily on the environment in which the UI operates, a UI for this emulator 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 is designed to run in a web browser. This page describes the setup procedures for that UI. - - _Note:_ The setup and initialization process for the emulator changed dramatically in release 1.00. This page describes the new process that started with that release. Prior to that time, this process was done by a special web page, `B5500ColdLoader.html`, which initialized the disk subsystem, performed the functions of a Cold Start, and loaded an initial set of system files. That script will still work, but it is now deprecated and will be removed in a future release. Instructions for the prior process are still available in [0.20-WebUIGettingStarted]. We strongly recommend you use the new process described below when using release 1.00 or later. - -== 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 in the following sections: - - * Use a suitable web browser -- at present, that means 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. - * Configure the system components and create the disk subsystem. See [WebUIGettingStarted#Configure_the_System Configure the System] below for details. - * Cold Start the disk subsystem and load the system software to it. See [WebUIGettingStarted#Initialize_the_System Initialize the System] below for details. - * In your web browser, access the *`webUI/B5500Console.html`* home 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 - * `performance.now()` API - * HTML `` element - -As of this writing, the emulator has been tested with and works with Mozilla Firefox (version 21 and above) and Google Chrome (version 35 and above).^1^ Somewhat earlier versions of these browsers may also work. Apple Safari will not support the emulator, because it does not as yet support the IndexedDB API.^2^ The emulator runs fine under Firefox or Chrome on a Macintosh, however. Microsoft Internet Explorer (at least through IE10) will not support the emulator. We have not yet tried Opera. - -== The Web Server == - -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. -See [WebUIGettingStarted#Establish_the_Web_Server Establish the Web Server] -below for more details. - -If you need a small, simple web server to host the emulator locally, we have had good success with *`mongoose`* (https://github.com/valenok/mongoose). It can run on the same workstation as your browser to serve the emulator files using the loop-back port (localhost or 127.0.0.1). Versions are available that run under Windows, Linux, UNIX, and Mac OS. It is extremely easy to set up. Under Windows, it can run as either a user 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. - -Beginning with release 1.00, the emulator can now run off-line, without access to the web server from which it is hosted. Off-line operation is automatic when the browser supports the HTML5 "application cache" standard and is operating without a network connection or cannot contact the web server. See the discussion on off-line operation in [WebUIUsingTheConsole Using the Console] for details on how this works. - -== 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 script that defines the configuration of the system components. - * *`webUI/`* contains everything else you need to run the system. In particular, it contains the Console UI, the peripheral device drivers, and a Syllable Debugger utility that can be used to examine the state of the processors and memory while running programs under its control, including the MCP. - -A third directory, *`tools/`* contains standalone utilities that can be used to maintain and examine the emulator environment. This directory also contains a few standard card decks that are used with the emulator: - - * *[http://www.phkimpel.us/B5500/tools/COLDSTART-XIII.card COLDSTART-XIII.card]*: This contains the card images necessary to Cold Start the disk subsystem and load an initial set of system files. It consists of two standalone card-load programs and their parameter cards. You may use this as is, or as a base to create a customized load deck. See [WebUIGettingStarted#Initialize_the_System Initialize the System] below for details on its use. - * *[http://www.phkimpel.us/B5500/tools/ESPOL-Binary-Card-Loader.card ESPOL-Binary-Card-Loader.card]*: This is a single binary-card image for the boot loader used with several card-load decks. Copies of this are already included in the Cold Start deck above. - * *[http://www.phkimpel.us/B5500/tools/CONTROL.DECK.card CONTROL.DECK.card]*: This is a single card image used to label a card reader for the MCP's "Load Control" (input spooling) utility. - * *[http://www.phkimpel.us/B5500/tools/END.CONTROL.card END.CONTROL.card]*: This is a single card image used to terminate use of Load Control on a card reader. - -Recent releases of the emulator files can be obtained 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 that already has the emulator files set up, you do not need to download a separate copy of an emulator release. Unless you are running your web server on the same workstation as your web browser, you do not need to store the emulator scripts on your workstation. You will need to download at least the Cold Start deck, though, which can be done using the link in the bullet list above. - -== 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 for the B5500 system software. We have acquired an educational/hobbyist license from Unisys 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 the open-source project site with the rest of the 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 [WebUIGettingStarted#Cold-Starting_the_System Cold Start process, 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 wish to use your own web server, however, the general steps to set up the emulator files are: - - # Create a new virtual directory for the web server, e.g., `/B5500/`, to hold the emulator files. - # To support the off-line "application cache" capability, you may need to create a mapping in the server between the "`.appcache`" file extension and the "`text/cache-manifest`" MIME type. - # 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 the files from at least the *`emulator/`* and *`webUI/`* directories. Those directories should be created 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. - -Even though the `.bcd` files are not needed to run the emulator, you will probably want to keep them available on your workstation. Not all of the files from these tapes need to be loaded when the system is initialized. You may load a minimal set of files at first, and then incrementally load additional files as needed using MCP `?LOAD` or `?ADD` control cards as discussed under [WebUIGettingStarted#Loading_the_System_Files Loading the System Files] below. - -== Initialize the System == - -The web-based emulator uses HTML5 IndexedDB databases to implement disk storage, plus a small database for system configuration data. IndexedDB is essentially a small database server embedded within the web browser. The database data is stored in one or more files on your local workstation, but is usually hidden deep within the profile directory your browser maintains for your user account on the workstation. It generally is not easy to access the physical files for these databases, nor is there any need to do so. - - _Note:_ You _must_ run the emulator consistently from the same web site in order to access the same IndexedDB database. You must also consistently 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 load the emulator from different web sites, the browser will access separate databases for each web site. - -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 emulator using two different URLs for our hosting site, - - * `http://www.phkimpel.us/B5500/webUI/B5500Console.html` - * `http://phkimpel.us.B5500/webUI/B5500Console.html` - -Both URLs reference the same physical server and web pages, but accessing the emulator 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 a given instance of the emulator. You may, of course, use different browsers to run separate instances of the emulator. - -=== Create the Initial System Configuration === - -When first starting out with the emulator, the easiest approach is to allow the emulator to create a default system and disk configuration. This will occur automatically the first time you "power on" the emulator unless you take specific steps beforehand to set up a non-default configuration. The default configuration can be easily changed after it is created. In addition, you can create and maintain multiple configurations, and switch among them. - -See the [WebUIConfiguringTheSystem Configuring the System] page for information on establishing a non-default configuration and modifying a configuration once it is established. The remainder of this section will describe how to proceed with a default initial configuration, and assumes you are installing the emulator on your workstation for the first time. - -To begin, load the emulator home page into your web browser. If you are running your own web server, access 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 - -The home page will look similar to this: - - https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Home-Page.png - -The home page has two buttons, each of which will start the emulator and open a window for the Operator Console: - - * *Start & Power On* will display the Console window and automatically power up the emulator, as if you had clicked the Console's green *POWER ON* button. - * *Start - Powered Off* will simply display the Console window without powering up the emulator. This button is useful if you want to make configuration changes to the emulator, as those can only be made while the emulator is in a powered-off state. - -The Console is a small control panel with several buttons and lights. The layout and function of this panel is described in the [WebUIUsingTheConsole Using the B5500 Console] page. - -Next, if you did not choose to power on the emulator when opening the Console window, click the green *POWER ON* button on the Console. It will illuminate. - -Regardless of the method that was used to power on the emulator, it will now attempt to open its configuration database, and finding that it does not exist, will display an alert similar to this: - - https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/System-Config-Does-Not-Exist.PNG - -In order to proceed with the initialization, click the *OK* button. The emulator will create its configuration database, store a default configuration named `Default` in it, and then display the following confirmation: - - https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/Configuration-Default-Created.PNG - -When you click the *OK* button on this confirmation to continue, the emulator will proceed with its internal initialization and open several sub-windows for the peripheral I/O devices. When it attempts to initialize the disk subsystem (which does not have a window), it will find that the IndexedDB database for that subsystem does not exist and display the following alert: - - https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/Disk-Config-Does-Not-Exist.PNG - - Note that this alert is posted to the main Operator Console window and may be obscured by other windows which have opened. You may need to bring the Operator Console window to the foreground in order to see this alert. - -Click the *OK* button on this alert to continue. The emulator will create a default disk subsystem named `B5500DiskUnit` and display this confirmation: - - https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/Disk-Config-Created.PNG - -Clicking *OK* on the confirmation will allow the emulator to finish its initialization and open any additional windows for the peripheral I/O devices. The entire process should take only a few seconds. You are now ready to Cold Start the disk subsystem and load the system software. - -=== Default System Configuration === - -The default configuration created by the emulator will consist of the following system components: - - * One Processor, PA, set to operate as the control processor, P1. - * Three Input/Output Control Units, IO1, IO2, IO3. - * Eight 4K-word memory modules, for a total of 32K words (the maximum). - * The Supervisory Printer, SPO. - * One line printer, LPA. - * One card reader, CRA. - * One card punch, CPA. - * One magnetic tape drive, MTA. - * One Disk File Control Unit, DKA, with the Disk File Exchange (DFX) enabled. - * One Data Communications Control Unit, DCA, with a single teletype terminal. - -By default, the initial disk configuration for the emulator has a single Electronics Unit (EU) with 200,000 segments of disk storage. This is equivalent to a full complement of five Model I Storage Units (SUs) on the EU. That translates to six million B5500 words, or 48 million 6-bit characters of disk storage. - -The amount of physical disk space used on your workstation for the emulated disk subsystem will vary depending on the number and size of B5500 files you store while running the emulator. It will also depend on the manner in which IndexedDB has been implemented by your browser. The physical disk space used may be many times the virtual space occupied by B5500 files. - -The IndexedDB database will generally use only the physical disk space needed to support the disk subsystem, but that space will grow as you add more B5500 files in the emulated disk subsystem. Once physical disk space on your workstation is allocated to the database, it will persist until the disk subsystem is deleted. Deleting files in the B5500 environment will not reduce the amount of physical disk space used by the emulator on your workstation, but it will free up space within the emulated disk subsystem that other B5500 files can occupy. - -Additional EUs, to a maximum of 20, may be added to the disk subsystem. The default system configuration has one Disk File Control, DKA. A second control, DKB may be added to the configuration, which will allow two disk I/Os to take place simultaneously, as long as they are to different EUs. Systems with two controls and multiple EUs may also include a Disk File Exchange (DFX), which will allow either control to access any EU. Enabling the DFX will limit the usable number of EUs to a maximum of 10, however. - -See the [WebUIConfiguringTheSystem Configuring the System] page for more information on configuring additional disk units and system components, creating multiple system configurations, and creating multiple disk subsystems. - -=== 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 the MCP configuration data on the disk. It it similar in concept 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. - -A real B5500 computer system arrived from the factory with nothing recorded on the disk units. A Cold Start is therefore necessary to create the MCP file system on the disk, establish an initial set of system operational settings, and load the MCP and its bootstrap program to the disk. In addition to initializing a new system, the Cold Start process can be used to reinitialize the disk for an existing system, or to recover from serious disk corruption. "Recover" in this case implies wiping out all of the data and reloading it from backup tapes. - - _Note:_ The Cold Start process _does not check for a previously existing file system_. It unconditionally creates a new file system, destroying any previously-existing one. You must use the following process with care, especially when you have multiple disk subsystems defined. Make sure you are Cold Starting the correct one. - -Initializing the disk subsystem on a real B5500 involved loading two bootstrap programs from cards, the COLD loader and Tape-to-Disk loader. The COLD loader initialized the file system; the Tape-to-Disk loader copies the MCP operating system file from tape to the new file system and configures the bootstrap mechanism to find it. The emulator uses exactly the same process. - -Before proceeding with this section, you must have completed the following: - - * You must have established an initial system configuration and disk subsystem, as described above under [WebUIGettingStarted#Initialize-the-System Initialize the System]. You can use the automatically-created default configuration or a custom one you have created, but it must exist first. If you just initialized the system as described in the previous sections, simply continue from that point. - * You must have downloaded at least the `SYSTEM` tape image, as described in earlier sections, and have that tape image available on your workstation. The name of this tape image as downloaded from our hosting site is `B5500-XIII-SYSTEM-adc00257.bcd`. - * You must have the Cold Start deck available on your workstation. You can copy this file from the `tools/` directory of the emulator files, or [http://www.phkimpel.us/B5500/tools/COLDSTART-XIII.card download it from our hosting site]. - -If you wish to customize the parameter cards in the Cold Start deck, do so before proceeding further. A description of the parameter cards can be found in the [http://bitsavers.org/pdf/burroughs/B5000_B5500_B5700/1024916_B5500_B5700_OperMan_Sep68.pdf B5500 MCP Operations Manual], starting on page 3-14 ("Card Load Select Programs"). Be careful not to alter the card images containing object code for the programs. Note that the two binary bootstrap card images in this deck are each 160 characters long, and each must be fully contained on one text line. - -The following steps accomplish the Cold Start: - - # If the emulator is not already powered on, do so now. - # Load the Cold Start deck into the card reader, CRA, and make it ready. See the [WebUIUsingTheCardReader Using the Card Reader] page for instructions on how to load a file from your workstation as a card deck into the reader and make the reader ready. - # Load the `SYSTEM` tape into the tape drive and make it ready. See [WebUIUsingTheMagTapeDrive Using the Magnetic Tape Drive] for instructions on how to load a tape image file into a tape drive and make the drive ready. If your configuration has more than one tape drive, the image may be loaded into any of them. - # On the Operator Console window, click the yellow *CARD LOAD SELECT* button so that it is illuminated. - # On the Operator Console window, click the black *LOAD* button. You should see the reader begin reading cards. If nothing happens, make sure you have the correct deck loaded into the reader and that the reader is in a ready status. If necessary, fix any problems, click *HALT* on the Console, and click *LOAD* again. - # The reader will stop about half-way through the deck, after reading the COLD loader program and its parameter cards. It will create the new file system on the disk, store the options specified on the parameter cards, print the message "`DIRECTRY BUILT`" on the SPO, and halt. This completes the first phase of the Cold Start, which should take less than 30 seconds. - # To continue, click *HALT* and then *LOAD* on the Operator Console. Make sure that the *CARD LOAD SELECT* button is still illuminated. This reads the Tape-to-Disk loader program into memory and begins executing it. You should see the tape reel icon on the tape drive window spin as it searches the tape and loads the MCP object code to disk. When the load completes successfully, the tape will rewind and the program will print "`MCP FILE LOADED`" on the SPO. - # The Tape-to-Disk loader will then halt/load (boot) the system using the MCP file just loaded. - -=== The First Halt/Load === - -This completes the Cold Start process itself, but some additional steps are still necessary to make the system operational. After the halt/load initiated by the Tape-to-Disk loader, the MCP will almost immediately print a message on the SPO: - - {{{ +# WebUI Getting Started # + + + +# 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) is the external representation the system and provides the means by which you interact with it. Because the implementation of I/O devices depends heavily on the environment in which the UI operates, a UI for this emulator 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 is designed to run in a web browser. This page describes the setup procedures for that UI. + +> _Note:_ The setup and initialization process for the emulator changed dramatically in release 1.00. This page describes the new process that started with that release. Prior to that time, this process was done by a special web page, `B5500ColdLoader.html`, which initialized the disk subsystem, performed the functions of a Cold Start, and loaded an initial set of system files. That script will still work, but it is now deprecated and will be removed in a future release. Instructions for the prior process are still available in [0.20-WebUIGettingStarted]. We strongly recommend you use the new process described below when using release 1.00 or later. + +## 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 in the following sections: + + * Use a suitable web browser -- at present, that means Mozilla Firefox or Google Chrome. See [The Web Browser](WebUIGettingStarted#The_Web_Browser.md) 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 [The Web Server](WebUIGettingStarted#The_Web_Server.md) and [The Emulator Files](WebUIGettingStarted#The_Emulator_Files.md) below for details. + * Download a copy of the Burroughs B5500 system software tape images from http://www.phkimpel.us/B5500/webSite/SoftwareRequest.html. See [The Burroughs B5500 Software](WebUIGettingStarted#The_Burroughs_B5500_Software.md) below for details. + * Configure the system components and create the disk subsystem. See [Configure the System](WebUIGettingStarted#Configure_the_System.md) below for details. + * Cold Start the disk subsystem and load the system software to it. See [Initialize the System](WebUIGettingStarted#Initialize_the_System.md) below for details. + * In your web browser, access the **`webUI/B5500Console.html`** home page from the web server to run the emulator. + + +# What You Will Need # + +To use the web-based emulator, you will need four things: + + 1. A suitable web browser. + 1. A web server configured to deliver files from the emulator directories (our hosting site is set up to do this). + 1. 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). + 1. 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 + * `performance.now()` API + * HTML `` element + +As of this writing, the emulator has been tested with and works with Mozilla Firefox (version 21 and above) and Google Chrome (version 35 and above).1 Somewhat earlier versions of these browsers may also work. Apple Safari will not support the emulator, because it does not as yet support the IndexedDB API.2 The emulator runs fine under Firefox or Chrome on a Macintosh, however. Microsoft Internet Explorer (at least through IE10) will not support the emulator. We have not yet tried Opera. + +## The Web Server ## + +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. +See [Establish the Web Server](WebUIGettingStarted#Establish_the_Web_Server.md) +below for more details. + +If you need a small, simple web server to host the emulator locally, we have had good success with **`mongoose`** (https://github.com/valenok/mongoose). It can run on the same workstation as your browser to serve the emulator files using the loop-back port (localhost or 127.0.0.1). Versions are available that run under Windows, Linux, UNIX, and Mac OS. It is extremely easy to set up. Under Windows, it can run as either a user 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. + +Beginning with release 1.00, the emulator can now run off-line, without access to the web server from which it is hosted. Off-line operation is automatic when the browser supports the HTML5 "application cache" standard and is operating without a network connection or cannot contact the web server. See the discussion on off-line operation in [Using the Console](WebUIUsingTheConsole.md) for details on how this works. + +## 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 script that defines the configuration of the system components. + * **`webUI/`** contains everything else you need to run the system. In particular, it contains the Console UI, the peripheral device drivers, and a Syllable Debugger utility that can be used to examine the state of the processors and memory while running programs under its control, including the MCP. + +A third directory, **`tools/`** contains standalone utilities that can be used to maintain and examine the emulator environment. This directory also contains a few standard card decks that are used with the emulator: + + * **[COLDSTART-XIII.card](http://www.phkimpel.us/B5500/tools/COLDSTART-XIII.card)**: This contains the card images necessary to Cold Start the disk subsystem and load an initial set of system files. It consists of two standalone card-load programs and their parameter cards. You may use this as is, or as a base to create a customized load deck. See [Initialize the System](WebUIGettingStarted#Initialize_the_System.md) below for details on its use. + * **[ESPOL-Binary-Card-Loader.card](http://www.phkimpel.us/B5500/tools/ESPOL-Binary-Card-Loader.card)**: This is a single binary-card image for the boot loader used with several card-load decks. Copies of this are already included in the Cold Start deck above. + * **[CONTROL.DECK.card](http://www.phkimpel.us/B5500/tools/CONTROL.DECK.card)**: This is a single card image used to label a card reader for the MCP's "Load Control" (input spooling) utility. + * **[END.CONTROL.card](http://www.phkimpel.us/B5500/tools/END.CONTROL.card)**: This is a single card image used to terminate use of Load Control on a card reader. + +Recent releases of the emulator files can be obtained from +[our download site](https://drive.google.com/folderview?id=0BxqKm7v4xBswM29qUkxPTkVfYzg&usp=sharing). Each release is packaged as a separate `.zip` file. + +If you use a web server that already has the emulator files set up, you do not need to download a separate copy of an emulator release. Unless you are running your web server on the same workstation as your web browser, you do not need to store the emulator scripts on your workstation. You will need to download at least the Cold Start deck, though, which can be done using the link in the bullet list above. + +## 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 for the B5500 system software. We have acquired an educational/hobbyist license from Unisys 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 the open-source project site with the rest of the 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 +[page on our hosting service](http://www.phkimpel.us/B5500/webSite/SoftwareRequest.html). Go to that page, review and accept the licensing terms (they are not onerous), and download one or more of the tape images. See +[Download the B5500 System Software](WebUIGettingStarted#Download_the_B5500_System_Software.md) 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 Start process, discussed below](WebUIGettingStarted#Cold-Starting_the_System.md), 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 wish to use your own web server, however, the general steps to set up the emulator files are: + + 1. Create a new virtual directory for the web server, e.g., `/B5500/`, to hold the emulator files. + 1. To support the off-line "application cache" capability, you may need to create a mapping in the server between the "`.appcache`" file extension and the "`text/cache-manifest`" MIME type. + 1. Download one of the emulator releases (the one with the highest release-number suffix is usually best) from [our download site](https://drive.google.com/folderview?id=0BxqKm7v4xBswM29qUkxPTkVfYzg&usp=sharing). + 1. Unzip the release into the directory on your server's file system where the virtual directory is mapped. You will need the files from at least the **`emulator/`** and **`webUI/`** directories. Those directories should be created 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. + +Even though the `.bcd` files are not needed to run the emulator, you will probably want to keep them available on your workstation. Not all of the files from these tapes need to be loaded when the system is initialized. You may load a minimal set of files at first, and then incrementally load additional files as needed using MCP `?LOAD` or `?ADD` control cards as discussed under [Loading the System Files](WebUIGettingStarted#Loading_the_System_Files.md) below. + +## Initialize the System ## + +The web-based emulator uses HTML5 IndexedDB databases to implement disk storage, plus a small database for system configuration data. IndexedDB is essentially a small database server embedded within the web browser. The database data is stored in one or more files on your local workstation, but is usually hidden deep within the profile directory your browser maintains for your user account on the workstation. It generally is not easy to access the physical files for these databases, nor is there any need to do so. + +> _Note:_ You _must_ run the emulator consistently from the same web site in order to access the same IndexedDB database. You must also consistently 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 load the emulator from different web sites, the browser will access separate databases for each web site. + +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 emulator using two different URLs for our hosting site, + + * `http://www.phkimpel.us/B5500/webUI/B5500Console.html` + * `http://phkimpel.us.B5500/webUI/B5500Console.html` + +Both URLs reference the same physical server and web pages, but accessing the emulator 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 a given instance of the emulator. You may, of course, use different browsers to run separate instances of the emulator. + +### Create the Initial System Configuration ### + +When first starting out with the emulator, the easiest approach is to allow the emulator to create a default system and disk configuration. This will occur automatically the first time you "power on" the emulator unless you take specific steps beforehand to set up a non-default configuration. The default configuration can be easily changed after it is created. In addition, you can create and maintain multiple configurations, and switch among them. + +See the [Configuring the System](WebUIConfiguringTheSystem.md) page for information on establishing a non-default configuration and modifying a configuration once it is established. The remainder of this section will describe how to proceed with a default initial configuration, and assumes you are installing the emulator on your workstation for the first time. + +To begin, load the emulator home page into your web browser. If you are running your own web server, access 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 + +The home page will look similar to this: + +> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Home-Page.png](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Home-Page.png) + +The home page has two buttons, each of which will start the emulator and open a window for the Operator Console: + + * **Start & Power On** will display the Console window and automatically power up the emulator, as if you had clicked the Console's green **POWER ON** button. + * **Start - Powered Off** will simply display the Console window without powering up the emulator. This button is useful if you want to make configuration changes to the emulator, as those can only be made while the emulator is in a powered-off state. + +The Console is a small control panel with several buttons and lights. The layout and function of this panel is described in the [Using the B5500 Console](WebUIUsingTheConsole.md) page. + +Next, if you did not choose to power on the emulator when opening the Console window, click the green **POWER ON** button on the Console. It will illuminate. + +Regardless of the method that was used to power on the emulator, it will now attempt to open its configuration database, and finding that it does not exist, will display an alert similar to this: + +> https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/System-Config-Does-Not-Exist.PNG + +In order to proceed with the initialization, click the **OK** button. The emulator will create its configuration database, store a default configuration named `Default` in it, and then display the following confirmation: + +> https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/Configuration-Default-Created.PNG + +When you click the **OK** button on this confirmation to continue, the emulator will proceed with its internal initialization and open several sub-windows for the peripheral I/O devices. When it attempts to initialize the disk subsystem (which does not have a window), it will find that the IndexedDB database for that subsystem does not exist and display the following alert: + +> https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/Disk-Config-Does-Not-Exist.PNG + +> Note that this alert is posted to the main Operator Console window and may be obscured by other windows which have opened. You may need to bring the Operator Console window to the foreground in order to see this alert. + +Click the **OK** button on this alert to continue. The emulator will create a default disk subsystem named `B5500DiskUnit` and display this confirmation: + +> https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/Disk-Config-Created.PNG + +Clicking **OK** on the confirmation will allow the emulator to finish its initialization and open any additional windows for the peripheral I/O devices. The entire process should take only a few seconds. You are now ready to Cold Start the disk subsystem and load the system software. + +### Default System Configuration ### + +The default configuration created by the emulator will consist of the following system components: + + * One Processor, PA, set to operate as the control processor, P1. + * Three Input/Output Control Units, IO1, IO2, IO3. + * Eight 4K-word memory modules, for a total of 32K words (the maximum). + * The Supervisory Printer, SPO. + * One line printer, LPA. + * One card reader, CRA. + * One card punch, CPA. + * One magnetic tape drive, MTA. + * One Disk File Control Unit, DKA, with the Disk File Exchange (DFX) enabled. + * One Data Communications Control Unit, DCA, with a single teletype terminal. + +By default, the initial disk configuration for the emulator has a single Electronics Unit (EU) with 200,000 segments of disk storage. This is equivalent to a full complement of five Model I Storage Units (SUs) on the EU. That translates to six million B5500 words, or 48 million 6-bit characters of disk storage. + +The amount of physical disk space used on your workstation for the emulated disk subsystem will vary depending on the number and size of B5500 files you store while running the emulator. It will also depend on the manner in which IndexedDB has been implemented by your browser. The physical disk space used may be many times the virtual space occupied by B5500 files. + +The IndexedDB database will generally use only the physical disk space needed to support the disk subsystem, but that space will grow as you add more B5500 files in the emulated disk subsystem. Once physical disk space on your workstation is allocated to the database, it will persist until the disk subsystem is deleted. Deleting files in the B5500 environment will not reduce the amount of physical disk space used by the emulator on your workstation, but it will free up space within the emulated disk subsystem that other B5500 files can occupy. + +Additional EUs, to a maximum of 20, may be added to the disk subsystem. The default system configuration has one Disk File Control, DKA. A second control, DKB may be added to the configuration, which will allow two disk I/Os to take place simultaneously, as long as they are to different EUs. Systems with two controls and multiple EUs may also include a Disk File Exchange (DFX), which will allow either control to access any EU. Enabling the DFX will limit the usable number of EUs to a maximum of 10, however. + +See the [Configuring the System](WebUIConfiguringTheSystem.md) page for more information on configuring additional disk units and system components, creating multiple system configurations, and creating multiple disk subsystems. + +### 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 the MCP configuration data on the disk. It it similar in concept 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. + +A real B5500 computer system arrived from the factory with nothing recorded on the disk units. A Cold Start is therefore necessary to create the MCP file system on the disk, establish an initial set of system operational settings, and load the MCP and its bootstrap program to the disk. In addition to initializing a new system, the Cold Start process can be used to reinitialize the disk for an existing system, or to recover from serious disk corruption. "Recover" in this case implies wiping out all of the data and reloading it from backup tapes. + +> _Note:_ The Cold Start process _does not check for a previously existing file system_. It unconditionally creates a new file system, destroying any previously-existing one. You must use the following process with care, especially when you have multiple disk subsystems defined. Make sure you are Cold Starting the correct one. + +Initializing the disk subsystem on a real B5500 involved loading two bootstrap programs from cards, the COLD loader and Tape-to-Disk loader. The COLD loader initialized the file system; the Tape-to-Disk loader copies the MCP operating system file from tape to the new file system and configures the bootstrap mechanism to find it. The emulator uses exactly the same process. + +Before proceeding with this section, you must have completed the following: + + * You must have established an initial system configuration and disk subsystem, as described above under [Initialize the System](WebUIGettingStarted#Initialize-the-System.md). You can use the automatically-created default configuration or a custom one you have created, but it must exist first. If you just initialized the system as described in the previous sections, simply continue from that point. + * You must have downloaded at least the `SYSTEM` tape image, as described in earlier sections, and have that tape image available on your workstation. The name of this tape image as downloaded from our hosting site is `B5500-XIII-SYSTEM-adc00257.bcd`. + * You must have the Cold Start deck available on your workstation. You can copy this file from the `tools/` directory of the emulator files, or [download it from our hosting site](http://www.phkimpel.us/B5500/tools/COLDSTART-XIII.card). + +If you wish to customize the parameter cards in the Cold Start deck, do so before proceeding further. A description of the parameter cards can be found in the [B5500 MCP Operations Manual](http://bitsavers.org/pdf/burroughs/B5000_B5500_B5700/1024916_B5500_B5700_OperMan_Sep68.pdf), starting on page 3-14 ("Card Load Select Programs"). Be careful not to alter the card images containing object code for the programs. Note that the two binary bootstrap card images in this deck are each 160 characters long, and each must be fully contained on one text line. + +The following steps accomplish the Cold Start: + + 1. If the emulator is not already powered on, do so now. + 1. Load the Cold Start deck into the card reader, CRA, and make it ready. See the [Using the Card Reader](WebUIUsingTheCardReader.md) page for instructions on how to load a file from your workstation as a card deck into the reader and make the reader ready. + 1. Load the `SYSTEM` tape into the tape drive and make it ready. See [Using the Magnetic Tape Drive](WebUIUsingTheMagTapeDrive.md) for instructions on how to load a tape image file into a tape drive and make the drive ready. If your configuration has more than one tape drive, the image may be loaded into any of them. + 1. On the Operator Console window, click the yellow **CARD LOAD SELECT** button so that it is illuminated. + 1. On the Operator Console window, click the black **LOAD** button. You should see the reader begin reading cards. If nothing happens, make sure you have the correct deck loaded into the reader and that the reader is in a ready status. If necessary, fix any problems, click **HALT** on the Console, and click **LOAD** again. + 1. The reader will stop about half-way through the deck, after reading the COLD loader program and its parameter cards. It will create the new file system on the disk, store the options specified on the parameter cards, print the message "`DIRECTRY BUILT`" on the SPO, and halt. This completes the first phase of the Cold Start, which should take less than 30 seconds. + 1. To continue, click **HALT** and then **LOAD** on the Operator Console. Make sure that the **CARD LOAD SELECT** button is still illuminated. This reads the Tape-to-Disk loader program into memory and begins executing it. You should see the tape reel icon on the tape drive window spin as it searches the tape and loads the MCP object code to disk. When the load completes successfully, the tape will rewind and the program will print "`MCP FILE LOADED`" on the SPO. + 1. The Tape-to-Disk loader will then halt/load (boot) the system using the MCP file just loaded. + +### The First Halt/Load ### + +This completes the Cold Start process itself, but some additional steps are still necessary to make the system operational. After the halt/load initiated by the Tape-to-Disk loader, the MCP will almost immediately print a message on the SPO: + +``` -H/L WITH MCP/DISK MARK XIII MODS RRRRRRR@- - }}} - -The MCP will spend several seconds preparing its internal tables and initializing its private area of the disk, then print messages similar to the following on the SPO: - - {{{ +``` + +The MCP will spend several seconds preparing its internal tables and initializing its private area of the disk, then print messages similar to the following on the SPO: + +``` DKA EU0 SU 1,2,3,4,5 WENT READY TIME IS 0000 DATE IS SATURDAY, 9/ 1/84 #TR PLEASE - }}} - -The `DKA EU0`... message indicates the MCP has seen EU0 and its five SUs for the first time. You will not see this message after subsequent halt/loads. The time is zero, indicating it has not yet been set. The date comes from one of the parameter cards for the COLD loader in the Cold Start deck. The `#TR PLEASE` message indicates that the MCP will not finish its initialization phase and begin normal operations until the time is set. This behavior is an option specified by one of the parameter cards in the Cold Start deck, and may be changed if desired. It can also be changed using the `RO` SPO command. - -Before setting the time, you should set the date. The B5500 MCP ceased to be supported long before the year 2000 and is not Y2K-compatible. You may enter any date you wish, but it will be a 1900-based date. Hence, the days of the week output by the system may appear to be wrong, as they are being computed using years in the 1900s. We recommend that you choose a year in the 1970s or 1980s. - -To set the date, use the `DT` command, specifying the date in mm/dd/yy format. Click the *INPUT REQUEST* button on the SPO. After the *READY* light illuminates, enter the following on your keyboard, substituting your date. - - {{{ +``` + +The `DKA EU0`... message indicates the MCP has seen EU0 and its five SUs for the first time. You will not see this message after subsequent halt/loads. The time is zero, indicating it has not yet been set. The date comes from one of the parameter cards for the COLD loader in the Cold Start deck. The `#TR PLEASE` message indicates that the MCP will not finish its initialization phase and begin normal operations until the time is set. This behavior is an option specified by one of the parameter cards in the Cold Start deck, and may be changed if desired. It can also be changed using the `RO` SPO command. + +Before setting the time, you should set the date. The B5500 MCP ceased to be supported long before the year 2000 and is not Y2K-compatible. You may enter any date you wish, but it will be a 1900-based date. Hence, the days of the week output by the system may appear to be wrong, as they are being computed using years in the 1900s. We recommend that you choose a year in the 1970s or 1980s. + +To set the date, use the `DT` command, specifying the date in mm/dd/yy format. Click the **INPUT REQUEST** button on the SPO. After the **READY** light illuminates, enter the following on your keyboard, substituting your date. + +``` DT 9/4/84 - }}} - -To terminate the command, either click the *END OF MESSAGE* button on the SPO or press *Enter* on your keyboard. The MCP will respond with a message indicating the new date. - -The time is set in a similar manner using the `TR` command, specifying the time as a four-digit number in 24-hour format: -000000000000............ - {{{ +``` + +To terminate the command, either click the **END OF MESSAGE** button on the SPO or press **Enter** on your keyboard. The MCP will respond with a message indicating the new date. + +The time is set in a similar manner using the `TR` command, specifying the time as a four-digit number in 24-hour format: +000000000000............ +``` TR 1936 - }}} - -Once the time has been entered, the MCP is ready for normal operations. You will immediately see the following message, which will be explained shortly. - - {{{ +``` + +Once the time has been entered, the MCP is ready for normal operations. You will immediately see the following message, which will be explained shortly. + +``` ##LOAD INTRNSC/DISK NOW.... - }}} - -The standard Cold Start deck has a short sequence of control cards following the Tape-to-Disk loader that will copy a minimal set of files from the `SYSTEM` tape. The card reader should still be ready from its use with the Tape-to-Disk loader, so once you set the time, you should see these cards being read, the `SYSTEM` tape begin to spin again, and a series of messages similar to the following print on the SPO: - - {{{ +``` + +The standard Cold Start deck has a short sequence of control cards following the Tape-to-Disk loader that will copy a minimal set of files from the `SYSTEM` tape. The card reader should still be ready from its use with the Tape-to-Disk loader, so once you set the time, you should see these cards being read, the `SYSTEM` tape begin to spin again, and a series of messages similar to the following print on the SPO: + +``` 5:LIBMAIN/DISK= 1 BOJ 1936 MTA IN 0 SYSTEM 1:LIBMAIN/DISK= 1 INT/DISK LOADED,MTA @@ -295,67 +292,67 @@ The standard Cold Start deck has a short sequence of control cards following the XALGOL/DISK LOADED,MTA LOGOUT/DISK LOADED,MTA LIBMAIN/DISK= 1 EOJ 1937 - }}} - -This loads the System Intrinsics (`INT/DISK`), the printer output spooler (`PRNPBT/DISK`), the card input spooler (`LDCNTRL/DISK`), four compilers, and a program to print the system log file. You can edit the control cards at the end of the Cold Start deck to load more or fewer files, or add and remove files later using the SPO or another card deck. We recommend that you load at least the `INT/DISK` file at this point, however. - -The System Intrinsics is a library of common routines that can be dynamically bound to user programs. It contains the math functions, input/output formatting routines, and a variety of other support routines used by various programming languages. Its name must be specified to the MCP, and since this is the first time the system has been booted since the Cold Start, the MCP does not yet have that name. Hence the "`##LOAD`..." message above. - -To specify the name of the Intrinsics file, use the `CI` SPO command, thus: - - {{{ +``` + +This loads the System Intrinsics (`INT/DISK`), the printer output spooler (`PRNPBT/DISK`), the card input spooler (`LDCNTRL/DISK`), four compilers, and a program to print the system log file. You can edit the control cards at the end of the Cold Start deck to load more or fewer files, or add and remove files later using the SPO or another card deck. We recommend that you load at least the `INT/DISK` file at this point, however. + +The System Intrinsics is a library of common routines that can be dynamically bound to user programs. It contains the math functions, input/output formatting routines, and a variety of other support routines used by various programming languages. Its name must be specified to the MCP, and since this is the first time the system has been booted since the Cold Start, the MCP does not yet have that name. Hence the "`##LOAD`..." message above. + +To specify the name of the Intrinsics file, use the `CI` SPO command, thus: + +``` CI INT/DISK - }}} - -You should only need to do this once. The MCP will store the name with the other system options on disk and automatically load the Intrinsics from that file after subsequent halt/loads. - -The system and MCP are now ready for use. For additional information on using the SPO, see the [WebUIUsingTheSPO Using the SPO] page. For a general overview of emulator and MCP operations, see the [WebUIRunningTheEmulator Running the Emulator] page. - -=== Loading Additional System Files === - -You may wish to load additional files from the `SYSTEM` tape once the Cold Start process is completed and the MCP is operational. The following are good candidates for additional system files to load, 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 formatting documentation and cross-referencing identifiers in source files. - -"Library/Maintenance" is the portion of the MCP that manages disk files and maintains the disk directory. Among its features is the capability to dump disk files to and load disk files from magnetic tape. This was typically used for software distribution, file backup, archiving, and transferring files between systems. - -Files can be loaded from Library/Maintenance volumes such as the `SYSTEM`, `SYMBOL1`, and `SYMBOL2` tape images using the `LOAD` and `ADD` control card commands, e.g., - - {{{ +``` + +You should only need to do this once. The MCP will store the name with the other system options on disk and automatically load the Intrinsics from that file after subsequent halt/loads. + +The system and MCP are now ready for use. For additional information on using the SPO, see the [Using the SPO](WebUIUsingTheSPO.md) page. For a general overview of emulator and MCP operations, see the [Running the Emulator](WebUIRunningTheEmulator.md) page. + +### Loading Additional System Files ### + +You may wish to load additional files from the `SYSTEM` tape once the Cold Start process is completed and the MCP is operational. The following are good candidates for additional system files to load, 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 formatting documentation and cross-referencing identifiers in source files. + +"Library/Maintenance" is the portion of the MCP that manages disk files and maintains the disk directory. Among its features is the capability to dump disk files to and load disk files from magnetic tape. This was typically used for software distribution, file backup, archiving, and transferring files between systems. + +Files can be loaded from Library/Maintenance volumes such as the `SYSTEM`, `SYMBOL1`, and `SYMBOL2` tape images using the `LOAD` and `ADD` control card commands, e.g., + +``` ?LOAD FROM SYSTEM ESPOL/DISK, COBOL/DISK, DUMP/ANALYZE; END - }}} - -The `ADD` command works the same as `LOAD`, except that it loads only those files that are not already in the disk directory. - -A control card command can be continued across multiple card images by terminating a card with a hyphen (`-`) wherever a word or punctuation character might appear. The continuation line(s) that follow must not have an invalid character in column 1. The command must be terminated either by appending `;END` on the last line or by a final line with `?END` beginning in column 1. - -All files having the same first or last identifier in their file name may be loaded by specifying _MFID_`/=` or `=/`_FID_, where _MFID_ is the "multi-file identifier" and _FID_ is the "file identifier" portion of a file name, respectively. All files from a tape can be loaded by specifying `=/=`. Library/Maintenance will not overwrite certain critical system files, such as the currently running MCP, the Intrinsics, or the system log. - -See [WebUIUsingTheMagTapeDrive Using the Magnetic Tape Drive] for more information on how to mount tape images onto a tape drive. See Section 4, and in particular page 4-15 ff, in http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1024916_B5500_B5700_OperMan_Sep68.pdf for more information on control card syntax and the Library/Maintenance commands. - - -= Next Steps = - -See [WebUIRunningTheEmulator WebUI Running the Emulator] for detailed instructions on how to start the emulator and run the emulated B5500 system. - -See [http://bitsavers.org/pdf/burroughs/B5000_5500_5700/ the Burroughs documents at bitsavers.org] for copies of the original Burroughs manuals and other reference information on the B5500 system. - - - -`____________` - -^1^ Earlier versions of the emulator ran fine on Chrome 27 (the earliest version we tested), but somewhere around Chrome 30 the browser started crashing ("Aw, Snap!") while running the emulator. This appears to have been a problem with garbage collection, resulting in the browser running out of memory. The problem was resolved in mid-2014 with Chrome 35. - -^2^ Apple Safari is rumored to have support for IndexedDB in version 8. See http://caniuse.com/#feat=indexeddb for the current status. \ No newline at end of file +``` + +The `ADD` command works the same as `LOAD`, except that it loads only those files that are not already in the disk directory. + +A control card command can be continued across multiple card images by terminating a card with a hyphen (`-`) wherever a word or punctuation character might appear. The continuation line(s) that follow must not have an invalid character in column 1. The command must be terminated either by appending `;END` on the last line or by a final line with `?END` beginning in column 1. + +All files having the same first or last identifier in their file name may be loaded by specifying _MFID_`/=` or `=/`_FID_, where _MFID_ is the "multi-file identifier" and _FID_ is the "file identifier" portion of a file name, respectively. All files from a tape can be loaded by specifying `=/=`. Library/Maintenance will not overwrite certain critical system files, such as the currently running MCP, the Intrinsics, or the system log. + +See [Using the Magnetic Tape Drive](WebUIUsingTheMagTapeDrive.md) for more information on how to mount tape images onto a tape drive. See Section 4, and in particular page 4-15 ff, in http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1024916_B5500_B5700_OperMan_Sep68.pdf for more information on control card syntax and the Library/Maintenance commands. + + +# Next Steps # + +See [WebUI Running the Emulator](WebUIRunningTheEmulator.md) for detailed instructions on how to start the emulator and run the emulated B5500 system. + +See [the Burroughs documents at bitsavers.org](http://bitsavers.org/pdf/burroughs/B5000_5500_5700/) for copies of the original Burroughs manuals and other reference information on the B5500 system. + + + +`____________` + +1 Earlier versions of the emulator ran fine on Chrome 27 (the earliest version we tested), but somewhere around Chrome 30 the browser started crashing ("Aw, Snap!") while running the emulator. This appears to have been a problem with garbage collection, resulting in the browser running out of memory. The problem was resolved in mid-2014 with Chrome 35. + +2 Apple Safari is rumored to have support for IndexedDB in version 8. See http://caniuse.com/#feat=indexeddb for the current status. \ No newline at end of file diff --git a/WebUIHowToSetUpCANDE.md b/WebUIHowToSetUpCANDE.md deleted file mode 100644 index ae8e6c8..0000000 --- a/WebUIHowToSetUpCANDE.md +++ /dev/null @@ -1,469 +0,0 @@ -# WebUI Setting Up TSMCP and CANDE # - - - -# Introduction # - -This page describes how to add timesharing features to an existing emulator environment for the Burroughs B5500 system. At the end is a short sample session using the CANDE (Command and Edit) user interface. - -## Prerequisites ## - -The procedure described below assumes you have the retro-B5500 emulator installed and set up with the default DCMCP (Datacom MCP) software as described in [WebUI Getting Started](WebUIGettingStarted.md). - -Before proceeding, you should have a basic familiarity with the emulator, SPO, card reader, and tape drive. See the following pages for information on these topics: - - * [Running the Emulator](WebUIRunningTheEmulator.md) - * [Using the SPO](WebUIUsingTheSPO.md) - * [Using the Card Reader](WebUIUsingTheCardReader.md) - * [Using the Magnetic Tape Drive](WebUIUsingTheMagTapeDrive.md) - -## Background ## - -There were several variations of the MCP (Master Control Program) operating system used with the B5000 and B5500 computer systems over their long active lifetime. The original MCP for the B5000, released in early 1963, was somewhat limited, largely due to the severely restricted mass storage (two 32K-word drums) available on that system. The B5000 was a batch system, with most processing involving punched cards, magnetic tape, and possibly paper tape. - -The B5500, first available in early 1965, was essentially the same system, but with the addition of a new Head-per-Track disk subsystem. HPT disk offered capacities up to one billion 6-bit characters. The MCP was completely rewritten to take advantage of this new disk, becoming known as the Disk File MCP (DFMCP). - -Data communications interface hardware became available for the B5500 shortly after the DFMCP was released. The most commonly-used interface was the B249 Data Transmission Control Unit (DTCU) paired with one or more B487 Data Transmission Terminal Units (DTTU). Each DTTU could support up to 16 line-adapter slots. Each adapter supported one data communications circuit. Later a programmable interface, the Data Communications Processor (DCP), originally developed for the B6500 project, became available on the B5500. The B5500 was then renamed for marketing purposes as the B5700. - -The DFMCP was enhanced to support this datacom equipment, becoming the Data Communications MCP (DCMCP). Its capabilities were oriented towards transaction processing, where multiple remote stations exchanged messages with one or more central server programs, rather than interactive timesharing. - -## The TSMCP and CANDE ## - -The DCMCP worked well in the environment it was designed for, but its approach to dynamic memory management was not well-suited for the user-oriented interactivity typical of a timesharing environment. To address that, Burroughs created another variation, the Timesharing MCP (TSMCP or TSSMCP). - -The goal of the DCMCP was to maximize overall system throughput. The goal of the TSMCP was to handle large numbers of interactive tasks (i.e., those with long idle times between periods of actual processor use) and minimize user response time. - -The TSMCP was derived from the DCMCP and supported all but a few of the DCMCP capabilities. The major change was a new memory management mechanism. Memory is typically the most critical resource in an on-line system. It was especially critical with the relatively small memory sizes available in the 1960s -- the 32K-word maximum for the B5500 was typical. - -Core memory for the TSMCP is divided into two portions at a site-specified address known as the "fence." Memory below the fence is managed the same way as for the DCMCP, with data and code segments for all tasks allocated from one common heap. CANDE, MCP utilities (such as card and printer spooling) and the TSMCP itself run below the fence. - -Memory above the fence is organized into a number of "swap areas" for use by both batch programs and the interactive programs initiated by remote users. Code and data segments for these programs are allocated solely within their respective swap areas. This supported "time slicing" of the memory space for both batch and interactive programs, as all of the non-shared memory used by a user program was in its swap area, and could be paged out to disk as a unit, making room for the swap areas of other users to be paged in for their time slice. - -To manage remote interactive sessions, Burroughs developed the Command and Edit (CANDE, pronounced "candy") handler. This was a command-line interface somewhat similar to what we would call a shell today, but with a line-oriented text editor built in. Most terminal devices of the day were teletype-like devices, which could only support line editing. Full-screen editing was something still in the future. - -With CANDE, users could create and edit source and text files, compile programs, and run programs, interacting with the programs through so-called "remote files." CANDE also supported commands to rename and delete files, list files to the terminal, copy files to line printer and card punch devices, and manage the interactive session. A basic security system isolated each user's files from other users. The owner could specify permissions that allowed other users to share individual files. - -The TSMCP and CANDE were quite popular on B5500s used by schools and universities. Some systems continued to run through the late 1970s and possibly into the early 1980s. Sites with heavy batch loads or more transaction-oriented datacom requirements tended to stick with the DCMCP. Both variations of the MCP continued to be supported and enhanced in parallel by Burroughs through the 1970s. Only one MCP could be run on a system at a time, but as we will see, it requires little more than a Halt/Load (reboot) to switch between them. - - -# Overview of the Setup Process # - -CANDE consists of a main program (`CANDE/TSHARER`) and numerous helper programs that are invoked by the main program as needed to do time-consuming tasks, such as a compilation or file resequence, on behalf of a user. All this software is on the `SYSTEM` tape and must be loaded to disk before it can be run. - -Once you have the necessary software loaded, you will need to set up two configuration files: - - * **`SYSTEM/DISK`** describes the data communications circuit and station environment, and is used only by the TSMCP. Since the web-based emulator currently supports only one terminal device, that configuration file has a fixed configuration, as shown below. This file is maintained by the program `SYSDISK/MAKER`. - * **`USER/CANDE`** defines the remote users. This file is used by CANDE. It is binary file containing the user's login name, password, and per-account information. This file is maintained by the program `USERS/CANDE`. - -CANDE only runs under the TSMCP, so the next requirement is to Halt/Load the system under that MCP. TSMCP also requires a different set of System Intrinsics. After creating the two files above, you must specify the new MCP and Intrinsics files to the system and Halt/Load the system to initiate the TSMCP. - -Once TSMCP initialization finishes, you must then initiate CANDE. At that point you can log in using the terminal and start timesharing. - - -# Setting Up the System # - -This section discusses the step-by-step process to prepare the web-based emulator for the TSMCP and CANDE, switch to the TSMCP, and initiate CANDE. - -## Preparing the Configuration Files ## - -This first step takes place outside of the emulator. Using your text editor of choice, prepare a text file for a card deck to create the `SYSTEM/DISK` file as follows: - -``` - ?EXECUTE SYSDISK/MAKER - ?DATA CARD - LINE,0,0,112,0,0,7,0, - LINE,1,0,112,0,0,0,1, - STA,0,0,0,0,"0","0",0,0, - ?END -``` - -The web-based emulator supports the B249/B487 interface, with a single terminal on DTTU #1, buffer #0. That adapter slot is configured to have a 112-character buffer. - - * The first `LINE` card defines a pseudo-line that CANDE uses for its "schedule" sessions. - * The second `LINE` card defines the datacom circuit for the emulated terminal. - * The `STA` card defines the teletype station on that line. Teletype circuits could support only one station, so this card is optional. - -Note the trailing commas ("`,`") on each of the cards. These are required. The only acceptable variation to this configuration concerns the last field on the second `LINE` card: - - * `0` indicates this is a switched (dial-up) circuit. - * `1` indicates this is a direct-connect (hardwired) circuit. TSMCP considers the terminal to be permanently connected to the system - -The emulated terminal behaves as if it is connected on a switched circuit, although you can choose either option on its `LINE` card. The only behavioral difference is that if you configure the line as switched, TSMCP will automatically disconnect when you log out from CANDE. - -The `SYSDISK/MAKER` program and format of the cards it processes is documented in Section 1 of the [Burroughs B5700 Time Sharing System Reference Manual](http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1058583_B5700_TSS_RefMan_Sep72.pdf). - -Next, prepare another card deck to create the `USERS/CANDE` file: - -``` - ?EXECUTE USER/CANDE - ?DATA CARD - $NEW - $USER "B5500" - PASSWORD "SECRET" - NAME "USER NAME" - NO CHARGE -``` - -Replace the text in the quoted strings with a user name, password, and display name of your choice. `$NEW` indicates that a new file will be created rather than an existing file being updated. `PASSWORD` and `NAME` are optional, and may be omitted. If no password is specified, you will log in with only your user name. `NO CHARGE` indicates that CANDE will not request a "charge code" (billing account number) as part of the log-in process. - -You may create multiple user accounts by repeating the sequence of cards starting with the `$USER` card above. - -There are a few additional options for configuring user accounts. The `USER/CANDE` program and format of the cards it processes is also documented in Section 1 of the [Burroughs B5700 Time Sharing System Reference Manual](http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1058583_B5700_TSS_RefMan_Sep72.pdf). - -## Loading the System Software Files ## - -The next step is to load the necessary files from the Mark XIII `SYSTEM` tape image file. You should already have this file from the original setup for the DCMCP, as described in [WebUI Getting Started](WebUIGettingStarted.md). - -First, Halt/Load the system to the DCMCP and set the date and time as necessary. You can also do the following steps under the TSMCP, but you will still need to Halt/Load after building the configuration files. - -Load the `SYSTEM` tape image file into the tape drive (MTA window) by clicking the **LOAD** button on the drive, selecting the file, and then clicking the **REMOTE** button. You can confirm that the tape is loaded and ready by entering the following SPO command, but this is not necessary: - -``` - OL MTA -``` - -CANDE requires quite a few files, and the easiest thing to do is simply load everything from the `SYSTEM` tape. With the tape loaded in the drive, enter the following command on the SPO: - -``` - CC ADD FROM SYSTEM =/=; END -``` - -The `ADD` command will copy only those files that are not already present on disk. You can substitute `LOAD` for `ADD`, which will copy all the files specified, generally overwriting any existing files. This is safe to do, as MCP Library/Maintenance will not overwrite critical files, such as the running MCP. - -Copying the files to disk will take a few minutes and output many messages to the SPO. - -If you wish to do a more targeted load, you will need the following files: - -``` - CC ADD FROM SYSTEM TSS/MCP, TSS/INT, USERS/CANDE, SYSDISK/MAKER, - - CANDE/TSHARER, FIND/DISK, GUARD/DISK, =/CANDE; END -``` - -Note the "`-`" at the end of the first line, which allows continuation of a control command. You should also load any additional compilers or utility programs you will want to use, e.g., `ALGOL/DISK`, `BASIC/DISK`, `COBOL/DISK`, `COBOL68/DISK`, `FORTRAN/DISK`, or `XALGOL/DISK`. - -## Building the Configuration Files ## - -Create the two configuration files, `SYSTEM/DISK` and `USERS/CANDE` by loading the card deck files you created above into the card reader and clicking the reader's **START** button. The decks can be run in any order. You can load both decks into the reader at the same time, if you wish. - -Make sure you resolve any errors in these decks before proceeding. CANDE will not start without both files present. - -## Initiating TSMCP and CANDE ## - -The next step is to designate the MCP and Intrinsics files that should be -used at the next Halt/Load. Enter the following two commands on the SPO: -on the SPO: - -``` - CM TSS/MCP - CI TSS/INT -``` - -These commands modify the bootstrap information in sector 0 of the disk. You should see responses similar to this: - -``` - CM TSS/MCP - NEXT MCP WILL BE TSS/MCP - CI TSS/INT - NEW INTRINSIC FILE IS: TSS/INT. -``` - -Now reboot the system by switching to the emulator's Console window and clicking first the **HALT** button and then the **LOAD** button (this is why it's called a Halt/Load). You should see a message indicating the TSMCP is now running. After initialization completes, enter the date and time as necessary: - -``` - -H/L WITH TSS/MCP MARK XIII,F=16384[MODS=RRRRRRRR]- - TIME IS 1429 - DATE IS THURSDAY, 11/17/83 - #TR PLEASE - TR 1431 - TIME IS 1431 -``` - -The "`F=16384`" indicates the fence location in memory. The value shown is the default if the fence was not specified at Cold Start time. You can change this value at any time using the `MF` SPO command, but it will only take effect at the next Halt/Load. Fence values must be in the range 8184 to 28644. Lower values give more memory to the swap areas for batch and interactive user programs. Higher values give more memory to the MCP and CANDE handler program. The default value is a good one to start with. - -To switch back to the DCMCP, simply designate its MCP and intrinsics files and do another Halt/Load. The fence location is ignored by the DCMCP: - -``` - CM MCP/DISK - CI INT/DISK -``` - -Once the TSMCP has initialized, you can initiate CANDE with the following SPO command: - -``` - CE -``` - -You should see the CANDE handler enter the mix and output its initialization message: - -``` - 0:CANDE/TSHARER/SITE= 1 BOJ 1516 - USERS/CANDE FILE DATED 00111783 -``` - -This indicates that CANDE is running and ready for use. - - -# Using CANDE # - -A typical B5500 timesharing system supported 20-30 users. The web-based emulator supports only one terminal, though, so only one user at a time can be signed on to CANDE in this environment. More information on using the emulated terminal can be found in the [Using Datacom](WebUIUsingDatacom.md) wiki page. - -Note that six of the 64 characters in the B5500 character set were used as control characters by the teletype adapter hardware, and could not be used for their normal purpose in user program text and output messages: - -| **Terminal** | **B5500 graphic** | **Input** | **Output** | -|:-------------|:------------------|:----------|:-----------| -| `}` | greater-or-equal | ignored | disconnect switched line | -| `{` | less-or-equal | ignored | carriage return | -| `!` | not-equal | disconnect | line feed | -| `>` | greater-than | ignored | X-on (ASCII DC1) | -| `<` | less-than | backspace | RUBOUT (ASCII DEL) | -| `~` | left-arrow | end of message | end of message | - -See pages 3-15 and 3-16 in the [B5500 Handbook](http://bitsavers.org/pdf/burroughs/1031986_B5500_Handbook_Aug70.pdf) for information on the character substitutions used by the B249/B487. - -To begin a session, click the **Connect** button on the terminal (DCA) window. The button should light. - -## Logging In ## - -After connecting the terminal, you should see a welcome message from CANDE within a few seconds: - -``` - B5500 TIME SHARING - 01/00, STATION 02 - ENTER USER CODE, PLEASE- -``` - -Enter your user name as defined in the `USERS/CANDE` file. Officially, the end-of-message character for a teletype device was the left-arrow key (Shift-letter-O, "`~`" in the emulator), but as a convenience the emulator also supports using the **Enter** key. The terminal will echo a "`~`" in either case. - -``` - ENTER USER CODE, PLEASE-B5500~ -``` - -CANDE will next request your password and output several sequences of characters on the same line of the terminal. On a teletype device, this would create an inky blob on the paper, which would obscure the password when it was entered. That doesn't work so well on a web page, so just enter your password on top of those characters, followed by end-of-message. If you did not specify a password for your user name, just key end-of-message by itself. - -``` - AND YOUR PASSWORD - SECRET~@ - 11/17/83 2:33 PM. - GOOD AFTERNOON, USER NAME YOU HAVE STATION 02 - - # -``` - -At this point, you are logged in to CANDE and can begin entering commands. When you are finished with your session, enter `BYE` to log out. Alternatively, you can click the terminal's **Connect** button to disconnect. - -CANDE commands and use of the terminal under CANDE are documented in the -[Burroughs B5500 Time Sharing System Terminal User's Guide](http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1038205_B5500_TS_TerminalUG_Jun69.pdf). Note that the emulator does not presently support the paper tape terminal features described in this manual, particularly the CANDE `TAPE` command. - - -## Sample CANDE Session ## - -Here is a sample session, illustrating creating, compiling, and running a simple BASIC program. CANDE requires line numbers (more properly known as sequence numbers) on all lines of all files, not just those for BASIC: - -``` - CREATE FOO BASIC~ - FILE:FOO - TYPE:BASIC -- CREATED - 10FOR I = 1 TO 5~ - 20PRINT I, I*I~ - 30NEXT I~ - 40END~ - RUN~ - WAIT. - - COMPILING. - - END COMPILE 1.5 SEC. - - RUNNING - - 1 1 - 2 4 - 3 9 - 4 16 - 5 25 - - END FOO .4 SEC. -``` - -Note that the `RUN` command knows if the program source has not been compiled since it was last modified, and automatically recompiles before running it. - -Now we edit the program slightly and recompile and rerun it. The "`*`" (`FIX`) command below searches line 20 for the literal string "`I*I`" and replaces it with "`SQR(I)`". Most non-alphanumeric characters can be used as token delimiters in this command. - -Also note that multiple CANDE commands can be entered on one line, delimited by semicolons ("`;`"). Due to their nature, single-line entries (commands beginning with a sequence number) and `FIX` commands can appear only as the last command on a line. - -``` - *20/I*I/SQR(I)~ - LIST; RUN~ - - FILE:FOO - TYPE:BASIC --11/17/83 3:26 PM. - - 10 FOR I = 1 TO 5 - 20 PRINT I, SQR(I) - 30 NEXT I - 40 END - - END LIST 3.5 SEC. - - COMPILING. - - END COMPILE 2.4 SEC. - - RUNNING - - 1 1 - 2 1.414214 - 3 1.732051 - 4 2 - 5 2.236068 - - END FOO .3 SEC. -``` - -Here is a slightly larger example of an Algol program that implements the outrageously-recursive Ackermann function. Note the use of the CANDE `SEQ` (sequence) command to automatically supply line numbers and the "`<`" character as a backspace: - -``` - CREATE ACKMAN ALGOL~ - FILE:ACKMAN - TYPE:ALGOL -- CREATED - SEQ 100100+100~ - 100100BEGIN~ - 100200COMMENT ACKERMANN FUNCTION TEST;~ - 100300INTEGER PROCEDURE ACKERMANN(A, B);~ - 100400 VALUE A, B;~ - 100500 INTEGER A, B;~ - 100600 BEGIN~ - 100700 ACKERMANN:=~ - 100800 IF A = 0 THEN~ - 100900 AC< +# WebUI Setting Up TSMCP and CANDE # -= Introduction = + +# Introduction # This page describes how to add timesharing features to an existing emulator environment for the Burroughs B5500 system. At the end is a short sample session using the CANDE (Command and Edit) user interface. -== Prerequisites == +## Prerequisites ## -The procedure described below assumes you have the retro-B5500 emulator installed and set up with the default DCMCP (Datacom MCP) software as described in [WebUIGettingStarted WebUI Getting Started]. +The procedure described below assumes you have the retro-B5500 emulator installed and set up with the default DCMCP (Datacom MCP) software as described in [WebUI Getting Started](WebUIGettingStarted.md). Before proceeding, you should have a basic familiarity with the emulator, SPO, card reader, and tape drive. See the following pages for information on these topics: - * [WebUIRunningTheEmulator Running the Emulator] - * [WebUIUsingTheSPO Using the SPO] - * [WebUIUsingTheCardReader Using the Card Reader] - * [WebUIUsingTheMagTapeDrive Using the Magnetic Tape Drive] + * [Running the Emulator](WebUIRunningTheEmulator.md) + * [Using the SPO](WebUIUsingTheSPO.md) + * [Using the Card Reader](WebUIUsingTheCardReader.md) + * [Using the Magnetic Tape Drive](WebUIUsingTheMagTapeDrive.md) -== Background == +## Background ## There were several variations of the MCP (Master Control Program) operating system used with the B5000 and B5500 computer systems over their long active lifetime. The original MCP for the B5000, released in early 1963, was somewhat limited, largely due to the severely restricted mass storage (two 32K-word drums) available on that system. The B5000 was a batch system, with most processing involving punched cards, magnetic tape, and possibly paper tape. @@ -30,7 +27,7 @@ Data communications interface hardware became available for the B5500 shortly af The DFMCP was enhanced to support this datacom equipment, becoming the Data Communications MCP (DCMCP). Its capabilities were oriented towards transaction processing, where multiple remote stations exchanged messages with one or more central server programs, rather than interactive timesharing. -== The TSMCP and CANDE == +## The TSMCP and CANDE ## The DCMCP worked well in the environment it was designed for, but its approach to dynamic memory management was not well-suited for the user-oriented interactivity typical of a timesharing environment. To address that, Burroughs created another variation, the Timesharing MCP (TSMCP or TSSMCP). @@ -49,36 +46,36 @@ With CANDE, users could create and edit source and text files, compile programs, The TSMCP and CANDE were quite popular on B5500s used by schools and universities. Some systems continued to run through the late 1970s and possibly into the early 1980s. Sites with heavy batch loads or more transaction-oriented datacom requirements tended to stick with the DCMCP. Both variations of the MCP continued to be supported and enhanced in parallel by Burroughs through the 1970s. Only one MCP could be run on a system at a time, but as we will see, it requires little more than a Halt/Load (reboot) to switch between them. -= Overview of the Setup Process == +# Overview of the Setup Process # CANDE consists of a main program (`CANDE/TSHARER`) and numerous helper programs that are invoked by the main program as needed to do time-consuming tasks, such as a compilation or file resequence, on behalf of a user. All this software is on the `SYSTEM` tape and must be loaded to disk before it can be run. Once you have the necessary software loaded, you will need to set up two configuration files: - * *`SYSTEM/DISK`* describes the data communications circuit and station environment, and is used only by the TSMCP. Since the web-based emulator currently supports only one terminal device, that configuration file has a fixed configuration, as shown below. This file is maintained by the program `SYSDISK/MAKER`. - * *`USER/CANDE`* defines the remote users. This file is used by CANDE. It is binary file containing the user's login name, password, and per-account information. This file is maintained by the program `USERS/CANDE`. + * **`SYSTEM/DISK`** describes the data communications circuit and station environment, and is used only by the TSMCP. Since the web-based emulator currently supports only one terminal device, that configuration file has a fixed configuration, as shown below. This file is maintained by the program `SYSDISK/MAKER`. + * **`USER/CANDE`** defines the remote users. This file is used by CANDE. It is binary file containing the user's login name, password, and per-account information. This file is maintained by the program `USERS/CANDE`. CANDE only runs under the TSMCP, so the next requirement is to Halt/Load the system under that MCP. TSMCP also requires a different set of System Intrinsics. After creating the two files above, you must specify the new MCP and Intrinsics files to the system and Halt/Load the system to initiate the TSMCP. Once TSMCP initialization finishes, you must then initiate CANDE. At that point you can log in using the terminal and start timesharing. -= Setting Up the System = +# Setting Up the System # This section discusses the step-by-step process to prepare the web-based emulator for the TSMCP and CANDE, switch to the TSMCP, and initiate CANDE. -== Preparing the Configuration Files == +## Preparing the Configuration Files ## This first step takes place outside of the emulator. Using your text editor of choice, prepare a text file for a card deck to create the `SYSTEM/DISK` file as follows: - {{{ +``` ?EXECUTE SYSDISK/MAKER ?DATA CARD LINE,0,0,112,0,0,7,0, LINE,1,0,112,0,0,0,1, STA,0,0,0,0,"0","0",0,0, ?END - }}} +``` The web-based emulator supports the B249/B487 interface, with a single terminal on DTTU #1, buffer #0. That adapter slot is configured to have a 112-character buffer. @@ -93,11 +90,11 @@ Note the trailing commas ("`,`") on each of the cards. These are required. The o The emulated terminal behaves as if it is connected on a switched circuit, although you can choose either option on its `LINE` card. The only behavioral difference is that if you configure the line as switched, TSMCP will automatically disconnect when you log out from CANDE. -The `SYSDISK/MAKER` program and format of the cards it processes is documented in Section 1 of the [http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1058583_B5700_TSS_RefMan_Sep72.pdf Burroughs B5700 Time Sharing System Reference Manual]. +The `SYSDISK/MAKER` program and format of the cards it processes is documented in Section 1 of the [Burroughs B5700 Time Sharing System Reference Manual](http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1058583_B5700_TSS_RefMan_Sep72.pdf). Next, prepare another card deck to create the `USERS/CANDE` file: - {{{ +``` ?EXECUTE USER/CANDE ?DATA CARD $NEW @@ -105,31 +102,31 @@ Next, prepare another card deck to create the `USERS/CANDE` file: PASSWORD "SECRET" NAME "USER NAME" NO CHARGE - }}} +``` Replace the text in the quoted strings with a user name, password, and display name of your choice. `$NEW` indicates that a new file will be created rather than an existing file being updated. `PASSWORD` and `NAME` are optional, and may be omitted. If no password is specified, you will log in with only your user name. `NO CHARGE` indicates that CANDE will not request a "charge code" (billing account number) as part of the log-in process. You may create multiple user accounts by repeating the sequence of cards starting with the `$USER` card above. -There are a few additional options for configuring user accounts. The `USER/CANDE` program and format of the cards it processes is also documented in Section 1 of the [http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1058583_B5700_TSS_RefMan_Sep72.pdf Burroughs B5700 Time Sharing System Reference Manual]. +There are a few additional options for configuring user accounts. The `USER/CANDE` program and format of the cards it processes is also documented in Section 1 of the [Burroughs B5700 Time Sharing System Reference Manual](http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1058583_B5700_TSS_RefMan_Sep72.pdf). -== Loading the System Software Files == +## Loading the System Software Files ## -The next step is to load the necessary files from the Mark XIII `SYSTEM` tape image file. You should already have this file from the original setup for the DCMCP, as described in [WebUIGettingStarted WebUI Getting Started]. +The next step is to load the necessary files from the Mark XIII `SYSTEM` tape image file. You should already have this file from the original setup for the DCMCP, as described in [WebUI Getting Started](WebUIGettingStarted.md). First, Halt/Load the system to the DCMCP and set the date and time as necessary. You can also do the following steps under the TSMCP, but you will still need to Halt/Load after building the configuration files. -Load the `SYSTEM` tape image file into the tape drive (MTA window) by clicking the *LOAD* button on the drive, selecting the file, and then clicking the *REMOTE* button. You can confirm that the tape is loaded and ready by entering the following SPO command, but this is not necessary: +Load the `SYSTEM` tape image file into the tape drive (MTA window) by clicking the **LOAD** button on the drive, selecting the file, and then clicking the **REMOTE** button. You can confirm that the tape is loaded and ready by entering the following SPO command, but this is not necessary: - {{{ +``` OL MTA - }}} +``` CANDE requires quite a few files, and the easiest thing to do is simply load everything from the `SYSTEM` tape. With the tape loaded in the drive, enter the following command on the SPO: - {{{ +``` CC ADD FROM SYSTEM =/=; END - }}} +``` The `ADD` command will copy only those files that are not already present on disk. You can substitute `LOAD` for `ADD`, which will copy all the files specified, generally overwriting any existing files. This is safe to do, as MCP Library/Maintenance will not overwrite critical files, such as the running MCP. @@ -137,130 +134,131 @@ Copying the files to disk will take a few minutes and output many messages to th If you wish to do a more targeted load, you will need the following files: - {{{ +``` CC ADD FROM SYSTEM TSS/MCP, TSS/INT, USERS/CANDE, SYSDISK/MAKER, - CANDE/TSHARER, FIND/DISK, GUARD/DISK, =/CANDE; END - }}} +``` Note the "`-`" at the end of the first line, which allows continuation of a control command. You should also load any additional compilers or utility programs you will want to use, e.g., `ALGOL/DISK`, `BASIC/DISK`, `COBOL/DISK`, `COBOL68/DISK`, `FORTRAN/DISK`, or `XALGOL/DISK`. -== Building the Configuration Files == +## Building the Configuration Files ## -Create the two configuration files, `SYSTEM/DISK` and `USERS/CANDE` by loading the card deck files you created above into the card reader and clicking the reader's *START* button. The decks can be run in any order. You can load both decks into the reader at the same time, if you wish. +Create the two configuration files, `SYSTEM/DISK` and `USERS/CANDE` by loading the card deck files you created above into the card reader and clicking the reader's **START** button. The decks can be run in any order. You can load both decks into the reader at the same time, if you wish. Make sure you resolve any errors in these decks before proceeding. CANDE will not start without both files present. -== Initiating TSMCP and CANDE == +## Initiating TSMCP and CANDE ## The next step is to designate the MCP and Intrinsics files that should be used at the next Halt/Load. Enter the following two commands on the SPO: on the SPO: - {{{ +``` CM TSS/MCP CI TSS/INT - }}} +``` These commands modify the bootstrap information in sector 0 of the disk. You should see responses similar to this: - {{{ +``` CM TSS/MCP NEXT MCP WILL BE TSS/MCP CI TSS/INT NEW INTRINSIC FILE IS: TSS/INT. - }}} +``` -Now reboot the system by switching to the emulator's Console window and clicking first the *HALT* button and then the *LOAD* button (this is why it's called a Halt/Load). You should see a message indicating the TSMCP is now running. After initialization completes, enter the date and time as necessary: +Now reboot the system by switching to the emulator's Console window and clicking first the **HALT** button and then the **LOAD** button (this is why it's called a Halt/Load). You should see a message indicating the TSMCP is now running. After initialization completes, enter the date and time as necessary: - {{{ +``` -H/L WITH TSS/MCP MARK XIII,F=16384[MODS=RRRRRRRR]- TIME IS 1429 DATE IS THURSDAY, 11/17/83 #TR PLEASE TR 1431 TIME IS 1431 - }}} +``` The "`F=16384`" indicates the fence location in memory. The value shown is the default if the fence was not specified at Cold Start time. You can change this value at any time using the `MF` SPO command, but it will only take effect at the next Halt/Load. Fence values must be in the range 8184 to 28644. Lower values give more memory to the swap areas for batch and interactive user programs. Higher values give more memory to the MCP and CANDE handler program. The default value is a good one to start with. To switch back to the DCMCP, simply designate its MCP and intrinsics files and do another Halt/Load. The fence location is ignored by the DCMCP: - {{{ +``` CM MCP/DISK CI INT/DISK - }}} +``` Once the TSMCP has initialized, you can initiate CANDE with the following SPO command: - {{{ +``` CE - }}} +``` You should see the CANDE handler enter the mix and output its initialization message: - {{{ +``` 0:CANDE/TSHARER/SITE= 1 BOJ 1516 USERS/CANDE FILE DATED 00111783 - }}} +``` This indicates that CANDE is running and ready for use. -= Using CANDE = +# Using CANDE # -A typical B5500 timesharing system supported 20-30 users. The web-based emulator supports only one terminal, though, so only one user at a time can be signed on to CANDE in this environment. More information on using the emulated terminal can be found in the [WebUIUsingDatacom Using Datacom] wiki page. +A typical B5500 timesharing system supported 20-30 users. The web-based emulator supports only one terminal, though, so only one user at a time can be signed on to CANDE in this environment. More information on using the emulated terminal can be found in the [Using Datacom](WebUIUsingDatacom.md) wiki page. Note that six of the 64 characters in the B5500 character set were used as control characters by the teletype adapter hardware, and could not be used for their normal purpose in user program text and output messages: -|| *Terminal* || *B5500 graphic* || *Input* || *Output* || -|| `}` || greater-or-equal || ignored || disconnect switched line || -|| `{` || less-or-equal || ignored || carriage return || -|| `!` || not-equal || disconnect || line feed || -|| `>` || greater-than || ignored || X-on (ASCII DC1) || -|| `<` || less-than || backspace || RUBOUT (ASCII DEL) || -|| `~` || left-arrow || end of message || end of message || +| **Terminal** | **B5500 graphic** | **Input** | **Output** | +|:-------------|:------------------|:----------|:-----------| +| `}` | greater-or-equal | ignored | disconnect switched line | +| `{` | less-or-equal | ignored | carriage return | +| `!` | not-equal | disconnect | line feed | +| `>` | greater-than | ignored | X-on (ASCII DC1) | +| `<` | less-than | backspace | RUBOUT (ASCII DEL) | +| `~` | left-arrow | end of message | end of message | -See pages 3-15 and 3-16 in the [http://bitsavers.org/pdf/burroughs/1031986_B5500_Handbook_Aug70.pdf B5500 Handbook] for information on the character substitutions used by the B249/B487. +See pages 3-15 and 3-16 in the [B5500 Handbook](http://bitsavers.org/pdf/burroughs/1031986_B5500_Handbook_Aug70.pdf) for information on the character substitutions used by the B249/B487. -To begin a session, click the *Connect* button on the terminal (DCA) window. The button should light. +To begin a session, click the **Connect** button on the terminal (DCA) window. The button should light. -== Logging In == +## Logging In ## After connecting the terminal, you should see a welcome message from CANDE within a few seconds: - {{{ +``` B5500 TIME SHARING - 01/00, STATION 02 ENTER USER CODE, PLEASE- - }}} +``` -Enter your user name as defined in the `USERS/CANDE` file. Officially, the end-of-message character for a teletype device was the left-arrow key (Shift-letter-O, "`~`" in the emulator), but as a convenience the emulator also supports using the *Enter* key. The terminal will echo a "`~`" in either case. +Enter your user name as defined in the `USERS/CANDE` file. Officially, the end-of-message character for a teletype device was the left-arrow key (Shift-letter-O, "`~`" in the emulator), but as a convenience the emulator also supports using the **Enter** key. The terminal will echo a "`~`" in either case. - {{{ +``` ENTER USER CODE, PLEASE-B5500~ - }}} +``` CANDE will next request your password and output several sequences of characters on the same line of the terminal. On a teletype device, this would create an inky blob on the paper, which would obscure the password when it was entered. That doesn't work so well on a web page, so just enter your password on top of those characters, followed by end-of-message. If you did not specify a password for your user name, just key end-of-message by itself. - {{{ +``` AND YOUR PASSWORD SECRET~@ 11/17/83 2:33 PM. GOOD AFTERNOON, USER NAME YOU HAVE STATION 02 # - }}} +``` -At this point, you are logged in to CANDE and can begin entering commands. When you are finished with your session, enter `BYE` to log out. Alternatively, you can click the terminal's *Connect* button to disconnect. +At this point, you are logged in to CANDE and can begin entering commands. When you are finished with your session, enter `BYE` to log out. Alternatively, you can click the terminal's **Connect** button to disconnect. CANDE commands and use of the terminal under CANDE are documented in the -[http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1038205_B5500_TS_TerminalUG_Jun69.pdf Burroughs B5500 Time Sharing System Terminal User's Guide]. Note that the emulator does not presently support the paper tape terminal features described in this manual, particularly the CANDE `TAPE` command. +[Burroughs B5500 Time Sharing System Terminal User's Guide](http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1038205_B5500_TS_TerminalUG_Jun69.pdf). Note that the emulator does not presently support the paper tape terminal features described in this manual, particularly the CANDE `TAPE` command. -== Sample CANDE Session == +## Sample CANDE Session ## Here is a sample session, illustrating creating, compiling, and running a simple BASIC program. CANDE requires line numbers (more properly known as sequence numbers) on all lines of all files, not just those for BASIC: - {{{ +``` CREATE FOO BASIC~ FILE:FOO - TYPE:BASIC -- CREATED 10FOR I = 1 TO 5~ @@ -283,7 +281,7 @@ Here is a sample session, illustrating creating, compiling, and running a simple 5 25 END FOO .4 SEC. - }}} +``` Note that the `RUN` command knows if the program source has not been compiled since it was last modified, and automatically recompiles before running it. @@ -291,7 +289,7 @@ Now we edit the program slightly and recompile and rerun it. The "`*`" (`FIX`) c Also note that multiple CANDE commands can be entered on one line, delimited by semicolons ("`;`"). Due to their nature, single-line entries (commands beginning with a sequence number) and `FIX` commands can appear only as the last command on a line. - {{{ +``` *20/I*I/SQR(I)~ LIST; RUN~ @@ -317,11 +315,11 @@ Also note that multiple CANDE commands can be entered on one line, delimited by 5 2.236068 END FOO .3 SEC. - }}} +``` Here is a slightly larger example of an Algol program that implements the outrageously-recursive Ackermann function. Note the use of the CANDE `SEQ` (sequence) command to automatically supply line numbers and the "`<`" character as a backspace: - {{{ +``` CREATE ACKMAN ALGOL~ FILE:ACKMAN - TYPE:ALGOL -- CREATED SEQ 100100+100~ @@ -359,13 +357,13 @@ Here is a slightly larger example of an Algol program that implements the outrag NEAR LINE 102300 ERROR NUMBER 100 -- F1. ERR COMPILE .7 SEC. - }}} +``` Oops, we forgot to define the format `F1`. We will insert it by choosing a line number between two of the existing ones. Also, one of the `ELSE` clauses is indented too far, so we'll fix that as well. Note that the `SEQ` command above was terminated by entering an empty line. A type-19 file declaration (line 101700) creates a datacom "remote" file, which is automatically assigned to the initiating terminal by the TSMCP. - {{{ +``` 101750FORMAT F1 (2I4,I12);~ FIX 101200. .~ RUN~ @@ -404,13 +402,13 @@ Note that the `SEQ` command above was terminated by entering an empty line. A ty -STACK OVRFLW, LINE NO 101500 ERR ACKMAN .3 SEC. - }}} +``` The Ackermann function is so heavily recursive that the program ran out of stack space while trying to evaluate `ACKERMANN(3,4)`. Now we will save what we have done thus far, list the current version of the program, and log off CANDE: - {{{ +``` SAVE~ FILE:ACKMAN - TYPE:ALGOL -- SAVED. @@ -455,14 +453,14 @@ Now we will save what we have done thus far, list the current version of the pro OFF AT 2:36 PM. GOODBYE B5500 11/17/83 - }}} +``` -= Cold-Starting Directly to the TSMCP = +# Cold-Starting Directly to the TSMCP # This page has described how to set up TSMCP and CANDE after the B5500 emulator has already been cold-started with the DCMCP. It is also possible to Cold Start directly to the TSMCP. -Peter Grootswagers has prepared a very nice set of instructions for cold-starting directly to TSMCP. This is available on the [http://groups.google.com/group/retro-b5500 retro-B5500 forum], dated 20 November 2013. The direct link to the post with his instructions is [https://groups.google.com/forum/#!topic/retro-b5500/zCBSxow113M]. +Peter Grootswagers has prepared a very nice set of instructions for cold-starting directly to TSMCP. This is available on the [retro-B5500 forum](http://groups.google.com/group/retro-b5500), dated 20 November 2013. The direct link to the post with his instructions is https://groups.google.com/forum/#!topic/retro-b5500/zCBSxow113M. diff --git a/WebUIRunningTheEmulator.md b/WebUIRunningTheEmulator.md deleted file mode 100644 index 48c064d..0000000 --- a/WebUIRunningTheEmulator.md +++ /dev/null @@ -1,173 +0,0 @@ -# WebUI Running the Emulator # - - -This page describes operation of the retro-B5500 emulator in a web browser. In order to use the emulator, it must first have been set up as described in [WebUI Getting Started](WebUIGettingStarted.md). - -Note that some web browsers, particularly Firefox, may slow the execution of their web pages when those pages are running in a non-active tab of a window. The emulator runs continuously, and has a performance throttling mechanism that attempts to run the emulated processors at their real B5500 speed. To keep this mechanism synchronized with real time, do not open the B5500 Console in a window where one of the other tabs is active. It is best to open the Console in its own window, or at least keep it as the active tab in its window. If you need to use the browser to access other sites at the same time the emulator is running, it is best to open separate browser windows to do so. - -Beginning with release 1.00, the emulator can now run off-line, without access to the web server from which it is hosted. Off-line operation is automatic when the browser is operating without a network connection or cannot contact the web server. See the discussion on off-line operation in [Using the Console](WebUIUsingTheConsole.md) for details on how this works. - - -# "Powering Up" the Emulator # - -The emulator is initiated from the `B5500Console.html` home 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 - -The home page will look similar to this: - -> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Home-Page.png](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Home-Page.png) - -The home page has two buttons, each of which will start the emulator and open a window for the Operator Console: - - * **Start & Power On** will display the Console window and automatically power up the emulator, as if you had clicked the Console's green **POWER ON** button. - * **Start - Powered Off** will simply display the Console window without powering up the emulator. This button is useful if you want to make configuration changes to the emulator, as those can only be made while the emulator is in a powered-off state. - -The Console is a small control panel with several buttons and lights. The **HALT**, **CARD 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 [Using the B5500 Console](WebUIUsingTheConsole.md). - -> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Console.png](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Console.png) - -To initialize the emulator, click the **POWER ON** button. The Console will display a brief lamp test. The **HALT** light will then illuminate, 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. Closing the Console window will power down the emulator. - -The SPO (Supervisory Printer) window is the one you will typically use the most. The Console window is also useful, as its lights give you information about how the system is running. - - -# Halt/Loading the MCP # - -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`. The MCP and `KERNEL` are placed on disk by the [Cold Start process](WebUIGettingStarted#Cold-Starting_the_System.md). - -The B5500 supports two types of load. The primary one is from disk and the alternate is from cards, as controlled by the **CARD LOAD SELECT** push button. In its normal, unlit state, **CARD LOAD SELECT** causes the system to load 63 segments starting at segment 1 of Electronics Unit (EU) 0. When **CARD LOAD SELECT** is illuminated, the system loads one binary card from the primary card reader, CRA. Clicking the button toggles its state. - -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. The **LOAD** button will not function until the SPO is on line and goes to **REMOTE** status. - -To load the MCP from disk, make sure the **CARD LOAD SELECT** button is not activated (unlit), 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. If either of these messages prints on the SPO, you must respond to them, as discussed in the next section. - -``` - #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. - -To help enforce that practice, we recommend that you require the time to be set (`SO USE TIME`), but not the date (`RO USE DATE`) at each halt/load. These option settings are established by the project's default Cold Start configuration, but you may change them after booting the MCP. With those option settings, the system will require you to set the time, but use it's prior date unless you change it. Until the time is set, the MCP will not recognize ready status on any of the peripherals except the SPO, and will not run any user programs. - -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 -- 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. The Mark XIII system files have dates in the 1970s, however, so to the system it will appear those files 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. Note that the day of week calculated by the system in this case will be incorrect for a 21st century year. - -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, will preserve the date across halt/loads, and will automatically change the date when its time-of-day clock crosses midnight. - - -# 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](http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/) have useful information: - - * The [B5500 Handbook (April 1970)](http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/1031986_B5500_Handbook_Aug70.pdf) describes: - * SPO output messages starting on page 4-1. - * SPO commands starting on page 4-23. - * The [B5500 Operation Manual (September 1968)](http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/1024916_B5500_B5700_OperMan_Sep68.pdf) 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 input commands starting on page C-40. - * The [Narrative Description of the B5500 MCP](http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1023579_Narrative_Description_Of_B5500_MCP_Oct66.pdf) gives a good overview of the MCP and how it works. - * The [bitsavers index page for the B5000/B5500/B5700](http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/) 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 [Using the SPO](WebUIUsingTheSPO.md) 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`. Our convention is to use a file extension of `.card` for these files, but the emulator applies no significance to the manner in which the files are named. 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 uses five special Algol characters that do not have ASCII equivalents, so we have chosen the following ASCII substitutions for them: - - * `~` for left-arrow - * `|` for "�" (multiplication) - * `{` 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. The underscore ("`_`") will be accepted as a substitute for the left-arrow. The card reader will also accept five Unicode characters for the special Algol characters -- U+00D7 for multiplication, U+2190 for left-arrow, U+2260 for not-equal, U+2264 for less-than-or-equal, and U+2265 for greater-than-or-equal. - -The card reader will consider all other ASCII or Unicode characters to be "invalid punches" in a card. An ASCII "`?`" 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" 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 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 as described above, and then click **START** to make it ready again. The MCP will automatically sense the status change and resume reading cards. - * 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 `?END` 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. You can then fix the deck and reload it into the reader. - - -# 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 manually, one at a time. - -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. One reason to do this is to change the system configuration, which can only be down with the power off. All of the other windows in the currently-selected configuration are reopened when the emulator is reinitialized by the **POWER ON** button. \ No newline at end of file diff --git a/WebUIRunningTheEmulator.wiki b/WebUIRunningTheEmulator.wiki index 3d88bd6..48c064d 100644 --- a/WebUIRunningTheEmulator.wiki +++ b/WebUIRunningTheEmulator.wiki @@ -1,120 +1,117 @@ -#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 = - - -This page describes operation of the retro-B5500 emulator in a web browser. In order to use the emulator, it must first have been set up as described in [WebUIGettingStarted WebUI Getting Started]. - -Note that some web browsers, particularly Firefox, may slow the execution of their web pages when those pages are running in a non-active tab of a window. The emulator runs continuously, and has a performance throttling mechanism that attempts to run the emulated processors at their real B5500 speed. To keep this mechanism synchronized with real time, do not open the B5500 Console in a window where one of the other tabs is active. It is best to open the Console in its own window, or at least keep it as the active tab in its window. If you need to use the browser to access other sites at the same time the emulator is running, it is best to open separate browser windows to do so. - -Beginning with release 1.00, the emulator can now run off-line, without access to the web server from which it is hosted. Off-line operation is automatic when the browser is operating without a network connection or cannot contact the web server. See the discussion on off-line operation in [WebUIUsingTheConsole Using the Console] for details on how this works. - - -= "Powering Up" the Emulator = - -The emulator is initiated from the `B5500Console.html` home 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 - -The home page will look similar to this: - - https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Home-Page.png - -The home page has two buttons, each of which will start the emulator and open a window for the Operator Console: - - * *Start & Power On* will display the Console window and automatically power up the emulator, as if you had clicked the Console's green *POWER ON* button. - * *Start - Powered Off* will simply display the Console window without powering up the emulator. This button is useful if you want to make configuration changes to the emulator, as those can only be made while the emulator is in a powered-off state. - -The Console is a small control panel with several buttons and lights. The *HALT*, *CARD 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 Console will display a brief lamp test. The *HALT* light will then illuminate, 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. Closing the Console window will power down the emulator. - -The SPO (Supervisory Printer) window is the one you will typically use the most. The Console window is also useful, as its lights give you information about how the system is running. - - -= Halt/Loading the MCP = - -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`. The MCP and `KERNEL` are placed on disk by the [WebUIGettingStarted#Cold-Starting_the_System Cold Start process]. - -The B5500 supports two types of load. The primary one is from disk and the alternate is from cards, as controlled by the *CARD LOAD SELECT* push button. In its normal, unlit state, *CARD LOAD SELECT* causes the system to load 63 segments starting at segment 1 of Electronics Unit (EU) 0. When *CARD LOAD SELECT* is illuminated, the system loads one binary card from the primary card reader, CRA. Clicking the button toggles its state. - -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. The *LOAD* button will not function until the SPO is on line and goes to *REMOTE* status. - -To load the MCP from disk, make sure the *CARD LOAD SELECT* button is not activated (unlit), 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: - - {{{ +# WebUI Running the Emulator # + + +This page describes operation of the retro-B5500 emulator in a web browser. In order to use the emulator, it must first have been set up as described in [WebUI Getting Started](WebUIGettingStarted.md). + +Note that some web browsers, particularly Firefox, may slow the execution of their web pages when those pages are running in a non-active tab of a window. The emulator runs continuously, and has a performance throttling mechanism that attempts to run the emulated processors at their real B5500 speed. To keep this mechanism synchronized with real time, do not open the B5500 Console in a window where one of the other tabs is active. It is best to open the Console in its own window, or at least keep it as the active tab in its window. If you need to use the browser to access other sites at the same time the emulator is running, it is best to open separate browser windows to do so. + +Beginning with release 1.00, the emulator can now run off-line, without access to the web server from which it is hosted. Off-line operation is automatic when the browser is operating without a network connection or cannot contact the web server. See the discussion on off-line operation in [Using the Console](WebUIUsingTheConsole.md) for details on how this works. + + +# "Powering Up" the Emulator # + +The emulator is initiated from the `B5500Console.html` home 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 + +The home page will look similar to this: + +> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Home-Page.png](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Home-Page.png) + +The home page has two buttons, each of which will start the emulator and open a window for the Operator Console: + + * **Start & Power On** will display the Console window and automatically power up the emulator, as if you had clicked the Console's green **POWER ON** button. + * **Start - Powered Off** will simply display the Console window without powering up the emulator. This button is useful if you want to make configuration changes to the emulator, as those can only be made while the emulator is in a powered-off state. + +The Console is a small control panel with several buttons and lights. The **HALT**, **CARD 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 [Using the B5500 Console](WebUIUsingTheConsole.md). + +> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Console.png](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Console.png) + +To initialize the emulator, click the **POWER ON** button. The Console will display a brief lamp test. The **HALT** light will then illuminate, 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. Closing the Console window will power down the emulator. + +The SPO (Supervisory Printer) window is the one you will typically use the most. The Console window is also useful, as its lights give you information about how the system is running. + + +# Halt/Loading the MCP # + +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`. The MCP and `KERNEL` are placed on disk by the [Cold Start process](WebUIGettingStarted#Cold-Starting_the_System.md). + +The B5500 supports two types of load. The primary one is from disk and the alternate is from cards, as controlled by the **CARD LOAD SELECT** push button. In its normal, unlit state, **CARD LOAD SELECT** causes the system to load 63 segments starting at segment 1 of Electronics Unit (EU) 0. When **CARD LOAD SELECT** is illuminated, the system loads one binary card from the primary card reader, CRA. Clicking the button toggles its state. + +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. The **LOAD** button will not function until the SPO is on line and goes to **REMOTE** status. + +To load the MCP from disk, make sure the **CARD LOAD SELECT** button is not activated (unlit), 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: - - {{{ +``` + +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. If either of these messages prints on the SPO, you must respond to them, as discussed in the next section. - - {{{ +``` + +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. If either of these messages prints on the SPO, you must respond to them, as discussed in the next section. + +``` #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. - -To help enforce that practice, we recommend that you require the time to be set (`SO USE TIME`), but not the date (`RO USE DATE`) at each halt/load. These option settings are established by the project's default Cold Start configuration, but you may change them after booting the MCP. With those option settings, the system will require you to set the time, but use it's prior date unless you change it. Until the time is set, the MCP will not recognize ready status on any of the peripherals except the SPO, and will not run any user programs. - -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 -- the MCP must first initiate an I/O to the SPO) enter the following, substituting your current time in 24-hour format. - - {{{ +``` + +# 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. + +To help enforce that practice, we recommend that you require the time to be set (`SO USE TIME`), but not the date (`RO USE DATE`) at each halt/load. These option settings are established by the project's default Cold Start configuration, but you may change them after booting the MCP. With those option settings, the system will require you to set the time, but use it's prior date unless you change it. Until the time is set, the MCP will not recognize ready status on any of the peripherals except the SPO, and will not run any user programs. + +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 -- 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. The Mark XIII system files have dates in the 1970s, however, so to the system it will appear those files 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. Note that the day of week calculated by the system in this case will be incorrect for a 21st century year. - -To set the date, enter a `DT` command with the date in month/day/year format: - - {{{ +``` + +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. The Mark XIII system files have dates in the 1970s, however, so to the system it will appear those files 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. Note that the day of week calculated by the system in this case will be incorrect for a 21st century year. + +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, will preserve the date across halt/loads, and will automatically change the date when its time-of-day clock crosses midnight. - - -= Exploring the B5500 Environment = - -Once the date and time are properly set, you can begin to use the system. A number of documents on [http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/ 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 input 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`. Our convention is to use a file extension of `.card` for these files, but the emulator applies no significance to the manner in which the files are named. The 64 valid ASCII characters you can use with the emulator are: - - {{{ +``` + +You can also use hyphens (`-`) instead of slashes (`/`) to separate the fields of the dates. The MCP stores the date on disk, will preserve the date across halt/loads, and will automatically change the date when its time-of-day clock crosses midnight. + + +# 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](http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/) have useful information: + + * The [B5500 Handbook (April 1970)](http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/1031986_B5500_Handbook_Aug70.pdf) describes: + * SPO output messages starting on page 4-1. + * SPO commands starting on page 4-23. + * The [B5500 Operation Manual (September 1968)](http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/1024916_B5500_B5700_OperMan_Sep68.pdf) 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 input commands starting on page C-40. + * The [Narrative Description of the B5500 MCP](http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1023579_Narrative_Description_Of_B5500_MCP_Oct66.pdf) gives a good overview of the MCP and how it works. + * The [bitsavers index page for the B5000/B5500/B5700](http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/) 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 [Using the SPO](WebUIUsingTheSPO.md) 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`. Our convention is to use a file extension of `.card` for these files, but the emulator applies no significance to the manner in which the files are named. 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 @@ -123,23 +120,23 @@ You can prepare "card decks" as ordinary text files on your workstation and read Q R $ * - 0 ; { / S T U V W X Y Z , % ! = } " - }}} - -The B5500 uses five special Algol characters that do not have ASCII equivalents, so we have chosen the following ASCII substitutions for them: - - * `~` for left-arrow - * `|` for "×" (multiplication) - * `{` 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. The underscore ("`_`") will be accepted as a substitute for the left-arrow. The card reader will also accept five Unicode characters for the special Algol characters -- U+00D7 for multiplication, U+2190 for left-arrow, U+2260 for not-equal, U+2264 for less-than-or-equal, and U+2265 for greater-than-or-equal. - -The card reader will consider all other ASCII or Unicode characters to be "invalid punches" in a card. An ASCII "`?`" 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" 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 simple Algol program. The program's output will go to the line printer: - - {{{ +``` + +The B5500 uses five special Algol characters that do not have ASCII equivalents, so we have chosen the following ASCII substitutions for them: + + * `~` for left-arrow + * `|` for "�" (multiplication) + * `{` 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. The underscore ("`_`") will be accepted as a substitute for the left-arrow. The card reader will also accept five Unicode characters for the special Algol characters -- U+00D7 for multiplication, U+2190 for left-arrow, U+2260 for not-equal, U+2264 for less-than-or-equal, and U+2265 for greater-than-or-equal. + +The card reader will consider all other ASCII or Unicode characters to be "invalid punches" in a card. An ASCII "`?`" 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" 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 simple Algol program. The program's output will go to the line printer: + +``` ? COMPILE FIRST/TRY WITH ALGOL GO ? DATA CARD $ CARD LIST SINGLE @@ -152,25 +149,25 @@ Your "card deck" files should have the necessary control cards on the front (wit 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 as described above, and then click *START* to make it ready again. The MCP will automatically sense the status change and resume reading cards. - * 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 `?END` 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. You can then fix the deck and reload it into the reader. - - -= 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 manually, one at a time. - -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. One reason to do this is to change the system configuration, which can only be down with the power off. All of the other windows in the currently-selected configuration are reopened when the emulator is reinitialized by the *POWER ON* button. \ No newline at end of file +``` + +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 as described above, and then click **START** to make it ready again. The MCP will automatically sense the status change and resume reading cards. + * 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 `?END` 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. You can then fix the deck and reload it into the reader. + + +# 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 manually, one at a time. + +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. One reason to do this is to change the system configuration, which can only be down with the power off. All of the other windows in the currently-selected configuration are reopened when the emulator is reinitialized by the **POWER ON** button. \ No newline at end of file diff --git a/WebUIUsingDatacom.md b/WebUIUsingDatacom.md deleted file mode 100644 index 41aa744..0000000 --- a/WebUIUsingDatacom.md +++ /dev/null @@ -1,77 +0,0 @@ -# WebUI Using Datacom # - - - -Data communications interfaces for computers were at a primitive state when the B5000 and B5500 were designed, and it shows in the equipment and software available with the B5500. Datacom was an I/O device. It multiplexed the traffic for multiple terminals onto one data path to and from the I/O Control Units. - -The B5500 initially supported teletypes and other low-speed devices, but eventually supported the Burroughs line of poll-select video terminals, the TC500 (a programmable keyboard/printer device), and RJE through satellite B300 or IBM 1050 systems. - - - -# Background # - -There was an early "inquiry" system based on the B5480 Data Communications Control Unit (DCCU). This was somewhat limited, as it could not initiate messages to a remote terminal -- it could only send responses to messages from a terminal. - -The second iteration was a "data transmission" system, which consisted of the B249 Data Transmission Control Unit (DTCU) plus up to 15 B487 Data Transmission Terminal Units (DTTU). The DTCU connected to the B5500 I/O Control Unit. It provided a multiplexed interface for the B487s, along with translation circuitry to convert ASCII and Baudot character sets to the BCL encoding used with the B5500. - -Each B487 supported up to 15 communications circuits. Each circuit was terminated in an adapter card that plugged into the B487. There were different adapter cards for different types of circuits (e.g., teletype current-loop, Bell 103A modem, TWIX, etc.). The B487 buffered characters from each circuit to assemble messages, sending blocks of message data instead of individual characters through the B249 to the I/O Control Unit. - -The B487 was limited, however, by a very small buffer memory -- 420 characters total for all circuits. 28 characters of this was allocated to each adapter slot, but multiple 28-character chunks could be assigned to an adapter by leaving the appropriate number of adapter slots following that adapter unoccupied. Thus, on one B487 you could configure lots of adapters with small buffers, or fewer adapters with larger buffers. - -One problem with implementing a datacom interface in the web-based emulator is that web browsers act strictly as clients in a network connection, and what the emulator needs to do is act as a server. As a result, the web-based emulator cannot support something obvious, such as the Telnet protocol -- there just is not any way to get a browser to accept those connections as a server. - -Therefore, we have decided to punt and implement a datacom interface for a _single_ terminal within the browser environment itself. While internally this terminal implements much of the mechanism of the B487 and B249, on the surface it works somewhat like the SPO device. It has a terminal-like window that emulates a teletype device. The device has been assigned four buffer segments, or 112 characters of buffer memory. Ping-pong buffering is not currently supported. - -The window for the terminal interface we have developed for the web-based emulator looks like this: - -> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Datacom-Terminal.png](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Datacom-Terminal.png) - -You type messages into this window, and the window displays the system's responses -- all at ten characters per second -- just like any good 1960s terminal would do. - - -# Terminal Control Panel # - -The B249 DTCU and B487 DTTU do not have a user interface. The terminal itself is all that appears, and roughly models a Teletype Model 33 KSR unit. Across the top of its window are a **Connect** button and a series of red indicators reflecting the status of the terminal's buffer in the DTTU: - - * **NR** -- Not Ready -- the buffer and/or DTCU/DTTU is not ready. - * **IDLE** -- the buffer is in an idle state, ready to receive input from the user or output from the system. - * **RR** -- Read Ready -- The user has entered a message into the buffer that is ready to be sent to the system. A buffer becomes Read Ready when the user enters an end-of-message character (see below) or the buffer becomes completely full. The buffer signals the system that it has data to send. The state reverts to Idle once the system reads the buffer. - * **WR** -- Write Ready -- this state is normally set after the system sends data to the buffer without an end-of-message character. Once the buffer sends the all of data to the terminal, the buffer enters the Write Ready state and signals the system that it is ready for more output. - * **IBZ** -- Input Busy -- the buffer enters this state when the user types the first character of a message. It stays in this state until either the user enters an end-of-message character or the buffer becomes full, at which point it enters the Read Ready state. - * **OBZ** -- Output Busy -- the buffer enters this state after receiving an output message from the system. It stays in this state while it is transmitting the data to the terminal. Once the buffer is empty, it enters either the Idle or Write Ready state, depending on whether it has seen an end-of-message character from the system or the buffer has become full. - * **AB** -- Abnormal -- this is a flag that has different meaning depending on the state of the buffer. For example, Input Busy Abnormal indicates that the user has entered a "?" in the message (used to indicate a control message to the MCP). Write Ready Abnormal indicates that either the terminal has just connected to the DTTU or the user has entered the WRU (who-are-you) character. It is generally reset the next time the buffer changes state. - * **INT** -- Interrupt Requested -- this is another flag that can be set for several states when the buffer requires attention from the system. It indicates than an Inquiry Request interrupt has been sent to the B5500. It will be reset once the B5500 performs an Interrogate operation to determine the status of the highest-priority buffer that initiated the interrupt. - * **FB** -- Full Buffer -- this flag indicates that the buffer has been filled on either input or output without sensing an end-of-character message. It will be reset once the buffer is emptied. - - -# Using the Datacom Terminal # - -The **Connect** button is used to initiate a connection between the terminal and the DTTU, similar to dialing a telephone number and establishing a modem connection. Simply click the button to connect. It will light. Click again to disconnect. After connecting, a system running the Datacom MCP should respond with an identification message within a few seconds: - -``` - B-5500 01/00 -``` - -The numbers following "`B-5500`" are the DTTU number and buffer number within that DTTU. Since the emulator currently supports only one terminal buffer, these numbers are constant. - -Because the B5500 had a character set consisting of only 64 printable characters, it had no native provision for the types of control characters (carriage-return, backspace, etc.) we are now accustomed to using with ASCII. Therefore, certain of the Model 33 printable characters were reserved for this purpose. On input, the following characters have special meaning: - - * `<` -- backspace. - * (left-arrow) -- end of message. The Model 33 Teletype had this character, but on modern keyboards this is represented by the underscore character (`_`). For the web-based emulator, we use both underscore and the tilde (`~`) to represent the left arrow. The ASCII DC1 character (also known as X-on or control-Q) will also end an input message. - * (control-B) -- also known as ASCII STX, this is the equivalent of sending a Break signal from the terminal. - * (control-E) -- also known as ASCII ENQ, this is the WRU (who-are-you) character. - * (control-L) -- also known as ASCII FF, this character would clear the input buffer after the user started entering a message, but leave the buffer in an Input Busy state. - * `!` -- disconnect -- entered on input, this character will disconnect the terminal from the DTTU. - -The emulated terminal supports two user-interface features that the DTTU Teletype adapter did not: - - 1. You can press the **Enter** key on your keyboard instead of the "`~`" to end a message. The terminal will print a "`~`". - 1. You can press the Backspace key to correct errors. The terminal will print a "`<`". - -See pages 3-15 and 3-16 in the [B5500 Handbook](http://bitsavers.org/pdf/burroughs/1031986_B5500_Handbook_Aug70.pdf) for information on the character substitutions used by the B249/B487. - -You may move and resize the terminal window, and minimize it, but _do not close the window_. The system will warn you if you attempt to do this. Closing the window will render the terminal inoperable until the emulator is reinitialized with the **POWER ON** button. - -When you resize the terminal window, the "paper" area will change size accordingly. If the window becomes too narrow for the current output, the output lines will be clipped on the right, although the output itself is unaffected and will reappear if the window is made larger. Below a certain minimum (and essentially usable) window size, the window contents will no longer resize and will be clipped. - -The area representing the "paper" for the terminal has a 5000-line scrollback. You can copy portions of this text using ordinary click-and-drag functions of your pointing device. If you double-click anywhere in the text, however, the emulator will open a temporary window and copy the entire contents of the "paper" into it. From there, you can save the text in a file or copy/paste it into another application. When you have finished with the temporary window, simply close it. \ No newline at end of file diff --git a/WebUIUsingDatacom.wiki b/WebUIUsingDatacom.wiki index 169010d..41aa744 100644 --- a/WebUIUsingDatacom.wiki +++ b/WebUIUsingDatacom.wiki @@ -1,80 +1,77 @@ -#summary Instructions for using the datacom interface with the retro-B5500 emulator in a web browser. -#labels Burroughs,B5500,emulator,retro-b5500,datacom,terminal,B249,DTCU,B487,DTTU - -= WebUI Using Datacom = - - - -Data communications interfaces for computers were at a primitive state when the B5000 and B5500 were designed, and it shows in the equipment and software available with the B5500. Datacom was an I/O device. It multiplexed the traffic for multiple terminals onto one data path to and from the I/O Control Units. - -The B5500 initially supported teletypes and other low-speed devices, but eventually supported the Burroughs line of poll-select video terminals, the TC500 (a programmable keyboard/printer device), and RJE through satellite B300 or IBM 1050 systems. - - - -= Background = - -There was an early "inquiry" system based on the B5480 Data Communications Control Unit (DCCU). This was somewhat limited, as it could not initiate messages to a remote terminal -- it could only send responses to messages from a terminal. - -The second iteration was a "data transmission" system, which consisted of the B249 Data Transmission Control Unit (DTCU) plus up to 15 B487 Data Transmission Terminal Units (DTTU). The DTCU connected to the B5500 I/O Control Unit. It provided a multiplexed interface for the B487s, along with translation circuitry to convert ASCII and Baudot character sets to the BCL encoding used with the B5500. - -Each B487 supported up to 15 communications circuits. Each circuit was terminated in an adapter card that plugged into the B487. There were different adapter cards for different types of circuits (e.g., teletype current-loop, Bell 103A modem, TWIX, etc.). The B487 buffered characters from each circuit to assemble messages, sending blocks of message data instead of individual characters through the B249 to the I/O Control Unit. - -The B487 was limited, however, by a very small buffer memory -- 420 characters total for all circuits. 28 characters of this was allocated to each adapter slot, but multiple 28-character chunks could be assigned to an adapter by leaving the appropriate number of adapter slots following that adapter unoccupied. Thus, on one B487 you could configure lots of adapters with small buffers, or fewer adapters with larger buffers. - -One problem with implementing a datacom interface in the web-based emulator is that web browsers act strictly as clients in a network connection, and what the emulator needs to do is act as a server. As a result, the web-based emulator cannot support something obvious, such as the Telnet protocol -- there just is not any way to get a browser to accept those connections as a server. - -Therefore, we have decided to punt and implement a datacom interface for a _single_ terminal within the browser environment itself. While internally this terminal implements much of the mechanism of the B487 and B249, on the surface it works somewhat like the SPO device. It has a terminal-like window that emulates a teletype device. The device has been assigned four buffer segments, or 112 characters of buffer memory. Ping-pong buffering is not currently supported. - -The window for the terminal interface we have developed for the web-based emulator looks like this: - - https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Datacom-Terminal.png - -You type messages into this window, and the window displays the system's responses -- all at ten characters per second -- just like any good 1960s terminal would do. - - -= Terminal Control Panel = - -The B249 DTCU and B487 DTTU do not have a user interface. The terminal itself is all that appears, and roughly models a Teletype Model 33 KSR unit. Across the top of its window are a *Connect* button and a series of red indicators reflecting the status of the terminal's buffer in the DTTU: - - * *NR* -- Not Ready -- the buffer and/or DTCU/DTTU is not ready. - * *IDLE* -- the buffer is in an idle state, ready to receive input from the user or output from the system. - * *RR* -- Read Ready -- The user has entered a message into the buffer that is ready to be sent to the system. A buffer becomes Read Ready when the user enters an end-of-message character (see below) or the buffer becomes completely full. The buffer signals the system that it has data to send. The state reverts to Idle once the system reads the buffer. - * *WR* -- Write Ready -- this state is normally set after the system sends data to the buffer without an end-of-message character. Once the buffer sends the all of data to the terminal, the buffer enters the Write Ready state and signals the system that it is ready for more output. - * *IBZ* -- Input Busy -- the buffer enters this state when the user types the first character of a message. It stays in this state until either the user enters an end-of-message character or the buffer becomes full, at which point it enters the Read Ready state. - * *OBZ* -- Output Busy -- the buffer enters this state after receiving an output message from the system. It stays in this state while it is transmitting the data to the terminal. Once the buffer is empty, it enters either the Idle or Write Ready state, depending on whether it has seen an end-of-message character from the system or the buffer has become full. - * *AB* -- Abnormal -- this is a flag that has different meaning depending on the state of the buffer. For example, Input Busy Abnormal indicates that the user has entered a "?" in the message (used to indicate a control message to the MCP). Write Ready Abnormal indicates that either the terminal has just connected to the DTTU or the user has entered the WRU (who-are-you) character. It is generally reset the next time the buffer changes state. - * *INT* -- Interrupt Requested -- this is another flag that can be set for several states when the buffer requires attention from the system. It indicates than an Inquiry Request interrupt has been sent to the B5500. It will be reset once the B5500 performs an Interrogate operation to determine the status of the highest-priority buffer that initiated the interrupt. - * *FB* -- Full Buffer -- this flag indicates that the buffer has been filled on either input or output without sensing an end-of-character message. It will be reset once the buffer is emptied. - - -= Using the Datacom Terminal = - -The *Connect* button is used to initiate a connection between the terminal and the DTTU, similar to dialing a telephone number and establishing a modem connection. Simply click the button to connect. It will light. Click again to disconnect. After connecting, a system running the Datacom MCP should respond with an identification message within a few seconds: - - {{{ +# WebUI Using Datacom # + + + +Data communications interfaces for computers were at a primitive state when the B5000 and B5500 were designed, and it shows in the equipment and software available with the B5500. Datacom was an I/O device. It multiplexed the traffic for multiple terminals onto one data path to and from the I/O Control Units. + +The B5500 initially supported teletypes and other low-speed devices, but eventually supported the Burroughs line of poll-select video terminals, the TC500 (a programmable keyboard/printer device), and RJE through satellite B300 or IBM 1050 systems. + + + +# Background # + +There was an early "inquiry" system based on the B5480 Data Communications Control Unit (DCCU). This was somewhat limited, as it could not initiate messages to a remote terminal -- it could only send responses to messages from a terminal. + +The second iteration was a "data transmission" system, which consisted of the B249 Data Transmission Control Unit (DTCU) plus up to 15 B487 Data Transmission Terminal Units (DTTU). The DTCU connected to the B5500 I/O Control Unit. It provided a multiplexed interface for the B487s, along with translation circuitry to convert ASCII and Baudot character sets to the BCL encoding used with the B5500. + +Each B487 supported up to 15 communications circuits. Each circuit was terminated in an adapter card that plugged into the B487. There were different adapter cards for different types of circuits (e.g., teletype current-loop, Bell 103A modem, TWIX, etc.). The B487 buffered characters from each circuit to assemble messages, sending blocks of message data instead of individual characters through the B249 to the I/O Control Unit. + +The B487 was limited, however, by a very small buffer memory -- 420 characters total for all circuits. 28 characters of this was allocated to each adapter slot, but multiple 28-character chunks could be assigned to an adapter by leaving the appropriate number of adapter slots following that adapter unoccupied. Thus, on one B487 you could configure lots of adapters with small buffers, or fewer adapters with larger buffers. + +One problem with implementing a datacom interface in the web-based emulator is that web browsers act strictly as clients in a network connection, and what the emulator needs to do is act as a server. As a result, the web-based emulator cannot support something obvious, such as the Telnet protocol -- there just is not any way to get a browser to accept those connections as a server. + +Therefore, we have decided to punt and implement a datacom interface for a _single_ terminal within the browser environment itself. While internally this terminal implements much of the mechanism of the B487 and B249, on the surface it works somewhat like the SPO device. It has a terminal-like window that emulates a teletype device. The device has been assigned four buffer segments, or 112 characters of buffer memory. Ping-pong buffering is not currently supported. + +The window for the terminal interface we have developed for the web-based emulator looks like this: + +> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Datacom-Terminal.png](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Datacom-Terminal.png) + +You type messages into this window, and the window displays the system's responses -- all at ten characters per second -- just like any good 1960s terminal would do. + + +# Terminal Control Panel # + +The B249 DTCU and B487 DTTU do not have a user interface. The terminal itself is all that appears, and roughly models a Teletype Model 33 KSR unit. Across the top of its window are a **Connect** button and a series of red indicators reflecting the status of the terminal's buffer in the DTTU: + + * **NR** -- Not Ready -- the buffer and/or DTCU/DTTU is not ready. + * **IDLE** -- the buffer is in an idle state, ready to receive input from the user or output from the system. + * **RR** -- Read Ready -- The user has entered a message into the buffer that is ready to be sent to the system. A buffer becomes Read Ready when the user enters an end-of-message character (see below) or the buffer becomes completely full. The buffer signals the system that it has data to send. The state reverts to Idle once the system reads the buffer. + * **WR** -- Write Ready -- this state is normally set after the system sends data to the buffer without an end-of-message character. Once the buffer sends the all of data to the terminal, the buffer enters the Write Ready state and signals the system that it is ready for more output. + * **IBZ** -- Input Busy -- the buffer enters this state when the user types the first character of a message. It stays in this state until either the user enters an end-of-message character or the buffer becomes full, at which point it enters the Read Ready state. + * **OBZ** -- Output Busy -- the buffer enters this state after receiving an output message from the system. It stays in this state while it is transmitting the data to the terminal. Once the buffer is empty, it enters either the Idle or Write Ready state, depending on whether it has seen an end-of-message character from the system or the buffer has become full. + * **AB** -- Abnormal -- this is a flag that has different meaning depending on the state of the buffer. For example, Input Busy Abnormal indicates that the user has entered a "?" in the message (used to indicate a control message to the MCP). Write Ready Abnormal indicates that either the terminal has just connected to the DTTU or the user has entered the WRU (who-are-you) character. It is generally reset the next time the buffer changes state. + * **INT** -- Interrupt Requested -- this is another flag that can be set for several states when the buffer requires attention from the system. It indicates than an Inquiry Request interrupt has been sent to the B5500. It will be reset once the B5500 performs an Interrogate operation to determine the status of the highest-priority buffer that initiated the interrupt. + * **FB** -- Full Buffer -- this flag indicates that the buffer has been filled on either input or output without sensing an end-of-character message. It will be reset once the buffer is emptied. + + +# Using the Datacom Terminal # + +The **Connect** button is used to initiate a connection between the terminal and the DTTU, similar to dialing a telephone number and establishing a modem connection. Simply click the button to connect. It will light. Click again to disconnect. After connecting, a system running the Datacom MCP should respond with an identification message within a few seconds: + +``` B-5500 01/00 - }}} - -The numbers following "`B-5500`" are the DTTU number and buffer number within that DTTU. Since the emulator currently supports only one terminal buffer, these numbers are constant. - -Because the B5500 had a character set consisting of only 64 printable characters, it had no native provision for the types of control characters (carriage-return, backspace, etc.) we are now accustomed to using with ASCII. Therefore, certain of the Model 33 printable characters were reserved for this purpose. On input, the following characters have special meaning: - - * `<` -- backspace. - * (left-arrow) -- end of message. The Model 33 Teletype had this character, but on modern keyboards this is represented by the underscore character (`_`). For the web-based emulator, we use both underscore and the tilde (`~`) to represent the left arrow. The ASCII DC1 character (also known as X-on or control-Q) will also end an input message. - * (control-B) -- also known as ASCII STX, this is the equivalent of sending a Break signal from the terminal. - * (control-E) -- also known as ASCII ENQ, this is the WRU (who-are-you) character. - * (control-L) -- also known as ASCII FF, this character would clear the input buffer after the user started entering a message, but leave the buffer in an Input Busy state. - * `!` -- disconnect -- entered on input, this character will disconnect the terminal from the DTTU. - -The emulated terminal supports two user-interface features that the DTTU Teletype adapter did not: - - # You can press the *Enter* key on your keyboard instead of the "`~`" to end a message. The terminal will print a "`~`". - # You can press the Backspace key to correct errors. The terminal will print a "`<`". - -See pages 3-15 and 3-16 in the [http://bitsavers.org/pdf/burroughs/1031986_B5500_Handbook_Aug70.pdf B5500 Handbook] for information on the character substitutions used by the B249/B487. - -You may move and resize the terminal window, and minimize it, but _do not close the window_. The system will warn you if you attempt to do this. Closing the window will render the terminal inoperable until the emulator is reinitialized with the *POWER ON* button. - -When you resize the terminal window, the "paper" area will change size accordingly. If the window becomes too narrow for the current output, the output lines will be clipped on the right, although the output itself is unaffected and will reappear if the window is made larger. Below a certain minimum (and essentially usable) window size, the window contents will no longer resize and will be clipped. - -The area representing the "paper" for the terminal has a 5000-line scrollback. You can copy portions of this text using ordinary click-and-drag functions of your pointing device. If you double-click anywhere in the text, however, the emulator will open a temporary window and copy the entire contents of the "paper" into it. From there, you can save the text in a file or copy/paste it into another application. When you have finished with the temporary window, simply close it. +``` + +The numbers following "`B-5500`" are the DTTU number and buffer number within that DTTU. Since the emulator currently supports only one terminal buffer, these numbers are constant. + +Because the B5500 had a character set consisting of only 64 printable characters, it had no native provision for the types of control characters (carriage-return, backspace, etc.) we are now accustomed to using with ASCII. Therefore, certain of the Model 33 printable characters were reserved for this purpose. On input, the following characters have special meaning: + + * `<` -- backspace. + * (left-arrow) -- end of message. The Model 33 Teletype had this character, but on modern keyboards this is represented by the underscore character (`_`). For the web-based emulator, we use both underscore and the tilde (`~`) to represent the left arrow. The ASCII DC1 character (also known as X-on or control-Q) will also end an input message. + * (control-B) -- also known as ASCII STX, this is the equivalent of sending a Break signal from the terminal. + * (control-E) -- also known as ASCII ENQ, this is the WRU (who-are-you) character. + * (control-L) -- also known as ASCII FF, this character would clear the input buffer after the user started entering a message, but leave the buffer in an Input Busy state. + * `!` -- disconnect -- entered on input, this character will disconnect the terminal from the DTTU. + +The emulated terminal supports two user-interface features that the DTTU Teletype adapter did not: + + 1. You can press the **Enter** key on your keyboard instead of the "`~`" to end a message. The terminal will print a "`~`". + 1. You can press the Backspace key to correct errors. The terminal will print a "`<`". + +See pages 3-15 and 3-16 in the [B5500 Handbook](http://bitsavers.org/pdf/burroughs/1031986_B5500_Handbook_Aug70.pdf) for information on the character substitutions used by the B249/B487. + +You may move and resize the terminal window, and minimize it, but _do not close the window_. The system will warn you if you attempt to do this. Closing the window will render the terminal inoperable until the emulator is reinitialized with the **POWER ON** button. + +When you resize the terminal window, the "paper" area will change size accordingly. If the window becomes too narrow for the current output, the output lines will be clipped on the right, although the output itself is unaffected and will reappear if the window is made larger. Below a certain minimum (and essentially usable) window size, the window contents will no longer resize and will be clipped. + +The area representing the "paper" for the terminal has a 5000-line scrollback. You can copy portions of this text using ordinary click-and-drag functions of your pointing device. If you double-click anywhere in the text, however, the emulator will open a temporary window and copy the entire contents of the "paper" into it. From there, you can save the text in a file or copy/paste it into another application. When you have finished with the temporary window, simply close it. \ No newline at end of file diff --git a/WebUIUsingTheCardPunch.md b/WebUIUsingTheCardPunch.md deleted file mode 100644 index e1a85e0..0000000 --- a/WebUIUsingTheCardPunch.md +++ /dev/null @@ -1,75 +0,0 @@ -# WebUI Using the Card Punch # - - - -The B5500 supported a couple of card punch models, with speeds ranging from 100 to 300 cards per minute. A B5500 system could have one card punch, identified as `CPA`. - - -# Background # - -The card punch interface we have developed for the web-based emulator is modeled after the 300 card-per-minute B304. This interface opens in a separate window when the **POWER ON** button is activated on the emulator console: - -> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-CardPunch.png](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-CardPunch.png) - -The B304 had additional buttons and lamps related to the mechanical issues of punching cards (e.g., feed and punch check indicators), but these controls are not relevant to operation under the emulator. - -The unit had three output stackers, primary (Stacker 1), auxiliary (Stacker 2) and error. The error stacker was used for cards detected to be in error after punching, cards left in the punch area too long and ejected automatically by the unit, and "runout" cards that were manually cleared from the feed path. The error stacker is not modeled by the emulator. - -Stackers 1 and 2 each have an output capacity of 850 cards. When either stacker becomes "full" (i.e., the number of cards reaches that limit), the unit goes into a not-ready state. - -The last few cards punched to each stacker are shown in text areas on the window for the card punch user interface. Each line of text represents one card. You can virtually remove "cards" from the "stacker" by selecting and copying lines of text from these areas and then pasting them into another application, such as a text editor, from which they can be saved to your local file system. This copy/paste technique is the only reasonably convenient way to capture data from the punch unit. - -Cards can be punched only in alpha mode, i.e., ordinary alphanumeric keypunch hole patterns. Binary punching is not supported by the B304. Lines are composed using the emulator's version of the B5500 64-character set: - -``` - 0 1 2 3 4 5 6 7 - 8 9 # @ ? : > { - + A B C D E F G - H I . [ & ( < ~ - | J K L M N O P - Q R $ * - 0 ; { - / S T U V W X - Y Z , % ! = } " -``` - -The B5500 used five special Algol characters that do not have ASCII equivalents. The emulator uses the following ASCII substitutions for them: - - * `~` for left-arrow - * `|` for the multiplication sign - * `{` for less-than-or-equal - * `}` for greater-than-or-equal - * `!` for not-equal - -As an option, the punch will render the special Algol characters using their appropriate Unicode glyphs. See below for instructions on how to enable and disable this feature. The five Unicode glyphs are: - - * U+00D7: small-cross (multiplication sign) - * U+2190: left-arrow - * U+2260: not-equal - * U+2264: less-than-or-equal - * U+2265: greater-than-or-equal - - -# Card Punch Control Panel # - -The user interface for the emulated card punch consists of the following controls and indicators: - - * **NOT READY** -- this white indicator illuminates when the punch is in a not-ready status. The punch becomes ready when the **START** button is clicked. It becomes not-ready when the **STOP** button is clicked or when either output stacker becomes full. - * **RUNOUT** -- This red button/indicator is used to "empty" the output stackers of the punch. This is a different use than the button had on the B304 punch unit. The button only responds to clicks when the punch is in a not-ready status. Clicking the button in a not-ready status toggles the state of the button. When this button is activated (the indicator is lit), clicking the **START** button will display a confirmation box asking if it is okay to empty both stackers of the punch. If you reply OK, the lines of text in both stackers will be erased and the punch will be placed in a ready status. If you want to capture the data for the cards from either of the stackers, you much select and copy their lines of text before emptying the stacker. - * **STOP** -- clicking this red button will stop the punch and place it in a not-ready status. The **NOT READY** button will illuminate. - * **START** -- clicking this green button will place the punch in a ready status. The **NOT READY** lamp will go out. The MCP should sense the status change within a second or two and begin (or resume) punching cards if any I/Os to the punch are currently queued. - -Below the buttons are text areas and progress bars for each stacker. These show the relative number of cards currently in each output stacker. Each time you empty the stackers, this bar resets all the way to the left. As cards are punched, the length of the bar will increase towards to right in proportion to the number of cards in the output stacker. - -Below each progress bar, the text areas show the last card images that were punched for each stacker. - -In the upper-right of the unit's window is a checkbox labeled **ALGOL GLYPHS**. When this box is checked, the five special Algol characters will be rendered using their Unicode glyphs. When the box is unchecked, those characters will be rendered using their ASCII substitutions, as described above. Toggling the checkbox will convert the characters in the stacker text areas between Unicode glyphs and the ASCII substitution glyphs. The initial setting for this checkbox is taken from the "Algol Glyphs" setting for the punch in the current system configuration. - -Below the checkbox are two annunciators, "`STACKER 1 FULL`" and "`STACKER 2 FULL`" that will illuminate when their respective stacker reaches its output-hopper limit. These annunciators will go off when the stackers are cleared. - -# Operating the Card Punch # - -As mentioned above, you can stop the punch at any time and make it not-ready by clicking the **STOP** button. Restart it by clicking the **START** button. Whenever the punch is stopped and in a not-ready status, you can copy/paste the lines of text from a stacker and/or clear both stackers using the **RUNOUT** button. - -When either stacker limit is reached, the punch will stop and go not-ready. You can determine which stacker is full by examining their respective stacker progress bars, but an annunciator in the upper-right of the unit's window will also illuminate to indicate the problem. Clicking the **START** button will allow one additional card to be punched, then the unit will go not-ready again. - -To resume continuous operation of the punch, you must clear the stackers. As described above, with the unit in a not-ready state, click the **RUNOUT** button, then the **START** button, and reply to the confirmation box. Once the stackers are empty, click the **START** button again to resume punching. \ No newline at end of file diff --git a/WebUIUsingTheCardPunch.wiki b/WebUIUsingTheCardPunch.wiki index 775e7d2..e1a85e0 100644 --- a/WebUIUsingTheCardPunch.wiki +++ b/WebUIUsingTheCardPunch.wiki @@ -1,30 +1,27 @@ -#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,B304 - -= WebUI Using the Card Punch = - - - -The B5500 supported a couple of card punch models, with speeds ranging from 100 to 300 cards per minute. A B5500 system could have one card punch, identified as `CPA`. - - -= Background = - -The card punch interface we have developed for the web-based emulator is modeled after the 300 card-per-minute B304. This interface opens in a separate window when the *POWER ON* button is activated on the emulator console: - - https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-CardPunch.png - -The B304 had additional buttons and lamps related to the mechanical issues of punching cards (e.g., feed and punch check indicators), but these controls are not relevant to operation under the emulator. - -The unit had three output stackers, primary (Stacker 1), auxiliary (Stacker 2) and error. The error stacker was used for cards detected to be in error after punching, cards left in the punch area too long and ejected automatically by the unit, and "runout" cards that were manually cleared from the feed path. The error stacker is not modeled by the emulator. - -Stackers 1 and 2 each have an output capacity of 850 cards. When either stacker becomes "full" (i.e., the number of cards reaches that limit), the unit goes into a not-ready state. - -The last few cards punched to each stacker are shown in text areas on the window for the card punch user interface. Each line of text represents one card. You can virtually remove "cards" from the "stacker" by selecting and copying lines of text from these areas and then pasting them into another application, such as a text editor, from which they can be saved to your local file system. This copy/paste technique is the only reasonably convenient way to capture data from the punch unit. - -Cards can be punched only in alpha mode, i.e., ordinary alphanumeric keypunch hole patterns. Binary punching is not supported by the B304. Lines are composed using the emulator's version of the B5500 64-character set: - - {{{ +# WebUI Using the Card Punch # + + + +The B5500 supported a couple of card punch models, with speeds ranging from 100 to 300 cards per minute. A B5500 system could have one card punch, identified as `CPA`. + + +# Background # + +The card punch interface we have developed for the web-based emulator is modeled after the 300 card-per-minute B304. This interface opens in a separate window when the **POWER ON** button is activated on the emulator console: + +> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-CardPunch.png](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-CardPunch.png) + +The B304 had additional buttons and lamps related to the mechanical issues of punching cards (e.g., feed and punch check indicators), but these controls are not relevant to operation under the emulator. + +The unit had three output stackers, primary (Stacker 1), auxiliary (Stacker 2) and error. The error stacker was used for cards detected to be in error after punching, cards left in the punch area too long and ejected automatically by the unit, and "runout" cards that were manually cleared from the feed path. The error stacker is not modeled by the emulator. + +Stackers 1 and 2 each have an output capacity of 850 cards. When either stacker becomes "full" (i.e., the number of cards reaches that limit), the unit goes into a not-ready state. + +The last few cards punched to each stacker are shown in text areas on the window for the card punch user interface. Each line of text represents one card. You can virtually remove "cards" from the "stacker" by selecting and copying lines of text from these areas and then pasting them into another application, such as a text editor, from which they can be saved to your local file system. This copy/paste technique is the only reasonably convenient way to capture data from the punch unit. + +Cards can be punched only in alpha mode, i.e., ordinary alphanumeric keypunch hole patterns. Binary punching is not supported by the B304. Lines are composed using the emulator's version of the B5500 64-character set: + +``` 0 1 2 3 4 5 6 7 8 9 # @ ? : > { + A B C D E F G @@ -33,46 +30,46 @@ Cards can be punched only in alpha mode, i.e., ordinary alphanumeric keypunch ho Q R $ * - 0 ; { / S T U V W X Y Z , % ! = } " - }}} - -The B5500 used five special Algol characters that do not have ASCII equivalents. The emulator uses the following ASCII substitutions for them: - - * `~` for left-arrow - * `|` for the multiplication sign - * `{` for less-than-or-equal - * `}` for greater-than-or-equal - * `!` for not-equal - -As an option, the punch will render the special Algol characters using their appropriate Unicode glyphs. See below for instructions on how to enable and disable this feature. The five Unicode glyphs are: - - * U+00D7: small-cross (multiplication sign) - * U+2190: left-arrow - * U+2260: not-equal - * U+2264: less-than-or-equal - * U+2265: greater-than-or-equal - - -= Card Punch Control Panel = - -The user interface for the emulated card punch consists of the following controls and indicators: - - * *NOT READY* -- this white indicator illuminates when the punch is in a not-ready status. The punch becomes ready when the *START* button is clicked. It becomes not-ready when the *STOP* button is clicked or when either output stacker becomes full. - * *RUNOUT* -- This red button/indicator is used to "empty" the output stackers of the punch. This is a different use than the button had on the B304 punch unit. The button only responds to clicks when the punch is in a not-ready status. Clicking the button in a not-ready status toggles the state of the button. When this button is activated (the indicator is lit), clicking the *START* button will display a confirmation box asking if it is okay to empty both stackers of the punch. If you reply OK, the lines of text in both stackers will be erased and the punch will be placed in a ready status. If you want to capture the data for the cards from either of the stackers, you much select and copy their lines of text before emptying the stacker. - * *STOP* -- clicking this red button will stop the punch and place it in a not-ready status. The *NOT READY* button will illuminate. - * *START* -- clicking this green button will place the punch in a ready status. The *NOT READY* lamp will go out. The MCP should sense the status change within a second or two and begin (or resume) punching cards if any I/Os to the punch are currently queued. - -Below the buttons are text areas and progress bars for each stacker. These show the relative number of cards currently in each output stacker. Each time you empty the stackers, this bar resets all the way to the left. As cards are punched, the length of the bar will increase towards to right in proportion to the number of cards in the output stacker. - -Below each progress bar, the text areas show the last card images that were punched for each stacker. - -In the upper-right of the unit's window is a checkbox labeled *ALGOL GLYPHS*. When this box is checked, the five special Algol characters will be rendered using their Unicode glyphs. When the box is unchecked, those characters will be rendered using their ASCII substitutions, as described above. Toggling the checkbox will convert the characters in the stacker text areas between Unicode glyphs and the ASCII substitution glyphs. The initial setting for this checkbox is taken from the "Algol Glyphs" setting for the punch in the current system configuration. - -Below the checkbox are two annunciators, "`STACKER 1 FULL`" and "`STACKER 2 FULL`" that will illuminate when their respective stacker reaches its output-hopper limit. These annunciators will go off when the stackers are cleared. - -= Operating the Card Punch = - -As mentioned above, you can stop the punch at any time and make it not-ready by clicking the *STOP* button. Restart it by clicking the *START* button. Whenever the punch is stopped and in a not-ready status, you can copy/paste the lines of text from a stacker and/or clear both stackers using the *RUNOUT* button. - -When either stacker limit is reached, the punch will stop and go not-ready. You can determine which stacker is full by examining their respective stacker progress bars, but an annunciator in the upper-right of the unit's window will also illuminate to indicate the problem. Clicking the *START* button will allow one additional card to be punched, then the unit will go not-ready again. - -To resume continuous operation of the punch, you must clear the stackers. As described above, with the unit in a not-ready state, click the *RUNOUT* button, then the *START* button, and reply to the confirmation box. Once the stackers are empty, click the *START* button again to resume punching. \ No newline at end of file +``` + +The B5500 used five special Algol characters that do not have ASCII equivalents. The emulator uses the following ASCII substitutions for them: + + * `~` for left-arrow + * `|` for the multiplication sign + * `{` for less-than-or-equal + * `}` for greater-than-or-equal + * `!` for not-equal + +As an option, the punch will render the special Algol characters using their appropriate Unicode glyphs. See below for instructions on how to enable and disable this feature. The five Unicode glyphs are: + + * U+00D7: small-cross (multiplication sign) + * U+2190: left-arrow + * U+2260: not-equal + * U+2264: less-than-or-equal + * U+2265: greater-than-or-equal + + +# Card Punch Control Panel # + +The user interface for the emulated card punch consists of the following controls and indicators: + + * **NOT READY** -- this white indicator illuminates when the punch is in a not-ready status. The punch becomes ready when the **START** button is clicked. It becomes not-ready when the **STOP** button is clicked or when either output stacker becomes full. + * **RUNOUT** -- This red button/indicator is used to "empty" the output stackers of the punch. This is a different use than the button had on the B304 punch unit. The button only responds to clicks when the punch is in a not-ready status. Clicking the button in a not-ready status toggles the state of the button. When this button is activated (the indicator is lit), clicking the **START** button will display a confirmation box asking if it is okay to empty both stackers of the punch. If you reply OK, the lines of text in both stackers will be erased and the punch will be placed in a ready status. If you want to capture the data for the cards from either of the stackers, you much select and copy their lines of text before emptying the stacker. + * **STOP** -- clicking this red button will stop the punch and place it in a not-ready status. The **NOT READY** button will illuminate. + * **START** -- clicking this green button will place the punch in a ready status. The **NOT READY** lamp will go out. The MCP should sense the status change within a second or two and begin (or resume) punching cards if any I/Os to the punch are currently queued. + +Below the buttons are text areas and progress bars for each stacker. These show the relative number of cards currently in each output stacker. Each time you empty the stackers, this bar resets all the way to the left. As cards are punched, the length of the bar will increase towards to right in proportion to the number of cards in the output stacker. + +Below each progress bar, the text areas show the last card images that were punched for each stacker. + +In the upper-right of the unit's window is a checkbox labeled **ALGOL GLYPHS**. When this box is checked, the five special Algol characters will be rendered using their Unicode glyphs. When the box is unchecked, those characters will be rendered using their ASCII substitutions, as described above. Toggling the checkbox will convert the characters in the stacker text areas between Unicode glyphs and the ASCII substitution glyphs. The initial setting for this checkbox is taken from the "Algol Glyphs" setting for the punch in the current system configuration. + +Below the checkbox are two annunciators, "`STACKER 1 FULL`" and "`STACKER 2 FULL`" that will illuminate when their respective stacker reaches its output-hopper limit. These annunciators will go off when the stackers are cleared. + +# Operating the Card Punch # + +As mentioned above, you can stop the punch at any time and make it not-ready by clicking the **STOP** button. Restart it by clicking the **START** button. Whenever the punch is stopped and in a not-ready status, you can copy/paste the lines of text from a stacker and/or clear both stackers using the **RUNOUT** button. + +When either stacker limit is reached, the punch will stop and go not-ready. You can determine which stacker is full by examining their respective stacker progress bars, but an annunciator in the upper-right of the unit's window will also illuminate to indicate the problem. Clicking the **START** button will allow one additional card to be punched, then the unit will go not-ready again. + +To resume continuous operation of the punch, you must clear the stackers. As described above, with the unit in a not-ready state, click the **RUNOUT** button, then the **START** button, and reply to the confirmation box. Once the stackers are empty, click the **START** button again to resume punching. \ No newline at end of file diff --git a/WebUIUsingTheCardReader.md b/WebUIUsingTheCardReader.md deleted file mode 100644 index 5a4599e..0000000 --- a/WebUIUsingTheCardReader.md +++ /dev/null @@ -1,101 +0,0 @@ -# WebUI Using the Card Reader # - - - -The B5500 supported several card reader models, with speeds ranging from 200 to 1400 cards per minute. The higher-speed models had a belt-driven feeding mechanism that was similar to the Burroughs check-sorting equipment, and was probably derived from it. - -A B5500 system could have one or two card readers, identified as `CRA` and `CRB`. - -Here is a view of either a B124 or B129 reader (they were physically identical, differing only in speed) at Stanford University in California, probably during the mid-1960s: - -> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-at-Stanford.jpg](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-at-Stanford.jpg) - - -# Background # - -The card reader interface we have developed for the web-based emulator is modeled after the 1400 card-per-minute B129. This interface opens in a separate window when the **POWER ON** button is activated on the emulator console: - -> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-CardReader.png](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-CardReader.png) - -The B129 had additional buttons and lamps related to the mechanical issues of reading cards (e.g., feed and read check indicators), but these controls are not relevant to operation under the emulator. - -Card "decks" used with the emulator are ordinary ASCII text files, which can be prepared with any text editor. The files can have any file-name extension; we recommend using "`.card`". Lines of text in the file may be delimited with a carriage return (ASCII hex 0D), a line feed (ASCII hex 0A), or a carriage-return/line-feed pair. - -When reading in alpha mode, each line of text represents one 80-column card image. Lines of text shorter than 80 characters will be padded with spaces internally on the right to a length of 80; lines longer than 80 characters will be truncated internally on the right to a length of 80. - -When reading in binary mode, each line of text should have 160 characters, arranged in pairs. The first character of each pair represents the binary value of the top six rows in a column of the card; the second character represents the binary value of the lower six rows in that column. Each ASCII character from the binary card image is translated to its equivalent 6-bit B5500 internal code, e.g., "`A`" to 21 octal, "`$`" to 52 octal. Lines shorter than 160 characters will be padded internally on the right with zeroes to a length of 160; lines longer than 160 characters will be truncated internally on the right to a length of 160. - -Binary cards are generally used only for small bootstrap-loader programs; they are not normally read by user programs. - -In either mode, lines of text should be composed using the emulator's version of the B5500 64-character set: - -``` - 0 1 2 3 4 5 6 7 - 8 9 # @ ? : > { - + A B C D E F G - H I . [ & ( < ~ - | J K L M N O P - Q R $ * - 0 ; { - / S T U V W X - Y Z , % ! = } " -``` - -The B5500 used five special Algol characters that do not have ASCII equivalents. The emulator uses the following ASCII substitutions for them: - - * `~` for left-arrow - * `|` for the multiplication sign - * `{` for less-than-or-equal - * `}` for greater-than-or-equal - * `!` for not-equal - -The card reader interface will translate lower-case ASCII letters to upper case. The underscore ("`_`") will be accepted as a substitute for `~` as the left-arrow. The reader will also accept five Unicode characters for the special Algol characters: - - * U+00D7: small-cross (multiplication sign) - * U+2190: left-arrow - * U+2260: not-equal - * U+2264: less-than-or-equal - * U+2265: greater-than-or-equal - -The card reader will consider all other ASCII or Unicode characters to be "invalid punches" in a card. A "`?`" in the first position in a line of text will be considered to be an invalid punch (for the purpose of identifying the line to the MCP as a control card) but will be allowed as a valid character in any other position. - -Your card-deck text files should normally have the necessary control cards on the front (with a "`?`" or other invalid character in the first column) and a `?END` control card at the end, but this is not a requirement of the emulated reader. A single text file can represent a complete deck, multiple decks, or a partial deck. While the physical card readers had an input hopper capacity of about 2400 cards, there is no practical limit to the size of a text file that can be loaded into the emulated reader. - - -# Card Reader Control Panel # - -The user interface for the emulated card reader consists of the following controls and indicators: - - * **NOT READY** -- this white indicator illuminates when the reader is in a not-ready status. The reader becomes ready when the **START** button is clicked and the "input hopper" is not empty. It becomes not-ready when the **STOP** button is clicked or after the last card is read from the input hopper. - * **EOF** -- This red button/indicator is used to signal end-of-file to the host system. When this button is activated (the indicator is lit), clicking the **START** button with an empty input hopper will set an EOF indication in the B5500 result descriptor. The MCP ignores this indication, however, so the button is non-functional with the B5500. - * **STOP** -- clicking this red button will stop the reader and place it in a not-ready status. The **NOT READY** button will illuminate. - * **START** -- clicking this green button when the input hopper is non-empty will place the reader in a ready status. The **NOT READY** lamp will go out. The MCP should sense the status change within a second or two and begin (or resume) reading cards. - -Below the buttons is a file-picker control. Clicking its **Browse...** or **Choose File** button will open a dialog box from which you can select files to load as card decks into the reader. This control is enabled only when the reader is in a not-ready status. You can select multiple files at a time, which will cause all of the files selected to be appended to the input hopper. The order in which they are appended depends on your browser and underlying operating system, however. - -You can append additional files to the reader's input hopper at any time. If the system is currently reading cards, simply click **STOP** to make the reader not-ready, select the files you want to load, and then click **START** to resume reading. - -Below the file-picker control is a progress bar. This shows the relative size of the stack of cards remaining in the reader's input hopper. Each time you load one or more files into the reader, this bar advances to its full width. As cards are read, the length of the bar will decrease towards the left in proportion to the number of cards left to be read. See below on how the progress bar can be used to "empty the hopper." - -Below the progress bar, the reader shows the last two card images that were read. The most recently-read card image is on the bottom. This can be useful if the MCP stops the reader due to a control-card error or an invalid character detected in a card. - - -# Operating the Card Reader # - -The basic technique with the card reader is simple -- use the file-picker control to load one or more files into the reader, then click the **START** button to make the reader ready. The MCP should recognize the ready status and begin reading cards automatically. The reader will become not-ready after the last card has been read. - -As mentioned above, you can stop the reader at any time and make it not-ready by clicking the **STOP** button. Restart it by clicking the **START** button. Whenever the reader is stopped and in a not-ready status, you can load additional files into it. - -You can also "empty the hopper" while the card reader is in a not-ready status. To do this, click the progress bar. An alert box will pop up asking you to confirm that you want to empty the hopper. - -Note that it is not possible to remove just one of your "decks" from the reader's input hopper. Once files are loaded into the reader, they lose their individual identity as files and become just a part of the stack of cards to be read. When you empty the hopper, everything goes, regardless of the file or files from which it originally came. - -When the MCP encounters a control card with an error, or a card with an invalid character in other than the first column, it will stop reading cards and display the card in error on the SPO. The reader will remain in a ready status. When this happens, you generally have two choices: - - 1. Stop the reader, empty the input hopper, correct the file with the card in error off-line, then reload the corrected file into the reader. - 1. On the SPO, enter "`CL CR`_x_" or "`RY CR`_x_" (where "_x_" indicates the reader, `A` or `B`) to clear the MCP's error status. The MCP will resume reading cards, but will not process them until after the next `?END` card is encountered. This is a convenient way to bypass just the deck that has an error. - -The reader shows the last two cards that were read in the bottom panel of its window. This should help you locate the card in error so that you can correct it. - -On some browsers, attempting to load the same file twice in succession into the reader may not work. The reason is that the emulator relies on the HTML file-picker control's "onChange" event to detect when you have selected a file. If you reselect the same file you just previously selected, the browser may not consider the value of the file-picker control to have changed, and hence not fire the event. - -The browser resets the file-picker control whenever the reader goes not ready, either when the input hopper becomes empty or you click the **STOP** button. Thus, to load the same file multiple times in succession into the reader, simply click **STOP** between each file selection. \ No newline at end of file diff --git a/WebUIUsingTheCardReader.wiki b/WebUIUsingTheCardReader.wiki index 8e9aee1..5a4599e 100644 --- a/WebUIUsingTheCardReader.wiki +++ b/WebUIUsingTheCardReader.wiki @@ -1,38 +1,35 @@ -#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,B129 - -= WebUI Using the Card Reader = - - - -The B5500 supported several card reader models, with speeds ranging from 200 to 1400 cards per minute. The higher-speed models had a belt-driven feeding mechanism that was similar to the Burroughs check-sorting equipment, and was probably derived from it. - -A B5500 system could have one or two card readers, identified as `CRA` and `CRB`. - -Here is a view of either a B124 or B129 reader (they were physically identical, differing only in speed) at Stanford University in California, probably during the mid-1960s: - - https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-at-Stanford.jpg - - -= Background = - -The card reader interface we have developed for the web-based emulator is modeled after the 1400 card-per-minute B129. This interface opens in a separate window when the *POWER ON* button is activated on the emulator console: - - https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-CardReader.png - -The B129 had additional buttons and lamps related to the mechanical issues of reading cards (e.g., feed and read check indicators), but these controls are not relevant to operation under the emulator. - -Card "decks" used with the emulator are ordinary ASCII text files, which can be prepared with any text editor. The files can have any file-name extension; we recommend using "`.card`". Lines of text in the file may be delimited with a carriage return (ASCII hex 0D), a line feed (ASCII hex 0A), or a carriage-return/line-feed pair. - -When reading in alpha mode, each line of text represents one 80-column card image. Lines of text shorter than 80 characters will be padded with spaces internally on the right to a length of 80; lines longer than 80 characters will be truncated internally on the right to a length of 80. - -When reading in binary mode, each line of text should have 160 characters, arranged in pairs. The first character of each pair represents the binary value of the top six rows in a column of the card; the second character represents the binary value of the lower six rows in that column. Each ASCII character from the binary card image is translated to its equivalent 6-bit B5500 internal code, e.g., "`A`" to 21 octal, "`$`" to 52 octal. Lines shorter than 160 characters will be padded internally on the right with zeroes to a length of 160; lines longer than 160 characters will be truncated internally on the right to a length of 160. - -Binary cards are generally used only for small bootstrap-loader programs; they are not normally read by user programs. - -In either mode, lines of text should be composed using the emulator's version of the B5500 64-character set: - - {{{ +# WebUI Using the Card Reader # + + + +The B5500 supported several card reader models, with speeds ranging from 200 to 1400 cards per minute. The higher-speed models had a belt-driven feeding mechanism that was similar to the Burroughs check-sorting equipment, and was probably derived from it. + +A B5500 system could have one or two card readers, identified as `CRA` and `CRB`. + +Here is a view of either a B124 or B129 reader (they were physically identical, differing only in speed) at Stanford University in California, probably during the mid-1960s: + +> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-at-Stanford.jpg](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-at-Stanford.jpg) + + +# Background # + +The card reader interface we have developed for the web-based emulator is modeled after the 1400 card-per-minute B129. This interface opens in a separate window when the **POWER ON** button is activated on the emulator console: + +> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-CardReader.png](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-CardReader.png) + +The B129 had additional buttons and lamps related to the mechanical issues of reading cards (e.g., feed and read check indicators), but these controls are not relevant to operation under the emulator. + +Card "decks" used with the emulator are ordinary ASCII text files, which can be prepared with any text editor. The files can have any file-name extension; we recommend using "`.card`". Lines of text in the file may be delimited with a carriage return (ASCII hex 0D), a line feed (ASCII hex 0A), or a carriage-return/line-feed pair. + +When reading in alpha mode, each line of text represents one 80-column card image. Lines of text shorter than 80 characters will be padded with spaces internally on the right to a length of 80; lines longer than 80 characters will be truncated internally on the right to a length of 80. + +When reading in binary mode, each line of text should have 160 characters, arranged in pairs. The first character of each pair represents the binary value of the top six rows in a column of the card; the second character represents the binary value of the lower six rows in that column. Each ASCII character from the binary card image is translated to its equivalent 6-bit B5500 internal code, e.g., "`A`" to 21 octal, "`$`" to 52 octal. Lines shorter than 160 characters will be padded internally on the right with zeroes to a length of 160; lines longer than 160 characters will be truncated internally on the right to a length of 160. + +Binary cards are generally used only for small bootstrap-loader programs; they are not normally read by user programs. + +In either mode, lines of text should be composed using the emulator's version of the B5500 64-character set: + +``` 0 1 2 3 4 5 6 7 8 9 # @ ? : > { + A B C D E F G @@ -41,64 +38,64 @@ In either mode, lines of text should be composed using the emulator's version of Q R $ * - 0 ; { / S T U V W X Y Z , % ! = } " - }}} - -The B5500 used five special Algol characters that do not have ASCII equivalents. The emulator uses the following ASCII substitutions for them: - - * `~` for left-arrow - * `|` for the multiplication sign - * `{` for less-than-or-equal - * `}` for greater-than-or-equal - * `!` for not-equal - -The card reader interface will translate lower-case ASCII letters to upper case. The underscore ("`_`") will be accepted as a substitute for `~` as the left-arrow. The reader will also accept five Unicode characters for the special Algol characters: - - * U+00D7: small-cross (multiplication sign) - * U+2190: left-arrow - * U+2260: not-equal - * U+2264: less-than-or-equal - * U+2265: greater-than-or-equal - -The card reader will consider all other ASCII or Unicode characters to be "invalid punches" in a card. A "`?`" in the first position in a line of text will be considered to be an invalid punch (for the purpose of identifying the line to the MCP as a control card) but will be allowed as a valid character in any other position. - -Your card-deck text files should normally have the necessary control cards on the front (with a "`?`" or other invalid character in the first column) and a `?END` control card at the end, but this is not a requirement of the emulated reader. A single text file can represent a complete deck, multiple decks, or a partial deck. While the physical card readers had an input hopper capacity of about 2400 cards, there is no practical limit to the size of a text file that can be loaded into the emulated reader. - - -= Card Reader Control Panel = - -The user interface for the emulated card reader consists of the following controls and indicators: - - * *NOT READY* -- this white indicator illuminates when the reader is in a not-ready status. The reader becomes ready when the *START* button is clicked and the "input hopper" is not empty. It becomes not-ready when the *STOP* button is clicked or after the last card is read from the input hopper. - * *EOF* -- This red button/indicator is used to signal end-of-file to the host system. When this button is activated (the indicator is lit), clicking the *START* button with an empty input hopper will set an EOF indication in the B5500 result descriptor. The MCP ignores this indication, however, so the button is non-functional with the B5500. - * *STOP* -- clicking this red button will stop the reader and place it in a not-ready status. The *NOT READY* button will illuminate. - * *START* -- clicking this green button when the input hopper is non-empty will place the reader in a ready status. The *NOT READY* lamp will go out. The MCP should sense the status change within a second or two and begin (or resume) reading cards. - -Below the buttons is a file-picker control. Clicking its *Browse...* or *Choose File* button will open a dialog box from which you can select files to load as card decks into the reader. This control is enabled only when the reader is in a not-ready status. You can select multiple files at a time, which will cause all of the files selected to be appended to the input hopper. The order in which they are appended depends on your browser and underlying operating system, however. - -You can append additional files to the reader's input hopper at any time. If the system is currently reading cards, simply click *STOP* to make the reader not-ready, select the files you want to load, and then click *START* to resume reading. - -Below the file-picker control is a progress bar. This shows the relative size of the stack of cards remaining in the reader's input hopper. Each time you load one or more files into the reader, this bar advances to its full width. As cards are read, the length of the bar will decrease towards the left in proportion to the number of cards left to be read. See below on how the progress bar can be used to "empty the hopper." - -Below the progress bar, the reader shows the last two card images that were read. The most recently-read card image is on the bottom. This can be useful if the MCP stops the reader due to a control-card error or an invalid character detected in a card. - - -= Operating the Card Reader = - -The basic technique with the card reader is simple -- use the file-picker control to load one or more files into the reader, then click the *START* button to make the reader ready. The MCP should recognize the ready status and begin reading cards automatically. The reader will become not-ready after the last card has been read. - -As mentioned above, you can stop the reader at any time and make it not-ready by clicking the *STOP* button. Restart it by clicking the *START* button. Whenever the reader is stopped and in a not-ready status, you can load additional files into it. - -You can also "empty the hopper" while the card reader is in a not-ready status. To do this, click the progress bar. An alert box will pop up asking you to confirm that you want to empty the hopper. - -Note that it is not possible to remove just one of your "decks" from the reader's input hopper. Once files are loaded into the reader, they lose their individual identity as files and become just a part of the stack of cards to be read. When you empty the hopper, everything goes, regardless of the file or files from which it originally came. - -When the MCP encounters a control card with an error, or a card with an invalid character in other than the first column, it will stop reading cards and display the card in error on the SPO. The reader will remain in a ready status. When this happens, you generally have two choices: - - # Stop the reader, empty the input hopper, correct the file with the card in error off-line, then reload the corrected file into the reader. - # On the SPO, enter "`CL CR`_x_" or "`RY CR`_x_" (where "_x_" indicates the reader, `A` or `B`) to clear the MCP's error status. The MCP will resume reading cards, but will not process them until after the next `?END` card is encountered. This is a convenient way to bypass just the deck that has an error. - -The reader shows the last two cards that were read in the bottom panel of its window. This should help you locate the card in error so that you can correct it. - -On some browsers, attempting to load the same file twice in succession into the reader may not work. The reason is that the emulator relies on the HTML file-picker control's "onChange" event to detect when you have selected a file. If you reselect the same file you just previously selected, the browser may not consider the value of the file-picker control to have changed, and hence not fire the event. - -The browser resets the file-picker control whenever the reader goes not ready, either when the input hopper becomes empty or you click the *STOP* button. Thus, to load the same file multiple times in succession into the reader, simply click *STOP* between each file selection. \ No newline at end of file +``` + +The B5500 used five special Algol characters that do not have ASCII equivalents. The emulator uses the following ASCII substitutions for them: + + * `~` for left-arrow + * `|` for the multiplication sign + * `{` for less-than-or-equal + * `}` for greater-than-or-equal + * `!` for not-equal + +The card reader interface will translate lower-case ASCII letters to upper case. The underscore ("`_`") will be accepted as a substitute for `~` as the left-arrow. The reader will also accept five Unicode characters for the special Algol characters: + + * U+00D7: small-cross (multiplication sign) + * U+2190: left-arrow + * U+2260: not-equal + * U+2264: less-than-or-equal + * U+2265: greater-than-or-equal + +The card reader will consider all other ASCII or Unicode characters to be "invalid punches" in a card. A "`?`" in the first position in a line of text will be considered to be an invalid punch (for the purpose of identifying the line to the MCP as a control card) but will be allowed as a valid character in any other position. + +Your card-deck text files should normally have the necessary control cards on the front (with a "`?`" or other invalid character in the first column) and a `?END` control card at the end, but this is not a requirement of the emulated reader. A single text file can represent a complete deck, multiple decks, or a partial deck. While the physical card readers had an input hopper capacity of about 2400 cards, there is no practical limit to the size of a text file that can be loaded into the emulated reader. + + +# Card Reader Control Panel # + +The user interface for the emulated card reader consists of the following controls and indicators: + + * **NOT READY** -- this white indicator illuminates when the reader is in a not-ready status. The reader becomes ready when the **START** button is clicked and the "input hopper" is not empty. It becomes not-ready when the **STOP** button is clicked or after the last card is read from the input hopper. + * **EOF** -- This red button/indicator is used to signal end-of-file to the host system. When this button is activated (the indicator is lit), clicking the **START** button with an empty input hopper will set an EOF indication in the B5500 result descriptor. The MCP ignores this indication, however, so the button is non-functional with the B5500. + * **STOP** -- clicking this red button will stop the reader and place it in a not-ready status. The **NOT READY** button will illuminate. + * **START** -- clicking this green button when the input hopper is non-empty will place the reader in a ready status. The **NOT READY** lamp will go out. The MCP should sense the status change within a second or two and begin (or resume) reading cards. + +Below the buttons is a file-picker control. Clicking its **Browse...** or **Choose File** button will open a dialog box from which you can select files to load as card decks into the reader. This control is enabled only when the reader is in a not-ready status. You can select multiple files at a time, which will cause all of the files selected to be appended to the input hopper. The order in which they are appended depends on your browser and underlying operating system, however. + +You can append additional files to the reader's input hopper at any time. If the system is currently reading cards, simply click **STOP** to make the reader not-ready, select the files you want to load, and then click **START** to resume reading. + +Below the file-picker control is a progress bar. This shows the relative size of the stack of cards remaining in the reader's input hopper. Each time you load one or more files into the reader, this bar advances to its full width. As cards are read, the length of the bar will decrease towards the left in proportion to the number of cards left to be read. See below on how the progress bar can be used to "empty the hopper." + +Below the progress bar, the reader shows the last two card images that were read. The most recently-read card image is on the bottom. This can be useful if the MCP stops the reader due to a control-card error or an invalid character detected in a card. + + +# Operating the Card Reader # + +The basic technique with the card reader is simple -- use the file-picker control to load one or more files into the reader, then click the **START** button to make the reader ready. The MCP should recognize the ready status and begin reading cards automatically. The reader will become not-ready after the last card has been read. + +As mentioned above, you can stop the reader at any time and make it not-ready by clicking the **STOP** button. Restart it by clicking the **START** button. Whenever the reader is stopped and in a not-ready status, you can load additional files into it. + +You can also "empty the hopper" while the card reader is in a not-ready status. To do this, click the progress bar. An alert box will pop up asking you to confirm that you want to empty the hopper. + +Note that it is not possible to remove just one of your "decks" from the reader's input hopper. Once files are loaded into the reader, they lose their individual identity as files and become just a part of the stack of cards to be read. When you empty the hopper, everything goes, regardless of the file or files from which it originally came. + +When the MCP encounters a control card with an error, or a card with an invalid character in other than the first column, it will stop reading cards and display the card in error on the SPO. The reader will remain in a ready status. When this happens, you generally have two choices: + + 1. Stop the reader, empty the input hopper, correct the file with the card in error off-line, then reload the corrected file into the reader. + 1. On the SPO, enter "`CL CR`_x_" or "`RY CR`_x_" (where "_x_" indicates the reader, `A` or `B`) to clear the MCP's error status. The MCP will resume reading cards, but will not process them until after the next `?END` card is encountered. This is a convenient way to bypass just the deck that has an error. + +The reader shows the last two cards that were read in the bottom panel of its window. This should help you locate the card in error so that you can correct it. + +On some browsers, attempting to load the same file twice in succession into the reader may not work. The reason is that the emulator relies on the HTML file-picker control's "onChange" event to detect when you have selected a file. If you reselect the same file you just previously selected, the browser may not consider the value of the file-picker control to have changed, and hence not fire the event. + +The browser resets the file-picker control whenever the reader goes not ready, either when the input hopper becomes empty or you click the **STOP** button. Thus, to load the same file multiple times in succession into the reader, simply click **STOP** between each file selection. \ No newline at end of file diff --git a/WebUIUsingTheConsole.md b/WebUIUsingTheConsole.md deleted file mode 100644 index ca88010..0000000 --- a/WebUIUsingTheConsole.md +++ /dev/null @@ -1,173 +0,0 @@ -# WebUI Using the B5500 Console # - - -Compared to virtually every other computer system of the 1960s, the Burroughs B5500 had an extraordinarily minimalist operator console -- just five buttons and six lights, plus a few more on the Teletype SPO (supervisory printer/keyboard). The best image we have of the Console is from the 1968 Burroughs Corporation annual report: - -> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Console-Image.png](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Console-Image.png) - -That image shows the B5500 at the City of Montreal, Canada. In the foreground is the L-shaped console desk, with the Teletype Model 33 SPO. You can see part of a card reader behind the SPO and magnetic tape drives in the background. - -We have tried to be faithful to the design of the Console in our representation of it for the web-based user interface: - -> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Console.png](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 central control for the web-based emulator. To display the Console, navigate to the emulator's home page, `B5500Console.html` 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 - -The home page will look similar to this: - -> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Home-Page.png](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Home-Page.png) - -On the home page, click one of the "Start" buttons. This will open a small window for the Console. - - * The **Start & Power On** button will open the Console window and automatically power up the emulator, as if you had clicked the Console's green **POWER ON** button. - * The **Start - Powered Off** button will simply open the Console window without powering up the emulator. You may wish to use this button if you want to make configuration changes before running the emulator, as such changes can be made only when the emulator is in a powered-off state. - -Once the Console window is open, you may move it around on your screen, or even minimize it. Closing the Console window will implicitly halt the system and power down the emulator. The emulator will display a warning dialog if you attempt to close the Console window while the emulator is powered up. - - -# Layout of the Console # - -The Console is used to power the system on and off, initiate a load (boot) of the operating system, and halt the system. The A/B Normal/Control lights give a basic indication of system activity. All other operations are handled through the SPO. - -From left to right, the controls on the Console are: - - * **HALT** button -- clicking this red pushbutton halts the system. This initiates an immediate termination of all processing. The only way to continue after halting is to click **LOAD** and reboot the system. The button illuminates when power is on and the system is halted. - * **NOT READY** light -- this white indicator illuminates when one of the components of the system that did not have its own ready/not ready indicator is in a not-ready or off-line state. It applies to processors, I/O units, memory modules, and the first drum (if present). The emulator handles this in a similar manner. It will turn on the light if, at the time the system is powered on, any of the following conditions are true, as they will prevent the system either from booting or from supporting the MCP: - * No Processor is enabled in the current configuration. - * One of the enabled processors is not designated as P1, the control processor. - * No I/O Control Units (channels) are enabled. - * Memory module 0 (having addressees 00000-07777 octal) is not enabled. - * The SPO device is not enabled in the configuration. - * The DKA device (Disk File Control A) is not enabled in the configuration. - * **MEMORY CHECK** -- this red light illuminates when a memory parity error is detected by either processor. The emulator does not presently generate memory parity errors, however. Clicking this light while power is on will produce a full dump of processor state and memory in a separate browser window. This dump can be generated at any time, even while the system is running. - * **LOAD** -- clicking this black pushbutton clears all registers in the system and initiates a load operation. When loading from disk, 63 sectors (1890 words) are read into memory starting at location 20 octal. When loading from cards, one binary card is read starting at location 20 octal. If the read is successful, Processor 1 then starts executing at that address. - * **CARD LOAD SELECT** -- this yellow button/light controls whether a load operation reads from the first disk1 or the first card reader. In its normal position, load is from disk. When pressed, the physical button latched inward and illuminated, enabling load from cards. In the web-based emulator, the state of the button toggles each time you click it, but the button only illuminates. - * **A NORMAL** -- this yellow light illuminates when Processor A is operating in Normal State (i.e., running user code). - * **A CONTROL** -- this yellow light illuminates when Processor A is operating in Control State (i.e., running MCP code).2 - * **B NORMAL** -- this yellow light illuminates when Processor B is operating in Normal State. - * **B CONTROL** -- this yellow light illuminates when Processor B is operating in Control State. - * **POWER ON** -- clicking this green light/button initiates a power-up sequence for the system. The button is illuminated while power is applied to the system. In the web-based emulator, clicking this button first runs a brief lamp test. The emulator then loads the current configuration parameters, 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** -- clicking this black pushbutton initiates a power shutdown sequence for the system. In the web-based emulator, clicking this button halts the processor(s) and closes the peripheral sub-windows. - -When the Console window first opens, 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 clicked, **HALT** becomes active and **LOAD** is deactivated. When power is on, **POWER OFF** can be clicked at any time, even while 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 click the **LOAD** button. The **LOAD** button will not function until the SPO is on line and goes to **REMOTE** status. - -Once you load the system, there is generally nothing further 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. We recommend, however that you do an orderly shutdown when you are finished with the system -- click **HALT**, then **POWER OFF**, then close the Console window, and then quit the browser if desired. - -To reboot a running system, click **HALT** and then **LOAD**. You may halt the system and power it off, then power it back on and do a load without quitting the browser. In order to change the emulator configuration, you must halt and power down the emulator. - -You may move and resize the emulator windows in any way you wish, including the Console window. You may also minimize any of the windows, but _do not close the peripheral windows._ Closing one of those will render that device inoperable until the emulator is reinitialized with the **POWER ON** button. Closing the emulator window will abort the emulator. - -Some web browsers, particularly Firefox, slow the execution of Javascript scripts while they run in a non-active tab of a window. The emulator has a performance throttling mechanism that attempts to run the B5500 processor at its real speed. To keep this mechanism from falling behind in terms of real time, avoid opening the B5500 Console in a window with multiple tabs where one of the other tabs is the active one. It is best to open the Console in its own window, or at least keep it as the active tab in a window. If you need to use the browser to access other web sites at the same time the emulator is running, we recommend that you open separate browser windows to do so. - -See the [Running the Emulator](WebUIRunningTheEmulator.md) 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 while it runs. To give a better view of what is happening within the system (and just because it was sort of a cool thing to do), the emulator displays a series of white annunciator lights in two rows below the standard buttons and lights. If you are a purist and don't want to see these additional lights, you can toggle their display off and on by clicking the Burroughs logo in the upper-right corner of the Console. - -Clicking the retro-B5500 logo (or the plain B5500 logo if the Console is in purist mode) while the emulator power is off will open a sub-window from which you can examine and alter the system configuration. Processors, I/O Units, memory modules, peripheral devices, and a disk subsystem can be included or excluded from the configuration. Multiple, named configurations can be stored and recalled, so you can easily maintain different configurations for different purposes. You can also maintain multiple disk subsystems and switch among them. See [Configuring the System](WebUIConfiguringTheSystem.md) for details. - -In non-purist mode, the Console displays the names of the current system configuration and current disk subsystem above the Burroughs logo. It also displays the current version of the emulator below the Burroughs logo and to the left of the retro-B5500 logo. - -The `MEMORY CHECK` indicator was a lamp and not a pushbutton on the B5500. If you click this lamp while the emulator is in a powered-on state, however, the Console will generate a full dump of processor and core memory state in a separate window. You may then save the contents of this window to a file or copy/paste it into another program for analysis. Simply close the window when you are finished with it. - -> Note: Prior to release 1.00, clicking the `NOT READY` indicator allowed you to toggle Processor B into and out of the current system configuration. With the implementation of the interface for system configuration in that release, however, this behavior has been removed. The number of processors in the system is now controlled through the configuration interface. - -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 illuminated if the corresponding element of the system had any activity since the last update of the display. The A/B Normal/Control lights use multiple shades of yellow to simulate lamp intensity, which in turn indicates the relative amount of time a processor is in each state. - -The top row of annunciators displays activity for the I/O Units (channels), external interrupts, and Processor 2 control for the system: - - * `IOU1` -- I/O unit 1 busy (i.e., an I/O is 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 (fires 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 control #1 read check finished - * `DK2F` -- Disk file control #2 read check finished - * `P2BF` -- Processor 2 busy flip-flop3 - * `HP2F` -- Halt Processor 2 flip-flop - -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 exponential moving average for the percentage of time the emulated processor is delaying its execution in order to throttle its performance to that of a real B5500. Numbers closer to 100% indicate the processor emulation is using relatively small amounts of your workstation's physical processor. Numbers closer to zero indicate the emulator is unable to run at the speed of a real B5500. - * **P1 Delay:** the exponential moving average amount of time (in milliseconds) that processor emulation is delayed during throttling, _in excess of_ the amount of time it requested to be delayed. This is somewhat an indication of how precise the Javascript `setTimeout()` mechanism is in your browser. This value may fluctuate in response to the intensity of the instruction stream, I/O activity, browser overhead (e.g., memory garbage collection), or interference from other programs running on your workstation. If this value continuously increases, however, it means that your workstation is unable to run the emulator at the speed of a B5500. - -In our experience with Mozilla Firefox and Google Chrome, the delay number is typically about half the browser's actual precision, plus one or two milliseconds. HTLM5 standards specify that browsers must have a precision of at least four milliseconds, so you should see values in the 3-4ms range for a compliant browser. Lower values are better, as all of the emulation takes place on one Javascript thread, and shorter delays allow the emulation to switch among processor and I/O tasks more efficiently. - -Note that on most Windows systems, at least through Windows 7, the default timer precision is about 15ms, and you typically should see average delays in the 7-8ms range. Google Chrome is known to mess with the Windows timer mechanism beneficially, however, and meets the HTML5 requirement. Curiously, Chrome's effect on the Windows timer is system-wide -- if you run the emulator in Firefox at the same as Chrome is active in your workstation, the average delay in Firefox will be about the same as it is for Chrome. Starting with version 23, Firefox under Windows appears to handle timers more precisely as well. - -Beginning with emulator version 0.20, we are using the Javascript `performance.now()` API to measure time more accurately, but that does not affect the precision of the Javascript `setTimeout()` function. - - -# Operating the Emulator Off-line # - -Starting with release 1.00, the emulator supports an HTML5 feature known as the "Application Cache." This feature allows the emulator to be installed on your local workstation as a web application, and for it to function when your local workstation is not connected to a network, or is otherwise unable to contact the web server where the emulator is hosted. - -Installation of the emulator files for off-line use is automatic. When operating your local workstation off line, you load the emulator into the browser exactly the same way as when on line, using a URL that addresses the `webUI/B5500Console.html` page at the server on which the emulator is hosted. The browser will recognize that it cannot contact the web server and will load the emulator files from its application cache. The rest of emulator operation is the same as when using it on line. - -The first time you load a version of the emulator enabled for off-line use, the browser will automatically download the files and install them in its application cache. Thereafter, each time you load the emulator when the browser is on line to the web server, the browser will automatically check to see if a newer version of the emulator is available on the server. If a newer version is available, the browser will automatically download it in the background to the application cache. The new version will not be used, however, until the next time the emulator is loaded (or reloaded) in the browser. - -When you load the emulator into your browser, the Console will display messages in its upper-left corner, above the **HALT** button, indicating progress of the browser checking for a newer version and downloading any updates. The last in the sequence of progress messages will remain on the Console for several seconds, and then will be erased. You do not need to wait for these progress messages to go away before powering-on the emulator or loading the MCP -- those activities can be initiated while the checking and downloading process is taking place. - -You will see some combination of the following messages on the Console while it is checking and updating the application cache: - -| Checking for emulator update... | The browser has initiated the process of checking for a newer version of the emulator. | -|:--------------------------------|:---------------------------------------------------------------------------------------| -| Emulator version is current. | The browser determined that no newer version is available. | -| Initiating download for emulator update... | The browser has determined that a later version of the emulator is available on the server and has initiated downloading the new files. | -| x of y resources downloaded thus far... | This message may appear occasionally during download of new files to indicate the progress of the download. | -| Emulator update completed. Reload this page to activate the new version. | Download of a new version completed successfully, but the browser is still using the former version of the emulator. The new version can be made available by powering-off the emulator and reloading the Console page. | -| Emulator is now installed for off-line use. | This message will appear the first time the emulator is downloaded and installed into the browser's application cache. | -| Unable to check for emulator update. | The browser is unable to contact the web server or access the emulator's manifest file. The emulator will run in the off-line mode. | -| Emulator off-line installation has been disabled. | The manifest file for the application cache has been removed from the server. This causes the emulator to be removed from the local application cache. Off-line operation of the emulator is no longer possible. | - -Note that in order to properly serve the manifest file that enables Application Cache functionality for the emulator, your web server may need to be configured to apply the MIME type "`text/cache-manifest`" to files with a "`.appcache`" extension on their file name. - - - -`____________` - -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, if present and enabled, could run only user programs in Normal State, and was essentially a slave to Processor 1. - -3 P2BF serves primarily to inhibit P1 from initiating a program on P2, so it is always illuminated for a system where a second processor is disabled or not configured. \ No newline at end of file diff --git a/WebUIUsingTheConsole.wiki b/WebUIUsingTheConsole.wiki index 6d2acd3..ca88010 100644 --- a/WebUIUsingTheConsole.wiki +++ b/WebUIUsingTheConsole.wiki @@ -1,175 +1,173 @@ -#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 = - - -Compared to virtually every other computer system of the 1960s, the Burroughs B5500 had an extraordinarily minimalist operator console -- just five buttons and six lights, plus a few more on the Teletype SPO (supervisory printer/keyboard). The best image we have of the Console is from the 1968 Burroughs Corporation annual report: - - https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Console-Image.png - -That image shows the B5500 at the City of Montreal, Canada. In the foreground is the L-shaped console desk, with the Teletype Model 33 SPO. You can see part of a card reader behind the SPO and magnetic tape drives in the background. - -We have tried to be faithful to the design of the Console in our representation of it for the web-based user interface: - - 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 central control for the web-based emulator. To display the Console, navigate to the emulator's home page, `B5500Console.html` 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 - -The home page will look similar to this: - - https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Home-Page.png - -On the home page, click one of the "Start" buttons. This will open a small window for the Console. - - * The *Start & Power On* button will open the Console window and automatically power up the emulator, as if you had clicked the Console's green *POWER ON* button. - * The *Start - Powered Off* button will simply open the Console window without powering up the emulator. You may wish to use this button if you want to make configuration changes before running the emulator, as such changes can be made only when the emulator is in a powered-off state. - -Once the Console window is open, you may move it around on your screen, or even minimize it. Closing the Console window will implicitly halt the system and power down the emulator. The emulator will display a warning dialog if you attempt to close the Console window while the emulator is powered up. - - -= Layout of the Console = - -The Console is used to power the system on and off, initiate a load (boot) of the operating system, and halt the system. The A/B Normal/Control lights give a basic indication of system activity. All other operations are handled through the SPO. - -From left to right, the controls on the Console are: - - * *HALT* button -- clicking this red pushbutton halts the system. This initiates an immediate termination of all processing. The only way to continue after halting is to click *LOAD* and reboot the system. The button illuminates when power is on and the system is halted. - * *NOT READY* light -- this white indicator illuminates when one of the components of the system that did not have its own ready/not ready indicator is in a not-ready or off-line state. It applies to processors, I/O units, memory modules, and the first drum (if present). The emulator handles this in a similar manner. It will turn on the light if, at the time the system is powered on, any of the following conditions are true, as they will prevent the system either from booting or from supporting the MCP: - * No Processor is enabled in the current configuration. - * One of the enabled processors is not designated as P1, the control processor. - * No I/O Control Units (channels) are enabled. - * Memory module 0 (having addressees 00000-07777 octal) is not enabled. - * The SPO device is not enabled in the configuration. - * The DKA device (Disk File Control A) is not enabled in the configuration. - * *MEMORY CHECK* -- this red light illuminates when a memory parity error is detected by either processor. The emulator does not presently generate memory parity errors, however. Clicking this light while power is on will produce a full dump of processor state and memory in a separate browser window. This dump can be generated at any time, even while the system is running. - * *LOAD* -- clicking this black pushbutton clears all registers in the system and initiates a load operation. When loading from disk, 63 sectors (1890 words) are read into memory starting at location 20 octal. When loading from cards, one binary card is read starting at location 20 octal. If the read is successful, Processor 1 then starts executing at that address. - * *CARD LOAD SELECT* -- this yellow button/light controls whether a load operation reads from the first disk^1^ or the first card reader. In its normal position, load is from disk. When pressed, the physical button latched inward and illuminated, enabling load from cards. In the web-based emulator, the state of the button toggles each time you click it, but the button only illuminates. - * *A NORMAL* -- this yellow light illuminates when Processor A is operating in Normal State (i.e., running user code). - * *A CONTROL* -- this yellow light illuminates when Processor A is operating in Control State (i.e., running MCP code).^2^ - * *B NORMAL* -- this yellow light illuminates when Processor B is operating in Normal State. - * *B CONTROL* -- this yellow light illuminates when Processor B is operating in Control State. - * *POWER ON* -- clicking this green light/button initiates a power-up sequence for the system. The button is illuminated while power is applied to the system. In the web-based emulator, clicking this button first runs a brief lamp test. The emulator then loads the current configuration parameters, 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* -- clicking this black pushbutton initiates a power shutdown sequence for the system. In the web-based emulator, clicking this button halts the processor(s) and closes the peripheral sub-windows. - -When the Console window first opens, 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 clicked, *HALT* becomes active and *LOAD* is deactivated. When power is on, *POWER OFF* can be clicked at any time, even while 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 click the *LOAD* button. The *LOAD* button will not function until the SPO is on line and goes to *REMOTE* status. - -Once you load the system, there is generally nothing further 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. We recommend, however that you do an orderly shutdown when you are finished with the system -- click *HALT*, then *POWER OFF*, then close the Console window, and then quit the browser if desired. - -To reboot a running system, click *HALT* and then *LOAD*. You may halt the system and power it off, then power it back on and do a load without quitting the browser. In order to change the emulator configuration, you must halt and power down the emulator. - -You may move and resize the emulator windows in any way you wish, including the Console window. You may also minimize any of the windows, but _do not close the peripheral windows._ Closing one of those will render that device inoperable until the emulator is reinitialized with the *POWER ON* button. Closing the emulator window will abort the emulator. - -Some web browsers, particularly Firefox, slow the execution of Javascript scripts while they run in a non-active tab of a window. The emulator has a performance throttling mechanism that attempts to run the B5500 processor at its real speed. To keep this mechanism from falling behind in terms of real time, avoid opening the B5500 Console in a window with multiple tabs where one of the other tabs is the active one. It is best to open the Console in its own window, or at least keep it as the active tab in a window. If you need to use the browser to access other web sites at the same time the emulator is running, we recommend that you open separate browser windows to do so. - -See the [WebUIRunningTheEmulator Running the Emulator] page for more information on using the Console to start the emulator and operate it. - - -= Emulator Features Added to the Console = - -Since the emulator is not a physical system, it is often difficult to tell exactly what is happening while it runs. To give a better view of what is happening within the system (and just because it was sort of a cool thing to do), the emulator displays a series of white annunciator lights in two rows below the standard buttons and lights. If you are a purist and don't want to see these additional lights, you can toggle their display off and on by clicking the Burroughs logo in the upper-right corner of the Console. - -Clicking the retro-B5500 logo (or the plain B5500 logo if the Console is in purist mode) while the emulator power is off will open a sub-window from which you can examine and alter the system configuration. Processors, I/O Units, memory modules, peripheral devices, and a disk subsystem can be included or excluded from the configuration. Multiple, named configurations can be stored and recalled, so you can easily maintain different configurations for different purposes. You can also maintain multiple disk subsystems and switch among them. See [WebUIConfiguringTheSystem Configuring the System] for details. - -In non-purist mode, the Console displays the names of the current system configuration and current disk subsystem above the Burroughs logo. It also displays the current version of the emulator below the Burroughs logo and to the left of the retro-B5500 logo. - -The `MEMORY CHECK` indicator was a lamp and not a pushbutton on the B5500. If you click this lamp while the emulator is in a powered-on state, however, the Console will generate a full dump of processor and core memory state in a separate window. You may then save the contents of this window to a file or copy/paste it into another program for analysis. Simply close the window when you are finished with it. - - Note: Prior to release 1.00, clicking the `NOT READY` indicator allowed you to toggle Processor B into and out of the current system configuration. With the implementation of the interface for system configuration in that release, however, this behavior has been removed. The number of processors in the system is now controlled through the configuration interface. - -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 illuminated if the corresponding element of the system had any activity since the last update of the display. The A/B Normal/Control lights use multiple shades of yellow to simulate lamp intensity, which in turn indicates the relative amount of time a processor is in each state. - -The top row of annunciators displays activity for the I/O Units (channels), external interrupts, and Processor 2 control for the system: - - * `IOU1` -- I/O unit 1 busy (i.e., an I/O is 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 (fires 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 control #1 read check finished - * `DK2F` -- Disk file control #2 read check finished - * `P2BF` -- Processor 2 busy flip-flop^3^ - * `HP2F` -- Halt Processor 2 flip-flop - -The second row of annunciators displays activity for the peripheral devices in the system: - - * `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 exponential moving average for the percentage of time the emulated processor is delaying its execution in order to throttle its performance to that of a real B5500. Numbers closer to 100% indicate the processor emulation is using relatively small amounts of your workstation's physical processor. Numbers closer to zero indicate the emulator is unable to run at the speed of a real B5500. - * *P1 Delay:* the exponential moving average amount of time (in milliseconds) that processor emulation is delayed during throttling, _in excess of_ the amount of time it requested to be delayed. This is somewhat an indication of how precise the Javascript `setTimeout()` mechanism is in your browser. This value may fluctuate in response to the intensity of the instruction stream, I/O activity, browser overhead (e.g., memory garbage collection), or interference from other programs running on your workstation. If this value continuously increases, however, it means that your workstation is unable to run the emulator at the speed of a B5500. - -In our experience with Mozilla Firefox and Google Chrome, the delay number is typically about half the browser's actual precision, plus one or two milliseconds. HTLM5 standards specify that browsers must have a precision of at least four milliseconds, so you should see values in the 3-4ms range for a compliant browser. Lower values are better, as all of the emulation takes place on one Javascript thread, and shorter delays allow the emulation to switch among processor and I/O tasks more efficiently. - -Note that on most Windows systems, at least through Windows 7, the default timer precision is about 15ms, and you typically should see average delays in the 7-8ms range. Google Chrome is known to mess with the Windows timer mechanism beneficially, however, and meets the HTML5 requirement. Curiously, Chrome's effect on the Windows timer is system-wide -- if you run the emulator in Firefox at the same as Chrome is active in your workstation, the average delay in Firefox will be about the same as it is for Chrome. Starting with version 23, Firefox under Windows appears to handle timers more precisely as well. - -Beginning with emulator version 0.20, we are using the Javascript `performance.now()` API to measure time more accurately, but that does not affect the precision of the Javascript `setTimeout()` function. - - -= Operating the Emulator Off-line = - -Starting with release 1.00, the emulator supports an HTML5 feature known as the "Application Cache." This feature allows the emulator to be installed on your local workstation as a web application, and for it to function when your local workstation is not connected to a network, or is otherwise unable to contact the web server where the emulator is hosted. - -Installation of the emulator files for off-line use is automatic. When operating your local workstation off line, you load the emulator into the browser exactly the same way as when on line, using a URL that addresses the `webUI/B5500Console.html` page at the server on which the emulator is hosted. The browser will recognize that it cannot contact the web server and will load the emulator files from its application cache. The rest of emulator operation is the same as when using it on line. - -The first time you load a version of the emulator enabled for off-line use, the browser will automatically download the files and install them in its application cache. Thereafter, each time you load the emulator when the browser is on line to the web server, the browser will automatically check to see if a newer version of the emulator is available on the server. If a newer version is available, the browser will automatically download it in the background to the application cache. The new version will not be used, however, until the next time the emulator is loaded (or reloaded) in the browser. - -When you load the emulator into your browser, the Console will display messages in its upper-left corner, above the *HALT* button, indicating progress of the browser checking for a newer version and downloading any updates. The last in the sequence of progress messages will remain on the Console for several seconds, and then will be erased. You do not need to wait for these progress messages to go away before powering-on the emulator or loading the MCP -- those activities can be initiated while the checking and downloading process is taking place. - -You will see some combination of the following messages on the Console while it is checking and updating the application cache: - -|| Checking for emulator update... || The browser has initiated the process of checking for a newer version of the emulator. || -|| Emulator version is current. || The browser determined that no newer version is available. || -|| Initiating download for emulator update... || The browser has determined that a later version of the emulator is available on the server and has initiated downloading the new files. || -|| x of y resources downloaded thus far... || This message may appear occasionally during download of new files to indicate the progress of the download. || -|| Emulator update completed. Reload this page to activate the new version. || Download of a new version completed successfully, but the browser is still using the former version of the emulator. The new version can be made available by powering-off the emulator and reloading the Console page. || -|| Emulator is now installed for off-line use. || This message will appear the first time the emulator is downloaded and installed into the browser's application cache. || -|| Unable to check for emulator update. || The browser is unable to contact the web server or access the emulator's manifest file. The emulator will run in the off-line mode. || -|| Emulator off-line installation has been disabled. || The manifest file for the application cache has been removed from the server. This causes the emulator to be removed from the local application cache. Off-line operation of the emulator is no longer possible. || - -Note that in order to properly serve the manifest file that enables Application Cache functionality for the emulator, your web server may need to be configured to apply the MIME type "`text/cache-manifest`" to files with a "`.appcache`" extension on their file name. - - - -`____________` - -^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, if present and enabled, could run only user programs in Normal State, and was essentially a slave to Processor 1. - -^3^ P2BF serves primarily to inhibit P1 from initiating a program on P2, so it is always illuminated for a system where a second processor is disabled or not configured. \ No newline at end of file +# WebUI Using the B5500 Console # + + +Compared to virtually every other computer system of the 1960s, the Burroughs B5500 had an extraordinarily minimalist operator console -- just five buttons and six lights, plus a few more on the Teletype SPO (supervisory printer/keyboard). The best image we have of the Console is from the 1968 Burroughs Corporation annual report: + +> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Console-Image.png](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Console-Image.png) + +That image shows the B5500 at the City of Montreal, Canada. In the foreground is the L-shaped console desk, with the Teletype Model 33 SPO. You can see part of a card reader behind the SPO and magnetic tape drives in the background. + +We have tried to be faithful to the design of the Console in our representation of it for the web-based user interface: + +> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Console.png](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 central control for the web-based emulator. To display the Console, navigate to the emulator's home page, `B5500Console.html` 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 + +The home page will look similar to this: + +> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Home-Page.png](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-Home-Page.png) + +On the home page, click one of the "Start" buttons. This will open a small window for the Console. + + * The **Start & Power On** button will open the Console window and automatically power up the emulator, as if you had clicked the Console's green **POWER ON** button. + * The **Start - Powered Off** button will simply open the Console window without powering up the emulator. You may wish to use this button if you want to make configuration changes before running the emulator, as such changes can be made only when the emulator is in a powered-off state. + +Once the Console window is open, you may move it around on your screen, or even minimize it. Closing the Console window will implicitly halt the system and power down the emulator. The emulator will display a warning dialog if you attempt to close the Console window while the emulator is powered up. + + +# Layout of the Console # + +The Console is used to power the system on and off, initiate a load (boot) of the operating system, and halt the system. The A/B Normal/Control lights give a basic indication of system activity. All other operations are handled through the SPO. + +From left to right, the controls on the Console are: + + * **HALT** button -- clicking this red pushbutton halts the system. This initiates an immediate termination of all processing. The only way to continue after halting is to click **LOAD** and reboot the system. The button illuminates when power is on and the system is halted. + * **NOT READY** light -- this white indicator illuminates when one of the components of the system that did not have its own ready/not ready indicator is in a not-ready or off-line state. It applies to processors, I/O units, memory modules, and the first drum (if present). The emulator handles this in a similar manner. It will turn on the light if, at the time the system is powered on, any of the following conditions are true, as they will prevent the system either from booting or from supporting the MCP: + * No Processor is enabled in the current configuration. + * One of the enabled processors is not designated as P1, the control processor. + * No I/O Control Units (channels) are enabled. + * Memory module 0 (having addressees 00000-07777 octal) is not enabled. + * The SPO device is not enabled in the configuration. + * The DKA device (Disk File Control A) is not enabled in the configuration. + * **MEMORY CHECK** -- this red light illuminates when a memory parity error is detected by either processor. The emulator does not presently generate memory parity errors, however. Clicking this light while power is on will produce a full dump of processor state and memory in a separate browser window. This dump can be generated at any time, even while the system is running. + * **LOAD** -- clicking this black pushbutton clears all registers in the system and initiates a load operation. When loading from disk, 63 sectors (1890 words) are read into memory starting at location 20 octal. When loading from cards, one binary card is read starting at location 20 octal. If the read is successful, Processor 1 then starts executing at that address. + * **CARD LOAD SELECT** -- this yellow button/light controls whether a load operation reads from the first disk1 or the first card reader. In its normal position, load is from disk. When pressed, the physical button latched inward and illuminated, enabling load from cards. In the web-based emulator, the state of the button toggles each time you click it, but the button only illuminates. + * **A NORMAL** -- this yellow light illuminates when Processor A is operating in Normal State (i.e., running user code). + * **A CONTROL** -- this yellow light illuminates when Processor A is operating in Control State (i.e., running MCP code).2 + * **B NORMAL** -- this yellow light illuminates when Processor B is operating in Normal State. + * **B CONTROL** -- this yellow light illuminates when Processor B is operating in Control State. + * **POWER ON** -- clicking this green light/button initiates a power-up sequence for the system. The button is illuminated while power is applied to the system. In the web-based emulator, clicking this button first runs a brief lamp test. The emulator then loads the current configuration parameters, 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** -- clicking this black pushbutton initiates a power shutdown sequence for the system. In the web-based emulator, clicking this button halts the processor(s) and closes the peripheral sub-windows. + +When the Console window first opens, 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 clicked, **HALT** becomes active and **LOAD** is deactivated. When power is on, **POWER OFF** can be clicked at any time, even while 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 click the **LOAD** button. The **LOAD** button will not function until the SPO is on line and goes to **REMOTE** status. + +Once you load the system, there is generally nothing further 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. We recommend, however that you do an orderly shutdown when you are finished with the system -- click **HALT**, then **POWER OFF**, then close the Console window, and then quit the browser if desired. + +To reboot a running system, click **HALT** and then **LOAD**. You may halt the system and power it off, then power it back on and do a load without quitting the browser. In order to change the emulator configuration, you must halt and power down the emulator. + +You may move and resize the emulator windows in any way you wish, including the Console window. You may also minimize any of the windows, but _do not close the peripheral windows._ Closing one of those will render that device inoperable until the emulator is reinitialized with the **POWER ON** button. Closing the emulator window will abort the emulator. + +Some web browsers, particularly Firefox, slow the execution of Javascript scripts while they run in a non-active tab of a window. The emulator has a performance throttling mechanism that attempts to run the B5500 processor at its real speed. To keep this mechanism from falling behind in terms of real time, avoid opening the B5500 Console in a window with multiple tabs where one of the other tabs is the active one. It is best to open the Console in its own window, or at least keep it as the active tab in a window. If you need to use the browser to access other web sites at the same time the emulator is running, we recommend that you open separate browser windows to do so. + +See the [Running the Emulator](WebUIRunningTheEmulator.md) 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 while it runs. To give a better view of what is happening within the system (and just because it was sort of a cool thing to do), the emulator displays a series of white annunciator lights in two rows below the standard buttons and lights. If you are a purist and don't want to see these additional lights, you can toggle their display off and on by clicking the Burroughs logo in the upper-right corner of the Console. + +Clicking the retro-B5500 logo (or the plain B5500 logo if the Console is in purist mode) while the emulator power is off will open a sub-window from which you can examine and alter the system configuration. Processors, I/O Units, memory modules, peripheral devices, and a disk subsystem can be included or excluded from the configuration. Multiple, named configurations can be stored and recalled, so you can easily maintain different configurations for different purposes. You can also maintain multiple disk subsystems and switch among them. See [Configuring the System](WebUIConfiguringTheSystem.md) for details. + +In non-purist mode, the Console displays the names of the current system configuration and current disk subsystem above the Burroughs logo. It also displays the current version of the emulator below the Burroughs logo and to the left of the retro-B5500 logo. + +The `MEMORY CHECK` indicator was a lamp and not a pushbutton on the B5500. If you click this lamp while the emulator is in a powered-on state, however, the Console will generate a full dump of processor and core memory state in a separate window. You may then save the contents of this window to a file or copy/paste it into another program for analysis. Simply close the window when you are finished with it. + +> Note: Prior to release 1.00, clicking the `NOT READY` indicator allowed you to toggle Processor B into and out of the current system configuration. With the implementation of the interface for system configuration in that release, however, this behavior has been removed. The number of processors in the system is now controlled through the configuration interface. + +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 illuminated if the corresponding element of the system had any activity since the last update of the display. The A/B Normal/Control lights use multiple shades of yellow to simulate lamp intensity, which in turn indicates the relative amount of time a processor is in each state. + +The top row of annunciators displays activity for the I/O Units (channels), external interrupts, and Processor 2 control for the system: + + * `IOU1` -- I/O unit 1 busy (i.e., an I/O is 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 (fires 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 control #1 read check finished + * `DK2F` -- Disk file control #2 read check finished + * `P2BF` -- Processor 2 busy flip-flop3 + * `HP2F` -- Halt Processor 2 flip-flop + +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 exponential moving average for the percentage of time the emulated processor is delaying its execution in order to throttle its performance to that of a real B5500. Numbers closer to 100% indicate the processor emulation is using relatively small amounts of your workstation's physical processor. Numbers closer to zero indicate the emulator is unable to run at the speed of a real B5500. + * **P1 Delay:** the exponential moving average amount of time (in milliseconds) that processor emulation is delayed during throttling, _in excess of_ the amount of time it requested to be delayed. This is somewhat an indication of how precise the Javascript `setTimeout()` mechanism is in your browser. This value may fluctuate in response to the intensity of the instruction stream, I/O activity, browser overhead (e.g., memory garbage collection), or interference from other programs running on your workstation. If this value continuously increases, however, it means that your workstation is unable to run the emulator at the speed of a B5500. + +In our experience with Mozilla Firefox and Google Chrome, the delay number is typically about half the browser's actual precision, plus one or two milliseconds. HTLM5 standards specify that browsers must have a precision of at least four milliseconds, so you should see values in the 3-4ms range for a compliant browser. Lower values are better, as all of the emulation takes place on one Javascript thread, and shorter delays allow the emulation to switch among processor and I/O tasks more efficiently. + +Note that on most Windows systems, at least through Windows 7, the default timer precision is about 15ms, and you typically should see average delays in the 7-8ms range. Google Chrome is known to mess with the Windows timer mechanism beneficially, however, and meets the HTML5 requirement. Curiously, Chrome's effect on the Windows timer is system-wide -- if you run the emulator in Firefox at the same as Chrome is active in your workstation, the average delay in Firefox will be about the same as it is for Chrome. Starting with version 23, Firefox under Windows appears to handle timers more precisely as well. + +Beginning with emulator version 0.20, we are using the Javascript `performance.now()` API to measure time more accurately, but that does not affect the precision of the Javascript `setTimeout()` function. + + +# Operating the Emulator Off-line # + +Starting with release 1.00, the emulator supports an HTML5 feature known as the "Application Cache." This feature allows the emulator to be installed on your local workstation as a web application, and for it to function when your local workstation is not connected to a network, or is otherwise unable to contact the web server where the emulator is hosted. + +Installation of the emulator files for off-line use is automatic. When operating your local workstation off line, you load the emulator into the browser exactly the same way as when on line, using a URL that addresses the `webUI/B5500Console.html` page at the server on which the emulator is hosted. The browser will recognize that it cannot contact the web server and will load the emulator files from its application cache. The rest of emulator operation is the same as when using it on line. + +The first time you load a version of the emulator enabled for off-line use, the browser will automatically download the files and install them in its application cache. Thereafter, each time you load the emulator when the browser is on line to the web server, the browser will automatically check to see if a newer version of the emulator is available on the server. If a newer version is available, the browser will automatically download it in the background to the application cache. The new version will not be used, however, until the next time the emulator is loaded (or reloaded) in the browser. + +When you load the emulator into your browser, the Console will display messages in its upper-left corner, above the **HALT** button, indicating progress of the browser checking for a newer version and downloading any updates. The last in the sequence of progress messages will remain on the Console for several seconds, and then will be erased. You do not need to wait for these progress messages to go away before powering-on the emulator or loading the MCP -- those activities can be initiated while the checking and downloading process is taking place. + +You will see some combination of the following messages on the Console while it is checking and updating the application cache: + +| Checking for emulator update... | The browser has initiated the process of checking for a newer version of the emulator. | +|:--------------------------------|:---------------------------------------------------------------------------------------| +| Emulator version is current. | The browser determined that no newer version is available. | +| Initiating download for emulator update... | The browser has determined that a later version of the emulator is available on the server and has initiated downloading the new files. | +| x of y resources downloaded thus far... | This message may appear occasionally during download of new files to indicate the progress of the download. | +| Emulator update completed. Reload this page to activate the new version. | Download of a new version completed successfully, but the browser is still using the former version of the emulator. The new version can be made available by powering-off the emulator and reloading the Console page. | +| Emulator is now installed for off-line use. | This message will appear the first time the emulator is downloaded and installed into the browser's application cache. | +| Unable to check for emulator update. | The browser is unable to contact the web server or access the emulator's manifest file. The emulator will run in the off-line mode. | +| Emulator off-line installation has been disabled. | The manifest file for the application cache has been removed from the server. This causes the emulator to be removed from the local application cache. Off-line operation of the emulator is no longer possible. | + +Note that in order to properly serve the manifest file that enables Application Cache functionality for the emulator, your web server may need to be configured to apply the MIME type "`text/cache-manifest`" to files with a "`.appcache`" extension on their file name. + + + +`____________` + +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, if present and enabled, could run only user programs in Normal State, and was essentially a slave to Processor 1. + +3 P2BF serves primarily to inhibit P1 from initiating a program on P2, so it is always illuminated for a system where a second processor is disabled or not configured. \ No newline at end of file diff --git a/WebUIUsingTheLinePrinter.md b/WebUIUsingTheLinePrinter.md deleted file mode 100644 index 6e9630c..0000000 --- a/WebUIUsingTheLinePrinter.md +++ /dev/null @@ -1,83 +0,0 @@ -# WebUI Using the Line Printer # - - - -The B5500 supported several line printer models, with speeds ranging from 475 to 1040 lines per minute. A B5500 system could have one or two line printers, identified as `LPA` and `LPB`. - - -# Background # - -The line printer interface we have developed for the web-based emulator is modeled after the 1040 line-per-minute B329. This interface opens in a separate window when the **POWER ON** button is activated on the emulator console. - -> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-LinePrinter.png](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-LinePrinter.png) - -The B329 had additional buttons and lamps related to the mechanical issues of the printer (e.g., print-check errors), but these controls are not relevant to operation under the emulator. - -The printer used standard pin-feed continuous forms. It had a punched-paper carriage-control tape to define vertical skip positions on a page of forms, but the carriage tape is not supported by the emulator. All skip-to-channel printer operations are treated as skip-to-channel-1 (form feed) operations. These result in a dashed horizontal line being placed at that point in the paper area of the printer's window. - -Single- and double-spaced printing of output is supported. Zero-spaced printing (overprinting) is not supported -- such lines are printed with single spacing. The channel-12 "skip over perforation" feature of the printer is also not supported. - -The printer interface consists of several buttons, lamps, and other controls, plus an area that displays the "paper" with a number of the most-recently printed lines. Lines are printed in this area as they are received from one of the B5500's I/O Control Units. The area will scroll as lines are added to the end. - -The text of the printed lines is stored in your workstation's memory. To avoid flooding memory during large print runs, the capacity of the "paper" area is limited to 150,000 lines, which is roughly equivalent to a case of the stock "greenbar" pin-feed paper that was used with these printers. Once this limit is reached, the printer will go not-ready and the **END OF PAPER** button/indicator will illuminate. See below for how you can clear the paper area and continue printing. - -You can virtually remove "paper" from the printer by selecting and copying lines of text from the paper area and then pasting them into another application, such as a text editor, from which they can be saved to your local file system. This copy/paste technique is the only reasonably convenient way to capture data from the browser-based emulator. Some browsers may also allow you to save the paper-area contents to a file or print the area to your local printer. - -Lines of text are composed using the ASCII equivalent of the emulator's version of the B5500 64-character set: - -``` - 0 1 2 3 4 5 6 7 - 8 9 # @ ? : > { - + A B C D E F G - H I . [ & ( < ~ - | J K L M N O P - Q R $ * - 0 ; { - / S T U V W X - Y Z , % ! = } " -``` - -The B5500 used five special Algol characters that do not have ASCII equivalents. The emulator uses the following ASCII substitutions for them: - - * `~` for left-arrow - * `|` for the multiplication sign - * `{` for less-than-or-equal - * `}` for greater-than-or-equal - * `!` for not-equal - -As an option, the printer will render the special Algol characters using their appropriate Unicode glyphs. See below for instructions on how to enable and disable this feature. The five Unicode glyphs are: - - * U+00D7: small-cross (multiplication sign) - * U+2190: left-arrow - * U+2260: not-equal - * U+2264: less-than-or-equal - * U+2265: greater-than-or-equal - - -# Line Printer Control Panel # - -The user interface for the emulated line printer consists of the following controls and indicators: - - * **NOT READY** -- this white indicator illuminates when the printer is in a not-ready status. The printer becomes ready when the **START** button is clicked. It becomes not-ready when the **STOP** button is clicked or when the paper-area limit is reached. - * **END OF PAPER** -- this white button/indicator lights when the paper-area limit is reached. This condition will also change the printer status to not-ready and illuminate the **NOT READY** indicator. When the **END OF PAPER** indicator is lit, clicking it will make the printer ready again, but the next line printed will trigger the paper-area limit, making the printer not-ready again. The button is not active except when lit. To resume continuous printing, you must first clear the paper area, as discussed below. - * **SKIP TO HEADING** -- clicking this black button when the printer is in a not-ready status will simulate a skip-to-channel-1 operation. Clicking this button three times in succession will initiate clearing the paper area, as discussed in more detail below. The button is not active when the printer is in a ready status. - * **SPACE** -- clicking this black button when the printer is in a not-ready status will simulate a single-space operation. The button is not active when the printer is in a ready status. - * **STOP** -- clicking this red button will stop the printer and place it in a not-ready status. The **NOT READY** button will illuminate. The button is not active when the printer is not ready. - * **START** -- clicking this green button will place the printer in a ready status. The **NOT READY** lamp will go out. The MCP should sense the status change within a second or two and begin (or resume) printing if any I/Os to the unit are currently queued. - -The purpose of the **END OF PAPER** button was to incrementally print the last few lines on the last page of box of paper, so that it would clear the lower pin-feed tractor. Once that page was completed, the first page of a new box of paper could be loaded into the printer. The emulated printer simply reproduces this behavior. - -To the right of the buttons is a progress bar showing the relative amount of "paper" left before the paper-area limit is reached. Each time you clear paper from the printer, this bar resets all the way to the right. As lines are printed, the length of the bar will decrease towards to left in proportion to the number of lines printed. - -In the upper-right of the unit's window is a checkbox labeled **ALGOL GLYPHS**. When this box is checked, the five special Algol characters will be rendered using their Unicode glyphs. When the box is unchecked, those characters will be rendered using their ASCII substitutions, as described above. Toggling the checkbox will convert the characters in the paper area between Unicode glyphs and the ASCII substitution glyphs. The initial setting for this box is taken from the "Algol Glyphs" setting for the printers in the current system configuration. - -To the left of the **ALGOL GLYPHS** checkbox is another checkbox labeled **GREENBAR**. When this box is checked, the paper area will be formatted with alternating green and white bars, similar to that found on traditional pin-feed continuous forms. Toggling the checkbox will alternately remove and reinstate the green bars. The initial setting for this box is checked. - -# Operating the Line Printer # - -As mentioned above, you can stop the printer at any time and make it not-ready to copy or save lines of text from the paper area and/or clear the paper area. - -In the normal case, there is nothing you need to do with the printer except watch the lines go by as they are printed. If you want to save the printed output, select the portion you wish to keep and copy/paste it into another application. If your browser supports it, you may also be able to print the paper area or save it as a text file to your local file system. When printing directly to a printer for your workstation, the dashed lines in the paper area should force a from feed on the workstation printer. - -When the paper-area limit is reached, the printer will stop, go not-ready, and illuminate the **END OF PAPER** button. Clicking the **END OF PAPER** button will allow one additional line to be printed, then the unit will go not-ready again. You can continue clicking the button as many times as desired. - -To resume continuous operation of the printer after the paper-area limit is reached, you must clear the paper area. As described above, with the unit in a not-ready state, click the **SKIP TO HEADING** button _three_ times in succession. A confirmation dialog will display, asking if you want to clear the paper. When you click the **OK** button on this dialog, the paper area will be cleared and the paper supply reset to the maximum. At this point you can click the **START** button to resume printing. Make sure you copy or save any text from the print area you want to keep before clearing the paper area. \ No newline at end of file diff --git a/WebUIUsingTheLinePrinter.wiki b/WebUIUsingTheLinePrinter.wiki index b1e379a..6e9630c 100644 --- a/WebUIUsingTheLinePrinter.wiki +++ b/WebUIUsingTheLinePrinter.wiki @@ -1,34 +1,31 @@ -#summary Instructions for using the line printer with the retro-B5500 emulator in a web browser. -#labels Burroughs,B5500,emulator,retro-b5500,operator,printer,B329 - -= WebUI Using the Line Printer = - - - -The B5500 supported several line printer models, with speeds ranging from 475 to 1040 lines per minute. A B5500 system could have one or two line printers, identified as `LPA` and `LPB`. - - -= Background = - -The line printer interface we have developed for the web-based emulator is modeled after the 1040 line-per-minute B329. This interface opens in a separate window when the *POWER ON* button is activated on the emulator console. - - https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-LinePrinter.png - -The B329 had additional buttons and lamps related to the mechanical issues of the printer (e.g., print-check errors), but these controls are not relevant to operation under the emulator. - -The printer used standard pin-feed continuous forms. It had a punched-paper carriage-control tape to define vertical skip positions on a page of forms, but the carriage tape is not supported by the emulator. All skip-to-channel printer operations are treated as skip-to-channel-1 (form feed) operations. These result in a dashed horizontal line being placed at that point in the paper area of the printer's window. - -Single- and double-spaced printing of output is supported. Zero-spaced printing (overprinting) is not supported -- such lines are printed with single spacing. The channel-12 "skip over perforation" feature of the printer is also not supported. - -The printer interface consists of several buttons, lamps, and other controls, plus an area that displays the "paper" with a number of the most-recently printed lines. Lines are printed in this area as they are received from one of the B5500's I/O Control Units. The area will scroll as lines are added to the end. - -The text of the printed lines is stored in your workstation's memory. To avoid flooding memory during large print runs, the capacity of the "paper" area is limited to 150,000 lines, which is roughly equivalent to a case of the stock "greenbar" pin-feed paper that was used with these printers. Once this limit is reached, the printer will go not-ready and the *END OF PAPER* button/indicator will illuminate. See below for how you can clear the paper area and continue printing. - -You can virtually remove "paper" from the printer by selecting and copying lines of text from the paper area and then pasting them into another application, such as a text editor, from which they can be saved to your local file system. This copy/paste technique is the only reasonably convenient way to capture data from the browser-based emulator. Some browsers may also allow you to save the paper-area contents to a file or print the area to your local printer. - -Lines of text are composed using the ASCII equivalent of the emulator's version of the B5500 64-character set: - - {{{ +# WebUI Using the Line Printer # + + + +The B5500 supported several line printer models, with speeds ranging from 475 to 1040 lines per minute. A B5500 system could have one or two line printers, identified as `LPA` and `LPB`. + + +# Background # + +The line printer interface we have developed for the web-based emulator is modeled after the 1040 line-per-minute B329. This interface opens in a separate window when the **POWER ON** button is activated on the emulator console. + +> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-LinePrinter.png](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-LinePrinter.png) + +The B329 had additional buttons and lamps related to the mechanical issues of the printer (e.g., print-check errors), but these controls are not relevant to operation under the emulator. + +The printer used standard pin-feed continuous forms. It had a punched-paper carriage-control tape to define vertical skip positions on a page of forms, but the carriage tape is not supported by the emulator. All skip-to-channel printer operations are treated as skip-to-channel-1 (form feed) operations. These result in a dashed horizontal line being placed at that point in the paper area of the printer's window. + +Single- and double-spaced printing of output is supported. Zero-spaced printing (overprinting) is not supported -- such lines are printed with single spacing. The channel-12 "skip over perforation" feature of the printer is also not supported. + +The printer interface consists of several buttons, lamps, and other controls, plus an area that displays the "paper" with a number of the most-recently printed lines. Lines are printed in this area as they are received from one of the B5500's I/O Control Units. The area will scroll as lines are added to the end. + +The text of the printed lines is stored in your workstation's memory. To avoid flooding memory during large print runs, the capacity of the "paper" area is limited to 150,000 lines, which is roughly equivalent to a case of the stock "greenbar" pin-feed paper that was used with these printers. Once this limit is reached, the printer will go not-ready and the **END OF PAPER** button/indicator will illuminate. See below for how you can clear the paper area and continue printing. + +You can virtually remove "paper" from the printer by selecting and copying lines of text from the paper area and then pasting them into another application, such as a text editor, from which they can be saved to your local file system. This copy/paste technique is the only reasonably convenient way to capture data from the browser-based emulator. Some browsers may also allow you to save the paper-area contents to a file or print the area to your local printer. + +Lines of text are composed using the ASCII equivalent of the emulator's version of the B5500 64-character set: + +``` 0 1 2 3 4 5 6 7 8 9 # @ ? : > { + A B C D E F G @@ -37,50 +34,50 @@ Lines of text are composed using the ASCII equivalent of the emulator's version Q R $ * - 0 ; { / S T U V W X Y Z , % ! = } " - }}} - -The B5500 used five special Algol characters that do not have ASCII equivalents. The emulator uses the following ASCII substitutions for them: - - * `~` for left-arrow - * `|` for the multiplication sign - * `{` for less-than-or-equal - * `}` for greater-than-or-equal - * `!` for not-equal - -As an option, the printer will render the special Algol characters using their appropriate Unicode glyphs. See below for instructions on how to enable and disable this feature. The five Unicode glyphs are: - - * U+00D7: small-cross (multiplication sign) - * U+2190: left-arrow - * U+2260: not-equal - * U+2264: less-than-or-equal - * U+2265: greater-than-or-equal - - -= Line Printer Control Panel = - -The user interface for the emulated line printer consists of the following controls and indicators: - - * *NOT READY* -- this white indicator illuminates when the printer is in a not-ready status. The printer becomes ready when the *START* button is clicked. It becomes not-ready when the *STOP* button is clicked or when the paper-area limit is reached. - * *END OF PAPER* -- this white button/indicator lights when the paper-area limit is reached. This condition will also change the printer status to not-ready and illuminate the *NOT READY* indicator. When the *END OF PAPER* indicator is lit, clicking it will make the printer ready again, but the next line printed will trigger the paper-area limit, making the printer not-ready again. The button is not active except when lit. To resume continuous printing, you must first clear the paper area, as discussed below. - * *SKIP TO HEADING* -- clicking this black button when the printer is in a not-ready status will simulate a skip-to-channel-1 operation. Clicking this button three times in succession will initiate clearing the paper area, as discussed in more detail below. The button is not active when the printer is in a ready status. - * *SPACE* -- clicking this black button when the printer is in a not-ready status will simulate a single-space operation. The button is not active when the printer is in a ready status. - * *STOP* -- clicking this red button will stop the printer and place it in a not-ready status. The *NOT READY* button will illuminate. The button is not active when the printer is not ready. - * *START* -- clicking this green button will place the printer in a ready status. The *NOT READY* lamp will go out. The MCP should sense the status change within a second or two and begin (or resume) printing if any I/Os to the unit are currently queued. - -The purpose of the *END OF PAPER* button was to incrementally print the last few lines on the last page of box of paper, so that it would clear the lower pin-feed tractor. Once that page was completed, the first page of a new box of paper could be loaded into the printer. The emulated printer simply reproduces this behavior. - -To the right of the buttons is a progress bar showing the relative amount of "paper" left before the paper-area limit is reached. Each time you clear paper from the printer, this bar resets all the way to the right. As lines are printed, the length of the bar will decrease towards to left in proportion to the number of lines printed. - -In the upper-right of the unit's window is a checkbox labeled *ALGOL GLYPHS*. When this box is checked, the five special Algol characters will be rendered using their Unicode glyphs. When the box is unchecked, those characters will be rendered using their ASCII substitutions, as described above. Toggling the checkbox will convert the characters in the paper area between Unicode glyphs and the ASCII substitution glyphs. The initial setting for this box is taken from the "Algol Glyphs" setting for the printers in the current system configuration. - -To the left of the *ALGOL GLYPHS* checkbox is another checkbox labeled *GREENBAR*. When this box is checked, the paper area will be formatted with alternating green and white bars, similar to that found on traditional pin-feed continuous forms. Toggling the checkbox will alternately remove and reinstate the green bars. The initial setting for this box is checked. - -= Operating the Line Printer = - -As mentioned above, you can stop the printer at any time and make it not-ready to copy or save lines of text from the paper area and/or clear the paper area. - -In the normal case, there is nothing you need to do with the printer except watch the lines go by as they are printed. If you want to save the printed output, select the portion you wish to keep and copy/paste it into another application. If your browser supports it, you may also be able to print the paper area or save it as a text file to your local file system. When printing directly to a printer for your workstation, the dashed lines in the paper area should force a from feed on the workstation printer. - -When the paper-area limit is reached, the printer will stop, go not-ready, and illuminate the *END OF PAPER* button. Clicking the *END OF PAPER* button will allow one additional line to be printed, then the unit will go not-ready again. You can continue clicking the button as many times as desired. - -To resume continuous operation of the printer after the paper-area limit is reached, you must clear the paper area. As described above, with the unit in a not-ready state, click the *SKIP TO HEADING* button _three_ times in succession. A confirmation dialog will display, asking if you want to clear the paper. When you click the *OK* button on this dialog, the paper area will be cleared and the paper supply reset to the maximum. At this point you can click the *START* button to resume printing. Make sure you copy or save any text from the print area you want to keep before clearing the paper area. +``` + +The B5500 used five special Algol characters that do not have ASCII equivalents. The emulator uses the following ASCII substitutions for them: + + * `~` for left-arrow + * `|` for the multiplication sign + * `{` for less-than-or-equal + * `}` for greater-than-or-equal + * `!` for not-equal + +As an option, the printer will render the special Algol characters using their appropriate Unicode glyphs. See below for instructions on how to enable and disable this feature. The five Unicode glyphs are: + + * U+00D7: small-cross (multiplication sign) + * U+2190: left-arrow + * U+2260: not-equal + * U+2264: less-than-or-equal + * U+2265: greater-than-or-equal + + +# Line Printer Control Panel # + +The user interface for the emulated line printer consists of the following controls and indicators: + + * **NOT READY** -- this white indicator illuminates when the printer is in a not-ready status. The printer becomes ready when the **START** button is clicked. It becomes not-ready when the **STOP** button is clicked or when the paper-area limit is reached. + * **END OF PAPER** -- this white button/indicator lights when the paper-area limit is reached. This condition will also change the printer status to not-ready and illuminate the **NOT READY** indicator. When the **END OF PAPER** indicator is lit, clicking it will make the printer ready again, but the next line printed will trigger the paper-area limit, making the printer not-ready again. The button is not active except when lit. To resume continuous printing, you must first clear the paper area, as discussed below. + * **SKIP TO HEADING** -- clicking this black button when the printer is in a not-ready status will simulate a skip-to-channel-1 operation. Clicking this button three times in succession will initiate clearing the paper area, as discussed in more detail below. The button is not active when the printer is in a ready status. + * **SPACE** -- clicking this black button when the printer is in a not-ready status will simulate a single-space operation. The button is not active when the printer is in a ready status. + * **STOP** -- clicking this red button will stop the printer and place it in a not-ready status. The **NOT READY** button will illuminate. The button is not active when the printer is not ready. + * **START** -- clicking this green button will place the printer in a ready status. The **NOT READY** lamp will go out. The MCP should sense the status change within a second or two and begin (or resume) printing if any I/Os to the unit are currently queued. + +The purpose of the **END OF PAPER** button was to incrementally print the last few lines on the last page of box of paper, so that it would clear the lower pin-feed tractor. Once that page was completed, the first page of a new box of paper could be loaded into the printer. The emulated printer simply reproduces this behavior. + +To the right of the buttons is a progress bar showing the relative amount of "paper" left before the paper-area limit is reached. Each time you clear paper from the printer, this bar resets all the way to the right. As lines are printed, the length of the bar will decrease towards to left in proportion to the number of lines printed. + +In the upper-right of the unit's window is a checkbox labeled **ALGOL GLYPHS**. When this box is checked, the five special Algol characters will be rendered using their Unicode glyphs. When the box is unchecked, those characters will be rendered using their ASCII substitutions, as described above. Toggling the checkbox will convert the characters in the paper area between Unicode glyphs and the ASCII substitution glyphs. The initial setting for this box is taken from the "Algol Glyphs" setting for the printers in the current system configuration. + +To the left of the **ALGOL GLYPHS** checkbox is another checkbox labeled **GREENBAR**. When this box is checked, the paper area will be formatted with alternating green and white bars, similar to that found on traditional pin-feed continuous forms. Toggling the checkbox will alternately remove and reinstate the green bars. The initial setting for this box is checked. + +# Operating the Line Printer # + +As mentioned above, you can stop the printer at any time and make it not-ready to copy or save lines of text from the paper area and/or clear the paper area. + +In the normal case, there is nothing you need to do with the printer except watch the lines go by as they are printed. If you want to save the printed output, select the portion you wish to keep and copy/paste it into another application. If your browser supports it, you may also be able to print the paper area or save it as a text file to your local file system. When printing directly to a printer for your workstation, the dashed lines in the paper area should force a from feed on the workstation printer. + +When the paper-area limit is reached, the printer will stop, go not-ready, and illuminate the **END OF PAPER** button. Clicking the **END OF PAPER** button will allow one additional line to be printed, then the unit will go not-ready again. You can continue clicking the button as many times as desired. + +To resume continuous operation of the printer after the paper-area limit is reached, you must clear the paper area. As described above, with the unit in a not-ready state, click the **SKIP TO HEADING** button _three_ times in succession. A confirmation dialog will display, asking if you want to clear the paper. When you click the **OK** button on this dialog, the paper area will be cleared and the paper supply reset to the maximum. At this point you can click the **START** button to resume printing. Make sure you copy or save any text from the print area you want to keep before clearing the paper area. \ No newline at end of file diff --git a/WebUIUsingTheMagTapeDrive.md b/WebUIUsingTheMagTapeDrive.md deleted file mode 100644 index beb39cf..0000000 --- a/WebUIUsingTheMagTapeDrive.md +++ /dev/null @@ -1,168 +0,0 @@ -# WebUI Using the Magnetic Tape Drive # - - - -The B5500 supported several 7-track tape drive models, with recording densities of 200, 555, and 800 bits per inch. Not all drives supported all densities. Tape speed ranged from 83 to 120 inches per second, with data transfer ranges ranging in concert from 66,000 to 96,000 characters per second. Blocks of data on the tape were delimited by a 0.75-inch unrecorded gap. Rewind speed was 320 inches/second, taking about 90 seconds for a full 2400-foot reel of tape. - -All drives could record in even or odd parity. With even parity (also termed alpha mode), characters were translated to and from BCL (Burroughs Common Language), which was very similar to the character codes used with IBM 1401 tape drives. With odd parity (binary mode), bits were recorded without translation from their internal representation in the B5500 core memory. - -A B5500 system could have up to 16 tape drives, identified as `MTA` through `MTT` (with letters `G`, `I`, `O`, and `Q` not used). - -Here is a view of a B42x-series drive with its front door open, showing the tape head, pinch-roller mechanisms, and tape columns: - -> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/MagTape-Drive-burr0136.jpg](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/MagTape-Drive-burr0136.jpg) - - -# Background # - -The tape drive interface we have developed for the web-based emulator is modeled after the 90 inch-per-second B425, operating at 800 bpi. This interface opens in a separate window when the **POWER ON** button is activated on the emulator console: - -> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-MagTapeDrive.png](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-MagTapeDrive.png) - -The B425 had additional buttons and lights for power on/off, but these controls are not relevant to operation under the emulator. - -A 2400-foot reel of tape has a capacity of 2-22 million characters, depending on the size of the blocks recorded. A typical capacity is 10-15 million characters. - -Data for tape volumes ("reels") may be maintained externally as ordinary workstation files. Such a file is referred to as a "tape image." This tape drive implementation supports the following tape image formats: - - * **"`.bcd`"** -- In this format, each 7-bit frame on the tape is stored in one 8-bit byte. The low-order six bits of the byte contain the data, low-order bit last. The seventh bit is parity. The high-order bit in the byte is a one if this frame starts a physical block on the tape. A tape mark (end-of-file indicator) is represented by a single-frame block with the hexadecimal value 8F (i.e., an even-parity BCL greater-than-or-equal character). The same tape mark encoding is used with both even and odd parity recording. - * **Text** -- In this format, the tape image is a standard text file. Each 7-bit frame on the tape is stored as one ASCII character. Each physical tape block is represented as one line of text in the image file. Lines of text may be delimited by a carriage-return, a line-feed (new-line), a form-feed, a carriage-return/line-feed pair, or a carriage-return/form-feed pair. A tape image can be loaded into the system as either even or odd parity, but the characters in the text image are represented the same either way. A tape mark is represented by a line with a single "`}`" (greater-than-or-equal) character. Note that in this format, the length of a tape block is determined by the length of its ASCII line of text, so trailing spaces are significant, and tab-compression may not be used. - -Lines of text for a tape image should be composed using the emulator's version of the B5500 64-character set: - -``` - 0 1 2 3 4 5 6 7 - 8 9 # @ ? : > { - + A B C D E F G - H I . [ & ( < ~ - | J K L M N O P - Q R $ * - 0 ; { - / S T U V W X - Y Z , % ! = } " -``` - -The B5500 used five special Algol characters that do not have ASCII equivalents. The emulator uses the following ASCII substitutions for them: - - * `~` for left-arrow - * `|` for the small-cross (multiplication sign) - * `{` for less-than-or-equal - * `}` for greater-than-or-equal - * `!` for not-equal - -The tape drive interface will translate lower-case ASCII letters to upper case. The drive will consider all other ASCII or Unicode characters to be vertical-parity errors in a tape frame. None of the current tape image formats support the concept of longitudinal (block-check) parity. - -By default, the B5500 MCP brackets each file on the tape with 80-character label records. These label records serve to identify the tape reel and file names, and to provide the record size, block size, creation date, and expiration date for the tape. - -Tape files have a two-part name, the MFID (multi-file identifier, which is the same for all files on one logical volume), and the FID (file identifier), which should uniquely identify the file within the logical volume. Each of these names can be up to seven characters in length. A logical tape volume can extend across multiple physical reels of tape. - -This two-level naming convention was first established for tapes on the B5000, and later carried into the design of the B5500 MCP disk directory. It eventually made its way into the design of the disk directory for Gary Kildall's CPM operating system. - -When a tape is mounted on a drive and the drive made ready, the MCP will automatically read the label and assign the drive to any program that has asked for a file by the names specified on the label. If only the MFID matches, the MCP will automatically search up-tape for a file with the matching FID. Unlabeled tapes are also supported by the MCP, but are less convenient, as they typically need to be assigned manually to a program using the SPO `UL` command. - -Tapes marked as "scratch" will be assigned automatically to programs requiring an output tape. Tapes may be "scratched" using the SPO `PG` command. - - -# Tape Drive Control Panel # - -The user interface for the emulated tape drive consists of the following controls and indicators: - - * **UNLOAD** -- this black button is used to unload a tape image from the drive. This button is active only when an image is currently loaded, the drive is in local (not-ready) status, and the tape is positioned at BOT (beginning of tape). - * **LOAD** -- this black button is used to load a tape image file into the drive as if it were a reel of tape. The button is active only when no image is currently loaded into the drive. Clicking this button will bring up the tape loader dialog to select an image file, as described below. - * **LOCAL** -- this yellow button/indicator lights when the drive is in a not-ready status. The drive becomes ready when a tape image is loaded and the **REMOTE** button is clicked. It becomes not-ready when this button is clicked. - * **REMOTE** -- this yellow button/indicator lights when the drive is in a ready status. The drive becomes ready when a tape image is loaded and this button is clicked. It becomes not-ready when the **LOCAL** button is clicked. - * **WRITE RING** -- This red button/indicator is used to signal and control whether the tape image that is currently mounted is enabled for writing. When this button is lit, the image is writable. Writable status can only be set (i.e., the write ring can be inserted) during the process of loading a tape image. Writable status can be reset (i.e., the write ring can be pulled) at any time while an image is loaded, even while it is in use. - * **REWIND** -- clicking this black button will rewind the tape image to its load point at the beginning of the image. The button is active only when a tape image is loaded into the drive and the drive is in local status. - -When a tape image is loaded into the drive, an icon representing a reel of tape will appear next to the rewind button. While not shown on the picture above, there are white annunciators along the right edge of the panel showing the status of the tape image: - - * **UNLOADED** -- indicates that no tape image is currently loaded into the drive. - * **AT BOT** -- indicates that a tape image is loaded and is currently positioned at the beginning of the tape, or "load point." - * **AT EOT** -- indicates that a tape image is loaded and is currently positioned past the end-of-tape marker. - * **REWINDING** -- indicates that the drive is currently rewinding to the load point of the image. - -Below the buttons is a text area. This is initially blank, but after a tape image is loaded into the drive it will display either the name of the image file that was loaded, or "`(blank tape)`" if a blank image was loaded. - -Below the text is a progress bar. This shows the relative amount of data from the tape image remaining on the "supply reel." When you load a tape image into the drive, this bar is set to 100% at its far right edge. As the tape moves in the forward direction, the length of the bar will decrease towards the left; as the tape moves backward, the length of the bar will increase towards the right. - - -## Loading a Tape Image ## - -Before a tape drive can be assigned to a user program or the MCP, a tape image must be loaded into it. Clicking the **LOAD** button initiates the load process and displays a dialog box for that purpose: - -> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-MagTapeLoader.png](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-MagTapeLoader.png) - -There are two types of tape images that can be loaded into the drive: an image from an existing file, and a blank image. - - 1. To load an image from an existing file, use the file-picker control at the top of the dialog to select the file from your local file system. The interface will infer the type of image format from the file name extension as follows: - * "`.bcd`" implies a ".bcd" tape image. - * Anything else implies an "ASCII Odd Parity" text image. - 1. To load a blank image into the drive, do not use the file-picker control. Select "`(blank tape)`" from the **Format** drop-down list. This is the default setting when the loader dialog opens. - -You may use the **Format** drop-down list to change the inferred image type after a file is loaded. Internally, the emulator uses the .bcd format to store and manipulate the tape image data. It converts between this format and the external format as necessary when loading and unloading tape images. - -A file must be selected unless you are loading a blank tape, in which case any file that may have been selected is ignored. - -Once a tape image is selected, there are two optional controls that you may use: - - * **Write Ring** -- checking this box will make the image writable and illuminate the Write Ring button on the tape drive window. When loading a blank tape image, this setting will be forced. - * **Tape Length** -- selecting an item from this drop-down list will specify the total length of the tape image. This is significant only when the **Write Ring** box is checked and the image is to be writable. The drop-down list of tape lengths is disabled otherwise. There are three choices for length: 600 feet, 1200 feet, and 2400 feet (the default), corresponding to the most common reel sizes that were used for 7-track magnetic tape. If an image file is larger than the selected length, the actual image length plus the equivalent of 20 feet of tape will be used instead. - -You can select only one file at a time to load into the drive. The emulator does not attempt to verify that any file you load is a valid tape image. An invalid image file or a mismatch between the selected format and the image data will generally result in parity errors during read operations. - -Once you have the parameters for the tape image specified, click the **OK** button to complete the load process, or click **Cancel** to abort the load and leave the drive in an unloaded state. Clicking either of these buttons will cause the loader dialog to close. - -After the tape image is loaded into the drive, the drive will remain in local (not-ready) status. You must click the **REMOTE** button to make the drive ready and available to the MCP. - - -## Unloading a Tape Image ## - -If you load a tape image into the drive with its write ring enabled, and the system actually writes on that image, then when you unload the image from the drive the emulator will offer you the option to save the image. Note that when the write ring is enabled, any writes to the tape do not affect the file from which you loaded the tape image. All tape operations affect only the internal tape image data resident in memory. - -If the image is read-only or has not been written to, clicking the **UNLOAD** button will simply discard the internal image data and leave the drive in an unloaded state. - -If the image has been written to, clicking the **UNLOAD** button will cause a dialog box to open, asking whether you want to save the image data. - - * If you click **Cancel** on this dialog, the internal image data will be discarded and the drive set to an unloaded state, as above. - * If you click **OK** on this dialog, the emulator will open a blank window and format the final contents of the internal tape image to that window as an ASCII text image. For full-tape images, this conversion from the internal ".bcd" format to ASCII text may take several seconds. - * Once the tape image data is displayed in the window, you may save the text to a file on your local workstation or copy/paste the text into another program, such as a text editor. - * If you choose to paste the text into another program, you should disable any options in that program that will trim trailing spaces from lines or compress multiple spaces using tab characters, as these may cause the image to become corrupted. - * Once you have saved or copied the tape image data, simply close the window that was opened by the **UNLOAD** button. - -Note that regardless of the format of the image you loaded into the drive, unloading and saving the internal image data will always be done using the ASCII text format. Other formats involve binary data with non-printing characters, which at present are not practical to output from a web browser to your local file system. - - -# Operating the Magnetic Tape Drive # - -The basic technique used with the tape drive is simple -- use the **LOAD** button to select a tape image for loading into the drive, then click the **REMOTE** button to make the drive ready. The MCP should recognize the ready status and attempt to read the tape label. If the file names in the label match the file names requested by a program, the drive will be assigned to the program automatically. Automatic name matching can be overridden on input using the SPO `IL` and `UL` commands. - -Tape output is generally done only to "scratch" volumes, which may be created with the `PG` SPO command. To scratch an existing tape, simply enter "`PG MT`x". Its existing volume number will be preserved in the scratch label. To scratch a tape and assign a volume number, enter "`PG MT`x`-`nnnnn", where "nnnnn" is the volume number, which may be one to five digits in length. The "`-`" delimiter is required and may not be prefixed or suffixed by spaces. - -The B5500 MCP will treat blank tapes as scratch with a volume number of 00000. - -The `OU` SPO command can be used to direct output to a specific drive. - -You can stop the drive at any time and make it not-ready by clicking the **LOCAL** button. Restart it by clicking the **REMOTE** button. Whenever the drive is in a not-ready status, you can rewind or unload the tape image. - -Library/Maintenance is the portion of the MCP that manages disk files and maintains the disk directory. Among its features is the capability to dump disk files to and load disk files from magnetic tape. This is typically used for file backup, archiving, and transferring files among systems. - -Disk files can be loaded from Library/Maintenance volumes such as the `SYSTEM`, `SYMBOL1`, and `SYMBOL2` tape images using the `LOAD` and `ADD` control card commands, e.g., - -``` - ?LOAD FROM SYSTEM ESPOL/DISK, COBOL/DISK, DUMP/ANALYZE -``` - -A control card command can be continued across multiple card images by terminating a card with a hyphen ("`-`") wherever a word or other punctuation character might appear. The continuation card(s) that follow must not have an invalid character in column 1. - -All files having the same first or last identifier in their file name may be loaded by specifying `MFID/=` or `=/FID`. All files from a tape can be loaded by specifying `=/=`. Library/Maintenance will not overwrite certain critical system files, such as the current MCP, Intrinsics, and system log. - -The `ADD` command works the same as `LOAD`, except that it loads only files that are not already in the disk directory. - -Disk files can be dumped to Library/Maintenance volumes using the `DUMP` control card command, e.g., - -``` - ?DUMP TO BKUP CANDE/USERS, =/DISK, DATA/= -``` - -The MCP will automatically detect the end of a tape reel and request another tape if the amount of data to be dumped overflows the first reel. The MCP will refuse to dump certain files, such as the system log and disk directory. - -See Section 4, and in particular page 4-15 ff, in http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1024916_B5500_B5700_OperMan_Sep68.pdf for more information on control card syntax and the Library/Maintenance commands. \ No newline at end of file diff --git a/WebUIUsingTheMagTapeDrive.wiki b/WebUIUsingTheMagTapeDrive.wiki index 4d1703e..beb39cf 100644 --- a/WebUIUsingTheMagTapeDrive.wiki +++ b/WebUIUsingTheMagTapeDrive.wiki @@ -1,39 +1,36 @@ -#summary Instructions for using the magnetic tape drive with the retro-B5500 emulator in a web browser. -#labels Burroughs,B5500,emulator,retro-b5500,operator,magnetic tape,B425 - -= WebUI Using the Magnetic Tape Drive = - - - -The B5500 supported several 7-track tape drive models, with recording densities of 200, 555, and 800 bits per inch. Not all drives supported all densities. Tape speed ranged from 83 to 120 inches per second, with data transfer ranges ranging in concert from 66,000 to 96,000 characters per second. Blocks of data on the tape were delimited by a 0.75-inch unrecorded gap. Rewind speed was 320 inches/second, taking about 90 seconds for a full 2400-foot reel of tape. - -All drives could record in even or odd parity. With even parity (also termed alpha mode), characters were translated to and from BCL (Burroughs Common Language), which was very similar to the character codes used with IBM 1401 tape drives. With odd parity (binary mode), bits were recorded without translation from their internal representation in the B5500 core memory. - -A B5500 system could have up to 16 tape drives, identified as `MTA` through `MTT` (with letters `G`, `I`, `O`, and `Q` not used). - -Here is a view of a B42x-series drive with its front door open, showing the tape head, pinch-roller mechanisms, and tape columns: - - https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/MagTape-Drive-burr0136.jpg - - -= Background = - -The tape drive interface we have developed for the web-based emulator is modeled after the 90 inch-per-second B425, operating at 800 bpi. This interface opens in a separate window when the *POWER ON* button is activated on the emulator console: - - https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-MagTapeDrive.png - -The B425 had additional buttons and lights for power on/off, but these controls are not relevant to operation under the emulator. - -A 2400-foot reel of tape has a capacity of 2-22 million characters, depending on the size of the blocks recorded. A typical capacity is 10-15 million characters. - -Data for tape volumes ("reels") may be maintained externally as ordinary workstation files. Such a file is referred to as a "tape image." This tape drive implementation supports the following tape image formats: - - * *"`.bcd`"* -- In this format, each 7-bit frame on the tape is stored in one 8-bit byte. The low-order six bits of the byte contain the data, low-order bit last. The seventh bit is parity. The high-order bit in the byte is a one if this frame starts a physical block on the tape. A tape mark (end-of-file indicator) is represented by a single-frame block with the hexadecimal value 8F (i.e., an even-parity BCL greater-than-or-equal character). The same tape mark encoding is used with both even and odd parity recording. - * *Text* -- In this format, the tape image is a standard text file. Each 7-bit frame on the tape is stored as one ASCII character. Each physical tape block is represented as one line of text in the image file. Lines of text may be delimited by a carriage-return, a line-feed (new-line), a form-feed, a carriage-return/line-feed pair, or a carriage-return/form-feed pair. A tape image can be loaded into the system as either even or odd parity, but the characters in the text image are represented the same either way. A tape mark is represented by a line with a single "`}`" (greater-than-or-equal) character. Note that in this format, the length of a tape block is determined by the length of its ASCII line of text, so trailing spaces are significant, and tab-compression may not be used. - -Lines of text for a tape image should be composed using the emulator's version of the B5500 64-character set: - - {{{ +# WebUI Using the Magnetic Tape Drive # + + + +The B5500 supported several 7-track tape drive models, with recording densities of 200, 555, and 800 bits per inch. Not all drives supported all densities. Tape speed ranged from 83 to 120 inches per second, with data transfer ranges ranging in concert from 66,000 to 96,000 characters per second. Blocks of data on the tape were delimited by a 0.75-inch unrecorded gap. Rewind speed was 320 inches/second, taking about 90 seconds for a full 2400-foot reel of tape. + +All drives could record in even or odd parity. With even parity (also termed alpha mode), characters were translated to and from BCL (Burroughs Common Language), which was very similar to the character codes used with IBM 1401 tape drives. With odd parity (binary mode), bits were recorded without translation from their internal representation in the B5500 core memory. + +A B5500 system could have up to 16 tape drives, identified as `MTA` through `MTT` (with letters `G`, `I`, `O`, and `Q` not used). + +Here is a view of a B42x-series drive with its front door open, showing the tape head, pinch-roller mechanisms, and tape columns: + +> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/MagTape-Drive-burr0136.jpg](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/MagTape-Drive-burr0136.jpg) + + +# Background # + +The tape drive interface we have developed for the web-based emulator is modeled after the 90 inch-per-second B425, operating at 800 bpi. This interface opens in a separate window when the **POWER ON** button is activated on the emulator console: + +> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-MagTapeDrive.png](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-MagTapeDrive.png) + +The B425 had additional buttons and lights for power on/off, but these controls are not relevant to operation under the emulator. + +A 2400-foot reel of tape has a capacity of 2-22 million characters, depending on the size of the blocks recorded. A typical capacity is 10-15 million characters. + +Data for tape volumes ("reels") may be maintained externally as ordinary workstation files. Such a file is referred to as a "tape image." This tape drive implementation supports the following tape image formats: + + * **"`.bcd`"** -- In this format, each 7-bit frame on the tape is stored in one 8-bit byte. The low-order six bits of the byte contain the data, low-order bit last. The seventh bit is parity. The high-order bit in the byte is a one if this frame starts a physical block on the tape. A tape mark (end-of-file indicator) is represented by a single-frame block with the hexadecimal value 8F (i.e., an even-parity BCL greater-than-or-equal character). The same tape mark encoding is used with both even and odd parity recording. + * **Text** -- In this format, the tape image is a standard text file. Each 7-bit frame on the tape is stored as one ASCII character. Each physical tape block is represented as one line of text in the image file. Lines of text may be delimited by a carriage-return, a line-feed (new-line), a form-feed, a carriage-return/line-feed pair, or a carriage-return/form-feed pair. A tape image can be loaded into the system as either even or odd parity, but the characters in the text image are represented the same either way. A tape mark is represented by a line with a single "`}`" (greater-than-or-equal) character. Note that in this format, the length of a tape block is determined by the length of its ASCII line of text, so trailing spaces are significant, and tab-compression may not be used. + +Lines of text for a tape image should be composed using the emulator's version of the B5500 64-character set: + +``` 0 1 2 3 4 5 6 7 8 9 # @ ? : > { + A B C D E F G @@ -42,130 +39,130 @@ Lines of text for a tape image should be composed using the emulator's version o Q R $ * - 0 ; { / S T U V W X Y Z , % ! = } " - }}} - -The B5500 used five special Algol characters that do not have ASCII equivalents. The emulator uses the following ASCII substitutions for them: - - * `~` for left-arrow - * `|` for the small-cross (multiplication sign) - * `{` for less-than-or-equal - * `}` for greater-than-or-equal - * `!` for not-equal - -The tape drive interface will translate lower-case ASCII letters to upper case. The drive will consider all other ASCII or Unicode characters to be vertical-parity errors in a tape frame. None of the current tape image formats support the concept of longitudinal (block-check) parity. - -By default, the B5500 MCP brackets each file on the tape with 80-character label records. These label records serve to identify the tape reel and file names, and to provide the record size, block size, creation date, and expiration date for the tape. - -Tape files have a two-part name, the MFID (multi-file identifier, which is the same for all files on one logical volume), and the FID (file identifier), which should uniquely identify the file within the logical volume. Each of these names can be up to seven characters in length. A logical tape volume can extend across multiple physical reels of tape. - -This two-level naming convention was first established for tapes on the B5000, and later carried into the design of the B5500 MCP disk directory. It eventually made its way into the design of the disk directory for Gary Kildall's CPM operating system. - -When a tape is mounted on a drive and the drive made ready, the MCP will automatically read the label and assign the drive to any program that has asked for a file by the names specified on the label. If only the MFID matches, the MCP will automatically search up-tape for a file with the matching FID. Unlabeled tapes are also supported by the MCP, but are less convenient, as they typically need to be assigned manually to a program using the SPO `UL` command. - -Tapes marked as "scratch" will be assigned automatically to programs requiring an output tape. Tapes may be "scratched" using the SPO `PG` command. - - -= Tape Drive Control Panel = - -The user interface for the emulated tape drive consists of the following controls and indicators: - - * *UNLOAD* -- this black button is used to unload a tape image from the drive. This button is active only when an image is currently loaded, the drive is in local (not-ready) status, and the tape is positioned at BOT (beginning of tape). - * *LOAD* -- this black button is used to load a tape image file into the drive as if it were a reel of tape. The button is active only when no image is currently loaded into the drive. Clicking this button will bring up the tape loader dialog to select an image file, as described below. - * *LOCAL* -- this yellow button/indicator lights when the drive is in a not-ready status. The drive becomes ready when a tape image is loaded and the *REMOTE* button is clicked. It becomes not-ready when this button is clicked. - * *REMOTE* -- this yellow button/indicator lights when the drive is in a ready status. The drive becomes ready when a tape image is loaded and this button is clicked. It becomes not-ready when the *LOCAL* button is clicked. - * *WRITE RING* -- This red button/indicator is used to signal and control whether the tape image that is currently mounted is enabled for writing. When this button is lit, the image is writable. Writable status can only be set (i.e., the write ring can be inserted) during the process of loading a tape image. Writable status can be reset (i.e., the write ring can be pulled) at any time while an image is loaded, even while it is in use. - * *REWIND* -- clicking this black button will rewind the tape image to its load point at the beginning of the image. The button is active only when a tape image is loaded into the drive and the drive is in local status. - -When a tape image is loaded into the drive, an icon representing a reel of tape will appear next to the rewind button. While not shown on the picture above, there are white annunciators along the right edge of the panel showing the status of the tape image: - - * *UNLOADED* -- indicates that no tape image is currently loaded into the drive. - * *AT BOT* -- indicates that a tape image is loaded and is currently positioned at the beginning of the tape, or "load point." - * *AT EOT* -- indicates that a tape image is loaded and is currently positioned past the end-of-tape marker. - * *REWINDING* -- indicates that the drive is currently rewinding to the load point of the image. - -Below the buttons is a text area. This is initially blank, but after a tape image is loaded into the drive it will display either the name of the image file that was loaded, or "`(blank tape)`" if a blank image was loaded. - -Below the text is a progress bar. This shows the relative amount of data from the tape image remaining on the "supply reel." When you load a tape image into the drive, this bar is set to 100% at its far right edge. As the tape moves in the forward direction, the length of the bar will decrease towards the left; as the tape moves backward, the length of the bar will increase towards the right. - - -== Loading a Tape Image == - -Before a tape drive can be assigned to a user program or the MCP, a tape image must be loaded into it. Clicking the *LOAD* button initiates the load process and displays a dialog box for that purpose: - - https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-MagTapeLoader.png - -There are two types of tape images that can be loaded into the drive: an image from an existing file, and a blank image. - - # To load an image from an existing file, use the file-picker control at the top of the dialog to select the file from your local file system. The interface will infer the type of image format from the file name extension as follows: - * "`.bcd`" implies a ".bcd" tape image. - * Anything else implies an "ASCII Odd Parity" text image. - # To load a blank image into the drive, do not use the file-picker control. Select "`(blank tape)`" from the *Format* drop-down list. This is the default setting when the loader dialog opens. - -You may use the *Format* drop-down list to change the inferred image type after a file is loaded. Internally, the emulator uses the .bcd format to store and manipulate the tape image data. It converts between this format and the external format as necessary when loading and unloading tape images. - -A file must be selected unless you are loading a blank tape, in which case any file that may have been selected is ignored. - -Once a tape image is selected, there are two optional controls that you may use: - - * *Write Ring* -- checking this box will make the image writable and illuminate the Write Ring button on the tape drive window. When loading a blank tape image, this setting will be forced. - * *Tape Length* -- selecting an item from this drop-down list will specify the total length of the tape image. This is significant only when the *Write Ring* box is checked and the image is to be writable. The drop-down list of tape lengths is disabled otherwise. There are three choices for length: 600 feet, 1200 feet, and 2400 feet (the default), corresponding to the most common reel sizes that were used for 7-track magnetic tape. If an image file is larger than the selected length, the actual image length plus the equivalent of 20 feet of tape will be used instead. - -You can select only one file at a time to load into the drive. The emulator does not attempt to verify that any file you load is a valid tape image. An invalid image file or a mismatch between the selected format and the image data will generally result in parity errors during read operations. - -Once you have the parameters for the tape image specified, click the *OK* button to complete the load process, or click *Cancel* to abort the load and leave the drive in an unloaded state. Clicking either of these buttons will cause the loader dialog to close. - -After the tape image is loaded into the drive, the drive will remain in local (not-ready) status. You must click the *REMOTE* button to make the drive ready and available to the MCP. - - -== Unloading a Tape Image == - -If you load a tape image into the drive with its write ring enabled, and the system actually writes on that image, then when you unload the image from the drive the emulator will offer you the option to save the image. Note that when the write ring is enabled, any writes to the tape do not affect the file from which you loaded the tape image. All tape operations affect only the internal tape image data resident in memory. - -If the image is read-only or has not been written to, clicking the *UNLOAD* button will simply discard the internal image data and leave the drive in an unloaded state. - -If the image has been written to, clicking the *UNLOAD* button will cause a dialog box to open, asking whether you want to save the image data. - - * If you click *Cancel* on this dialog, the internal image data will be discarded and the drive set to an unloaded state, as above. - * If you click *OK* on this dialog, the emulator will open a blank window and format the final contents of the internal tape image to that window as an ASCII text image. For full-tape images, this conversion from the internal ".bcd" format to ASCII text may take several seconds. - * Once the tape image data is displayed in the window, you may save the text to a file on your local workstation or copy/paste the text into another program, such as a text editor. - * If you choose to paste the text into another program, you should disable any options in that program that will trim trailing spaces from lines or compress multiple spaces using tab characters, as these may cause the image to become corrupted. - * Once you have saved or copied the tape image data, simply close the window that was opened by the *UNLOAD* button. - -Note that regardless of the format of the image you loaded into the drive, unloading and saving the internal image data will always be done using the ASCII text format. Other formats involve binary data with non-printing characters, which at present are not practical to output from a web browser to your local file system. - - -= Operating the Magnetic Tape Drive = - -The basic technique used with the tape drive is simple -- use the *LOAD* button to select a tape image for loading into the drive, then click the *REMOTE* button to make the drive ready. The MCP should recognize the ready status and attempt to read the tape label. If the file names in the label match the file names requested by a program, the drive will be assigned to the program automatically. Automatic name matching can be overridden on input using the SPO `IL` and `UL` commands. - -Tape output is generally done only to "scratch" volumes, which may be created with the `PG` SPO command. To scratch an existing tape, simply enter "`PG MT`x". Its existing volume number will be preserved in the scratch label. To scratch a tape and assign a volume number, enter "`PG MT`x`-`nnnnn", where "nnnnn" is the volume number, which may be one to five digits in length. The "`-`" delimiter is required and may not be prefixed or suffixed by spaces. - -The B5500 MCP will treat blank tapes as scratch with a volume number of 00000. - -The `OU` SPO command can be used to direct output to a specific drive. - -You can stop the drive at any time and make it not-ready by clicking the *LOCAL* button. Restart it by clicking the *REMOTE* button. Whenever the drive is in a not-ready status, you can rewind or unload the tape image. - -Library/Maintenance is the portion of the MCP that manages disk files and maintains the disk directory. Among its features is the capability to dump disk files to and load disk files from magnetic tape. This is typically used for file backup, archiving, and transferring files among systems. - -Disk files can be loaded from Library/Maintenance volumes such as the `SYSTEM`, `SYMBOL1`, and `SYMBOL2` tape images using the `LOAD` and `ADD` control card commands, e.g., - - {{{ +``` + +The B5500 used five special Algol characters that do not have ASCII equivalents. The emulator uses the following ASCII substitutions for them: + + * `~` for left-arrow + * `|` for the small-cross (multiplication sign) + * `{` for less-than-or-equal + * `}` for greater-than-or-equal + * `!` for not-equal + +The tape drive interface will translate lower-case ASCII letters to upper case. The drive will consider all other ASCII or Unicode characters to be vertical-parity errors in a tape frame. None of the current tape image formats support the concept of longitudinal (block-check) parity. + +By default, the B5500 MCP brackets each file on the tape with 80-character label records. These label records serve to identify the tape reel and file names, and to provide the record size, block size, creation date, and expiration date for the tape. + +Tape files have a two-part name, the MFID (multi-file identifier, which is the same for all files on one logical volume), and the FID (file identifier), which should uniquely identify the file within the logical volume. Each of these names can be up to seven characters in length. A logical tape volume can extend across multiple physical reels of tape. + +This two-level naming convention was first established for tapes on the B5000, and later carried into the design of the B5500 MCP disk directory. It eventually made its way into the design of the disk directory for Gary Kildall's CPM operating system. + +When a tape is mounted on a drive and the drive made ready, the MCP will automatically read the label and assign the drive to any program that has asked for a file by the names specified on the label. If only the MFID matches, the MCP will automatically search up-tape for a file with the matching FID. Unlabeled tapes are also supported by the MCP, but are less convenient, as they typically need to be assigned manually to a program using the SPO `UL` command. + +Tapes marked as "scratch" will be assigned automatically to programs requiring an output tape. Tapes may be "scratched" using the SPO `PG` command. + + +# Tape Drive Control Panel # + +The user interface for the emulated tape drive consists of the following controls and indicators: + + * **UNLOAD** -- this black button is used to unload a tape image from the drive. This button is active only when an image is currently loaded, the drive is in local (not-ready) status, and the tape is positioned at BOT (beginning of tape). + * **LOAD** -- this black button is used to load a tape image file into the drive as if it were a reel of tape. The button is active only when no image is currently loaded into the drive. Clicking this button will bring up the tape loader dialog to select an image file, as described below. + * **LOCAL** -- this yellow button/indicator lights when the drive is in a not-ready status. The drive becomes ready when a tape image is loaded and the **REMOTE** button is clicked. It becomes not-ready when this button is clicked. + * **REMOTE** -- this yellow button/indicator lights when the drive is in a ready status. The drive becomes ready when a tape image is loaded and this button is clicked. It becomes not-ready when the **LOCAL** button is clicked. + * **WRITE RING** -- This red button/indicator is used to signal and control whether the tape image that is currently mounted is enabled for writing. When this button is lit, the image is writable. Writable status can only be set (i.e., the write ring can be inserted) during the process of loading a tape image. Writable status can be reset (i.e., the write ring can be pulled) at any time while an image is loaded, even while it is in use. + * **REWIND** -- clicking this black button will rewind the tape image to its load point at the beginning of the image. The button is active only when a tape image is loaded into the drive and the drive is in local status. + +When a tape image is loaded into the drive, an icon representing a reel of tape will appear next to the rewind button. While not shown on the picture above, there are white annunciators along the right edge of the panel showing the status of the tape image: + + * **UNLOADED** -- indicates that no tape image is currently loaded into the drive. + * **AT BOT** -- indicates that a tape image is loaded and is currently positioned at the beginning of the tape, or "load point." + * **AT EOT** -- indicates that a tape image is loaded and is currently positioned past the end-of-tape marker. + * **REWINDING** -- indicates that the drive is currently rewinding to the load point of the image. + +Below the buttons is a text area. This is initially blank, but after a tape image is loaded into the drive it will display either the name of the image file that was loaded, or "`(blank tape)`" if a blank image was loaded. + +Below the text is a progress bar. This shows the relative amount of data from the tape image remaining on the "supply reel." When you load a tape image into the drive, this bar is set to 100% at its far right edge. As the tape moves in the forward direction, the length of the bar will decrease towards the left; as the tape moves backward, the length of the bar will increase towards the right. + + +## Loading a Tape Image ## + +Before a tape drive can be assigned to a user program or the MCP, a tape image must be loaded into it. Clicking the **LOAD** button initiates the load process and displays a dialog box for that purpose: + +> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-MagTapeLoader.png](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-MagTapeLoader.png) + +There are two types of tape images that can be loaded into the drive: an image from an existing file, and a blank image. + + 1. To load an image from an existing file, use the file-picker control at the top of the dialog to select the file from your local file system. The interface will infer the type of image format from the file name extension as follows: + * "`.bcd`" implies a ".bcd" tape image. + * Anything else implies an "ASCII Odd Parity" text image. + 1. To load a blank image into the drive, do not use the file-picker control. Select "`(blank tape)`" from the **Format** drop-down list. This is the default setting when the loader dialog opens. + +You may use the **Format** drop-down list to change the inferred image type after a file is loaded. Internally, the emulator uses the .bcd format to store and manipulate the tape image data. It converts between this format and the external format as necessary when loading and unloading tape images. + +A file must be selected unless you are loading a blank tape, in which case any file that may have been selected is ignored. + +Once a tape image is selected, there are two optional controls that you may use: + + * **Write Ring** -- checking this box will make the image writable and illuminate the Write Ring button on the tape drive window. When loading a blank tape image, this setting will be forced. + * **Tape Length** -- selecting an item from this drop-down list will specify the total length of the tape image. This is significant only when the **Write Ring** box is checked and the image is to be writable. The drop-down list of tape lengths is disabled otherwise. There are three choices for length: 600 feet, 1200 feet, and 2400 feet (the default), corresponding to the most common reel sizes that were used for 7-track magnetic tape. If an image file is larger than the selected length, the actual image length plus the equivalent of 20 feet of tape will be used instead. + +You can select only one file at a time to load into the drive. The emulator does not attempt to verify that any file you load is a valid tape image. An invalid image file or a mismatch between the selected format and the image data will generally result in parity errors during read operations. + +Once you have the parameters for the tape image specified, click the **OK** button to complete the load process, or click **Cancel** to abort the load and leave the drive in an unloaded state. Clicking either of these buttons will cause the loader dialog to close. + +After the tape image is loaded into the drive, the drive will remain in local (not-ready) status. You must click the **REMOTE** button to make the drive ready and available to the MCP. + + +## Unloading a Tape Image ## + +If you load a tape image into the drive with its write ring enabled, and the system actually writes on that image, then when you unload the image from the drive the emulator will offer you the option to save the image. Note that when the write ring is enabled, any writes to the tape do not affect the file from which you loaded the tape image. All tape operations affect only the internal tape image data resident in memory. + +If the image is read-only or has not been written to, clicking the **UNLOAD** button will simply discard the internal image data and leave the drive in an unloaded state. + +If the image has been written to, clicking the **UNLOAD** button will cause a dialog box to open, asking whether you want to save the image data. + + * If you click **Cancel** on this dialog, the internal image data will be discarded and the drive set to an unloaded state, as above. + * If you click **OK** on this dialog, the emulator will open a blank window and format the final contents of the internal tape image to that window as an ASCII text image. For full-tape images, this conversion from the internal ".bcd" format to ASCII text may take several seconds. + * Once the tape image data is displayed in the window, you may save the text to a file on your local workstation or copy/paste the text into another program, such as a text editor. + * If you choose to paste the text into another program, you should disable any options in that program that will trim trailing spaces from lines or compress multiple spaces using tab characters, as these may cause the image to become corrupted. + * Once you have saved or copied the tape image data, simply close the window that was opened by the **UNLOAD** button. + +Note that regardless of the format of the image you loaded into the drive, unloading and saving the internal image data will always be done using the ASCII text format. Other formats involve binary data with non-printing characters, which at present are not practical to output from a web browser to your local file system. + + +# Operating the Magnetic Tape Drive # + +The basic technique used with the tape drive is simple -- use the **LOAD** button to select a tape image for loading into the drive, then click the **REMOTE** button to make the drive ready. The MCP should recognize the ready status and attempt to read the tape label. If the file names in the label match the file names requested by a program, the drive will be assigned to the program automatically. Automatic name matching can be overridden on input using the SPO `IL` and `UL` commands. + +Tape output is generally done only to "scratch" volumes, which may be created with the `PG` SPO command. To scratch an existing tape, simply enter "`PG MT`x". Its existing volume number will be preserved in the scratch label. To scratch a tape and assign a volume number, enter "`PG MT`x`-`nnnnn", where "nnnnn" is the volume number, which may be one to five digits in length. The "`-`" delimiter is required and may not be prefixed or suffixed by spaces. + +The B5500 MCP will treat blank tapes as scratch with a volume number of 00000. + +The `OU` SPO command can be used to direct output to a specific drive. + +You can stop the drive at any time and make it not-ready by clicking the **LOCAL** button. Restart it by clicking the **REMOTE** button. Whenever the drive is in a not-ready status, you can rewind or unload the tape image. + +Library/Maintenance is the portion of the MCP that manages disk files and maintains the disk directory. Among its features is the capability to dump disk files to and load disk files from magnetic tape. This is typically used for file backup, archiving, and transferring files among systems. + +Disk files can be loaded from Library/Maintenance volumes such as the `SYSTEM`, `SYMBOL1`, and `SYMBOL2` tape images using the `LOAD` and `ADD` control card commands, e.g., + +``` ?LOAD FROM SYSTEM ESPOL/DISK, COBOL/DISK, DUMP/ANALYZE - }}} - -A control card command can be continued across multiple card images by terminating a card with a hyphen ("`-`") wherever a word or other punctuation character might appear. The continuation card(s) that follow must not have an invalid character in column 1. - -All files having the same first or last identifier in their file name may be loaded by specifying `MFID/=` or `=/FID`. All files from a tape can be loaded by specifying `=/=`. Library/Maintenance will not overwrite certain critical system files, such as the current MCP, Intrinsics, and system log. - -The `ADD` command works the same as `LOAD`, except that it loads only files that are not already in the disk directory. - -Disk files can be dumped to Library/Maintenance volumes using the `DUMP` control card command, e.g., - - {{{ +``` + +A control card command can be continued across multiple card images by terminating a card with a hyphen ("`-`") wherever a word or other punctuation character might appear. The continuation card(s) that follow must not have an invalid character in column 1. + +All files having the same first or last identifier in their file name may be loaded by specifying `MFID/=` or `=/FID`. All files from a tape can be loaded by specifying `=/=`. Library/Maintenance will not overwrite certain critical system files, such as the current MCP, Intrinsics, and system log. + +The `ADD` command works the same as `LOAD`, except that it loads only files that are not already in the disk directory. + +Disk files can be dumped to Library/Maintenance volumes using the `DUMP` control card command, e.g., + +``` ?DUMP TO BKUP CANDE/USERS, =/DISK, DATA/= - }}} - -The MCP will automatically detect the end of a tape reel and request another tape if the amount of data to be dumped overflows the first reel. The MCP will refuse to dump certain files, such as the system log and disk directory. - -See Section 4, and in particular page 4-15 ff, in http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1024916_B5500_B5700_OperMan_Sep68.pdf for more information on control card syntax and the Library/Maintenance commands. +``` + +The MCP will automatically detect the end of a tape reel and request another tape if the amount of data to be dumped overflows the first reel. The MCP will refuse to dump certain files, such as the system log and disk directory. + +See Section 4, and in particular page 4-15 ff, in http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1024916_B5500_B5700_OperMan_Sep68.pdf for more information on control card syntax and the Library/Maintenance commands. \ No newline at end of file diff --git a/WebUIUsingTheSPO.md b/WebUIUsingTheSPO.md deleted file mode 100644 index 567b7f6..0000000 --- a/WebUIUsingTheSPO.md +++ /dev/null @@ -1,178 +0,0 @@ -# WebUI Using the SPO # - - - -Virtually all operational control of a B5500 system was done through the supervisory keyboard/printer, or SPO. - -The term "SPO" (pronounced "spoh") apparently comes from the Burroughs 220, a late-1950s vacuum-tube computer system that preceded the B5500. The 220 had a Supervisory Print Out instruction, the assembly-language mnemonic for which was SPO. This instruction would cause a specified number of words to be printed from memory to the system's console printer/keyboard. - -Use of the term SPO persisted with Burroughs systems long after mechanical printer/keyboards were no longer used on the console and the operator interface transitioned to a video terminal. Modern Unisys MCP systems have for some time referred to the SPO as the Operator Display Terminal, or ODT. - - -# Background # - -Initially on the B5000 and early B5500s, the SPO was a Smith-Corona electric typewriter, modified to interface with the system's I/O Control Units. Later, Burroughs switched to a 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](http://bitsavers.org/pdf/burroughs/1023850_B100-200-300ref.pdf): - -> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B495-SPO-Image.png](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B495-SPO-Image.png) - -The printer and control buttons look very similar to the interface we have developed for the web-based emulator: - -> ![https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-SPO.png](https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-SPO.png) - -The SPO was intended solely as an operational control device and not as a timesharing terminal. User 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, for example, to edit source code. - -The SPO was also a peripheral I/O 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 message. 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 SPO output queue for the whole system or a specified job. - -In order to read from the SPO keyboard, the system must select an I/O unit and initiate a read operation. 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, although we have co-opted one for the "Algol Glyphs" feature discussed below. These controls are labeled as follows: - - * **POWER** -- this green light illuminates when power is applied to the unit. In the web-based emulator, it is always illuminated, and otherwise non-functional. - * **READY** -- this yellow light illuminates when the system initiates a read operation in response to the **INPUT REQUEST** button being clicked. - * **REMOTE** -- this yellow button/light indicates the unit is on-line to the rest of the system. If the unit is off-line, clicking the button makes it on-line. - * **LOCAL** -- this yellow button/light indicates the unit is off-line to the rest of the system. If the unit is on-line, clicking the button makes it off-line. When the unit is off-line, you can type comments onto the paper, which will be printed but not transmitted to the system. - * **INPUT REQUEST** this yellow button/light is used to raise the Keyboard Request interrupt. That interrupt in turn causes the MCP to initiate a read operation for the keyboard. When clicked, 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, click this yellow button to terminate input and signal the system that the command is complete. This also extinguishes the **READY** light. - * **ERROR** -- if you made a mistake while entering a command, click 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 unit. To cancel a partially-entered command and not reenter it, click **ERROR**. Then when the **READY** light comes back on, click **END OF MESSAGE**. - * **ALGOL GLYPHS** -- this yellow button/light was originally blank and unused. With the emulator, however, it is used to control whether the five special Algol characters are output as Unicode glyphs or as their ASCII substitutes. When the button is lit, the Algol characters are output as Unicode glyphs. Clicking the button toggles between the two output modes and converts existing glyphs on the "paper" between Unicode and ASCII as necessary. The default setting is taken from the current system configuration. - -The ASCII substitutions for the five special Algol characters are: - - * `~` for left-arrow - * `|` for the multiplication sign - * `{` for less-than-or-equal - * `}` for greater-than-or-equal - * `!` for not-equal - -You will never see the left-arrow glyph or its "`~`" substitute printed to the SPO. This character is used internally as an end-of-message marker. When the I/O Control Unit encounters the character in a buffer being output to the SPO, it terminates the data transfer and the "`~`" is not printed. - -On input, typing a "`~`" character has the same effect as clicking the **END OF MESSAGE** button. The SPO will also interpret the underscore ("`_`") character the same as "`~`" on input. - -The emulated SPO supports a few user-interface features that the Teletype Model 33 device did not: - - 1. 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 clicked. - 1. You can press the **Enter** key on your keyboard to end a message instead of clicking the **END OF MESSAGE** button. - 1. 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 clicking 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. - 1. Lower-case letters will be translated to upper case as you type them. Neither the B5500 nor the Model 33 supported lower case. - 1. When entering a command, you can press the **Backspace** key to correct errors. The Model 33 could not backspace. - 1. You can type faster than 10 characters/second, which was physically impossible with a Model 33. - -The original implementation of the emulated SPO simply captured keystrokes from the SPO window, echoing them to the "paper" or activating control functions as necessary. This worked fine on workstations that have a keyboard, but it does not work at all on tablets that emulate a keyboard on their touch screen. Most tablet-based browsers only display the on-screen keyboard when the focus is in a text area or other control that accepts keyboard input. Without a text area, you can't get a keyboard, and without a keyboard, you can't send keystrokes to the SPO window, so input on a touch screen was not possible. Tablets with a physical keyboard would still work, however. - -In order to support the touch interface of tablets, the SPO interface was changed in emulator version 1.00 to capture input using a standard text control instead of waiting for keystrokes to be directed to its window. When the system initiates a read to the SPO and the **READY** light illuminates, the SPO now enables a one-line text box at the bottom of the "paper" area. This text box is border-less, but does have a light-yellow background. As a bonus, the SPO now shows a cursor when you are entering text, and you can now do standard GIU editing and cut-and-paste during keyboard input. Once you signal end-of-message, the text box disappears and your input is transferred to the "paper" underneath it. - -If you are using a keyboard, you can use the **ESC**, **Enter**, and **Backspace** keys as described above. If you are using a touch interface, you must click the **INPUT REQUEST** and **END OF MESSAGE** buttons to control SPO input. - -A similar technique is now used when you click the **LOCAL** key to take the SPO off line. The same border-less text box will appear at the bottom of the "paper" area to accept your input. When you click **REMOTE**, the text box will disappear and its contents will be transferred to the "paper." If you press **Enter** or attempt to type more than 72 characters in the text box, the characters in the text box will be transferred to the "paper" and the text box cleared to accept more characters for the next line. When transitioning from **LOCAL** to **REMOTE** and the text box is non-empty, the text transferred to the "paper" will always be followed by a new-line. - - -# 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 click the **LOAD** button on the operator console. The **LOAD** button will not function until the SPO **REMOTE** light illuminates. - -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 on the Operator Console. - -When you resize the SPO window, the "paper" area will change size accordingly. If the window becomes too narrow for the current output, the output lines will be clipped on the right, although the output itself is unaffected and will reappear once the window is made larger. Below a certain minimum (and essentially usable) window size, the window contents will no longer resize and will be clipped. - -The area representing the "paper" for the SPO has a 5000-line scrollback. Once this limit is reached, the earliest lines are deleted. You can copy portions of the text on the paper using ordinary click-and-drag functions of your pointing device. - -Starting with release 1.00, the SPO "paper" is no longer implemented as an `