github.com/pkimpel.retro-b5500
1
0
Fork 0
mirror of https://github.com/pkimpel/retro-b5500.git synced 2026-04-14 08:59:13 +00:00
Code Releases Activity

Reconstruct Google Code wiki history from r344 on 2013-07-21.

Browse Source
This commit is contained in:
Paul Kimpel
2015-04-04 09:29:51 -07:00
parent 9dc71f9fd9
commit ad235cc3eb
1 changed files with 60 additions and 57 deletions
Download Patch File Download Diff File Expand all files Collapse all files

117
WebUIRunningTheEmulator.wiki
View File

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