failing the tape data test after passing Tape Control I & II

[Peter Peterson]

Hi all,

We're working on getting our two FCTs up and running at UMD. (That's a separate story.)

One of the reasons we are trying to get the FCT up and running is that we're having trouble with the Tape Data Test (having passed the first two tape tests). We fail the first checksum test, which I believe is E2. You have to use the assembly source for debugging, but the program is structured in a clever way to make this relatively easy. 

This test reads/writes data to the tape and checks the Tape Accumulator (TAC) against a computed and stored checksum to make sure the tape drive is working properly. The input to the pattern read/written is either the LSW & RSW or one of those if using the PRNG method rather than a fixed repeating method (that's an SNS switch option). Anyway, the stored checksum (visible in the AC upon failure) changes when we change the inputs (fixed or random), but the TAC value (which is rotated into the MQ from the TAC for easy comparison) is as far as I can tell, always 7377 regardless of the test input (see attached). 

We cleaned every M222 board and reseated them, which solved a previous tape control test failure (we cleaned the M304 responsible for the signal that was failing), but this did not help with the Tape Data Test.

My next plan is to clean everything involved with the TC12 (some of our cards have gotten quite dusty in two years), and also to try swapping some M222 board positions to see if that changes the value in our MQ. 

But it occurred to me that, having had much more experience with these machines, someone here might recognize something about this issue or have suggestions about how we could pursue this issue.

A couple of other salient points:

The tape unit is able to pass a Mark12 mark / check, which seems weird if the TAC is not working correctly, unless it somehow doesn't use the checksum in the same way?

I also verified that ROR (rotating from AC into the MQ works) by setting a value into the AC and rotating it one bit at a time using the DO switch -- rotates perfectly well. (Besides, now that I think of it, the comparison is actually between the AC and the stored checksum location, not the MQ... that's just for user convenience. But at least ROR works!)

Any ideas?

Peter

--

Peter A. H. Peterson, Ph.D.

Assistant Professor
Department of Computer Science

University of Minnesota Duluth

[Maury Pepper]

Other than the test program, is there anything else that's failing with respect to reading and writing tapes? I suspect not because after the first pass of marking, what follows just uses regular tape commands to write data to every block and then verify that every block reads properly.

When the test program halts, I would compare the AC with the stored checksum (using exam) to see if there's a pattern with the mismatch.

I'm pretty sure the value in the MQ should be 7777. Since it's 7377, that might be a clue.

Is the test program listing available online?

    -maury-

--
You received this message because you are subscribed to the Google Groups "PDP-12 Restoration Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pdp+uns...@d.umn.edu.

[CLASystems]

c

On Fri, May 17, 2019 at 1:51 AM Maury Pepper <mpe...@ieee.org> wrote:

Other than the test program, is there anything else that's failing with respect to reading and writing tapes? I suspect not because after the first pass of marking, what follows just uses regular tape commands to write data to every block and then verify that every block reads properly.

When the test program halts, I would compare the AC with the stored checksum (using exam) to see if there's a pattern with the mismatch.

I'm pretty sure the value in the MQ should be 7777. Since it's 7377, that might be a clue.

Sounds like a stuck bit on the particular flop that is bit[3] in the PDP-8 sense.  The MARK12 program may like what it does and gets fooled, but the failing program can use patterns,

Of all the adcacent modules that are the same M222, they are INTENDED to not need timing adjustments, i.e., are all TTL chips.  So, doing some swaps [you should remember the original positions!] should reveal if the pattern changes to a different predictable value.  If you get to the problem bit moving over, then by two independent swaps that both cause failure, only one module will be involved in both failures, and that's your baddie.

This is not a cleaning problem, it is a solid failure, etc.

Is the test program listing available online?

That would also be nice to help display exactly what went wrong when, but I would start with the assumption of a stuck bit problem which board swaps will show.

    -maury-

cjl

ps: I am seriously concerned to get a working machine, since it is still possible the RICM machine is not reliable reading for certain important LINCtapes.  Michael believes it is a local electrical noise problem and it is clearly unreliable [noise can be counted on to be truly random].  The machine was moved a short distance, suggesting a slight change in the noise POSSIBLY, could even be worse, hopefully better, or just the same, needs to be checked.

In any case, if your location is noise-free, which seems correct, then it is important to be able to fix the problems and I can authorize Michael to send you one of my tapes in question.  Fortunately there are several that are equivalent as far as my problem goes, getting an image of a LINC-8 mark program for which there is no source available!  If I can get the binary, I will disassemble it, etc. and I can indicate what I need dealt with, which is not all that much, etc.
When we finally get to an actual LINC-8 restoration, we will need these tapes as part of the process, etc.

The tape hardware of the LINC-8 is totally different, as it is in fact a built-in PDP-8 peripheral that shares format variations with the LINC and PDP-12 where the PDP-12 is a superset of the LINC and the LINC-8 is in fact a superset of both [you would suspect another order of things but it's true].

Oddly, the system I got the working program from writes INCOMPATIBLE LINCtapes because of blunders of the developers, and they never fixed the problem.  As such, the formatter correctly creates tapes that CANNOT be read, BUT can be written compatibly and THEN can be read.  They got the "polarity" of the take checksum exactly backwards but use software that EXPECTS that!  It was really quite a feat that I was ever able to retrieve the program in the first place!

Once I disassemble it, I will change the way it does the conventional post-markcd write and read to use standard format so all will be happy,  The present method is to use a generic P?S/8 block-oriented copy program to write out standard bit patterns and then read them back and compare.  That program works for any device that the system's handlers can access, and this includes both the 200 octal block tapes P?S/8 and OS/8 require on both machines and the standard 256 word format needed on all classic LINC systems (and PDP-12 DIAL as well).

Also, I should be able to get a P?S/8 for PDP-12 LINCtape up with some effort.  I have not tried because of your predicament and Michaels other ruinous problems.  He ignores it because he has two other devices RX and RK and all but the tape work fine.  I sent him a working RX system with my versions of the MARK12 and TC12F programs on it, but you have to have an RX01 to use it.  But I can make a similar version for PDP-12 but you need working LINCtape to create that system, then you can use all of P?S/8 on the PDP-12, although multiple drives are needed in certain instances.  But with PITA value, you can tediously fake that switching tapes  and tape drive units when it comes up.  Back in the days f Brooklyn Poly, we had only ONE TU55!

cjl

On 5/16/19 10:11 PM, Peter Peterson wrote:

Hi all,

We're working on getting our two FCTs up and running at UMD. (That's a separate story.)

One of the reasons we are trying to get the FCT up and running is that we're having trouble with the Tape Data Test (having passed the first two tape tests). We fail the first checksum test, which I believe is E2. You have to use the assembly source for debugging, but the program is structured in a clever way to make this relatively easy. 

This test reads/writes data to the tape and checks the Tape Accumulator (TAC) against a computed and stored checksum to make sure the tape drive is working properly. The input to the pattern read/written is either the LSW & RSW or one of those if using the PRNG method rather than a fixed repeating method (that's an SNS switch option). Anyway, the stored checksum (visible in the AC upon failure) changes when we change the inputs (fixed or random), but the TAC value (which is rotated into the MQ from the TAC for easy comparison) is as far as I can tell, always 7377 regardless of the test input (see attached). 

We cleaned every M222 board and reseated them, which solved a previous tape control test failure (we cleaned the M304 responsible for the signal that was failing), but this did not help with the Tape Data Test.

My next plan is to clean everything involved with the TC12 (some of our cards have gotten quite dusty in two years), and also to try swapping some M222 board positions to see if that changes the value in our MQ. 

But it occurred to me that, having had much more experience with these machines, someone here might recognize something about this issue or have suggestions about how we could pursue this issue.

A couple of other salient points:

The tape unit is able to pass a Mark12 mark / check, which seems weird if the TAC is not working correctly, unless it somehow doesn't use the checksum in the same way?

I also verified that ROR (rotating from AC into the MQ works) by setting a value into the AC and rotating it one bit at a time using the DO switch -- rotates perfectly well. (Besides, now that I think of it, the comparison is actually between the AC and the stored checksum location, not the MQ... that's just for user convenience. But at least ROR works!)

Any ideas?

Peter

--

Peter A. H. Peterson, Ph.D.

Assistant Professor
Department of Computer Science

University of Minnesota Duluth

--
You received this message because you are subscribed to the Google Groups "PDP-12 Restoration Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pdp+uns...@d.umn.edu.

--
You received this message because you are subscribed to the Google Groups "PDP-12 Restoration Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pdp+uns...@d.umn.edu.

--

"In the future, OS/2 will be on everyone's desktop"

Bill Gates, 1992

[Peter Peterson]

Hi all,

Thanks for your ideas. You had good instincts. We cleaned and reseated everything (swapping cards as suggested) but it did not solve the problem. We ran the flip chip tester on the cards we could, and the FCT suggested that the cards were fine. We also discovered that the bit in question is part of the extended tape operations buffer -- we wrote a short program to copy RSW into the AC, copy to the XOB and then back from the XOB into the AC. The result was that yes, bit 3 (I think -- Julian?) was not being set properly. Unfortunately, it was not being set properly only about 3/4 of the time. 

We scoped the signals and found that if we flexed the backplane door a certain way, the problem disappeared. If left to its own devices, it (generally) fails about 3/4 of the operations.

Julian has ordered a little dummy flip chip we can plug into a card slot so that we can test the card slot.

Has anyone had this issue before? We aren't sure, but it seems like either the connections in the slot are flaky, or (gulp) maybe there's a problem with the wire wrap?

Charles, I'm hopeful that once we get this worked out, we would be very happy to archive any tapes you (or anyone else) have.

Thanks,

Peter

[CLASystems]

On Sat, Jun 15, 2019 at 11:09 AM Peter Peterson <pa...@d.umn.edu> wrote:

Hi all,

Thanks for your ideas. You had good instincts.

We've been doing this for a long while :-).

We cleaned and reseated everything (swapping cards as suggested) but it did not solve the problem. We ran the flip chip tester on the cards we could, and the FCT suggested that the cards were fine. We also discovered that the bit in question is part of the extended tape operations buffer -- we wrote a short program to copy RSW into the AC, copy to the XOB and then back from the XOB into the AC. The result was that yes, bit 3 (I think -- Julian?) was not being set properly. Unfortunately, it was not being set properly only about 3/4 of the time. 

We scoped the signals and found that if we flexed the backplane door a certain way, the problem disappeared. If left to its own devices, it (generally) fails about 3/4 of the operations.

Julian has ordered a little dummy flip chip we can plug into a card slot so that we can test the card slot.

You should get a card extended.  Is this card a single-slot or a dual-slot?  But yes, you have to be able to prove continuity is certain.

Has anyone had this issue before? We aren't sure, but it seems like either the connections in the slot are flaky, or (gulp) maybe there's a problem with the wire wrap?

There are various things to be tried, not to worry.

The contacts of the slot can be cleaned with pipe-cleaners to see if that changes anything.  Can just be a fatal amount of oxide.  You can also spray the slot carefully but MUST use a NON-RESIDUE kind of contact cleaner, or you are making things seriously worse!  Pipe cleaners are the safest!

In rare cases, the wrap is bad, but that is not likely,  And still not sure the card is found not guilty - not quite yet.  Or did you swap that module as well?

As John Paul Jones once said, I have just begun to fight!

Charles, I'm hopeful that once we get this worked out, we would be very happy to archive any tapes you (or anyone else) have

That's actually two different projects from two different people.

If I can get a fire lit under the RICM, the goal is to get one of the LINC-8s to be restored.  This is far more work currently than what you need, I don't see anything that complicated for you.

That said, the LINC-8 has an advantage over the PDP-12 regarding LINCtapes:

The tape drives are from the original LINC.  They simply DO NOT HAVE all the adjustments and other areas that DEC got into trouble with only to make so many mistakes and blunders, only to in theory gain about 20 percent performance improvement.  These drives do NOT have powerful motors, instead they are tooth-belt driven shafts that go back to tooth-pulleys on much smaller motors.  The guides are one solid block and nothing to either wear out either the guide nor the tapes!  No one ever deskews the heads because they were factory set. it if ain't broke, don't fix it.  The tapes transfer by program transfer like a TD8E, not by DMA, and as such, software doesn't have anything "interfering" with the often too-automatic hardware, so you can deal with relevant issues, etc.  There are a lot more cycles between word transfers so it is far more forgiving than the analogous problem in the TD8E world, etc.

And as a side issue, the modifications to the LINC-8 allow reading and writing of DECtapes FAR more reliably than PRTC12F, etc. [Not that it is a problem directly as there are adequately working DECtape-based machines, etc.

I have a small core of LINCtapes that must get read, and Michael Thompson has them all.  The jury is still out if their PDP-12 can read tapes reliably at all; in their opinion the problem is a bad noise problem in the AC lines that is pervasive to the room the machine WAS in!  Yes, WAS, as they have recently  moved and as of last week, not gotten around to testing the extent of the problem in the new home, which is a building over, etc.  AC problems can be tricky; sometimes it's even only a matter of rotating the machine 90 degrees relative to nearby wiring, but not reasonable to tweak the machine position to minimize the problem, etc.  So,I have to see how this pans out, etc.

The LINC-8 design will very likely be more immune to the problem inherently, etc.

The tapes in question are needed to be imaged on a way I can get to, and convenient would be to make images onto an .RK05 image file we can e-mail around so I can open it in SIMH.  My KERMIT-12 utilities can read the tapes through the normal LINCtape OS/8 handlers and create an image file of the entire tape.  Being OS/8-worthy is NOT a requirement, just the underlying media is the same.  All but P?S/8 and OS/8 use 256 words/block LINCtapes; these two use 128 words/block LINCtapes, but it is hard to get proper tape formatting  programs that actually do the job!  This is because in total ignorance, the writers of the DIAL-based formatting programs ASSUMED they should be 129 words despite there being ZERO software that uses that format!

Thus, what we do in the PDP-12 in both P?S/8 and OS/8 is TOLERATE a superfluous 129th word that actually has literally all negatives about its presence.
All P/S/8 and OS/8 PDP-12 LINCtape handlers have special internal waste software that assumes the destruction causes by the presence of the extra word, saves the old word, and then restores it after the transfer of the latest block is done.  This repeats for every block transferred, etc.  If it were CERTAIN it was 1 28 words, then this could be eliminated [Note: In P?S/8 for the TC12, there are other additional nuisances beyond that which affects OS/8 b but it is for the same pathetic base reason.

Towards that end, I released to RICM P?S/8 for RX01 with MODIFIED versions of both the PRTC12F and MARK12 programs that run under P?S/8 and DO NOT have the blunder; it is strictly 128 words/block in all contexts, etc.

Of course, the originals are on an old version of P?S/8 for the TC12, which, while very different in terms of overall system capability, from the stand point of merely executing the two programs, this is done trivially with a single command each; thus, to do so on either the old or the latest it's the same simple procedure, which is essentially typing in R the program name or in some cases leaving the R out entirely.  [Note: P?S/8 supports a form of concise command language, just not to be confused with that of OS/8 or TOPS-19.  This is precisely the same as COS-300.  You have to understand that all of these systems are "incestuous" because the same six or less people wrote all of them.  I can explain the historic details for anyone interested, but the short version is that R-L monitor came first, it was hacked up to become DIBOL-8 and DEC never knew they were selling something they didn't write nor own, and the only difference was the names of the commands were "futurized" so that when the real COS came out, they would be totally compatible.  Then, P?S/8, first being lockstep with R-L as we evolved gradually away from it, copies the same exact relevant commands as COS, thus, actually certain pages of the COS-300/310 manuals actually apply to P/S/8 directly.  [Note: Both systems support the concept of a BASIC-like line editor in the command level, so you are always potentially editing a file while you operate it, and do not need to overtly run an editing program.

There are two adjacent releases of that system, and one of each is at RICM.  From the standpoint of bootability to a TC12 system and to run the two LINCtape utilities, they are identical, etc.

Thus, if you get a copy of one of them, you should be able to a) Use it to format proper LINCtapes for OS/8 and P?S/8 usage, b) It also redundantly does what the DIAL program does regarding the "standard" 256 word tapes, and of course, using the OS/8 LINCtape handler for TC12 as it stands, create for me an image file of that tape itself using Ky'e's handler to update to an .RK05 file you can email to me directly, etc.  I can do the inverse if I have anything to send to you, etc.

There are important LINC-8 LINCtapes RICM has also that are for support of both OS/8 and P/S/8 on LINCtapes that are 128 words/block  They are vital to the restoration project because the source files are lost, but I can disassemble them as need be.  They are on bootable-to-modified LINC-8 128 words/block LINCtapes.  Note: The LINC-8 CANNOT read 129 words/block tapes without pointlessly special utilities being written [presumably to read from 129 words/block then write to 128 words/block\  ]I think you can understand the ramification of this blunder better now.]

One of the programs is the MARKL8 program for the LINC-8 that is not graphically interacted with.  It was hard to obtain from yet another LINC-8 system known as CPS-4K, not clear if any copies of that system exist any more.  [for the most part, no great loss, but it adds another wrinkle:  The standard format on CPS-4K is an INCOMPATIBLE CHECKSUM 128 words/block LINCtape!  Just to read a tape I once had was quite a chore.  They eventually realized their blunder and distributed a subroutine that could read or write standard or their reversed polarity checksum tapes, as if that was good enough and in fact NEVER corrected the problem!  [Just shows how much more important a SOFTWARE-controlled tape format is!  Needless to say, it is impossible to read CPS-4K tapes on a PDP-12!]

Thus, I want a copy of any of these LINC-8 bootable older P/S/8 tapes so I can disassemble that formatting program and perhaps make some small changes for use in a contemporaneous P?S/8 for the restored LINC-8 in the future.  The time frame is dependent on the RICM, but I am generally available on all of this, etc.

Maury Pepper is the one who wants to archive standard LINCtapes from a LINC.  It's the source code of very original LAP systems of historical significance.  to archive the files themselves individually represents many challenges because, unlike DIAL, these are NOT even in (six-bit) ASCII, but rather in early LINC keyboard code.  Thus, a "post processing" issue is to convert the files to be more like PDP-12 DIAL dual assembler language and format, etc.

That said, I have available the primary solution to archiving the tape:  P?S/8 supports a universal interchange data program that is block-number oriented, not filename oriented.  A truly copy these blocks to those blocks, and verify copy that it worked, etc. it's ideal for all of these things.  It supports the standard 256 word format tapes as well, so they could be read and then copied to say the 128 word format used by P?S/8 and OS/8, and then those blocks can get back to a wider archive world, etc. and any lower-level processing becomes "offline" to the original hardware transfer, etc.  In fact, some of the work I can do on SIMH on my Windows PC, etc.

Another P/S/8 utility exists called L6DCON, and it is also on either of those two bootable TC12 tapes.  What this does is a bi-directional conversion between DIAL source files and P/S/8 source files.  [And there is also OS8CON which is OS/8 source files to/from P?S/8 source files].

All of these programs play a role in these issues, etc.

Thanks,

Peter

cjl

Virus-free. www.avast.com

[Michael Thompson]

Wire-wrap is more reliable than soldered connections, so unlikely to be a problem.

Possibly one of the data cables between the heads and the controller?

--

[CLASystems]

On Sat, Jun 15, 2019 at 1:18 PM Michael Thompson <michael.9...@gmail.com> wrote:

Wire-wrap is more reliable than soldered connections, so unlikely to be a problem.

Possibly one of the data cables between the heads and the controller?

Absolutely NOT!

this is a problem NOT of even the tape drive at all!

The extended operations buffer is not transferring a bit in or out properly.  You don't even need a tape to perform this!

cjl

Virus-free. www.avast.com

[Peter Peterson]

We wondered about this, too, and also came to Charles' conclusion. We tried to clean the slots with deoxit but did not use pipe cleaners on the connections. That, and the extender card will be our next step.

Can we simply "tone" the backplane for continuity without damaging connected components, or what is the best (and safest) way of doing that?

Thanks.

[CLASystems]

Any modern low-voltage ohmmeter can be used to prove continuity between say a contact on a gold pin of a card-edge placed in the socket and the other lead clipped onto the pin.  The question right now is, how clean are the contacts and is anything transferring onto the gold pins [which can sorta be "erased" using  a method Michael Thompson will post; I spoke to him earlier.]

Also, is this a common card you should have already swapped, or a rare card you did not.  Something is intermittent in the scheme of things, and the wire-wrap is the most reliable and unlikely cause.

cjl