pbirkel@gmail.com
Veteran Member
That is absolutely amazing treatise; many thanks for bringing it to our (or at least *my*) attention Al!
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
TU56 Restoration
- Thread starter bobaboba
- Start date
That is absolutely amazing treatise; many thanks for bringing it to our (or at least *my*) attention Al!
That's been my recent experience too! although on the current TD8E anything and everything has been damaged. I think the board may have possibly have been inserted backwards at some time.
Yes, I have already been caught out by that
and spent a while looking for a non-fault.This would have been much harder without Vince's schematics as the originals I've been able to find have been pretty illegible. Luckily the write up in the maintenance manual is comprehensive.
I've had to replace every IC connected to the TU56 interface cable now (latest is a 8242 which is nearly working but has a bad '1' level which intermittently fails to propagate the timing track. I tried pulling it up a bit harder but very little difference for a significant additional load. I don't have one so things have stalled again while I go and find one. This fault had me stuck for a while because any time I checked it on the scope it seemed OK but what has been happening is that it drops timing pulses from time to time depending on (I suppose) noise on the rails.
I've also had to replace over half of the omnibus interface ICs as well as a scattering of others so goodness only knows what has happened to this TD8E board in the past. I've now replaced 18 ICs (including one - a 7474 - which was actually working but I guessed the fault wrong ;o( ).
I notice that one of the TU56 drives is slow to spin up. Actually the motor spins up just fine if the tape hub is removed so something is binding but it isn't obvious yet quite what - the hub mounts up to a positive stop, no adjustment, so I'm supposing that it can't be that?
I've also had to replace over half of the omnibus interface ICs as well as a scattering of others so goodness only knows what has happened to this TD8E board in the past. I've now replaced 18 ICs (including one - a 7474 - which was actually working but I guessed the fault wrong ;o( ).
I notice that one of the TU56 drives is slow to spin up. Actually the motor spins up just fine if the tape hub is removed so something is binding but it isn't obvious yet quite what - the hub mounts up to a positive stop, no adjustment, so I'm supposing that it can't be that?
Found the problem with the slow TU56 drive. I couldn't understand why the motor spun fine but when I mounted the hub tight back to a 17 thou feeler gauge it became sticky. Turned out that the spring-loaded brass bush behind the hub was dry of lubricant and when the hub pushed it back on the spindle it got to a place where there was a slight buildup of corrosion. The extra load was enough to make the motor slow to start as there isn't all that much starting torque available.
Howeverrrr! while I was working on that, the drive to the spindle failed completely. Anddddd - when I swapped a couple of modules around to try to localise the problem I seem to have caused another failure which broke the other spindle! So for now the TU56 only has the other transport working but it shouldn't be a difficult fix as long as the motors are OK so I'll concentrate on getting some tape I/O to the TD8E before I worry about it.
Howeverrrr! while I was working on that, the drive to the spindle failed completely. Anddddd - when I swapped a couple of modules around to try to localise the problem I seem to have caused another failure which broke the other spindle! So for now the TU56 only has the other transport working
but it shouldn't be a difficult fix as long as the motors are OK so I'll concentrate on getting some tape I/O to the TD8E before I worry about it.I now remember that I had a similar problem with my TU56, you could rotate it a bit by hand but it would spring back when released, the spring on the shaft was seized. When you put the hub back on the shaft it needs to be just a fraction "out" not pushed hard back, DEC have a small plastic thingy to get the space correct, I can dig it out and lend it to you if you like.
As you are obviously back I will also send the PCB we were discussing of list.
Dave H
Thanks DaveH. I think the hub position is OK. The manual says 0.017" clearance from the brass boss on the front plate and I have set this with a feeler gauge (still have an old imperial one in the toolbox). The problem was the spring loaded bush behind the hub which I think is there to take up any float.
Let me know what you want for the PCBs.
Thanks, Bob.
Let me know what you want for the PCBs.
Thanks, Bob.
The TU56 saga has been slowly going on and I've picked it up again after the Christmas celebrations etc. I've made some progress and the unit now passes the diagnostics except for writing (it needs a formatted DecTape for that and I don't have one). However I can run the formatting program and it attempts to write the timing track but fails straightaway on read back.
Originally when I ran the diagnostics it would run through the tape displaying block numbers in each direction but now it displays garbage so I guess the formatting program has rewritten the timing track but incorrectly and the old data is now misaligned with it. I can see write signals when formatting. The unit still recognises the end-of-tape marks as it can repeatedly reverse at them so I think it is probably fairly simple - maybe the TD8E multiplexer isn't working properly on write. I've tried altering the number of blocks it tries to write and I end up with a tape which recognises end-of-tape in the appropriate place so at least the EOT end zone is writing correctly.
Yesterday the 8/E died again (sigh!). Don't know what the fault is yet, but single stepping a short program works correctly and running it normally goes awry. Joys of restoration.
Does anyone have a couple of dectapes they would be prepared to sell (preferably working pdp/8 format with a few files on)? It's very difficult to debug things without a known good tape and as I've already found a partly working unit easily screws up the tape format. I'm in the UK.
Originally when I ran the diagnostics it would run through the tape displaying block numbers in each direction but now it displays garbage so I guess the formatting program has rewritten the timing track but incorrectly and the old data is now misaligned with it. I can see write signals when formatting. The unit still recognises the end-of-tape marks as it can repeatedly reverse at them so I think it is probably fairly simple - maybe the TD8E multiplexer isn't working properly on write. I've tried altering the number of blocks it tries to write and I end up with a tape which recognises end-of-tape in the appropriate place so at least the EOT end zone is writing correctly.
Yesterday the 8/E died again (sigh!). Don't know what the fault is yet, but single stepping a short program works correctly and running it normally goes awry. Joys of restoration.
Does anyone have a couple of dectapes they would be prepared to sell (preferably working pdp/8 format with a few files on)? It's very difficult to debug things without a known good tape and as I've already found a partly working unit easily screws up the tape format. I'm in the UK.
m_thompson
Veteran Member
I had similar issues when debugging my TD8-E/TU56. I was not 100% sure that the processor was working OK, and not at all sure that the TD8-E and TU56 were working. I did have access to DECtapes that were formatted on an 8/I with a TC01, so at least I knew that the tapes were OK. I could move the tapes manually and look at the data from the tape head, then look at the data from the G888 modules. This is where I found a bad tape head. :-(
Detecting the End Zone only requires the Timing and Mark tracks, so at least that part is working.
I wrote some simple programs that helped with the debugging. One reads the console switches and writes the value to the Command Register. With that tool I could look at the Data Register to see if the data got from the tape to the controller, and then to the Omnibus. On mine, I found that the flip-flop for read/write would not set, so it would never go to write mode.
Formatting a tape is a little complicated. If your Timing and Mark tracks are OK on the tape you formatted, then at least your Mark Track Register and a good percentage of the timing logic is OK. It sounds like you didn't write the data tracks when formatting, so I would chase that logic. You could run the formatter again and see if the data ia actually making it to the G888 modules and to the heads.
I also found that a 74123 Retriggerable Monostable Multivibrator is used to create the clock signal to write the timing track on a new DECtape. Mine was running at a 4.5 μs interval and should have been 8.2 μs. Adjusting the trimpot fixed that.
I added a second serial port and used Kyle Owen's serial disk server to boot OS/8. At that point it was very easy to run diags to prove that the processor was working OK.
Detecting the End Zone only requires the Timing and Mark tracks, so at least that part is working.
I wrote some simple programs that helped with the debugging. One reads the console switches and writes the value to the Command Register. With that tool I could look at the Data Register to see if the data got from the tape to the controller, and then to the Omnibus. On mine, I found that the flip-flop for read/write would not set, so it would never go to write mode.
Formatting a tape is a little complicated. If your Timing and Mark tracks are OK on the tape you formatted, then at least your Mark Track Register and a good percentage of the timing logic is OK. It sounds like you didn't write the data tracks when formatting, so I would chase that logic. You could run the formatter again and see if the data ia actually making it to the G888 modules and to the heads.
I also found that a 74123 Retriggerable Monostable Multivibrator is used to create the clock signal to write the timing track on a new DECtape. Mine was running at a 4.5 μs interval and should have been 8.2 μs. Adjusting the trimpot fixed that.
I added a second serial port and used Kyle Owen's serial disk server to boot OS/8. At that point it was very easy to run diags to prove that the processor was working OK.
Success??
I think that I have got my TU56/TD8E working!
I found that the IC (quad EX-NOR) which receives the Timing Track signal on the TD8E was faulty. Worked logically OK, but was prone to generate occasional spikes from power supply noise, and was occasionally generating a spike on the trailing edge of the noise-blanking monostable which retriggered the monostable and upset the timing sequence. Replacing the IC has fixed things I think. I couldn't find the correct replacement, but a 74LS266 seems to drop in OK.
This was an absolute sod to find as it was infrequent and random. I eventually found it by working painstakingly through logic analysis captures to find the error on the mono signal, then deducing where the spike was coming from. The spike itself was too narrow for my logic analyser to see but after it had passed through a couple of gates it became (just) visible.
I only have 1 rather damaged DecTape and it fails to format but I think this is the fault of the tape itself. I was able to patch the formatting program to write a shorter pattern and start it off well into the middle of the tape and this worked OK. Not only that, but I was able to zero the directory in OS/8 and write/read a few files. This isn't perfect of course because the tape is actually shorter than OS/8 thinks it is but I think it proves that with a good tape it will be fine.
A collector in the UK has kindly offered me a couple of tapes so I think I will soon be up and running.
The remaining problem is that only 1 of the TU56 drives is functioning, the motors on the other side don't run. This seems a trivial problem though so I expect to fix it in short order.
Overall, pretty chuffed!
I think that I have got my TU56/TD8E working!
I found that the IC (quad EX-NOR) which receives the Timing Track signal on the TD8E was faulty. Worked logically OK, but was prone to generate occasional spikes from power supply noise, and was occasionally generating a spike on the trailing edge of the noise-blanking monostable which retriggered the monostable and upset the timing sequence. Replacing the IC has fixed things I think. I couldn't find the correct replacement, but a 74LS266 seems to drop in OK.
This was an absolute sod to find as it was infrequent and random. I eventually found it by working painstakingly through logic analysis captures to find the error on the mono signal, then deducing where the spike was coming from. The spike itself was too narrow for my logic analyser to see but after it had passed through a couple of gates it became (just) visible.
I only have 1 rather damaged DecTape and it fails to format but I think this is the fault of the tape itself. I was able to patch the formatting program to write a shorter pattern and start it off well into the middle of the tape and this worked OK. Not only that, but I was able to zero the directory in OS/8 and write/read a few files. This isn't perfect of course because the tape is actually shorter than OS/8 thinks it is but I think it proves that with a good tape it will be fine.
A collector in the UK has kindly offered me a couple of tapes so I think I will soon be up and running.
The remaining problem is that only 1 of the TU56 drives is functioning, the motors on the other side don't run. This seems a trivial problem though so I expect to fix it in short order.
Overall, pretty chuffed!
m_thompson
Veteran Member
Its a really good feeling to finally overcome the last fault and get an ancient machine running again. The motor problem is not an intermittent, so that should be pretty easy for you to debug. You can always swap boards from one drive to the other to localize the problem.
I got diverted by my FPGA on the Omnibus project so I haven't touched the TD8/E and TU56 for a while. I borrowed a tape head from a TU56 on a PDP-11, but I will eventually have to give it back. Haven't found a spare yet.
I have a new project to image about 200 LINC tapes. We don't have the TC12 controller on the museum's PDP-12 working perfectly yet, so I was considering writing a program on the 8/e. Since the TD8/E is really dumb I should be able to just read everything, buffer it, and send it out the serial port. If I fake a serial port with the FPGA the speed is nearly unlimited.
I got diverted by my FPGA on the Omnibus project so I haven't touched the TD8/E and TU56 for a while. I borrowed a tape head from a TU56 on a PDP-11, but I will eventually have to give it back. Haven't found a spare yet.
I have a new project to image about 200 LINC tapes. We don't have the TC12 controller on the museum's PDP-12 working perfectly yet, so I was considering writing a program on the 8/e. Since the TD8/E is really dumb I should be able to just read everything, buffer it, and send it out the serial port. If I fake a serial port with the FPGA the speed is nearly unlimited.
Nice one Bob, that faulty XOR sounded like a real so and so to track down, I do like hard faults. Im currently working on a DK8 RTC, umpteen good passes on the Maindec one day, loades of errors the next, what fun.
DaveH
DaveH
Last edited:
Not always such a good idea though! Since if you're unlucky whatever caused the first board to die might also kill the other one when you swap them.
Since I'm basically a bit of an optimist (and a bit idle too) I've already been bitten by this one.
Originally one of the motors on the first drive seemed to stutter a bit, then it got worse, then it stopped spinning altogether.
So I swapped the cards from the good motor to the bad one one at a time to try to localise the problem.
Now neither motor works so I surmise that I have replicated the original fault.
m_thompson
Veteran Member
Check the front panel switches on the TU56. If they don't work, the motors don't work. On the PDP-12 the motors didn't work at all. The Remote/Local switch needed cleaning to get Local to activate and turn on the motors. Then the Forward/Reverse would not work. More switch cleaning fixed that.
Fixed the motor drive problems. One of the controllers had both transistors on one side of the H-bridge blown short and that had in turn blown the fuse on the motor supply board. Blew the other fuse too when I swapped cards over so no big deal. The motors run fine now. Rather surprised that the power transistors had gone as they are generally quite rugged. Didn't even manage to achieve their design goal of protecting the fuse .
Fixing the board only took about 15 minutes but it took me a couple of hours first to trace the circuit from the pcb. My cards are the older double height boards as opposed to the triple height documented in the available TU56 maintenance manuals. Lots of detail design differences as well as quite different physically.
Next problem seems to be with relays. One drive works fine and swapping its relay board to the other side lets the other side work fine too so at least 1 of the original relays on that drive is stuck. Haven't worked through it yet but tapping the relays to try to free them off hasn't fixed things.
Anyone know if it's still possible to get suitable replacements anywhere or is it just a matter of drilling new holes for whatever I can find?
.Fixing the board only took about 15 minutes but it took me a couple of hours first to trace the circuit from the pcb. My cards are the older double height boards as opposed to the triple height documented in the available TU56 maintenance manuals. Lots of detail design differences as well as quite different physically.
Next problem seems to be with relays. One drive works fine and swapping its relay board to the other side lets the other side work fine too so at least 1 of the original relays on that drive is stuck. Haven't worked through it yet but tapping the relays to try to free them off hasn't fixed things.
Anyone know if it's still possible to get suitable replacements anywhere or is it just a matter of drilling new holes for whatever I can find?
Last edited:
Marty
Veteran Member
Hi All;
Bobaboba, a Picture of said Relay, for those of us not knowing what You are looking for, would help tremendously.. Maybe someone has something Similar laying around, that could be just what You need..
THANK YOU Marty
Bobaboba, a Picture of said Relay, for those of us not knowing what You are looking for, would help tremendously.. Maybe someone has something Similar laying around, that could be just what You need..
THANK YOU Marty
m_thompson
Veteran Member
We found another bad TU56 tape head when debugging the PDP-12 today.
Yes, I'll do that later today. Didn't have a camera handy when I discovered the problem last night. I don't think the relay type is particularly critical but it's always nice to use a proper replacement on these old things rather than just a modern component. (I think anyway).
Fixed the motor drive problems. One of the controllers had both transistors on one side of the H-bridge blown short and that had in turn blown the fuse on the motor supply board. Blew the other fuse too when I swapped cards over so no big deal. The motors run fine now. Rather surprised that the power transistors had gone as they are generally quite rugged. Didn't even manage to achieve their design goal of protecting the fuse
Fixing the board only took about 15 minutes but it took me a couple of hours first to trace the circuit from the pcb. My cards are the older double height boards as opposed to the triple height documented in the available TU56 maintenance manuals. Lots of detail design differences as well as quite different physically.
Next problem seems to be with relays. One drive works fine and swapping its relay board to the other side lets the other side work fine too so at least 1 of the original relays on that drive is stuck. Haven't worked through it yet but tapping the relays to try to free them off hasn't fixed things.
Anyone know if it's still possible to get suitable replacements anywhere or is it just a matter of drilling new holes for whatever I can find?
Repairing vintage gear with vintage or vintage equivalent parts is sometimes preferred. But if you choose or are forced by part availability to put in more modern parts I would go with something solid state rather than an actual "relay".
m_thompson
Veteran Member
You could write a program to select drive 0, wait a while, select drive 1, and repeat. If you let this run for a while it might burnish the relay contacts and let the signals go through.