Welcome to the Datatron 205 and 220 Blog

This blog is a companion to T J Sawyer's Web Page that outlines the history of the Burroughs Datatron 205 and Paul Kimpel's incredible 205 and 220 emulators. Please visit those sites and return here to post any comments.

Saturday, June 23, 2018

Introducing the retro-220 Emulator

A prior post on this blog introduced the Burroughs 220 computer system, discussing the origins of its development, describing its relationship to the ElectroData Datatron 205, and giving an overview of its architecture and main features

This is Paul Kimpel with another post on Tom's 205 and 220 blog.. That prior post laid the groundwork for this one -- to introduce the emulator I've developed for the 220. This post will present the features of that emulator, discuss its current state of development, describe how you can use it, and point you to the documentation and relevant reference materials.

As with my earlier retro-205 emulator for the 205 and retro-b5500 emulator for the Burroughs B5500, the retro-220 emulator is written in Javascript and runs in a standard web browser. Multiple windows on the screen are used to display the panels and peripheral devices of the system.

For the impatient who don't want to read through the following, the source code and resource files for the emulator are maintained as an open-source project at https://github.com/pkimpel/retro-220/. You can run the emulator from a hosting site I have set up, or you can download the files from the project's Git repository and set them up on your own web server. See the section Using the Emulator, below, for details on how to do this. Additional set-up and operating instructions can be found in the project wiki.


Choosing to Emulate the 220


While building an emulator for the 220 is a logical sequel to my earlier retro-205 emulator for the 205, this emulator is the fulfillment of an idea I've been carrying for almost 30 years. In August 1991, I visited the original Computer Museum in Boston, Massachusetts. After spending several satisfying hours viewing the exhibits, I was browsing in the museum's bookstore, and found a section that had old computer manuals. These were probably documents that had been donated to the museum, but were duplicates of ones they already had, so they were offering them for sale.

I have spent much of my career working with Burroughs systems and their Unisys successors. I had been disappointed to see nothing from that line in the museum's exhibits, but there in the bookstore I saw a manual titled The Operational Characteristics of the Datatron 220 Electronic Data-Processing System, Preliminary Edition from 1957. I was delighted to find this and bought it on the spot. It was only $6.00.

The Manual That Started It All
Almost immediately I had the idea -- I think it was while I was still in the bookstore -- that perhaps with the aid of this manual I could some day I write an emulator and make this system virtually work again. Perhaps this would be something interesting to do in retirement, which at the time was still a long way off. Of course, having no concept then what might be involved in such a task -- let alone that I might actually need some software to make it work -- and having started my career when computers still had large, complex control panels with lots of lights and switches and other neat stuff, I was really thinking how cool it would be to reproduce the 220 control panel and make all those lights blink.

Sometimes an early enthusiasm like this runs aground on the reality of what it takes to bring an idea to fruition, but sometimes that reality turns out to be way more interesting than the original enthusiasm, and that has certainly been the case here.

So that, dear reader, is how I became interested in emulating old computers -- to make the lights blink.

I also had a friend, the late Al Collins, who had worked for ElectroData and Burroughs in Pasadena during the 1950s and early 1960s. Al loved to tell stories. He had quite a few about the 205, the 220, and the early days of the B5000. It was also from Al that I originally learned of the BALGOL compiler for the 220. Al had a listing of the compiler, which his family and I were unable to find after he passed away. I found one on bitsavers.org, though, along with additional 220 reference materials, and that reignited the idea of some day not only emulating the 220, but also restoring that compiler and getting it to run again. Then I found a later and more complete listing that Professor Donald Knuth had donated to the Computer History Museum.

With that, I appeared to have everything I needed to build an emulator for the 220 and restore a significant piece of software for it. Thus the goals of this project became similar to those for the retro-205 emulator:
  1. Design and build the emulator so that it will run in a modern, standards-compliant web browser.
  2. Emulate the 220 processor, memory, and input/output devices as faithfully as is practical within he constraints imposed by a browser environment. In particular, the emulator should run programs exactly as a 220 would have run them.
  3. Execute 220 programs as closely as possible to the actual speed of a real 220. Emulation at speed is something I have been fairly successful at achieving with the 205 and B5500 emulators, and I think it is an important component for faithful emulation of any computer system, but for especially older ones that are so much slower than current systems.
  4. Provide as faithful a user experience as is practical within the constraints of a web-browser environment. The goal is for you to be able to use the emulator the same way you would have used a 220, with allowances for the fact that the emulator is not a physical piece of hardware. The user interface should be at least evocative of the physical machine, though, especially with respect to the control panels and I/O devices.
  5. Reconstruct and make operational the BALGOL compiler from the scanned listings on the Computer History Museum's web site.

Current Development Status


The BALGOL compiler and library comprises over 10,700 lines of assembler coding, so I started transcribing that first, in early November 2016. Design and coding of the emulator began in late January 2017. Transcription of the BALGOL listings was completed in early February 2017 and an initial proofing pass by early April. Implementation of the emulator, except for magnetic tape devices, was essentially complete by the end of May 2017.

Magnetic tape is required for the BALGOL compiler, but magnetic tape on the 220 was a complex device, and proved to be quite a challenge to implement. The project stalled for several months in the face of that challenge, and I did not finally have it working until mid-November 2017, almost a year after the project began.

Work to date since then has mostly involved assembling the compiler pieces into a running program and testing the compiler with a few sample programs. I will devote future blog posts to a detailed description of the recovery and reconstruction of the compiler and the sample programs we presently have working. The materials for these are available now, however, on the project's GitHub repository.

At this point, the 220 emulator is complete except for the DataFile, a semi-random tape mechanism similar to the one available on the 205, and the High Speed Printer (HSP), an early drum printer. All instructions for the 220 processor, except those for the HSP, are presently implemented, including those for floating-point arithmetic.

The emulator is written entirely in Javascript, with HTML and CSS used to lay out the user interface. It requires a fairly modern web browser in order to run, as it employs a number of features from the on-going HTML5 standardization effort. The emulator works and has been tested with reasonably-recent versions of Google Chrome, Mozilla Firefox, and Apple Safari for Mac OS. The emulator will not work with tablet devices, as tablets do not support multiple windows on the screen.

Two people have given me a great deal of advice and assistance on this project, and have helped make it a success. Tom Sawyer, as always, has continued his strong support for my efforts, and uncovered much interesting and useful information during his research at the Charles Babbage Institute in Minneapolis. Through Tom, I met Michael Mahon on line. Michael used a 220 during his graduate studies at Cal Tech in the mid-1960s. His memories of actually using a system have been invaluable. Michael has written his own emulator for the 220 -- that runs on an Apple II! He also wrote a paper-tape based assembler for the 220, SNAP, while at Cal Tech, and has generously made the source code for that program available to this project.


Using the Emulator


As mentioned above, the emulator requires a modern browser, with Firefox and Chrome being the two I have used the most. You will also need a reasonably powerful workstation. Emulation of the 220 instructions requires almost nothing, but update of the panels and I/O device windows can be very graphics-intensive, and requires a fair amount of horsepower. My five-year old Dell PC with a 3GHz quad-core Pentium i3 processor handles the emulator adequately. It will also help if you have a big monitor, as the windows for the control console and I/O devices tend to overlap each other.

The emulator must be served to your browser from a web server over HTTP. You will not be able to download the emulator files to your workstation and run them directly from your local file system. That is a limitation with the way that browsers work, not with the emulator. Of course, there's no reason you can't run a web server on your workstation and serve the emulator files from there. Regardless, once the emulator is loaded into your workstation, it runs entirely locally, and needs no further access to the web server.

Setting Up the Emulator


The easiest way to get started with the emulator is to use the hosting site, where I have set up the emulator files. Feel free to use it:


If you would prefer to run the emulator from another web server, download the files from the Git repository on the project site. You can download a zip file of the latest version of the emulator source code by clicking the Download ZIP button on the project's home page:


Alternatively, you can clone the project from the repository using the following Git command:

git clone https://github.com/pkimpel/retro-220 retro-220

Although the GitHub project site uses a Git source code repository, GitHub also allows you to access the repository using Subversion clients. A read-only checkout of the emulator files can be performed using a Subversion command similar to this:

 svn checkout https://github.com/pkimpel/retro-220/trunk retro-220

You will need at least the emulator/, webUI/, and webUI/resources/ directories from the repository. The emulator/ and webUI/ directories must be rooted in the same virtual directory on your web server. You may also wish to download/check out the software/ directory, as it contains a number of 220 programs, but that directory is not required to run the emulator.

The emulator will open a number of sub-windows when it initializes. Most browsers will consider these windows to be "pop-ups," so if you are using a pop-up blocker, you should disable it before starting the emulator. Most pop-up blockers will allow you to disable blocking for specific web sites, however, which will allow you to run the emulator without having to forgo protection from pop-ups for all sites. Modern browsers enable a pop-up blocker by default, and many browser toolbar plug-ins implement additional ones. All of them will need to be disabled for the emulator site.

More information on system requirements, setting up the emulator, and using a local web server is available on the Getting Started wiki page.

The Emulator Home Page


When you first load the emulator, it initializes with a default configuration, which is adequate in most cases to get started using it. Once it loads into your browser, it's ready to run. The hosting-site URL above references the emulator's home page, which looks like this:

retro-220 Emulator Home Page

The current version of the emulator is shown in the upper-right corner of the page. There are links below the horizontal bar to the open-source project site and to this blog. The picture is from Michigan National Bank in Lansing, Michigan, ca. 1960. In the background are tape drives and a portion of the system cabinetry. In the foreground is the system's Control Console.

Below the picture are two large blue buttons. The Configure System button can be used to modify the system configuration. It is active only when the emulator is in a "powered-off" state. The emulator is initially configured for 5000 words of memory, one teletype printer (the "SPO"), one paper-tape reader, no paper-tape punch, one card reader, one line printer, one card punch, and two magnetic tape drives. See the Configuring the 220 Emulator wiki page for instructions on modifying the configuration.

To start the emulator, click the Start the Emulator button below the picture. Additional windows will open for the Control Console panel and the I/O devices. The blue button will become disabled after it is clicked, and will remain so until the emulator is powered off from the Control Console as discussed below. While the emulator is running, the home page is not needed, but do not to close or minimize it -- just leave it in the background.

Also note that some browsers, particularly Firefox, will slow execution of scripts for a web page if that page is in a tab other than the currently-active one of a window. In the case of the emulator, this means that if the home page is in a non-active tab, the emulator will likely run very slowly. If you need to use the browser for another purpose while the emulator is running, leave the emulator's home page in the active tab of its window and open another window for the other purpose.

The Control Console


The 220 had a large and impressive console built into a desk. The central panel of the console was used to operate the system. There were two additional panels on either side of the main one that were normally concealed by snap-off covers. These were used mainly by the field engineers for system diagnosis and maintenance. The emulator does not presently implement those additional panels. The main panel looks like this in a browser:

retro-220 Control Console
This section of the post covers the features and operation of the Control Console in some detail. Much of this repeats the information contained in the Using the Console wiki page, but understanding the Console is critical to being able to use the emulator, just as it was for operating a real 220, so a relatively complete treatment of it is given here.

 Register Displays


The first two rows on this panel show the main registers for the system. The 220 was a decimal system that used BCD (binary-coded decimal) encoding, so the registers are arranged as groups of columns, with each column holding one four-bit digit. The bits in each column have values 8-4-2-1 from top to bottom. Thus a digit 7 has the bottom three bits set; a digit 9 has the top and bottom bits set. Digit values 10-15 are termed "Forbidden Combinations" and will cause the system to halt with a Digit Check alarm.

The first row has registers A (the accumulator), R (the accumulator extension), and D (a register through which data entered and exited the processor). The second row has B (the index register), P (the program address counter), C (the command, or current-instruction register), E (the memory address register), and S (the stop or breakpoint-address register, used in debugging programs). The purpose of these registers is described in Section 2 of the Operational Characteristics manual available on bitsavers.org.

On a real 220, there were small white rectangular buttons below each lamp of a register that, when pressed, would set that bit to 1. To reset a bit, you would hold down the large white rectangular button on the left side of the register while simultaneously pressing the small white button for that bit. This is awkward to do with most pointing devices, so in the emulator the large left-hand button is inactive, and each click of the lamp or the white button below it toggles the current state of that bit. Clicking the large white rectangular button on the right side of a register clears that register.

Indicator Lamps


In the row below the registers are three groups of colored lamps. The group on the left consists of red lamps that light when an error or alarm condition is sensed by the system. These conditions cause the system to halt. Most of these lamps are also buttons, which can be clicked to reset the corresponding alarm condition. See Section 3 in the Operating Procedures manual for information on the conditions each of these lamps represents.

The middle group consists of three blue lamps that indicate the processor's current state.
  • The RUN lamp is lit when the processor is executing instructions in continuous mode.
  • The FETCH and EXECUTE lamps indicate the current phase in which the processor is operating. 220 instructions are executed in two steps:
    • During the Fetch phase, the next instruction is loaded into the C register from memory at the address in the P register, and then P increments by one. If the low-order bit of the sign digit in the instruction word is 1, the value in the B register is added to the operand address in the low-order four digits of the C register. 
    • Once the C register is loaded, the phase switches to Execute and the instruction is executed. The phase then switches back to Fetch and the process repeats. The two lamps indicate the phase the processor will enter next.
The group of lamps on the right show a set of conditions that are set by some instructions and can be acted upon by others:
  • OVERFLOW indicates that arithmetic overflow has occurred during the execution of an instruction. It is sensed and reset by the Branch Overflow instruction.
  • REPEAT is set by the Decrease Field Location and Decrease Field Location Load B instructions that decrement a field in a word. It is sensed by the Branch Repeat instruction. It is used to control the execution of loops.
  • The LOW, EQUAL, HIGH lamps indicate the last result of the Compare Field A/R instructions and are sensed by the Branch Low/High/Equal/Unequal instructions.

Control Switches


The row below the lamps contains groups of switches. These were in the form of large "organ switches," similar to the paddle switches that control stops on an organ. They were made of translucent plastic, and came in two types: momentary switches that acted like a button, and latched switches that would maintain their position. The latched switches were lit when in the "on" (down) position.

The group of switches on the left consist of ten Program Control Switches that are of the latched type. The settings of these switches can be sensed by the Branch Control Switch instruction, and are used to set options for, or to communicate dynamically with, a program.

The group of four momentary switches in the middle control the system's operation:
  • STOP halts the processor, preserving its current state. Execution can be continued using the RUN or STEP switches.
  • RUN starts the processor in continuous execution. This switch is enabled only when the processor is halted and the blue RUN lamp is off.
  • STEP starts the processor, but only for the next Fetch or Execute phase. At the end of that phase, the processor halts. Thus, this switch needs to be pressed twice to completely execute one instruction. This switch is also enabled only when the processor is halted and the blue RUN lamp is off.
  • CLEAR clears all registers and flip-flops in the processor. If the processor is running when this switch is pressed, it halts.
The group of switches on the right serve various purposes:
  • KEYBOARD is a momentary switch that enables the decimal keyboard, as described below. This switch is enabled only when the processor is halted and the blue RUN lamp is off.
  • "S" ON is a latched switch that enables the S register. This register holds a memory address that, when accessed in the manner indicated by the next three switches, will cause the processor to halt. When this switch is off, the value in the S register and the other three switches are ignored.
  • UNITS is a latched switch that, when on, will cause only the low-order digit of the S register to be compared in detecting a stop address.
  • "S" TO P is a latched switch that indicates the processor is to halt at the end of the Fetch phase when the P register matches the S register. P increments during Fetch, so the processor will halt with P one greater than S.
  • "S" TO C is a latched switch that indicates the processor is to halt at the end of the Execute phase when the low-order four digits of the C register (the operand address) matches the S register.
  • RESET/TRANSFER is a momentary switch that, when clicked, will cause the contents of the P register and the low-order four digits of the C register to be stored in memory location 0000. The processor will then branch to the instruction at memory address 0001. This switch worked somewhat like an interrupt, and could be used to recover control of the system after certain peripheral errors that do not allow the Execute phase of an instruction to complete.
  • TCU CLEAR is a momentary switch that, when clicked, clears the Magnetic Tape Control Unit. This was used to recover from certain magnetic tape errors. It performs the same function as the CLEAR button on the TCU panel.
Below the row of switches, on the left and right sides of the console, are two grayed-out buttons. These are provided for the eventual implementation of the two maintenance panels, but are presently non-functional.

Interval Timer


In the center at the bottom of the panel is the interval timer. On a real 220, this was a separate mechanical timer that was attached to the console by a cable and usually sat on the console desk. This timer runs whenever the processor is executing instructions and the blue RUN lamp is lit. It records time in seconds and tenths, counting up to 9999.9 before rolling over to zero. The timer can be reset to zero at any time by clicking the black ZERO TIMER button on its left.

Power Off Button


To the right of the timer is a red button captioned POWER OFF. This button must be double-clicked to activate it. Doing so will stop the processor if it is running, and close the Control Console and all peripheral device windows, leaving open only the window for the emulator's home page. The contents of the 220 memory and peripheral devices will be lost. Make sure that you capture any output you wish to keep from the peripheral devices before powering off the emulator.

Memory Dump Feature


The retro-220 emulator supports a diagnostic feature on the console. If you click the circular "B" logo at the top of the panel (affectionately known within Burroughs as "the Meatball"), the emulator will open a temporary window on your screen and format the processor's current register settings and all of memory to it. From this window you can view the dump, or copy/save the text to another program or a file. You can generate these dumps as often as you like, even while the system is running. Each dump will open in a separate temporary window. When you are finished with a dump, simply close its window.

More information on the Control Console is available in the Using the Control Console wiki page and in Section 3 of the Handbook of Operating Procedures for the Burroughs 220.

The Console Keyboard


The 220 Control Console has a decimal keyboard. This was another module connected to the console by a cable, and usually sat on the console desk. The emulator implements this keyboard as a separate window, but that window is not displayed by default. To open the window and enable the keyboard, click the KEYBOARD momentary switch on the console. This switch is enabled only when the processor is halted and the blue RUN lamp is not lit.

220 Control Console Decimal Keyboard
The red lamp at the bottom of the keyboard will be lit when the keyboard is active. To use the keyboard, you can click on its buttons. Alternatively, when the keyboard window has the focus, use the keys on your workstation's keyboard. You can close the keyboard window when you are not using it; clicking the KEYBOARD switch will reopen it.

Keying the decimal buttons causes those digits to enter the processor's D register from the right, shifting the other digits in the register to the left in the process. The high-order digit in the sign position of the register shifts off and is lost. If you make a mistake, you can clear the D register and start over, or simply keep keying digits, possibly with some leading zeroes to clear out digits in the register you don't want.

The other buttons on the console keyboard function as follows. The characters in brackets indicate the equivalent keys you can press on your workstation keyboard:
  • C [C, c] -- transfers the contents of the low-order ten digits of the D register to the C register. If the low order bit of the sign digit in the D register is set, B-register modification of the operand address in the C register occurs. The D register is unaffected.
  • E [E, e] -- transfers the low-order four digits of the D register to the E register and clears the D register. This establishes the memory address used by the next two buttons.
  • EXAM [X, x] -- loads the word from memory at the address in E to the D register. The E register counts up by one.
  • ENT [Enter, Return] -- stores the contents of the D register to the memory address in the E register. The E register counts up by one.
  • STEP [S, s] -- acts the same as the STEP switch on the Control Console.
  • ADD [+] -- algebraically adds the value of the D register to the A register and then starts the processor as if RUN had been clicked. This feature is designed to be used with the Keyboard Add instruction. When this instruction is executed, the D register is cleared, the processor halts, and the keyboard is enabled automatically. Once the ADD key is pressed, D is added to A and the processor resumes execution.
More information on the keyboard is available in Section 3 of the Handbook of Operating Procedures for the Burroughs 220.


Input/Output Devices


The 220 supported a number of contemporary peripheral devices for input and output of data. At present, the emulator supports teletype printers, paper tape readers and punches, the Cardatron interface for IBM punched-card equipment, and reel-to-reel magnetic tape drives. The emulator does not at present support the DataFile magnetic tape unit nor the High Speed Printer.

Teletypes and the SPO


A 220 system could support up to ten teletype printers. Every system had an additional teletype known as the Supervisory Printer, or SPO (pronounced "spOH"), which was addressed with a different instruction than the other teletypes. All printers were identical Teletype Model 28 units that printed at 10 characters/second, although Burroughs later introduced some high-speed printers that were plug-compatible with the Model 28. Any teletype could be designated as the SPO; a paper-tape punch could also be designated as the SPO.

Each teletype device is displayed as a separate window in the emulator.

retro-220 SPO/Teletype Printer Window
Each printer has a control panel that can be accessed by clicking the Open Panel button at the top of the window. This panel can be used to set the device address, zero-suppress behavior, line width, end-of-word carriage control, and tab stops. Text from the "paper" area of the printer can be captured by double-clicking that area. This will extract the text to a separate temporary window, from which it can be copied or saved. See the Using the SPO, Teletype, and Paper Tape wiki page for details.

Paper Tape Punch


A 220 could optionally be configured with up to ten paper-tape punches. The punch operated at 60 characters/second, using a seven-level code compatible with the IBM 046 Tape to Card Converter. Teletypes and paper-tape punches share the same set of device addresses, so a system could support any combination of the two devices up to a total of ten units.

retro-220 Paper Tape Punch
The paper-tape punch is a simple unit that displays the words that have been punched in a scrolling window. The text in this window can be extracted and saved in the same way as for teletypes. Words are formatted as either numeric or alphanumeric depending on the value of the sign of the word being punched. The format of the text is compatible with the paper-tape reader, discussed next. See the Using the SPO, Teletype, and Paper Tape wiki page for details.

Paper Tape Reader


A 220 could optionally be configured with up to ten paper-tape readers. The readers operated at a switch-selectable speed of 500 or 1000 characters/second. Paper tape image files can be prepared with any text editor and loaded into the reader. Tape images saved from a paper-tape punch can also be loaded directly into the reader.

retro-220 Paper Tape Reader
A progress bar on the reader's window shows the relative amount of the tape image that has not yet been read. As the tape image is read, the words from the tape scroll horizontally across the bottom of the window. See the Using the SPO, Teletype, and Paper Tape wiki page for the format of paper-tape image files and details of the reader's operation.

The Cardatron


The Cardatron was a device that interfaced the 220 to IBM punched-card tabulating equipment. It was introduced with the ElectroData 205 shortly before Burroughs acquired ElectroData in 1956. It was then adapted to the 220 with very little change. For background on the Cardatron and how it worked, see the The Mighty CARDATRON and Using the retro-205 Cardatron blog posts.

For more details on the 220 Cardatron elements discussed below, see the Using the Cardatron wiki page and Section 6 in the Operational Characteristics manual.

Cardatron Control Unit


The Cardatron consisted of a Control Unit that interfaced to the processor, plus an Input or Output Unit that interfaced between the Control Unit and a specific IBM device. The Input/Output units could buffer a single card image, so some overlap in I/O operations was possible. Any combination of up to seven Input or Output units could be attached to the Control Unit.

In the emulator, the Cardatron Control Unit has a small window with a few indicator lamps. The lamps show status and unit selection, but you do not need to interact with this window when running the emulator. See the wiki page for an explanation of the lamps.

retro-220 Cardatron Control Unit

Cardatron Input Unit


The Input Unit interfaced card readers to the 220. Two types of readers could be used, the IBM Type 087/089 collator, operating at 240 cards/minute, and the Type 523 Summary Punch operating at 100 cards per minute. In the emulator, the reader operates at 240 cards/minute.

The Input Unit had a small drum that buffered one card image and stored up to five strings of digits known as "format bands." These strings described how to convert the punches in card columns to digits or characters in 220 memory words. A punch in a specified column on a card (often column 1 or 80) selected the band under which that card would be read and converted.

Each Input Unit displays as a separate window in the emulator. Card image files are ordinary text files and can be loaded into the reader much as decks of cards were loaded into the input hopper of a real reader. See the wiki page for an explanation of the controls and indicators on the reader window.

retro-220 Cardatron Input Unit / Card Reader

Cardatron Output Unit for Printer


There were two types of Output Unit, one supporting 80 columns for card punches and one supporting 120 columns for line printers. The 120-column unit was designed to connect to an IBM Type 407 tabulator operating at 150 lines/minute. This unit also had a small buffer drum that could buffer one line of print and store up to five format bands. The bands described how to converts words from the 220 memory to columns on a card or print line.

Each printer displays as a separate window in the emulator. Printed text can be extracted from its "paper" area and saved in the same manner as described for teletype units above. See the wiki page for an explanation of the controls and indicators on the printer window.

retro-220 Cardatron Output Unit / Printer

Cardatron Output Unit for Punch


The 80-column Output Unit was otherwise identical to the 120-column unit and was designed to connect to an IBM Type 523 Summary Punch operating at 100 cards/minute. The 523 could also be used as a card reader, but the same device could be be used in both ways. The punch window looks and operates similarly to the printer:

retro-220 Cardatron Output Unit / Punch

Magnetic Tape Storage


The 220 supported two types of magnetic tape devices. The Tape Storage Unit (TSU) was a traditional reel-to-reel device using 3/4-inch plastic tape wound on 3500-foot metal reels. Data was recorded digit-serial in two independent lanes on the tape. Recording was at 208.33 bits/inch with a tape speed of 120 inches/second. The emulator currently implements this device.

The second tape unit was the DataFile, a semi-random device consisting of 50 strips of tape accessed by a tape head assembly that traversed across the strips perpendicular to the tape motion. This device was also available on the 205. The retro-220 emulator does not presently support this device, but implementation in planned. For an introduction to the DataFile, see this 205 blog post.

The magnetic tape implementation on the 220 was both complex and sophisticated, and deserves a blog post on its own to describe its implementation and capabilities.

Tape Control Unit


Both the TSU and DataFile were controlled by a common Tape Control Unit (TCU). Up to ten tape drives, in any combination of TSUs and DataFiles, could be supported on a 220 system.

In the emulator, this unit has a window that displays its major flip-flops and two main registers. You do not normally need to interact with the TCU when operating the emulator, but it shows information that may be useful in diagnosing tape errors. The TCU may need to be cleared to recover from some types of tape errors. The CLEAR button on this unit has the same function as the TCU CLEAR switch on the Control Console.

retro-220 Magnetic Tape Control Unit (TCU)

Tape Storage Unit


In the emulator, each TSU has a window that displays controls and indicators used to operate the unit and monitor its state.

retro-220 Magnetic Tape Storage Unit (TSU)
When a tape image is loaded in the unit, a small reel icon will appear in the upper-right of the window. This icon will spin in response to tape commands addressing the unit. Annunciators will appear below this reel to indicate certain conditions (e.g., REWINDING, AT BOT).

The blue lamps across the top of the window indicate the status of the drive. The most important of these are the NOT READY, TRANSPORT POWER ON (unit is on line), and TRANSPORT POWER OFF (unit is off line).

The red and black buttons below the lamps control the unit. LOAD and UNLOAD initiate the loading and unloading of tape images in the unit. REWIND will rewind the tape to its load point (BOT, Beginning of Tape) if the unit is off line. ON and ST'DBY switch the unit between on-line and off-line status. RWLR releases a "rewind lockout" condition that is imposed by a variant of the processor's tape rewind instruction. WRITE and NOT WRITE control write protection for a mounted tape image.

The UNIT DESIGNATE pull-down list determines the logical unit number to which the unit will respond. This is the unit number specified in tape instructions. Not more than one TSU should be on-line at the same time with the same unit number. If more than one TSU is on line with the same number, all such TSUs will appear to the processor as not ready.

At the bottom of the window is a meter bar that, when a tape image is loaded into the unit, shows the relative amount of tape left on the reel. The bar will move to the left as tape is read in a forward direction. Above the bar is the name of tape image currently loaded into the unit.

Tape images are ordinary comma-delimited (CSV) text files. They can be prepared manually using a text editor or spreadsheet program. When unloading a tape image, if the image has been updated while it was loaded, the emulator will pop up an alert offering to save the updated image. Since browsers cannot write directly to your workstation's file system, the updated image will be formatted in a temporary window, from which you can copy or save it. Tape image files are copied into the emulator's memory when they are loaded, and are operated on in memory. The file from which the image is loaded is not updated by the emulator, but you can save the text of an image back to the same file name to obtain the same effect.

This brief overview of TSU operation and behavior is intended to give you an introduction to the use of magnetic tape on the 220. For more detailed instructions on loading and unloading tape images and on the format of tape image files, see the Using Magnetic Tape page in the wiki.


Running the Pre-Loaded Programs


The preceding introduction should give you enough information to load the 220 emulator into your browser and operate its controls. Just to give the emulator something to do out of the box (i.e., make the lights blink), the emulated memory is pre-loaded with a few small demonstration programs. These are all self-contained and use only the SPO teletype for output. The starting address for each of these programs is:

  * 0080 -- a simple counter program that increments the A register as fast as possible. Each iteration should take 0.310ms, or about 3226 iterations/second.
  * 0090 -- the classic Hello World program, which with default Console unit designations will write to the SPO, and then halt.
  * 0100 -- a program that computes square roots using integer arithmetic, printing the argument and root values to the SPO. This program uses the decimal-point insertion feature of the SPO.
  * 0200 -- the same square root program as at 0100 modified to use floating point arithmetic. Floating point numbers are represented as seemmmmmmmm, where s is the sign digit, ee is the exponent biased by 50, and mmmmmmmm is the eight-digit mantissa with the decimal point to the left of the first digit. The number 2.23602 (or 0.223602E+01) is therefore represented in the 220 as +5122360200. The program also uses the decimal-point insertion feature, so this value will print on the SPO as 51.2360200.
  * 0300 -- a program that prints the first 800 digits of Pi, adapted from a C program by Dik Winter of CWI in Amsterdam. The results are printed on the SPO in four-digit groups. It takes about 25 seconds for the first group to print. The remaining groups will come out progressively faster. The program takes about 40 minutes to run to completion. The B register counts down as a four-digit group is generated; the group will print when B reaches zero.

There are two methods you can use to run these programs from the Control Console.

Method 1: Finger-boning the Console lamps:
  1. Click the CLEAR switch on the Console.
  2. Enter the address of the routine in the lamps of the P register. All digits are in BCD, with the low-order bit of the digits in the bottom row of the register lamps.
  3. Make sure the FETCH lamp is lit. Click it if necessary. This will cause the processor to start by fetching the first instruction from the address in P.
  4. Click the START switch to begin execution.
The following screen shot shows the panel as it should be set to run the Hello World program at address 0090:

Setting a Program Starting Address

Method 2: Using the Console Keyboard:
  1. Click the CLEAR switch.
  2. Click the KEYBOARD switch. The keyboard window should appear in the lower-right corner of the screen.
  3. Enter 30xxxx by either clicking the numeric digits of the Console keyboard or typing on your workstation keyboard. "xxxx" is the address of the program you wish to run. This is a Branch Unconditional (BUN) instruction. You will see the digits shift into the D register.
  4. Click the C key on the Console keyboard (or type "c" on your workstation keyboard). This will transfer the contents of D to the C register.
  5. Click the EXECUTE lamp to place the Processor in the Execute Phase. This will cause it to start with the instruction in the C register.
  6. Click the START switch on the Console to begin execution.
The programs at locations 0080, 0100, and 0200 will run continuously until they are halted by clicking the STOP or CLEAR switches. The programs at 0090 and 0300 will run to completion and then halt. The RUN lamp will extinguish. These programs can be stopped manually at any time.

You can also single-step the programs to see individual instructions execute. Simply click the STEP switch on the Console or they keyboard. The Processor must be halted (RUN lamp is off) for the STEP switch to be active. Note that it takes two steps to execute one instruction -- one step for the Fetch Phase and one for the Execute Phase. The FETCH and EXECUTE lamps indicate which phase will be performed next when STEP is clicked.


Conclusion


This concludes the overview of the retro-220 emulator in its current state of development. The DataFile magnetic tape and High Speed Printer devices will be implemented at some point in the future, but there is presently no schedule for their development.

The next post will discuss the Burroughs Algebraic Compiler (BALGOL) and the process used to recover it from a listing and get it running again.

Sunday, March 11, 2018

retro-205 Emulator Version 1.01 Released

Most of the development work that has been going on behind this blog over the past year has been devoted to the Burroughs 220 and its retro-220 emulator. Nonetheless, I have continued to enhance and correct the retro-205 emulator for the ElectroData/Burroughs Datatron 205 computer system. We have now accumulated sufficient changes to this emulator to justify releasing an update, version 1.01.

This is Paul Kimpel with another guest post on Tom's 205 and 220 blog. Version 1.01 consists of bug fixes, internal enhancements, and a few new features that are externally visible. This post will describe those changes.

New Features


Power-Off Behavior


The thing that everyone who uses the retro-205 emulator needs to know about this release is that the way you "power off" and shut down the emulator has changed. Previously, a single click of the red OFF button on the Supervisory Panel would terminate the emulator and close all of its windows, leaving only the original browser window with the home page open on your screen.

Now, the OFF button requires a double-click to shut down the emulator. If you hover over the button with your cursor, a tool-tip will pop up to remind you. This behavior has been adopted from the retro-220 emulator, where the power-off and system-clear buttons are close together. I was frequently clicking power-off when I intended to click the clear button, so added the double-click as a safety measure. It seems reasonable to make this behavior consistent between the two emulators.

Memory Dump Generation


The emulator now supports a memory-dump capability. On the Supervisory Panel, below the D register, is a section labeled TEST SYSTEM. The controls in this section have been non-functional in the emulator, as they affected the 205 electronics at a level below which the emulator operates.

Supervisory Panel TEST SYSTEM section

Now, however, clicking the SINGLE PULSE button in the upper-right corner of this section will cause the emulator to open a sub-window and format the current processor state and memory contents to that window. You can generate this dump at any time, even while the emulator is running a program. It will show an instantaneous snapshot of the system state at that point in time.

SINGLE-PULSE Button Memory Dump

From this window, you can copy, save, or print the dump using the standard facilities in your browser for doing so. You can click the button multiple times to generate multiple dumps, each in its own window. When you are finished with a dump, simply close its window.

Apple Safari Pop-up Restrictions


This next item could be qualified as a bug fix, but it's really a new feature. The emulator had been operating quite well in the three major modern workstation browsers -- Google Chrome, Mozilla Firefox, and Apple Safari. I recently updated my MacBook Air to macOS 10.13 (High Sierra), and with that update came Safari 11.0.

Trying to run the retro-220 emulator in Safari after this update resulted in the emulator crashing after opening its first pop-up window. I quickly discovered that the retro-b5500 and retro-205 emulators suffered the same problem. I had Safari configured to allow pop-ups, so what gives?

Some research revealed that this new version of Safari places additional restrictions on pop-up windows. Specifically, it would always allow the first pop-up, but if subsequent pop-ups were opened before some amount of time had passed, Safari would inhibit the pop-up. Reports varied on the amount of time that had to elapse between opens, ranging upward from 500ms.

The emulator opens pop-ups for the Supervisory Panel, Control Console, and each of its peripheral devices. All of these elements are implemented as Javascript objects, and as part of their instantiation, each one opens, sizes, and positions its own pop-up window. Trying to insert appropriate delays in the initialization process that instantiates these objects was going to be difficult, so I decided instead to centralize the mechanism for opening pop-ups.

Now, each object calls a common "open pop-up" function in the D205Util.js module, passing parameters necessary to open and configure the window. In addition, each object passes a reference to its "onload" event handler that should be called once the browser opens the window and loads its initial content. These parameters are bundled into a data structure, and that structure is inserted into a queue of pop-up open requests. If the queue was previously empty, the open function calls another function to dequeue and process the first (and in this case, only) entry in the queue. If the queue was not previously empty, then processing of the queue is known to be on-going, and the open function simply exits.

The dequeue function plucks the first entry from the queue and uses the parameter values from the entry to perform a Javascript window open call. If that call fails (i.e., returns a null result), the dequeue function reinserts the failed entry back into the head of the queue, increments a timeout value, and using that updated timeout value, schedules itself for later execution using the Javascript setTimeout() function. When the timeout expires and calls the dequeue function, that function again tries to process the first entry in the queue. This process repeats, incrementing the timeout value at each iteration, until the window open is successful.

Once the dequeue function obtains a successful window-open result, it attaches the original caller's onload event handler to the window. After the browser finishes loading the window, it will call this handler, which will complete the initialization of the console or peripheral device object. Finally, and unless the queue is now empty, the dequeue function reschedules itself using the current timeout period to process the next entry in the queue.

This new mechanism works extremely well. It automatically adjusts the delay between opens based on the individual browser's behavior. The initial timeout value is 500ms and increments by 250ms on each iteration of a failed open. My tests indicate that Safari 11.0 starts making nice when the timeout reaches 1000ms. Chrome and Firefox both cruise through pop-up opens, because their open attempts do not fail; thus nothing ever gets queued, so the opens proceed without any delay.

Bug Fixes


 The following problems have been corrected in the emulator:
  1. Floating-point addition/subtraction was producing the wrong result if the mantissa of either operand was zero. Thanks to Tom Sawyer for finding and reporting this problem.
  2. During floating-point divide, the quotient mantissa was not being normalized properly.
  3. If a magnetic tape operation was initiated against a not-ready unit, the Processor's internal performance throttling mechanism could become corrupted, causing the emulator to run erratically.
  4. The Designated Unit lamps on Cardatron devices were not always being illuminated properly.
  5. Changes to the Format Select control on Cardatron input devices (card readers), an emulator feature that allows the band-select column on cards to be overridden, were not being detected properly. This usually rendered that control non-functional.
  6. Format-Lockout for Cardatron input devices was not working when there was a simulated 8-punch in the band selection column of the card. See the Cardatron wiki page for details on how simulated 8-punch coding is implemented in this emulator.
  7. Skip-to-channel carriage control on Cardatron printer devices did not always work properly, depending on the carriage control being applied on the next write to the device.
  8. Several 205 devices display output from the system in windows or frames, and allow you to save or print the data using standard browser controls. The common document used for these windows and frames contained extraneous white-space, which resulted in blank lines before and after the actual output. This extraneous white-space has been eliminated.

Internal Enhancements


Every release contains a number of minor tweaks and optimizations to improve the performance, reliability, or maintainability of the emulator. Sometimes there are new Javascript or DOM features that are mature enough to replace custom coding in the emulator that was doing the same or a similar thing. Many of these changes are too minor or obscure to mention, but all are visible in the source file "deltas" available on the project's repository site.

The following summarizes the most important of these internal enhancements for version 1.01:
  1. Binding an object context to a function is a common feature of Javascript object-oriented programming. The traditional way of doing this has been to wrap the subject function with another function that captures the context in a closure and then calls the subject function with the Function.apply() method. Recent versions of Javascript can now do this internally using the Function.bind() method. The emulator's custom bindMethod() utility functions have been replaced with this intrinsic capability.
  2. A common operation in web programming is to manipulate the list of CSS class names in a DOM element's className property. Traditionally this has been done using simple regular expressions, but the modern DOM treats the className property as a classList object, which has intrinsic methods to add, remove, and test for the presence of specific class names. These classList methods are now used in the emulator.
  3. Data transfers between memory and card devices are controlled by format band programming in the Cardatron. Because of this, the Cardatron controls how much data is transferred. Thus it must signal the Processor when the transfer is complete so that the Processor can terminate that I/O instruction and continue execution. The way this signal was being passed to the Processor during card-read operations was not particularly reliable, and has been improved.
  4. The setCallback() function used to manage asynchronous functions in the emulator seems to be forever undergoing refinement. Some additional tuning changes were made in this release. 
Work on the retro-205 emulator will continue in the background, and as accumulation of new enhancements and bug fixes warrants, I will be making new releases of the emulator available.

Wednesday, February 28, 2018

Introducing the Burroughs 220

The Burroughs 220 was a late-1950s decimal, vacuum-tube, core-memory computer system. It was the successor to the ElectroData/Burroughs Datatron 205 system. It shared many of the 205's characteristics while improving upon several others. It was also the first new system to be released under the Burroughs name after Burroughs acquired ElectroData in mid-1956.

The 220 was perhaps the last major vacuum-tube computer design to reach the market. It did so as IBM, Philco, and Univac were announcing, and in some cases delivering, transistor designs. Because of this, the 220 did not sell particularly well, but it was popular with universities and research establishments, and it laid groundwork for the much more successful Burroughs systems that followed it, particularly the B5500.

This blog was re-titled for the Burroughs 205 and 220 a year ago, and we haven't said a peep about the 220 -- until now. This is Paul Kimpel with our initial post on that computer system. It will introduce the architecture and components of the 220, compare them to the earlier 205, and give a brief overview of our project to build an emulator and recover software for the machine.


Genesis of the Burroughs 220


By the mid-1950s, the ElectroData 205 had become a successful product. It was a relatively low-cost computer system for its day, but due to its drum memory and digit-sequential internal operation, it was also relatively slow. It had robust magnetic tape and punched-card facilities, however, and even though it had originally been designed with scientific computation in mind, these input-output facilities gave it an entry into businesses with a need to process large repositories of data -- the field of "commercial" data processing.

ElectroData needed to pursue these commercial customers and workloads if it was to stay in the computer business, and for that they would need a new, larger, faster system. They saw an opportunity to produce a larger system at a lower price point than competing systems of comparable size. The problem was that they were extremely strapped for capital just to continue their current operations, let alone to design and build a new system. The situation was so acute that, by early 1956, ElectroData was seriously considering terminating operations and closing the business. It was precisely at that point that Burroughs, having significantly more capital, and looking for an acquisition to boost their attempts at entry into the commercial computer business, came calling.

Prior to this, ElectroData had studied the possibility of modifying the 205 to use magnetic core memory instead of a drum. That idea proved not to be viable, for both technical and economic reasons, but it did initiate some preliminary work on a design, known as Project 737, for a new system that would use core memory.

As ElectroData's acquisition by Burroughs was closing, this new design was chosen over the BEAM IV, a system designed under the direction of Issac Auerbach at the Burroughs Research Center in Paoli, Pennsylvania. Project 737 became the Burroughs 220. While Paoli had their BEAM IV canceled, they did get to build the core memory for the 220.

The 205 and 220 are sometimes referred to as the B205 and B220. This is incorrect. The Burroughs B200-series systems, which eventually expanded to the B100/200/300/500-series, came immediately after the 220, ca. 1960. They were small, transistorized, variable field-length, character-addressable computers. Architecturally, they were very different from the 205 and 220. They were, however, somewhat similar to -- and competed against -- the IBM 1401.

Since the 220 is an outgrowth of the 205, and retained a number of the 205's characteristics, let us first review the architecture of the 205 and then see how the 220 differed.


A Review of the ElectroData 205


The 205 was initially conceived at Consolidated Electrodynamics Corporation (CEC) as a digital calculator. CEC made mass spectrometers, and analysis of the data coming from these instruments requires solving systems of simultaneous linear equations. By the mid-1940s, CEC had built analog devices that could solve  systems with up to 12 unknowns, but to solve larger problems they needed to go digital.

CEC recognized early that the calculator would have additional potential if developed as a fully-programmable computer, so they expanded their scope and designed a system initially known as the CEC 30-201. The development proceeded through models -202 and -203, at which point CEC spun off the computer business as ElectoData, and the 30-203 became the Datatron 203. The 203 had only paper-tape input/output, plus a 10-character per second Flexowriter printer. Enhancements to support magnetic tape resulted in the Datatron 204, and finally adding the Cardatron punched-card interface resulted in the Datatron 205.

ElectroData/Burroughs 205 System

205 Drum Memory


The design of the 201 through 205 systems was oriented around their drum memory. Data was stored on the drum as 44-bit words, with each word organized as 11 four-bit BCD digits. The high order digit was used as the sign, with the low-order bit of that digit indicating positive (0) or negative (1). The other three bits of the sign digit were not generally defined for internal processor operations, but did have significance in some I/O operations. The remaining 10 digits of a word represented either a signed-magnitude decimal number or five alphanumeric characters. As an option, the later systems supported floating-point arithmetic, which used the high-order two digits of a word as an exponent biased by 50 and the low-order eight digits as a fractional mantissa. The sign digit retained its meaning in floating point as for integer values.

The memory drum was organized in 24 tracks of 200 words each. It rotated at 3750 RPM, so a full revolution took 16.8 milliseconds. Switching between tracks took negligible time, but the average latency until a desired word came under the read/write head was half a revolution, or 8.4ms. This was slow -- compare it to the IBM 650's drum, which rotated at 12,500 RPM. The choice of a slower drum was apparently made for reasons of cost and reliability.

205 Memory Drum


20 of the tracks on the drum formed the computer's main memory of 4000 words. To help compensate for the slow access time, the other four tracks were organized as recirculating delay lines, termed the high-speed loops, with the read and write heads separated by one-tenth of a revolution. This allowed storage of only one-tenth the number of words (20) per track, but with one-tenth the access time (0.84ms average). Special instructions could block 20 words in the main memory to or from one of the loops in a single drum rotation. Executing instructions and accessing data in the loops was almost ten times as fast as main memory. Doing so was highly desirable, but programming for it was complicated by the need to block and unblock words explicitly between the loops and main memory.

The drum was so central to the design of the system that even the clock signals for the electronics came from the it. Prerecorded tracks provided pulses for digit and word timing, plus a once-per-revolution signal to assure that the processor's address coincidence logic stayed in sync with the drum. These timing tracks gave the 205 an effective clock rate of 142.8 KHz.

205 Registers and Data Flow


The 205 had the following major registers:
  • A -- the accumulator.
  • R -- the "remainder" or accumulator extension of 10 digits. Digits could be shifted between this register and A, but R could not be loaded or stored directly. The Multiply instruction multiplied A by a value in memory, producing a 20-digit product in A and R. The Divide instruction divided the 20-digit value in A and R by a value in memory, leaving the quotient in A and the remainder in R. R was also used to store the return address in subroutine-branch instructions.
  • B -- the index register. The ElectroData 203/204/205 were the first commercial systems in the U.S. to offer this form of address abstraction, although the idea appears to have come from the UK Manchester Mark 1 by way of Harry Huskey, who consulted with the original CEC design team.
  • C -- the "command" register holding the current instruction. This 10-digit register held the two-digit operation code, the four-digit effective operand address, and the four-digit address of the next instruction to be executed. By default, the instruction address incremented automatically during fetch of an instruction into C. Branch instructions simply replaced this default address with the effective address from the branch instruction.
  • D -- the "data" register. It buffered a word coming from memory or a peripheral device.
Each track on the drum was recorded bit-parallel but digit-sequential. That is, each digit-wide logical track consisted of four bit-wide physical tracks. Data entered the processor from memory or the peripheral devices one digit at a time into the D register. Data exited the processor for storage in memory or writing to peripheral devices one digit at a time through the A register. Because words entered the processor low-order digit first, buffering an incoming word in this register also allowed the processor to examine the sign -- which arrived from the drum last -- before commencing an arithmetic operation.

Since the data came into and left the processor in a digit-sequential manner, all internal processing was done digit-sequential as well. The adder was only one digit wide, and all inter-register transfers occurred one digit at a time. In fact, all inter-register transfers went through the adder, which would actually add or not, depending on the operation. The digit-sequential design also reduced the complexity of the electronics, helping keep the size and cost of the system down.

Burroughs 205 Processor Data Flow

205 Instruction Format


Words holding executable instructions had the following format:

± CCCB PP AAAA

where:
  • ± is the sign digit. If the low-order bit of this digit is 1 (negative), the contents of the B register are added to the AAAA field as it is transferred into the C register, thus indexing the operand address prior to instruction execution.
  • CCC are the so-called "control" digits. These had significance primarily for I/O instructions.
  • B is the breakpoint-skip digit. Bits in this digit would cause the computer to halt or skip the instruction based on switches set on the Control Console. It was used for program debugging.
  • PP is the operation code, e.g., 74 for Add or 20 for Change [Branch] Unconditionally.
  • AAAA is the operand address. In most instructions it referenced an address on the drum, but in some instructions, such as shifts, it signified a count, and in others it had no significance. B-register modification of this field would occur regardless of its significance.
With this background on the 205, we can now examine how the design of the 220 differed.

The Burroughs 220 Architecture


Both architecturally and electronically, the 220 was quite similar to the 205. It was still a decimal, vacuum-tube design. The 220 retained the 205's 11-digit word format, instruction format, and numeric representation. Core memory replaced the drum. Memory sizes could range from 2,000 to 10,000 words in 1,000-word increments. A typical memory size was 5,000 words. There being no drum, the clock was supplied by an oscillator circuit, and at 200 KHz, was only slightly faster than the 205's 142.8 KHz rate.

The Operational Characteristics manual describes the architecture, instruction set, and input/output devices in detail.

While the 220 retained the instruction word format of the 205 and many instructions worked similarly, the operation codes and control (now termed "variant") digits were entirely different. Programs for the 205 had to be rewritten to run on the 220. That said, the 220 was a much easier system to program than the 205, first because the design headache of blocking 20 words at a time into the high-speed loops was no longer an issue, and second because the 220 had a more powerful instruction set.

Burroughs 220 System

220 Registers and Data Flow


The 220 retained the same major registers as the 205, but with a few changes and additions:
  • The A and D registers were the same, except that now data both entered and left the processor through D.
  • The R register had the same function in arithmetic and shift operations, but was expanded to 11 digits to accommodate a sign digit. It no longer stored the return address for a subroutine call. R could also be loaded and stored directly from and to memory, and could be compared directly to a word in memory.
  • The C register was still 10 digits and held the op code and effective address, but not the address of the next instruction to be executed (see P below). It was a copy of the instruction word from memory, without the sign, and after any B-register indexing of the address field had been applied. Therefore, it also held the variant digits from the instruction word.
  • The B register was the same, although there were additional instructions for loading, incrementing, decrementing, and branching based on its value.
  • A new register, P, was implemented to hold the next-instruction address.
  • A new register, E, was implemented to hold the address of a word to be loaded from or stored to the core memory.
  • A new register, IB (input buffer), was implemented to hold the word loaded from or stored to memory. Words were generally transferred to and from this register and the D register, but not always.
  • A new register, S, was implemented to replace the function of the breakpoint digit in instruction words. You could set an address in this register and enable it with switches on the console. When execution reached that address, the processor would halt.
 All of these registers except for IB were shown on the 220's rather fancy console:

220 Control Console


The 44 bits of a word were transferred in parallel between the core memory and the IB register in a single five-microsecond clock cycle. Then the data moved between IB and D, and through the other registers, in the same digit-sequential fashion as in the 205. The adder was still only one digit wide, and most inter-register movement continued to be gated through it.

220 Processor Data Flow

This sequential operation and the only modestly-faster clock meant that the internal performance of the 220 was little better than that of the 205. Most of the system's speed increase came from eliminating the latency of the drum memory.

Retention of digit-sequential operation appears to have been a conscious decision, probably to reduce the cost of the system and allow it to come to market more quickly. An internal ElectroData memo from 5 June 1956, after the Burroughs acquisition was announced but before it closed, stated:
The basic configuration of the 220 will be the same as the 204, with the exception of the Core Memory. New circuitry in the 220 will be held to a minimum. Generally the plug-in [vacuum tube] packages will remain the same.

We do know that the concept of the 220 was not fully realized in the design that was finally built, at least in the mind of its chief logician, Edward (Ted) Glaser. In his 1973 oral biography, on file at the Smithsonian National Museum of American History, he had this to say (page 24):
It turns out that what the 220 was supposed to be was the 205, with the loops removed, the recirculating loops, and a small core memory put in. That was my assignment. And it became quite clear that with the speed of core that was then available, this couldn't be done and it was a ridiculous balance. There was no way I could prove that to anyone. So I did one of the lowest-down, dirtiest tricks I've ever done. I designed five machines before I told anybody about any of them. And each one had glaring faults. And I was able to escalate Burroughs from one machine to the next. Well, it turned out we got stuck on four. We didn't build five. So four -- 220 was the fourth in the series. It was not the machine I really wanted to build, but it was close to it.
At that point, Glaser appeared to start to talk about the fifth design, but the interview was interrupted, and it never came back to this topic. So we'll never know what he had in mind for his fifth design, or the ways in which he thought the 220 as built was still deficient.

220 Partial-Word Operations


Aside from the advantages that retaining the digit-sequential operation had for cost and time to market, the most beneficial was that it enabled a very useful new feature -- operation on partial words.

The digits in a 220 word are numbered as follows:

±   1 2 3 4   5 6   7 8 9 0

where ± is the sign digit and "0" is interpreted as 10. A "partial word" is a contiguous field of digits denoted by a two-digit pair, referred to as sL (start-Length). The first digit of the pair specifies the starting digit in the field; the second digit specifies the field length. The field therefore consists of the digit numbered s and the L-1 digits to its left. A length of zero is also interpreted as 10.

Thus, the operation code in a word can be referred to as the 62-field -- digit #6 and the digit to its left. The low-order four digits comprising the operand address are the 04-field. The entire numeric portion of the word (all but the sign) is the 00-field. The sign could not be the starting digit of a field, but in most contexts could be included in a partial-word field. Field overflow was not permitted, however -- the sign digit was as far to the left as a field could go. If an sL digit pair had L > s+1, the processor would halt with a Program Check alarm. An sL = 12 field is valid; a 13 field is not.

Partial-word operations were implemented as variations on shifting. Like the 205, the 220 could physically shift or rotate its registers only to the right. Left shifts were actually rotates to the right for the complementary number of digits. In a partial-word operation, the word is simply rotated to the right until the s digit is in the low-order or "0" position, from which it can be transferred to and from the adder. Then it and the next L digits are operated upon (add, transfer, etc.), and finally any remaining digits are again simply rotated until the word is back in its original position. This behavior was mechanized using a special register, DC, the Digit Counter.

Partial-word fields were supported in the following operations:
  • Branch on equality of a two-digit value compared circularly to a field in register A or R.
  • Compare a field in A or R to a corresponding field in a memory word and set the Compare Indicator, from which branches could be made based on a low, equal, or high conditions.
  • Increase or decrease a field in a memory word by a four-digit value, leaving the other digits in the word unaffected.
  • Decrease a field in a memory word by a four-digit value (possibly zero), then load the high-order digits of the resulting value in the field into the high-order digits of B.
  • Store a field from A, R, or B to a corresponding field in a memory word, leaving the other digits in the memory word unaffected.
Being able to operate intrinsically on partial words often eliminated additional instructions that would otherwise be needed to shift and extract digits before manipulating or storing them. This increased the efficiency of both execution and memory usage, partially offsetting the overhead of digit-sequential processing.

The partial-word facilities also provided convenient and efficient ways to modify operand addresses, variant digits, and even op codes in instruction words. A common trick was to implement a switch by adding or subtracting 29 to the 62-field in a word -- toggling the op code between 01 (No-Op) and 30 (Branch Unconditional). Partial-word facilities could also be used to pack multiple values into a single word, allowing programs to maintain larger numbers of values -- a not-insignificant advantage in the days of severely-constrained memory sizes. This was particularly important in the implementation of the Burroughs Algebraic Compiler (BALGOL), which will be discussed in future blog posts.

Additional 220 Enhancements


There were several other notable enhancements to the 220 instruction set over the 205:
  • The A, R, and B registers could be cleared to zero individually or in any combination with one instruction. The 205 could clear only A and R, and A only as a side effect of a store.
  • R could be loaded and stored directly without affecting A. The 205 could load and store R only by shifting values between A and R. This improved the setup for integer multiply/divide operations and allowed R to be used more conveniently as temporary storage. Stores could be of a partial word.
  • Similarly B could be loaded and stored directly, either as a whole or partial word.
  • A word in memory could be cleared to zero with a single instruction.
  • Instructions to compare A and R to a whole or partial word in memory replaced the 205's awkward branch-on-sign-difference mechanism. 
  • The sign digit of the A register could be tested against or replaced by a literal digit value.
  • Loop control was considerably enhanced. The 220 supported the 205's ability to decrement B and branch if it had not underflowed below 0000, but the decrement value could be 0000-9999 instead of just 1. Similarly, there was an instruction to increment B by 0000-9999 and branch if the result had not overflowed past 9999.
  • Looping could also be controlled using a new element, the Repeat Toggle. This was set by instructions that could increment or decrement a partial-word field in a memory word by 00-99. The toggle was set if the operation did not overflow or underflow, respectively, the designated field. The Branch Repeat instruction would branch or not based on the state of this toggle.
  • Subroutine call was supported on the 220 by the Store P instruction, which would store the value of the instruction counter, plus one, into the low-order four digits of the word at the instruction's operand address. This effectively stored a return address, and would typically be followed by a branch instruction to enter the subroutine. Compare this to the 205's Change-and-Record instructions, which stored the return address in the upper four digits of the R register.
  • The 220 supported a full complement of shift operations. Right shifts discarded digits off the low end of the register; left shifts acted as rotates (and as mentioned above, were implemented internally as right rotates). Register A could be shifted left or right, with or without participation by the sign digits. A and R could be shifted together left or right for up to 20 digits. The sign digit did not participate in the twin-register shifts, but it did get copied from A to R or R to A, depending on the direction of the shift.
  • The 220 had a Record Transfer instruction that could move from one to 100 words between locations in memory. The instruction's operand address specified the starting source location; the B register specified the destination address. At the end, B had been incremented to the address after the last word transferred, allowing multiple consecutive transfers to move larger blocks of data.
  • On the 205, overflow in an arithmetic instruction caused the processor to halt if the next instruction was not a conditional branch. On the 220, this behavior could be turned on or off programmatically. There was also an explicit Branch on Overflow instruction to test for overflow and reset the indicator if the branch was taken.
  • The 220 had an explicit No-Op (no operation) instruction that did nothing. On the 205, any unassigned op-code was treated as a No-Op. On the 220, executing an unassigned op-code caused the processor to halt with a Program Check Alarm.

220 Input-Output Facilities


 The 220 supported the same types of input-output devices as the 205, although the I/O instructions and the capabilities of the devices in some cases were quite different.

Console Devices


The so-called console devices included teletype printers, paper-tape readers, and paper-tape punches. A system could support up to 10 readers, up to ten teletypes or punches in any combination, and one special teletype termed the Supervisory Printer, or SPO (pronounced "spoh"). Teletype units could be substituted for punches and vice versa.

The 205's Frieden Flexowriter was replaced by a Teletype Model 28 RO (Receive Only) teleprinter, which operated at 10 characters per second. The Model 28 had the advantage that it used a moving type box to position characters on a line rather than the Flexowriter's moving typewriter carriage. The SPO was identical to the other teletype devices and was interchangeable with them. The SPO was addressed by a different instruction in the processor, however, and that instruction had an automatic decimal-point insertion feature that instructions for the other teletypes did not.

ElectroData designed and built their own high-speed paper-tape equipment, using 7/8-inch (22mm) tape and a seven-level code compatible with the IBM Eight-Channel Tape Code for the Type 046 Tape to Card Converter (a variant of the 026 keypunch). The reader was photoelectric and operated at a switch-selectable 500 or 1000 characters per second. It could stop in the space of a single character. The punch operated at 60 characters per second.

As an option, each teletype device could be configured with a paper tape reader, but this could be used only for off-line printing of paper tapes.

The paper-tape punches, teletypes, and SPO were connected to the processor in a daisy-chain. Switches in the device cabinets designated their unit number, 1-10, or SPO. The first device in the chain with a designation that matched that of an output instruction received and acted upon the data. The teletypes and SPO could each respond to multiple unit numbers, so it was possible for the software to address multiple devices but have the output come out on a smaller number of them.

On the 205, words were output to console devices one at a time from the A register. They were formatted as numeric or alphanumeric based on the values of address digits in the instruction words. On the 220, a single instruction could output up to 100 words directly from memory. The 2-bit in the sign digit of a word indicated whether it should be formatted as numeric (0) or alphanumeric (1). Thus, words with signs of 2 were considered to hold five alphanumeric characters, and words of mixed numeric and alphanumeric data could be output by the same instruction. This alpha vs. numeric behavior was effective only for the console devices, however.

Punched Card Devices


The Cardatron punched-card subsystem originally developed for the 205 was adapted for the 220 with very little change. The Cardatron was an interface between the 220 and IBM punched-card equipment. It translated between card or printer columns on the IBM machines and words in the 220 memory, It provided low-level editing of the data during transfer by means of digit strings termed "format bands" that were loaded to the interface from the 220's memory. It could also buffer one card or line image per IBM machine, allowing the processor to continue running while the machine operated on that card or line.

A 220 could have one Cardatron subsystem, which could support up to seven IBM machines. The Type 087 collator was used as a 240-card/minute reader, the Type 523 could be used as a 100-card/minute reader or punch (but not both at the same time), and the Type 407 was used as a 150-line/minute printer.

 The only significant differences between the Cardatron for the 205 and the 220 were (a) the ability to specify a sign of 2 for a word during input translation from a card reader, and (b) data transfer between the 220 memory and Cardatron units went from high to low addresses. That is, Cardatron instructions specified the ending address of the buffer area in memory. The Cardatron processed card and print columns backwards, so the descending addressing allowed the data in memory to be in ascending order. On the 205, data transfer was in ascending sequence, which meant that the words in memory were reversed with respect to their order on the card or print line.

For more information on the Cardatron and its features, see these two posts on this blog for the 205 version:

Magnetic Tape Devices


The 220 took the basic idea of the 205's magnetic tape subsystem and significantly extended it. The 205 used 3/4-inch (19mm) plastic tape on 2500-foot (762m) reels. The tape had two parallel lanes that each stored digit-wide frames at 100 bits/inch and moved at 60 inches/second. Only one lane could be read or written at a time, but the lane was programmatically selectable. Data was recorded in fixed-length blocks of 20 words each. Individual blocks could be overwritten in place. A full reel of tape could hold 10,000 blocks. Each block was assigned a four-digit number. The tape subsystem could search bidirectionally for a specified block number independently and asynchronously from the processor.

The 220 enhanced the 205 tape implementation in the following ways:
  • The tape was physically identical, but came on 3500-foot (1067m) reels.
  • The tape still had two parallel lanes, but data was recorded at 208.33 bits/inch and the tape moved at 120 inches/second -- twice as dense and twice as fast.
  • Blocks could be 10-100 words in length, and a tape could have mixed block sizes. Blocks could still be overwritten in place, but once a block of a certain size was written on tape, that size could not be changed. The entire tape had to be erased (a process known as "editing") and rewritten in order to change block sizes.
  • Up to ten blocks could be read or written in a single instruction. Variants of the instructions allowed reading and writing sequences of mixed block sizes. Tapes could also be spaced forward or backward up to ten blocks at a time.
  • Instead of block numbers, the first word in each block was considered to be its identifier or "keyword". The tape subsystem could search a tape bidirectionally and asynchronously for the block with the highest keyword that was less than or equal to a specified value. Optionally, the match could be made on a partial-word field. The search stopped with the tape positioned to read the matching block. In order for the search to work as intended, the keywords had to be unique and written in ascending order, but it was not a requirement that tapes be created in that particular fashion.
  • In addition to the bidirectional keyword search, the tape subsystem could search asynchronously in the forward direction for a block where a specified word in the first ten of the block matched a value. This was termed a "scan." This match could also be made on a partial-word field. As with search, a scan stopped with the tape positioned to read the matching block.
  • Instead of a simple end-of-file mark like the IBM tapes had, the 220 could write and sense two types of special blocks on the tape:
    1. An End-of-Tape block was typically written at the end of information on a tape, but could be placed anywhere. It contained a single control word (although the block physically occupied ten words on tape) that held two addresses:
      • The 64-field of that control word was the address of a word in memory where the values of the P register and 04-field of the C register would be stored.
      • The 04-field of the control word was the address to which the processor would branch when the block was read.
      An EOT block would terminate a search or scan operation, but the control word would not be acted upon until the block was actually read.
    2. A Control Block was one where the sign digit of its keyword was 7. When this type of block was read, all words in the block except the last were transferred to memory. The last word was not transferred to memory, but was acted on in the same way as the control word in an EOT block, storing fields from the P and C registers and branching to a specified address.
Like the 205, the 220 had two types of tape drives. The first was a traditional free-standing, reel-to-reel unit. It had an unusual design -- waist-high, with a slanted tape deck that held the reels, heads, and vacuum columns, as shown in this image from the Georgia Tech installation:

220 Free-standing Tape Drives
The second type of tape drive was the DataFile, a pre-disk design intended to provide faster random access to large data sets. It was another waist-high cabinet, but with 50 parallel bins instead of reels, each bin holding a 270-foot tape strip. The strips looped over a set of rods that supported a head assembly on a moving carriage.

220 DataFile Tape Unit
The carriage could position to any one of the tape strips within 1.5 seconds and drive that strip forward or backward. Except for their shorter length, the tapes, recording characteristics, and tape operations were identical to those for the free-standing units. While tape in the free-standing drives had two lanes, the DataFile acted as if it had a tape with 100 lanes. The tapes were not removable except for maintenance, so the DataFile was used more like a disk drive than a tape unit, albeit one with a large access latency.

This image shows the interior of a 205 DataFile, but the internal mechanism for the 220 was similar:

205 DataFile Showing Tape Strips


High-Speed Printers


Burroughs developed an early electrostatic printer named the Whippet that could output about 250 characters per second. It used coated paper and heat to fix a dry ink to the surface of the paper. It was originally developed for the U.S. Army Signal Corps, but at least a few units were installed at non-government sites, including one at CalTech. It could substitute for one of the teletypes.

Burroughs also developed its own high-speed drum printer for the 220, a design that continued to be refined and used into the 1970s with the B-series computer systems. The printer for the 220 could be used in two ways. It could be attached directly to the system and driven programmatically. It could also be used off-line, with a separate control unit that read data from a free-standing tape drive. The control unit was configured through a plugboard and was designed with the intent that data could be formatted and printed directly from master files, avoiding tying up the rest of the system for long print runs. The idea of off-line printing did not survive beyond the 220 era, however.


The retro-220 Project


I started a project in late 2016, having as its main goal the development of a web-browser based emulator for the 220, along the same lines as the retro-205 project for the 205. The emulator is written in Javascript and uses standard HTML and CSS to create a user interface within the browser. Due to the similarities between elements of the 205 and 220, I was able to port quite a bit of the code for the 205 emulator over to the 220.

Like my earlier emulation projects, the retro-220 emulator is open source and available for anyone to use. The emulator itself and all but the magnetic tape implementation were substantially complete by late Spring 2017. The 220 tape subsystem proved to be a significant challenge, and was not completed until late 2017. At this writing, the emulator is at version 0.06, and is complete except for the DataFile and high-speed drum printer devices.

This screen shot shows the emulator in action:

retro-220 Emulator Running from the Firefox Browser


The second goal for this project has been reconstruction of the Burroughs Algebraic Compiler for the 220, better known as BALGOL. This was an early implementation of the Algol-58 language, the predecessor to the better-known Algol-60. The compiler was first released in March 1960. Donald Knuth, who participated in its development, has donated a scan of the compiler and library listing to the Computer History Museum in Mountain View, California. An earlier, less complete listing is also available on bitsavers.org.

I have used Professor Knuth's listing to transcribe the assembly language source code for the compiler and its library, and have written two cross-assemblers to generate 220 object code from those transcriptions. The reconstructed compiler is now starting to work and is presently undergoing further testing and validation. The current state of its development can be found in the retro-220 project repository.

At this point, I am starting to work on a wiki for the emulator and compiler that will be available on the repository web site. I am also preparing additional blog posts on the project. The next one will be an introduction to the emulator and its user interface, so stay tuned.