github.com/pkimpel.retro-b5500
1
0
Fork 0
mirror of https://github.com/pkimpel/retro-b5500.git synced 2026-04-18 10:06:01 +00:00
Code Releases Activity

Reconstruct Google Code wiki history from r379 on 2013-11-25.

Browse Source
This commit is contained in:
Paul Kimpel
2015-04-04 09:58:43 -07:00
parent ccdcbcfbde
commit eadbed3be3
1 changed files with 178 additions and 32 deletions
Download Patch File Download Diff File Expand all files Collapse all files

210
WebUIHowToSetUpCANDE.wiki
View File

@@ -1,23 +1,21 @@
#summary Instructions for setting up the TSMCP and CANDE timesharing environment in the web-based retro-B5500 emulator.
#summary Instructions for setting up the TSMCP and CANDE timesharing environment in the web-based emulator.
#labels Burroughs,B5500,emulator,retro-b5500,TSMCP,CANDE,timesharing
= WebUI Setting Up TSMCP and CANDE =
<wiki:toc max_depth="2"/>
= D R A F T =
= Introduction =
This page describes how to setup the timesharing features to an existing emulator environment for the Burroughs B5500 system. At the end is a short sample session using [http://en.wikipedia.org/wiki/CANDE CANDE] (Command AND Edit "Candy" - a command line shell and text editor for MCP).
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 [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 [WebUIGettingStarted WebUI Getting Started].
Before proceeding, you should have a basic familiarity with the emulator, SPO, card reader, and tape drive. See the following pages for information these topics:
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:
* [WebUIRuningTheEmulator Running the Emulator]
* [WebUIRunningTheEmulator Running the Emulator]
* [WebUIUsingTheSPO Using the SPO]
* [WebUIUsingTheCardReader Using the Card Reader]
* [WebUIUsingTheMagTapeDrive Using the Magnetic Tape Drive]
@@ -28,7 +26,7 @@ There were several variations of the MCP (Master Control Program) operating syst
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 DTCU (Data Transmission Control Unit) 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.
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.
@@ -36,33 +34,33 @@ The DFMCP was enhanced to support this datacom equipment, becoming the Data Comm
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 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 (the 32K-word maximum for the B5500 was typical) available in the 1960s.
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.
Core memory for the TSMCP is divided into two portions at a site-specified location known as the "fence." Memory below the fence is managed the same way as for the DCMCP, with data and code segments for all programs allocated from one common heap. Batch programs and the TSMCP itself run below the fence.
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.
Memory above the fence is organized into a number of "swap areas" for use by the interactive programs initiated by remote users. Code and data segments for these programs are allocated solely within their respective swap areas. This supported the "time slicing" of memory for interactive programs, as all of the non-shared memory used by an interactive 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.
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.
To manage remote interactive sessions, Burroughs developed the Command AND Edit (CANDE) handler. This was a command-line interface somewhat like what we would call a shell today, but with a line-oriented file 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.
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.
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 their 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.
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.
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.
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.
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.
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.
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 to initiate the TSMCP.
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 initiate CANDE. At that point you can log in using the terminal and start timesharing.
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 =
@@ -75,7 +73,6 @@ This first step takes place outside of the emulator. Using your text editor of c
{{{
?EXECUTE SYSDISK/MAKER
?FILE LINE = LINE BACKUP
?DATA CARD
LINE,0,0,112,0,0,7,0,
LINE,1,0,112,0,0,0,1,
@@ -83,7 +80,7 @@ This first step takes place outside of the emulator. Using your text editor of c
?END
}}}
The web-based emulator supports the B249/B487 interface, with a single terminal on DTTU #1, buffer #0. That adapter slot is configured with a 112-character buffer.
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.
@@ -91,8 +88,8 @@ The web-based emulator supports the B249/B487 interface, with a single terminal
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:
* `1` indicates this is a direct-connect (hardwired) circuit. TSMCP considers the terminal to be permanently connected to the system
* `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.
@@ -102,7 +99,6 @@ Next, prepare another card deck to create the `USERS/CANDE` file:
{{{
?EXECUTE USER/CANDE
?FILE LINE = LINE BACKUP
?DATA CARD
$NEW
$USER "B5500"
@@ -129,18 +125,20 @@ Load the `SYSTEM` tape image file into the tape drive (MTA window) by clicking t
OL MTA
}}}
CANDE requires quite a few files, and the easiest thing to do is simply load everything from the `SYSTEM` tape. This is safe, as MCP Library/Maintenance will not overwrite critical files, such as the running MCP. With the tape loaded in the drive, enter the following command on the SPO:
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 LOAD FROM SYSTEM =/=; END
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 LOAD FROM SYSTEM TSS/MCP, TSS/INT, USERS/CANDE, SYSDISK/MAKER, -
CC ADD FROM SYSTEM TSS/MCP, TSS/INT, USERS/CANDE, SYSDISK/MAKER, -
CANDE/TSHARER, FIND/DISK, GUARD/DISK, =/CANDE; END
}}}
@@ -154,7 +152,7 @@ Make sure you resolve any errors in these decks before proceeding. CANDE will no
== Initiating TSMCP and CANDE ==
The next step is to designate the TSMCP as the MCP that should be
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:
@@ -183,7 +181,7 @@ Now reboot the system by switching to the emulator's Console window and clicking
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 interactive programs. Higher values give more memory to the MCP, the CANDE handler program, and batch programs. The default value is a good one to start with.
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:
@@ -212,6 +210,16 @@ This indicates that CANDE is running and ready for use.
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.
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 ||
To begin a session, click the *Connect* button on the terminal (DCA) window. The button should light.
== Logging In ==
@@ -236,19 +244,19 @@ CANDE will next request your password and output several sequences of characters
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
[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.
[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.
== Sample CANDE Session ==
Here is a sample session, illustrating creating, compiling, and running a simple program. CANDE requires line numbers (more properly known as sequence numbers) on all lines of all files, not just those for BASIC:
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~
@@ -309,6 +317,144 @@ Also note that multiple CANDE commands can be entered on one line, delimited by
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<<B+1~
101000 ELSE IF B = 0 THEN~
101100 ACKERMANN(A-1, 1)~
101200 ELSE~
101300 ACKERMANN(A-1, ACKERMANN(A, B-1));~
101400 END ACKERMANN;~
101500 ~
101600INTEGER I, J, K;~
101700FILE OUT DC 19 9<(1,10);~
101800 ~
101900FOR I:= 1 STEP 1 UNTIL 10 DO~
102000 FOR J:= 1 STEP 1 UNTIL 10 DO~
102100 BEGIN~
102200 K:= ACKERMANN(I, J);~
102300 WRITE(DC, F1, I, J, K);~
102400 END FOR J;~
102500END.~
102600~
#
RUN~
WAIT.
COMPILING.
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~
WAIT.
COMPILING.
END COMPILE .9 SEC.
RUNNING
1 1 3
1 2 4
1 3 5
1 4 6
1 5 7
1 6 8
1 7 9
1 8 10
1 9 11
1 10 12
2 1 5
2 2 7
2 3 9
2 4 11
2 5 13
2 6 15
2 7 17
2 8 19
2 9 21
2 10 23
3 1 13
3 2 29
3 3 61
-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.
LIST~
FILE:ACKMAN - TYPE:ALGOL --11/25/83 9:06 PM.
100100 BEGIN
100200 COMMENT ACKERMANN FUNCTION TEST;
100300 INTEGER PROCEDURE ACKERMANN(A, B);
100400 VALUE A, B;
100500 INTEGER A, B;
100600 BEGIN
100700 ACKERMANN:=
100800 IF A = 0 THEN
100900 B+1
101000 ELSE IF B = 0 THEN
101100 ACKERMANN(A-1, 1)
101200 ELSE
101300 ACKERMANN(A-1, ACKERMANN(A, B-1));
101400 END ACKERMANN;
101500
101600 INTEGER I, J, K;
101700 FILE OUT DC 19 (1,10);
101750 FORMAT F1 (2I4,I12);
101800
101900 FOR I:= 1 STEP 1 UNTIL 10 DO
102000 FOR J:= 1 STEP 1 UNTIL 10 DO
102100 BEGIN
102200 K:= ACKERMANN(I, J);
102300 WRITE(DC, F1, I, J, K);
102400 END FOR J;
102500 END.
END QUIKLST .4 SEC.
BYE~
ON FOR 35.9 SEC.
C&E USE 1.8 SEC.
EXECUTE 3.9 SEC.
IO TIME 38.5 SEC.
OFF AT 2:36 PM.
GOODBYE B5500
11/17/83
}}}
= Cold-Starting Directly to the TSMCP =
@@ -318,6 +464,6 @@ Peter Grootswagers has prepared a very nice set of instructions for cold-startin
________________
`________________`
_Credits_: The information in this wiki page was prepared by Tim Sirianni, with historical notes and editorial interference from Paul Kimpel.