Tempest Plays Blind - But No VG Output At All

[andrewb]

Make sure you are grounding the watchdog when you do the VG tests.

 

[64B1T]

Make sure you are grounding the watchdog when you do the VG tests.

It was grounded I believe... I'll have to double check. There were a lot of probes and jumpers all over the place. I remember reading the tool tip and grounding it though.

 

[lilypad19]

With the watchdog grounded, and running the HALT Test with the "Reset after test" button not lit.. If you are getting a timeout, then your VG is broken. No HALT can be a lot of things. It is part of the VG loop.. It can be anywhere, but I start looking around the state PROM.

 

[andrewb]

It was grounded I believe... I'll have to double check. There were a lot of probes and jumpers all over the place. I remember reading the tool tip and grounding it though.

You really should only need CR1 jumped (to bypass the power-on reset circuit, so you can power just the main board, and only need +5V, and no 10.3V), and a jumper on WDDIS to ground. I actually just solder a small 1/2" piece of Kynar across CR1 when I'm working on these on the bench to permanently jump CR1, then remove it later.

Then clip the scope probe from the Catbox onto the HALT test point. (So you don't need to clip to the chip leg.) Tempest is convenient because it gives you a test point for HALT, which not all boards do.

 

[64B1T]

With the watchdog grounded, and running the HALT Test with the "Reset after test" button not lit.. If you are getting a timeout, then your VG is broken. No HALT can be a lot of things. It is part of the VG loop.. It can be anywhere, but I start looking around the state PROM.

Yeah the VG is definitely broken. I went and repeated the test. WDDIS was definitely grounded. I piggybacked the halt latch LS74 which didn't have any change, so I imagine it's proably something in the decoder, given that it's not watchdogging normally, so the reset counter should be okay?

 

[lilypad19]

If the WDDIS is doing its job and the circuit is not toggling anything (it shouldn't be) and the RESET line is now high with it disabled.. then don't worry about the WD circuit for now. You need to get HALT working first.

The issue is it can be a lot of things, the state prom, the data shifters, the LS42 decoder.. The VG circuit is a big circle with a bunch of on ramps and off ramps..
Sometimes piggybacking a chip while you have the FPGA Tester looping, you will see the HALT timing glitch or change (not always). That is the 'first pass'.
Fixing HALT can take a while - a lot can effect it..

Make sure all of the clocks into that circuit are working 12mhz, etc..

 

[64B1T]

Good news, it's not the PROM. I swapped the one from my working Tempest PCB over since I could reach it through the coin door, and there was no change.

I also tried piggybacking the LS42 with a LS42N I had in stock, and no change either.

So I think next, I have to look at all the data shifters? I don't have any of those spare I don't think.

 

[lilypad19]

When you don't have HALT, it can be a lot of things..
When I'm in this situation - I run the HALT test. If you run it once - you will see a big pulse width number (300k+ usually) and it stops.

If the tester is in loop more, you can hit the reset button on the PC and it will run the cycle again. The "Reset after test" button is doing the same thing. So that the loop option actually loops for you after a timeout (great button, thank you Fred).

You will need to go all through the vector generator (state machine and shifters is where I start in this situation) and try to find the offending chip. There is no single answer on that issue.

 

[64B1T]

I've absolved address decoder of any sins through lots of logic probing.

Through a hunch, I pulled the LS175 at J7, because it didn't seem like it was producing any output when running the extended CAT Box tests, and lo and behold, when I stuck it in my chip tester, it failed. That's the 'good news'

The bad news is after excitedly socketing it, thinking my salvation was at hand, I realized I don't have any LS175s in stock.

Sob.

 

[ArcadeTechGW]

I've absolved address decoder of any sins through lots of logic probing.

Through a hunch, I pulled the LS175 at J7, because it didn't seem like it was producing any output when running the extended CAT Box tests, and lo and behold, when I stuck it in my chip tester, it failed. That's the 'good news'

The bad news is after excitedly socketing it, thinking my salvation was at hand, I realized I don't have any LS175s in stock.

Sob.

At least you have a SUSPECT for goodness sake! Now you can replace it and MAYBE you hit the SUSPECT Jackpot!

Well done!

 

[64B1T]

While I'm waiting for Digikey to make a delivery, I decided to start tooling on the monitor. Like the PCB, it's deffo dead.

I started with AndrewB's pullup guide for 6100s.

Right of the bat, two dead frame transistors. Neat.

So I recapped the whole thing and built a LV2K (thanks Charles Kline). Voltages on the deflection board seem fine for the LV2K. Everything seems okay over there.

However... The HV supply is FUCKED. It's clear that someone tried messing with it in the past. There were caps of the wrong values, and odd transistors installed. I removed most of them and put the right spec in... Nada.

No HV whatsoever. When I looked at the LV inputs, it seems +24 was coming in at -5V (???) and -24 was coming in at -19V (??) Disconnected that plug, everything is right as rain again at the deflection board side. What the hell, man?

Something must be bad somewhere... But what? Not the Zeners. Replaced those as suspect.

 

[Texas_Funnyhair]

While I'm waiting for Digikey to make a delivery, I decided to start tooling on the monitor. Like the PCB, it's deffo dead.

I started with AndrewB's pullup guide for 6100s.

Right of the bat, two dead frame transistors. Neat.

So I recapped the whole thing and built a LV2K (thanks Charles Kline). Voltages on the deflection board seem fine for the LV2K. Everything seems okay over there.

However... The HV supply is FUCKED. It's clear that someone tried messing with it in the past. There were caps of the wrong values, and odd transistors installed. I removed most of them and put the right spec in... Nada.

No HV whatsoever. When I looked at the LV inputs, it seems +24 was coming in at -5V (???) and -24 was coming in at -19V (??) Disconnected that plug, everything is right as rain again at the deflection board side. What the hell, man?

Something must be bad somewhere... But what? Not the Zeners. Replaced those as suspect.

I'd suspect there's a trace shorted somewhere, did the previous work put any jumpers on the bottom from pulling up traces?


Could send it off to AndrewB to rebuild, did a great job with my 6100's HV and has my other boards right now.

 

[64B1T]

LS175 came in. Despite testing bad in the tester, that wasn't the problem. But I still think it's the best clue I've got.

Right now, none of the outputs on EITHER LS175 (J7 or H7) are toggling. This is DIVY12, OPO, OP1, OP2, Z0, Z1, and Z2.

However, all the inputs (DVG 4, 5, 6, 7) are toggling, and I can hear them making different patterns during the attract mode (with the logic probe). The thing that I am thinking about right now are the signals Latch1 and Latch3, where Latch1 is in common between both chips. They're definitely toggling, but they must not be toggling at the right clock for the Flip Flops to well... Flip Flop.

These signals come from the LS42 decoder at F7. Nothing seems stuck there... But I haven't pulled this chip and tested it out of circuit yet.

It's fed by the LS74 at B8 which I know is good, and the Vector PROM at D7, which should also be okay (I swapped in the PROM from my other tempest and it worked)

So I'm thinking I may have to take out F7 and Test? Or possibly trace VGGO back from B8 to see what that is doing.

If Halt is the problem, is this just a red herring symptom, and should I be looking earlier in the state machine?

 

[64B1T]

I guess I can't be distracted by the monitor anymore. Gotta actually figure out this PCB.

 

[64B1T]

Slowly plugging through the State machine. No breakthroughs yet.

What's the best way to test the VGCK line?

GO is stuck high for the most part while the game is running. Not sure if that's normal, I assume it is?

 

[64B1T]

VGCLK is 1.51Mhz, so not that, I assume that's correct, seems so for other Atari games.

Still haven't found a smoking gun. Lots of signals that don't do what they're supposed to (static or such) but are fed by earlier, static signals, which loop back... As expected. The core loop of the VSM is entirely good chips.

The Vector Timer 161s all also showed no change in behavior when piggybacked.

This is where I'm at right now.

Green: Good
Yellow: Know would be OK if previous inputs were OK
Orange: Chip Seems good from logic probe active testing.
Blue: No change when piggybacked.


I'm looking at the Stack and Program counter right now. It's definitely not trying to get through the stack. The outputs from M5/L5/K5 are all Static. However, that's controlled by the data shifter, which is governed by the latch 1 signal, which is also gridlocked.

I can see why these things have such a less than stellar reputation for debugging.

Somehow it still happily plays blind through all of this.

 

[Kaworu5]

@MyztikJenz It has been a bit since we looked at Lunar Lander, this sounds somewhat familiar to what your state machine was doing. Though LL and Tempest are different enough that it might not be worth comparing.

 

[64B1T]

Good god this thing has had EVERY issue. And still does.

I've pulled many chips in trying to figure out what the hell was going on with the vector generator, and a lot of them tested bad. Some, admittedly tested fine, just confirming how much time I spent chasing my tail. The biggest problem I kept having (in multiple areas) was what appeared to be internal shorts in upstream chips, somehow pulling high or low their input lines, making it seem like the previous chips weren't outputting anything, when in fact they would when legs were lifted or pulled out of circuit. I think that happened 2 or 3 times.

Compounded by the fact that a lot of the chips had some pretty heavy corrosion on them, plus some previous work. I found out that Rats were using the cabinet as a nest at some point, so I'm assuming Rat piss did them in. But we're getting somewhere now I guess.

And by "And still does," I'm only able to get this output at the first stage of the X and Y TL82s. Still absolutely nothing on both X and Y outputs. What are the odds right? I'd say pretty good odds given how absolutely fucked the VG was. Final chip I replaced before getting it to work was the LS32 at J8, because I noticed that the _OP2_ and _OP0_ lines were stuck, and the LS175 source chip was fine. J8 was the only one they shared in common.

Fun stuff.

In any case, figuring out what's wrong with the Analog Section is a tomorrow me problem. Tonight me has had enough of this board lol.

 

[pbozeman]

Even though you don't have final output, your recent progress is a huge win and substantial progress! Congrats!

 

[VectorCollector]

I'm fixing a Space Duel state-machine at the moment too.
So far, every IC that had RUSTY legs, was bad.
I've had other boards with similar condition but most worked fine. Humm.

Hey Hey, My My. It's better to burn out than to fade away.