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
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: [email protected] || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
