The TU58 tape unit

Another gift from Geert (thanks)!

This uses DC100 tapes that must be preformatted. I have a set of “new old stock” tapes still in cellophane, but it is more than likely that these tapes have completely perished by now. Despite that I would like to get the drive at least in technical good state again

Cleaning and repairing the cassette drives

First thing to attack is the drives themselves. Their capstan will have turned to very sticky and almost fluid goo. We need to remove the drives and scrape off the old rubber, and clean the metal part. The latter can be done with a bit of acetone, and you can use the motor of the drive as a small “lathe” by connecting it to a power supply. After that the capstan looks at least clean:

Next part is to replace the rubber. For this I 3D printed a ring in TPU with the inner diameter smaller than the capstan as to have a tight fit on it, making the drives look quite hip:

Testing the unit

The power supply was disconnected from the main PCB and switched on. Voltages were all fine

Next round was to test the device. For that we would need a PDP-11 or so, and that’s a bit of a lot of work to get running just to test these… The tu58 uses RS232 to connect to the computer, so I used and USB-to-RS232 cable and made a cable to connect that to the TU58. This uses a BERG connector which can be replaced by a 2x5 ribbon connector. Just press in a bit of ribbon cable and split that out to make the prerequisite connections to the 9-pin D connector of the USB cable, as follows:

(fix connection schema, I forgot to write down the pinout)

To test the device I wrote some Java code to talk with the serial port using the protocol described in the TU58 user guide. This worked fine, see the initial parts of the initialization here:

You can see the initial stream of INIT characters (the Et’s above) sent by the TU58. My program then sends a BREAK (represented as Nu) and two INIT characters to initialize the TU58 to which it responds with a CONT (the Dl). I then send a GET STATUS command packet which responds with SUCCESS, unit 0.

Next phase was to actually try to read a block. To do that I wrote the code to send the READ command. That, however, always failed:

Read tape 1 block 40 for 8192 bytes
ERROR: Unexpected end packet: [motorStopped], unit 1

While it answers this nothing happens: the motor is not running at all. So, something’s wrong. The wrongness is on both drives (0 and 1), they react the same.

Putting an oscilloscope on drive 1’s motor shows the following when we run the program:

This looks like one side of the motor is not being driven: both pulses are at about 12V; we would expect one to be at a higher voltage than the other.

One simple step is to test the drive transistors. I desoldered the D44C8 ones (NPN) and tested them with my chinese tester; they tested OK.

Next step is to follow the signals. To help with this I run the “read” command in a loop, with a second of wait in between.

Oscilloscope measurements

Yellow: Base of Q15.

Light blue: Pin 11 E8, called F H. This indicates we’re not moving forward

Purple: Pin 3 E10. This is the exit of a NAND of RUN H and R H. It drives Q15 which is a PNP power transistor whose emitter is at 12V and its collector is at pin 6 of the motor (which is the BLACK connector of the motor. We see it going DOWN when the read command is issued, which should mean that it drives the black line to +12V. This also indicates that the tu58 wants to go REVERSE.

Dark blue: Pin 3 E8. This is the R H signal, again an indication that the drive wants to REVERSE.

This seems to indicate that the pin 6 part of the drive motor is driven to +12V properly, and that the Pin 5 part of the motor is not driven (considering the motor image above).

Considering the schematic the opposite side should drive Q13 through Q14. These are driven by a 7406 OC inverter (pin 11 = F H, pin 10 drives base Q14. This should work as follows:

• F H is low (as we’re reversing). So Pin 10 should be open, and driven to a + voltage, causing Q14 to start conducting, causing Q13 to do the same.

Next image:

Yellow: base of Q13, stays at 0 → this means the - side of the reverse action is not driven as we saw.

Blue: Pin 11 of E8 the 7406 (F H, input). This is a noisy LOW,

Purple: Pin 10 of E8, driving the transistors.

For some reason we do not get pin 10 of E8 high. Looking at the schematic there is a single circuit that controls the voltage on all outputs of E8 which is related to the speed control. The output of E15 pin 7 (called “Servo Amp”) is connected to a 2.4/2.4K network to all outputs. If this remains low it might cause this problem, so let’s take a look at its in- and outputs.

Yellow: E15 pin 5 , Blue pin 6 , purple pin 7 (output).

It looks like the + line here is at quite a higher voltage than the - line - so why is the output so low?

Let’s try to cut R64 to remove the feedback loop and see if this makes the motor run.. This resistor is not numbered correctly (apparently) on the component overview; it can be found immediately under C46 between the two resistor arrays.

Dark blue is now the basis of Q13. Cutting the resistor had no effect, sigh.

Checking E8 pin 10 again at least shows something (purple trace):

Still a very low voltage,

Putting the yellow trace on the collector of E14. This should show the +12V voltage from the “other” side switching on, and it does:

Next part is to find out why the output of pin 10 stays so low. What I tried:

• Remove Q14. No effect.

• Replace 7406 with a new one. No effect.

This requires a bit more thinking 8-/.