Emulator Configuration and Version 0.06

It has been more than a year since an update to the retro-205 emulator was last released. I have been tinkering with a few things inside the emulator over the past year, but most of the work during that time has been devoted to reconstructing software for the 205, particularly Donald Knuth's Algol-58 compiler and the Shell Assembler. Both of these have been discussed in prior posts.

This is Paul Kimpel, with another post on Tom Sawyer's 205 blog. Last month I got back to some serious development for the emulator. With that effort now complete, it's time to push out a formal 0.06 release and describe what has changed since 0.05 was released in August 2015. This post will discuss those changes and further project activity in the following main sections:

1. System Configuration Facility
2. Cardatron Leading-Zero Suppression
3. Control Panel Display Enhancements
4. Other Corrections and Enhancements
5. Future Work

System Configuration Facility

Like the color of Henry Ford's Model-T automobile, up until now you could have had any configuration of peripheral devices for the retro-205 emulator you wanted, as long as it was the one I had hard-wired into the software. The I/O architecture of the emulator was designed from the beginning to support user-specified configurations, but I had yet to implement the user interface and persistence mechanism necessary to realize of that part of the design. I finally completed that late in November.

The emulator home page now has a second button below the picture of the 205 at Detroit Arsenal, labeled Configure System.

Emulator home page with new Configure System button

Clicking that second button opens a sub-window, which shows the current system configuration and allows you to change it. The button is enabled -- and the configuration can be accessed -- only after the emulator is initially loaded or when it is in a powered-down state.

Sample emulator configuration window

This page has three areas for selection of Console Units, Cardatron Units, and Magnetic Tape Units. You can change the configuration by altering the controls in this window and clicking the SAVE button. If you only want to view the configuration, or to discard any changes you have made, click CANCEL. Both buttons close the window.

Persisting the Configuration

The configuration data is saved using an HTML5 feature known as Local Storage, implemented in Javascript by the window.localStorage object. Local Storage is supported by reasonably recent versions of all the major browsers. It allows a web page to store information that will persist across browser sessions and workstation restarts. For example, Firefox stores this data in a SQLite data base on your local disk drive.

Data in Local Storage is subject to the browser's same-origin policy, meaning that separate copies of the data are maintained for each combination in a URL of scheme (http/https), host name, and port number. Thus, if you are accessing the emulator on two different web sites, you will have a different copy of the configuration data for each one. The host name is taken literally -- you can access the emulator on my hosting site either at http://www.phkimpel.us/ElectroData-205/ or at http://phkimpel.us/ElectroData-205/. Both URLs will access the same physical files on the server, but those are different origins as far as the browser is concerned. In addition, Local Storage data is maintained differently by different browsers, so Firefox and Google Chrome, for example, will have separate copies of Local Storage data as well.

When you first run retro-205 version 0.06 in your browser, the emulator will recognize that no configuration data is present, and will automatically create a default configuration for you. That configuration is the same as the one that has been hard-wired into the software up to now:

• Console devices: Flexowriter printer, paper tape reader, paper tape punch.
• Cardatron devices: Card Reader 1, Card Punches 1 and 2, Line Printer 3.
• Magnetic tape devices: DataReaders A, B, C, designated as units 1, 4, 5, respectively.

The emulator has previously used Local Storage to persist switch settings for the Supervisory Panel, Control Console, and Flexowriter/Typewriter Control Unit. Those switch settings are now maintained in the new configuration data. When the 0.06 and later emulators first create the new configuration data, they will look for the older switch settings and apply those to the new configuration. The older switch settings will then be deleted. If you subsequently fall back to an older version of the emulator, the older switch settings will no longer be there and will revert to default values. The new configuration data will not be affected by such a fall-back however.

The following sections discuss the areas of the System Configuration window and how you use them to specify the set of peripherals to be included in your 205 system.

Control Console Units

The Control Console is the easiest section to configure. There are three checkboxes to specify whether you want the Flexowriter, paper-tape reader, and paper-tape punch. Any combination of these may be included or excluded from the configuration. The decimal-only keyboard is always present in the configuration, and thus is not represented in the configuration window.

The 205 had two physical paper-tape readers, the slow-speed mechanical reader that was part of the Flexowriter, and a high-speed optical reader. Both are implemented as one unit in the emulator, with the INPUT knob on the Control Console selecting the speed at which the device will operate. Similarly, the 205 had two paper-tape punches, one part of the Flexowriter (punch output was a by-product of printing), and a separate high-speed unit. The emulator supports only the high-speed punch.

Note that if you exclude one of the Console units from the configuration and then attempt to address that unit with a console I/O instruction, the processor will hang on the I/O, waiting for the device to respond. Generally, the only way out of this situation is to clear the system and start over. This is apparently the way a real 205 behaved as well.

Cardatron Units

The Cardatron supports card readers for input, plus card punches and tabulators (line printers) for output. The Cardatron Control Unit had seven slots into which input or output units could be plugged. By convention, input units were numbered from one starting at the left-most slot; output units were numbered from one starting at the right-most slot. Therefore, input unit #2 would occupy the same slot as output unit #6, although of course only one type of unit could be plugged into a slot at a time.

The System Configuration window uses the same convention. For each slot, you can choose a card reader, card punch, or line printer, or you can leave the slot unused. To the right of the unit selection lists are two sets of checkboxes, which apply only to output units:

• If Algol Glyphs is checked, the "&#%¤" characters will print as "+=()", respectively. If this box is unchecked, those characters will print as is. This option can be changed on the device window.
• If Greenbar is checked, output to a line printer device will be grouped in lines of three, with the background color for each group alternating between green and white, simulating the appearance of the pin-feed paper stock typically used with such devices. This option can also be changed on the device window, but is ignored by card punch devices.

Card reader device windows have pull-down lists to specify how their format band is to be selected and the card column from which the band number is to be sensed. These cannot be set on the configuration window, but their setting is now recorded in the configuration data and persisted across emulator sessions.

Card punches and line printers have a new capability with this release to perform leading-zero suppression in specified fields of the output card or line image. The fields are specified as a list of one-relative column numbers in which zero suppression is to begin. The current list of column numbers is shown on the configuration window, but can be set only on the device window. The list of columns is ignored for card reader devices. See the Cardatron Leading-Zero Suppression section below for more information on this feature.

Magnetic Tape Units

The 205 supported two types of magnetic tape devices, the Model 544 DataReader (a traditional reel-to-reel unit) and the Model 560 DataFile (a semi-random access device that used a movable read/write head to access 50 tape strips stored in parallel bins). The emulator currently supports the DataReader, and support for the DataFile is in progress (see below).

Magnetic tape units are identified in two ways. Each of the ten possible units is assigned a letter (A-J) that defines its physical connection to the system. In addition, the drives each have a ten-position switch that specifies their "unit designate." This switch was set by the computer operator. Tape instructions in the Processor addressed units by their designate number, 1-9 plus 0 (for 10), not by their physical unit designation.

The System Configuration window allows you to specify the type of unit for each of the ten physical connections to the system. Until the DataFile is implemented in the emulator, that selection will be treated the same as "(not used)."

You also specify the initial unit designate for each of the devices on the configuration window. This can be changed on the individual units once the emulator has initialized and the unit windows are displayed. Changes made on the unit windows will now be recorded in the configuration data and persisted across browser sessions.

Each unit also has checkboxes on the configuration window to specify the initial state of three switches on the individual unit windows:

• Remote: If this switch is on and a tape is loaded in the drive, the unit will be in a ready condition and can be addressed by the Processor. The switch must be in Local in order to load or unload tapes, or to manually rewind the tape.
• Rewind-Ready: If this switch is on and Remote is also on when a tape finishes rewinding, the unit will be in a ready condition. This setting will be ignored by DataFile units, which did not support programmatic rewind.
• Not-Write: if this switch is on, the unit is inhibited from writing to the tape.

As with the unit designate setting, changes to these switches on the unit windows are now recorded in the configuration data and persisted across emulator sessions.

Note that the contents of tape reels are not persisted across browser sessions. All units are implicitly unloaded after the emulator initializes. When you shut down the emulator by pressing the OFF button on the Supervisory Panel, the contents of all mounted reels of tape are lost. To save data that has been written to tape, you must manually unload the tape and save its contents.

Cardatron Leading-Zero Suppression

The traditional notation we use for decimal numbers presents only the significant digits of the number. Leading zeroes in the whole (integer) portion of a number are not normally written, and often trailing zeroes in the fractional portion of a number are not written as well. Because people are so used to this convention, and because suppression of non-significant zeroes makes the magnitude of a number easier to grasp, computer systems have long supported hardware and software facilities to suppress these non-significant zeroes.

On the 205, leading zero suppression for output devices was done by the devices themselves, not by the Processor. There is a Zero Suppress switch on the Console's Typewriter Control Unit that will suppress leading zeros in numeric values by translating them to spaces before sending them to the Flexowriter.

For Cardatron output devices, leading-zero suppression was done by means of plugboard wiring on the IBM card device -- a Type 407 tabulator for printing or a Type 523 summary punch for cards. As described in the blog post for Knuth's Algol-58 compiler, the behavior of zero suppression on these IBM machines worked in a non-obvious way. Pins on the IBM machine's plugboard identified columns on the output record where zero suppression was to begin. Suppression continued in the columns to the immediate right until a character was encountered that has a "numeric" punch in its card code. At that point, further zero suppression was discontinued until the next column identified for zero suppression, if any, was encountered.

The curious part of this arrangement was the definition of a numeric punch. An IBM card consisted of 80 columns and 12 rows. The top three rows (designated as 12 [+], 11[-], and 0) were termed the "zone" punches. The bottom three rows (designated 1 through 9) were termed the "numeric" punches. Thus, 0 was considered to be a zone, not a numeric punch. Many characters in the IBM card code were represented by two or more punches -- the letter "D" is represented by a 12-4 punch and "$" by an 11-3-8 punch, for example. If a column held a character that has a numeric punch in its card code, that character would discontinue zero suppression.

There are only four characters in the IBM card code used with the Type 407 and 523 devices that do not have numeric punches: "&" or "+" (12 punch), "-" (11 punch), "0" (0 punch), and blank (no punches). Thus as long as columns in a zero-suppression sequence had one of these character codes, suppression would continue, and those columns would be changed to blanks. Of course the way you generate blanks on a card or line of print is to punch or print nothing at all, so zero suppression was effectively output suppression for those columns.

The emulator does not attempt to emulate the IBM devices themselves. Attempting to emulate all the things you could do with a 407 plugboard would be an interesting, but quite daunting task. Thus, the emulator has not been capable of zero suppression on Cardatron output. For example, line 938 from the Algol-58 listing (on page 17):

         313 1 0003 12 0000¤             1   3000000 STA   OUT        D1

is actually output by the MEASY assembler like this:

   0000 0313 1 0003 12 0000¤     0       10003000000 STA   OUT   0  0 D1
   ^    ^                        ^       ^^                      ^  ^
....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|

        10        20        30        40        50        60        70
The ruler below the line shows the 1-relative column positions on the line. In his documentation for the MEASY assembler, Knuth specified the "Break Zero Print Control" columns for the 407 to be 4, 9, 34, 42, 43, 66, and 69, as denoted by the "^" characters above the ruler. This causes columns in that line to be blanked as follows:

   0000 0313 1 0003 12 0000¤     0       10003000000 STA   OUT   0  0 D1

In this case, only zeroes are being suppressed, as you would expect. The reason this was an issue with the Algol-58 compiler recovery was lines like this:

   0000 0002 0 0000 15 7012      0       00000000010 NOR         0& 7

which unfortunately showed up on the listing (page 12) like this:

   0000 0002 0 0000 15 7012      0       00000000010 NOR         0& 7

Alas, that "0&" in columns 66-67 is very significant (meaning "at the current location plus 0"), and since it was suppressed on the listing, was not initially transcribed. That omission changed the intended meaning of the instruction from "Normalize the A register and branch on zero to address ((*+10) mod 20) + 7000" to "Normalize the A register and branch on zero to address ((10) mod 20) + 7000," i.e., to effective address 7010 instead of 7012. Fortunately, this problem was caught due to the difference between the assembled address and the address that was transcribed from the numeric instruction word.

With that rather long introduction to leading-zero suppression for Cardatron output devices and the occasional mischief it causes, this release now supports such suppression. There is an additional button on the control panel for line printers and card punches, labeled SET ZS:

Line Printer window with new SET ZS button

The center of this button will be black if no zero suppression has been configured for the device, and green if zero suppression is currently in effect. Clicking this button opens a sub-window with which you can view, enter, or edit the list of zero-suppression columns for the device:

Zero-suppression panel window

You simply enter a comma-delimited list of numbers that indicate the columns on the output where zero-suppression is to begin. The numbers must be entered in ascending order. Spaces and empty entries (adjacent commas or spaces between two commas) are ignored. To save the list and apply it to the device, click the OK button.

The list of columns is recorded in the system configuration data and preserved across browser sessions. You can view the current list of columns on the System Configuration window, but the list can be changed only through the SET ZS button on the device window.

The recommended list of zero-suppression columns for Knuth's EASY assembler is 13, 14, 15, 20. The Shell Assembler does not require zero-suppression of its output.

Control Panel Display Enhancements

One of the things that has been a lot of fun (and lot of effort) with the retro-205 emulator is the reproduction of the Supervisory Panel and Control Console. Being able to interact with the system in much the same way that programmers and operators did with a real 205 is interesting, and tells us something about the practice of programming, debugging, and operating computers 50-60 years ago.

Both panels operate independently. Every 50 milliseconds or so they interrogate the state of the processor and translate that to on/off settings of the neon lamps on the panel window. That refresh rate (20 times per second) is close to the human ability to perceive visual change (24 frames per second), and about one-third of the refresh rate for most modern computer displays. Even so, the sampling is a binary process -- it results in a lamp being fully on or off for the next 50 milliseconds.

The lamps on a real 205 panel did not behave that way. They were continuously sampling the state of the flip-flops they represented, and since the lamps have a slight persistence, their intensity nicely presented a time-averaged value of the 0/1 state of the flip-flop to which they were connected.

Tom Sawyer saw this early on in the emulator development, and pointed out to me that the Fetch/Execute and Overflow indicators did not behave at all the way he remembered them. I added some code to the Processor to compute an exponential running average of the state of those signals, which yields a value between 0 and 1. I experimented with colors and came up with a set of seven that ranged in apparent brightness from full off (dark gray) to full on (orange, red, white, etc.). It was then easy to convert the fractional average state to one of those colors and display it in the lamp.

That simple mechanism gave a very nice effect, but it only improved the display of those three lamps. I had wanted for some time to extend it to the rest of the lamps on the panels. Last winter, I started experimenting with fractional intensities for the Control Console, and have gradually extended that to the Supervisory Panel as well.

While in principle the idea of computing a running average signal intensity and translating that to lamp color is simple, doing it for the full panels is complicated by two things:

• There's a lot of lamps, and that requires a lot of calculations. There are 230 flip-flops whose state needs to be time averaged. The Supervisory Panel displays all of those; the Control Console displays 187 of them. The exponential running average calculation is of the form
  
  v[n+1] = v[n]*a + x*(1-a)
  where:
• v[n+1] is the updated average for this period
• v[n] is the average computed for the prior period
• x is the new value of the state for this period (0 or 1)
• a (termed alpha) is a decay constant between 0 and 1. Larger values of a diminish the effect of new values of x upon the average; smaller values give new values of x more influence upon the average.
• Ideally, we would update the average intensities at every clock pulse (7 microseconds), but the emulator does not work at the clock level. It works at the instruction level, attempting to accurately represent the state of the Processor's registers and control flip-flops at the end of each Fetch or Execute cycle. Besides, computing 230 averages 142,857 times per second (corresponding to the rate at which digits cycled through the registers) seems a bit much for a dynamically-typed, interpreted language such as Javascript. The panels don't update that fast, anyway.

Backing off from attempting to model lamp intensities at that low a level, I decided to try doing it during the drum latency that occurs at each memory access. There is drum latency during each Fetch cycle to load the next instruction word into the Processor, and another during those instructions that require an operand from memory. These latencies average 8 milliseconds for accesses to the 4000-word main portion of the memory drum, and 0.8 milliseconds for access to the high-speed loops. That is a more reasonable refresh rate.

It also turns out to give a very nice effect. The partial lamp intensities give a much smoother appearance to the display, and actually look like a computer that's chewing away on some problem. My four-year old 3GHz Pentium i3 desktop does not seem to have any trouble keeping up with the calculations. A bigger limitation appears to be the browser's ability to update the screen fast enough. Not only does the emulator need to perform all those calculations, but the browser needs to translate the style changes that set the lamp colors into the appropriate set of pixels and pump them out to the display. Google Chrome and Safari seem to do this best, with a smoothly updating display that looks very realistic. Firefox does less well, with a chunkier update behavior, suggesting that it doesn't (or can't) update the screen as frequently as Chrome and Safari can.

Although the visual effect was nice, initially there were two problems with this approach. The first was that when the Processor stopped, so did the updating of the average intensities for the lamps. The display would freeze with many lamps showing partial intensities. I solved that by putting in extra code at each place a halt could occur to recompute the averages using an alpha of 0, which sets all the averages to the halted 0/1 state of the flip-flops.

The second problem was that nothing was displaying for the Carry and Adder lamps on the Supervisory Panel. I finally realized that the state of those emulated flip-flops was being set only at the end of a Fetch or Execute cycle, and the Carry and Adder are almost always zero at that point. The Adder works in a digit-sequential fashion, so I solved that problem by introducing code into its operation to update the average intensities for those flip-flops for each digit passing through the Adder instead of once at the end.

While these make the panel displays appear more realistic, it has been tacked onto the emulator as an afterthought, and it's all a bit of a kludge. The flip-flops for the registers on the panels go through many more state changes than we are sampling. It would be nice to do a better job of including those intermediate states in the lamp intensities being displayed, but that would require a different approach to the internal design of the emulator, and probably an implementation for some environment more computationally powerful than Javascript in a web browser.

Other Corrections and Enhancements

This release contains the following additional corrections and enhancements to the emulator.

• This project has always operated under the open-source MIT License. A copy of that license is now included in the GitHub repository and on the hosting site.
• A home page with useful links has been added to the project hosting site at http://www.phkimpel.us/ElectroData-205/.
• A second card punch was added to the standard system configuration as Cardatron output unit #2. This was required for use with Knuth's Algol-58 compiler.
• Translation for the "lozenge" glyph was corrected for output to the Flexowriter.
• An annunciator showing the current block number has been added to the magnetic tape panel, just below the spinning reel icon. The tape read, write, and search commands have been modified to update this annunciator as the tape moves. As part of this change tape search was rewritten to allow it to be interrupted more cleanly by a general system clear.
• The windows for the peripheral devices were being opened twice during emulator initialization. This was initially done to avoid having to manually close a lot of windows when the emulator crashed, but it is reliable enough now that the double-open is no longer needed.
• The method used to initially position and size the Control Console window was changed to avoid a bug in Google Chrome.
• When copying lines of output from the "paper" area of a Cardatron line printer device, some browsers (notably Firefox) would insert a blank line between every three lines of text. This was a consequence of using individual HTML <pre> elements to implement the greenbar paper background. The markup has been changed to use <div> elements in a way that avoids the extraneous blank lines.

Future Work

With the implementation of the system configuration capability, there is just one more significant component for the emulator itself that needs to be completed, the Model 560 DataFile storage unit. As mentioned above, this was a type of magnetic tape device, but used multiple strips of tape to achieve semi-random access to data. It interfaced to the Processor through the same Tape Control Unit as the Model 544 DataReader, and was controlled by the same tape instructions.

Much of the mechanics of the DataFile can be taken from existing code for the DataReader, but there are some significant differences. The tape strips were not removable, except for maintenance, so the entire mechanism for loading and unloading tapes goes away. With that, however, comes the need to persistently store the contents of the tape strips across emulator sessions. Read, write, and search work the same as for the DataReader, but lane selection during search also needs to move the tape head to the appropriate strip, a process that could take up to two seconds. Thus, it will be a fair amount of work to clone a DataFile implementation from the existing DataReader one.

After completing the recovery of Knuth's Algol-58 compiler last year, I corresponded briefly with Professor Knuth, who expressed interest in having that program work again, and kindly sent me some additional programs and materials for the 205. Those have been partially recovered and made to run, but more work is needed on a couple of them. These will be described in a future blog post.

Finally, with work on the retro-205 emulator nearing completion, I've started looking for another machine to emulate. The successor to the 205 was the Burroughs 220, a somewhat similar computer design, but with core memory instead of a drum, a much-improved instruction set, and a more sophisticated Algol-58 compiler that was known as BALGOL. A complete listing of that compiler, donated by Professor Knuth, survives on the Computer History Museum web site.

Tom Sawyer has agreed that this blog can be re-purposed as a Burroughs 205 and 220 resource, thus you can expect to see posts on the retro-220 emulator and BALGOL recovery project starting in 2017.

Using the retro-205 Cardatron

This is the second part of a two-part post on the punched-card facilities of the ElectroData/Burroughs Datatron 205 and the Cardatron device that implemented those facilities. The first part of this post reviewed the development of I/O interfaces for the Datatron and described how its Cardatron device was able to connect standard IBM punched-card equipment to the 205.

This second part discusses how the Cardatron and punched-card equipment have been implemented in the retro-205 emulator and how to operate them.

Emulator version 0.04a, with the Cardatron features described below, was released on 7 March and is available from the hosting site at http://www.phkimpel.us/ElectroData/205/webUI/D205.html. The open-source project is presently hosted on Google Code at https://code.google.com/p/retro-205/ GitHub at https://github.com/pkimpel/retro-205/. [Updated 2015-04-11]

Cardatron User Interface

As discussed in the first part of this post, the Cardatron consisted of a central Control Unit and up to seven Input or Output Units. Each Input or Output Unit controlled one IBM card machine.

Cardatron Control Unit

The Control Unit is the interface between the Input and Output Units and the 205 Processor and memory. It also routes I/O commands to the appropriate Input or Output Unit and assures that only one unit is communicating with Processor at a time. In the emulator, the Control Unit has a small window showing its status:

The OU lamp is on if last I/O was to an Output Unit and off if to an Input Unit.

The UDn lamps indicate in binary the unit number last addressed. The emulator presently supports the following units:

• Input Unit 1: IBM 087/089 collator, 240 cards/minute.
• Output Unit 1: IBM 523 card punch, 100 cards/minute.
• Output Unit 2: IBM 407 tabulator/printer, 150 lines/minute. In the next release this printer will be moving to Output Unit 3 for compatibility with MEASY and the Algol-58 compiler.

Eventually, I would like to make the units user-configurable, but at present they are hardwired in the emulator source.

The RDn lamps indicate the current "relay designate" settings. The four bits of the "r-digit" in a CDW (54) instruction would set these relays, which in turn could be sensed by the card machine for special action, typically carriage control.

The GENERAL CLEAR button clears both the Cardatron Control Unit and the Processor. It does not clear the individual Input and Output Units.

The INPUT SETUP button causes a CDR instruction (0 00u0 44 0000) to be forced into the C register of the Processor. This provides a convenient way to preset the Processor to read a card from unit "u" when START or CONT was pressed on one of the control panels. The unit number for "u" was determined by a switch in Control Unit. For the retro-205 emulator, this button unconditionally selects Input Unit 1.

See the section "Loading Object Decks," below, for details on how the Control Unit is normally used with the emulator.

Cardatron Input Unit

The Input Unit interfaced card readers to the Control Unit. In the emulator, each Input Unit has a window that combines the controls for the unit and its reader:

The START and STOP buttons control the ready status of the reader. The reader will not feed cards unless the START button is clicked and is illuminated. You can stop and start the reader while it is reading cards.

The NO FORMAT button lights and the reader goes not ready if the Input Unit cannot determine a format band from the card that was just read. Pressing START in this situation will restart the reader and cause the no-format card to be skipped.

The SM (Start Machine) lamp lights while the card reader is in the process of reading a card and transferring the numeric and zone column data to the buffer drum. The lamp goes out after the card is read and the unit is waiting for the Processor to read the buffer.

The RLO (Reload Lockout) lamp lights when reload lockout is in effect for the unit.

The FLO (Format Lockout) lamp lights when reload lockout has been initiated by a 8-punch in the format column of the card instead of the low-order bit in the k-digit of a CDR or CDRF instruction. Whenever FLO is lit, RLO will also be lit. The following ASCII characters in the format column can be used to initiate format lockout:

• "`" = 1-8 punch (grave accent)
• ":" = 2-8 punch
• "#" = 3-8 punch
• "@" = 4-8 punch
• "'" = 5-8 punch (apostrophe)
• "=" = 6-8 punch
• """ = 7-8 punch (double quote)

The FSn lamps indicate the binary code for the currently-selected format band.

The FORMAT SELECT pull-down list is an artifact of the emulator and did not exist on the Cardatron, although its effect could be produced through special plugboard wiring on the card machine. It overrides the characters in the format column and specifies directly the format band to be used for reading cards. When set to "By Col" (the default), the format band number will be determined from the character in the card column specified by the FORMAT COL control. Any other setting will specify the number of the format band to be used, regardless of what is on the card being read.

This control is provided in the emulator as a convenience for reading text file "decks" that may not have a column set aside to select a format band.

The FORMAT COL pull-down list specifies the card column from which the format band selection (and possibly, format lockout signal) will be taken. Since columns 1 and 80 were common choices for format columns, 80 appears first in the list.

The CLEAR button clears the Input Unit and resets it to a default status. It does not, however, empty the input hopper.

The file-picker control (with a button typically labeled Browse... or Choose Files) is used to select one or more text files from your local file system that will be loaded into the "input hopper" of the reader. You can select multiple files, one at a time, to stack them in the input hopper. In most browsers, you can also select multiple files at once, but the order in which the files will appear in the input hopper may be indeterminate. The control will display the name of the last single file loaded.

The INPUT HOPPER progress bar below the file-picker control shows the relative amount of data left in the input hopper of the reader. The bar advances to its far right position each time a file is loaded into the reader. As cards are read, the bar diminishes to its left in proportion to the amount of data that has been read.

When the reader is in a not-ready condition (the STOP lamp is lit), clicking anywhere in the progress bar will display a dialog box asking if you want to empty the input hopper. If you reply in the affirmative, the entire hopper will be cleared, regardless of the number of decks (text files) remaining in it.

The area below the progress bar displays the last two cards that have been read, with the last card on the bottom.

Cardatron Output Unit for Line Printer

Output Units are used for both card punches and line printers. The user interface differs slightly between the two. Each printer device has a window that combines the controls for the Output Unit and the printer:

The START and STOP buttons control the ready status of the printer, similar to that for the card reader. The printer can be stopped and started while it is in operation, but it will not print unless the START lamp is lit. The lamp is lit and the device is made ready automatically when the emulator is powered up.

The END OF SUPPLY button lights and the printer goes not-ready when it is "out of paper." At present, the paper capacity is 150,000 lines -- about equivalent to a box of the pin-feed paper that was used with printers of the time. The output of the printer is held in memory so that it can be copied or saved later. The capacity limit prevents memory from being flooded endlessly with line images. When the limit is reached, the printer stops and this button lights. Clicking the button will allow one additional line to be printed each time it is clicked, but continuous operation of the printer will not resume until the output area is cleared by one of the two methods discussed below.

The FEED SUPPLY button performs two functions. The first is that clicking the button while the printer is in a not-ready status will simulate a form feed. The second is that clicking the button three times in succession while the printer is in a not-ready status will display a dialog box asking if you want to clear the output area. Make sure you have copied or saved any data from the output area you wish to keep before responding in the affirmative. This is one way to clear the output area and reset the end-of-supply condition discussed above.

The CLEAR button clears the Output Unit and resets it to a default status. It does not, however, clear the output area.

The SM (Start Machine) lamp lights while the printer is in the process of transferring the numeric and zone column data from the buffer drum and printing a line. The lamp goes out after the line is printed and the unit is ready for the Processor to send another line of data.

The FSn lamps indicate the binary code for the currently-selected format.

The GREENBAR checkbox controls whether the output area is formatted with greenbar shading, similar to that traditionally pre-printed on the pin-feed paper used with line printers. Uncheck this box if you plan to copy the printed output to another program or save it to a file, as for some browsers (particularly Firefox), the greenbar formatting causes additional blank lines to be included in the data that is copied or saved. You can check or uncheck this box at any time, even while the printer is operating.

The ALGOL GLYPHS checkbox for the Output Unit controls which set of ASCII characters the emulator uses when outputting the internal 205 codes corresponding to the four characters discussed below. If the box is unchecked, the commercial character set is used; if the box is checked, the FORTRAN (scientific) set is used. This setting also can be changed at any time, even while the printer is operating.

The IBM 407 print wheels had 48 characters plus the space. IBM offered print wheels with different character sets, which were used for different applications. The two that were most commonly used with the Cardatron were the standard commercial set (wheel configuration A) and the FORTRAN set (wheel configuration F). Wheel configuration A had the following characters:

0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ $#%.,-*/@&¤

The "¤" glyph is termed the "lozenge". There are 47 glyphs shown above. A space, as with most impact printers, was generated by printing nothing in a column, so what was on the 48th print wheel position? That was another asterisk used by the 407 to replace leading zeroes in an amount for check protection (e.g., "$******123.45").

Wheel configuration F substituted the following characters for use with FORTRAN and other "scientific" languages (such as Algol):

• & : +
• # : =
• % : (
• ¤ : )

See the IBM FORTRAN II General Information Manual, Appendix B, for more information on these character sets.

Below the checkboxes is the SUPPLY REMAINING progress bar, which shows the relative output capacity remaining from the 150,000-line limit. The bar will diminish to the left as lines are printed.
The output area occupies the remainder of the window, showing the data as it is being printed. Lines scroll off the top of this area, but are retained in the browser's memory. When the printer is not operating, you can scroll back to view earlier lines and copy them for pasting into another program. The output area is an HTML frame, and many browsers will allow you to save the text directly from it to a file on your local workstation.

Another option for capturing the text that has been printed is to double-click anywhere in the output area. As with the output areas for the Flexowriter and paper-tape punch, this will do two things:

1. A new, temporary window will be opened and the entire text of the output area will be copied into this new window. If the GREENBAR box is checked, this text will not show the green shading, but will also not have any extra blank lines.
2. The output area will be cleared. This is the second way to reset the end-of-supply condition discussed above.

Double-clicking the output area can be done at any time, even while the printer is operating. You can copy, save, or print the text in the temporary window as you wish. When you are finished, simply close the temporary window.

Cardatron Output Unit for Punched Cards

Like printer devices, each card punch device has a window that combines the controls for the Output Unit and the punch:

The layout and operation of this window is identical to that for printer devices, except that it does not contain the GREENBAR checkbox and green shading is never applied to the output area. The capacity limit of the output area for a card punch is 150,000 cards.

Loading Object Decks

One of the more common uses of a card reader on the 205 was loading program object decks into memory so the program could be executed. This section describes how to do that using the retro-205 emulator.

Standard practice was to create object decks so that they could be loaded using the hard-wired format band number 6, since this did not require any of the programmable format bands to be loaded first. Therefore, there needs to be a "6" in some column of each card, and the most likely choice is column 1.

A common practice, though, was to punch 6s in columns 1-3. Format band 6 read seven full, 11-digit words (backwards, of course) from columns 4-80, plus only the low-order three digits of a word from columns 1-3. That partial word was of very limited use when loading an object deck, so filling those three columns with 6s allows the deck to be loaded with the Cardatron Input Unit set to select the format from any of those columns.

A well-designed object deck was also self-locating in memory. The first word read from the first card (i.e., the one in columns 72-80) typically had a sign with a value in the 4-7 range, indicating an instruction to be executed rather than a word to be read into memory. The address in that instruction would specify where in memory the program should start. Once again, see the three-card memory-clear program cited in the first part of this post for a good example of how this was done:

https://drive.google.com/open?id=1VHIFHZ8osHTARGBhJxTDN3A1UAmew0lf17Dk-FhEz-8&authuser=0

To load an object deck perform the following steps in the order listed:

1. First, make sure the reader is not ready and that its "input hopper" is empty.
2. Set the FORMAT COL control on the reader to the column from which format 6 will be sensed -- typically column 1. Alternatively, you can set the FORMAT SELECT control to 6, but this is not usually the best method to use.
3. Use the file picker control on the reader to select from your local system the text file containing the object deck.
4. Click the START button on the reader. The reader should feed the first card image and the FSn lamps should indicate format number 6.

The reader is now ready, but the initial CDR (44) instruction to command the reader must be entered into the Processor manually. This could not be done easily on the Supervisory Panel, as the Cardatron unit number is sensed from the third digit in the instruction word, and that digit cannot be entered in the C register. Therefore, you need to go to the Control Console and do the following:

1. Press the CLEAR button to clear the Processor.
2. Set the INPUT knob on the right side of the Console panel to KEYBOARD.
3. Click the CONT button. This will attempt the execute the instruction in the C register. Since that register was just cleared, the instruction will be 0 0000 00 0000, i.e., a PTR that will attempt to read from the currently-selected Console device to address 0000. Since that is the keyboard, the KEYBOARD annunciator will light.
4. On your workstation's keyboard, enter: 6 0010 44 0000 and press Enter. This will read one card from Input Unit 1 to address 0000. If loading from a different unit, change the 1 to the appropriate unit number.
5. The load deck should relocate that 0000 address and include additional instruction words to read the remainder of the cards automatically.

The 0.04a version of the emulator implements a simpler way to bootstrap the deck once it has been loaded into the reader. Thanks to Tom Sawyer for pointing out this method to me.
Load the deck into the reader using the first four steps above. Instead of the five steps immediately above, however, do the following:

1. Click GENERAL CLEAR on the Cardatron Control Unit.
2. Click INPUT SETUP on the Cardatron Control Unit. This will preset the Processor for a CDR (44) instruction for Input Unit 1 and address 0000.
3. Click START on the Supervisory Panel or CONT on the Control Console to start the load.

Depending on how the load deck is constructed, it may be possible to place a data deck for the program in the reader after the load deck so that the data will be available immediately to the program. The two conditions that may permit this are:

• Format of the data cards must be sensed from the same column as the Input Unit used to load the program.
• If the program must load one or more input format bands (typically the case), those bands must be loaded before the card reader is able to read the first data card. One way this can be done is to have the last card of the load deck put the reader in reload-lockout to prevent the first card in the data deck from being read automatically by the Input Unit. The initialization code in the program could then load the format band(s) in the Input Unit, maintaining reload-lockout until the CDRF (48) instruction for the last band to be loaded. The last (or only) CDRF releases reload-lockout, allowing the first card to be read asynchronously by the Input Unit with the appropriate format band now correctly loaded.

If at either of these conditions could not be met, then the load deck should be loaded and read separately. Once the reader is empty and the program has loaded its input format band(s), the data deck can be loaded into the reader.

In Other News...

Tom Sawyer and I have been having some problems with the HTML5 Application Cache (App Cache) feature in Firefox, so in release 0.04a I have disabled the emulator's use of it. This should not affect your ability to use the emulator when you can actively connect to the hosting site, but it will prevent you from using it when a connection to the hosting site is not available. I hope to have that capability reinstated in the next release.

Last week Google announced that it is terminating its free Google Code project hosting service. Projects will become read-only in August 2015 and the service will be shut down completely in January 2016. The retro-205 emulator project, of course, uses Google Code, so now we need to find a new home for it.

I am currently evaluating other project hosting services and hope to make a decision in the coming week. I also need to move the retro-b5500 emulator project, and intend for both projects to end up on the same service. Once the 205 project is moved to its new home, I'll make an announcement on this blog. The project site on Google Code will also have a forwarding reference to the new site.

Since completing the implementation of the Cardatron and punched-card interfaces described above, I have been working on resurrection of Donald Knuth's EASY and MEASY assemblers. These are the assemblers used to develop his Algol-58 compiler for the 205. That effort is progressing well, and I hope to have a report on it in the next few weeks.

The next big development task for emulator is implementation of the 205's magnetic tape subsystem. This is a necessary capability for both the MEASY assembler and the Algol-58 compiler. This is also a large task, and it may be a couple of months before it is available.

The Mighty CARDATRON

The 1950s through the 1970s were the age of punched-card interfaces for computer systems. Their use started to fall off in the 1980s, and by the early 1990s punched cards were more or less extinct. During their time, though, at least in the United States, punched cards and their related equipment were the primary (and sometimes the only) interface between people and the computer.

This is Paul Kimpel again, with another update on the development of the retro-205 emulator for the ElectroData/Burroughs Datatron 205. The past two months have largely been devoted to implementing a punched-card and line-printer interface for the emulator. This is a large subject. A combined introduction to the punch-card facilities of the Datatron and a description of their implementation in the retro-205 emulator is too long for one post, so I have split it into two parts.

This first part briefly discusses the development of I/O interfaces for the Datatron, introduces the punched-card equipment it used, and describes how punched-card I/O was handled. The second part, to be published within the next couple of days, will describe how punched-card support has been implemented in the retro-205 emulator.

Background

The earliest models of the Datatron computer system, the Consolidated Electrodynamics 201 through the ElectroData 203, supported so-called "Console I/O" -- input from punched paper tape and output to paper tape or the Flexowriter typewriter. It was termed Console I/O because the data went through the desk-sized Control Console, which contained relay-based circuits to route and synchronize the signals between the Processor and peripheral units. It was slow, and the preparation and editing of paper tapes was cumbersome.

The first punched-card interface for the Datatron was a device known as the Punched Card Converter. This was a very basic device, handling only numeric data from and to cards. It stood between the Datatron Processor and up to two IBM punched card machines, one for input and one for output:

• For input, the IBM Type 514, 523, or 528 punches and reproducers
• For punched-card output, also the IBM Type 514, 523, and 528
• For printed output, the IBM Type 402 tabulator or 419 numerical accounting machine

The Punched Card Converter offered no buffering of the data, so the Processor was stalled while the IBM machine was in operation, and throughput suffered accordingly. It also had little formatting or data conversion capability. There were knobs to control the number of words per card read on input or punched/printed on output, but that was it. A more capable interface to IBM machines was needed.

ElectroData eventually produced that more capable interface, calling it the CARDATRON, apparently in consonance with the DATATRON name of its host system. ElectroData seemed to prefer these names in all capitals, but in the rest of this post I'll capitalize just their first letters.

Cardatron Architecture

The Cardatron first appeared ca. 1956, about the time that Burroughs acquired ElectroData. As mentioned above, system models through the 203 used Console I/O and, later on, the Punched Card Converter. A 204 was a 203 with the necessary changes to support magnetic tape. A 205 was a 204 with additional changes to support the Cardatron. The Cardatron worked well enough that it was carried forward essentially unchanged to the 205's successor, the Burroughs 220.

Like the Punched Card Converter, the Cardatron stood between the Processor and a number of IBM punched-card machines. Unlike the earlier interface, it could connect a maximum of seven card machines in any combination of input and output devices. The machines supported were:

• For input, the IBM Type 087 and 089 collators, or the 523 summary punch
• For punched-card output, the IBM Type 523 (although the same machine could not be used for both input and output)
• For printed output, the IBM Type 407 tabulator

The Cardatron had two main functions:

1. Buffering. The 205 was not that fast, but the IBM machines were considerably slower. The 087 and 089 could read at 240 cards/minute (twice that if merging from both input hoppers), the 523 could read or punch at 100 cards/minute, and the 407 could print at 150 lines/minute. Buffering allowed the 205 Processor to continue executing while the Cardatron drove the IBM machine asynchronously. Only one card image or print line per machine could be buffered at a time.
2. Formatting. The 205 had an 11-digit word. That word could hold a signed 10-digit number or five alphanumeric characters at two digits per character. The 205 had little in the way of character-level manipulation, just digit-wise shift/rotate and an Extract instruction that could do digit-wise masking operations somewhat like logical AND. The Cardatron provided the mechanism to take variably-sized numeric and alphanumeric fields on the card and map them to full words in the 205 memory, discarding unwanted zones or whole columns from the card, supplying zero digits to left- or right-justify fields in memory, and mapping a zone punch to the sign digit in memory. To accomplish this, it used a set of programmable format bands that were loaded into the Cardatron from the Processor.

A Cardatron system consisted of a Control Unit and any combination of up to seven Input or Output Units. Each unit occupied a full-size cabinet. Each Input or Output Unit controlled one IBM card machine.

The Control Unit provided the data path to the Processor and a switching network to select individual Input and Output Units. The unit was selected by the value of the third digit in an I/O instruction word. See the section "Cardatron Instructions" below for details on the instruction word formats and the additional digits in those words used to control Cardatron I/O.

The Processor could transfer data to or from only one unit at a time, but once the relatively fast data transfer was completed between the Processor and Cardatron, the Input or Output Unit drove the IBM machine asynchronously. Thus, it was possible for the Cardatron to have multiple simultaneous operations in progress with the card machines at a time.

Each Input or Output Unit contained a small drum that rotated at 21,600 RPM. The drum had six read/write tracks, or bands that could hold 316 digits each (slightly less than 29 11-digit words). Additional read-only tracks provided timing signals to the unit. The first of the six bands was used to buffer data going to or from the card machine. The remaining bands, numbered 1 through 5, were used to store strings of formatting codes.

A card image or print line was transferred between the card machine and the Processor under control of one of the format bands. On output, the band was selected by the second numeric digit in the CDW (54) instruction word. On input, however, the format band was selected by a punch on the card being read. This approach was somewhat controversial, as it required the customer to plan their card layout around the need to reserve one column for format control. The column containing the format punch was designated by a manual setting in the Input Unit. Columns 1, 2, and 80 were apparently the most common choices.

An Input Unit had two further capabilities:

• Fixed Format Bands. There were two additional pseudo bands. These bands were not stored on the drum, but were hard-wired in the Cardatron Input Unit's logic. Format 6 was an all-numeric format that could read up to seven full 11-digit words plus a partial three-digit word from a card. It was typically used for loading object programs or raw data into the system. Format 7 was "reject format." The data from the card was not passed to the Processor, and the Input Unit automatically proceeded to read the next card.
• Reload Lockout. If the second digit (called the "k-digit") of the CDR (44) instruction was odd, the Input Unit was placed in a "reload lockout" condition. The data from the card was transferred to the Processor, but the data remained on the Input Unit's buffer drum and the next card was not fed from the card machine. This feature was generally used in one of two ways:
• To reread the same data into a different starting address on the memory drum.
• To hold the data on the buffer drum while the format band was reloaded, so that the data could be read again under a different format.

Reload lockout was released once a CDR (44) or CDRF (48) was executed with an even value in the k-digit of the instruction word.

Additional control over data formatting could be accomplished through wiring of the plugboards in the IBM machines. ElectroData and Burroughs had standard plugboard configurations that transferred all columns of a card or line of print as is, but some sites developed their own plugboard wiring to satisfy special requirements.

Cardatron Formatting Facilities

The first concept behind Cardatron formatting and data conversion is that the I/O took place in two phases:

• For input, the first phase asynchronously read a card and transferred its data to the data band on the buffer drum. The second phase transferred the data from the buffer drum to the Processor when the Processor requested it by executing a CDR (44) instruction. Note that this meant the Input Unit generally read the card asynchronously before the Processor asked for its data.
• For output, the first phase transferred the data from the Processor to the data band on the buffer drum under control of a CDW (54) instruction and released the Processor for further execution. The second phase asynchronously transferred the data from the buffer drum to the card machine.

The data transfer in both phases was controlled by the digits of the selected format band. Transfer between the Input or Output Unit and the Processor was limited by the speed of rotation of the unit's buffer drum, or one word per 2.78 ms. That rate could be achieved when transferring data to or from one of the high-speed memory loops, which had an average access time of 0.84 ms, but otherwise the rate was controlled by the average access time to main memory, 8.4 ms. A single I/O typically transferred 10-20 words, so even transfers to and from main memory took less time than the fastest card machine cycles.

The second concept behind Cardatron formatting is that each column on a card or line of print was divided into two parts, a numeric digit and a zone digit. The Cardatron allowed you to copy digits, delete digits, and insert zero digits in the path between the card machine and the Processor.

A standard punched card consisted of 80 columns and 12 rows. From the top of the card, these are known as the 12, 11, and 0-9 rows. The numeric portion of a column is considered to be the bottom nine rows, 1-9. The zone portion of a column is considered to be the top three rows, 12, 11, and 0. For numeric data, a negative number was generally indicated by an 11 punch over the leading digit of the field, and a non-negative number was generally indicated by a 12-punch or no zone punch at all.

As an Input Unit was reading a card, it split each column into the numeric and zone halves, and then encoded each half so that one column occupied two (not necessarily contiguous) digits on the buffer drum. An Output Unit took one or two digits from the buffer drum (as controlled by the format band) to produce one column for punching or printing on the card machine. The actual process was a little more complex than that, but the central idea is that the numeric and zone portions of a column on the card machine were stored and manipulated as separate digits on the buffer drum. The conversion process and encoding of digits on the buffer drum are detailed in United States Patents 3,000,556 (September 16, 1961, L.L. Bewley et al) and 3,072,328, (January 8, 1963, L.L. Bewley et al).

The third concept behind Cardatron formatting is that each data digit on the buffer drum was paired with the corresponding format digit on the selected format band. Thus the handling of data digit 1 was controlled by format digit 1, data digit 2 by format digit 2, and so forth. Not all data digits were necessarily associated with columns on the card -- digits could be deleted and zero digits could be inserted into the data stream as determined by the format band digits.

Digits on the data band could have the values 0-9, 11, and 12. Those last two values where used to encode multiple punches in the numeric part of a column for certain special characters, e.g., 11-3-8 for "$". Digits on the format bands were restricted to values 0 to 3. The formatting digits were interpreted somewhat differently for Input and Output Units. For an Input Unit, format digits mapped the numeric and zone digits coming from the card to digits in the destination computer word as follows:

• 0 caused a 0 digit to be inserted in the corresponding data digit position on the buffer drum. The 0 digit was inserted on the drum before the next digit coming from the card. In effect, this code caused a padding zero digit to be inserted into the computer word.
• 1 caused the numeric or zone digit coming from the card to be recorded in the corresponding data digit on the buffer drum. The digit was not simply copied, but encoded in a special way as described in Patent 3,000,556. In effect, this copied the digit to the computer word, but a transformation took place for alphanumeric data to account for the numeric/zone representation of characters on a card vs. the two-digit alphanumeric coding used internally by the 205. Generally, though, two 1 digits in succession transferred one alphanumeric column from the card to the computer word.
• 2 caused the numeric or zone digit coming from the card to be dropped and replaced by a 0 digit in the corresponding data digit on the buffer drum. This code is effectively a combination of format digits 1 and 3. In effect, this code replaced the digit coming from the card with a zero in the computer word.
• 3 caused the numeric or zone digit coming from the card to be dropped. In effect, this code prevented storing the digit coming from the card in the computer word.

For an Output Unit, data digits coming from a computer word are mapped to numeric and zone digits for a card or print column, and the format digits operated as follows:

• 0 caused a 0 digit to be inserted in the corresponding data digit position on the buffer drum. This digit was inserted before the next digit coming from the computer word. In effect, this code caused the corresponding numeric or zone portion of a column to have no punch. Two 0 codes in succession generally resulted a blank column on output.
• 1 caused the digit from the computer word to be recorded in the corresponding data digit on the buffer drum. As with input, a special transformation occurred to handle the differences between the internal 205 alphanumeric coding and card numeric/zone coding, as described in Patent 3,072,328. In effect, this code copied the digit from the word to the corresponding numeric or zone position in the next card column. Generally, two 1 digits in succession transferred one alphanumeric character from the computer word to the card or print line.
• 2 caused one digit from the computer word to be stored in the corresponding data digit on the buffer drum such that it would be punched/printed as one numeric column on the output device. In effect, this code caused the digit from the computer word to generate both a numeric and zone code for the output column. The behavior of this code, as opposed to a 3-1 combination, was designed to supply a 0 punch for a 0 digit, which would not normally happen for format digit 1, since strictly speaking 0 is a zone punch, not a numeric punch.
• 3 caused the next digit from the computer word to be dropped. This was often used to strip leading numeric zeroes from a computer word so that either a shorter field could be formatted on the output device, or the zone punch for the sign digit could be properly positioned, or both.

The next characteristic of Cardatron formatting, and a highly unusual one, is that data and format digits on the buffer drum mapped to columns on the IBM machine backwards. That is, data and format digit 1 corresponded to the numeric portion of column 80 on a punched card, or the last print position on the printer. The reason for this may be that during input, digits coming from the Cardatron entered the sign position of the Processor's D register and were shifted right; on output, digits going to the Cardatron exited the low end of the A register and were also shifted right. Starting at the end of the card made it somewhat easier to deal with leading zeroes in words and to position the sign digit properly.

Another characteristic of Cardatron formatting was that, since data in the Input or Output Unit was processed in reverse order, but words were fetched or stored on the memory drum in ascending order, fields on the card were mapped in reverse order to words in memory -- the last field on the IBM machine was at the first address in memory. This may be counter-intuitive, but since both input and output worked the same way, words came into the system and went out in the same relative order. The reverse ordering of fields also meshed well with the indexing and decrement-and-branch behavior of the B register.

The way these format digits interacted with card or print columns can be difficult to envision from a brief description such as the foregoing. A small example might help illuminate how it worked. Since Cardatron formatting worked from right to left on the card, we'll just consider a couple of fields at the end of a card:

• Columns 72-76 contain a five-digit numeric field with the sign indicated by a zone punch over column 72.
• Column 77 is not used.
• Columns 78-80 are a three-character alphanumeric field.

Thus, the last portion of the card could be visualized as the following string, where S is a signed numeric digit, N is an unsigned numeric digit, X is an ignored column, and A is an alphanumeric column:

...SNNNNXAAA

We want the alphanumeric field to end up left justified over spaces in one word of main memory and the numeric field to be right-justified over zeroes in the next word. Since the data is read backwards, if the CDR (44) instruction specifies address 4000, the alphanumeric field will be stored in 4000 and the numeric field will be in 4001.

The following digits in the format band will do this transformation between the card columns and computer words, again reading from right to left. The vertical-bar characters (not part of the format band coding) show where word boundaries in memory will coincide with the format digits:

...|100000131313131|3301111110000|

• The four 0 digits on the end simply shift four zeroes into the D register starting from the sign (left-most) digit and moving to the right. The internal 205 code for a space is 00, so this inserts the two spaces necessary to left-justify the three-character alphanumeric field in its computer word. 
• Next, the six 1 digits alternately copy the numeric and zone digits from the last three columns on the card and shift those into the D register as well, pushing the spaces to the right. The codes for the numeric and zone digits undergo transformations going from the card to the Cardatron buffer drum and from the buffer drum to the D register in order to translate the characters to internal 205 character codes. 
• Then the 0 in the format band shifts in a 0 for the sign digit, completing the first word, which will be stored at location 4000 in the 205's memory. 
• The 33 digit pair deletes the numeric and zone codes for the unused column 77 on the card. 
• Next, the four pairs of 31 format digits alternately copy the numeric portions of card columns 73-76 and discard the zone portions. This shifts the low-order four digits of the numeric field into the D register. 
• The next 1 digit copies the numeric portion of card column 72 to the D register. 
• The five 0 digits shift as many zeroes into the D register. The purpose of these 0 digits is to right-justify the number in the word. We now have ten digits shifted into the D register. 
• The final 1 digit shifts the zone from the card column 72 into the sign digit, completing the word that will be stored at location 4001.

Unfortunately a good publicly-accessible reference for the 205 Cardatron is not presently available. A quite usable description, however, can be found in Section 6 of the Burroughs 220 Operational Characteristics manual, available at:

http://bitsavers.org/pdf/burroughs/electrodata/220/5020A_B220_OperCharac_Aug60.pdf.

Format band coding had to be prepared by the programmer and loaded into the 205's drum memory. All 11 digits of a word were used to store the format band digits, so the 316 digits of a band required 29 words in memory. Sign-digits in the data other than 0 or 1 had special meaning during input from an I/O device, however, and format band data typically had 2s and 3s in the sign digits of their words, so special handling was required to load programs that contained format bands.

During input from Console and Cardatron devices, the sign digit of the words being read were examined before being stored in memory and acted upon as follows:

• Digits 0, 1, 8, 9 -- word is stored normally with the sign digit as is.
• Digit 2 -- the current contents of the B register are added to the word and the sign digit is replaced by 0 before the word is stored in memory. B-register modification was typically used to adjust relocatable addresses in instruction words.
• Digit 3 -- same as Digit 2, except the sign digit is replaced by 1 before the word is stored in memory.
• Digit 4 -- the word is not stored in memory, but is transferred to the C register and then executed as an instruction. For Cardatron input, the op code in the word must be 44 for CDR (alas, the documentation does not say what happens if the op code was anything else). The input operation continues with the next word from the device. Words with this sign digit were typically used to change the address at which the following words would be stored.
• Digit 5 -- same as Digit 4, except the B register is added to the word before it is transferred to the C register and executed.
• Digit 6 -- the word is not stored in memory, but is transferred to the C register and then executed as an instruction. Unlike the action for Digits 4 and 5, a word with this sign digit caused data transfer from the device to stop and the I/O operation to be terminated. The word could contain any op code, but most frequently it was an unconditional branch (20) or another input command.
• Digit 7 -- same as Digit 6, except the B register is added to the word before it is transferred to the C register and executed.

This modifying behavior of sign digits in a data input stream was an interesting idea, and permitted control over an I/O operation somewhat like the channel programs for the IBM 709 and later systems. The differences with the 205 approach were that the I/O commands were embedded in the data itself instead of being stored separately, and that the words could be modified by the contents of the B register before being stored in memory.

Note that words with sign digits having values of 2 or 3 normally caused the input word to be modified by the B register and the sign digit to be changed to a 0 or 1. This is something you definitely do not want to have happen to a format band as it is being loaded into memory, so some overrides to the default behavior were necessary.

For input from Console devices, there was a switch on the Sub-Maintenance panel that could be set to suppress the interpretation of signs in the data stream. The retro-205 emulator does not presently implement this switch.

For input from Cardatron devices, the second digit (k-digit) of the CDR (44) instruction word could be used to control the interpretation of sign digits in the words being read. If the high-order bit in the word was set, then B-register modification of input words with signs 2, 3, 5, and 7 was suppressed, and signs of 2 or 3 were stored as is. Note that the low-order bit of the k-digit still controlled reload lockout.

For an example of how sign digits in words coming from the Cardatron could control and redirect data during an I/O, see this analysis of a small, three-card program that clears the 205 memory drum:

https://drive.google.com/open?id=1VHIFHZ8osHTARGBhJxTDN3A1UAmew0lf17Dk-FhEz-8&authuser=0

Note that this program uses the hard-wired format band 6, which acted as if it consisted (right-to-left) of 80 pairs of 31 digits, preceded by 154 0 digits to fill out the format band. This band will transfer 14 words of data to the 205 memory, unless the transfer is stopped sooner by a sign-6 or -7 instruction word (which would normally be the case).

Cardatron Instructions

There were six instructions in the 205 Processor for commanding the Cardatron. In the following discussion, "s" is the sign digit, "r" is the relay-designate digit, "k" represents the k-digit discussed above, "u" is the Cardatron unit number (1-7), "p" is the standard breakpoint control digit, "x" is a digit that is ignored, and "aaaa" is the effective address of the instruction, which may be modified by the B register if the sign digit in the instruction word is odd.

CDR: Card Read (s xkup 44 aaaa)

Read words from Input Unit "u" to memory starting at address "aaaa". The k-digit may indicate reload lockout or sign-handling override. The number of words read is determined by the format band selected by the card, but that number may be reduced if the incoming data contains a word with a sign of 6 or 7.

CDRI: Card Read Interrogate (s xxup 45 aaaa)

Interrogate the status of Input Unit "u". If a card has been read and the unit's buffer drum is loaded and ready to transfer data to the Processor, branch to "aaaa" after clearing the R register and storing the current control counter in the high-order four digits of R. If the buffer is not loaded and ready to transfer data, continue with the next instruction in sequence.

CDRF: Card Read Format (s xkup 48 aaaa)

Load a format band on Input Unit "u" from 29 words in memory starting at "aaaa". The band number and reload lockout control are encoded in the k-digit. Odd values of k set reload lockout and even values release it. k-digit values 0-1 load band 1, 2-3 load band 2, 4-5 load band 3, 6-7 load band 4 and 8-9 load band 5. Use of the high-order bit of the k-digit to control sign digit transfer and B-register modification is not relevant for this instruction. 

CDW: Card Write (s rkup 54 aaaa)

Write words to Output Unit "u" from memory starting at address "aaaa". The k-digit specifies the format band as for CDRF (48) above. The r-digit sets a group of four relays that were generally used to convey carriage-control information to a line printer. The number of words written is determined by the format band. The low-order bit of the k-digit is not relevant for this instruction.

CDWI: Card Write Interrogate (s xxup 55 aaaa)

Interrogate the status of Output Unit "u". If the unit's buffer drum is ready to receive data from the Processor, branch to "aaaa" after clearing the R register and storing the current control counter in the high-order four digits of R. If the buffer is loaded and the unit is still busy writing to the card machine, continue with the next instruction in sequence.

CDWF: Card Write Format (s xkup 58 aaaa)

Load a format band on Output Unit "u" from 29 words in memory starting at "aaaa". The k-digit specifies the band number as for CDRF (48) above. The low-order bit of the k-digit is not relevant for this instruction.

This ends the first part of the discussion on punched cards and the Cardatron. Stay tuned for the second part on how the Cardatron has been implemented in the retro-205 emulator.