[Simh] PDP-10 DECtapes

[Timothe Litt]

> I don't know if I'd call the TD8E arcane. 

I'll side with Bob on this one.  You would too, if you glance at the 
simh code for emulating it.  Even the imperfect emulation has to deal 
with mechanical timing - acceleration, deceleration and timing marks.   
(Imperfect = linear approximation; speed actually varies as a function 
of position due to the diameter changes as tape goes on and off the 
reels.)  And there are other oddities that software may or may not be 
sensitive to.  Like the fact that you don't just wait for acceleration; 
the tape moves, so the next valid block number over the read head is a 
function of when the tape is up to speed.  For the smart controllers, 
you don't see the block number until up-to-speed.  For the TD8E, I don't 
know.

Dumb hardware doesn't mean that the emulation is easy or simple. 
Sometimes it is; sometimes not.  This is not.


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

On 28-Mar-13 08:17, Johnny Billquist wrote:
> On 2013-03-28 03: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.
>
> I don't know if I'd call the TD8E arcane. Like I said before, it is 
> the most stupid controller ever invented.
> I had to write code last year to extract 18b images from a PDP-15 
> using the TD8E. Reading through the documentation, and reading through 
> the TD8E driver as well as PIP10 was enough for me to understand how 
> it worked, so you should be able to do the same.
> Basically, the TD8E gives you almost nothing at all. You need to do 
> just about all the fiddling yourself.
> It is horribly stupid and primitive.
>
>     Johnny
>
> _______________________________________________
> 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/0c844f29/attachment-0002.bin>