RSTS V7 magtape images on bitsavers

[Paul Koning]

> On Feb 9, 2017, at 9:14 PM, Zane Healy <healyzh at aracnet.com> wrote:
> 
> 
>> On Feb 9, 2017, at 5:39 PM, Paul Koning <paulkoning at comcast.net> wrote:
>> 
>> Gents,
>> 
>> I'm looking at a set of RSTS V7 magtape images (a release kit) which have an odd format that gives SIMH fits.
>> 
>> In the container formats I'm used to, each tape block image is preceded and followed by the data length as a 4-byte value.  In SIMH that's rounded up to even, in E11 format it's not, but apart from that this is how things work.
>> 
>> The V7 tape images don't match that format.  It looks like each block contains not just the data but also 2 more bytes, and the data length value represents that extra 2 bytes.  So the tape label is 16 bytes, not 14, and the data blocks are 514 bytes, not 512.
>> 
>> Does this ring any bells?  Where do those extra bytes come from?  Can SIMH be told to deal with this or does it require a repair program to fix the format?
>> 
>> 	paul
>> 
> 
> What is the file extension?  TPC or TAP?  I forget which SIMH uses, but there used to be a converter available to go from the format that many of the tape images are in, to the one SIMH uses.
> 
> Zane

From what I read about TPC, those tape images aren't TPC format -- which is described as having a 2 byte block length field.  What I see is 4 byte block lengths but 2 extraneous "data" bytes.  It's almost like the tape capture machinery picked up the LPC and CRC bytes from the tape block and stored those too, not just the data.

	paul