Using DECtape or Magtape with on-screen or scale model front panels

[Rene Richarz]

I'm opening this new thread because the discussion about tape drives in "simulated peripherals, but with physical appearance (and handling)" has been mainly on simulated tape peripherals without physical appearance.

My current project is to hook up the SimH TQ tape driver and the SimH DECtape driver to my simulated DECtape front panel. Currently I'm trying to understand the TQ tape driver. I'm able to read and write tapes in 2.11 BSD using "tar", and I am able to see what's going on in the TQ driver. Below is a log file created with the following lines in boot.ini

set tq enabled

attach tq0 /home/pi/bsdtapes/tq0tape.tap

set debug /home/pi/bsdtapes/tqlog.txt

set tq debug

set tq nodebug=REG;STR

Log file after booting bsd and writing a short file using "tar cv filename":

Debug output to "/home/pi/bsdtapes/tqlog.txt"

Debug output to "/home/pi/bsdtapes/tqlog.txt" at Mon Dec  9 09:30:55 2019

PDP-11 simulator V4.0-0 Current  REALCONS build Aug 14 2019

DBG(8333)> TQ TAPE: sim_tape_reset(unit=0)

DBG(255815)> TQ TAPE: sim_tape_reset(unit=0)

DBG(4049508283)> TQ TAPE: sim_tape_reset(unit=0)

DBG(4049508283)> TQ REQ: initialization started

DBG(4049508490)> TQ TRACE: tq_quesvc

DBG(4049508490)> TQ INIT: CSTA=0, SAW=0x9BAC

DBG(4049508811)> TQ TRACE: tq_quesvc

DBG(4049508811)> TQ INIT: CSTA=2, SAW=0x2488

DBG(4049509097)> TQ TRACE: tq_quesvc

DBG(4049509097)> TQ INIT: CSTA=3, SAW=0x1

DBG(4049509189)> TQ TRACE: tq_quesvc

DBG(4049509189)> TQ INIT: CSTA=6, SAW=0x3

DBG(4049509189)> TQ REQ: initialization complete

DBG(4049513938)> TQ TRACE: tq_quesvc

DBG(4049513938)> TQ REQ: cmd=0004(SCC), mod=0000, unit=0, bc=00D00000, ma=00000000, obj=0, pos=0x0

DBG(4049513938)> TQ TRACE: tq_mscp

DBG(4049513938)> TQ TRACE: tq_scc

DBG(4049513938)> TQ REQ: rsp=0084, sts=0000, rszl=0000, obj=0, pos=0

DBG(4049514138)> TQ TRACE: tq_quesvc

DBG(4049515298)> TQ TRACE: tq_quesvc

DBG(4049515298)> TQ REQ: cmd=0009(ONL), mod=2000, unit=0, bc=00000000, ma=00000000, obj=0, pos=0x0

DBG(4049515298)> TQ TRACE: tq_mscp

DBG(4049515298)> TQ TRACE: tq_onl

DBG(4049515298)> TQ TAPE: sim_tape_rewind(unit=0)

DBG(4049515298)> TQ REQ: rsp=0089, sts=0000, rszl=0201, obj=0, pos=0

DBG(4049515498)> TQ TRACE: tq_quesvc

DBG(4049516923)> TQ TRACE: tq_quesvc

DBG(4049516923)> TQ REQ: cmd=0003(GUS), mod=0000, unit=0, bc=00000000, ma=00000000, obj=0, pos=0x0

DBG(4049516923)> TQ TRACE: tq_mscp

DBG(4049516923)> TQ TRACE: tq_gus

DBG(4049516923)> TQ REQ: rsp=0083, sts=0000, rszl=0000, obj=0, pos=0

DBG(4049517123)> TQ TRACE: tq_quesvc

DBG(4049518898)> TQ TRACE: tq_quesvc

DBG(4049518898)> TQ REQ: cmd=0025(POS), mod=2004, unit=0, bc=00000000, ma=00000000, obj=0, pos=0x0

DBG(4049518898)> TQ TRACE: tq_mscp

DBG(4049518898)> TQ TRACE: tq_pos

DBG(4049518898)> TQ TRACE: tq_mot_valid

DBG(4049518898)> TQ TRACE: tq_svc(unit=0, pkt=1, cmd=POS, mdf=0x2004, bc=0x0, phase=top)

DBG(4049518898)> TQ TAPE: sim_tape_position(unit=0, flags=0x2, recs=0, files=0)

DBG(4049518898)> TQ TRACE: tq_io_complete(status=0)

DBG(4049519098)> TQ TRACE: tq_quesvc

DBG(4049519398)> TQ TRACE: tq_svc(unit=0, pkt=1, cmd=POS, mdf=0x2004, bc=0x0, phase=top)

DBG(4049519398)> TQ REQ: Position Done: mdf=0x2004, nrec=0, ntmk=0, skrec=0, sktmk=0, skobj=0

DBG(4049519398)> TQ REQ: rsp=00A5, sts=0000, rszl=0000, obj=0, pos=0

DBG(4049521782)> TQ TRACE: tq_quesvc

DBG(4049521782)> TQ REQ: cmd=000A(SUC), mod=0020, unit=0, bc=00000000, ma=00000000, obj=0, pos=0x0

DBG(4049521782)> TQ TRACE: tq_mscp

DBG(4049521782)> TQ TRACE: tq_suc

DBG(4049521782)> TQ REQ: rsp=008A, sts=0000, rszl=0201, obj=0, pos=0

DBG(4049521982)> TQ TRACE: tq_quesvc

DBG(4049795501)> TQ TRACE: tq_quesvc

DBG(4049795501)> TQ REQ: cmd=0022( WR), mod=0000, unit=0, bc=00002800, ma=0001A000, obj=0, pos=0x0

DBG(4049795501)> TQ TRACE: tq_mscp

DBG(4049795501)> TQ TRACE: tq_rw

DBG(4049795501)> TQ TRACE: tq_mot_valid

DBG(4049795501)> TQ TRACE: tq_svc(unit=0, pkt=1, cmd=WR, mdf=0x0, bc=0x2800, phase=top)

DBG(4049795501)> TQ TAPE: sim_tape_wrrecf(unit=0, buf=0xb55b0090, bc=10240)

DBG(4049795501)> TQ TRACE: tq_io_complete(status=0)

DBG(4049795701)> TQ TRACE: tq_quesvc

DBG(4049796001)> TQ TRACE: tq_svc(unit=0, pkt=1, cmd=WR, mdf=0x0, bc=0x2800, phase=top)

DBG(4049796001)> TQ REQ: rsp=00A2, sts=0000, rszl=2800, obj=1, pos=10248

DBG(4049805221)> TQ TRACE: tq_quesvc

DBG(4049805221)> TQ REQ: cmd=0022( WR), mod=0000, unit=0, bc=00002800, ma=0001A000, obj=1, pos=0x2808

DBG(4049805221)> TQ TRACE: tq_mscp

DBG(4049805221)> TQ TRACE: tq_rw

DBG(4049805221)> TQ TRACE: tq_mot_valid

DBG(4049805221)> TQ TRACE: tq_svc(unit=0, pkt=1, cmd=WR, mdf=0x0, bc=0x2800, phase=top)

DBG(4049805221)> TQ TAPE: sim_tape_wrrecf(unit=0, buf=0xb55b0090, bc=10240)

DBG(4049805221)> TQ TRACE: tq_io_complete(status=0)

DBG(4049805421)> TQ TRACE: tq_quesvc

DBG(4049805721)> TQ TRACE: tq_svc(unit=0, pkt=1, cmd=WR, mdf=0x0, bc=0x2800, phase=top)

DBG(4049805721)> TQ REQ: rsp=00A2, sts=0000, rszl=2800, obj=2, pos=20496

DBG(4049815411)> TQ TRACE: tq_quesvc

DBG(4049815411)> TQ REQ: cmd=0024(WTM), mod=2000, unit=0, bc=00000000, ma=00000000, obj=2, pos=0x5010

DBG(4049815411)> TQ TRACE: tq_mscp

DBG(4049815411)> TQ TRACE: tq_wtm

DBG(4049815411)> TQ TRACE: tq_mot_valid

DBG(4049815411)> TQ TRACE: tq_svc(unit=0, pkt=1, cmd=WTM, mdf=0x2000, bc=0x0, phase=top)

DBG(4049815411)> TQ TAPE: sim_tape_wrtmk(unit=0)

DBG(4049815411)> TQ TRACE: tq_io_complete(status=0)

DBG(4049815611)> TQ TRACE: tq_quesvc

DBG(4049815911)> TQ TRACE: tq_svc(unit=0, pkt=1, cmd=WTM, mdf=0x2000, bc=0x0, phase=top)

DBG(4049815911)> TQ REQ: rsp=00A4, sts=0000, rszl=0000, obj=3, pos=20500

DBG(4049818045)> TQ TRACE: tq_quesvc

DBG(4049818045)> TQ REQ: cmd=0024(WTM), mod=2000, unit=0, bc=00000000, ma=00000000, obj=3, pos=0x5014

DBG(4049818045)> TQ TRACE: tq_mscp

DBG(4049818045)> TQ TRACE: tq_wtm

DBG(4049818045)> TQ TRACE: tq_mot_valid

DBG(4049818045)> TQ TRACE: tq_svc(unit=0, pkt=1, cmd=WTM, mdf=0x2000, bc=0x0, phase=top)

DBG(4049818045)> TQ TAPE: sim_tape_wrtmk(unit=0)

DBG(4049818045)> TQ TRACE: tq_io_complete(status=0)

DBG(4049818245)> TQ TRACE: tq_quesvc

DBG(4049818545)> TQ TRACE: tq_svc(unit=0, pkt=1, cmd=WTM, mdf=0x2000, bc=0x0, phase=top)

DBG(4049818545)> TQ REQ: rsp=00A4, sts=0000, rszl=0000, obj=4, pos=20504

DBG(4049820683)> TQ TRACE: tq_quesvc

DBG(4049820683)> TQ REQ: cmd=0025(POS), mod=000C, unit=0, bc=00000001, ma=00000000, obj=4, pos=0x5018

DBG(4049820683)> TQ TRACE: tq_mscp

DBG(4049820683)> TQ TRACE: tq_pos

DBG(4049820683)> TQ TRACE: tq_mot_valid

DBG(4049820683)> TQ TRACE: tq_svc(unit=0, pkt=1, cmd=POS, mdf=0xC, bc=0x1, phase=top)

DBG(4049820683)> TQ TAPE: sim_tape_position(unit=0, flags=0x6, recs=1, files=0)

DBG(4049820683)> TQ TAPE: sim_tape_sprecsr(unit=0, count=1)

DBG(4049820683)> TQ TAPE: sim_tape_sprecr(unit=0)

DBG(4049820683)> TQ TRACE: tq_io_complete(status=0)

DBG(4049820883)> TQ TRACE: tq_quesvc

DBG(4049821183)> TQ TRACE: tq_svc(unit=0, pkt=1, cmd=POS, mdf=0xC, bc=0x1, phase=top)

DBG(4049821183)> TQ REQ: Position Done: mdf=0x000C, nrec=1, ntmk=0, skrec=0, sktmk=0, skobj=1

DBG(4049821183)> TQ REQ: rsp=00A5, sts=0000, rszl=0000, obj=3, pos=20500

DBG(4049823356)> TQ TRACE: tq_quesvc

DBG(4049823356)> TQ REQ: cmd=0025(POS), mod=2042, unit=0, bc=00000000, ma=00000000, obj=3, pos=0x5014

DBG(4049823356)> TQ TRACE: tq_mscp

DBG(4049823356)> TQ TRACE: tq_pos

DBG(4049823356)> TQ TRACE: tq_mot_valid

DBG(4049823356)> TQ TRACE: tq_svc(unit=0, pkt=1, cmd=POS, mdf=0x2042, bc=0x0, phase=top)

DBG(4049823356)> TQ TAPE: sim_tape_position(unit=0, flags=0x8, recs=0, files=0)

DBG(4049823356)> TQ TAPE: sim_tape_rewind(unit=0)

DBG(4049823356)> TQ TAPE: sim_tape_spfilebyrecf(unit=0, count=0, check_leot=0)

DBG(4049823356)> TQ TAPE: sim_tape_sprecsf(unit=0, count=0)

DBG(4049823356)> TQ TRACE: tq_io_complete(status=0)

DBG(4049823556)> TQ TRACE: tq_quesvc

DBG(4049823856)> TQ TRACE: tq_svc(unit=0, pkt=1, cmd=POS, mdf=0x2042, bc=0x0, phase=top)

DBG(4049823856)> TQ REQ: Position Done: mdf=0x2042, nrec=0, ntmk=0, skrec=0, sktmk=0, skobj=0

DBG(4049823856)> TQ REQ: rsp=00A5, sts=0000, rszl=0000, obj=0, pos=0

DBG(4073607272)> TQ TRACE: tq_tmrsvc

DBG(4094449392)> TQ TRACE: tq_tmrsvc

DBG(4121644099)> TQ TRACE: tq_tmrsvc

DBG(4147273125)> TQ TRACE: tq_tmrsvc

DBG(4172594440)> TQ TRACE: tq_tmrsvc

DBG(4197874438)> TQ TRACE: tq_tmrsvc

One can actually see how it initializes and positions the tape and writes 2 blocks. That's all fine, and tells me how the SimH driver goes through its motions. It should therefore be easy to add a few lines in the SimH driver to talk to my simulated front panel, turn on the "remote" light, and spin the reels at the appropriate times.

But my problem is that the SimH TQ driver does not appear to simulate realistic tape transfer times. In fact I have not found anything throttling it to realistic transfer times, and backing up my whole home directory seems to happen much too fast. Using "help tq set" does not appear to give any parameter which could be used for throttling. So I hope that somebody with a bit of experience in writing or modifying a SimH driver could give me a hint on how throttling in that driver can be added or turned on. I think what would have to be done is to delay "tq_io_complete".

[Johnny Billquist]

I think neither disk, nor tape, tries to simulate speed. This is also a
tricky subject, because it depends on what disk/tape you want to
simulate. They can be wildly different in speed. (And, just as with
serial, I personally don't like that slowing down, but I can understand
that some people want to experience what it actually was like back then.)

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pidp-11/4f1c5bff-9ecb-43e3-ab76-30b5f638184b%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/4f1c5bff-9ecb-43e3-ab76-30b5f638184b%40googlegroups.com?utm_medium=email&utm_source=footer>.

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

[Rene Richarz]

On Monday, December 9, 2019 at 11:26:52 AM UTC+1, Johnny Billquist wrote:

I think neither disk, nor tape, tries to simulate speed. This is also a
tricky subject, because it depends on what disk/tape you want to
simulate. They can be wildly different in speed. (And, just as with
serial, I personally don't like that slowing down, but I can understand
that some people want to experience what it actually was like back then.)

Yes, I normally also want to run at full speed. But if you have a simulated on-screen or scale-model front panel, it's really no fun if the wheels just turn for a few milliseconds.

I have in the mean time changed the debug log to include a time stamp and show only the relevant TQ REQ statements. What you can see below is that it writes 2 blocks and some marks in just a few milliseconds (I guess to the Linux disk cache). Fortunately one can see that all TQ REQ lines do contain an actual position on tape. It is therefore not very difficult to calculate a reasonable execution time for each command. All I have to do is to find out how to add these delays without suspending SimH. I haven't verified that, but I would expect that the device driver actually uses simulated DMA and/or interrupts and SimH does not hang in that driver while the tape is doing something.

And once I have modified the TQ driver it should be possible to use a similar strategy to modify the DECtape driver.

Debug output to "/home/pi/bsdtapes/tqlog.txt"

   Debug messages display time of day as hh:mm:ss.msec relative to the start of debugging

Debug output to "/home/pi/bsdtapes/tqlog.txt" at Mon Dec  9 11:23:21 2019

PDP-11 simulator V4.0-0 Current  REALCONS build Aug 14 2019

DBG(01:01:46.870 2483969620)> TQ REQ: initialization started

DBG(01:01:46.870 2483970518)> TQ REQ: initialization complete

DBG(01:01:46.871 2483975271)> TQ REQ: cmd=0004(SCC), mod=0000, unit=0, bc=00D00000, ma=00000000, obj=0, pos=0x0

DBG(01:01:46.872 2483975271)> TQ REQ: rsp=0084, sts=0000, rszl=0000, obj=0, pos=0

DBG(01:01:46.872 2483976631)> TQ REQ: cmd=0009(ONL), mod=2000, unit=0, bc=00000000, ma=00000000, obj=0, pos=0x0

DBG(01:01:46.872 2483976631)> TQ REQ: rsp=0089, sts=0000, rszl=0201, obj=0, pos=0

DBG(01:01:46.872 2483978256)> TQ REQ: cmd=0003(GUS), mod=0000, unit=0, bc=00000000, ma=00000000, obj=0, pos=0x0

DBG(01:01:46.872 2483978256)> TQ REQ: rsp=0083, sts=0000, rszl=0000, obj=0, pos=0

DBG(01:01:46.873 2483980231)> TQ REQ: cmd=0025(POS), mod=2004, unit=0, bc=00000000, ma=00000000, obj=0, pos=0x0

DBG(01:01:46.873 2483980731)> TQ REQ: Position Done: mdf=0x2004, nrec=0, ntmk=0, skrec=0, sktmk=0, skobj=0

DBG(01:01:46.873 2483980731)> TQ REQ: rsp=00A5, sts=0000, rszl=0000, obj=0, pos=0

DBG(01:01:46.874 2483983115)> TQ REQ: cmd=000A(SUC), mod=0020, unit=0, bc=00000000, ma=00000000, obj=0, pos=0x0

DBG(01:01:46.874 2483983115)> TQ REQ: rsp=008A, sts=0000, rszl=0201, obj=0, pos=0

DBG(01:01:46.964 2484256839)> TQ REQ: cmd=0022( WR), mod=0000, unit=0, bc=00002800, ma=0001A000, obj=0, pos=0x0

DBG(01:01:46.965 2484257339)> TQ REQ: rsp=00A2, sts=0000, rszl=2800, obj=1, pos=10248

DBG(01:01:46.968 2484266561)> TQ REQ: cmd=0022( WR), mod=0000, unit=0, bc=00002800, ma=0001A000, obj=1, pos=0x2808

DBG(01:01:46.968 2484267061)> TQ REQ: rsp=00A2, sts=0000, rszl=2800, obj=2, pos=20496

DBG(01:01:46.971 2484276769)> TQ REQ: cmd=0024(WTM), mod=2000, unit=0, bc=00000000, ma=00000000, obj=2, pos=0x5010

DBG(01:01:46.971 2484277269)> TQ REQ: rsp=00A4, sts=0000, rszl=0000, obj=3, pos=20500

DBG(01:01:46.972 2484279403)> TQ REQ: cmd=0024(WTM), mod=2000, unit=0, bc=00000000, ma=00000000, obj=3, pos=0x5014

DBG(01:01:46.972 2484279903)> TQ REQ: rsp=00A4, sts=0000, rszl=0000, obj=4, pos=20504

DBG(01:01:46.972 2484282041)> TQ REQ: cmd=0025(POS), mod=000C, unit=0, bc=00000001, ma=00000000, obj=4, pos=0x5018

DBG(01:01:46.973 2484282541)> TQ REQ: Position Done: mdf=0x000C, nrec=1, ntmk=0, skrec=0, sktmk=0, skobj=1

DBG(01:01:46.973 2484282541)> TQ REQ: rsp=00A5, sts=0000, rszl=0000, obj=3, pos=20500

DBG(01:01:46.973 2484284714)> TQ REQ: cmd=0025(POS), mod=2042, unit=0, bc=00000000, ma=00000000, obj=3, pos=0x5014

DBG(01:01:46.974 2484285214)> TQ REQ: Position Done: mdf=0x2042, nrec=0, ntmk=0, skrec=0, sktmk=0, skobj=0

DBG(01:01:46.974 2484285214)> TQ REQ: rsp=00A5, sts=0000, rszl=0000, obj=0, pos=0

HALT instruction, PC: 000014 (MOV #1,11242)

sim> exit

Goodbye

Eth: closed eth0

[Oscar Vermeulen]

Rene,

From the PiDP-8, I know it uses the td and dt devices as DECtape emulation. One of them (I can't quite remember which one) is more or less timing-correct.

I'm away from PiDPs at the moment, but do you alse have both td and dt devices in the simh PDP-11 simulation?

Kind regards,

Oscar.

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/099b47d2-a655-43c2-ae22-d83b3fe99a65%40googlegroups.com.

[Steve Tockey]

For what it’s worth, I think simulated device speed is a more general problem. The PiDP-8/I simulated paper tape reader (PTR:) runs so fast that it chokes simh when interrupts are enabled. I hope that a general case solution can be found that solves the problem not only for DecTape but for other simulated I/O devices like PTR: as well.

One though would be to have the device speed simulated within a separate thread but that takes more knowledge of how simh works than I have time to figure out.

[Johnny Billquist]

On 2019-12-09 12:02, Rene Richarz wrote:
>
>
> On Monday, December 9, 2019 at 11:26:52 AM UTC+1, Johnny Billquist wrote:
>
> I think neither disk, nor tape, tries to simulate speed. This is also a
> tricky subject, because it depends on what disk/tape you want to
> simulate. They can be wildly different in speed. (And, just as with
> serial, I personally don't like that slowing down, but I can understand
> that some people want to experience what it actually was like back
> then.)
>
>
> Yes, I normally also want to run at full speed. But if you have a
> simulated on-screen or scale-model front panel, it's really no fun if
> the wheels just turn for a few milliseconds.

Like I said - I can understand that some people want to experience it. :-)

> I have in the mean time changed the debug log to include a time stamp
> and show only the relevant TQ REQ statements. What you can see below is
> that it writes 2 blocks and some marks in just a few milliseconds (I
> guess to the Linux disk cache). Fortunately one can see that all TQ REQ
> lines do contain an actual position on tape. It is therefore not very
> difficult to calculate a reasonable execution time for each command. All
> I have to do is to find out how to add these delays without suspending
> SimH. I haven't verified that, but I would expect that the device driver
> actually uses simulated DMA and/or interrupts and SimH does not hang in
> that driver while the tape is doing something.

Right. It's usually using DMA, so no CPU activity. And yes, simh needs
to know about tape position, in order to be able to seek, since seeks on
tape are for most things relative to current position.

> And once I have modified the TQ driver it should be possible to use a
> similar strategy to modify the DECtape driver.

From that point of view, yes. Just as with a simulated disk. You know
the current position, and you know where you want to go, so then you can
compute how much time it would take.

Johnny

[Digby R.S. Tarvin]

I would think that two settable parameters would be enough for a reasonable simulation of speed - a figure for seek speed (in blocks or inches per second), and a figure for read/write speed (in the same units). 

Default would be zero, meaning no added delays. Not sure if it would be worth worrying about acceleration...

I'd prefer to update the simh tape elulation to talk to real hardware, but I suppose it would be trivial to add the timing emulation at the same time, as most of the work is becoming familiar with the code that is already there. 

Likewise, if you are integrating some visualization support into the driver, adding delay timing would also be a negligible increase in  the amount of work.

DigbyT

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/dce718a5-1116-2261-a9af-5a61488eff91%40softjar.se.

[Rene Richarz]

I have coded the communication between a simulated host and the tu56 on-screen front panel. I have also written a little "demo" program simulating a host and the copying of data from drive 0 to drive 1. The new version of tu56 and the demo program are in my github repo https://github.com/rricharz/Tu56. The whole project turns out to be easier and more fun than I originally anticipated.

I don't have a real TU 56 to compare, but I'm sure that some more seeks are required before and after the actual copying, and the timing needs improvement. But if anybody having a working TU 56 wants a more realistic demo, demo.c is easy to understand and modify. Of course I would be very interested in a more realistic version of demo.c.

I know now exactly how to make the SimH TQ driver talk to my panel, and add realistic timing to it. Not a lot more work to be done therefore to make the on-screen panel work with BSD (using magtape io, because there is no DECtape driver in BSD).

Afterwards, I will need help from somebody to set up and operate a DEC operating system to talk to the SimH DECtape driver, so that I can implement the modifications required in that driver to talk to the tu56 on-screen panel.

Finally, all that work will also be very useful for making a scale model TU 56 front panel.

[Henk Gooijen]

Am Dienstag, 10. Dezember 2019 10:13:44 UTC+1 schrieb Rene Richarz:

[... snip ...]

Finally, all that work will also be very useful for making a scale model TU 56 front panel.

It is a new project at very low priority, but I bought 4 stepper motors (10 euro each), a 4-channel stepper motor driver (30 euro) and two 8-channel heads (Woelke M368X).

Promising nothing, but I like cool experiments ... however, I have no clue what the result will be in the end ...

Given the recent activities, I have picked up the RK05 "project". Still struggling with the mechanical construction for the cartridge guidance into the "RK05 drive".

That is where I got stuck (last year ?!), but really want to get to a neat solution this time. That's what holidays are for :)

[Rene Richarz]

On Tuesday, December 10, 2019 at 3:07:02 AM UTC+1, Steve Tockey wrote:

For what it’s worth, I think simulated device speed is a more general problem. The PiDP-8/I simulated paper tape reader (PTR:) runs so fast that it chokes simh when interrupts are enabled. I hope that a general case solution can be found that solves the problem not only for DecTape but for other simulated I/O devices like PTR: as well.

One though would be to have the device speed simulated within a separate thread but that takes more knowledge of how simh works than I have time to figure out.

 

Yes, that would be nice.

SimH is a single threaded simulator simulating a large number of CPU's and peripheral devices. It does all the interrupts, DMA and other things using a number of internal clocks, and a task scheduler. One of the clocks is a real absolute clock in microseconds, others simulate whatever a specific computer had. A device can also have its on clocks, but depends on the main SimH scheduler calling specific device routines at requested times, and on every driver behaving as a good citizen.

Most of the device drivers run as fast as possible, and as Johnny said recently, most users probably want it that way. Most of the efforts drivers make regarding timing is not to overwhelm the operating system running. That's a complex story already, given that many historic device drivers are haven't been written for faster hardware.

Simulating the device driver at a realistic speed is in SimH defined to be the responsibility of each device driver. SimH just provides a number of hooks to do that.

The first thing I would do is to look at the settings of the driver you would want to operate differently.

Typing

  help drivername set

in SimH should show you all of that.

[Rene Richarz]

The TU 56 on-screen front panel emulator and the corresponding TQ tape driver are now ready at https://github.com/rricharz/Tu56.

See this youtube video. It shows 2.11 BSD on the PiDP-11 uploading several Tektronix 4010 plot files from the TU 56 emulator and displaying them on the tek4010 terminal emulator. The TU 56 has to do lots of seeks, because each file is uploaded separately and then displayed right away. It uses the TQ tape driver at the moment because we do not have a 2.11 BSD DECtape driver.

The tu56 emulator runs at what I believe is a realistic speed. The tek4010 emulator has been set to 2400 baud in this video for a realist 1970's experience.

I'm looking forward to your critical comments and ideas for improvements.

[Steve Tockey]

Rene Richarz wrote:

"The first thing I would do is to look at the settings of the driver you would want to operate differently."

Unfortunately, the SIMH response is:

sim> help ptr set

No SET help is available for the PTR device

"Simulating the device driver at a realistic speed is in SimH defined to be the responsibility of each device driver. SimH just provides a number of hooks to do that."

Looking at the relevant source code, it's clear that the driver I'm interested in is not taking advantage of any of those hooks. Again, FYI, I am personally concerned with the PTR: driver for the PiDP-8/i. The source code is here:

.../pidp8i/src/SIMH/PDP8/pdp8_pt.c

the code that simulates getting the next character from PTR: (specifically, case 2: in function int32 ptr (int32 IR, int32 AC) ) simply pulls the next character out of the attached data file.

Of course it would be trivial to put a delay loop into that function and that would slow down the device. However that would also block the rest of SIMH from executing anything, thus defeating the whole purpose. When running with interrupts enabled, SIMH needs to be able to continue whatever other CPU processing is going on during the simulated time delay between characters.

So yes, my concern is not entirely relevant to the main thread of simulating DecTape. However again my point is that if a general (not a DecTape-specific) solution can be built then it could be ported over to PiDP-8/i land and help solve my problem, too.

By the way, what hooks does SIMH provide? Where would I find them documented?

Thanks,

-- steve

[sunnyboy010101]

What a wonderful video. I loved the animation of the tape drive, and the work that went into making a very realistic rendition of the drive.

[Rene Richarz]

On Wednesday, December 11, 2019 at 10:02:01 PM UTC+1, Steve Tockey wrote:

By the way, what hooks does SIMH provide? Where would I find them documented?

You can read about it in chapter 3.2.1 of the following documentation:

Writing a simulator for simh

 

[Henk Gooijen]

Without checking, IIRC the RK05 driver implements calculated (seek) delays.

-Henk

Am Mittwoch, 11. Dezember 2019 22:02:01 UTC+1 schrieb Steve Tockey:

Rene Richarz wrote:

"The first thing I would do is to look at the settings of the driver you would want to operate differently."

Unfortunately, the SIMH response is:

sim> help ptr set

No SET help is available for the PTR device

"Simulating the device driver at a realistic speed is in SimH defined to be the responsibility of each device driver. SimH just provides a number of hooks to do that."

Looking at the relevant source code, it's clear that the driver I'm interested in is not taking advantage of any of those hooks. Again, FYI, I am personally concerned with the PTR: driver for the PiDP-8/i. The source code is here:

.../pidp8i/src/SIMH/PDP8/pdp8_pt.c

[Rene Richarz]

On Tuesday, December 10, 2019 at 12:56:04 AM UTC+1, oscarv wrote:

From the PiDP-8, I know it uses the td and dt devices as DECtape emulation. One of them (I can't quite remember which one) is more or less timing-correct.

I'm away from PiDPs at the moment, but do you alse have both td and dt devices in the simh PDP-11 simulation?

 

Oscar,

I had a quick look at the PDP-8 TD driver

  https://github.com/simh/simh/blob/master/PDP8/pdp8_td.c

and it looks quite simple and does handle realistic timing.

I think it would not take more than a few hours to put the hooks in there to talk to my tu56 front panel. But I would need a test setup. Not knowing anything about how to operate a PDP-8 and DECtape I feel the effort to put a test system in place would be much larger than the actual modification of the driver. I assume you have instructions somewhere how to download and install suitable PiDP-8 software. If you can also point me to instructions on how to initiate some very simple DECtape operations (such as reading or writing to a small file, not booting up on DECtape), that would help a lot.

Or, if somebody can point me to simple instructions on how to setup and operate a DECtape using a DEC PDP-11 OS on the PiDP-11, then I could modify the PDP-11 DT driver. The PDP-11 DT driver looks a lot more complicated than the PDP-8 DT driver, but has debug facilities which help to understand what it is doing.

[Neal G.]

On Thursday, December 12, 2019 at 2:53:31 AM UTC-6, Rene Richarz wrote:

Or, if somebody can point me to simple instructions on how to setup and operate a DECtape using a DEC PDP-11 OS on the PiDP-11, then I could modify the PDP-11 DT driver. The PDP-11 DT driver looks a lot more complicated than the PDP-8 DT driver, but has debug facilities which help to understand what it is doing.

I can help with this when you're ready to work on the PDP-11 driver.

With a previously initialized DECtape attached in simh,

then in RSX11M+

      $ mount dt0: volume_label

to list the volume's content,

      $ dir dt0:[*,*]*.*

or to list the volume's usage and free space,

      $ dir /free

- Neal G.

[Rene Richarz]

Thanks, Neal,

That's already very helpful. Unfortunately I have 2 more roadblocks to overcome before I can start to work with RSX-11.

1. I have not yet figured out how to attach a DECtape driver. I can find "pdp11_td.c" in "/opt/pidp11/src/02.3_simh/4.x+realcons/src/PDP11", and it is a DECtape driver, which would not be too hard to modify. But "set td enabled" or "attach td filename" or "set td debug" in SimH just gives me an error message: non-existent device. I think somehow the driver is probably not linked in SimH, or I'm doing something wrong. Maybe I have to modify the build process of SimH to

include that driver. I will dig in the SimH documentation tomorrow :(.

2. I probably also need an image of a DECtape to attach. But maybe the driver will initialize an empty file. We will see once I can attach the driver.

[Rene Richarz]

I just realized that most likely the simh driver to use with DECtape on RSX11 is the TC driver.

in boot.ini:

set debug -r -n /home/pi/tapes/tclog.txt

set tc debug

set tc enable

attach tc0 /home/pi/tapes/tc0tape.dectape

gives the following debug logfile in tclog.txt:

PDP-11 simulator V4.0-0 Current  REALCONS build Dec 11 2019

TC0: 16b format, buffering file in memory

RQ0: 'PiDP11_DU0.dsk' Contains an ODS1 File system

......

It did create an empty tc0tape.dectape file

But when I try in RSX-11 to mount the DECtape, I get

>MOUNT TC0:MYTAPE

MOU - no such device available

Maybe what I really need is a RECtape image, which I can attach, instead of letting the driver create an empty file. Or is these a way to initialize it once RSX-11 is running?

Any help is appreciated.

[Warren Young]

On Thursday, December 12, 2019 at 1:53:31 AM UTC-7, Rene Richarz wrote:

Not knowing anything about how to operate a PDP-8 and DECtape I feel the effort to put a test system in place would be much larger than the actual modification of the driver.

The PiDP-8/I software builds and runs on just about everything, and it configures, builds, and installs in the usual way.

You don't even have to install it. Just say "make run" after it's built to launch the built simulator with the freshly-built OS/8 disk image.

I'd recommend that you do this on a desktop platform, not on your PiDP-11, for a couple of reasons.

First, the computer you're reading this on is probably faster than your PiDP-11, so if the PiDP-8/I software will build on it, you'll get to your destination faster by building and testing your work there. Most of my own work on the PiDP-8/I software is done on a Mac, and a fair bit on an Ubuntu VM on my laptop, not on the PiDP-8/I itself. I pretty much only build for final testing and running on the Pi.

Second, the default configuration will get confused if you run it on a Pi with a PiDP-11 front panel attached. It'll say "Oh, I see the Pi's GPIO, I know how to run the front panel!" and be dead wrong. You can get around this by running bin/pdp8, which is the same as bin/pidp8i-sim with all of the PiDP-8/I stuff either compiled out or disabled, but then things like "make run" don't work short of modifying the Makefile. You avoid all of that hassle by running it on a non-Pi host.

 

instructions on how to initiate some very simple DECtape operations

$ make run

... stuff ...

Ctrl-E

Simulation stopped, PC: 01210 (JMP 1207)
sim> att dt media/os8/al-4691c-sa-os8-v3d-1.1978.tu56
DT0: 12b format, buffering file in memory
sim> c
DIR DTA0:

[Johnny Billquist]

In RSX, the DECtape device isn't TC:, it is DT:. Check if you have such
a device.

DEV DT: (under MCR)
SHOW DEV DT: (under DCL)

If it exists, then you should be good to go. If it don't then it needs
to be built and loaded into the system.

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/8a443349-5dd8-415e-993a-a84b060814e9%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/8a443349-5dd8-415e-993a-a84b060814e9%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Neal G.]

On Thursday, December 12, 2019 at 1:23:05 PM UTC-6, Rene Richarz wrote:

Maybe what I really need is a RECtape image, which I can attach, instead of letting the driver create an empty file. Or is these a way to initialize it once RSX-11 is running?

Any help is appreciated.

Thanks Jonny for the correction.

Rene, here's some additional information.

It appears that the RSX11 system in PiDP-11 was configured with the DECTape II, TU58, not the original TU56.

The RSX11 device identifier for the TU58 is DD instead of DT.

Unfortunately the simh configuration (boot.ini) for the RSX11 system does not enable the simh "TDC" device which implements the TU58 and its controller.

If the boot.ini is revised to place this,
   set tdc enable
somewhere before the line,
   set dz enable
then the next time RSX11 is started, the TU58 will be availble.

Now running RSX11 a show device indicates,

$ sh dev
...
DD0:     Loaded Type=TU58
DD1:     Loaded Type=TU58
...

The DECTape devices are available.
OK, now let's initialize a blank DECTape.

CTRL-E
Simulation stopped, PC: 025340 (BR 25306)

sim> attach tdc0 test01-tu58.tap
TDC: creating new file
TDC: buffering file in memory

sim> sh tdc
TDC     controllers=1, address=17776500-17776507, vector=300*, BR4, 2 units
  TDC0  262KB, attached to test01-tu58.tap, write enabled
  TDC1  262KB, not attached, write enabled
sim> cont

$ ALLOCATE DD0:
$ MOUNT DD0: /FOREIGN
$ BAD DD0:
BAD -- DD0: Total bad blocks= 0.

$ INITIALIZE DD0: TEST01

$ DISMOUNT DD0:
DMO -- TT0:    dismounted from DD0:    *** Final dismount initiated ***
10:47:35  *** DD0:  -- Dismount complete
$

Now that the DECTape volume is ready for use, here's a session that mounts it normally, checks its status, checks it free space.

$ MOUNT DD0: TEST01

$ SHOW DEVICE DD
DD0:     TT0: - Private Mounted Loaded Label=TEST01 Type=TU58
DD1:     Loaded Type=TU58

$ DIR DD0: /FREE

DD0: has 484. blocks free, 28. blocks used out of 512.
Largest contiguous space = 484. blocks
25. file headers are free, 5. headers used out of 30.

$

Next we'll create a USER directory on the DECTape and copy some sample text files from the USER directory on the main disk (DU0:)

$ SET DEFAULT DU0:[USER] /NAMED
$ CREATE/DIR DD0:[USER]
$ DIR *.TXT

Directory DU0:[USER]
21-DEC-2019 10:51

FLU.TXT;1           1.         18-DEC-1998 02:46
FLY.TXT;3           1.         18-DEC-1998 02:46
HELLO.TXT;1         2.         18-DEC-1998 02:46
LONG.TXT;1          25.        18-DEC-1998 02:46
WHATSHERE.TXT;1     10.        18-DEC-1998 02:46
MAIL4.TXT;1         16.        01-MAY-2018 17:30

Total of 55./59. blocks in 6. files

$ COPY *.TXT DD0:[USER]
$ DIR DD0:[USER]

Directory DD0:[USER]
21-DEC-2019 10:51

FLU.TXT;1           1.         18-DEC-1998 02:46
FLY.TXT;1           1.         18-DEC-1998 02:46
HELLO.TXT;1         2.         18-DEC-1998 02:46
LONG.TXT;1          25.        18-DEC-1998 02:46
WHATSHERE.TXT;1     10.        18-DEC-1998 02:46
MAIL4.TXT;1         16.        01-MAY-2018 17:30

Total of 55./55. blocks in 6. files

$

Recheck he amount of free space on the DECTape,

$ DIR/FREE DD0:

DD0: has 428. blocks free, 84. blocks used out of 512.
Largest contiguous space = 428. blocks
18. file headers are free, 12. headers used out of 30.

$

Type the content of one of the text files from the DECTape; then dismount the DECTape.

$ TYPE DD0:[USER]HELLO.TXT
        <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
        |                                               |
        |     Hello.                                    |
        |                                               |
        |      You are now logged in on the             |
        |      RSX-11M-PLUS Operating System.           |
...

$ DISMOUNT DD0:
DMO -- TT0:    dismounted from DD0:    *** Final dismount initiated ***
$
  10:53:47  *** DD0:  -- Dismount complete
$

When done with the DECTape, detach the simh file.

CTRL-E
Simulation stopped, PC: 025340 (BR 25306)
sim> detach tdc0
TDC: writing buffer to file
sim>

While this example used the TU58 and the simh TDC device. Operation of the TU56 with the simh TC device would be very similar.
But, as Johnny noted, a system regen would be needed to make a TU56 available to RSX11.
The PiDP-11 RSX11 system is quite large. I have a few much simplier RSX11 systems I've been working with.

If it would help, I can regen one of those with a TU56, just let me know.

- Neal G.

[Johnny Billquist]

Just a small comment here.

You do not need to regenerate RSX for this.
If you run SYSGEN, there is the option of just building a device driver
and nothing else. Do that to build the DECtape device driver.
Then you just load the device driver into the running system, and off
you go.

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/d7a2ef73-543f-4a7b-b4c3-5c8b7bce5d1a%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/d7a2ef73-543f-4a7b-b4c3-5c8b7bce5d1a%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Rene Richarz]

Neal,

Your detailed writeup is very helpful. The good news is, that we are talking to the tdc driver and I can see lots of things going on in that driver if I turn on debugging.

The bad news is that I'm stuck after the "INITIALIZE DD0: TEST01" command, because "DISMOUNT DD0:" gives me the following error:

CCL syntax error -- unknown or ambiguous command

If I then just type CTRL-E and "detach tdc0" it does write a buffer to tape, but unfortunately the file is just 256 kByte long. I think that the "DISMOUNT" is essential to save the "INITIALIZE".

I can later mount DD0: again and do the "SHOW DEVICE DD", but "DIR DD0: /FREE" does not work.

What is the proper command for the DISMOUNT step?

Thanks, Rene

[Johnny Billquist]

Rene, you seem to be using the CCL command line interpreter then.
In which case, your commands are going to be more related to MCR.

So the proper command in MCR is DMO, not DISMOUNT.

And it seems very correct that the file would be 256 KB. As far as I can
remember, that is the capacity of a DECtape.

And before you do a DIR, the tape needs to be mounted normally. That
means mounted with the label name, and not mounted foreign (/FOR).

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/653508bc-613d-42fa-bca0-3c7bfeabddd8%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/653508bc-613d-42fa-bca0-3c7bfeabddd8%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Rene Richarz]

On Friday, December 13, 2019 at 9:47:31 AM UTC+1, Johnny Billquist wrote:

Rene, you seem to be using the CCL command line interpreter then.
In which case, your commands are going to be more related to MCR.

So the proper command in MCR is DMO, not DISMOUNT.

Ok, that works. I can now "MOUNT DD0: TEST1" and "SHOW DEVICE DD", but I'm getting stuck again trying to do "CREATE/DIR DD0:[USER]".

The response is  "pip -- cannot find directory file".

 

And it seems very correct that the file would be 256 KB. As far as I can
remember, that is the capacity of a DECtape.

OK. Sounds reasonable. My first floppy was 80 kByte.

 

And before you do a DIR, the tape needs to be mounted normally. That
means mounted with the label name, and not mounted foreign (/FOR).

I'm trying to do that, I think. Sorry, after 45 years of using Unix, Linux, DOS and Windows RSX11 really looks extremely strange.

Maybe it would be easier for somebody understanding RSX11 to modify the tdc DECtape driver (pdp11_td.c). What needs to be done to support my TU56 on screen front panel is very easy to understand if one looks at demo.c in my github repo.

Rene

[Johnny Billquist]

To create a directory under MCR the command is "UFD".

But maybe you should switch to DCL since that is a little more human friendly...

SET /DCL=TI:

Johnny

Rene Richarz <rene.r...@bluewin.ch> skrev: (13 december 2019 11:08:37 CET)

--
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.

[Rene Richarz]

On Friday, December 13, 2019 at 2:42:27 PM UTC+1, Johnny Billquist wrote:

But maybe you should switch to DCL since that is a little more human friendly...

SET /DCL=TI:

Thanks, Johnny,

That does the job. I'm now all set to analyze and modify the tdc driver (TU58) driver to save the status bits so that my TU56 front panel can read them.

IMPORTANT - WHICH DRIVER TO MODIFY (TU58 or TU56)?

Before starting, I would like to ask the RSX11 users in this group, whether they prefer to operate with the TU58 driver running the TU56 front panel, or the TU56 driver.

If the group prefers the TU56 driver, I will need a modified RSX11 image with the corresponding device driver enabled (could you make that, Neal?) and the proper attach command for it, including the device name in RSX11. As far as I can see you cannot have both drivers being activated at the same time because they appear to use the same vectors.

I haven't yet looked into the timing of these 2 drivers. For the front panel to look right,

it will in any case be necessary to have reasonable realistic timing.

 

[Steve Tockey]

Rene,

Thanks so much, that hint did the trick. I found that the SIMH PDP-8 PTR: and PTP: can, in fact, already be throttled. Lines 147 and 158 of .../pidp8i/src/SIMH/PDP8/pdp8_pt.c are both essentially this:

sim_activate (&ptr_unit, ptr_unit.wait);

where ptr_unit.wait is declared earlier on line 112 to be the value 24. According to my calculations (which could easily be wrong), a more appropriate value to simulate an optical PTR: running at 1200 characters per second would be about 350.

Anyway, the root of the problem I was trying to solve was not PTR: going too fast after all. The problem had to do with the on-disk file format of *.pt files. I will post the details in the PiDP-8/i forum as they are relevant there and not here.

So thanks again for the info that enabled me to figure out the root problem. I appreciate it.

-- steve

[Neal G.]

On Friday, December 13, 2019 at 8:32:06 AM UTC-6, Rene Richarz wrote:

I will need a modified RSX11 image with the corresponding device driver enabled (could you make that, Neal?) and the proper attach command for it, including the device name in RSX11. As far as I can see you cannot have both drivers being activated at the same time because they appear to use the same vectors.

 

Here's a link to a folder with a simplified RSX11M+ image.

https://drive.google.com/drive/folders/1aGznjJE6uMQIsMI6DL6XioSSF6_ERqLv?usp=sharing

The archive contains the RA81 disk with RSX11M+, a SimH .ini to configure and boot the system and an initialized DECTape for the TU56.

The image is similar to the PiDP-11 RSX image having System/System and User/User accounts.

The User account automatically sets the DCL command interpreter.

The console and System account default to the MCR command interpreter, so for conveniene it is helpful to use the command Johnny mentioned,

SET /DCL=TI:

to use the slightly more modern and free-form DCL commands.

The command sequence to use the TU56 are the same as the TU58, just replace DD0: with DT0:

And when at the SimH prompt refer to "tc0" instead of "tdc0"

Yes, RSX is a little strange, but those were strange times as many of the now common-place operating system and UI concepts were still evolving. It is intriguing to see trace the similarity and changes from PDP-8 OS/8 to PDP-11 RSX to VAX/VMS then compare them with something really weird CDC NOS :)

Once you get the system up and running, I can give you some more commands to exercise the TU56; such as sending the listing and map files to the TU56 as a program is being compiled and linked.

-  Neal G.

[Johnny Billquist]

On 2019-12-13 15:32, Rene Richarz wrote:
>
>
> On Friday, December 13, 2019 at 2:42:27 PM UTC+1, Johnny Billquist wrote:
>
> But maybe you should switch to DCL since that is a little more human
> friendly...
>
> SET /DCL=TI:
>
>
> Thanks, Johnny,

MCR is, for most people, a very weird experience. Its syntax and command
names are almost as bad as Unix. It's rather efficient to use when you
know it, but it's not something I'd recommend anyone to use.

DEC came up with DCL for a reason. :-)

> That does the job. I'm now all set to analyze and modify the tdc driver
> (TU58) driver to save the status bits so that my TU56 front panel can
> read them.
>
> IMPORTANT - WHICH DRIVER TO MODIFY (TU58 or TU56)?

The TU58 is called DECtape II, but most people, even back then, was of
the opinion that it was not related to DECtape at all, and should not
have been named anything with DECtape in the first place.
The DECtape II connects via a serial port, uses small cardridges, and is
slower than molass.

I suggest you don't mix the two up. Continue playing with DECtape, and
forget the TU58.

> Before starting, I would like to ask the RSX11 users in this group,
> whether they prefer to operate with the TU58 driver running the TU56
> front panel, or the TU56 driver.

See above.

> If the group prefers the TU56 driver, I will need a modified RSX11 image
> with the corresponding device driver enabled (could you make that,
> Neal?) and the proper attach command for it, including the device name
> in RSX11. As far as I can see you cannot have both drivers being
> activated at the same time because they appear to use the same vectors.

That just becomes a question of changing the vector of one of them then.
Vectors are not holy (nor are CSR addresses). You can change these
around as much as you want to (with the possible restriction that simh
might not allow you to, which I have hit in the past).

> I haven't yet looked into the timing of these 2 drivers. For the front
> panel to look right,
> it will in any case be necessary to have reasonable realistic timing.

As said above, the TU58 is a completely different story, with a
completely different timing, and visual, if you want to emulate it...

Johnny

[Rene Richarz]

I have finished the slightly modified drivers required in SimH to talk to my TU 56 front panel emulation. The following drivers are now available:

- a DECtape driver for the PiDP-8

- a DECtape driver for the PiDP-11

- a magtape driver for the PiDP-11 (for the various Unix systems, which cannot talk to a DECtape driver)

The tu56 program and these drivers are all in my github repo

  https://github.com/rricharz/Tu56

Questions, critical comments and suggestions for improvements are very welcome.

Have fun!

Rene

[Johnny Billquist]

Seems silly to have a DECtape front panel emulation for a magtape. :-)
Why don't you make a front panel emulation of a magtape as well, for
that one? Although that might be more tricky, since it then becomes a
question of what drive to emulate. And there are many more moving parts
and things going on on a magtape. Although, it would also be way cooler,
if you actually got it working right. Emulate a TU77 would be a very
nice thing, with a transparent door...

[Rene Richarz]

On Saturday, December 14, 2019 at 4:27:27 PM UTC+1, Johnny Billquist wrote:

Seems silly to have a DECtape front panel emulation for a magtape. :-)

Yes and no. In fact I have received conformation that the DECtape drives were actually used on some of the historical Unix systems, but in a mode which

just simulated a magtape. The drives were available and used for backup and data transfer. And handling from a software point of view was exactly like "tar".

But of course if there is enough interest I could also make a TU77 front panel. I will have a look at some youtube videos of TU77 tapes in action. It will be more difficult because the reel speed is most likely much slower than on the TU56. Also, you might need to mount your screen vertically :).

Let’s now just see whether PiDP-8 and PiDP-11 users are interested in tape front panel emulators.

What I’m looking forward is somebody’s video of a PiDP-8 booting from and running off the simulated DECtape. Unfortunately I do not have a PiDP-8 to make such a video myself.

Rene

[Johnny Billquist]

On 2019-12-14 16:48, Rene Richarz wrote:
>
>
> On Saturday, December 14, 2019 at 4:27:27 PM UTC+1, Johnny Billquist wrote:
>
> Seems silly to have a DECtape front panel emulation for a magtape. :-)
>
>
> Yes and no. In fact I have received conformation that the DECtape drives
> were actually used on some of the historical Unix systems, but in a mode
> which
> just simulated a magtape. The drives were available and used for backup
> and data transfer. And handling from a software point of view was
> exactly like "tar".

No, it don't, because it can't. Yes, Historical Unix system used
DECtapes. But they never used them like a magtape, because it is
impossible. They used them like a floppy.

tar is perfectly capable of also using a floppy as a destination.

> But of course if there is enough interest I could also make a TU77 front
> panel. I will have a look at some youtube videos of TU77 tapes in
> action. It will be more difficult because the reel speed is most likely
> much slower than on the TU56. Also, you might need to mount your screen
> vertically :).

Reel speed can actually be pretty high. But it is way more complicated,
because wheel speed is only indirectly related to tape read/write
operations. And wheel speed can run at a lot different speeds, which are
totally independent of read/write operations. :-)

> Let’s now just see whether PiDP-8 and PiDP-11 users are interested in
> tape front panel emulators.
>
> What I’m looking forward is somebody’s video of a PiDP-8 booting from
> and running off the simulated DECtape. Unfortunately I do not have a
> PiDP-8 to make such a video myself.

I'm sure it will come in short order.

[Neal G.]

On Saturday, December 14, 2019 at 9:48:43 AM UTC-6, Rene Richarz wrote:

But of course if there is enough interest I could also make a TU77 front panel.

A TU77 or TU45 front panel would excellent. That RSX11 test image is configured with 2 TU45s.

If you want to try them out; in SimH they are referenced as "tu0" and "tu1"; and in RSX11 they are "mm0:" and "mm1:"

As Johnny noted creating a visual simulation would be a challenge. There are several mechanical systems involved; left and right reel motion, left and right tape column motion, and the capstan motion which actually moves the tape and is the only motion directly tied to read/write activity. There are also special, tape load and tape unload, operations; which were a significant part of the routine use of these vaccuum column tape drives.

[Johnny Billquist]

Just to make things clear. If you have configured RSX with two TU45
drives, it also works with TU77. They are the same from RSX point of
view. All massbus tape drives which use the TM03 formatter are the same.
That means the TE16, TU16, TU45 and TU77. RSX will tell which specific
drive you have, but it's the same device driver for all of them.

The only massbus tape drive I know differs is the TU78.

Johnny

[Rene Richarz]

BOOTING RT-11 FROM A TU56 DECtape drive

====================================

There is a youtube video of a PDP-11 booting a minimal RT-11 from a DECtape drive, see https://youtu.be/ZGBS8mBAfYo

I would like to try that with my PiDP-11 and my tu56 front panel emulator. I understand that it will be very slow. Does anybody have such a bootable TU56 image and a boot.ini file which I could use?

EMULATING A TU77, TU45 OR OTHER VACUUM COLUMN MAGTAPE DRIVE

=============================================================

As far as I understand these drives operate with the front door closed  and one can really only see part of the reels during operation. That makes them much less interesting for a front panel emulation as compared to the TU56, but would make a decent emulation feasible. I think I understand the details of calculating reel rotation speed. Furthermore I haven't found any good high resolution pictures of such drives on the net, nor any youtube videos demonstrating such a drive in action. Obtaining high quality pictures would be the first roadblock to overcome if one would want to make such a front panel emulator.

[Neil Higgins]

It booted RT-11 (?) faster than my PC boots Windows 10. Should I be worried?

[Johnny Billquist]

On 2019-12-15 08:20, Rene Richarz wrote:
>
> EMULATING A TU77, TU45 OR OTHER VACUUM COLUMN MAGTAPE DRIVE
> =============================================================
>
> As far as I understand these drives operate with the front door closed
>  and one can really only see part of the reels during operation. That
> makes them much less interesting for a front panel emulation as compared
> to the TU56, but would make a decent emulation feasible. I think I
> understand the details of calculating reel rotation speed. Furthermore I
> haven't found any good high resolution pictures of such drives on the
> net, nor any youtube videos demonstrating such a drive in action.
> Obtaining high quality pictures would be the first roadblock to overcome
> if one would want to make such a front panel emulator.

That's why I said "with a transparent door". :-)
Normally you'll see the reels, but you don't see the vacuum colons.
But the vacuum colons are really cool.

https://www.flickr.com/photos/anachrocomputer/322320527/in/photostream/
gives a good start. Not sure it's at a high enough resolution, though.
And there is no tape mounted...

Johnny

[Rene Richarz]

This is in my opinion the most impressive video I have seen on youtube showing a vacuum column magnetic tape drive in action, in this case the IBM 729, a very impressive piece of mechanical and electrical engineering! Most of you have probably seen it.

  https://youtu.be/7Lh4CMz_Z6M

Look at those vacuum columns in operation, and the electrical connectors, for example!

I wish something like that would be available for the TU45 or TU77, but I think it cannot be made because the front door had to be closed for the proper flow of the tape.

To make a on-screen front panel emulation, one would need a video like this showing the tape drive and vacuum columns in action, and a well illuminated high resolution picture taken in the center axis of the drive and with a horizontal resolution of at least 1000 dots (drive only, excluding background). And it would be an extremely demanding simulation, most likely exceeding my capabilities.

[andy]

excellent video Rene, thx for sharing!

Andy

[Boris Bokowski]

If you ever have the chance to visit the Computer History Museum in Mountain View, CA (where the video was taken), check beforehand whether there's a live demo you can attend. I recently went on a Saturday and got to see the IBM 360 in action - with the tape drives, the printer, a card punch and the card reader. Very impressive!

Boris

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/29694f1c-585f-4fbd-a9eb-f137ad323ca5%40googlegroups.com.

[Stephen Casner]

On Mon, 16 Dec 2019, Boris Bokowski wrote:

> If you ever have the chance to visit the Computer History Museum in
> Mountain View, CA (where the video was taken), check beforehand whether
> there's a live demo you can attend. I recently went on a Saturday and got
> to see the IBM 360 in action - with the tape drives, the printer, a card
> punch and the card reader. Very impressive!

The computer in the video with the tape drives is an IBM 1401 which is
significantly older than the 360. There are two 1401s in that room.
AFAIK the museum does not have an operational IBM 360. In addition to
the 1401s there is an operational PDP-1, and I was part of the team
that did the museum's first restoration 15 years ago of an IBM 1620.
Sadly, that machine is in storage and no longer operating.

-- Steve

[Boris Bokowski]

Oops, yes, IBM 1401, apologies for the confusion.

[Johnny Billquist]

On 2019-12-16 09:47, Rene Richarz wrote:
> This is in my opinion the most impressive video I have seen on youtube
> showing a vacuum column magnetic tape drive in action, in this case the
> IBM 729, a very impressive piece of mechanical and electrical
> engineering! Most of you have probably seen it.
>
>   https://youtu.be/7Lh4CMz_Z6M
>
> Look at those vacuum columns in operation, and the electrical
> connectors, for example!

Very cool. And mechanically way more complicated than a TU77.

However, in other ways, the TU77 is more impressive. The TU77 don't just
have one switch at each end of the column. Instead it's something like
10 switches in there that sense how much tape is in the column, and the
motors can run at various speeds, in order to keep it close to the
center point.

The IBM 729 runs the tape past the heads at 75 ips. The TU77 runs the
tape at 125 ips.

> I wish something like that would be available for the TU45 or TU77, but
> I think it cannot be made because the front door had to be closed for
> the proper flow of the tape.

Actually not. The TU77 can run perfectly fine with the door open. There
is a safety switch that checks that the door is closed, but you can just
jam it and run with the door open. It's just to keep fingers out of
harms way.

The vacuum colons are protected by a second inner door, which have
transparent parts, so you can see the tape in operation.

> To make a on-screen front panel emulation, one would need a video like
> this showing the tape drive and vacuum columns in action, and a well
> illuminated high resolution picture taken in the center axis of the
> drive and with a horizontal resolution of at least 1000 dots (drive
> only, excluding background). And it would be an extremely demanding
> simulation, most likely exceeding my capabilities.

Definitely a challenge to do the simulation, I agree. But it would be
cool. :-)

[Rene Richarz]

WHEEL MOTION AND SWITCH SOUND ON TU56 EMULATOR

Version 0.3 of tu56 has added sounds on the on-screen front panel simulation of the TU 56 DECtape drive.

USING THE TU56 SIMULATION WITH HISTORICAL UNIX SYSTEMS

What remained was to clean up the use of the DECtape drive with the historical Unix systems.

It has been confirmed by Bob Eager that DECtape was used with historical Unix systems such as system 6, using the "tp" command. This command is also available in 2.11 BSD and is partly functional.

From "man 5 tp" on 2.11 BSD:

    Tp dumps files to and extracts files from DECtape and

  magtape.  The formats of these tapes are THE SAME except

  that magtapes have larger directories.

  ...

  Blocks 1 through 24 for DECtape (1 through 62 for magtape)

  contain a directory of the tape.

  ...

And from "man tp"

  ...

  The following characters may be used in addition to the

  letter which selects the function desired.

  m         Specifies magtape as opposed to DECtape.

  ...

Magtapes can be addressed with /dev/rmt? and /dev/nrmt?, where ? is the unit number, addressing the magtape hardware.

DECtapes can be addressed with /dev/tape?, addressing the DECtape hardware.

Unfortunately there is no DECtape support in the current 2.11 BSD kernel used on the PiDP-11, but addressing a Magtape with "tp" works properly, for example to write a file:

tp cvmf /dev/rmt0 filename

To list the directory:

tp tmf /dev/rmt0

and to read a file

tp xmf /dev/rmt0

There is a warning when writing the first time to a new tape:

  Warning: cannot read prototype boot block.

where it obviously cannot find a prototype boot block to write in the first block on the tape. This warning can be ignored, because we do not want to boot from tape.

Form "man 5 tp":

   Block zero contains a copy of a stand-alone bootstrap pro-

     gram.  See reboot(8).

According to "man 5 tp" the format as seen from Unix on the tape is exactly the same as if it would be on DECtape, except the number of directory blocks which is 64 on a Magtape and 32 on a DECtape.

I think therefore, that using the "m" option and the device "/dev/rmt0" for "magtape device" is therefore a good approximation of using DECtapes on historical Unix systems with tu56. Ideally, it would of course be possible to put the support for the DECtape back into the kernel, so that "/dev/tape0" and "mt" in the DECtape mode could be used again. This would have the added benefit that one could use the "d" option in "tp" and erase individual files from the tape, which is not possible using the "m" option.

[Johnny Billquist]

On 2019-12-17 08:18, Rene Richarz wrote:
> WHEEL MOTION AND SWITCH SOUND ON TU56 EMULATOR
>
> Version 0.3 of tu56 has added sounds on the on-screen front panel
> simulation of the TU 56 DECtape drive.
>
> USING THE TU56 SIMULATION WITH HISTORICAL UNIX SYSTEMS
>
> What remained was to clean up the use of the DECtape drive with the
> historical Unix systems.
>
> It has been confirmed by Bob Eager that DECtape was used with historical
> Unix systems such as system 6, using the "tp" command. This command is
> also available in 2.11 BSD and is partly functional.

I wasn't even aware that this had been questioned. :-)

> From "man 5 tp" on 2.11 BSD:
>

> Tpdumps files to and extracts files from DECtape and

>
>   magtape.  The formats of these tapes are THE SAME except
>
>   that magtapes have larger directories.
>
>   ...
>
>   Blocks 1 through 24 for DECtape (1 through 62 for magtape)
>
>   contain a directory of the tape.
>
>   ...
>
>
> And from "man tp"
>
>
>   ...
>
>   The following characters may be used in addition to the
>
>   letter which selects the function desired.
>
>
>   m         Specifies magtape as opposed to DECtape.
>
>   ...
>
>
> Magtapes can be addressed with /dev/rmt? and /dev/nrmt?, where ? is the
> unit number, addressing the magtape hardware.
>
> DECtapes can be addressed with /dev/tape?, addressing the DECtape hardware.

Yes. Nothing new about that. Just as a floppy would be /dev/floppy? or
something like that.

No. A magtape is never a good approximation for DECtape.
The 'd' option to delete individual files only works on DECtape, and not
magtape, for the simple reason that they are not even close to equivalent.

[Geoffrey McDermott]

The primary reason that you can't delete a block on a mag tape is that
the data size, and therefor the length of the block can be almost any
size (there's an upper limit, but it's based on the design of whatever
controller is used) for each block. On the DECtape, it sort of emulates
a disk in that the block sizes are fixed.

[Johnny Billquist]

Actually, it is more than the just the variable length of records.
On DECtape, there is a clock track, which is always read, both for reads
and writes, and which guarantees that any rewrite overwrites the actual
same data. With a magtape, even if you rewrite a block with the same
size, it does not necessarily mean that it will take the same size on
the tape, so any tape subsequent record might be partially overwritten,
if you overwrite an existing block with something with the same size.
Or, the old, overwritten data, might still have the tail part still on
the tape making any subsequent reads totally messed up. Essentially,
whenever writing to a magtape, that has to be considered the logical end
of the tape.

So, append only.

[Steve Tockey]

In case anybody might happen to care, the reason for the clock track(s) on DecTape is that the take-up reel always runs at a constant speed. The take-from reel always tries to go slower to maintain tape tension. The challenge is that the tape moves noticeably faster over the read-write head when the take-up reel is nearly full than when it is nearly empty. So data track reading and writing is synchronized through the timing track(s).

On traditional tape drives, the tape moves at a constant speed over the read-write head as driven by the capstan so there is less (or no) need for timing tracks. But, reel drive motor control logic gets complex as a result.

The control logic in a DecTape unit is much simpler than in traditional tape drives.

Formatting a DecTape involves writing block boundary markers, timing tracks, and end-of-tape zones so the drive control logic can figure out where it is on the tape.

[Johnny Billquist]

But that is not the whole point. Yes, the tape speed over the heads
vary, and yes, it allows for a simpler mechanical design.

However, even if they had done the full monty of normal magtape, and
used fixed size blocks, without clock, you'd not be able to rewrite data
reliably. That is the second, and maybe even more important point of the
clock track.

It means that you really can rewrite blocks anywhere on the tape
reliably, without affecting anything else on the tape, before or after
the stuff you write. Which means, in the end, that it acts the same way
a disk does, and not like a tape does.

There were, over the years, various attempts at using normal tape drives
in a similar manner, but it just never worked that well, since there is
no proper control over the write, so that it properly could overwrite
old data and continue having all other data stay around.

There are several issues. One is that one drive might not run at exactly
the same speed as another drive. Another is that the inter-block gap can
actually be of different lengths, and even on the same tape drive, there
are commonly two different gap lengths that the drive might create,
depending on whether it is streaming, or in start-stop mode. The
inter-block gap can then be either a short or a long one. Programs don't
have any control over this, but obviously it is absolutely critical if
you are going to try and overwrite an existing block. And of course,
these kind of timings drift with age of components, and so on.

So, the clock track is what makes the DECtape a DECtape, and gives it
all the properties that makes it special. Along with the fixed length
blocks, and the meta-data that exists for every block. It really isn't a
tape, from the traditional point of how tape drives work. It works like
a disk, just a rather slow one, especially if we talk about seeks.

[Stephen Casner]

On Sat, 14 Dec 2019, Johnny Billquist wrote:

> The TU58 is called DECtape II, but most people, even back then, was of the
> opinion that it was not related to DECtape at all, and should not have been
> named anything with DECtape in the first place.
> The DECtape II connects via a serial port, uses small cardridges, and is
> slower than molass.
>
> I suggest you don't mix the two up. Continue playing with DECtape, and forget
> the TU58.

In the early 1980s I worked on a project that implemented a
specialized network router on dedicated 11/44 systems with no disk,
only TU58. The idea was that once the system was booted up and
running, no disk would be needed, so the managers wanted to avoid the
cost. For the developers, though, it was painful.

The code ran on our own real-time operating system, EPOS, that used a
Unix v6 filesystem on disks and on the TU58 tape. We carefully
crafted the initial sequence of filesystem blocks on the tape to hold
directories, inodes and file contents in the optimal order to minimize
the amount of seeking required.

-- Steve

[Rene Richarz]

There are now minimal instructions on how to use the tu56 DECtape on-screen emulator on 2.11 BSD, RSX11 and the PiDP-8 in the Tu56 GitHub repo (thanks to Neal G. and Warren Young). If you can help to improve these instructions or add additional instructions for other operating systems your help and all constructive remarks are very much appreciated. You can post these here or send them to me directly (email address in the repo).

I hope that tu56 turns out to be a nice addition to your PiDP-11 or PiDP-8 experience. I made it for those of us who do not own a working TU 56, but would still like to recreate the past experience.  Sorry for the very few compromises which do not please everybody but were required to make it work.

[Rene Richarz]

After fixing a nasty timing bug, tu56 can now also properly simulate a bootup from DECtape on the PiDP-8.

  https://youtu.be/FxtvWlFUPO0

Sorry for not having seen this bug earlier. There is also a video demonstrating the copy of files from unit 1 to unit 0 of the TU 56 on the PiDP-11:

  https://youtu.be/Ue-wMTntcZg

[Rene Richarz]

I have started to make a feasibility study of making a TU77 on-screen magnetic tape emulator similar to the TU56 Dectape emulator (tu56). I think that a simple physics model of the reel rotational motion and the tape position in the vacuum columns is possible.

The most difficult part, in my opinion, is to show the reels in realistic motion.  The current plan is to

1. Compose the picture from 2 reel pictures, one full of tape and one empty, with the calculated current radius of the tape on the reel as the cutoff line.

2. Rotate the picture by an angle calculated in the physics model.

3. If the reel it is currently moving, start with blurred pictures in step 1.

Enclosed is a picture of a reel with tape as an example, but I need either a picture of a completely opaque reel, or two identical pictures of the same reel, full and empty of tape. The pictures need to be taken from the axis of the reel, so that they can be rotated without perspective distortions. Lighting is also an issue. The trace of lighting in the enclosed picture from top to bottom is less than ideal when the reel is rotated.

Any help is appreciated, especially if you are aware of or have pictures of opaque reels which were used in the TU77.

[Johnny Billquist]

You need to think about how to do the reels at various different speeds.
And of course this is then related to where the tape loop is in the
vacuum colon. But the tape position in the vacuum colon is then also
affected by actual read/write or other tape motion from the controller.

So it ends up something like this:

Loading mght be easiest to just fake at the start, since that is a
rather special case.

1) When a block is read or written, move up the loop of the in column by
the amount of data. Or by approximate length of tape, if skipping. This
movement is at constant speed always. And is really fast. Move the out
column tape loop by the same amount, but the opposite direction to the
in column.

2) In the in column, if tape moves up more than some delta from neutral,
start feed wheel at slow speed to move more tape into the column. If
delta from center becomes bigger, increase wheel speed. On the real
drive, the speed increments are at discrete steps, based on how many
switches gets exposed to vacuum or not. I don't remember exactly how
many switches, and thus steps, there are. But that should be obvious in
the documentation, if you want to really match the real drive closely.

3) Same as 2, but if tape moves down, then move the wheel the other way
to take tape out of the column back to the reel.

4) Same as 2, but for out column.

5) Same as 3, but for out column.

And that's it. :-)

Johnny

On 2019-12-22 11:12, Rene Richarz wrote:
> I have started to make a feasibility study of making a TU77 on-screen
> magnetic tape emulator similar to the TU56 Dectape emulator (tu56). I
> think that a simple physics model of the reel rotational motion and the
> tape position in the vacuum columns is possible.
>
> The most difficult part, in my opinion, is to show the reels in
> realistic motion.  The current plan is to
>
> 1. Compose the picture from 2 reel pictures, one full of tape and one
> empty, with the calculated current radius of the tape on the reel as the
> cutoff line.
>
> 2. Rotate the picture by an angle calculated in the physics model.
>
> 3. If the reel it is currently moving, start with blurred pictures in
> step 1.
>

> tape2.jpg
>
>
> Enclosed is a picture of a reel with tape as an example, but I need
> either a picture of a completely opaque reel, or two identical pictures
> of the same reel, full and empty of tape. The pictures need to be taken
> from the axis of the reel, so that they can be rotated without
> perspective distortions. Lighting is also an issue. The trace of
> lighting in the enclosed picture from top to bottom is less than ideal
> when the reel is rotated.
>
> Any help is appreciated, especially if you are aware of or have pictures
> of opaque reels which were used in the TU77.
>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/0d2edece-6d73-4a35-afc1-09b16b1b2951%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/0d2edece-6d73-4a35-afc1-09b16b1b2951%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Jonathan Morton]

> On 22 Dec, 2019, at 12:12 pm, Rene Richarz <rene.r...@bluewin.ch> wrote:
>
> Enclosed is a picture of a reel with tape as an example, but I need either a picture of a completely opaque reel, or two identical pictures of the same reel, full and empty of tape. The pictures need to be taken from the axis of the reel, so that they can be rotated without perspective distortions. Lighting is also an issue. The trace of lighting in the enclosed picture from top to bottom is less than ideal when the reel is rotated.

I think you can simplify the photographic requirements by separating the wound tape graphic from the reel graphic entirely. The spinning tape will look the same as when stationary, including lighting, and only the reel needs to be rotated (and blurred).

This does mean you need three graphics: an empty reel, an overlay of the transparent reel cover (perhaps on a greenscreen backing to permit generation of an alpha channel), and the wound tape with the transparent cover and reel hub removed. A variable radius of the latter would be shown sandwiched between the other two.

Because the reels on this drive can spin at different speeds depending on the amount of tape in the column, you'll need to blur the hub and cover graphics by several amounts corresponding to those speeds and the expected framerate of the emulation - say 60fps if you need to assume just one framerate. This should be reasonably straightforward to do programmatically. I think it's reasonable to assume the reels don't need to accelerate through less than a full speed step per frame, which I'm sure will simplify your simulation.

- Jonathan Morton

[Rene Richarz]

On Sunday, December 22, 2019 at 11:39:29 AM UTC+1, Johnny Billquist wrote:

2) In the in column, if tape moves up more than some delta from neutral,
start feed wheel at slow speed to move more tape into the column. If
delta from center becomes bigger, increase wheel speed. On the real
drive, the speed increments are at discrete steps, based on how many
switches gets exposed to vacuum or not. I don't remember exactly how
many switches, and thus steps, there are. But that should be obvious in
the documentation, if you want to really match the real drive closely.

Below is one of the excellent pictures Henk already made of his TU77 for me. As far as I can see there are lots of holes. I will therefore start my physics model with a reel acceleration/speed based on delta in the vacuum column, no steps. And capstan speed just on/off. But I'm a physicist after all. So if it has to be more complicated, no big deal. And even a fairly complex physics model will take much less computational time than composing the picture of the large high resolution reels.

As I said above, showing the reels properly is probably more difficult.

[Rene Richarz]

Sorry for yet another bag of questions regarding the TU77. If there would be a video of a running TU77, I could read whatever I need from slow motion and still pictures. But because I have not found a video nor am I aware of a fully functional unit anywhere, I'm relying on specifications and the memory of users.

From the user manual I get some relevant information:

Tape speed 3.2 m/s (125 ips)

Rewind time for 731.5 m (2400 ft) tape 65 s

Tape density 1600 or 800 bpi

Start and stop time: 3 ms

Start distance 4.2 mm (0.166 in)

Stop distance 5.0 mm (0.195 in)

The acceleration and deceleration of the reels I can guess from the amount of tape which could be stored in a vacuum column. One would assume that the vacuum columns were long enough.

But I'm missing a few very important parameters:

1) Minimum and maximum bits stored in one read or write operation at 125 ips (blocksize?). From this I could calculate minimum and maximum time of the capstan running at 125 ips.

2) Minimum elapsed time between 2 individual read or write operation at 125 ips

3) Does 1) also apply for seeks, or would the tape just keep running over multiple blocks/files at 125 ips?

[Johnny Billquist]

Hi...

On 2019-12-22 14:35, Rene Richarz wrote:
> Sorry for yet another bag of questions regarding the TU77. If there
> would be a video of a running TU77, I could read whatever I need from
> slow motion and still pictures. But because I have not found a video nor
> am I aware of a fully functional unit anywhere, I'm relying on
> specifications and the memory of users.

I really enjoy these questions. And I might eventually also be able to
provide a video of an operational TU77. Update have two of them, which
we can hook up to Magica, which is the 11/70 we keep running.
Last we ran them, though, I remember there being some kind of problem
with each of the drive. But my plan is to look at that this summer, and
try to get one back operational.

There might be others who actually have one running today - I don't know...

> From the user manual I get some relevant information:
>
> Tape speed 3.2 m/s (125 ips)
> Rewind time for 731.5 m (2400 ft) tape 65 s
> Tape density 1600 or 800 bpi
> Start and stop time: 3 ms
> Start distance 4.2 mm (0.166 in)
> Stop distance 5.0 mm (0.195 in)
>
> The acceleration and deceleration of the reels I can guess from the
> amount of tape which could be stored in a vacuum column. One would
> assume that the vacuum columns were long enough.

Yes. They are. And yes, just computing the time to fill half the column,
at half the speed at the capstan will tell you a worst case acceleration
of a reel. Mind you, they probably can operate a bit faster than that,
as you want to have some margins...

> But I'm missing a few very important parameters:
>
> 1) Minimum and maximum bits stored in one read or write operation at 125
> ips (blocksize?). From this I could calculate minimum and maximum time
> of the capstan running at 125 ips.

That is not a parameter of the drive, but the controller, as well as
standards for magtapes.
On a PDP-11, I think the specified minimum block size is 14 bytes, while
the maximum block size is 65536 bytes. Any number in between can occur.
Multiply by 8 to get bits, but then again, the TU77 have 9 tracks so you
have one additional parity bit. But for both 800 and 1600 bpi, you
essentially have one byte per "row". At 6250 bpi, I think the encoding
is more complicated... But the TU77 don't have that density. For that
you need the TU78.

> 2) Minimum elapsed time between 2 individual read or write operation at
> 125 ips

That is not defined in time, but the standard have some information
about the minimum length of an inter-block gap.
As far as I can remember, the tape drives might end up with essentially
two different sizes of these gaps, depending on tape drive.

I can research this in more detail later. Maybe tonight...

> 3) Does 1) also apply for seeks, or would the tape just keep running
> over multiple blocks/files at 125 ips?

Seeks are just a question of searching a specific number of blocks or
tape marks forward or reverse. So the controller is essentially just
asking the tape drive to move to the next block or tape mark over and
over again until the count is up. This is usually actually done in the
formatter, and not even the controller, so it happens pretty close to
the drive, so it is just running the tape at 125 ips across the heads
the whole time until the right place is found.

Johnny

[Jonathan Morton]

> On 22 Dec, 2019, at 4:27 pm, Johnny Billquist <b...@softjar.se> wrote:
>
> …so it is just running the tape at 125 ips across the heads the whole time until the right place is found.

Except in fast-rewind mode. The specs imply an average tape speed of about 11.25 m/s, substantially faster than the normal read/write speed, so this is evidently done directly reel-to-reel rather than through the capstan motor, most likely with the head unloaded and the vacuum columns completely taken up first (as the IBM tape drive demonstrates).

But of course fast-rewind mode is used only to find the very start of the tape, not any particular block in the middle.

- Jonathan Morton

[Johnny Billquist]

On 2019-12-22 15:35, Jonathan Morton wrote:
>> On 22 Dec, 2019, at 4:27 pm, Johnny Billquist <b...@softjar.se> wrote:
>>
>> …so it is just running the tape at 125 ips across the heads the whole time until the right place is found.
>
> Except in fast-rewind mode. The specs imply an average tape speed of about 11.25 m/s, substantially faster than the normal read/write speed, so this is evidently done directly reel-to-reel rather than through the capstan motor, most likely with the head unloaded and the vacuum columns completely taken up first (as the IBM tape drive demonstrates).

Right. Fast rewinding is running at a higher speed.
But it's still done through the vacuum colons, and over the capstan
motor. There is no way of unloading the heads, or avoiding the whole
assembly of rollers. They are all fixed in place, and the tape always
runs by them.

Someone should probably look at the drive documentation to see some kind
of description how it is done, as this is a rather special mode of the
drive.

Same story with actual load or unload, which I also avoided touching
yet. That is done in a special way also.

> But of course fast-rewind mode is used only to find the very start of the tape, not any particular block in the middle.

Right. No actual reading is taking place. The tape is rewound until the
BOT optical marker is found.

[Rene Richarz]

Here is a little Xmas present for the PiDP-11 user group:

The result of my feasibility study for a TU77 mag tape on-screen simulator.

https://youtu.be/oVU4_1gBZU8

I'm currently using the picture of a TE16, but plan to switch to a TU77. The reel motions and the vacuum column levels are simulated at the moment. There is of course a lot more to do, but the feasibility study shows that it can be done on a Raspberry PI 4B+.

[Neal G.]

Thanks for the preview; looks good.

I noticed that the capstan wheel is stationary; but that's probably on your to-do list already.

On Wednesday, December 25, 2019 at 2:12:39 AM UTC-6, Rene Richarz wrote:

Here is a little Xmas present for the PiDP-11 user group:

The result of my feasibility study for a TU77 mag tape on-screen simulator.

...

[Charley Jones]

Beautiful work.  Nice to see the tapes flying again.  For me it’s been more than 30 years since I saw an active tape.

Sent from my iPhone Xs!

On Dec 25, 2019, at 11:30 AM, Neal G. <cven...@earthlink.net> wrote:



--

You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/f1046980-e439-4c8e-b07f-e86c3c5c7698%40googlegroups.com.

[Terry Kennedy]

On Wednesday, December 25, 2019 at 2:30:21 PM UTC-5, Neal G. wrote:

Thanks for the preview; looks good.

I noticed that the capstan wheel is stationary; but that's probably on your to-do list already.

I'm a bit late to this party, so forgive me if this has been covered...

The movement of the tape loops in the columns on real drives is pretty abrupt - all of the tape needed comes out of there until the edge of the tape passes over the first of the sensor holes, at which point the reel servo motors start feeding tape, which they do at a faster and faster rate as the tape loop gets closer and closer to coming out of the columns. Look for videos of IBM 3420 / 3422 tape drives - those have deeper columns, but I'm sure there are a lot more videos of those around.

Trivia - the main reason for the Tx78 -> Tx79 rename was that the manufacturer (Triumph Adler or some rebranding of same) wasn't getting enough business from DEC to justify a brand-specific front door. That's the reason the front door of the Tx79 has 3 rectangular dimples - it is for the IBM channel and unit number (often starting at 280) for the IBM variant. I don't think there was ever a Massbus TU79, though I did stick a TM78 formatter in one once.

IBG (inter-block gap) length is allowed a fair variety of variation. Bitsavers probably has IBM's tape format specification (probably has ANSI in the name). This is to allow drives that couldn't start / stop rapidly to have an overshoot IBG before writing the next record. Drives like the Tx77/78/79 write pretty short IRGs. Back in the day, we used something called "tape developer" (one trade name was Magnasee) which was a very volatile fluid (most likely banned today) with extremely fine magnetic particles suspended in it.You would pass a loop of tape through the can after you shook the can to agitate the particles, and when the fluid evaporated you would see the actual bits (really, flux transitions) as white spots on the tape. I don't have any pictures of tape so developed, but I did run some transit farecards through it to prove there was no difference between blue and yellow MTA farecards, and you can see the results there: https://www.glaver.org/transient/metro.jpg

If someone in the [much] greater NYC area (say, less than 400 miles or so) has a TU77/78 drive that has problems but has a system with a working Massbus interface and a place for me to stay while working on the drive, I would most likely be willing to travel at my expense to repair it. DEC Field Service used to tell people who didn't have service contracts to bring their drives to me as I could fix them for a lot less than DEC could, and they would stay fixed. Eventually (when I had 6 TU78's and 2 TU77's, all masters with formatters) that I'd fixed and was running at SPC, DEC FS started bringing their drives to me for rebuilding and would cycle a batch through every 2 weeks. This was during the "ECO wars" where applying any of the drive / formatter FCOs made things worse. Drives after I fixed them up left my shop being able to load properly-prepared tape out of an Easy-load II tape seal virtually 100% of the time, while on DEC drives (even brand new ones) this often resulted in the first few feet getting mashed up as repeated failures to load damaged the end of the tape even further.

HS Rewind on the Tx77/78/79 used the whole tape path (there was no provision for any form of eject that would eliminate the capstan), the servo control of the capstan was relinquished and it free-wheeled as the tape rolled by. Since the drive no longer needed to maintain a constant speed across the tape head, it could be pulled through as fast as the vacuum column sensors and reel servos could support.

[Rene Richarz]

Thanks to everybody for their valuable input.

On Thursday, December 26, 2019 at 1:01:03 PM UTC+1, Terry Kennedy wrote:

The movement of the tape loops in the columns on real drives is pretty abrupt - all of the tape needed comes out of there until the edge of the tape passes over the first of the sensor holes, at which point the reel servo motors start feeding tape, which they do at a faster and faster rate as the tape loop gets closer and closer to coming out of the columns.

Terry,

Your input is very important. My goal is to make an on-screen front panel emulator of the TU77. As far as I can see the TU77 has lots of holes to measure the position of the tape in the vacuum column quite accurately. I think therefore that the tape movements in the column were probably not as abrupt as on some other drives with less precise position measurements. The spec says that the capstan went from zero to full speed in 3 ms. Based on the length of the columns my estimate is that the reels took up to 200 ms to come to speed. The simulation calculates a new frame around every 40 ms (the exact current frame rate is used in the physics model). Therefore, the acceleration of the reels is well visible, whereas the capstan just jumps from zero to full speed.

I have now implemented the physics model, the capstan motion, the changing tape radius, and the rewind. I can now see very well how

- the radius of the tape changes more if there is less tape on the reel

- the reel rotates faster and takes longer to accelerate if there is less tape on the reel

- the reels lag behind the capstan, with the reel with less tape lagging more due to the higher speed

while the PiDP-11 is writing a bunch of files of different lengths onto the tape.

Once I get a good image of the TU77, I will switch the simulation to the TU77, because I am using the TU77 specs and physics. When this is done, I will publish a new video on youtube. 

I don't think anymore that the inter-block gap is of any relevance for my emulator. SimH just pushes multiple blocks of a file without any noticeable time gap, the capstan wouldn't stop anyway, and the next block write would most likely start before the 40 ms of the current frame period is over.

Thanks again for your input

Rene

[Terry Kennedy]

On Thursday, December 26, 2019 at 9:55:32 AM UTC-5, Rene Richarz wrote:

My goal is to make an on-screen front panel emulator of the TU77. As far as I can see the TU77 has lots of holes to measure the position of the tape in the vacuum column quite accurately. I think therefore that the tape movements in the column were probably not as abrupt as on some other drives with less precise position measurements. The spec says that the capstan went from zero to full speed in 3 ms. Based on the length of the columns my estimate is that the reels took up to 200 ms to come to speed. The simulation calculates a new frame around every 40 ms (the exact current frame rate is used in the physics model). Therefore, the acceleration of the reels is well visible, whereas the capstan just jumps from zero to full speed.

  The capstan acceleration is so fast because the tape needs to be moving at the correct constant speed by the time the tape has moved out of the IBG (see, there it is again!) and into the start of the next block of data. While it is true that the tape formats are self-clocking, write performance needs to be tightly controlled in order to meet the ANSI density specification and if the drive does that for writes, it may as well do it for reads.

  It may be informative to look back and consider tension-arm tape drives - the arms drove potentiometers which controlled the motion of the suppy and take-up reels, as there were no other sensors. There was always some drive to the reel motors to maintain tape tension, since again there weren't any vacuum columns on tension-arm drives.

  The tape loops in the vacuum columns can definitely move quite rapidly (and sometimes aggressively). All of the sounds you get from one of these drives, beyond the constant blower noise, is from the loops moving the columns. This can be anything from a slow "brup-brup" type noise when writing 64K records intermittently to a constant high-pitched buzzing when writing small (80 byte card images, for example). The drive to larger record sizes came from the IBM side, where it was realized that a tape full of 80-byte records consisted mostly of IBG's with a little data every now and then. That's why the "blocking factor" (number of card images per tape block) was so important on those systems. You can see traces of that today in the Unix 'dd' utility (which even takes its name from the IBM job control card "//SYSIN DD").

I have now implemented the physics model, the capstan motion, the changing tape radius, and the rewind. I can now see very well how

- the radius of the tape changes more if there is less tape on the reel

- the reel rotates faster and takes longer to accelerate if there is less tape on the reel

- the reels lag behind the capstan, with the reel with less tape lagging more due to the higher speed

while the PiDP-11 is writing a bunch of files of different lengths onto the tape.

 

  That is excellent news!

 

Once I get a good image of the TU77, I will switch the simulation to the TU77, because I am using the TU77 specs and physics. When this is done, I will publish a new video on youtube.

   I don't remember if the LSSM has a TU77 or TU78 drive (Dave, are you on here?), but if it does I'll gladly photograph it at very high resolution the next time I'm there - I've taken pictures of the insides of their 11-750 and 11-780 systems and printed them 100% size so people can see what is inside those systems without staff needing to continually open and close the cabinets and air dams (a very bad idea on a 780 if it is running!).

 

I don't think anymore that the inter-block gap is of any relevance for my emulator. SimH just pushes multiple blocks of a file without any noticeable time gap, the capstan wouldn't stop anyway, and the next block write would most likely start before the 40 ms of the current frame period is over.

 Remember, these drives were NOT streamers like the TU80/81 - in fact, the exact opposite. Any tape read or write operation started tape motion, transferred the block, and then stopped the tape. This happened even if the formatter had the next block (for a write) or free buffer (for a read) ready - stop / start / stop. The TU78 at least (not sure about the 77) had some optimizations there (it needed to - otherwise 80-byte records at 6250 BPI would have been excruciating) to keep the capstan and reel motors "hot" and ready to move. This start-stop action is what made the sounds I mentioned above - think of the tape loop as a guitar string (although one of variable length). A steady flow of data will have the tape moving in the columns.

[Rene Richarz]

On Friday, December 27, 2019 at 5:41:19 AM UTC+1, Terry Kennedy wrote:

 Remember, these drives were NOT streamers like the TU80/81 - in fact, the exact opposite. Any tape read or write operation started tape motion, transferred the block, and then stopped the tape. This happened even if the formatter had the next block (for a write) or free buffer (for a read) ready - stop / start / stop

I uploaded a new video  https://youtu.be/8GL19xPuenI which shows the current state of the emulator. I think that it is mostly ok now, perhaps with the exception of what happens between 2 blocks. What I can see is that "tar" in BSD reports to store files in blocks (of 512 + overhead) bytes, but in the SimH magtape driver there is one large block arriving and reported to my emulator. One could probably hear something, but I do not plan at the moment to add sound to the magtape emulation. But I'm sure that one couldn't see the capstan stopping and starting again using a frame rate of approx. 25 Hz. Maybe I could fake some vacuum column position changes every 512 + overhead bytes. That would probably be visible. But then, other operating systems probably use other block sizes.

Regarding the TU77 pictures, I think that Henk Gooijen will make a picture of his open and closed drive for me. If that's not possible, I will let you know.

 

[Neal G.]

On Friday, December 27, 2019 at 4:50:10 AM UTC-6, Rene Richarz wrote:

I uploaded a new video  https://youtu.be/8GL19xPuenI which shows the current state of the emulator. I think that it is mostly ok now,

 

Mostly OK, but there seems to be some problem when tape motion stops; the takeup reel continues to spin after the capstan has stopped.

Although there would be a short motion perhaps 45 degrees to recenter the tape loop, in the video the reel makes one or two revolutions which would pull the tape entirely out of the column. Review the motion of the upper reel and capstan in the video at about 00:45 and 00:48.

One could probably hear something, but I do not plan at the moment to add sound to the magtape emulation.

 

The noise of the vacuum system overwhelms all other sounds. The door helped reduce this noise as well as providing safety from the moving parts. These tape drives were also primarily used in seperate environmentally controlled rooms where the sound could be contained. As systems began moving to the general office environments, tape drives which used a tension-arm mechanisms in place of the vacuum column became popular as they were significantly quieter.

[Johnny Billquist]

My recollection is that they could be almost singing. The constant
vacuum pump noise was always there, and loud for sure. But when it was
working, it was making more noise.

I was reading Alan's response, and it brought a smile to my face...
I wonder if I should offer him accommodation in Uppsala this summer... ;-)

[Johnny Billquist]

On 2019-12-27 11:50, Rene Richarz wrote:
>
>
> On Friday, December 27, 2019 at 5:41:19 AM UTC+1, Terry Kennedy wrote:
>
>  Remember, these drives were NOT streamers like the TU80/81 - in
> fact, the exact opposite. Any tape read or write operation started
> tape motion, transferred the block, and then stopped the tape. This
> happened even if the formatter had the next block (for a write) or
> free buffer (for a read) ready - stop / start / stop
>
>
> I uploaded a new video https://youtu.be/8GL19xPuenI which shows the
> current state of the emulator. I think that it is mostly ok now, perhaps
> with the exception of what happens between 2 blocks. What I can see is
> that "tar" in BSD reports to store files in blocks (of 512 + overhead)
> bytes, but in the SimH magtape driver there is one large block arriving
> and reported to my emulator.

Well, you didn't fully read through tar and understand what it does.
Yes, tar works on 512 byte units, called blocks, but it groups them
together. This is the blocking factor, which by default in 2.11BSD is
20. That means the normal tape block read or written is actually 10240
bytes in tar. You can change that with the -b flag, if you want to.

And I would expect that this is what you see in the end in simh... :-)

But also, there potentially some smaller tape records in there as well.
I would have to read through more code to remember exactly how file
directory information is handled, or the end of a file.

[Rene Richarz]

On Friday, December 27, 2019 at 11:42:18 PM UTC+1, Johnny Billquist wrote:

Yes, tar works on 512 byte units, called blocks, but it groups them
together. This is the blocking factor, which by default in 2.11BSD is
20. That means the normal tape block read or written is actually 10240
bytes in tar.

I forgot about that, but checked it now in the SimH driver. It does indeed cut large files into these blocks, and my emulator receives this information. Sometimes it is actually visible that the capstan stops for some milliseconds, but often it just stops and starts again within one frame (approx. 40 ms) and one doesn't see anything. The reels don't have time to come to a full stop. The question is of course, whether the reels really stopped in between 2 such blocks. If that's the case, I need to increase the interblock delay in the SimH driver to a more realistic value.

[Rene Richarz]

On Friday, December 27, 2019 at 9:36:56 PM UTC+1, Neal G. wrote:

 

Mostly OK, but there seems to be some problem when tape motion stops; the takeup reel continues to spin after the capstan has stopped.

Although there would be a short motion perhaps 45 degrees to recenter the tape loop, in the video the reel makes one or two revolutions which would pull the tape entirely out of the column. Review the motion of the upper reel and capstan in the video at about 00:45 and 00:48.

Point taken. Actually, the maximum delta in the takeup column is 260 dots. Therefore, the takeup reel should pull less than 520 dots of tape from the vacuum column after the capstan has stopped. The minimum tape radius is 100 dots, which means a circumference of 628 dots. Therefore, the empty reel should not turn more than 300°.

The tape speed on the TU77 is 320 cm/s, which amounts to 7.84 rps, or 0.127s per turn on the empty reel. During a linear deceleration phase, the average speed is 50% of the original speed. Therefore, the maximal allowed time to come to a full stop would be 0.254s.

In the last video, the actual value was a bit too large. I'm going to reduce it accordingly.

While analyzing your point, I realized another issue. During the deceleration phase, the takeup column can only give tape, because the reel will not move backwards, and the capstan does not move at all. Therefore the ending position will always be towards the end of the column. I didn't get that right in the last video, but it is easy to correct.

Thanks for your valuable input. I have corrected these issues now, but will not publish an updated video right away. The problem is that you cannot replace a video on youtube with a better one. One can only make a new video and delete the old one, but then the link to the old one is broken.

[Johnny Billquist]

I would say no. Most of the time, the reels didn't come to a full stop.
But they would by sortof varying the speed all the time.

[Lars Brinkhoff]

Rene Richarz wrote:

The result of my feasibility study for a TU77 mag tape on-screen simulator.

https://youtu.be/oVU4_1gBZU8 

Thank you, this is so delightful!

Maybe paper tape next?! :-)

[Lars Brinkhoff]

Would there be support for custom tape labels?  E.g. use a photo of some particular real tape.  I have some interesting photos.

[Rene Richarz]

On Saturday, December 28, 2019 at 2:08:03 PM UTC+1, Lars Brinkhoff wrote:

Would there be support for custom tape labels?  E.g. use a photo of some particular reel tape.  I have some interesting photos.

Good question. I have been thinking about that too. It is not trivial, because I‘m making all the required pictures at various angles and with and without blurring using gimp. This minimizes on-the fly calculations. It takes about an hour of work per reel. I don‘t know whether gimp could be scripted. Just send me pictures of your reels, and I will tell you what‘s possible.

[Rene Richarz]

Thanks to the pictures Henk Gooijen made of his TU77, the emulation of the TU77 is now also ready.

https://youtu.be/ilRWveCcB44

https://github.com/rricharz/Tu77

Have fun and all the best for a healthy 2020!

[Ville Laitinen]

Hi, i uploaded a tc11 (dectape controller) kernel driver for 211bsd to  https://github.com/vlait/211bsd-tc11

in case someone wants to play with the tu56 frontend and a real os :D

There's a preconfigured disk image for use with simh and some sparse info for installing it yourself if you so desire.

There are some example scripts included in the disk image /home/tc/tu56examples directory.

Please do not use this without backing up all your files first !! 

br,

-V

--

You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/90c7c158-5e21-4599-b8ae-d227fdfabccc%40googlegroups.com.

[Frank Wortner]

I wonder if there is a way to simulate this?  ;-)

"When a defective batch of ... new design hubs was shipped on new DECtape drives, these hubs would loosen over time. As a result, DECtape reels would fall off the drives, usually when being spun at full speed, as in an end-to-end seek. The reel of tape would fall onto the floor and roll in a straight line or circle, often unspooling and tangling the tape as it went. In spite of this horrifying spectacle, desperate users would carefully untangle that tape and wind it laboriously back onto the tape reel, then re-install it onto the hub, with a paper shim to hold the reel more tightly."

[Rene Richarz]

On Thursday, January 2, 2020 at 9:13:10 PM UTC+1, Ville Laitinen wrote:

Hi, i uploaded a tc11 (dectape controller) kernel driver for 211bsd to  https://github.com/vlait/211bsd-tc11

Very nice. It's really fun to use the DECtapes as very small disks in 2.11 BSD! And if you have the tu56 front panel emulator running, you can even observe how BSD buffers the tape drives, and writes to them after a while.

 

I have modified my boot.ini to attach 2 magtapes and 2 DECtapes during bootup, and save the DECtape buffers after a proper shutdown (see attachment). I have done the tests with your image being root, but I will put the modified kernel in my standard system and see, whether it does not cause any trouble doing the usual work, and using the DECtapes as a normal user.

The only little quirk I can see at the moment is that you have to manually unmount the DECtapes before shutting down BSD. If you don't do that, one of the DECtape drives will run forever after the shutdown. I think what happens is that the umount is done automatically during shutdown, but SimH kills the DECtape driver before it has finished simulating the umount. Probably difficult to fix in SimH. Fortunately the DECtape reel doesn't jump off the hub in this situation :-).

[ Edited:]

The little quirk described above has been fixed with a slightly modified TC driver for SimH. Make sure that you install the latest SimH TC driver from my tu56 repo. For details look at the bottom of https://github.com/rricharz/Tu56/blob/master/bsd.txt

[Ville Laitinen]

Yep, looks like the calls to sync will not flush all data and the tc gets a call to write one block just before halt.

not sure if the tape would normally stop after WDATA completes.

While trying to figure out why the fs doesn't get flushed i added autoconfig and disklabel support.

Both are really just unnecessary bloat but the kernel seems to be happier with them when using the tape as a file system. 

disk image on github is not yet updated, there is only the tar file containing changed/added files

-V

On Fri, Jan 3, 2020 at 10:56 AM Rene Richarz <rene.r...@bluewin.ch> wrote:

On Thursday, January 2, 2020 at 9:13:10 PM UTC+1, Ville Laitinen wrote:

Hi, i uploaded a tc11 (dectape controller) kernel driver for 211bsd to  https://github.com/vlait/211bsd-tc11

Very nice. It's really fun to use the DECtapes as very small disks in 2.11 BSD! And if you have the tu56 front panel emulator running, you can even observe how SimH buffers the tape drives, and writes to them after a while.

 

I have modified my boot.ini to attach 2 magtapes and 2 DECtapes during bootup, and save the DECtape buffers after a proper shutdown (see attachment). I have done the tests with your image being root, but I will put the modified kernel in my standard system and see, whether it does not cause any trouble doing the usual work, and using the DECtapes as a normal user.

The only little quirk I can see at the moment is that you have to manually unmount the DECtapes before shutting down BSD. If you don't do that, one of the DECtape drives will run forever after the shutdown. I think what happens is that the umount is done automatically during shutdown, but SimH kills the DECtape driver before it has finished simulating the umount. Probably difficult to fix in SimH. Fortunately the DECtape reel doesn't jump off the hub in this situation :-).

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/fd0cb280-9575-4365-847f-3b66b3baf53b%40googlegroups.com.

[Jonathan Morton]

> On 3 Jan, 2020, at 11:00 pm, Ville Laitinen <vlai...@gmail.com> wrote:
>
> Yep, looks like the calls to sync will not flush all data and the tc gets a call to write one block just before halt.
> not sure if the tape would normally stop after WDATA completes.

Surely even if the CPU halts, the drive controllers would still progress normally into a quiescent state? This would include stopping the tape once that final block is written.

So to handle shutdown correctly, SIMH should not exit instantly on CPU halt, but keep running until attached hardware is also quiescent.

- Jonathan Morton

[Johnny Billquist]

Ummm... Depends. I know of at least one DECtape controller, where if you
halt the machine while the tape is spinning, the tape will continue
spinning in all eternity.

[Ville Laitinen]

I'm pretty sure this is all my fault because i don't really understand how the filesystem works. 

Shutdown definitely does not wait for the transaction to complete as that would stop the tape - 

the driver interrupt asserts a SAT|GO whenever the transaction queue is empty which stops all tapes attached.

the drivers' close() is not called so i'm not sure how to delay the shutdown without causing all transactions to block.

-V

[Johnny Billquist]

Well, the system should sync all file systems at shutdown, and I would
think/hope/expect that it waits for them to complete before halting, but
I can't really remember for sure if it actually do...
If so, there might be some hook missing in the driver for the DECtape...
If noone have solved this in a few days, I might go into the code and
try to figure out/remember...

Johnny

On 2020-01-03 22:49, Ville Laitinen wrote:
> I'm pretty sure this is all my fault because i don't really understand
> how the filesystem works.
> Shutdown definitely does not wait for the transaction to complete as
> that would stop the tape -
> the driver interrupt asserts a SAT|GO whenever the transaction queue is
> empty which stops all tapes attached.
>
> the drivers' close() is not called so i'm not sure how to delay the
> shutdown without causing all transactions to block.
> -V
>
> On Fri, Jan 3, 2020 at 11:30 PM Johnny Billquist <b...@softjar.se
> <mailto:b...@softjar.se>> wrote:
>
> On 2020-01-03 22:18, Jonathan Morton wrote:
> >> On 3 Jan, 2020, at 11:00 pm, Ville Laitinen <vlai...@gmail.com

> <mailto:vlai...@gmail.com>> wrote:
> >>
> >> Yep, looks like the calls to sync will not flush all data and
> the tc gets a call to write one block just before halt.
> >> not sure if the tape would normally stop after WDATA completes.
> >
> > Surely even if the CPU halts, the drive controllers would still
> progress normally into a quiescent state?  This would include
> stopping the tape once that final block is written.
> >
> > So to handle shutdown correctly, SIMH should not exit instantly
> on CPU halt, but keep running until attached hardware is also quiescent.
>
> Ummm... Depends. I know of at least one DECtape controller, where if
> you
> halt the machine while the tape is spinning, the tape will continue
> spinning in all eternity.
>
>    Johnny
>
> --
> Johnny Billquist                  || "I'm on a bus
>                                    ||  on a psychedelic trip

> email: b...@softjar.se <mailto:b...@softjar.se>             ||

[Rene Richarz]

On Friday, January 3, 2020 at 10:49:39 PM UTC+1, Ville Laitinen wrote:

I'm pretty sure this is all my fault because i don't really understand how the filesystem works.

I'm not so sure that this is true .-).

It could as well be my fault because I don't understand well enough how the SimH DECtape driver works. SimH drivers are very difficult to understand because SimH is a single threaded program. Therefore, a driver should never put the whole SimH process to sleep, or even worse, run in a loop, while it is waiting for a timeout or a new command. In fact, if it would put the whole process to sleep while waiting for the next command, that command would of course never arrive, because the client CPU would not run.

I HAVE FIXED THE QUIRK by issuing a stop command for both drives in the SimH driver when the TC drives are detached. The lastest pdp11_tc.c in the tu56 repo has that fix. You need to install it to use the fixed version. A detach (either automatic in boot.ini, see my boot.ini in my last message, or manual) needs to be issued anyway after using the DECtape, because SimH does not write the DECtape buffer into a Linux file unless you detach the drive. I have on purpose not yet put that into the PDP-8 DECtape driver pdp8_dt.c, because if we don't see the problem on the PiDP-8, that will tell us that it is not SimH but BSD which has the problem.

If that's sufficient for you and you are not interested in the fine details of SimH, you can stop reading here. But for those interested in the fine details, I'm going on here.

Triple buffering:

******************

One thing which makes disk drive operations (including DECtape) somewhat difficult to understand and debug is triple buffering. First 2.11 BSD buffers any disk in its own (virtual) buffer. One can see that very well if tu56 is showing DECtape actions. A write to the tape is executed several seconds after the BSD user program is told that the write is complete. Second, the SimH DECtape driver implements its own buffering. I don't know why it does that, because in my opinion that is completely unnecessary and just adds to the confusion. The SimH DECtape driver writes that buffer to a Linux disk file if the detach command is executed. Third, Linux of course buffers the disk file as well. You never know when it is actually written to the SD card in the case of a Raspberry Pi running SimH.

Absolute timing or not:

*************************

SimH basically offers two types of timing commands: sim_activate(time) and sim_activate_abs(time). Both activate a simulated interrupt in SimH, so that the driver can give control back to SimH while it is waiting for the next event. The first one simulates timing based on actual speed of the SimH engine (throttled or not, dependent on speed of host CPU), whereas the second simulates absolute timing in microseconds. The SimH tape drivers all use the first one. In my opinion, that's kind of weird. Why should the tape drive be much slower if SimH is running on a slower Raspberry Pi? A change to that was required in my modified DECtape SimH driver, because the driver was running unrealistically fast on a RPi4, so that most tape actions were not visible in the front panel emulator. And I cannot just increase these times because then it would run unrealistically slow on slower RPi systems. I have changed all the timing to absolute timing, and implemented the TU56 "line timing" as defined in the original TU56 hardware specifications (a line is 3 bits).

Therefore, as long as the Raspberry Pi is fast enough, the tape speed should be more or less the same as on the real hardware. Of course, with my limited understanding of how the driver works, I cannot be sure that this has not introduces a bug. Please let me know if this does not work as expected in your environment.

Tape drive status:

********************

What I have added to the SimH DECtape and mag tape drivers is that they save a status byte, and in the case of the mag tape driver also a tape position, in a temporary file /tmp/tu56status. Both DECtape and mag tape use the same status file. Therefore, the two front panels are interchangeable to some degree. While the tape is used, Linux will of course keep that little file in its buffer. The advantage of using this type of communication between SimH and tu56 or tu77 is, that SimH does work all on its own and is not bothered by any of the front panel emulations running or not. This type of communication means that tu56 or tu77 might miss some status changes if they happen much too fast, and would anyway not be visible in between screen refreshes. Because DECtape actions are very fast, tu56 actually samples the tape status 10 times in between screen refreshed to avoid missing important tape motion changes. But both tu56 and tu77 will never miss the last status change. This means, that if the tape does not stop after BSD has been shut down, the DECtape SimH driver has definitely not issued a stop command to the front panel simulator. But this does not mean that the BSD kernel has not done everything right. It is still very likely that SimH just kills the DECtape driver without going through its proper states to slow down and stop the tape during a shutdown. Or, it is possible that with my limited understanding of the DECtape driver I have missed a line in the program, where I should have added a stop drive status change.

[Ville Laitinen]

checked the tc device status after a halt and the status register shows ready meaning no error - this is as it probably should be since dma is being performed without the cpu.

Also tested with mounted devices on other disk controllers and it looks like they get a hail mary from the kernel just before halt no matter what the fs status is, dectape just doesn't stop the reels after a successful operation but it's not really an error.

incidentally, mount_ufs does not bother checking if there actually is a filesystem present and will happily mount partition 'a' of a  virgin drive with no data on it, verified with ra driver which looks like the latest incarnation of disk drivers.

Default disklabels provided by the driver really don't seem like a smart idea, how was disktab worse ?

Then again autoconfig reading entrypoints from a kernel image is just nasty... why not hardwire stuff in kernel conf since the admin almost certainly knows what hardare is installed.

-V

--

You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/7142df63-ddb1-484b-898f-47f4e36332ce%40googlegroups.com.

[Johnny Billquist]

On 2020-01-04 22:32, Ville Laitinen wrote:
> checked the tc device status after a halt and the status register shows
> ready meaning no error - this is as it probably should be since dma is
> being performed without the cpu.
> Also tested with mounted devices on other disk controllers and it looks
> like they get a hail mary from the kernel just before halt no matter
> what the fs status is, dectape just doesn't stop the reels after a
> successful operation but it's not really an error.

Are the explicit go/stop commands on the TC11, or are those implied by
some other operation?
If they are explicit, then it's no surprise if the drive would keep
spinning. But if they are implied, then I would expect the drive to stop
after the operation, whether the CPU is running or not.

> incidentally, mount_ufs does not bother checking if there actually is a
> filesystem present and will happily mount partition 'a' of a  virgin
> drive with no data on it, verified with ra driver which looks like the
> latest incarnation of disk drivers.

That sounds very broken. It should require that there is a proper
superblock... So, something broken or buggy...

> Default disklabels provided by the driver really don't seem like a smart
> idea, how was disktab worse ?

Is that a trick question?
You do know that before disk labels, the offsets of the different
partitions were actually hardcoded in the device drivers. The disktab
file was just a help for tools, but the final truth was what in the
device drivers, and nowhere else. (And no, device drivers did not try to
read the disktab file.)

And you have to provide a default disklabel when there isn't one on the
disk, or else the device driver would suddenly not be able to access the
drive at all, unless you do a huge special case around that situation.
And why would you, when a default disklabel solves it in a much cleaner way?

> Then again autoconfig reading entrypoints from a kernel image is just
> nasty... why not hardwire stuff in kernel conf since the admin almost
> certainly knows what hardare is installed.

Uh... Again. A trick question, or what?
The only kernel conf that exists is the one that is used to build the
kernel. And, as you noted, the kernel is where the information comes
from. So it is already hardwired in the kernel conf, since that is the
only place the kernel is getting it from.

Or what entry points and autoconfig are you talking about?

[Johnny Billquist]

On 2020-01-04 23:37, Johnny Billquist wrote:
> On 2020-01-04 22:32, Ville Laitinen wrote:
>> incidentally, mount_ufs does not bother checking if there actually is
>> a filesystem present and will happily mount partition 'a' of a  virgin
>> drive with no data on it, verified with ra driver which looks like the
>> latest incarnation of disk drivers.
>
> That sounds very broken. It should require that there is a proper
> superblock... So, something broken or buggy...

By the way, mount actually seem to only check that the fs type is
reasonable in the disklabel. I think that this is not good enough. So
thanks for spotting this. Let's see if we can improve on that...

But one additional risk/chance is always that you can have overlapping
partitions, in which case mount could definitely be happy.

Typically, partition a is at the start of the disk, while partition c
covers the whole disk. So you you create a file system on partition a,
from the system point of view, partition c also have a correct file system.

[Ville Laitinen]

Sorry, using gmail so this reply is going to seem odd...

"

Are the explicit go/stop commands on the TC11, or are those implied by
some other operation?
If they are explicit, then it's no surprise if the drive would keep
spinning. But if they are implied, then I would expect the drive to stop
after the operation, whether the CPU is running or not.

"

Start is implied but stop is explicit so the current behaviour is as expected - 

I'm a little frustrated because i can't figure out a way around this without having all calls to

strategy block...

The only reference i about device drivers i could find is 

"The Design and Implementation of the 4.3BSD UNIX Operating System" which actually says

the "close" function should not be needed for block devices.

About disklabels.. having a partitioning tool from the beginning would have been a better solution.

No - i wouldn't have been smart enough to suggest that back then :D

More than one driver will happily supply the kernel with a default "a spanning the whole drive" if there is no valid data found

which i think is just plain stupid.

Then again, the choice of available hardware at the time was very limited so there was really no need to have a "generic" disk drive, 

although some of the drivers updated in the 90's make it clear this is a pain :D

With autoconfig i was referring to /etc/autoconfig which actually reads /etc/dtab and kernel image to find the expected devices and their XXattach

entry points. 

This i guess was intended a timesaver for adding a second(or Nth) controller without having to recompile the kernel ?

Reason why i was upset with it is the sources imply some kernel structures may not be initialized if the attach function doesn't exist - however 

almost all XXprobe/XXattach functions simply check writing to the supplied address doesn't cause a fault so it would have been less costly (sizewise)

to just list them in the kernel conf file. (then again, that's not actually a fault with the design but the device drivers...)

[Rene Richarz]

On Sunday, January 5, 2020 at 1:22:17 AM UTC+1, Ville Laitinen wrote:

 

Start is implied but stop is explicit so the current behaviour is as expected - 

I'm a little frustrated ...

Ville,

Don‘t worry too much about this. It‘s rather a feature than a bug :-)

I still think what happens is the following. If you want, I can put some debug statements into the SimH driver to verify this.

During the shutdown, the sync writes a last block to the tape. Remember, SimH is a simulator, not the real hardware. So what does it do? It first updates its internal tape buffer with that last block, and then issues a sim_activate_abs to simulate the write block timing. Then it returns control to the rest of SimH. Now, under normal circumstances, SimH would simulate an interrupt after the write block time, and the SimH driver would send a stop tape status to the front panel emulator. But because we are processing a shutdown, SimH receives a halt during the write block time, and most likely stops servicing any simulated interrupts from any driver. Therefore, the tape never stops, but the updated block is in the driver buffer.

With my fix of issuing a stop tape status when detach is called, this problem is solved. If the user has added a proper detach at the end of his boot.ini, the tape stops and the content of the SimH driver buffer is flushed. If there is no detach in boot.ini, the reel keeps moving and reminds the user to issue a manual detach :-) Remember, the detach is required anyway because otherwise the the SimH driver would not flush its internal buffer.

 

[Johnny Billquist]

On 2020-01-05 01:22, Ville Laitinen wrote:
> Sorry, using gmail so this reply is going to seem odd...

:-)

> "
> Are the explicit go/stop commands on the TC11, or are those implied by
> some other operation?
> If they are explicit, then it's no surprise if the drive would keep
> spinning. But if they are implied, then I would expect the drive to stop
> after the operation, whether the CPU is running or not.
> "
>
> Start is implied but stop is explicit so the current behaviour is as
> expected -
> I'm a little frustrated because i can't figure out a way around this
> without having all calls to
> strategy block...
> The only reference i about device drivers i could find is
> "The Design and Implementation of the 4.3BSD UNIX Operating System"
> which actually says
> the "close" function should not be needed for block devices.

Ah. So the DECtape behaves as expected. No stop coming, so it keeps
running. Ok...
Hmm. Tricky. Essentially, at the interrupt when transfer has been
completed, is where you would normally issue the stop then, but that
requires that the processor is still running.

But the sync at halt cannot allow to complete until all data in memory
have been flushed, so it needs to keep a count of how much data is left
to do, and only halts when this is zero.

I haven't looked at that in a while, but it seems possible that it can
be solved through that mechanism. But it assumes that it doesn't halt
until all I/O operations have completed. I would hope/assume that this
is allowed to happen, as I would be worried about DMA completing if the
CPU is halted... But I would need to look more to be sure.

> About disklabels.. having a partitioning tool from the beginning would
> have been a better solution.

Certainly. But the partitioning tool came at the same time as disk
labels. Before then, neither existed, and all you had was fixed offsets
in the drivers.

> No - i wouldn't have been smart enough to suggest that back then :D
> More than one driver will happily supply the kernel with a default "a
> spanning the whole drive" if there is no valid data found
> which i think is just plain stupid.

It is needed. You need to have a way of addressing the whole disk.

> Then again, the choice of available hardware at the time was very
> limited so there was really no need to have a "generic" disk drive,
> although some of the drivers updated in the 90's make it clear this is a
> pain :D

Well, it became a pain already in the 80s. Until the MSCP drivers, it
was simple. All controllers had a known set of disk drives, and you
could have a fixed table of partitions. Of course, that set of
partitions was not ideal, since different people sometimes wanted
different layouts, but it was good enough that it worked. Massbus is the
thing with the most varied set of disk drives. It became a little ugly
there, but still sortof manageable.

But with MSCP, it soon became much worse, since there appeared so many
different disks, with different capacities. And MSCP in fact is totally
open ended there. You can basically have any size of disk hooked to
MSCP. So, fixed partition tables obviously were a bad idea on that. But
it still took until the 90s before 2.11BSD got them.

> With autoconfig i was referring to /etc/autoconfig which actually reads
> /etc/dtab and kernel image to find the expected devices and their XXattach
> entry points.
> This i guess was intended a timesaver for adding a second(or Nth)
> controller without having to recompile the kernel ?
> Reason why i was upset with it is the sources imply some kernel
> structures may not be initialized if the attach function doesn't exist -
> however
> almost all XXprobe/XXattach functions simply check writing to the
> supplied address doesn't cause a fault so it would have been less costly
> (sizewise)
> to just list them in the kernel conf file. (then again, that's not
> actually a fault with the design but the device drivers...)

Ah. That...
Well, it was probably more a question of getting something only done
once out of the kernel itself. Space saving on a memory limited machine.
For other (newer) BSD systems, it's all in the kernel.
All it does is try to provoke an interrupt for each controller, and if
it actually do interrupt, install the proper information in the
interrupt vector table for that controller. (Well, for some controllers,
it don't even interrupt...)

Normally, you could just leave all controller in in /etc/dtab, and let
it probe the hell out of the system. Whatever you have in your kernel
config will then decide which controllers you actually end up having.
It's just that autoconfig is trying to match the kernel to the actual
hardware, and adjust the setup accordingly.

However, you cannot add extra controllers by just editing /etc/dtab. You
still define how many controllers you have in the kernel itself.
But it does allow easier moving the CSR and vector around for the
controllers, since that comes from /etc/dtab.

As far as the probe functions go, depending on the device, they might
just check if it is possible to read from the CSR, or they might also
try writing, in order to evoke an interrupt. And then it checks if an
interrupt happened.

And I can't see any device specific attach functions. Each controller
has its own probe function in autoconfig, but there is just one attach
function used by all. So the controller gets probed, and if it exists,
it is attached, meaning the interrupt vector is set up. If no device
driver exists for the controller, it obviously will also not get an
interrupt vector set up, since there is no code for the interrupt to
jump to.

Seems very reasonable to me.

[Ville Laitinen]

" And I can't see any device specific attach functions. Each controller
has its own probe function in autoconfig, but there is just one attach
function used by all. So the controller gets probed, and if it exists,
it is attached, meaning the interrupt vector is set up. If no device
driver exists for the controller, it obviously will also not get an
interrupt vector set up, since there is no code for the interrupt to
jump to."

Well yeah, this is actually where it gets interesting :)

Autoconfig actually reads the kernel namespace trying  to locate a device specific XXattach function where XX is the device name read from the /etc/dtab.

https://www.retro11.de/ouxr/211bsd/usr/src/sys/autoconfig/read_nlist.c.html 

 

If the XXprobe (read_nlist actually checks if it can find XXprobe in the kernel that can be used instead of the builtin routines) is successful XXattach wil be called via syscall.

https://www.retro11.de/ouxr/211bsd/usr/src/sys/autoconfig/attach.c.html 

 

[Johnny Billquist]

Ah. You were thinking of that one, and not the one in autoconfig.

Well, once the controller is attached, it needs to probe to find which
disks exist. This cannot be done by autoconfig, since it requires more
controlled communication with the controller, which clearly only the
drive can be allowed to have.

Johnny

> email: b...@softjar.se <mailto:b...@softjar.se>             ||

[Ville Laitinen]

> Ah. So the DECtape behaves as expected. No stop coming, so it keeps
>running. Ok...
>Hmm. Tricky. Essentially, at the interrupt when transfer has been
>completed, is where you would normally issue the stop then, but that
>requires that the processor is still running.

So the cpu will not do anything if it receives an interrupt when halted ?

(yeah, i know i could probably find this info from manuals but asking on the list is faster :) 

>But the sync at halt cannot allow to complete until all data in memory
>have been flushed, so it needs to keep a count of how much data is left
>to do, and only halts when this is zero.

>I haven't looked at that in a while, but it seems possible that it can
>be solved through that mechanism. But it assumes that it doesn't halt
>until all I/O operations have completed. I would hope/assume that this
>is allowed to happen, as I would be worried about DMA completing if the
>CPU is halted... But I would need to look more to be sure."

"boot" in machdep2 does this to wait for used buffers.

      { register struct buf *bp;
 400:           int iter, nbusy;
 401: 
 402:           for (iter = 0; iter < 20; iter++) {
 403:             nbusy = 0;
 404:             for (bp = &buf[nbuf]; --bp >= buf; )
 405:                 if (bp->b_flags & B_BUSY)
 406:                     nbusy++;
 407:             if (nbusy == 0)
 408:                 break;
 409:             printf("%d ", nbusy);
 410:             delay(40000L * iter);
 411:           }
 412:         }

Based on a quick test no filesystem block requests have B_BUSY set though so the above cannot see any pending transfers.

(again, just guesswork - i could be completely wrong :)

br,

-V

still using gmail web interface... sorry about the mess..

[Ville Laitinen]

gah, i really wish there was a recall button for emails :D

Please ignore the below as it's not quite true, the transfer requests have busy set when they arrive at the driver.

[Johnny Billquist]

On 2020-01-05 17:44, Ville Laitinen wrote:
> > Ah. So the DECtape behaves as expected. No stop coming, so it keeps
> >running. Ok...
> >Hmm. Tricky. Essentially, at the interrupt when transfer has been
> >completed, is where you would normally issue the stop then, but that
> >requires that the processor is still running.
>
> So the cpu will not do anything if it receives an interrupt when halted ?
> (yeah, i know i could probably find this info from manuals but asking on
> the list is faster :)

Right. If the CPU is halted, it cannot react to an interrupt.

> >But the sync at halt cannot allow to complete until all data in memory
> >have been flushed, so it needs to keep a count of how much data is left
> >to do, and only halts when this is zero.
>
> >I haven't looked at that in a while, but it seems possible that it can
> >be solved through that mechanism. But it assumes that it doesn't halt
> >until all I/O operations have completed. I would hope/assume that this
> >is allowed to happen, as I would be worried about DMA completing if the
> >CPU is halted... But I would need to look more to be sure."
>
> "boot" in machdep2 does this to wait for used buffers.
>

> { <https://www.retro11.de/ouxr/211bsd/usr/src/sys/pdp/machdep2.c.html#n:412> register struct buf <https://www.retro11.de/ouxr/211bsd/usr/src/sys/h/buf.h.html#sd:buf> *bp;
> /400/: int iter, nbusy;
> /401/:
> /402/: for (iter =0; iter <20; iter++){ <https://www.retro11.de/ouxr/211bsd/usr/src/sys/pdp/machdep2.c.html#n:411>
> /403/: nbusy =0;
> /404/: for (bp = &buf <https://www.retro11.de/ouxr/211bsd/usr/src/sys/pdp/genassym.c.html#s:_buf>[nbuf]; --bp >=buf <https://www.retro11.de/ouxr/211bsd/usr/src/sys/pdp/genassym.c.html#s:_buf>; )
> /405/: if (bp->b_flags &B_BUSY <https://www.retro11.de/ouxr/211bsd/usr/src/sys/h/buf.h.html#m:B_BUSY>)
> /406/: nbusy++;
> /407/: if (nbusy ==0)
> /408/: break;
> /409/: printf <https://www.retro11.de/ouxr/211bsd/usr/src/sys/sys/subr_prf.c.html#s:_printf>("%d ", nbusy);
> /410/: delay <https://www.retro11.de/ouxr/211bsd/usr/src/sys/pdp/net_xxx.s.html#s:_delay>(40000L * iter);
> /411/: } <https://www.retro11.de/ouxr/211bsd/usr/src/sys/pdp/machdep2.c.html#n:402>
> /412/: } <https://www.retro11.de/ouxr/211bsd/usr/src/sys/pdp/machdep2.c.html#n:399>

>
>
> Based on a quick test no filesystem block requests have B_BUSY set though so the above cannot see any pending transfers.

The B_BUSY flag is normally managed by the file system code, and not in
any device driver.
It's the file system that have things cached...

> (again, just guesswork - i could be completely wrong :)

Which means it should wait for any transactions to complete. It does
depend on the B_BUSY flag correctly though... I hope the DECtape driver
is presented as a block device, on which the normal file system tools,
mounting and so on happens...