Nice job on the write up!

The only thing i did differently was to pick up the feature lamp bus right at the rectifer plug and then put it in with the rest of the wire bundle that goes up to the head. Picking up the feature lamp bus right in the head makes sense though.

There is three aux lamp boards. Two are identical sans decoder logic and one has a different pin out (more SCRs).

Any manual with the aux lamp board will give you the pin out of the .156" plugs. I know kings of steel, future spa, kiss, have the smaller aux lamp board. EBD has aux board with more lamp circuits.

I am really familiar with the aux lamp board if you need help with something. It works with the same idea as the first lamp board. Just different decoding chips and latches with lamp strobe 2 instead of 1.

Interesting thing i noticed while testing MPU boards in my test rig.

I use Hot Hand as the normal test software. Test rig has a LED compatible driver board in in and a LED test panel with loading resistors just like the Hans board does.

With Hot Hand software all 60 lamps are working fine in test and game play mode. When I stuff Ali software into the MPU with the same LDB Q57 and Q14 flicker. I grab another MPU with Ali sofware and still the same two LEDs flicker. I grab a different LDB and put it in and a few different LEDs are flickering. I change the MPU software back to Hot Hand and now all sixty LEDs are working again. Also with Ali software the offending lamps start working properly if I change the load R value from 680 to 470. Feature lamp bus is a bang on 6.3vdc on the test rig.

That tells me there is something going on with the software that effects whether are not the SCR may stay latched. Perhaps some kind of refresh duty cycle? MPU 200 clock speed???

Any software guys have comment about the LDB refreshing between games? This might be the reason why the AUX boards usually do not need load resistors. I havent looked at anything with an oscilloscope yet.

When I run Ali software at 500khz every single feature lamp flicker/strobes.

I have a different LDB on the test rig right now and only flickers Q2 with Ali software. The 0000 decoder position might have been a fluke, but interesting thought.

Also odd is the problem is only showing up on Ali software because when I change to Flight 2K without touching anything else all the LEDs behave. Switch back to Ali and Q2 flickers again.

The lamp flickers in game play mode too with just ali... odd.

swapping the Q2 with another is a fix as lowering the load R value. Seems every SCR is not created equally. I have just a few from both On Semi and UTC brands not latching 680R in ali. Easiest and best fix might be to just use 560 or 470R even if it is overkill in most situations. Start getting close to the 1/8w rating of the sip networks in later games using the -54 transformer that run the feature lamps as much as 7v.

Newest MPUs changed R21 to a 27K resistor + 10k trim pot wired up like a rheostat which allows the display interrupt to set to about 300 - 400hz. I might try twizzling that pot to see if it effects the random SCR LED flicker in Ali.

I have noticed the latching current requirement of SCRs is all over the place, even in the name brand parts like on semi it varies lot to lot and even piece to piece. I tested four different brands/part numbers and go figure the cheapest Chinese brand from LCSC has the best latching characteristics out of all the ones I tested. I had one lot of on semi SCRs that wouldnt latch for crap with LEDs unless i really stiffened up the resistors to about 270R-330R. Still was fine for incandescent.

https://datasheet.lcsc.com/szlcsc/1810010233_Changjiang-Electronics-Tech-CJ-MCR100-6_C77884.pdf

I assume the means the original lamp boards are also going to show some variance on latching current and whether or not you get full latching with an add on board.

Once I run out of the current PCB layout I believe am switching the lamp board to use all C106 SCRs and no TO92 packaged ones. The larger packaged C106 SCR seem to have better latching characteristics even tho the data sheet says it shouldn't.

For stern MPU200 games the lowest decoder positions you need about 470ohm load resistor @6v or else you have a good chance some LEDs will not latch the SCRs. For Bally -35 games its about 680ohm on the lowest decoder positions.

Also minor differences in CPU board clock speed will effect latching characteristics too. Its why MPU200 games will always be more likely to have flickering LEDs than Bally games. The faster the CPU clock, the closer they update the feature lamps to zero volts and not enough current flows to latch the SCR.

Add an extra 1k resistor across the offending lamp or do it at the LDB and it should fix. The RL resistor designation number line up with the SCR's designation number. I can swap out the LDB if you want to.

A few months ago I changed my test fixture to try and mimic worst possible case scenario to identify any SCRs that don't want to latch and then tweak that SCR's load resistor value or replace the SCR.

another way to do it may be to intercept the lamp address/data/strobe and delay it to be further from the zero crossing point. shift registers and a clock or something like that.

the aux lamp board never flickers with LEDs because it is refreshed after the main lamp board putting it further from the zero cross point.