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.

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 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 condition.
  • 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.

22 comments:

Bill said...

I've looked at your 205 emulator with something approaching awe. I collaborated with Tom Sawyer briefly prior to the demise of my mother whose estate I administered. I met with my first 205 in 1963 and quickly became a groupie. Your reconstruction of the Algol compiler (and in particular, its library) is most impressive.
KUDOs for your achievement.
It belongs in a computer museum for posterity.
Thanks again,
Bill

Paul Kimpel said...

Thanks, Bill. Both the 205 and 220 (and their respective Algol compilers) have been really interesting things to work on, and it's gratifying to have been able to take them as far as I have. My goal has been to recreate the panels and peripheral devices in a way that at least evokes the real machine and what it was like to use it. I couldn't have done nearly as good a job of it without Tom's advice, experience with the 205, diligent research at CBI, and not infrequent admonishments when I managed to get things wrong.

Dr. Leonard Kreuter, Clevelan dech ep said...

I BELIEVE I COMMUNICATED MR SAWYER SEVERAL YEARS AGO. I WAS WITH ELECTRODATA STARTING IN 1956 WORKING AS A TECH REP IN THE CLEVELAND DISTRICT OFFICE.

ALAN READE THE DISTRICT MANAGER CONTRACTED WITH DON KNUTH, THEN A CASE INSTITUTE STUDENT TO DO PROGRAMMING FOR A B205. I BABY SAT DON THE FIRST TIME HE LAID HANDS ON A B205. THE SYSTEM WAS INSTALLED AT CLEVELAND GRAPHITE BRONZE. I WAS NOW A SALESMAN AND THE CLEVELAND GRAPHITE 205 WAS MY INSTALLATION. I WAS NOT AWARE OF THE FACT THAT KNUTH HAD NEVER SEEN A DATATRON BEFORE. WITHOUT MORE THAN A HELLO KNUTH WENT TO WORK ON THE SYSTEM INSERTING A PROGRAM AND STEPPING IT THRU READING THE REGISTERS.

THE DATATRON THAT MR SAWYER WORKED ON WAS A RESULT OF A PROGRAM I INITIATED AT BURROUGHS. IN 1960 I REJOINED BURROUGHS IN WASHINGTON DC. THE WASHINGTON OFFICE HAD A NOW OBSOLETE B205 IN A DEMONSTRATION ENVIRONMENT ON SITE.

AS I WAS WALKING PAST THE COMPUTER ROOM I NOTICED THE FIELD ENGINEERS PAKING UP THE SYSTEM FOR SHIPMENT. I ASKED THEM WHERE IT WAS BEING SENT. THEY TOLD ME IT WAS BEING SHIPPED BACK TO THE PASADENA PLANT FOR STORAGE. RECOGNIZING THE COST CRAZINESS OF SHIPPING AN OBSOLETE PRODUCT ACROSS THE COUNTRY TO A WAREHOUSE WHERE IT WOULD REMAIN FOREVER WAS MADNESS. I IMMEDIATELY DROVE INTO VIRGINIA AND WENT TO A SMALL TECHNICAL SCHOOL, MET WITH MANAGEMENT AND TOLD THEM BURROUGHS WOULD DONATE A B205 TO THEM AND THAT ALL THEY HAD TO DO WAS PURCHASE TAPE DRIVE PERIPHERALS.

THEY AGREED. UPON RETURNING TO THE DISTRICT OFFICE I TOLD THE DISTRICT MANAGER THAT INSTEAD OF PAYING TO SHIP THE SYSTEM TO PASADENA THE SCHOOL WAS PAYING TO HAVE THE SYSTEM SHIPPED, PAYING BURROUGHS TO INSTALL IT, AND PURCHASING THE SYSTEMS TAPE DRIVES. IN ADDITION THERE MIGHT VERY WELL BNE SOME TRAX BENEFITS TO BURROUGHS AS A RESUL;T OF THE DONATION.

FORTUNATELY FOR MY CAREER, THE VICE PRESIDENT OF MARKETING (KEN BEMENT) WAS VISTING THE WASHINGTON DISTRICT MANAGER (IRV RECTOR). WHEN HE LEARNED WHAT I HAD DONE HE ASKED TO DOCUMENT A PLAN AND SEND IT TO DETROIT.

3-4 MONTHS LATER I FOUND MYSELF IN DETROIT, BEING CALLED THE JUNKMAN HAVING BEEN GIVEN THE 205 & 220 WAREHOUSE INVENTORY, RUNNING AROUND THE COUNTRY DONATING SYSTEMS TO UNIVERSITIES AND SELLING PERIPHERALS.

I FURTHER EXPANDED THE PROGRAM FOR SYSTEMS THAT WERE STILL INSTALLED CONVINCING USERS TO EXECUTE THE PURCHASE OPTION AS THE SYSTEMS WERE CLOSE TO REPLACEMENT AND DONATE SYSTEMS TO UNIVERSITIES REAPING THE TAX BENEFITS ASSOCIATED WITH THE DONATION.

WHEN I DEPLETED THE ENTIRE 205 & 220 INVENTORY, BURROUGHS HAD INSTALLED ABOUT 20 B5000. WHERE THE ONLY THING WE COULD GUARANTEE THE USER WAS SLOW PROCESSING AS THE OPERATING SYSTEM CHEWED UP THE CPU AND DOWNTIME.

I WAS NOW KNOWN AS BEMENTS BOY. THEY TURNED THE B5000 PRODUCT OVER TO ME WITH THE MARKETING MISSION OF GETTING THE USERS WHO WERE NOT PAYING RENT TO PAY RENT AND TO KEEP THE SYSTEMS IN THE FIELD OPERATIONAL. TO ACCOMPLISH THIS I HAD A SMALL GROUP OF FIELD ENGINEERS AND PROGRAMMERS WORKING OUT OF DETROIT FURTHER SUPPORTED BY THE PASADENA ENGINEERING AND PROGRAMMING COMMUNITY. (I WAS FRIENDLY AND/OR ACQUAINTED WITH LLOYD TURNER, CLARK OLIPHANT, BEN DENT, NORM KREUDER, ETC. ALL OUT OF PASADENA

AFTER STABILIZATION OF THE B5000 BY GOING TO THE B5500 WITH THE DISK OPERATING SYSTEM I WAS THEN MADE MARKETING MANAGER FOR LARGE SCALE SYSTEMS. B5500 SYSTEM SALES HAD STALLED AND CONSIDERATION WAS BEING GIVEN TO CLOSING DOWN THE PRODUCTION LINE.

(I THINK THATS ENOUGH EGO HISTORY FOR TONITE - LEN KREUTER)

Andrew said...

I came across the following book on Ebay today: AN INTRODUCTION TO CODING THE BURROUGHS 220; PUBLISHED 1959. I decided to buy it and try my hand at programming a BALGOL program or two. When studying Computer Science at RIT in the mid 80's, we were taught that Algol was the common ancester of most common procedural languages in popular commercial use. I was very excited to see an actual B205 emulator. And what a great story by Len Kreuter. You guys made history!

Paul Kimpel said...

Thanks, Andrew. I'm aware of the 1959 INTRODUCTION book, and have a scan of it courtesy of Michael Mahon. It's definitely an introductory text that omits many details, some of them quite significant, but it's a good resource for getting started with the 220 and programming concepts in general. The 1960 "Operational Characteristics of the Burroughs 220" (bulletin 5020A, http://bitsavers.org/pdf/burroughs/electrodata/220/5020A_B220_OperCharac_Aug60.pdf) is a much better reference once you've mastered the basics in the INTRODUCTION.

Algol has indeed had a major influence on almost all procedural languages developed since 1960. I still program in the extended version of Algol-60 for the Unisys ClearPath MCP (nee Burroughs) systems, still enjoy it, and even occasionally get paid to do so.

I'm not sure we've made any history with this project, but we've certainly recovered some significant bits of it and made those accessible.

Unknown said...

Paul, you and Tom did a fantastic job on this. I'd love to be able to reverse-engineer the code that loads the library routines so as to be able to reconstruct the missing library routines if only by inference. Not enough hours in the day.

But I really and truly admire your methodical work on the emulators and compilers. I've never ever seen a 220 - the 204/205 was all I was ever exposed to in the Burroughs/Electrodata product line. But they really were fun machines to learn on.
So easy to program, we always coded for format band 1 because machine language was so very easy to learn for the 205.

All the best to you and yours...

Paul Kimpel said...

Thanks very much. Tom Sawyer has been done some work on the missing library routines for Knuth's 205 Algol-58 compiler, but there hasn't been much progress recently. I think he's determined the format of the routines on the compiler tape and how the compiler finds them for linking in the overlay module, but I don't think he's tried to actually code any of the missing routines. We have a complete library for the 220 BALGOL compiler, however, so we are hoping those can be adapted to the 205.

Just for the record, I've never seen a 220, either -- or a 204/205. The B5500 was the first Burroughs machine I worked with, and I messed around with the B300 a little bit in the early 1970s.

Bill said...

I enjoyed your site and all the technical details and was wondering if you had any additional information on the production of the Burroughs 220. I recently bought a Burroughs 220, but just these units, two 551 magnetic tape storage units, the 550 magnetic tape control unit, and the 415 control console. The serial number of the control console is 138 and the tape drive controller is number 142. I was wondering if you knew the total that were built, production years (I think this one was 1958) and if there are any still left, in museums or private collections. It was saved from a college getting rid of it 50 years ago by a guy who stored it in his home's basement, probably just these smaller units were all he could move down there, and even they are extremely heavy. I want to preserve it, but also try to get the tape drives working again. The tape drive controller is missing several plug in circuit boards though. I would also like to build a sequencer for the neon bulbs in the control console to simulate it working.
Thanks for any help.
Bill

Paul Kimpel said...

Wow. Thanks for the information, Bill. There was a 220 console that surfaced a few months ago in Indiana, which I have since heard was sold -- by chance is that the one you acquired?

I have some basic information on the 220 dates and production numbers, but I'm passing that question on to Tom Sawyer, who has done a lot of research at the Charles Babbage Institute in Minneapolis on these early machines. He will probably be able to give you more definitive information.

My understanding is that design of the 220 started at ElectroData in Pasadena some time before Burroughs acquired ElecroData in mid-1956. I think production started in 1957 and first customer deliveries were either in late 1957 or early 1958. Around 60 systems were built, and the market response to the system was a disappointment to Burroughs. Considering that this was arguably the last of the significant vacuum-tube systems, and that IBM, Sperry Univac, and Philco were already starting to bring transistorized systems to market, Burroughs is perhaps fortunate that it sold as many as it did. I suspect production had stopped by the time the B5000 was released in early 1963, and perhaps earlier than that.

I think the Stanford University 220 was replaced by a B5000 in 1963 or 1964. I have been told by someone who was there that the CalTech 220 was decommissioned in 1966 and that the Burroughs Pasadena plant got rid of all of their 220s by 1968. I doubt that any customer systems ran much longer than that -- they would have been really expensive to run and maintain -- and probably most were shut down by the mid-1960s.

I don't know of any complete or partial systems either in museums or private collections. Hollywood used a number of 205 and 220 systems as props in movies and TV shows (e.g., see http://www.starringthecomputer.com/computer.html?c=325), and it's possible that there may still be pieces of one or more 220s in the stygian depths of some backlot warehouse.

You have tape drives!! One of the people who has worked with me on my 220 emulator has a 220 tape in deep storage. We would love to be able to get the bits off of it, because we think it holds some significant software. I think your idea of trying to get the drives and tape controller working again is really interesting, but I think what we need is something much simpler -- tape heads, a tape path, and some way to handle the reels.

Finding appropriate heads has been our major stumbling block thus far. If you would be willing to work with us, it might be possible that we could use one of your drives to pass the tape and tap the signals coming off the heads, perhaps by manually cranking the reels. With that, we should be able to amplify and record the flux transitions on the tape, then worry about decoding them into usable data off line. If you would be interested, we could really use your help (not to mention your drives).

Your idea of building a sequencer to drive the console lamps is also interesting, but we have a couple of 220 emulators now. What about connecting one or more of those emulators to your console and driving the lamps realistically? The electronics to do that are beyond my skill, but I know how to run 220 code with relatively accurate timing and generate register values for output.

This is the biggest 220 hardware find I know of, and raises a number of interesting possibilities.

If you'd like to correspond privately, my address is paul dot kimpel atsign digm dot com. I'm in San Diego, California.

Thanks again for posting, and for rescuing this equipment.

Doug Crawford said...

Hello:
This Burroughs component is dated 1957.
Would this have been part of the 205?
If not can identify it?
https://imgur.com/a/pty7qiJ

T J Sawyer said...

Hi Doug,

I believe that you have a board from a Univac 1101 (which would have been originally an ERA computer assembled in St. Paul.)

The Burroughs logo indicates that it was manufactured at the Electronics Instruments Division (EID) of Burroughs. This division was created about 1952 to manufacture the Pulse Control Units that Burroughs newly created Research arm had developed. EID existed in a separate facility in Philadelphia until about 1963 when it was merged with another division in Plainfield, NJ. EID was largely involved in manufacturing core memory by that time and Plainfield was heading that effort.

It is likely that ERA contracted out manufacture of some components to Burroughs EID, something that I was unaware of.

Hope this helps. Thanks for a nice link.

Doug Crawford said...

@ T J Sawyer: Thanks best lead yet. I wondered about the 1101 computer since it
does have the ext "TYPE 1101" on it. This was acquired by an associate in
a PA or NJ Ham Fest or other swap meet some time ago.
So it being related to production in PA or NJ might make sense.
I know the Malvern PA building wasn't around in '52, but the manufacture is '57.
It is also curious why Remington Rand asset tags are on it- would they have
aquired it for research/study? That tag says Philadelphia too, likely the building
of the Eckert & Mauchly division?

Doug Crawford said...

@ T J Sawyer: Oh wait you said UNIVAC 1101... Would Remington Rand build an 1101 with a Burroughs Flip-Flop? Why? Echert & Mauchly patented a tube Flip Flop on ENIAC, so they certainly could build their own. Plus the "1101" wording was, I gather, part of the Burroughs build/printing, would they have printed 1101 on it on behalf of Remington Rand? Maybe.
If you feel strongly about this I'll hit up UNIVAC people. Thanks for your input!

Doug Crawford said...

@ T J Sawyer: You put me on the right track. I found this which lists various
rack mount instrumentation devices, including a flip flop.
https://dome.mit.edu/bitstream/handle/1721.3/39196/MC665_r05_M-1774.pdf?sequence=1&isAllowed=y

Paul Kimpel said...

@Doug Crawford: As Tom pointed out, the UNIVAC 1101 wasn't built by UNIVAC -- it was originally designed and built by ERA (Engineering Research Associates) in St. Paul around 1950. ERA had been founded after WW II by William Norris and Howard Engstrom. Shortly after the 1101 was finished the company ran into serious financial difficulties, and was then purchased by Remington Rand in 1952.

So perhaps that flip-flop was tagged as Remington Rand property at the time ERA was acquired, and any tagging for ERA was removed or never existed to begin with.

Norris and Engstrom of course went on to found Control Data Corporation, and Remington Rand (later Sperry) went on to build more systems in the 1100-series. The 1100 engineering facilities remained in the Minneapolis area, and Unisys (created by the merger of Sperry and Burroughs in 1986) still maintains an engineering facility for the modern descendants of the 1100s in Egan, MN.

Doug Crawford said...

@ Paul Kimpel:
That's informative facts I'm glad to know.
However I'm not sure that this is material to our device: https://imgur.com/a/pty7qiJ
as its tag shows it was built by Burroughs in Philadelphia in '57, and this
document:
https://dome.mit.edu/bitstream/handle/1721.3/39196/MC665_r05_M-1774.pdf?sequence=1&isAllowed=y
discloses that devices that seem to be of type are associated with that division.

Doug Crawford said...

In other words, the 1101 on the front of this associates it with the
rack mount models of instrumentation disclosed in the letter from MIT.
It is a coincidence then that ERA named their computer 1101 in '52.

Doug Crawford said...

FYI - if you didn't revisit the imgur link, I added more photos there in the middle of this discussion.

T J Sawyer said...

I will revise my suggestion: I am quite sure that this is a "Pulse Control Unit" from Burroughs EID. See Electronics, October 1952, page 156 at
https://worldradiohistory.com/Archive-Electronics/50s/Electronics-1952-10.pdf
where Harry Kenosian descibes the several PCU units available including the 1101B Flip Flop. There is also a photo of the Burroughs Lab Computer built with the PCUs to demonstrate their capability. The rack-mount chassis and coax connectors appear similar.

I suppose the 1101C is a later model. How the Remington Rand logo got there will take someone with RemRand insight. By the way, the Burroughs Lab Computer utilized an ERA drum but with Burroughs wound heads - so the two groups were certainly exchanging info.

I did a bit of research on two of the tube types in the imgur photos. The 6CL6 appears to have been introduced in June of 1952. I didn't find an introduction date for the 5695 but out in Pasadena, Burroughs was building a special testing deck for them in 1957 as they were going to being used in the Burroughs 220 and there were reports of problems from "some manufacturers" after long cuttoff times.

It appears that the 1101 nomenclature is merely a coincidence. The ERA use of 1101 arose because the newly created NSA gave a number a contracts to ERA and task number 13 (binary 1101) was for the computer in question.

Doug Crawford said...

@ T J: That's awesome. I found mention of the Burroughs Lab Computer in Philadelphia in another MIT memo. I didn't think I'd find anything else about it and there you are!
Even digging up a photo. We have one of the Coincidence Detectors pictured also!
Thanks so much. You even managed to bring us full circle back the 220
with the 6CL6! Well done.
If ya'll are ever near the central New Jersey USA shore, come see our
VCF Computer History Museum at InfoAge, Wall Township NJ. InfoAge.org and VCFed.org.

Doug Crawford said...

OK it gets better: This memo on Project Whirlwind status:

http://www.bitsavers.org/pdf/mit/lincolnLaboratory/MC665/M-SERIES/M-1852_BIWEEKLY_REPORT_19530213.pdf

on page six is reporting to Jay Forrester on details of
the Burroughs Flip Flop, presumably the
flip flop of the equipment explored in the prior memo

https://dome.mit.edu/bitstream/handle/1721.3/39196/MC665_r05_M-1774.pdf?sequence=1&isAllowed=y

So it appears this EID product line found use in project Whirlwind.

T J Sawyer said...

Actually, the EID product line derived from Whirlwind. If you have not read Hoberg's description of the Burroughs Lab Computer, it can be found here:

http://www.bitsavers.org/pdf/afips/1952-02_%2302.pdf

Both Hoberg and Kenosian were veterans of Whirlwind.

There was quite a bit of recruiting to the Burroughs Paoli lab from there and other nearby technology centers.