[Simh] PDP-10 DECtapes

[Bob Supnik]

I think you've got it, Tim. Here's what I've found:

05/13/2004  02:29 PM           295,936 J189B.DTA
05/13/2004  02:29 PM           295,936 J190C.DTA
05/13/2004  02:29 PM           295,936 J331A.DTA
06/24/2006  05:21 PM           295,936 MAINDEC-10-DCZBA-C-UB_4-73.dta

The last is the image Tim provided.

Still have to debug PIP10; it would be easier with an OS/8 system 
generated for the TC08.

/Bob

On 3/28/2013 6:43 AM, Timothe Litt wrote:
> 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
>
>