• Please review our updated Terms and Rules here

Tektronix 4052A Screen CRT dead

Yes, you can program up to eight 4052/4054 ROM Packs into a single 1Mb EPROM with Jos Dreesen's 4052 Multifunction ROM Pack.

Jos' 4052 Diagnostic ROM Pack has an EPROM - but it is just for the Diagnostic ROM pack code.
 
I think I'm on a similar path trying to restore a 4052 for a local museum. It seems to have had a rough life and initially the main fuse kept blowing owing to a failed surge protector and electrolytic cap in the power supply. Removing the surge protector and replacing the cap resulted in the PSU falling into spec, and machine starting to show signs of life. I now get the following on-screen, which slowly gets brighter for about 2 minutes and then the contrast drops back (the screen does not go completely black). The busy, break, i/o and power lights all illuminate and DS1, DS3 and DS4 LEDs are lit on the main board. DS2 is not lit and neither are DS190 and DS195 on the CPU board. No cursor or other activity is seen, and the keyboard does not respond.

1727460001427.png

I've not tried to calibrate the screen yet, but before I investigating further, I was wondering if seeing such patterns was expected, or might be indicative of CRT damage?
 
Last edited:
I think you need to ERASE the screen - but can't ERASE it because the CPU is malfunctioning.

A catch 22 situation!

Monty should be able to diagnose your LED status information for you.

Dave
 
Ahh OK, cool thanks. I didn't want to spend ages reviving the hardware only to discover the storage tube was toast, it's the USP of the machine after all.

Second question, do you know the minimum set of components needed to get the digital section of the machine up and running? The short wiring makes debugging the main PCBs impossible with the screen / tape in place, so I'm wondering if they should show life on their own with just a 5V power supply? It would be handy to be able to get them up and running without the the larger voltages on the I/O board being present.

Cheers
 
I think I'm on a similar path trying to restore a 4052 for a local museum. It seems to have had a rough life and initially the main fuse kept blowing owing to a failed surge protector and electrolytic cap in the power supply. Removing the surge protector and replacing the cap resulted in the PSU falling into spec, and machine starting to show signs of life. I now get the following on-screen, which slowly gets brighter for about 2 minutes and then the contrast drops back (the screen does not go completely black). The busy, break, i/o and power lights all illuminate and DS1, DS3 and DS4 LEDs are lit on the main board. DS2 is not lit and neither are DS190 and DS195 on the CPU board. No cursor or other activity is seen, and the keyboard does not respond.

View attachment 1287065

I've not tried to calibrate the screen yet, but before I investigating further, I was wondering if seeing such patterns was expected, or might be indicative of CRT damage?

This screen behavior is promising. It shows that computer had some text on the screen and the flood guns are working and the display board has dimmed the screen after a couple of minutes.

Dave is correct - if all four lights on the front panel are ON - the BASIC ROMs did not complete self test.

As described in this Tektronix document on my github repository:
Tek_067-0942-99_System_Test_Fixture_instructions.pdf

The DS1, DS2, DS3 and DS4 LEDs on the MCP board should be blinking and DS4 is the most significant bit of the ALU program counter.

Page 6 in this doc covers 4052/4054 Fault Analysis, and the Summary table on the next page indicates BUSY/BREAK/POWER lights on means a problem on the ALU or MCP or I/O.

Page 10 shows that 1101 on DS4/DS3/DS2/DS1 indicates a Handshake failure during a write to an I/O address.

Dave may be able to provide a little more background on what that microcode is doing.
 
Thanks guys, like Dave I'll take a look tomorrow morning UK time :)
One I/O device that is checked during power-on tests is the Tape Board - and if the ribbon cable from the I/O board is not installed, the 4050 computer will halt in power-on tests.
 
Sorry, I have some problems at home I have to sort out.
No worries, no rush, real life caught up we me today too.

One I/O device that is checked during power-on tests is the Tape Board - and if the ribbon cable from the I/O board is not installed, the 4050 computer will halt in power-on tests.
Bummer, I was hoping to avoid having to have the screen / tape chassis attached and run the machine like this whilst debugging the main boards...
1727537215799.png

I assume that in addition to the usual bodge wires this abomination on the ALU board is expected (the machine also has a repair sticker and has had a rectifier in the PSU replaced at some point in the past):
1727537704097.png

Interestingly, with just a 5V power source I don't see a sensible clock at J200. Instead I see a 2.3V DC level with a noisy 49MHz 0.4V square wave overlaid on it (i.e. not a decent TTL output). If I remove the jumper and feed in a 4V 1MHz square clock instead of that generated by the ALU I can see it being propagated and divided down to 500KHz at A15 of P201. When I do this DS4-DS1 are now 0101. So I think my first problem is a fault in the main ALU clock generation.
 
What the hell is that bodge?!
Ahh OK, so not expected then! And the plot thickens. That's U65, which according to the schematics should be a 7428 quad input NOR buffer used as a set on inverters on the on the restart signal signal coming from the MCP (see the left side of page 16). However, as you can see from the image it's actually a 74LS00. All but pins 5, 7 and 14 have been lifted and I think the chip has been rewired to mimic the 7428. I guess whoever did this didn't have a 7428 or 7402 to hand. ;)

Anyway, back to the clock I think, see if we can fathom which capacitor has gone south.
 
Somebody made that ugly bodge... and didn't even try to use a socket? Disgusting.

At least a 7402 would have the same type of gates, and pointing the right way too.
 
I unsoldered and replaced a couple of ICs on a couple of boards in my 4054A repair earlier this year. I would caution you that the IC solder pads on these Tektronix boards are small and I had one pad tear off during repair.
 
After much fiddling I think I have a good main clock signal! If I just power the logic boards (the keyboard, monitor and tape drive are disconnected to allow easier scope probing) I can now see activity in the ALU and the incoming signals from the MCP for approximately 85usec after the RESTART signal goes high. After this everything stops, with the following status condition: DS1=on, DS2=off, DS3=on, DS4=off, DS190=on, DS195=off. I guess this suggests that the ALU is at least trying to execute some microcode. Could someone interpret this state, and let me know if it points to the cause of the halt.
 
No further progress, but some more data. I've found that DS1-DS4 show the most significant nibble of the PC (helpful), and DS190 and DS195 show the CCRH and CCRV lines respectively (although what these actually do does not seem to be described in the service manual - I am rapidly coming to the conclusion that although the description is voluminous, it's actually pretty poor in terms of aiding understanding, for example there doesn't seem to be a description of the reset / restart process of the MCP/ALU).

So I went in search of the PC on the MCP board (which helpfully can be accessed on J266), and discovered that the value 0xfff0 was being clocked into it approximately 40usec after the RESTART signal is asserted. This value is held for about 0.14sec after which it is replaced with 0x9000 until the machine is powered down (hence the pattern seen on DS1-DS4). According to this post, the reset vector should probably be expected to be found at 0xfefe, which obviously is disappointing, and suggests that the PC is not being initialised correctly on reset?
 
Ah, I can answer your question - well, I could if I was at home! I am on a business trip this week, so only have my phone as company...

It is part of the microcode start-up procedure checking for internal errors. I am sure it is described, but you have to go hunt...

I certainly remember reading it somewhere and comparing it with my microcode disassembly.

Dave
 
Cool, that would be great. A bit more data. I found the reference to the startup check in the service manual, so I figure things are failing somewhere in there. I've located what I think are the microcode address test points on J203 and J204. It's not totally clear to me where the data on these is clocked so I used the rising edge of CPCLK-1 and I get the following trace:
addr1.png

If this interpretation of the addresses is correct, the full set of addresses seen is in the text file attached. This ends with the following sequence at address 0x8B:

addr2.png

Is this a known stopping point? Or is there a disassembly of the microcode somewhere?
 

Attachments

  • addr1.txt
    6.1 KB · Views: 1
Back
Top