Centipede trackball control affects horozontal position of the centipede

Another thread covered in shit from the usual suspects.
All this guy wanted to do was share his centipede repair process and get some advise. How would you judge this forum after viewing this same dick measuring contest and the barrage of insults thread after thread? I would say it makes us all look bad.
1736567068075.png
 
  • Like
Reactions: r3v
Let's start with the historical data that @yaryar provided. C5 Pin 11 (The output of an OR gate) was stuck high. As you can see we have very little off cycle time. Let's follow the signal generation back.
C5 Pin 11 Image.png

C5 Pin 13 (OR Input) gets the PLOAD Inverse signal. Again, the off duty cycle is having some trouble.
PLOAD Inverse C5 Pin 13 Image.png

C5 Pin 12 (OR Input) gets its signal from L8 Pin 6. Again we see issues. Lets continue to follow the signal path.
C5 Pin 12 Image.png

L8 is a NAND gate. Its output Pin 6 should only go low when both inputs are high. L8 Pin 5 gets 256H. L8 Pin 4 gets 256HD Inverse. So the output for Pin 6 should be high the majority of the time since 256HD inverse is derived from 256H. Let's look at L8 Pin 4 and see what 256HD Inverse looks like... Look at how off the duty cycle is here.
256HD Inverse L8 Pin 4 Image.png

Since 256HD Inverse is derived from 256H lets see what it looks like on L8 Pin 5.... That looks rough.256H L8 Pin 5 Image.png
Lets look at 256H at its generation source M2 Pin 13... Doesn't look much better.
256H M2 Pin 13 Image.png
Let's go through the counters. 128H at M2 Pin 14... Again with a poor duty cycle.128H M2 Pin 14 Image.png
64H at N2 Pin 11... Not as bad
64H N2 Pin 11 Image.png
32H at N2 Pin 12.
32H N2 Pin 12 Image.png
16H at N2 Pin 13.
16H N2 Pin 13 Image.png

10 Image limit. To be continued.
 
8H at N2 Pin 14.
8H N2 Pin 14 Image.png
4H at P2 Pin 11.
4H P2 Pin 11 Image.png
2H at P2 Pin 12.
2H P2 Pin 12 Image.png
1H at P2 Pin 13.
1H P2 Pin 13 Image.png
6 MHz at P2 Pin 14.... Yikes
6 MHz P2 Pin 14 Image.png
6 MHz at 6MHz test point on the PCB.
6 MHz Image.png
12 MHz at the 12 MHZ test post on the PCB.
12 MHz Image.png
Someone has been here before and it wasn't me.
Clock Circuit 2.JPG
 
8H at N2 Pin 14.
View attachment 792799
4H at P2 Pin 11.
View attachment 792801
2H at P2 Pin 12.
View attachment 792802
1H at P2 Pin 13.
View attachment 792803
6 MHz at P2 Pin 14.... Yikes
View attachment 792804
6 MHz at 6MHz test point on the PCB.
View attachment 792806
12 MHz at the 12 MHZ test post on the PCB.
View attachment 792807
Someone has been here before and it wasn't me.
View attachment 792809
I like how cell phone cameras traditionally make everything look better except closeups of solder lol

this is one of those instances where I would take everything apart there and redo it, making sure that everything is connecting to where it should
 
  • Like
Reactions: r3v
I like how cell phone cameras traditionally make everything look better except closeups of solder lol

this is one of those instances where I would take everything apart there and redo it, making sure that everything is connecting to where it should
Yup. Broken solder joint on C1 and C2. I had mentioned to you previously, the cabinet was being stored in an outdoor building by the previous owner. Look at the rust on the crystal can. Hopefully the crystal within is still in its spec. I'll clean everything up next weekend as I've run out of time. I'm going to take the time to do some out of circuit testing.
 
256h may not be a signal with 50/50 duty cycle normally, when that line comes on, you're in horizontal retrace which isn't as long as drawing a line. Due to this, 128h should also be off more than it's on.

Your 6mhz and everything after looks fine. If it was a borderline clock you'd have intermittent sync issues and instability.
 
Also note that PLOAD is nand of signals 1h, 2h, and 4h. it will only go low 1 out of 8 pixels (each 1h cycle). inverse PLOAD looks fine. you need to eyeball C5 harder.

Edit: or L8. I was more trying to say it's not the clock.
 
Last edited:
256h may not be a signal with 50/50 duty cycle normally, when that line comes on, you're in horizontal retrace which isn't as long as drawing a line. Due to this, 128h should also be off more than it's on.

Your 6mhz and everything after looks fine. If it was a borderline clock you'd have intermittent sync issues and instability.
256H is a digital clock signal generated by dividing the input clock signal through the three LS163A counter ICs (P2,N2,M2). The CRT retrace time has nothing to do with its generation. 256H should be on for 256 clock cycles and off for 256 clock cycles.

I only posted screen shots eariler and not the actual waveform data. When I crunched the numbers we get the following...

Here are the duty cycle on time precentages for each signal as we go through the counter circuit.

12 MHz 51%
6 MHz 52%
1H 53%
2H 51%
4H 52%
8H 51.76%
16H 50.25%
32H 50%
64H 49.92%
128H 64.67%
256H 68.08
256HD 70.92%

Notice how the duty cycle percentage gets closer to 50% in the middle of the count 16H - 64H. This happens because the flip-flops act as a low pass filter smoothing out some (but not all) of the imperfections in the clock signal.

Once we get onto the very low frequencies like 128H and 256H the cumulative errors compound into a worsening duty cycle once again.

Lastly 256HD is produced by M4 and is a latched version of 256H. M4's clock signal is generated from 6 MHz and the carry bit of P2 further compounding the errors of the generation of 256HD.
 
If 256h is supposed to be 50/50 duty cycle, then explain this.

That's 256h on my working board.

256 won't be 50/50 because the timer circuit is not set to count to an multiple of 256 because of retrace. It counts 256 for the drawn area, then a bit more after the hsync pulse to wait for retrace.
 

Attachments

  • 20250122_093229.jpg
    20250122_093229.jpg
    372.6 KB · Views: 7
Last edited:
You're barking up the wrong tree.
Yeah, in a prior reply I told him where the issue was for a previous repair with the exact symptoms he is having. He could have saved himself a ton of time by going into the area I mentioned. If he doesn't have a comparator, piggyback the less than 10 ICs in that area with known good ones, with the scope on the output pins of the ICs, looking for any signals that go into contention.
 
Yeah, in a prior reply I told him where the issue was for a previous repair with the exact symptoms he is having. He could have saved himself a ton of time by going into the area I mentioned. If he doesn't have a comparator, piggyback the less than 10 ICs in that area with known good ones, with the scope on the output pins of the ICs, looking for any signals that go into contention.


Yes. One mistake some people make when getting into repairs is trying to 'out think' the problem.

Understanding how the circuitry works, and hypothesizing what could be wrong is certainly a good practice. But in situations where you aren't 100% sure exactly where the problem is, you have to balance that with other tools in your toolbox.

At the end of the day, there's usually one chip somewhere that is misbehaving, and all you need to do is find it. And any means to do that is fair game.

Sometimes brute force checking all of the chips in a given area with a probe or comparator can reveal a problem faster than coming up with complex theories, making simulations, writing code, or even breaking out logic analyzers or other complex tools. So you start with the simple physical things (visual inspection, self-test, logic probe, etc). And save the more complicated things for last, if the easy ones don't pan out.

I have an HP comparator. But rather than use that a lot of the time, I'll do what I call a 'poor man's comparator', where if I have a chip with a suspected stuck pin, I'll piggyback a chip with just that one leg lifted, and probe the original vs piggybacked legs with a logic probe.

These digital chips typically work or they don't. Worrying about noise, and how 'clean' the signals are is a red herring most of the time. Many signals can look like shit and still work. Bad signals are usually either stuck (high or low), dead (meaning there's no voltage, or it's floating at 2.5V, so the probe shows nothing), or for things like counters and buffers, you can have the outputs toggling, but just not toggling correctly (which can be harder to detect with a probe, and a scope can be more helpful.) But again, in the time it takes to set a scope up, you can often just desolder and replace the chip, if you're reasonably confident that's where the problem is.
 
Just swap out L8 already, it's getting good signals in and shit signal out. Also probe pic1-pic3 to start with the incorrect background characters issue.
 
If 256h is supposed to be 50/50 duty cycle, then explain this.

That's 256h on my working board.

256 won't be 50/50 because the timer circuit is not set to count to an multiple of 256 because of retrace. It counts 256 for the drawn area, then a bit more after the hsync pulse to wait for retrace.

Your problem is you're using a Hantek scope instead of a Rigol.

Every signal on every board should have a 50-50 duty cycle -- Slowmac says so. LOL.
 
Your problem is you're using a Hantek scope instead of a Rigol.
Nah. The problem is that trevor used generic probes that weren't calibrated. Even so, who knows when that scope was calibrated last! If it's like mine, it would have been 20 years ago!
 
Back
Top Bottom