Your o-scope picture looks like the typical SCR not staying latched problem to me.

Just throwing out some stuff...

In testing i have noticed certain MPU200 games are more likely to show your flickering on the lower address lamps like yours. All i change is the MPU board from a bally game to Stern MPu200 and lamps may flicker.

Lowering the feature lamp voltage can make lamps flicker. More lamps on at once lower the voltage gets increasing the chance to flicker.

Extra load almost always can fix a flickering lamp. When i test lamp drivers with 680R load resistors I use a MPU200 game software that shows the most flickering. Then add any extra resistors to increase load as needed to keep a scr latched

Resistance in the connector contact that goes from the LDB connector to an actual lamp will cause flickering. Need a solid low resistance connection to the lamp or it may flicker. After so many insertion cycles on my tester the plating of the female pins starts to rub off and the lamps begin to flicker. I repin the plug and it goes away.

Like Vid mentioned... all SCRs are not equal in latching. There can be small differences from part to part even in the same lot.

Some other tid bits about SCRs i noticed playing around on a test fixture...

The timing of the firing of the SCR in relation to the wave of the feature lamp voltage seems critical for latching. If I run Bally software (0.5mhz naturally) at MPU-200 speed (0.895mhz) the low positions outputs of the decoders start to flicker. If I run Bally software at 1mhz more lamps start to flicker with most likely ones being low positions on the decoders.

If I run MPU200 software at Bally speed pretty much no SCRs will latch and they all flicker baddly.

Aux lamp driver board almost never show flickering with LEDs. I think it is due to the timing of being updated after the main lamp board is and the feature lamp wave is in a spot more current flows.

Right at a feature lamp that flickers what voltage do you read on the bare wire? Is it more than a couple tenths of a V lower than what you get at the rectifier board? Perhaps the bare wire chain going around the PF is just hanging on by a thread somewhere and it is dropping voltage.

You can even make a single lamp tester for a sanity check. Take a lamp socket. One end put a wire with gator clip on it. The other end put a 0.100" crimp and put it into a small connector housing. You can then attach the gator clip right to the feature lamp bus somewhere you know is solid and then plug the connector end into a lamp driver male pin, like at Q14 and see if your lamp still flickers.

The rectifier is a GBPC3506W by fairchild or on-semi which is a 35a part (assuming you can keep it cool). Should be plenty sufficient. In the -54 rectifier board Bally went back to normal type bridge instead of split into two "varo" diode things. So that really shouldnt matter how the rectification is done. Just rectifier diodes either way in a different package.

I do notice you have what looks like a 6mm x 30mm time fuse in F1. The clips are designed for 6.2mm x 32mm or 1.25" x 0.25" fuses like a MDL(slow) or AGC(fast) fuse in Bussman world. Hopefully I didnt put that fuse in the rectifier board when i sent it out. Anyways since it is a hair smaller, make sure it is fitting in solid and no resistance. I would probably put an AGC-10 fuse in there.

The first decoders output positions are most likely to show flickering assuming because of the timing of firing the SCR compared to where the feature lamp wave is. In this case the SCR fires when the wave is too close to zero to make enough current and flow. The CPU gets a zero X interrupt right when things are at zero. It begins to update the lamp picture starting at outputs 0 and work to 15. When it does output 0 the wave is still too low and not enough current flows and SCR doesnt latch. When the CPU gets to doing output 15 the feature lamp voltage is high enough everything latches no problem.

The pattern of missing probably depends on what the CPU is doing before it handles the interrupt. I'd assume some stuff may take priority over updating the lamps so if the CPU is working on something else it may finish that. Then jump to interrupt routine to do the lamps adding whatever time delay is needed so the SCR fires at a friendlier time.

The timing shouldnt be an issue tho as I can run Future Spa software in a test setup and get all sixty main lamp drivers SCRs to latch every time and all 12 aux lamps too while using LEDs. Makes me think resistance somewhere not letting enough current flow to latch the SCRs at the low position.

Ground return from xfrmer to lamp driver board??? Specially since you hooked the 6vdc feature lamp bus right at the rect board.

The feature lamp circuit is the same. Just the -49 board uses dual diodes to be able to handle more current and there is an extra header pin. The -18 replacement has the extra header pin and the diode bridge is able to handle the high current. The rectifier board is probably the most popular item I sell so lots of the rectifier boards out there and I know at least a handful if not many have replapced the -49 rectifier without any problems. I know a guy with the full LED treatment with a space invaders (-49 originally) and know issues with flickers. I can run future spa on a test setup with same rectifier no issues.

I really doubt the rectifier board itself is the problem. Specially with the wave form reading you took looked OK. Unless the bridge has has a bad diode internally which seems unlikely since it is a brand new part from On Semi or Fairchild.

Looks like the CPU is updating the lamp picture too early compared to the wave of the feature lamp voltage by testing I have done. All i have to do to get your results is to speed up the CPU clock and the lower decoder positions begin to flicker like your example. I don't know about the Alltek MPU, but you can slow down the original Bally MPU's CPU clock by tinkering with cap/res values. I run my replacement MPUs at 0.5mhz and that seems fine. Original Bally MPUs vary clock speed do to tolerance of resistors and caps(-10%/+20% caps) in the clock circuit. I can't really speak to what Alltek CPU clock is or if there is any easy way to slow it down.

What is the CPU clock running at? cpu p37 frequency check.

Not necessarily a blown open or shorted internal diode, but one with far different V-drop than the other three. Again does seem highly unlikely.

I don't know but it is worth checking since a faster CPU clock gives your exact symptoms i'd say the issue is timing somewhere in regards to zero cross, the feature lamp wave, and when the CPU updates the lamp picture. SCR fires too early and the wave is too low so not enough current draws across the SCR to keep it latched is my assumption.

Here is an example of how I can make q14 and q29 flicker running future spa software by increasing the cpu's clock speed. The lamps that end up flickering vary SCR to SCR (ldb to ldb) but always begin at or near decoder output position 0.

I don't exactly know the order the cpu/software updates the lamp picture but Q14 and Q29 are presumably the first two lamps to be updated.

yep. Hz mode of DMM. Black lead on ground and red lead on P37 of the CPU chip. Should be around 0.5mhz or 500khz. Much higher speed than that and you can see the flickering begins. Presumably because the CPU updates the lamp picture before the feature lamp voltage is high enough to latch all the SCRs.

I just checked an original bally mpu and got 0.505mhz. The working example shown above was a nvram.weebly mpu running 0.500mhz bang on because a fixed crystal is used.

Is that extra 50hz in clock speed going to make the feature lamp flicker.....? i dont know but the faster speed is for sure not helping. I can't tell you how to slow down the alltek mpu but tinkering with small changes on the original bally MPU resistors (or caps)in the clock circuit can give you speed adjustment.

Backbox grounding is pretty wonky in a game like future spa. The 12v at the sound board and 5v voltage regulator(could 20khz in SMPS's noise range?) have isolated returns back to the transformer panel (hv too). What if bad grounds on the 12v regulator end up leaving the 5v supply at different potential then the 43v? Could that cause effect on the 43v zero X detection?

I mention because of the picture of the 12v not going all the way to zero.

There is no cap except for one 820pF past the 50% resistor v-divide on the MPU. I wondered about him initially but I don't think that is a problem. There is a fail mode in other games where a sound board diode shorts letting a (100uF) cap smooth the 43v which completely breaks the zero cross detector. MPU no boot.