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

On Feb 9, 2017, at 8: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?