# 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 `