Tempest Plays Blind - But No VG Output At All

[64B1T]

Ok. The next question is, is it CORRECT activity?

Compare to a good board if you have one.

Oh lord. Yeah, our other tempest is working, but so much stuff will have to be moved to get to that PCB... If I can't make any more headway tomorrow I'll pull it and compare though.

There's a distinct sound to when the inputs are toggling correctly. It's a fast toggling. You can train your ear to hear it. It's subtle, but I've run into cases where the inputs are toggling, but it isn't correct, and I got no picture. Usually that isn't the case, and they'll be mostly or entirely dead, and sometimes only on one DAC. But if both DACs are active on all 10 inputs, that's information.

I would expect garbage if they were getting partial inputs or wrong inputs right, so long as they're all toggling? Why would it present no image at all?

I would also put the scope in XY mode on both pin 7's of the first TL082's after the DACs, and see if you can get an image. (As normally you should get an image there, it'll just be scaled slightly from the final output size.) That will tell you if the issue is downstream, or if you're getting the same bad image as when you probe XOUT and YOUT.

I'll give this a shot. That's a good test...

The fact that it's playing blind, without resetting, suggests the issue is late in the VG, if it's in the VG. Most of the time, VG issues will cause resets if they are in the early to middle part of the VG.

That's what had me so confused at the get go. Hadn't run into one like that yet. I'm used to perpetual mysterious watchdog barking. Not mysterious silence of dog.

 

[andrewb]

I would expect garbage if they were getting partial inputs or wrong inputs right, so long as they're all toggling? Why would it present no image at all?

That's why you want to look at what's happening at those pin 7's of the first TL082's after the DAC's (because you can't look at the DAC outputs directly because they are current signals, so that's the first place you can see a voltage). You might have something different there than at the XOUT/YOUT pins, because there's other stuff between them. So that will narrow it down a bit.

It's also possible you could just have two bad DACs. I've had it happen. So you could also try socketing and replacing one of them, and seeing if that changes things.

Also, tone out all connections in the video section, and be especially suspect if there are traces of any prior work. Make sure all of the DAC connections and power are actually connected to what they should be connected to.

 

[64B1T]

I got a chance to tone things out. I hadn't touched it since Thursday, and it had another RAM failure when I booted it, which I again corrected. Weird.

In any case, the DACs seem to be producing something but probably garbage while in gameplay/attract mode:

But not be doing anything in test mode, when booted to test mode. When you swap from gameplay to test, it does produce random? Noise on the DACs.

 

[ArcadeTechGW]

Starting to go through the early Tempest I picked up this weekend.

PCB had some RAM errors, so I replaced them with AM9114BPC RAM chips on hand, in place of the original 9114s that it had. This allowed the game to play blind (and enter test mode blind). I assumed when I went to plug it up to my oscilloscope, I'd see something. Nope. Nothing whatsoever. Just a single stationary dot. No motion. What the heck?

So here I broke out the CAT Box, and I found something else interesting. @fcawth not sure if I'm just being dumb or something, but the cat box didn't seem to like the AM9114BPC RAM chips I had installed in the tempest. While the game seemed to "work" with them in, the CAT box would refuse to connect, showing errors in the GUI. When I replaced those RAM chips with some working M2114 pulls I had, the errors went away and I was able to connect. No change in behavior with the PCB.

As of now, ROM and RAM verify (this is a V1 Romset game, so that's pretty cool). All test point voltages on the PCB seem nominal, the pokeys are also testing good.

What should I be poking at next? Whatever it is seems to be upstream of the analog section. Dacs or above? I do see some activity on the DACs with the logic probe, and activity on the vector rom/ram.

How is your AC Ripple?

 

[64B1T]

How is your AC Ripple?

Damn near zero, actually. First thing I checked.

 

[ArcadeTechGW]

Damn near zero, actually. First thing I checked.

Nice. You said your rails were good, I didn't see anything on the ripple. Thanks.

The memory thing is odd. I wonder if the speed was throwing the unit off and making it fault?

 

[andrewb]

This isn't a ripple issue. Ripple will prevent the board from booting. But that's obviously not the case.

Your VG just isn't working. What you're seeing on the DAC's is just junk, and doesn't resemble anything close to working. You just have to troubleshoot the VG, which there is no straightforward process for.

Also, I hope you didn't have the monitor connected for any of those videos. Do not, do not, do not, do that until you figure the VG out, and verify that the XY voltages are working and safe. You can very easily blow a monitor any time a game board is not working properly. *Always* disconnect the monitor and either use a scope as a display, and/or use your DMM and logic probe to determine if the entire board is working, all the way through the video section.

Do you know if all of your ROMs are good? This is a case where the easiest thing to do would be to throw the FPGA Catbox on it and test ROM and RAM. In lieu of that, you can pull the ROMs and test them in a burner, or swap them with good ones on a known-good board if you have one (testing the unknown ROMs on the good board, and the good board's ROMs on the unknown board. Doing both is always a good idea.) Sometimes the best tool to diagnose a dead board is another working board.

Remember that with respect to the VG, it's garbage in, garbage out. So if you have a bad ROM (or a bad RAM that self-test isn't catching, which can happen on these), the VG will not appear to work.

The CPU appears to be working, and it's playing blind. Usually that means there's a problem late in the VG. However ROM/RAM issues can potentially cause that too.

You just need to build what I call a 'pyramid of confidence', verifying to yourself that the simplest things are good first (power, clock, ROM and RAM), and then attacking the VG. You can start piggybacking chips, starting with the data shifters, and vector timer sections.

Get or make a test lead that has a hook style grabber on one end, and a micrograbber on the other. Clip the hook to the logic probe tip, and the micrograbber to one of the DAC inputs that isn't toggling. As you piggyback chips, listen for any that cause the DAC input to start toggling. Test the probe on a good board so you know what working DAC inputs sound like, but they all basically toggle really fast. There's a specific sound to it when the VG is working correctly. But you can use that to know if you hit on something in the VG, without needing the monitor or even a scope connected.

Beyond that, it's just a matter of tracing through the VG logic. However the VG is a loop that wraps back on itself. So entire sections can seem dead, if any one chip in the loop is bad.

Also, only use test mode to debug the VG. It's simpler. You don't even need the aux board connected. If you jumper across CR1 (to bypass the power-on reset circuit), and you jumper C48 (which activates the self-test switch input), you can debug the main board/VG on a bench with just 5V, if you use the logic probe trick above to monitor the input to the DAC.

 

[VectorCollector]

Don't you own an oscilloscope (analog or digital)?
Makes life much easier especially now that you have so many games. Just sayin'.

And you do have an FPGACAT. Yes?

 

[64B1T]

Don't you own an oscilloscope (analog or digital)?
Makes life much easier especially now that you have so many games. Just sayin'.

And you do have an FPGACAT. Yes?

Yes to all of the above. Digital and Analog.

Nothing coming up on analog scope whatsoever. In any mode. Clocks seem good.

Cat box says all is well in the world. (ROMs included)
Really I think I need to do signature analysis on it and see if that reveals any clues.

I'm blaming the RAM issues on all I have in terms of spare 2114s right now is pulls from other boards. I really, really, need to put an APAR order in.

I will probably pull my working PCB when I work up the motivation to move all the crap I need to move in order to access that machine.

 

[mwiggett]

Yes to all of the above. Digital and Analog.

Nothing coming up on analog scope whatsoever. In any mode. Clocks seem good.

Cat box says all is well in the world. (ROMs included)
Really I think I need to do signature analysis on it and see if that reveals any clues.

I'm blaming the RAM issues on all I have in terms of spare 2114s right now is pulls from other boards. I really, really, need to put an APAR order in.

I will probably pull my working PCB when I work up the motivation to move all the crap I need to move in order to access that machine.

IMO, seeing that the catbox is passing rom and ram, you do not need to do a signature analysis. You need to go and do the tests for the vector generator, starting with the HALT test, and continuing down the other tests until you find one that doesn't have the correct times. If all that looks good, you can put the catbox away, start looking at other vector areas with a scope.

 

[VectorCollector]

Then use the digital scope to look at the DAC inputs. Seeing is believing.
Then use the analog scope to work "backwards" from the X/Y outputs though the amps etc and see if any are faulty. Use Y-T mode and not X-Y.
From that second vid, it seems to be "playing blind", yes?

After all this, you might come to the conclusion that there is a simple solution. Not the VG. More common failures.
For example, bad DAC. Bad TL082 amp(s). Bad LF13201 switch. Bad MC1495 multiplier. Bad POT(s).

 

[64B1T]

After all this, you might come to the conclusion that there is a simple solution. Not the VG. More common failures.
For example, bad DAC. Bad TL082 amp(s). Bad LF13201 switch. Bad MC1495 multiplier. Bad POT(s).

Yeah, I think it's upstream of the DACs whatever it is. Definitely not a DAC or TL82 issue.

When I get a chance I'll have to probe upstream more.

 

[VectorCollector]

Yeah, I think it's upstream of the DACs whatever it is. Definitely not a DAC or TL82 issue.

When I get a chance I'll have to probe upstream more.

If you are basing that conclusion on the logic probe results, then I'd suggest rethinking that.
Use your scope. That's the best advice I can give. (LOL)

 

[64B1T]

If you are basing that conclusion on the logic probe results, then I'd suggest rethinking that.
Use your scope. That's the best advice I can give. (LOL)

I'm basing that conclusion on scope... Plus I socketed the DAC and TL082s in the X section and verified no behavior change with new chips.

 

[VectorCollector]

So, after replacing the DAC and TL082, there is no waveform at all at the first TL082 stage output A11 (pin1, 7) after the DAC? Even if the DAC has some data on its inputs?

Though I don't condone shotgunnin' parts, I do believe it's a good idea to carefully socket most (if not all) of the ICs in the analog section. (YMMV)

 

[64B1T]

So, after replacing the DAC and TL082, there is no waveform at all at the first TL082 stage output A11 (pin1, 7) after the DAC? Even if the DAC has some data on its inputs?

Though I don't condone shotgunnin' parts, I do believe it's a good idea to carefully socket most (if not all) of the ICs in the analog section. (YMMV)

Nada. At least, not last time I checked. Forgot to update on that earlier in the post.

 

[andrewb]

What mwiggett said. You need to do the Catbox VG tests next.

 

[lilypad19]

What mwiggett said. You need to do the Catbox VG tests next.

Agreed also - the VG tests are the best way to know if it is alive.. If all the tests are good.. There are far fewer chips to look at in between the DACs and the VG..
Halt is #1 - if this doesn't work.. No need to look further.. that test has to run..
I check center next..

I've had situations were center doesn't work - but draw single short vector does.. That issue is part of the vector ram addressing (as I remember)
Each test provides clues.

 

[wugly]

just to make sure you have data going into dac but nothing coming out. You of course have verified proper input voltages to dac and tl082

 

[64B1T]

Had a free hour today to look at Tempest, and use the CAT Box.

It looks like there's definitely some kind of Halt Problem.

VG Reset works, but if I just hit the HALT test repeatedly WITHOUT reset, I get a Halt Timeout.

If I boot the game, DO NOTHING, with the VG, and run the halt test without reset, it will work and give me the expected timings repeatedly, so long as I only run HALT. If I run any other test, it will then be "softlocked" so to speak, and the timings will either be screwed up (with reset) or will give me a Halt timeout.

If I probe the halt signal with the reset ON and the halt test looping, it toggles, but I think only due to the reset. Timings are still screwed up.