[Simh] PDP-10 DECtapes

[Timothe Litt]

Bob,

It might be useful to know exactly which images you tested.  A number of 
the 'PDP-10 DECtape images' that turned up on a quick Google search are 
actually for the PDP-11 front-end of a KL1090/1090.  These are in fact 
16-bit tapes: the file format would be Files-11 for RSX20F tapes; I 
think the KLAD DECtapes were DOS-11 format, but it's been a while.  The 
KLAD tapes were accessed by the -11 and loaded into the -10 via the 
DTE20.   This is distinct from 10-side DECtape diagnostics, which also 
exist. Google 'AA-JS16A-TC' for some Files-11 format information; I'd 
have to think a bit on the DOS-11 format.

Knowing which images you're working with would let the custodians of the 
images indicate their source, and perhaps from that we can work back to 
the people/method/tools used to create them.

Also, if the data that you're working with is in fact truncated saves of 
36-bit data, the directory block should still be recognizable.  
Filenames are in sixbit, and the block numbers in links fit in 16 bits.  
So the data should make sense, even if it is incomplete.  I posted the 
key format information for TOPS-10 DECtapes a while back in this 
string.  PDP-11 filenames were encoded in (PDP-11) Raxdix50.

I could look at an image file if you need help untangling the data.

On the pip10 /z, pip10 seems to use a private DTA service routine; it's 
in the sources that I pointed you to earlier.

This communication may not represent my employer's views,
if any, on the matters discussed.

On 27-Mar-13 22:08, Bob Supnik wrote:
> I believe the PDP-10 DECtape images that are floating around the web 
> may not be accurate transcriptions.
>
> All the images are 289KB long. An 18b (36b) DECtape consists of 18b 
> words in a 32b container (a 36b word in a 72b container). Thus, each 
> 256W x 18b (128W x 36b) DECtape block requires 1KB of dusj storage. 
> Therefore, the unage length, in KB, should equal the number of blocks, 
> which is 578. And in fact, all extent 18b PDP DECtape images are 578KB 
> long.
>
> A 16b DECtape consists of 16b words in a 16b container. Thus, each 
> 256W x 16b DECtape block requires 1/2 KB of storage. Therefore, the 
> image length, in KB, should equal half the number of blocks, or 578 / 
> 2 = 289. And that's what we have.
>
> This is confirmed by the fact that if you let the simulator "autosize" 
> the 289KB images, it comes up with PDP-11 format.
>
> I verified, by patching the simulator, that there is data in both 
> halves of each 32b word in the image. This too points to a PDP-11 image.
>
> Even if the PDP-10 DECtape were packed with no  padding, it should be 
> 18/16 = 9/8 the size of a PDP-11 image, or 325+KB. So I think the 
> images were transcribed on a TC11 and are missing 2b in every 18b.
>
> This is not to say that the TD8E simulator is correct. I cannot get it 
> to zero (initialize) a fresh 18b DECtape through PIP10, so something 
> is broken. However, the TD8E is so arcane that it will take a 
> considerable period of time to figure out what the software is trying 
> to do and why the simulator is responding incorrectly.
>
> /Bob
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130328/a6f35470/attachment-0002.bin>