Asteroids rev 5 PCB bad X and Y output voltages

Yes, I bought a GQ-4x4 and a UV eraser and verified that the chips were blank before burning asteroids rev 2 from here https://arcarc.xmission.com/archive/Web Archives/ionpool.net (Dec-31-2020)/arcade/atari/roms.html
First I tested the existing ROM chips against those files and found two of 3 to be bad. Vector PROM checked OK too. I experimented by burning a set of rev 1 asteroids and still have the same glitch.

When I probe the DACs with the o-scope I can still see the glitch happen so I assume it's upstream somewhere?
Might be in the 161s
 
Yes. As I stated above, you have a VG issue.
I'd like to (attempt) to diagnose the problem if possible. Is this something I might be able to do with an o-scope, DMM and logic probe? I'd like to become more fluent in reading schematics and applying them with the tools I have. I don't want to call it quits yet because I've made it this far haha
 
Gee, it's almost like that's just what I said.

(Dilbert, ArcadeTechGW has me blocked because he doesn't like it when I correct the wrong advice he regularly posts. But that's why he's oblivious to my posts, because he isn't seeing them.)
I have you blocked because you are a toxic troll. Period.
 
I have you blocked because you are a toxic troll. Period.

All I do is point out when you post technically incorrect information.

If that's considered toxic, then the problem is you. The overwhelming majority of other people here don't feel a need to block me.

Nonetheless, I will continue to explain to new people what's going on, when you make posts in the same threads I am already having people in, and they get confused because you don't appear to be seeing the information that has already been posted.
 
1759258551192.png
Look, you both have gotten me this far. Every time I dive into a different topic on this forum you two provide a wealth of information in your own respects
 
View attachment 851063
Look, you both have gotten me this far. Every time I dive into a different topic on this forum you two provide a wealth of information in your own respects
I was going to say hey dudes, this is a repair thread, your beefs in the politics section shouldn't apply. lol

I just class andrewb as the supreme authority on vector matters. though if you have caca pins in plugs, I personally just replace them entirely. I don't muck with the skinny round pin headers on the monitor deflection boards either, those get replaced too.

obligatory YMMV
 
I was going to say hey dudes, this is a repair thread, your beefs in the politics section shouldn't apply. lol

I just class andrewb as the supreme authority on vector matters. though if you have caca pins in plugs, I personally just replace them entirely. I don't muck with the skinny round pin headers on the monitor deflection boards either, those get replaced too.

obligatory YMMV
I was able to remove the pins and clean them up. Everything is working as it should now except for the dreaded glitch. I believe that schmutz was from the 40 year old plastic wire degrading over time. Or the Wicked Witch of the West was playing cocktail asteroids as she was melting...
 
I'd like to (attempt) to diagnose the problem if possible. Is this something I might be able to do with an o-scope, DMM and logic probe? I'd like to become more fluent in reading schematics and applying them with the tools I have. I don't want to call it quits yet because I've made it this far haha

In this case, those tools aren't really going to be sufficient for this level of problem. You need the ability to capture long traces of logic data, and compare them to a known working board. Or you'd need a logic comparator, which would let you compare the streams of data from one chip against another good chip in real-time.

You sometimes can narrow down problems like this with a logic probe, but it takes experience. And the ability to listen to and compare what you can hear with the probe, against another known-working board, side by side.

As I mentioned above, the easiest trick to try would be piggybacking the chips in the Vector Timer section, one at a time. I'd start with the four 161's. This is a useful trick for a lot of VG issues. But like any technique, it isn't a silver bullet, and isn't guaranteed to catch every possible problem. Part of working on these boards is having as many tools and techniques as possible in your arsenal, and trying multiple until one of them hits on something. No one tool works for every possible case.

Another trick in these cases is to suspect any chips that are Signetics brand, if they are in the section you are focusing on. These are labeled with a big 'S', or 'SA', or 'SB' on them. They tend to fail at much higher rates than other brands on these boards. Not that I advocate shotgunning, but if you just replace all Signetics chips off the bat, you'd stand about a 75% chance of fixing most VG issues.
 
If you are going to do this yourself triple check any of the board work you do and buzz out the paths. (I have no idea what your proficiency of soldering is so I write this part). you are getting a lot of repeating partial data that does not look to be involved with scaling at all since the numbers are wigging out too. My down and dirty look for you would be to logic probe the counter 191 chips out through till you get to the dacs. be aware some of the muxs have the exact same inputs on multiple pins. If you look in the vector generator program counter which is as far back as I would look in the vg section you are only going to figure out anything without advanced tools by piggybacking a reg file chip on the board and while you are watching the screen pull it off and see if you have any change. Data over there won't be a stuck pin (I have never seen a stuck pin over there) but you will get incorrect data out. Check the inputs of the 191 counters next for anything stuck. the data muxs next have to be working enough for the vram to pass testing and get a good test pattern.

Ps did you do an extremely detailed through look of the board for any trace scratches or hair line metallic threads or solder trails that might be corrupting the board?
 
If you are going to do this yourself triple check any of the board work you do and buzz out the paths. (I have no idea what your proficiency of soldering is so I write this part). you are getting a lot of repeating partial data that does not look to be involved with scaling at all since the numbers are wigging out too. My down and dirty look for you would be to logic probe the counter 191 chips out through till you get to the dacs. be aware some of the muxs have the exact same inputs on multiple pins. If you look in the vector generator program counter which is as far back as I would look in the vg section you are only going to figure out anything without advanced tools by piggybacking a reg file chip on the board and while you are watching the screen pull it off and see if you have any change. Data over there won't be a stuck pin (I have never seen a stuck pin over there) but you will get incorrect data out. Check the inputs of the 191 counters next for anything stuck. the data muxs next have to be working enough for the vram to pass testing and get a good test pattern.

Ps did you do an extremely detailed through look of the board for any trace scratches or hair line metallic threads or solder trails that might be corrupting the board?
I agree with what you are suggesting. My dyslexia got me 161s - it's the 191 counters.

I think what you mean by "buzz out" is similar to what I say when I say ring out - power off, go from the top of the pin to the next pad in the trace downstream, verify low (<0.3 ohm) resistance.

When you say "stuck" input, normally you would expect to see the input vary up and down constantly. A pin which is high or low on the logic probe could be stuck.

I'm trying to translate your experienced speech down to a more entry level. If I didn't get it right, please correct me.
 
@andrewb you know a lot more about this board then I do. What am I missing about the counters in the vector timer. One of my assumptions is that If I can get a stable test pattern with no watchdog I tend to believe that the state machine is good and that the timer is running good enough to draw the lines or are my assumptions off or just highly probable.
 
View attachment 851063
Look, you both have gotten me this far. Every time I dive into a different topic on this forum you two provide a wealth of information in your own respects
It's not fighting, it's just correcting a false narrative. I have provided him with this feedback - at times he is incredibly helpful, but at other times, he can be quite abrasive and off-putting. More than one person on here has told me they left because of his responses.
 
I agree with what you are suggesting. My dyslexia got me 161s - it's the 191 counters.

I think what you mean by "buzz out" is similar to what I say when I say ring out - power off, go from the top of the pin to the next pad in the trace downstream, verify low (<0.3 ohm) resistance.

When you say "stuck" input, normally you would expect to see the input vary up and down constantly. A pin which is high or low on the logic probe could be stuck.

I'm trying to translate your experienced speech down to a more entry level. If I didn't get it right, please correct me.
you got the gist of what I was trying to say
 
You can always probe around. But in this case I'd say a probe is unlikely to yield anything obvious, because the board is mostly working. You can check, but don't waste hours looking.

You're getting very high speed glitches, which implies something is misbehaving very quickly (like a counter), which a probe will be unlikely to find.

Probes are good for lots of things, including cases where you have a completely non-working VG, and you want to see if/what subsections are toggling or not, which can help you narrow down where problems might be.

But I wouldn't spend too much time with a probe in this case, as you're unlikely to find anything obviously dead or stuck. Everything will likely be toggling, and the probe just doesn't have the precision needed to figure out what's not toggling correctly. That's why more powerful tools are needed. (Though piggybacking often works in cases like this. But again, not always.)
 
If you are going to do this yourself triple check any of the board work you do and buzz out the paths. (I have no idea what your proficiency of soldering is so I write this part). you are getting a lot of repeating partial data that does not look to be involved with scaling at all since the numbers are wigging out too. My down and dirty look for you would be to logic probe the counter 191 chips out through till you get to the dacs. be aware some of the muxs have the exact same inputs on multiple pins. If you look in the vector generator program counter which is as far back as I would look in the vg section you are only going to figure out anything without advanced tools by piggybacking a reg file chip on the board and while you are watching the screen pull it off and see if you have any change. Data over there won't be a stuck pin (I have never seen a stuck pin over there) but you will get incorrect data out. Check the inputs of the 191 counters next for anything stuck. the data muxs next have to be working enough for the vram to pass testing and get a good test pattern.

Ps did you do an extremely detailed through look of the board for any trace scratches or hair line metallic threads or solder trails that might be corrupting the board?
I appreciate the detailed response. As far as soldering goes I'm still a novice. I've recapped a few monitors, replaced some chips, sockets and other components here and there. I'm fortunate to work in the computer recycling business so I've got a lot of boards to practice on (getting the extra parts is a plus too).

I looked through the board and found a few scratched traces but they passed continuity check.

This board does have a speed mod daughter card (I'll post a pic shortly) but the dip switches don't do much except make a couple of fast/slow beeps based on the number. Not sure if a chip (or that card) could be a culprit or not. I cleaned and reflowed solder on the legs of N11 where the jumper wires go into the card and checked the seemingly damaged trace under the socket at C5 and everything seems alright.
 
I agree with what you are suggesting. My dyslexia got me 161s - it's the 191 counters.

(EDIT: Disregard former comments about 194's. I was getting mixed up with Tempest, as I'm helping someone else with one at the moment. Too many parallel conversations.)

From the video posted, the glitching seems to be heavily in the X axis. But not completely. This points to potentially one of the three 191's for the X axis shifters, or possibly one of the 161's in the Vector Timer.

When a board is glitching but NOT resetting, this tends to point to something later in the VG, e.g., the Shifters. However it's possible to have bad 161's in the Vector Timer and not get resets. (And it's possible to have bad 191's AND resets. Both of those are less likely, but not impossible). Glitching in more than one axis tends to point more to the Vector Timer. But these are all just first-order rules of thumb, and are not always 100% true.

@Dilbert, can you post a decent-res pic of the middle section of the board, so we can see what brands of chips are in these sections?
 
Last edited:
I appreciate the detailed response. As far as soldering goes I'm still a novice. I've recapped a few monitors, replaced some chips, sockets and other components here and there. I'm fortunate to work in the computer recycling business so I've got a lot of boards to practice on (getting the extra parts is a plus too).

I looked through the board and found a few scratched traces but they passed continuity check.

This board does have a speed mod daughter card (I'll post a pic shortly) but the dip switches don't do much except make a couple of fast/slow beeps based on the number. Not sure if a chip (or that card) could be a culprit or not. I cleaned and reflowed solder on the legs of N11 where the jumper wires go into the card and checked the seemingly damaged trace under the socket at C5 and everything seems alright.
That "speed mod" may not be what you think.

Atari had some problems getting certain chips, so they worked up a board which went over the top and plugged into a socket, as a workaround using different chips.

Post a photo here of that sub-board when you get a chance. I don't believe it is in the vector state machine, so it probably isn't your problem.

I'd concentrate on the 191s. If you need me to check mine and tell you what I get with a logic probe, let me know.
 
IMG_6797.JPEGIMG_6798.JPEGIMG_6799.JPEGIMG_6800.JPEGIMG_6801.JPEG
Is this high enough quality or should I take half and half closeups of the board
 
Here's another video of the glitch in 120fps for your viewing pleasure, or to add to the forum archive lol
 
Back
Top Bottom