Emulator Version 1.00 and the DataFile

Development of the retro-205 emulator for the ElectroData/Burroughs Datatron 205 computer system is now functionally complete. That is not to say that it is finished. As a friend used to say, programs are never finished -- they merely become obsolete.

This is Paul Kimpel with another guest post on Tom's 205 and 220 blog. It is time to drag the emulator out of its 0.xx development era, so I am pleased to announce that the version just released has been labeled 1.00. Rather than have one monster post that describes all of the changes in this release, this post will discuss the implementation of the final piece of the 205 hardware, a magnetic tape device known as the DataFile. It will also describe a few bugs and enhancements that have been addressed. A second post will discuss the other major improvement in this release -- emulator timing.

The DataFile

The Datatron 205 supported a relatively typical, reel-to-reel magnetic tape drive, known as the Model 544 DataReader. To understand the DataFile, let us start with a description of the DataReader.

Overview of the DataReader

The DataReader was connected to the 205 processor through the Model 543 Tape Control Unit. It used 2500-foot reels of 3/4-inch magnetic tape. The tape was recorded in two parallel lanes of six tracks each. Four tracks were used to record BCD numeric data, the fifth track was even parity, and the sixth track signaled the start of a block. Blocks were a fixed 20 words each, matching the size of the high-speed loops on the 205's memory drum. The tape moved at 60 inches/second, with data recorded at 100 bits/inch. Total length of a block, including inter-block gap and a block header, was 2.78 inches. Total capacity of a reel of tape was 10,000 blocks per lane.

Blocks in a lane were numbered from 0 through 9999. Individual blocks could be read and written, and since they were of fixed length, and even reliably overwritten -- something that could not be done with the IBM recording format that later became the de facto standard. The 205 processor had a tape search instruction that specified the lane and block number sought. Once initiated, the Tape Control Unit conducted the search either forwards or backwards, asynchronously and independently of the processor.

This was in the pre-disk era of computing, and much data processing was done using sequential file techniques. The asynchronous search, dual lane, and overwrite features gave the 205 some interesting advantages in applications that had to maintain large data sets on magnetic tape. A number of clever indexing and lane-switching techniques were developed to take advantage of them, some of which are described in Bulletin 3024, The Magnetic Tape System Handbook.

Even with these advantages, tape operations were still very slow. Average time for the DataReader to locate a random block on a full reel of tape was almost four minutes. Disk technology was on the horizon, but very expensive -- IBM was to introduce its 305 RAMAC system in September 1956, shortly after Burroughs acquired ElectroData. The RAMAC disk boasted an access time of 600ms, but a total capacity of only five million digits, hardly more than the 4.4 million digits on a single reel of 205 tape.

The DataFile Compromise

Into this situation, ca. 1954, stepped Duncan MacDonald, one of the lead designers at ElectroData. Realizing that the search would be faster on a shorter tape, and that data capacity was proportional to the total length of tape, he came up with a mechanism that used shorter tapes, but lots of them. The result was the Model 560 DataFile, for which MacDonald was awarded U.S. Patent 2,914,752 in 1959.

The DataFile was housed in a long, waist-high cabinet with a hinged cover, leading to the enclosure being nicknamed "the coffin." This image from Tom Sawyer's web site (and originally from the Charles Babbage Institute) shows the unit with its cover open:

Model 560 DataFile Unit

Inside the enclosure were a set of horizontal rods, over which were draped 50 tapes. Underneath the rod assembly was a moving carriage with pinch rollers and two tape heads. The carriage could traverse under the tapes and stop at any one of them, latching into position and allowing the pinch rollers to engage with a rotating capstan to drive that tape forward or backward. The time to traverse and latch into position varied linearly from about 0.5 to 2.0 seconds, depending on the distance traversed. Thus the carriage could relatively quickly select any one of the 50 tapes and read or write it.

Below the rods the cabinet was partitioned into 50 parallel bins, each wide enough for a tape, with perforated walls separating the tapes. The tapes fell loosely into these bins -- they were not wound on reels or hubs. The perforated bin walls allowed air to enter and exit the bins as the carriage drove a tape back and forth, causing the tape strip to rise or fall within the bin.

The tapes, tape heads, and recording format used with the DataFile were exactly the same as the reel-to-reel DataReader, except that the individual tapes were 250 feet long instead of 2500 feet. Each tape still had two lanes, but only 1000 blocks per lane. Tape speed, recording density, block size, and the overwrite and asynchronous search features were all the same as for the DataReader.

The DataFile used the same Tape Control Unit, which could support any combination of up to ten DataReaders and DataFiles per 205 system. One DataFile could store 50×2×1000 = 100,000 blocks or 22,000,000 digits, and a fully-configured system up to 220,000,000 digits. This was mass storage, ca. 1955.

Unlike the DataReader, the individual tapes in the DataFile were not removable, except for servicing and replacement when they became worn. Thus, the DataFile acted much more like a disk unit than a tape drive, albeit a disk unit with a rather severe latency problem. Burroughs quoted the average time to access a random block within a tape as 15.3 seconds, and an average of 16.3 seconds if the carriage had to move. This was a lot better than four minutes for the DataReader, but a lot worse than 600ms for the RAMAC, once it came along. The DataFile was thus a compromise design, filling a niche in the time between tape- and disk-based eras of data processing.

As you might expect of a device with a heavy carriage that (a) moved quickly when traversing, and (b) was surrounded by flimsy tapes, the DataFile could be high-maintenance, to the point where its less-charitable nickname was "the DataFail." In addition to its mechanical complexity, the tapes were subject to wear, and if left motionless in their bins too long, could settle and crease, causing data errors. Standard operating procedure called for all tapes to be moved from end-to-end at least weekly to avoid this, a process that could be done off-line from the unit's control panel.

Programming for the DataFile was similar to that for a DataReader. The only significant differences were:

• A DataFile unit had 100 lanes instead of two.
• Individual lanes held one-tenth the number of blocks compared to the DataReader.
• The DataFile did not respond to tape rewind commands. To position a tape to its beginning, you did a tape search for block 0000 on an appropriate lane.

The tape instruction formats for the DataFile were the same as for the DataReader, with one exception in the way lanes were selected by a Magnetic Tape Search (MTS, 42) operation. The format of that instruction was:

s hhup 42 aaaa

where s is the sign digit, hh specifies the lane number, u is the tape drive unit number, p is the standard breakpoint digit, and aaaa is the address field, which for this instruction specified the block number to which the tape should be moved. If the low-order bit of the sign digit was set, normal B-register modification would occur, and the effective block number would be the sum of the contents of the B register and the address field.

When this instruction was used with a DataReader, only the low-order bit of the hh field was significant, as there were only two lanes to select between. When used with the DataFile, the full two-digit lane number (00-99) was significant.

The retro-205 DataFile Implementation

Even though the recording and instruction formats for the DataFile were the same as the DataReader, implementing the DataFile in the emulator posed some issues. The major one was persistence of the data. Since the tapes are not removable, their data cannot be stored outside the emulator in ordinary files, the way that tape image files used with the DataReader are. The emulator needed to store the tape data internally in a way that would survive across emulator sessions and workstation restarts.

The solution was to accept that the DataFile is more like a disk unit, and to apply the same approach I used to implement Head-per-Track disk units for the retro-B5500 emulator. Modern web browsers support a lightweight data base API known as IndexedDB. This is not a relational data base, but instead stores Javascript objects. The objects are stored in one or more structures termed object stores, which are similar in concept to tables in a relational data base. The objects within a store may be indexed by properties of the objects themselves, or by external values supplied by the application.

To support the DataFile, the retro-205 emulator uses a single IndexedDB data base, named "D205DataFileDB". This data base is created automatically the first time that a DataFile is added to the system configuration. Each "physical" DataFile unit, lettered A through J in the configuration, has a separate object store in this data base. That store is permanently associated with that physical device letter. If you reconfigure that device letter to be a DataReader, the store will continue to exist, but be hidden. If you later configure the device letter back to a DataFile, the data in the store will again be available. Note that the unit designation numbers (1 to 0 [for unit 10]), selected on the drive panels and used by the software to address tape units, can be changed at any time without affecting the object stores.

Within each object store for a DataFile unit, the data is stored as objects that are 20-word arrays. Each object corresponds to one block on one of the tape strips for the unit. These objects are indexed by a number computed as (lane number)×1000 + (block number), where the lane number ranges from 0-99 and the block number from 0-999 within a lane. While internally the block objects can be accessed quickly and randomly, the emulator executes the necessary delays to model the timing of the DataFile device.

Once the IndexedDB data base is created, it resides permanently on your workstation's local disk. The emulator does not provide a way to remove it, although most browsers allow you to inspect and remove these data bases through their "developer tools" interface. If you remove the data base for the DataFile, it will simply be recreated again the next time you run the emulator with a DataFile present in its configuration. Any former data for the data base will have been lost, of course.

Different browsers implement IndexedDB data bases in different ways. For example, Firefox uses SQLite as the underlying storage engine, while Google Chrome uses LevelDB, a derivative of its BigTable technology. Therefore, you will not be able to share the data base for a DataFile between browsers.

In addition, these data bases are subject to the browser's "same-origin" policy, meaning that resources associated with one web site generally cannot be accessed by resources from some other web site. The combination of scheme (http/https), host name, and port in a site's URL is used in determining same-origin access. For example, you can access the emulator's hosting site as http://www.phkimpel.us/ElectroData-205/ or as http://phkimpel.us/ElectroData-205/ -- both URLs refer to the same physical files on the same physical web server, but to your browser they are different origins, and consequently will use different IndexedDB instances.

Using the retro-205 DataFile

As with all peripheral devices configured in the emulator, each DataFile unit will display a separate window on your screen, similar to this:

retro-205 DataFile Device Window

The controls on this window are similar to those for the DataReader. The area below the controls shows a representation of the 50 tape bins. The brown bars show the relative position of the each tape, with a zero-length bar representing the tape in a rewound (block number 0000) position. Below the bins is a representation of the carriage and tape heads, which move in response to lane selection by tape search instructions. The currently-selected bin is highlighted in yellow.

When the emulator initializes, each DataFile in the configuration is opened with its tapes in random positions. The carriage is initially positioned at tape 25, lane 50.

The DESIGNATE pull-down list selects the unit number that will be recognized by magnetic tape instructions. The REMOTE/LOCAL and NOT WRITE/WRITE switches function the same as for a DataReader. The unit must be in Remote (ready) status in order to be addressed by software. Setting the NOT WRITE switch prevents writing to any of the tapes, but the tapes will still move in response to write instructions. A real DataFile had a set of individual write lock-out tabs for each tape, but this has not yet been implemented in the emulator.

The REWIND and STOP REWIND buttons are always active, regardless of the setting of the REMOTE/LOCAL switch. Clicking REWIND will initiate a rewind of all tape strips, in the manner it worked on a real DataFile. The carriage will move to the left-most tape (for lanes 0/1) and rewind it. Then it will move to the right-most tape (for lanes 98/99), rewinding each tape in reverse sequence until it again reaches the left-most tape. Clicking STOP REWIND will interrupt the process and return the carriage to the left-most tape.

A full rewind on a real DataFile would take an average of more than 20 minutes, depending on the positions of the tape strips. In implementing the rewind function in the emulator, reproducing that particular timing behavior of a real system did not seem necessary, so the emulator presently rewinds DataFile tapes at ten times the speed of a real unit -- averaging a little over two minutes to complete.

Applications for the DataFile

The DataFile is useful for storing large programs and any data that you want to persist across emulator sessions. The Shell Assembler was specifically designed to work with the DataFile, and Donald Knuth's Algol-58 compiler works well from it, too. One issue is that there is no built-in way to load data into a DataFile -- you must write a program to do that.

Here is a small card-load program that will load the Shell Assembler to lane 89 on a DataFile designated as unit 0 (i.e., 10) from lane 1 of a DataReader designated as unit 1:

https://github.com/pkimpel/retro-205/blob/master/software/Shell-Assembler/Shell-Utilities/Shell-Load-DataFile.card

The tape image used by this program can be downloaded from:

https://github.com/pkimpel/retro-205/blob/master/software/Shell-Assembler/Shell-Assembler-Load.tape

Once loaded to the DataFile, the assembler can be executed using this small card-load program:

https://github.com/pkimpel/retro-205/blob/master/software/Shell-Assembler/Shell-Assembler-Bootstrap.card

Bug Fixes and Minor Enhancements

The 205 floating-point implementation has a nice trick -- you can discard the fractional part of a number by adding the floating-point value 5800000000 (i.e., 0.0 × 10⁸) to it. Algebraically this is meaningless, but the way that floating-point addition was mechanized caused the augend value in the A register to be scaled (shifted right) during the alignment of exponents that took place before the addition. Any fractional digits in the value would shift off the low-order end of the number and be lost. The normalization (shifting left) that occurs after the addition would then put the remaining digits back in their original positions. Alas, this was not working in the emulator. The problem was that I was normalizing the addend value in the D register before scaling the A register. By reversing the order of scaling and normalization, that trick now works properly.

Tom Sawyer discovered that the tape drives were not properly transferring data when the operand address was not aligned on a mod-20 boundary. The problem had to do with the way that tape reads and writes are buffered in the 4000 and 5000 high-speed loops on the memory drum. The word at the mod-20 memory address was being mapped to the first word in the tape block, rather than the word at the operand address being first in the tape block. This has been corrected.

Tom also discovered that the way the emulator was interpreting the breakpoint digit in instruction words was not correct.

• The low-order three bits of that digit are a mask. If any of the 1-bits in that mask match the setting of the breakpoint switch on the Control Console, the processor will halt with a BKPT alarm after the execution of that instruction.
• The high-order bit in the breakpoint digit is used with the SKIP switch. If that switch is on and the high-order bit of the breakpoint digit is a 1, the processor will skip that instruction. It does so by remaining in the fetch state rather than switching to the execute state, allowing the next instruction to be fetched immediately.

The problem occurred when both the breakpoint and skip conditions were true for the same instruction. In this case, the instruction should not be executed and the processor should stop at the end of the fetch cycle for that instruction. Instead, it was doing this only if the low-order bit of the breakpoint digit was a 1, not if the breakpoint switch matched one of the 1-bits in the breakpoint mask. This has also been corrected.

One of the items in the material Prof. Knuth sent me last year was ElectroData Technical Newsletter #5, dated February 14, 1958. This document described how all 100 two-digit character codes mapped to glyphs on the Flexowriter and Cardatron output devices. Character translation in the emulator for these devices has been changed to match the information in that document.

Input translation from ASCII to internal 205 code for card devices has been altered slightly in order to improve support for Cardatron reload lockout. In the Cardatron, reload lockout could be imposed by a multi-punch combination in the column that selected the format band. A numeric punch (1-7) selected the format band as usual; an 8-punch signaled reload lockout. Trying to simulate this with ASCII character codes is a little awkward, but here is the current arrangement:

• the grave accent (`), a 1-8 punch, now maps to the digit 1;
• the colon (:), a 2-8 punch, now maps to the digit 2;
• the "#" is a 3-8 punch;
• the "@" is a 4-8 punch;
• the characters "|", "}", "~" now arbitrarily map to the digits 5, 6, 7, representing 5-8, 6-8, and 7-8 punches, respectively ;
• the double-quote ("), a 7-8 punch, now maps to the digit 7;
• the apostrophe (') now maps to the "@" but is treated as a 5-8 punch for reload lockout.

On the Flexowriter, clicking the RESET button on the Typewriter Control Unit panel will now output a new-line sequence if the carriage is not at the left margin. Previously, there was no way to reset the carriage if the computer stopped in the middle of a line.

Please stay tuned for the second post on improvements to emulator instruction timing.