Re: General TC11 DECtape diagnostic/formatter questions

[Paul Koning]

> On Nov 15, 2016, at 5:40 PM, Josh Dersch  wrote:
> 
> ...
> I noticed the following commented-out line at the beginning of the program:
> 
> START:
> ; RESET   ;CLEAR THE WORLD
> ; MOV #P7,PS  ;LOCKOUT P1 BY RAISING CPU PRIORITY <<
> 
> Uncommenting the MOV #P7,PS line allows the formatter to run properly.
> It appears that interrupts (I'd guess the LTC interrupt) were taking
> enough time away from the program to cause it to miss data; I'm
> guessing it's because I'm running the FB monitor rather than the SJ
> monitor, but I'm not familiar enough with RT-11 yet to know exactly
> where to place the blame.

Yes, commenting out that code is clearly a bug.  The RALL/WALL/WRTM functions 
are used in program I/O mode, so the CPU has to be ready with each new word as 
the tape finishes with the previous one.  Interrupts are most definitely 
supposed to be disabled.  DECtape formatting is a standalone activity, not 
something run under any OS.

RT-11 FB is likely to do a bit more stuff per clock interrupt, but either way, 
you're entirely correct that interrupts -- clock or otherwise -- need to be 
disabled.  The consequence of spurious interrupts might be a corrupt mark 
track, or wrong data written by the WALL pass, or verify errors during the RALL 
pass.

BTW, on RALL, it's actually possible to use DMA for the lower 16 bits of the 18 
bit data.  The RT11 utility FILEX does that when reading PDP10 format tapes.  
(I suppose the same might be true for WALL, I haven't heard of that being 
done.)  But the conventional way is to ignore the DMA and handle the data via 
the Data register plus the two extended data bits in the status register.

paul

Re: General TC11 DECtape diagnostic/formatter questions

[Josh Dersch]

On Wed, Nov 9, 2016 at 7:20 PM, Josh Dersch  wrote:

> On 11/9/16 6:18 PM, Paul Koning wrote:
>
> On Nov 9, 2016, at 5:57 PM, Josh Dersch  wrote:
>>>
>>> ...
>>> A quick update -- I ran the ZTCD diagnostics and they do fail, despite my
>>> recollection (this is what I get for not taking notes at the end of
>>> yesterday, and yesterday seems so far away now...).  The first test (a
>>> forward WALL, followed by an RALL of a single block) fails with the
>>> following spew (for example):
>>>
>>> BLKRQ 000310 DATA ERR  WORD 00054.  S/B 176376  WAS 104106
>>>
>>> Based on a reading of the fiche listing (which is a slightly newer
>>> revision
>>> of the binary I have) I believe S/B is the expected data and "WAS" is the
>>> read-back data for a given word.  Since one appears to be the obverse
>>> complement of the other, it looks like the obverse complement logic is
>>> running when it shouldn't be...
>>>
>> Yes, those two patterns are indeed obverse complement.  Word 0054?
>> That's odd, if it's doing this wrong for a word in the middle of the
>> buffer.  Can you have it halt on fail so you can examine the buffer?
>>
>> paul
>>
>>
>>
>> It's actually word 4 (transcription error on my half) and it reports
> errors for all words in the block (though the reported word number doesn't
> actually correspond in any meaningful way to the word on tape, per the
> documentation); i just singled that one out for an example.  They all show
> the read data being the obverse complement of the expected data.  I'll be
> doing some serious debugging tomorrow...
>
> - Josh
>

So a small update:

I spent some time probing various signals and I couldn't find anything
obviously wrong; while the failing diagnostic was running, the obverse
complement logic in the hardware was behaving as I'd expect (i.e. it wasn't
being used, since an RALL was in effect).  I went so far as to write my own
little test program that does basically what the ZTCD diagnostic Test 0
does -- a WDATA (forward) followed by a RALL (forward) and a comparison of
the data, and everything came back clean.

But I gained a better understanding of how the TC11 hardware works and how
it's programmed, so that's always a good thing.

And that knowledge helped me when I went back to the RT-11 formatter to see
if I could work out what was going wrong there.  As you recall, the
formatter was failing after writing the T tracks with a Data Miss (DATM)
error.  Data Miss in this case would indicate the software not responding
in time to the READY signal during a RALL command, which is interesting --
this would seem to indicate more of a software problem than a hardware one.

I noticed the following commented-out line at the beginning of the program:

START:
;   RESET   ;CLEAR THE WORLD
;   MOV #P7,PS  ;LOCKOUT P1 BY RAISING CPU PRIORITY <<

Uncommenting the MOV #P7,PS line allows the formatter to run properly.
It appears that interrupts (I'd guess the LTC interrupt) were taking
enough time away from the program to cause it to miss data; I'm
guessing it's because I'm running the FB monitor rather than the SJ
monitor, but I'm not familiar enough with RT-11 yet to know exactly
where to place the blame.

At any rate, at this point I'm able to format a tape, initialize it in
RT-11, and copy/verify files onto it without any issues.  The failing
diagnostics are still puzzling, but I'm almost ready to throw in the
towel on them :).

- Josh

Re: General TC11 DECtape diagnostic/formatter questions

[Christian Corti]

On Thu, 10 Nov 2016, Noel Chiappa wrote:

BTW, I noticed a couple of places in DTF.MAC where error checking code was
commented out, e.g.:

 ;EHLT4:XX  ;HALT WITH BLK#IN LIGHTS, CONTINUE
 ;  MOV #257.,R0;TO FIND DATA WORD POSITION
 ;  ADD TOG1,R0 ;DETERMINE WHICH WORD IS WRONG
 ;EHLT5:XX  ;HALT WITH #OF WORD IN LIGHTS. 0=REV. CHKSUM
 ;  MOV @TCDT,R0;CONTINUE TO FETCH BAD WORD
 ;EHLT6:XX  ;HALT WITH BAD DATA IN LIGHTS. CONTINUE

Maybe it would be useful to un-comment them?


No, this is the old code to display the error words in the front-panel 
display. Instead, my code (that follows the commented one) converts the 
words to ASCII octal representation and displays the appropriate error 
message on the console.


Christian

Re: General TC11 DECtape diagnostic/formatter questions

[Noel Chiappa]

> From: Christian Corti

> Seems the original must have been the XXDP TC11 DECtape formatter
> program by Robert J. Collins. I have no clue where I found the RT11
> version of this

So that made me wonder if the V6 Unix version of tcf.s really was related to
DTF.MAC. I checked out the two of them, and it seems they are likely
un-related; very different structure, etc.

BTW, I noticed a couple of places in DTF.MAC where error checking code was
commented out, e.g.:

  ;EHLT4:   XX  ;HALT WITH BLK#IN LIGHTS, CONTINUE
  ; MOV #257.,R0;TO FIND DATA WORD POSITION
  ; ADD TOG1,R0 ;DETERMINE WHICH WORD IS WRONG
  ;EHLT5:   XX  ;HALT WITH #OF WORD IN LIGHTS. 0=REV. CHKSUM
  ; MOV @TCDT,R0;CONTINUE TO FETCH BAD WORD
  ;EHLT6:   XX  ;HALT WITH BAD DATA IN LIGHTS. CONTINUE

Maybe it would be useful to un-comment them?
  

> On Nov 9, 2016, at 5:57 PM, Josh Dersch wrote:

> I believe S/B is the expected data

Yes, probably stands for 'should be'.

Noel

Re: General TC11 DECtape diagnostic/formatter questions

[Christian Corti]

On Wed, 9 Nov 2016, Noel Chiappa wrote:

Having just looked at the original :-), it did have two messages:

 "ready drive 0 and type y"

and

 "tcf: error"


Seems the original must have been the XXDP TC11 DECtape formatter program 
by Robert J. Collins. I have no clue where I found the RT11 version of 
this, it must have been in 2005 after we got the TC11 and TU56 along with 
the 11/20 and other peripherals. The modified version was part of DECUS, 
it is listed in the August 1978 edition of the PDP11 DECUS catalog (page 
28, program no. 11-216), but apparently it isn't online (any more?).


Christian

Re: General TC11 DECtape diagnostic/formatter questions

[Josh Dersch]

On 11/9/16 6:18 PM, Paul Koning wrote:


On Nov 9, 2016, at 5:57 PM, Josh Dersch  wrote:

...
A quick update -- I ran the ZTCD diagnostics and they do fail, despite my
recollection (this is what I get for not taking notes at the end of
yesterday, and yesterday seems so far away now...).  The first test (a
forward WALL, followed by an RALL of a single block) fails with the
following spew (for example):

BLKRQ 000310 DATA ERR  WORD 00054.  S/B 176376  WAS 104106

Based on a reading of the fiche listing (which is a slightly newer revision
of the binary I have) I believe S/B is the expected data and "WAS" is the
read-back data for a given word.  Since one appears to be the obverse
complement of the other, it looks like the obverse complement logic is
running when it shouldn't be...

Yes, those two patterns are indeed obverse complement.  Word 0054?  That's odd, 
if it's doing this wrong for a word in the middle of the buffer.  Can you have 
it halt on fail so you can examine the buffer?

paul



It's actually word 4 (transcription error on my half) and it reports 
errors for all words in the block (though the reported word number 
doesn't actually correspond in any meaningful way to the word on tape, 
per the documentation); i just singled that one out for an example.  
They all show the read data being the obverse complement of the expected 
data.  I'll be doing some serious debugging tomorrow...


- Josh

Re: General TC11 DECtape diagnostic/formatter questions

[Paul Koning]

> On Nov 9, 2016, at 5:57 PM, Josh Dersch  wrote:
> 
> ...
> A quick update -- I ran the ZTCD diagnostics and they do fail, despite my
> recollection (this is what I get for not taking notes at the end of
> yesterday, and yesterday seems so far away now...).  The first test (a
> forward WALL, followed by an RALL of a single block) fails with the
> following spew (for example):
> 
> BLKRQ 000310 DATA ERR  WORD 00054.  S/B 176376  WAS 104106
> 
> Based on a reading of the fiche listing (which is a slightly newer revision
> of the binary I have) I believe S/B is the expected data and "WAS" is the
> read-back data for a given word.  Since one appears to be the obverse
> complement of the other, it looks like the obverse complement logic is
> running when it shouldn't be...

Yes, those two patterns are indeed obverse complement.  Word 0054?  That's odd, 
if it's doing this wrong for a word in the middle of the buffer.  Can you have 
it halt on fail so you can examine the buffer?

paul

Re: General TC11 DECtape diagnostic/formatter questions

[Josh Dersch]

On Wed, Nov 9, 2016 at 1:43 PM, Josh Dersch  wrote:

>
>
> On Wed, Nov 9, 2016 at 1:05 PM, Paul Koning 
> wrote:
>
>>
>> > On Nov 9, 2016, at 3:32 PM, Josh Dersch  wrote:
>> >
>> > ...
>> >
>> > Now that I've gotten the full suite of diagnostics to run, the problem
>> > seems to be that the TC11 isn't reading properly in reverse -- Tests
>> > 15,16,21,22,26,27 and 34 of ZTCD fail, all others pass (modulo a
>> marginal
>> > block on the tape causing a failure here and there).  This would
>> probably
>> > explain why DTF fails immediately after writing T, since it works in
>> > reverse from that point...
>>
>> Not necessarily.  I thought that reading direction simply changes the bit
>> patterns seen by the electronics because the waveforms are reversed.  This
>> is the famous "obverse complement".
>>
>> In the Mark track, reversing the direction means that you see the bits in
>> the opposite order and complemented.  As I recall, the encoding takes
>> advantage of this: the start of block code is the obverse complement of the
>> end of block code (so that reversing means the "end" code now reads like
>> "start").
>>
>> In the data, you have 3 bits parallel.  So there, reversing means that
>> you get the 3 bits at a time reverse (think of octal digits reversed),
>> complemented.  For 16-bit data, look at it as 18 bits with 2 bits unused.
>>
>> In Read-All and Write-All, the controller doesn't do anything for
>> direction, so if you write in one direction data meant to be read in the
>> opposite direction, the software has to supply obverse-complement format
>> data.
>>
>> For regular Read and Write, the controller does handle direction change:
>> the reverse commands do an obverse-complement on the supplied data words,
>> so your data ends up word-wise reversed but the bits are in the expected
>> spot and of the expected polarity.
>>
>> The second pass (after the WRTM) in the formatting program is a reverse
>> direction WALL, so my comment that the hardware doesn't do anything special
>> for direction applies there.
>>
>> A possibility is that the motor has a problem causing an excessive speed
>> difference between forward and reverse.  But in any case, yes, scope and
>> schematics seem needed here.
>>
>
> Those are good points.  It's clear from running the diagnostics (ZTCC, not
> ZTCD, sorry for the important typo) that a Read in a reverse direction
> fails (but writes seem to be OK in either direction -- the tests that do
> forward reads, regardless of the write direction of the data universally
> pass). So there's definitely a fault there, but as you point out it may be
> a separate issue from the formatter problem.  Read-All and Write-All tests
> (ZTCD) seem to be OK, but I'm going to re-run them just to be doubly-sure.
> If those pass, I'm going to start with scoping out the OBVERSE ENB H
> signals and the logic associated with them and see if there's anything
> fishy there.
>
> - Josh
>

A quick update -- I ran the ZTCD diagnostics and they do fail, despite my
recollection (this is what I get for not taking notes at the end of
yesterday, and yesterday seems so far away now...).  The first test (a
forward WALL, followed by an RALL of a single block) fails with the
following spew (for example):

BLKRQ 000310 DATA ERR  WORD 00054.  S/B 176376  WAS 104106

Based on a reading of the fiche listing (which is a slightly newer revision
of the binary I have) I believe S/B is the expected data and "WAS" is the
read-back data for a given word.  Since one appears to be the obverse
complement of the other, it looks like the obverse complement logic is
running when it shouldn't be...

- Josh



>
>
>
>>
>> paul
>>
>>
>>
>

Re: General TC11 DECtape diagnostic/formatter questions

[Al Kossow]

On 11/9/16 1:50 PM, jim stephens wrote:
> 
> Are
> there two such stations on the drive for reading?

Nope. DECtape only has one set of heads, so it writes blind.

Re: General TC11 DECtape diagnostic/formatter questions

[jim stephens]

On 11/9/2016 1:43 PM, Josh Dersch wrote:

t's clear from running the diagnostics (ZTCC, not
ZTCD, sorry for the important typo) that a Read in a reverse direction
fails (but writes seem to be OK in either direction -- the tests that do
forward reads, regardless of the write direction of the data universally
pass).
When you do writes, you have to physically have a read station 
positioned after the write station on the head.  Are there two such 
stations on the drive for reading?  Otherwise the writes may just be 
blind writes, which would of course work as there isn't much to check 
other than to backspace and do a re-read.


Just curious, as though I've got access to TU-56's have not looked for 
that detail.


thanks
jim

Re: General TC11 DECtape diagnostic/formatter questions

[Josh Dersch]

On Wed, Nov 9, 2016 at 1:05 PM, Paul Koning  wrote:

>
> > On Nov 9, 2016, at 3:32 PM, Josh Dersch  wrote:
> >
> > ...
> >
> > Now that I've gotten the full suite of diagnostics to run, the problem
> > seems to be that the TC11 isn't reading properly in reverse -- Tests
> > 15,16,21,22,26,27 and 34 of ZTCD fail, all others pass (modulo a marginal
> > block on the tape causing a failure here and there).  This would probably
> > explain why DTF fails immediately after writing T, since it works in
> > reverse from that point...
>
> Not necessarily.  I thought that reading direction simply changes the bit
> patterns seen by the electronics because the waveforms are reversed.  This
> is the famous "obverse complement".
>
> In the Mark track, reversing the direction means that you see the bits in
> the opposite order and complemented.  As I recall, the encoding takes
> advantage of this: the start of block code is the obverse complement of the
> end of block code (so that reversing means the "end" code now reads like
> "start").
>
> In the data, you have 3 bits parallel.  So there, reversing means that you
> get the 3 bits at a time reverse (think of octal digits reversed),
> complemented.  For 16-bit data, look at it as 18 bits with 2 bits unused.
>
> In Read-All and Write-All, the controller doesn't do anything for
> direction, so if you write in one direction data meant to be read in the
> opposite direction, the software has to supply obverse-complement format
> data.
>
> For regular Read and Write, the controller does handle direction change:
> the reverse commands do an obverse-complement on the supplied data words,
> so your data ends up word-wise reversed but the bits are in the expected
> spot and of the expected polarity.
>
> The second pass (after the WRTM) in the formatting program is a reverse
> direction WALL, so my comment that the hardware doesn't do anything special
> for direction applies there.
>
> A possibility is that the motor has a problem causing an excessive speed
> difference between forward and reverse.  But in any case, yes, scope and
> schematics seem needed here.
>

Those are good points.  It's clear from running the diagnostics (ZTCC, not
ZTCD, sorry for the important typo) that a Read in a reverse direction
fails (but writes seem to be OK in either direction -- the tests that do
forward reads, regardless of the write direction of the data universally
pass). So there's definitely a fault there, but as you point out it may be
a separate issue from the formatter problem.  Read-All and Write-All tests
(ZTCD) seem to be OK, but I'm going to re-run them just to be doubly-sure.
If those pass, I'm going to start with scoping out the OBVERSE ENB H
signals and the logic associated with them and see if there's anything
fishy there.

- Josh



>
> paul
>
>
>

Re: General TC11 DECtape diagnostic/formatter questions

[Paul Koning]

> On Nov 9, 2016, at 3:32 PM, Josh Dersch  wrote:
> 
> ...
> 
> Now that I've gotten the full suite of diagnostics to run, the problem
> seems to be that the TC11 isn't reading properly in reverse -- Tests
> 15,16,21,22,26,27 and 34 of ZTCD fail, all others pass (modulo a marginal
> block on the tape causing a failure here and there).  This would probably
> explain why DTF fails immediately after writing T, since it works in
> reverse from that point...

Not necessarily.  I thought that reading direction simply changes the bit 
patterns seen by the electronics because the waveforms are reversed.  This is 
the famous "obverse complement".

In the Mark track, reversing the direction means that you see the bits in the 
opposite order and complemented.  As I recall, the encoding takes advantage of 
this: the start of block code is the obverse complement of the end of block 
code (so that reversing means the "end" code now reads like "start").

In the data, you have 3 bits parallel.  So there, reversing means that you get 
the 3 bits at a time reverse (think of octal digits reversed), complemented.  
For 16-bit data, look at it as 18 bits with 2 bits unused.

In Read-All and Write-All, the controller doesn't do anything for direction, so 
if you write in one direction data meant to be read in the opposite direction, 
the software has to supply obverse-complement format data.

For regular Read and Write, the controller does handle direction change: the 
reverse commands do an obverse-complement on the supplied data words, so your 
data ends up word-wise reversed but the bits are in the expected spot and of 
the expected polarity.

The second pass (after the WRTM) in the formatting program is a reverse 
direction WALL, so my comment that the hardware doesn't do anything special for 
direction applies there.

A possibility is that the motor has a problem causing an excessive speed 
difference between forward and reverse.  But in any case, yes, scope and 
schematics seem needed here.

paul

Re: General TC11 DECtape diagnostic/formatter questions

[Noel Chiappa]

> From: Josh Dersch

>> The UNIX V6 distro includes a standalone program, tcf.s, to format
>> DECtapes.

> I could probably get a V6 distribution running if I need to, but if you
> have the means to do so easily, that would be handy so I can at least
> have another tool to try out.

I had a look at tcf.s, and it depends on having been loaded by the V6 disk
bootstrap - it uses the console driver in the bootstrap (the bootstrap leaves
a pointer to it in R5).

So it might be easier to use that DTF.MAC, which seems like it's mostly the
same program, and which you apparently already have working?

If you'd still like to use the V6 tcf, due to the teletype driver issue,
probably the easist thing is that I could make up a miniature disk image
(RK05, if you have that available), with both the V6 bootstap, and tcf on it.
Otherwise, I might be able to cobble something together; a hacked version of
tcf including the console driver, or something like that.

> Something that XXDP can load would be useful.

I know nothing of almost any DEC software, alas - I'm assuming it can handle
.LDA files, but I don't know which format it prefers.


> From: Christian Corti

> I enhanced DTF with some useful messages and error/status output. IIRC
> the "original" version produced no messages at all.

Having just looked at the original :-), it did have two messages:

  "ready drive 0 and type y"

and

  "tcf: error"

(Shades of 'ed' :-)

Noel

Re: General TC11 DECtape diagnostic/formatter questions

[Josh Dersch]

On Wed, Nov 9, 2016 at 12:59 AM, Christian Corti <
c...@informatik.uni-stuttgart.de> wrote:

> On Tue, 8 Nov 2016, Josh Dersch wrote:
>
>> with the TC11 system," and I haven't managed to find it. I *have* found
>> this:
>> http://mirrors.pdp-11.ru/inf.informatik.uni-stuttgart.de/pdp11/dtf.mac
>>
>
> ... which is simply a mirror of our FTP server at
> ftp://ftp.informatik.uni-stuttgart.de/pub/cm/...
>
> I enhanced DTF with some useful messages and error/status output. IIRC the
> "original" version produced no messages at all.
>
> (1) above, I'm not averse to thinking there may be more than meets the eye
>> with this issue.
>>
>> So in a nutshell:  Anyone used a TC11 on a later PDP-11 (like the 11/44)?
>> Anyone have any thoughts on the diagnostics and formatter issues?
>>
>
> I have a TC11 with TU56 on our 11/34. Did you check the WRTM/WALL switches?



Yep, even ran DTF with them flipped the other way around out of
superstition :).

Now that I've gotten the full suite of diagnostics to run, the problem
seems to be that the TC11 isn't reading properly in reverse -- Tests
15,16,21,22,26,27 and 34 of ZTCD fail, all others pass (modulo a marginal
block on the tape causing a failure here and there).  This would probably
explain why DTF fails immediately after writing T, since it works in
reverse from that point...

Time to sit down with the schematics and figure out where the problem may
lie.

Thanks, all,
- Josh


>
>
> Christian
>

Re: General TC11 DECtape diagnostic/formatter questions

[Paul Koning]

> On Nov 9, 2016, at 3:59 AM, Christian Corti 
>  wrote:
> 
> On Tue, 8 Nov 2016, Josh Dersch wrote:
>> with the TC11 system," and I haven't managed to find it. I *have* found
>> this:
>> http://mirrors.pdp-11.ru/inf.informatik.uni-stuttgart.de/pdp11/dtf.mac
> 
> ... which is simply a mirror of our FTP server at
> ftp://ftp.informatik.uni-stuttgart.de/pub/cm/...
> 
> I enhanced DTF with some useful messages and error/status output. IIRC the 
> "original" version produced no messages at all.

That sounds right.  The convention of the paper tape era diagnostics is that 
errors are reported by halts at specific (documented) addresses, sometimes with 
specific values in R0.

paul

Re: General TC11 DECtape diagnostic/formatter questions

[Christian Corti]

On Tue, 8 Nov 2016, Josh Dersch wrote:

with the TC11 system," and I haven't managed to find it. I *have* found
this:
http://mirrors.pdp-11.ru/inf.informatik.uni-stuttgart.de/pdp11/dtf.mac


... which is simply a mirror of our FTP server at
ftp://ftp.informatik.uni-stuttgart.de/pub/cm/...

I enhanced DTF with some useful messages and error/status output. IIRC the 
"original" version produced no messages at all.



(1) above, I'm not averse to thinking there may be more than meets the eye
with this issue.

So in a nutshell:  Anyone used a TC11 on a later PDP-11 (like the 11/44)?
Anyone have any thoughts on the diagnostics and formatter issues?


I have a TC11 with TU56 on our 11/34. Did you check the WRTM/WALL 
switches?


Christian

Re: General TC11 DECtape diagnostic/formatter questions

[Josh Dersch]

On 11/8/16 1:43 PM, Noel Chiappa wrote:


 > From: Josh Dersch

 > If I run them on SIMH configured as an 11/44, I see the same behavior.
 > If I run them on SIMH configured as an 11/20, then I get the printout
 > described in the documentation and listings. ... I haven't yet dug in
 > to see what accounts for the difference -- any ideas?

The fact that the simulator produces identical results to the real hardware
would argue that it's not a bug in that particular hardware. So it must be
some real difference between the two.

There are subtle differences between the 11/20, and other 11's - e.g. on the
/20 SWAB does't clear the V bit - maybe it's one of them? It might be worth
trying setting the CPU type to other values, and see if it works on any other
machine type.
Turns out it's the XXDP XM monitor causing the issues (I would wager 
that it sets up the MMU in such a way that older diagnostics don't deal 
well).  If I run it under the SM Monitor it works.  Whew :).




 > 2) I'm looking for means to format DECtapes on the TC11. ... The
 > maintenance manual only indicates "a special program supplied with the
 > TC11 system," and I haven't managed to find it.

The UNIX V6 distro includes a standalone program, tcf.s, to format DECtapes.
I don't know if you have a running V6 system (real or emulated) to assemble
it one; if you want me to assemble it and provide it as binary (in a variety
of formats, e.g. .LDA format), let me know.


I could probably get a V6 distribution running if I need to, but if you 
have the means to do so easily, that would be handy so I can at least 
have another tool to try out.  Something that XXDP can load would be useful.


Thanks,
Josh



Noel

Re: General TC11 DECtape diagnostic/formatter questions

[Noel Chiappa]

> From: Josh Dersch

> If I run them on SIMH configured as an 11/44, I see the same behavior.
> If I run them on SIMH configured as an 11/20, then I get the printout
> described in the documentation and listings. ... I haven't yet dug in
> to see what accounts for the difference -- any ideas?

The fact that the simulator produces identical results to the real hardware
would argue that it's not a bug in that particular hardware. So it must be
some real difference between the two.

There are subtle differences between the 11/20, and other 11's - e.g. on the
/20 SWAB does't clear the V bit - maybe it's one of them? It might be worth
trying setting the CPU type to other values, and see if it works on any other
machine type.

> 2) I'm looking for means to format DECtapes on the TC11. ... The
> maintenance manual only indicates "a special program supplied with the
> TC11 system," and I haven't managed to find it.

The UNIX V6 distro includes a standalone program, tcf.s, to format DECtapes.
I don't know if you have a running V6 system (real or emulated) to assemble
it one; if you want me to assemble it and provide it as binary (in a variety
of formats, e.g. .LDA format), let me know.

Noel

Re: General TC11 DECtape diagnostic/formatter questions

[Josh Dersch]

On Tue, Nov 8, 2016 at 12:54 PM, Paul Koning  wrote:

>
> > On Nov 8, 2016, at 3:37 PM, Josh Dersch  wrote:
> >
> > Hi all --
> >
> > ...
> > 2) I'm looking for means to format DECtapes on the TC11.  I have a few
> > marginal tapes and I'd like to see if reformatting them brings them back
> to
> > life.  The maintenance manual only indicates "a special program supplied
> > with the TC11 system," and I haven't managed to find it. I *have* found
> > this:
> > http://mirrors.pdp-11.ru/inf.informatik.uni-stuttgart.de/pdp11/dtf.mac
> > which I've assembled and run on RT-11 and it goes through the motions of
> > writing out the timing and mark tracks, but when it goes through the
> second
> > pass to write out the block numbers it fails immediately, with either
> > status 001207 (indicating a "Data Missed" error) or 020033 (Mark Track
> > Error).  I haven't yet hooked up a scope to see if the T tracks are
> > *actually* being written, but given my experience with the diagnostics in
> > (1) above, I'm not averse to thinking there may be more than meets the
> eye
> > with this issue.
> >
> > So in a nutshell:  Anyone used a TC11 on a later PDP-11 (like the 11/44)?
> > Anyone have any thoughts on the diagnostics and formatter issues?
>
> In college I used them on 11/20 and 11/45 processors with no troubles.
> And I think at DEC we had them on an 11/70.  In any case, there's no reason
> to expect trouble based on the CPU type.
>

Beyond the XXDP diags not running properly ;).  Some further
experimentation reveals that if I set the system memory to 64KW or less,
the ZTCA, etc. diagnostics run as expected.  Forcing the XXDP disk to boot
the SM (vs. the XM) monitor makes things work even on a machine with >
64KW.  So that looks to be solved, fingers crossed.



>
> The standard DEC supplied formatting program was originally supplied as a
> paper tape diagnostic.  Way back in 1974 I rewrote it slightly so it would
> do the whole job in one pass, without asking you to reset switches, and it
> would also write proper empty directories (DOS style).  But the standard
> program should work fine, and the one you mentioned appears similar.
>
> It's sufficient to have both the WRTM and WALL enable switches set for the
> whole operation.  The official approach is to set WRTM (only) during the
> first pass, WALL (only) during the second, and no switches after that.  But
> having unnecessary switches set to enable is harmless.
>

Good to know, thanks!


>
> If you had a switch set wrong you'd get an invalid operation error.
> You're seeing some different code, which suggests either the mark or timing
> tracks weren't written properly, or that there's some issue with the read
> circuitry.  Yes, I would say it's time to hook up the scope and start
> tracing some signals.
>

Yep.  Hopefully with the newfound ability to run the real diagnostics, this
will be a bit easier.  I'm guessing the read circuits are OK (since I am
able to use pre-formatted tapes without issue).



>
> If you have a tape believed to be good that you're willing to erase, you
> might try reformatting that one.  That would help rule out issues caused by
> bad media.  While it is very rare for DECtape media to fail to the point
> that formatting doesn't work, it *is* possible.
>

The tape I'm trying to format had a handful of bad blocks, none near either
end of the tape (where the error in formatting occurs).  So I think the
media can be eliminated from the set of possible problems here.

Thanks again,
Josh



>
> paul
>
>
>

Re: General TC11 DECtape diagnostic/formatter questions

[Paul Koning]

> On Nov 8, 2016, at 3:37 PM, Josh Dersch  wrote:
> 
> Hi all --
> 
> ...
> 2) I'm looking for means to format DECtapes on the TC11.  I have a few
> marginal tapes and I'd like to see if reformatting them brings them back to
> life.  The maintenance manual only indicates "a special program supplied
> with the TC11 system," and I haven't managed to find it. I *have* found
> this:
> http://mirrors.pdp-11.ru/inf.informatik.uni-stuttgart.de/pdp11/dtf.mac
> which I've assembled and run on RT-11 and it goes through the motions of
> writing out the timing and mark tracks, but when it goes through the second
> pass to write out the block numbers it fails immediately, with either
> status 001207 (indicating a "Data Missed" error) or 020033 (Mark Track
> Error).  I haven't yet hooked up a scope to see if the T tracks are
> *actually* being written, but given my experience with the diagnostics in
> (1) above, I'm not averse to thinking there may be more than meets the eye
> with this issue.
> 
> So in a nutshell:  Anyone used a TC11 on a later PDP-11 (like the 11/44)?
> Anyone have any thoughts on the diagnostics and formatter issues?

In college I used them on 11/20 and 11/45 processors with no troubles.  And I 
think at DEC we had them on an 11/70.  In any case, there's no reason to expect 
trouble based on the CPU type.

The standard DEC supplied formatting program was originally supplied as a paper 
tape diagnostic.  Way back in 1974 I rewrote it slightly so it would do the 
whole job in one pass, without asking you to reset switches, and it would also 
write proper empty directories (DOS style).  But the standard program should 
work fine, and the one you mentioned appears similar.

It's sufficient to have both the WRTM and WALL enable switches set for the 
whole operation.  The official approach is to set WRTM (only) during the first 
pass, WALL (only) during the second, and no switches after that.  But having 
unnecessary switches set to enable is harmless.

If you had a switch set wrong you'd get an invalid operation error.  You're 
seeing some different code, which suggests either the mark or timing tracks 
weren't written properly, or that there's some issue with the read circuitry.  
Yes, I would say it's time to hook up the scope and start tracing some signals.

If you have a tape believed to be good that you're willing to erase, you might 
try reformatting that one.  That would help rule out issues caused by bad 
media.  While it is very rare for DECtape media to fail to the point that 
formatting doesn't work, it *is* possible.

paul

Re: General TC11 DECtape diagnostic/formatter questions

[Al Kossow]

On 11/8/16 12:37 PM, Josh Dersch wrote:
> I've assembled and run on RT-11 and it goes through the motions of
> writing out the timing and mark tracks, but when it goes through the second
> pass to write out the block numbers it fails immediately

Did you set the switch on the controller front panel to enable the clock track 
writing?