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:
- System Configuration Facility
- Cardatron Leading-Zero Suppression
- Control Panel Display Enhancements
- Other Corrections and Enhancements
- 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 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 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.
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:
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:
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.
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.
