Line printer art: (was Re: tape baking)

Chuck Guzis cclist at sydex.com
Fri Jul 7 11:35:33 CDT 2017


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



More information about the cctalk mailing list