[Simh] PDP-10 DECtapes

[Johnny Billquist]

On 2013-03-28 13:41, Timothe Litt wrote:
>> 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.

I wasn't arguing that it was easy. In this case the opposite is 
definitely true. The TD8E is horrible. I've been saying that a number of 
times now. But I wouldn't call it arcane. It's simple.
That is the problem. It is too simple. It essentially exposes more or 
less just the electrical interface to the TU56, and that's it.

And that is the unfortunate part, because that means it exposes a very 
analog, stupid interface. It is very complex to emulate right, since it 
does so little.
Really. A TD8E does almost nothing. It is so simple and cheap it is 
ridiculous. The board have very little logic. And it was really cheap. 
And easy to design. And easy to manufacture.

It was the super-cheap option for a PDP-8 if you wanted DECtape.

Like I said, it is anything but complex in real life. Emulating it is a 
totally different story, for the same reason.

Depending on what you try to emulate, you can afford a few shortcuts. 
For OS/8, as well as all other DEC software I know of, you don't need to 
emulate the tape acceleration. You can pretend acceleration is 
instantaneous. Since all DEC software run the TD8E in polled mode, it is 
always just sitting there reading data until the right stuff comes. If 
you start feeding data a little earlier from the tape, it don't change 
anything.
Software like MULTOS, which actually try to use the TD8E in a 
timesharing system on the other hand, is a problem, since it does timing 
calculations for the tape to estimate how long before it comes to the 
right place, in order to not just do a polling loop all the time (not 
fun if you timeshare). However, no DEC software ever supported the TD8E 
in anything but just polled I/O.

(Yes, I really dislike the TD8E. And yes, I have a real one.)

	Johnny

>
> 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
>
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>


-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol