The raw binary file can be downloaded from here: http://bit.ly/1NklvGj
(Reference my original page with the MINICOM DISK TO TAPE UTILITY)
Here's how, in Bruce's words:
The tape contains a disk/tape backup/restore utility that is somewhat representative of those used with Point 4, and other 3rd-party DG lookalike systems. It is a stand-alone utility that is bootable if it exists as the first record of the first file of a mag tape or cartridge.
The usual procedure is to bootstrap the tape using the Nova APL function (or just toggling in simple 2-instruction 'fat-finger' program). Once the program is read into memory, it starts execution and displays its introductory message. At this point another tape/cartridge may be loaded onto the tape drive for backup or restore purposes.
I used our reNOVAte software (see reNOVAte manual) for doing my investigations rather than SimH due to convenience, and was able to run the program and exercise its various functions.
This particular utility is very specific regarding the type of disk drive and IRIS logical units it supports.
The utility assumes two devices exist: a tape controller using device code <022> and a disk controller using device code <027>. The tape controller may or may not perform QIC to DG-style file handling emulation since the original tape is not available to me.
The disk controller appears to use the standard DG "Zebra" controller (Model 6060/6061/6067) programming model. However, it assumes a non-standard disk geometry of 16 cylinders, 5 heads, and 32 sectors.
The tape file itself needs to be created in the SimH tape if it is to be used with the default SimH tape driver. The QIC format may exist as a single large data record of 16,384 bytes, or of multiple 512-byte records followed by a file mark. (I can not tell its original format given only the .bin file to work with.)
The utility also makes assumptions about tape read timing and CPU instruction execution speed. Horrible programming technique, but unfortunately not uncommon practice. Any such timing dependencies must be found and compensated for in the device driver or instruction emulation.
Dissecting and running the utility reveals further program assumptions:
The 40 MB disk drive has a geometry of 442 cylinders, 5 heads, 32 sectors/track (head).
The IRIS logical unit to physical disk address assignments are:
LUN CYL HD SEC
---- --- -- ---
LUN 0: 0, 0, 0 disk start address
15, 4, 31 disk end address
LUN 1: 16, 0, 0
111, 4, 31
LUN 2: 112, 0, 0
223, 4, 31
LUN 3: 224, 0, 0
335, 4, 31
LUN 4: 336, 0, 0
441, 4, 31
Total disk formatted size: 36,308,640 bytes
Data is transferred to/from the disk to the tape drive in 4KB records during backup/restore operations.
Only logical units 0, 1 and 2 can fit on a tape; a second tape was required for backing up logical units 3 and 4.
Next step: obtain data files that contain the LUNx information...
Creating a separate disk file that contains the contents of one of the tape files is okay. We can figuratively 'stitch" the files together into a format compatible with SimH by using some of our own utilities.
Since the DiskUtility transfers data on a block-for-block basis, all tape records must be recognized even if the record contains errors. Otherwise, the required relative position between tape and disk "records" will become lost. Error records can be indicated a variety of ways, so
According to a quick calculation, the LUN byte sizes can be calculated from the previously-provided LUN "partition" info as:
LUN 0: 1,310,720
LUN 1: 7,864,320
LUN 2: 9,175,040
LUN 3: 9,175,040
LUN 4: 8,683,520
LUN 0, 1 and 2 can fit on boot tape according to DiscUtility hints, LUN 3 and 4 fit on separate (2nd) backup tape.
-------------------------------
The cylinder/head/sector information was determined by monitoring the tape-to-disk LUN backup operation disk reads - these were the actual cyls/hds/sects actually written for the corresponding LUN backups.
I just did the following quick (hopefully correct) calculation:
Each cylinder has 81,920 bytes (5 heads * 32 sectors * 512 bytes = 81,920 bytes/cylinder), and LUN0 has 16 cylinders: 16 cylinders * 81,920 bytes/cylinder = 1,310,720.
More to follow...
-------------------------------
Now, back in my own words:
In my reading of the files on a full backup set where I found this Minicom Utility:
It appears that the pattern is that each file is the exact size of the partition, plus one "block" of either 4096 or 8192 bytes. The first file (after the bootable utility) on each tape has its first block as 8192 bytes, and it happens to also be 8192 bytes larger than the LU partition. All of the other files have their first block size, and all subsequent blocks size at 4096 bytes, and it happens to also be 4096 bytes larger than the corresponding LU partitions, which is the exact size of one block, and also the size of the first block in each of these files.
The first block also seems to contain a uniform bit/byte format, so could this be the "header" information for the LU? Just a guess so far.
So, here's the overview:
A full Hard Drive backup set consisted of two 20Mb QIC tapes:
Tape C (1 of 2) has four files:
1) Minicom Utility 8,192 bytes
2) LU0 1,318,912 bytes (8,192 bytes larger)
3) LU1 7,868,416 bytes (4,096 bytes larger)
4) LU2 9,179,136 bytes (4,096 bytes larger)
Tape CC (2 of 2) has three files: the Minicom Utility again, LU3 & LU4.
1) Minicom Utility 8,192 bytes
2) LU3 9,183,232 bytes (8,192 bytes larger)
3) LU4 8,687,616 bytes (4,096 bytes larger)
To which Bruce replies:
Various other 3rd-party backup/restore utilities had 'header blocks' prefixed to the actual backup data. The header blocks contained disk geometry information and sometimes partition information, so I would not be surprised if there is a block in front of the partition backups in this case also.
No comments:
Post a Comment