Tektronix 4097 GPIB 8" Floppy Drive

[Tony Duell]

> 
> 
> Hello, all,
> 
> I realize that this is likely a shot in the dark, but if there's any

Be warned that I have (alas) nevr seen one of these units, so what i am 
going to say is going to be very general. But it might help

> please that I might find some help, it's going to be here.  There isn't
> much Tektronix information out there.
> 
> I recently received a Tektronix 4051 in very nice shape, fully
> operational.  Along with that, a slew of cartridge tapes, ROMPacks, two

Nice find!

> Joysticks, and a Tek 4907 8" Floppy Disc subsystem.  The 4907 connects
> to the 4051 via GPIB, and there's a "File Manager" ROMPack that goes
> into a ROM Backpack slot to provide the code to the 4051 to drive the
> floppy system.
> 
> The 4907 has a built in controller based on a Motorola 6800 CPU that
> handles the GPIB communications, running the floppy drive, and
> everything necessary to make the drive an intelligent peripheral.
> 
> The 4907 is in nice shape...everything inside is very clean.  Power
> supply voltages are all where they should be, with minimal ripple.   The
> controller is a set of two boards.  The bottom board, fairly large,
> contains the CPU, RAM, and all of the stuff for the GPIB interface and
> floppy drive interface.  The top board, connected by a ribbon cable,
> appears to contain ROM that contains the 6800 code that runs the
> controller. Oddly, there is one chip missing in this top board, a
> socketed part.  I don't know if it's *supposed* to be like this, or if


I asusme this is likely to be a ROM chip (i.e. same number of pins as the 
other ROMs on this PCB). My guess (being optimistic) is that the board 
was made ofre sensible number of ROM chips (8, 16, etc) but fewer were 
actually neeeded to store the firmware (c.f early HP9815 CPU boards which 
have space for 8 ROM chips but only 7 are ever fitted).

If you are genuinley missing a ROM, you are going to have _big_ problems.

> perhaps a chip was perhaps scavenged from this position at some time.
> Identifying it will be a chore if it's a critical part.
> 
> The RAM and ROM are all socketed, as well as a few other parts, so I

What sort of RAMs are used? Some older static RAM chips are noted for 
unreliability, and can cause 'interesting' faults. 

> made sure that all were securely in their sockets.  I checked for any
> foreign debris on the circuit boards or elsewhere in the cabinet, and
> found nothing but one floppy disk write protect sticker.  So, I powered
> it up.  The device has four LEDs on the front panel.  They are labeled
> BUSY, FAULT, FILE OPEN and CLOCK.   When powered up, all the LEDs come
> on for a short time, then are turned off, then the CLOCK LED lights

Do you know if all those LEDs are controlled by the processor? Can you 
trace them back to an output poret. The point being that the fact they 
are doing something would seem to imply the processor was working, and 
that it was executing some code.

The CLOCK LED is curious to me. I would have thought, if that is 
controlled by the processsor (rather htan some hardware power-fail 
circuit) then it would be turned on after the 'core' (ROM, RAM, CPU, etc) 
self-tests. which impleis those might well have passed. Oh for a schematic..

> (this indicator lights to tell the user that the real-time (volatile)
> clock in the controller needs to be set to the date and time), then
> shortly (perhaps 1/2 second) thereafter, the FAULT light turns on.  In
> reading the Operator's Manual (thank God for Bitsavers), it says that if
> the fault light comes on, it's an indication that there is a problem
> with the controller, and that if "restarting" does not clear it that the
> unit should be service by Tektronix factory service. =20

Argh!. Such manuals annoy me. 'I am the service engineer damnit. Just 
tell me what the real fault is' :-)

> 
> Needless to say, getting Tektronix factory service to come look at this
> thing would be an exercise in futility.
> My guess is that either ROM checksum isn't passing checksum (Bad ROM?
> EEK, NO!!), or perhaps there's a RAM problem.

What sort of floppy drive does it use? Is there a standard interface 
(like 50 pin SA800 thingy)? Does it make any attempt to, for example, 
restore the heads to cylinder 0?

> Unfortunately, Bitsavers doesn't have the service manual, which would
> certainly make it easier to diagnose the problem.  I'm looking for
> guidance in terms of trying to fix it.  Anyone out there have a copy of
> the "4907 File Manager Service Manual" that they'd care to share (e.g.,
> I'll borrow and scan and make available to Al), or scan it and send to
> me?
> 
> I'll check the obvious...scope out the 6800 to make sure the
> address/data line are wiggling, and check for stuck levels on the

Not a bad idea, but the fact it turns the fault light off and on again 
would seem to indicate the CPU was running.

> address/data bus, but beyond that, without a Logic Analyzer or Emulator,
> it's going to be pretty difficult to proceed further.  I'd love to get

I assume you don;t have a logic analyser. If you do, I'd trigger it on 
the FAULT LED turning on, and trace the code backwards from there.

> this drive working on the 4051, as it'd make it a lot easier to gather
> up all of the software that is on the batch of 1/4" cartridge tapes that
> came with the system, and then upload them somewhere, perhaps to the
> Bitsavers software archive.
> 
> 
> 

-tony