Thanks for describing it farther so I know what to add.

Not wifi, but this is what my old dev setup looked like in Nineball.

sterndevelopment1 (resized).jpg

Glad the OP got it figured out! And added the bug to the TODO list...

Just FYI still working on mine but the small drop coil in Drop 7 is bad on my machine.

Fixed coil, everything fine now. Great work everyone figuring this annoying ass issue out for us and everyone moving forward!

The orange trigger wires on the slings contain one cap each.

The trough micro switches do NOT have any caps.

No caps on lock switches or slings for me. Other machine I play has no caps on slings either.

I believe when looking at the schematics there are only 2 or 3 switches with caps in the machine?

Capacitors are only used on fast activated switches to help the CPU see them activate. They're typically on pop-bumpers, standup targets and rollovers that the ball travels fast over. They're not needed on trough switches.

I noticed your trough caps which I thought was weird.

From what I see caps are on adv Spinner stand up, loop under switch, & dead bumper

Looking at the schematics, there's only 3 switch caps: 1 on the dead bumper, 1 on the 7k/skill shot standing target, and 1 for the upper left loop roll-under gate.

IMG_20191128_115733.jpg

Ah yes thank you, spinner tricked me

I had one on the pop bumper and both slings and found they would often fire multiple times or be too sensitive. I would just install caps at the 3 switches called out on the schematic.

Doubtful.

Have you replaced those caps? They sound too sensitive.

The extra ball coming out in the shooter lane is a symptom of the software issues I'm still looking into.

If you're doing that with your other hand touching a metal side rail (that's wired to ground) that behavior is not unusual.

After the original fixing it up when I got it Nine Ball was working fine as far as locks and multiball for a couple years. The previous league session it went down where the ball would drain and occasionally not spit out another ball. You would have to power cycle the game in this state. No matter what once it lost the balls it could not find them until a reboot. Seemed like it was only happening in multiplayer games.

I found that the middle lock switch was a bit dirty and sometimes was closing and opening fast when the game vibrated, but the main issue (i think) was the outhole kicker. Sometimes when it would kick a ball to the shooter lane the kicker arm was sticking at full throw and causing the trough balls not to sit on the switches correctly. Cleaned the lock switches and fixed the sticky kicker and it seems fine again and survived 4 sets of four player games and a bunch of other random play.

Another software bug I noticed in Nine Ball is similar to the Meteor sound bug but it eventually resolves itself unlike some meteor versions. If the NVRAM is not filled with zeroes there is a good chance the background will be wrong. The background sound (and test) will be funky until you finish a game. At the end of the game the software corrects whatever RAM value causes the wrong sound. Then it is fine forever unless the ram gets corrupt from booting another game software or whatever reason. I chased that problem around thinking a board had an issue until I let it finish a game.

Added these to the list of things to do. The game should be able to deal with multiple switch closures without going crazy. They test the switch for debouncing and then forget that they did so, and randomly will do it again.

Since I just wrote a 'test_switch_closed' routine for my new meteor code, I'll be able to add that to 9 ball as well - the really large issue is that semi-large swaths of code might have to be written unless all of the switch testing 9 ball currently does in assembly can be converted to my new function I should end up with some space then. After 5-6 switch tests I'll be ahead of the curve since the new function will be 'test_switch_closed switch#' and then a 2 or 3 byte function to react to it, instead of lda $34 ora $39 anda #$03 cmpa #$03 bne somewhere which is what most of the switch tests currently are. (10 bytes). I tagged into the checklamp function to be able to do this but I'll need a free ram byte somewhere.... which I can probably pick up after I rewrite the lamp blinking routines which hog 5 bytes they don't even use (they're as if flags need a blink matrix.... they don't.....)