Centipede trackball control affects horozontal position of the centipede

Had I known Centipede was such a controversial topic I would have started this thread with an abortion joke to lighten the mood. This is what I chose as my hobby ffs.

mecha has helped me out in the past as has andrewb. I respect both of their technical opinions as well as yours Hudson. Although I must say you do come across as a bit of a douch. The game actually does have POKEY issues as well according to my research. However this bug is what currently intrigues me.
The trackball doesn't "write" to anything.
You're correct sir. I was speaking in technical shorthand.
The CPU reads the trackball, and modifies the shooter position based on it.
Interesting choice of words. Wouldn't it be more appropriate to say "The MPU reads the trackball data and "writes" the archer's location to the proper memory location."?

If the mux output of P5 was messed up couldn't that make the trackball data be written to the wrong memory location? This is my current theory after looking at the schematics.

Hudson, please don't squelch other people's speech in my thread. This is a community effort.

If I do (b) the OP doesn't know the stupid post was stupid.
You sure about that. Boy what judgment you've passed on me.


I'm armed with an oscilloscope, digital probes and a multimeter and I'm not afraid to use them!!!

Y'all want to have some sort of ganglia contest, fine! I challenge everyone in this forum. I'll provide absolutely no measurements only symptoms. Everyone is welcome to make a guess. Afterwards we will see who was on the correct path.

This game has been sitting in my game room for two years now. This is my hobby. Entertain me humans!

I'll post a video soon.
 
Here is the video. Happy new year!

you look like you have a few issues here. the gibberish text from an old thread @channelmanic suggested reseating the F7 and HJ7 roms. honestly that would've been my first plan of attack for any bizarro weirdness. I don't know if Centipede had the same affliction as some other Atari games but there are some boards that have very awful quality sockets. your monitor blue cutoff (bias) is also too high, that's why it looks like a glowing blue lol

if you flip the test switch and I think press reset button (if it has it, I don't exactly specialize in Atari, I just fixed all kinds of them over the years) it should run self test and it will report any potential errors. the ram errors should be beep codes if any.
 
Thanks for posting the video, very helpful.
It does look like multiple issues .. I'm of the opinion fix what I can see first. It does appear you have a Pokey issue since some mushrooms are down the side. (i.e. no random numbers). If you can borrow one from another board or have a spare - swap it in and see what changes - or just pull it out while looking at the other symptoms.

Your test screen is messed up It should power on like this.. Your sprites seem to be spaced 2x maybe? If you hit the start button and move the trackball you can move each individual sprite one at a time (I think 16 of them)


IMG_7023.JPG

I'd have to pull a board out to be sure, but I'd look in the motion object horizontal section at these counters as a starting place.. The issue could be earlier in the circuit.. It 'seems' counter related to me.. at least from this distance :)

1735742271565.png
 
Last edited:
As the title says, the trackball controls the horizontal position of the centipede. This sounds like the trackball is writing into memory spaces that it shouldn't. Could this be the LS157 multiplexer at P5 causing this issue?
Per a repair i did for a customer 2 years ago, same symptoms you're having. Hope this helps:

(From 7/23, PB Shoppe) Centipede repair, this was a fun one to repair, based on the symptoms. Game plays, but when you move your player around, all of the other Motion Sprites move with your player. If you move up, the Centipede moves up!! The issue based on the symptoms will be somewhere in the Motion Object hardware. Usually when I have a known good board, and I know I'll be working on more of the same, I'll write down the scope readings of every pin of every IC. This seems like it's crazy, but in this case it helps solve this issue. There is an LS32 IC at C5 that feeds the clock to the two LS163 counters in this circuit. According to my notes, pin 11 of C5 should be high with a continuing low pulse. On the bad board, this signal is high all of the time. Swapping C5 fixes the issue.
 
you look like you have a few issues here. the gibberish text from an old thread @channelmanic suggested reseating the F7 and HJ7 roms. honestly that would've been my first plan of attack for any bizarro weirdness. I don't know if Centipede had the same affliction as some other Atari games but there are some boards that have very awful quality sockets. your monitor blue cutoff (bias) is also too high, that's why it looks like a glowing blue lol

if you flip the test switch and I think press reset button (if it has it, I don't exactly specialize in Atari, I just fixed all kinds of them over the years) it should run self test and it will report any potential errors. the ram errors should be beep codes if any.
When I purchased this cabinet it was being stored in an unconditioned outdoor shed. I actually don't remember what all I cleaned up on this board if anything. I'll check all socketed components. I'll probably end up replacing them at some point.

I wouldn't be surprised if the monitor needs further adjustment. It was completely dead when I purchased the cabinet. I put a rebuild kit in it as well as replacing a failed resistor that was allowing B+ to go super high. Its in a thread somewhere on these forums.

I noticed the test screen does not go all the way to the bottom of the monitor. I'm not sure if this is a monitor or the game board issue. I need to setup a proper DC test bench with a VGA converter.
 
Thanks for posting the video, very helpful.
It does look like multiple issues .. I'm of the opinion fix what I can see first. It does appear you have a Pokey issue since some mushrooms are down the side. (i.e. no random numbers). If you can borrow one from another board or have a spare - swap it in and see what changes - or just pull it out while looking at the other symptoms.

Your test screen is messed up It should power on like this.. Your sprites seem to be spaced 2x maybe? If you hit the start button and move the trackball you can move each individual sprite one at a time (I think 16 of them)


View attachment 790383

I'd have to pull a board out to be sure, but I'd look in the motion object horizontal section at these counters as a starting place.. The issue could be earlier in the circuit.. It 'seems' counter related to me.. at least from this distance :)

View attachment 790384
I don't have a spare Pokey. I'll probably end up harvesting one out of an old 2600 game cart at some point. I don't remember what 2600 carts have them. I'm still holding out hope that the Pokey issue is a socket issue.

This bug has always felt like a timing issue to me as well. I know counters go out quite frequently. I'll study this section of the schematic. I'll test B5 and A5 once we get to that stage.
 
As I've told you repeatedly.
I don't care.

Do you think your dogpile posts are helping anything get fixed?
Don't you have anything "technical" to add?

All you ever do is adding more noise. -- Maybe some deoxit will fix this issue too.

Why don't you just put me on ignore? It's not like you're looking to learn anything from my technical posts.


As expected, you avoided the question.

Let me clue you in, since I can't tell if you are genuinely mentally incapable of self-reflection, or of you're just an intentional asshole. But you're known in and out of this community for being an asshole.

Keep this in mind the next time you accuse anyone else of doing the same.

And the reason I don't block you is because someone has to call you on your antics. A lot of people here are afraid to. But gamefixer is 100% correct here.

This forum is not just about 'posting technical content'. Acting like a socially functioning adult is another aspect of being in any social group. And you have deep and severe issues with that. Get help, and learn how to interact. Nobody here likes your bullshit.

And if you truly don't care, then you shouldn't feel obligated to reply. Because you don't care, remember?
 
  • Like
Reactions: r3v
2600 ballblazer has one.

To be clear, it's the 7800 Ballblazer.

I also have NOS Pokeys available:

 
Per a repair i did for a customer 2 years ago, same symptoms you're having. Hope this helps:

(From 7/23, PB Shoppe) Centipede repair, this was a fun one to repair, based on the symptoms. Game plays, but when you move your player around, all of the other Motion Sprites move with your player. If you move up, the Centipede moves up!! The issue based on the symptoms will be somewhere in the Motion Object hardware. Usually when I have a known good board, and I know I'll be working on more of the same, I'll write down the scope readings of every pin of every IC. This seems like it's crazy, but in this case it helps solve this issue. There is an LS32 IC at C5 that feeds the clock to the two LS163 counters in this circuit. According to my notes, pin 11 of C5 should be high with a continuing low pulse. On the bad board, this signal is high all of the time. Swapping C5 fixes the issue.
Wow! This is super cool man. You've come across something like this before and took the time to document it. Thanks

I'll will give C5 a look once I begin testing.

C5 is an OR gate. The output is Pin11 as stated and the inputs are Pin13 (Inverse of PLOAD) and Pin12 (The output of L8 Pin6)
 
Last edited:
Look at the screen:
Clearly it's at least one bad 2101.
Replace the pokey... run self test... listen to the beep codes.

From the pics, I'd guessing L7 and N7 are bad (or the 153s that read them out -- but that wouldn't explain the sprite issues)

1735767995306.png
 
Last edited:
Interesting choice of words. Wouldn't it be more appropriate to say "The MPU reads the trackball data and "writes" the archer's location to the proper memory location."?
No it's not. the 6502 is a CPU not an MPU.

If the mux output of P5 was messed up couldn't that make the trackball data be written to the wrong memory location? This is my current theory after looking at the schematics.
It's not going to make the trackball data be written to 16 different memory locations to move the entire centipede.

Hudson, please don't squelch other people's speech in my thread. This is a community effort.
If prefer to listen to people who have no idea what they're talking then I'll stop wasting my time.
 
And the reason I don't block you is because someone has to call you on your antics. A lot of people here are afraid to. But gamefixer is 100% correct here.
Ah, your good old "I'm only an asshole because you're an asshole" excuse.
Ever try making a technical contribution?
 
No it's not. the 6502 is a CPU not an MPU.


It's not going to make the trackball data be written to 16 different memory locations to move the entire centipede.


If prefer to listen to people who have no idea what they're talking then I'll stop wasting my time.
The schematics refer to it as an MPU. I'm not making things up.

That makes a lot of sense. Thanks for the correction.

I prefer to have a whole community of people backing me with various experience and backgrounds. That includes you Hudson.
 
...and you described the problem incorrectly...

The problem has nothing to do with trackball as it also happens during attract when the position of the shooter is determined by the code, and the trackball isn't even being read...
 
...and you described the problem incorrectly...

The problem has nothing to do with trackball as it also happens during attract when the position of the shooter is determined by the code, and the trackball isn't even being read...
Sure, I get what you're saying. Let me see if I can better technically regurgitate what I am saying...

The value of the archer's location is being stored at a specific memory location. That memory location can only be written to within a specific time frame. If the timing is off, the archer's location data will be written to the wrong memory location and adversely interact with some other part of the game. It doesn't matter what's changing the archer's location data be it the trackball or the internal code. You're absolutely right, the trackball has nothing to do with the bug it only interacts with it.

I can see how this could be a counter issue or a memory issue as you and others have stated.
 
Back
Top Bottom