I've seen the same thing. With the MPU board out of circuit it doesn't take much noise on that point to trigger the zero crossing detector.
Question is when you did this, does the board reboot after that 7th flash? Does the LED go dim?

Can you measure the frequency out of the 555 timer (pin 3 of U12)?

Essentially it sounds like you're getting stack overflow/corruption of the RAM at U7 either because of bad address line connections to it, or the display interrupt generator running at too high a speed causing the RAM stack to overflow after the 7th LED flash and the game begins initialisation.

FYI, the RAM test on power up only tests that data read was the same as data written. It does not test that data was written/read to/from the expected RAM address. So the RAM test can pass even with a disconnected address line at the RAM chip. U7 RAM is barely used until the 7th LED flash occurs after which the game populates RAM with system/game data and corruption can cause crash/reboot behavior.

Just confirming, this also happens when you fake the 7th LED flash with what you noticed in your "interesting observation" by just touching the top of R17

Get yourself one of those cheap $10 - $20 LCR testers from China or locally - look on ebay, there's hundreds of them. They're useful for testing all sorts of components (I use them to test ESR of capacitors and SCRs) and get one that includes frequency counter functionality.

I've got one of these - yes the plastic case is amateur but it does the job.

ebay.com link: TFT GM328 Transistor Tester Diode LCR ESR meter PWM Square wave Voltmeter LD PL

These problems are nearly always related to the battery corrosion - possibly something around the U8 repair that's upsetting U7 maybe on the top side of the board under the socket.

Have you verified connections to the U7 RAM pins are ok.

With U7 removed, what do the pin receptors in the U7 socket look like?

The 555 area looks ok on your board, since you can't quickly test it I'd leave it for later.

Yes, pulling that U8 socket out will become a major recovery.

Remove the U8 chip and shine a bright light from the back of the board - look carefully on the top side of the U8 socket pins at board level for any shorts between pins/traces.

You might want to carefully clean the flux from the U8 socket repair so you can get a better look - depends if you want to take the risk.

Since there's traces running between pins, you actually need to test for shorts from pin to trace aswell - i.e. shorts won't always appear on adjacent pins.
I use an old fashioned analog multi-meter for doing this. Set the meter for low resistance mode. Meter lead on pin 1 of the chip. Other meter lead on pin 2 and slide that lead across all pins on the chip. When I see the meter needle swing faster than usual I know to recheck those pins for a short. If nothing turns up with pin 1 then move to pin 2, do the same with pin 3 and all other pins until you get to the last pin on the chip.
You can do it with a DMM, I just prefer an analog meter for this due to the instant feedback I get from the meter needle.

Note there are some pins on U8 that are connected together - go by the schematics.

Have you got an EPROM programmer?

Besides the supply pins to U7 and U8, have you confirmed with a logic probe that you're getting activity on all other pins on those RAM chips?

Grab a jumper wire with alligator clips on both ends. Hook a clip to one side of capacitor C16 (near the 555 at U12). Power on the board. As soon as you see the 6th LED flash, clip the other alligator on the other leg of C16 to effectively short it out. This should stop the 555 display interrupt generator. Does the board reboot after the 7th LED flash?
You might need to try this exercise a few times to make sure you short C16 at the right time.

Let's see a pic of the other side!

Good to see you've dealt with the corrosion, it should last another 40 years!

What's the logic probe indicating on the below - hold the logic probe on the pins for the length of the 7 flashes MPU self test:
U7 pins: 10, 11, 16
U8 pins: 17, 18, 19, 21

Ok, so scratch the 555 timer as being the problem.

You got another set of game ROMs you can directly plug in?

I need to see clearer detailed pictures of the board.
Please carefully clean the flux from the U8 socket repair and take photos of the board outdoors in daylight (but not direct sunlight). Full board pics front and back, plus closeups of the corrosion and RAM areas.

Make sure you select the "Original size (no rescaling)" option before uploading the pics so Pinside doesn't squash them.

Pinside_NoScaling.png

Thanks those are much clearer. I think we discussed it on your previous MPU board thread, carefully pop that plastic cover off the U7 socket and the U11 socket. Those Augut covers come off fairly easily. Lets see what condition the pin receptors in the sockets look like. You can put the covers back on later.

Also can you post pics of the U8 socket (both sides) like I've done below with a bright light behind the board?

MPU_Sockets 004a.jpg

On the first pic with the light under U8, try to scrape the crud away between the pins at board level using a pointy metal needle.
There's some bits of crud across the lower side of U7 socket traces - do the same there.

I can't tell from the pictures due to lighting; what is your opinion of the socket pin receptors? Any green corrosion and/or dark tarnished? Pin 1 of U11 doesn't look great. Take a close look at them.

In the picture below is it a piece of shrapnel from the plastic cover circled or something more sinister?

MPU_U11_Socket_PinsA.jpg

Yeah and somehow in the solder bath they didn't bridge.

Doubt it.

What voltage do you measure at the reset line of the CPU (pin 40)? Does it dip the moment it resets after the 7th LED flash?

Have you replaced U7 and U8 with known good chips? Your U8 looks like a remark/fake with a date code of '50... All the Philips 5101 I get from China have original markings in white printing, newest date codes around '94.

BTW, if you have one of those small brass wire brushes, very carefully clean those tarnished legs on the ROMs both inner and outer sides. Also pop off their socket covers for a quick look.

Grab your multi-meter and set it on resistance mode. Connect the red meter lead to a ground point on the board. Using the black meter lead, measure the resistance on all the pins of U7 and U8 and report them back (or just compare them yourself with another board looking for any anomalies).

Lucky you checked another board because my multi-meter gives very different resistance readings that we can't compare.

If you swap the U8 RAM between the boards, does the pin 22 resistance measurement follow the chip or the board?

BTW, I should have mentioned to make sure there's no batteries connected to either board - batteries will invalidate the U8 pin 22 resistance reading.

If you have time it might be an idea to do the same resistance checks on the U9 CPU chip on both boards for comparison.

Excellent work!
To be honest I was getting worried this wasn't going to get solved..

Ok, so looks like the interrupt request line on the CPU (pin 4) was defaulting to always active.
When the board is booting and running the self tests, the CPU has external interrupts disabled (it ignores the state of pin 4). After the board successfully passes the tests, it then enables external interrupts and begins to initialise the game and go into attract mode.
If an external interrupt comes in and the CPU can't determine where it came from, this is considered abnormal so the software is coded to simply reboot. That's the condition your board was in.

There are three valid sources of external interrupts to temporarily change the course of what the CPU is doing:
1) The self test button on the coin door
2) The Display Interrupt Generator (U12) - at 320 times per second it gets the CPU to refresh the display digits
3) Zero Crossing Detector - at 120 times per second it gets the CPU to update game timers (sounds, solenoids, etc), read the switch matrix, refresh the lamps and other system functions