> On Feb 9, 2017, at 9:14 PM, Zane Healy <heal...@aracnet.com> wrote:
>
>
>> On Feb 9, 2017, at 5:39 PM, Paul Koning <paulkon...@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
