• Please review our updated Terms and Rules here

New Tektronix 4051 owner - needs help repairing his 4051

Thanks. I didn't have that one. I had assumed that might be the case but its good to have the confirmation.

I hooked up an LA and what I am seeing is a bit strange. The trace shows what I get in response to a FIND@5:1 command. The ATN gets asserted by the controller (Tek) as expected but no commands are being sent. About halfway through the trace both NRFD and NDAC end up being un-asserted, probably due to timeout.

When ATN is first asserted by the Tek, both NDAC and NRFD are asserted as expected. NRFD is then un-asserted by the 4924 emulator to indicate that it is ready to receive data, but no data gets placed on the bus and the Tek does not assert DAV to indicate data is available. In other words no command bytes are being sent. After a period, the ATN signal gets un-asserted. During this time, the Tek should have sent an MLA, an address and an MSA 0x73. Once the commands are sent, ATN should get un-asserted and we should see a couple of data bytes placed on the bus (the file number '1' + CR) and then finally ATN should get asserted again and an UNL command sent.

I ran another trace with only the Tek connected to the LA. The emulator was disconnected. It shows a similar pattern and gives the same MESSAGE 69 error on the screen except that NDAC and NRFD never get asserted because there is no device on the bus. I also tried a further with a WRITE command (emulator connected) to see how the Tek would behave in the sender role. The results were similar and the same error message appeared on screen.

I am trying to understand what all this means. The Tek is clearly capable of manipulating the data bus as we can see all lines switching between high and low. The REN and ATN signals also get asserted so both of these lines work. From the circuit diagram I see that DAV, NDAC, NRFD and SRQ are handled by one MC3441 chip (U91) whereas ATN, REN, IFC and EOI are handled by a second MC3441 IC. Data buffered by a further two MC3441 chips. U183B and U193C also come into play, but I am wondering whether U91 is faulty. Judging from the flux present on the underside of the board, it appears that U91 had been replaced at sometime in the past.

The other aspect of this is that no data is getting placed on the data bus ( DIO-1 thru DIO-8 ) and the link between the three ICs involved is the TALK signal which is passed through gates on U193 (74LS02), but then both gates B and D would have to be affected. It is also possible that the PIA is not seeing the state of NDAC and NRFD in which case either U91 or U183B could be responsible.

I guess the next step is going to be to attach the LA directly to the PIA (U265) to see what it is doing and have a look at the gates U193B and U193D.
 

Attachments

  • pulseview-Tek-4051.png
    pulseview-Tek-4051.png
    310.7 KB · Views: 2
  • pulseview-Tek-4051-only-01.png
    pulseview-Tek-4051-only-01.png
    290.5 KB · Views: 2
Last edited:
Diagram B in the GPIB HW Support Manual is the diagram for the 4051 GPIB hardware design (pdf pages 203-204 - 205 is a duplicate of 203).

The Diagram C is a suggested hardware data Header generator. I don't think any device implemented this logic in hardware.

Diagram D is the 4924 Tape Drive GPIB hardware implementation.
 
I did create an OCR version of the GPIB HW Support Manual if that helps I can upload it to my google drive and PM you the link.
 
I disassembled the 4051 and connected the emulator to the GPIB port, the logic analyser to the PIA U265 and captured the GPIB traffic. ATN was connected to p1 of U193 so as to get the signal the correct way around. Reading the signals from the PIA showed the Tek putting data on the bus. What surprised me was that NDAC, NRFD and DAV were all active and apparently handshaking. I opened a terminal session to the emulator and watched it as I ran another FIND comment and sure enough the emulator responded! I then ran OLD@5: and after a brief BUSY+IO got the program listing!

Anyway, I re-assembled the Tek 4051 and hooked everything up again and once again - nothing! Just the MESSAGE 69 error. As before, resetting both Ardionos multiple times made no difference.

I am currently still using the test setup on the development board and the 1284p chip and this is connected via Dupont wires to a UNO which has a cable and IEEE plug on it. I figured that maybe there is a problem with the cable, but when I plug it back into DMM and read it from the UNO, it reads fine. The emulator reads all the signals from the UNO without a problem.

It would seem that the ICs do probably work OK, but there is some form of intermittent problem.
 

Attachments

  • GPIB-Tek-direct-from-PIA-01.png
    GPIB-Tek-direct-from-PIA-01.png
    51.9 KB · Views: 5
  • OLD-from-emulator-01.jpg
    OLD-from-emulator-01.jpg
    179.6 KB · Views: 5
That's curious behavior. I wonder about the cabled connection through the UNO. Possibly the additional connectors and small Dupont wires are not providing valid low logic levels to the Tek?

Maybe its time to mount the 1284 board to my Tape Emulator board. You could install headers in the Tape Emulator board so you can plug in the 1284 board and remove it later for a different application.

Since you are not using the Pololu micro SD - you can still jumper the 1284 ISP connector to your micro SD card and add a jumper wire to connect to the CS pin.
 
The Dupont connectors was the first suspicion and I carefully checked and rechecked everything. Communication between UNO and the development board via the Dupont wires seemed to be working OK and I had been using this setup for development but it was still worth checking.

I took the main board out again and had another good look at it. I had previously noticed that there were some bare wires and a single red wire between the IEEE488 connector and tracks on the board. I had assumed this was factory work but on closer inspection I realised that this was actually a repair that had been done some considerable time ago in the past. It then became evident that at least one of the pins of the IEEE 488 connector had come away from the track, there being only a hairline crack visible right next to the IEEE connector pin. One or two others looked suspect but it was difficult to tell. There was some slight give in the connector so if the mounting screws were loose, one might imagine how, over time, with the strain of the weight of a GPIB cable on the connector this could happen.

When the test was done with the logic analyser attached directly to the PIA, the board will have been the other way up and the weight of the GPIB cable would have been pulling the connector in the opposite direction which might have allowed tracks to temporarily make a connection. This might explain why the test worked at that time but failed on re-assembly when the connector would have wiggled back slightly to its original position loosing the connection.

I have soldered three additional bare wires to the two already present to ensure a firm connection of the broken and adjacent suspect pins to the board. I have also removed and replaced the original red wire and wired up a further two adjacent tracks that also looked suspect. The remainder of the pins were re-flowed along with a number of pins on the opposite side of the board. It doesn't look very pretty, but it has resolved the problem.

I have re-assembled the 4051 and connected it up to the emulator again in the same way as it was under the fault condition. I was now successfully able to download a program from the emulator. For some reason the OLD had command had to be issued twice as appeared to hang the first time but hitting break a couple of times returned the 4051 to the cursor. The OLD command was then issued again and this time is successfully downloaded the program from the emulator. These are things that may need a little work on the emulator but at least I am now seeing GPIB communications and I can work with that.

I do need to get my finger out and get that Tape Emulator and Panaduino board soldered up and ready! I plan to do that over the weekend.
 

Attachments

  • GPIP-port-repair.jpg
    GPIP-port-repair.jpg
    117.6 KB · Views: 6
Last edited:
Great news!

Did you have the 1284 powered and connected before powering the 4051?

I have not been able to do that with my 4052 (which has same GPIB discrete logic as the 4051) or my 4054A which has a TI 9914 GPIB IC.
For both my computers I power the Tek first - with the Tape Emulator plugged in but not powered - then power the Tape Emulator from the USB connector.
 
Yes, the 1284 was powered up already. What I have found is that with the 1284 plugged into the Tek and the Tek powered down, I can't communicate with the UNO or the DMM. Once the Tek is powered up it all springs back to life! Once I get the Tape Emulator soldered up that will not be an issue but it is curious nonetheless.
 
I have re-assembled the 4051 and connected it up to the emulator again in the same way as it was under the fault condition. I was now successfully able to download a program from the emulator. For some reason the OLD had command had to be issued twice as appeared to hang the first time but hitting break a couple of times returned the 4051 to the cursor. The OLD command was then issued again and this time is successfully downloaded the program from the emulator. These are things that may need a little work on the emulator but at least I am now seeing GPIB communications and I can work with that.

I do need to get my finger out and get that Tape Emulator and Panaduino board soldered up and ready! I plan to do that over the weekend.

This could be a GPIB timing issue with the 4051 and the Tape Emulator. I'm glad you now have a working 4051 because I was anxious that I didn't have one to test.

With my 4054A using a TI 9914 GPIB controller - it will have the fastest transfers.
My 4052 has the same discrete GPIB logic as the 4051 - however the bit-slice processor is 10x faster.
With your 4051 - we will be able to test the emulator against all three Tektronix 4050 computers for compatibility!

BTW - I powered my 4052 on a couple of days ago and it now has a display issue that I need to debug.
The blinking cursor is visible, but the text doesn't persist and there is a weird fog in the center. I think it is a high voltage issue on the display board.

But my 4054A is still working fine - so I will use it as we refine the Tape Emulator code.

The eevblog forum may be the best spot to continue the discussion about the Tape Emulator.
 
While browsing through my spareparts I found some NOS ROM's for the 4051. See pic..
Selling for 15 Euro a piece (untested!) as I do not have a 4051..

20230303_101235.jpg
 
Wow, I only found this thread now. That was some serious sleuthing and congrats to WaveyDipole with the ever competent help of DaveR and Monty.

This brought back (somewhat painful) memories of troubleshooting my totally comatose 4052 with my LA (actually a plugin for my Tek 7603 scope, probably from around the same vintage). The ROMs were junk and I had to get replacements on a spare MAS board which turned out to be a totally different revision, so I simply swapped the entire board as you can't mix 'n' match ROMs.

DaveR was essential in then figuring out that the firmware also wound up in an infinite loop after the RAM test, and I wasn't surprised to see the same thing happen in the 4051. In my case it was down to 3-4 bad chips in the option RAM bank, which were thankfully socketed.

Finally, the 4052 would still hang with MRESTART asserted when the tape drive was plugged in. It turned out there were a bunch of fried 74xx chips on there, though I believe I fabricated that error myself when I stupidly reversed the tape drive ribbon cable, as the connector isn't keyed like the others (and I assume it's the same on the 4051).

Interestingly, I've had no issues with the display board yet, but will check the "smurf grenades" on there if and when that arises.

Thanks again for this fascinating thread, guys. Job well done!!!

--Roland
 
Roland,

Glad to have you back in the forum! Your 4052 service manual chapter scans were very helpful for my 4052 repair!

We now have a very good complete scan of the 070-2840-03 4052-4054A Technical Data service manual on bitsavers.org:
http://www.bitsavers.org/pdf/tektronix/405x/070-2840-03_4052-4054A_Service_Manual_Technical_Data_198211.pdf

I needed this in order to troubleshoot my 4054 after I upgraded the MAS and I/O boards and ALU ROMs with my A-Series upgrade kit.

I guess the only 4050 service manual not posted online is the 4052-4052A Parts and Schematics manual.

If needed - vintagetek.org could scan it from their comprehensive Tektronix microfiche collection:

https://vintagetek.org/microfiche-scans/

Monty
 
Roland,

Glad to have you back in the forum! Your 4052 service manual chapter scans were very helpful for my 4052 repair!

Hi Monty, glad they helped, chaotic as some of those notes are in retrospect! I remember it took me -- on and off -- about 5 years (!) to hunt the complete 4052 docs down; they simply weren't in circulation back when I got the clunker. If anything, all I found were incomplete excerpts. A big thanks again to Philipp Belben for providing these in the first place, though I don't know who actually scanned them.

Thanks also for your help and all the tapes you've transferred, without which the Teks wouldn't be doing much. And of course a big thanks to Jos for those cool hardware goodies!

Now to find some replacement belts for my tapes, which are now failing by the dozen. CuriousMarc proposed "Elastibands" as a viable (and affordable) solution, but you won't find those in Europe, or only as overpriced import. Will have to think of something else.

Best regards,

--Roland
 
Roland,

I have the same problem with belts for the tapes.

I've tried Elastibands - they work only a couple of times then stretch and fail.

But I created a solution - a solid state Tektronix 4050 GPIB Flash Drive with the help of my GPIB software collaborator @WaveyDipole :

Tektronix 4050 Flash Drive-labeled.jpg



Tektronix 4051/4052/4052A/4054/4054A GPIB Flash Drive Features:

  1. Completely replaces 4050 internal tape drive for ALL program and data storage
  2. Immediate access and faster loading of all files than internal tape
  3. Flash Drive is compatible with ALL Tektronix 4051, 4052, 4052A, 4054 and 4054A computers using standard GPIB port
    • No serial port or Option ROM needed
  4. Supports all 4050 BASIC GPIB tape commands:
    • FIND, MARK, KILL, OLD, BOLD, SAVE, BSAVE, APPEND, BAPPEN, PRINT, INPUT, READ, WRITE
  5. Ready to run with 100's of files in separate ‘tape’ directories including 35 games and 33 R12/Fast Graphics pictures on the MicroSD card
  6. MicroSD card provides Gigabytes of program data and storage
    • Plug MicroSD into USB-MicroSD adapter to transfer program & data files to/from your PC
  7. Stores each ‘tape’ in separate directory – 100’s of tapes can be stored on same Flash Drive
  8. Main Menu – organizes access to curated directories and programs
    • First Time Setup discovery of installed Options to ensure that Main Menu items are compatible with your 4050 computer detected configuration.
    • Options detected include 4050 Model, Memory size, R05 BINARY Program Loader ROM, R12 Graphics Enhancement ROM, 4052 Diagnostic ROM, 4054/4054A Option 30 and TransEra 4052/4054 RTC.
    • The Main Menu includes a File Browser selection allowing easy access to all the Flash Drive directories with a TLIST and Change Directory feature. Return to the Main Menu at any time by typing RUN.
  9. Flash Drive AUTO LOAD – uses the RTC (Real-Time-Clock) Option (included in @jdreesen's 4052/4054 Multi-Function Option ROM pack available separately) to AUTO LOAD your 4050 computer at power-on to your Favorite Program and Directory which is the last selection you made from the Main Menu.
  10. Flash Drive Micro-USB power cord included.
    • USB 5V 1A power adapter is not included as it requires a country specific power connector.
  11. One Flash Drive zip file with the all the latest ‘tapes’ and programs can be downloaded from the internet and be unzipped to your MicroSD card to update your Flash Drive.

All the Tek 4050 programs I've recovered and all the programs I have written can easily fit on the Flash Drive with simple edits to the programs:
  • Change tape commands like FIND, OLD, READ@33: to FIND@5: OLD@5: READ@5:
  • Change the program and data filenames to the Flash Drive filename format listed in the user guide.
    • I typically just copy an existing Flash Drive filename to the new file and change the first number of the name to the desired flash drive file number and edit the comment field.
  • You can put all the files from a single tape into a FAT32 directory on the Flash Drive.
    • You must at least copy the file 124 LAST file to that directory so the FIND@5: command will find your file or stop if it can't find that file number.

PM me if you are interested in an assembled Flash Drive.

If you want to source the parts and assemble it yourself, I put the BOM in my Flash Drive user guide Chapter 10:

https://github.com/mmcgraw74/Tektronix-4051-4052-4054-Program-Files/blob/master/Flash_Drive/GPIB_Flash_Drive_User_Guide_July_20_2022.pdf
Flash Drive Arduino firmware and initial Flash Drive file zip image in that same folder.
 
Hi Monty,

thanks for the info on the Elastibands -- good to know! I guess they're only an option for a one-time recovery then.

Thanks also for the info on the Flash drive; will have to think about "pimping" my 4052, also with Jos' MF Option ROM. I'll set aside some time to actually do something with the Tek again in the coming weeks, and see where I go from there.

--Roland
 
Hi Monty,

thanks for the info on the Elastibands -- good to know! I guess they're only an option for a one-time recovery then.

Thanks also for the info on the Flash drive; will have to think about "pimping" my 4052, also with Jos' MF Option ROM. I'll set aside some time to actually do something with the Tek again in the coming weeks, and see where I go from there.

--Roland
Another item to consider on one-time recovery of these old DC300 tapes is to bake the tape in a dehydrator before trying to recover it. This can reduce tape oxide shed when you recover the tape.

I describe some of my dehydrate process here:
https://forum.vcfed.org/index.php?threads/tektronix-4051-4052-4052a-4054-4054a-program-archives.65705/page-6#post-1205660

What I didn't mention in that post but did mention in a different thread is I use several CALLs in the TransEra 750-SPU Super Utilities ROM Pack for the 4052/4054 in my TapeDump program to dump the entire tape in one pass to my PC using the serial interface.

This eliminates file seeks that stretch the belt and wear out the tape before it is recovered.
https://github.com/mmcgraw74/Tektronix-4051-4052-4054-Program-Files/blob/master/Tape_Dump/TapeDump8.txt

This TapeDump program captures ASCII Programs and DATA AND Binary Programs and DATA including file header blocks. I then use Notepad++ with the steps in the post above to pull all those files out of the single dump file including the Binary files.

You can either make that TransEra ROM Pack or write that ROM into Jos' MFM EPROM. I posted the TransEra ROM Packs in my github repo along with the 4052 ROM Packs that I have.

I don't remember if you had the serial interface on your 4052. If you don't you can easily modify the TapeDump program to write the output to an ASCII file on my Flash Drive.
 
Back
Top