[Simh] Problem with reading tape with PDP-11 SIMH

[Alan Frisbie]

On 05/21/2015 11:34 AM, Mark Pizzolato - Info Comm wrote:

 > I need a little more detail here.  I don’t know what the TPC
 > program is, but from what you are saying it might be a program
 > which reads a tape and creates a TPC format tape image.

Yes, that is exactly it.   It is the original RSX tape copy program,
and I was one of the authors, and primary maintainer in the 1980s,
along with Glenn Everhart.

 > If so, I wonder why you're doing this?

I wanted to see if I could use it to read a TAP image of a tape
to disk (as a TPC container file), then write a new "tape" in
TPC format.   I think that a TAP-to-TPC conversion utility exists,
but this idea came to mind and I wanted to try it.

 > Can you configure a TMSCP device on the simulator and in your OS
 > (simh device TQ) and try the same activity?

Not with the SYSGEN configuration I have at the moment, but I plan
to SYSGEN an RSX-11M-Plus v4.6 system soon, so I will add it.

 > If it works with TQ and doesn't with TS then your recipe is
 > good and there probably is a simulation issue.

Good point, and I will try that.

 > Does the TPC program merely use the normal OS device driver to
 > manipulate the device, or does it attempt to directly mess with
 > hardware?

Ordinary RSX QIO requests to the O/S.   It was designed to work
with both RSX-11D (and IAS) and RSX-11M.

 > If the OS driver is being used, then the simulator will behave
 > differently than real hardware in one significant way.  Since
 > you are saying " TPC was written to move a tape drive as fast
 > as possible", it would suggest to me that it attempts to queue
 > multiple I/O concurrent requests to the driver.

That is exactly what TPC is doing.   It fires off as many asynchronous
I/Os as it has buffer space for, then enters a wait state.   As
each read operation completes, an AST (RSX Asynchronous System Trap)
routine writes it to disk, then fires off another tape read request.
It only exits the mainline wait state when the end of tape data is
detected.

 > The difference with the simulator vs the real hardware is that,
 > in general the TPC program may never get a chance to queue more
 > than one I/O to the device since the first operation will likely
 > complete BEFORE control returns to the user mode program.  This
 > may stress the user mode program in ways which it never saw when
 > real tape operations took many milliseconds (or seconds).

An excellent point, which I had not considered.   I will have to
do some exploration in this area.

 > If this is happening, some adjustments to the behavior of the
 > TS device can potentially be made to slow it down.  Try
 > "sim> DEP TS TIME 5000" or change 5000 to some other large number
 > (the default is 10).

I will try this and let you know what happens.

Thanks for the information and suggestions.

Alan Frisbie