UsingTheDataFile - pkimpel/retro-205 GitHub Wiki
Using the 205 DataFile Magnetic Tape Unit
The Datatron 205 supported an unusual tape device, the Model 560 DataFile.
The DataFile shared much of the media and recording technology of the DataReader. It connected to the 205 processor and memory using the same Model 543 Tape Control Unit. A 205 system could support one Control Unit, which in turn could support any combination of up to 10 DataReaders and DataFiles.
For an overview of the DataReader and background on the way it recorded data, see the DataReader wiki page. For additional background on the DataFile, see Emulator Version 1.00 and the DataFile on Tom Sawyer's 205 and 220 blog.
Overview of the DataFile
The DataFile was introduced during the pre-disk era of computing, when much data processing was done using sequential file techniques. The asynchronous search, dual lane, and block overwrite features gave the 205 some interesting advantages in applications that had to maintain large data sets on magnetic tape, but tape operations were still very slow. Average time for the DataReader to locate a random block on a full, 2500-foot reel of tape was almost four minutes.
The DataFile was designed to reduce the access time to data stored on magnetic tape. It did this by using shorter tapes, lots of them, and a drive mechanism that could quickly select among the tapes.
The DataFile was housed in a long, waist-high cabinet with a hinged cover, sometimes termed "the coffin." This image from Tom Sawyer's web site (and originally from the Charles Babbage Institute) shows the unit with its cover open:
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.
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 long latency. 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 the performance of disks that would begin appearing in the late 1950s.
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
Since the tapes in the DataFile 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. Instead, the emulator stores the tape data internally using a mechanism supported by most modern web browsers, the IndexedDB API.
IndexedDB does not implement 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. 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. Internally, 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
The default configuration for the retro-205 emulator does not include any DataFile units. You must add DataFiles to the configuration if you wish to use them. See the Configuring the Emulator page for details on how to do this.
As with all peripheral devices configured in the emulator, each DataFile unit in the system configuration will display a separate window on your screen, similar to this:
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 physical DataFile had a set of individual write lock-out tabs for each tape, but this has not 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 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.
There is no built-in way to load data into a DataFile -- you must write a program to do that.
The following is a link to 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:
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: