On 07/07/2017 08:25 AM, Dave Wade wrote: > The header is six bytes long. Two are the length of the current > block. Two of the bytes are the length of the previous block, so you > can do read backwards, two of the bytes contain flag bits. One of the > flags says this chunk is the first part of a real block, another the > last part, so typically both are set for blocks less than 64K. For > blocks, bigger than 64K they the first chunk flag is set for the > first 64K, the last chunk has the last chunk bit set, and any > intermediate chunks have no bits set. Again this facilitates read > backwards....
Okay, that fills in a few gaps that the reference I cited didn't address. Contrast with the SIMH .tap structure, where all blocks are prefixed and suffixed with a 32-bit byte count, with certain high-order bits serving as flags for error and EOI indicators, with a single 32bit word of zero serving as tapemark. Read-backward is straightforward. The AWS format seems overcomplicated to me, but perhaps it's an artifact of a 16-bit memory-limited implementation. It's curious that, like TAP, the byte counts are little-endian. In any case, not a big deal to translate between the two. My own implementation of TAP keeps the same basic structure as the SIMH version, but appends a few records of metadata, including the log session of the read of the physical tape and a JPEG of the original tape. I usually trim those off when I make tape data available for other than the customer. Almost all of my work is done with archivists and the metadata is much appreciated. I've voiced my opinion before of being a bit surprised that neither AWS nor TAP makes any provision for metadata. The tape data bits don't tell the whole story. --Chuck
