Space Invaders processor in reset

Mojodog333

Active member

Donor 2024-2025
Joined
Nov 5, 2024
Messages
379
Reaction score
157
Location
Michigan
I started debugging an SI board today. There is a staric image of garbage on the screen. The Midway troublehooting guide suggested looking at RAM. I saw RAM was working but the WE pin is dead. Tracing back to the micro, I see it is being held is reset. I was trying to trace back to what controls the signal in the schematic and it looks like it goes to a pin 16, but I can't find the other end of the signal. Is anyone familiar with where that is on the schematic or on the board.
 
Thanks for the quick reply! I am seeing a logic 1. I was assuming RESET is active high since it does not have a bar on it like WR. There is a 2Mhz clock present, but all of the address lines are inactive. I can't remember the voltage, but it was on the order of 1-2V, so I thought they might be tri-stated.

Let me know if I interpreted the polarity of RESET.
 
Let me know if I interpreted the polarity of RESET.

Yes that's correct, if that is high the CPU will do nothing. You say you have clock at the CPU so that is a good sign.

If RESET is constantly high you need to trace back to the 2 x 161's on the sound board (D2/E2) that generate RESET. It sounds like they may not be being clocked (pin 2) which is signal "60 Hz" fed from the timing circuit on the main board (9316s).
 
Ok, the 60Hz clock was there for the watchdog, but once I looked at that part of the schematic, I realized the reset signal comes in on the 11-pin header... which I did not have connected... So, progress!

I am getting vertical lines, but not all of them.
It is supposed to be: 1 on, 2 off, 3, on and 10 off.
I am getting: 1 on, 2 off, 1 on, 12 off.
It will shift periodically several bits to the left or right.

1750724323446.jpeg

I put a logic anayzer on the 74166 because that was the problem on my Sea Wolf, but this appears correct...(D0-D7 on the bottom, D11 is the Load/Shift signal, and D12 is the output.)

1750724363905.png

Does this point toward the bit shifters that are used for animation? I'm familiar with it, but didn't have to dig in too deep with my Sea Wolf.

I tried the test ROM for this, but the graphics were not readable, and it would reset every few seconds (watchdog?) (I do need to re-check my 2716 strapping.)
 
if you are using the rom that test all the chips at the same time then you can figure out the chips by position on screen. same position on screen as the seawolf.
 
Example:if RAM 2 and C are faulty, and the others are good, a screen likethis is displayed:






2​

























C​

































































Belowis the mapping between the RAM index and the RAM label



Index

1​

2​

3​

4​

5​

6​

7​

8​

A​

B​

C​

D​

E​

F​

G​

H​

Label

G8​

G9​

G10​

G11​

G12​

G13​

G14​

G15​

H8​

H9​

H10​

H11​

H12​

H13​

H14​

H15​
 
Example:if RAM 2 and C are faulty, and the others are good, a screen likethis is displayed:






2​

























C​

































































Belowis the mapping between the RAM index and the RAM label



Index

1​

2​

3​

4​

5​

6​

7​

8​

A​

B​

C​

D​

E​

F​

G​

H​

Label

G8​

G9​

G10​

G11​

G12​

G13​

G14​

G15​

H8​

H9​

H10​

H11​

H12​

H13​

H14​

H15​

Im not sure if I'm using the same test ROM your are talking about. This is the screen I am seeing. Despite all the corruption, I can still read RAM and shifters are ok.

1000046400.jpg

Here is a video of it running. I guess my strapping is good since it is executing.



Need to think about what I'm looking at here...
 
If the test ROM is saying RAM is ok then that proves everything from CPU to RAM and back again.

You need to look at what's between the RAM and the video output, there isn't much...
 
Check out the characters. All of them are missing the exact same pixels. Like the letter K and numbers 4 and 7. Maybe a problem with that address range in the EPROM?
 
start simple and check the filter cap on the video output. we will work on watchdogging later when the picture looks better but the ram is passing

c4 is my next thought to see if it is working
 
Is that the one that A/C couples in the sync pulses with the data? I tried to quickly measure the ESR before i jumped in the car and it was off the scale. Either it is bad or I need to remove it to get a good measurement.
 
@wugly I think you are on to something with the decoupling cap. Check this out. All of the corruption is on characters where there is a run of active pixels in a row horizontally (from the scan perspective). If that cap is bad, wouldn't the charge decay faster and the voltage would fall off causing all the pixels to be off until the next transition?

1750784980297.png

Was just thinking over lunch. It also explains the missing horizontal lines of the grid. I think the areas with the light vertical lines are solid blocks of active pixels. Won't be able to check it out until tonight.
 
or c4 could be putting out bad data which is the actual video data from the rams. just the first two places I would be looking.

the program is running meaning data is getting back to cpu. data on the output goes through c4 which is same data going to cpu that is working. the monitor sync signals seem to be working so I would be looking at c4 output through the cap to video output
 
Last edited:
or c4 could be putting out bad data which is the actual video data from the rams. just the first two places I would be looking.

the program is running meaning data is getting back to cpu. data on the output goes through c4 which is same data going to cpu that is working. the monitor sync signals seem to be working so I would be looking at c4 output through the cap to video output
It was the cap!

1000046419.jpg

Now to start hooking up inputs and the speaker and see what's next.

Thanks for the help!
 
did the watchdog clear up?
Yeah, the watchdog wasn't working right because I didn't have the 11-pin header plugged in, which left the reset line floating and prevented the watchdog from working properly.

So, all the sounds work, but the inputs look flakey so I'm digging through the port addressing logic to understand it before I try and make sense of what's happening (or not happening) on the board.

After that, probably start working on the monitor.
 
Back
Top Bottom