Tempest board repair.

jkoolpe

Well-known member
Joined
Apr 21, 2005
Messages
2,563
Reaction score
765
Location
San Bruno, California
Hey all!

Well, picked up 2 very nice Tempest uprights a little while back...they were complete and in very nice shape overall (one even had Clay's multikit installed), but both were not working and had board and power issues.

I have one fully working again, and the other I have both rebuilt the A/R board and rebuilt the monitor so both items are now working fine.

But the last issue I'm still trying to figure out is with the board from the latter machine which is the board with the multikit on it. It was originally playing blind so I found and replaced 2 bad chips in the analog output section which brought back the output. And I reflowed the solder for all of the pins for the interconnect cable (on both the main and AUX boards).

I now can get to the menu select screen, and the game plays the Breakout game fine, but whenever I try to bring up one of the Tempest selections, I get a hot mess on the screen.

Video is here:

https://youtu.be/2b6lVUxPd24

Originally when this happened, the self-test would give me a RAM error with the beeps telling me that the 2114 RAM at location "L3" was bad. So I changed out this chip and the error message went away, but now I see the mess in the video :( . I rechecked the socket I had installed for the new RAM chip, and it appears to be fine as far as I can tell.

Any ideas on where to start looking/probing now?

Thanks in advance.

Jon
 
I don't have much experience troubleshooting Tempest boards... but have you swapped boards to narrow down to whether the main or aux board (or both) is bad?

It actually looks like a lot is working properly, and maybe just the drawing of the 3D tubes is having problems. Maybe a problem with the math box circuitry on the aux board? In test mode, do you have a 'M' (or any other letter) in the middle of the screen above the DIP settings? IIRC, it's largely made up of bipolar PROMs, which (generally, not necessarily these on Tempest) seem to fail often.

DogP
 
No error codes/letters/etc. on the self test screen anymore (since I replaced that one RAM chip).

I was thinking to try swapping AUX boards with a known working one (I have a few) as the next step. The only snag is that the board has the Clay kit on it so I'll need to desolder the reset board from the two points it solders onto the main board.

I don't think I need to remove it from the AUX board as it does not appear to be required for the multikit.

Jon
 
Looks like a mathbox issue to me, since it only affects the 3D stuff.

Hope you have a signature analysis setup, that seems to be the only methodical way to work through these problems.
 
Update: I swapped in a known working AUX board, and the problem did not change.

So it appears that the AUX board and mathbox are not my problem but rather something on the main board. I also tested the interconnect cable, pin by pin, and they all checked out fine between the 2 boards.

And again, the self-test passes now with no error codes.

Gonna have to hunker down with the o-scope...again, any ideas where on the main board and/or in the schematics to possibly focus on?

Jon
 
Have you tried removing the kit?

The kits are known to go bad. I've fixed a couple, with various issues. But in your case I'd pull the kit, go back to stock ROMs (or even better, single ROM mod it) and start from there.
 
Just tried de-installing the kit, and no change...same symptoms :( .

Oddly, the first time I fired it up, it was in test mode, and I got the same sequence of beeps that said that the RAM at L3 was bad (the one I replaced). But then I cycled the power (off and then back on again), and this RAM error went away and the self-test screen showed no errors.

Tried the power cycling a couple of more times, same result...was not able to reproduce the RAM error again, and self-test screen shows no errors.

Jon
 
I wasn't sure from your video, but we see there is graphic distortion, however does the underlying game otherwise appear to be playing relatively properly? (i.e., is it basically playing blind, but with really messed up graphics?) I'm trying to discern this, versus the case where the gameplay is actually being affected beyond just the graphics.

If it's purely a graphic issue, and the CPU is not resetting at all (perhaps you can confirm by sticking a logic probe on the the CPU's reset pin 40), then at least that narrows it down slightly.

Otherwise if it is resetting, that doesn't rule out CPU-side issues (although it doesn't confirm that, either).

You might also try leaving the board on for a while and letting it heat up, and seeing if that changes the self-test results. I've seen cases where borderline RAM won't throw self-test errors until the machine has been left on a while. Just another thing to try.
 
Game does play with normal sounds so as you say, it's almost the equivalent of playing blind.

Logic probe on pin 40 of the CPU chip reads high and does not move so I believe that means that's OK. It does the same thing for the working boardset I have.

Don't know if this means anything or not, but I used my HP Logic Comparator to test a bunch of the 74LS chips, and the 74LS161 at E4 gave what appeared to be bad readings for all of the output pins (pins 11-15), but I did try swapping this chip with a new one and again, no change.

The bad readings registered as slightly flickering LEDs on the Comparator, but they were consistently showing up.
 
Jon,

Have you just tried simply swapping the CPU with a known good one from another boardset. Sometimes a CPU can go bad without completely dying...

Just my $.02
 
I'd say it's a fairly safe bet that the issue is not the CPU, or anything on the CPU side, but rather it's the vector side (and we know it's not the aux board, so that rules that out.)

The fact that you aren't getting resets/watchdogging would suggest it's actually something fairly far down on the vector side also, as usually when there are CPU-side issues, you'll get watchdogging, as well as if there is something wrong in the State Machine section of the vector side.

One trick that is known for Asteroids boards, which is used to determine vector vs CPU-side issues is to lift the DMAGO pin on the decoder at L6, which disables the VSM. If you are getting watchdogging, and you lift DMAGO, and you see the watchdogging go away, then you know the issue is on the vector generator side. (And if it's still there, then you know it's CPU-side). What isn't as well-known is that this trick also works for Tempests, except you lift the VGGO signal, which is pin 11 of J5.

However in your case, since you aren't getting resets either way, and it's basically playing blind, it suggests the issue isn't CPU-side, or the state machine. (And I'd expect you'll see the same playing-blind behavior if you lift VGGO.) That doesn't solve it, but at least it narrows it down somewhat.

As a sanity check, you can check to make sure the outputs of each of the four LS161's in the Vector Timer are toggling. Also, check to make sure the carry signals (pin 15) are also toggling. (I've found this trick very handy for identifying bad counters, as I've seen bad ones where the outputs toggle, but the carries don't, which is usually a red flag).
 
Vector Timer is a good bet, or check what is the equivalent of the AVG chip for Tempest: the chips in the Stack and Program Counter and Vector-Generator Address Selector boxes on sheet 3 side A of the schematics.
 
Just checked the LS161s...the outputs (pins 11-15) are all toggling except for pin 15 of the chip at E8. But I did a comparison with a known working board for this chip on the o-scope, and the readouts look to be the same so I think that's OK.

So the the best of my knowledge, these chips seem to be OK. I tested them all with the logic comparator, and they did not give any errors either.

I'll do as douglasb suggests next...
 
Just checked the LS161s...the outputs (pins 11-15) are all toggling except for pin 15 of the chip at E8. But I did a comparison with a known working board for this chip on the o-scope, and the readouts look to be the same so I think that's OK.

So the the best of my knowledge, these chips seem to be OK. I tested them all with the logic comparator, and they did not give any errors either.

I'll do as douglasb suggests next...


Yeah, Doug beat me to it, but I was also going to suggest Stack + Program Counter next. I actually expected the Vector Timer to be ok, which was why I said to sanity check it.

Graphics issues that are not causing watchdogging usually fall into two categories. One where you can see that it's clearly affecting only one axis, which you can usually troubleshoot to the final counter/shifter stages on the vector side (if it's not just something in the analog section, which is relatively easy to determine with a scope.) If it's affecting both axes, as it is in your case, then the path from the Program Counter to the VG RAM would be the next best place to focus.

You'll get it. Some boards are just extra tricky.
 
Oh and I meant to add that outputs 11-14 of E4 (IRQ Timer) are not connected so the comparator results are moot. Ditto with pin 15 of E8 at the end of the Vector Timer chain. As you continue poking around, don't worry about pins that have little unlabeled tails such as pins 6 and 7 of J6 as that indicates they are not used. That's not true for those with labels (such as pins 2, 3, 6, and 7 pf M5) - those go to other sections of the PCB/schematics.

Other conventions you'll see: at M6, L6, and K6 the lines drawn through the chips for pins 4, 5, 11, 12, 13, and 14 indicate those signals are sent to the same pins on all three chips. On M5 pin 4 the label P,R15 signifies a pull-up resistor that ties that pin (and commonly a few others nearby) to +5v so it is always high. Finally, the "/VGGO 11 N6 triangle circle S04 10" means that the active-low VGGO signal is sent into pin 11 of the chip at N6 (an inverter - 74S04) and comes out of pin 10 on its way into pin 14 of M5, L5, and K5. Some or all of other gates on the rest of chip N6 could be used anywhere else on the schematic.
 
Probing as best I know how in the sections as suggested.

I found something that I'm not sure about:

At the LS193 chip at L5 for pin 2, the output on my o-scope screen shows a peak and valley readout with peaks that are clearly shorter than these same peaks for this same pin on this same chip on the known good board.

However, I did use my comparator on this chip, but no error showed. Still, should this be telling me something or should I try to swap out this chip?

Also, a friend suggested that maybe my DAC-08 is bad. How would I know if this would be the case? The output from pin 4 for this chip is definitely messed up/different than the output from the good board (again, when compared on the o-scope screen). And the inputs look the same as for the those from the good board.
 
At the LS193 chip at L5 for pin 2, the output on my o-scope screen shows a peak and valley readout with peaks that are clearly shorter than these same peaks for this same pin on this same chip on the known good board.

However, I did use my comparator on this chip, but no error showed. Still, should this be telling me something or should I try to swap out this chip?

Also, a friend suggested that maybe my DAC-08 is bad. ... The output from pin 4 for this chip is definitely messed up/different than the output from the good board (again, when compared on the o-scope screen). And the inputs look the same as for the those from the good board.

If you mean the good board shows a waveform that has peaks of 5v and valleys at 0v, but the problem board has peaks that are less than 5v then that is a problem. By the book if they are under 2.7v then the next chip will not consider it a high at all. Or, it may be that the next chip's input is shorted and your L5 is doing its best but it doesn't matter because the next ship isn't listening.

So I'd replace either L5 because of weak output on pin 2 (signal AVG6) or the LS157 at M2 (where the AVG6 signal goes to) because of bad input.

As for the DAC-08, it takes DVY0-7 as inputs, which are generated based on the data coming over the DVG0-7 lines from VRAM and VROM. That data is selected by the AM0-10 addresses calculated by the VG Address Selector that includes chip M2. So signal AVG6 not being represented will change what the DAC is doing. Its inputs may look the same, but unless you are looking at them with a logic analyzer (not a logic probe or even a scope) you may not see the difference. It's not that AVG6 missing propagates through to the DAC and one of its inputs will be missing; it's that a missing AVG6 will still select 8 bits of data for DVG0-7 but it won't be the right data.

You can test this on your good boardset by momentarily grounding pin 2 of L5 and seeing what happens to your output (from the DAC or even the image on screen).
 
Changed the chip at L5, but there was no change still :( .

But the output at pin 2 is definitely better (as in the peaks are now the same height as for the other LS193 chips in this section). I even put in the original chip and re-measured these peaks, and again they were lesser in height so the new LS193 chip did make a difference in that respect. But again, the symptoms did not change.

I looked at the input to pin 10 on the LS157 at M2, and it looked the same as coming off of pin 2 of the replaced LS193 at L5.

Should I still try replacing M2 anyway?

Jon
 
No need to replace M2 (or L6 where AVG6 also connects) as it seems you guessed right on L5.

My next guess is something in the DVX signals. DVY trouble would really mess things up since it also does Vector Timer Control, but DVX is mostly just used for X output. The exception is DVX11 and DVX12 which do go to the Timer. Make sure you have the /LATCH3 signal and check the LS175 at H7.
 
Back
Top Bottom