Paul Kimpel edited this page Mar 20, 2018 · 8 revisions

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:

B5500 card reader at Stanford 1960s


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:

B5500 emulator card reader interface screen shot

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. See the discussion of the Keyin window below for an alternate way to supply card images to the 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.
  • KEY IN DECK -- clicking this white button on the far right of the panel will open a small sub-window with which you can quickly key in card images. Clicking the Insert button on the window will append those card images to the reader's input hopper. See the "Operating the Card Reader" section below before for more details.

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 or text from the Keyin window 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 or key in the images 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 more card images 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 or the KEY IN DECK window to load one or more "decks" 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 decks 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 the data is loaded into the reader, it loses its identity as individual decks and becomes just a part of the stack of cards to be read. When you empty the hopper, everything goes, regardless of the files keyed-in text from which it originally came.

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.

Using the Keyin Window

The KEY IN DECK button on the reader's panel offers a convenient way to append card images to the input hopper without preparing a file off-line and then loading it into the reader. When you click the button, a small sub-window will open. This window contains a text area in which you can key in the text of card images, one per line.

B5500 emulator card reader interface screen shot

Clicking the Insert button on the window will append the text you have entered to the end of the reader's input hopper.

Clicking the Cancel button, or simply closing the window, will discard any text you have entered without appending it to the reader's input hopper.

The window opens with the text area sized for lines of approximately 72 characters. Lines will word-wrap if you type beyond the right margin of the text area, but wrapped text remains part of the same card image. Use the Enter key to delimit card images. The window can be resized to eliminate word-wrapping if you wish. You can copy/paste text into the window and edit it before appending it to the hopper.

Below the text area are three white buttons that will insert frequently-used control card images at the end of the text area. They append a new-line after their text, but do not force the start of a new line before their text.

  • ?CONTROL/DECK -- inserts the control card required by the MCP's Load/Control (LDCNTRL/DISK) input spooler to label the reader. The spooler is initiated by the LD DK SPO command.
  • ?END CONTROL -- inserts the control card that will terminate Load/Control for that reader at the time the card is read.
  • ?END -- inserts the control card that signals the end of user jobs.

The Keyin window can be used by itself or in combination with the file picker control to load sequences of ad hoc card images and files from the local file system. For example, if you have a file containing a source program you would like to compile or load to disk, you could use the Keyin window first to enter the necessary control cards into the input hopper, then use the file picker to append the source program, and finally open the Keyin window again to append a ?END card to complete the deck.

The KEY IN DECK button is enabled only when the reader is in a not-ready status. While the reader is ready, the button is disabled and grayed out. While the Keyin window is open, the reader's START button is disabled. It is re-enabled when you click the Insert or Cancel buttons, or close the Keyin window.

Recovering from Card Errors

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.
  2. On the SPO, enter "CL CRx" or "RY CRx" (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.