[Simh] PDP-10 DECtapes

Thu Mar 28 08:24:16 EDT 2013

J189B is the RSX20F V14-17 AUX dectape
J190C is the V14-45 system tape
J331A is the the V12-40 AUX tape.

All of these are Files-11 format (16-bit).

DCZBA decodes to a KA/KI diagnostic, but it turns out to be the 'basic 
peripheral diagnostic'; it probably wasn't renamed for the KL.  
According to the label on bitsavers 
(http://bitsavers.trailing-edge.com/bits/DEC/pdp10/dectape/diag/MAINDEC-10-DCZBA-C-UB_4-73.dta.txt), 
this is a 16-bit formatted tape containing 11-based KL10 diagnostics.  
So the filename may be wrong...

In any case, you don't have any -10 format DECtape images.

I have some physical 10-format tapes, but not the means to transcribe 
them. They're not of general interest; personal files.

I vaguely remember that someone has captured real 36-bit DECtapes, but 
the details escape me.  Al Kossow may remember...

A previous note pointed you to the OS/8 doc on how to configure for 
different hardware.

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

On 28-Mar-13 07:45, Bob Supnik wrote:
> 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
>>
>>

-------------- 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/f246d257/attachment-0002.bin>