Asteroids diagonal lines shooting across the screen

UnwoundS3GA

Member

Donor 2014
Joined
Feb 19, 2014
Messages
139
Reaction score
14
Location
Parkersburg, West Virginia
Asteroids diagonal lines shooting across the screen

Have an Asteroids that seems to play fine (program wise). Other then that, it seems something is bad in the vector generator circuit possibly? Symptoms are as follows: in game mode- you can hear the game playing and all sounds are present but there are only diagonal lines shooting across the screen. Test mode- a slightly different diagonal line shooting across the screen with a constant beeping sound. Here's a video with the issue for clarification: https://m.youtube.com/watch?v=KUqU-5ng5lE
Hopefully someone can help me.
 
If this were bad vector generator RAM, you would probably get a sequence of different sounding beeps at startup (if the self-test switch is on and then you power up the game). The repeating single beep you are getting combined with the game actually playing blind does point to a vector state machine problem. If you have a logic probe, see what pins 6, 7, 9 and 10 of the LS109 chip @ A7 are doing.
 
If this were bad vector generator RAM, you would probably get a sequence of different sounding beeps at startup (if the self-test switch is on and then you power up the game). The repeating single beep you are getting combined with the game actually playing blind does point to a vector state machine problem. If you have a logic probe, see what pins 6, 7, 9 and 10 of the LS109 chip @ A7 are doing.



Thanks for responding! Just pulled the game out and I have my logic probe ready. However, on my PCB, A7 is a LS74. There is an LS109 2 chips down at A9. Did you maybe mean that one?
 
Asteroids diagonal lines shooting across the screen

If this were bad vector generator RAM, you would probably get a sequence of different sounding beeps at startup (if the self-test switch is on and then you power up the game). The repeating single beep you are getting combined with the game actually playing blind does point to a vector state machine problem. If you have a logic probe, see what pins 6, 7, 9 and 10 of the LS109 chip @ A7 are doing.



In case you mean't A9. I've included what I found with the logic probe.

LS74 @ A7: pin 6- pulsing, pin 7- stuck low (ground), pin 9- pulsing, pin 10- pulsing

LS109 @ A9: pin 6- pulsing, pin 7- pulsing, pin 9- pulsing, pin 10- pulsing

Do I need to be more elaborate than pulsing? For example some were pulsing and the low led on my logic probe was more lit up then the high led, vice versa... also, I'm curious, how were you able to match my issue with a vector state machine problem?
 
Last edited:
In case you mean't A9. I've included what I found with the logic probe.

LS109 @ A9: pin 6- pulsing, pin 7- pulsing, pin 9- pulsing, pin 10- pulsing

Do I need to be more elaborate than pulsing? For example some were pulsing and the low led on my logic probe was more lit up then the high led, vice versa... also, I'm curious, how were you able to match my issue with a vector state machine problem?

Yes I meant A9 - sorry. Pulsing is good in that it means there is life in the state machine, but bad in that it means it will take a lot more probing to track down the problem.

Vector games have two parts: the game play side that is run by the CPU and responds to inputs, keeps score, calculates what should happen next, etc. and the vector side which is a whole other microcomputer running in parallel to process drawing instructions fast enough for the vector monitor to draw the image. They work hand in hand, telling each other to stop and go in their turn.

Since your game makes all the sounds of coining up, flashing P1 and P2, starting a game, responding to controls, and playing that means the CPU side is working.

It also means the vector side is working... sorta. If either side gets stuck there is a mechanism on the PCB ("the watchdog") that resets the entire game. If the vector side were totally dead it would never let the CPU have its turn, and the CPU would keep waiting until the watchdog reset it.

The pins you tested show that the CPU and VSM are taking their turns and sending the stop and start signals to each other.

Next is to put it back in self-test and probe pin 40 of the CPU.
 
Yes I meant A9 - sorry. Pulsing is good in that it means there is life in the state machine, but bad in that it means it will take a lot more probing to track down the problem.



Vector games have two parts: the game play side that is run by the CPU and responds to inputs, keeps score, calculates what should happen next, etc. and the vector side which is a whole other microcomputer running in parallel to process drawing instructions fast enough for the vector monitor to draw the image. They work hand in hand, telling each other to stop and go in their turn.



Since your game makes all the sounds of coining up, flashing P1 and P2, starting a game, responding to controls, and playing that means the CPU side is working.



It also means the vector side is working... sorta. If either side gets stuck there is a mechanism on the PCB ("the watchdog") that resets the entire game. If the vector side were totally dead it would never let the CPU have its turn, and the CPU would keep waiting until the watchdog reset it.



The pins you tested show that the CPU and VSM are taking their turns and sending the stop and start signals to each other.



Next is to put it back in self-test and probe pin 40 of the CPU.



Thanks for the elaboration! Now I am getting a better understanding of these vector games.

Well, I probed CPU pin 40 during test mode and it is pulsing - it coordinates with the repeated beep heard in test mode (when the beep occurs, pin 40 goes low. When the beep stops, pin 40 goes high).

Also, this is strange...when you switch from test mode back to normal mode while the game is powered on, the game doesn't play blind anymore and the cone buttons begin to flash rapidly - pin 40 also pulses rapidly during this. I figured out that in order for the game to play blind, (with diagonal lines shooting across the screen) you have to power the game on while the test mode switch is set to normal gameplay mode.

Thanks for your help so far!
 
Pub 40 is the reset pin for the CPU, so now you've seen the watchdog in action pulsing that pin to reset the game. The chirp beep you hear is the game trying to start.
Usually it is test mode - being much simpler - that is able to run and 'feed' the watchdog so it does not reset the board, while it is game mode that breaks down. It is odd that you have the opposite. Not being able to do so from a 'warm boot' might be a clue. What happens if you do test mode, then flip back into game mode lockup, and then press the reset button on the PCB?
 
Pub 40 is the reset pin for the CPU, so now you've seen the watchdog in action pulsing that pin to reset the game. The chirp beep you hear is the game trying to start.
Usually it is test mode - being much simpler - that is able to run and 'feed' the watchdog so it does not reset the board, while it is game mode that breaks down. It is odd that you have the opposite. Not being able to do so from a 'warm boot' might be a clue. What happens if you do test mode, then flip back into game mode lockup, and then press the reset button on the PCB?

Interesting... well here's what I tried this morning, I powered the game on during normal gameplay mode...verified the game is still playing blind, then set it to test mode, and it began its resetting with the repeated beeping sound. Then, I switched the test mode back to normal gameplay mode, and it began to reset rapidly (cone buttons also flickering rapidly). Then, I tried what you suggested, I hit the reset button on the PCB and after many attempts, pin 40 never reached its normal state (HIGH). Oddly enough, if I hit the reset button while the game isn't resetting and it is playing blind in its normal gameplay mode state, it will always boot and play blind. So it seems the only way I am able to achieve the rapid resetting in normal gameplay mode is to switch from test to normal gameplay mode while it is powered on. Oddly enough, sometimes here and there, but almost never, if you power it on in normal gameplay mode, it will do the rapid reset..but everytime, all I have to do is power cycle the game...and what's strange is that neither symptom (whether it plays blind or resets in normal gameplay mode seems to match to a warm boot or a cold boot..as this morning, I booted it cold, and it played blind. Shut it off and turned it back on and it began resetting..power cycle again, and it plays blind again....) So sounds like I might have more then 1 issue here?
 
Last edited:
You may have multiple issues. Another factor here is the power-on reset circuit, which causes an initial reset after a slight delay so power can stabilize. In a warm boot, that does not happen. But when you pull the rug out from self test code (by switching to game mode) the watchdog reset should have the same result. The POR, watchdog, and reset button all pulse the CPU reset pin, but you get different results based on the state of the game.
I will guess the difference has to do with what is loaded into RAM, specifically the "zero page" RAM that the CPU uses immediately after a reset. If you haven't already, clean the legs of the four ROMs and the CPU. The test code is in one of the three program ROMs so it may not be getting loaded properly. That would normally put the kibosh on the game code too, but who knows. The test mode beeps you get also point to zero page RAM trouble. If it weren't for the game playing blind, I'd have already suggested replacing it.
 
You may have multiple issues. Another factor here is the power-on reset circuit, which causes an initial reset after a slight delay so power can stabilize. In a warm boot, that does not happen. But when you pull the rug out from self test code (by switching to game mode) the watchdog reset should have the same result. The POR, watchdog, and reset button all pulse the CPU reset pin, but you get different results based on the state of the game.
I will guess the difference has to do with what is loaded into RAM, specifically the "zero page" RAM that the CPU uses immediately after a reset. If you haven't already, clean the legs of the four ROMs and the CPU. The test code is in one of the three program ROMs so it may not be getting loaded properly. That would normally put the kibosh on the game code too, but who knows. The test mode beeps you get also point to zero page RAM trouble. If it weren't for the game playing blind, I'd have already suggested replacing it.



Another thing (I probably should of mentioned already) is that this PCB used to work perfectly fine other then a hum that was coming from the PCB. I was diagnosing a LM324 opamp chip at L8 and reading voltages off the legs of it with a multimeter.... slipped and shorted pins 3 and 4. And from the looks of it, would've put +22 volts DC into the 5v rail through a CMOS quad bilateral switch at M9 (4016B)...right after I shorted it, i began getting these symptoms. So the chip legs are probably fine. I've attached a photo of the area of the schematic where i shorted 3 and 4 of L8 (LM324). I thought that since it looked like it went through the 5v rail and that it didn't go to any particular chip, the only way I could diagnose this PCB now was it's symptoms.... So does this tell you anything?

91fd50b390d28c5af0d0313c3de12a80.jpg
 
Back
Top Bottom