Space Duel vector output repair

douglasgb

Well-known member

Donor 11 years: 2012-2022
Joined
Nov 17, 2003
Messages
3,393
Reaction score
485
Location
Santa Monica, California
After fixing two bad vector RAMs on this Space Duel PCB, the image looks ok but there is some bowing of the sides and the centering seems only to move the objects in the middle the screen until they are clipped at the edge. It is also too big. Adjusting the X and Y size pots down to their minimum barely squeezes the image onto the monitor. All the adjustment pots do have an effect, but no amount fixes the issues.



So I believe this is one or more of the MC1495 multipliers, since they handle pincushion correction as well as taking the size pots as inputs.
 
Replaced each of the MC1495s and there was no change. Made sure the pots were good. Tested all the resistors and such that feed into the MC1495s. Since it seemed to be mostly affecting the X axis, I replaced the op-amps at A10 and D/E11 and still no change. Getting desperate I replaced the DAC at A/B9 thinking it might be messing with X BIP and/or X Ref which might also affect the Y axis. Nope.

This seemed the best line of investigation, since the stuff in the 'DAC Reference and Bipolar Voltage Sources' box on sheet 8B are what shape the output of the DAC (so it can swing from positive into negative territory, and output the right magnitude of current for the op-amps). I replaced both Q11 and Q12, check CR4, and nothing made any difference.
 
I hooked up a working board and started comparing various parts of the circuit while both boards were displaying the test screen. I was sure this was an analog problem, but....

It turns out that on the bad board the VCTR signal that control the whole voltage source section was just a bit different than it was on the working board. My first tests were just measuring the frequency of the signal (even though it is not a regular signal, my scope will approximate it). It was as if it were running using a slower clock. Preparing to be annoyed I checked the crystal but it was the correct 12.096 MHz.

Looking at the actual waveform on the scope, the signal was staying high a bit longer than it should be... which meant all the reference voltages were too high, so the DAC output was magnified and everything was drawn too big. That matched the symptoms, but how could the VCTR signal be operating properly but just stretched out? It is derived from VCLK and state machine opcodes and strobes and stuff that would mess up any drawing if it weren't working right (sheet 7B). I checked VCLK to make sure (sheet 4B) and it was right on at 1.5MHz.
 
Knowing it was now a logic problem, I looked for things that could affect VCTR and sheet 7B shows that another ingredient is the /STOP signal coning out of the Vector Timer. The timer works with the position counters to make the vector state machine wait until a vector is drawn before reloading the counters and timer to start work on the next one. The /STOP signal was working, of course (without it there would be no vectors) However, it was a bit too regular, as if the vector timer wasn't getting any variety in the length of vectors.

The inputs to the vector timer are clocks, opcodes, and strobe signals, but also the line coming from the Vector Scaling section. Aha! This uses binary scaling info in the vector instructions to multiply the size of vectors. And it could affect the vector timer, which could affect VCTR. I went back to run ALL of the self test screens and found this:


Which should be this:


After that is was easy.
 
Last edited:
Checking the signals within the 'Vector Scaling' box on sheet 7B, I found that the three outputs of the 74LS175 latch at 7D were stuck. While this could be a bad LS175, it could also be the chip those signals were going to was preventing them from doing what they should. The key here is that even pins 6 and 7 - which are not hooked up to anything - were not toggling (even though Atari kindly sent DVY10 into pin 5 as well as 12). This stoppage of the whole chip could happen if clear (pin 1) were stuck on, or if the clock signal on pin 9 (which tells the latch to latch) was not being received. Sure enough, pin 9 was stuck low.

That traces right back to the LS32 at J6. I tested the inputs to that gate and both pins 4 and 5 were toggling, but the output pin 6 was stuck. I piggybacked another LS32 on top and pin 6 came to life, and the image on the scope shrunk down to the proper size and I could see the scaling test running correctly. Woot!
 
Nice work. The digital issues that look analog can be some of the nastiest to troubleshoot.

I've thought about using the same 'frequency signature' technique. If you went through and characterized what the freq values should be on all major signals, for a normal board running one of the test pattern screens, I wonder if it would give you another fast way of diagnosing things.

Of course no single method is perfect, but the more tricks in the toolbox, the better.
 
Checking the signals within the 'Vector Scaling' box on sheet 7B, I found that the three outputs of the 74LS175 latch at 7D were stuck. While this could be a bad LS175, it could also be the chip those signals were going to was preventing them from doing what they should. The key here is that even pins 6 and 7 - which are not hooked up to anything - were not toggling (even though Atari kindly sent DVY10 into pin 5 as well as 12). This stoppage of the whole chip could happen if clear (pin 1) were stuck on, or if the clock signal on pin 9 (which tells the latch to latch) was not being received. Sure enough, pin 9 was stuck low.

That traces right back to the LS32 at J6. I tested the inputs to that gate and both pins 4 and 5 were toggling, but the output pin 6 was stuck. I piggybacked another LS32 on top and pin 6 came to life, and the image on the scope shrunk down to the proper size and I could see the scaling test running correctly. Woot!

Great detective work. LS32's are on my "TTL parts that fail more often than others" list.
 
Nice work. The digital issues that look analog can be some of the nastiest to troubleshoot.

Amen! It is because of the initial misdiagnosis (trouble looked analog but was digital) that I wrote this up.

I've thought about using the same 'frequency signature' technique. If you went through and characterized what the freq values should be on all major signals, for a normal board running one of the test pattern screens, I wonder if it would give you another fast way of diagnosing things.

I've done something similar for Omega Race, listing the logic probe results for a working board in self-test. Of course, that does not help if the problem is post-DAC in the analog section. And even using a scope can be a challenge because some stages deal in current instead of voltage. If only there were a way to plug a board into the DAC's position and see if it's "go/no go" at that point.

Great detective work. LS32's are on my "TTL parts that fail more often than others" list.

Isn't that odd? I wonder why is true that certain chips seem to fail more often. Overworked? More delicate or complicated inner workings? You'd think an OR gate would be pretty fundamental.
 
Don't forget LS74 FlipFlops. Those bad boys fail a lot too.
I would say it just statistical failure as LS74's are used in large quantity on many boards. Maybe true for basic logic gate ICs too, such as the LS32.

And don't forget "Signetics". LOL :)
 
Back
Top Bottom